Subject: Comments on draft-ietf-mpls-ldp-mib-09.txt

From: Ina Minei <[email-masked]>
Date: Fri, 7 Feb 2003 15:00:34 -0800 (PST)

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

---

From: [email-masked]
Date: Thu, 13 Feb 2003 17:20:29 -0500

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

>1) Authentication information

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

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

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

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

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

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

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.

>Change in the session down trap

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

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

---

From: Ina Minei <[email-masked]>
Date: Thu, 13 Feb 2003 16:27:48 -0800 (PST)

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

			Ina

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

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

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

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

> 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

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

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

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

---

From: [email-masked]
Date: Thu, 13 Feb 2003 21:56:53 -0500

At 04:27 PM 2/13/03 -0800, Ina Minei wrote:

>conversations with an operator.

Sure.

As I said above, this is still a network issue and not an individual

node issue.  In other words, each LSR/LER involved in the session will

generate a trap that says something different.  This is because they

only see why their side of the session was torn down.  It is upto an NMS
to figure

out the root cause.  This is not something that an individual node can
do

accurately.

>is formed - not very usable.

This is exactly why an NMS should be used.

Also, in my humble opinion, it is a little unrealistic to expect that

an SNMP-based MIB should make provisions for nodes which don't have

snmp enabled. 

The point I was trying to make is that if you know that hellos are 
being

sent from a UDP port, then you should be able to know the interface.

>adjacencies is running on an interface.

As I stated before an entity is a "potential session" meaning that

the entity contains all the configuration information needed to

create a SINGLE session. 

> Knowing which are the interfaces

The DESCRIPTION of mplsLdpEntityIndex states: "...<bigger>Another way to
use this 

             index is to give this the

             value of ifIndex.  However, this is dependant

             on the implementation."

</bigger>

>would be nice if it was readily available.

These totals and other objects you are asking for are traditionally

left up to an NMS to aggregate and maintain.

You can certainly add them to a proprietary MIB.

Yes, either situation is possible.  But it seems overkill to send a

trap everytime an adjacency is lost.  

  -Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 14 Feb 2003 13:05:31 -0500

>not appear in the lastest drafts of the BGP4 MIB either.

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

>is not indicative that a session is about to be closed.

"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