Re: MIBs for GMPLS

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

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

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


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

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