The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Fwd: JP Please Look At this
Nic,
See comments in line,
>From: Nic Neate [mailto:Nic.Neate@dataconnection.com]
>Sent: Thursday, September 25, 2003 7:42 AM
>To: Cisco - Thomas Nadeau
>Cc: mpls@uu.net; riza.cetin@alcatel.be; stefaan.de_cnodder@alcatel.be;
>Juniper - Der-Hwa Gan
>Subject: RE: Suggested improvements to the Fast Reroute MIB definition
>in draft-ietf-mpls-fastreroute-mib-01
>
>
>Tom,
>
>Thanks for your feedback. Responses inline - I think my points still
>stand.
>
>Nic.
>
>-----Original Message-----
>From: Cisco - Thomas Nadeau
>Sent: Wednesday, September 24, 2003 8:32 PM
>To: Nic Neate; riza.cetin@alcatel.be; stefaan.de_cnodder@alcatel.be;
>Juniper - Der-Hwa Gan
>Cc: mpls@uu.net
>Subject: RE: 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.
The FRR draft allows to support both one-to-one and facility backup and the
preference for one method or the other can be signalled in the FAST REROUTE
object but on a single hop, one *or* the other will be used to protect a
single fast reroutable, not *both*. Moreover, bear in mind that from a
realistic standpoint, the likelihood that both method are deployed in the
same network is not very high, except during a transition period.
In my opinion the current MIB structure perfectly makes sense.
JP.
> 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?
>
><Nic>
>Data Connection has an implementation that supports both methods at the
>same
>time. This is covered by the spec - see this paragraph from section 0
>of
>the FRR draft.
>
> This draft rationalizes the RSVP signaling for both methods such
> that any implementation can recognize all FRR requests and clearly
> respond, either positively if they are capable of performing the
> method, or with a clear error such that requester is informed and
> can seek alternate means of backup. This draft also allows a
> single implementation to support both methods, thereby providing a
> range of capabilities. Thus the described behavior and extensions
> to RSVP allow LERs and LSRs to implement either or both methods.
></Nic>
>
> >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.
>
><Nic>
>By "different FRR configuration" I mean any difference in the
>configuration
>supplied by the mplsFrrConstTable, for example a different
>mplsFrrConstBandwidth for the backup LSPs.
></Nic>
>
> >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?
>
><Nic>
>I don't have a strong argument either way - in your capacity as "Mr MIB"
>you're best placed to advise. I originally suggested a RowPointer
>because
>the mplsFrrConstTable and mplsTunnelTable are in different MIBs, and
>because
>some implementations may wish to use some other table for FRR
>configuration.
>Currently the mplsTunnelTable contains both RowPointers and indices to
>reference other tables - I'd be interested to know what the logic is in
>the
>existing cases for choosing one over the other.
></Nic>
>
> > -- 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.
>
><Nic>
>Again, I don't have a strong argument for using an index over a
>RowPointer.
>I suggested a simple index in this case because the tables are closely
>related in the same MIB.
></Nic>
>
> >
> >
> > 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.
>
><Nic>
>There is information in this table not covered in the
>mplsFrrFacRouteDBTable
>(or anywhere else for facility backups). For example the XC pointer.
>Hence
>there is value in using this table to provide information about all
>backups
>and not just detours. (Note though that bypass LSPs aren't included in
>the
>definition of "backup" - see the FRR draft).
></Nic>
>
> >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).
>
><Nic>
>I think there may be some confusion here because I have called the
>fields
>mplsFrrBackup* rather than mplsFrrDetour* (because of my suggestion
>above to
>rename the table in that way). There is nothing in the mplsTunnelTable
>about detours (I think that is the principle requirement for an
>mplsFrrDetourTable).
></Nic>
>
> > 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 }
> >
>
><Nic>
>Any comments on this last suggestion?
></Nic>
|
|