The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	Resending...

	Would the authors comment on the following additions to the ldp
mib?  Should these comments be incorporated in a separate document?

			Thank you,

				Ina Minei

---------- Forwarded message ----------
Date: Fri, 7 Feb 2003 15:00:34 -0800 (PST)
From: Ina Minei <ina@juniper.net>
To: mpls@UU.NET
Subject: Comments on draft-ietf-mpls-ldp-mib-09.txt


    Hello,

    Please find below a few comments on draft-ietf-mpls-ldp-mib-09.txt.

    Let me start by saying that moving to 4 mib modules (from version
8 to version 9 of the draft) was an excellent step, making the
document much easier to read and use.

    Please find below a few additions to the MPLS-LDP-MIB module.

1) Authentication information
-----------------------------
TCP MD5 signature is mentioned in the LDP RFC, but not in the
mib. It is useful to know whether a session is authenticated or not.

   mplsLdpSesAuthenticationType OBJECT-TYPE
         SYNTAX      INTEGER {
                       none(0),
                       md5(1)
                     }
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "The authentication type for this session."
         ::= { mplsLdpSessionEntry 6 }


2) Reason for the session going down
------------------------------------
>From an operator's point of view, it is useful to know the cause for a
session going down. Similar functionality can be found in the bgp mib.
This information could be passed in the session down trap as well,
providing a powerful debugging tool for network operators.

mplsLdpSesDownReason OBJECT-TYPE
    SYNTAX        INTEGER {
                    holdExpired (1),
		    connectionExpired (2),
		    allAdjacenciesDown (3),
		    badTLV (4),
		    badPDU (5),
		    badPacket (6),
		    connectionError (7),
		    peerSentNotification (8),
		    unexpectedEOF (9),
		    authenticationChanged (10),
		    initError (11),
		    gracefulRestartAbort (12),
		    unknown (13) }
    MAX-ACCESS    accessible-for-notify
    STATUS        current
    DESCRIPTION
	"The reason why the session transitioned to nonexistent state.
	Can be one of the following:
	hold time expired, connection time expired, all adjacencies down,
	received bad tlv, received bad packet, connection error,
	received notification from peer, received unexpected end-of-file,
	authentication key was changed, error during initialization,
	graceful restart was aborted, or unknown reason."
    ::= {mplsLdpSessionEntry 7}

3) Additional information for hello adjacencies
-----------------------------------------------
a) The mib currently provides no interface information. It is important
to know which interface the hello adjacency is on.

mplsLdpHelloAdjIntf OBJECT-TYPE
    SYNTAX       InterfaceIndex
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION
        "For a hello adjacency of type link(1), the ifIndex of the
	interface, for a hello adjacency of type targeted(2), the
	ifIndex of the loopback interface."
    ::= { mplsLdpHelloAdjacencyEntry 4 }

b) It is useful to have the address information as well, though this
can be obtained from the interface index.

c) It is useful to have a timestamp of when this adjacency came
up.

4) Interface information for the LDP entity
-------------------------------------------
LDP is a discovery protocol. In many systems, the configuration of the
protocol is done by specifying the interfaces on which the discovery
should be attempted. It is not guaranteed that adjacencies will be
formed on these interfaces.
A table specifying for each LDP entity which interfaces it is running
on, and how many adjacencies were established on each of these
interfaces, would provide valuable insight for the network operator.

5) Graceful restart information
-------------------------------
draft-ietf-mpls-ldp-restart-06.txt is now moving to Proposed
Standard. It might be useful to include the graceful restart information
at this time, in order to avoid having to add it later.
     The graceful restart info is:
- graceful restart enabled/disabled
- helper mode enabled/disabled
- recovery time
- max recovery time
- reconnect time
     Some of this belongs to the entity, and some to the peer. If
there is agreement on adding this information, I can write it up.

6) Additional identifier of the LDP Entity
------------------------------------------
Currently the MplsLdpIdentifier is the only identifier for an LDP
Entity. This is based on the assumption that the LdpIdentifier will
be unique. However, when implementing several instances with
overlapping address space, this may not be true (I am thinking of the
vpn case). It would be good to have an additional identifier (perhaps
an integer) that can be used to differentiate between these otherwise
equal entities. (otherwise things like traps will be of limited use).
The linkage between this additional identifier and the instances can
be done separately, but I think having the hook in now will be good
for the future.

7) Summary information for LDP Entity
-------------------------------------
To be able to sanity check the state of the protocol on a particular
box, it is useful to have a snapshot of the state of the sessions for
each ldp entity. Something along the lines: # of operational sessions,
total number of sessions in all states, number of interfaces, number
of neighbors. The idea is for this table to be polled at regular
intervals, to make sure nothing is going wrong. (traps won't always be
the key, since they can be disabled, or may not make it)

Traps
=====
Change in the session down trap
-------------------------------
>From an operator's point of view, it is useful to know the cause for a
session going down. This can be passed in the trap, and would provide more
information than the number of unknown messages or unknown TLVs
received.

mplsLdpSessionDown NOTIFICATION-TYPE
     OBJECTS     {
                    mplsLdpSesState,
		    mplsLdpSesDownReason

                 }
     STATUS      current
     DESCRIPTION
        "If this notification is enabled to generated,
        then this notification is sent when the
        the value of 'mplsLdpSesState' leaves
        the 'operational(5)' state."
     ::= { mplsLdpNotificationPrefix 4 }

Change in the session up trap
-----------------------------
It was not clear to me the reason whty we send the number of unknown
messages/tlv in the session up trap. Would you explain the usage?

Add an adjacency-down trap
-------------------------
Losing adjacencies may lead to losing a session. (though when a
session is established over several adjacencies, this is not the
case). In any case, a user can decide if it is beneficial for his
network to track adjacencies going down anyway. It can be used to alert
the operator that something went wrong in the redundant path, and his ldp
session is at risk.


		 Thank you,

			Ina Minei