idnits 2.17.00 (12 Aug 2021) /tmp/idnits61425/draft-ietf-6man-enhanced-vpn-vtn-id-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 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 (5 March 2022) is 70 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 (-10) exists of draft-ietf-teas-enhanced-vpn-09 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-19) exists of draft-ietf-lsr-flex-algo-18 Summary: 1 error (**), 0 flaws (~~), 3 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: 6 September 2022 C. Xie 6 C. Ma 7 China Telecom 8 G. Mishra 9 Verizon Inc. 10 5 March 2022 12 Carrying Virtual Transport Network (VTN) Identifier in IPv6 Extension 13 Header 14 draft-ietf-6man-enhanced-vpn-vtn-id-00 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 6 September 2022. 58 Copyright Notice 60 Copyright (c) 2022 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 (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 76 2. New IPv6 Extension Header Option for VTN . . . . . . . . . . 4 77 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. VTN Option Insertion . . . . . . . . . . . . . . . . . . 5 79 3.2. VTN based Packet Forwarding . . . . . . . . . . . . . . . 5 80 4. Operational Considerations . . . . . . . . . . . . . . . . . 6 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 83 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 87 9.2. Informative References . . . . . . . . . . . . . . . . . 7 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 Virtual Private Networks (VPNs) provide different customers with 93 logically isolated connectivity over a common network infrastructure. 94 With the introduction and evolvement of 5G and other network 95 scenarios, some existing or new customers may require connectivity 96 services with advanced characteristics comparing to traditional VPNs, 97 such as resource isolation from other services or guaranteed 98 performance. Such kind of network service is called enhanced VPN 99 (VPN+). VPN+ service requires the coordination and integration 100 between the overlay VPNs and the network characteristics of the 101 underlay. 103 [I-D.ietf-teas-enhanced-vpn] describes a framework and the candidate 104 component technologies for providing VPN+ services. It also 105 introduces the concept of Virtual Transport Network (VTN). A Virtual 106 Transport Network (VTN) is a virtual underlay network which consists 107 of a set of dedicated or shared network resources allocated from the 108 physical underlay network, and is associated with a customized 109 logical network topology. VPN+ services can be delivered by mapping 110 one or a group of overlay VPNs to the appropriate VTNs as the 111 underlay, so as to provide the network characteristics required by 112 the customers. In packet forwarding, traffic of different VPN+ 113 services need to be processed separately based on the network 114 resources and the logical topology associated with the corresponding 115 VTN. 117 [I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the 118 scalability considerations and the possible optimizations for 119 providing a relatively large number of VTNs for VPN+ services. One 120 approach to improve the data plane scalability of VTN is to introduce 121 a dedicated VTN Resource Identifier (VTN Resource ID) in the data 122 packet to identify the set of network resources allocated to a VTN, 123 so that VTN-specific packet processing can be performed using that 124 set of resources, which avoids the possible resource competition with 125 services in other VTNs. This is called Resource Independent (RI) 126 VTN. A VTN Resource ID represents a subset of the resources (e.g. 127 bandwidth, buffer and queuing resources) allocated on a given set of 128 links and nodes which constitute a logical network topology. The 129 logical topology associated with a VTN could be defined using 130 mechanisms such as Multi-Topology [RFC4915], [RFC5120] or Flex-Algo 131 [I-D.ietf-lsr-flex-algo], etc. 133 This document proposes a mechanism to carry the VTN resource ID in a 134 new Hop-by-Hop option of IPv6 extension header [RFC8200] of IPv6 135 packet, so that on each network node along the packet forwarding 136 path, the VTN option in the packet is parsed, and the obtained VTN 137 Resource ID is used to instruct the network node to use the set of 138 network resources allocated to the corresponding VTN to process and 139 forward the packet. The procedure for processing the VTN Resource ID 140 is also specified. This provides a scalable solution to support a 141 relatively large number of VTNs in an IPv6 network. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 BCP14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 149 appear in all capitals, as shown here. 151 2. New IPv6 Extension Header Option for VTN 153 A new Hop-by-Hop option type "VTN" is defined to carry the VTN 154 related Identifier in an IPv6 packet. Its format is shown as below: 156 Option Option Option 157 Type Data Len Data 158 +--------+--------+-------------------------+ 159 |BBCTTTTT|00000100| 4-octet VTN Resource ID | 160 +--------+--------+-------------------------+ 161 Figure 1. The format of VTN Option 163 Option Type: 8-bit identifier of the type of option. The type of VTN 164 option is to be assigned by IANA. The highest-order bits of the type 165 field are defined as below: 167 * BB 00 The highest-order 2 bits are set to 00 to indicate that a 168 node which does not recognize this type will skip over it and 169 continue processing the header. 171 * C 0 The third highest-order bit are set to 0 to indicate this 172 option does not change en route. 174 Opt Data Len: 8-bit unsigned integer indicates the length of the 175 option Data field of this option, in octets. The value of Opt Data 176 Len of VTN option SHOULD be set to 4. 178 VTN Resource ID: 4-octet identifier which uniquely identifies the set 179 of network resources allocated to a VTN. 181 Editor's note: The length of the VTN Resource ID is defined as 182 4-octet in correspondence to the 4-octet Single Network Slice 183 Selection Assistance Information (S-NSSAI) defined in 3GPP [TS23501]. 185 8-bit 24-bit 186 +------------+-------------------------+ 187 | SST | Slice Differentiator | 188 +------------+-------------------------+ 189 Figure 2. The format of S-NSSAI 191 3. Procedures 193 As the VTN option needs to be processed by each node along the path 194 for VTN-specific forwarding, it SHOULD be carried in IPv6 Hop-by-Hop 195 options header when the Hop-by-Hop options header can be either 196 processed or ignored in forwarding plane by all the nodes along the 197 path. 199 3.1. VTN Option Insertion 201 When an ingress node of an IPv6 domain receives a packet, according 202 to the traffic classification or mapping policy, the packet is 203 steered into one of the VTNs in the network, then the packet SHOULD 204 be encapsulated in an outer IPv6 header, and the Resource ID of the 205 VTN which the packet is mapped to SHOULD be carried in the VTN option 206 of the Hop-by-Hop options header associated with the outer IPv6 207 header. 209 3.2. VTN based Packet Forwarding 211 On receipt of a packet with the VTN option, each network node which 212 can process the VTN option in fast path SHOULD use the VTN Resource 213 ID to determine the set of local network resources allocated to the 214 VTN for packet processing. The packet forwarding behavior is based 215 on both the destination IP address and the VTN Resource ID. More 216 specifically, the destination IP address is used to determine the 217 next-hop and the outgoing interface, and VTN Resource ID is used to 218 determine the set of network resources on the outgoing interface 219 which are reserved to the VTN for processing and sending the packet. 220 The Traffic Class field of the outer IPv6 header MAY be used to 221 provide Diffserv treatment for packets which belong to the same VTN. 222 The egress node of the IPv6 domain SHOULD decapsulate the outer IPv6 223 header which includes the VTN option. 225 In the forwarding plane, there can be different approaches of 226 partitioning the local network resources and allocating them to 227 different VTNs. For example, on one physical interface, a subset of 228 the forwarding plane resources (e.g. the bandwidth and the associated 229 buffer and queuing resources) can be allocated to a particular VTN 230 and represented as a virtual sub-interface with reserved bandwidth 231 resource. In packet forwarding, the IPv6 destination address of the 232 received packet is used to identify the next-hop and the outgoing 233 layer-3 interface, and the VTN Resource ID is used to further 234 identify the virtual sub-interface which is associated with the VTN 235 on the outgoing interface. 237 Network nodes which do not support the processing of Hop-by-Hop 238 options header SHOULD ignore the Hop-by-Hop options header and 239 forward the packet only based on the destination IP address. Network 240 nodes which support Hop-by-Hop Options header, but do not support the 241 VTN option SHOULD ignore the VTN option and continue to forward the 242 packet based on the destination IP address and MAY also based on the 243 rest of the Hop-by-Hop Options. 245 4. Operational Considerations 247 As described in [RFC8200], network nodes may be configured to ignore 248 the Hop-by-Hop Options header, and in some implementations a packet 249 containing a Hop-by-Hop Options header may be dropped or assigned to 250 a slow processing path. The proposed modification to the processing 251 of IPv6 Hop-by-Hop options header is specified in 252 [I-D.ietf-6man-hbh-processing]. Operator needs to make sure that all 253 the network nodes involved in a VTN can either process Hop-by-Hop 254 Options header in the fast path, or ignore the Hop-by-Hop Option 255 header. Since a VTN is associated with a logical network topology, 256 it is practical to ensure that all the network nodes involved in that 257 logical topology support the processing of the HBH options header and 258 the VTN option. In other word, packets steered into a VTN MUST NOT 259 be dropped due to the existence of the Hop-by-Hop Options header. It 260 is RECOMMENDED to configure all the network nodes involved in a VTN 261 to process the Hop-by-Hop Options header and the VTN option if there 262 is a nob for this. 264 5. IANA Considerations 266 This document requests IANA to assign a new option type from 267 "Destination Options and Hop-by-Hop Options" registry. 269 Value Description Reference 270 -------------------------------------- 271 TBD VTN Option this document 273 6. Security Considerations 275 The security considerations with IPv6 Hop-by-Hop options header are 276 described in [RFC8200], [RFC7045] and [I-D.ietf-6man-hbh-processing]. 277 This document introduces a new IPv6 Hop-by-Hop option which is either 278 processed in the fast path or ignored by network nodes, thus it does 279 not introduce additional security issues. 281 7. Contributors 283 Zhibo Hu 284 Email: huzhibo@huawei.com 286 Lei Bao 287 Email: baolei7@huawei.com 289 8. Acknowledgements 291 The authors would like to thank Juhua Xu, James Guichard, Joel 292 Halpern and Tom Petch for their review and valuable comments. 294 9. References 296 9.1. Normative References 298 [I-D.ietf-teas-enhanced-vpn] 299 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 300 Framework for Enhanced Virtual Private Network (VPN+) 301 Services", Work in Progress, Internet-Draft, draft-ietf- 302 teas-enhanced-vpn-09, 25 October 2021, 303 . 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, 308 DOI 10.17487/RFC2119, March 1997, 309 . 311 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 312 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 313 May 2017, . 315 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 316 (IPv6) Specification", STD 86, RFC 8200, 317 DOI 10.17487/RFC8200, July 2017, 318 . 320 9.2. Informative References 322 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 323 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 324 Mishra, G., and F. Qin, "Scalability Considerations for 325 Enhanced VPN (VPN+)", Work in Progress, Internet-Draft, 326 draft-dong-teas-enhanced-vpn-vtn-scalability-04, 25 327 October 2021, . 330 [I-D.ietf-6man-hbh-processing] 331 Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options 332 Processing Procedures", Work in Progress, Internet-Draft, 333 draft-ietf-6man-hbh-processing-00, 29 January 2022, 334 . 337 [I-D.ietf-lsr-flex-algo] 338 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 339 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 340 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 341 2021, . 344 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 345 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 346 RFC 4915, DOI 10.17487/RFC4915, June 2007, 347 . 349 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 350 Topology (MT) Routing in Intermediate System to 351 Intermediate Systems (IS-ISs)", RFC 5120, 352 DOI 10.17487/RFC5120, February 2008, 353 . 355 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 356 of IPv6 Extension Headers", RFC 7045, 357 DOI 10.17487/RFC7045, December 2013, 358 . 360 [TS23501] "3GPP TS23.501", 2016, 361 . 364 Authors' Addresses 366 Jie Dong 367 Huawei Technologies 368 Huawei Campus, No. 156 Beiqing Road 369 Beijing 370 100095 371 China 372 Email: jie.dong@huawei.com 374 Zhenbin Li 375 Huawei Technologies 376 Huawei Campus, No. 156 Beiqing Road 377 Beijing 378 100095 379 China 380 Email: lizhenbin@huawei.com 382 Chongfeng Xie 383 China Telecom 384 China Telecom Beijing Information Science & Technology, Beiqijia 385 Beijing 386 102209 387 China 388 Email: xiechf@chinatelecom.cn 390 Chenhao Ma 391 China Telecom 392 China Telecom Beijing Information Science & Technology, Beiqijia 393 Beijing 394 102209 395 China 396 Email: machh@chinatelecom.cn 398 Gyan Mishra 399 Verizon Inc. 400 Email: gyan.s.mishra@verizon.com