The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

:
>At the MIB review meeting in Atlanta, we discussed the issue of indexing 
>the XCTable. Is there a resolution now how this should work?

         The solution agreed to is as follows using the MPLS LSR-MIB's
mplsInSegmentTable:

         (ifIndex, labelCategory, OctetString(24 bytes))

         labelCategory { mpls, gmplsSonet, gmplsTDM }

         To use the pair, you first check the type which tells you
         what type of label to expect. If the labelCategory is set to mpls,
         then the mplsInSegmentTopLabel object is queried for
         the 20 bit MPLS label.

         If the labelCategory is something else, you need to query
         the gmplsInSegmentLabelTable (GMPLS LSR MIB),
         which looks like:

         gmplsInSegmentLabelTable
         INDEX ( labelPrimaryIndex (OctetString (24 bytes)),
                    labelPartIndex (Unsigned32))
         This table has one object that is an OctetString that
                 contains the actual label value (or the piece
                 of the label if it spans more than one Octet String).

         The first index gets  you to the group of octet strings used
                 to represent the long label, and the second gets you
                 to the specific "chunk" of the label.  I propose that
                 we let the "chunk" index of 0 specify that only
                 1 "chunk" exists, so that the NMS need not look
                 further for the label's value.

         The agreement was to replace any instance where an
MPLS label appeared in any of the MIBs to include the (type,
octet string) pair and to have the gmpls label table extensions
used to extend places where it was necessary to represent those
labels in GMPLS.

>Additionally, I tried to explain the problem again to some people here, 
>but was not able anymore to recall what the problem really was.

         The problem was many fold:

         1) Use of (ifIndex, label (32 bits)) is not sufficient to
                 index GMPLS labels which are (in theory) unlimited
                 in length.

         2) Overloading the label to say that if the top bits were
                 set to indicate that the label was really a GMPLS
                 label table index was unacceptable.

         3) Use of the 32 bit label value to index (easily at least) all
                 of the many applications of MPLS on a box that
                 supported all current applications did not work.

>They ask me why we need mplsXCInSegmentIfIndex, mplsXCInSegmentLabel as 
>index instead of mplsInSegmentIndex. The explanation might be added to the 
>description as well.

         I think that the explanation of what the fields are and how they are
used belongs in the MIB, but the details of why we chose what we
did over say any other approach belongs in meeting minutes.

         --Tom




>Marcus
>
>--------------------------------------
>Marcus Brunner
>Network Laboratories
>NEC Europe Ltd.
>
>E-Mail: brunner@ccrle.nec.de
>WWW:    http://www.ccrle.nec.de/
>Phone: +49 (0) 6221 905 11 29
>personal home page: http://www.brubers.org/marcus
>

"The difficult, we do immediately.  The impossible takes a little longer." 
-- Air Force Motto