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

From: Jim Boyle <[email-masked]>
Date: Thu, 17 Aug 2000 22:19:19 -0600

On July 27 "Cucchiara, Joan" <[email-masked]> wrote:
|
|Lastly, is the TE working group going to be developing MIBs and/or PIBs?
|In my opinion this is not clear from the working group's charter.
|
|  Thank you, Joan

It isn't an explicit deliverable in the charter, except that in general the 
TEWG is to "develop ... specify... techniques.. for TE in the Internet"

The interim meeting sort of focused in on
o) why would one do TE
o) what are some of the issues with TE today
o) what measurements are needed to effectively do TE

Mibs fall square in the last one above.  Perhaps a clear re-charter is in 
order on the TE, however.

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.

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.

There was (as usual on Mibs) a bit of apathy in the TE meeting in 
pittsburgh, however it was voiced loudly that standardization of a simple 
straightforward mib is a good thing and Kireeti's draft was likely the most 
appropriate vehicle for this.

So, with that said - I'd like to see what the consensus of the list is.

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

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

thanks,

Jim

---

From: Paul Langille <[email-masked]>
Date: Fri, 18 Aug 2000 10:27:46 -0400

Jim Boyle wrote:

<snip>

> 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.

    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.)

    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
(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 a model draft but I feel this draft needs some sort of
reference. Without this reference we will spin for a long time on the object
definitions.)

        Paul
--
Paul Langille                e-mail: [email-masked]
Crescent Networks            phone: (978) 244-9002 x244
201 Riverneck Road           fax: (978) 244-9211
Chelmsford, MA 01824

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 18 Aug 2000 10:42:22 -0400

> > 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

---

From: Vijay Gill <[email-masked]>
Date: Fri, 18 Aug 2000 13:36:22 -0400

> 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

---

From: Vijay Gill <[email-masked]>
Date: Fri, 18 Aug 2000 13:42:16 -0400

>                  This is because it is essentially a proprietary MIB.

The design basis of the MIB was based upon network operators needs.

1) What we want

2) What you think we want

There are very subtle differences between those two statements.

>                  then this reason alone would tell you to NOT have 2 MIBs.

So we propose using the kireeti MIB as the basis. The kireeti MIB is based
in reality of operational need, which is a fine place to start from, I
assure you.

/vijay

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 18 Aug 2000 14:06:38 -0400

>There are very subtle differences between those two statements.

         Yes, there is a subtle difference and it is really who "we"
is defined as. To you "we" is defined as the small set of operators
who are currently are using Juniper switches, and of course, those folks
love Kireeti's MIB. It is not however, the model necessarily used
for managing the other LSRs that are out there. There are many others
who use the MPLS-TE-MIB and MPLS-LSR-MIBs for managing their switches/routers.
I have said it once, and I will say it again, if you want to use Juniper's
proprietary MIB to manage your LSRs, then go ahead. If you want to use a
standard MIB to manage the rest of the LSRs in the world, then
use those MIBs which are being defined by the MPLS WG. If the standard
MIB does not suit your needs, then by all means, join in the discussion
of defining it.

>in reality of operational need, which is a fine place to start from, I

         What I will assure you of is that the Kireeti-MIB is based on the
reality of the Juniper implementation. This is not the reality of what the
rest of the world uses. Furthermore, it does not necessarily contain the
operational reality of MPLS features that other LSR vendors are currently
deploying due to its incomplete nature.

         --Tom

---

From: Ron Bonica <[email-masked]>
Date: Fri, 18 Aug 2000 14:47:53 -0500

> deploying due to its incomplete nature.

Tom,

I am an operator with MPLS deployed in my network. For fault management
purposes, I need to know the following:

	-> which LSPs are broken
	-> which LSPs are sub-optimally routed
	-> which LSPs have reset

Using Kireeti's MIB, I can answer these questions by polling the following
items:

	-> mplsLspState
	-> mplsPathType
	-> mplsLspLastPathChange

This is pretty simple.

Couldn't this level of abstraction be applied to any MPLS implementation?

Please re-orient me if I am missing some very fundamental issue.

                           Ron

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 18 Aug 2000 14:52:26 -0400

Hi Ron,

>Couldn't this level of abstraction be applied to any MPLS implementation?

         Yes. These were precisely some of the salient features
from Kireeti's MIB which we were trying to incorporate into
the MPLS-TE-MIB. However, we need Kireeti's and the TE WG's
help to make sure that these are really the things that people
need added. FYI, these attributes can be easily added to the
mplsTunnelTable in the MPLS-TE-MIB. It may also be favorable to
add traps for these state changes rather than polling.

>Please re-orient me if I am missing some very fundamental issue.

         Nope. Makes perfect sense to me.

         --Tom

---

From: Vijay Gill <[email-masked]>
Date: Fri, 18 Aug 2000 17:14:14 -0400

> deploying due to its incomplete nature.

Ah yes, I see the disconnect now.

I am coming from the reality of the operators world, who have to use these
things on a daily basis to keep a network up and running vs the reality of
those vendors who think they know better than we what we want.

/vijay

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 18 Aug 2000 21:06:13 -0400

>I am coming from the reality of the operators world, who have to use these

         You are coming from the reality of a rather small operator
world that only uses Juniper boxes in their network. I am
trying to speak for those operators who I have spoken with, who
are in the majority. These folks have networks which are not comprised
of a single vendor's devices. This group manages networks comprised of
boxes from many vendors and would specifically like to use a single MIB
to do this. It is an operational nightmare to have to figure out which
vendors boxes (and perhaps which versions of those boxes) use which
standard MIB. In these cases your Juniper-specific solution just will
not work for the reasons which I and others have outlined about 10 times
today. I hope that people are seeing this situation for what it really
is.

>those vendors who think they know better than we what we want.

         If I understand you correctly the, "reality of those vendors who
think they know better than we what we want" means not exclusively using
Juniper boxes. If I am understanding you correctly, then this sounds okay
to me. Remember, you are free to deploy whatever you want in your network.
Bear in mind that you are in the minority of operators. We all know what
the reality of the situation is not a homogeneous network of LSRs. For
this reason, the majority of operators (and all of the ones which I personally
spoke with today) want to use a single, standard (i.e.: non-proprietary)
MIB to manage all of the *different* LSRs that they have deployed in their
networks.

         --Tom

---

From: Vijay Gill <[email-masked]>
Date: Sat, 19 Aug 2000 00:21:54 -0400

> Bear in mind that you are in the minority of operators. We all know what

I think randy has spoken for the rest of the messages with the union vs
intersection post.  As for deploying what we want, we are going to do
precisely that and we'll check back next year, same bat list.

/vijay

---

From: Dave Cooper <[email-masked]>
Date: Fri, 18 Aug 2000 21:16:53 +0000

Our network is another heavy implementor of MPLS w/ both vendors
in the mix and i'll second Ron's comments on what basic functionality
we need NOW rather than waiting for some all-encomapssing all-vendor
satisfying MIB (if that exists). Basic operational checks into 

LSP transitions via counter
LSP last transition
LSP path changes
LSP explicit route 
LSP record route

All of which have to currently be retrieved using less than 
spectacular methods.  A script ssh'ing to the routers
every N minute doesnt cut it.
 
While both implementations tend to do the same 
thing using different methods, i still think a majority of the 
objects in kireeti's mib can be extended across all implementations.

Bottom line... now is better than later as far as an operator's 
concerned.

-dave