Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG item?

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

Hi Jim,

>As for Kireeti's mib, it was mentioned in the interim meeting as a fine 
>example
>of a mib that real operational networks are actually using and that it has 
>a good
>set of operational information needed to monitor and manage TE-based 
>networks.
>His mib is operationally focused.

         His MIB is operationally focused, but it fails to cover many of the
scenarios which a *standard* TE MIB should support, and will need to be
modified heavily in the future to effectively be able to manage the things
that the MPLS-TE-MIB can manage today. This will effectively duplicate all 
of the
hard work done by folks in the MPLS WG over the past 2 years. I would also
argue that it is focused to support a SMALL subset of MPLS features, in 
particular,
those which are only supported by Juniper switches. It also assumes a 
particular
view of TE tunnels which his product only supports. The MPLS TE MIB does not.
Last I checked, there were many other LSR vendors out there deploying MPLS!
Furthermore, its structure is poor as far as MIBs go. Has anyone actually 
looked
over this MIB? It contains things like the hop table as an OCTET STRING. 
Yea, sure,
it can be modified to be more MIB-correct, but I would argue that doing so 
would
require him to add something like the Hop table which is already in the 
MPLS-TE-MIB,
so it would in the end, look "more complicated" like the MPLS-TE-MIB anyway.

         To comment about the operational deployment of the MPLS MIBs, I 
was cut off
at the meeting before I could explain that there are several deployments of 
the MPLS
LSR/TE MIBs out there now. All seem to work fine, and when they have not,
the implementors have been courteous enough to supply their comments to the 
MPLS
WG mailing list so that we could make the MPLS-TE-MIB better. There is nothing
academic about the MPLS-TE-MIB.

         Finally, if everyone is so concerned with operational deployment,
hasn't anyone considered the fact that two MIBs present an operational pain
for those implementing NMS systems and for those who are implementing
the LSRs? This seems why in the past, there have not been two MIBs deployed
by the IETF to manage the same thing! It means twice the work for those who
wish to implement both, and means totally confusing those who are trying
to manage these systems. Hmmm, which MIB do I use? Oh, this is a vendor X box,
I should use TE-TE-MIB. Oh, this is vendor X v2.3.4, I should use MPLS-TE-MIB.
Totally confusing.  This is why the IETF has deployed a single MIB to
manage a single feature.

>The MPLS WG TE mib seems very focused on configuration.  One might also 
>argue that it could be cumbersome to implement solely to get the benefits 
>of an added perf type table, which by itself can be represented as in 
>Kireeti's draft.  So clearly, they currently address different roles, and 
>as such, appear to have little overlap.

         That is not true. Operational statistics are available in the 
MPLS-TE-MIB,
LSR-MIB and RFC2233 Interfaces MIBs. The MPLS MIBs were all designed to work
together and with the ifMIB. Furthermore, the few features which were not
included in the MPLS-TE-MIB which were in the other draft, can easily be
incorporated, and would have been a long time ago if Kireeti had pointed out
the fact that we had missed them. The MPLS-TE-MIB authors have no beef with
adding or modifying the TE MIB if the WGs think that it needs to be modified.
We also have no objection to working with folks to make certain parts of the
MPLS-TE-MIB optional for those who think that it is somehow too large.
However, we will not know about these concerns unless folks post them
to the WG mailing lists. I am still wondering why Kireeti has not proposed his
specific changes to the MPLS-WG's mailing list.

>Should Kireeti's draft
>a) be accepted as a TE WG item at this time?

         NO.

>b) not be accepted as a TE WG item at this time?

         YES. 1) too confusing having two MIBs to manage the same thing, 2) 
too limited.

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

         Some folks might only be subscribed to the MPLS WG mailing list, 
and will
not be aware of the discussion. I think that we should distribute to both.

         --Tom

---

From: Kireeti Kompella <[email-masked]>
Date: Sat, 19 Aug 2000 16:20:46 -0700 (PDT)

Hi,

Reading through the vigorous debate in response to Jim's mail (thanks,
Jim!), especially Randy's, Vijay's and other service providers' input,
a thought crystallized; and I have a suggestion.

Let me cut to the chase:

***  Rename draft-ietf-mpls-te-mib      ***
***  to     draft-ietf-mpls-tunnel-mib  ***

There will be those who reject the above out-of-hand.  The rest
may care to read on and see if the following makes sense.

------------------

1) te-mib = Traffic Engineering MIB

Traffic Engineering is the mapping of traffic to traffic trunks
(see RFC 2702) for the purpose of performance optimization of
networks.  Vital to this is the routing of the traffic trunks; an
important component is the use of constraints and constraint-based
routing to this end.  Pragmatism (and RFC 2702) also dictates that
there be alternative paths for a trunk (read: primary/secondary paths).

Therefore, it would seem logical for a TE MIB to offer means to view:

a) administrative group information;
b) constraints on traffic trunks;
c) the means by which constraint information was obtained;
d) the results of constraint-based routing (EROs).

Furthermore, since trunk routing is important:

e) stats on how often trunks were re-routed (and the last time this
   happened).

From the T in TE:

f) stats on packet and octet counts through a traffic trunk.

Finally, since the objective of TE is to "optimize the network":

g) how much time a trunk used its primary path (more optimal) vs.
h) how much time a trunk used a secondary path (less optimal) vs.
i) how much time a trunk was down.

Of all of the above, the "mpls-tunnel-mib" only provides the ERO.
The "te-mib" provides all of the above.  There may be other info that
is TE-related that one or the other MIB provides, or that neither
does; however, that is for the TE WG to determine and recommend.

Action item: replace all occurences of "mplsLsp..." in the "Kireeti"
TE MIB with "trafficTrunk...".

-------------------

2) MPLS Tunnel MIB = Tunnel + MPLS

The excellently written "mpls-tunnel-mib" doesn't once mention
traffic engineering in its "features list" (section 4) or its
outline (section 5), except in naming the MIB.  These two
sections focus exclusively on tunnels, as does the entire MIB.

Furthermore, the MIB does a good job of deconstructing tunnels
into their constituent components (segments), and offers the
flexibility of defining
   a) point-to-point tunnels;
   b) multipoint-to-point tunnels;
   c) point-to-multipoint tunnels;

and of defining tunnel properties, such as whether or not they
are interfaces, fast-reroute, merging-permitted, ...

So, this is very much a tunnel MIB.

Moreover, the MIB offers (through close interaction with the LSR
MIB) the labels in and labels out information -- hence very much
an MPLS MIB.

The above information, while largely irrelevant to Traffic
Engineering, is vital indeed (as witness the large following the
MIB has).  The two years of work that has gone into this MIB have
been well spent.

---------------------

3) The argument to incorporate the TE MIB into the MPLS Tunnel MIB
   because MPLS tunnels can be used to do TE extends naturally to:
   incorporate the Diff-Serv MIB into the MPLS Tunnel MIB because
   MPLS tunnels can be used very effectively to do Diff Serv (RFC
   2430 and draft-ietf-mpls-diff-ext); and (in its ludicrous extreme)
   to fold in the interface MIB since MPLS tunnels can be interfaces.

This argument is best put to rest.

Kireeti.

---

From: [email-masked]
Date: Mon, 21 Aug 2000 09:24:55 -0400

My opinion is that we should merge the MIBs into a single draft so that 
the operators can manage things "now". Obviously, this also gets us out 
the duplicate MIB issue. 

We can work on the new (combined) draft to add whatever we want- that's 
what the draft process is for. We shouldn't _only_ be looking at what 
operators wish for/need/want/ for the moment. 

If the MIB gets to out of hand in the future (big), well, that's why we 
have compliance statements. 

Wouldn't this solution address both side's concerns? Merging salient 
objects seems like an easy and obvious solution. 

Yes, I have seen Randy's posts regarding union/intersection, etc,etc. 

As far as the Juniper bashing goes, (you/we know who you are) you might 
want to go back and read the thread; several operators _have_ been 
posting.. I find it hard to believe all these shops only run Juniper (I 
could be wrong) yet, they still like the Kireeti MIB.  go figure. 

-Spence

Kireeti Kompella <[email-masked]>
Sent by: [email-masked]
08/19/00 07:20 PM

        To:     [email-masked], [email-masked]
        cc:     [email-masked]
        Subject:        Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG item?

Hi,

Let me cut to the chase:

------------------

From the T in TE:

-------------------

---------------------

Kireeti.

---

From: [email-masked]
Date: Fri, 18 Aug 2000 17:34:47 EDT

> b) not be accepted as a TE WG item at this time?

In view of the existence of a perfectly adequate te mib in the mplswg
which has existed for quite a while now I propose that this new MIB not
be accepted as a tewg draft. We certainly do not want two MIBs for MPLS
TE!

Tom

---------------------------------------------
This message was sent using MI-Webmail.
No matter where you are, never lose touch.
Get your Email using MI-Webmail.
http://www.monmouth.com/