The MPLS WG Archive

[jcucchiara@mindspring.com]

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. 

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.


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?

   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: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
Sent: Sunday, November 09, 2003 12:13 PM
To: Lai, Wai S (Waisum), ALABS
Cc: mpls@UU.NET
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, Internet-Drafts@ietf.org 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
>