The MPLS WG Archive

[Spencer.Giacalone@predictive.com]

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 <kireeti@juniper.net>
Sent by: owner-te-wg@UU.NET
08/19/00 07:20 PM

 
        To:     jboyle@Level3.net, te-wg@UU.NET
        cc:     mpls@UU.NET
        Subject:        Re: consensus to make draft-kompella-mpls-te-mib-00.txt a TEWG item?


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.