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

From: Cheenu Srinivasan <[email-masked]>
Date: Fri, 18 Aug 2000 17:23:36 -0400

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

---

From: Vijay Gill <[email-masked]>
Date: Fri, 18 Aug 2000 17:25:52 -0400

> is to make it general enough to implement on other switches as well.

That I do not argue with.  In fact, we would very much like to have this
on all LSRs, such that we can switch out the front ends without having to
change the backends out.  What we would like is that the kireeti MIB be
standardized with the specical JNX bits generalized. The MIB is a good
match to how networks are being operated today, and as such, should form a
good basis for a standard MIB implemented across all platforms.

/vijay

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 18 Aug 2000 21:21:27 -0400

Hi,

>good basis for a standard MIB implemented across all platforms.

         So why not just take the salient features out of that MIB and
put them into the MPLS-TE-MIB? All of these features could easily be
included in the TE-MIB, as well as other features for the
others who were interested in them. If you have looked at the
MPLS-TE-MIB lately (which I unfortunately do not believe many
of the folks commenting for keeping this other MIB today have not),
it is not that much larger than Kireeti's MIB in terms of tables to
manage. The change in your operational software should not be that significant
considering the structure of things. We currently have 4 tables, one of which
is optional. Two of these tables are basically for the tunnel Hop information
which Kireeti has crammed into a single OCTET-STRING (very bad design).
If you don't care to look at LSP information, then don't follow the
XCIndex down into the MPLS-LSR-MIB and be done with it. We can easily
make conforming with the MIB easier by making some other tables
optional.

         --Tom