idnits 2.17.1 draft-ninan-mpls-spring-inter-domain-oam-01.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 (November 19, 2020) is 1252 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 530, but not defined == Missing Reference: 'N-ASBR1' is mentioned on line 530, but not defined == Missing Reference: 'EPE-ASBR1-ASBR4' is mentioned on line 530, but not defined == Missing Reference: 'N-PE4' is mentioned on line 530, but not defined == Missing Reference: 'N-ASBR4' is mentioned on line 575, but not defined == Missing Reference: 'EPE-ASBR4-ASBR1' is mentioned on line 575, but not defined == Missing Reference: 'N-PE1' is mentioned on line 539, but not defined == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mpls-interas-lspping' is defined on line 709, 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: 1 error (**), 0 flaws (~~), 12 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: May 23, 2021 Juniper Networks Inc. 6 S. Ninan 7 Individual Contributor 8 N. Kumar 9 Cisco Systems, Inc. 10 November 19, 2020 12 PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks 13 draft-ninan-mpls-spring-inter-domain-oam-01 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 May 23, 2021. 50 Copyright Notice 52 Copyright (c) 2020 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. Reverse Path Segment List TLV . . . . . . . . . . . . . . . . 5 70 3.1. Reverse Path Segment List TLV definition . . . . . . . . 5 71 3.1.1. Segment sub-TLV . . . . . . . . . . . . . . . . . . . 6 72 3.2. SRv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 11 73 4. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 11 74 4.1. Sending an Echo-Request . . . . . . . . . . . . . . . . . 11 75 4.2. Receiving an Echo-Request . . . . . . . . . . . . . . . . 11 76 4.3. Sending an Echo-Reply . . . . . . . . . . . . . . . . . . 11 77 5. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 12 78 5.1. Procedures for Segment Routing LSP ping . . . . . . . . . 12 79 5.2. Procedures for Segment Routing LSP Traceroute . . . . . . 13 80 6. Building Reverse Path Segment List TLV dynamically . . . . . 13 81 6.1. The procedures to build the reverse path . . . . . . . . 13 82 6.2. Details with example . . . . . . . . . . . . . . . . . . 14 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 89 11.2. Informative References . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 +----------------+ 95 | Controller/PMS | 96 +----------------+ 98 |---------AS1----------| |--------AS2----------| 100 ASBR2-------ASBR3 101 / \ 102 / \ 103 PE1------P1------P2 P3------P4------PE4 104 \ / 105 \ / 106 ASBR1-------ASBR4 108 Figure 1: Inter-AS Segment Routing topology 110 Many network deployments have built their networks consisting of 111 multiple Autonomous Systems either for ease of operations or as a 112 result of network mergers and acquisitions. Segment Routing can be 113 deployed in such scenarios to provide end to end paths, traversing 114 multiple Autonomous systems(AS). These paths consist of Segment 115 Identifiers(SID) of different type as per [RFC8402]. 117 [RFC8660] specifies the forwarding plane behaviour to allow Segment 118 Routing to operate on top of MPLS data plane. 119 [I-D.ietf-spring-segment-routing-central-epe] describes BGP peering 120 SIDs, which will help in steering packet from one Autonomous system 121 to another. Using above SR capabilities, paths which span across 122 multiple Autonomous systems can be created. 124 For example Figure 1 describes an inter-AS network scenario 125 consisting of ASes AS1 and AS2. Both AS1 and AS2 are Segment Routing 126 enabled and the EPE links have EPE labels configured and advertised 127 via [I-D.ietf-idr-bgpls-segment-routing-epe]. Controller or head-end 128 can build end-to-end Traffic-Engineered path consisting of Node-SIDs, 129 Adjacency-SIDs and EPE-SIDs. It is advantageous for operations to be 130 able to perform LSP ping and traceroute procedures on these inter-AS 131 SR paths. LSP ping/traceroute procedures use ip connectivity for 132 Echo-reply to reach the head-end. In inter-AS networks, ip 133 connectivity may not be there from each router in the path.For 134 example in Figure 1 P3 and P4 may not have ip connectivity for PE1. 136 [RFC8403] describes mechanisms to carry out the MPLS ping/traceroute 137 from a PMS. It is possible to build GRE tunnels or static routes to 138 each router in the network to get IP connectivity for the reverse 139 path. This mechanism is operationally very heavy and requires PMS to 140 be capable of building huge number of GRE tunnels, which may not be 141 feasible. 143 It is not possible to carry out LSP ping and Traceroute functionality 144 on these paths to verify basic connectivity and fault isolation using 145 existing LSP ping and Traceroute mechanism([RFC8287] and [RFC8029]). 146 This is because, there exists no IP connectivity to source address of 147 ping packet, which is in a different AS, from the destination of 148 Ping/Traceroute. 150 [RFC7743] describes a Echo-relay based solution based on advertising 151 a new Relay Node Address Stack TLV containing stack of Echo-relay ip 152 addresses. That mechanism requires the return ping packet to reach 153 the control plane on every relay node. 155 This document describes a new mechanism which is efficient and simple 156 and can be easily deployed in SR networks. This mechanism uses a new 157 Reverse Path Segment List TLV to convey the reverse path. The TLV 158 can either be derived by a smart application/controller which has a 159 full topology view or by the help of intermediate nodes. 161 2. Inter domain networks with multiple IGPs 163 |-Domain 1|-------Domain 2-----|--Domain 3-| 165 PE1------ABR1--------P--------ABR2------PE4 166 \ / \ /\ / 167 -------- ----------------- ------- 168 BGP-LU BGP-LU BGP-LU 170 Figure 2: Inter-domain networks with multiple IGPs 172 When the network consists of large number of nodes, the nodes are 173 seggregated into multiple IGP domains. The connectivity to the 174 remote PEs can be achieved using BGP-LU [RFC3107] or by stacking the 175 labels for each domain as described in [RFC8604]. It is useful to 176 support mpls ping and traceroute mechanisms for these networks. The 177 procedures described in this document for constructing reverse path 178 TLV and its use in echo-reply is equally applicable to networks 179 consisting of multiple IGP domains that use BGP-LU or label stacking. 181 3. Reverse Path Segment List TLV 183 Segment Routing networks statically assign the labels to nodes and 184 PMS/Head-end may know the entire database. The reverse path can be 185 built from PMS/Head-end by stacking segments for the reverse path. A 186 new TLV "Reverse Path Segment List TLV" is defined. Each TLV 187 contains a list of segment sub-TLVs which may be a prefix/adjacency/ 188 binding SID/EPE SID. MPLS Echo -request should contain this TLV, 189 which defines reverse path to reach source from the destination. 191 The new Reverse Path Segment List TLV is an optional TLV. This TLV 192 is carried in the Echo-Request message. This optional TLV MAY appear 193 in the Echo-request message in any order before or after Target FEC 194 Stack TLV. The Reverse Path Segment List TLV is defined as below. 195 Each MPLS Echo-request SHOULD contain this TLV in inter-AS/inter- 196 domain cases, which will enable remote end(egress/transit routers) to 197 send the reply to source. 199 In some cases, the head-end may not have complete visibility. In 200 such cases, it can rely on downstream routers to build the reverse 201 path. For this purpose, the TLV is carried in the Echo-Reply 202 message. Section 6 describes one basic idea in this direction. 204 The Reverse Path Segment List TLV contains different types of 205 segments. The type of segment that the head-end chooses to send in 206 the Reverse Path Segment List TLV is governed by local policy. In 207 certain scenarios the head-end may choose to send Type 2/Type 3 208 segments consisting of IPV4 address and SID. In such cases that node 209 sending the echo-reply MUST derive the MPLS labels from SIDs based on 210 SRGB and encode the echo-reply with MPLS labels. 212 Some networks may consist of pure IPV4 domains and Pure IPv6 domains. 213 Handling end-to-end MPLS OAM for such networks is out of scope for 214 this document. It is recommended to use dual stack in such cases and 215 use end-to-end IPv6 addresses for MPLS ping and trace route 216 procedures. 218 3.1. Reverse Path Segment List TLV definition 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |Type = TBD | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Segment sub TLV | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | ... | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 3: Reverse Path Segment List TLV 231 Type: TBD 233 Length: Length of TLV. Excludes length of type and length field. 234 Includes length of all sun-tlvs 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. The segments applicable to this documents have been re- 245 defined here. One or more segment sub-TLV can be included. The 246 segment sub-TLVs included MAY 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 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Flags | RESERVED | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Label | TC |S| TTL | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 Figure 4: Type 1 Segment sub-TLV 274 where: 276 Type: 1 (to be assigned by IANA from the new registry "Sub-TLV of 277 Reverse path segment List TLV"). 279 Length is 8. 281 Flags: 1 octet of flags as defined in Section Section 3.1.1.4. 283 RESERVED: 3 octets of reserved bits. SHOULD be unset on transmission 284 and MUST be ignored on receipt. 286 Label: 20 bits of label value. 288 TC: 3 bits of traffic class 290 S: 1 bit of bottom-of-stack. 292 TTL: 1 octet of TTL. 294 The following applies to the Type-1 Segment sub-TLV: 296 The S bit SHOULD be zero upon transmission, and MUST be ignored upon 297 reception. 299 If the originator wants the receiver to choose the TC value, it sets 300 the TC field to zero. 302 If the originator wants the receiver to choose the TTL value, it sets 303 the TTL field to 255. 305 If the originator wants to recommend a value for these fields, it 306 puts those values in the TC and/or TTL fields. 308 The receiver MAY override the originator's values for these fields. 309 This would be determined by local policy at the receiver. One 310 possible policy would be to override the fields only if the fields 311 have the default values specified above. 313 3.1.1.2. Type 3: IPv4 Node Address with optional SID for SR-MPLS 315 The Type-3 Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 316 and an optional SID in the form of an MPLS label. The format is as 317 follows: 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Length | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Flags | SR Algorithm | RESERVED | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | IPv4 Node Address (4 octets) | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | SID (optional, 4 octets) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 5: Type 3 Segment sub-TLV 333 where: 335 Type: 3 (to be assigned by IANA from the new registry "Sub-TLV of 336 Reverse path segment List TLV"). 338 Length is 8 or 12. 340 Flags: 1 octet of flags as defined in Section Section 3.1.1.4. 342 SR Algorithm: 1 octet specifying SR Algorithm as described in section 343 3.1.1 in [RFC8402], when A-Flag as defined in 344 Section Section 3.1.1.4is present. SR Algorithm is used by SRPM as 345 described in section 4 in [I-D.ietf-spring-segment-routing-policy]. 346 When A-Flag is not encoded, this field SHOULD be unset on 347 transmission and MUST be ignored on receipt. 349 RESERVED: 2 octets of reserved bits. SHOULD be unset on transmission 350 and MUST be ignored on receipt. 352 IPv4 Node Address: a 4 octet IPv4 address representing a node. 354 SID: 4 octet MPLS label. 356 The following applies to the Type-3 Segment sub-TLV: 358 The IPv4 Node Address MUST be present. 360 The SID is optional and specifies a 4 octet MPLS SID containing 361 label, TC, S and TTL as defined in Section Section 3.1.1.1. 363 If length is 8, then only the IPv4 Node Address is present. 365 If length is 12, then the IPv4 Node Address and the MPLS SID are 366 present. 368 3.1.1.3. Type 4: IPv6 Node Address with optional SID for SR MPLS 370 The Type-4 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 371 and an optional SID in the form of an MPLS label. The format is as 372 follows: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Flags | SR Algorithm | RESERVED | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 // IPv6 Node Address (16 octets) // 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | SID (optional, 4 octets) | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 6: Type 4 Segment sub-TLV 388 where: 390 Type: 4 (to be assigned by IANA from the new registry "Sub-TLV of 391 Reverse path segment List TLV"). 393 Length is 20 or 24. 395 Flags: 1 octet of flags as defined in Section Section 3.1.1.4. 397 SR Algorithm: 1 octet specifying SR Algorithm as described in section 398 3.1.1 in [RFC8402], when A-Flag as defined in Section Section 3.1.1.4 399 is present. SR Algorithm is used by SRPM as described in section 4 400 in [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 401 encoded, this field SHOULD be unset on transmission and MUST be 402 ignored on receipt. 404 RESERVED: 2 octets of reserved bits. SHOULD be unset on transmission 405 and MUST be ignored on receipt. 407 IPv6 Node Address: a 16 octet IPv6 address representing a node. 409 SID: 4 octet MPLS label. 411 The following applies to the Type-4 Segment sub-TLV: 413 The IPv6 Node Address MUST be present. 415 The SID is optional and specifies a 4 octet MPLS SID containing 416 label, TC, S and TTL as defined in Section Section 3.1.1.1 . 418 If length is 20, then only the IPv6 Node Address is present. 420 If length is 24, then the IPv6 Node Address and the MPLS SID are 421 present. 423 3.1.1.4. Segment Flags 425 The Segment Types described above MAY contain following flags in the 426 "Flags" field (codes to be assigned by IANA from the registry 427 "Reverse path segment list sub-TLV Flags" ) 429 0 1 2 3 4 5 6 7 430 +-+-+-+-+-+-+-+-+ 431 |V|A| | 432 +-+-+-+-+-+-+-+-+ 434 Figure 7: Flags 436 where: 438 V-Flag: This flag is used by SRPM for the purpose of "SID 439 verification" as described in Section 5.1 in 440 [I-D.ietf-spring-segment-routing-policy]. 442 A-Flag: This flag indicates the presence of SR Algorithm id in the 443 "SR Algorithm" field applicable to various Segment Types. SR 444 Algorithm is used by SRPM as described in section 4 in 445 [I-D.ietf-spring-segment-routing-policy]. 447 Unused bits in the Flag octet SHOULD be set to zero upon transmission 448 and MUST be ignored upon receipt. 450 The following applies to the Segment Flags: 452 V-Flag is applicable to all Segment Types. 454 A-Flag is applicable to Segment Types 3, 4 and 9. If A-Flag appears 455 with any other Segment Type, it MUST be ignored. 457 3.2. SRv6 Dataplane 459 SRv6 dataplane is not in the scope of this document and will be 460 addressed in a separate document. 462 4. Detailed Procedures 464 4.1. Sending an Echo-Request 466 In the inter-AS scenario when there is no reverse path connectivity, 467 LSP ping initiator MUST add a Reverse Path Segment List TLV in the 468 Echo-request message. The reverse Segment List MUST correspond to 469 the return path from the egress. The Reverse Path Segment List TLV 470 is an ordered list of Segments. The first Segment corresponds to the 471 top Segment in MPLS header that the responder MUST use while sending 472 the Echo-reply. 474 4.2. Receiving an Echo-Request 476 When a receiver does not understand the Reverse Path Segment List 477 TLV, it SHOULD silently ignore the TLV and proceed with normal 478 processing as described in [RFC8029].When a Reverse Path Segment List 479 TLV is received, and the responder supports processing it, it MUST 480 use the Segments in Reverse Path Segment List TLV to build the echo- 481 reply. The responder MUST follow the normal FEC validation 482 procedures as described in [RFC8029] and [RFC8287] and this document 483 does not suggest any change to those procedures. When the Echo-reply 484 has to be sent out the Reverse Path Segment List TLV is used to 485 construct the MPLS packet to send out. 487 4.3. Sending an Echo-Reply 489 The Echo-Reply message is sent as MPLS packet with a MPLS label 490 stack. The Echo-Reply message MUST be constructed as described in 491 the [RFC8029]. An MPLS packet is constructed with Echo-reply in the 492 payload. The top label MUST be constructed from the first Segment 493 from the Reverse Path Segment List TLV. The remaining labels MUST 494 follow the order from the Reverse Path Segment List TLV. The 495 responder MAY check the reachability of the top label in its own LFIB 496 before sending the Echo-Reply. 498 5. Detailed Example 500 An example topology is given in Figure 1 . This will be used in below 501 sections to explain LSP Ping and Traceroute procedures. The PMS/ 502 Head-end has complete view of topology. PE1, P1, P2, ASBR1 and ASBR2 503 are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are in AS2. 505 AS1 and AS2 have Segment Routing enabled. IGPs like OSPF/ISIS are 506 used to flood SIDs in each Autonomous System. The ASBR1, ASBR2, 507 ASBR3, ASBR4 advertise BGP EPE SIDs for the inter-AS links. Topology 508 of AS1 and AS2 are advertised via BGP-LS to the controller/PMS or 509 Head-end node. The EPE-SIDs are also advertised via BGP-LS as 510 described in [I-D.ietf-idr-bgpls-segment-routing-epe] 512 The description in the document uses below notations for Segment 513 Identifiers(SIDs). 515 Node SIDs : N-PE1, N-P1, N-ASBR1 etc. 517 Adjacency SIDs : Adj-PE1-P1, Adj-P1-P2 etc. 519 EPE SIDS : EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 etc. 521 Let us consider a traffic engineered path built from PE1 to PE4 with 522 Segment List stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 523 for following procedures. This stack may be programmed by 524 controller/PMS or Head-end router PE1 may have imported the whole 525 topology information from BGP-LS and computed the inter-AS path. 527 5.1. Procedures for Segment Routing LSP ping 529 To perform LSP ping procedure on an SR-Path from PE1 to PE4 530 consisting of label stacks [N-P1,N-ASBR1,EPE-ASBR1-ASBR4, N-PE4], The 531 remote end(PE4) needs IP connectivity to head end(PE1) for the 532 Segment Routing ping to succeed, because Echo-reply needs to travel 533 back to PE1 from PE4. But in typical deployment scenario there will 534 be no ip route from PE4 to PE1 as they belong to different ASes. 536 PE1 adds Reverse Path from PE4 to PE1 in the MPLS Echo-request using 537 multiple Segments in "Reverse Path Segment List TLV" as defined 538 above. An example reverse path Segment List for PE1 to PE4 for LSP 539 ping is [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. An implementation may 540 also build a Reverse Path Segment List consisting of labels to reach 541 its own AS. Once the label stack is popped-off the Echo-reply 542 message will be exposed.The further packet forwarding will be based 543 on ip lookup. An example Reverse Path Segment List for this case 544 could be [N-ASBR4, EPE-ASBR4-ASBR1]. 546 On receiving MPLS Echo-request PE4 first validates FEC in the Echo- 547 request. PE4 then builds label stack to send the response from PE4 548 to PE1 by copying the labels from "Reverse Path Segment List TLV". 549 PE4 builds the Echo-reply packet with the MPLS label stack 550 constructed and imposes MPLS headers on top of Echo-reply packet and 551 sends out the packet towards PE1. This Segment List stack can 552 successfully steer reply back to Head-end node(PE1). 554 5.2. Procedures for Segment Routing LSP Traceroute 556 As described in the procedures for LSP ping, the reverse Segment List 557 may be sent from head-end in which case the LSP Traceroute procedures 558 are similar to LSP ping. The head-end constructs the Reverse Path 559 Segment List TLV and the egress node uses the Reverse Path Segment 560 List to construct the Echo-reply packet header. Head-end/PMS is 561 aware of the reverse path from every node visited in the network and 562 builds the Reverse Path Segment List for every visited node 563 accordingly. 565 For Example: 567 For the same traffic engineered path PE1 to PE4 mentioned in above 568 sections, let us assume there is no reverse path available from the 569 nodes ASBR4 to PE1. During the Traceroute procedure, when PE1 has to 570 visit ASBR4, it builds reverse Path Label Stack TLV and includes 571 label to the border-node which has the route to, PE1. In this 572 example the Reverse Path Segment List TLV will contain [EPE- 573 ASBR4-ASBR1]. Further down the traceroute procedure when P3 or P4 574 node is being visited, PE1 build the Reverse Path Segment List TLV 575 containing [N-ASBR4, EPE-ASBR4-ASBR1]. The Echo-reply will be an 576 MPLS packet with this label stack and will be forwarded to PE1. 578 6. Building Reverse Path Segment List TLV dynamically 580 In some cases, the head-end may not have complete visibility of 581 Inter-AS topology. In such cases, it can rely on downstream routers 582 to build the reverse path for mpls traceroute procedures. For this 583 purpose, the Reverse Path Segment List TLV is carried in the Echo- 584 Reply. 586 6.1. The procedures to build the reverse path 588 When an ASBR receives an echo-request from another AS, and ASBR is 589 configured to build the Reverse Path dynamically, ASBR MUST build a 590 Reverse Path Segmnet List TLV and add it in echo-reply. ASBR MUST 591 locally decide the outgoing interface for the echo-reply packet. 592 Generally, remote ASBR will choose interface on which the incoming 593 OAM packet was receieved to send the echo-reply out. Reverse Path 594 Segment List TLV is built by adding two segment sub TLVs. The top 595 segment sub TLV consists of the ASBR's Node SID and second segment 596 consists of the EPE SID in the reverse direction to reach the AS from 597 which the OAM packet was received.The type of segment chosen to build 598 Reverse Path Segment List TLV is implementation dependent. In cases 599 where the AS is configured with different SRGBs, the Node SID of the 600 ASBR should be represented using type 3 segment so that all the nodes 601 inside the AS can correctly translate the Node-SID to a label. 603 Irrespective of which type of segment is included in the Reverse Path 604 Segment List TLV, the responder of echo-request always translates the 605 Reverse Path Segment List TLV to a label stack and builds MPLS header 606 for the the echo-reply packet. This procedure can be applied to an 607 end-to-end path consisting of multiple ASes. Each ASBR at the border 608 adds its Node-SID and EPE-SID on top of existing segments in the 609 Reverse Path Segment List. 611 6.2. Details with example 613 Let us consider a traffic engineered path built from PE1 to PE4 with 614 a label stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 for 615 the following procedures. This traceroute doesn't need any Reverse 616 Path Segment List TLV till it leaves AS1, because IP connectivity 617 will be there to send echo-reply. But this traceroute requires 618 Reverse Path Segment List TLV once it starts probing AS2 routers. 619 According to this procedure, ASBR4 should add Reverse Path Segment 620 List TLV in its echo-reply. ASBR4 should form this Reverse Path 621 Segment List TLV using its own Node SID(N-ASBR4) and EPE SID (EPE- 622 ASRB4-ASBR1) labels. Then PE1 should use this Reverse Path Segment 623 List TLV in subsequent echo-requests. In this example, when the 624 subsequent echo-request reaches P3, it should use this Reverse Path 625 Segment List TLV for sending the echo-reply. The same Reverse Path 626 Segment List TLV is enough for any router in AS2 to send the reply. 627 Because the first label(N-ASBR4) can direct echo-reply to ASBR4 and 628 second one (EPE-ASBR4-ASBR1) to direct echo-reply to AS1. Once echo 629 reply reaches AS1, normal IP forwarding helps it to reach PE1 or the 630 head-end. 632 7. Security Considerations 634 TBD 636 8. IANA Considerations 638 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 639 Parameters TLVs Registry 641 Reverse Path Segment List TLV : TBD (Range 32768-65535) 643 Sub-TLV of Reverse path segment List TLV (New Registry) 645 SID only in the form of mpls label : TBD (Range 32768-65535) 647 IPv4 Node Address with optional SID for SR-MPLS : TBD (Range 648 32768-65535) 650 IPv6 Node Address with optional SID for SR-MPLS : TBD (Range 651 32768-65535) 653 9. Contributors 655 1.Carlos Pignataro 657 Cisco Systems, Inc. 659 cpignata@cisco.com 661 2. Zafar Ali 663 Cisco Systems, Inc. 665 zali@cisco.com 667 10. Acknowledgments 669 Thanks to Bruno Decreane for suggesting use of generic Segment sub- 670 TLV. 672 11. References 674 11.1. Normative References 676 [I-D.ietf-idr-segment-routing-te-policy] 677 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 678 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 679 Routing Policies in BGP", draft-ietf-idr-segment-routing- 680 te-policy-11 (work in progress), November 2020. 682 [I-D.ietf-spring-segment-routing-central-epe] 683 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 684 Afanasiev, "Segment Routing Centralized BGP Egress Peer 685 Engineering", draft-ietf-spring-segment-routing-central- 686 epe-10 (work in progress), December 2017. 688 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 689 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 690 Switched (MPLS) Data-Plane Failures", RFC 8029, 691 DOI 10.17487/RFC8029, March 2017, 692 . 694 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 695 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 696 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 697 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 698 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 699 . 701 11.2. Informative References 703 [I-D.ietf-idr-bgpls-segment-routing-epe] 704 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 705 S., and J. Dong, "BGP-LS extensions for Segment Routing 706 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 707 segment-routing-epe-19 (work in progress), May 2019. 709 [I-D.ietf-mpls-interas-lspping] 710 Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane 711 Failures in Inter-AS and inter-provider Scenarios", draft- 712 ietf-mpls-interas-lspping-00 (work in progress), March 713 2007. 715 [I-D.ietf-spring-segment-routing-policy] 716 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 717 P. Mattes, "Segment Routing Policy Architecture", draft- 718 ietf-spring-segment-routing-policy-09 (work in progress), 719 November 2020. 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, 723 DOI 10.17487/RFC2119, March 1997, 724 . 726 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 727 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 728 . 730 [RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G. 731 Swallow, Ed., "Relayed Echo Reply Mechanism for Label 732 Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743, 733 January 2016, . 735 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 736 Decraene, B., Litkowski, S., and R. Shakir, "Segment 737 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 738 July 2018, . 740 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 741 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 742 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 743 2018, . 745 [RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., 746 Henderickx, W., and D. Cooper, "Interconnecting Millions 747 of Endpoints with Segment Routing", RFC 8604, 748 DOI 10.17487/RFC8604, June 2019, 749 . 751 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 752 Decraene, B., Litkowski, S., and R. Shakir, "Segment 753 Routing with the MPLS Data Plane", RFC 8660, 754 DOI 10.17487/RFC8660, December 2019, 755 . 757 Authors' Addresses 759 Shraddha Hegde 760 Juniper Networks Inc. 761 Exora Business Park 762 Bangalore, KA 560103 763 India 765 Email: shraddha@juniper.net 767 Kapil Arora 768 Juniper Networks Inc. 770 Email: kapilaro@juniper.net 772 Mukul Srivastava 773 Juniper Networks Inc. 775 Email: msri@juniper.net 776 Samson Ninan 777 Individual Contributor 779 Email: samson.cse@gmail.com 781 Nagendra Kumar 782 Cisco Systems, Inc. 784 Email: naikumar@cisco.com