Re: MIBs for GMPLS

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

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

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

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

We'll think about this a bit.

Thanks,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
Tel: 703-847-1867
afarrel@movaz.com