idnits 2.17.1 draft-ninan-spring-mpls-inter-as-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8287], [RFC8604]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 3, 2019) is 1635 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 487, but not defined == Missing Reference: 'N-ASBR1' is mentioned on line 487, but not defined == Missing Reference: 'EPE-ASBR1-ASBR4' is mentioned on line 487, but not defined == Missing Reference: 'N-PE4' is mentioned on line 487, but not defined == Missing Reference: 'N-ASBR4' is mentioned on line 532, but not defined == Missing Reference: 'EPE-ASBR4-ASBR1' is mentioned on line 532, but not defined == Missing Reference: 'N-PE1' is mentioned on line 496, but not defined == Unused Reference: 'I-D.ietf-mpls-interas-lspping' is defined on line 647, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-07 ** 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-03 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing area S. Hegde 3 Internet-Draft K. Arora 4 Intended status: Standards Track S. Ninan 5 Expires: May 6, 2020 M. Srivastava 6 Juniper Networks Inc. 7 N. Kumar 8 Cisco Systems, Inc. 9 November 3, 2019 11 PMS/Head-end based MPLS Ping and Traceroute in Inter-AS SR Networks 12 draft-ninan-spring-mpls-inter-as-oam-02 14 Abstract 16 Segment Routing (SR) architecture leverages source routing and 17 tunneling paradigms and can be directly applied to the use of a 18 Multiprotocol Label Switching (MPLS) data plane. Segment Routing 19 also provides an easy and efficient way to provide inter connectivity 20 in a large scale network as described in [RFC8604]. [RFC8287] 21 illustrates the problem and defines extensions to perform LSP Ping 22 and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency 23 Segment Identifiers (SIDs) with an MPLS data plane. It is useful to 24 have the LSP Ping and traceroute procedures when an SR end-to-end 25 path spans across multiple ASes. This document describes mechanisms 26 to facilitae LSP ping and traceroute in inter-AS SR networks in an 27 efficient manner with simple OAM protocol extension which uses 28 dataplane forwarding alone for sending Echo-Reply. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 6, 2020. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Reverse Path Segment List TLV . . . . . . . . . . . . . . . . 4 72 2.1. Reverse Path Segment List TLV definition . . . . . . . . 5 73 2.1.1. Segment sub-TLV . . . . . . . . . . . . . . . . . . . 5 74 2.2. SRv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 9 75 3. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 10 76 3.1. Sending an Echo-Request . . . . . . . . . . . . . . . . . 10 77 3.2. Receiving an Echo-Request . . . . . . . . . . . . . . . . 10 78 3.3. Sending an Echo-Reply . . . . . . . . . . . . . . . . . . 10 79 4. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 10 80 4.1. Procedures for Segment Routing LSP ping . . . . . . . . . 11 81 4.2. Procedures for Segment Routing LSP Traceroute . . . . . . 12 82 5. Building Reverse Path Segment List TLV dynamically . . . . . 12 83 5.1. The procedures to build the reverse path . . . . . . . . 12 84 5.2. Details with example . . . . . . . . . . . . . . . . . . 13 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 91 10.2. Informative References . . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 +----------------+ 97 | Controller/PMS | 98 +----------------+ 100 |---------AS1----------| |--------AS2----------| 102 ASBR2-------ASBR3 103 / \ 104 / \ 105 PE1------P1------P2 P3------P4------PE4 106 \ / 107 \ / 108 ASBR1-------ASBR4 110 Figure 1: Inter-AS Segment Routing topology 112 Many network deployments have built their networks consisting of 113 multiple Autonomous Systems either for ease of operations or as a 114 result of network mergers and acquisitions. Segment Routing can be 115 deployed in such scenarios to provide end to end paths, traversing 116 multiple Autonomous systems(AS). These paths consist of Segment 117 Identifiers(SID) of different type as per [RFC8402]. 119 [I-D.ietf-spring-segment-routing-mpls] specifies the forwarding plane 120 behaviour to allow Segment Routing to operate on top of MPLS data 121 plane. [I-D.ietf-spring-segment-routing-central-epe] describes BGP 122 peering SIDs, which will help in steering packet from one Autonomous 123 system to another. Using above SR capabilities, paths which span 124 across multiple Autonomous systems can be created. 126 For example Figure 1 describes an inter-AS network scenario 127 consisting of ASes AS1 and AS2. Both AS1 and AS2 are Segment Routing 128 enabled and the EPE links have EPE labels configured and advertised 129 via [I-D.ietf-idr-bgpls-segment-routing-epe]. Controller or head-end 130 can build end-to-end Traffic-Engineered path Node-SIDs, Adjacency- 131 SIDs and EPE-SIDs. It is advantageous for operations to be able to 132 perform LSP ping and traceroute procedures on these inter-AS SR 133 paths. LSP ping/traceroute procedures use ip connectivity for Echo- 134 reply to reach the head-end. In inter-AS networks, ip connectivity 135 may not be there from each router in the path.For example in Figure 1 136 P3 and P4 may not have ip connectivity for PE1. 138 [RFC8403] describes mechanisms to carry out the MPLS ping/traceroute 139 from a PMS. It is possible to build GRE tunnels or static routes to 140 each router in the network to get IP connectivity for the reverse 141 path. This mechanism is operationally very heavy and requires PMS to 142 be capable of building huge number of GRE tunnels, which may not be 143 feasible. 145 It is not possible to carry out LSP ping and Traceroute functionality 146 on these paths to verify basic connectivity and fault isolation using 147 existing LSP ping and Traceroute mechanism([RFC8287] and [RFC8029]). 148 This is because, there exists no IP connectivity to source address of 149 ping packet, which is in a different AS, from the destination of 150 Ping/Traceroute. 152 [RFC7743] describes a Echo-relay based solution based on advertising 153 a new Relay Node Address Stack TLV containing stack of Echo-relay ip 154 addresses. This mechanism requires the return ping packet to reach 155 the control plane on every relay node. 157 This document describes a mechanism which is efficient and simple and 158 can be easily deployed in SR networks. This mechanism uses a new 159 Reverse Path Segment List TLV to convey the reverse path. The TLV 160 can either be derived by a smart application/controller which has a 161 full topology view or by the help of intermediate nodes. 163 2. Reverse Path Segment List TLV 165 Segment Routing networks statically assign the labels to nodes and 166 PMS/Head-end may know the entire database. The reverse path can be 167 built from PMS/Head-end by stacking segments for the reverse path. A 168 new TLV "Reverse Path Segment List TLV" is defined. Each TLV 169 contains a list of segment sub-TLVs which may be a prefix/adjacency/ 170 binding SID/EPE SID. MPLS Echo -request should contain this TLV, 171 which defines reverse path to reach source from the destination. 173 The new Reverse Path Segment List TLV is an optional TLV. This TLV 174 is carried in the Echo-Request message. This optional TLV MAY appear 175 in the Echo-request message in any order before or after Target FEC 176 Stack TLV. The Reverse Path Segment List TLV is defined as below. 177 Each MPLS Echo-request SHOULD contain this TLV in inter-AS cases, 178 which will enable remote end(egress/transit routers) to send the 179 reply to source. 181 In some cases, the head-end may not have complete visibility. In 182 such cases, it can rely on downstream routers to build the reverse 183 path. For this purpose, the TLV is carried in the Echo-Reply 184 message. Section 5 describes one basic idea in this direction. 186 2.1. Reverse Path Segment List TLV definition 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |Type = TBD | Length | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Segment sub TLV | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | ... | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 2: Reverse Path Segment List TLV 200 Type: TBD 202 Length: Length of TLV including TLV header and length of sub TLV. 204 There can be one or more segment sub-TLVs in a Reverse Path Segment 205 List TLV. The applicable segment types are described in 206 Section 2.1.1. The Segment type in a Reverse Path Segment List TLV 207 MAY be same or different. 209 2.1.1. Segment sub-TLV 211 [I-D.ietf-spring-segment-routing-policy] defines various types of 212 segments. These segment types are applicable here. One or more 213 segment sub-TLV can be included. The segment sub-TLVs included MAY 214 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 2.1.1.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 | Flags | RESERVED | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Label | TC |S| TTL | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 3: Type 1 Segment sub-TLV 240 where: 242 Type: 1 (to be assigned by IANA from the registry "SR Policy List 243 Sub-TLVs" defined in [I-D.ietf-idr-segment-routing-te-policy]). 245 Length is 6. 247 Flags: 1 octet of flags as defined in Section Section 2.1.1.4. 249 RESERVED: 1 octet of reserved bits. SHOULD be unset on transmission 250 and MUST be ignored on receipt. 252 Label: 20 bits of label value. 254 TC: 3 bits of traffic class 256 S: 1 bit of bottom-of-stack. 258 TTL: 1 octet of TTL. 260 The following applies to the Type-1 Segment sub-TLV: 262 The S bit SHOULD be zero upon transmission, and MUST be ignored upon 263 reception. 265 If the originator wants the receiver to choose the TC value, it sets 266 the TC field to zero. 268 If the originator wants the receiver to choose the TTL value, it sets 269 the TTL field to 255. 271 If the originator wants to recommend a value for these fields, it 272 puts those values in the TC and/or TTL fields. 274 The receiver MAY override the originator's values for these fields. 275 This would be determined by local policy at the receiver. One 276 possible policy would be to override the fields only if the fields 277 have the default values specified above. 279 2.1.1.2. Type 3: IPv4 Node Address with optional SID for SR-MPLS 281 The Type-3 Segment Sub-TLV encodes an IPv4 node address, SR Algorithm 282 and an optional SID in the form of an MPLS label. The format is as 283 follows: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type | Length | Flags | SR Algorithm | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | IPv4 Node Address (4 octets) | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | SID (optional, 4 octets) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 4: Type 3 Segment sub-TLV 297 where: 299 Type: 3 (to be assigned by IANA from the registry "SR Policy List 300 Sub-TLVs" defined in [I-D.ietf-idr-segment-routing-te-policy]). 302 Length is 6 or 10. 304 Flags: 1 octet of flags as defined in Section Section 2.1.1.4. 306 SR Algorithm: 1 octet specifying SR Algorithm as described in section 307 3.1.1 in [RFC8402], when A-Flag as defined in 308 Section Section 2.1.1.4is present. SR Algorithm is used by SRPM as 309 described in section 4 in [I-D.ietf-spring-segment-routing-policy]. 310 When A-Flag is not encoded, this field SHOULD be unset on 311 transmission and MUST be ignored on receipt. 313 IPv4 Node Address: a 4 octet IPv4 address representing a node. 315 SID: 4 octet MPLS label. 317 The following applies to the Type-3 Segment sub-TLV: 319 The IPv4 Node Address MUST be present. 321 The SID is optional and specifies a 4 octet MPLS SID containing 322 label, TC, S and TTL as defined in Section Section 2.1.1.1. 324 If length is 6, then only the IPv4 Node Address is present. 326 If length is 10, then the IPv4 Node Address and the MPLS SID are 327 present. 329 2.1.1.3. Type 4: IPv6 Node Address with optional SID for SR MPLS 331 The Type-4 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm 332 and an optional SID in the form of an MPLS label. The format is as 333 follows: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type | Length | Flags | SR Algorithm | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 // IPv6 Node Address (16 octets) // 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | SID (optional, 4 octets) | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Figure 5: Type 4 Segment sub-TLV 347 where: 349 Type: 4 (to be assigned by IANA from the registry "SR Policy List 350 Sub-TLVs" defined in [I-D.ietf-idr-segment-routing-te-policy]). 352 Length is 18 or 22. 354 Flags: 1 octet of flags as defined in Section Section 2.1.1.4. 356 SR Algorithm: 1 octet specifying SR Algorithm as described in section 357 3.1.1 in [RFC8402], when A-Flag as defined in Section Section 2.1.1.4 358 is present. SR Algorithm is used by SRPM as described in section 4 359 in [I-D.ietf-spring-segment-routing-policy]. When A-Flag is not 360 encoded, this field SHOULD be unset on transmission and MUST be 361 ignored on receipt. 363 IPv6 Node Address: a 16 octet IPv6 address representing a node. 365 SID: 4 octet MPLS label. 367 The following applies to the Type-4 Segment sub-TLV: 369 The IPv6 Node Address MUST be present. 371 The SID is optional and specifies a 4 octet MPLS SID containing 372 label, TC, S and TTL as defined in Section Section 2.1.1.1 . 374 If length is 18, then only the IPv6 Node Address is present. 376 If length is 22, then the IPv6 Node Address and the MPLS SID are 377 present. 379 2.1.1.4. Segment Flags 381 The Segment Types described above MAY contain following flags in the 382 "Flags" field (codes to be assigned by IANA from the registry "SR 383 Policy Segment Flags" defined 384 in[I-D.ietf-idr-segment-routing-te-policy]) 386 0 1 2 3 4 5 6 7 387 +-+-+-+-+-+-+-+-+ 388 |V|A| | 389 +-+-+-+-+-+-+-+-+ 391 Figure 6: Flags 393 where: 395 V-Flag: This flag is used by SRPM for the purpose of "SID 396 verification" as described in Section 5.1 in 397 [I-D.ietf-spring-segment-routing-policy]. 399 A-Flag: This flag indicates the presence of SR Algorithm id in the 400 "SR Algorithm" field applicable to various Segment Types. SR 401 Algorithm is used by SRPM as described in section 4 in 402 [I-D.ietf-spring-segment-routing-policy]. 404 Unused bits in the Flag octet SHOULD be set to zero upon transmission 405 and MUST be ignored upon receipt. 407 The following applies to the Segment Flags: 409 V-Flag is applicable to all Segment Types. 411 A-Flag is applicable to Segment Types 3, 4 and 9. If A-Flag appears 412 with any other Segment Type, it MUST be ignored. 414 2.2. SRv6 Dataplane 416 SRv6 dataplane is not in the scope of this document and will be 417 addressed in a separate document. 419 3. Detailed Procedures 421 3.1. Sending an Echo-Request 423 In the inter-AS scenario when there is no reverse path connectivity, 424 LSP ping initiator MUST add a Reverse Path Segment List TLV in the 425 Echo-request message. The reverse Segment List MUST correspond to 426 the return path from the egress. The Reverse Path Segment List TLV 427 is an ordered list of Segments. The first Segment corresponds to the 428 top Segment in MPLS header that the responder MUST use while sending 429 the Echo-reply. 431 3.2. Receiving an Echo-Request 433 When a receiver does not understand the Reverse Path Segment List 434 TLV, it SHOULD silently ignore the TLV and proceed with normal 435 processing as described in [RFC8029].When a Reverse Path Segment List 436 TLV is received, and the responder supports processing it, it MUST 437 use the Segments in Reverse Path Segment List TLV to build the echo- 438 reply. The responder MUST follow the normal FEC validation 439 procedures as described in [RFC8029] and [RFC8287] and this document 440 does not suggest any change to those procedures. When the Echo-reply 441 has to be sent out the Reverse Path Segment List TLV is used to 442 construct the MPLS packet to send out. 444 3.3. Sending an Echo-Reply 446 The Echo-Reply message is sent as MPLS packet with a MPLS label 447 stack. The Echo-Reply message MUST be constructed as described in 448 the [RFC8029]. An MPLS packet is constructed with Echo-reply in the 449 payload. The top label MUST be constructed from the first Segment 450 from the Reverse Path Segment List TLV. The remaining labels MUST 451 follow the order from the Reverse Path Segment List TLV. The 452 responder MAY check the reachability of the top label in its own LFIB 453 before sending the Echo-Reply. 455 4. Detailed Example 457 An example topology is given in Figure 1 . This will be used in below 458 sections to explain LSP Ping and Traceroute procedures. The PMS/ 459 Head-end has complete view of topology. PE1, P1, P2, ASBR1 and ASBR2 460 are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are in AS2. 462 AS1 and AS2 have Segment Routing enabled. IGPs like OSPF/ISIS are 463 used to flood SIDs in each Autonomous System. The ASBR1, ASBR2, 464 ASBR3, ASBR4 advertise BGP EPE SIDs for the inter-AS links. Topology 465 of AS1 and AS2 are advertised via BGP-LS to the controller/PMS or 466 Head-end node. The EPE-SIDs are also advertised via BGP-LS as 467 described in [I-D.ietf-idr-bgpls-segment-routing-epe] 469 The description in the document uses below notations for Segment 470 Identifiers(SIDs). 472 Node SIDs : N-PE1, N-P1, N-ASBR1 etc. 474 Adjacency SIDs : Adj-PE1-P1, Adj-P1-P2 etc. 476 EPE SIDS : EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 etc. 478 Let us consider a traffic engineered path built from PE1 to PE4 with 479 Segment List stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 480 for following procedures. This stack may be programmed by 481 controller/PMS or Head-end router PE1 may have imported the whole 482 topology information from BGP-LS and computed the inter-AS path. 484 4.1. Procedures for Segment Routing LSP ping 486 To perform LSP ping procedure on an SR-Path from PE1 to PE4 487 consisting of label stacks [N-P1,N-ASBR1,EPE-ASBR1-ASBR4, N-PE4], The 488 remote end(PE4) needs IP connectivity to head end(PE1) for the 489 Segment Routing ping to succeed, because Echo-reply needs to travel 490 back to PE1 from PE4. But in typical deployment scenario there will 491 be no ip route from PE4 to PE1 as they belong to different ASes. 493 PE1 adds Reverse Path from PE4 to PE1 in the MPLS Echo-request using 494 multiple Segments in "Reverse Path Segment List TLV" as defined 495 above. An example reverse path Segment List for PE1 to PE4 for LSP 496 ping is [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. An implementation may 497 also build a Reverse Path Segment List consisting of labels to reach 498 its own AS. Once the label stack is popped-off the Echo-reply 499 message will be exposed.The further packet forwarding will be based 500 on ip lookup. An example Reverse Path Segment List for this case 501 could be [N-ASBR4, EPE-ASBR4-ASBR1]. 503 On receiving MPLS Echo-request PE4 first validates FEC in the Echo- 504 request. PE4 then builds label stack to send the response from PE4 505 to PE1 by copying the labels from "Reverse Path Segment List TLV". 506 PE4 builds the Echo-reply packet with the MPLS label stack 507 constructed and imposes MPLS headers on top of Echo-reply packet and 508 sends out the packet towards PE1. This Segment List stack can 509 successfully steer reply back to Head-end node(PE1). 511 4.2. Procedures for Segment Routing LSP Traceroute 513 As described in the procedures for LSP ping, the reverse Segment List 514 may be sent from head-end in which case the LSP Traceroute procedures 515 are similar to LSP ping. The head-end constructs the Reverse Path 516 Segment List TLV and the egress node uses the Reverse Path Segment 517 List to construct the Echo-reply packet header. Head-end/PMS is 518 aware of the reverse path from every node visited in the network and 519 builds the Reverse Path Segment List for every visited node 520 accordingly. 522 For Example: 524 For the same traffic engineered path PE1 to PE4 mentioned in above 525 sections, let us assume there is no reverse path available from the 526 nodes ASBR4 to PE1. During the Traceroute procedure, when PE1 has to 527 visit ASBR4, it builds reverse Path Label Stack TLV and includes 528 label to the border-node which has the route to, PE1. In this 529 example the Reverse Path Segment List TLV will contain [EPE- 530 ASBR4-ASBR1]. Further down the traceroute procedure when P3 or P4 531 node is being visited, PE1 build the Reverse Path Segment List TLV 532 containing [N-ASBR4, EPE-ASBR4-ASBR1]. The Echo-reply will be an 533 MPLS packet with this label stack and will be forwarded to PE1. 535 5. Building Reverse Path Segment List TLV dynamically 537 In some cases, the head-end may not have complete visibility of 538 Inter-AS topology. In such cases, it can rely on downstream routers 539 to build the reverse path for mpls traceroute procedures. For this 540 purpose, the Reverse Path Segment List TLV is carried in the Echo- 541 Reply. 543 5.1. The procedures to build the reverse path 545 When an ASBR receives an echo-request from another AS, and ASBR is 546 configured to build the Reverse Path dynamically, ASBR MUST build a 547 Reverse Path Segmnet List TLV and add it in echo-reply. ASBR MUST 548 locally decide the outgoing interface for the echo-reply packet. 549 Generally, remote ASBR will choose interface on which the incoming 550 OAM packet was receieved to send the echo-reply out. Reverse Path 551 Segment List TLV is built by adding two segment sub TLVs. The top 552 segment sub TLV consists of the ASBR's Node SID and second segment 553 consists of the EPE SID in the reverse direction to reach the AS from 554 which the OAM packet was received.The type of segment chosen to build 555 Reverse Path Segment List TLV is implementation dependent. In cases 556 where the AS is configured with different SRGBs, the Node SID of the 557 ASBR should be represented using type 3 segment so that all the nodes 558 inside the AS can correctly translate the Node-SID to a label. 560 Irrespective of which type of segment is included in the Reverse Path 561 Segment List TLV, the responder of echo-request always translates the 562 Reverse Path Segment List TLV to a label stack and builds MPLS header 563 for the the echo-reply packet. 565 5.2. Details with example 567 Let us consider a traffic engineered path built from PE1 to PE4 with 568 a label stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 for 569 the following procedures. This traceroute doesn't need any Reverse 570 Path Segment List TLV till it leaves AS1, because IP connectivity 571 will be there to send echo-reply. But this traceroute requires 572 Reverse Path Segment List TLV once it starts probing AS2 routers. 573 According to this procedure, ASBR4 should add Reverse Path Segment 574 List TLV in its echo-reply. ASBR4 should form this Reverse Path 575 Segment List TLV using its own Node SID(N-ASBR4) and EPE SID (EPE- 576 ASRB4-ASBR1) labels. Then PE1 should use this Reverse Path Segment 577 List TLV in subsequent echo-requests. In this example, when the 578 subsequent echo-request reaches P3, it should use this Reverse Path 579 Segment List TLV for sending the echo-reply. The same Reverse Path 580 Segment List TLV is enough for any router in AS2 to send the reply. 581 Because the first label(N-ASBR4) can direct echo-reply to ASBR4 and 582 second one (EPE-ASBR4-ASBR1) to direct echo-reply to AS1. Once echo 583 reply reaches AS1, normal IP forwarding helps it to reach PE1 or the 584 head-end. 586 6. Security Considerations 588 TBD 590 7. IANA Considerations 592 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 593 Parameters TLVs Registry 595 Reverse Path Segment List TLV : TBD 597 8. Contributors 599 1.Carlos Pignataro 601 Cisco Systems, Inc. 603 cpignata@cisco.com 605 2. Zafar Ali 607 Cisco Systems, Inc. 609 zali@cisco.com 611 9. Acknowledgments 613 Thanks to Bruno Decreane for suggesting use of generic Segment sub- 614 TLV. 616 10. References 618 10.1. Normative References 620 [I-D.ietf-idr-segment-routing-te-policy] 621 Previdi, S., Filsfils, C., Mattes, P., Rosen, E., Jain, 622 D., and S. Lin, "Advertising Segment Routing Policies in 623 BGP", draft-ietf-idr-segment-routing-te-policy-07 (work in 624 progress), July 2019. 626 [I-D.ietf-spring-segment-routing-central-epe] 627 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 628 Afanasiev, "Segment Routing Centralized BGP Egress Peer 629 Engineering", draft-ietf-spring-segment-routing-central- 630 epe-10 (work in progress), December 2017. 632 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 633 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 634 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 635 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 636 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 637 . 639 10.2. Informative References 641 [I-D.ietf-idr-bgpls-segment-routing-epe] 642 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 643 S., and J. Dong, "BGP-LS extensions for Segment Routing 644 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 645 segment-routing-epe-19 (work in progress), May 2019. 647 [I-D.ietf-mpls-interas-lspping] 648 Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane 649 Failures in Inter-AS and inter-provider Scenarios", draft- 650 ietf-mpls-interas-lspping-00 (work in progress), March 651 2007. 653 [I-D.ietf-spring-segment-routing-mpls] 654 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 655 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 656 data plane", draft-ietf-spring-segment-routing-mpls-22 657 (work in progress), May 2019. 659 [I-D.ietf-spring-segment-routing-policy] 660 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 661 bogdanov@google.com, b., and P. Mattes, "Segment Routing 662 Policy Architecture", draft-ietf-spring-segment-routing- 663 policy-03 (work in progress), May 2019. 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, 667 DOI 10.17487/RFC2119, March 1997, 668 . 670 [RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G. 671 Swallow, Ed., "Relayed Echo Reply Mechanism for Label 672 Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743, 673 January 2016, . 675 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 676 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 677 Switched (MPLS) Data-Plane Failures", RFC 8029, 678 DOI 10.17487/RFC8029, March 2017, 679 . 681 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 682 Decraene, B., Litkowski, S., and R. Shakir, "Segment 683 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 684 July 2018, . 686 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 687 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 688 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 689 2018, . 691 [RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., 692 Henderickx, W., and D. Cooper, "Interconnecting Millions 693 of Endpoints with Segment Routing", RFC 8604, 694 DOI 10.17487/RFC8604, June 2019, 695 . 697 Authors' Addresses 699 Shraddha Hegde 700 Juniper Networks Inc. 701 Exora Business Park 702 Bangalore, KA 560103 703 India 705 Email: shraddha@juniper.net 707 Kapil Arora 708 Juniper Networks Inc. 710 Email: kapilaro@juniper.net 712 Samson Ninan 713 Juniper Networks Inc. 715 Email: samsonn@juniper.net 717 Mukul Srivastava 718 Juniper Networks Inc. 720 Email: msri@juniper.net 722 Nagendra Kumar 723 Cisco Systems, Inc. 725 Email: naikumar@cisco.com