idnits 2.17.00 (12 Aug 2021) /tmp/idnits64569/draft-li-spring-sr-e2e-ietf-network-slicing-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (24 March 2022) is 51 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-spring-sr-for-enhanced-vpn' is defined on line 479, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slices-08 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slices (ref. 'I-D.ietf-teas-ietf-network-slices') Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft J. Dong 4 Intended status: Standards Track Huawei Technologies 5 Expires: 25 September 2022 R. Pang 6 China Unicom 7 Y. Zhu 8 China Telecom 9 24 March 2022 11 Segment Routing for End-to-End IETF Network Slicing 12 draft-li-spring-sr-e2e-ietf-network-slicing-03 14 Abstract 16 Network slicing can be used to meet the connectivity and performance 17 requirement of different services or customers in a shared network. 18 An IETF network slice can be realized as enhanced VPNs (VPN+), which 19 is delivered by integrating the overlay VPN service with a Virtual 20 Transport Network (VTN) as the underlay. An end-to-end IETF network 21 slice may span multiple network domains. Within each domain, traffic 22 of the end-to-end network slice service is mapped to a domain VTN. 23 In the context of IETF network slicing, a VTN can be instantiated as 24 a Network Resource Partition (NRP). 26 When segment routing (SR) is used to build a multi-domain IETF 27 network slices, information of the local network slices in each 28 domain can be specified using special SR binding segments called NRP 29 binding segments (NRP BSID). The multi-domain IETF network slice can 30 be specified using a list of NRP BSIDs in the packet, each of which 31 can be used by the corresponding domain edge nodes to steer the 32 traffic of end-to-end IETF network slice into the specific NRP in the 33 local domain. 35 This document describes the functionality of NRP binding segment and 36 its instantiation in SR-MPLS and SRv6. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 25 September 2022. 61 Copyright Notice 63 Copyright (c) 2022 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Revised BSD License text as 72 described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Revised BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Segment Routing for IETF E2E Network Slicing . . . . . . . . 4 79 3. SRv6 NRP Binding Functions . . . . . . . . . . . . . . . . . 5 80 3.1. End.B6NRP.Encaps . . . . . . . . . . . . . . . . . . . . 5 81 3.2. End.NRP.Encaps . . . . . . . . . . . . . . . . . . . . . 6 82 3.3. End.BNRP.Encaps . . . . . . . . . . . . . . . . . . . . . 7 83 4. SR-MPLS NRP BSIDs . . . . . . . . . . . . . . . . . . . . . . 8 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 89 8.2. Informative References . . . . . . . . . . . . . . . . . 10 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 [I-D.ietf-teas-ietf-network-slices] introduces the concept and the 95 characteristics of IETF network slice, and describes a general 96 framework for IETF network slice management and operation.It also 97 introduces the concept Network Resource Partition (NRP), which is a 98 collection of resources identified in the underlay network. 100 [I-D.ietf-teas-enhanced-vpn] describes the framework and the 101 candidate component technologies for providing enhanced VPN (VPN+) 102 services based on existing VPN and Traffic Engineering (TE) 103 technologies with enhanced characteristics that specific services 104 require above traditional VPNs. It also introduces the concept of 105 Virtual Transport Network (VTN). A Virtual Transport Network (VTN) 106 is a virtual underlay network which consists of a set of dedicated or 107 shared network resources allocated from the physical underlay 108 network, and is associated with a customized logical network 109 topology. VPN+ services can be delivered by mapping one or a group 110 of overlay VPNs to the appropriate VTNs as the underlay, so as to 111 provide the network characteristics required by the customers. 112 Enhanced VPN (VPN+) and VTN can be used for the realization of IETF 113 network slices. In the context of IETF network slicing, a VTN can be 114 instantiated as an NRP. VTN and NRP are considered interchangable 115 terms in this document. 117 [I-D.dong-teas-nrp-scalability] describes the scalability 118 considerations in the control plane and data plane to enable NRPs and 119 provide the suggestions to improve the scalability of NRP. In the 120 control plane, It proposes the approach of decoupling the topology 121 and resource attributes of NRP, so that multiple NRPs may share the 122 same topology and the result of topology based path computation. In 123 the data plane, it proposes to carry a dedicated NRP-ID of a network 124 domain in the data packet to determine the set of resources reserved 125 for the corresponding NRP. 127 An IETF network slice may span multiple network domains. Within each 128 domain, traffic of the end-to-end network slice is mapped to a local 129 network slice. The NRP ID which identifies the NRP in the local 130 domain for the end-to-end network slice needs to be determined on the 131 domain edge node. 133 When segment routing (SR) is used to build a multi-domain IETF 134 network slice, information of the local network slices in each domain 135 can be specified using special SR binding segments called NRP binding 136 segments (NRP BSID). The multi-domain IETF network slice can be 137 specified using a list of NRP BSIDs in the packet, each of which can 138 be used by the corresponding domain edge nodes to steer the traffic 139 of end-to-end IETF network slice using the specific resource-aware 140 segments or NRP-ID of the local domain. 142 This document describes the functionality of the network slice 143 binding segment and its instantiation in SR-MPLS and SRv6. 145 2. Segment Routing for IETF E2E Network Slicing 147 [I-D.dong-teas-nrp-scalability] describes the scalability 148 considerations in the control plane and data plane to create NRPs. 149 In data plane, it proposes to carry a dedicated NRP-ID in data packet 150 to determine the set of resources reserved for the corresponding NRP 151 in a network domain. 153 [I-D.li-teas-e2e-ietf-network-slicing] describes the framework of 154 carrying network slice related identifiers in the data plane, each of 155 the network slice IDs may have a different network scope. It 156 provides an approach of mapping the global NRP-ID to domain NRP-IDs 157 at the network domain border nodes. 159 With Segment Routing, there are several optional approaches to 160 realize the mapping between the end-to-end network slice and the 161 network slice constructs in the local domain. 163 The first type of approaches are to use one type of NRP BSID to steer 164 traffic to an SR Policy associated with a local NRP. This is called 165 the NRP-TE BSID. There are some variants in terms of the detailed 166 behavior: 168 * The first variant is to use one type of NRP BSID to specify the 169 mapping of traffic to a SR policy which consists of list of 170 resource-aware segments [I-D.ietf-spring-resource-aware-segments] 171 associated with a local NRP. 173 * The second variant is to use one type of NRP BSID to specify the 174 mapping of traffic to a SR policy which is bound to a local NRP- 175 ID. 177 The second type of approaches is to use one type of NRP BSID to steer 178 traffic to follow the shortest path within a local domain NRP. This 179 is called the NRP-BE BSID. There are some variants in terms of the 180 detailed behavior: 182 * The first variant is to use one type of NRP BSID to determine a 183 local NRP-ID, and instruct the encapsulation of the local NRP-ID 184 into the packet at the domain edge node. 186 * The second variant is to use one type of NRP BSID to specify the 187 mapping of traffic to a local NRP, the local NRP-ID is specified 188 in the associated fields by the ingress node, and is encapsulated 189 into the packet at the domain edge node. 191 The behavior of the first type of NRP BSID is similar to the function 192 of the existing SR BSID, the difference is it is associated with a 193 particular NRP. The second type of the NRP BSID is different from 194 the existing binding segment. The instantiation of the NRP BSIDs in 195 SR-MPLS and SRv6 are described in the following sections. 197 3. SRv6 NRP Binding Functions 199 [RFC8986] defines the SRv6 Network Programming concept and specifies 200 the base set of SRv6 behaviors. The SRv6 End.B6.Encaps function is 201 defined to instantiate the Binding SID in SRv6, which can be reused 202 as one type of NRP-TE BSID to specify the mapping of traffic to a 203 list of resource-aware SRv6 segments of a domain NRP. 205 [I-D.ietf-6man-enhanced-vpn-vtn-id] describes the mechanism of 206 carrying the VTN-ID of a network domain in the IPv6 Hop-by-Hop (HBH) 207 extension header. For the type 2, 3, 4 of NRP binding segments 208 described in section 2, three new SRv6 Binding functions are defined 209 in the following sections. 211 3.1. End.B6NRP.Encaps 213 A new SRv6 function called End.B6NRP.Encaps: Endpoint bound to a SRv6 214 Policy in a NRP with IPv6 encapsulation is defined in this section. 215 This is a variation of the End behavior. It instructs the endpoint 216 node to determine an SRv6 Policy in a specific NRP of the local 217 domain, and encapsulate the SID list of the SR Policy and the NRP-ID 218 in a new IPv6 header. 220 Any SID instance of this behavior is associated with an SR Policy B, 221 a NRP-ID V and a source address A. 223 When node N receives a packet whose IPv6 DA is S, and S is a local 224 End.B6NRP.Encaps SID, N does the following: 226 S01. When an SRH is processed { 227 S02. If (Segments Left == 0) { 228 S03. Stop processing the SRH, and proceed to process the next 229 header in the packet, whose type is identified by 230 the Next Header field in the routing header. 231 S04. } 232 S05. If (IPv6 Hop Limit <= 1) { 233 S06. Send an ICMP Time Exceeded message to the Source Address 234 with Code 0 (Hop limit exceeded in transit), 235 interrupt packet processing, and discard the packet. 236 S07. } 237 S08. max_LE = (Hdr Ext Len / 2) - 1 238 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 239 S10. Send an ICMP Parameter Problem to the Source Address 240 with Code 0 (Erroneous header field encountered) 241 and Pointer set to the Segments Left field, 242 interrupt packet processing, and discard the packet. 243 S11. } 244 S12. Decrement IPv6 Hop Limit by 1 245 S13. Decrement Segments Left by 1 246 S14. Update IPv6 DA with Segment List [Segments Left] 247 S15. Push a new IPv6 header with its own SRH containing B, and 248 the VTN-ID in VTN option set to V in the HBH Ext header 249 S16. Set the outer IPv6 SA to A 250 S17. Set the outer IPv6 DA to the first SID of B 251 S18. Set the outer Payload Length, Traffic Class, Flow Label, 252 Hop Limit, and Next Header fields 253 S19. Submit the packet to the egress IPv6 FIB lookup for 254 transmission to the new destination 255 S20. } 257 3.2. End.NRP.Encaps 259 A new SRv6 function called End.NRP.Encaps is defined. This is a 260 variation of the End behavior. It instructs the endpoint node to 261 determine the corresponding NRP-ID of the local domain based on the 262 mapping relationship between the End.NRP.Encaps SID and the NRPs 263 maintained on the endpoint. The NRP-ID is encapsulated in the VTN 264 option in the IPv6 HBH extension header. 266 Any SID instance of this behavior is associated with one NRP-ID V and 267 a source address A. 269 When node N receives a packet whose IPv6 DA is S, and S is a local 270 End.NRP.Encaps SID, N does the following: 272 S01. When an SRH is processed { 273 S02. If (Segments Left == 0) { 274 S03. Stop processing the SRH, and proceed to process the next 275 header in the packet, whose type is identified by 276 the Next Header field in the routing header. 277 S04. } 278 S05. If (IPv6 Hop Limit <= 1) { 279 S06. Send an ICMP Time Exceeded message to the Source Address 280 with Code 0 (Hop limit exceeded in transit), 281 interrupt packet processing, and discard the packet. 282 S07. } 283 S08. max_LE = (Hdr Ext Len / 2) - 1 284 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 285 S10. Send an ICMP Parameter Problem to the Source Address 286 with Code 0 (Erroneous header field encountered) 287 and Pointer set to the Segments Left field, 288 interrupt packet processing, and discard the packet. 289 S11. } 290 S12. Decrement IPv6 Hop Limit by 1 291 S13. Decrement Segments Left by 1 292 S14. Update IPv6 DA with Segment List [Segments Left] 293 S15. Set the VTN-ID in VTN option to V in the HBH Ext header 294 S16. Submit the packet to the egress IPv6 FIB lookup for 295 transmission to the new destination 296 S17. } 298 3.3. End.BNRP.Encaps 300 A new SRv6 function called End.BNRP.Encaps: Endpoint bound to a NRP 301 with IPv6 encapsulation is defined. This is a variation of the End 302 behavior. For the End.BNRP SID, its corresponding NRP-ID should be 303 specified and encapsulated by the ingress node of SRv6 Path. It 304 instructs the endpoint node to obtain the corresponding NRP-ID from 305 the SRH, and encapsulate it in the VTN option in the IPv6 HBH 306 extension header. Through the End.BNRP.Encaps, the ingress node can 307 flexibly specify the local NRP the packet traverses in the network. 309 Any SID instance of this behavior is associated with one NRP-ID V and 310 a source address A. 312 There can be several options to carry the local NRP-ID corresponding 313 to the End.BNRP.Encaps function: 315 1. The NRP-ID is carried in the argument field of the 316 End.BNRP.Encaps SID. 318 2. The NRP-ID is carried in the SRH TLV field. 320 3. The NRP-ID is carried in the next SID following the 321 End.BNRP.Encaps SID in the SID list. 323 Editor's note: In the current version of this document, option 1 is 324 preferred, in which the local NRP-ID is carried in the argument field 325 of the SRv6 SID. 327 When an ingress node of an SR path encapsulates the End.BNRP.Encaps 328 SID into the packet, it SHOULD put the NRP-ID which the packet is 329 expected to be mapped to into the argument part of the SID. 331 When node N receives a packet whose IPv6 DA is S, and S is a local 332 End.BNRP.Encaps SID, N does the following: 334 S01. When an SRH is processed { 335 S02. If (Segments Left == 0) { 336 S03. Stop processing the SRH, and proceed to process the next 337 header in the packet, whose type is identified by 338 the Next Header field in the routing header. 339 S04. } 340 S05. If (IPv6 Hop Limit <= 1) { 341 S06. Send an ICMP Time Exceeded message to the Source Address 342 with Code 0 (Hop limit exceeded in transit), 343 interrupt packet processing, and discard the packet. 344 S07. } 345 S08. max_LE = (Hdr Ext Len / 2) - 1 346 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 347 S10. Send an ICMP Parameter Problem to the Source Address 348 with Code 0 (Erroneous header field encountered) 349 and Pointer set to the Segments Left field, 350 interrupt packet processing, and discard the packet. 351 S11. } 352 S12. Obtain the NRP-ID V from the argument part of the IPv6 DA 353 S13. Decrement IPv6 Hop Limit by 1 354 S14. Decrement Segments Left by 1 355 S15. Update IPv6 DA with Segment List [Segments Left] 356 S16. Set the VTN-ID in VTN option to V in the HBH Ext header 357 S17. Submit the packet to the egress IPv6 FIB lookup for 358 transmission to the new destination 359 S18. } 361 4. SR-MPLS NRP BSIDs 363 [I-D.li-mpls-enhanced-vpn-vtn-id] describes the mechanism of carrying 364 the VTN-ID of a network domain in the MPLS extension header. 366 With SR-MPLS data plane, NRP BSIDs can be allocated by a domain edge 367 node for the three types of NRP binding behaviors described in 368 section 2. 370 For the first type of NRP BSID, a BSID can be bound to a list of 371 resource-aware segments of a local NRP. When a node receives a 372 packet with a locally assigned NRP BSID, it determines the 373 corresponding SID list which consists of the resource-aware segments 374 of a local NRP, and encapsulates the SID list to the MPLS label 375 stack. 377 For another variant of the first type NRP BSID, a NRP BSID is bound 378 to a SR Policy and a local NRP-ID. When a node receives a packet 379 with a locally assigned NRP BSID, it determines the corresponding SID 380 list and the local NRP-ID, and encaps the packet with the SID list 381 and an MPLS VTN extension header which carries the local NRP-ID. 382 Note this requires to assign a NRP BSID for each SR policy in each 383 NRP the node participates in. 385 For the second type of NRP BSID, a NRP BSID is bound to the shortest 386 path in an NRP of the local network domain. When a node receives a 387 packet with a locally assigned NRP BSID, it determines the 388 corresponding local NRP-ID based on the mapping relationship between 389 the NRP BSID and the NRP-ID, and encapsulates the packet with an MPLS 390 VTN extension header which carries the local NRP-ID. Note this 391 requires to assign a NRP BSID for each local NRP. 393 For a variant of the second type NRP BSID, a NRP BSID is bound to the 394 shortest path in an NRP of the local network domain, the NRP-ID is 395 specified and encapsulated by the ingress node in the MPLS VTN 396 extension header. When a node receives a packet with a locally 397 assigned NRP BSID, it obtains the corresponding local NRP-ID from the 398 NRP-ID list in the VTN extension header, and update the local NRP-ID 399 in the VTN extension header with the obtained NRP-ID. 401 5. IANA Considerations 403 TBD 405 6. Security Considerations 407 TBD 409 7. Acknowledgements 411 The authors would like to thank Zhibo Hu for his review and valuable 412 comments. 414 8. References 416 8.1. Normative References 418 [I-D.ietf-teas-enhanced-vpn] 419 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 420 Framework for Enhanced Virtual Private Network (VPN+) 421 Services", Work in Progress, Internet-Draft, draft-ietf- 422 teas-enhanced-vpn-10, 6 March 2022, 423 . 426 [I-D.ietf-teas-ietf-network-slices] 427 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 428 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 429 Network Slices", Work in Progress, Internet-Draft, draft- 430 ietf-teas-ietf-network-slices-08, 6 March 2022, 431 . 434 [I-D.li-teas-e2e-ietf-network-slicing] 435 Li, Z., Dong, J., Pang, R., and Y. Zhu, "Framework for 436 End-to-End IETF Network Slicing", Work in Progress, 437 Internet-Draft, draft-li-teas-e2e-ietf-network-slicing-02, 438 7 March 2022, . 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, 443 DOI 10.17487/RFC2119, March 1997, 444 . 446 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 447 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 448 (SRv6) Network Programming", RFC 8986, 449 DOI 10.17487/RFC8986, February 2021, 450 . 452 8.2. Informative References 454 [I-D.dong-teas-nrp-scalability] 455 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 456 Mishra, G., Qin, F., Saad, T., and V. P. Beeram, 457 "Scalability Considerations for Network Resource 458 Partition", Work in Progress, Internet-Draft, draft-dong- 459 teas-nrp-scalability-01, 7 February 2022, 460 . 463 [I-D.ietf-6man-enhanced-vpn-vtn-id] 464 Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, 465 "Carrying Virtual Transport Network (VTN) Identifier in 466 IPv6 Extension Header", Work in Progress, Internet-Draft, 467 draft-ietf-6man-enhanced-vpn-vtn-id-00, 5 March 2022, 468 . 471 [I-D.ietf-spring-resource-aware-segments] 472 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 473 Z., and F. Clad, "Introducing Resource Awareness to SR 474 Segments", Work in Progress, Internet-Draft, draft-ietf- 475 spring-resource-aware-segments-04, 5 March 2022, 476 . 479 [I-D.ietf-spring-sr-for-enhanced-vpn] 480 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 481 Z., and F. Clad, "Segment Routing based Virtual Transport 482 Network (VTN) for Enhanced VPN", Work in Progress, 483 Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-02, 484 5 March 2022, . 487 [I-D.li-mpls-enhanced-vpn-vtn-id] 488 Li, Z. and J. Dong, "Carrying Virtual Transport Network 489 Identifier in MPLS Packet", Work in Progress, Internet- 490 Draft, draft-li-mpls-enhanced-vpn-vtn-id-02, 7 March 2022, 491 . 494 Authors' Addresses 496 Zhenbin Li 497 Huawei Technologies 498 Huawei Campus, No. 156 Beiqing Road 499 Beijing 500 100095 501 China 502 Email: lizhenbin@huawei.com 504 Jie Dong 505 Huawei Technologies 506 Huawei Campus, No. 156 Beiqing Road 507 Beijing 508 100095 509 China 510 Email: jie.dong@huawei.com 512 Ran Pang 513 China Unicom 514 Email: pangran@chinaunicom.cn 516 Yongqing Zhu 517 China Telecom 518 Email: zhuyq8@chinatelecom.cn