MPLS Working Group Wai Sum Lai Internet Draft Li-Jin Chung Document: 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]