The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

Randy, et al -

	What Tom has been saying makes a lot of sense.

	If operators want only to deal with a simplified 
MIB - containing (for instance) only those read-only
objects that they need, then the TE working group should
define a subset of the TE-MIB that applies to their needs.
The it falls to the authors of the TE-MIB to make sure it
contains (or continues to contain) all of the objects in
that subset - even if that means adding some to the MIB.

	That way, you don't end up having to support 2 MIBs
with significant overlap and the operators are ensured 
that they can manage their networks in the way that they
would like to.

	This also seems to be an appropriate division of
labor.

	Thanks!

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Friday, August 18, 2000 7:42 AM
> To: Randy Bush; Paul Langille
> Cc: te-wg@UU.NET; mpls@UU.NET
> Subject: Re: consensus to make draft-kompella-mpls-te-mib-00.txt a
> TEWGitem?
> 
> 
> 
> > > 1) I don't understand why the 'interesting' objects in 
> Kireeti's MIB cannot
> > > be folded into the TE-MIB.
> >
> >there are two kinds of designs, union and intersection.  the 
> former is the
> >union of everyone's laundry lists, the latter the minimal 
> intersection.
> >conversations between the two tend to go like
> >   user: the X is far too complex, we only need F
> >   union: you want F, we will add F
> >   user: but we don't want the weight of A, B, C, D, E, and 
> G through Z
> >   union: what do you think X is missing?
> >   user: it's not so much what it's missing, its all that 
> other stuff it has
> >   ...
> 
>          There are several flaws with this argument.
> 
>          0) This can be accomplished by adjusting the conformance
>                  statement of the existing MIBs. The 
> MPLS-TE-MIB authors
>                  are perfectly willing to work with you guys to define
>                  how this should be done.
> 
>          1) There will be a duplication of work. The 
> so-called minimalist
>                  MIB will still have to support generic TE 
> functionallity,
>                  which is already defined by the MPLS-TE-MIB. 
> Why re-invent
>                  the wheel?
> 
>          2) Because it is a so-called minimalist design, it 
> only incorporates
>                  the minimalist design of one particular 
> implementation.
>                  This is because it is essentially a proprietary MIB.
> 
>          3) When does one stop using the so-called minimal 
> one and start
>                  using the MPLS-TE-MIB? When one wants to 
> inter-operate? If
>                  you are really concerned with operational 
> functionality,
>                  then this reason alone would tell you to NOT 
> have 2 MIBs.
> 
> > > 2) What is the real 'purpose' of Kireeti's MIB.
> >
> >finding out where router R will send traffic T in a nice 
> simple way that
> >operational people tend to use.
> 
>          That is very subjective. The MPLS-TE-MIB does this in a nice
>          and simple way too and works for all 
> implementations, not just
>          the ones which have currently implemented Kireeti's 
> products. 
> There
>          are several folks who have or who are implementing 
> the MPLS-TE-MIB,
>          and these folks have not found it to be overly cumbersome to
>          implement or to use.
> 
>          --Tom
> 
>