idnits 2.17.1 draft-li-rtgwg-protocol-assisted-protocol-04.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 (February 19, 2021) is 1160 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 913, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 930, but no explicit reference was found in the text == Unused Reference: 'I-D.song-ntf' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'RFC1213' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'RFC3988' is defined on line 969, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 979, 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 S. Chen 4 Intended status: Standards Track Huawei 5 Expires: August 23, 2021 Y. Qu 6 Futurewei 7 Y. Gu 8 Huawei 9 February 19, 2021 11 Protocol Assisted Protocol (PASP) 12 draft-li-rtgwg-protocol-assisted-protocol-04 14 Abstract 16 For routing protocol troubleshooting, different approaches exibit 17 merits w.r.t. different situations. They can be generally divided 18 into two categories, the distributive way and the centralized way. A 19 very commonly used distributive approach is to log in possiblly all 20 related devices one by one to check massive data via CLI. Such 21 approach provides very detailed device information, however it 22 requires operators with high NOC (Network Operation Center) 23 experience and suffers from low troubleshooting efficiency and high 24 cost. The centralized approach is realized by collecting data from 25 devices via approaches, like the streaming Telemetry or BMP(BGP 26 Monitoring Protocol) RFC7854 [RFC7854], for the centralized server to 27 analyze all gathered data. Such approach allows a comprehensive view 28 fo the whole network and facilitates automated troubleshooting, but 29 is limited by the data collection boundary set by different 30 management domains, as well as high network bandwidth and CPU 31 computation costs. 33 This document proposes a semi-distributive and semi-centralized 34 approach for fast routing protocol troubleshooting, localizing the 35 target device and possibly the root cause, more precisely. It 36 defines a new protocol, called the PASP (Protocol assisted Protocol), 37 for devices to exchange protocol related information between each 38 other in both active and on-demand manners. It allow devices to 39 request specific information from other devices and receive replies 40 to the requested data. It also allows actively transmission of 41 information without request to inform other devices to better react 42 w.r.t. network issues. 44 Requirements Language 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [RFC2119]. 50 Status of This Memo 52 This Internet-Draft is submitted in full conformance with the 53 provisions of BCP 78 and BCP 79. 55 Internet-Drafts are working documents of the Internet Engineering 56 Task Force (IETF). Note that other groups may also distribute 57 working documents as Internet-Drafts. The list of current Internet- 58 Drafts is at https://datatracker.ietf.org/drafts/current/. 60 Internet-Drafts are draft documents valid for a maximum of six months 61 and may be updated, replaced, or obsoleted by other documents at any 62 time. It is inappropriate to use Internet-Drafts as reference 63 material or to cite them other than as "work in progress." 65 This Internet-Draft will expire on August 23, 2021. 67 Copyright Notice 69 Copyright (c) 2021 IETF Trust and the persons identified as the 70 document authors. All rights reserved. 72 This document is subject to BCP 78 and the IETF Trust's Legal 73 Provisions Relating to IETF Documents 74 (https://trustee.ietf.org/license-info) in effect on the date of 75 publication of this document. Please review these documents 76 carefully, as they describe your rights and restrictions with respect 77 to this document. Code Components extracted from this document must 78 include Simplified BSD License text as described in Section 4.e of 79 the Trust Legal Provisions and are provided without warranty as 80 described in the Simplified BSD License. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 85 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.2. PASP Usage Use cases . . . . . . . . . . . . . . . . . . 5 87 1.2.1. Use Case 1: BGP Route Oscillation . . . . . . . . . . 5 88 1.2.2. Use Case 2: RSVP-TE Set Up Failure . . . . . . . . . 6 89 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 90 3. PASP Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 91 3.1. PASP Encapsulation . . . . . . . . . . . . . . . . . . . 7 92 3.2. PASP Speaker and PASP Agent . . . . . . . . . . . . . . . 7 93 3.3. PASP Event . . . . . . . . . . . . . . . . . . . . . . . 7 94 3.4. Summary of Operation . . . . . . . . . . . . . . . . . . 8 95 3.4.1. PASP Capability Negotiation Process . . . . . . . . . 8 96 3.4.2. PASP Request and Reply Process . . . . . . . . . . . 8 97 3.4.3. PASP Notification Process . . . . . . . . . . . . . . 9 99 4. PASP Message Format . . . . . . . . . . . . . . . . . . . . . 9 100 4.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 9 101 4.1.1. Capability Negotiation Message . . . . . . . . . . . 10 102 4.2. Request Message . . . . . . . . . . . . . . . . . . . . . 11 103 4.3. Reply Message . . . . . . . . . . . . . . . . . . . . . . 12 104 4.4. Notification Message . . . . . . . . . . . . . . . . . . 13 105 4.5. ACK Message . . . . . . . . . . . . . . . . . . . . . . . 14 106 5. PASP Operations . . . . . . . . . . . . . . . . . . . . . . . 14 107 5.1. Capability Negotiation Process . . . . . . . . . . . . . 14 108 5.1.1. PASP Peering Relation Establish Process . . . . . . . 14 109 5.1.2. PASP Capability Enabling Notification Process . . . . 15 110 5.1.3. PASP Capability Disabling Notification Process . . . 16 111 5.2. PASP Request and Reply Process . . . . . . . . . . . . . 16 112 5.3. PASP Notification Process . . . . . . . . . . . . . . . . 18 113 6. PASP Error Handling . . . . . . . . . . . . . . . . . . . . . 19 114 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 19 115 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 116 9. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 117 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 118 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 119 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 122 1. Introduction 124 A healthy control plane, providing network connectivity, is the 125 foundation of a well-functioning network. There have been rich 126 routing and signaling protocols designed and used for IP networks, 127 such as IGP (ISIS,OSPF), BGP, LDP, RSVP-TE and so on. The health 128 issues of these protocols, such as neighbor/peer disconnect/set up 129 failure, LSP set up failure, route flapping and so on, have been 130 devoted with ongoing efforts for diagnosing and remediation. 132 1.1. Motivation 134 The distributive protocol troubleshooting approach is typically 135 realized through manual per-device check. It's both time- and labor- 136 consuming, and requires NOC experience of the operators. Amongst 137 all, localizing the target device is usually the most diffcult and 138 time-consuming part. For example, in the case of route loop, 139 operators first log in a random deivce that reports TTL alarms, and 140 then check the looped route in the Forwarding Information Base (FIB) 141 and/or the Routing Information Base (RIB). It requires device by 142 device check, as well as manul data correlation, to pin point to the 143 exact responsible device, since the information retrival and analysis 144 of such distributive way is fragmented. In addition, the low 145 efficiency and manul troubleshooting activities may further impact 146 new network services and/or enlarge affected areas. 148 The centralized network OAM, by collecting network-wide data from 149 devices, enables automatic routing protocol troubleshooting. Date 150 collection protocols, such as SNMP (Simple Network Management 151 Protocol) [RFC1157], NETCONF (Network Configuration Protocol) 152 [RFC6241], and (BMP) [RFC7854], can provide various information 153 retrival, such as network states, routing data, configurations and so 154 on. Such centrazlized way relies on the existence of a centralized 155 server/controller, which is not supported by some legacy networks. 156 What's more, even with the existence of a centralized server/ 157 controller, it can only collect the data within its own management 158 domain, while the cross-domain data are not available due to 159 independent managment of different ISPs. Thus, the lack of such 160 information may lead to troubleshooting failure. In addition, 161 centralized approaches may suffer from high network bandwidth and CPU 162 computation consumptions. 164 Another way of protocol troubleshooting is utilzing the protocol 165 itself to convey diagnosing information. For example, some reason 166 codes are carried in the Path-Err/ResvErr messages of RSVP-TE, so 167 that to other nodes may know the why the tunnel fails to be set up. 168 Such approaches is semi-distributive and semi-centralized. It does 169 not rely on the deployment of a centralized server, but still gets 170 partial global view of the network. However, there still requires 171 non-trivial augementation works to existing routing protocols in 172 order to support troubleshooting. This then raises the question that 173 whether such non-routing data is suitable to be carried in these 174 routing protocols. The extra encapsulation, parsing and analyzing 175 work for the non-routing data would further slow down the network 176 convergence. Thus, it's better to separate the routing and non- 177 routing data transmission as well as data parsing. In addition, 178 coexisting with legacy devices may cause interop issues. Thus, 179 relying on augumenting existing routing protocols without network- 180 wide upgrading may not only fail to provide the truobleshooting 181 benefit, but further affect the operation of the existing routing 182 system. What's more, the failure of routing protocol instance would 183 lead to the failure of diagnosing itself. All in all, it's 184 reasonable to separate the protocol diagnosing data 185 generation/encapsulation/transmission/parsing from the protocol 186 itself. 188 This document proposes a new protocol, called the PASP (Protocol 189 assisted Protocol), for devices to exchange protocol related 190 information between each other. It allows both active and on-demand 191 data exchange. Considering that massiveness of protocol/routing 192 related data, the intuitive of designing PASP is not to exchange the 193 comprehensive protocol/routing status between devices, but to provide 194 very specific information required for fast troubleshooting. The 195 benefits of such a semi-distributive and semi-centralized approach 196 are summarized as follows: 198 1. It facilitates automatic troubleshooting without requiring manul 199 device by device check. 201 2. It allows individual device to have a more global view by 202 requesting data from other devices. 204 3. It does not rely on the deployement of a centralized server/ 205 controller. 207 4. It passes the dtata collection boundary set by different 208 management domains by cross-domain data exchange between devices. 210 5. It relieves the bandwidth pressure of network-wide data 211 collection, and the processing pressure of the centralized 212 server. 214 6. It does not affect the running of existing routing protocols. 216 1.2. PASP Usage Use cases 218 PASP allows both data request/reply and data notification between 219 devices. PASP speakers use the exchanged PASP data to help fast 220 localize the network issues. 222 1.2.1. Use Case 1: BGP Route Oscillation 224 A BGP route oscillation can be caused by various reasons, and usually 225 leaves network-wide impact. In order to find the root cause and take 226 remediation actions, the first step is to localize the oscillation 227 source. In this case, a BGP speaker can send a PASP Request Message 228 to the next hop device of the oscillating route asking " Are you the 229 oscillation source?". If the BGP speaker is the oscillation source, 230 possiblly knows by running a device diagnosing system, replies with a 231 PASP Reply Message saying that "I'm the oscillation source!" to the 232 device who sends the PASP Request Message. If the BGP speaker is not 233 the oscillation source, it further asks the same question with a PASP 234 Request Message to its next hop device of the oscillating route. 235 This request and reply process continues util the request has reached 236 the oscillation source. The source device then sends a PASP Reply 237 Message to tell its upstream device along the PASP request path that 238 " I am the oscillation source!", and then "xx is the oscillation 239 source!" information is further sent back hop by hop to the device 240 who originates the request. 242 1.2.2. Use Case 2: RSVP-TE Set Up Failure 244 The MPLS label switch path set up, either using RSVP-TE or LDP, may 245 fail due to various reasons. Typical troubleshooting procedures are 246 to log in the device, and then check if the failure lies on the 247 configuration, or path computation error, or link failure. 248 Sometimes, it requires the check of multiple devices along the 249 tunnel. Certain reason codes can be carried in the Path-Err/ResvErr 250 messages of RSVP-TE, while other data are currently not supported to 251 be transmitted to the path ingress/egress node, such as the 252 authentication failure. Using PASP, the device, which is reponsible 253 for the tunnel set up failure, can send the PASP Notification Message 254 to the Ingress device, and possibly with some reason codes so that 255 the ingress device can not only localize the target device but also 256 the root cause. 258 2. Terminology 260 IGP: Interior Gateway Protocol 262 IS-IS: Intermediate System to Intermediate System 264 OSPF: Open Shortest Path First 266 BGP: Boarder Gateway Protocol 268 BGP-LS: Boarder Gateway Protocol-Link State 270 MPLS: Multi-Protocol Label Switching 272 RSVP-TE: Resource Reservation Protocol-Traffic Engineering 274 LDP: Label Distribution Protocol 276 BMP: BGP Monitoring Protocol 278 LSP: Link State Packet 280 IPFIX: Internet Protocol Flow Information Export 282 PASP: Protocol assisted Protocol 284 UDP: User Datagram Protocol 286 3. PASP Overview 288 3.1. PASP Encapsulation 290 PASP uses UDP as its transport protocol, which is connectionless. 291 The reason that UDP is selected over TCP is because PASP is intended 292 for on-demand communications. The PASP packet is defined as follows. 293 This document requires the assignment of a User Port registry for the 294 UDP Destination Port. 296 +-------------+-------------+-------------+-------------+-------------+ 297 | ETH. Header | IP Header | UDP Header | PASP Header| PASP Payload| 298 +-------------+-------------+-------------+-------------+-------------+ 300 Figure 1. Encapsulation in UDP 302 3.2. PASP Speaker and PASP Agent 304 This document uses PASP speakers to refer to routing devices that 305 communicate with each other using PASP. PASP speakers SHOULD be 306 implemented with a supporting module (or multiple modules) to 307 receive, parse, analyze, generate, and send PASP messages. For 308 example, a BGP diagnosing module used for BGP related PASP message 309 handling functions as a PASP agent. A PASP Agent is the union of 310 multiple such modules regarding different protocols, or one module 311 for all protocols. Such supporting module is called PASP Agent in 312 this document. PASP Agent, standalone, SHOULD be able to provide 313 protocol troubleshooting capability with local information. Enabling 314 PASP exchange capability, PASP agent gains information from remote 315 PASP speakers to improve diagnosing accuracy . The primary function 316 of PASP is to provide a unfied tunnel for protocol diagnosing 317 information exchange without augumenting each specific protocol. 319 3.3. PASP Event 321 A PASP Event is referred to as the a troubleshooting instance running 322 within a PASP Agent. A PASP Agent may instantiate one or multiple 323 PASP Events for each protocol at the same time depending on the 324 configured troubleshooting triggering condition. For example, an 325 PASP Event is intiated automatically when device CPU is over high, or 326 manually with related command line input from a device operator. 327 Once a PASP Event is generated, corresponding PASP processes are to 328 be called on demand. Notice, the initiation of PASP Capability 329 Negotiation does not require the existance of a PASP Event. 331 3.4. Summary of Operation 333 The communications between two PASP speakders should follow three 334 major processes, i.e., the Capability Negotiation Process, the 335 Request and Reply Process, and the Notification Process. This 336 document defines 5 PASP Message types, i.e., Negotiation Message, 337 Request Message, Reply Message, Notification Message, and ACK 338 Message, which are used in the above PASP processes. 340 3.4.1. PASP Capability Negotiation Process 342 The purpose of the Capability Negotiation process is to inform two 343 PASP speakers of each other's PASP capabilties. The PASP capability 344 indicates, for which specific protocol(s), that PASP supports its/ 345 their diagnosing information exchange. The process can be further 346 divided into three procudures: 1) PASP Peering Relations Establish 347 process, 2) PASP Capability Enabling Notification Process, 3) PASP 348 Capability Disabling Notification Process. The Capability 349 Negotiation Process is realized by the exchange of PASP Capability 350 Negotiation Message, which is defined in Section 4. 352 Although PASP is connectionless, a successful PASP Peering Relations 353 Establish Process is required to be successfully performed before any 354 other PASP process. This process can be initiated by either the 355 local or remote PASP speaker through sending out a PASP Capability 356 Negotiation Message. The Negotiation Message may or may not require 357 an ACK Message, as indicated in the Negotiation Message. A 358 successful Peering is established if both PASP speakers have 359 correctly received the other speaker's Capability Negotiation 360 Message. After a successful negotiation, two PASP speakers can 361 exchange any PASP Message on-demand. The PASP Capability Enabling 362 Notification Process is used to inform the PASP peer its newly 363 supported capability, which can be intiated by the PASP speaker at 364 any moment after a PASP Peering is established with the respective 365 PASP Peer. The PASP Capability Disabling Notification Process is 366 used to inform the PASP peer its newly unsupported capability, which 367 can be intiated by the PASP speaker at any moment after a PASP 368 Peering is established with the respective PASP Peer. 370 3.4.2. PASP Request and Reply Process 372 The purpose of the PASP Request and Reply Process is to acquire 373 information needed by a PASP speaker from other PASP speakers for a 374 specific PASP Event. The Request and Reply Messages can be 375 customized for different events. The process is triggered by the 376 instantiation of a PASP Event, and starts with sending a Request 377 Message to a target PASP peer. The target PASP peer is selected by 378 the PASP agent regarding the current PASP Event, which is out of the 379 scope of this document. The remote PASP speaker, after receiving the 380 Request Message, sends out a Reply Message to the request sender. 381 ACK is required or not as indicated in the Message Flag. 383 One Request Message received at the local PASP speaker from a PASP 384 peer may further results in a new Request Message generation 385 regarding a third PASP speaker, if the local PASP speaker does not 386 have the right Reply to this PASP peer. This local PASP speaker does 387 not send Reply Message to the requesting PASP peer until it receives 388 a new Reply Message from this third PASP speaker. So the whole 389 process In order to avoid Request/Reply loops, a Residua Hop value is 390 used to limit the Request/Reply rounds. 392 3.4.3. PASP Notification Process 394 The Notification Process is used by a PASP speaker voluntarily to 395 notify other PASP speakers of certain information regarding a PASP 396 Event. The process is triggered by the instantiation of a PASP 397 Event, and starts with sending a Notification Message to one or 398 multiple target PASP peer(s). The target PASP peer(s) is/are 399 selected by the PASP agent regarding the current PASP Event, which is 400 out of the scope of this document. The Notification Message may or 401 may not require an ACK Message, as indicated in the Notification 402 Message. 404 4. PASP Message Format 406 4.1. Common Header 408 The common header is encapsulated in all PASP messages. It is 409 defined as follows. 411 0 1 2 3 412 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 413 +---------------+----------------+------------------------------+ 414 |V| Flag | Msg. Type | Length | 415 +---------------+----------------+------------------------------+ 416 + Peer Address (16 bytes) + 417 ~ ~ 418 +--------------------------------+------------------------------+ 419 | Msg. Sequence | 420 +--------------------------------+ 422 Figure 2. PASP Common Header 424 o Flag (1 byte): The V flag indicates that the source IP address is 425 an IPv6 address. For IPv4 address, this is set to 0. 427 o Message Type (1 byte): This indicates the PASP message type.The 428 following types are defined, and listed as follows. 430 * Type = TBD1: Capability Negotiation Message. It is used for 431 two devices to inform each other of the capabilties they 432 support and no longer support. 434 * Type = TBD2: Request Message. 436 * Type = TBD3: Reply Message. 438 * Type = TBD4: Notification Message. 440 * Type = TBD5: ACK Message. It is used to confirm to the local 441 device that the remote device has received a previous sent PASP 442 message, which can be either a Negotiation Message, a Request 443 Message, a Reply Message or an Notification Message. 445 o Length (2 bytes): Length of the message in bytes, including the 446 Common Header and the following Message. 448 o Souece IP Address (16 bytes): It indicates the IP address who 449 initiates the PASP message. It is 4 bytes long if an IPv4 address 450 is carried in this field (with the 12 most significant bytes zero- 451 filled) and 16 bytes long if an IPv6 address is carried in this 452 field. 454 o Message Sequence (2 bytes): It indicates the sequence number of 455 each PASP message. 457 4.1.1. Capability Negotiation Message 459 The Negotiation Message is used in the PASP Capability Negotiation 460 Process. It is defined as follows. 462 0 1 2 3 463 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 464 +--------------------------------+------------------------------+ 465 | Version |A|E| Flag | 466 +--------------------------------+------------------------------+ 467 | Protocol Capacity | 468 +---------------------------------------------------------------+ 470 Figure 3. PASP Negotiation Message 472 o Version (1 byte): It indicates the PASP version. The current 473 version is 0. 475 o Flags (1 bytes): Two flag bits are currently defined. 477 * The A bit is used to indicate if an ACK Message from the remote 478 PASP speaker is required for each Negotiation Message sent. If 479 an ACK is required, then the A bit SHOULD be set to "1", and 480 "0" otherwise. 482 * The E bit is used to indicate the enabling/disabling of the 483 capabilities that carried in the Protocol Capability field. If 484 the local device wants to inform the remote device of enabling 485 one or more capabilities, the E bit SHOULD be set to "1". If 486 the local device wants to inform the remote device of disabling 487 one or more capabilities, the E bit SHOULD be set to "0". 489 o Protocol Capability (4 bytes): It is 4-byte bitmap that indicates 490 the capability of inforamtion exchange regarding various 491 protocols. Each bit represents one protocol. The following 492 protocol capability is defined (from the rightmost bit). 494 * Bit 0: ISIS 496 * Bit 1: OSPF 498 * Bit 2: BGP 500 * Bit 3: LDP 502 4.2. Request Message 504 The Request Message is used for the local device to request specific 505 data regarding one specific protocol or application from the remote 506 device. It MUST be sent after a successful Capability Negotiation 507 Process (described in Section 5.1), and the requested protocol/ 508 application MUST be supported by both the local and remote devices, 509 as indicated in the Negotiation Messages exchanged between the local 510 and remote devices. It is defined as follows. 512 0 1 2 3 513 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 514 +---------------+----------------+------------------------------+ 515 |A| Flag | Prot. Capb. | Event ID | 516 +--------------------------------+------------------------------+ 517 | Res. Hop | 518 +---------------+-----------------------------------------------+ 519 + Request Data + 520 ~ ~ 521 +---------------------------------------------------------------+ 523 Figure 4. PASP Request Message 525 o Flags (1 byte): It is currently reserved. The A bit is used to 526 indicate if an ACK Message from the remote PASP speaker is 527 required for each Request Message sent. If an ACK is required, 528 then the A bit SHOULD be set to "1", and "0" otherwise. 530 o Capability (1 byte): It represents the bit index of the protocol, 531 which the Request Message is requesting data for. 533 o Event ID (2 bytes): It indicates the event number that this 534 Request message is regarding. 536 o Residua hop (1 byte): it indicates the residua Request hops of the 537 current PASP Event. It is reduced by 1 at each PASP speaker when 538 generating a further PASP Request to a third PASP speaker. 540 o Request Data (Variable): Specifies information of the data that 541 the local device is requesting. The specific format remains to be 542 determined per each protocol, as well as each use case. 544 4.3. Reply Message 546 The Reply Message is used to carry the information that the local 547 device requests from the remote device through the Request Message. 548 It is defined as follows. 550 0 1 2 3 551 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 552 +---------------+----------------+------------------------------+ 553 |A| Flag | Prot. Capb. | Event ID | 554 +---------------+----------------+------------------------------+ 555 + Reply Data + 556 ~ ~ 557 +---------------------------------------------------------------+ 559 Figure 5. PASP Reply Message 561 o Flags (1 byte): It is currently reserved. The A bit is used to 562 indicate if an ACK Message from the remote PASP speaker is 563 required for each Reply Message sent. If an ACK is required, then 564 the A bit SHOULD be set to "1", and "0" otherwise. 566 o Capability (1 byte): It represents the bit index of the protocol, 567 which the Reply Message is replying data for. 569 o Event ID (2 bytes): It indicates the event number that this Reply 570 message is regarding. 572 o Reply Data (Variable): Specifies information of the data that the 573 local device is replying. The specific format remains to be 574 determined per each protocol, as well as each use case. 576 4.4. Notification Message 578 The Notification Message is used to carry the information that the 579 local device sends to the remote device. 581 0 1 2 3 582 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 583 +---------------+----------------+------------------------------+ 584 |A| Flag | Prot. Capb. | Event ID | 585 +---------------+----------------+------------------------------+ 586 + Notification Data + 587 ~ ~ 588 +---------------------------------------------------------------+ 590 Figure 6. PASP Notification Message 592 o Flags (1 byte): It is currently reserved. The A bit is used to 593 indicate if an ACK Message from the remote PASP speaker is 594 required for each Notification Message sent. If an ACK is 595 required, then the A bit SHOULD be set to "1", and "0" otherwise. 597 o Capability (1 byte): It represents the bit index of the protocol, 598 which the Notification Message is notifying for. 600 o Event ID (2 bytes): It indicates the event number that this 601 Notification Message is regarding. 603 o Notification Data (Variable): Specifies information of the data 604 that the local device is notifying. The specific format remains 605 to be determined per each protocol, as well as each use case. 607 o 609 4.5. ACK Message 611 The ACK Message is used to confirm that the remote device has 612 received a PASP Message with the A bit set to "1". The ACK Message 613 includes only the PASP Common Header. The Msg. Sequence MUST be set 614 to the sequence number carried in the received PASP message, which 615 requires this ACK. 617 5. PASP Operations 619 The PASP operations include the following 3 major processes, the 620 Capability Negotiation Process, the Data Request and Reply Process, 621 and the Data Notification Process. 623 5.1. Capability Negotiation Process 625 5.1.1. PASP Peering Relation Establish Process 627 A successful PASP Peering relation MUST be Established between two 628 PASP speakers before any other PASP process. 630 As the first step, a Capability Negotiation Message can be initiated 631 at any time by a PASP speaker,as long as the target PASP peer is IP 632 reachable. It usually companies the establishment of neighboring/ 633 peering relation between two routing devices. The "A" bit in the 634 Negotiation Message MUST be set as 1 during the PASP Peering 635 Establish Process, meaning ACK required. The "E" in the Negotiation 636 Message MUST be set to 1 during this process, meaning the 637 capabilities indicated in the Protocol Capability field are enabled 638 by default. The Protocol Capability field SHOULD indicate all the 639 protocol capabilities that are supported by the local PASP Agent and 640 currently enabled. After the first Negotiation Message is sent, the 641 local device SHUOLD wait for the ACK Message from the remote device 642 for a certain time period before taking further actions, and if no 643 ACK Message is received within this time frame, the local device 644 SHOULD resend the Negotiation Message to the remote device. The 645 waiting period can be configured locally. This send and wait process 646 CAN be repeated for at most 3 times before receiving a ACK Message 647 from the remote device. If after 3 times of resending the 648 Negotiation Message, still no ACK received, then this peering 649 establishment is treated as unsuccessful. 651 The next step for the local PASP speaker is to wait for the 652 Negotiation Message from the remote PASP speaker. If no Negotiation 653 Message is received from the remote PASP speaker within a time frame 654 after its own Negotiation Message is sent , the local PASP speaker 655 CAN resend the Negotiation Message. This time frame is also 656 configured locally. This send and wait process CAN be repeated for 657 at most 3 times before receiving a Negotiation Message from the 658 remote PASP speaker. If after 3 times of resending the Negotiation 659 Message, still no Negotiation Message received, then this negotiation 660 is treated as unsuccessful. If a Negotiation Message is received and 661 parsed correctly, an ACK MUST be sent to the remote PASP speaker. 663 Once an ACK Message and a Negotiation Message are received from the 664 remote PASP speaker and correctly parsed, a PASP Peering relation is 665 considered as successfully established. The local PASP speaker 666 maintains locally the protocol capabilities of the remote PASP 667 speaker, and uses them during other PASP processes. 669 5.1.2. PASP Capability Enabling Notification Process 671 Once the PASP Peering relation is set up between two PASP speakers, 672 they become PASP peers. Thereafter, any PASP speaker supports a new 673 protocol capability, it SHOULD call the Capability Enabling 674 Notification Process to inform all its PASP peers. 676 When the local PASP speaker initates a PASP Capability Enabling 677 Notification Process: The "A" bit in the Negotiation Message MUST be 678 set as 1 during the PASP Capability Enabling Notification Process, 679 meaning ACK required. The "E" in the Negotiation Message MUST be set 680 to 1 during this process, meaning the capabilities indicated in the 681 Protocol Capability field are enabled. The Protocol Capability field 682 SHOULD indicate all the protocol capabilities that are supported by 683 the local PASP Agent and currently enabled. After the Negotiation 684 Message is sent, the local PASP speaker SHUOLD wait for the ACK 685 Message from the PASP peer for a certain time period before taking 686 further actions, and if no ACK Message is received within this time 687 frame, the local device SHOULD resend the Negotiation Message to the 688 remote device. The waiting period can be configured locally. This 689 send and wait process CAN be repeated for at most 3 times before 690 receiving a ACK Message from the remote device. If after 3 times of 691 resending the Negotiation Message, still no ACK received, then this 692 Capability Enabling Notification Process is treated as unsuccessful. 693 This process MAY be intiated at another time thereafter. If a ACK is 694 received, the Capability Enabling Notification Process is considered 695 successful. 697 When a PASP peer initates a PASP Capability Enabling Notification 698 Process: The local PASP speaker, after receiving the PASP Negotiation 699 Message and correctly parsing it, sends out an ACK. This Capability 700 Enabling Notification Process is considered successful. The local 701 PASP speaker updates the capability status maintained accordingly. 703 5.1.3. PASP Capability Disabling Notification Process 705 Whenever a PASP speaker disables a PASP capability, it SHOULD 706 initiate a PASP Capability Disabling Notification Process to inform 707 all its PASP peers. 709 When the local PASP speaker initates a PASP Capability Disabling 710 Notification Process: The "A" bit in the Negotiation Message MUST be 711 set as 1 during the PASP Capability Disabling Notification Process, 712 meaning ACK required. The "E" in the Negotiation Message MUST be set 713 to 0 during this process, meaning the capabilities indicated in the 714 Protocol Capability field are disabled. The Protocol Capability 715 field SHOULD indicate all the protocol capability that is disabled. 716 After the Negotiation Message is sent, the local PASP speaker SHUOLD 717 wait for the ACK Message from the PASP peer for a certain time period 718 before taking further actions, and if no ACK Message is received 719 within this time frame, the local device SHOULD resend the 720 Negotiation Message to the remote device. The waiting period can be 721 configured locally. This send and wait process CAN be repeated for 722 at most 3 times before receiving a ACK Message from the remote 723 device. If after 3 times of resending the Negotiation Message, still 724 no ACK received, then this Capability Disabling Notification Process 725 is treated as unsuccessful. This process MAY be intiated at another 726 time thereafter. 728 When a PASP peer initates a PASP Capability Disabling Notification 729 Process: The local PASP speaker, after receiving the PASP Negotiation 730 Message and correctly parsing it, sends out an ACK. This Capability 731 Disabling Notification Process is considered successful. The local 732 PASP speaker updates the capability status maintained accordingly. 734 5.2. PASP Request and Reply Process 736 When a local PASP Event triggers a PASP Request and Reply Process, 737 the local PASP speaker initates a Request Message, and send to a 738 target PASP peer as indicated by PASP Agent per this PASP Event. 739 This local PASP speaker is called the Request and Reply Process 740 Starter. It sets the Residua Hop as the maximum number of Request/ 741 Reply rounds (e.g., 10) it will wait in order to receive the final 742 Reply. The Event ID and the Request are set by the local PASP Agent. 743 The A bit of the Request Message MUST be set to "1" (i.e., ACK is 744 required). The local device waits for the ACK Message from the 745 remote device for a certain time period before taking further 746 actions, and if no ACK Message is received within this time frame, 747 the local device SHOULD resend the Request Message to the remote 748 device. The waiting period can be configured locally. This send and 749 wait process CAN be repeated for at most 3 times before receiving a 750 ACK Message from the remote device. If after 3 times of resending 751 the Request Message, still no ACK received, then this Request and 752 Reply Process is treated as unsuccessful. If ACK received, the local 753 device waits for the Reply Message. If no Reply Message is received 754 from the remote device within a time frame, the local device can 755 resend the Request Message. This send and wait process CAN be 756 repeated for at most 3 times before receiving a Reply Message from 757 the remote device. If after 3 times of resending the Request 758 Message, still no Reply Message received, then this Request and Reply 759 Process is treated as unsuccessful. The waiting period can be 760 configured locally, and SHOULD take into consideration of the Residua 761 Hop value. If the Request and Reply Process Starter receives the 762 Reply Message within the time frame, and the Event ID is matched to 763 the local PASP Event, the PASP Request and Reply Process is 764 considered as successful. 766 When a local PASP speaker receives a Request Message from its PASP 767 peer (i.e., it is not the Pequest and Reply Process Starter), it 768 sends back an ACK Message. With the received Request Message, a new 769 PASP event it instantiated at the local PASP Agent. The PASP event 770 triggers the troubleshooting analysis of the received Request 771 Message, and then generate the Reply Message if the Reply condition 772 is met, or generate a new Request Message when the Reply condition is 773 not met. The Reply condition and the troubleshooting analysis of the 774 PASP Agent is out of the scope of this document. 776 If the Reply condition is met, the local PASP speaker is called the 777 Request and Reply Process Terminator. It generates the Reply Message 778 and send the message back to the requesting PASP peer. The Event ID 779 is set to be the same as the Event ID of the received Request 780 Message. The Reply Data is set by the local PASP Agent per this 781 generated event. The A bit of the Reply Message MUST be set to "1" 782 (i.e., ACK is required). The local device waits for the ACK Message 783 from the remote device for a certain time period before taking 784 further actions, and if no ACK Message is received within this time 785 frame, the local device SHOULD resend the Reply Message to the remote 786 device. The waiting period can be configured locally. This send and 787 wait process CAN be repeated for at most 3 times before receiving a 788 ACK Message from the remote device. If after 3 times of resending 789 the Request Message, still no ACK received, then this Request and 790 Reply Process is treated as unsuccessful. 792 If the Reply condition is not met, the local PASP speaker is called 793 the Request and Reply Process mid-handler. It generates a new 794 Request Message and send the message to a third PASP speaker per 795 indicated by the local PASP Agent per this generated event. In the 796 new generated Request Message, the Residua Hop value by MUST be 797 reduced by 1. The A bit of the Request Message MUST be set to "1" 798 (i.e., ACK is required). The local device waits for the ACK Message 799 from the remote device for a certain time period before taking 800 further actions, and if no ACK Message is received within this time 801 frame, the local device SHOULD resend the Request Message to the 802 remote device. The waiting period can be configured locally. This 803 send and wait process CAN be repeated for at most 3 times before 804 receiving a ACK Message from the remote device. If after 3 times of 805 resending the Request Message, still no ACK received, then this 806 Request and Reply Process is treated as unsuccessful. If ACK 807 received, the local device waits for the Reply Message. If no Reply 808 Message is received from the remote device within a time frame, the 809 local device can resend the Request Message. This send and wait 810 process CAN be repeated for at most 3 times before receiving a Reply 811 Message from the remote device. If after 3 times of resending the 812 Request Message, still no Reply Message received, then this Request 813 and Reply Process is treated as unsuccessful. The waiting period can 814 be configured locally, and SHOULD take into consideration of the 815 Residua Hop value. If the local device receives the Reply Message 816 within the time frame, it generates a new Reply Message and sends 817 back to it requesting PASP peer. The Event ID of the new Reply 818 Message is set to be the same as the Event ID of the received Request 819 Message. 821 5.3. PASP Notification Process 823 When a local PASP Event triggers a PASP Notification Process, the 824 local PASP speaker initates a Notification Message. The target PASP 825 peer(s) is/are selected by the PASP agent regarding the current PASP 826 Event, which is out of the scope of this document. The Notification 827 Message may or may not require an ACK Message, as indicated in the 828 Notification Message. If the A bit is set to 1 (meaning ACK 829 required), the local device waits for the ACK Message from the remote 830 device for a certain time period before taking further actions, and 831 if no ACK Message is received within this time frame, the local 832 device SHOULD resend the Notification Message to the remote device. 833 The waiting period can be configured locally. This send and wait 834 process CAN be repeated for at most 3 times before receiving a ACK 835 Message from the remote device. If after 3 times of resending the 836 Request Message, still no ACK received, then this Request and Reply 837 Process is treated as unsuccessful. The waiting period can be 838 configured locally. If ACK is received within the time frame, the 839 Notification Process is considered to be successful. If the A bit is 840 set to 0 (meaning no ACK required), after sending the Notification 841 Message, the Notification Process is considered successful. 843 6. PASP Error Handling 845 When any PASP process is unsuccessful, information is recorded or not 846 by local PASP Agent. No further action is taken. 848 7. Discussion 850 In addition to the preceding message definition and process 851 description, the security and reliability requirements of the PASP 852 need to be considered. There are two possible options to implement 853 PASP. 855 - Option 1: PASP is developed independently as a new protocol. 857 - Option 2: PASP reuses the existing protocol Generic Autonomic 858 Signaling Protocol(GRASP) [I-D.ietf-anima-grasp] . 860 Option1: 862 1. Definition of the Message Format and Interaction Process: It can 863 be defined independently in the PASP. 865 2. Reliability: The transmission mode of PASP is based on UDP mainly 866 considering that the collected information is the auxiliary 867 information to help locate the protocol fault, and the information 868 loss has no impact on the service. In addition, if TCP mode is 869 adopted, the resource consumption of the device may be large, 870 especially when there area large number of neighbors. If it is 871 considered that PASP must ensure reliability, it can done in the 872 application layer, such as adding the sequence number to the message. 874 3. Security: MD5 authentication can be introduced for PASP security. 876 Option2: 878 ANIMA GRASP is a signaling protocol used for dynamic peer discovery, 879 status synchronization, and parameter negotiation between AS nodes or 880 AS service agents. GRASP specifies that unicast packets must be 881 transmitted based on TCP, and multicast packets (Discovery and Flood) 882 must be transmitted based on UDP. 884 1. Message format and interaction process: PASP can reuse the 885 defined messages and procedures of the GRASP. Messages defined in 886 the PASP include Capability Negotiation Message, Request Message, 887 Reply Message, and Negotiation Message. These message types are also 888 defined in GRASP. 890 2. Reliability: TCP mode of GRASP can be used to ensure reliability 891 for PASP. But there may be challenge for the equipment resources. 893 3. Security: Autonomic Control Plane(ACP) 894 [I-D.ietf-anima-autonomic-control-plane] can be reused. 896 8. Security Considerations 898 TBD 900 9. IANA 902 TBD 904 10. Contributors 906 We thank Jiaqing Zhang (Huawei), Tao Du (Huawei) and Lei Li (Huawei) 907 for their contributions. 909 11. Acknowledgments 911 12. References 913 [I-D.brockners-inband-oam-requirements] 914 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 915 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 916 T., Lapukhov, P., and r. remy@barefootnetworks.com, 917 "Requirements for In-situ OAM", draft-brockners-inband- 918 oam-requirements-03 (work in progress), March 2017. 920 [I-D.ietf-anima-autonomic-control-plane] 921 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 922 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 923 plane-30 (work in progress), October 2020. 925 [I-D.ietf-anima-grasp] 926 Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "A 927 Generic Autonomic Signaling Protocol (GRASP)", draft-ietf- 928 anima-grasp-15 (work in progress), July 2017. 930 [I-D.ietf-netconf-yang-push] 931 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 932 draft-ietf-netconf-yang-push-25 (work in progress), May 933 2019. 935 [I-D.song-ntf] 936 Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z., 937 Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a 938 Network Telemetry Framework", draft-song-ntf-02 (work in 939 progress), July 2018. 941 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 942 "Simple Network Management Protocol (SNMP)", RFC 1157, 943 DOI 10.17487/RFC1157, May 1990, 944 . 946 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 947 DOI 10.17487/RFC1191, November 1990, 948 . 950 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 951 dual environments", RFC 1195, DOI 10.17487/RFC1195, 952 December 1990, . 954 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 955 for Network Management of TCP/IP-based internets: MIB-II", 956 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 957 . 959 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 960 Requirement Levels", BCP 14, RFC 2119, 961 DOI 10.17487/RFC2119, March 1997, 962 . 964 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 965 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 966 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 967 . 969 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 970 Signalling Extensions for the Label Distribution 971 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 972 . 974 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 975 and A. Bierman, Ed., "Network Configuration Protocol 976 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 977 . 979 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 980 S. Ray, "North-Bound Distribution of Link-State and 981 Traffic Engineering (TE) Information Using BGP", RFC 7752, 982 DOI 10.17487/RFC7752, March 2016, 983 . 985 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 986 Monitoring Protocol (BMP)", RFC 7854, 987 DOI 10.17487/RFC7854, June 2016, 988 . 990 Authors' Addresses 992 Zhenbin Li 993 Huawei 994 156 Beiqing Rd 995 Beijing 996 China 998 Email: lizhenbin@huawei.com 1000 Shuanglong Chen 1001 Huawei 1002 156 Beiqing Road 1003 Beijing,100095 1004 China 1006 Email: chenshuanglong@huawei.com 1008 Yingzhen Qu 1009 Futurewei 1011 Email: yingzhen.qu@futurewei.com 1013 Yunan Gu 1014 Huawei 1015 156 Beiqing Rd 1016 Beijing 1017 China 1019 Email: guyunan@huawei.com