MPLS Working Group Wai Sum Lai
Internet Draft Li-Jin Chung
Document: <draft-lai-mpls-mib-rqmts-00.txt> AT&T Labs
Category: Informational
April 2003
Network Management Requirements for MPLS MIBs
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In this document, requirements for three MPLS-related MIBs (LDP-MIB,
VPN-MIB, and BGP4-MIB) are presented for the support of specific
network management needs for fault and performance management.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Conventions used in this document..................................1
1. Introduction....................................................2
2. Requirements for the LDP-MIB....................................2
2.1 Performance Management Requirement.............................2
2.2 Drawbacks of existing approach.................................3
2.3 Fault Management Requirement...................................4
Lai, et al Category - Expiration [Page 1]
Internet-Draft Requirements for MPLS MIBs Apr 2003
3. Requirements for the VPN-MIB....................................4
3.1 Number of Dropped Routes.......................................4
3.2 RT/RD Linkage..................................................4
4. Requirements for the BGP4-MIB...................................5
4.1 Maximum-Prefix Threshold.......................................5
5. Conclusions.....................................................5
6. Security Considerations.........................................5
7. References......................................................5
8. Acknowledgments.................................................5
9. Author's Addresses..............................................5
Full Copyright Statement...........................................6
1. Introduction
In this document, we present requirements for three of the MPLS-
related MIBs based on testing in our lab that was focused on
providing a management solution for planned services (e.g., MPLS
VPN). These are the LDP-MIB [1], VPN-MIB [2], and BGP4-MIB [3].
The requirements are for the support of specific network management
needs in the areas of fault and performance management. For
example, through our testing of the LDP-MIB [1], we found that some
of the objects require enhancements to make it more effective to
identify the fault condition (and thus more effective for
troubleshooting and trouble resolution), while other objects require
new sub-object(s) to present a certain level of aggregation to meet
operational need.
Requirements for the LDP-MIB, VPN-MIB, and BGP4-MIB are described
separately in the next three sections to follow. No specific MIB
extensions or objects are proposed based on the requirements. Such
extensions are left to discussion and consensus among MIB designers
based on the requirements.
2. Requirements for the LDP-MIB
2.1 Performance Management Requirement
In the LDP-MIB of an LSR, there is an LDP Entity for each LDP-
enabled interface. Each such entity is a collection of
configuration, control, and status information for the establishment
of LDP Sessions. In particular, it contains the label objects, in
either the Generic Label Space or the Per-Interface Label Space. An
LDP Session is set up by using one of these label objects.
For engineering of LDP Sessions and router resource management,
there is a need to capture the signaling usage/performance of the
LDP Entities, as well as the traffic usage/performance of the LDP
Sessions. Currently in the LDP-MIB, in the LDP Entity Statistics
Table mplsLdpEntityStatsTable, there is the mplsLdpAttemptedSessions
counter for the total attempted sessions. Other than that, there
Lai, et al Category - Expiration [Page 2]
Internet-Draft Requirements for MPLS MIBs Apr 2003
are no objects to provide the necessary counters to record usage for
either the Generic Label Space Entities or the Per-Interface Label
Space Entities.
To support LDP Entity and Session statistics reports for MPLS
performance management, enhancement to the LDP-MIB is needed to
provide summary statistics on the health of LDP Entities and
Sessions to capture the usage/performance characteristics.
Furthermore, such enhancement should provide a linkage between the
LDP Entity/Session and the physical interface to aid troubleshooting
by a service provider. It would be unacceptable to have to go
through many hoops of NMS processing/analysis to get such
information. Not only will this process not meet the real-time
network management response time requirement, the reliability of the
resulting information is also questionable.
2.2 Drawbacks of existing approach
To provide a high-level barometer of the performance of LDP
Entity/Sessions, we need a way to get aggregate counts for
performance monitoring reasons, so that the ratio of attempts and
successful attempts can be estimated.
For an LDP Session that has been established on an LDP Entity, there
will be a notification if the session goes up/down. Thus, it is
possible for a gauge32-like object for an Established Session
Counter to be gleaned from the number of mplsLdpSessionEntries and
from examining the mplsLdpEntityGenLREntries for the Generic Label
Space. Similarly, for the equivalent of the Disabled Session
Counter, a count of the glitches in the Session related to Generic
Labels could possibly be figured out by polling the
mplsLdpSesDiscontinuityTime object for the LDP Entities that are
associated with a Generic Label range. For the Per-Interface Label
space, one would look at the Interface Label tables associated with
an Entity instead of the Generic Label range table. Note that, as
currently specified, once a Session is started, the label range
tables cannot change. This means that once an NMS retrieves the
Entity and Label range information, it will be fairly static.
Hence, the NMS can just poll the mplsLdpEntityLastChange to see if
there are changes to the Entity table.
While existing procedures are available as described above, such
procedures also depend mostly on the NMS to perform different
manipulation of the MIB-collected data to make them meaningful.
Given that LDP itself is complicated enough, a more useful approach
would be to not rely on the NMS to do too much work to understand
the performance of LDP. As far as possible, a solution must not
require extensive MIB walks of the LDP-MIB, to avoid the consumption
of valuable network resources, e.g., by reducing the volume of MIB
data that needs to be transmitted and subsequently processed by the
NMS. Note that reduction of the volume of data transmission may
help to increase the data reliability as well.
Lai, et al Category - Expiration [Page 3]
Internet-Draft Requirements for MPLS MIBs Apr 2003
2.3 Fault Management Requirement
It is required to ensure persistency of information in the LDP-MIB
Entity Table and Entity Statistics Table, whenever an LDP Entity is
disabled and then re-enabled.
Currently, the instrumentations in the Entity Table and the Entity
Statistics Table will only show active LDP Entities (i.e., those
with enabled status). When an LDP Entity goes up and down, its
entry in the Entity Table appears and then disappears entirely.
This will result in the loss of historical information related to
the LDP Entity status and performance information. An enhancement
is needed so the counters will accumulate with prior-entity ID-
counters.
3. Requirements for the VPN-MIB
3.1 Number of Dropped Routes
Currently, there is the mplsNumVrfRouteMaxThreshExceeded
notification when the operator-defined VRF maximum route threshold
is exceeded. However, this notification gives no information on the
number of routes being dropped due to such threshold being exceeded.
It is required that such a count be reported for capacity planning
and threshold tuning purposes. Some examples of practical use are:
1. Engineering of the routing table - to properly tune its size via
the maximum route threshold.
2. Understanding of customer demand for prefix routes - increase in
demand could be due to growth of the business, or re-homing. Re-
engineering effort might be needed if this is the case.
3. Trouble shooting and understanding the customer service impact -
customer might inject too many routes due to provisioning errors.
4. Router resource management to optimize router performance - the
overflow counts can be summarized at the per-router level for
forecasting and capacity planning.
3.2 RT/RD Linkage
In the mplsVpnVrfRouteTargetTable table, it appears that there is no
explicit mapping between the route targets (RT) and their associated
Route Distinguisher (RD). An association between VRF, RD, and RT in
this table should be provided so that the RT is associated with the
RD index and not the VRF name index. Currently, the
mplsVpnVrfRouteTargetTable table is key on the VRF name, but one VRF
name could have two or more RD numbers assigned to it. Also, while
the mplsVpnRouteTarget uses the same format as the
mplsVpnRouteDistinguisher, it does not provide the RD index. An
explicit association between RT and RD is needed.
Lai, et al Category - Expiration [Page 4]
Internet-Draft Requirements for MPLS MIBs Apr 2003
4. Requirements for the BGP4-MIB
4.1 Maximum-Prefix Threshold
As a part of VPN resource monitoring to protect router stability,
BGP neighbor maximum-prefix limit on the PE-CE link should be used
to limit the number of eBGP routes injected in the VRF to prevent
router crash. Thus, there is a need to keep track of the current
number of BGP prefixes on the PE-CE link. For this monitoring, a
new notification should be provided to indicate per-interface BGP
maximum prefix threshold exceeded for the PE-CE e-BGP connection.
This notification can be used for capacity management, resource
management, and network management.
To allow for automatic clearing of the above notification, a clear
notification is needed to indicate that the number of BGP prefix for
the same interface is lower than the maximum threshold. This is to
be generated only when the threshold-exceeded notification is
active.
5. Conclusions
To be added.
6. Security Considerations
To be added.
7. References
Normative References
1 J. Cucchiara, H. Sjostrand, and J. Luciani, "Definitions of
Managed Objects for the Multiprotocol Label Switching, Label
Distribution Protocol (LDP)," Internet-Draft, Work in Progress.
2 T.D. Nadeau, L. Fang, H. Van Der Linde, S.J. Brannon, F.M.
Chiussi, J. Dube, and M. Tatham, "MPLS/BGP Virtual Private
Network Management Information Base Using SMIv2," Internet-Draft,
Work in Progress.
3 J. Haas and S. Hares (Editors), "Definitions of Managed Objects
for the Fourth Version of Border Gateway Protocol (BGP-4),"
Internet-Draft, Work in Progress.
Informative References
8. Acknowledgments
We would like to thank Jerry Ash for his input and comments.
9. Author's Addresses
Wai Sum Lai
Lai, et al Category - Expiration [Page 5]
Internet-Draft Requirements for MPLS MIBs Apr 2003
AT&T Labs
Room D5-3D18
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-3712
Email: wlai@att.com
Li-Jin W. Chung
AT&T Labs
Room C4-2A05
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-8449
Email: lic@att.com
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Lai, et al Category - Expiration [Page 6]