idnits 2.17.1 draft-ninan-spring-mpls-inter-as-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 : ---------------------------------------------------------------------------- ** 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 (July 5, 2019) is 1756 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 265, but not defined == Missing Reference: 'N-ASBR1' is mentioned on line 265, but not defined == Missing Reference: 'EPE-ASBR1-ASBR4' is mentioned on line 265, but not defined == Missing Reference: 'N-PE4' is mentioned on line 265, but not defined == Missing Reference: 'N-ASBR4' is mentioned on line 274, but not defined == Missing Reference: 'EPE-ASBR4-ASBR1' is mentioned on line 274, but not defined == Missing Reference: 'N-PE1' is mentioned on line 274, but not defined == Missing Reference: 'EPE-ASBR2-ASBR1' is mentioned on line 306, but not defined == Unused Reference: 'I-D.ietf-mpls-interas-lspping' is defined on line 350, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-spring-segment-routing-central-epe (ref. 'I-D.ietf-spring-segment-routing-central-epe') Summary: 2 errors (**), 0 flaws (~~), 10 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: January 6, 2020 M. Srivastava 6 Juniper Networks Inc. 7 July 5, 2019 9 PMS/Head-end based MPLS Ping and Traceroute in Inter-AS SR Networks 10 draft-ninan-spring-mpls-inter-as-oam-01 12 Abstract 14 Segment Routing (SR) architecture leverages source routing and 15 tunneling paradigms and can be directly applied to the use of a 16 Multiprotocol Label Switching (MPLS) data plane. Segment Routing 17 also provides an easy and efficient way to provide inter connectivity 18 in a large scale network as described in [RFC8604]. [RFC8287] 19 illustrates the problem and defines extensions to perform LSP Ping 20 and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency 21 Segment Identifiers (SIDs) with an MPLS data plane. It is useful to 22 have the LSP Ping and traceroute procedures when an SR end-to-end 23 path spans across multiple ASes. This document describes mechanisms 24 to facilitae LSP ping and traceroute in inter-AS SR networks in an 25 efficient manner with simple OAM protocol extension which uses 26 dataplane 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 January 6, 2020. 50 Copyright Notice 52 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Reverse Path label stack TLV . . . . . . . . . . . . . . . . 4 69 2.1. Reverse Path label stack TLV definition . . . . . . . . . 4 70 2.2. SRv6 Dataplane . . . . . . . . . . . . . . . . . . . . . 5 71 3. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Sending an Echo-Request . . . . . . . . . . . . . . . . . 5 73 3.2. Receiving an Echo-Request . . . . . . . . . . . . . . . . 6 74 3.3. Sending an Echo-Reply . . . . . . . . . . . . . . . . . . 6 75 4. Detailed Example . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Procedures for Segment Routing LSP ping . . . . . . . . . 7 77 4.2. Procedures for Segment Routing LSP Traceroute . . . . . . 7 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 83 8.2. Informative References . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 87 +----------------+ 88 | Controller/PMS | 89 +----------------+ 91 |---------AS1----------| |--------AS2----------| 93 ASBR2-------ASBR3 94 / \ 95 / \ 96 PE1------P1------P2 P3------P4------PE4 97 \ / 98 \ / 99 ASBR1-------ASBR4 101 Figure 1: Inter-AS Segment Routing topology 103 Many network deployments have built their networks consisting of 104 multiple Autonomous Systems either for ease of operations or as a 105 result of network mergers and acquisitions. Segment Routing can be 106 deployed in such scenarios to provide end to end paths, traversing 107 multiple Autonomous systems(AS). These paths consist of Segment 108 Identifiers(SID) of different type as per [RFC8402]. 110 [I-D.ietf-spring-segment-routing-mpls] specifies the forwarding plane 111 behaviour to allow Segment Routing to operate on top of MPLS data 112 plane. [I-D.ietf-spring-segment-routing-central-epe] describes BGP 113 peering SIDs, which will help in steering packet from one Autonomous 114 system to another. Using above SR capabilities, paths which span 115 across multiple Autonomous systems can be created. 117 For example Figure 1 describes a topology consisting of inter-AS 118 network consisting of ASes AS1 and AS2. Both AS1 and AS2 are Segment 119 Routing enabled and the EPE links have EPE labels configured and 120 advertised via [I-D.ietf-idr-bgpls-segment-routing-epe]. Controller 121 or head-end can build end-to-end Traffic-Engineered path Node-SIDs, 122 Adjacency-SIDs and EPE-SIDs. It is advantageous for operations to be 123 able to perform LSP ping and traceroute procedures on these inter-AS 124 SR paths. LSP ping/traceroute procedures use ip connectivity for 125 Echo-reply to reach the head-end. In inter-AS networks, ip 126 connectivity may not be there from each router in the path.For 127 example in Figure 1 P3 and P4 may not have ip connectivity for PE1. 129 [RFC8403] describes mechanisms to carry out the MPLS ping/traceroute 130 from a PMS. It is possible to build GRE tunnels or static routes to 131 each router in the network to get IP connectivity for the return 132 path. This mechanism is operationally very heavy and requires PMS to 133 be capable of building huge number of GRE tunnels, which may not be 134 feasible. 136 It is not possible to carry out LSP ping and Traceroute functionality 137 on these paths to verify basic connectivity and fault isolation using 138 existing LSP ping and Traceroute mechanism([RFC8287] and [RFC8029]). 139 This is because, there exists no IP connectivity to source address of 140 ping packet, which is in a different AS, from the destination of 141 Ping/Traceroute. 143 [RFC7743] describes a Echo-relay based solution based on advertising 144 a new Relay Node Address Stack TLV containing stack of Echo-relay ip 145 addresses. This mechanism requires the return ping packet to reach 146 the control plane on every relay node. This document describes a 147 mechanism which is efficient and simple and can be easily deployed in 148 SR networks. 150 2. Reverse Path label stack TLV 152 Segment Routing networks statically assign the labels to nodes and 153 PMS/Head-end knows entire database. The return path can be built 154 from PMS/Head-end by stacking labels for the return path. A new TLV 155 "Reverse Path label stack TLV" is defined. Each TLV contains a list 156 of labels which may be a prefix/adjacency/binding SID/EPE SID. MPLS 157 Echo -request should contain this TLV, which defines reverse path to 158 reach source from the destination. 160 The new Reverse Path label stack TLV is an optional TLV. This TLV is 161 carried in the Echo-Request message. This optional TLV MAY appear in 162 the Echo-request message in any order before or after Target FEC 163 Stack TLV. The Reverse Path label stack TLV is defined as below. 164 Each MPLS Echo-request SHOULD contain this TLV in inter-AS cases, 165 which will enable remote end to send the reply to source. 167 2.1. Reverse Path label stack TLV definition 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 |Type = TBD | Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | No. of labels | Reseved | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Label (20 bits) | Reserved | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | ... | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 2: Reverse Path label stack TLV 182 Type: TBD 184 Length: Length of TLV including TLV header 186 No. Of labels: 188 Ordered set of Labels in the Reverse Path label stack 190 Label : 192 Represents 20 bit label. This field should be used to build the 193 return packet. The first label in the label stack represents the top 194 most label that should be encoded in the return packet. 196 2.2. SRv6 Dataplane 198 A future version of this document will address the SRv6 Dataplane. 200 3. Detailed Procedures 202 3.1. Sending an Echo-Request 204 LSP ping initiator MUST add a Return Path Label Stack TLV in the 205 Echo-request message. The return label stack MUST correspond to the 206 return path from the egress. The Reverse Path Label Stack TLV is an 207 ordered list of labels. The first label corresponds to the top label 208 that the responder should use to construct the Echo-reply. 210 3.2. Receiving an Echo-Request 212 When a receiver does not understand the Reverse Path Label Stack TLV, 213 it SHOULD silently ignore the TLV and proceed with normal processing 214 as described in [RFC8029].When a Reverse Path Label Stack TLV is 215 received, and the responder supports processing it, it MUST use the 216 labels in Reverse Path Label Stack TLV to build the echo-reply. The 217 responder MUST follow the normal FEC validation procedures as 218 described in [RFC8029] and [RFC8287] and this document does not 219 suggest any change to those procedures. When the Echo-reply has to 220 be sent out the Reverse Path label Stack TLV is used to construct the 221 MPLS packet to send out. 223 3.3. Sending an Echo-Reply 225 The Echo-Reply message is sent as MPLS packet with a MPLS label 226 stack. The Echo-Reply message MUST be constructed as described in 227 the [RFC8029]. An MPLS packet is constructed with Echo-reply in the 228 payload. The top label MUST be the first label from the Reverse Path 229 Label Stack TLV. The remaining labels MUST follow the order from the 230 Reverse Path Label Stack. The responder MAY check the reachability 231 of the top label in its own LFIB before sending the Echo-Reply. 233 4. Detailed Example 235 An example topology is given in Figure 1 . This will be used in below 236 sections to explain LSP Ping and Traceroute procedures. The PMS/ 237 Head-end has complete view of topology. PE1, P1, P2, ASBR1 and ASBR2 238 are in AS1. Similarly ASBR3, ASBR4, P3, P4 and PE4 are in AS2. 240 AS1 and AS2 have Segment Routing enabled. IGPs like OSPF/ISIS are 241 used to flood SIDs in each Autonomous System. The ASBR1, ASBR2, 242 ASBR3, ASBR4 advertise BGP EPE SIDs for the inter-AS links. Topology 243 of AS1 and AS2 are advertised via BGP-LS to the controller/PMS or 244 Head-end node. The EPE-SIDs are also advertised via BGP-LS as 245 described in [I-D.ietf-idr-bgpls-segment-routing-epe] 247 The description in the document uses below notations for Segment 248 Identifiers(SIDs). 250 Node SIDs : N-PE1, N-P1, N-ASBR1 etc. 252 Adjacency SIDs : Adj-PE1-P1, Adj-P1-P2 etc. 254 EPE SIDS : EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 etc. 256 Let us consider a traffic engineered path built from PE1 to PE4 with 257 label stack as below. N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4 for 258 following procedures. This stack may be programmed by controller/PMS 259 or Head-end router PE1 may have imported the whole topology 260 information from BGP-LS and computed the inter-AS path. 262 4.1. Procedures for Segment Routing LSP ping 264 To perform LSP ping procedure on an SR-Path from PE1 to PE4 265 consisting of label stack [N-P1,N-ASBR1,EPE-ASBR1-ASBR4, N-PE4], The 266 remote end(PE4) needs IP connectivity to head end(PE1) for the 267 Segment Routing ping to succeed, because Echo-reply needs to travel 268 back to PE1 from PE4. But in typical deployment scenario there will 269 be no ip route from PE4 to PE1 as they belong to different ASes. 271 PE1 adds Reverse Path from PE4 to PE1 in the MPLS Echo-request using 272 multiple labels in "Reverse Path Label Stack TLV" as defined above. 273 An example return path label stack for PE1 to PE4 for LSP ping i 274 [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. An implementation may also build 275 a Reverse Path Label stack consisting of labels to reach its own AS. 276 Once the label stack is popped-off the Echo-reply message will be 277 exposed.The further packet forwarding will be based on ip lookup. An 278 example Reverse Path Label Stack for this case could be [N-ASBR4, 279 EPE-ASBR4-ASBR1]. 281 On receiving MPLS Echo-request PE4 first validates FEC in the Echo- 282 request. PE4 then builds label stack to send the response from PE4 283 to PE1 by copying the labels from "Return Path Label Stack TLV". PE4 284 builds the Echo-reply packet with the MPLS label stack constructed 285 and imposes MPLS headers on top of Echo-reply packet and sends out 286 the packet towards PE1. This label stack can successfully steer 287 reply back to Head-end node(PE1). 289 4.2. Procedures for Segment Routing LSP Traceroute 291 As described in the procedures for LSP ping, the return label stack 292 may be sent from head-end in which case the LSP Traceroute procedures 293 are similar to LSP ping. The head-end constructs the Reverse Path 294 Label Stack TLV and the egress node uses the Reverse Path Label Stack 295 to construct the Echo-reply packet header. Head-end/PMS is aware of 296 the return path from every node visited in the network and builds the 297 Reverse Path Label Stack for every visited node accordingly. 299 For Example: 301 For the same traffic engineered path PE1 to PE4 mentioned in above 302 sections, let us assume there is no return path available from the 303 nodes ASBR2 to PE1. During the Traceroute procedure, when PE1 has to 304 visit ASBR2, it builds Return Path Label Stack TLV and includes label 305 to the border-node which has the route to, PE1. In this example the 306 Return Path Label Stack TLV will contain [EPE-ASBR2-ASBR1]. Further 307 down the traceroute procedure when P3 or P4 node is being visited, 308 PE1 build the Return Path Label Stack TLV containing [N-ASBR2, EPE- 309 ASBR2-ASBR1]. The Echo-reply will be an MPLS packet with this label 310 stack and will be forwarded to PE1. 312 5. Security Considerations 314 TBD 316 6. IANA Considerations 318 Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 319 Parameters TLVs Registry 321 Reverse Path label stack TLV : TBD 323 7. Acknowledgments 325 8. References 327 8.1. Normative References 329 [I-D.ietf-spring-segment-routing-central-epe] 330 Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. 331 Afanasiev, "Segment Routing Centralized BGP Egress Peer 332 Engineering", draft-ietf-spring-segment-routing-central- 333 epe-10 (work in progress), December 2017. 335 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 336 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 337 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 338 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 339 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 340 . 342 8.2. Informative References 344 [I-D.ietf-idr-bgpls-segment-routing-epe] 345 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 346 S., and J. Dong, "BGP-LS extensions for Segment Routing 347 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 348 segment-routing-epe-19 (work in progress), May 2019. 350 [I-D.ietf-mpls-interas-lspping] 351 Nadeau, T. and G. Swallow, "Detecting MPLS Data Plane 352 Failures in Inter-AS and inter-provider Scenarios", draft- 353 ietf-mpls-interas-lspping-00 (work in progress), March 354 2007. 356 [I-D.ietf-spring-segment-routing-mpls] 357 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 358 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 359 data plane", draft-ietf-spring-segment-routing-mpls-22 360 (work in progress), May 2019. 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, 364 DOI 10.17487/RFC2119, March 1997, 365 . 367 [RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G. 368 Swallow, Ed., "Relayed Echo Reply Mechanism for Label 369 Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743, 370 January 2016, . 372 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 373 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 374 Switched (MPLS) Data-Plane Failures", RFC 8029, 375 DOI 10.17487/RFC8029, March 2017, 376 . 378 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 379 Decraene, B., Litkowski, S., and R. Shakir, "Segment 380 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 381 July 2018, . 383 [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. 384 Kumar, "A Scalable and Topology-Aware MPLS Data-Plane 385 Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 386 2018, . 388 [RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., 389 Henderickx, W., and D. Cooper, "Interconnecting Millions 390 of Endpoints with Segment Routing", RFC 8604, 391 DOI 10.17487/RFC8604, June 2019, 392 . 394 Authors' Addresses 396 Shraddha Hegde 397 Juniper Networks Inc. 398 Exora Business Park 399 Bangalore, KA 560103 400 India 402 Email: shraddha@juniper.net 404 Kapil Arora 405 Juniper Networks Inc. 407 Email: kapilaro@juniper.net 409 Samson Ninan 410 Juniper Networks Inc. 412 Email: samsonn@juniper.net 414 Mukul Srivastava 415 Juniper Networks Inc. 417 Email: msri@juniper.net