idnits 2.17.1 draft-li-rtgwg-protocol-assisted-protocol-02.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 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 (March 04, 2020) is 1507 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 857, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'I-D.song-ntf' is defined on line 869, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 884, but no explicit reference was found in the text == Unused Reference: 'RFC1213' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'RFC3988' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 913, 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: 8 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 Y. Gu 4 Intended status: Standards Track Huawei 5 Expires: September 5, 2020 March 04, 2020 7 Protocol Assisted Protocol (PAP) 8 draft-li-rtgwg-protocol-assisted-protocol-02 10 Abstract 12 For routing protocol troubleshooting, different approaches exibit 13 merits w.r.t. different situations. They can be generally divided 14 into two categories, the distributive way and the centralized way. A 15 very commonly used distributive approach is to log in possiblly all 16 related devices one by one to check massive data via CLI. Such 17 approach provides very detailed device information, however it 18 requires operators with high NOC (Network Operation Center) 19 experience and suffers from low troubleshooting efficiency and high 20 cost. The centralized approach is realized by collecting data from 21 devices via approaches, like the streaming Telemetry or BMP(BGP 22 Monitoring Protocol) RFC7854 [RFC7854], for the centralized server to 23 analyze all gathered data. Such approach allows a comprehensive view 24 fo the whole network and facilitates automated troubleshooting, but 25 is limited by the data collection boundary set by different 26 management domains, as well as high network bandwidth and CPU 27 computation costs. 29 This document proposes a semi-distributive and semi-centralized 30 approach for fast routing protocol troubleshooting, localizing the 31 target device and possibly the root cause, more precisely. It 32 defines a new protocol, called the PAP (Protocol assisted Protocol), 33 for devices to exchange protocol related information between each 34 other in both active and on-demand manners. It allow devices to 35 request specific information from other devices and receive replies 36 to the requested data. It also allows actively transmission of 37 information without request to inform other devices to better react 38 w.r.t. network issues. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on September 5, 2020. 63 Copyright Notice 65 Copyright (c) 2020 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 82 1.2. PAP Usage Use cases . . . . . . . . . . . . . . . . . . . 5 83 1.2.1. Use Case 1: BGP Route Oscillation . . . . . . . . . . 5 84 1.2.2. Use Case 2: RSVP-TE Set Up Failure . . . . . . . . . 6 85 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 3. PAP Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 87 3.1. PAP Encapsulation . . . . . . . . . . . . . . . . . . . . 7 88 3.2. PAP Speaker and PAP Agent . . . . . . . . . . . . . . . . 7 89 3.3. PAP Event . . . . . . . . . . . . . . . . . . . . . . . . 7 90 3.4. Summary of Operation . . . . . . . . . . . . . . . . . . 8 91 3.4.1. PAP Capability Negotiation Process . . . . . . . . . 8 92 3.4.2. PAP Request and Reply Process . . . . . . . . . . . . 8 93 3.4.3. PAP Notification Process . . . . . . . . . . . . . . 9 95 4. PAP Message Format . . . . . . . . . . . . . . . . . . . . . 9 96 4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 9 97 4.1.1. Capability Negotiation Message . . . . . . . . . . . 10 98 4.2. Request Message . . . . . . . . . . . . . . . . . . . . . 11 99 4.3. Reply Message . . . . . . . . . . . . . . . . . . . . . . 12 100 4.4. Notification Message . . . . . . . . . . . . . . . . . . 13 101 4.5. ACK Message . . . . . . . . . . . . . . . . . . . . . . . 14 102 5. PAP Operations . . . . . . . . . . . . . . . . . . . . . . . 14 103 5.1. Capability Negotiation Process . . . . . . . . . . . . . 14 104 5.1.1. PAP Peering Relation Establish Process . . . . . . . 14 105 5.1.2. PAP Capability Enabling Notification Process . . . . 15 106 5.1.3. PAP Capability Disabling Notification Process . . . . 16 107 5.2. PAP Request and Reply Process . . . . . . . . . . . . . . 16 108 5.3. PAP Notification Process . . . . . . . . . . . . . . . . 18 109 6. PAP Error Handling . . . . . . . . . . . . . . . . . . . . . 18 110 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 111 8. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 112 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 113 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 114 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 117 1. Introduction 119 A healthy control plane, providing network connectivity, is the 120 foundation of a well-functioning network. There have been rich 121 routing and signaling protocols designed and used for IP networks, 122 such as IGP (ISIS,OSPF), BGP, LDP, RSVP-TE and so on. The health 123 issues of these protocols, such as neighbor/peer disconnect/set up 124 failure, LSP set up failure, route flapping and so on, have been 125 devoted with ongoing efforts for diagnosing and remediation. 127 1.1. Motivation 129 The distributive protocol troubleshooting approach is typically 130 realized through manual per-device check. It's both time- and labor- 131 consuming, and requires NOC experience of the operators. Amongst 132 all, localizing the target device is usually the most diffcult and 133 time-consuming part. For example, in the case of route loop, 134 operators first log in a random deivce that reports TTL alarms, and 135 then check the looped route in the Forwarding Information Base (FIB) 136 and/or the Routing Information Base (RIB). It requires device by 137 device check, as well as manul data correlation, to pin point to the 138 exact responsible device, since the information retrival and analysis 139 of such distributive way is fragmented. In addition, the low 140 efficiency and manul troubleshooting activities may further impact 141 new network services and/or enlarge affected areas. 143 The centralized network OAM, by collecting network-wide data from 144 devices, enables automatic routing protocol troubleshooting. Date 145 collection protocols, such as SNMP (Simple Network Management 146 Protocol) [RFC1157], NETCONF (Network Configuration Protocol) 147 [RFC6241], and (BMP) [RFC7854], can provide various information 148 retrival, such as network states, routing data, configurations and so 149 on. Such centrazlized way relies on the existence of a centralized 150 server/controller, which is not supported by some legacy networks. 151 What's more, even with the existence of a centralized server/ 152 controller, it can only collect the data within its own management 153 domain, while the cross-domain data are not available due to 154 independent managment of different ISPs. Thus, the lack of such 155 information may lead to troubleshooting failure. In addition, 156 centralized approaches may suffer from high network bandwidth and CPU 157 computation consumptions. 159 Another way of protocol troubleshooting is utilzing the protocol 160 itself to convey diagnosing information. For example, some reason 161 codes are carried in the Path-Err/ResvErr messages of RSVP-TE, so 162 that to other nodes may know the why the tunnel fails to be set up. 163 Such approaches is semi-distributive and semi-centralized. It does 164 not rely on the deployment of a centralized server, but still gets 165 partial global view of the network. However, there still requires 166 non-trivial augementation works to existing routing protocols in 167 order to support troubleshooting. This then raises the question that 168 whether such non-routing data is suitable to be carried in these 169 routing protocols. The extra encapsulation, parsing and analyzing 170 work for the non-routing data would further slow down the network 171 convergence. Thus, it's better to separate the routing and non- 172 routing data transmission as well as data parsing. In addition, 173 coexisting with legacy devices may cause interop issues. Thus, 174 relying on augumenting existing routing protocols without network- 175 wide upgrading may not only fail to provide the truobleshooting 176 benefit, but further affect the operation of the existing routing 177 system. What's more, the failure of routing protocol instance would 178 lead to the failure of diagnosing itself. All in all, it's 179 reasonable to separate the protocol diagnosing data 180 generation/encapsulation/transmission/parsing from the protocol 181 itself. 183 This document proposes a new protocol, called the PAP (Protocol 184 assisted Protocol), for devices to exchange protocol related 185 information between each other. It allows both active and on-demand 186 data exchange. Considering that massiveness of protocol/routing 187 related data, the intuitive of designing PAP is not to exchange the 188 comprehensive protocol/routing status between devices, but to provide 189 very specific information required for fast troubleshooting. The 190 benefits of such a semi-distributive and semi-centralized approach 191 are summarized as follows: 193 1. It facilitates automatic troubleshooting without requiring manul 194 device by device check. 196 2. It allows individual device to have a more global view by 197 requesting data from other devices. 199 3. It does not rely on the deployement of a centralized server/ 200 controller. 202 4. It passes the dtata collection boundary set by different 203 management domains by cross-domain data exchange between devices. 205 5. It relieves the bandwidth pressure of network-wide data 206 collection, and the processing pressure of the centralized 207 server. 209 6. It does not affect the running of existing routing protocols. 211 1.2. PAP Usage Use cases 213 PAP allows both data request/reply and data notification between 214 devices. PAP speakers use the exchanged PAP data to help fast 215 localize the network issues. 217 1.2.1. Use Case 1: BGP Route Oscillation 219 A BGP route oscillation can be caused by various reasons, and usually 220 leaves network-wide impact. In order to find the root cause and take 221 remediation actions, the first step is to localize the oscillation 222 source. In this case, a BGP speaker can send a PAP Request Message 223 to the next hop device of the oscillating route asking " Are you the 224 oscillation source?". If the BGP speaker is the oscillation source, 225 possiblly knows by running a device diagnosing system, replies with a 226 PAP Reply Message saying that "I'm the oscillation source!" to the 227 device who sends the PAP Request Message. If the BGP speaker is not 228 the oscillation source, it further asks the same question with a PAP 229 Request Message to its next hop device of the oscillating route. 230 This request and reply process continues util the request has reached 231 the oscillation source. The source device then sends a PAP Reply 232 Message to tell its upstream device along the PAP request path that " 233 I am the oscillation source!", and then "xx is the oscillation 234 source!" information is further sent back hop by hop to the device 235 who originates the request. 237 1.2.2. Use Case 2: RSVP-TE Set Up Failure 239 The MPLS label switch path set up, either using RSVP-TE or LDP, may 240 fail due to various reasons. Typical troubleshooting procedures are 241 to log in the device, and then check if the failure lies on the 242 configuration, or path computation error, or link failure. 243 Sometimes, it requires the check of multiple devices along the 244 tunnel. Certain reason codes can be carried in the Path-Err/ResvErr 245 messages of RSVP-TE, while other data are currently not supported to 246 be transmitted to the path ingress/egress node, such as the 247 authentication failure. Using PAP, the device, which is reponsible 248 for the tunnel set up failure, can send the PAP Notification Message 249 to the Ingress device, and possibly with some reason codes so that 250 the ingress device can not only localize the target device but also 251 the root cause. 253 2. Terminology 255 IGP: Interior Gateway Protocol 257 IS-IS: Intermediate System to Intermediate System 259 OSPF: Open Shortest Path First 261 BGP: Boarder Gateway Protocol 263 BGP-LS: Boarder Gateway Protocol-Link State 265 MPLS: Multi-Protocol Label Switching 267 RSVP-TE: Resource Reservation Protocol-Traffic Engineering 269 LDP: Label Distribution Protocol 271 BMP: BGP Monitoring Protocol 273 LSP: Link State Packet 275 IPFIX: Internet Protocol Flow Information Export 277 PAP: Protocol assisted Protocol 279 UDP: User Datagram Protocol 281 3. PAP Overview 283 3.1. PAP Encapsulation 285 PAP uses UDP as its transport protocol, which is connectionless. The 286 reason that UDP is selected over TCP is because PAP is intended for 287 on-demand communications. The PAP packet is defined as follows. 288 This document requires the assignment of a User Port registry for the 289 UDP Destination Port. 291 +-------------+-------------+-------------+-------------+-------------+ 292 | ETH. Header | IP Header | UDP Header | PAP Header | PAP Payload | 293 +-------------+-------------+-------------+-------------+-------------+ 295 Figure 1. Encapsulation in UDP 297 3.2. PAP Speaker and PAP Agent 299 This document uses PAP speakers to refer to routing devices that 300 communicate with each other using PAP. PAP speakers SHOULD be 301 implemented with a supporting module (or multiple modules) to 302 receive, parse, analyze, generate, and send PAP messages. For 303 example, a BGP diagnosing module used for BGP related PAP message 304 handling functions as a PAP agent. A PAP Agent is the union of 305 multiple such modules regarding different protocols, or one module 306 for all protocols. Such supporting module is called PAP Agent in 307 this document. PAP Agent, standalone, SHOULD be able to provide 308 protocol troubleshooting capability with local information. Enabling 309 PAP exchange capability, PAP agent gains information from remote PAP 310 speakers to improve diagnosing accuracy . The primary function of PAP 311 is to provide a unfied tunnel for protocol diagnosing information 312 exchange without augumenting each specific protocol. 314 3.3. PAP Event 316 A PAP Event is referred to as the a troubleshooting instance running 317 within a PAP Agent. A PAP Agent may instantiate one or multiple PAP 318 Events for each protocol at the same time depending on the configured 319 troubleshooting triggering condition. For example, an PAP Event is 320 intiated automatically when device CPU is over high, or manually with 321 related command line input from a device operator. Once a PAP Event 322 is generated, corresponding PAP processes are to be called on demand. 323 Notice, the initiation of PAP Capability Negotiation does not require 324 the existance of a PAP Event. 326 3.4. Summary of Operation 328 The communications between two PAP speakders should follow three 329 major processes, i.e., the Capability Negotiation Process, the 330 Request and Reply Process, and the Notification Process. This 331 document defines 5 PAP Message types, i.e., Negotiation Message, 332 Request Message, Reply Message, Notification Message, and ACK 333 Message, which are used in the above PAP processes. 335 3.4.1. PAP Capability Negotiation Process 337 The purpose of the Capability Negotiation process is to inform two 338 PAP speakers of each other's PAP capabilties. The PAP capability 339 indicates, for which specific protocol(s), that PAP supports its/ 340 their diagnosing information exchange. The process can be further 341 divided into three procudures: 1) PAP Peering Relations Establish 342 process, 2) PAP Capability Enabling Notification Process, 3) PAP 343 Capability Disabling Notification Process. The Capability 344 Negotiation Process is realized by the exchange of PAP Capability 345 Negotiation Message, which is defined in Section 4. 347 Although PAP is connectionless, a successful PAP Peering Relations 348 Establish Process is required to be successfully performed before any 349 other PAP process. This process can be initiated by either the local 350 or remote PAP speaker through sending out a PAP Capability 351 Negotiation Message. The Negotiation Message may or may not require 352 an ACK Message, as indicated in the Negotiation Message. A 353 successful Peering is established if both PAP speakers have correctly 354 received the other speaker's Capability Negotiation Message. After a 355 successful negotiation, two PAP speakers can exchange any PAP Message 356 on-demand. The PAP Capability Enabling Notification Process is used 357 to inform the PAP peer its newly supported capability, which can be 358 intiated by the PAP speaker at any moment after a PAP Peering is 359 established with the respective PAP Peer. The PAP Capability 360 Disabling Notification Process is used to inform the PAP peer its 361 newly unsupported capability, which can be intiated by the PAP 362 speaker at any moment after a PAP Peering is established with the 363 respective PAP Peer. 365 3.4.2. PAP Request and Reply Process 367 The purpose of the PAP Request and Reply Process is to acquire 368 information needed by a PAP speaker from other PAP speakers for a 369 specific PAP Event. The Request and Reply Messages can be customized 370 for different events. The process is triggered by the instantiation 371 of a PAP Event, and starts with sending a Request Message to a target 372 PAP peer. The target PAP peer is selected by the PAP agent regarding 373 the current PAP Event, which is out of the scope of this document. 375 The remote PAP speaker, after receiving the Request Message, sends 376 out a Reply Message to the request sender. ACK is required or not as 377 indicated in the Message Flag. 379 One Request Message received at the local PAP speaker from a PAP peer 380 may further results in a new Request Message generation regarding a 381 third PAP speaker, if the local PAP speaker does not have the right 382 Reply to this PAP peer. This local PAP speaker does not send Reply 383 Message to the requesting PAP peer until it receives a new Reply 384 Message from this third PAP speaker. So the whole process In order 385 to avoid Request/Reply loops, a Residua Hop value is used to limit 386 the Request/Reply rounds. 388 3.4.3. PAP Notification Process 390 The Notification Process is used by a PAP speaker voluntarily to 391 notify other PAP speakers of certain information regarding a PAP 392 Event. The process is triggered by the instantiation of a PAP Event, 393 and starts with sending a Notification Message to one or multiple 394 target PAP peer(s). The target PAP peer(s) is/are selected by the 395 PAP agent regarding the current PAP Event, which is out of the scope 396 of this document. The Notification Message may or may not require an 397 ACK Message, as indicated in the Notification Message. 399 4. PAP Message Format 401 4.1. Common Header 403 The common header is encapsulated in all PAP messages. It is defined 404 as follows. 406 0 1 2 3 407 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 408 +---------------+----------------+------------------------------+ 409 |V| Flag | Msg. Type | Length | 410 +---------------+----------------+------------------------------+ 411 + Peer Address (16 bytes) + 412 ~ ~ 413 +--------------------------------+------------------------------+ 414 | Msg. Sequence | 415 +--------------------------------+ 417 Figure 2. PAP Common Header 419 o Flag (1 byte): The V flag indicates that the source IP address is 420 an IPv6 address. For IPv4 address, this is set to 0. 422 o Message Type (1 byte): This indicates the PAP message type.The 423 following types are defined, and listed as follows. 425 * Type = TBD1: Capability Negotiation Message. It is used for 426 two devices to inform each other of the capabilties they 427 support and no longer support. 429 * Type = TBD2: Request Message. 431 * Type = TBD3: Reply Message. 433 * Type = TBD4: Notification Message. 435 * Type = TBD5: ACK Message. It is used to confirm to the local 436 device that the remote device has received a previous sent PAP 437 message, which can be either a Negotiation Message, a Request 438 Message, a Reply Message or an Notification Message. 440 o Length (2 bytes): Length of the message in bytes, including the 441 Common Header and the following Message. 443 o Souece IP Address (16 bytes): It indicates the IP address who 444 initiates the PAP message. It is 4 bytes long if an IPv4 address 445 is carried in this field (with the 12 most significant bytes zero- 446 filled) and 16 bytes long if an IPv6 address is carried in this 447 field. 449 o Message Sequence (2 bytes): It indicates the sequence number of 450 each PAP message. 452 4.1.1. Capability Negotiation Message 454 The Negotiation Message is used in the PAP Capability Negotiation 455 Process. It is defined as follows. 457 0 1 2 3 458 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 459 +--------------------------------+------------------------------+ 460 | Version |A|E| Flag | 461 +--------------------------------+------------------------------+ 462 | Protocol Capacity | 463 +---------------------------------------------------------------+ 465 Figure 3. PAP Negotiation Message 467 o Version (1 byte): It indicates the PAP version. The current 468 version is 0. 470 o Flags (1 bytes): Two flag bits are currently defined. 472 * The A bit is used to indicate if an ACK Message from the remote 473 PAP speaker is required for each Negotiation Message sent. If 474 an ACK is required, then the A bit SHOULD be set to "1", and 475 "0" otherwise. 477 * The E bit is used to indicate the enabling/disabling of the 478 capabilities that carried in the Protocol Capability field. If 479 the local device wants to inform the remote device of enabling 480 one or more capabilities, the E bit SHOULD be set to "1". If 481 the local device wants to inform the remote device of disabling 482 one or more capabilities, the E bit SHOULD be set to "0". 484 o Protocol Capability (4 bytes): It is 4-byte bitmap that indicates 485 the capability of inforamtion exchange regarding various 486 protocols. Each bit represents one protocol. The following 487 protocol capability is defined (from the rightmost bit). 489 * Bit 0: ISIS 491 * Bit 1: OSPF 493 * Bit 2: BGP 495 * Bit 3: LDP 497 4.2. Request Message 499 The Request Message is used for the local device to request specific 500 data regarding one specific protocol or application from the remote 501 device. It MUST be sent after a successful Capability Negotiation 502 Process (described in Section 5.1), and the requested protocol/ 503 application MUST be supported by both the local and remote devices, 504 as indicated in the Negotiation Messages exchanged between the local 505 and remote devices. It is defined as follows. 507 0 1 2 3 508 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 509 +---------------+----------------+------------------------------+ 510 |A| Flag | Prot. Capb. | Event ID | 511 +--------------------------------+------------------------------+ 512 | Res. Hop | 513 +---------------+-----------------------------------------------+ 514 + Request Data + 515 ~ ~ 516 +---------------------------------------------------------------+ 518 Figure 4. PAP Request Message 520 o Flags (1 byte): It is currently reserved. The A bit is used to 521 indicate if an ACK Message from the remote PAP speaker is required 522 for each Request Message sent. If an ACK is required, then the A 523 bit SHOULD be set to "1", and "0" otherwise. 525 o Capability (1 byte): It represents the bit index of the protocol, 526 which the Request Message is requesting data for. 528 o Event ID (2 bytes): It indicates the event number that this 529 Request message is regarding. 531 o Residua hop (1 byte): it indicates the residua Request hops of the 532 current PAP Event. It is reduced by 1 at each PAP speaker when 533 generating a further PAP Request to a third PAP speaker. 535 o Request Data (Variable): Specifies information of the data that 536 the local device is requesting. The specific format remains to be 537 determined per each protocol, as well as each use case. 539 4.3. Reply Message 541 The Reply Message is used to carry the information that the local 542 device requests from the remote device through the Request Message. 543 It is defined as follows. 545 0 1 2 3 546 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 547 +---------------+----------------+------------------------------+ 548 |A| Flag | Prot. Capb. | Event ID | 549 +---------------+----------------+------------------------------+ 550 + Reply Data + 551 ~ ~ 552 +---------------------------------------------------------------+ 554 Figure 5. PAP Reply Message 556 o Flags (1 byte): It is currently reserved. The A bit is used to 557 indicate if an ACK Message from the remote PAP speaker is required 558 for each Reply Message sent. If an ACK is required, then the A 559 bit SHOULD be set to "1", and "0" otherwise. 561 o Capability (1 byte): It represents the bit index of the protocol, 562 which the Reply Message is replying data for. 564 o Event ID (2 bytes): It indicates the event number that this Reply 565 message is regarding. 567 o Reply Data (Variable): Specifies information of the data that the 568 local device is replying. The specific format remains to be 569 determined per each protocol, as well as each use case. 571 4.4. Notification Message 573 The Notification Message is used to carry the information that the 574 local device sends to the remote device. 576 0 1 2 3 577 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 578 +---------------+----------------+------------------------------+ 579 |A| Flag | Prot. Capb. | Event ID | 580 +---------------+----------------+------------------------------+ 581 + Notification Data + 582 ~ ~ 583 +---------------------------------------------------------------+ 585 Figure 6. PAP Notification Message 587 o Flags (1 byte): It is currently reserved. The A bit is used to 588 indicate if an ACK Message from the remote PAP speaker is required 589 for each Notification Message sent. If an ACK is required, then 590 the A bit SHOULD be set to "1", and "0" otherwise. 592 o Capability (1 byte): It represents the bit index of the protocol, 593 which the Notification Message is notifying for. 595 o Event ID (2 bytes): It indicates the event number that this 596 Notification Message is regarding. 598 o Notification Data (Variable): Specifies information of the data 599 that the local device is notifying. The specific format remains 600 to be determined per each protocol, as well as each use case. 602 4.5. ACK Message 604 The ACK Message is used to confirm that the remote device has 605 received a PAP Message with the A bit set to "1". The ACK Message 606 includes only the PAP Common Header. The Msg. Sequence MUST be set 607 to the sequence number carried in the received PAP message, which 608 requires this ACK. 610 5. PAP Operations 612 The PAP operations include the following 3 major processes, the 613 Capability Negotiation Process, the Data Request and Reply Process, 614 and the Data Notification Process. 616 5.1. Capability Negotiation Process 618 5.1.1. PAP Peering Relation Establish Process 620 A successful PAP Peering relation MUST be Established between two PAP 621 speakers before any other PAP process. 623 As the first step, a Capability Negotiation Message can be initiated 624 at any time by a PAP speaker,as long as the target PAP peer is IP 625 reachable. It usually companies the establishment of neighboring/ 626 peering relation between two routing devices. The "A" bit in the 627 Negotiation Message MUST be set as 1 during the PAP Peering Establish 628 Process, meaning ACK required. The "E" in the Negotiation Message 629 MUST be set to 1 during this process, meaning the capabilities 630 indicated in the Protocol Capability field are enabled by default. 631 The Protocol Capability field SHOULD indicate all the protocol 632 capabilities that are supported by the local PAP Agent and currently 633 enabled. After the first Negotiation Message is sent, the local 634 device SHUOLD wait for the ACK Message from the remote device for a 635 certain time period before taking further actions, and if no ACK 636 Message is received within this time frame, the local device SHOULD 637 resend the Negotiation Message to the remote device. The waiting 638 period can be configured locally. This send and wait process CAN be 639 repeated for at most 3 times before receiving a ACK Message from the 640 remote device. If after 3 times of resending the Negotiation 641 Message, still no ACK received, then this peering establishment is 642 treated as unsuccessful. 644 The next step for the local PAP speaker is to wait for the 645 Negotiation Message from the remote PAP speaker. If no Negotiation 646 Message is received from the remote PAP speaker within a time frame 647 after its own Negotiation Message is sent , the local PAP speaker CAN 648 resend the Negotiation Message. This time frame is also configured 649 locally. This send and wait process CAN be repeated for at most 3 650 times before receiving a Negotiation Message from the remote PAP 651 speaker. If after 3 times of resending the Negotiation Message, 652 still no Negotiation Message received, then this negotiation is 653 treated as unsuccessful. If a Negotiation Message is received and 654 parsed correctly, an ACK MUST be sent to the remote PAP speaker. 656 Once an ACK Message and a Negotiation Message are received from the 657 remote PAP speaker and correctly parsed, a PAP Peering relation is 658 considered as successfully established. The local PAP speaker 659 maintains locally the protocol capabilities of the remote PAP 660 speaker, and uses them during other PAP processes. 662 5.1.2. PAP Capability Enabling Notification Process 664 Once the PAP Peering relation is set up between two PAP speakers, 665 they become PAP peers. Thereafter, any PAP speaker supports a new 666 protocol capability, it SHOULD call the Capability Enabling 667 Notification Process to inform all its PAP peers. 669 When the local PAP speaker initates a PAP Capability Enabling 670 Notification Process: The "A" bit in the Negotiation Message MUST be 671 set as 1 during the PAP Capability Enabling Notification Process, 672 meaning ACK required. The "E" in the Negotiation Message MUST be set 673 to 1 during this process, meaning the capabilities indicated in the 674 Protocol Capability field are enabled. The Protocol Capability field 675 SHOULD indicate all the protocol capabilities that are supported by 676 the local PAP Agent and currently enabled. After the Negotiation 677 Message is sent, the local PAP speaker SHUOLD wait for the ACK 678 Message from the PAP peer for a certain time period before taking 679 further actions, and if no ACK Message is received within this time 680 frame, the local device SHOULD resend the Negotiation Message to the 681 remote device. The waiting period can be configured locally. This 682 send and wait process CAN be repeated for at most 3 times before 683 receiving a ACK Message from the remote device. If after 3 times of 684 resending the Negotiation Message, still no ACK received, then this 685 Capability Enabling Notification Process is treated as unsuccessful. 686 This process MAY be intiated at another time thereafter. If a ACK is 687 received, the Capability Enabling Notification Process is considered 688 successful. 690 When a PAP peer initates a PAP Capability Enabling Notification 691 Process: The local PAP speaker, after receiving the PAP Negotiation 692 Message and correctly parsing it, sends out an ACK. This Capability 693 Enabling Notification Process is considered successful. The local 694 PAP speaker updates the capability status maintained accordingly. 696 5.1.3. PAP Capability Disabling Notification Process 698 Whenever a PAP speaker disables a PAP capability, it SHOULD initiate 699 a PAP Capability Disabling Notification Process to inform all its PAP 700 peers. 702 When the local PAP speaker initates a PAP Capability Disabling 703 Notification Process: The "A" bit in the Negotiation Message MUST be 704 set as 1 during the PAP Capability Disabling Notification Process, 705 meaning ACK required. The "E" in the Negotiation Message MUST be set 706 to 0 during this process, meaning the capabilities indicated in the 707 Protocol Capability field are disabled. The Protocol Capability 708 field SHOULD indicate all the protocol capability that is disabled. 709 After the Negotiation Message is sent, the local PAP speaker SHUOLD 710 wait for the ACK Message from the PAP peer for a certain time period 711 before taking further actions, and if no ACK Message is received 712 within this time frame, the local device SHOULD resend the 713 Negotiation Message to the remote device. The waiting period can be 714 configured locally. This send and wait process CAN be repeated for 715 at most 3 times before receiving a ACK Message from the remote 716 device. If after 3 times of resending the Negotiation Message, still 717 no ACK received, then this Capability Disabling Notification Process 718 is treated as unsuccessful. This process MAY be intiated at another 719 time thereafter. 721 When a PAP peer initates a PAP Capability Disabling Notification 722 Process: The local PAP speaker, after receiving the PAP Negotiation 723 Message and correctly parsing it, sends out an ACK. This Capability 724 Disabling Notification Process is considered successful. The local 725 PAP speaker updates the capability status maintained accordingly. 727 5.2. PAP Request and Reply Process 729 When a local PAP Event triggers a PAP Request and Reply Process, the 730 local PAP speaker initates a Request Message, and send to a target 731 PAP peer as indicated by PAP Agent per this PAP Event. This local 732 PAP speaker is called the Request and Reply Process Starter. It sets 733 the Residua Hop as the maximum number of Request/Reply rounds (e.g., 734 10) it will wait in order to receive the final Reply. The Event ID 735 and the Request are set by the local PAP Agent. The A bit of the 736 Request Message MUST be set to "1" (i.e., ACK is required). The 737 local device waits for the ACK Message from the remote device for a 738 certain time period before taking further actions, and if no ACK 739 Message is received within this time frame, the local device SHOULD 740 resend the Request Message to the remote device. The waiting period 741 can be configured locally. This send and wait process CAN be 742 repeated for at most 3 times before receiving a ACK Message from the 743 remote device. If after 3 times of resending the Request Message, 744 still no ACK received, then this Request and Reply Process is treated 745 as unsuccessful. If ACK received, the local device waits for the 746 Reply Message. If no Reply Message is received from the remote 747 device within a time frame, the local device can resend the Request 748 Message. This send and wait process CAN be repeated for at most 3 749 times before receiving a Reply Message from the remote device. If 750 after 3 times of resending the Request Message, still no Reply 751 Message received, then this Request and Reply Process is treated as 752 unsuccessful. The waiting period can be configured locally, and 753 SHOULD take into consideration of the Residua Hop value. If the 754 Request and Reply Process Starter receives the Reply Message within 755 the time frame, and the Event ID is matched to the local PAP Event, 756 the PAP Request and Reply Process is considered as successful. 758 When a local PAP speaker receives a Request Message from its PAP peer 759 (i.e., it is not the Pequest and Reply Process Starter), it sends 760 back an ACK Message. With the received Request Message, a new PAP 761 event it instantiated at the local PAP Agent. The PAP event triggers 762 the troubleshooting analysis of the received Request Message, and 763 then generate the Reply Message if the Reply condition is met, or 764 generate a new Request Message when the Reply condition is not met. 765 The Reply condition and the troubleshooting analysis of the PAP Agent 766 is out of the scope of this document. 768 If the Reply condition is met, the local PAP speaker is called the 769 Request and Reply Process Terminator. It generates the Reply Message 770 and send the message back to the requesting PAP peer. The Event ID 771 is set to be the same as the Event ID of the received Request 772 Message. The Reply Data is set by the local PAP Agent per this 773 generated event. The A bit of the Reply Message MUST be set to "1" 774 (i.e., ACK is required). The local device waits for the ACK Message 775 from the remote device for a certain time period before taking 776 further actions, and if no ACK Message is received within this time 777 frame, the local device SHOULD resend the Reply Message to the remote 778 device. The waiting period can be configured locally. This send and 779 wait process CAN be repeated for at most 3 times before receiving a 780 ACK Message from the remote device. If after 3 times of resending 781 the Request Message, still no ACK received, then this Request and 782 Reply Process is treated as unsuccessful. 784 If the Reply condition is not met, the local PAP speaker is called 785 the Request and Reply Process mid-handler. It generates a new 786 Request Message and send the message to a third PAP speaker per 787 indicated by the local PAP Agent per this generated event. In the 788 new generated Request Message, the Residua Hop value by MUST be 789 reduced by 1. The A bit of the Request Message MUST be set to "1" 790 (i.e., ACK is required). The local device waits for the ACK Message 791 from the remote device for a certain time period before taking 792 further actions, and if no ACK Message is received within this time 793 frame, the local device SHOULD resend the Request Message to the 794 remote device. The waiting period can be configured locally. This 795 send and wait process CAN be repeated for at most 3 times before 796 receiving a ACK Message from the remote device. If after 3 times of 797 resending the Request Message, still no ACK received, then this 798 Request and Reply Process is treated as unsuccessful. If ACK 799 received, the local device waits for the Reply Message. If no Reply 800 Message is received from the remote device within a time frame, the 801 local device can resend the Request Message. This send and wait 802 process CAN be repeated for at most 3 times before receiving a Reply 803 Message from the remote device. If after 3 times of resending the 804 Request Message, still no Reply Message received, then this Request 805 and Reply Process is treated as unsuccessful. The waiting period can 806 be configured locally, and SHOULD take into consideration of the 807 Residua Hop value. If the local device receives the Reply Message 808 within the time frame, it generates a new Reply Message and sends 809 back to it requesting PAP peer. The Event ID of the new Reply 810 Message is set to be the same as the Event ID of the received Request 811 Message. 813 5.3. PAP Notification Process 815 When a local PAP Event triggers a PAP Notification Process, the local 816 PAP speaker initates a Notification Message. The target PAP peer(s) 817 is/are selected by the PAP agent regarding the current PAP Event, 818 which is out of the scope of this document. The Notification Message 819 may or may not require an ACK Message, as indicated in the 820 Notification Message. If the A bit is set to 1 (meaning ACK 821 required), the local device waits for the ACK Message from the remote 822 device for a certain time period before taking further actions, and 823 if no ACK Message is received within this time frame, the local 824 device SHOULD resend the Notification Message to the remote device. 825 The waiting period can be configured locally. This send and wait 826 process CAN be repeated for at most 3 times before receiving a ACK 827 Message from the remote device. If after 3 times of resending the 828 Request Message, still no ACK received, then this Request and Reply 829 Process is treated as unsuccessful. The waiting period can be 830 configured locally. If ACK is received within the time frame, the 831 Notification Process is considered to be successful. If the A bit is 832 set to 0 (meaning no ACK required), after sending the Notification 833 Message, the Notification Process is considered successful. 835 6. PAP Error Handling 837 When any PAP process is unsuccessful, information is recorded or not 838 by local PAP Agent. No further action is taken. 840 7. Security Considerations 842 TBD 844 8. IANA 846 TBD 848 9. Contributors 850 We thank Jiaqing Zhang (Huawei), Tao Du (Huawei) and Lei Li (Huawei) 851 for their contributions. 853 10. Acknowledgments 855 11. References 857 [I-D.brockners-inband-oam-requirements] 858 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 859 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 860 T., Lapukhov, P., and r. remy@barefootnetworks.com, 861 "Requirements for In-situ OAM", draft-brockners-inband- 862 oam-requirements-03 (work in progress), March 2017. 864 [I-D.ietf-netconf-yang-push] 865 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 866 draft-ietf-netconf-yang-push-25 (work in progress), May 867 2019. 869 [I-D.song-ntf] 870 Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z., 871 Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a 872 Network Telemetry Framework", draft-song-ntf-02 (work in 873 progress), July 2018. 875 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 876 "Simple Network Management Protocol (SNMP)", RFC 1157, 877 DOI 10.17487/RFC1157, May 1990, 878 . 880 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 881 DOI 10.17487/RFC1191, November 1990, 882 . 884 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 885 dual environments", RFC 1195, DOI 10.17487/RFC1195, 886 December 1990, . 888 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 889 for Network Management of TCP/IP-based internets: MIB-II", 890 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 891 . 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, 895 DOI 10.17487/RFC2119, March 1997, 896 . 898 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 899 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 900 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 901 . 903 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 904 Signalling Extensions for the Label Distribution 905 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 906 . 908 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 909 and A. Bierman, Ed., "Network Configuration Protocol 910 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 911 . 913 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 914 S. Ray, "North-Bound Distribution of Link-State and 915 Traffic Engineering (TE) Information Using BGP", RFC 7752, 916 DOI 10.17487/RFC7752, March 2016, 917 . 919 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 920 Monitoring Protocol (BMP)", RFC 7854, 921 DOI 10.17487/RFC7854, June 2016, 922 . 924 Authors' Addresses 926 Zhenbin Li 927 Huawei 928 156 Beiqing Rd 929 Beijing 930 China 932 Email: lizhenbin@huawei.com 933 Yunan Gu 934 Huawei 935 156 Beiqing Rd 936 Beijing 937 China 939 Email: guyunan@huawei.com