Subject: LDP-MIB Enhancement for Performance Management

From: "Lai, Wai S (Waisum), ALASO" <[email-masked]>
Date: Fri, 15 Nov 2002 21:55:56 -0500

There is currently no object in the LDP-MIB to provide necessary counters
for both the Generic Label Space Entities and the Per-Interface Label Space
Entities.  To support LDP entity and session statistics reports for MPLS
performance management, we propose the following enhancement to the LDP-MIB.
Specifically, we propose the addition of the following new objects to
provide summary statistics on the health of LDP entities and sessions to
capture the usage/performance of LDP sessions:

 .  Generic Label Space Entity Attempted Counter
. Generic Label Space Entity Established Counter
. Generic Label Space Entity Disabled Counter 
· Per-Interface Label Space Entity Attempted Counter
· Per-Interface Label Space Entity Established Counter
· Per-Interface Label Space Entity Disabled Counter 
· Generic Label Space Session Attempted Counter
· Generic Label Space Session Established Counter 
· Generic Label Space Session Disabled Counter 
· Per-Interface Label Space Session Attempted Counter 
· Per-Interface Label Space Session Established Counter
· Per-Interface Label Space Session Disabled Counter

In addition, these objects should provide an index to map this LDP entity
with associated IfIndex in the IF-MIB.

In the above set of counters,
(1) The Attempted Counter indicates the specific number of attempts made
to establish the LDP entity between two peers where the corresponding
label space entity/session would be created, whether those attempts are
successful or not.

(2) The Established Counter indicates the specific number of successful
attempts made to establish the LDP entity between two peers where the
corresponding label space entity/session is created.

(3) The Disabled Counter indicates the specific number of LDP entities
disabled between two peers where the the corresponding label space
entity/session were used.

Each of the above is a running counter that is only re-initialized when
LDP session is re-initialized.

These counters will provide a high-level barometer of performance of LDP
entity/sessions.  Without such variables, elaborate NMS-based processing
and extensive MIB walks of the LDP-MIB are required, thus consuming valuable
network and NMS resources.
 
Your comments on the above proposal are solicited.
Thanks, Wai Sum

---

From: [email-masked]
Date: Sun, 17 Nov 2002 17:22:54 -0500

Hello Wai Sum,

> capture the usage/performance of LDP sessions:

The objects you suggest below for an entity
don't make sense to me.  The Entity is
a collection of configuration/control/status for 
setting up an LDP session.  There is
no such thing as an attempted Entity, either
a row in the entity table is created or it
isn't which can easily be discerned by the 
RowStatus.  Same comment for the Established
counter.  

Not sure what is meant by "Disabled Counter",
unless you mean that we keep a count of
everytime the mplsLdpEntityOperStatus changes
from enabled to disabled, but this is something
that an NMS should be polling for (if it cares).

Assuming a Session is established which is
based on that entity, there will be a 
notification if the session goes up/down.

> · Per-Interface Label Space Entity Disabled

The LDP-MIB does provide the hooks for 
the counters mentioned below.  
By this I mean that the LDP-MIB
is counting specific errors which could
be polled by an NMS (along with the Discontinuity
objects), and then divided according to which
L2 is associated with the Entity at the NMS.

> · Generic Label Space Session Attempted Counter

see mplsLdpAttemptedSessions and 
mplsLdpEntityDiscontinuityTime objects
along with the mplsLdpEntityGenLREntries.

> · Generic Label Space Session Established

This should be a gauge32-like objects
which can be gleened from the number
of mplsLdpSessionEntries and from
examining the mplsLdpEntityGenLREntries.

> · Generic Label Space Session Disabled Counter 

Don't understand what you are asking for.
If you are asking for a count of the 
glitches in the Session related to Generic Labels
this could be figured out by polling
the mplsLdpSesDiscontinuityTime object
for entities which are associated with a
generic label range.

> · Per-Interface Label Space Session Disabled

Similar comments for the above, except that
instead of the Generic Label range table would
look at the interface label tables associated
with an Entity.

Please note: once a Session is started, the 
label range tables cannot change.  This 
means that once an NMS retrieves the Entity
and LabelRange information, it will 
be fairly static.  The NMS can just
poll the mplsLdpEntityLastChange to see
if there are changes to the Entity
table.

> with associated IfIndex in the IF-MIB.

The Entity is for configuring a session.
A session runs over TCP, so are you
suggesting to add the ifIndex of the
TCP session?  Also, as stated in the
description of the mplsLdpEntityIndex, 
"Another way to use this index is to give
this the value of ifIndex.  However, this
is dependent on the implementation."  For
example, if the ifIndex values are
not persistent through a reboot, you
may decide to not have the mplsLdpEntityIndex
be a value of ifIndex.

> whether those attempts are

An Entity is basically a Peer on "this LSR"
By "this LSR" I mean the LSR that the NMS is
talking to. 

> LDP session is re-initialized.

An Agent does not usually re-initialize counters,
that is why there are usually discontinuity 
time object associated with counters.

> network and NMS resources.

Initially the NMS will need to poll when
it first discovers a device.  It will 
need to understand which Entities are
for which L2 (by looking at the 
Label Range Tables).  After that
the NMS will need to poll for the
mplsLdpEntityLastChange object, the
mplsLdpAttemptedSessions object (along
with the mplsLdpEntityDiscontinuityTime
object) and then the NMS will need to
divided these according to the L2 that
the LDP Session is configured for.

This is not an abnormal amount
of polling for an NMS in my opinion.

As an aside, would suggest that we move
any NMS/Agent specific discussions to the
mibs email list.  

Thanks,
  -Joan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sun, 17 Nov 2002 23:10:40 -0500

I agree with Joan's comments with
a few things to add.

         --Tom

>RowStatus.  Same comment for the Established

         Right. The protocol just doesn't work this
way.

>The Entity is for configuring a session.

         Or showing dynamic sessions
that the device has instigated.

>TCP session?

         Can't this information can be found by
looking at the destination transport address that you
are adding as part of the current set of revisions,
and then looking in the routing table
for the next hop?

>Also, as stated in the

         Another way of protecting against
this is to just make sure that in cases where
the ifIndex is used and ifIndex persistence is implemented
in the device that the NMS understand that a
discontinuity has occurred and that it should re-read
the table.  This sounds like the easiest approach,
and one that can be easily handled by just about
any NMS out there.

>of polling for an NMS in my opinion.

         And in mine.

> > Your comments on the above proposal are

Success is relative; the more success, the more relatives. -Anonymous