idnits 2.17.1 draft-li-rtgwg-protocol-assisted-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC7854]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.brockners-inband-oam-requirements' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'I-D.song-ntf' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC1213' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'RFC3988' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 731, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-brockners-inband-oam-requirements (ref. 'I-D.brockners-inband-oam-requirements') ** Downref: Normative reference to an Informational draft: draft-song-ntf (ref. 'I-D.song-ntf') ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Experimental RFC: RFC 3988 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft L. Li 4 Intended status: Standards Track Y. Gu 5 Expires: January 9, 2020 Huawei 6 July 8, 2019 8 Protocol Assisted Protocol (PAP) 9 draft-li-rtgwg-protocol-assisted-protocol-01 11 Abstract 13 For routing protocol troubleshooting, different approaches exibit 14 merits w.r.t. different situations. They can be generally divided 15 into two categories, the distributive way and the centralized way. A 16 very commonly used distributive approach is to log in possiblly all 17 related devices one by one to check massive data via CLI. Such 18 approach provides very detailed device information, however it 19 requires operators with high NOC (Network Operation Center) 20 experience and suffers from low troubleshooting efficiency and high 21 cost. The centralized approach is realized by collecting data from 22 devices via approaches, like the streaming Telemetry or BMP(BGP 23 Monitoring Protocol) RFC7854 [RFC7854], for the centralized server to 24 analyze all gathered data. Such approach allows a comprehensive view 25 fo the whole network and facilitates automated troubleshooting, but 26 is limited by the data collection boundary set by different 27 management domains, as well as high network bandwidth and CPU 28 computation costs. 30 This document proposes a semi-distributive and semi-centralized 31 approach for fast routing protocol troubleshooting, localizing the 32 target device and possibly the root cause, more precisely. It 33 defines a new protocol, called the PAP (Protocol assisted Protocol), 34 for devices to exchange protocol related information between each 35 other in both active and on-demand manners. It allow devices to 36 request specific information from other devices and receive replies 37 to the requested data. It also allows actively transmission of 38 information without request to inform other devices to better react 39 w.r.t. network issues. 41 Requirements Language 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [RFC2119]. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on January 9, 2020. 64 Copyright Notice 66 Copyright (c) 2019 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (https://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 83 1.2. PAP Usage Use cases . . . . . . . . . . . . . . . . . . . 5 84 1.2.1. Use Case 1: BGP Route Oscillation . . . . . . . . . . 5 85 1.2.2. Use Case 2: RSVP-TE Set Up Failure . . . . . . . . . 5 86 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 3. PAP Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 88 4. PAP Message Format . . . . . . . . . . . . . . . . . . . . . 8 89 4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 8 90 4.2. Negotiation Message . . . . . . . . . . . . . . . . . . . 9 91 4.3. Request Message . . . . . . . . . . . . . . . . . . . . . 10 92 4.4. Reply Message . . . . . . . . . . . . . . . . . . . . . . 10 93 4.5. Notification Message . . . . . . . . . . . . . . . . . . 11 94 4.6. ACK Message . . . . . . . . . . . . . . . . . . . . . . . 12 96 5. PAP Operations . . . . . . . . . . . . . . . . . . . . . . . 12 97 5.1. Capability Negotiation Process . . . . . . . . . . . . . 12 98 5.2. Data Request and Reply Process . . . . . . . . . . . . . 14 99 5.3. Data Notification Process . . . . . . . . . . . . . . . . 14 100 6. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 102 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 106 1. Introduction 108 A healthy control plane, providing network connectivity, is the 109 foundation of a well-functioning network. There have been rich 110 routing and signaling protocols designed and used for IP networks, 111 such as IGP (ISIS,OSPF), BGP, LDP, RSVP-TE and so on. The health 112 issues of these protocols, such as neighbor/peer disconnect/set up 113 failure, LSP set up failure, route flapping and so on, have been 114 devoted with ongoing efforts for diagnosing and remediation. 116 1.1. Motivation 118 The distributive protocol troubleshooting approach is typically 119 realized through manual per-device check. It's both time- and labor- 120 consuming, and requires NOC experience of the operators. Amongst 121 all, localizing the target device is usually the most diffcult and 122 time-consuming part. For example, in the case of route loop, 123 operators first log in a random deivce that reports TTL alarms, and 124 then check the looped route in the Forwarding Information Base (FIB) 125 and/or the Routing Information Base (RIB). It requires device by 126 device check, as well as manul data correlation, to pin point to the 127 exact responsible device, since the information retrival and analysis 128 of such distributive way is fragmented. In addition, the low 129 efficiency and manul troubleshooting activities may further impact 130 new network services and/or enlarge affected areas. 132 The centralized network OAM, by collecting network-wide data from 133 devices, enables automatic routing protocol troubleshooting. Date 134 collection protocols, such as SNMP (Simple Network Management 135 Protocol) [RFC1157], NETCONF (Network Configuration Protocol) 136 [RFC6241], and (BMP) [RFC7854], can provide various information 137 retrival, such as network states, routing data, configurations and so 138 on. Such centrazlized way relies on the existence of a centralized 139 server/controller, which is not supported by some legacy networks. 140 What's more, even with the existence of a centralized server/ 141 controller, it can only collect the data within its own management 142 domain, while the cross-domain data are not available due to 143 independent managment of different ISPs. Thus, the lack of such 144 information may lead to troubleshooting failure. In addition, 145 centralized approaches may suffer from high network bandwidth and CPU 146 computation consumptions. 148 Another way of protocol troubleshooting is utilzing the protocol 149 itself to convey diagnosing information. For example, some reason 150 codes are carried in the Path-Err/ResvErr messages of RSVP-TE, so 151 that to other nodes may know the why the tunnel fails to be set up. 152 Such approaches is semi-distributive and semi-centralized. It does 153 not rely on the deployment of a centralized server, but still gets 154 partial global view of the network. However, there still requires 155 non-trivial augementation works to existing routing protocols in 156 order to support troubleshooting. This then raises the question that 157 whether such non-routing data is suitable to be carried in these 158 routing protocols. The extra encapsulation, parsing and analyzing 159 work for the non-routing data would further slow down the network 160 convergence. Thus, it's better to separate the routing and non- 161 routing data transmission as well as data parsing. In addition, 162 coexisting with legacy devices may cause interop issues. Thus, 163 relying on augumenting existing routing protocols without network- 164 wide upgrading may not only fail to provide the truobleshooting 165 benefit, but further affect the operation of the existing routing 166 system. What's more, the failure of routing protocol instance would 167 lead to the failure of diagnosing itself. All in all, it's 168 reasonable to separate the protocol diagnosing data 169 generation/encapsulation/transmission/parsing from the protocol 170 itself. 172 This document proposes a new protocol, called the PAP (Protocol 173 assisted Protocol), for devices to exchange protocol related 174 information between each other. It allows both active and on-demand 175 data exchange. Considering that massiveness of protocol/routing 176 related data, the intuitive of designing PAP is not to exchange the 177 comprehensive protocol/routing status between devices, but to provide 178 very specific information required for the contemprary 179 troubleshooting. The benefits of such a semi-distributive and semi- 180 centralized approach are summarized as follows: 182 1. It facilitates automatic troubleshooting without requiring manul 183 device by device check. 185 2. It allows individual device to have a more global view by 186 requesting data from other devices. 188 3. It does not rely on the deployement of a centralized server/ 189 controller. 191 4. It passes the dtata collection boundary set by different 192 management domains by cross-domain data exchange between devices. 194 5. It relieves the bandwidth pressure of network-wide data 195 collection, and the processing pressure of the centralized 196 server. 198 6. It does not affect the running of existing routing protocols. 200 1.2. PAP Usage Use cases 202 PAP allows both data request/reply and data notitication between 203 devices. PAP speakers use the exchanged PAP data to help fast 204 localize the network issues. 206 1.2.1. Use Case 1: BGP Route Oscillation 208 A BGP route oscillation can be caused by various reasons, and usually 209 leaves network-wide impact. In order to find the root cause and take 210 remediation actions, the first step is to localize the oscillation 211 source. In this case, a BGP speaker can send a PAP Request Message 212 to the next hop device of the oscillating route asking " Are you the 213 oscillation source?". If the BGP speaker is the oscillation source, 214 possiblly knows by running a device diagnosing system, replies with a 215 PAP Reply Message saying that "I'm the oscillation source!" to the 216 device who sends the PAP Request Message. If the BGP speaker is not 217 the oscillation source, it further asks the same question with a PAP 218 Request Message to its next hop device of the oscillating route. 219 This request and reply process continues util the request has reached 220 the oscillation source. The source device then sends a PAP Reply 221 Message to tell its upstream device along the PAP request path that " 222 I am the oscillation source!", and then "xx is the oscillation 223 source!" information is further sent back hop by hop to the device 224 who originates the request. 226 1.2.2. Use Case 2: RSVP-TE Set Up Failure 228 The MPLS label switch path set up, either using RSVP-TE or LDP, may 229 fail due to various reasons. Typical troubleshooting procedures are 230 to log in the device, and then check if the failure lies on the 231 configuration, or path computation error, or link failure. 232 Sometimes, it requires the check of multiple devices along the 233 tunnel. Certain reason codes can be carried in the Path-Err/ResvErr 234 messages of RSVP-TE, while other data are currently not supported to 235 be transmitted to the path ingress/egress node, such as the 236 authentication failure. Using PAP, the device, which is reponsible 237 for the tunnel set up failure, can send the PAP Notification Message 238 to the Ingress device, and possibly with some reason codes so that 239 the ingress device can not only localize the target device but also 240 the root cause. 242 2. Terminology 244 IGP: Interior Gateway Protocol 246 IS-IS: Intermediate System to Intermediate System 248 OSPF: Open Shortest Path First 250 BGP: Boarder Gateway Protocol 252 BGP-LS: Boarder Gateway Protocol-Link State 254 MPLS: Multi-Protocol Label Switching 256 RSVP-TE: Resource Reservation Protocol-Traffic Engineering 258 LDP: Label Distribution Protocol 260 BMP: BGP Monitoring Protocol 262 LSP: Link State Packet 264 IPFIX: Internet Protocol Flow Information Export 266 PAP: Protocol assisted Protocol 268 UDP: User Datagram Protocol 270 3. PAP Overview 272 PAP is a non-routing protocol used for PAP speakers to exchange 273 routing protocol related information. The primary function of PAP is 274 to provide a unfied tunnel for protocol diagnosing information 275 exchange without augumenting each specific protocol. 277 PAP uses UDP as its transport protocol, which is connectionless. The 278 reason that UDP is selected over TCP is because PAP is intended for 279 on-demand communications. The PAP packet is defined as follows. 280 This document requires the assignment of a User Port registry for the 281 UDP Destination Port. 283 +-------------+-------------+-------------+-------------+-------------+ 284 | ETH. Header | IP Header | UDP Header | PAP Header | PAP Payload | 285 +-------------+-------------+-------------+-------------+-------------+ 287 Figure 1. Encapsulation in UDP 289 This document uses PAP speakers to refer to two routing devices that 290 support PAP and/or communicate with each other using PAP throughout. 291 The communications between two PAP speakders should follow three 292 major processes, i.e., the Capability Negotiation Process, the 293 Request and Reply Process, and the Notification Process. This 294 document defines 5 PAP Message types, i.e., Negotiation Message, 295 Request Message, Reply Message, Notification Message, and ACK 296 Message, which are used in the above PAP processes. 298 Although PAP is connectionless, there still requires a successful 299 Caoability Negotiation between two PAP speakers before the exchange 300 of any PAP messages (except the Negotiation Message). The purpose of 301 the Capability Negotiation process is to inform both PAP speakders of 302 each other's PAP capabilties. The capabilities of a PAP speaker 303 refer to the support of diagnosing information exchange of specific 304 protocols, while the generation of such data are possibly enabled by 305 a local protocol diagnosing system. The negotiation can be initiated 306 by either the local or remote PAP speaker through sending out a PAP 307 Negotiation Message. The Negotiation Message may or may not require 308 an ACK Message, as indicated in the Negotiation Message. A 309 successful negotiation is achieved if both PAP speakers have 310 correctly received the other speakder's Negotiation Message 311 regardless of the message content. A more detailed definition of a 312 successful negotiation is defined in Section 5.1. After a successful 313 negotiation, two PAP speakers can exchange any PAP Message on-demand. 315 The purpose of the Request and Reply process is to acquire 316 information needed by a PAP speaker from other PAP speakers for 317 diagnosing a specific protocol. The Request and Reply Messages can 318 be customized for different protocols. The process starts by any PAP 319 speaker sending a Request Message to another PAP speaker. The PAP 320 receiver, after receiving the Request message, sends out a Reply 321 Message to the request sender. The generation of both Request and 322 Reply Messages is protocol-specific, and depends on possibaly a local 323 protocol diagnosing system. One Request Message received may further 324 results in a new Request Message generated and sent out to a third 325 PAP speaker, if the receiver does not have the answer to the sender. 326 Both Request and Reply Messages may or may not require an ACK 327 Message, as indicated in the Request/Reply Messages. 329 The Notification Process is used to serve active data notification. 330 Any PAP speaker, having information to share with other PAP speakers, 331 may start to send Notification Messages to any target PAP speaker. 332 This information sharing is also protocol-specific, and can be 333 possibly generated by a local protocl diagnosing system. The 334 Notification Message may or may not require an ACK Message, as 335 indicated in the Notification Message. 337 4. PAP Message Format 339 4.1. Common Header 341 The common header is encapsulated in all PAP messages. It includes 342 the following fields. 344 0 15 31 345 +----------------------+---------------------+ 346 | Sequence Number | Length | 347 +-----------+----------+---------------------+ 348 | Msg. Type | 349 +-----------+ 351 Figure 2. PAP Common Header 353 o Sequence Number (2 byte): It is used to indicate the sequence of 354 the PAP Message. It uses unsigned integers to distinguish the PAP 355 Messages sent to the same remote device. The integer is set 356 incrementally in order time. 358 o Length (2 bytes): Length of the message in bytes, including the 359 Common Header and the following Message. 361 o Message Type (1 byte): This indicates the PAP message type.The 362 following types are defined, and listed as follows. 364 * Type = TBD1: Negotiation Message. It is used for two devices 365 to inform each other of the capabilties they support and no 366 longer support. 368 * Type = TBD2: Request Message. 370 * Type = TBD3: Reply Message. 372 * Type = TBD4: Notification Message. 374 * Type = TBD5: ACK Message. It is used to confirm to the local 375 device that the remote device has received a previous sent PAP 376 message, which can be either a Negotiation Message, a Request 377 Message, a Reply Message or an Notification Message. 379 4.2. Negotiation Message 381 The Negotiation Message is used for both capabilty negotiation 382 between the local PAP speaker and the remote PAP speaker. It is also 383 used to indicate the enabling and distabling of any supported 384 capabiliity. The Negotiation Message is required to be exchanged 385 before two PAP speaers can exchange any other PAP Message types. 387 0 15 31 388 +--------------------------------------------+ 389 | Version |A|C| Reserved | 390 +--------------------------------------------+ 391 | Protocol Capability | 392 +--------------------------------------------+ 393 | Optional Capability | 394 +--------------------------------------------+ 396 Figure 3. PAP Negotiation Message 398 o Version (2 bytes): It indicates the PAP version. The current 399 version is 0. 401 o Flags (2 bytes): Two flag bits are currently defined. 403 * The A bit is used to indicate if an ACK Message from the remote 404 PAP speaker is required for each Negotiation Message sent. If 405 an ACK is required, then the A bit SHOULD be set to "1", and 406 "0" otherwise. 408 * The C bit is used to indicate the enabling/disabling of the 409 capabilities that carried in the Protocol Capability field. If 410 the local device wants to inform the remote device of enabling 411 one or more capabilities, the C bit SHOULD be set to "1". If 412 the local device wants to inform the remote device of disabling 413 one or more capabilities, the C bit SHOULD be set to "0". 415 o Protocol Capability (4 bytes): It is 4-byte bit map that indicates 416 the capability of inforamtion exchange regarding various 417 protocols. Each bit represents one protocol. For example, the 418 right most bit of the Protocl Capability represents the capability 419 of exchanging IS-IS protocol related information. The format and 420 definition of information exchanged, regarding each protocol, MUST 421 follow the PAP Message format and definition. 423 o Optional Capability (4 bytes): It is 4-byte bit map that indicates 424 the capability of other inforamtion. It can be used to carry 425 other application-specific information, which allows future 426 extension. Its format and definition remains to be determined. 428 4.3. Request Message 430 The Request Message is used for the local device to request specific 431 data regarding one specific protocol or application from the remote 432 device. It MUST be sent after a successful Capability Negotiation 433 Process (described in Section 5.1), and the requested protocol/ 434 application MUST be supported by both the local and remote devices, 435 as indicated in the Negotiation Messages exchanged between the local 436 and remote devices. 438 The Statistic TLV is defined as follows. 440 0 15 31 441 +----------------------+ 442 |A| Reserved | 443 +----------------------+---------------------+ 444 | Capability | 445 +--------------------------------------------+ 446 | Data Request | 447 +--------------------------------------------+ 449 Figure 4. PAP Request Message 451 o Flags (2 bytes): The A bit is used to indicate if an ACK Message 452 from the remote PAP speaker is required for each Request Message 453 sent. If an ACK is required, then the A bit SHOULD be set to "1", 454 and "0" otherwise. 456 o Capability (4 bytes): It is 4-byte bit map that indicates the 457 specific protocol/application the Request Message is requesting 458 data for. The respective bit of this specific protocol/ 459 application MUST be set to "1", and the rest of the bits MUST be 460 set to "0". 462 o Data Request (Variable): Specifies what data the local device is 463 requesting. The specific format remains to be determined. 465 4.4. Reply Message 467 The Reply Message is used to carry the information that the local 468 device requests from the remote device through the Request Message. 470 0 15 31 471 +----------------------+ 472 |A| Reserved | 473 +----------------------+---------------------+ 474 | Capability | 475 +--------------------------------------------+ 476 | Data Reply | 477 +--------------------------------------------+ 479 Figure 5. PAP Request Message 481 o Flags (2 bytes): The A bit is used to indicate if an ACK Message 482 from the remote PAP speaker is required for each Request Message 483 sent. If an ACK is required, then the A bit SHOULD be set to "1", 484 and "0" otherwise. 486 o Capability (4 bytes): It is 4-byte bit map that indicates the 487 specific protocol/application the Reply Message is replying for. 488 The respective bit of this specific protocol/application MUST be 489 set to "1", and the rest of the bits MUST be set to "0". 491 o Data Reply (Variable): It contains the data that the local device 492 requests from the remote device. The specific format remains to 493 be determined. 495 4.5. Notification Message 497 The Notification Message is used to carry the information that the 498 local device sends to the remote device. 500 0 15 31 501 +----------------------+ 502 |A| Reserved | 503 +----------------------+---------------------+ 504 | Capability | 505 +--------------------------------------------+ 506 | Data Nitification | 507 +--------------------------------------------+ 509 Figure 6. PAP Notification Message 511 o Flags (2 bytes): The A bit is used to indicate if an ACK Message 512 from the remote PAP speaker is required for each Request Message 513 sent. If an ACK is required, then the A bit SHOULD be set to "1", 514 and "0" otherwise. 516 o Capability (4 bytes): It is 4-byte bit map that indicates the 517 specific protocol/application the Notification Message is 518 notifying for. The respective bit of this specific protocol/ 519 application MUST be set to "1", and the rest of the bits MUST be 520 set to "0". 522 o Data Notification (Variable): It contains the data that the local 523 device actively sends to the remote device. The specific format 524 remains to be determined. 526 4.6. ACK Message 528 The ACK Message is used to confirm that the remote device has 529 received a PAP Message that set the A bit to "1". The ACK Message 530 includes only the ACK sequence Number field, which MUST be set to the 531 sequence number carried in the PAP Common Header of the received PAP 532 message, which requires this ACK Message. 534 0 15 31 535 +--------------------------------------------+ 536 | ACK Sequence Number | 537 +--------------------------------------------+ 539 Figure 7. PAP ACK Message 541 5. PAP Operations 543 The PAP operations include the following 3 processes, the Capability 544 Negotiation Process, the Data Request and Reply Process, and the Data 545 Notification Process. 547 5.1. Capability Negotiation Process 549 The Capability Negotiation process refers to the process that two 550 devices inform each other of the capabilties they support and no 551 longer support. A successful negotiation that inform each other of 552 the supported capabilities between two devices MUST be achieved 553 before the exchange of any other PAP Message. 555 The first Negotiation Message can be sent at any time per the local 556 device's configuration. One or more Negotiation Messages can be sent 557 at any time after the first Negotiation Message. Once a Negotiation 558 Message is sent from a local device, an ACK Message from the remote 559 device is required/or not per the indication of the "A" bit in the 560 Negotiation Message. If the A bit is set to "1" (i.e., ACK is 561 required), the local device SHUOLD wait for the ACK Message from the 562 remote device for a certain time period before taking further 563 actions, and if no ACK Message is received within this time frame, 564 the local device SHOULD resend the Negotiation Message to the remote 565 device. The waiting period can be configured locally. This send and 566 wait process CAN be repeated for at most 3 times before receiving a 567 ACK Message from the remote device. If after 3 times of resending 568 the Negotiation Message, still no ACK received, then this negotiation 569 is treated as unsuccessful. If the A bit is set to "0", then the 570 local device does not wait for any ACK Message. If no Negotiation 571 Message is received from the remote device within a time frame, the 572 local device can resend the Negotiation Message. This send and wait 573 process CAN be repeated for at most 3 times before receiving a 574 Negotiation Message from the remote device. If after 3 times of 575 resending the Negotiation Message, still no Negotiation Message 576 received, then this negotiation is treated as Unsuccessful. The 577 waiting period can be configured locally. Once a Negotiation Message 578 is received from the remote device, the negotiation between the two 579 devices is treated as successful regardless from the local device's 580 perspective. 582 On the other hand, the remote device, after receiving the Negotiation 583 Message from the local device, SHOULD send out its own Negotiation 584 Message that indicates the capabilities that it supports. If the A 585 bit of the received Negotiation Message from the local device is set 586 to "1", the remote device SHOULD sent an ACK Message before sending 587 the new Negotiation Message. After the remote device sends out the 588 Negotiation Message back to the local device, it waits/or not for the 589 ACK message, depending on if the A bit of the Negotiation Message 590 sent to the local device is set to "1". If it's set to "1", the 591 remote device waits for the ACK message for a certain time period 592 before taking further actions. If no ACK Message is received within 593 this time frame, the remote device SHOULD resend the Negotiation 594 Message to the local device. The waiting period can be configured 595 locally at the remote device. This send and wait process CAN be 596 repeated for at most 3 times before receiving a ACK Message from the 597 local device. If after 3 times of resending the Negotiation Message, 598 still no ACK received, then the remote device treats this negotiation 599 as unsuccessful, and successful otherwise. If the A bit of the 600 Negotiation Message sent from the remote device is set to "0", then 601 the remote device treats the negotiation as successful after sending 602 out the Negotiation Message. 604 The C bit in the Negotiation Message MUST always be set to "1" before 605 the negotiation is successful. A successful Capability Negotiation 606 means that both the local and remote devices have the information of 607 what capabilties the other side support so that when exchanging any 608 other messages, only the capabilities that are supported by both ends 609 SHOULD be carried in the respective capabilty fields. 611 Another process of the Capability Negotiation Process is to inform 612 the remote device of the capability/capabilities that the local 613 device no longer supports with the indication of C bit set as "0". 615 To inform the other device of the disabled capabiliity/capabilities, 616 the local device MUST have sent one or more Negotiation Messages that 617 indicate the support of such capability/capabilities previously. 619 5.2. Data Request and Reply Process 621 After a successful Capability Negotiation, the local device CAN send 622 the Data Request Message to the remote device per local 623 configuration. An Reply Message SHOULD only be sent after receiving 624 a Request Message. If the A bit of the Request Message is set to "1" 625 (i.e., ACK is required), the local device SHUOLD wait for the ACK 626 Message from the remote device for a certain time period before 627 taking further actions, and if no ACK Message is received within this 628 time frame, the local device SHOULD resend the Request Message to the 629 remote device. The waiting period can be configured locally. This 630 send and wait process CAN be repeated for at most 3 times before 631 receiving a ACK Message from the remote device. If the A bit is set 632 to "0", then the local device does not wait for any ACK Message. If 633 no Reply Message is received from the remote device within a time 634 frame, the local device can resend the Request Message. This send 635 and wait process CAN be repeated for at most 3 times before receiving 636 a Reply Message from the remote device. If after 3 times of 637 resending the Request Message, still no Reply Message received, then 638 no further action is taken. The waiting period can be configured 639 locally. 641 On the other hand, the remote device, after receiving the Request 642 Message from the local device, SHOULD send out the Reply Message to 643 reply the requst. If the A bit of the received Request Message from 644 the local device is set to "1", the remote device SHOULD sent an ACK 645 Message before sending the Reply Message. 647 To request data for multiple protocols/applications, seperate Request 648 Messages SHOULD be sent, with each Request Message requesting one 649 specific protocol/application data. According, the Reply Message is 650 also sent sperately per each Request Message. 652 5.3. Data Notification Process 654 The Notification Message CAN be sent by the local or the remote 655 device at any time once the Capability Negotiation is successful. 656 Each Notification Message SHOULD only indicate one specific protocol/ 657 application. The A bit can be set to "1" or "0" to allow the local/ 658 remote device to know if the other device has received the 659 Notification Message through the ACK Message. 661 6. IANA 663 TBD 665 7. Contributors 667 Jiaqing Zhang, Huawei, zhangjiaqing@huawei.com 669 8. Acknowledgments 671 TBD 673 9. References 675 [I-D.brockners-inband-oam-requirements] 676 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 677 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 678 T., Lapukhov, P., and r. remy@barefootnetworks.com, 679 "Requirements for In-situ OAM", draft-brockners-inband- 680 oam-requirements-03 (work in progress), March 2017. 682 [I-D.ietf-netconf-yang-push] 683 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 684 draft-ietf-netconf-yang-push-25 (work in progress), May 685 2019. 687 [I-D.song-ntf] 688 Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z., 689 Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a 690 Network Telemetry Framework", draft-song-ntf-02 (work in 691 progress), July 2018. 693 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 694 "Simple Network Management Protocol (SNMP)", RFC 1157, 695 DOI 10.17487/RFC1157, May 1990, 696 . 698 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 699 DOI 10.17487/RFC1191, November 1990, 700 . 702 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 703 dual environments", RFC 1195, DOI 10.17487/RFC1195, 704 December 1990, . 706 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 707 for Network Management of TCP/IP-based internets: MIB-II", 708 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 709 . 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, 713 DOI 10.17487/RFC2119, March 1997, 714 . 716 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 717 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 718 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 719 . 721 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 722 Signalling Extensions for the Label Distribution 723 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 724 . 726 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 727 and A. Bierman, Ed., "Network Configuration Protocol 728 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 729 . 731 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 732 S. Ray, "North-Bound Distribution of Link-State and 733 Traffic Engineering (TE) Information Using BGP", RFC 7752, 734 DOI 10.17487/RFC7752, March 2016, 735 . 737 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 738 Monitoring Protocol (BMP)", RFC 7854, 739 DOI 10.17487/RFC7854, June 2016, 740 . 742 Authors' Addresses 744 Zhenbin Li 745 Huawei 746 156 Beiqing Rd 747 Beijing 748 China 750 Email: lizhenbin@huawei.com 751 Lei Li 752 Huawei 753 156 Beiqing Rd 754 Beijing 755 China 757 Email: lily.lilei@huawei.com 759 Yunan Gu 760 Huawei 761 156 Beiqing Rd 762 Beijing 763 China 765 Email: guyunan@huawei.com