The MPLS WG Archive

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

> -----Original Message-----
> From: Adrian Farrel [mailto:afarrel@movaz.com] 
> Sent: Friday, June 06, 2003 10:51 AM
> To: Loa Andersson; MPLS WG
> Cc: Thomas D. Nadeau; Bert Wijnen
> Subject: Re: prequeal to WG lat call om the LSR mib module
> 
> 
> 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? 

	Because it may be insufficient to identify the 
application's indexing. Although I agree with you that 
having an integer indicate the application's internal ID,
I don't see this as having any advantage over using
a longer addressing space. The reason being that if you allow 
each application to index its entries as it may (i.e.: LDP 
might use destination IPv4 or IPv6 prefixes), then it is 
a straight O(1) indexing operation to get to both the 
application's bag of labels and the entry itself.  The
semantical meaning between an octet string or two integers
is the same, but the flexibility that the octet string affords
you is much better.

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

	I wouldn't characterize it that way. Personally, having 
implemented this and many other MIBs, I will say that octet 
strings are not necessarily a mess, especially in this case
since the octet string truly represents just a potentially
large unsigned integer (or a really small one if that is all
you want to support).

> 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

	This scheme will not work unless we also include an
ifIndex. The reason being that the same application may 
want to distribute the same label on different interfaces
(per-interface label spaces). Using only those two indexes
will not uniquely identify both instances of the same label.
I think that we had arrived at this in Atlanta:

	(ifIndex, appId, label)

	So using this scheme, we now have a triple index
to iterate over, making your GetNext way less efficient
and straight-forward than just using a single octet 
string.  I think this is what pushed us towards using
an octet string.

	--Tom



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