The MPLS WG Archive

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

Bert,
In answer to your second point...

> > > 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.
>
> I do not exactly understand that complexity either.
> Why can it not be a longer octet string that represents the
> label. Why does it have to be an integer for a <32bit label
> and if that value is zero then one needs to follow a ptr
> to some other place where it is basically an octet string?

The issue here is that GMPLS labels may have some format associated with them.
The format dictates subfields, and it may be useful to allow those subfields to
be separately settable/viewable.

Arguments have been made that the context (and perhaps a type indicator) can
dictate the structure of a GMPLS label and it can be left to the NMS to format
the label and present it to the operator. IMHO this is not good enough because
that structure has to be learned from somewhere. It is either encoded in the NMS
(which means the NMS is GMPLS-aware) or in the MIB module. If it is in the MIB
module it could go in a description (which is no help to the NMS), a display
hint (which is possible, but would probably be overly complex), or we break the
label up into its constituent subfields.

I can refer you to the proto-labelTable in the gmpls-lsr-mib (which is sadly old
and blocked behind the MPLS LSR MIB) which gives some impression of what was in
our minds with regard to a table specially for labels.

An index from the LSR MIB into the labelTable is sufficient for most purposes,
and the original plan was to have a field that was either an in-place label or
an index into the labelTable (note that a large number of GMPLS labels have no
substructure and can be encoded in a 32-bit label).

But there was concern from some quarters that multiple labelTables need to be
maintained in some implementations, so a more complex indexing scheme is needed.
The three possible answers (multiple indexes, rowPointer, octetString) have all
been tried and we dance around in circles preferring one then another.

I am still a fan of multiple (i.e. dual) integer indexes (so that I can leave
the primary index as zero in my implementation which does not need this
function).

Adrian