Network Working Group H. Chen Internet-Draft China Telecom Intended status: Informational Z. Li Expires: September 12, 2019 China Mobile F. Xu Tencent Y. Gu Z. Li Huawei March 11, 2019 Network-wide Protocol Monitoring (NPM): Use Cases draft-chen-npm-use-cases-00 Abstract As networks continue to scale, we need a coordinated effort for diagnosing control plane health issues in heterogeneous environments. Traditionally, operators developed internal solutions to address the identification and remediation of control plane health issues, but as networks increase in size, speed and dynamicity, new methods and techniques will be required. This document highlights key network health issues, as well as network planning requirements, identified by leading network operators. It also provides an overview of current art and techniques that are used, but highlights key deficiencies and areas for improvement. This document proposes a unified management framework for coordinating diagnostics of control plane problems and optimization of network design. Furthermore, it outlines requirements for collecting, storing and analyzing control plane data, to minimise or negate control plane problems that may significantly affect overall network performance and to optimize path/peering/policy planning for meeting application-specific demands. Requirements Language 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 [RFC2119]. Chen, et al. Expires September 12, 2019 [Page 1] Internet-Draft NPM Use Cases March 2019 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 12, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Role of Telemetry . . . . . . . . . . . . . . . . . . . . 3 1.2. Role of Control Plane Telemetry . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Network Troubleshooting Challenges . . . . . . . . . . . 5 3.2. Network Planning Challenges . . . . . . . . . . . . . . . 7 4. Network-wide Protocol Monitoring (NPM) . . . . . . . . . . . 7 5. NPM Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Network Troubleshooting Use Cases . . . . . . . . . . . . 9 5.1.1. IS-IS Route Flapping . . . . . . . . . . . . . . . . 10 5.1.2. LSDB Synchronization Failure . . . . . . . . . . . . 11 5.1.3. Route Loop . . . . . . . . . . . . . . . . . . . . . 11 5.1.4. Tunnel Set Up Failure . . . . . . . . . . . . . . . . 12 Chen, et al. Expires September 12, 2019 [Page 2] Internet-Draft NPM Use Cases March 2019 5.2. Network Planning Use Cases . . . . . . . . . . . . . . . 12 5.2.1. Route Policy Validation . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Recently, significant effort has been made to evolve control network resources, using management plane enhancements and control of network state via centralized and distributed control plane methods. There is ongoing effort in the diagnosing of forwarding plane performance degradation, using telemetry-based solutions and in-band data plane OAM. However, less emphasis has been applied on the diagnosing and remediation of health problems related to optimal control of network resources, and diagnosing control plane health issues. The document outlines the existing set of standards-based tools and highlights the lack of capability for addressing control plane monitoring. 1.1. Role of Telemetry The concept of network telemetry has been proposed to meet the current and future OAM demands, supporting real-time data collection, process, exportation, and analysis, and an architectural framework of existing Telemetry approaches is introduced in [I-D.song-ntf] [I-D.song-ntf]. Network telemetry provides visibility to the network health conditions, and is beneficial for faster network troubleshooting, network OpEx (operating expenditure) reduction, and network optimization. Telemetry can be applied to the data plane, control plane and management plane. There have been various methods proposed for each plane: o Management Plane Telemetry: The management plane telemetry focuses on network operational state retrieval and configuration management. SNMP (Simple Network Management Protocol) [RFC1157], NETCONF (Network Configuration Protocol) [RFC6241] and gNMI (gRPC Network Management Interface) [I-D.openconfig-rtgwg-gnmi-spec] are three widely adopted management plane Telemetry approaches. Data consumers can subscribe to specific data stores through SNMP/gRPC/ NETCONF. o Control Plane Telemetry: The control plane telemetry works on routing protocol monitoring and routing related data retrieval, e.g., topology, route policy, RIB and so on. BGP monitoring Chen, et al. Expires September 12, 2019 [Page 3] Internet-Draft NPM Use Cases March 2019 protocol (BMP) [RFC7854] is proposed to monitor BGP sessions and intended to provide a convenient interface for obtaining BGP route views. Date collected using BMP can be further analyzed with big data platforms for network health condition visualization, diagnose and prediction applications. o Data Plane Telemetry: The data plane telemetry works on traffic performance measurement and traffic related data retrieval, e.g., lattency, jitter, buffer size and so on. For example, In-situ OAM (iOAM) [I-D.brockners-inband-oam-requirements] embeds an instruction header to the user data packets, and collects the requested data and adds it to the user packet at each network node along the forwarding path. Applications such as path verification, SLA (service-level agreement) assurance can be enabled with iOAM. 1.2. Role of Control Plane Telemetry The above mentioned telemetry approaches may vary in data type and form, including: encapsulation, serialization, transportation,subscription, and data analysis, thus resulting in various applications. With the network operations and maintenance evolving towards automation and intent-driven, higher requirements are set for each plane. Healthy management plane and control plane are essential for high-quality data service provisioning. The visibility of management and control planes' healthiness provides insights for changes in the data plane. First of all, the running of control protocols aims to provide and guarantee the network connectivity and reachability, which is the foundation of any data service running above it. The monitoring of the control plane detects the healthiness issue in real time so that immediate troubleshooting actions can be taken, and thus mitigating the affect on data services as much as possible. Secondly, without route analytics, the dynamic nature of IP networking makes it virtually impossible to know at any time point how traffic is traversing the networks. For example, by collecting real-time BGP routes through BMP and correlating them with traffic data retrieved through data plane telemetry, the operator is able to provide both inter-domain and intra-domain traffic optimization. Finally, the validation and evaluation of route policies is another common appeal from both carriers and OTTs. The difficulty here majorly lies in the precise definition of the correctness of policies. In other words, the policy validation depends largely on the operator's understanding and manual judgement of the current network status instead of formatted and quantitive command executed Chen, et al. Expires September 12, 2019 [Page 4] Internet-Draft NPM Use Cases March 2019 at devices. Thus, it demands visualized presentations of how the policies impact the route changes through control plane telemtry so that operators may have direct judgement of the policy correctness. The conventional separated data collections of route policy and route information is not sufficient for the correctness validation of route policy. Based on discussions with leading operators, this document identifies the challenges and problems that the current control plane telemetry faces and suggests the data collection requirements. The necessity for a Network-wide Protocol Monitoring (NPM) framework is illustrated and conducted through the discussion of specific use cases. 2. Terminology IGP: Interior Gateway Protocol IS-IS: Intermediate System to Intermediate System BGP: Boarder Gateway Protocol BGP-LS: Boarder Gateway Protocol-Link State MPLS: Multi-Protocol Label Switching RSVP-TE: Resource Reservation Protocol-Traffic Engineering LDP: Label Distribution Protocol NPM: Network-wide Protocol Monitoring NPMS: Network Protocol Monitoring System BMP: BGP Monitoring Protocol LSP: Link State Packet SDN: Software Defined Network IPFIX: Internet Protocol Flow Information Export 3. Problem Statement 3.1. Network Troubleshooting Challenges According to Huawei 2016 network issue statistics, about 48% issues of the total amount are routing protocol-related, including protocol adjacency/peer set up failure, adjacency/peer flapping, protocol- Chen, et al. Expires September 12, 2019 [Page 5] Internet-Draft NPM Use Cases March 2019 related table error. What's more, the routing protocol issues are not standalone, which simultaneously come with anomaly status in data plane, and are finally reflected on poor service quality and user experience. Existing methods for protocol troubleshooting include CLI, SNMP, Netconf-YANG/gRPC-YANG and vendor-specific/third party tools. Using CLI to do per-device check provides adequate per device information, but lacks network-wide vision, thus leading to either massive labor/time consumption checking all devices or fail to localize the source. Besides, complex CLI usage (combination and repeat pattern) requires experience from the NOC person. Management protocols, like SNMP, Netconf/gRPC, provide information already/to be gathered from the network, which reduces operational complexity, but sacrifices data adequacy compared with CLI. Since the above protocols aren't designed specifically for routing troubleshooting, not all the data source required is currently supported for exportation, and the lack of certain data becomes the troubleshooting bottleneck. For example, in an LSP purge abnormal case caused by continuous corrupted LSP, it's useful to collect the corrupted LSP PDUs for root cause analysis. In addition, for the currently supported, as well as to be supported, data source collection, the data synchronization issue, due to export performance difference of various approaches, can be a concern for data correlation. The data collection requirements depend largely on the use cases, and more details are discussed in Section 5. Some third party OAM tools provide troubleshooting-customized information collection and analysis. For example, Packet Design uses passive listening to collect IS-IS/OSPF/BGP messages to do route analysis for troubleshooting and path optimization. Such passive listening lacks per-device information collection. For example, to detect the existence of a route loop and analyze the root cause, it not only requires the network-wide RIB/FIB collection, but also requires the route policy information that is responsible for the generation of loop issue. To summarize here, the currently protocols and tools do not provide sufficient data source for routing troubleshooting. There requires new methods or augmented work to existing methods to enhance the control plane data collection and to support more efficient data correlation. Chen, et al. Expires September 12, 2019 [Page 6] Internet-Draft NPM Use Cases March 2019 3.2. Network Planning Challenges The dynamic nature of IP networks, e.g., peer up/down, prefix advertisement, route change, and so on, has great influence on the service provisioning. With the emerging of new network services, such as automated driving systems, AR (Augmented Reality), and so on, network planning is facing new requirements in order to meet the latency, bandwidth and security demands. The requirements can generally break into two perspectives: 1. sufficient and up-to-date routing data collection as the input for network simulation; 2. accurate what-if simulation to evaluate new network planning actions. Most existing control plane and data plane simulation tools, e.g., Batfish [Batfish], use device configurations to generate a control/ data plane. There exists some concerns w.r.t. such simulation method: 1. in a multi-vendor network understanding and translating the configuration files is a non-trivial task for the simulator; 2. the generated control/control plane is not the 100% mirroring of the actual network, and thus resulting in less accurate simulation results. Thus, it requires real-time routing data collection from the on-going network. Currently, BGP routes and peering states are monitored in real-time by using BMP. However, IS-IS/OSPF/MPLS routing data still lacks legitimate and comprehensive monitoring. Here, not only the data coverage, including RIB/FIB, network topology, peering states and so on, but also the data synchronization of various devices should be considered in order to recover a faithful data/control plane within the simulator. 4. Network-wide Protocol Monitoring (NPM) With the above mentioned challenges facing the control plane telemetry, it is of great value to identify the requirements from typical use cases, and the gaps between the requirements and existing methods. It is thus necessary to propose a comprehensive control plane telemetry framework, as shown in Figure 1. Chen, et al. Expires September 12, 2019 [Page 7] Internet-Draft NPM Use Cases March 2019 +-------------+ +----->+ NPM Server +<-----+ | +------+------+ | | ^ | | + | | BMP,gRPC,Netconf, | | BGP+LS,new|protocol?: | | topology,protocol PDU, | | RIB,route policy, | | statistics... | ****|*************|*************|***** * | | | AS0* * | +--+--+ | * * | +...+-->+ R 3 +<--+...+ | * * | | +-----+ | | * * | | | | * * | + | | * * | ISIS/OSPF/BGP/ | | * * | MPLS/SR... | | * * | + + | * * | | ISIS/OSPF/BGP/| * * | | MPLS/SR... + | * * | | | | * BGP/MPLS* | v ISIS/OSPF/BGP/ v | *BGP/MPLS +-----+ /SR * ++--+-+ MPLS/SR... +-+--++ */SR +-----+ | AS1 +<---------->+ R 1 +<-----+...+----->+ R 2 +<---------->+ AS2 | +-----+ * +-----+ +-----+ * +-----+ * * ************************************** Figure 1: NPM framework Under the NPM framework, the challenges, use cases, requirements, gaps, and solutions options are to be identified and discussed. The NPM problem space is depicted in Figure 2. Two general requirements are concluded from the challenges discussed above. o The requirement of a "tunnel" for the control plane data export: There should be a way (or ways) of exporting the required control plane data, and the export performance (e.g., data modeling, encoding and transmission) should be able to meet per application requirements; o The requirement of adequate data collection: In order to support specific troubleshooting and planning use cases, the collected data coverage, including the data type coverage and the network coverage, should be adequate. The data type coverage refers to data such as protocol PDUs, RIBs, policy and so on, and the Chen, et al. Expires September 12, 2019 [Page 8] Internet-Draft NPM Use Cases March 2019 network type coverage refers to the devices providing such information. More specific requirements may vary case by case, but it is a common appeal to guarantee a valid tunnel and adequate data collection. Data Source: Topology,protocol PDU, NPM problem space: RIB,route policy, suffcient data type coverage, statistics... sufficient device coverage +--------+----------+ | v +-------------+-------------+ | Data Generation: | NPM problem space: | data encapsulation, | data model definition, | data serialization, | data process efficiency | data subscription | +-------------+-------------+ | v +-------------+-------------+ | Data Transportation: | NPM problem space: | | Transportation protocol | BMP, gRPC, Netconf, | selection, | BGP-LS, new protocol? | exportation efficiency +-------------+-------------+ | v +-------------+-------------+ | Data Analysis: | | Protocol troubleshooting, | NPM problem space: | Policy validation, | data synchronization, | Traffic optimization, | data parse efficiency | What-if simulation | +---------------------------+ Figure 2: NPM problem space 5. NPM Use Cases 5.1. Network Troubleshooting Use Cases We have identified several typical routing issues that occur frequently in the network, and are typically hard to localize. Chen, et al. Expires September 12, 2019 [Page 9] Internet-Draft NPM Use Cases March 2019 5.1.1. IS-IS Route Flapping The IS-IS Route Flapping refers to the situation that one or more routes appear and then disappear in the routing table repeatedly. Route flapping usually comes with massive PDUs interactions (e.g., LSP, LSP purge...), which consume excessive network bandwidth, and excessive CPU processing. In addition, the impact is often network- wide. The localizing of the flapping source and the identifying of root causes haven't been easy work due to various reasons. The flapping can be caused by system ID conflict, IS-IS neighborship flapping, route source flapping (caused by import route policy misconfiguration) , device clock dis-function with abnormal LSP purge (e.g., 100 times faster) and so on. o The system ID conflict check is a network-wide work. If such information is collected centrally to a controller/server, the issues can be identified in seconds, and more importantly, in advance of the actual flapping event. o The IS-IS neighborship flapping is typically caused by interface flapping, BFD flapping, CPU high and so on. Conventionally, to located the issue, operators typically identify the target device(s), and then log in the devices to check related statistics, parsed protocol PDU data and configurations. The manual check often requires a combination of multiple CLIs (check cost/next hop/exit interface/LSP age...) in a repeated manner, which is time-consuming and requires rich OAM experience. If such statistics and configuration data were collected at the server in real-time, the server may analyze them automatically or semi- automatically with troubleshooting algorithms implemented at the server. o In the case that route policies are misconfigured, which then causes the route flapping, it's typically difficult to directly identify the responsible policy in a short time. Thus, if the route change history is recorded in correlation with the route policy, then with such record collected at the server, the server can directly identify the responsible policy with the one-to-one mapping between policy processing and the route attribute change. o In the case that flapping comes with abnormal LSP purges, it may be due to continuous LSP corruptions with falsified shorter Remaining Lifetime, or the clock running 100 times faster with 100 times more purge LSPs generated. In order to identify the purge originator, RFC 6232 [RFC6232] proposes to carry the Purge Orginator Identification (POI) TLV in IS-IS. However, to analyze Chen, et al. Expires September 12, 2019 [Page 10] Internet-Draft NPM Use Cases March 2019 the root cause of such abnormal purges, the collection and analysis of LSP PDUs are needed. 5.1.2. LSDB Synchronization Failure During the IS-IS flooding, sometimes the LSP synchronization failure happens. The synchronization failure causes can be generally classified into three cases: o Case 1, the LSP is not correctly advertised. For example, an LSP sent by Router A fails to be synchronized at Router B. It can be due to incorrect route export policy, or too many prefixes being advertised which exceeds the LSP/MTU threshold, and so on at Router A. o Case 2, LSP transmission error, which is tyically caused by IS-IS adjacency failure, .e.g., link down/BFD down/authentication failure. o Case 3, the LSP is received but not correctly processed. The problem that happens at Router B can be faulty route import policy, or Router B being in Overload mode, or the hardware/ software bugs. With sufficient ISIS PDU related statistics and parsed PDU information recorded at the device, the neighborship failure in Case 2 can be typically diagnosed at Router A or Router B independently. With such diagnosing information collected (e.g., in the format of reason code) in real-time, the server can identify the root synchronization issue with much less time and labor consumption compared with conventional methods. In Case 1 & 3, the failure is mostly caused by incorrect route policy and software/hardware issue. By comparing the LSDB with the sent/received LSP, differences can be recognized. Then the difference may further guide the localization of the root cause. Thus, by collecting the LSDBs and sent/received LSPs from the two affected neighbors, the server can have more insights at the synchronization failure. 5.1.3. Route Loop Incorrect import policy, such as incorrect protocol priority (distance) or improper default route configuration, may result in a route loop. TTL anomaly report or packet loss complain triggers loop alarm. However, locating the exact device(s) and more importantly the responsible configuration/policy is definitely non-trivial work. The generation of routing information base/forwarding information base (RIB/FIB) is related to various protocols and massive route Chen, et al. Expires September 12, 2019 [Page 11] Internet-Draft NPM Use Cases March 2019 policies, which often makes it hard to locate the loop source in a timely manner. If the network-wide RIB/FIB data can be collected in real-time, the server is able to run loop detection algorithms to detect and locate the loop. More importantly, with real-time RIB/FIB collected as the input for network simulator, loop can be predicted with what-if simulations of network changes, such as new policy, or link failure. 5.1.4. Tunnel Set Up Failure The MPLS label switch path set up, either using RSVP-TE or LDP, may fail due to various reasons. Typical troubleshooting procedures are to log in the device, and then check if the failure lies on the configuration, or path computation error, or link failure. Sometimes, it requires the check of multiple devices along the tunnel. Certain reason codes can be carried in the Path-Err/ResvErr messages of RSVP-TE, while other data are currently not supported to be transmitted to the path ingress/egress node, such as the authentication failure. In this case, if the tunnel configurations of devices along the tunnel, as well as the link states, and other reasons diagnosed by each device can be collected centrally, the server is able to do a thorough analysis and find the root cause. 5.2. Network Planning Use Cases Monitoring and analyzing the network routing events not only help identify the root causes of network issues, but also provide visibility of how routing changes affect network traffic. With the benefit of data plane telemetry, such as iOAM and IPFIX, network traffic matrices can be generated to give a glance of the current network performance. More specifically, traffic matrices visualize the current and historical network changes, such as link utilization, link delay, jitter, and so on. While traffic matrices provide "what" are the network changes, the control plane event monitoring, such as adjacency/peering failure, route flapping, prefix advertize/withdraw, provides "why". 5.2.1. Route Policy Validation Route policy validation has been a great concern for operators when implementing new policies as well as optimizing existing pollicies. Validation comes in two perspectives: o Firstly, there requires valid monitoring of implemented policy correlated with network changes to understand how one policy impacts routing in both single-device and network-wide views. Conventionally, policy/configuration data collection (e.g., Chen, et al. Expires September 12, 2019 [Page 12] Internet-Draft NPM Use Cases March 2019 through Netconf/YANG) is separate from route information collection (e.g., BMP), which lacks correlation between policy and routes. Thus, even with both information at hand, it is still difficult for the operator to figure out how a policy impacts the route change. If the route change is recorded correlated with policy processing, the server can directly identify the impact through the correlation analysis of such data collected from all devices. o Secondly, there requires pre-check of policy impact using simulation tools. Most existing simulation tools use device configurations to generate a control plane/data plane, and then run what-if simulations to evaluate a new policy. However, there exists difference between the on-going network and the generated control/data plane, and thus leading the simulation results less effective. If the control/data plane snapshot (e.g., topology, protocol neighbor state, RIB...) of the on going network is realized and taken as the input of the simulation, the reliability of the evaluation can be greatly improved. 6. Security Considerations TBD 7. Contributors TBD 8. Acknowledgments TBD 9. References [Batfish] etc., A. F., "A General Approach to Network Configuration Analysis", May 2015. [I-D.brockners-inband-oam-requirements] Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, T., Lapukhov, P., and r. remy@barefootnetworks.com, "Requirements for In-situ OAM", draft-brockners-inband- oam-requirements-03 (work in progress), March 2017. Chen, et al. Expires September 12, 2019 [Page 13] Internet-Draft NPM Use Cases March 2019 [I-D.ietf-grow-bmp-adj-rib-out] Evens, T., Bayraktar, S., Lucente, P., Mi, K., and S. Zhuang, "Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)", draft-ietf-grow-bmp-adj-rib-out-03 (work in progress), December 2018. [I-D.ietf-grow-bmp-local-rib] Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, "Support for Local RIB in BGP Monitoring Protocol (BMP)", draft-ietf-grow-bmp-local-rib-02 (work in progress), September 2018. [I-D.ietf-netconf-yang-push] Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- Nygaard, E., Bierman, A., and B. Lengyel, "Subscription to YANG Datastores", draft-ietf-netconf-yang-push-22 (work in progress), February 2019. [I-D.openconfig-rtgwg-gnmi-spec] Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, C., and C. Morrow, "gRPC Network Management Interface (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in progress), March 2018. [I-D.song-ntf] Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a Network Telemetry Framework", draft-song-ntf-02 (work in progress), July 2018. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1157, DOI 10.17487/RFC1157, May 1990, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, . Chen, et al. Expires September 12, 2019 [Page 14] Internet-Draft NPM Use Cases March 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, . [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, . [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge Originator Identification TLV for IS-IS", RFC 6232, DOI 10.17487/RFC6232, May 2011, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . Chen, et al. Expires September 12, 2019 [Page 15] Internet-Draft NPM Use Cases March 2019 Authors' Addresses Huanan Chen China Telecom 109 West Zhongshan Ave Guangzhou China Email: chenhuanan@gsta.com Zhenqiang Li China Mobile No. 32 Xuanwumenxi Ave., Xicheng District Beijing China Email: lizhenqiang@chinamobile.com Feng Xu Tencent Guangzhou China Email: oliverxu@tencent.com Yunan Gu Huawei 156 Beiqing Rd Beijing China Email: guyunan@huawei.com Zhenbin Li Huawei 156 Beiqing Rd Beijing China Email: lizhenbin@huawei.com Chen, et al. Expires September 12, 2019 [Page 16]