idnits 2.17.1 draft-dong-6man-enhanced-vpn-vtn-id-06.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 24, 2021) is 886 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-08 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-04) exists of draft-dong-teas-enhanced-vpn-vtn-scalability-03 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-17 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft Z. Li 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 27, 2022 C. Xie 6 C. Ma 7 China Telecom 8 G. Mishra 9 Verizon Inc. 10 October 24, 2021 12 Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension 13 Header 14 draft-dong-6man-enhanced-vpn-vtn-id-06 16 Abstract 18 Virtual Private Networks (VPNs) provide different customers with 19 logically separated connectivity over a common network 20 infrastructure. With the introduction and evolvement of 5G and other 21 network scenarios, some existing or new customers may require 22 connectivity services with advanced characteristics comparing to 23 traditional VPNs. Such kind of network service is called enhanced 24 VPNs (VPN+). 26 A Virtual Transport Network (VTN) is a virtual underlay network which 27 consists of a set of dedicated or shared network resources allocated 28 from the physical underlay network, and is associated with a 29 customized logical network topology. VPN+ services can be delivered 30 by mapping one or a group of overlay VPNs to the appropriate VTNs as 31 the virtual underlay. In packet forwarding, some fields in the data 32 packet needs to be used to identify the VTN the packet belongs to, so 33 that the VTN-specific processing can be performed on each node the 34 packet traverses. 36 This document proposes a new Hop-by-Hop option of IPv6 extension 37 header to carry the VTN Resource ID, which is used to identify the 38 set of network resources allocated to a VTN for packet processing. 39 The procedure for processing the VTN option is also specified. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on April 27, 2022. 58 Copyright Notice 60 Copyright (c) 2021 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 76 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 77 2. New IPv6 Extension Header Option for VTN . . . . . . . . . . 4 78 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3.1. VTN Option Insertion . . . . . . . . . . . . . . . . . . 5 80 3.2. VTN based Packet Forwarding . . . . . . . . . . . . . . . 5 81 4. Operational Considerations . . . . . . . . . . . . . . . . . 6 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 84 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 88 9.2. Informative References . . . . . . . . . . . . . . . . . 7 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 91 1. Introduction 93 Virtual Private Networks (VPNs) provide different customers with 94 logically isolated connectivity over a common network infrastructure. 95 With the introduction and evolvement of 5G and other network 96 scenarios, some existing or new customers may require connectivity 97 services with advanced characteristics comparing to traditional VPNs, 98 such as resource isolation from other services or guaranteed 99 performance. Such kind of network service is called enhanced VPN 100 (VPN+). VPN+ service requires the coordination and integration 101 between the overlay VPNs and the network characteristics of the 102 underlay. 104 [I-D.ietf-teas-enhanced-vpn] describes a framework and the candidate 105 component technologies for providing VPN+ services. It also 106 introduces the concept of Virtual Transport Network (VTN). A Virtual 107 Transport Network (VTN) is a virtual underlay network which consists 108 of a set of dedicated or shared network resources allocated from the 109 physical underlay network, and is associated with a customized 110 logical network topology. VPN+ services can be delivered by mapping 111 one or a group of overlay VPNs to the appropriate VTNs as the 112 underlay, so as to provide the network characteristics required by 113 the customers. In packet forwarding, traffic of different VPN+ 114 services need to be processed separately based on the network 115 resources and the logical topology associated with the corresponding 116 VTN. 118 [I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the 119 scalability considerations and the possible optimizations for 120 providing a relatively large number of VTNs for VPN+ services. One 121 approach to improve the data plane scalability of VTN is to introduce 122 a dedicated VTN Resource Identifier (VTN Resource ID) in the data 123 packet to identify the set of network resources allocated to a VTN, 124 so that VTN-specific packet processing can be performed using that 125 set of resources, which avoids the possible resource competition with 126 services in other VTNs. This is called Resource Independent (RI) 127 VTN. A VTN Resource ID represents a subset of the resources (e.g. 128 bandwidth, buffer and queuing resources) allocated on a given set of 129 links and nodes which constitute a logical network topology. The 130 logical topology associated with a VTN could be defined using 131 mechanisms such as Multi-Topology [RFC4915], [RFC5120] or Flex-Algo 132 [I-D.ietf-lsr-flex-algo], etc. 134 This document proposes a mechanism to carry the VTN resource ID in a 135 new Hop-by-Hop option of IPv6 extension header [RFC8200] of IPv6 136 packet, so that on each network node along the packet forwarding 137 path, the VTN option in the packet is parsed, and the obtained VTN 138 Resource ID is used to instruct the network node to use the set of 139 network resources allocated to the corresponding VTN to process and 140 forward the packet. The procedure for processing the VTN Resource ID 141 is also specified. This provides a scalable solution to support a 142 relatively large number of VTNs in an IPv6 network. 144 1.1. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in 149 BCP14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 150 appear in all capitals, as shown here. 152 2. New IPv6 Extension Header Option for VTN 154 A new Hop-by-Hop option type "VTN" is defined to carry the VTN 155 related Identifier in an IPv6 packet. Its format is shown as below: 157 Option Option Option 158 Type Data Len Data 159 +--------+--------+-------------------------+ 160 |BBCTTTTT|00000100| 4-octet VTN Resource ID | 161 +--------+--------+-------------------------+ 162 Figure 1. The format of VTN Option 164 Option Type: 8-bit identifier of the type of option. The type of VTN 165 option is to be assigned by IANA. The highest-order bits of the type 166 field are defined as below: 168 o BB 00 The highest-order 2 bits are set to 00 to indicate that a 169 node which does not recognize this type will skip over it and 170 continue processing the header. 172 o C 0 The third highest-order bit are set to 0 to indicate this 173 option does not change en route. 175 Opt Data Len: 8-bit unsigned integer indicates the length of the 176 option Data field of this option, in octets. The value of Opt Data 177 Len of VTN option SHOULD be set to 4. 179 VTN Resource ID: 4-octet identifier which uniquely identifies the set 180 of network resources allocated to a VTN. 182 Editor's note: The length of the VTN Resource ID is defined as 183 4-octet in correspondence to the 4-octet Single Network Slice 184 Selection Assistance Information (S-NSSAI) defined in 3GPP [TS23501]. 186 8-bit 24-bit 187 +------------+-------------------------+ 188 | SST | Slice Differentiator | 189 +------------+-------------------------+ 190 Figure 2. The format of S-NSSAI 192 3. Procedures 194 As the VTN option needs to be processed by each node along the path 195 for VTN-specific forwarding, it SHOULD be carried in IPv6 Hop-by-Hop 196 options header when the Hop-by-Hop options header can be either 197 processed or ignored in forwarding plane by all the nodes along the 198 path. 200 3.1. VTN Option Insertion 202 When an ingress node of an IPv6 domain receives a packet, according 203 to the traffic classification or mapping policy, the packet is 204 steered into one of the VTNs in the network, then the packet SHOULD 205 be encapsulated in an outer IPv6 header, and the Resource ID of the 206 VTN which the packet is mapped to SHOULD be carried in the VTN option 207 of the Hop-by-Hop options header associated with the outer IPv6 208 header. 210 3.2. VTN based Packet Forwarding 212 On receipt of a packet with the VTN option, each network node which 213 can process the VTN option in fast path SHOULD use the VTN Resource 214 ID to determine the set of local network resources allocated to the 215 VTN for packet processing. The packet forwarding behavior is based 216 on both the destination IP address and the VTN Resource ID. More 217 specifically, the destination IP address is used to determine the 218 next-hop and the outgoing interface, and VTN Resource ID is used to 219 determine the set of network resources on the outgoing interface 220 which are reserved to the VTN for processing and sending the packet. 221 The Traffic Class field of the outer IPv6 header MAY be used to 222 provide Diffserv treatment for packets which belong to the same VTN. 223 The egress node of the IPv6 domain SHOULD decapsulate the outer IPv6 224 header which includes the VTN option. 226 In the forwarding plane, there can be different approaches of 227 partitioning the local network resources and allocating them to 228 different VTNs. For example, on one physical interface, a subset of 229 the forwarding plane resources (e.g. the bandwidth and the associated 230 buffer and queuing resources) can be allocated to a particular VTN 231 and represented as a virtual sub-interface with reserved bandwidth 232 resource. In packet forwarding, the IPv6 destination address of the 233 received packet is used to identify the next-hop and the outgoing 234 layer-3 interface, and the VTN Resource ID is used to further 235 identify the virtual sub-interface which is associated with the VTN 236 on the outgoing interface. 238 Network nodes which do not support the processing of Hop-by-Hop 239 options header SHOULD ignore the Hop-by-Hop options header and 240 forward the packet only based on the destination IP address. Network 241 nodes which support Hop-by-Hop Options header, but do not support the 242 VTN option SHOULD ignore the VTN option and continue to forward the 243 packet based on the destination IP address and MAY also based on the 244 rest of the Hop-by-Hop Options. 246 4. Operational Considerations 248 As described in [RFC8200], network nodes may be configured to ignore 249 the Hop-by-Hop Options header, and in some implementations a packet 250 containing a Hop-by-Hop Options header may be dropped or assigned to 251 a slow processing path. The proposed modification to the processing 252 of IPv6 Hop-by-Hop options header is specified in 253 [I-D.hinden-6man-hbh-processing]. Operator needs to make sure that 254 all the network nodes involved in a VTN can either process Hop-by-Hop 255 Options header in the fast path, or ignore the Hop-by-Hop Option 256 header. Since a VTN is associated with a logical network topology, 257 it is practical to ensure that all the network nodes involved in that 258 logical topology support the processing of the HBH options header and 259 the VTN option. In other word, packets steered into a VTN MUST NOT 260 be dropped due to the existence of the Hop-by-Hop Options header. It 261 is RECOMMENDED to configure all the network nodes involved in a VTN 262 to process the Hop-by-Hop Options header and the VTN option if there 263 is a nob for this. 265 5. IANA Considerations 267 This document requests IANA to assign a new option type from 268 "Destination Options and Hop-by-Hop Options" registry. 270 Value Description Reference 271 -------------------------------------- 272 TBD VTN Option this document 274 6. Security Considerations 276 The security considerations with IPv6 Hop-by-Hop options header are 277 described in [RFC8200], [RFC7045] and 278 [I-D.hinden-6man-hbh-processing]. This document introduces a new 279 IPv6 Hop-by-Hop option which is either processed in the fast path or 280 ignored by network nodes, thus it does not introduce additional 281 security issues. 283 7. Contributors 284 Zhibo Hu 285 Email: huzhibo@huawei.com 287 Lei Bao 288 Email: baolei7@huawei.com 290 8. Acknowledgements 292 The authors would like to thank Juhua Xu, James Guichard, Joel 293 Halpern and Tom Petch for their review and valuable comments. 295 9. References 297 9.1. Normative References 299 [I-D.ietf-teas-enhanced-vpn] 300 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 301 Framework for Enhanced Virtual Private Network (VPN+) 302 Services", draft-ietf-teas-enhanced-vpn-08 (work in 303 progress), July 2021. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, 307 DOI 10.17487/RFC2119, March 1997, 308 . 310 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 311 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 312 May 2017, . 314 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 315 (IPv6) Specification", STD 86, RFC 8200, 316 DOI 10.17487/RFC8200, July 2017, 317 . 319 9.2. Informative References 321 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 322 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 323 Mishra, G., and F. Qin, "Scalability Considerations for 324 Enhanced VPN (VPN+)", draft-dong-teas-enhanced-vpn-vtn- 325 scalability-03 (work in progress), July 2021. 327 [I-D.hinden-6man-hbh-processing] 328 Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options 329 Processing Procedures", draft-hinden-6man-hbh- 330 processing-01 (work in progress), June 2021. 332 [I-D.ietf-lsr-flex-algo] 333 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 334 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 335 algo-17 (work in progress), July 2021. 337 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 338 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 339 RFC 4915, DOI 10.17487/RFC4915, June 2007, 340 . 342 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 343 Topology (MT) Routing in Intermediate System to 344 Intermediate Systems (IS-ISs)", RFC 5120, 345 DOI 10.17487/RFC5120, February 2008, 346 . 348 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 349 of IPv6 Extension Headers", RFC 7045, 350 DOI 10.17487/RFC7045, December 2013, 351 . 353 [TS23501] "3GPP TS23.501", 2016, 354 . 357 Authors' Addresses 359 Jie Dong 360 Huawei Technologies 361 Huawei Campus, No. 156 Beiqing Road 362 Beijing 100095 363 China 365 Email: jie.dong@huawei.com 367 Zhenbin Li 368 Huawei Technologies 369 Huawei Campus, No. 156 Beiqing Road 370 Beijing 100095 371 China 373 Email: lizhenbin@huawei.com 374 Chongfeng Xie 375 China Telecom 376 China Telecom Beijing Information Science & Technology, Beiqijia 377 Beijing 102209 378 China 380 Email: xiechf@chinatelecom.cn 382 Chenhao Ma 383 China Telecom 384 China Telecom Beijing Information Science & Technology, Beiqijia 385 Beijing 102209 386 China 388 Email: machh@chinatelecom.cn 390 Gyan Mishra 391 Verizon Inc. 393 Email: gyan.s.mishra@verizon.com