idnits 2.17.1 draft-ninan-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 (April 16, 2021) is 1099 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 495, but not defined == Missing Reference: 'N-ASBR1' is mentioned on line 495, but not defined == Missing Reference: 'EPE-ASBR1-ASBR4' is mentioned on line 495, but not defined == Missing Reference: 'N-PE4' is mentioned on line 495, but not defined == Missing Reference: 'N-ASBR4' is mentioned on line 537, but not defined == Missing Reference: 'EPE-ASBR4-ASBR1' is mentioned on line 537, but not defined == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mpls-interas-lspping' is defined on line 676, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 ** Downref: Normative reference to an Informational draft: draft-ietf-spring-segment-routing-central-epe (ref. 'I-D.ietf-spring-segment-routing-central-epe') == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). 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: October 18, 2021 Juniper Networks Inc. 6 S. Ninan 7 Individual Contributor 8 N. Kumar 9 Cisco Systems, Inc. 10 April 16, 2021 12 PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks 13 draft-ninan-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 LSP Ping and traceroute 22 procedures when an SR end-to-end path spans across multiple ASes or 23 domains. This document describes mechanisms to facilitae LSP ping 24 and traceroute in inter-AS/inter-domain SR networks in an efficient 25 manner with simple OAM protocol extension which uses dataplane 26 forwarding alone for sending Echo-Reply. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on October 18, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Inter domain networks with multiple IGPs . . . . . . . . . . 4 69 3. Return Path TLV . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Segment sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. Type 1: SID only, in the form of MPLS Label . . . . . . . 5 72 4.2. Type 3: IPv4 Node Address with optional SID for SR-MPLS . 7 73 4.3. Type 4: IPv6 Node Address with optional SID for SR MPLS . 8 74 4.4. Segment Flags . . . . . . . . . . . . . . . . . . . . . . 9 75 5. SRv6 Dataplane . . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 10 77 6.1. Sending an Echo-Request . . . . . . . . . . . . . . . . . 10 78 6.2. Receiving an Echo-Request . . . . . . . . . . . . . . . . 10 79 6.3. Sending an Echo-Reply . . . . . . . . . . . . . . . . . . 10 80 7. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 11 81 7.1. Procedures for Segment Routing LSP ping . . . . . . . . . 11 82 7.2. Procedures for Segment Routing LSP Traceroute . . . . . . 12 83 8. Building Reverse Path Segment List TLV dynamically . . . . . 12 84 8.1. The procedures to build the reverse path . . . . . . . . 13 85 8.2. Details with example . . . . . . . . . . . . . . . . . . 13 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 89 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 13.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 +----------------+ 98 | Controller/PMS | 99 +----------------+ 101 |---------AS1----------| |--------AS2----------| 103 ASBR2-------ASBR3 104 / \ 105 / \ 106 PE1------P1------P2 P3------P4------PE4 107 \ / 108 \ / 109 ASBR1-------ASBR4 111 Figure 1: Inter-AS Segment Routing topology 113 Many network deployments have built their networks consisting of 114 multiple Autonomous Systems either for ease of operations or as a 115 result of network mergers and acquisitions. Segment Routing can be 116 deployed in such scenarios to provide end to end paths, traversing 117 multiple Autonomous systems(AS). These paths consist of Segment 118 Identifiers(SID) of different type as per [RFC8402]. 120 [RFC8660] specifies the forwarding plane behaviour to allow Segment 121 Routing to operate on top of MPLS data plane. 122 [I-D.ietf-spring-segment-routing-central-epe] describes BGP peering 123 SIDs, which will help in steering packet from one Autonomous system 124 to another. Using above SR capabilities, paths which span across 125 multiple Autonomous systems can be created. 127 For example Figure 1 describes an inter-AS network scenario 128 consisting of ASes AS1 and AS2. Both AS1 and AS2 are Segment Routing 129 enabled and the EPE links have EPE labels configured and advertised 130 via [I-D.ietf-idr-bgpls-segment-routing-epe]. Controller or head-end 131 can build end-to-end Traffic-Engineered path consisting of Node-SIDs, 132 Adjacency-SIDs and EPE-SIDs. It is advantageous for operations to be 133 able to perform LSP ping and traceroute procedures on these inter-AS 134 SR paths. LSP ping/traceroute procedures use ip connectivity for 135 Echo-reply to reach the head-end. In inter-AS networks, ip 136 connectivity may not be there from each router in the path.For 137 example in Figure 1 P3 and P4 may not have ip connectivity for PE1. 139 [RFC8403] describes mechanisms to carry out the MPLS ping/traceroute 140 from a PMS. It is possible to build GRE tunnels or static routes to 141 each router in the network to get IP connectivity for the reverse 142 path. This mechanism is operationally very heavy and requires PMS to 143 be capable of building huge number of GRE tunnels, which may not be 144 feasible. 146 It is not possible to carry out LSP ping and Traceroute functionality 147 on these paths to verify basic connectivity and fault isolation using 148 existing LSP ping and Traceroute mechanism([RFC8287] and [RFC8029]). 149 This is because, there exists no IP connectivity to source address of 150 ping packet, which is in a different AS, from the destination of 151 Ping/Traceroute. 153 [RFC7743] describes a Echo-relay based solution based on advertising 154 a new Relay Node Address Stack TLV containing stack of Echo-relay ip 155 addresses. That mechanism requires the return ping packet to reach 156 the control plane on every relay node. 158 This document describes a new mechanism which is efficient and simple 159 and can be easily deployed in SR networks. This mechanism uses 160 Return path TLV [RFC7110] to convey the reverse path. Three new sub- 161 TLVs for Return path TLV are defined, that faciliate encoding segment 162 routing label stack. The TLV can either be derived by a smart 163 application or controller which has a full topology view. This 164 document also proposes mechanisms to derive the Return path 165 dynamically during traceroute procedures. 167 2. Inter domain networks with multiple IGPs 169 |-Domain 1|-------Domain 2-----|--Domain 3-| 171 PE1------ABR1--------P--------ABR2------PE4 172 \ / \ /\ / 173 -------- ----------------- ------- 174 BGP-LU BGP-LU BGP-LU 176 Figure 2: Inter-domain networks with multiple IGPs 178 When the network consists of large number of nodes, the nodes are 179 seggregated into multiple IGP domains. The connectivity to the 180 remote PEs can be achieved using BGP-LU [RFC3107] or by stacking the 181 labels for each domain as described in [RFC8604]. It is useful to 182 support mpls ping and traceroute mechanisms for these networks. The 183 procedures described in this document for constructing Return path 184 TLV and its use in echo-reply is equally applicable to networks 185 consisting of multiple IGP domains that use BGP-LU or label stacking. 187 3. Return Path TLV 189 Segment Routing networks statically assign the labels to nodes and 190 PMS/Head-end may know the entire database. The reverse path can be 191 built from PMS/Head-end by stacking segments for the reverse path. 192 Return path TLV as defined in [RFC7110] is used to carry the return 193 path. While using the procedures described in this document, the 194 reply mode MUST be set to 5 and Return Path TLV MUST be included in 195 the Echo-Request message. The procedures decribed in [RFC7110] are 196 applicable for constructing the Return Path TLV. This document 197 define three new sub-TLVs to encode the Segment Routing path 199 The type of segment that the head-end chooses to send in the Return 200 Path TLV is governed by local policy. 202 Some networks may consist of pure IPV4 domains and Pure IPv6 domains. 203 Handling end-to-end MPLS OAM for such networks is out of scope for 204 this document. It is recommended to use dual stack in such cases and 205 use end-to-end IPv6 addresses for MPLS ping and trace route 206 procedures. 208 4. Segment sub-TLV 210 [I-D.ietf-spring-segment-routing-policy] defines various types of 211 segments. The segments applicable to this documents have been re- 212 defined here. One or more segment sub-TLV can be included in the 213 Return Path TLV. The segment sub-TLVs included in a Return Path TLV 214 MAY be of different types. 216 Below types of segment sub-TLVs are applicable for the Reverse Path 217 Segment List TLV. 219 Type 1: SID only, in the form of MPLS Label 221 Type 3: IPv4 Node Address with optional SID 223 Type 4: IPv6 Node Address with optional SID for SR MPLS 225 4.1. Type 1: SID only, in the form of MPLS Label 227 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 228 MPLS label. The format is as follows: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Length | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Flags | RESERVED | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Label | TC |S| TTL | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 3: Type 1 Segment sub-TLV 242 where: 244 Type: TBD1(to be assigned by IANA from the registry "Sub-TLV Target 245 FEC stack TLV"). 247 Length is 8. 249 Flags: 1 octet of flags as defined in Section Section 4.4. 251 RESERVED: 3 octets of reserved bits. SHOULD be unset on transmission 252 and MUST be ignored on receipt. 254 Label: 20 bits of label value. 256 TC: 3 bits of traffic class 258 S: 1 bit of bottom-of-stack. 260 TTL: 1 octet of TTL. 262 The following applies to the Type-1 Segment sub-TLV: 264 The S bit SHOULD be zero upon transmission, and MUST be ignored upon 265 reception. 267 If the originator wants the receiver to choose the TC value, it sets 268 the TC field to zero. 270 If the originator wants the receiver to choose the TTL value, it sets 271 the TTL field to 255. 273 If the originator wants to recommend a value for these fields, it 274 puts those values in the TC and/or TTL fields. 276 The receiver MAY override the originator's values for these fields. 277 This would be determined by local policy at the receiver. One 278 possible policy would be to override the fields only if the fields 279 have the default values specified above. 281 4.2. Type 3: IPv4 Node Address with optional SID for SR-MPLS 283 The Type-3 Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 284 and an optional SID in the form of an MPLS label. The format is as 285 follows: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Length | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Flags | RESERVED | SR Algorithm | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | IPv4 Node Address (4 octets) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | SID (optional, 4 octets) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 4: Type 3 Segment sub-TLV 301 where: 303 Type: TBD3(to be assigned by IANA from the registry "Sub-TLV Target 304 FEC stack TLV"). 306 Length is 8 or 12. 308 Flags: 1 octet of flags as defined in Section Section 4.4. 310 SR Algorithm: 1 octet specifying SR Algorithm as described in section 311 3.1.1 in [RFC8402], when A-Flag as defined in Section Section 4.4is 312 present. SR Algorithm is used by the receiver to derive the Label. 313 When A-Flag is not encoded, this field SHOULD be unset on 314 transmission and MUST be ignored on receipt. 316 RESERVED: 2 octets of reserved bits. SHOULD be unset on transmission 317 and MUST be ignored on receipt. 319 IPv4 Node Address: a 4 octet IPv4 address representing a node. 321 SID: 4 octet MPLS label. 323 The following applies to the Type-3 Segment sub-TLV: 325 The IPv4 Node Address MUST be present. 327 The SID is optional and specifies a 4 octet MPLS SID containing 328 label, TC, S and TTL as defined in Section Section 4.1. 330 If length is 8, then only the IPv4 Node Address is present. 332 If length is 12, then the IPv4 Node Address and the MPLS SID are 333 present. 335 4.3. Type 4: IPv6 Node Address with optional SID for SR MPLS 337 The Type-4 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 338 and an optional SID in the form of an MPLS label. The format is as 339 follows: 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type | Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Flags | RESERVED | SR Algorithm | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 // IPv6 Node Address (16 octets) // 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | SID (optional, 4 octets) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 5: Type 4 Segment sub-TLV 355 where: 357 Type: TBD4(to be assigned by IANA from the registry "Sub-TLV Target 358 FEC stack TLV"). 360 Length is 20 or 24. 362 Flags: 1 octet of flags as defined in Section Section 4.4. 364 SR Algorithm: 1 octet specifying SR Algorithm as described in section 365 3.1.1 in [RFC8402], when A-Flag as defined in Section Section 4.4 is 366 present. SR Algorithm is used by the receiver to derive the label. 367 When A-Flag is not encoded, this field SHOULD be unset on 368 transmission and MUST be ignored on receipt. 370 RESERVED: 2 octets of reserved bits. SHOULD be unset on transmission 371 and MUST be ignored on receipt. 373 IPv6 Node Address: a 16 octet IPv6 address representing a node. 375 SID: 4 octet MPLS label. 377 The following applies to the Type-4 Segment sub-TLV: 379 The IPv6 Node Address MUST be present. 381 The SID is optional and specifies a 4 octet MPLS SID containing 382 label, TC, S and TTL as defined in Section Section 4.1 . 384 If length is 20, then only the IPv6 Node Address is present. 386 If length is 24, then the IPv6 Node Address and the MPLS SID are 387 present. 389 4.4. Segment Flags 391 The Segment Types described above MAY contain following flags in the 392 "Flags" field (codes to be assigned by IANA from the registry "Return 393 path sub-TLV Flags" ) 395 0 1 2 3 4 5 6 7 396 +-+-+-+-+-+-+-+-+ 397 | |A| | 398 +-+-+-+-+-+-+-+-+ 400 Figure 6: Flags 402 where: 404 A-Flag: This flag indicates the presence of SR Algorithm id in the 405 "SR Algorithm" field applicable to various Segment Types. 407 Unused bits in the Flag octet SHOULD be set to zero upon transmission 408 and MUST be ignored upon receipt. 410 The following applies to the Segment Flags: 412 A-Flag is applicable to Segment Types 3, 4. If A-Flag appears with 413 any other Segment Type, it MUST be ignored. 415 5. SRv6 Dataplane 417 SRv6 dataplane is not in the scope of this document and will be 418 addressed in a separate document. 420 6. Detailed Procedures 422 6.1. Sending an Echo-Request 424 In the inter-AS scenario when there is no reverse path connectivity, 425 LSP ping initiator MUST add a Return Path TLV in the Echo-request 426 message. The reverse Segment List MUST correspond to the return path 427 from the egress. The Return Path TLV must contain the Segment 428 Routing Path in the reverse direction encoded as an ordered list of 429 Segments. The first Segment MUST correspond to the top Segment in 430 MPLS header that the responder MUST use while sending the Echo-reply. 432 6.2. Receiving an Echo-Request 434 As described in [RFC7110], when Reply mode is set to 5 (Reply via 435 Specified Path), The Echo-Request MUST contain the Return path TLV. 436 Absence of Reply path TLV is treated as malformed Echo-Request.When a 437 Return Path TLV is received, and the responder that supports 438 processing it, it MUST use the Segments in Return Path TLV to build 439 the echo-reply. The responder MUST follow the normal FEC validation 440 procedures as described in [RFC8029] and [RFC8287] and this document 441 does not suggest any change to those procedures. When the Echo-reply 442 has to be sent out the Return Path TLV is used to construct the MPLS 443 packet to send out. 445 6.3. Sending an Echo-Reply 447 The Echo-Reply message is sent as MPLS packet with a MPLS label 448 stack. The Echo-Reply message MUST be constructed as described in 449 the [RFC8029]. An MPLS packet is constructed with Echo-reply in the 450 payload. The top label MUST be constructed from the first Segment 451 from the Return Path TLV. The remaining labels MUST follow the order 452 from the Return Path TLV. The responder MAY check the reachability 453 of the top label in its own LFIB before sending the Echo-Reply. In 454 certain scenarios the head-end may choose to send Type 2/Type 3 455 segments consisting of IPV4 address and SID. In such cases that node 456 sending the echo-reply MUST derive the MPLS labels from SIDs based on 457 SRGB and encode the echo-reply with MPLS labels. 459 The return code MUST be set as described in [RFC7110]. The Return 460 Path TLV MUST be included in Echo-Reply indicating the specified 461 return path that the echo reply message is required to follow. 463 7. Detailed Example 465 An example topology is given in Figure 1 . This will be used in 466 below sections to explain LSP Ping and Traceroute procedures. The 467 PMS/Head-end has complete view of topology. PE1, P1, P2, ASBR1 and 468 ASBR2 are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are in AS2. 470 AS1 and AS2 have Segment Routing enabled. IGPs like OSPF/ISIS are 471 used to flood SIDs in each Autonomous System. The ASBR1, ASBR2, 472 ASBR3, ASBR4 advertise BGP EPE SIDs for the inter-AS links. Topology 473 of AS1 and AS2 are advertised via BGP-LS to the controller/PMS or 474 Head-end node. The EPE-SIDs are also advertised via BGP-LS as 475 described in [I-D.ietf-idr-bgpls-segment-routing-epe] 477 The description in the document uses below notations for Segment 478 Identifiers(SIDs). 480 Node SIDs : N-PE1, N-P1, N-ASBR1 etc. 482 Adjacency SIDs : Adj-PE1-P1, Adj-P1-P2 etc. 484 EPE SIDS : EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 etc. 486 Let us consider a traffic engineered path built from PE1 to PE4 with 487 Segment List stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 488 for following procedures. This stack may be programmed by 489 controller/PMS or Head-end router PE1 may have imported the whole 490 topology information from BGP-LS and computed the inter-AS path. 492 7.1. Procedures for Segment Routing LSP ping 494 To perform LSP ping procedure on an SR-Path from PE1 to PE4 495 consisting of label stacks [N-P1,N-ASBR1,EPE-ASBR1-ASBR4, N-PE4], The 496 remote end(PE4) needs IP connectivity to head end(PE1) for the 497 Segment Routing ping to succeed, because Echo-reply needs to travel 498 back to PE1 from PE4. But in typical deployment scenario there will 499 be no ip route from PE4 to PE1 as they belong to different ASes. 501 PE1 adds Return Path from PE4 to PE1 in the MPLS Echo-request using 502 multiple Segments in "Return Path TLV" as defined above. An example 503 return path Segment List for PE1 to PE4 for LSP ping is [N-ASBR4, 504 EPE-ASBR4-ASBR1, N-PE1]. An implementation may also build a Return 505 Path consisting of labels to reach its own AS. Once the label stack 506 is popped-off the Echo-reply message will be exposed.The further 507 packet forwarding will be based on ip lookup. An example Return Path 508 for this case could be [N-ASBR4, EPE-ASBR4-ASBR1]. 510 On receiving MPLS Echo-request PE4 first validates FEC in the Echo- 511 request. PE4 then builds label stack to send the response from PE4 512 to PE1 by copying the labels from "Return Path TLV". PE4 builds the 513 Echo-reply packet with the MPLS label stack constructed and imposes 514 MPLS headers on top of Echo-reply packet and sends out the packet 515 towards PE1. This Segment List stack can successfully steer reply 516 back to Head-end node(PE1). 518 7.2. Procedures for Segment Routing LSP Traceroute 520 As described in the procedures for LSP ping, the reverse Segment List 521 may be sent from head-end in which case the LSP Traceroute procedures 522 are similar to LSP ping. The head-end constructs the Return Path TLV 523 and the egress node uses the Return Path to construct the Echo-reply 524 packet header. Head-end/PMS is aware of the return path from every 525 node visited in the network and builds the Return Path segment list 526 for every visited node accordingly. 528 For Example: 530 For the same traffic engineered path PE1 to PE4 mentioned in above 531 sections, let us assume there is no reverse path available from the 532 nodes ASBR4 to PE1. During the Traceroute procedure, when PE1 has to 533 visit ASBR4, it builds return Path TLV and includes label to the 534 border-node which has the route to, PE1. In this example the Return 535 Path TLV will contain [EPE-ASBR4-ASBR1]. Further down the traceroute 536 procedure when P3 or P4 node is being visited, PE1 build the Return 537 Path TLV containing [N-ASBR4, EPE-ASBR4-ASBR1]. The Echo-reply will 538 be an MPLS packet with this label stack and will be forwarded to PE1. 540 8. Building Reverse Path Segment List TLV dynamically 542 In some cases, the head-end may not have complete visibility of 543 Inter-AS topology. In such cases, it can rely on downstream routers 544 to build the reverse path for mpls traceroute procedures. For this 545 purpose, new return code is defined which implies the Return Path TLV 546 in the Echo-reply corresponds to the return path to be used in next 547 Echo-Request. 549 Value Meaning 550 ------ ---------------------- 551 0x0006 Use Return Path TLV in Echo-Reply for next Echo-Request. 553 Figure 7: Return Code 555 8.1. The procedures to build the reverse path 557 When an ASBR receives an echo-request from another AS, and ASBR is 558 configured to build the return path dynamically, ASBR MUST build a 559 Return Path TLV that should be used in next Echo-request and add it 560 in echo-reply. ASBR MUST locally decide the outgoing interface for 561 the echo-reply packet. Generally, remote ASBR will choose interface 562 on which the incoming OAM packet was receieved to send the echo-reply 563 out. Return Path TLV is built by adding two segment sub TLVs. The 564 top segment sub TLV consists of the ASBR's Node SID and second 565 segment consists of the EPE SID in the reverse direction to reach the 566 AS from which the OAM packet was received.The type of segment chosen 567 to build Return Path TLV is implementation dependent. In cases where 568 the AS is configured with different SRGBs, the Node SID of the ASBR 569 should be represented using type 3 segment so that all the nodes 570 inside the AS can correctly translate the Node-SID to a label. 572 Irrespective of which type of segment is included in the Return Path 573 TLV, the responder of echo-request always translates the Return Path 574 TLV to a label stack and builds MPLS header for the the echo-reply 575 packet. This procedure can be applied to an end-to-end path 576 consisting of multiple ASes. Each ASBR at the border adds its Node- 577 SID and EPE-SID on top of existing segments in the Return Path TLV. 579 8.2. Details with example 581 Let us consider a traffic engineered path built from PE1 to PE4 with 582 a label stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 for 583 the following procedures. This traceroute doesn't need any changes 584 to the Return Path TLV till it leaves AS1. The same Return Path TLV 585 that is received is included in the Echo-Reply. But this traceroute 586 requires changes to Return Path TLV once it starts probing AS2 587 routers. ASBR4 should form this Return Path TLV using its own Node 588 SID(N-ASBR4) and EPE SID (EPE-ASRB4-ASBR1) labels and set the return 589 code to 6. Then PE1 should use this Return Path TLV in subsequent 590 echo-requests. In this example, when the subsequent echo-request 591 reaches P3, it should use this Return Path TLV for sending the echo- 592 reply. The same Return Path TLV is enough for any router in AS2 to 593 send the reply. Because the first label(N-ASBR4) can direct echo- 594 reply to ASBR4 and second one (EPE-ASBR4-ASBR1) to direct echo-reply 595 to AS1. Once echo reply reaches AS1, normal IP forwarding helps it 596 to reach PE1 or the head-end. 598 9. Security Considerations 600 TBD 602 10. IANA Considerations 604 Sub-TLVs for TLV Types 1, 16, and 21 606 SID only in the form of mpls label : TBD (Range 32768-65535) 608 IPv4 Node Address with optional SID for SR-MPLS : TBD (Range 609 32768-65535) 611 IPv6 Node Address with optional SID for SR-MPLS : TBD (Range 612 32768-65535) 614 11. Contributors 616 1.Carlos Pignataro 618 Cisco Systems, Inc. 620 cpignata@cisco.com 622 2. Zafar Ali 624 Cisco Systems, Inc. 626 zali@cisco.com 628 12. Acknowledgments 630 Thanks to Bruno Decreane for suggesting use of generic Segment sub- 631 TLV. Thanks to Adrian Farrel for careful review and comments. 632 Thanks to Mach Chen for suggesting to use Return Path TLV. 634 13. References 636 13.1. Normative References 638 [I-D.ietf-idr-segment-routing-te-policy] 639 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 640 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 641 Routing Policies in BGP", draft-ietf-idr-segment-routing- 642 te-policy-11 (work in progress), November 2020. 644 [I-D.ietf-spring-segment-routing-central-epe] 645 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 646 Afanasiev, "Segment Routing Centralized BGP Egress Peer 647 Engineering", draft-ietf-spring-segment-routing-central- 648 epe-10 (work in progress), December 2017. 650 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 651 "Return Path Specified Label Switched Path (LSP) Ping", 652 RFC 7110, DOI 10.17487/RFC7110, January 2014, 653 . 655 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 656 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 657 Switched (MPLS) Data-Plane Failures", RFC 8029, 658 DOI 10.17487/RFC8029, March 2017, 659 . 661 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 662 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 663 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 664 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 665 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 666 . 668 13.2. Informative References 670 [I-D.ietf-idr-bgpls-segment-routing-epe] 671 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 672 S., and J. Dong, "BGP-LS extensions for Segment Routing 673 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 674 segment-routing-epe-19 (work in progress), May 2019. 676 [I-D.ietf-mpls-interas-lspping] 677 Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane 678 Failures in Inter-AS and inter-provider Scenarios", draft- 679 ietf-mpls-interas-lspping-00 (work in progress), March 680 2007. 682 [I-D.ietf-spring-segment-routing-policy] 683 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 684 P. Mattes, "Segment Routing Policy Architecture", draft- 685 ietf-spring-segment-routing-policy-09 (work in progress), 686 November 2020. 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, 690 DOI 10.17487/RFC2119, March 1997, 691 . 693 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 694 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 695 . 697 [RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G. 698 Swallow, Ed., "Relayed Echo Reply Mechanism for Label 699 Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743, 700 January 2016, . 702 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 703 Decraene, B., Litkowski, S., and R. Shakir, "Segment 704 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 705 July 2018, . 707 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 708 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 709 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 710 2018, . 712 [RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., 713 Henderickx, W., and D. Cooper, "Interconnecting Millions 714 of Endpoints with Segment Routing", RFC 8604, 715 DOI 10.17487/RFC8604, June 2019, 716 . 718 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 719 Decraene, B., Litkowski, S., and R. Shakir, "Segment 720 Routing with the MPLS Data Plane", RFC 8660, 721 DOI 10.17487/RFC8660, December 2019, 722 . 724 Authors' Addresses 726 Shraddha Hegde 727 Juniper Networks Inc. 728 Exora Business Park 729 Bangalore, KA 560103 730 India 732 Email: shraddha@juniper.net 734 Kapil Arora 735 Juniper Networks Inc. 737 Email: kapilaro@juniper.net 739 Mukul Srivastava 740 Juniper Networks Inc. 742 Email: msri@juniper.net 743 Samson Ninan 744 Individual Contributor 746 Email: samson.cse@gmail.com 748 Nagendra Kumar 749 Cisco Systems, Inc. 751 Email: naikumar@cisco.com