idnits 2.17.1 draft-ietf-mpls-spring-inter-domain-oam-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 December 2021) is 864 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) == Missing Reference: 'N-P1' is mentioned on line 620, but not defined == Missing Reference: 'N-ASBR1' is mentioned on line 620, but not defined == Missing Reference: 'EPE-ASBR1-ASBR4' is mentioned on line 620, but not defined == Missing Reference: 'N-PE4' is mentioned on line 620, but not defined == Missing Reference: 'N-ASBR4' is mentioned on line 678, but not defined == Missing Reference: 'EPE-ASBR4-ASBR1' is mentioned on line 678, but not defined == Missing Reference: 'N-PE1' is mentioned on line 831, but not defined == Missing Reference: 'PE1' is mentioned on line 673, but not defined == Missing Reference: 'ASBR1' is mentioned on line 673, but not defined == Missing Reference: 'ASBR4' is mentioned on line 673, but not defined == Missing Reference: 'ASBR6' is mentioned on line 673, but not defined == Missing Reference: 'ASBR8' is mentioned on line 673, but not defined == Missing Reference: 'PE5' is mentioned on line 673, but not defined == Missing Reference: 'N-ABR1' is mentioned on line 831, but not defined == Missing Reference: 'N-ABR2' is mentioned on line 831, but not defined ** Downref: Normative reference to an Informational RFC: RFC 9087 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing area S. Hegde 3 Internet-Draft K. Arora 4 Intended status: Standards Track M. Srivastava 5 Expires: 16 June 2022 Juniper Networks Inc. 6 S. Ninan 7 Ciena 8 N. Kumar 9 Cisco Systems, Inc. 10 13 December 2021 12 PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks 13 draft-ietf-mpls-spring-inter-domain-oam-02 15 Abstract 17 Segment Routing (SR) architecture leverages source routing and 18 tunneling paradigms and can be directly applied to the use of a 19 Multiprotocol Label Switching (MPLS) data plane. A network may 20 consist of multiple IGP domains or multiple ASes under the control of 21 same organization. It is useful to have the Label switched Path 22 (LSP) Ping and traceroute procedures when an SR end-to-end path spans 23 across multiple ASes or domains. This document describes mechanisms 24 to facilitae LSP ping and traceroute in inter-AS/inter-domain SR-MPLS 25 networks in an efficient manner with simple Operations, 26 Administration, and Maintenance (OAM) protocol extension which uses 27 dataplane forwarding alone for sending echo reply. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 [RFC2119] [RFC8174] when, and only when, they appear in all 35 capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 16 June 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Revised BSD License text as 65 described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Revised BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Definition of Domain . . . . . . . . . . . . . . . . . . 5 72 2. Inter domain networks with multiple IGPs . . . . . . . . . . 5 73 3. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . . . 5 74 4. Segment sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. Type A: SID only, in the form of MPLS Label . . . . . . . 7 76 4.2. Type C: IPv4 Node Address with optional SID for 77 SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.3. Type D: IPv6 Node Address with optional SID for SR 79 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.4. Segment Flags . . . . . . . . . . . . . . . . . . . . . . 10 81 5. SRv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 11 82 6. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 11 83 6.1. Sending an echo request . . . . . . . . . . . . . . . . . 11 84 6.2. Receiving an echo request . . . . . . . . . . . . . . . . 11 85 6.3. Sending an echo reply . . . . . . . . . . . . . . . . . . 12 86 6.4. Receiving an echo reply . . . . . . . . . . . . . . . . . 12 87 7. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 12 88 7.1. Procedures for Segment Routing LSP ping . . . . . . . . . 13 89 7.2. Procedures for Segment Routing LSP Traceroute . . . . . . 14 90 8. Building Reply Path TLV dynamically . . . . . . . . . . . . . 16 91 8.1. The procedures to build the return path . . . . . . . . . 16 92 8.2. Details with example . . . . . . . . . . . . . . . . . . 18 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 96 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 99 13.2. Informative References . . . . . . . . . . . . . . . . . 21 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 102 1. Introduction 104 +----------------+ 105 | Controller/PMS | 106 +----------------+ 108 |---AS1-----| |------AS2------| |----AS3---| 110 ASBR2----ASBR3 ASBR5------ASBR7 111 / \ / \ 112 / \ / \ 113 PE1----P1---P2 P3---P4---PE4 P5---P6--PE5 114 \ / \ / 115 \ / \ / 116 ASBR1----ASBR4 ASBR6------ASBR8 118 Figure 1: Inter-AS Segment Routing topology 120 Many network deployments have built their networks consisting of 121 multiple Autonomous Systems either for ease of operations or as a 122 result of network mergers and acquisitions. Segment Routing can be 123 deployed in such scenarios to provide end to end paths, traversing 124 multiple Autonomous systems(AS). These paths consist of Segment 125 Identifiers(SID) of different type as per [RFC8402]. 127 [RFC8660] specifies the forwarding plane behaviour to allow Segment 128 Routing to operate on top of MPLS data plane. [RFC9087] describes 129 BGP peering SIDs, which will help in steering packet from one 130 Autonomous system to another. Using above SR capabilities, paths 131 which span across multiple Autonomous systems can be created. 133 For example Figure 1 describes an inter-AS network scenario 134 consisting of ASes AS1 and AS2. Both AS1 and AS2 are Segment Routing 135 enabled and the EPE links have EPE labels configured and advertised 136 via [I-D.ietf-idr-bgpls-segment-routing-epe]. Controller or head-end 137 can build end-to-end Traffic-Engineered path consisting of Node-SIDs, 138 Adjacency-SIDs and EPE-SIDs. It is advantageous for operations to be 139 able to perform LSP ping and traceroute procedures on these inter-AS 140 SR-MPLS paths. LSP ping/traceroute procedures use IP connectivity 141 for echo reply to reach the head-end. In inter-AS networks, IP 142 connectivity may not be there from each router in the path.For 143 example in Figure 1 P3 and P4 may not have IP connectivity for PE1. 145 [RFC8403] describes mechanisms to carry out the MPLS ping/traceroute 146 from a Path Monitoring System (PMS). It is possible to build GRE 147 tunnels or static routes to each router in the network to get IP 148 connectivity for the reverse path. This mechanism is operationally 149 very heavy and requires PMS to be capable of building huge number of 150 GRE tunnels, which may not be feasible. 152 It is not possible to carry out LSP ping and Traceroute functionality 153 on these paths to verify basic connectivity and fault isolation using 154 existing LSP ping and Traceroute mechanism([RFC8287] and [RFC8029]). 155 This is because, there exists no IP connectivity to source address of 156 ping packet, which is in a different AS, from the destination of 157 Ping/Traceroute. 159 [RFC7743] describes a Echo-relay based solution based on advertising 160 a new Relay Node Address Stack TLV containing stack of Echo-relay IP 161 addresses. These mechansims can be applied to segment routing 162 networks as well. [RFC7743] mechanism requires the return ping 163 packet to be processed in slow path or as a bump-in-the-wire on every 164 relay node. The motivation of the current document is to provide an 165 alternate mechanism for ping/traceroute in inter-domain segment 166 routing networks. 168 This document describes a new mechanism which is efficient and simple 169 and can be easily deployed in SR-MPLS networks. This mechanism uses 170 MPLS path and no changes required in the forwarding path. Any MPLS 171 capable node will be able to forward the echo-reply packet in fast 172 path. The current draft describes a mechanism that uses Reply path 173 TLV [RFC7110] to convey the reverse path. Three new sub-TLVs for 174 Reply path TLV are defined, that faciliate encoding segment routing 175 label stack. The TLV can either be derived by a smart application or 176 controller which has a full topology view. This document also 177 proposes mechanisms to derive the return path dynamically during 178 traceroute procedures. 180 The current document is focused on the inter-domain use case. 181 However, the protocol extensions described in this document may be 182 applied to indicate the return path for other use cases as well. 184 1.1. Definition of Domain 186 The term domain used in this document implies an IGP domain where 187 every node is visible to every other node for the purposes of 188 shortest path computation. The domain implies an IGP area or level. 189 An Autonomous System (AS) consists of one or more IGP domains.The 190 procedures described in this document are applicable to paths built 191 across multiple domains which includes inter-area as well as inter-AS 192 paths. This document is applicable to SR-MPLS networks where all 193 nodes in each of the domains are SR capable. It is also applicable 194 to SR-MPLS networks where SR acts an an overlay having SR incapable 195 underlay nodes. In such networks, the traceroute procedure is 196 executed only on the overlay SR nodes. 198 2. Inter domain networks with multiple IGPs 200 |-Domain 1|-------Domain 2-----|--Domain 3-| 202 PE1------ABR1--------P--------ABR2------PE4 203 \ / \ /\ / 204 -------- ----------------- ------- 205 BGP-LU BGP-LU BGP-LU 207 Figure 2: Inter-domain networks with multiple IGPs 209 When the network consists of large number of nodes, the nodes are 210 seggregated into multiple IGP domains. The connectivity to the 211 remote PEs can be achieved using BGP-Labeled Unicast (BGP-LU) 212 [RFC8277] or by stacking the labels for each domain as described in 213 [RFC8604]. It is useful to support MPLS ping and traceroute 214 mechanisms for these networks. The procedures described in this 215 document for constructing Reply path TLV and its use in echo reply is 216 equally applicable to networks consisting of multiple IGP domains 217 that use BGP-LU or label stacking. 219 3. Reply Path TLV 221 Segment Routing networks statically assign the labels to nodes and 222 PMS/Head-end may know the entire database. The reverse path can be 223 built from PMS/Head-end by stacking segments for the reverse path. 224 Reply path TLV as defined in [RFC7110] is used to carry the return 225 path. While using the procedures described in this document, the 226 reply mode is set to 5 (Reply via Specified Path), and Reply Path TLV 227 is included in the echo request message as described in [RFC7110]. 229 The Reply Path TLV is constructed as per Section 4.2 of RFC 7110.This 230 document define three new sub-TLVs to encode the Segment Routing 231 path. 233 The type of segment that the head-end chooses to send in the Reply 234 Path TLV is governed by local policy. Implementations may provide 235 CLI input parameters in Labels, IPv4 addresses or IPv6 addresses or a 236 combination of these which gets encoded in the return path TLV. 237 Implementations may also provide mechansims to acquire the database 238 of remote domains and compute the return path based on the acquired 239 database. For traceroute purposes, the return path will have to 240 consider the reply being sent from every node along the path. The 241 return path changes when the traceroute progresses and crosses each 242 domain. One of the ways this can be implemented on headend is to 243 acquire the entire database (of all domains) and build return path 244 for every node along the SR-MPLS path based on the knowledge of the 245 database. Another mechansim is to use dynamically computed return 246 path as described in Section 8 248 Some networks may consist of pure IPV4 domains and pure IPv6 domains. 249 Handling end-to-end MPLS OAM for such networks is out of scope for 250 this document. It is recommended to use dual stack in such cases and 251 use end-to-end IPv6 addresses for MPLS ping and trace route 252 procedures. 254 4. Segment sub-TLV 256 [I-D.ietf-spring-segment-routing-policy] defines various types of 257 segments. The types of segments applicable to this document have 258 been defined in this section for the use of MPLS OAM. The motivation 259 has been to keep the definitions same as in 260 [I-D.ietf-spring-segment-routing-policy] with minimal modifications 261 if it is absolutely needed. One or more segment sub-TLV can be 262 included in the Reply Path TLV. The segment sub-TLVs included in a 263 Reply Path TLV MAY be of different types. 265 Below types of segment sub-TLVs are applicable for the Reverse Path 266 Segment List TLV. 268 Type A: SID only, in the form of MPLS Label 270 Type C: IPv4 Node Address with optional SID 272 Type D: IPv6 Node Address with optional SID for SR MPLS 274 4.1. Type A: SID only, in the form of MPLS Label 276 The Type-A Segment Sub-TLV encodes a single SID in the form of an 277 MPLS label. The format is as follows: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Type | Length | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Flags | RESERVED | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Label | TC |S| TTL | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 3: Type 1 Segment sub-TLV 291 where: 293 Type: TBD1(to be assigned by IANA from the registry "Sub-TLVs for TLV 294 Types 1, 16, and 21"). 296 Length is 8. 298 Flags: 1 octet of flags as defined in Section 4.4. 300 RESERVED: 3 octets of reserved bits. SHOULD be unset on transmission 301 and MUST be ignored on receipt. 303 Label: 20 bits of label value. 305 TC: 3 bits of traffic class 307 S: 1 bit Reserved 309 TTL: 1 octet of TTL. 311 The following applies to the Type-1 Segment sub-TLV: 313 The S bit SHOULD be zero upon transmission, and MUST be ignored upon 314 reception. 316 If the originator wants the receiver to choose the TC value, it sets 317 the TC field to zero. 319 If the originator wants the receiver to choose the TTL value, it sets 320 the TTL field to 255. 322 If the originator wants to recommend a value for these fields, it 323 puts those values in the TC and/or TTL fields. 325 The receiver MAY override the originator's values for these fields. 326 This would be determined by local policy at the receiver. One 327 possible policy would be to override the fields only if the fields 328 have the default values specified above. 330 4.2. Type C: IPv4 Node Address with optional SID for SR-MPLS 332 The Type-C Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 333 and an optional SID in the form of an MPLS label. The format is as 334 follows: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Flags | RESERVED (MBZ) | SR Algorithm | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | IPv4 Node Address (4 octets) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | SID (optional, 4 octets) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 4: Type 3 Segment sub-TLV 350 where: 352 Type: TBD3(to be assigned by IANA from the registry "Sub-TLVs for TLV 353 Types 1, 16, and 21"). 355 Length is 8 or 12. 357 Flags: 1 octet of flags as defined in Section 4.4. 359 SR Algorithm: 1 octet specifying SR Algorithm as described in section 360 3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4is present. 361 SR Algorithm is used by the receiver to derive the Label. When 362 A-flag is unset, this field has no meaning and thus MUST be set to 363 zero on transmission and ignored on receipt. 365 RESERVED: 2 octets of reserved bits.MUST be set to zero when sending; 366 MUST be ignored on receipt. 368 IPv4 Node Address: a 4 octet IPv4 address representing a node. 370 SID: optional :4 octet field containing label, TC, S and TTL as 371 defined in Section 4.1 373 The following applies to the Type-3 Segment sub-TLV: 375 The IPv4 Node Address MUST be present. 377 The SID is optional and specifies a 4 octet MPLS SID containing 378 label, TC, S and TTL as defined in Section 4.1. 380 If length is 8, then only the IPv4 Node Address is present. 382 If length is 12, then the IPv4 Node Address and the MPLS SID are 383 present.When the MPLS SID field is present, it MUST be used for 384 constructing the Reply Path TLV. 386 4.3. Type D: IPv6 Node Address with optional SID for SR MPLS 388 The Type-D Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 389 and an optional SID in the form of an MPLS label. The format is as 390 follows: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Type | Length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Flags | RESERVED(MBZ) | SR Algorithm | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 // IPv6 Node Address (16 octets) // 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | SID (optional, 4 octets) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 5: Type 4 Segment sub-TLV 406 where: 408 Type: TBD4(to be assigned by IANA from the registry "Sub-TLVs for TLV 409 Types 1, 16, and 21"). 411 Length is 20 or 24. 413 Flags: 1 octet of flags as defined in Section 4.4. 415 SR Algorithm: 1 octet specifying SR Algorithm as described in section 416 3.1.1 in [RFC8402], when A-Flag as defined in Section 4.4 is present. 417 SR Algorithm is used by the receiver to derive the label.W hen A-flag 418 is unset, this field has no meaning and thus MUST be set to zero on 419 transmission and ignored on receipt. 421 RESERVED: 2 octets of reserved bits.MUST be set to zero when sending; 422 MUST be ignored on receipt.. 424 IPv6 Node Address: a 16 octet IPv6 address representing a node. 426 SID: optional :4 octet field containing label, TC, S and TTL as 427 defined in Section 4.1 429 The following applies to the Type-4 Segment sub-TLV: 431 The IPv6 Node Address MUST be present. 433 The SID is optional and specifies a 4 octet MPLS SID containing 434 label, TC, S and TTL as defined in Section 4.1 . 436 If length is 20, then only the IPv6 Node Address is present. 438 If length is 24, then the IPv6 Node Address and the MPLS SID are 439 present. When the MPLS SID field is present, it MUST be used for 440 constructing the Reply Path TLV. 442 4.4. Segment Flags 444 The Segment Types described above contain following flags in the 445 "Flags" field (codes to be assigned by IANA from the registry 446 "Segment sub-TLV Flags" ) 448 0 1 2 3 4 5 6 7 449 +-+-+-+-+-+-+-+-+ 450 | |A| | 451 +-+-+-+-+-+-+-+-+ 453 Figure 6: Flags 455 where: 457 A-Flag: This flag indicates the presence of SR Algorithm id in the 458 "SR Algorithm" field applicable to various Segment Types. 460 Unused bits in the Flag octet SHOULD be set to zero upon transmission 461 and MUST be ignored upon receipt. 463 The following applies to the Segment Flags: 465 A-Flag is applicable to Segment Types 3, 4. If A-Flag appears with 466 any other Segment Type, it MUST be ignored. 468 5. SRv6 Dataplane 470 SRv6 dataplane is not in the scope of this document and will be 471 addressed in a separate document. 473 6. Detailed Procedures 475 6.1. Sending an echo request 477 In the inter-AS scenario when there is no reverse path connectivity, 478 the procedures described in this document should be used. LSP ping 479 initiator MUST set the Reply Mode of the echo request to "Reply via 480 Specified Path", and a Reply Path TLV MUST be carried in the echo 481 request message correspondingly. The Reply Path TLV must contain the 482 Segment Routing Path in the reverse direction encoded as an ordered 483 list of segments. The first Segment MUST correspond to the top 484 Segment in MPLS header that the responder MUST use while sending the 485 echo reply. 487 6.2. Receiving an echo request 489 As described in [RFC7110], when Reply mode is set to 5 (Reply via 490 Specified Path),The echo request MUST contain the Reply path TLV. 491 Absence of Reply path TLV is treated as malformed echo request. when 492 an echo request is received, if the egress LSR does not know the 493 Reply Mode 5 defined in [RFC7110], an echo reply with the return code 494 set to "Malformed echo request received" and the Subcode set to zero 495 will be sent back to the ingress LSR according to the rules of 496 [RFC8029]. When a Reply Path TLV is received, and the responder that 497 supports processing it, it MUST use the segments in Reply Path TLV to 498 build the echo reply.The responder MUST follow the normal FEC 499 validation procedures as described in [RFC8029] and [RFC8287] and 500 this document does not suggest any change to those procedures. When 501 the echo reply has to be sent out the Reply Path TLV is used to 502 construct the MPLS packet to send out. 504 6.3. Sending an echo reply 506 The echo reply message is sent as MPLS packet with a MPLS label 507 stack. The echo reply message MUST be constructed as described in 508 the [RFC8029]. An MPLS packet is constructed with echo reply in the 509 payload. The top label MUST be constructed from the first Segment 510 from the Reply Path TLV. The remaining labels MUST follow the order 511 from the Reply Path TLV. The responder MAY check the reachability of 512 the top label in its own Label Forwarding Information Base (LFIB) 513 before sending the echo reply. In certain scenarios the head-end may 514 choose to send Type 3/Type 4 segments consisting of IPV4 address or 515 IPv6 address. Optionally a SID may also be assiciated with Type 3/ 516 Type4 segment. In such cases the node sending the echo reply MUST 517 derive the MPLS labels based on Node-SIDs associated with the IPv4 518 /IPv6 addresses or from the optional MPLS SIDs in the type 3/ type 4 519 segments and encode the echo reply with MPLS labels. 521 The reply path return code MUST be set as described in section 7.4 of 522 [RFC7110]. The Reply Path TLV MUST be included in echo reply 523 indicating the specified return path that the echo reply message is 524 required to follow as described in section 5.3 of [RFC7110]. 526 When the node is configured to dynamically create return path for 527 next echo request, the procedures described in Section 8 MUST be 528 used. The reply path return code MUST be set to TBA1 and same Reply 529 Path TLV or a new Reply Path TLV MUST be included in the echo reply. 531 6.4. Receiving an echo reply 533 The rules and process defined in Section 4.6 of [RFC8029] and section 534 5.4 of [RFC7110] apply here. In addition, if the Reply path return 535 code is "Use Reply Path TLV in echo reply for next echo request", the 536 Reply Path TLV from the echo Reply MUST be sent in the next echo 537 request with TTL incremented by 1. 539 7. Detailed Example 541 Example topologies given in Figure 1 and Figure 2 will be used in 542 below sections to explain LSP Ping and Traceroute procedures. The 543 PMS/Head-end has complete view of topology. PE1, P1, P2, ASBR1 and 544 ASBR2 are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are in AS2. 546 AS1 and AS2 have Segment Routing enabled. IGPs like OSPF/ISIS are 547 used to flood SIDs in each Autonomous System. The ASBR1, ASBR2, 548 ASBR3, ASBR4 advertise BGP EPE SIDs for the inter-AS links. Topology 549 of AS1 and AS2 are advertised via BGP-Link State (BGP-LS) to the 550 controller/PMS or Head-end node. The EPE-SIDs are also advertised 551 via BGP-LS as described in [I-D.ietf-idr-bgpls-segment-routing-epe] 552 The description in the document uses below notations for Segment 553 Identifiers(SIDs). 555 Node SIDs : N-PE1, N-P1, N-ASBR1 N-ABR1, N-ABR2etc. 557 Adjacency SIDs : Adj-PE1-P1, Adj-P1-P2 etc. 559 EPE SIDS : EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 etc. 561 Let us consider a traffic engineered path built from PE1 to PE4 with 562 Segment List stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 563 for following procedures. This stack may be programmed by 564 controller/PMS or Head-end router PE1 may have imported the whole 565 topology information from BGP-LS and computed the inter-AS path. 567 7.1. Procedures for Segment Routing LSP ping 569 To perform LSP ping procedure on an SR-MPLS-Path from PE1 to PE4 570 consisting of label stacks [N-P1,N-ASBR1,EPE-ASBR1-ASBR4, N-PE4], The 571 remote end(PE4) needs IP connectivity to head end(PE1) for the 572 Segment Routing ping to succeed, because echo reply needs to travel 573 back to PE1 from PE4. But in typical deployment scenario there will 574 be no IP route from PE4 to PE1 as they belong to different ASes. 576 PE1 adds return Path from PE4 to PE1 in the MPLS echo request using 577 multiple Segments in "Reply Path TLV" as defined above. An example 578 return path TLV for PE1 to PE4 for LSP ping is [N-ASBR4, EPE- 579 ASBR4-ASBR1, N-PE1]. An implementation may also build a return Path 580 consisting of labels to reach its own AS. Once the label stack is 581 popped-off the echo reply message will be exposed. The further 582 packet forwarding will be based on IP lookup. An example return Path 583 for this case could be [N-ASBR4, EPE-ASBR4-ASBR1]. 585 On receiving MPLS echo request PE4 first validates FEC in the echo 586 request. PE4 then builds label stack to send the response from PE4 587 to PE1 by copying the labels from "Reply Path TLV". PE4 builds the 588 echo reply packet with the MPLS label stack constructed and imposes 589 MPLS headers on top of echo reply packet and sends out the packet 590 towards PE1. This Segment List stack can successfully steer reply 591 back to Head-end node(PE1). 593 7.2. Procedures for Segment Routing LSP Traceroute 595 Traceroute procedure involves visiting every node on the path and 596 echo reply sent from every node. In this section, we describe the 597 traceroute mechanims when the headend/PMS has complete visibility of 598 the database. Headend/PMS computes the return path from each node in 599 the entire SR-MPLS path that is being tracerouted. The return path 600 computation is implementation dependant. As the headend/PMS 601 completely controls the return path, it can use proprietary 602 computations to build the return path. 604 One of the ways the return path can be built, is to use the principle 605 of building label stacks by adding each domain border node's Node SID 606 on the return path label stack as the traceroute progresses. For 607 inter-AS networks, in addition to border node's Node-SID, EPE-SID in 608 the reverse direction also need to be added to the label stack. 610 The Inter-domain/inter-as traceroute procedure uses the TTL expiry 611 mechansim as specified in [RFC8029] and [RFC8287]. Every echo 612 request packet Headend/PMS MUST include the appropriate return path 613 in the Reply Path TLV. The node that receives the echo request MUST 614 follow procedures described in section Section 6.1 and section 615 Section 6.2 to send out echo reply. 617 For Example: 619 Let us consider a topology from Figure 1. Let us consider a SR-MPLS 620 path [N-P1,N-ASBR1,EPE-ASBR1-ASBR4, N-PE4]. The traceroute is being 621 executed for this inter-AS path for destination PE4. PE1 sends first 622 echo request with TTL set to 1 and includes return path TLV 623 consisting of Type 1 Segment containing label derived from its own SR 624 Global Block (SRGB). Note that the type of segment used in 625 constructing the return Path is local policy. If the entire network 626 has same SRGB configured, Type 1 segments can be used.The TTL expires 627 on P1 and the P1 sends echo reply using the return path. Note that 628 implementations may choose to exclude return path TLV until 629 traceroute reaches the first domain border as the return IP path to 630 PE1 is expected to be available inside the first domain. 632 TTL is set to 2 and the next echo request is sent out. Until the 633 traceroute procedure reaches the domain border node ASBR1, same 634 return path TLV consisting of single Label (PE1's node Label)is used. 635 When echo request reaches ASBR1, and echo reply is received, the next 636 echo request needs to include additional label as ASBR1 is a border 637 node. The return path TLV is built based on the forward path. As 638 the forward path consists of EPE-ASBR1-ASBR4, an EPE-SID in the 639 reverse direction is included in the return path TLV. The return 640 path now consists of two labels [N-PE1, EPE-ASBR4-ASBR1]. The echo 641 reply from ASBR4 will use this return path to send the reply. 643 The next echo request after visiting the border node ASBR4 will 644 update the return path with Node-SID label of ASBR4. The return path 645 beyond ASBR4 will be [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4]. This same 646 return path is used until the traceroute procedure reaches next set 647 of border nodes. When there are multiple ASes the traceroute 648 procedure will continue by adding a set of Node labels and EPE labels 649 as the border nodes are visited. 651 Note that the above return path building procedure requires the 652 database of all the domains to be available at the headend/PMS. 654 The above description assumed the same SRGB is configured on all 655 nodes along the path. The SRGB may differ from one node to another 656 node and the SR architecture [RFC8402] allows the nodes to use 657 different SRGB. In such scenarios PE1 sends Type 3 (or Type 4 in 658 case of IPv6 networks) segment with Node address of PE1 and with 659 optional MPLS SID associated with the Node address. The receiving 660 node derives the label for the return path based on its own SRGB. 661 When the traceroute procedure crosses the border ASBR1, headend PE1 662 should send type 1 segment for N-PE1 based on the label derived from 663 ASBR1's SRGB. This is required because in AS2, ASBR4, P3, P4 etc may 664 not have the topology information to derive SRGB for PE1. After the 665 traceroute procedure reaches ASBR4 the return path will be 666 [N-PE1(type1 with label based on ASBR1's SRGB), EPE-ASBR4-ASBR1, 667 N-ASBR4 (Type 3)]. 669 In order to extend the example to multiple ASes consisting of 3 or 670 more ASes, let us consider a traceroute from PE1 to PE5 in Figure 1. 671 In this example, the PE1 to PE5 path has to cross 3 domains AS1, AS2 672 and AS3. Let us consider a path from PE1 to PE5 that goes through 673 [PE1, ASBR1, ASBR4, ASBR6, ASBR8,PE5]. When the traceroute procedure 674 is visiting the nodes in AS1, the Reply path TLV sent from headend 675 consists of [N-PE1]. When the traceroute procedure reaches the 676 ASBR4, the return Path consists of [N-PE1, EPE-ASBR4-ASBR1]. While 677 visiting nodes in AS2, the traceroute procedure consists of Reply 678 Path TLV [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4]. similarly, while visiting 679 the ASBR8 Reply Path TLV adds the EPE SID from ASBR8 to ASBR6. While 680 visiting nodes in AS3 Node-SId of ASBR8 would also be added which 681 makes the return Path [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4, EPE- 682 ASBR8-ASBR6, N-ASBR8] 684 Let us consider another example from topology Figure 2. This 685 topology consists of multi-domain IGP with common border node between 686 the domains. This could be achieved with multi-area or multi-level 687 IGP or multiple instances of IGP deployed on same node. The return 688 path computation for this topology is similar to the multi-AS 689 computation except that the return path consists of single border 690 node label. When traceroute procedure is visiting node P, the return 691 path consists of [N-PE1, N-ABR1]. 693 8. Building Reply Path TLV dynamically 695 In some cases, the head-end may not have complete visibility of 696 Inter-AS/Inter-domain topology. In such cases, it can rely on 697 downstream routers to build the reverse path for MPLS traceroute 698 procedures. For this purpose, Reply Path TLV in the echo reply 699 corresponds to the return path to be used in next echo request. 701 Value Meaning 702 ------ ---------------------- 703 TBA1 Use Reply Path TLV in echo reply for next echo request. 705 Figure 7: Reply path return Code 707 8.1. The procedures to build the return path 709 In order to dynamically build the return Path for traceroute 710 procedures, the domain border nodes along the path being tracerouted 711 MUST support the procedures described in this section. Local policy 712 on the domain border nodes SHOULD determine whether the domain border 713 node participates in building return path dynamically during 714 traceroute. 716 Headend/PMS node MAY include its own node label while initiating 717 traceroute procedure. When an ABR receives the echo request, if the 718 local policy implies building dynamic return path, ABR MUST include 719 its own Node label. If there is a Reply Path TLV included in the 720 received echo request message, the ABR's node label is added before 721 the existing segments. The type of segment added is based on local 722 policy. In cases when SRGB is not uniform across the network, it is 723 RECOMMENDED to add type 3 or type 4 segment. If the existing segment 724 in the Reply Path TLV is a type 3/type 4 segment, that segment MUST 725 be converted to Type 1 segment based on ABR's own SRGB.This is 726 because downstream nodes will not know what SRGB to use to translate 727 the IP address to a label. As the ABR added its own Node label, it 728 is guaranteed that this ABR will be in the return path and will be 729 forwarding the traffic based on next label after its own label. 731 When an ASBR receives an echo request from another AS, and ASBR is 732 configured to build the return path dynamically, ASBR MUST build a 733 Reply Path TLV and include it in the echo reply. The Reply Path TLV 734 MUST consist of its own node label and an EPE-SID to the AS from 735 where the traceroute message was received. A Reply path return code 736 of TBA1 MUST be set in the echo reply to indicate that next echo 737 request should use the return Path from the Reply Path TLV in the 738 echo reply. ASBR MUST locally decide the outgoing interface for the 739 echo reply packet. Generally, remote ASBR will choose interface on 740 which the incoming OAM packet was receieved to send the echo reply 741 out. Reply Path TLV is built by adding two segment sub TLVs. The 742 top segment sub TLV consists of the ASBR's Node SID and second 743 segment consists of the EPE SID in the reverse direction to reach the 744 AS from which the OAM packet was received.The type of segment chosen 745 to build Reply Path TLV is a local policy. It is RECOMMENDED to use 746 type 3/type4 segment for the top segment when the SRGB is not 747 gurateed to be uniform in the domain. 749 Irrespective of which type of segment is included in the Reply Path 750 TLV, the responder of echo request MUST always translate the Reply 751 Path TLV to a label stack and build MPLS header for the the echo 752 reply packet. This procedure can be applied to an end-to-end path 753 consisting of multiple ASes. Each ASBR that receives echo request 754 from another AS adds its Node-SID and EPE-SID on top of existing 755 segments in the Reply Path TLV. 757 An ASBR that receives the echo request from a neighbor belonging to 758 same AS, MUST look at the Reply Path TLV received in the echo 759 request. If the Reply Path TLV consists of a Type 3/Type 4 segment, 760 it MUST convert the Type 3/4 segment to Type 1 segment by deriving 761 label from its own SRGB. The ASBR MUST set the reply path return 762 code to TBA1 and send the newly constructed Reply Path TLV in the 763 echo reply. 765 Internal nodes or non domain border nodes MAY not set the Reply Path 766 TLV return code to TBA1 in the echo reply message as there is no 767 change in the return Path. In these cases, the headend node/PMS that 768 initiates the traceroute procedure MUST continue to send previously 769 sent Reply Path TLV in the echo request message in every next echo 770 request. 772 Note that an ASBR's local policy may prohibit it from participating 773 in the dynamic traceroute procedures. If such an ASBR is encountered 774 in the forward path, dynamic return path building procedures will 775 fail. In such cases, ASBR that supports this document MUST set the 776 return code TBA2 to indicate local policies do not allow the dynamic 777 return path building. 779 Value Meaning 780 ------ --------------------------------------------------- 781 TBA2 Local policy does not allow dynamic return Path building. 783 Figure 8: Local policy return Code 785 8.2. Details with example 787 Let us consider a topology from Figure 1. Let us consider a SR 788 policy path built from PE1 to PE4 with a label stack as below. N-P1, 789 N-ASBR1, EPE-ASBR1-ASBR4, N-PE4. PE1 begins traceroute with TTL set 790 to 1 and includes [N-PE1] in the Reply Path TLV. The traceroute 791 packet TTL expires on P1 and P1 processes the traceroute as per the 792 procedures described in [RFC8029] and [RFC8287]. P1 sends echo reply 793 with the same return Path TLV with reply path return code set to 6. 794 The return code of the echo reply itself is set to the return code as 795 per [RFC8029] and [RFC8287]. This traceroute doesn't need any 796 changes to the Reply Path TLV till it leaves AS1. The same Reply 797 Path TLV that is received may be included in the echo reply by P1 and 798 P2 or no Reply Path TLV included so that headend continues to use 799 same return path in echo request that it used to send previous echo 800 request. 802 When ASBR1 receives the echo request, in case it recieved type3/type 803 4 segment in the Reply Path TLV in the echo request, it converts that 804 type 3/4 segment to Type 1 based on its own SRGB. When ASBR4 805 receives the echo request, it should form this Reply Path TLV using 806 its own Node SID(N-ASBR4) and EPE SID (EPE-ASRB4-ASBR1) labels and 807 set the reply path return code to TBA1. Then PE1 should use this 808 Reply Path TLV in subsequent echo requests. In this example, when 809 the subsequent echo request reaches P3, it should use this Reply Path 810 TLV for sending the echo reply. The same Reply Path TLV is 811 sufficient for any router in AS2 to send the reply. Because the 812 first label(N-ASBR4) can direct echo reply to ASBR4 and second one 813 (EPE-ASBR4-ASBR1) to direct echo reply to AS1. Once echo reply 814 reaches AS1, normal IP forwarding or the N-PE1 helps it to reach PE1. 816 The example described in above paragraphs can be extended to multiple 817 ASes by following the same procedure of each ASBR adding Node-SID and 818 EPE-SID on receieving echo request from neighboring AS. 820 Let us consider a topology from Figure 2. It consists of multiple 821 IGP domains with multiple area/levels or separate IGP instances. 822 There is a single border node that seperates the two domains. In 823 this case, PE1 sends traceroute packet with TTL set to 1 and includes 824 N-PE1 in the return path TLV. ABR1 receives the echo request and 825 while sending echo reply adds its own node Label to the Reply Path 826 TLV and sets the Reply path return code to TBA1. The Reply path TLV 827 in the echo reply from ABR1 consists of [N-PE1, N-ABR1]. Next echo 828 request with TTL 2 reaches P node. It is an internal node so it does 829 not change the return Path. echo request with TTL 3 reaches ABR2 and 830 it adds its own Node label so the return path TLV sent in echo reply 831 will be [N-PE1, N-ABR1, N-ABR2]. echo request with TTL 4 reaches PE4 832 and it sends echo reply return code as Egress. PE4 does not include 833 any Reply Path TLV in echo reply. The above example assumes uniform 834 SRGB throughout the domain. In case of different SRGBs, the top 835 segment will be a type 3/4 segment and all other segments will be 836 type 1. Each border node converts the type 3/type 4 segment to type 837 1 before adding its own segment to the Reply Path TLV. 839 9. Security Considerations 841 The procedures described in this document enable LSP ping and 842 traceroute to be executed across multiple domains or multiple ASes 843 that belong to same adminstration or closely co-operating 844 administration. It is assumed that sharing domain internal 845 information across such domains does not pose security risk. However 846 procedures described in this document may be used by an attacker to 847 extract the domain internal information. An operator MUST deploy 848 appropriate filter policies as described in [RFC8029] to restrict the 849 LSP ping/traceroute packets based on origin. It is also suggested 850 that an operator SHOULD deploy security mechanisms such as MACSEC on 851 inter-domain links or security vulnerable links to prevent spoofing 852 attacks. 854 10. IANA Considerations 856 Sub-TLVs for TLV Types 1, 16, and 21 858 SID only in the form of MPLS label : TBD (Range 32768-65535) 860 IPv4 Node Address with optional SID for SR-MPLS : TBD (Range 861 32768-65535) 863 IPv6 Node Address with optional SID for SR-MPLS : TBD (Range 864 32768-65535) 866 Reply Path Return Codes Registry 868 TBA1:Use Reply Path TLV in echo reply for next echo request. 870 TBA2:Local policy does not allow dynamic return Path building. 872 11. Contributors 874 1.Carlos Pignataro 876 Cisco Systems, Inc. 878 cpignata@cisco.com 880 2. Zafar Ali 882 Cisco Systems, Inc. 884 zali@cisco.com 886 12. Acknowledgments 888 Thanks to Bruno Decreane for suggesting use of generic Segment sub- 889 TLV. Thanks to Adrian Farrel, Huub van Helvoort, Dhruv Dhody, 890 Dongjie, for careful review and comments. Thanks to Mach Chen for 891 suggesting to use Reply Path TLV. Thanks to Gregory Mirsky for 892 detailed review which helped improve the readability of the document 893 to a great extent. 895 13. References 896 13.1. Normative References 898 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 899 Requirement Levels", BCP 14, RFC 2119, 900 DOI 10.17487/RFC2119, March 1997, 901 . 903 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 904 "Return Path Specified Label Switched Path (LSP) Ping", 905 RFC 7110, DOI 10.17487/RFC7110, January 2014, 906 . 908 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 909 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 910 Switched (MPLS) Data-Plane Failures", RFC 8029, 911 DOI 10.17487/RFC8029, March 2017, 912 . 914 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 915 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 916 May 2017, . 918 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 919 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 920 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 921 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 922 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 923 . 925 [RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E., 926 and D. Afanasiev, "Segment Routing Centralized BGP Egress 927 Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August 928 2021, . 930 13.2. Informative References 932 [I-D.ietf-idr-bgpls-segment-routing-epe] 933 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 934 S., and J. Dong, "Border Gateway Protocol - Link State 935 (BGP-LS) Extensions for Segment Routing BGP Egress Peer 936 Engineering", Work in Progress, Internet-Draft, draft- 937 ietf-idr-bgpls-segment-routing-epe-19, 16 May 2019, 938 . 941 [I-D.ietf-spring-segment-routing-policy] 942 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 943 P. Mattes, "Segment Routing Policy Architecture", Work in 944 Progress, Internet-Draft, draft-ietf-spring-segment- 945 routing-policy-14, 25 October 2021, 946 . 949 [RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G. 950 Swallow, Ed., "Relayed Echo Reply Mechanism for Label 951 Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743, 952 January 2016, . 954 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 955 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 956 . 958 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 959 Decraene, B., Litkowski, S., and R. Shakir, "Segment 960 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 961 July 2018, . 963 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 964 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 965 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 966 2018, . 968 [RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., 969 Henderickx, W., and D. Cooper, "Interconnecting Millions 970 of Endpoints with Segment Routing", RFC 8604, 971 DOI 10.17487/RFC8604, June 2019, 972 . 974 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 975 Decraene, B., Litkowski, S., and R. Shakir, "Segment 976 Routing with the MPLS Data Plane", RFC 8660, 977 DOI 10.17487/RFC8660, December 2019, 978 . 980 Authors' Addresses 982 Shraddha Hegde 983 Juniper Networks Inc. 984 Exora Business Park 985 Bangalore 560103 986 KA 987 India 989 Email: shraddha@juniper.net 990 Kapil Arora 991 Juniper Networks Inc. 993 Email: kapilaro@juniper.net 995 Mukul Srivastava 996 Juniper Networks Inc. 998 Email: msri@juniper.net 1000 Samson Ninan 1001 Ciena 1003 Email: sninan@ciena.com 1005 Nagendra Kumar 1006 Cisco Systems, Inc. 1008 Email: naikumar@cisco.com