Subject: Suggested improvements to the Fast Reroute MIB definition in draf t-ietf-mpls-fastreroute-mib-01

From: Nic Neate <[email-masked]>
Date: Tue, 23 Sep 2003 11:13:16 +0100

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.

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.

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.

   -- 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.

   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."

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.

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.

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).

   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 }