idnits 2.17.1 draft-xiong-spring-path-segment-sr-inter-domain-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 5 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 3, 2019) is 1730 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) == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-00 == Outdated reference: A later version (-02) exists of draft-xiong-pce-stateful-pce-sr-inter-domain-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Quan Xiong 3 Internet-Draft Greg Mirsky 4 Intended status: Standards Track ZTE Corporation 5 Expires: January 4, 2020 Weiqiang Cheng 6 China Mobile 7 July 3, 2019 9 The Use of Path Segment in SR Inter-domain Scenarios 10 draft-xiong-spring-path-segment-sr-inter-domain-00 12 Abstract 14 This document discusses the inter-domain scenarios for SR-MPLS 15 network and proposes the solution with the use of Path Segment. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 4, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions used in this document . . . . . . . . . . . . . . 3 53 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 3. Path Segment for SR-MPLS Inter-domain . . . . . . . . . . . . 3 56 3.1. Inter-domain Path Segment . . . . . . . . . . . . . . . . 4 57 3.2. End-to-end Path Segment . . . . . . . . . . . . . . . . . 4 58 4. SR-MPLS Inter-domain Scenarios . . . . . . . . . . . . . . . 5 59 4.1. Stitching Inter-domain with i-Path . . . . . . . . . . . 5 60 4.2. Nesting Inter-domain with e-Path . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 Segment Routing (SR) leverages the source routing paradigm. A node 70 steers a packet through an SR Policy instantiated as an ordered list 71 of instructions called "segments". A segment can represent any 72 instruction, topological or service based. A segment can have a 73 semantic local to an SR node or global within an SR domain. SR 74 supports per-flow explicit routing while maintaining per-flow state 75 only at the ingress nodes of the SR domain. Segment Routing can be 76 instantiated on MPLS data plane which is referred to as SR-MPLS 77 [I-D.ietf-spring-segment-routing-mpls]. SR-MPLS leverages the MPLS 78 label stack to construct the SR path. 80 [I-D.ietf-spring-mpls-path-segment] defines a Path Segment identifier 81 to support bidirectional path correlation for transport network. In 82 multi-domain scenarios, the SR bidirectional end-to-end tunnel MAY be 83 established with the use of Path Segments. The SR-MPLS inter-domain 84 models include the stitching and nesting inter-domain models. Path 85 Segment MAY be used to indicate the inter-domain path or the end-to- 86 end path and correlate the inter-domain paths or end-to-end 87 unidirectional paths. 89 This document discusses the inter-domain scenarios for SR-MPLS 90 networks and proposes the solution with the use of Path Segment for 91 end-to-end bidirectional SR path. 93 2. Conventions used in this document 95 2.1. Terminology 97 ABR: Area Border Routers. Routers used to connect two IGP areas 98 (areas in OSPF or levels in IS-IS). 100 A->B SID list: The SID List from SR node A to SR node B. 102 AS: Autonomous System. 104 ASBR: Autonomous System Border Router. Router used to connect 105 together ASes of the same or different service providers via one or 106 more inter-AS links. 108 Domains:Autonomous System (AS) or IGP Area. An Autonomous System is 109 composed by one or more IGP area. 111 e-Path: End-to-end Path segment. 113 s-Path: Sub-path Path Segment. 115 Inter-Area: Two IGP areas interconnects with an ABR in a AS. 117 Inter-AS: Two ASes interconnects with an ASBR. 119 IGP: Interior Gateway Protocol. 121 i-Path/i-PSID: Inter-domain Path Segment. 123 SR: Segment Routing. 125 SR-MPLS: Segment Routing with MPLS data plane. 127 2.2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 3. Path Segment for SR-MPLS Inter-domain 136 3.1. Inter-domain Path Segment 138 In the stitching inter-domain model, the end-to-end SR path being 139 split into multiple segments section 4.2. And each segment can be 140 identified by an inter-domain path segment (i-Path or i-PSID). The 141 inter-domain path segment is valid in the corresponding domain and 142 the border nodes maintain the forwarding entries of that i-Path 143 segment mapping to the next i-Path. In the headend node, the i-Path 144 can be mapped to the inter-domain path of reverse direction and 145 correlates the two unidirectional paths. The border nodes should 146 install the following MPLS data entries for Path segments: 148 incoming label: i-Path 149 outgoing label: the SID list of the next domain or link + next i-Path 151 Taking Figure 1 as an example, the border node X installs the MPLS 152 data entries: 154 incoming label: i-Path(A->X) 155 outgoing label: X->Y SID list + i-Path(X->Y) 157 The i-Path can be a locally unique label and assigned from the 158 Segment Routing Local Block (SRLB). It is required that the 159 controller(e.g., PCE) assigns the label to ensure the ingress and the 160 egress node can recognize it and it also can be assigned from egress 161 node of each domain. PCEP based i-Path allocation and procedure is 162 defined in [I-D.xiong-pce-stateful-pce-sr-inter-domain]. 164 3.2. End-to-end Path Segment 166 The nesting inter-domain model is described in 167 [I-D.ietf-spring-mpls-path-segment], an end-to-end path segment, also 168 referred to as e-Path, is used to indicate the end-to-end path, and 169 an s-Path is used to indicate the intra-domain path. The e-Path is 170 encapsulated at the ingress nodes and decapsulated at the egress 171 nodes. The transit nodes, even the border nodes of domains, are not 172 aware of the e-Path segment. The s-Path can be used as stitching 173 label to correlate the two domains. The use of the binding SID 174 [RFC8402] is also recommended to reduce the size of lable stack 175 section 4.2. 177 The e-Path can be a globally unique or local label. If the e-Path is 178 globally unique, it MUST be assigned from the SRGB block of each 179 domain. If the e-Path is a local label, it is required that the 180 controller(e.g., PCE) or a super controller (e.g., hierarchical PCE) 181 assigns the label to ensure the ingress(A) and the egress node(Z) can 182 recognize it and there is no SID collision in the ingress and egress 183 domains. 185 4. SR-MPLS Inter-domain Scenarios 187 The domains of the networks may be IGP Areas or ASes and the inter- 188 domain scenario may be inter-Area or inter-AS. The multiple SR-MPLS 189 domains may be interconnect with a ABR within areas or inter-link 190 between ASes. This document takes IGP Areas domains for example. 191 SR-MPLS domains can be deployed as Figure 1 shown. 193 + + + 194 + + + + + + 195 + + + + + + 196 + + + + + + 197 A SR-MPLS X SR-MPLS Y SR-MPLS Z 198 + IGP 1 + + IGP 2 + + IGP 3 + 199 + + + + + + 200 + + + + + + 201 + + + 203 Figure 1: SR-MPLS and MPLS-TP interworking Scenario 205 Two SR-MPLS inter-domain models are discussed in this document 206 including the stitching and nesting inter-domain model which are 207 described in Section 4.1 and Section 4.2 respectively. 209 4.1. Stitching Inter-domain with i-Path 211 The Figure 1 displays the border node inter-domain scenario. SR node 212 X and SR node Y are the border nodes of two different domains. The 213 i-Paths from A->X, X->Y, and Y->Z are used for the inter-domain path 214 segment. The ingress SR node A encapsulates the data packet with 215 i-Path (A->X) and A->X SID list. The data packet is forwarded to SR 216 node X according to the A->X SID list. Node X pushes the i-Path 217 (X->Y) and X->Y SID list based on the above mentioned forwarding 218 entry. The data packet is forwarded to node Y and then to the SR 219 node Z based on the same forwarding procedure. In node Z, the i-Path 220 (Y->Z) can be mapped to the path from Z to Y of reverse direction and 221 correlates the two unidirectional paths. The packet transmission of 222 the reverse direction is the same with the forwarding direction with 223 different i-Paths. 225 .................. ................. .................... 226 . . . . . . 227 +-----+ +-----+ +-----+ +-----+ 228 | A | | X | | Y | | Z | 229 +-----+ +-----+ +-----+ +-----+ 230 . SR Domain 1 . . SR Domain 2 . . SR Domain 3 . 231 .................. ................. .................... 233 |<------------------>|<------------------>|<--------------->| 234 i-Path(A->X) i-Path(X->Y) i-Path(Y->Z) 236 Node A Node X Node Y Node Z 237 +-------------+ +-------------+ +-------------+ 238 |A->X SID list| |X->Y SID list| |Y->Z SID list| 239 +-------------+ +-------------+ +-------------+ +--------------+ 240 |i-Path(A->X) |---->|i-Path(X->Y) |---->|i-Path(Y->Z) |--->| Payload | 241 +-------------+ +-------------+ +-------------+ +--------------+ 242 | Payload | | Payload | | Payload | 243 +-------------+ +-------------+ +-------------+ 245 Figure 2: Stitching Border Node Inter-Domain Scenario 247 4.2. Nesting Inter-domain with e-Path 249 Figure 3 shows the SR-MPLS nesting inter-domain scenario. The 250 e-Path(A->Z) is used to indicate the end-to-end path. The s-Path is 251 used to identify the domain's sub-path. The e-Path, s-Path and SR 252 list are pushed by the ingress node. The e-Path is used to correlate 253 the two unidirectional SR paths to an SR bidirectional path. The 254 s-Path can be used as stitching label to correlate the two inter- 255 domain sub-paths. 257 The use of the binding SID [RFC8402] is also recommended to replace 258 the SR list of each domain. As shown in Figure 3, the B-SID(X->Y) is 259 used to replace the X->Y SID list. Ingress node A pushes 260 e-Path(A->Z), B-SID(Y->Z), B-SID(X-Y), s-Path(A->X) and A->X SID list 261 in turn. When the packet is received at node X, the s-Path(A-X) and 262 X->Y SID list are popped, and the new s-Path(X->Y) is pushed. Also, 263 X->Y SID list replaces B-SID(X->Y) to indicate that packet to be 264 forwarded from node X to node Y. The data packet reaches the SR node 265 Z according to the same forwarding procedure. In SR node Z, the 266 e-Path (A->Z) is used to correlate the two unidirectional end-to-end 267 paths. 269 .................. ................. .................... 270 . . . . . . 271 +-----+ +-----+ +-----+ +-----+ 272 | A | | X | | Y | | Z | 273 +-----+ +-----+ +-----+ +-----+ 274 . SR Domain 1 . . SR Domain 2 . . SR Domain 3 . 275 .................. ................. .................... 277 |<------------------>|<------------------>|<--------------->| 278 s-Path(A->X) s-Path(X->Y) s-Path(Y->Z) 279 |<--------------------------------------------------------->| 280 e-Path(A->Z) 281 Node A 282 +-------------+ 283 |A->X SID list| Node X 284 +-------------+ +-------------+ 285 |s-Path(A->X) | |X->Y SID list| Node Y 286 +-------------+ +-------------+ +-------------+ 287 |B-SID(X->Y) | --> |s-Path(X->Y) | |Y->Z SID list| 288 +-------------+ +-------------+ +-------------+ 289 |B-SID(Y->Z) | |B-SID(Y->Z) | --> |s-Path(Y->Z) | Node Z 290 +-------------+ +-------------+ +-------------+ +-------------+ 291 |e-Path(A->Z) | |e-Path(A->Z) | |e-Path(A->Z) | --> |e-Path(A->Z) | 292 +-------------+ +-------------+ +-------------+ +-------------+ 293 | Payload | | Payload | | Payload | | Payload | 294 +-------------+ +-------------+ +-------------+ +-------------+ 296 Figure 3: Nesting Inter-Domain Scenario 298 5. Security Considerations 300 TBA 302 6. Acknowledgements 304 TBA 306 7. IANA Considerations 308 TBA 310 8. Normative References 312 [I-D.ietf-spring-mpls-path-segment] 313 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 314 "Path Segment in MPLS Based Segment Routing Network", 315 draft-ietf-spring-mpls-path-segment-00 (work in progress), 316 March 2019. 318 [I-D.ietf-spring-segment-routing-mpls] 319 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 320 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 321 data plane", draft-ietf-spring-segment-routing-mpls-22 322 (work in progress), May 2019. 324 [I-D.xiong-pce-stateful-pce-sr-inter-domain] 325 Xiong, Q., hu, f., Mirsky, G., and W. Cheng, "Stateful PCE 326 for SR-MPLS-TP Inter-domain", draft-xiong-pce-stateful- 327 pce-sr-inter-domain-00 (work in progress), December 2018. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 335 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 336 May 2017, . 338 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 339 Decraene, B., Litkowski, S., and R. Shakir, "Segment 340 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 341 July 2018, . 343 Authors' Addresses 345 Quan Xiong 346 ZTE Corporation 347 No.6 Huashi Park Rd 348 Wuhan, Hubei 430223 349 China 351 Phone: +86 27 83531060 352 Email: xiong.quan@zte.com.cn 354 Greg Mirsky 355 ZTE Corporation 356 USA 357 Weiqiang Cheng 358 China Mobile 359 Beijing 360 China 362 Email: chengweiqiang@chinamobile.com