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: jcucchiara@mindspring.com
[<mailto:jcucchiara@mindspring.com>mailto:jcucchiara@mindspring.com]
Sent: Tuesday, November 11, 2003 10:39 AM
To: Lai, Wai S (Waisum), ALABS
Cc: mpls@uu.net
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: jcucchiara@mindspring.com
[<mailto: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>http://www.ietf.org/internet-drafts/draft-lai-mpls-ldp-hist-mib-00.txt
>
<<<<