The MPLS WG Archive

[Cheenu Srinivasan <csrinivasan@tachion.com>]

Title: RE: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG it em?

Vijay Gill wrote:
>
> On Fri, 18 Aug 2000, Cheenu Srinivasan wrote:
>
> > Kireeti's MIB doesn't address numerous issues that would be
> necessary
> > in a standard TE MIB. It supports a very limited model of TE using
> > MPLS (specific to Juniper's switches). And, to put it bluntly, its
> > quite badly designed stylistically as well. Its not a good idea to
> > forget to "keep things as simple as possible but no simpler" or we
> > would end up with
>
> Perhaps we are forgetting what problem we are trying to solve here? It
> supports a very limited and yet very operationally focused model. By a
> very strange coincidence it is what the operators seem to be
> asking for.
> Let us not forget that in the end, the worlds most intricate
> model of a
> MIB that is all things to all people, is not useful if it
> cannot be used
> to solve existing problems now, as opposed to what vendors
> _think_ will be
> existing problems a year from now.

If all you are interested in is Juniper switches I understand your
viewpoint. However, the point of putting together a standard MIB
is to make it general enough to implement on other switches as well.

> As for the badly designed style, I cannot even begin to comment on
> that.  Perhaps a look at the CLNS vs IP design philosophy
> might be worth a
> revisit.

If simplicity (which in this context seems to be minimizing the number
of MIB objects) is all that is needed then we could reduce the whole
MIB to one single octet string. This is essentially the approach taken
in Kireeti's MIB.

>
> > There already exists, and has existed for quite a while, a
> TE MIB in the
> > mplswg. This MIB is generic and has evolved to incorporate
> the comments of
> > the mplswg. Also, it has been deployed in several switches.
> And, there are
> > very good operational and implementation reasons
>
> Yet strangely enough, for almost all purposes which I would
> need to run a
> network, the simple and spare kireeti MIB suffices. Just because I can
> solve some obscure corner case using the generic MIB does not mean I want
> to build a large annoying backend to support solving that corner case. 
> Operational reality is that 90% of most MIBS are never used and I do not
> want to hold up my network waiting till all parties are happy with a
> solution.

Like I said before, from the very narrow viewpoint of deploying a Juniper
network this is true. The existence of several implementations
of MPLS-TE-MIB means and the feedback we have received for close
to 2 years now does not agree with your conclusion about
implementation difficulty. Also, everyone (including you) has had ample
opportunity over this period of time to shape this MIB with their feedback
operationally or otherwise. And, the additional functionality that is
in the Kireeti MIB that is not in MPLS-TE-MIB can easily be added without
complicating the MIB any.

Cheenu