idnits 2.17.1 draft-dong-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 : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 208 has weird spacing: '...ntifier this...' == 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 (February 10, 2020) is 1536 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-6man-segment-routing-header' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 258, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-dong-teas-enhanced-vpn-vtn-scalability-00 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-07 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 6MAN working group J. Dong 2 Internet-Draft Z. Li 3 Intended status: Standard Track Huawei 4 Expires: August 2020 February 10, 2020 6 Carrying Virtual Transport Network (VTN) Identifier in IPv6 7 Extensison Header for Enhanced VPN 9 draft-dong-6man-enhanced-vpn-vtn-id-00 11 Abstract 13 This document proposes a new option type to carry virtual transport 14 network identifier (VTN ID) in the IPv6 extensions headers to 15 identify the virtual transport network the packet belongs to. The 16 procedure of processing the VTN option is also specified. This 17 provides a scalable solution for data plane encapsulation of 18 enhanced VPN (VPN+) as described in I-D.ietf-teas-enhanced-vpn. One 19 typical use case of VPN+ is to provide transport network slicing in 20 5G, while it could also be used in more general cases. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 10, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction ................................................ 2 57 2. Requirements Language ....................................... 3 58 3. New IPv6 Extension Header Option for VTN .................... 3 59 4. Procedures .................................................. 4 60 4.1. VTN Option Insertion ................................... 4 61 4.2. VTN based Packet Forwarding ............................ 5 62 5. Security Considerations ..................................... 5 63 IANA Considerations ............................................ 5 64 Contributors ................................................... 6 65 Acknowledgments ................................................ 6 66 References ..................................................... 6 67 Normative References ........................................ 6 68 Informative References ...................................... 6 69 Authors' Addresses ............................................. 7 71 1. Introduction 73 Virtual private networks (VPNs) have served the industry well as a 74 means of providing different groups of users with logically isolated 75 connectivity over a common network. Some customers may request a 76 connectivity services with advanced characteristics such as complete 77 isolation from other services or guaranteed performance. These 78 services are "enhanced VPNs" (known as VPN+). [I-D.ietf-teas- 79 enhanced-vpn] describes the framework and candidate component 80 technologies for providing enhanced VPN services. One typical use 81 case of VPN+ is to provide transport network slicing in 5G, while it 82 could also be used in more general cases. 84 The enhanced properties of VPN+ require tighter coordination and 85 integration between the underlay network resources and the overlay 86 network. VPN+ service is built on a Virtual Transport Network (VTN) 87 which has a customized network topology and a set of dedicated or 88 shared network resources allocated from the underlay network. The 89 overlay VPN together with the corresponding VTN in the underlay 90 provide the VPN+ service. In the network, traffic of different VPN+ 91 services need to be processed separately based on the topology and 92 the network resources associated with the corresponding VTN. 94 [I-D.dong-teas-enhanced-vpn-vtn-scalability] describes the 95 scalability considerations of enhanced VPN, in which one approach 96 to improve the data plane scalability is to introduce a dedicated 97 identifier indata packet to identify the VTN the packet belongs to, 98 so as to perform resource specific packet processing. This is called 99 Resource Independent (RI) VTN. 101 This document proposes a mechanism to carry the VTN Identifier (VTN 102 ID) in the IPv6 extensions headers [RFC8200] of packet, so that the 103 packet will be processed by network nodes using the network 104 resources allocated to the corresponding VTN. The procedure of 105 processing the VTN ID is also specified. This provides a scalable 106 solution for enhanced VPN data plane, so that it could be used to 107 support a large number of transport network slices in IPv6 network. 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. New IPv6 Extension Header Option for VTN 119 A new option type of IPv6 extension headers is defined to carry the 120 Virtual Transport Network Identifier (VTN ID) in IPv6 packet header. 121 Its format is shown as below: 123 Option Option Option 124 Type Data Len Data 125 +--------+--------+--------+--------+ 126 |BBCTTTTT|00000100| 4-octet VTN ID | 127 +--------+--------+--------+--------+ 129 Option Type: 8-bit identifier of the type of option. The type of VTN 130 option is TBD by IANA. The highest-order bits of the type field are 131 defined as below: 133 BB 00 The highest-order 2 bits are set to 00 to indicate that a 134 node which does not recognize this type will skip over it 135 and continue processing the header. 137 C 0 The third highest-order bit are set to 0 to indicate this 138 option does not change en route. 140 Opt Data Len: 8-bit unsigned integer indicates the length of the 141 option Data field of this option, in octets. The value of Opt Data 142 Len of VTN option SHOULD be set to 4. 144 Option Data: 4-octet VTN which uniquely identifies a virtual 145 transport network. 147 Editor's note: The length of the VTN ID is defined as 4-octet 148 partially for the matching with the 4-octet network slice identifier 149 defined in 3GPP [TS23501]. 151 8-bit 24-bit 152 +------------+-------------------------+ 153 | SST | Slice Differentiator | 154 +------------+-------------------------+ 156 4. Procedures 158 4.1. VTN Option Insertion 160 The VTN option is inserted at the edge of the IPv6 network which 161 provides enhanced VPN service. On receipt of a data packet, the 162 ingress node determines the associated enhanced VPN based on traffic 163 classification or local policies, then it SHOULD insert the 164 corresponding VTN ID option into the IPv6 extension header of the 165 packet. If SRv6 is enabled, the VTN option SHOULD be included in the 166 outer IPv6 header which MAY optionally include the SRH [I-D.ietf- 167 6man-segment-routing-header]. 169 In order to make the VTN option be processed by each node along the 170 path, it is RECOMMENDED that the VTN option be carried in the Hop- 171 by-Hop option header of the IPv6 packet. 173 4.2. VTN based Packet Forwarding 175 On receipt of a packet with the VTN option, each network node which 176 can support the VTN option SHOULD use the VTN ID to identify the 177 virtual network the packet belongs to, and the set of local network 178 resources allocated the processing of the packet. This means the 179 forwarding behavior is based on both the destination IP address and 180 the VTN option. 182 There can be different implementations of allocating local network 183 resources to the VTNs. On each interface, the resources allocated to 184 a particular VTN can be considered as a virtual sub-interface with 185 dedicated bandwidth. In packet forwarding, the IPv6 destination 186 address of the received packet is used to identify the next-hop and 187 the outgoing interface, and the VTN ID is used to further identify 188 the virtual sub-interface which is associated with the VTN on the 189 outgoing interface. 191 Routers which do not support Hop-by-Hop options SHOULD ignore this 192 option and SHOULD forward the packet. Routers which support Hop-by- 193 Hop Options, but do not recognize the VTN option SHOULD ignore the 194 option and continue to forward the packet merely based on the 195 destination IP address. 197 5. Security Considerations 199 TBD 201 IANA Considerations 203 This document requests IANA to assign a new option type from 204 "Destination Options and Hop-by-Hop Options" registry. 206 Value Description Reference 207 ------------------------------------------------------------ 208 TBD Virtual Transport Network Identifier this document 210 Contributors 212 Zhibo Hu 213 Email: huzhibo@huawei.com 215 Juhua Xu 216 Email: xujuhua@huawei.com 218 Acknowledgments 220 The authors would like to thank XXX for the review and valuable 221 comments. 223 References 225 Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 229 RFC2119, March 1997, . 232 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 233 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 234 May 2017, . 236 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 237 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/ 238 RFC8200, July 2017, . 241 Informative References 243 I-D.ietf-teas-enhanced-vpn] Dong, J., Bryant, S., Li, Z., Miyasaka, 244 T., and Y. Lee, "A Framework for Enhanced Virtual Private 245 Networks (VPN+) Service", draft-ietf-teas-enhanced-vpn-04 246 (work in progress), January 2020. 248 [I-D.dong-teas-enhanced-vpn-vtn-scalability] Dong, J., Li, Z., Qin, 249 F., "Scalability Considerations of Enhanced VPN", 250 draft-dong-teas-enhanced-vpn-vtn-scalability-00 251 (work in progress), February 2020. 253 [I-D.ietf-6man-segment-routing-header] Filsfils, C., Dukes, D., 254 Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, 255 "IPv6 Segment Routing Header (SRH)", draft-ietf-6man- 256 segment-routing-header-26 (work in progress), October 2019. 258 [I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, 259 P., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 260 Network Programming", draft-ietf-spring-srv6-network- 261 programming-07 (work in progress), December 2019. 263 [TS23501] "3GPP TS23.501", 2019, 264 . 267 Authors' Addresses 269 Jie Dong 270 Huawei 272 Email: jie.dong@huawei.com 274 Zhenbin Li 275 Huawei 277 Email: lizhenbin@huawei.com