The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

At 05:20 PM 2/13/2003 -0500, jcucchiara@mindspring.com wrote:
>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.

         I believe you are correct that this was the outcome at the time.

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

"The difficult, we do immediately.  The impossible takes a little longer." 
-- Air Force Motto

http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X