idnits 2.17.1 draft-xiong-spring-path-segment-sr-inter-domain-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Q. Xiong 3 Internet-Draft G. Mirsky 4 Intended status: Informational ZTE Corporation 5 Expires: January 14, 2021 W. Cheng 6 China Mobile 7 July 13, 2020 9 The Use of Path Segment in SR Inter-domain Scenarios 10 draft-xiong-spring-path-segment-sr-inter-domain-02 12 Abstract 14 This document illustrates the inter-domain scenarios for SR-MPLS 15 networks to support end-to-end bidirectional tunnel across multiple 16 domains with the use of Path Segments. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 14, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions used in this document . . . . . . . . . . . . . . 3 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3. End-to-end Path Segment . . . . . . . . . . . . . . . . . . . 4 57 3.1. S-PSID . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. N-PSID . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. SR-MPLS Inter-domain Scenarios . . . . . . . . . . . . . . . 4 60 4.1. Stitching of Path Segments . . . . . . . . . . . . . . . 5 61 4.2. Nesting of Path Segments . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Segment Routing (SR) leverages the source routing paradigm. A node 71 steers a packet through an SR Policy instantiated as an ordered list 72 of instructions called "segments". A segment can represent any 73 instruction, topological or service based. A segment can have a 74 semantic local to an SR node or global within an SR domain. SR 75 supports per-flow explicit routing while maintaining per-flow state 76 only at the ingress nodes of the SR domain. Segment Routing can be 77 instantiated on MPLS data plane which is referred to as SR-MPLS 78 [I-D.ietf-spring-segment-routing-mpls]. SR-MPLS leverages the MPLS 79 label stack to construct the SR path. 81 As defined in [RFC8402], the headend of an SR Policy binds a Binding 82 Segment ID (B-SID) to its policy. The B-SID could be bound to a SID 83 List or selected path and used to stitch the SR list and the SR Label 84 Switched Paths (LSP) across multiple domains. In some scenarios, for 85 example, a mobile backhaul transport network, it is required to 86 provide end-to-end bidirectional path across SR networks. 87 [I-D.ietf-spring-mpls-path-segment] defines a path segment identifier 88 to support bidirectional path correlation for transport network. In 89 the multi-domain scenarios, the SR bidirectional end-to-end path MAY 90 be established with the use of path segments. Path segment MAY be 91 used to indicate the end-to-end bidirectional path to achieve the 92 path monitoring including nesting of Path Segments or Path SID 93 (N-PSID) and stitching of Path Segments or Path SID (S-PSID). 95 This document illustrates the inter-domain scenarios for SR-MPLS 96 networks to support end-to-end bidirectional tunnel across multiple 97 domains with the use of Path Segments. 99 2. Conventions used in this document 101 2.1. Terminology 103 ABR: Area Border Routers. Routers used to connect two IGP areas 104 (areas in OSPF or levels in IS-IS). 106 A->B SID list: The SID List from SR node A to SR node B. 108 AS: Autonomous System. An Autonomous System is composed by one or 109 more IGP areas. 111 ASBR: Autonomous System Border Router. A router used to connect 112 together ASes of the same or different service providers via one or 113 more inter-AS links. 115 B-SID: Binding Segment ID. 117 Domains:Autonomous System (AS) or IGP Area. An Autonomous System is 118 composed by one or more IGP areas. 120 e-Path: End-to-end Path Segment. 122 Inter-Area: Two IGP areas interconnects with an ABR in an AS. 124 Inter-AS: Two ASes interconnects with an ASBR. 126 IGP: Interior Gateway Protocol. 128 N-PSID: Nesting of Path Segments. 130 S-PSID: Stitching of Path Segments. 132 SR: Segment Routing. 134 SR-MPLS: Segment Routing with MPLS data plane. 136 2.2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 3. End-to-end Path Segment 146 3.1. S-PSID 148 As described in [I-D.ietf-spring-mpls-path-segment], an end-to-end 149 Path Segment, also referred to as e-Path. In the inter-domain 150 scenario, the end-to-end SR path is split into multiple segments. 151 And each segment can be identified by S-PSIDs in stitching model. 152 The correlation of path segments can stitch the inter-domain paths 153 and bind unidirectional paths. The S-PSIDs are valid in the 154 corresponding domain and the border nodes maintain the forwarding 155 entries of that S-PSID. At the headend node, the S-PSID can 156 correlate the inter-domain path of reverse direction and bind the two 157 unidirectional paths. 159 The S-PSID can be a locally unique label and assigned from the 160 Segment Routing Local Block (SRLB). It is required that the 161 controller(e.g., PCE) assigns the label to ensure the ingress and the 162 egress node can recognize it and it also can be assigned from egress 163 node of each domain. PCEP based S-PSID allocation and procedure is 164 defined in [I-D.xiong-pce-stateful-pce-sr-inter-domain]. 166 3.2. N-PSID 168 As described in [I-D.ietf-spring-mpls-path-segment], an end-to-end 169 Path Segment, also referred to as e-Path. In nesting model, the 170 e-Path is also referred to as N-PSID which is encapsulated at the 171 ingress nodes and decapsulated at the egress nodes. The transit 172 nodes, even the border nodes of domains, are not aware of the N-PSID. 173 The use of the B-SID is also recommended to reduce t he size of label 174 stack section 4.2 and stitch the SR list and the SR LSP. The N-PSID 175 can be used to indicate the end-to-end path and achieve the 176 bidirectional path monitoring. 178 The N-PSID can be a globally unique or local label. If the N-PSID is 179 globally unique, it MUST be assigned from the SRGB block of each 180 domain. If the N-PSID is a local label, it is required that the 181 controller(e.g., PCE) or a super controller (e.g., hierarchical PCE) 182 assigns the label to ensure the ingress(A) and the egress node(Z) can 183 recognize it and there is no SID collision in the ingress and egress 184 domains. 186 4. SR-MPLS Inter-domain Scenarios 188 The domains of the networks may be IGP Areas or ASes and the inter- 189 domain scenario may be inter-Area or inter-AS. The multiple SR-MPLS 190 domains may be interconnected with a ABR within areas or inter-link 191 between ASes. This document takes IGP Areas domains for example. 193 The border link scenarios are in future discussion. SR-MPLS domains 194 can be deployed as Figure 1 shown. 196 + + + 197 + + + + + + 198 + + + + + + 199 + + + + + + 200 A SR-MPLS X SR-MPLS Y SR-MPLS Z 201 + IGP 1 + + IGP 2 + + IGP 3 + 202 + + + + + + 203 + + + + + + 204 + + + 206 Figure 1: SR-MPLS inter-domain Scenario 208 Two SR-MPLS inter-domain models are discussed in this document 209 including using the stitching and nesting of Path Segments which are 210 described in Section 4.1 and Section 4.2 respectively. 212 4.1. Stitching of Path Segments 214 The Figure 1 displays the border node inter-domain scenario. SR node 215 X and SR node Y are the border nodes of two different domains. The 216 S-PSIDs from A->X, X->Y, and Y->Z are used for the inter-domain path 217 segment. The ingress SR node A encapsulates the data packet with 218 S-PSID (A->X), B-SID(Y->Z), B-SID(X->Y) and A->X SID list. The data 219 packet is forwarded to SR node X according to the A->X SID list. 220 Node X pushes the S-PSID (X->Y), B-SID(Y->Z) and X->Y SID list based 221 on the above mentioned forwarding entry. The data packet is 222 forwarded to node Y and then to the SR node Z b ased on the same 223 forwarding procedure. In node Z, the S-PSID (Y->Z) can be mapped to 224 the path from Z to Y of reverse direction and correlates the two 225 unidirectional paths. The packet transmission of the reverse 226 direction is the same with the forwarding direction with different 227 S-PSID. The stitching of path segments can achieve the inter-domain 228 path monitoring. 230 .................. ................. .................... 231 . . . . . . 232 +-----+ +-----+ +-----+ +-----+ 233 | A | | X | | Y | | Z | 234 +-----+ +-----+ +-----+ +-----+ 235 . SR Domain 1 . . SR Domain 2 . . SR Domain 3 . 236 .................. ................. .................... 238 Service Layer: 239 |<----------------------End-to-end Service--------------->| 240 Path Segment: 241 |<-----S-PSID----->o<------S-PSID----->o<-----S-PSID----->| 242 LSP/Tunnel: 243 |<------SR-LSP---->|<-----SR-LSP------>|<-----SR-LSP----->| 244 Node: 245 |<----SID List---->|<-----SID List---->|<----SID List---->| 247 Node A Node X Node Y Node Z 248 +-------------+ 249 |A->X SID list| 250 +-------------+ +-------------+ 251 | B-SID(X->Y) | --->|X->Y SID list| 252 +-------------+ +-------------+ +-------------+ 253 | B-SID(Y->Z) | | B-SID(Y->Z) | --->|Y->Z SID list| 254 +-------------+ +-------------+ +-------------+ +--------------+ 255 |S-PSID(A->X) | |S-PSID(X->Y) | |S-PSID(Y->Z) | -->| Payload | 256 +-------------+ +-------------+ +-------------+ +--------------+ 257 | Payload | | Payload | | Payload | 258 +-------------+ +-------------+ +-------------+ 260 Figure 2: Stitching of Path Segments in Inter-Domain Scenario 262 4.2. Nesting of Path Segments 264 Figure 3 shows the SR-MPLS nesting inter-domain scenario. The 265 e-Path(A->Z) is used to indicate the end-to-end path. The N-PSID, 266 B-SID and SR list are pushed by the ingress node. The N-PSID is used 267 to correlate the two unidirectional SR paths to an SR bidirectional 268 path. 270 The use of the B-SID is also recommended to replace the SR list of 271 each domain. As shown in Figure 3, the B-SID(X->Y) is used to 272 replace the X->Y SID list. Ingress node A pushes N-PSID(A->Z), 273 B-SID(Y->Z), B-SID(X->Y), and A->X SID list in turn. When the packet 274 is received at node X, the X->Y SID list are popped. Also, X->Y SID 275 list replaces B-SID(X->Y) to indicate that packet to be forwarded 276 from node X to node Y. The data packet reaches the SR node Z 277 according to the same forwarding procedure. In SR node Z, the N-PSID 278 (A->Z) is used to correlate the two unidirectional end-to-end paths. 280 .................. ................. .................... 281 . . . . . . 282 +-----+ +-----+ +-----+ +-----+ 283 | A | | X | | Y | | Z | 284 +-----+ +-----+ +-----+ +-----+ 285 . SR Domain 1 . . SR Domain 2 . . SR Domain 3 . 286 .................. ................. .................... 288 Service Layer: 289 |<----------------------End-to-end Service--------------->| 290 Path Segment: 291 |<------------------------N-PSID------------------------->| 292 LSP/Tunnel: 293 |<------SR-LSP---->o<-------SR-LSP----->o<-----SR-LSP---->| 294 Node: 295 |<----SID List---->|<-----SID List----->|<----SID List--->| 297 Node A Node X Node Y Node Z 298 +-------------+ 299 |A->X SID list| 300 +-------------+ +-------------+ 301 |B-SID(X->Y) | --> |X->Y SID list| 302 +-------------+ +-------------+ +-------------+ 303 |B-SID(Y->Z) | |B-SID(Y->Z) | --> |Y->Z SID list| 304 +-------------+ +-------------+ +-------------+ +-------------+ 305 |N-PSID(A->Z) | |N-PSID(A->Z) | |N-PSID(A->Z) | --> | Payload | 306 +-------------+ +-------------+ +-------------+ +-------------+ 307 | Payload | | Payload | | Payload | 308 +-------------+ +-------------+ +-------------+ 310 Figure 3: Nesting of Path Segments in Inter-Domain Scenario 312 5. Security Considerations 314 TBA 316 6. Acknowledgements 318 TBA 320 7. IANA Considerations 322 TBA 324 8. Normative References 326 [I-D.ietf-spring-mpls-path-segment] 327 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 328 "Path Segment in MPLS Based Segment Routing Network", 329 draft-ietf-spring-mpls-path-segment-02 (work in progress), 330 February 2020. 332 [I-D.ietf-spring-segment-routing-mpls] 333 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 334 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 335 data plane", draft-ietf-spring-segment-routing-mpls-22 336 (work in progress), May 2019. 338 [I-D.xiong-pce-stateful-pce-sr-inter-domain] 339 Xiong, Q., Mirsky, G., hu, f., and W. Cheng, "Stateful PCE 340 for SR-MPLS Inter-domain", draft-xiong-pce-stateful-pce- 341 sr-inter-domain-02 (work in progress), October 2019. 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 349 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 350 May 2017, . 352 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 353 Decraene, B., Litkowski, S., and R. Shakir, "Segment 354 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 355 July 2018, . 357 Authors' Addresses 359 Quan Xiong 360 ZTE Corporation 361 No.6 Huashi Park Rd 362 Wuhan, Hubei 430223 363 China 365 Phone: +86 27 83531060 366 Email: xiong.quan@zte.com.cn 367 Greg Mirsky 368 ZTE Corporation 369 USA 371 Email: gregimirsky@gmail.com 373 Weiqiang Cheng 374 China Mobile 375 Beijing 376 China 378 Email: chengweiqiang@chinamobile.com