Subject: draft-nadeau-mpls-packet-classifier-mib-00.txt comments

From: Joan Cucchiara <[email-masked]>
Date: Mon, 13 Mar 2000 11:35:56 -0500

Tom, Arun and Cheenu,

I have some questions and comments and concerns on:
draft-nadeau-mpls-packet-classier-mib-00.txt

General comments
-----------------
* MIB doesn't compile with any of my mib compilers, can
you tell me which one you are using?
* In general, I find the MIB approach to be top-down
which leads to a gap in the logic between the MIB and what
is actually needed to set on the hardware-side in order to
provide for mpls packet classification.  You have barely scratched
the surface for ALL MPLS protocols.  (it is not clear
from the document that the intent is to provide a way
to support ALL MPLS protocols, but since this references
the LSR MIB, then I assumed this was the case: is that
a correct assumption?)  

It's as if the design was from picturing a GUI screen which has
something called interface and attaching
a bunch of classifier rules to try on the interface.
But this doesn't quite cut it as a MIB which can be
used to actually do this on hardware, at least not
as it is written now.  

For example, when an ifIndex goes away then all the
configuration that is done is GONE.  This is NOT 
a good design.  It is a configuration nightmare.

Do you really expect that a System Admin person would be 
keeping track of all of this?  That is paramount to having 
a sys admin keep track of every route through an ISP.  
And then CONFIGURE for it by knowing the ifIndex at any
point in time.  Which is not possible when setting up 
redundant LSPs.  It is not realistic that a Sys Admin 
would do this, do you agree?

The way you are treating LSPs is as if they are ALL PVC-like, which
may be true in some, but certainly not ALL instances, it is not a 
flexible design, and it is  not scalable design.  It
is a configuration nightmare.

Furthermore, the use of a DISPLAY strings as indices is not viable
for timely execution on the agent-side.  Modeling a
linked list which contains (Integer, DisplayString,
DisplayString) where the only other thing in the table
is RowStatus is also quite a poor design for the agent-side.

What about redirection to a different LSP?  The MIB
doesn't work unless redirection is to an LSP which
has been set up apriori, but what is this based on?
Where is the logic to determine when to redirect and
where to redirect to?  Is the System Admin supposed to
know magically when to do this and where?  Isn't this better
handled by allowing software algorithms to do redirect
versus a sys admin?  Currently, the MIB only allows this
to be configured.  Again, this is neither flexible, nor scalable.

What about mapping back to Labels? (for easy clean up on in a teardown 
scenario)

What about load balancing?  Seems like this is NOT supported in 
the MIB.

My greatest concern is that this MIB is completely useless unless
ifIndex a "static, persistent index".  By definition, ifIndex doesn't
have to be persistent, especially not through reboots OR DISCONTINUTY
types of situations.
  
How on earth can your MIB be done by an implementation
that does NOT make ifIndex persistent?  Is your intention to
re-write how IfIndex is used? 

This MIB is not viable because what you are calling
interfaceIndex is not a true ifIndex, OR maybe the expectation is that
someone  
will be continually configuring this MIB. Not a job I would want.

Since the basis of the MIB is mapping packet classifier rule sets to
ifIndex, is this MIB going to allow for INTEROPERABILITY?  Right now
it does not!  In fact, I would like to see a new rev with a complete
explanation of HOW this MIB will be INTEROPERABLE before seeing
it as adopted as a working group document.  It appears to me at least,
that very little thought was actually given to interoperability.

If the basis of the packet classifier identifier is a DisplayString, then is
this going to be interoperable?  Thus, the way you are identifying packet
classifiers has absolutely no meaning, even from devices by the same vendor.
For example, I could have the SAME exact classifier appear several times 
under different names, what good is this?

Section 4. Motivation

* I was expecting a simply stated goal for
this MIB, which I couldn't find.  Is this MIB
intended to be used for all MPLS protocols?

If so, could you state it plainly?

* The statement: "Conceptually, some of the
FTN table functionality could be implemented usig
the Forwarding Information Base(FIB) to map all packets
destined to a prefix to an LSP.  However, this mapping is 
course in nature."

What is meant by "course in nature", certainly for LDP
this is fine.   Again, if the intent of the MIB was
more clearly stated that would be helpful.

* The last sentence:  "...as well as new ones (i.e. classifier
rules?) such as those required by MPLS and Diff-Serv."  may
lead the audience to believe that this somehow works with 
diff-serv, I didn't see anything in this MIB which was diff-serv
specific, if so could you point this out?

Also, Diff-serv MIBs are being developed in about 3 different
groups, is it your intention to work with any of these
other efforts?  If so, could you elaborate on what the plans
are?

I would like to see all of the above issues explained, 
particularly, the issue of InterfaceIndex and interoperability.
BEFORE it is adopted as a working group document.

The entire point of having a standard MIB is for interoperability, and
I do not see how this MIB will provide any sort of interoperability
due to the assumptions regarding InterfaceIndex which have been made
but are NOT at all discussed anywhere in the MIB.

Thank you, 
 Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 13 Mar 2000 13:50:31 -0500

Hi Joan,

         Thanks for your very thorough comments. We
will go over them and get back to you and the MPLS
group shortly. Let me first say that many of your
comments, although warranted, are the result of an
initial design, but you probably know that
already. ;) It was our intent to get something reasonable
out for WG members to look at and comment on. We
will be working hard in the future to adjust the MIB
to meet the needs of the MPLS WG.

         --Tom

---

From: Joan Cucchiara <[email-masked]>
Date: Tue, 14 Mar 2000 10:21:27 -0500

Tom,
 
The MIB design is quite seriously flawed to the point
that it is not interoperable.
 
As I said, the use of InterfaceIndex is inappropriate,
and needs to be replaced by something along the
lines of a "physical entity", or some other more 
concrete model.   Another alternative would be to
tie these PVC-like LSPs directly to classifiers
similar to the way that Traffic Descriptors are
tied to VPL/VCLs in the AToM MIB.
 
Those ideas are just of the top of my head, and are
not offered as suggestions, but merely to point out
that this MIB needs to be redesigned.  
 
The issue isn't that this is an initial design and has some small 
issues because it was rushed to get in under a deadline; 
the issue is that the MIB design is seriously flawed and
I would like to see a redesign prior to accepting
this document as a working group document.   I'm not 
asking for perfection, but it is clear to me that the design
is flawed to begin with and more text and more objects 
aren't going to correct this.  It needs a redesign, and that
is what I'm asking for.  
 
-Thanks, Joan

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Monday, March 13, 2000 1:51 PM
To: Joan Cucchiara; [email-masked]'; [email-masked]'
Cc: [email-masked]
Subject: Re: draft-nadeau-mpls-packet-classifier-mib-00.txt comments

        Hi Joan,

        --Tom

Tom, Arun and Cheenu,

General comments
-----------------

  

Section 4. Motivation

Thank you, 
 Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 13 Mar 2000 13:50:31 -0500

Hi Joan,

         --Tom