Subject: RE: prequeal to WG lat call om the LSR mib module

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 6 Jun 2003 23:35:32 +0200

> > 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.
> >
So... my understanding is that the mplsInSegmentTable
and mplsOutSegmentTable are both read-create tables.

I do not see how the index object (the 24 octets) is
structured, and so I do not understand how an NMS application
that wants to create a specific entry in this table is going
to understand the structure. It now looks as if the NMS app
needs to pickup mplsInSegmentIndexNext or mplsOutSegmentIndexNext
and use that as an index. But will that always work, no matter
what kind of new entry the NMS app wants to create?

> > 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 WG needs to decide... but I find it more complex than
needed. Maybe it is just me.

Bert

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Jun 2003 18:34:24 -0400

Bert,
In answer to your second point...

> 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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sat, 7 Jun 2003 09:17:02 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Adrian Farrel
> Sent: Friday, June 06, 2003 6:34 PM
> To: Wijnen, Bert (Bert); MPLS WG
> Subject: Re: prequeal to WG lat call om the LSR mib module
> 
> 
> Bert,
> 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 

	Right, IMHO the GMPLS-LSR inSegmentTable indexing
will be for example:

	( mplsInSegmentIndex, gmplsLabelSegment )

where the latter index shows you which chunk of the label
you are getting at. Each row in this table can have
other fields such as label type and so on.

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

	You can do this too with an Octet String and make
other implementations happy as well, just encode your
index as (applicationId + ifIndex + label). Your search
time will be exactly the same as if they were three
indexes, and your GetNext function will be simplified.

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sat, 7 Jun 2003 09:22:11 -0400

> Of Wijnen, Bert (Bert)
> Sent: Friday, June 06, 2003 5:36 PM
> To: MPLS WG
> Subject: RE: prequeal to WG lat call om the LSR mib module
> 
> 
> > > MPLSers,
> > >
> > > 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:
> > >
> structured, 

	It isn't, view it as a large Unsigned32.

> and so I do not understand how an NMS application 
> needs to pickup mplsInSegmentIndexNext or 
> mplsOutSegmentIndexNext and use that as an index. But will 
> that always work, no matter what kind of new entry the NMS 
> app wants to create?

	I don't see why not.

> and if that value is zero then one needs to follow a ptr to 
> some other place where it is basically an octet string?

	I personally don't care whether there is a RowPointer
there or a boolean. Between version 09 and 10 the co-authors
had considered both, and it seemed that the RowPointer one
out. IMHO I think that we can re-use the tabular indexing 
from each MPLS-LSR MIB table in the GMPLS MIB and only require 
some indicator that tells someone looking at the MPLS-LSR MIB's 
tables that they need to look elsewhere for the rest of the
label. At one point we had a simple boolean that told
you this. Now we have a RowPointer that is set to zeroDotZero
or an OID. To me, it means the same thing, so at the end of
the day either approach will work just fine.

	--Tom