Subject: Fwd: JP Please Look At this

From: Jean Philippe Vasseur <[email-masked]>
Date: Tue, 30 Sep 2003 08:48:39 -0400

Nic,

See comments in line,

>From: Nic Neate [mailto:[email-masked]]
>Sent: Thursday, September 25, 2003 7:42 AM
>To: Cisco - Thomas Nadeau
>Cc: [email-masked]; [email-masked]; [email-masked];
>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; [email-masked]; [email-masked];
>Juniper - Der-Hwa Gan
>Cc: [email-masked]
>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:[email-masked]]
> >Sent: Tuesday, September 23, 2003 6:13 AM
> >To: [email-masked]'; [email-masked]';
> >Juniper - Der-Hwa Gan; Cisco - Thomas Nadeau
> >Cc: [email-masked]'
> >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>

---

From: Nic Neate <[email-masked]>
Date: Tue, 30 Sep 2003 17:38:19 +0100

> Sent: Tuesday, September 30, 2003 5:02 PM
> To: Nic Neate; 'Jean Philippe Vasseur'
> Subject: RE: JP Please Look At this
> 
> 
> 
> 
> >Sent: Tuesday, September 30, 2003 11:42 AM
> >To: 'Jean Philippe Vasseur'
> >Cc: [email-masked]; [email-masked]; 
> >[email-masked]; Juniper - Der-Hwa Gan; Cisco - 
> >Thomas Nadeau
> >Subject: RE: JP Please Look At this
> >
> >
> >JP,
> >
> >Responses are inline.  My main concern here is that the FRR 
> >MIB should be
> >consistent with the FRR draft.
> >
> >Thanks, Nic
> >
> >> From: Jean Philippe Vasseur [mailto:[email-masked]]
> >> Sent: Tuesday, September 30, 2003 1:49 PM
> >> To: Nic Neate
> >> Subject: Fwd: JP Please Look At this
> >> 
> >> 
> >> Nic,
> >> 
> >> See comments in line,
> >> 
> >
> ><snip>
> >
> >> single fast reroutable, not *both*.
> >
> >That's exactly my point - each LSP will use a single FRR 
> >protection method,
> >which hence should be configured in the mplsFrrConstTable.
> >
> >> Moreover, bear in mind 
> >> that from a 
> >Yes, I agree, but the FRR draft does nonetheless allow for a 
> >single LSR to
> >simultaneously support both protection methods.  The FRR MIB 
> >must therefore allow that as well.
> 
> 	Well, it does in a very clean way. It just doesn't in
> the way you are asking for. *) Let me reiterate the reasoning
> behind the current structure which splits the mib into
> three pieces: a common piece, one2one, and facility sections.
> 
> 	1) 	This separation makes it more easy to implement.
> 		If you support one mechanism or another,
> 		you can pick and choose which tables to implement.
> 		The code you generate from the MIB is very
> 		straight-forward. If you for example, want to
> 		implement one2one, you delete all of the facillity-
> 		related code that your compiler generates.
> 
> 	2) 	This separation makes it easier for a device to 
> 		comply with	the standard MIB.  There is no confusion
> 		about which objects apply to which mechanism.
> 
> 	3)	There is less potential for error on the authors'
> 		parts too, because we don't have to worry about
> 		having special parts of description clauses for
> 		each mechanism, or worry about discussing which
> 		object applies depending on the FRR mode.
> 
> 	4)	This makes implementations more efficient because
> 		they will not return columns that do not make
> 		sense for a particular FRR mode. The assumption
> 		is that most implementations will deploy one mode
> 		or another at any given time, so having them
> 		return useless columns wastes CPU time, network
> 		bandwidth, and generally is a waste.
> 
> 	5)	It makes it very convienent for a manager
> 		to quickly and easily go and look at tables
> 		specific to the FRR mechanism they are employing
> 		in their network. If they happen to be in a transition
> 		from one type to another, the device can certainly
> 		return entries from the other mechanism's table
> 		until the transition is completed.
> 
> 	--Tom
> 

That all makes perfect sense.  The mplsFrrConstTable belongs in the common
section of the MIB though.  I should have made that clear from the
beginning.  Without that, there is no way to configure the FAST_REROUTE
object when using facility backup.

All of the fields in this table apply equally to facility and one to one
backup, with no special "Description" clauses required.  That makes it the
natural place to also say whether this tunnel uses facility or one to one
backup.

Nic

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 30 Sep 2003 12:02:16 -0400

>[email-masked];

	--Tom