The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Suggested improvements to the Fast Reroute MIB definition in draft-ietf-mpls-fastreroute-mib-01
Replies inline.
--Tom
>-----Original Message-----
>From: Nic Neate [mailto:Nic.Neate@dataconnection.com]
>Sent: Tuesday, September 23, 2003 6:13 AM
>To: 'riza.cetin@alcatel.be'; 'stefaan.de_cnodder@alcatel.be';
>Juniper - Der-Hwa Gan; Cisco - Thomas Nadeau
>Cc: 'mpls@uu.net'
>Subject: Suggested improvements to the Fast Reroute MIB
>definition in draft-ietf-mpls-fastreroute-mib-01
>
>
>All,
>
>I've been looking at Fast Reroute MIB draft
>(draft-ietf-mpls-fastreroute-mib-01.txt) and I think there are
>a few bugs.
>I've suggested fixes and raised some other ideas below. These
>concern the
>mplsFrrConstProtectionMethod scalar, the mplsFrrConstTable and the
>mplsFrrDetourTable.
>
>Please let me know if you agree with these proposals, or have
>any further
>suggestions. Thanks,
>
>Nic
>
>
>mplsFrrConstProtectionMethod scalar
>===================================
>
>This scalar configures the protection method that is to be
>used. Currently,
>this applies to all LSPs traversing the LSR, however this
>option should be
>configurable per-LSP. Hence the mplsFrrConstProtectionMethod
>should rather be a field in the mplsFrrConstTable. This allows an LSR
to
>simultaneously support LSPs using both protection methods, and
interoperate
>between them, as allowed by the Fast Reroute draft.
It is our understanding that only One2One or Facillity
can be used on all LSPs that a given LSR supports, thus
the configuration is done globally. We do not
know of any products that support both at the same time,
or any that plan to. Can both be supported at the same
time given the current definitions of the standard?
>I suggest removing the mplsFrrConstProtectionMethod scalar,
>and adding the
>following field to the mplsFrrConstTable.
>
> mplsFrrConstProtectionMethod OBJECT-TYPE
> SYNTAX INTEGER { oneToOneBackup(0),
> facilityBackup(1)
> }
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION
> "Indicates which protection method is to be used for fast
> reroute."
> ::= { mplsFrrConstEntry 4 }
>
>Note that the other references to the
>mplsFrrConstProtectionMethod will need
>to be updated correspondingly, and in particular the
>definitions of most of
>the other scalars.
>
>
>mplsFrrConstTable
>=================
>
>A. The current indexing (mplsFrrConstIfIndex,
>mplsFrrConstTunnelIndex and
>mplsFrrConstTunnelInstance) is not sufficient in the case that
>two different
>LSPs use the same interface and have the same tunnel index and tunnel
>instance (but different ingress and egress LSR IDs) and
>require different Fast Reroute configuration.
By "different FRR configuration" do you mean two
mean One2One and Facillity? If so, paste in my response
from above here.
>Rather than adjusting the current indexing, I suggest
>replacing the three
>existing indices with a single integer index,
>mplsFrrConstIndex. This index
>can then be referenced from the mplsTunnelTable and the
>mplsFrrDetourTable,
>establishing a simple indexing system with clear relationships
>between the
>tables (which is also in line with existing relationships
>between tables in
>the TE-MIB and LSR-MIB). Some suggested text follows.
>
> MplsFrrConstIndex ::= TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION
> "Index into mplsFrrConstTable."
> SYNTAX Integer32 (1..65535)
>
> mplsFrrConstIndex OBJECT-TYPE
> SYNTAX MplsFrrConstIndex
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "Uniquely identifies this row."
> ::= { mplsFrrConstEntry 1 }
>
>The mplsTunnelTable should then be extended with a row pointer
>to indicate the mplsFrrConstTable to be used to configure Fast Reroute
>protection for that tunnel as follows.
Why do you suggest using a RowPointer over pure
indexes?
> -- MPLS Fast Reroute Tunnel Table
>
> mplsFrrTunnelTable OBJECT-TYPE
> SYNTAX SEQUENCE OF MplsFrrTunnelEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This table extends the mplsTunnelTable defined in the
> MPLS-TE MIB to provide Fast Reroute configuration."
> ::= { mplsFrrGeneralObjects 1 }
>
> mplsFrrTunnelEntry OBJECT-TYPE
> SYNTAX MplsFrrTunnelEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "This entry provides Fast Reroute configuration for the
> tunnel."
> AUGMENTS { mplsTunnelEntry }
> ::= {mplsFrrTunnelTable 1}
>
> MplsFrrTunnelEntry ::= SEQUENCE {
> mplsFrrTunnelFrrConstPointer RowPointer
> }
>
> mplsFrrTunnelFrrConstPointer OBJECT-TYPE
> SYNTAX RowPointer
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "This variable represents a pointer to the Fast Reroute
> parameter specification for this tunnel. This value may
> point at an entry in the mplsFrrConstTable to indicate
> which mplsFrrConstEntry is to be assigned to this LSP
> instance. This value may optionally point at an
> externally defined Fast Reroute parameter specification
> table. A value of zeroDotZero indicates default Fast
> Reroute parameters if the fastReroute bit in the
> mplsTunnelSessionAttributes is set, and otherwise no Fast
> Reroute protection."
> DEFVAL { zeroDotZero }
> ::= { mplsFrrTunnelEntry 1 }
>
> END
>
>Similarly, the mplsFrrConstIndex field should be added to the
>mplsFrrDetourTable to describe the protection that the detour
>is providing as follows.
Same question as above.
>
>
> mplsFrrDetourFrrConstIndex OBJECT-TYPE
> SYNTAX MplsFrrConstIndexOrZero
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "Index into the mplsFrrConstTable entry that specifies the
> Fast Reroute protection that this detour is providing."
> DEFVAL { 0 }
> ::= { mplsFrrDetourEntry 2 }
>
>B. The mplsFrrConstHopLimit field is not applicable to entries in this
>table representing detours, because this information is only
>known on the
>protected LSP (signaled in the RSVP FAST_REROUTE object). At
>transit detour nodes there is no way to fill in this field, so I
suggest modifying the
>description to the following.
>
> DESCRIPTION
> "The maximum number of hops that the detour LSP may traverse.
> This field is not relevant and should be ignored if this
> entry in the mplsFrrConstTable is being used in the context
> of representing a detour LSP."
OK.
>C. Typo: the mplsFrrConstExclAllAffinity field should be
>mplsFrrConstExclAnyAffinity. See section 4.1 of
>draft-ietf-mpls-rsvp-lsp-fastreroute-03, and the corresponding
>field in the TE-MIB.
OK.
>mplsFrrDetourTable
>==================
>
>A. This table needn't be restricted to detour LSPs, as it is just as
>applicable to the backup LSPs used in the facility method (by
>which I mean
>the backups that are tunneled through the bypass LSPs, not the
>bypass LSPs
>themselves). Simply renaming it to the mplsFrrBackupTable broadens its
>scope in this way, making it twice as useful.
We wanted to keep things separate to keep
conformance/implementation clean. There is a
place to keep information related to backup LSP info.
>B. I think it would be helpful to add pointers from this table to the
>mplsTunnelARHopTable and the mplsTunnelResourceTable, to
>describe the route
>the backup traverses, and the traffic parameters it uses. I
>suggest the
>following new fields (for which I have adopted the rename from
>"mplsFrrDetour* to mplsFrrBackup* as suggested above).
There are already "pointers" by virtue of looking
at the mplsTunnelTable to see the backup LSPs (and their
associated traffic parameters). These will be entries
with special tunnelInstanceIndex values (as described).
> mplsFrrBackupARHopPointer OBJECT-TYPE
> SYNTAX RowPointer
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "This variable represents a pointer an entry in the
> mplsTunnelARHopTable describing the actual hops traversed
> by this backup LSP. A value of zeroDotZero indicates
> that no record of the hops is available."
> DEFVAL { zeroDotZero }
> REFERENCE
> "Srinivansan, C., and A. Viswanathan, T. Nadeau, MPLS Traffic
> Engineering Management Information Base Using SMIv2,
> draft-ietf-mpls-te-mib-12.txt "
> ::= { mplsFrrBackupEntry 6 }
>
> mplsFrrBackupResourcePointer OBJECT-TYPE
> SYNTAX RowPointer
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "This variable represents a pointer to the traffic
> parameter specification for this backup LSP. This
> value may point at an entry in the
> mplsTunnelResourceTable or may optionally point at
> an externally defined traffic parameter specification
> table. A value of zeroDotZero indicates best-effort
> treatment."
> DEFVAL { zeroDotZero }
> REFERENCE
> "Srinivansan, C., and A. Viswanathan, T. Nadeau, MPLS Traffic
> Engineering Management Information Base Using SMIv2,
> draft-ietf-mpls-te-mib-12.txt "
> ::= { mplsFrrBackupEntry 7 }
>
>C. The mplsFrrDetourRole and mplsFrrDetourXCPointer fields mentioned
>elsewhere in the draft have been omitted from the definition
>of the table.
>I suggest incorporating them as follows (again, adopting the
>rename from
>"mplsFrrDetour* to mplsFrrBackup* suggested above).
>
> mplsFrrBackupRole OBJECT-TYPE
> SYNTAX BITS { head(0),
> merging(1)
> }
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "This bitmask describes the role of this backup LSP.
>
> head(0) This flag indicates that this LSR is the
> PLR for this backup.
>
> merging(1) This flag indicates that this backup
> merges with some other backups and/or the
> protected LSP at this LSR."
> ::= { mplsFrrBackupEntry 8 }
>
> mplsFrrBackupXCPointer OBJECT-TYPE
> SYNTAX RowPointer
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "This variable points to a row in the mplsXCTable.
> This table identifies the segments that compose
> this tunnel, their characteristics, and
> relationships to each other."
> REFERENCE
> "Srinivasan, C., Viswanathan, A., and T. Nadeau, MPLS
> Label Switch Router Management Information Base,
> Internet Draft <draft-ietf-mpls-lsr-mib-10.txt>,
> June 2003."
> DEFVAL { zeroDotZero }
> ::= { mplsFrrBackupEntry 9 }
>
|
|