Subject: Re: Consensus for draft-kompella-mpls-te-mib-00.txt

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 06 Sep 2000 19:27:47 -0400

Hi Jim,

>As the WG chair in question, I would like to point out two things:
>
>a) my message to tom was not from "lack of consensus", it was an attempt 
>to redirect his efforts away from "proprietary" and stylistic complaints 
>to an exploration of how a combination of the two mibs might be done, and 
>what would be the impact for implementors and operators (the last part has 
>not been addressed).  It was not framed as the solution, in fact I made it 
>clear that it should not be thought of that way.

         But why are we shutting off that work? Why did you assign it in the
first place? I have not heard from anyone on the list pro/con, but I personally
vote to include it into the MPLS-TE-MIB because I think it is important. 
 From several
private conversations I have heard that folks liked the compromised
solution (i.e.: of incorporating these non-overlapping things into the 
MPLS-TE-MIB).
I hope they respond in public to this thread. When I told these folks that 
Kireeti,
Arun, Cheenu and I were working on a proposal to fold-in the important 
parts from
his MIB into the MPLS-TE-MIB, they were extatic.

         Let me now outline the advantage of that solution versus adopting 
another
MIB:

         a) This has all the objects that *all* the operators wanted. That
                 is, those who wanted the objects from Kireeti's MIB and
                 those who wanted the objects from the MPLS-TE-MIB. I think
                 that this is a very important point (perhaps the most 
important
                 one that I will make now) since I think that this was the 
goal
                 we were all working very hard to achieve. Adoption of 
Kireeti's
                 MIB will only diverge the work and create confusion in the
                 marketplace.

         b) This obviates the need for having Kireeti's MIB because those
                 objects are now in the MPLS-TE-MIB, which from a recent
                 thread on the MPLS mailing list, vendors are implementing
                 and operators are using! I am sure that although vendors 
will not
                 be terribly happy having to implement the few more objects 
than
                 were proposed to be folded into the MPLS-TE-MIB, they will 
be happy
                 to since a good set of vendors have expressed definite 
interest in
                 them. This solution DOES NOT impact operators since they 
are free to
                 choose from the set of objects required for 
implementation. The
                 burden is on the vendors to implement a few more objects 
which they
                 might have anyway.

         c) Adopting the other MIB now will be a duplication of effort with the
                 MPLS WG. There is nothing which is in Kireeti's MIB that 
is not
                 in the MPLS-TE-MIB (or can be added in the future if the WGs
                 see fit to do so). In the future I see a problem with the 
coordination
                 of both MIBs, since I cannot foresee anything that belongs in
                 Kireeti's MIB not going into the MPLS-TE-MIB.

>b) in terms of consensus, there were two compelling arguments
>   - merge, as we can't have two mibs
>   - adopt kireeti's as it has all the right information w/ minimal added 
> complexity

         Lets not forget the argument of dropping the MIB after
we incorporated its salient features into the MPLS-TE-MIB.

>The issue of complexity is an obvious one, as there have been discussions 
>around "minimal implementations" or "conformance relaxation" or 
>"non-conformant implementations".  Some have also pointed out that having 
>two documents really is not that bad of a thing as they will both tie into 
>the mib structure independently.

         This is a misnomer. The MIB structure as a whole does contain
many objects, regardless of which actual document they reside in.
However, the fact of the matter is that it makes no sense to duplicate
a large set of objects under any of the sub-trees. This is what we
will effectively have if we adopt Kireeti's MIB after we fold-in
the objects from his MIB.

>I believe the best thing to do is to accept kireeti's draft as a te-wg 
>item, as it has both running code and rough (very) consensus behind 
>it.  The mpls wg mib currently does not have the right focus for the te-wg 
>and all folding kireeti's draft into it does (from the standpoint of 
>someone who only needs access to the information in kireeti's) is add 
>complexity.

         You are unnecessarily complicating the issue here. Folding in of 
the objects
does not complicate things unnecessarily for the operator. What it does is get
everyone what they need, regardless of which subset of vendors they were from.
The reasons why are:

         a) From what I understand, operators are after a subset of objects
                 from the MPLS-TE-MIB (including Kireeti's changes). Some
                 of the operators who were originally in favor of Kireeti's
                 MIB have told me that they were only after 2 or 3 objects
                 from his MIB. They did not care if there are other objects in
                 there or in the MPLS-TE-MIB. So, if the intersection of 
objects
                 is included (and made mandatory which is what was proposed)
                 we make everyone happy.  I hope that these operators will now
                 speak and make their thoughts known.

         b) The MPLS-TE-MIB is not much more complicated than Kireeti's MIB
                 despite some recent advertisements. Yes, it is a bit more 
complicated
                 at the expense of providing for a far more robust set of
                 functionality (i.e.: tunnels as interfaces, make-before-break,
                 etc...), but NOT at the expense of providing for any
                 of the things which are in Kireeti's MIB. To prove my point,
                 the MPLS-TE-MIB has 4 tables:

                 tunnelTable
                 perfTable
                 HopTable
                 ARHopTable
                 CRHopTable -- added from Kireeti's MIB
                 resourceTable
                 Notifications

         Kireeti's MIB has one table: tunnel table.

                 All that we have done is break things out and allow things to
         be a bit more flexible, as well as make provision for additional 
functionallity
         which is desired by many. The tunnel table contains a subset of 
what is
         available in Kireeti's tunnel table (while making the indexing much
         better). The various hop tables including the last one, are there to
         allow for a more orderly representation of the hops for those who
         care to look at them. For those who just want the source/dest of the
         tunnel, we have provided these right in the tunnelTable as they 
are used
         to from Kireeti's MIB. We have also proposed consolidating
         a few things with the recent changes from Kireeti's MIB so that 
we
         could provide easy access for those operators who were currently using
         his MIB.

         So, for all of the reasons outlined above, I do not think that it
is necessary or desirable or wise to adopt Kireeti's MIB and move it 
forward due
to its duplication of efforts with the MPLS-TE-MIB, and its lack of 
features which
are desired by some operators. The addition of these, plus the modifications
necessary to Kireeti's MIB to make it IESG-worthy will make it look strikingly
similar to the MPLS-TE-MIB, further duplicating precious time and effort.

         --Tom

---

From: Jim Boyle <[email-masked]>
Date: Wed, 06 Sep 2000 16:23:30 -0600

At 04:06 PM 8/30/00 -0400, Cheenu Srinivasan wrote:

>MPLS/TE WG members,
>
>         This message is in response to the recent introduction
>of the draft entitled, "draft-kompella-mpls-te-mib-00.txt" to
>the TE WG and the debate which followed. Since no consensus could
>be reached in the TE WG as to whether or not to adopt this draft,
>the TE WG chair felt that this work was still important, and as such
>has directed the author of this draft and the authors of the
>MPLS-TE-MIB to work out a consensus for folding-in the salient
>portions of the draft into the MPLS-TE-MIB. We have done so, and
>below you will find the fruits of our labor. We will wait for the
>feedback of the working groups before posting a revised version of
>MPLS-TE-MIB incorporating these changes.

a) my message to tom was not from "lack of consensus", it was an attempt to 
redirect his efforts away from "proprietary" and stylistic complaints to an 
exploration of how a combination of the two mibs might be done, and what 
would be the impact for implementors and operators (the last part has not 
been addressed).  It was not framed as the solution, in fact I made it 
clear that it should not be thought of that way.

I believe the best thing to do is to accept kireeti's draft as a te-wg 
item, as it has both running code and rough (very) consensus behind 
it.  The mpls wg mib currently does not have the right focus for the te-wg 
and all folding kireeti's draft into it does (from the standpoint of 
someone who only needs access to the information in kireeti's) is add 
complexity. It is important that the operational community has a way to 
monitor TE networks, and right now, draft-kompella-mpls-te-mib-00.txt is 
the best starting place for that.

regards,

Jim

>         Tom Nadeau
>         Kireeti Kompella
>         Cheenu Srinivasan
>         Arun Vishwanathan
>
>--------------------------------------------------------------------------------------- 
>
>
>         1. Two scalars to indicate the number of configured and
>            active tunnels: mplsConfiguredTunnels and mplsActiveTunnels. An
>            "active" tunnel denotes an mplsTunnelEntry with
>            mplsTunnelOperStatus = Up. A "configured" tunnel denotes an
>            mplsTunnelEntry whose mplsTunnelRowStatus is "active".
>
>         2. The addition of a new performance table which AUGMENTS
>            the mpslTunnelTable which includes the following
>            attributes:
>
>         mplsTunnelPerfPackets OBJECT-TYPE
>         SYNTAX     Counter32
>
>         mplsTunnelHCPerfPackets OBJECT-TYPE
>         SYNTAX     Counter64
>
>         mplsTunnelErrors OBJECT-TYPE
>         SYNTAX  Counter32
>
>         mplsTunnelPerfBytes OBJECT-TYPE
>         SYNTAX     Counter32
>
>         mplsTunnelHCPerfBytes OBJECT-TYPE
>         SYNTAX     Counter64
>
>         3. The following objects will be added to the tunnelTable
>            to allow for further monitoring of the state
>            of the tunnel once it is configured.
>
>                 mplsTunnelPrimaryTimeUp    TimeStamp,
>                 mplsTunnelPathChanges      Counter32,
>                 mplsTunnelLastPathChange   TimeStamp,
>                 mplsTunnelCreationTime     TimeStamp,
>                 mplsTunnelStateTransitions Unsigned32,
>                 mplsTunnelEgressLSRId      Unsigned32,
>
>         A path change is when the current active path (over which
>         packets are being forwarded) changes to another path.
>
>         4. The addition of a new table called mplsTunnelCHopTable
>            which lists the computed HOPs for a tunnel path.
>
>         5. We will enhance the mplsTunnelHopStrictOrLoose object
>            to change its name to mplsTunnelHopType. This object
>            will become an enumeration of { strict, loose }.
>
>         6.  A new bit will be added to the mplsTunnelSessionAttribute
>             called ComputePath. This bit instructs the LSR to
>             use Constraint-based Routing to compute the actual path to
>             be traversed by this tunnel instance.
>
>         7. Resource class affinity attributes associated with a traffic
>            tunnel can be used to specify the class of resources which are
>            to be explicitly included or excluded from the path of the 
> traffic
>            trunk. These are policy attributes which can be used to impose
>            additional constraints on the path traversed by a given traffic
>            trunk.
>
>         Three new objects shall be added to the tunnelEntry:
>
>         mplsTunnelIncludeAnyAffinity OBJECT-TYPE
>         SYNTAX          Integer32
>         MAX-ACCESS      not-accessible
>         STATUS          current
>         DESCRIPTION
>           "A link satisfies the include-any constraint iff  the 
> constraint is zero,
>            or the link and the constraint have a resource class in common."
>         REFERENCE "See section section 5.6.3 of RFC 2702."
>
>         mplsTunnelIncludeAllAffinity OBJECT-TYPE
>         SYNTAX          Integer32
>         MAX-ACCESS    not-accessible
>         STATUS        current
>         DESCRIPTION
>           "A link satisfies the include-all constraint if and only if the 
> link
>            contains all of the administrative groups specified in the 
> constraint."
>         REFERENCE "RFC 2702, section 5.6.3."
>
>         mplsTunnelExcludeAllAffinity OBJECT-TYPE
>         SYNTAX          Integer32
>         MAX-ACCESS    not-accessible
>         STATUS          current
>         DESCRIPTION
>           "A link satisfies the exclude constraint if and only if the
>           link contains none of the administrative groups specified in
>           the constraint."
>         REFERENCE "RFC 2702, section 5.6.3."
>
>         8. A scalar which will denote which type(s) of TE distribution 
> protocol(s)
>            is(are) in use by the LSR.
>
>         mplsTunnelTEDistProto OBJECT-TYPE
>         SYNTAX      BITS { other (0), ospf(1), isis (2) }
>         MAX-ACCESS    not-accessible
>         STATUS        current
>         DESCRIPTION
>           "The traffic engineering distribution protocol(s) used by this 
> LSR. Note that
>            an LSR may support more than one distribution protocol 
> simultaneously."
>
>--------------------------------------------------------------------------------------- 
>