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

From: Cheenu Srinivasan <[email-masked]>
Date: Thu, 7 Sep 2000 12:19:34 -0400

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

Jim,

As far as I can see we do not have any kind of working group consensus
to make Kireeti's MIB a working group document. There were at least
as many opinions to fold in the functionality from Kireeti's
MIB into the existing TE MIB but for some reason you have chosen to
ignore this. Also, since we posted the email explaining the "consensus
MIB" with these additions we have not heard any dissent over the last week.
In my opinion the whole process of consensus driven decision making is
getting rail-roaded.

Cheenu

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Sep 2000 20:50:48 +0200

the tewg has been asked by the iesg to take up the te mib.  can we please
get to work now?  i believe that some folk actually have technical comments.
thanks.

randy

---

From: George Swallow <[email-masked]>
Date: Fri, 08 Sep 2000 09:57:10 -0400

Randy -

> the tewg has been asked by the iesg to take up the te mib.  

Are you speaking for yourself as an AD or is the entine IESG behind
this?

I thought some of the key goals of the IESG was to limit duplication
of efforts and to promote peace among work groups.  As far as I
concerned you are failing at both.

...George

==================================================================
George Swallow       Cisco Systems                   (978) 244-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Randy Bush <[email-masked]>
Date: Fri, 08 Sep 2000 16:08:06 +0200

> Are you speaking for yourself as an AD or is the entine IESG behind

i spoke, well wrote, precisely.

> concerned you are failing at both.

we're doing the best we can with the goal of good technical solutions.

randy