The MPLS WG Archive

[jcucchiara@mindspring.com]

At 03:00 PM 2/7/03 -0800, Ina Minei wrote:
>
>    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.

Thanks for the feedback.  Most of the comments that I have
received on this re-organization are favorable also.
This was suggested by Bert W. during the IESG MIB review.


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


There is some discussion of this in the archives.  As you point
out this is a TCP mechanism which other protocols such as BGP or LDP
may use.  As I recall the consensus about this discussion was that
it would be better to add something to the TCP MIB and not put this
in other MIBs such as LDP or BGP.  As you may have noticed such an object does
not appear in the lastest drafts of the BGP4 MIB either. 


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


The above does not really clarify why a session was torn down.
An NMS by looking at each entity and peer in the Session in a network
should be able to discern why the session was torn down.  But I think
this is a network issue, not just an individual node issue.

As a point of clarity, are you an operator or are you giving feedback
based on conversations with an operator?  


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

Not sure I understand this.  If LSRa receives a hello message from
LSRb, why can't the NMS be smart enough to look at LSRb Entity table
to see the UDP Ports that the hello was sent out on?


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

It would be very close to mplsLdpSesStateLastChange, wouldn't it?
Not sure that this is really needed.

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

LDP Entities do not run on interfaces.  Entities are simply the
way to configure a potential session.  Please see section 3.5.1 and
3.5.1.1 of the MIB for further information.

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


It is beyond the scope of this document to add new functionality.
Please note, this MIB has gone through several last calls, and has just gone
through IESG review for a second time.  Also, there was an open meeting in
Nov at the
IETF.   In other words, it is too late in the process of this MIB to be
adding new functionality. 

Certainly, you may create a MIB for this functionality and
propose it to the working group.

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


There are 2 indices for this table, so am unclear as to if you are
asking for a 2nd or 3rd index?

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

As the AUGMENTS relations in the Session table indicates, there is
one session for each entity-peer relationship.

If you are saying that you want to understand how many LSPs per session
then you need to look at the mplsLdpLspTable.


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

These 2 counters are maintained throughout the life of a session and
so are forwarded with the traps to give extra information.

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

Not sure I agree with this.  There may be only one adjacency and that
is not indicative that a session is about to be closed.

-Joan



>
>		 Thank you,
>
>			Ina Minei
>
>