The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Comments on draft-ietf-mpls-ldp-mib-09.txt
At 04:27 PM 2/13/03 -0800, Ina Minei wrote: > > 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. Sure. > >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. > 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. >> >> >> > >> >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. 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. > I agree with you that the address information is not as useful, >but the interface information is essential. > 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. >> >> >> > >> >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. 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 >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. > The DESCRIPTION of mplsLdpEntityIndex states: "...Another way to use this index is to give this the value of ifIndex. However, this is dependant on the implementation." > > > >> > >> >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. 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. > >> >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? > Yes, either situation is possible. But it seems overkill to send a trap everytime an adjacency is lost. -Joan > >> >> >> >> > >> > Thank you, >> > >> > Ina Minei >> > >> > >> >
|
|