The MPLS WG Archive

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

> -----Original Message-----
> From: Marcus Brunner [mailto:brunner@ccrle.nec.de] 
> Sent: Monday, June 16, 2003 9:38 AM
> To: Loa Andersson; MPLS WG
> Cc: Thomas D. Nadeau; Bert Wijnen
> Subject: Re: prequeal to WG lat call om the LSR mib module
> 
> 
> 
> > 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.
> >
> 
> I find the 24 byte octet string as index really wired. The 
> Unsigned32 was 
> exactly the right thing for me. So I can not support the change.
> 
> >     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 sounds like a problem of information management on the 
> box and has IMHO nothing to do with a MIB design to be useful for
Management 
> Applications.

	Do you have an implementation of this MIB 
and is it distributed that you would care to 
return implementation experience on?

> Indexing always has implications on sorting in the management 
> application. 

	Generally negative ones when the indexing 
is created to be ideal.

> If the sorting based on different applications is needed I 
> would favor the 
> approach with an app index. I assume the app index will be 
> coded into the 24 octet string anyway so why not making 
> it explicit?

	Becuause it adds another index to the indexes.
This has the unfortunate side-effect of making other MIBs
that might reference these indexes (i.e.: LDP/TE/FTN)
more complex.  If you implement MIBs then you understand
that the addition of indexes often leads to more work
on the agent's part and thus a slower implementation. If
you can achieve the same things with a single index,
this seems like the right thing to do.

> >     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.
> 
> Sounds like an offer for incompatible implementations.

	You need to be more specific about what you mean
by that, because I did not imply that this lead to 
incompatabilities. It seems pretty clear to me that whether 
you encode 4 bytes as an Unsigned32 or an octet string,
you get the same semantic meaning.  

	--Tom



> > 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 like this approach the most from the three listed by Adrian 
> some time 
> ago. All have some problems, but this one works for me.
> 
> 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
> Mobile: +49 (0) 163 275 17 43
> personal home page: http://www.brubers.org/marcus
> 
> 
> 
> 
>