The MPLS WG Archive

[Vijay Gill <vijay@umbc.edu>]

On Fri, 18 Aug 2000, Paul Langille wrote:

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

>     I vote for "b". I don't think this MIB is quite ready for 'prime time'.
> There are a few issues that (in my humble opinion) need to be addressed.

Define prime time. We have networks to run. Now. Networks cannot be put on
hold till prime time.

>     1) I don't understand why the 'interesting' objects in Kireeti's
> MIB cannot be folded into the TE-MIB. A lot of the objects are
> duplicates. I would like to implement just one MIB. What are the pros
> and cons of merging these two drafts? (I feel you need a pretty strong
> argument to justify the duplication.)

1 - There is a set of features that we (the operators) need.

2 - There is a set of features that some people who mostly tend to be
    vendors think we (the operators) need.

3 - There is a set of features that some people who mostly tend to be
    vendors think we (the operators) might need.

#3 is a superset of #2 and #2 is a superset of #1.

Do not give us features you think we need, rather, give us features we
need. And this way, we will be all one big happy family.

The general trend in the IETF has been towards feature bloat. Bigger,
better, more.  And as an end result, we've ended up overkill, overdesign,
and endless bickerings.


>     2) What is the real 'purpose' of Kireeti's MIB. I would like to
> see a model or some other draft that gives a better description of the
> objects in the MIB


The real purpose of the MIB is to allow some set of operators using TE to
run their networks properly and hopefully, make some money while they're
at it.

> (i.e. it needs reference clauses on many of the objects). I think a
> lot of the objects in the MIB need clearer definition. Most MIBs tend
> to be a fallout of an existing draft. (For example the TE-MIB is based
> on CR-LDP and RSVP Tunnels.) Defining functionality via a MIB is
> typically a difficult process. Diffserv ran into this problem when
> they started the Diffserv-MIB. To clearly understand the specific
> objects Diffserv needed the model draft. (I am not saying that we need

As yes, Diffserv. Perhaps not the best example to bring up here.

/vijay