idnits 2.17.1 draft-li-spring-sr-e2e-ietf-network-slicing-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2021) is 1099 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 (-17) exists of draft-ietf-teas-enhanced-vpn-06 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slice-definition (ref. 'I-D.ietf-teas-ietf-network-slice-definition') ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slice-framework (ref. 'I-D.ietf-teas-ietf-network-slice-framework') == Outdated reference: A later version (-06) exists of draft-dong-6man-enhanced-vpn-vtn-id-02 == Outdated reference: A later version (-04) exists of draft-dong-teas-enhanced-vpn-vtn-scalability-01 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-01 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-for-enhanced-vpn-00 == Outdated reference: A later version (-03) exists of draft-li-mpls-enhanced-vpn-vtn-id-00 Summary: 3 errors (**), 0 flaws (~~), 8 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: October 24, 2021 April 22, 2021 7 Segment Routing for End-to-End IETF Network Slicing 8 draft-li-spring-sr-e2e-ietf-network-slicing-00 10 Abstract 12 Network slicing can be used to meet the connectivity and performance 13 requirement of different services or customers in a shared network. 14 An IETF network slice can be realized as enhanced VPNs (VPN+), which 15 is delivered by integrating the overlay VPN service with a Virtual 16 Transport Network (VTN) as the underlay. An end-to-end IETF network 17 slice may span multiple network domains. Within each domain, traffic 18 of the end-to-end network slice service is mapped to a local VTN. 20 When segment routing (SR) is used to build a multi-domain IETF 21 network slice, information of the local network slices in each domain 22 can be specified using special SR binding segments called VTN binding 23 segments (VTN BSID). The multi-domain IETF network slice can be 24 specified using a list of VTN BSIDs in the packet, each of which can 25 be used by the corresponding domain edge nodes to steer the traffic 26 of end-to-end IETF network slice into the specific VTN in the local 27 domain. 29 This document describes the functionality of VTN binding segment and 30 its instantiation in SR-MPLS and SRv6. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on October 24, 2021. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Segment Routing for IETF E2E Network Slicing . . . . . . . . 3 74 3. SRv6 VTN Binding Functions . . . . . . . . . . . . . . . . . 4 75 3.1. End.VTN.Encaps . . . . . . . . . . . . . . . . . . . . . 5 76 3.2. End.BVTN.Encaps . . . . . . . . . . . . . . . . . . . . . 5 77 3.3. End.B6VTN.Encaps . . . . . . . . . . . . . . . . . . . . 7 78 4. SR-MPLS VTN BSIDs . . . . . . . . . . . . . . . . . . . . . . 8 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 8.2. Informative References . . . . . . . . . . . . . . . . . 10 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 The definition and the characteristics of IETF network slice are 90 introduced in [I-D.ietf-teas-ietf-network-slice-definition], and 91 [I-D.ietf-teas-ietf-network-slice-framework] describes a general 92 framework of IETF network slice. 94 [I-D.ietf-teas-enhanced-vpn] describes the framework and the 95 candidate component technologies for providing enhanced VPN services. 97 VPN+ can be built from a VPN overlay and an underlying Virtual 98 Transport Network (VTN) which has a customized network topology and a 99 set of dedicated or shared resources in the underlay network. 100 Enhanced VPN (VPN+) can be used for the realization of IETF network 101 slices. [I-D.ietf-spring-sr-for-enhanced-vpn] describes the 102 mechanisms and procedures of using resource-aware segments 103 [I-D.ietf-spring-resource-aware-segments] to build SR based VTNs. 105 [I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the 106 scalability considerations in the control plane and data plane to 107 enable VPN+ services, and provide the suggestions to improve the 108 scalability of VTN. In the control plane, It proposes the approach 109 of decoupling the topology and resource attributes of VTN, so that 110 multiple VTNs may share the same topology and the result of topology 111 based path computation. In the data plane, it proposes to carry a 112 VTN-ID of a network domain in the data packet to determine the set of 113 resources reserved for the corresponding VTN. 115 An IETF network slice may span multiple network domains. Within each 116 domain, traffic of the end-to-end network slice is mapped to a local 117 network slice. The VTN-ID which identifies the virtual underlay 118 network in the local domain for the end-to-end network slice needs to 119 be determined on the domain edge node. 121 When segment routing (SR) is used to build a multi-domain IETF 122 network slice, information of the local network slices in each domain 123 can be specified using special SR binding segments called VTN binding 124 segments (VTN BSID). The multi-domain IETF network slice can be 125 specified using a list of VTN BSIDs in the packet, each of which can 126 be used by the corresponding domain edge nodes to steer the traffic 127 of end-to-end IETF network slice using the specific resource-aware 128 segments or VTN-ID of the local domain. 130 This document describes the functionality of the network slice 131 binding segment and its instantiation in SR-MPLS and SRv6. 133 2. Segment Routing for IETF E2E Network Slicing 135 [I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the 136 scalability considerations in the control plane and data plane to 137 enable VPN+ services. In data plane, it proposes to carry a 138 dedicated VTN-ID in data packet to determine the set of resources 139 reserved for the corresponding VTN in a network domain. 141 [I-D.li-teas-e2e-ietf-network-slicing] describes the framework of 142 carrying network slice related identifiers in the data plane, each of 143 the network slice IDs may have a different network scope. It 144 provides an approach of mapping the global VTN-ID to local VTN-IDs at 145 the network domain edge nodes. 147 With Segment Routing, there are several optional approaches to 148 realize the mapping between the end-to-end network slice and the 149 network slice constructs in the local domain. 151 1. The first approach is to use one type of VTN binding segment to 152 specify the mapping of traffic to a list of resource-aware 153 segments of a local VTN. 155 2. The second approach is to use one type of VTN binding segment to 156 determine a local VTN-ID, and instruct the encapsulation of the 157 local VTN-ID into the packet at the domain edge node. 159 3. The third approach is to use one type of VTN binding segment to 160 specify the mapping of traffic to a local VTN, the local VTN-ID 161 is specified in the associated fields by the ingress node, and is 162 encapsulated into the packet at the domain edge node. 164 4. The fourth approach is to use one type of VTN binding segment to 165 specify the mapping of traffic to a SR policy which is bound to a 166 local VTN. 168 The function of the first type of VTN binding segment is similar to 169 the function of the existing binding segment, the difference is it is 170 associated with a particular VTN. The other types of the VTN binding 171 segments are different from the existing binding segment, and their 172 instantiation in SR-MPLS and SRv6 are described in the following 173 sections. 175 3. SRv6 VTN Binding Functions 177 [RFC8986] defines the SRv6 Network Programming concept and specifies 178 the base set of SRv6 behaviors. The SRv6 End.B6.Encaps function is 179 defined to instantiate the Binding SID in SRv6, which can be used as 180 the first type of VTN binding function to specify the mapping of 181 traffic to a list of resource-aware SRv6 segments of a local VTN. 183 [I-D.dong-6man-enhanced-vpn-vtn-id] describes the mechanism of 184 carrying the VTN-ID of a network domain in the IPv6 Hop-by-Hop (HBH) 185 extension header. For the type 2, 3, 4 of VTN binding segments 186 described in section 2, three new SRv6 Binding functions are defined 187 in the following sections. 189 3.1. End.VTN.Encaps 191 A new SRv6 function called End.VTN.Encaps is defined. This is a 192 variation of the End behavior. It instructs the endpoint node to 193 determine the corresponding VTN-ID of the local domain based on the 194 mapping relationship between the End.VTN.Encaps SID and the VTNs 195 maintained on the endpoint. The VTN-ID is encapsulated in the VTN-ID 196 option in the IPv6 HBH extension header. 198 Any SID instance of this behavior is associated with one VTN-ID V and 199 a source address A. 201 When node N receives a packet whose IPv6 DA is S, and S is a local 202 End.VTN.Encaps SID, N does the following: 204 S01. When an SRH is processed { 205 S02. If (Segments Left == 0) { 206 S03. Stop processing the SRH, and proceed to process the next 207 header in the packet, whose type is identified by 208 the Next Header field in the routing header. 209 S04. } 210 S05. If (IPv6 Hop Limit <= 1) { 211 S06. Send an ICMP Time Exceeded message to the Source Address 212 with Code 0 (Hop limit exceeded in transit), 213 interrupt packet processing, and discard the packet. 214 S07. } 215 S08. max_LE = (Hdr Ext Len / 2) - 1 216 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 217 S10. Send an ICMP Parameter Problem to the Source Address 218 with Code 0 (Erroneous header field encountered) 219 and Pointer set to the Segments Left field, 220 interrupt packet processing, and discard the packet. 221 S11. } 222 S12. Decrement IPv6 Hop Limit by 1 223 S13. Decrement Segments Left by 1 224 S14. Update IPv6 DA with Segment List [Segments Left] 225 S15. Set the VTN-ID option to V in the HBH Ext header 226 S16. Submit the packet to the egress IPv6 FIB lookup for 227 transmission to the new destination 228 S17. } 230 3.2. End.BVTN.Encaps 232 A new SRv6 function called End.BVTN.Encaps: Endpoint bound to a VTN 233 with IPv6 encapsulation is defined. This is a variation of the End 234 behavior. For the End.BVTN SID, its corresponding VTN-ID should be 235 specified and encapsulated by the ingress node of SRv6 Path. It 236 instructs the endpoint node to obtain the corresponding VTN-ID from 237 the SRH, and encapsulate it in the VTN-ID option in the IPv6 HBH 238 extension header. Through the End.BVTN.Encaps, the ingress node can 239 flexibly specify the local VTN the packet traverses in the network. 241 Any SID instance of this behavior is associated with one VTN-ID V and 242 a source address A. 244 There can be several options to carry the local VTN-ID corresponding 245 to the End.BVTN.Encaps function: 247 1. The VTN-ID is carried in the argument field of the 248 End.BVTN.Encaps SID. 250 2. The VTN-ID is carried in the SRH TLV field. 252 3. The VTN-ID is carried in the next SID following the 253 End.BVTN.Encaps SID in the SID list. 255 Editor's note: In the current version of this document, option 1 is 256 preferred, in which the local VTN-ID is carried in the argument field 257 of the SRv6 SID. 259 When an ingress node of an SR path encapsulates the End.BVTN.Encaps 260 SID into the packet, it SHOULD put the VTN-ID which the packet is 261 expected to be mapped to into the argument part of the SID. 263 When node N receives a packet whose IPv6 DA is S, and S is a local 264 End.BVTN.Encaps SID, N does the following: 266 S01. When an SRH is processed { 267 S02. If (Segments Left == 0) { 268 S03. Stop processing the SRH, and proceed to process the next 269 header in the packet, whose type is identified by 270 the Next Header field in the routing header. 271 S04. } 272 S05. If (IPv6 Hop Limit <= 1) { 273 S06. Send an ICMP Time Exceeded message to the Source Address 274 with Code 0 (Hop limit exceeded in transit), 275 interrupt packet processing, and discard the packet. 276 S07. } 277 S08. max_LE = (Hdr Ext Len / 2) - 1 278 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 279 S10. Send an ICMP Parameter Problem to the Source Address 280 with Code 0 (Erroneous header field encountered) 281 and Pointer set to the Segments Left field, 282 interrupt packet processing, and discard the packet. 283 S11. } 284 S12. Obtain the VTN-ID V from the argument part of the IPv6 DA 285 S13. Decrement IPv6 Hop Limit by 1 286 S14. Decrement Segments Left by 1 287 S15. Update IPv6 DA with Segment List [Segments Left] 288 S16. Set the VTN-ID option to V in the HBH Ext header 289 S17. Submit the packet to the egress IPv6 FIB lookup for 290 transmission to the new destination 291 S18. } 293 3.3. End.B6VTN.Encaps 295 A new SRv6 function called End.B6VTN.Encaps: Endpoint bound to a SRv6 296 Policy in a VTN with IPv6 encapsulation is defined in this section. 297 This is a variation of the End behavior. It instructs the endpoint 298 node to determine an SRv6 Policy in a specific VTN of the local 299 domain, and encapsulate the SID list of the SR Policy and the VTN-ID 300 in a new IPv6 header. 302 Any SID instance of this behavior is associated with an SR Policy B, 303 a VTN-ID V and a source address A. 305 When node N receives a packet whose IPv6 DA is S, and S is a local 306 End.B6VTN.Encaps SID, N does the following: 308 S01. When an SRH is processed { 309 S02. If (Segments Left == 0) { 310 S03. Stop processing the SRH, and proceed to process the next 311 header in the packet, whose type is identified by 312 the Next Header field in the routing header. 313 S04. } 314 S05. If (IPv6 Hop Limit <= 1) { 315 S06. Send an ICMP Time Exceeded message to the Source Address 316 with Code 0 (Hop limit exceeded in transit), 317 interrupt packet processing, and discard the packet. 318 S07. } 319 S08. max_LE = (Hdr Ext Len / 2) - 1 320 S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { 321 S10. Send an ICMP Parameter Problem to the Source Address 322 with Code 0 (Erroneous header field encountered) 323 and Pointer set to the Segments Left field, 324 interrupt packet processing, and discard the packet. 325 S11. } 326 S12. Decrement IPv6 Hop Limit by 1 327 S13. Decrement Segments Left by 1 328 S14. Update IPv6 DA with Segment List [Segments Left] 329 S15. Push a new IPv6 header with its own SRH containing B, and 330 the VTN-ID option set to V in the HBH Ext header 331 S16. Set the outer IPv6 SA to A 332 S17. Set the outer IPv6 DA to the first SID of B 333 S18. Set the outer Payload Length, Traffic Class, Flow Label, 334 Hop Limit, and Next Header fields 335 S19. Submit the packet to the egress IPv6 FIB lookup for 336 transmission to the new destination 337 S20. } 339 4. SR-MPLS VTN BSIDs 341 [I-D.li-mpls-enhanced-vpn-vtn-id] describes the mechanism of carrying 342 the VTN-ID of a network domain in the MPLS extension header. 344 With SR-MPLS data plane, VTN binding SIDs can be allocated by a 345 domain edge node for the three types of VTN binding behaviors 346 described in section 2. 348 For the first type of VTN binding segment, a BSID is bound to a list 349 of resource-aware segments of a local VTN. When a node receives a 350 packet with a locally assigned VTN BSID, it determines the 351 corresponding SID list which consists of the resource-aware segments 352 of a local VTN, and encapsulates the SID list to the MPLS label 353 stack. 355 For the second type of VTN binding segment, a VTN BSID is bound to a 356 VTN of the local network domain. When a node receives a packet with 357 a locally assigned VTN BSID, it determines the corresponding local 358 VTN-ID based on the mapping relationship between the VTN BSID and the 359 VTN-ID, and encapsulates the packet with an MPLS VTN extension header 360 which carries the local VTN-ID option. Note this requires to assign 361 a VTN BSID for each VTN. 363 For the third type of VTN binding segment, a VTN BSID is bound to a 364 VTN of the local network domain, the VTN-ID is specified and 365 encapsulated by the ingress node in the MPLS VTN extension header. 366 When a node receives a packet with a locally assinged VTN BSID, it 367 obtains the corresponding local VTN-ID from the VTN-ID list in the 368 VTN extension header, and update the local VTN-ID option in the VTN 369 extension header with the obtained VTN-ID. 371 For the fourth type of VTN binding behavior, a VTN BSID is bound to a 372 SR Policy in a VTN of the local network domain. When a node receives 373 a packet with a locally assigned VTN BSID, it determines the 374 corresponding SID list and the local VTN-ID, and encaps the packet 375 with the SID list and an MPLS VTN extension header which carries the 376 local VTN-ID option. Note this requires to assign a VTN BSID for 377 each SR policy in each VTN the node participates in. 379 5. IANA Considerations 381 TBD 383 6. Security Considerations 385 TBD 387 7. Acknowledgements 389 TBD 391 8. References 393 8.1. Normative References 395 [I-D.ietf-teas-enhanced-vpn] 396 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 397 Framework for Enhanced Virtual Private Networks (VPN+) 398 Service", draft-ietf-teas-enhanced-vpn-06 (work in 399 progress), July 2020. 401 [I-D.ietf-teas-ietf-network-slice-definition] 402 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 403 Tantsura, "Definition of IETF Network Slices", draft-ietf- 404 teas-ietf-network-slice-definition-00 (work in progress), 405 January 2021. 407 [I-D.ietf-teas-ietf-network-slice-framework] 408 Gray, E. and J. Drake, "Framework for IETF Network 409 Slices", March 2021, . 412 [I-D.li-teas-e2e-ietf-network-slicing] 413 Li, Z. and J. Dong, "Framework for End-to-End IETF Network 414 Slicing", April 2021, . 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 423 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 424 (SRv6) Network Programming", RFC 8986, 425 DOI 10.17487/RFC8986, February 2021, 426 . 428 8.2. Informative References 430 [I-D.dong-6man-enhanced-vpn-vtn-id] 431 Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual 432 Transport Network Identifier in IPv6 Extension Header", 433 draft-dong-6man-enhanced-vpn-vtn-id-02 (work in progress), 434 November 2020. 436 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 437 Dong, J., Li, Z., Qin, F., and G. Yang, "Scalability 438 Considerations for Enhanced VPN (VPN+)", draft-dong-teas- 439 enhanced-vpn-vtn-scalability-01 (work in progress), 440 November 2020. 442 [I-D.ietf-spring-resource-aware-segments] 443 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 444 Z., and F. Clad, "Introducing Resource Awareness to SR 445 Segments", draft-ietf-spring-resource-aware-segments-01 446 (work in progress), January 2021. 448 [I-D.ietf-spring-sr-for-enhanced-vpn] 449 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 450 Z., and F. Clad, "Segment Routing based Virtual Transport 451 Network (VTN) for Enhanced VPN", draft-ietf-spring-sr-for- 452 enhanced-vpn-00 (work in progress), February 2021. 454 [I-D.li-mpls-enhanced-vpn-vtn-id] 455 Li, Z. and J. Dong, "Carrying Virtual Transport Network 456 Identifier in MPLS Packet", draft-li-mpls-enhanced-vpn- 457 vtn-id-00 (work in progress), February 2021. 459 Authors' Addresses 461 Zhenbin Li 462 Huawei Technologies 463 Huawei Campus, No. 156 Beiqing Road 464 Beijing 100095 465 China 467 Email: lizhenbin@huawei.com 469 Jie Dong 470 Huawei Technologies 471 Huawei Campus, No. 156 Beiqing Road 472 Beijing 100095 473 China 475 Email: jie.dong@huawei.com