idnits 2.17.1 draft-ninan-mpls-spring-inter-domain-oam-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 6, 2020) is 1443 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 519, but not defined == Missing Reference: 'N-ASBR1' is mentioned on line 519, but not defined == Missing Reference: 'EPE-ASBR1-ASBR4' is mentioned on line 519, but not defined == Missing Reference: 'N-PE4' is mentioned on line 519, but not defined == Missing Reference: 'N-ASBR4' is mentioned on line 564, but not defined == Missing Reference: 'EPE-ASBR4-ASBR1' is mentioned on line 564, but not defined == Missing Reference: 'N-PE1' is mentioned on line 528, but not defined == Unused Reference: 'I-D.ietf-mpls-interas-lspping' is defined on line 687, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-08 ** 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-06 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 1 error (**), 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 Juniper Networks Inc. 5 Expires: November 7, 2020 S. Ninan 6 Individual Contributor 7 M. Srivastava 8 Juniper Networks Inc. 9 N. Kumar 10 Cisco Systems, Inc. 11 May 6, 2020 13 PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks 14 draft-ninan-mpls-spring-inter-domain-oam-00 16 Abstract 18 Segment Routing (SR) architecture leverages source routing and 19 tunneling paradigms and can be directly applied to the use of a 20 Multiprotocol Label Switching (MPLS) data plane. A network may 21 consist of multiple IGP domains or multiple ASes under the control of 22 same organization. It is useful to have the LSP Ping and traceroute 23 procedures when an SR end-to-end path spans across multiple ASes or 24 domains. This document describes mechanisms to facilitae LSP ping 25 and traceroute in inter-AS/inter-domain SR networks in an efficient 26 manner with simple OAM protocol extension which uses dataplane 27 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", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 7, 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Inter domain networks with multiple IGPs . . . . . . . . . . 4 70 3. Reverse Path Segment List TLV . . . . . . . . . . . . . . . . 5 71 3.1. Reverse Path Segment List TLV definition . . . . . . . . 5 72 3.1.1. Segment sub-TLV . . . . . . . . . . . . . . . . . . . 6 73 3.2. SRv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 10 74 4. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 11 75 4.1. Sending an Echo-Request . . . . . . . . . . . . . . . . . 11 76 4.2. Receiving an Echo-Request . . . . . . . . . . . . . . . . 11 77 4.3. Sending an Echo-Reply . . . . . . . . . . . . . . . . . . 11 78 5. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. Procedures for Segment Routing LSP ping . . . . . . . . . 12 80 5.2. Procedures for Segment Routing LSP Traceroute . . . . . . 13 81 6. Building Reverse Path Segment List TLV dynamically . . . . . 13 82 6.1. The procedures to build the reverse path . . . . . . . . 13 83 6.2. Details with example . . . . . . . . . . . . . . . . . . 14 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 90 11.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 +----------------+ 96 | Controller/PMS | 97 +----------------+ 99 |---------AS1----------| |--------AS2----------| 101 ASBR2-------ASBR3 102 / \ 103 / \ 104 PE1------P1------P2 P3------P4------PE4 105 \ / 106 \ / 107 ASBR1-------ASBR4 109 Figure 1: Inter-AS Segment Routing topology 111 Many network deployments have built their networks consisting of 112 multiple Autonomous Systems either for ease of operations or as a 113 result of network mergers and acquisitions. Segment Routing can be 114 deployed in such scenarios to provide end to end paths, traversing 115 multiple Autonomous systems(AS). These paths consist of Segment 116 Identifiers(SID) of different type as per [RFC8402]. 118 [I-D.ietf-spring-segment-routing-mpls] specifies the forwarding plane 119 behaviour to allow Segment Routing to operate on top of MPLS data 120 plane. [I-D.ietf-spring-segment-routing-central-epe] describes BGP 121 peering SIDs, which will help in steering packet from one Autonomous 122 system to another. Using above SR capabilities, paths which span 123 across multiple Autonomous systems can be created. 125 For example Figure 1 describes an inter-AS network scenario 126 consisting of ASes AS1 and AS2. Both AS1 and AS2 are Segment Routing 127 enabled and the EPE links have EPE labels configured and advertised 128 via [I-D.ietf-idr-bgpls-segment-routing-epe]. Controller or head-end 129 can build end-to-end Traffic-Engineered path Node-SIDs, Adjacency- 130 SIDs and EPE-SIDs. It is advantageous for operations to be able to 131 perform LSP ping and traceroute procedures on these inter-AS SR 132 paths. LSP ping/traceroute procedures use ip connectivity for Echo- 133 reply to reach the head-end. In inter-AS networks, ip connectivity 134 may not be there from each router in the path.For example in Figure 1 135 P3 and P4 may not have ip connectivity for PE1. 137 [RFC8403] describes mechanisms to carry out the MPLS ping/traceroute 138 from a PMS. It is possible to build GRE tunnels or static routes to 139 each router in the network to get IP connectivity for the reverse 140 path. This mechanism is operationally very heavy and requires PMS to 141 be capable of building huge number of GRE tunnels, which may not be 142 feasible. 144 It is not possible to carry out LSP ping and Traceroute functionality 145 on these paths to verify basic connectivity and fault isolation using 146 existing LSP ping and Traceroute mechanism([RFC8287] and [RFC8029]). 147 This is because, there exists no IP connectivity to source address of 148 ping packet, which is in a different AS, from the destination of 149 Ping/Traceroute. 151 [RFC7743] describes a Echo-relay based solution based on advertising 152 a new Relay Node Address Stack TLV containing stack of Echo-relay ip 153 addresses. That mechanism requires the return ping packet to reach 154 the control plane on every relay node. 156 This document describes a mechanism which is efficient and simple and 157 can be easily deployed in SR networks. This mechanism uses a new 158 Reverse Path Segment List TLV to convey the reverse path. The TLV 159 can either be derived by a smart application/controller which has a 160 full topology view or by the help of intermediate nodes. 162 2. Inter domain networks with multiple IGPs 164 |-Domain 1|-------Domain 2-----|--Domain 3-| 166 PE1------ABR1--------P--------ABR2------PE4 167 \ / \ /\ / 168 -------- ----------------- ------- 169 BGP-LU BGP-LU BGP-LU 171 Figure 2: Inter-domain networks with multiple IGPs 173 When the network consists of large number of nodes, the nodes are 174 seggregated into multiple IGP domains. The connectivity to the 175 remote PEs can be achieved using BGP-LU [RFC3107] or by stacking the 176 labels for each domain as described in [RFC8604]. It is useful to 177 support mpls ping and traceroute mechanisms for these networks. The 178 procedures described in this document for constructing reverse path 179 TLV and its use in echo-reply is equally applicable to networks 180 consisting of multiple IGP domains that use BGP-LU or label stacking. 182 3. Reverse Path Segment List TLV 184 Segment Routing networks statically assign the labels to nodes and 185 PMS/Head-end may know the entire database. The reverse path can be 186 built from PMS/Head-end by stacking segments for the reverse path. A 187 new TLV "Reverse Path Segment List TLV" is defined. Each TLV 188 contains a list of segment sub-TLVs which may be a prefix/adjacency/ 189 binding SID/EPE SID. MPLS Echo -request should contain this TLV, 190 which defines reverse path to reach source from the destination. 192 The new Reverse Path Segment List TLV is an optional TLV. This TLV 193 is carried in the Echo-Request message. This optional TLV MAY appear 194 in the Echo-request message in any order before or after Target FEC 195 Stack TLV. The Reverse Path Segment List TLV is defined as below. 196 Each MPLS Echo-request SHOULD contain this TLV in inter-AS/inter- 197 domain cases, which will enable remote end(egress/transit routers) to 198 send the reply to source. 200 In some cases, the head-end may not have complete visibility. In 201 such cases, it can rely on downstream routers to build the reverse 202 path. For this purpose, the TLV is carried in the Echo-Reply 203 message. Section 6 describes one basic idea in this direction. 205 The Reverse Path Segment List TLV contains different types of 206 segments. The type of segment that the head-end chooses to send in 207 the Reverse Path Segment List TLV is geoverned by local policy. In 208 certain scenarios the head-end may choose to send Type 2/Type 3 209 segments consisting of IPV4 address and SID. In such cases that node 210 sending the echo-reply MUST derive the MPLS labels from SIDs based on 211 SRGB and encode the echo-reply with MPLS labels. 213 Some networks may consist of pure IPV4 domains and Pure IPv6 domains. 214 Handling end-to-end MPLS OAM for such networks is out of scope for 215 this document. It is recommended to use dual stack in such cases and 216 use end-to-end IPv6 addresses for MPLS ping and trace route 217 procedures. 219 3.1. Reverse Path Segment List TLV definition 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |Type = TBD | Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Segment sub TLV | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | ... | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 3: Reverse Path Segment List TLV 232 Type: TBD 234 Length: Length of TLV including TLV header and length of sub TLV. 236 There can be one or more segment sub-TLVs in a Reverse Path Segment 237 List TLV. The applicable segment types are described in 238 Section 3.1.1. The Segment type in a Reverse Path Segment List TLV 239 MAY be same or different. 241 3.1.1. Segment sub-TLV 243 [I-D.ietf-spring-segment-routing-policy] defines various types of 244 segments. These segment types are applicable here. One or more 245 segment sub-TLV can be included. The segment sub-TLVs included MAY 246 be of different types. 248 Below types of segment sub-TLVs are applicable for the Reverse Path 249 Segment List Tlv. 251 Type 1: SID only, in the form of MPLS Label 253 Type 3: IPv4 Node Address with optional SID 255 Type 4: IPv6 Node Address with optional SID for SR MPLS 257 3.1.1.1. Type 1: SID only, in the form of MPLS Label 259 The Type-1 Segment Sub-TLV encodes a single SID in the form of an 260 MPLS label. The format is as follows: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | Length | Flags | RESERVED | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Label | TC |S| TTL | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 4: Type 1 Segment sub-TLV 272 where: 274 Type: 1 (to be assigned by IANA from the registry "SR Policy List 275 Sub-TLVs" defined in [I-D.ietf-idr-segment-routing-te-policy]). 277 Length is 6. 279 Flags: 1 octet of flags as defined in Section Section 3.1.1.4. 281 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 282 and MUST be ignored on receipt. 284 Label: 20 bits of label value. 286 TC: 3 bits of traffic class 288 S: 1 bit of bottom-of-stack. 290 TTL: 1 octet of TTL. 292 The following applies to the Type-1 Segment sub-TLV: 294 The S bit SHOULD be zero upon transmission, and MUST be ignored upon 295 reception. 297 If the originator wants the receiver to choose the TC value, it sets 298 the TC field to zero. 300 If the originator wants the receiver to choose the TTL value, it sets 301 the TTL field to 255. 303 If the originator wants to recommend a value for these fields, it 304 puts those values in the TC and/or TTL fields. 306 The receiver MAY override the originator's values for these fields. 307 This would be determined by local policy at the receiver. One 308 possible policy would be to override the fields only if the fields 309 have the default values specified above. 311 3.1.1.2. Type 3: IPv4 Node Address with optional SID for SR-MPLS 313 The Type-3 Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 314 and an optional SID in the form of an MPLS label. The format is as 315 follows: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | Length | Flags | SR Algorithm | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | IPv4 Node Address (4 octets) | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | SID (optional, 4 octets) | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 5: Type 3 Segment sub-TLV 329 where: 331 Type: 3 (to be assigned by IANA from the registry "SR Policy List 332 Sub-TLVs" defined in [I-D.ietf-idr-segment-routing-te-policy]). 334 Length is 6 or 10. 336 Flags: 1 octet of flags as defined in Section Section 3.1.1.4. 338 SR Algorithm: 1 octet specifying SR Algorithm as described in section 339 3.1.1 in [RFC8402], when A-Flag as defined in 340 Section Section 3.1.1.4is present. SR Algorithm is used by SRPM as 341 described in section 4 in [I-D.ietf-spring-segment-routing-policy]. 342 When A-Flag is not encoded, this field SHOULD be unset on 343 transmission and MUST be ignored on receipt. 345 IPv4 Node Address: a 4 octet IPv4 address representing a node. 347 SID: 4 octet MPLS label. 349 The following applies to the Type-3 Segment sub-TLV: 351 The IPv4 Node Address MUST be present. 353 The SID is optional and specifies a 4 octet MPLS SID containing 354 label, TC, S and TTL as defined in Section Section 3.1.1.1. 356 If length is 6, then only the IPv4 Node Address is present. 358 If length is 10, then the IPv4 Node Address and the MPLS SID are 359 present. 361 3.1.1.3. Type 4: IPv6 Node Address with optional SID for SR MPLS 363 The Type-4 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 364 and an optional SID in the form of an MPLS label. The format is as 365 follows: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type | Length | Flags | SR Algorithm | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 // IPv6 Node Address (16 octets) // 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | SID (optional, 4 octets) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 6: Type 4 Segment sub-TLV 379 where: 381 Type: 4 (to be assigned by IANA from the registry "SR Policy List 382 Sub-TLVs" defined in [I-D.ietf-idr-segment-routing-te-policy]). 384 Length is 18 or 22. 386 Flags: 1 octet of flags as defined in Section Section 3.1.1.4. 388 SR Algorithm: 1 octet specifying SR Algorithm as described in section 389 3.1.1 in [RFC8402], when A-Flag as defined in Section Section 3.1.1.4 390 is present. SR Algorithm is used by SRPM as described in section 4 391 in [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 392 encoded, this field SHOULD be unset on transmission and MUST be 393 ignored on receipt. 395 IPv6 Node Address: a 16 octet IPv6 address representing a node. 397 SID: 4 octet MPLS label. 399 The following applies to the Type-4 Segment sub-TLV: 401 The IPv6 Node Address MUST be present. 403 The SID is optional and specifies a 4 octet MPLS SID containing 404 label, TC, S and TTL as defined in Section Section 3.1.1.1 . 406 If length is 18, then only the IPv6 Node Address is present. 408 If length is 22, then the IPv6 Node Address and the MPLS SID are 409 present. 411 3.1.1.4. Segment Flags 413 The Segment Types described above MAY contain following flags in the 414 "Flags" field (codes to be assigned by IANA from the registry "SR 415 Policy Segment Flags" defined 416 in[I-D.ietf-idr-segment-routing-te-policy]) 418 0 1 2 3 4 5 6 7 419 +-+-+-+-+-+-+-+-+ 420 |V|A| | 421 +-+-+-+-+-+-+-+-+ 423 Figure 7: Flags 425 where: 427 V-Flag: This flag is used by SRPM for the purpose of "SID 428 verification" as described in Section 5.1 in 429 [I-D.ietf-spring-segment-routing-policy]. 431 A-Flag: This flag indicates the presence of SR Algorithm id in the 432 "SR Algorithm" field applicable to various Segment Types. SR 433 Algorithm is used by SRPM as described in section 4 in 434 [I-D.ietf-spring-segment-routing-policy]. 436 Unused bits in the Flag octet SHOULD be set to zero upon transmission 437 and MUST be ignored upon receipt. 439 The following applies to the Segment Flags: 441 V-Flag is applicable to all Segment Types. 443 A-Flag is applicable to Segment Types 3, 4 and 9. If A-Flag appears 444 with any other Segment Type, it MUST be ignored. 446 3.2. SRv6 Dataplane 448 SRv6 dataplane is not in the scope of this document and will be 449 addressed in a separate document. 451 4. Detailed Procedures 453 4.1. Sending an Echo-Request 455 In the inter-AS scenario when there is no reverse path connectivity, 456 LSP ping initiator MUST add a Reverse Path Segment List TLV in the 457 Echo-request message. The reverse Segment List MUST correspond to 458 the return path from the egress. The Reverse Path Segment List TLV 459 is an ordered list of Segments. The first Segment corresponds to the 460 top Segment in MPLS header that the responder MUST use while sending 461 the Echo-reply. 463 4.2. Receiving an Echo-Request 465 When a receiver does not understand the Reverse Path Segment List 466 TLV, it SHOULD silently ignore the TLV and proceed with normal 467 processing as described in [RFC8029].When a Reverse Path Segment List 468 TLV is received, and the responder supports processing it, it MUST 469 use the Segments in Reverse Path Segment List TLV to build the echo- 470 reply. The responder MUST follow the normal FEC validation 471 procedures as described in [RFC8029] and [RFC8287] and this document 472 does not suggest any change to those procedures. When the Echo-reply 473 has to be sent out the Reverse Path Segment List TLV is used to 474 construct the MPLS packet to send out. 476 4.3. Sending an Echo-Reply 478 The Echo-Reply message is sent as MPLS packet with a MPLS label 479 stack. The Echo-Reply message MUST be constructed as described in 480 the [RFC8029]. An MPLS packet is constructed with Echo-reply in the 481 payload. The top label MUST be constructed from the first Segment 482 from the Reverse Path Segment List TLV. The remaining labels MUST 483 follow the order from the Reverse Path Segment List TLV. The 484 responder MAY check the reachability of the top label in its own LFIB 485 before sending the Echo-Reply. 487 5. Detailed Example 489 An example topology is given in Figure 1 . This will be used in below 490 sections to explain LSP Ping and Traceroute procedures. The PMS/ 491 Head-end has complete view of topology. PE1, P1, P2, ASBR1 and ASBR2 492 are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are in AS2. 494 AS1 and AS2 have Segment Routing enabled. IGPs like OSPF/ISIS are 495 used to flood SIDs in each Autonomous System. The ASBR1, ASBR2, 496 ASBR3, ASBR4 advertise BGP EPE SIDs for the inter-AS links. Topology 497 of AS1 and AS2 are advertised via BGP-LS to the controller/PMS or 498 Head-end node. The EPE-SIDs are also advertised via BGP-LS as 499 described in [I-D.ietf-idr-bgpls-segment-routing-epe] 501 The description in the document uses below notations for Segment 502 Identifiers(SIDs). 504 Node SIDs : N-PE1, N-P1, N-ASBR1 etc. 506 Adjacency SIDs : Adj-PE1-P1, Adj-P1-P2 etc. 508 EPE SIDS : EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 etc. 510 Let us consider a traffic engineered path built from PE1 to PE4 with 511 Segment List stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 512 for following procedures. This stack may be programmed by 513 controller/PMS or Head-end router PE1 may have imported the whole 514 topology information from BGP-LS and computed the inter-AS path. 516 5.1. Procedures for Segment Routing LSP ping 518 To perform LSP ping procedure on an SR-Path from PE1 to PE4 519 consisting of label stacks [N-P1,N-ASBR1,EPE-ASBR1-ASBR4, N-PE4], The 520 remote end(PE4) needs IP connectivity to head end(PE1) for the 521 Segment Routing ping to succeed, because Echo-reply needs to travel 522 back to PE1 from PE4. But in typical deployment scenario there will 523 be no ip route from PE4 to PE1 as they belong to different ASes. 525 PE1 adds Reverse Path from PE4 to PE1 in the MPLS Echo-request using 526 multiple Segments in "Reverse Path Segment List TLV" as defined 527 above. An example reverse path Segment List for PE1 to PE4 for LSP 528 ping is [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. An implementation may 529 also build a Reverse Path Segment List consisting of labels to reach 530 its own AS. Once the label stack is popped-off the Echo-reply 531 message will be exposed.The further packet forwarding will be based 532 on ip lookup. An example Reverse Path Segment List for this case 533 could be [N-ASBR4, EPE-ASBR4-ASBR1]. 535 On receiving MPLS Echo-request PE4 first validates FEC in the Echo- 536 request. PE4 then builds label stack to send the response from PE4 537 to PE1 by copying the labels from "Reverse Path Segment List TLV". 538 PE4 builds the Echo-reply packet with the MPLS label stack 539 constructed and imposes MPLS headers on top of Echo-reply packet and 540 sends out the packet towards PE1. This Segment List stack can 541 successfully steer reply back to Head-end node(PE1). 543 5.2. Procedures for Segment Routing LSP Traceroute 545 As described in the procedures for LSP ping, the reverse Segment List 546 may be sent from head-end in which case the LSP Traceroute procedures 547 are similar to LSP ping. The head-end constructs the Reverse Path 548 Segment List TLV and the egress node uses the Reverse Path Segment 549 List to construct the Echo-reply packet header. Head-end/PMS is 550 aware of the reverse path from every node visited in the network and 551 builds the Reverse Path Segment List for every visited node 552 accordingly. 554 For Example: 556 For the same traffic engineered path PE1 to PE4 mentioned in above 557 sections, let us assume there is no reverse path available from the 558 nodes ASBR4 to PE1. During the Traceroute procedure, when PE1 has to 559 visit ASBR4, it builds reverse Path Label Stack TLV and includes 560 label to the border-node which has the route to, PE1. In this 561 example the Reverse Path Segment List TLV will contain [EPE- 562 ASBR4-ASBR1]. Further down the traceroute procedure when P3 or P4 563 node is being visited, PE1 build the Reverse Path Segment List TLV 564 containing [N-ASBR4, EPE-ASBR4-ASBR1]. The Echo-reply will be an 565 MPLS packet with this label stack and will be forwarded to PE1. 567 6. Building Reverse Path Segment List TLV dynamically 569 In some cases, the head-end may not have complete visibility of 570 Inter-AS topology. In such cases, it can rely on downstream routers 571 to build the reverse path for mpls traceroute procedures. For this 572 purpose, the Reverse Path Segment List TLV is carried in the Echo- 573 Reply. 575 6.1. The procedures to build the reverse path 577 When an ASBR receives an echo-request from another AS, and ASBR is 578 configured to build the Reverse Path dynamically, ASBR MUST build a 579 Reverse Path Segmnet List TLV and add it in echo-reply. ASBR MUST 580 locally decide the outgoing interface for the echo-reply packet. 581 Generally, remote ASBR will choose interface on which the incoming 582 OAM packet was receieved to send the echo-reply out. Reverse Path 583 Segment List TLV is built by adding two segment sub TLVs. The top 584 segment sub TLV consists of the ASBR's Node SID and second segment 585 consists of the EPE SID in the reverse direction to reach the AS from 586 which the OAM packet was received.The type of segment chosen to build 587 Reverse Path Segment List TLV is implementation dependent. In cases 588 where the AS is configured with different SRGBs, the Node SID of the 589 ASBR should be represented using type 3 segment so that all the nodes 590 inside the AS can correctly translate the Node-SID to a label. 592 Irrespective of which type of segment is included in the Reverse Path 593 Segment List TLV, the responder of echo-request always translates the 594 Reverse Path Segment List TLV to a label stack and builds MPLS header 595 for the the echo-reply packet. This procedure can be applied to an 596 end-to-end path consisting of multiple ASes. Each ASBR at the border 597 adds its Node-SID and EPE-SID on top of existing segments in the 598 Reverse Path Segment List. 600 6.2. Details with example 602 Let us consider a traffic engineered path built from PE1 to PE4 with 603 a label stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 for 604 the following procedures. This traceroute doesn't need any Reverse 605 Path Segment List TLV till it leaves AS1, because IP connectivity 606 will be there to send echo-reply. But this traceroute requires 607 Reverse Path Segment List TLV once it starts probing AS2 routers. 608 According to this procedure, ASBR4 should add Reverse Path Segment 609 List TLV in its echo-reply. ASBR4 should form this Reverse Path 610 Segment List TLV using its own Node SID(N-ASBR4) and EPE SID (EPE- 611 ASRB4-ASBR1) labels. Then PE1 should use this Reverse Path Segment 612 List TLV in subsequent echo-requests. In this example, when the 613 subsequent echo-request reaches P3, it should use this Reverse Path 614 Segment List TLV for sending the echo-reply. The same Reverse Path 615 Segment List TLV is enough for any router in AS2 to send the reply. 616 Because the first label(N-ASBR4) can direct echo-reply to ASBR4 and 617 second one (EPE-ASBR4-ASBR1) to direct echo-reply to AS1. Once echo 618 reply reaches AS1, normal IP forwarding helps it to reach PE1 or the 619 head-end. 621 7. Security Considerations 623 TBD 625 8. IANA Considerations 627 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 628 Parameters TLVs Registry 630 Reverse Path Segment List TLV : TBD 632 9. Contributors 634 1.Carlos Pignataro 636 Cisco Systems, Inc. 638 cpignata@cisco.com 639 2. Zafar Ali 641 Cisco Systems, Inc. 643 zali@cisco.com 645 10. Acknowledgments 647 Thanks to Bruno Decreane for suggesting use of generic Segment sub- 648 TLV. 650 11. References 652 11.1. Normative References 654 [I-D.ietf-idr-segment-routing-te-policy] 655 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 656 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 657 Routing Policies in BGP", draft-ietf-idr-segment-routing- 658 te-policy-08 (work in progress), November 2019. 660 [I-D.ietf-spring-segment-routing-central-epe] 661 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 662 Afanasiev, "Segment Routing Centralized BGP Egress Peer 663 Engineering", draft-ietf-spring-segment-routing-central- 664 epe-10 (work in progress), December 2017. 666 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 667 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 668 Switched (MPLS) Data-Plane Failures", RFC 8029, 669 DOI 10.17487/RFC8029, March 2017, 670 . 672 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 673 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 674 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 675 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 676 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 677 . 679 11.2. Informative References 681 [I-D.ietf-idr-bgpls-segment-routing-epe] 682 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 683 S., and J. Dong, "BGP-LS extensions for Segment Routing 684 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 685 segment-routing-epe-19 (work in progress), May 2019. 687 [I-D.ietf-mpls-interas-lspping] 688 Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane 689 Failures in Inter-AS and inter-provider Scenarios", draft- 690 ietf-mpls-interas-lspping-00 (work in progress), March 691 2007. 693 [I-D.ietf-spring-segment-routing-mpls] 694 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 695 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 696 data plane", draft-ietf-spring-segment-routing-mpls-22 697 (work in progress), May 2019. 699 [I-D.ietf-spring-segment-routing-policy] 700 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 701 P. Mattes, "Segment Routing Policy Architecture", draft- 702 ietf-spring-segment-routing-policy-06 (work in progress), 703 December 2019. 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, 707 DOI 10.17487/RFC2119, March 1997, 708 . 710 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 711 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 712 . 714 [RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G. 715 Swallow, Ed., "Relayed Echo Reply Mechanism for Label 716 Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743, 717 January 2016, . 719 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 720 Decraene, B., Litkowski, S., and R. Shakir, "Segment 721 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 722 July 2018, . 724 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 725 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 726 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 727 2018, . 729 [RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., 730 Henderickx, W., and D. Cooper, "Interconnecting Millions 731 of Endpoints with Segment Routing", RFC 8604, 732 DOI 10.17487/RFC8604, June 2019, 733 . 735 Authors' Addresses 737 Shraddha Hegde 738 Juniper Networks Inc. 739 Exora Business Park 740 Bangalore, KA 560103 741 India 743 Email: shraddha@juniper.net 745 Kapil Arora 746 Juniper Networks Inc. 748 Email: kapilaro@juniper.net 750 Samson Ninan 751 Individual Contributor 753 Email: samson.cse@gmail.com 755 Mukul Srivastava 756 Juniper Networks Inc. 758 Email: msri@juniper.net 760 Nagendra Kumar 761 Cisco Systems, Inc. 763 Email: naikumar@cisco.com