Re: MIBs for GMPLS

[Joan Cucchiara <jcucchia@CrescentNetworks.com>]

Adrian Farrel wrote:
> 
> Hi Joan.
> 
> > Why is there so much overlap between these
> > MIBs and the MIBs in MPLS?
> >
> > It seems that the MPLS MIBs could be extended
> > for GMPLS specific info and thus avoid so much
> > overlap.  Could you shed some light on this?
> 
> Certainly.
> 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?

> 
> 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
> 
> Now, the feeling (amongst the authors and the implementors that gave us
> feedback) was that there were two prime objectives:
> a. support 'classic' MPLS and GMPLS with the same set of MIBs
> b. cause minimal disruption to people who have implemented the existing MIBs and
> want to move forward to GMPLS.
> 
> This ruled out option 3 (for which we were all hugely greatful!)
> 
> Options 1 and 4 differ only in timing.  When we looked at the timescales to
> produce the GMPLS MIBs we realized that it was likely to take another few months
> before the MIBs were close to being last-callable.  On the other hand, the
> existing MIBs are through WG last call and undergoing final markups for the
> IESG.  The demand for the existing MIBs to reach a stable form is immense and so
> we decided to rule out option 1.
> 
> This leaves option 2 or option 4.
> 
> Although using augmentation seems attractive (it was my first attempt at doing
> this work) when you push into the corners you find that it gets very messy.
> This is not to say it isn't possible, but every table takes a hit.  Other issues
> were
> - new values for existing fields
> - the desirability of a change to indexing in the LSR MIB.
> 
> It was decided that the solution we were most comfortable with was producing a
> version 2 of the MIBs.  This is sufficiently close to version 1 to be
> - understandable by the same group of people
> - easy to modify implementations to support version 2 (or both versions)
> 
> We are, of course, open to persuasive discussion on this point
> 

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

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.

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

  thanks, Joan

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