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 11:32:56 -0400

Jim Boyle wrote:
> 
> Should Kireeti's draft
> a) be accepted as a TE WG item at this time?
> b) not be accepted as a TE WG item at this time?

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 

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

So, Kireeti's draft should not be a working group document. If there is any
functionality that is needed in the existing TE MIB, based on WG consensus,
it can be added and that is the best course of action at this point.

>It'd be nice to limit the distro to <[email-masked]>, unless there is 
>objection, to limit sorting through duplicate messages.

Many people with an interest in this thread may not be subscribed to the
TE list. Let's keep the discussion on both lists.

Thanks,
Cheenu

---

From: Vijay Gill <[email-masked]>
Date: Fri, 18 Aug 2000 16:54:51 -0400

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.

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. 

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

/vijay

---

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

>very strange coincidence it is what the operators seem to be asking for.

         This is only what a certain subset of operators are looking for.
The operators who are using the MPLS-TE-MIB which I have spoken to
are very happy with it. I believe this set to be much larger than
the 3 or 4 who seem to want to use Kireeti's MIB to completely manage
their MPLS LSRs.

>network, the simple and spare kireeti MIB suffices.

         Yet strangely enough, it only suffices for networks which are
comprised of Juniper switches. Funny how that is, since it is
the Juniper proprietary MIB. I am sure that you would have the
same success with vendor X's proprietary MIBs as well.

>Just because I can

         I hardly belive that fast-reroute, auto-bandwidth tunnels,
fast-reroute, tunnel path options, ER-LSPs, tunnel interface
statistics, etc.. are obscure problems. These may be obscure vapor
ware in the limited implementation from the vendor which you are
deploying LSRs from, but not in others that I know of.

         --Tom