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

From: Arun Viswanathan <[email-masked]>
Date: Sat, 19 Aug 2000 15:03:41 -0700

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

I think we should not accept the MIB as a TE WG item.
With all that's been said in favor of Kireeti's MIB by a few,
I am not convinced that a separate operationally focused MIB
is required apart from the MPLS-TE-MIB. Obviously, Kireeti's
MIB hasn't found multi-vendor support from folks who
provide MPLS TE products. Moreover, I haven't seen much
support from the operators for a 'separate MIB' besides a few.

But, one thing is clear. Kireeti's MIB has some operational
friendly objects (if the MIB in its entirety is operationally
friendly is a subjective matter). But these objects are only
a few, and can easily be incorporated into the MPLS-TE-MIB.
Ron provided a concise list of these objects.

The MPLS-TE-MIB is fairly matured at this time. In fact, we
are planning on requesting a last call with some minor edits.
I think extending the MPLS-TE-MIB for this would be the
quickest path to getting a standards track MIB that finds
rough consensus of the WG(s). I think it would be
a waste of effort to make the TE WG undergo the process of
finding such a consensus all over again, especially without
earnestly exploring why the MIBs cannot or should not be merged.

-arun

---

From: Arun Viswanathan <[email-masked]>
Date: Sat, 19 Aug 2000 18:38:20 -0700

Kireeti,

> 
> Action item: replace all occurences of "mplsLsp..." in the "Kireeti"
> TE MIB with "trafficTrunk...".
> 
> 

Good try :-)

Your MIB is also a tunnel MIB. There is no difference between a tunnel
defined in MPLS-TE-MIB or your MIB wrt a traffic-trunk defined in PASTE
or rfc2702. A tunnel is a entity routable based on some constrains. 
However there is difference, in addition to a tunnel, a traffic-trunk
also represents the associated FECs (or a set of traffic flows belonging
to a class). In other words, a traffic-trunk is tunnel and FECs considered
together.

Howsoever you may choose to slice or dice it, I think the two MIBs
are largely the same, where your MIB has some operationally interesting
objects not contained in the MPLS-TE-MIB. I think this is the main
reason for this debate.

-arun

---

From: "Cucchiara, Joan" <[email-masked]>
Date: Mon, 21 Aug 2000 10:23:56 -0400

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Monday, August 21, 2000 5:42 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: consensus to make 
> draft-kompella-mpls-te-mib-00.txt a TEWG
> it em?
> 
> 
> My $0.02 on this...
> 
> I believe that this should NOT move forward as a tewg item at 
> this time.
> 
> I suggest that it could be the role of the tewg to
> - produce a TE MIB that is independent of MPLS
> - produce a set of requirements on the MPLS TE MIB and
>   request (insist?) that the mplswg incorporate them
> 
> I suggest that it is the role of the mplswg to
> - produce a fully functional MIB (set of MIBs) that
>   can be used to configure, manage and observe an MPLS
>   TE network
> - take input from implementers, operators and those
>   with particular TE experience 
> 
> Having had considerable experience with the mplswg MIBs
> I feel that there _is_ considerable overlap between the
> MIBs and that much of what Kireeti shows in his MIB can
> be found in the mplswg MIB.  On the other hand, there are
> other functions that are "new" in Kireeti's MIB that would
> be of value in the mplswg MIBs, and my view is that the
> authors of the mplswg MIBs must incorporate them.
> 
> I cannot understand why it would not be a valuable use of
> the conformance statement and conformance units to produce
> a single combined MIB where the function of Kireeti's MIB
> can be achieved by legally supporting just a subset of the
> objects in the mplswg MIBs.

I would like to understand what exactly is being
proposed here.

Are you proposing that by using conformance statements the MPLS-TE
MIB (draft-ietf-mpls-te-mib) produce a minimal set of requirements
which is essentially the objects contained in draft-kompella-te-mib?

If so, I'd like to raise a few concerns.  Assuming this could
be done (and I'm not convinced that it could) but for the
sake of argument, assuming that it is achievable:

1) that's not the purpose of conformance statements, so think
you'd be making MIB history here ;)   

2) These conformance statements would be extremely complex.  Right
now, one encounters conformance statements dealing largely with
physical issues, such as "The xxxATM Group needs to be supported
on devices which support one or more ATM interfaces".  
I can't imagine what you would base these
conformance statements on, such that someone a year from now
would be able to read them and understand what is being asked.

3) if the LSR MIB is effected because of this (and I believe that it
would be since the MPLS-TE MIB has quite a bit of dependence
on the LSR MIB) then what does this mean for the LSR MIB.  Does this
suggestion also extend to the LSR MIB, and thus, the LSR MIB's conformance
statements would need rewriting also?  Since the LSR MIB has
already had a couple of last calls, is it even possible
to go back and make changes to the LSR MIB?

4) the LDP MIB has a dependence on the LSR MIB, so I would like to
understand what is involved in rewriting conformance statements in
this way, and what the effects are on the MPLS-TE MIB and LSR MIB, 
prior to just accepting this solution at face value. 

5) Typically, when there are optional objects, these don't get
implemented.  What is the motivation for implementing them?  (there
is none to speak of because minimal compliance to a standard RFC is
compliance.)  If you end up making much of the MPLS-TE MIB optional
just to obtain a draft-kompella-mpls-te-mib, I think this is a complete
waste of time and energy, so again, I would like to understand how
this is going to be done, and what the consequences are prior to agreeing
to this course of action.

On the surface rewriting comformance statements may seem like a 
good compromise, but I have doubts about the feasibility of this
as a solution.  Could the authors speak to some of the issues above
so that we could get a clear understanding of what this would involve?

  Thanks, Joan

> 
> Would the authors (on both sides) like to comment on whether 
> this is feasible, or indeed whether they have already started
> discussions on this topic?
> 
> Regards,
> Adrian
> --
> Adrian Farrel  mailto:[email-masked]
> Network Convergence Group
> Data Connection Ltd., Chester, UK
> http://www.datcon.co.uk/
> Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422
>