The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

         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 <te-wg@uu.net>, 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