The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

Loa,
Thanks for the opportunity to comment publicly about this issue.

I believe there is a degree of cyclic redundancy about this debate.

In my view, part of the problem is caused by an attempt to place a tight
association between labels and segment indexing which is not a requirement for
successful implementation.

For the sake of history...

At the MIB meeting in Atlanta there was reluctant agreement to accept an octet
string. This octet string, however, was agreed as a combination of the two
fields (and three functions) that are now being proposed. That is, it provided
an identifier of the label, acted as an index into segment tables, and provided
an index into an external table containing labels. In effect it circumvented
issues of making a rowPointer an index (yuck) and provided a place to store
labels 'in line'.
This was a compromise designed to help implementers who believed that they
needed a more complex index than a single integer equivalent to the label
because the labels might be distributed across multiple label management
components *and* who believed that adding a secondary integer index to point to
the appropriate label management component was not sufficient - they needed an
'arbitrary' secondary index which could only be held in an octet string.

The value of that solution was that an non-32 bit label could be held 'in line'
in the octet string without needing to implement a label table provided that it
was clear from the context how the label should be interpreted.

Looking at the inSegmentTable

The old solution (version 9) had
- an interface index that was an index into the inSegmentTable
- a 23-bit label value that was an index into the inSegmentTable

The requirements are
- to be future-proofed ready to upgrade to GMPLS
- to support distributed solutions

For a while the proposal was
- an interface index that was an index into the inSegmentTable
- a 32-bit value that could be interpreted as
   - a label and an index into the inSegmentTable
   OR
   - an index into a labelTable and an index into the inSegmentTable

This went by the board because
- the labelTable may need to be distributed across components
   making a single 32-bit index hard to implement

The Atlanta solution was
- an interface index that was an index into the inSegmentTable
- an octet string that could be interpreted as
   - a label and an index into the inSegmentTable
   OR
   - an index into a labelTable and an index into the inSegmentTable

This was discarded (as far as I can tell) at least because
- arbitrary indexing of the inSegmentTable was preferred (matches the
   outSegmentTable)
- finding a 23-bit label in an octet string is not nice

This new solution (it is hard to be specific without seeing the relevant
bits of the MIB, but I was allowed to see some early versions) appears
to include
- an arbitrary octet string index for the segment table
- an object to contain the label if it will fit into a 23(sic)-bit value
- a pointer into an external table to hold labels otherwise
- an object to contain the interface index

I do not understand why an octet string index is needed. If you need your
insegment index to identify the location of the component that maintains the
segment, and you need that location to dictate the index, why do you not simply
use two integers? Integer searches are cheaper to implement - octet string
searches are a mess. (Yes, I know you can encode two integers into an octet
string, but that is hardly the point.)

Why not have
- an arbitrary primary integer index for the segment table
   this could be used as the component id or set to zero
   this could be used to contain the interface index if you want
- an arbitrary secondary integer index for the segment table
   this could be used as the label value if that is how your mind works
- a 32-bit object to contain the label if it will fit
   thus MPLS 23-bit labels and GMPLS 32-bit labels will fit
- a pointer into an external table to hold labels otherwise
- an object to contain the interface index

Adrian


----- Original Message -----
From: "Loa Andersson" <loa@pi.se>
To: "MPLS WG" <mpls@UU.NET>
Cc: "Thomas D. Nadeau" <tnadeau@cisco.com>; "Bert Wijnen" <bwijnen@lucent.com>
Sent: Friday, June 06, 2003 3:04 AM
Subject: prequeal to WG lat call om the LSR mib module


>
>
> MPLSers,
>
> included are two major items that the authors, wg-chairs and ADs
> want specific comments on when the LSR mib module is published and
> last called. The MIB will be sent to the Internet Drafts today (Friaday)
> but will take a few days before it is announced. The last call will be
> started by a specific mail, as soon as we see it publiched, and will be
> limitied to changes since the last version. The discussion on the items
> below could take place as a part of the wg last call.
>
>
> The items are:
>
> 1) The indexing of the in/out/XC
>     tables has changed from Unsigned32s
>     to Octet Strings of up to 24 bytes
>     in length.
>
>     The reason this was done was to facilitate
>     LSRs that support multiple applications of
>     MPLS in a distribute fashion. Use of a
>     flat 32 bit indexing space on these platforms
>     ends up with VERY slot N^2+ GetNext searches
>     due to the fact that labels are distributed
>     among different applications. The GetNext
>     routine must then query each application's
>     "bag" of labels to determine the next index.
>
>     This change is compatible with implementations
>     that wish to remain with the 4 byte indexing;
>     they just use a 4 byte octet string, while others
>     are free to use the more specific indexing.
>
> 2) The addition of a RowPointer to the in/out/label
>     stack tables to support "long" or GMPLS-style
>     labels. The RowPointer is normally set to zeroDotZero
>     except when the MIB needs to refer to an external
>     table that defines labels that exceed the 32bits
>     of space alloted in the tables today.  This
>     in essence, future-proofs the MIB and makes
>     it compatible immediately with the GMPLS MIBs
>     defined in CCAMP.
>

> --
> /Loa
>
> mobile + 46 739 81 21 64
> email: loa@pi.se
>