idnits 2.17.1 draft-dong-rtgwg-enhanced-vpn-protocol-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 (October 30, 2017) is 2370 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-detnet-architecture' is defined on line 443, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-bryant-rtgwg-enhanced-vpn-00 ** Downref: Normative reference to an Informational draft: draft-bryant-rtgwg-enhanced-vpn (ref. 'I-D.bryant-rtgwg-enhanced-vpn') == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-02 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 == Outdated reference: A later version (-09) exists of draft-ietf-teas-rsvp-te-scaling-rec-07 == Outdated reference: A later version (-03) exists of draft-sitaraman-mpls-rsvp-shared-labels-02 -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group J. Dong 3 Internet-Draft S. Bryant 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 3, 2018 October 30, 2017 7 Protocol Considerations for Enhanced VPN 8 draft-dong-rtgwg-enhanced-vpn-protocol-00 10 Abstract 12 This document describes the candidate protocol mechanisms which may 13 be used to meet the requirements of enhanced virtual private networks 14 (VPN+). The gaps and limitations of existing mechanisms are 15 analyzed, then a proposed mechanism is briefly described. The 16 proposed mechanism can be used to achieve network slicing to meet the 17 stringent requirement of emerging 5G services, but it can also be 18 useful in other general network scenarios. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 3, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. Role of the Underlay and Overlay . . . . . . . . . . . . . . 3 57 4. Considerations about Network Isolation . . . . . . . . . . . 3 58 4.1. Data Plane Isolation . . . . . . . . . . . . . . . . . . 4 59 4.2. Control Plane Isolation . . . . . . . . . . . . . . . . . 4 60 5. Analysis of Existing Mechanisms . . . . . . . . . . . . . . . 5 61 5.1. Overlay Virtual Networks . . . . . . . . . . . . . . . . 5 62 5.2. Multiple-Topology Routing and Segment Routing . . . . . . 6 63 6. Proposed Mechanism . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Per-link/Node Resource Partitioning . . . . . . . . . . . 7 65 6.2. Construction of Isolated Logical Networks . . . . . . . . 8 66 6.3. Mapping Service to Logical Network . . . . . . . . . . . 9 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 Virtual networks, often referred to as virtual private networks 77 (VPNs) have been widely deployed to provide different groups of users 78 with logically isolated access to a common network. The common 79 network that is used to provide the VPNs is often referred to as the 80 underlay, and the VPN is often called an overlay. 82 As described in [I-D.bryant-rtgwg-enhanced-vpn], the enhanced virtual 83 private networks (VPN+) refers to a virtual network which has 84 dedicated network resources allocated from the underlay network, so 85 that can achieve greater isolation and guaranteed performance than 86 traditional VPNs. VPN+ aims to provide a set of enhancements to 87 existing VPN services, among which greater isolation is one of the 88 key requirements of many emerging services, such as financial and 89 vertical industrial services. Apparently such level of isolation 90 cannot be met with pure overlay networks, as it requires tighter 91 coordination and integration between the overlay and the underlay 92 network, also it may rely on necessary enhancements to both the data 93 plane and control plane of networks. 95 This document describes the candidate protocol mechanisms to meet the 96 requirements of enhanced virtual private networks (VPN+), analyses 97 the limitations of some existing mechanisms, and proposes the 98 protocol mechanisms needed to provide VPN+ service. 100 2. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 [RFC2119]. 107 3. Role of the Underlay and Overlay 109 Basically the VPN based multi-tenant networks consist of two layers: 110 the overlay and the underlay, each layer plays a different role. The 111 underlay is responsible for establishing the network connectivity 112 based on the physical network infrastructure, also the management of 113 physical network resources. The overlay is used to setup various 114 customized virtual network topologies, and the logical network 115 separation between different tenants. 117 The overlay and the underlay can be loosely coupled, in which case 118 the overlay only requires the underlay to provide the connectivity 119 between specific service nodes, without the control of the underlay 120 path and resources, which means network resources in underlay can be 121 shared by all the overlay networks. This can be desirable when 122 scalability is the primary goal, as it minimizes the amount of state 123 in the network. 125 However, as many emerging services require guaranteed performance and 126 greater isolation from each other in the network, this loose-couple 127 mode can not meet such requirements. The overlay and underlay need 128 to be further integrated with each other. Normally this means more 129 states need to be maintained in the network, which may cause 130 scalability problem with some mechanisms. To overcome the 131 scalability problem, VPN+ requires an efficient mechanism for network 132 resource allocation and the mapping between the overlay and underlay 133 networks. 135 4. Considerations about Network Isolation 137 The requirement of enhanced VPN is described in 138 [I-D.bryant-rtgwg-enhanced-vpn], in which isolation is identified as 139 one of the most important requirement. When a network is used to 140 carry different types of services of multiple tenants, it is required 141 to provide some levels of isolation between different services or 142 different tenants. Based on different dimensions of isolation, 143 network isolation is categorized and described in following sections. 145 4.1. Data Plane Isolation 147 Isolation in data plane is the fundamental requirement of services 148 which are deployed as virtual private networks in a shared network 149 infrastructure. Depends on the level of data plane isolation, the 150 requirement is classified as soft isolation and hard isolation. 152 Soft isolation means that traffic of one application or tenant cannot 153 be received or inspected by any other application or tenant. Usually 154 soft isolation does not have strict resource or performance 155 requirement, the underlying network resource can be shared by 156 multiple applications or tenants, which is useful to achieve better 157 economy with statistical multiplexing. With soft isolation, when 158 service in one of the virtual networks experience some event such as 159 traffic burst or congestion, this may result in negative impacts to 160 other virtual networks in terms of bandwidth, latency, jitter, etc. 162 On the other hand, hard isolation means that any event happened to 163 the traffic in one virtual network will not interfere any other 164 application or tenant on the same network, which means the 165 characteristics of service can be more predictable. To achieve this, 166 at least some of the network resource need to be dedicated rather 167 than shared, which may reduce the economy due to statistical 168 multiplexing. Hard isolation is required by services that previously 169 have their own dedicated private networks and expect to have the same 170 network characteristics in a shared network. 172 4.2. Control Plane Isolation 174 There are many aspects in control plane, from router's perspective, 175 isolation in control plane can be achieved in different levels: 176 isolation of routing tables and isolation of routing protocols. 178 Isolation of routing tables is the preliminary requirement of multi- 179 tenancy, and can be achieved with many existing VPN mechanisms. It 180 usually can be done using a common control plane protocl such as BGP, 181 and the scalability has been proved by the wide deployment in the 182 field networks. 184 Isolation of routing protocols can provide further customization and 185 flexibility, as different tenants or applications can choose their 186 preferred protocols and provision it independently with customized 187 parameters. The cost of routing protocol isolation is that it 188 requires further complexity and more resource overhead, in some cases 189 the scalability of control protocol isolation can be challenging. 191 With the introduction of SDN, isolation of control plane can be 192 achieved by using separate controllers for different tenants or 193 applications. For example, each tenant can have his own controller 194 for network information allocation, path computation and service 195 provisioning. Note in this case, each tenant's controller can only 196 see information specific to this tenant, and has no access to 197 information of any other tenants. The tenant's controller may have 198 limited access to information and states of the network 199 infrastructure. 201 5. Analysis of Existing Mechanisms 203 This section analyses several existing mechanisms which are 204 considered as the candidate protocol mechanisms for VPN+, and 205 illustrates the gaps in meeting the requirements as described in 206 section 4. 208 5.1. Overlay Virtual Networks 210 In this document, the conventional VPNs (L3VPN, L2VPN, EVPN etc.) and 211 the overlay technologies developed in [NVO3] working group are 212 classified as overlay virtual networks. These mechanisms aim at 213 providing multi-tenant overlay connectivity using a unified control 214 plane. The underlay provides no resource of performance commitment 215 to the tenants of the overlays, thus the tenant only gets the best 216 effort provided to any traffic carried with the same traffic class in 217 the network. 219 According to operator's policy, the overlay connections of different 220 tenants can either share the same underlay tunnel, or use separate 221 dedicated tunnels to provide some degree of data plane isolation. If 222 there is a requirement to provide guaranteed network bandwidth from a 223 particular tenant, the approach is to establish a set of dedicated 224 RSVP-TE [RFC3205] LSPs to carry the traffic of this tenant. However, 225 such tunnels only provide bandwidth reservation for the tenant but no 226 other guarantees. The mechanisms under development in [DETNET] 227 working group may be needed for guaranteed low latency and packet 228 loss. 230 However, as the number of tenants requiring guaranteed performance 231 rises, so does the number of RSVP-TE LSPs, which ultimately leads to 232 scalability problems in the network. There are ongoing efforts to 233 improve the scalability of RSVP-TE LSPs both in control plane 234 [I-D.ietf-teas-rsvp-te-scaling-rec] and in data plane 235 [I-D.sitaraman-mpls-rsvp-shared-labels]. 237 5.2. Multiple-Topology Routing and Segment Routing 239 Multi-topology Routing (MTR) [RFC4915][RFC5120] has been designed to 240 provide multiple customized network topologies for different 241 services. When native IP forwarding is used as the data plane, there 242 is limitation in mapping the incoming packets of one interface to 243 different MTR topologies. The major use cases of multi-topology 244 routing is to provide different topologies for different address 245 families, e.g. IPv4 and IPv6 with different topologies, or use 246 particular topology for non-forwarding purpose, e.g. RPF check of 247 multicast. 249 Segment Routing (SR) [I-D.ietf-spring-segment-routing] leverages the 250 source routing paradigm and allows for flexible designation of 251 forwarding paths by encoding the paths as sequences of "segments" in 252 the data packet. In the IGP extensions for segment routing, multi- 253 topology has been taken into consideration, which may be used to 254 solve the forwarding plane issues of multi-topology, although it is 255 not specified in what scenarios segment routing and multi-topology 256 routing need to be used together. 258 Although MTR can create multiple customized topologies in the 259 network, it was not designed for resource reservation and isolation 260 between different topologies. When some nodes or links belongs to 261 multiple topologies, network resources on these nodes and links are 262 shared by all those topologies. Thus it is not possible to provide 263 tenants with isolation and guaranteed performance based on multi- 264 topology routing. 266 It is well accepted that segment routing can provide traffic 267 engineering (TE) with better scalability than RSVP-TE, however all 268 that current SR can do is to create a set of non-shortest paths in 269 the network, with network resource planning executed in the 270 controller. Different service traffic can be mapped to different 271 paths to achieve some service differentiation. Currently SR does not 272 provide any mechanism for resource reservation and isolation in the 273 network data plane, thus all network resources are shared by the 274 services carried by the same set of links and nodes. 276 6. Proposed Mechanism 278 This section describes the proposed mechanisms to meet the isolation 279 requirements of VPN+. 281 The overall solution is segment routing based, with necessary 282 extensions to create multiple isolated logical networks using a 283 common network infrastructure. Each logical network can have its own 284 customized topology and guaranteed network resources. Hard isolation 285 can be achieved between different logical networks, so that services 286 in different logical networks will not interfere with each other. 288 Segment Routing uses different types of Segment Identifiers (SIDs) to 289 build the SR path, in which the adjacency SID and the node SID are 290 the basic building blocks. Taking advantage of the SR architecture, 291 with some proper extensions, each logical network can be constructed 292 with a dedicated set of SIDs, each of which represents a subset of 293 resource reserved on a specific link or node. Based on the SIDs with 294 resource reservation, isolation between different logical networks 295 can be achieved. Compared to the resource reservation using RSVP-TE, 296 which is per end-to-end path based reservation, the SR based resource 297 reservation is per-hop per-virtual- network based, which could 298 significantly reduce the amount of states introduced to the network, 299 thus can avoid the scalability problem of RSVP-TE. 301 6.1. Per-link/Node Resource Partitioning 303 To achieve resource reservation with SR, resources of the links and 304 nodes needs to be partitioned into isolated pieces, so that different 305 pieces of the node and link resources can be allocated to different 306 logical networks independently. Normally a network controller is 307 responsible for the collection of network resource information, and 308 the computation of the subset of network resources needed on each 309 node or link for a particular virtual network based on tenant's 310 service requirement. The controller may also be used to trigger the 311 allocation of network resources on the network equipments using some 312 appropriate protocol. 314 Some enhancement in the data plane may be needed to meet the 315 requirement of hard resource isolation. For example, FlexE [FLEXE] 316 can provide time slot based link channelization, which could be used 317 as one mechanism for link resource partitioning and reservation. 318 Also there are efforts for resource partitioning inside the routing 319 nodes. The mechanisms of link and node resource partitioning can be 320 implementation specific, which are outside the scope of this 321 document. While the capability and information about link and node 322 resource partitioning needs to be advertised using some control 323 protocol, so that different partitions of link and node resources can 324 be used to set up different isolated networks. 326 When a link is partitioned into several pieces, information about 327 each piece of the link needs to be advertised, so that there is no 328 ambiguity about which particular piece of the link resource is 329 allocated for which particular logical network. Using segment 330 routing paradigm, each link partition needs to be assigned with a 331 dedicated adj-SID. In order to ensure that a particular link 332 partition would only be used for the path computation and data 333 forwarding of a particular logical network, each link partition needs 334 to be associated with the unique identifier of the logical network. 336 [I-D.ietf-isis-l2bundles] specifies a mechanism to advertise the link 337 attributes of the member links of a link bundle. Such mechanism can 338 be reused for the link partitioning case described in this document, 339 while some further extensions are needed to advertise the mapping 340 between the link attributes and the Logical Network Identifiers (LN- 341 ID). 343 Similarly, for node resource partitioning, different node-SIDs can be 344 assigned for each partition of node resource. Different Node-SIDs 345 are also needed for loose path forwarding of SR, service of different 346 logical networks uses different node-SIDs of the same node to 347 identify the logical networks it belongs to, so that the node could 348 steer different service inside their own logical networks using the 349 dedicated resource reserved for the logical network. In this way, 350 network isolation can also be achieved with SR loose path forwarding. 352 6.2. Construction of Isolated Logical Networks 354 With the mechanism described in section 6.1, each link or node 355 partition can be identified with a (SID, LN-ID) tuple, which 356 associate the SID and the resource it represents with a particular 357 logical network. Such information needs to be distributed both in 358 the network and to the network controller using protocol extensions 359 of IGP and BGP-LS, so that every node in the network and the 360 controller obtain the same link-state information of different 361 logical networks, so as to create the logical network topology using 362 the subset of the adj-SIDs and node-SIDs which associate with the 363 same LN-ID. From network resource perspective, each logical network 364 is constructed with the cluster of reserved network resources the 365 SIDs point to, and different logical networks are isolated from each 366 other. The SR path computation of each logical network SHOULD be 367 constrained to only use the SIDs belong to the logical network. 369 When service traffic is carried in a particular logical network, the 370 data packet is encapsulated with a sequence of Adj-SIDs and Node-SIDs 371 dedicated to this logical network, so that in forwarding plane the 372 packet will be steered through the link and node resources allocated 373 for those SIDs. Service of different logical networks always use 374 different SIDs when traversing the same physical links or nodes. 375 This ensures that service always use the network resources allocated 376 for its logical network. 378 6.3. Mapping Service to Logical Network 380 Mapping of service to logical networks can be quite flexible. 381 According to the different isolation requirements, one tenant who 382 requires hard isolation can be mapped to a dedicated logical network, 383 so that the network resource of the logical network are dedicated to 384 this tenant. If this tenant have multiple services, the resources 385 can be shared by all the services of this tenant, but the service 386 performance will never be impacted by service of other tenants. Some 387 service may require stringent performance in terms of bounded latency 388 and packet loss, then mechanisms of [DETNET] may be applied to this 389 service. 391 For tenants who only expect soft isolation and resource sharing or 392 competing is allowed between these tenants, these tenants can be 393 mapped to the same logical network for better economy and 394 scalability. Service traffic of tenants which mapped to the same 395 logical network may compete for some shared resources, but they will 396 never impact another tenant who owns a separate logical network. 397 According to the customized requirements, different group of tenants 398 can be mapped to different logical networks. 400 7. Security Considerations 402 The security concerns about segment routing 403 [I-D.ietf-spring-segment-routing] applies here. 405 8. IANA Considerations 407 There are no requested IANA actions. 409 9. References 411 9.1. Normative References 413 [I-D.bryant-rtgwg-enhanced-vpn] 414 Bryant, S. and J. Dong, "Enhanced Virtual Private Networks 415 (VPN+)", draft-bryant-rtgwg-enhanced-vpn-00 (work in 416 progress), July 2017. 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 424 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 425 RFC 4915, DOI 10.17487/RFC4915, June 2007, 426 . 428 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 429 Topology (MT) Routing in Intermediate System to 430 Intermediate Systems (IS-ISs)", RFC 5120, 431 DOI 10.17487/RFC5120, February 2008, 432 . 434 9.2. Informative References 436 [DETNET] "IETF Detnet Working Group", 2017, 437 . 439 [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, 440 . 443 [I-D.ietf-detnet-architecture] 444 Finn, N., Thubert, P., Varga, B., and J. Farkas, 445 "Deterministic Networking Architecture", draft-ietf- 446 detnet-architecture-02 (work in progress), June 2017. 448 [I-D.ietf-isis-l2bundles] 449 Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and 450 E. Aries, "Advertising L2 Bundle Member Link Attributes in 451 IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), 452 May 2017. 454 [I-D.ietf-spring-segment-routing] 455 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 456 and R. Shakir, "Segment Routing Architecture", draft-ietf- 457 spring-segment-routing-12 (work in progress), June 2017. 459 [I-D.ietf-teas-rsvp-te-scaling-rec] 460 Beeram, V., Minei, I., Shakir, R., Pacella, D., and T. 461 Saad, "Techniques to Improve the Scalability of RSVP 462 Traffic Engineering Deployments", draft-ietf-teas-rsvp-te- 463 scaling-rec-07 (work in progress), September 2017. 465 [I-D.sitaraman-mpls-rsvp-shared-labels] 466 Sitaraman, H., Beeram, V., Parikh, T., and T. Saad, 467 "Signaling RSVP-TE tunnels on a shared MPLS forwarding 468 plane", draft-sitaraman-mpls-rsvp-shared-labels-02 (work 469 in progress), September 2017. 471 [NVO3] "IETF NVO3 Working Group", 2017, 472 . 474 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 475 RFC 3205, DOI 10.17487/RFC3205, February 2002, 476 . 478 Authors' Addresses 480 Jie Dong 481 Huawei Technologies 483 Email: jie.dong@huawei.com 485 Stewart Bryant 486 Huawei Technologies 488 Email: stewart.bryant@gmail.com