idnits 2.17.1 draft-hu-mpls-sr-inter-domain-use-cases-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 11 instances of too long lines in the document, the longest one being 4 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (Dec 9, 2018) is 1958 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) == Unused Reference: 'I-D.ietf-pce-association-group' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC7551' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC8231' is defined on line 426, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-15 == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-06 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-17 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Workgroup Fangwei Hu 3 Internet-Draft Quan Xiong 4 Intended status: Standards Track Greg Mirsky 5 Expires: June 12, 2019 ZTE Corporation 6 Weiqiang Cheng 7 China Mobile 8 Dec 9, 2018 10 Segment Routing in MPLS-TP Inter-domain Use Cases 11 draft-hu-mpls-sr-inter-domain-use-cases-00 13 Abstract 15 This document discusses SR-MPLS-TP inter-domain scenarios and use 16 cases, and also SR-MPLS-TP inter-working with MPLS-TP network 17 requirement and use cases. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 12, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 2 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. SR-MPLS-TP Inter-domain . . . . . . . . . . . . . . . . . . . 3 58 3.1. SR-MPLS-TP Stitching Inter-domain . . . . . . . . . . . . 4 59 3.1.1. Border Node Inter-domain Scenario . . . . . . . . . . 4 60 3.1.2. Border Link Inter-domain Scenario . . . . . . . . . . 5 61 3.2. SR-MPLS-TP Nesting Inter-domain . . . . . . . . . . . . . 6 62 4. SR-MPLS-TP Inter-working with MPLS-TP . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 Segment Routing (SR) leverages the source routing paradigm. A node 72 steers a packet through an SR Policy instantiated as an ordered list 73 of instructions called "segments". A segment can represent any 74 instruction, topological or service based. A segment can have a 75 semantic local to an SR node or global within an SR domain. SR 76 supports per-flow explicit routing while maintaining per-flow state 77 only at the ingress nodes to the SR domain. Segment Routing can be 78 instantiated on MPLS data plane or IPv6 data plane. The former is 79 called SR-MPLS [I-D.ietf-spring-segment-routing-mpls] , the latter is 80 called SRv6 [I-D.ietf-6man-segment-routing-header]. SR-MPLS 81 leverages the MPLS label stack to construct SR path, and SRv6 uses 82 the Segment Routing Header to construct SR path. 84 [I-D.cheng-spring-mpls-path-segment] provides a path segment to 85 support bidirectional path correlation in an AS domain. A Path 86 Segment is defined to unique identify an SR path in a specific 87 context. This document proposes to discuss SR-MPLS-TP inter-domain 88 scenarios and use cases, and SR-MPLS-TP inter-working with MPLS-TP 89 network requirement and use case. 91 2. Conventions used in this document 92 2.1. Terminology 94 A->B SID list: The SID List from SR node A to SR node B. 96 AS: Autonomous Systems. 98 BSID: Binding SID. 100 e-Path: End-to-End path segment. 102 MPLS-TP: MPLS transport profile. 104 s-Path: Sub-path path segment. 106 SR: Segment routing. 108 SR-MPLS: Segment routing with MPLS data plane. 110 SR-MPLS-TP: Segment routing transport Profile with MPLS data plane. 112 2.2. Requirements Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 3. SR-MPLS-TP Inter-domain 122 There are two SR-MPLS-TP inter-domain models defined in this 123 document: stitching inter-domain model and nesting inter-domain 124 model. The stitching inter-domain model is that the end-to-end SR 125 path segment are split into multiple domain path segments. Each SR- 126 MPLS-TP domain has its domain path segment. The domain path segment 127 is valid in its own domain, and the border nodes maintain the 128 forwarding entries of its domain path segment mapping to other domain 129 path segment. There are two scenarios for stitching SR-MPLS-TP 130 inter-domain: border node inter-domain(section 3.1.1) and border link 131 inter-domain scenarios(section 3.1.2). 133 The nesting inter-domain model is that an e-Path segment is used to 134 indicate the end-to-end bidirectional path tunnel, and a s-Path is 135 used to indicate the domain bidirectional path tunnel. The e-path 136 segment is encapsulated in the ingress nodes, and decapsulated in the 137 egress nodes. The transmit nodes, even the border nodes of domains, 138 do not aware of the e-path segment(section 3.2 for details). The 139 s-Path are encapsulated and decapsualted in the border nodes of its 140 domain. 142 3.1. SR-MPLS-TP Stitching Inter-domain 144 3.1.1. Border Node Inter-domain Scenario 146 The following figure shows the border node inter-domain scenario. SR 147 node X and SR node Y are the border nodes of two different Autonomous 148 Systems. The Path labels (Path1, Path2, Path3, Path1',Path2' and 149 Path3') [I-D.cheng-spring-mpls-path-segment] are used for inter- 150 domain bidirectional tunnel indication. Path 1, Path 2 and Path3 are 151 used for the forwarding path from A to Z, and Path1', Path2' and 152 Path3' are used for the reverse path (from Z to A). The border nodes 153 should install the following MPLS data entries for Path labels: 155 incoming label: Path Label 156 outgoing label: the SID list of the next AS domain + next Path label 158 Taking figure 1 as the example, the border node X installs the MPLS 159 data entries: 161 incoming label: Path1 162 outgoing label: X-Y SID list + Path 2 164 The ingress SR node A encapsulates the data packet with Path1 label 165 and A-X SID list. The data packet forwards to SR node X according to 166 the A-X SID list. Node X encapsulates the Path2 label and X-Y SID 167 list based on the above forwarding entry. The data packet forwards 168 to node Y and even to destination SR node Z based on the same 169 forwarding procedure. The egress node Z pops the path label and 170 reverses back the data packet to the node Y. Node Y encapsulates the 171 Path3' label and Y-X SID list and forwards the packet to node X, and 172 X sends back to the ingress node based on the same forwarding 173 procedure. 175 .................. ................. .................... 176 . . . . . . 177 . . . . . . 178 +-----+ +-----+ +-----+ +-----+ 179 | A | | X | | Y | | Z | 180 +-----+ +-----+ +-----+ +-----+ 181 . . . . . . 182 . AS 1 . . AS2 . . AS3 . 183 .................. ................. ................... 185 Node A Node X Node Y 186 +-------------+ +-------------+ +-------------+ 187 |A-X SID list | |X-Y SID list | |Y-Z SID list | Node Z 188 +-------------+ +-------------+ +-------------+ +--------------+ 189 | Path1 |----\| Path2 |----\| Path3 |---\| Payload | 190 +-------------+----/+-------------+----/+-------------+---/+--------------+ 191 | Payload | | Payload | | Payload | 192 +-------------+ +-------------+ +-------------+ 194 Figure 1: Stitching Border Node Inter-Domain Scenario 196 3.1.2. Border Link Inter-domain Scenario 198 Figure 2 is the border link inter-domain scenario. All the SR nodes 199 belong to one AS in this scenario. The border nodes of different 200 Autonomous Systems are connected with direct physical or logical 201 links. The Path labels are not only assigned to the Autonomous 202 System, they are assigned to the links of the two ASes, for example, 203 the Path 2 (Path 2') and Path 4(Path 4') are assigned to the links 204 between AS1 and AS2, and between AS2 and AS3 respectively. 206 Ingress SR node A encapsulates the data packet with Path1 and A-B SID 207 list. The data packet forwards to SR node B according to the A-B SID 208 list. Node B encapsulates Path2 and the inter-domain link 209 label(label B-C) according to the forwarding entry, and forwards the 210 packet to Node C. SR node C forwards the packet to node X, then to 211 Y. The data packet forwards the destination SR node Z according to 212 the same forwarding procedure. 214 The border nodes should install the following MPLS data entries for 215 Path labels: 217 incoming label: Path Label 218 outgoing label: the SID list of the next AS domain + next Path label 220 If the border node belongs to the outgoing AS domain for the data 221 packet, the SID-List is the label assigned to the link between two 222 border nodes of different AS domains for the border link inter-domain 223 scenario. The procedure of assigning and processing that link label 224 is out of scope. 226 .................... .................... ..................... 227 . . . . . . 228 . . . . . . 229 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 230 .| A |-------| B |------ | C |------| X |-------| Y |------| Z | . 231 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 232 . . . . . . 233 . AS 1 . . AS2 . . AS3 . 234 .................... .................... ..................... 236 Node A Node B Node C 237 +-------------+ +-------------+ +-------------+ 238 |A-B SID list | | Label B->C | |C->X SID list| 239 +-------------+ +-------------+ +-------------+ 240 | Path1 |----\| Path2 |----\| Path3 |----\ 241 +-------------+----/+-------------+----/+-------------+----/ 242 | Payload | | Payload | | Payload | 243 +-------------+ +-------------+ +-------------+ 245 Node X Node Y 246 +-------------+ +-------------+ 247 | Label X->Y | |Y->Z SID list| Node Z 248 +-------------+ +-------------+ +--------------+ 249 | Path4 |----\| Path5 |----\| Payload | 250 +-------------+----/+-------------+----/+--------------+ 251 | Payload | | Payload | 252 +-------------+ +-------------+ 254 Figure 2: Stitching Border Link Inter-Domain Scenario 256 3.2. SR-MPLS-TP Nesting Inter-domain 258 Figure 3 shows the SR-MPLS-TP nesting inter-domain scenario. The 259 e-Path(A->Z) is used to indicate the end-to-end bidirectional tunnel. 260 The s-Path is used to indicate its domain sub-path bidirectional 261 tunnel. The e-Path, s-Path and SR list are encapsulated in the 262 ingress node. In order to reduce the label stacks, the binding 263 SID([RFC8402]) is recommended to be used to replace the SR list of 264 each domain. As the figure 3 shows, B-SID(X,Y) is used to replace 265 the X-Y SID list. Ingress node A pushes e-Path(A->Z), B-SID(Y->Z), 266 B-SID(X-Y), s-Path(A->X) and A-X SID list in turn. When the packet 267 is received in node X, the s-Path(A-X) and X-Y SID list are popped, a 268 new s-Path(X->Y) is pushed, and BSID(X->Y) is replaced by X-Y SID 269 list to indicate the packet being forwarded from node X to node Y. 271 The e-Path can be global unique or local label. If the e-Path is 272 global unique, it occupies the SRGB block of each domain. While if 273 the e-Path is a local label, it is required the controller(PCE) or 274 super controller( or hierarchical PCE) to assign the label to ensure 275 that ingress(A) and egress node(Z) can recognize it and there is no 276 SID confliction in the ingress and egress domains. 278 .................. ................. .................... 279 . . . . . . 280 . . . . . . 281 +-----+ +-----+ +-----+ +-----+ 282 | A | | X | | Y | | Z | 283 +-----+ +-----+ +-----+ +-----+ 284 . . . . . . 285 . AS 1 . . AS2 . . AS3 . 286 .................. ................. ................... 288 Node A 289 +-------------+ 290 |A-X SID list | Node X 291 +-------------+ +-------------+ 292 |s-Path(A->X) | |X-Y SID list | Node Y 293 +-------------+ +-------------+ +-------------+ 294 |B-SID (X->Y) | |s-Path(X->Y) | |X-Y SID list | 295 +-------------+ +-------------+ +-------------+ 296 |B-SID( Y->Z) | |B-SID( Y->Z) | |s-Path(Y->Z) | Node Z 297 +-------------+ +-------------+ +-------------+ +-------------+ 298 |e-Path(A->Z) | |e-Path(A->Z) | |e-Path(A->Z) | |e-Path(A->Z) | 299 +-------------+ +-------------+ +-------------+ +-------------+ 300 | Payload | | Payload | | Payload | | Payload | 301 +-------------+ +-------------+ +-------------+ +-------------+ 303 Figure 3: Nesting Inter-Domain Scenario 305 4. SR-MPLS-TP Inter-working with MPLS-TP 307 It is a common requirement that SR-MPLS-TP needs to inter-work with 308 MPLS-TP when SR is incrementally deployed in the MPLS-TP domain. 310 Figure 4 shows the stitching SR-MPLS-TP inter-working with MPLS-TP, 311 the left part is SR-MPLS-TP network, and the right part is MPLS-TP 312 network. The Path label is used for the bidirectional tunnel 313 indication in SR-MPLS-TP network. The Border nodes of SR-MPLS-TP 314 network should map the Path label to the corresponding MPLS-TP label 315 for bidirectional tunnel indication in MPLS-TP network. 317 ................................ .................................. 318 . . . . 319 .+---+ +---+ +---+ . . +---+ +---+ +----+ . 320 .| A |-------| B |------ | C |-.----.-| U |-------| V |------| W | . 321 .+-+-+ +-+-+ +---+ . . +---+ +-+-+ +-+--+ . 322 . | | . . | | . 323 . | | . . | | 324 .+-+-+ +-+-+ +---+ . . +---+ +-+-+ +-+--+ . 325 .| D |-------| E |------ | F |-.----.-| X |-------| Y |------| Z | . 326 .+---+ +---+ +---+ . . +---+ +---+ +----+ . 327 . . . . 328 . SR-MPLS-TP domain . . MPLS-TP domain . 329 ................................ .................................. 331 |<----------SID List----------->|<--------------MPLS-TP label------->| 332 |<--------Path label----------->| 333 |<---------------------------VPN Service---------------------------->| 335 Figure 4: Stitching SR-MPLS-TP inter-working with MPLS-TP 337 Figure 5 is the nesting SR-MPLS-TP inter-working with MPLS-TP 338 scenario. The difference with stitching SR-MPLS-TP inter-working 339 with MPLS-TP is that the Path label is end-to-end encapsulation in 340 the packet from SR-MPLS-TP domain to MPLS-TP domain. 342 ................................ .................................. 343 . . . . 344 .+---+ +---+ +---+ . . +---+ +---+ +----+ . 345 .| A |-------| B |------ | C |-.----.-| U |-------| V |------| W | . 346 .+-+-+ +-+-+ +---+ . . +---+ +-+-+ +-+--+ . 347 . | | . . | | . 348 . | | . . | | 349 .+-+-+ +-+-+ +---+ . . +---+ +-+-+ +-+--+ . 350 .| D |-------| E |------ | F |-.----.-| X |-------| Y |------| Z | . 351 .+---+ +---+ +---+ . . +---+ +---+ +----+ . 352 . . . . 353 . SR-MPLS-TP domain . . MPLS-TP domain . 354 ................................ .................................. 356 |<----------SID List----------->|<--------------MPLS-TP label------->| 357 |<---------------------------Path label----------------------------->| 358 |<---------------------------VPN Service---------------------------->| 360 Figure 5: nesting SR-MPLS-TP inter-working with MPLS-TP 362 The requirement of the SR-MPLS-TP inter-working with MPLS-TP is as 363 following: 365 o It is required to establish the end-to-end VPN service through SR- 366 MPLS-TP domain and MPLS-TP domain; 368 o The Path Label is required to carried through SR-MPLS-TP and MPLS- 369 TP domain in nesting SR-MPLS-TP inter-working with MPLS-TP model. 371 o The border nodes of MPLS-TP network could understand and process 372 the path segment from SR-MPLS-TP network. 374 o The border nodes in MPLS-TP could understand and process MPLS SID 375 sent from MPLS-SR-TP domain 377 o The border nodes in SR-MPLS-TP network could understand and 378 process the MPLS-TP labels sent from MPLS-TP domain; 380 5. Security Considerations 382 6. Acknowledgements 384 7. IANA Considerations 385 8. Normative References 387 [I-D.cheng-spring-mpls-path-segment] 388 Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler, 389 R., and S. Zhan, "Path Segment in MPLS Based Segment 390 Routing Network", draft-cheng-spring-mpls-path-segment-03 391 (work in progress), October 2018. 393 [I-D.ietf-6man-segment-routing-header] 394 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 395 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 396 (SRH)", draft-ietf-6man-segment-routing-header-15 (work in 397 progress), October 2018. 399 [I-D.ietf-pce-association-group] 400 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 401 Dhody, D., and Y. Tanaka, "PCEP Extensions for 402 Establishing Relationships Between Sets of LSPs", draft- 403 ietf-pce-association-group-06 (work in progress), June 404 2018. 406 [I-D.ietf-spring-segment-routing-mpls] 407 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 408 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 409 data plane", draft-ietf-spring-segment-routing-mpls-17 410 (work in progress), December 2018. 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE 418 Extensions for Associated Bidirectional Label Switched 419 Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, 420 . 422 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 423 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 424 May 2017, . 426 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 427 Computation Element Communication Protocol (PCEP) 428 Extensions for Stateful PCE", RFC 8231, 429 DOI 10.17487/RFC8231, September 2017, 430 . 432 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 433 Decraene, B., Litkowski, S., and R. Shakir, "Segment 434 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 435 July 2018, . 437 Authors' Addresses 439 Fangwei Hu 440 ZTE Corporation 441 No.889 Bibo Rd 442 Shanghai 201203 443 China 445 Phone: +86 21 68896273 446 Email: hu.fangwei@zte.com.cn 448 Quan Xiong 449 ZTE Corporation 450 No.6 Huashi Park Rd 451 Wuhan, Hubei 430223 452 China 454 Phone: +86 27 83531060 455 Email: xiong.quan@zte.com.cn 457 Greg Mirsky 458 ZTE Corporation 459 USA 461 Email: gregimirsky@gmail.com 463 Weiqiang Cheng 464 China Mobile 465 Beijing 466 China 468 Email: chengweiqiang@chinamobile.com