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

From: Cheenu Srinivasan <[email-masked]>
Date: Wed, 30 Aug 2000 16:06:19 -0400

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.

        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: "Sudhanshu Jain" <[email-masked]>
Date: Fri, 29 Sep 2000 20:44:59 -0700

Consensus for draft-kompella-mpls-te-mib-00.txtHi All,

Please see my inline comments below.

  ----- Original Message ----- 
  From: Cheenu Srinivasan 
  To: [email-masked]' ; [email-masked]' 
  Sent: Wednesday, August 30, 2000 1:06 PM
  Subject: Consensus for draft-kompella-mpls-te-mib-00.txt

  MPLS/TE WG members, 

          Tom Nadeau 
          Kireeti Kompella 
          Cheenu Srinivasan 
          Arun Vishwanathan 

  --------------------------------------------------------------------------------------- 

An unrelataed comment. If you look, there are potenially three oper status ( in rfc2233(ifOperStatus), mplsTunnelOperStatus and mplsXcOperStatus), which may be representing the same information.

I think,  mplsTunnelOperStatus is not really required as there is a direct index to the mplsXcTable and it has the mplsXcOperStatus.

Any comments??

                                     

                                     

I think these type of parameters are specific for the Packet Switch Capable(PSC) Interfaces and should be addressed accordingly.

How does the egress lsr id is learned in RSVP-TE? Also what is the usage of this information?

I think scope of mplsTunnelStateTransitions , should be increased to address notPresent, lowerLayerDown etc.

I think path change(mplsTunnelLastPathChange &  mplsTunnelPathChanges) is protection specific information, and should be addresses in seprate mplsTunnelTable's augumented table along with information like 

- current protection available

Also mplsTunnelTable's should have configurable information like "kind of protection" required for this Tunnel along with pre existing information "localProtectionAvailable".

-Sudhanshu