Network Working Group Z. Li Internet-Draft L. Li Intended status: Standards Track Y. Gu Expires: January 9, 2020 Huawei July 8, 2019 Protocol Assisted Protocol (PAP) draft-li-rtgwg-protocol-assisted-protocol-01 Abstract For routing protocol troubleshooting, different approaches exibit merits w.r.t. different situations. They can be generally divided into two categories, the distributive way and the centralized way. A very commonly used distributive approach is to log in possiblly all related devices one by one to check massive data via CLI. Such approach provides very detailed device information, however it requires operators with high NOC (Network Operation Center) experience and suffers from low troubleshooting efficiency and high cost. The centralized approach is realized by collecting data from devices via approaches, like the streaming Telemetry or BMP(BGP Monitoring Protocol) RFC7854 [RFC7854], for the centralized server to analyze all gathered data. Such approach allows a comprehensive view fo the whole network and facilitates automated troubleshooting, but is limited by the data collection boundary set by different management domains, as well as high network bandwidth and CPU computation costs. This document proposes a semi-distributive and semi-centralized approach for fast routing protocol troubleshooting, localizing the target device and possibly the root cause, more precisely. It defines a new protocol, called the PAP (Protocol assisted Protocol), for devices to exchange protocol related information between each other in both active and on-demand manners. It allow devices to request specific information from other devices and receive replies to the requested data. It also allows actively transmission of information without request to inform other devices to better react w.r.t. network issues. 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]. Li, et al. Expires January 9, 2020 [Page 1] Internet-Draft Protocol Assisted Protocol July 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 January 9, 2020. 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. PAP Usage Use cases . . . . . . . . . . . . . . . . . . . 5 1.2.1. Use Case 1: BGP Route Oscillation . . . . . . . . . . 5 1.2.2. Use Case 2: RSVP-TE Set Up Failure . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. PAP Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4. PAP Message Format . . . . . . . . . . . . . . . . . . . . . 8 4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Negotiation Message . . . . . . . . . . . . . . . . . . . 9 4.3. Request Message . . . . . . . . . . . . . . . . . . . . . 10 4.4. Reply Message . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Notification Message . . . . . . . . . . . . . . . . . . 11 4.6. ACK Message . . . . . . . . . . . . . . . . . . . . . . . 12 Li, et al. Expires January 9, 2020 [Page 2] Internet-Draft Protocol Assisted Protocol July 2019 5. PAP Operations . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Capability Negotiation Process . . . . . . . . . . . . . 12 5.2. Data Request and Reply Process . . . . . . . . . . . . . 14 5.3. Data Notification Process . . . . . . . . . . . . . . . . 14 6. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction A healthy control plane, providing network connectivity, is the foundation of a well-functioning network. There have been rich routing and signaling protocols designed and used for IP networks, such as IGP (ISIS,OSPF), BGP, LDP, RSVP-TE and so on. The health issues of these protocols, such as neighbor/peer disconnect/set up failure, LSP set up failure, route flapping and so on, have been devoted with ongoing efforts for diagnosing and remediation. 1.1. Motivation The distributive protocol troubleshooting approach is typically realized through manual per-device check. It's both time- and labor- consuming, and requires NOC experience of the operators. Amongst all, localizing the target device is usually the most diffcult and time-consuming part. For example, in the case of route loop, operators first log in a random deivce that reports TTL alarms, and then check the looped route in the Forwarding Information Base (FIB) and/or the Routing Information Base (RIB). It requires device by device check, as well as manul data correlation, to pin point to the exact responsible device, since the information retrival and analysis of such distributive way is fragmented. In addition, the low efficiency and manul troubleshooting activities may further impact new network services and/or enlarge affected areas. The centralized network OAM, by collecting network-wide data from devices, enables automatic routing protocol troubleshooting. Date collection protocols, such as SNMP (Simple Network Management Protocol) [RFC1157], NETCONF (Network Configuration Protocol) [RFC6241], and (BMP) [RFC7854], can provide various information retrival, such as network states, routing data, configurations and so on. Such centrazlized way relies on the existence of a centralized server/controller, which is not supported by some legacy networks. What's more, even with the existence of a centralized server/ controller, it can only collect the data within its own management domain, while the cross-domain data are not available due to independent managment of different ISPs. Thus, the lack of such Li, et al. Expires January 9, 2020 [Page 3] Internet-Draft Protocol Assisted Protocol July 2019 information may lead to troubleshooting failure. In addition, centralized approaches may suffer from high network bandwidth and CPU computation consumptions. Another way of protocol troubleshooting is utilzing the protocol itself to convey diagnosing information. For example, some reason codes are carried in the Path-Err/ResvErr messages of RSVP-TE, so that to other nodes may know the why the tunnel fails to be set up. Such approaches is semi-distributive and semi-centralized. It does not rely on the deployment of a centralized server, but still gets partial global view of the network. However, there still requires non-trivial augementation works to existing routing protocols in order to support troubleshooting. This then raises the question that whether such non-routing data is suitable to be carried in these routing protocols. The extra encapsulation, parsing and analyzing work for the non-routing data would further slow down the network convergence. Thus, it's better to separate the routing and non- routing data transmission as well as data parsing. In addition, coexisting with legacy devices may cause interop issues. Thus, relying on augumenting existing routing protocols without network- wide upgrading may not only fail to provide the truobleshooting benefit, but further affect the operation of the existing routing system. What's more, the failure of routing protocol instance would lead to the failure of diagnosing itself. All in all, it's reasonable to separate the protocol diagnosing data generation/encapsulation/transmission/parsing from the protocol itself. This document proposes a new protocol, called the PAP (Protocol assisted Protocol), for devices to exchange protocol related information between each other. It allows both active and on-demand data exchange. Considering that massiveness of protocol/routing related data, the intuitive of designing PAP is not to exchange the comprehensive protocol/routing status between devices, but to provide very specific information required for the contemprary troubleshooting. The benefits of such a semi-distributive and semi- centralized approach are summarized as follows: 1. It facilitates automatic troubleshooting without requiring manul device by device check. 2. It allows individual device to have a more global view by requesting data from other devices. 3. It does not rely on the deployement of a centralized server/ controller. Li, et al. Expires January 9, 2020 [Page 4] Internet-Draft Protocol Assisted Protocol July 2019 4. It passes the dtata collection boundary set by different management domains by cross-domain data exchange between devices. 5. It relieves the bandwidth pressure of network-wide data collection, and the processing pressure of the centralized server. 6. It does not affect the running of existing routing protocols. 1.2. PAP Usage Use cases PAP allows both data request/reply and data notitication between devices. PAP speakers use the exchanged PAP data to help fast localize the network issues. 1.2.1. Use Case 1: BGP Route Oscillation A BGP route oscillation can be caused by various reasons, and usually leaves network-wide impact. In order to find the root cause and take remediation actions, the first step is to localize the oscillation source. In this case, a BGP speaker can send a PAP Request Message to the next hop device of the oscillating route asking " Are you the oscillation source?". If the BGP speaker is the oscillation source, possiblly knows by running a device diagnosing system, replies with a PAP Reply Message saying that "I'm the oscillation source!" to the device who sends the PAP Request Message. If the BGP speaker is not the oscillation source, it further asks the same question with a PAP Request Message to its next hop device of the oscillating route. This request and reply process continues util the request has reached the oscillation source. The source device then sends a PAP Reply Message to tell its upstream device along the PAP request path that " I am the oscillation source!", and then "xx is the oscillation source!" information is further sent back hop by hop to the device who originates the request. 1.2.2. Use Case 2: RSVP-TE 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. Using PAP, the device, which is reponsible for the tunnel set up failure, can send the PAP Notification Message to the Ingress device, and possibly with some reason codes so that Li, et al. Expires January 9, 2020 [Page 5] Internet-Draft Protocol Assisted Protocol July 2019 the ingress device can not only localize the target device but also the root cause. 2. Terminology IGP: Interior Gateway Protocol IS-IS: Intermediate System to Intermediate System OSPF: Open Shortest Path First 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 BMP: BGP Monitoring Protocol LSP: Link State Packet IPFIX: Internet Protocol Flow Information Export PAP: Protocol assisted Protocol UDP: User Datagram Protocol 3. PAP Overview PAP is a non-routing protocol used for PAP speakers to exchange routing protocol related information. The primary function of PAP is to provide a unfied tunnel for protocol diagnosing information exchange without augumenting each specific protocol. PAP uses UDP as its transport protocol, which is connectionless. The reason that UDP is selected over TCP is because PAP is intended for on-demand communications. The PAP packet is defined as follows. This document requires the assignment of a User Port registry for the UDP Destination Port. Li, et al. Expires January 9, 2020 [Page 6] Internet-Draft Protocol Assisted Protocol July 2019 +-------------+-------------+-------------+-------------+-------------+ | ETH. Header | IP Header | UDP Header | PAP Header | PAP Payload | +-------------+-------------+-------------+-------------+-------------+ Figure 1. Encapsulation in UDP This document uses PAP speakers to refer to two routing devices that support PAP and/or communicate with each other using PAP throughout. The communications between two PAP speakders should follow three major processes, i.e., the Capability Negotiation Process, the Request and Reply Process, and the Notification Process. This document defines 5 PAP Message types, i.e., Negotiation Message, Request Message, Reply Message, Notification Message, and ACK Message, which are used in the above PAP processes. Although PAP is connectionless, there still requires a successful Caoability Negotiation between two PAP speakers before the exchange of any PAP messages (except the Negotiation Message). The purpose of the Capability Negotiation process is to inform both PAP speakders of each other's PAP capabilties. The capabilities of a PAP speaker refer to the support of diagnosing information exchange of specific protocols, while the generation of such data are possibly enabled by a local protocol diagnosing system. The negotiation can be initiated by either the local or remote PAP speaker through sending out a PAP Negotiation Message. The Negotiation Message may or may not require an ACK Message, as indicated in the Negotiation Message. A successful negotiation is achieved if both PAP speakers have correctly received the other speakder's Negotiation Message regardless of the message content. A more detailed definition of a successful negotiation is defined in Section 5.1. After a successful negotiation, two PAP speakers can exchange any PAP Message on-demand. The purpose of the Request and Reply process is to acquire information needed by a PAP speaker from other PAP speakers for diagnosing a specific protocol. The Request and Reply Messages can be customized for different protocols. The process starts by any PAP speaker sending a Request Message to another PAP speaker. The PAP receiver, after receiving the Request message, sends out a Reply Message to the request sender. The generation of both Request and Reply Messages is protocol-specific, and depends on possibaly a local protocol diagnosing system. One Request Message received may further results in a new Request Message generated and sent out to a third PAP speaker, if the receiver does not have the answer to the sender. Both Request and Reply Messages may or may not require an ACK Message, as indicated in the Request/Reply Messages. The Notification Process is used to serve active data notification. Any PAP speaker, having information to share with other PAP speakers, Li, et al. Expires January 9, 2020 [Page 7] Internet-Draft Protocol Assisted Protocol July 2019 may start to send Notification Messages to any target PAP speaker. This information sharing is also protocol-specific, and can be possibly generated by a local protocl diagnosing system. The Notification Message may or may not require an ACK Message, as indicated in the Notification Message. 4. PAP Message Format 4.1. Common Header The common header is encapsulated in all PAP messages. It includes the following fields. 0 15 31 +----------------------+---------------------+ | Sequence Number | Length | +-----------+----------+---------------------+ | Msg. Type | +-----------+ Figure 2. PAP Common Header o Sequence Number (2 byte): It is used to indicate the sequence of the PAP Message. It uses unsigned integers to distinguish the PAP Messages sent to the same remote device. The integer is set incrementally in order time. o Length (2 bytes): Length of the message in bytes, including the Common Header and the following Message. o Message Type (1 byte): This indicates the PAP message type.The following types are defined, and listed as follows. * Type = TBD1: Negotiation Message. It is used for two devices to inform each other of the capabilties they support and no longer support. * Type = TBD2: Request Message. * Type = TBD3: Reply Message. * Type = TBD4: Notification Message. * Type = TBD5: ACK Message. It is used to confirm to the local device that the remote device has received a previous sent PAP message, which can be either a Negotiation Message, a Request Message, a Reply Message or an Notification Message. Li, et al. Expires January 9, 2020 [Page 8] Internet-Draft Protocol Assisted Protocol July 2019 4.2. Negotiation Message The Negotiation Message is used for both capabilty negotiation between the local PAP speaker and the remote PAP speaker. It is also used to indicate the enabling and distabling of any supported capabiliity. The Negotiation Message is required to be exchanged before two PAP speaers can exchange any other PAP Message types. 0 15 31 +--------------------------------------------+ | Version |A|C| Reserved | +--------------------------------------------+ | Protocol Capability | +--------------------------------------------+ | Optional Capability | +--------------------------------------------+ Figure 3. PAP Negotiation Message o Version (2 bytes): It indicates the PAP version. The current version is 0. o Flags (2 bytes): Two flag bits are currently defined. * The A bit is used to indicate if an ACK Message from the remote PAP speaker is required for each Negotiation Message sent. If an ACK is required, then the A bit SHOULD be set to "1", and "0" otherwise. * The C bit is used to indicate the enabling/disabling of the capabilities that carried in the Protocol Capability field. If the local device wants to inform the remote device of enabling one or more capabilities, the C bit SHOULD be set to "1". If the local device wants to inform the remote device of disabling one or more capabilities, the C bit SHOULD be set to "0". o Protocol Capability (4 bytes): It is 4-byte bit map that indicates the capability of inforamtion exchange regarding various protocols. Each bit represents one protocol. For example, the right most bit of the Protocl Capability represents the capability of exchanging IS-IS protocol related information. The format and definition of information exchanged, regarding each protocol, MUST follow the PAP Message format and definition. o Optional Capability (4 bytes): It is 4-byte bit map that indicates the capability of other inforamtion. It can be used to carry other application-specific information, which allows future extension. Its format and definition remains to be determined. Li, et al. Expires January 9, 2020 [Page 9] Internet-Draft Protocol Assisted Protocol July 2019 4.3. Request Message The Request Message is used for the local device to request specific data regarding one specific protocol or application from the remote device. It MUST be sent after a successful Capability Negotiation Process (described in Section 5.1), and the requested protocol/ application MUST be supported by both the local and remote devices, as indicated in the Negotiation Messages exchanged between the local and remote devices. The Statistic TLV is defined as follows. 0 15 31 +----------------------+ |A| Reserved | +----------------------+---------------------+ | Capability | +--------------------------------------------+ | Data Request | +--------------------------------------------+ Figure 4. PAP Request Message o Flags (2 bytes): The A bit is used to indicate if an ACK Message from the remote PAP speaker is required for each Request Message sent. If an ACK is required, then the A bit SHOULD be set to "1", and "0" otherwise. o Capability (4 bytes): It is 4-byte bit map that indicates the specific protocol/application the Request Message is requesting data for. The respective bit of this specific protocol/ application MUST be set to "1", and the rest of the bits MUST be set to "0". o Data Request (Variable): Specifies what data the local device is requesting. The specific format remains to be determined. 4.4. Reply Message The Reply Message is used to carry the information that the local device requests from the remote device through the Request Message. Li, et al. Expires January 9, 2020 [Page 10] Internet-Draft Protocol Assisted Protocol July 2019 0 15 31 +----------------------+ |A| Reserved | +----------------------+---------------------+ | Capability | +--------------------------------------------+ | Data Reply | +--------------------------------------------+ Figure 5. PAP Request Message o Flags (2 bytes): The A bit is used to indicate if an ACK Message from the remote PAP speaker is required for each Request Message sent. If an ACK is required, then the A bit SHOULD be set to "1", and "0" otherwise. o Capability (4 bytes): It is 4-byte bit map that indicates the specific protocol/application the Reply Message is replying for. The respective bit of this specific protocol/application MUST be set to "1", and the rest of the bits MUST be set to "0". o Data Reply (Variable): It contains the data that the local device requests from the remote device. The specific format remains to be determined. 4.5. Notification Message The Notification Message is used to carry the information that the local device sends to the remote device. 0 15 31 +----------------------+ |A| Reserved | +----------------------+---------------------+ | Capability | +--------------------------------------------+ | Data Nitification | +--------------------------------------------+ Figure 6. PAP Notification Message o Flags (2 bytes): The A bit is used to indicate if an ACK Message from the remote PAP speaker is required for each Request Message sent. If an ACK is required, then the A bit SHOULD be set to "1", and "0" otherwise. o Capability (4 bytes): It is 4-byte bit map that indicates the specific protocol/application the Notification Message is Li, et al. Expires January 9, 2020 [Page 11] Internet-Draft Protocol Assisted Protocol July 2019 notifying for. The respective bit of this specific protocol/ application MUST be set to "1", and the rest of the bits MUST be set to "0". o Data Notification (Variable): It contains the data that the local device actively sends to the remote device. The specific format remains to be determined. 4.6. ACK Message The ACK Message is used to confirm that the remote device has received a PAP Message that set the A bit to "1". The ACK Message includes only the ACK sequence Number field, which MUST be set to the sequence number carried in the PAP Common Header of the received PAP message, which requires this ACK Message. 0 15 31 +--------------------------------------------+ | ACK Sequence Number | +--------------------------------------------+ Figure 7. PAP ACK Message 5. PAP Operations The PAP operations include the following 3 processes, the Capability Negotiation Process, the Data Request and Reply Process, and the Data Notification Process. 5.1. Capability Negotiation Process The Capability Negotiation process refers to the process that two devices inform each other of the capabilties they support and no longer support. A successful negotiation that inform each other of the supported capabilities between two devices MUST be achieved before the exchange of any other PAP Message. The first Negotiation Message can be sent at any time per the local device's configuration. One or more Negotiation Messages can be sent at any time after the first Negotiation Message. Once a Negotiation Message is sent from a local device, an ACK Message from the remote device is required/or not per the indication of the "A" bit in the Negotiation Message. If the A bit is set to "1" (i.e., ACK is required), the local device SHUOLD wait for the ACK Message from the remote device for a certain time period before taking further actions, and if no ACK Message is received within this time frame, the local device SHOULD resend the Negotiation Message to the remote device. The waiting period can be configured locally. This send and Li, et al. Expires January 9, 2020 [Page 12] Internet-Draft Protocol Assisted Protocol July 2019 wait process CAN be repeated for at most 3 times before receiving a ACK Message from the remote device. If after 3 times of resending the Negotiation Message, still no ACK received, then this negotiation is treated as unsuccessful. If the A bit is set to "0", then the local device does not wait for any ACK Message. If no Negotiation Message is received from the remote device within a time frame, the local device can resend the Negotiation Message. This send and wait process CAN be repeated for at most 3 times before receiving a Negotiation Message from the remote device. If after 3 times of resending the Negotiation Message, still no Negotiation Message received, then this negotiation is treated as Unsuccessful. The waiting period can be configured locally. Once a Negotiation Message is received from the remote device, the negotiation between the two devices is treated as successful regardless from the local device's perspective. On the other hand, the remote device, after receiving the Negotiation Message from the local device, SHOULD send out its own Negotiation Message that indicates the capabilities that it supports. If the A bit of the received Negotiation Message from the local device is set to "1", the remote device SHOULD sent an ACK Message before sending the new Negotiation Message. After the remote device sends out the Negotiation Message back to the local device, it waits/or not for the ACK message, depending on if the A bit of the Negotiation Message sent to the local device is set to "1". If it's set to "1", the remote device waits for the ACK message for a certain time period before taking further actions. If no ACK Message is received within this time frame, the remote device SHOULD resend the Negotiation Message to the local device. The waiting period can be configured locally at the remote device. This send and wait process CAN be repeated for at most 3 times before receiving a ACK Message from the local device. If after 3 times of resending the Negotiation Message, still no ACK received, then the remote device treats this negotiation as unsuccessful, and successful otherwise. If the A bit of the Negotiation Message sent from the remote device is set to "0", then the remote device treats the negotiation as successful after sending out the Negotiation Message. The C bit in the Negotiation Message MUST always be set to "1" before the negotiation is successful. A successful Capability Negotiation means that both the local and remote devices have the information of what capabilties the other side support so that when exchanging any other messages, only the capabilities that are supported by both ends SHOULD be carried in the respective capabilty fields. Another process of the Capability Negotiation Process is to inform the remote device of the capability/capabilities that the local device no longer supports with the indication of C bit set as "0". Li, et al. Expires January 9, 2020 [Page 13] Internet-Draft Protocol Assisted Protocol July 2019 To inform the other device of the disabled capabiliity/capabilities, the local device MUST have sent one or more Negotiation Messages that indicate the support of such capability/capabilities previously. 5.2. Data Request and Reply Process After a successful Capability Negotiation, the local device CAN send the Data Request Message to the remote device per local configuration. An Reply Message SHOULD only be sent after receiving a Request Message. If the A bit of the Request Message is set to "1" (i.e., ACK is required), the local device SHUOLD wait for the ACK Message from the remote device for a certain time period before taking further actions, and if no ACK Message is received within this time frame, the local device SHOULD resend the Request Message to the remote device. The waiting period can be configured locally. This send and wait process CAN be repeated for at most 3 times before receiving a ACK Message from the remote device. If the A bit is set to "0", then the local device does not wait for any ACK Message. If no Reply Message is received from the remote device within a time frame, the local device can resend the Request Message. This send and wait process CAN be repeated for at most 3 times before receiving a Reply Message from the remote device. If after 3 times of resending the Request Message, still no Reply Message received, then no further action is taken. The waiting period can be configured locally. On the other hand, the remote device, after receiving the Request Message from the local device, SHOULD send out the Reply Message to reply the requst. If the A bit of the received Request Message from the local device is set to "1", the remote device SHOULD sent an ACK Message before sending the Reply Message. To request data for multiple protocols/applications, seperate Request Messages SHOULD be sent, with each Request Message requesting one specific protocol/application data. According, the Reply Message is also sent sperately per each Request Message. 5.3. Data Notification Process The Notification Message CAN be sent by the local or the remote device at any time once the Capability Negotiation is successful. Each Notification Message SHOULD only indicate one specific protocol/ application. The A bit can be set to "1" or "0" to allow the local/ remote device to know if the other device has received the Notification Message through the ACK Message. Li, et al. Expires January 9, 2020 [Page 14] Internet-Draft Protocol Assisted Protocol July 2019 6. IANA TBD 7. Contributors Jiaqing Zhang, Huawei, zhangjiaqing@huawei.com 8. Acknowledgments TBD 9. References [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. [I-D.ietf-netconf-yang-push] Clemm, A. and E. Voit, "Subscription to YANG Datastores", draft-ietf-netconf-yang-push-25 (work in progress), May 2019. [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, . Li, et al. Expires January 9, 2020 [Page 15] Internet-Draft Protocol Assisted Protocol July 2019 [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, . [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, . [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, . [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, . Authors' Addresses Zhenbin Li Huawei 156 Beiqing Rd Beijing China Email: lizhenbin@huawei.com Li, et al. Expires January 9, 2020 [Page 16] Internet-Draft Protocol Assisted Protocol July 2019 Lei Li Huawei 156 Beiqing Rd Beijing China Email: lily.lilei@huawei.com Yunan Gu Huawei 156 Beiqing Rd Beijing China Email: guyunan@huawei.com Li, et al. Expires January 9, 2020 [Page 17]