The MPLS WG Archive

["Sudhanshu Jain" <sjain@maplenetworks.com>]

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

Hi All,

 

Please see my inline comments below.

 

----- Original Message -----

From: Cheenu Srinivasan

To: 'mpls@UU.NET' ; 'te-wg@UU.NET'

Sent: Wednesday, August 30, 2000 1:06 PM

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

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

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

 

 

        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 

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

                               

 

        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,

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.

 

 

 

        A path change is when the current active path (over which
        packets are being forwarded) changes to another path.

 

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