The MPLS WG Archive

[Nic Neate <Nic.Neate@dataconnection.com>]

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.

	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>