Subject: RE: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt

From: "Chung, Li-Jin W, ALABS" <[email-masked]>
Date: Mon, 1 Dec 2003 00:22:12 -0600

Joan, 

How are you? 

Please see my inserted notes below. Since your questions are mostly related to operations, I made an attempt to provide my personal review from operations perspective. Please let me know if you have further comments. 

Thanks, 

Li Chung 

-----Original Message----- 

From: [email-masked] [<mailto:[email-masked]>mailto:[email-masked]] 

Sent: Tuesday, November 11, 2003 10:39 AM 

To: Lai, Wai S (Waisum), ALABS 

Cc: [email-masked] 

Subject: Re: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt 

Wai Sum, 

Could you please directly address the following questions/comments: 

1) Why does an operator care about a total for Established Sessions 

and Terminated Sessions on a per Entity basis? 

These counters are AUGMENTS to the 

Entity table and I am unclear as to why an operator would deem these 

counts useful. Please do not tell me that it is helpful for router resource 

management and engineering of LDP sessions. Please tell me "how" they 

address the issue of router resource management and/or engineering of 

LDP sessions. An Entity is a MIB construct. Keeping totals of all sessions, 

which were established or terminated on a per Entity basis 

over some time frame, does not seem very helpful in my opinion, so 

I am trying to understand why you think that these are helpful. 

Li > This data is typically used for traffic management. Given the size of our network, the typical network management process is to look at the aggregate view of the network-wide performance first to get a glance of total counts on attempts, successes and failures. We use the ratio of failure/attempts and the history data to determine if there is an abnormal network event (network-wide or per router-wide) that we need to pay special attention to for trouble shooting or diagnosis. If there is a network-wide network event identified, we then go to the impacted network entity(ies) to begin our trouble shooting. At this point, we might need detailed data to identify root cause of the event. Such detailed data will be only needed on a certain router or certain interface; not network-wide. In addition, the ratio of failure/attempt helps us to prioritize our work as to which network event and which network entity that we should look at first if there are multiple events in the network at the same time. In short, augmentation allows us to have a first order of surveillence to identify the type and the location of the network events. So, the operators can quickly zoom into the right locations/routers/switches for trouble shooting. This will save our Time-to-Diagnosis and Time-to-Repair. 

2) With regard to the counters which are being proposed to AUGMENT 

the session table, exactly how do they help with Fault Management unless 

an NMS is polling them on every single node, on every LSP from start to 

end, and the agent is storing some history of these on every node? 

How does this help with router resources? 

I would think that such a feature would use quite a bit of router resources 

to store this information. 

Please see my note above. The saving of the router resource is from the saving of number of objects needs to be reported. The entity-wide objects obvious will be less than the per interface or per LSP wide objects. 

3) Also with regard to the counters which AUGMENT the session table, 

if/when the LSP goes down, what happens to the information 

stored in this table. Since it AUGMENTS the session table, the session is 

gone, so is this information gone also? 

This is a flaw of the counter design in my opinion. It is in fact the current Cisco implementation problem that links the reliabiliity of the performance counters with the LSP Up/Down status. The counters should be totally independent of the LSP Up/Down status. 

thanks, 

-Joan 

-----Original Message----- 

Joan, 

Thanks for your review of our draft and the comments below. 

As described in Section 2.1 of our draft, our requirements are very 

specific, i.e., for the engineering of LDP Sessions and router resource 

management. To meet this requirement, there is a need to capture the 

signaling usage/performance of the LDP Entities, and the traffic usage/ 

performance of the LDP Sessions. Another specific requirement for 

fault management is the need for persistent LSP information that 

survives LSP failures. The draft currently proposes five additional 

objects, while the issue of measurement interval and recording counters 

to maintain persistent history has been left open for further 

discussion. 

We would like to hear also other SP's view on our draft. Comments 

and suggestions on how the above requirements could/should be met are 

particularly welcome. 

Thanks, Wai Sum 

-----Original Message----- 

From: [email-masked] [<mailto:[email-masked]>mailto:[email-masked]] 

Sent: Sunday, November 09, 2003 12:13 PM 

To: Lai, Wai S (Waisum), ALABS 

Cc: [email-masked] 

Subject: Re: I-D ACTION:draft-lai-mpls-ldp-hist-mib-00.txt 

Hi Wai Sum, 

I have read this draft several times and was confused by it. 

The requirements are very broad areas (i.e. Performance Management 

Requirement, 

Fault Management Requirement), however, the proposed solution of adding 

5 new 

objects so as to lessen the burden on the SNMP manager (NMS), 

did not follow. 

The objects being proposed are also confusing to me. The Attempted 

Session counter is already in the MPLS-LDP-STD-MIB and the 

other 2 are totals don't provide relevant information in my opinion. 

Why does an operator care about an Entity which is a MIB constuct 

and not really important to LDP performance? 

Also, the packet counters are not going to be useful unless you 

are utilizing an NMS to monitor every node, and every LDP-LSP from 

start to end. You say you do not want to "burden" the network with 

additional NMS traffic or increase polling on nodes, 

but that would be the only way to make these counters useful 

as far as I can tell. 

I would like to hear from other operators on this draft. 

thanks, Joan 

At 06:29 PM 10/22/03 -0400, [email-masked] wrote: 

>A New Internet-Draft is available from the on-line Internet-Drafts 

directories. 

> Title : A Supplementary History Module for the MPLS 

LDP-MIB 

> Author(s) : W. Lai 

> Filename : draft-lai-mpls-ldp-hist-mib-00.txt 

> Pages : 8 

> Date : 2003-10-22 

>In this document, requirements for supplementing the MPLS LDP-MIB 

>are presented for the support of specific network management needs 

>for fault and performance management. Based on these requirements, 

>it describes managed objects in a supplementary history module for 

>use with the LDP-MIB. 

>A URL for this Internet-Draft is: 

><http://www.ietf.org/internet-drafts/draft-lai-mpls-ldp-hist-mib-00.txt>http://www.ietf.org/internet-drafts/draft-lai-mpls-ldp-hist-mib-00.txt 

<<<<