The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	Thank you for the quick feedback. Please find responses inline
below, marked ###.

			Ina

On Thu, 13 Feb 2003 jcucchiara@mindspring.com wrote:

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

### I am not an operator. The feedback I was giving was based on
conversations with an operator.

There are two reasons why having the above is useful:
- 1) It provides information about the reason the session went down.
E.g. "all adjacencies down" is a very clear indication that all the
neighbors went down. So is "hold time expired". Having such information
readily available can cut the "detective work" involved in troubleshooting
a session failure.
- 2) This information can be included in traps. Currently there is no
clue in the trap why the session went down.
When an error condition occurs in a network, (e.g. a link fails), there
will be many traps generated for this event - the ifmib, the ldp mib, the
igp mib will all report the failure. Usually, the operator wants to
identify that these failures are all related, and an error code can help
him do that.

I think the main benefit is to include this information in the session
down trap.

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

### Because this information can be made readily available on LSRa at
extremely little cost. What do we do in the scenario above if LSRb is
not snmp enabled? I always think about how i would feel if the cli
was providing the same functionality and I would have to go to the
neighboring router in order to find out on which interface the adjacency
is formed - not very usable.
	I agree with you that the address information is not as useful,
but the interface information is essential.

>
>
> >
> >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 really. A session may go down because of a bad packet for
example,  or a change in authentication. These are events that
wouldn't cause the adjacency to go down. Also, there may be several
adjacencies that belong to the same session (e.g. for parallel interfaces
which is a common  scenario). An adjacency may go down, but the session
will stay up. So the timers can be very different. One of the ways to
troubleshoot a session-down from the cli is to compare the time an
adjacency is up and the session is 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.
>
> 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.
>

### My previous comment was referring to the cli, thus the
miscommunication. My point is that an LDP entity
will be associated with one or more sessions (the case where no
sessions are established is not interesting) Each session is
established thanks to one or more adjacencies, and each of these
adjacencies is running on an interface. Knowing which are the interfaces
that an entity is associated with is very important. From the cli, for
many  vendors, the way to configure the protocol is to specify on which
interfaces the adjacency discovery should take place.  I hope this makes
my previous comment clearer.

	I believe the different optic comes from the fact that the mib was
written with ATM/FR in mind, where indeed the interface information is not
as interesting.




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

### Sorry, I missed this. I wanted a 2nd index, and didn't notice there
were two already. Please ignore my comment

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

### Agreed, but I don't want to have to walk the entire Peer Table to
extract this information. Since this info is likely to be polled often, it
would be nice if it was readily available.

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

### In the session up trap, the number of unknown messages received will
not really give the operator any useful info. I would not send this extra
info, though it can't do any harm either.

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

### I'm afraid I don't understand the comment. Are you saying there are
more than one or just one adjacency?


>
>
>
> >
> >		 Thank you,
> >
> >			Ina Minei
> >
> >
>