Re: MIBs for GMPLS

[Thomas Nadeau <tnadeau@cisco.com>]

At 11:51 PM 12/14/2001 -0500, Adrian Farrel wrote:
> > > We considered several approaches to producing GMPLS MIBs and 
> presented these
>in
> > > London (if the slides are not still on the Web site I can mail them to
>anyone
> > > interested).
> >
> > Which web site?
>
>IETF.
>I'll mail you under separate cover.
>
> > > The options were...
> > > 1. Recycle the existing MIBs
> > > 2. Add extensions to the existing MIBs as new tables and AUGMENTS
> > > 3. Completely rewrite the MIBs
> > > 4. Make version 2 MIBs
>
>[SNIP]
> > So the decision was for #4 Make Version 2 of the MIBs.
> >
> > Why then are you not calling these LSRv2-MIB and MPLS-TEv2-MIB, etc. ?
> > That is what is typically done.
>
>SNaFU.

         They are not called LSRv2 etc... because they support enhanced
functionality for GMPLS that "classic" MPLS cannot handle.  They are
intended to represent a superset of functions -- classic MPLS being
a superset.  Our thinking was that calling them v2 would just confuse
things. Perhaps we have done this anyway.

> > Further, if these are supposed to eventuall replace documents in the
> > MPLS working group, then isn't it appropriate to let that be known?
> > I have seen no such postings to that working group.
>
>Replace may be too strong a word.  Does the v1 MIB actually need to be 
>retired?
>
>You're correct that we haven't posted widely on the these MIBs yet.  They
>haven't existed long.
>
>I did send a note to the MPLS mailing list when we published the MIBs and
>invited the discussion to be joined on the ccamp list.  It is a good idea to
>send a reminder - I will.
>
> > I do think this is probably a good way to go (although it was not
> > clear from anything that I've read that that was the intent
> > until you explained it here.  Thanks for the explanation.
>
>Good, I'm glad you support the approach,
>
> > > > Also the Labels MIB is glumping everything into
> > > > a single table.  Was the use of separate tables (similar
> > > > to what LDP did for ATM and FR specific objects)
> > > > considered?
> > >
> > > Good choice of word, "glumping".  I confess that I was never a fan of the
> > > multiple table approach!
> > >
> > > >From an implementation point of view there is need be no impact 
> (although I
>can
> > > conceive of implementations where this is not the case :-).  The 
> conformance
> > > statement (of course, should make it clear that implementations can 
> support
> > > whatever set of label-types they like.  Note that an important 
> consideration
>is
> > > the type of labels reported from the network which may not match those
>supported
> > > locally.
> > >
> > > Hope this answers you.
> >
> > Not really.  This is not an implementation issue, it is a MIB design
> > issue.  I think it is sloppy (another highly technical term like
> > glumping ;) to have MIBs look like C union structures. Sorry to be
> > so terse, but I would *hope* the IETF would raise the bar on MIB
> > quality just a tad.  You have no idea if the way the MIB is currently
> > written would be less difficult to implement for most folks.
> > In fact, I would argue just the opposite; based on my experience
> > a poorly designed MIB is far more difficult to implement because
> > it is difficult to understand and it becomes difficult to maintain and
> > scale over time as deprecations/extentions are needed.
>
>OK. Probably bringing implementation into it is not going to help us much.  I
>have plenty of experience of MIB implementation and would not propose 
>anything I
>considered hard to implement, but as you say that is not the issue.

         The idea was not to discuss implementations, but to use existing ones
as a measure of how difficult it would be to support the new ones. Thus
far, it does not seem like it is that difficult to support the new functions
and the old ones on boxes that support both.

>The issue is doing the correct MIB-like thing.
>
>You are suggesting a label table for each type of label.  Presumably the
>referencing object still contains a simple index, and the table to index is
>deduced from the label type.

         We had thought of using this approach, but in the end it seemed like
having one table for all labels (with a label type) was the simplest approach.

>Note that we did not want to use rowPointer because we wanted to facilitate
>non-use of the Label Table in 32 bit label systems by direct inclusion of the
>label (as in the current MIBs).

         Yes.

         --Tom


>We'll think about this a bit.
>
>Thanks,
>Adrian
>--
>Adrian Farrel
>Movaz Networks Inc.
>Tel: 703-847-1867
>afarrel@movaz.com



------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.