idnits 2.17.1 draft-dong-spring-sr-for-enhanced-vpn-04.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 (July 1, 2019) is 1761 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 705, but no explicit reference was found in the text == Unused Reference: 'RFC6790' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 810, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-00 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-01 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft S. Bryant 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 2, 2020 T. Miyasaka 6 KDDI Corporation 7 Y. Zhu 8 China Telecom 9 F. Qin 10 Z. Li 11 China Mobile 12 July 1, 2019 14 Segment Routing for Enhanced VPN Service 15 draft-dong-spring-sr-for-enhanced-vpn-04 17 Abstract 19 Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it 20 to support the needs of new applications, particularly applications 21 that are associated with 5G services. These applications require 22 better isolation from both control and data plane's perspective and 23 have more stringent performance requirements than can be provided 24 with overlay VPNs. The characteristics of an enhanced VPN as 25 perceived by its tenant needs to be comparable to those of a 26 dedicated private network. This requires tight integration between 27 the overlay VPN and the underlay network topology and resources in a 28 scalable manner. An enhanced VPN may form the underpinning of 5G 29 network slicing, but will also be of use in its own right. This 30 document describes the use of segment routing based mechanisms to 31 provide the enhanced VPN service with required network topology and 32 resources. The overall mechanism of using segment routing to provide 33 enhanced VPN service is also described. The proposed mechanism is 34 applicable to both SR with MPLS data plane and SR with IPv6 data 35 plane (SRv6). 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 2, 2020. 54 Copyright Notice 56 Copyright (c) 2019 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 73 3. Segment Routing with Topology and Resource Awareness . . . . 4 74 3.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 77 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 5.1. Virtual Network Topology and Resource Computation . . . . 8 79 5.2. Network Resource and SID Allocation . . . . . . . . . . . 9 80 5.3. Construction of SR Virtual Networks . . . . . . . . . . . 11 81 5.4. VPN Service to SR Virtual Network Mapping . . . . . . . . 12 82 5.5. Virtual Network Visibility to Customer . . . . . . . . . 13 83 6. Benefits of the Proposed Mechanism . . . . . . . . . . . . . 13 84 7. Service Assurance . . . . . . . . . . . . . . . . . . . . . . 14 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 91 12.2. Informative References . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 Driven largely by needs arising from the 5G mobile network design, 97 the concept of network slicing has gained traction [NGMN-NS-Concept] 98 [TS23501][TS28530] [BBF-SD406]. Network slicing requires to 99 partition the physical network to several pieces to provide each 100 network slice with the required networking, computing, and storage 101 resources and functions drawn from a shared pool. Each network slice 102 can be seen as (and operated as) an independent virtual network. 104 For transport network, there is a need to create virtual networks 105 with enhanced characteristics. Such a virtual network can provide a 106 customized network topology, and a degree of isolation and 107 performance guarantee that previously could only be satisfied by 108 dedicated networks. Additionally, a network slice tenant may ask for 109 some level of control to their virtual network e.g. to customize the 110 service paths in the network slice. 112 The enhanced VPN service (VPN+) as described in 113 [I-D.ietf-teas-enhanced-vpn] is targeted at new applications which 114 require better isolation from both control plane and data plane's 115 perspective, and have more stringent performance requirements than 116 can be provided with existing overlay VPNs. An enhanced VPN may form 117 the underpinning of network slicing, but will also be of use in its 118 own right. 120 Although a VPN can be associated with a set of dedicated RSVP-TE 121 [RFC3209] LSPs with bandwidth reservation to provide some level of 122 guarantee to service performance, such mechanisms would introduce 123 per-VPN per-path states in the network, which is known to have 124 scalability issues [RFC5439] and has not been widely adopted in 125 production networks. 127 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 128 through an ordered list of segments. It can achieve explicit source 129 routing without introducing per-path state into the network. 130 Compared with RSVP-TE, currently SR does not have the capability of 131 reserving or identifying a particular set of network resources for 132 paricular services or customers. Although a centralized controller 133 can have a global view of network state and can provision different 134 services onto different SR paths, in data plane it still relies on 135 traditional DiffServ QoS mechanism [RFC2474] [RFC2475] to provide 136 coarse-grained traffic differentiation in the network. While such 137 kind of mechanism may be sufficient for some types of services, it 138 cannot meet the stringent requirement of some enhanced VPN services. 140 This document extends the SR paradigm by introducing additional 141 Segment Identifiers (SIDs) to represent different virtual network 142 topologies and a corresponding set of network resources allocated on 143 network segments. A group of SR SIDs can be used to specify the 144 customized topology of an enhanced VPN, and can be used to steer the 145 service traffic to be processed with the corresponding set of network 146 resources. The overall mechanism of using segment routing to provide 147 enhanced VPN is described. The proposed mechanism is applicable to 148 both SR with MPLS data plane (SR-MPLS) and SR with IPv6 data plane 149 (SRv6). 151 2. Requirements Notation 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in BCP 156 14 RFC 2119 [RFC2119] RFC8174 [RFC8174][when, and only when, they 157 appear in all capitals, as shown here. 159 3. Segment Routing with Topology and Resource Awareness 161 In order to support enhanced VPN service, the overlay VPNs need to be 162 integrated with the underlay network in terms of network topology and 163 resources. More specifically, enhanced VPNs need to be mapped to 164 different virtual topologies to provide customized connectivity, and 165 different set of network resources may be allocated to different 166 enhanced VPNs, or different groups of enhanced VPNs, to meet the 167 diverse performance requirement. When segment routing is used to 168 enable enhanced VPNs, it is necessary that the SR service paths can 169 be associated with a particular virtual network topology, and a 170 particular set of network resources. 172 In segment routing, several types of segments have been defined to 173 represent topological or service instructions. A topological segment 174 may be a node segment or an adjacency segment. A service segment may 175 be associated with specific service function for service chaining 176 purpose. This document introduces SR segments which can be 177 associated with particular network topology and particular set of 178 network resources. 180 This section describes the mechanisms to identify the associated 181 virtual network topology and resource information with the two SR 182 data plane instantiations: SR-MPLS and SRv6. 184 3.1. SR-MPLS 186 In SR-MPLS [I-D.ietf-spring-segment-routing-mpls], IGP Adjacency 187 Segment (Adj-SID) is an IGP-segment attached to a unidirectional 188 adjacency or a set of unidirectional adjacencies. IGP Node segment 189 is an IGP-Prefix segment that identifies a specific router (e.g., a 190 loopback). In [I-D.ietf-idr-bgpls-segment-routing-epe], PeerAdj SID 191 is used as instruction to steer over a specific local interface 192 towards a specific peer node in a peering Autonomous System (AS). 193 These types of SIDs can be extended to represent both topological 194 elements and the resources allocated on a particular network element. 196 For one particular IGP link, multiple Adj-SIDs SHOULD be allocated, 197 each of which is associated with a paritcular virtual network 198 topology, and MAY represent a subset of link resources. Several 199 approaches can be used to partition the link resource, such as 200 logical sub-interfaces, dedicated queues, etc. The detailed 201 mechanism of resource partitioning is out of scope of this document. 202 Similarly, for one particular IGP node, multiple node-SIDs SHOULD be 203 allocated, each of which is associated with a paritcular virtual 204 network topology, and may represent a subset of the node resource 205 (e.g. the processing resources). For one particular inter-domain 206 link, multiple BGP PeerAdj SIDs 207 [I-D.ietf-idr-bgpls-segment-routing-epe] can be allocated, each of 208 which is associated with a paritcular virtual network topology which 209 spans multiple domains, and may represent a subset of link resource 210 on the inter-domain link. Note that this per-segment resource 211 allocation complies to the SR paradigm, which avoids introducing per- 212 path state into the network. 214 A group of adj-SIDs and node-SIDs associated with the same virtual 215 network can be used to construct the SR SID-lists (either strict or 216 loose) for the service packet forwarding of a particular enhanced 217 VPN. This group of SIDs MAY also represent the set of network 218 resources which are reserved for a particular enhanced VPN, or a 219 group of enhanced VPNs. 221 In data packet forwarding, the adj-SID and node-SID are used to 222 identify the virtual network the packet belongs to, so that a virtual 223 network specific next-hop can be determined. The adj-SIDs MAY also 224 be used to steer traffic of different enhanced VPNs into different 225 set of link resources. The node SIDs MAY also be used to steer 226 traffic of different enhanced VPNs into different set of node 227 resources. When a node-SID is used in the SID-list to build an SR 228 loose path, the transit nodes use the node SID to identify the 229 virtual network, and MAY process the packet using the local resources 230 allocated for the corresponding virtual network. Note in this case, 231 Penultimate Hop Popping (PHP) [RFC3031] MUST be disabled. 233 This mechanism requires to allocate additional node-SIDs and adj-SIDs 234 for each virtual network (network slice). As the number of virtual 235 networks increases, the number of SIDs would increase accordingly. 236 It is expected that this mechanism is applicable to a network with a 237 limited number of network slices. 239 3.2. SRv6 241 As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6 242 Segment (SID) is a 128-bit value which consists of a locator (LOC) 243 and a function (FUNCT), optionally it may also contain additional 244 arguments (ARG) immediately after the FUNCT. The LOC of the SID is 245 routable and leads to the node which instantiates that SID, which 246 means the LOC can be parsed by all nodes in the network. The FUNCT 247 part of the SID is an opaque identification of a local function bound 248 to the SID, which means the FUNCT and ARG parts can only be parsed by 249 the node which instantiates that SID. 251 In order to support multiple virtual networks in a SRv6 network, all 252 the nodes (including the edge nodes and transit nodes) belonging to 253 one particular virtual network MUST have a consistent view of the 254 virtual network and performs consistent forwarding behavior to comply 255 to the network topology and resource constraints. A node which 256 participates in multiple virtual networks MUST be able to distinguish 257 packets which belong to different virtual networks. 259 Taking the above into consideration, for a particular network node, 260 multiple SRv6 LOCs SHOULD be allocated, each of which is associated 261 with a paritcular virtual network topology, and MAY represent a 262 subset of the network resources associated with the virtual network. 263 The SRv6 SIDs of a particular virtual network SHOULD be allocated 264 from the SID space using the virtual network specific LOC as prefix. 265 These SRv6 SIDs can be used to represent virtual network specific 266 local functions. 268 A group of SRv6 SIDs associated with the same virtual network can be 269 used to construct the SR SID-lists (either strict or loose) for the 270 service packet forwarding of a particular enhanced VPN. This group 271 of SIDs MAY also represent the set of network resources which are 272 reserved for a particular enhanced VPN, or a group of enhanced VPNs. 274 In data packet forwarding, the LOC part of SRv6 SID is used by 275 transit nodes to identify the virtual network the packet belongs to, 276 so that a virtual network specific next-hop can be determined. The 277 LOC MAY also be used to indicate the set of local network resources 278 on the transit nodes to be used for the forwarding of the received 279 packet. The SRv6 segment endpoint nodes use the local SRv6 SID to 280 identify the virtual network the packet belongs to, and the 281 particular local function to peform on the received packet. The 282 local SRv6 SID MAY also be used to identify the set of network 283 resource to be used for executing the local function. 285 This mechanism requires to allocate additional SRv6 Locators and SIDs 286 for each virtual network (network slice). As the number of virtual 287 networks increases, the number of Locators and SIDs would increase 288 accordingly. It is expected that this mechanism is applicable to a 289 network with a limited number of network slices. 291 4. Control Plane 293 The mechanism described in this document makes use of a centralized 294 controller that collects the information about the network 295 (configuration, state, routing databases, etc.) as well as the 296 service information (traffic matrix, performance statistics, etc.). 297 The controller is also responsible for the centralized computation 298 and optimization of the virtual networks used for enhanced VPNs. The 299 SR SIDs can be either explicitly provisioned by the controller, or 300 dynamically allocated by network nodes then reported to the 301 controller. The interaction between the controller and the network 302 nodes can be based on PCEP [RFC5440], Netconf/YANG [RFC6241] 303 [RFC7950] and BGP-LS [RFC7752]. In some scenarios, extensions to 304 some of these protocols is needed , which are out of the scope of 305 this document and will be specified in separate documents. 307 A distributed control plane can be used for the collection and 308 distribution of the network topology and state information of the 309 virtual networks among network nodes. Distributed route computation 310 for services of a particular enhanced VPN is also needed. The IGP 311 extensions for SR based enhanced VPN are specified in 312 [I-D.dong-lsr-sr-enhanced-vpn]. 314 5. Procedures 316 This section describes the procedures of provisioning enhanced VPN 317 service based on segment routing with resource awareness. 319 According to the requirement of an enhanced VPN service, a 320 centralized network controller calculates a subset of the physical 321 network topology to support the enhanced VPN. Within this topology, 322 the subset of network resources needed on each network element is 323 also determined. The subset of network topology and the subset of 324 network resources together constitute a virtual network (network 325 slice). Depending on the service requirement, the network topology 326 and resource can be dedicated for a particular enhanced VPN, or they 327 can be shared among multiple enhanced VPNs. 329 Following the segment routing paradigm, the network topology and 330 resource are represented in a per-segment manner, and are allocated 331 with different node-SIDs and adj-SIDs. A group of the node-SIDs and 332 adj-SIDs allocated for a paritcular virtual network will be used by 333 network nodes and the network controller to build a SR virtual 334 network topology, which is used as the logical underlay of the 335 enhanced VPN service. The extensions to IGP protocol to distribute 336 the SIDs and the associated resources allocated for a virtual network 337 are specified in [I-D.dong-lsr-sr-enhanced-vpn]. 339 Suppose customer A requests for an enhanced VPN service from the 340 network operator. The fundamental requirement is that service of 341 customer A does not experience unexpected interference from other 342 services in the same network, such as other customers' VPN services, 343 or the non-VPN services in the network. The detailed requirements 344 can be described with characteristics such as the following: 346 o Service topology: the service sites and the connectivity between 347 them. 349 o Service bandwidth: the bandwidth requirement between service 350 sites. 352 o Isolation: the level of isolation from other services in the 353 network. 355 o Reliability: whether fast local repair or end-to-end protection is 356 needed or not. 358 o Latency: the maximum latency for specific service between specific 359 service sites. 361 o Visibility: the customer may want to have some form of visibility 362 of the virtual network delivering the service. 364 5.1. Virtual Network Topology and Resource Computation 366 As described in section 4, a centralized network controller is 367 responsible for the computation of a virtual network for the 368 provisioning of enhanced VPNs. The controller collects the 369 information of network connectivity, network resources, network 370 performance and other relevant network states of the underlay 371 network. This can be done using either IGP [RFC5305] [RFC3630] 372 [RFC7471] [RFC7810] or BGP-LS [RFC7752] [RFC8571]. 374 Based on the information collected from the underlay network, 375 controller obtains the underlay network topology and the information 376 about the allocated and available network resources. When an 377 enhanced VPN service request is received from a tenant, the 378 controller computes the subset of the network topology, along with 379 set of the resources needed on each network element (e.g. links and 380 nodes) of the topology to meet the tenant's service requirements, 381 whilst maintaining the needs of the existing tenants that are using 382 the same network. The subset of network topology and resource 383 constitute a virtual network, which will be used as the underlay of 384 the requested enhanced VPN. 386 5.2. Network Resource and SID Allocation 388 According to the result of virtual network computation, network 389 controller instructs the network devices involved in the virtual 390 network to allocate the required network resources for the enhanced 391 VPN. This can be done with either PCEP [RFC5440] or Netconf/YANG 392 [RFC6241] [RFC7950] with necessary extensions. The network resources 393 are allocated in a per-segment manner. In addition, a set of 394 dedicated SIDs, e.g. node-SIDs and adj-SIDs are allocated to 395 identify the virtual network and the network resources allocated on 396 each network segment for the virtual network. 398 In forwarding plane, there are multiple ways of partitioning or 399 reserving network resources for different virtual networks. For 400 example, FlexE may be used to partition the link resource into 401 different sub-channels to achieve hard isolation between each other. 402 The candidate data plane technologies to support enhanced VPN can be 403 found in [I-D.ietf-teas-enhanced-vpn]. The SR SIDs are used as a 404 nework layer abstraction for various network resource partitioning or 405 reservation mechanisms in forwarding plane. 407 Node-SIDs: Node-SIDs: 408 r:101 r:102 409 g:201 Adj-SIDs: g:202 410 b:301 r:1001:1G r:1001:1G b:302 411 +-----+ g:2001:2G g:2001:2G +-----+ 412 | A | b:3001:1G b:3001:1G | B |Adj-SIDs: 413 | +------------------------+ + r:1003:1G 414 Adj-SIDs +--+--+ +--+--+\g:2003:2G 415 r:1002:1G| r:1002:1G| \ 416 g:2002:2G| g:2002:2G| \ r:1001:1G 417 b:3002:3G| b:3002:2G| \g:2001:2G 418 | | \ +-----+ Node-SIDs: 419 | | \+ E | r:105 420 | | /+ | g:205 421 r:1001:1G| r:1002:1G| / +-----+ 422 g:2001:2G| g:2002:2G| /r:1002:1G 423 b:3001:3G| b:3002:2G| / g:2002:2G 424 +--+--+ +--+--+ / 425 | | | |/r:1003:1G 426 | C +------------------------+ D + g:2003:2G 427 +-----+ r:1002:1G r:1001:1G +-----+ 428 Node-SIDs: g:2002:1G g:2001:1G Node-SIDs: 429 r:103 b:3002:2G b:3001:2G r:104 430 g:203 g:204 431 b:303 b:304 433 Figure 1. SIDs allocated to different virtual networks 435 Figure 1 shows a SR network to support enhanced VPN. Note that the 436 format of the SIDs in this figure are for illustration, both SR-MPLS 437 and SRv6 can be used as the data plane. In this example, three 438 virtual networks: red (r) , green (g) and blue (b) are created for 439 different enhanced VPNs. Both the red and green virtual networks 440 consist of nodes A, B, C, D, and E with all their interconnecting 441 links, whilst the blue virtual network only consists of nodes A, B, C 442 and D with all their interconnecting links. Note that different 443 virtual networks may have a set of shared nodes and links. On each 444 link, a dedicated Adj-SID is allocated for each virtual network it 445 participates in. Similarly, on each node, a dedicated Node-SID is 446 allocated for each virtual network it participates in. The Adj-SIDs 447 can be associated with different set of link resources (e.g. 448 bandwidth) allocated to different virtual networks, so that the Adj- 449 SIDs can be used to steer service traffic into different set of link 450 resources in the forwarding plane. The Node-SIDs can be associated 451 with the nodal resources allocated to different virtual network. In 452 addition, the Node-SIDs can be used to build loose SR path within 453 each virtual network, in this case it can be used by the transit 454 nodes to steer different service traffic into different set of local 455 network resources in the forwarding plane. 457 In Figure 1, the notation x:nnnn:y means that in virtual network x, 458 the adj-SID nnnn will steer the packet over a link which has 459 bandwidth y reserved for that virtual network. Thus the note 460 r:1002:1G in link C->D says that the red virtual network has a 461 reserved bandwidth of 1Gb/s on link C->D, and will be used by packets 462 arriving at node C with an adj-SID 1002 at the top of the label 463 stack. 465 5.3. Construction of SR Virtual Networks 467 To make both the network controller and network nodes aware of the 468 information of the virtual networks created in the network, each 469 network node MUST advertise the virtual networks it participates, 470 together with the set of SIDs and allocated resources into the 471 network and then distributed to the controller. This can be achieve 472 by means such as IGP extensions [I-D.dong-lsr-sr-enhanced-vpn], BGP- 473 LS [RFC7752] with necessary extensions, NETCONF/YANG [RFC6241] 474 [RFC7950]. 476 Based on the collected information of network topology, network 477 resource and SIDs information, both the controller and network nodes 478 are able to construct the SR virtual network and generate the 479 forwarding entries of each virtual network based on the node-SIDs and 480 adj-SIDs allocated for each virtual network. Unlike classic segment 481 routing in which network resources are always shared by all the 482 services and tenants, different SR virtual networks can be associated 483 with different set of resource allocated in the underlay network, so 484 that they can be used to meet the service requirement of enhanced 485 VPNs and provide the required isolation from other services in the 486 same network. 488 Figure 2 shows the SR virtual networks created from the underlay 489 network in Figure 1. 491 1001 1001 2001 2001 3001 3001 492 101---------102 201---------202 301---------302 493 | | \1003 | | \2003 | | 494 1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002| 495 | | 105 | | 205 | | 496 1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002| 497 | | / 1003 | | / 2003 | | 498 103---------104 203---------204 303---------304 499 1002 1001 1002 2001 3002 3001 500 Topology Red Topology Green Topology Blue 502 Figure 2. SR virtual networks using different groups of SIDs 504 In each SR virtual network, SR path is computed within the virtual 505 network taking its network topology and resource as constraints. The 506 SR path can be an explicit path instantiated using SR policy 507 [I-D.ietf-spring-segment-routing-policy], in which the segment-list 508 is built with the SIDs allocated to the virtual network. The service 509 path can also be an IGP computed path associated with a particular 510 node-SIDs of the virtual network. Different service paths in the 511 same virtual network would share the network resources allocated to 512 that virtual network. 514 For example, to create an explicit path A-B-D-E in the virtual 515 network red in Figure 2, the SR segment list encapsulated in the 516 service packet would be (1001, 1002, 1003). For the same explicit 517 path A-B-D-E in virtual network green, the SR segment list would be 518 (2001, 2002, 2003). In the case where we wish to construct a loose 519 path A-D-E in virtual network green, the service packet SHOULD be 520 encapsulated with the SR segment list (201, 204, 205). At node A, 521 the packet can be sent towards D via either node B or C using the 522 link and node resources allocated for virtual network green. At node 523 D the packet is forwarded to E using the link and node resource 524 allocated for virtual network green. Similarly, a packet to sent via 525 loose path A-D-E in virtual network red would be encapsulated with 526 segment list (101, 104, 105). In the case where an IGP computed path 527 is good enough, the packet can be simply encapsulated with the node 528 SID of egress node E in the corresponding virtual network. 530 5.4. VPN Service to SR Virtual Network Mapping 532 The enhanced VPN services can be provisioned using the customized SR 533 virtual networks as the underlay network. Different enhanced VPNs 534 can be provisioned in different SR virtual networks, each of which 535 would use the network resources allocated to a particular virtual 536 network, so that they will not interfere with each other. In another 537 case, a set of enhanced VPNs can be provisioned in the same SR 538 virtual network, in this case the network resources allocated to the 539 virtual network are shared by this set of enhanced VPNs, but will not 540 be shared with other services in the network. 542 5.5. Virtual Network Visibility to Customer 544 The tenants of enhanced VPNs may request different granularity of 545 visibility to the network which deliver the service. Depending on 546 the requirement, the network can be exposed to the tenant either as a 547 virtual network, or a set of computed paths with transit nodes, or 548 simply the abstract connectivity between endpoints without any path 549 information. The visibility can be delivered through different 550 possible mechanisms, such as IGPs (e.g. IS-IS, OSPF) or BGP-LS. In 551 addition, the network operator may want to restrict the visibility of 552 the information it delivers to the tenant by either hiding the 553 transit nodes between sites (and only delivering the endpoints 554 connectivity) or by hiding portions of the transit nodes (summarizing 555 the path into fewer nodes). Mechanisms such as BGP-LS allow the 556 flexibility of the advertisement of aggregated virtual network 557 information. 559 6. Benefits of the Proposed Mechanism 561 The proposed mechanism provides several key characteristics: 563 o Flexibility: Multiple customized virtual networks can be created 564 in a shared network to meet different customer's connectivity and 565 service requirement. Each customer is only aware of the topology 566 and attributes of a particular virtual network, and provision 567 services on the virtual network instead of the physical network. 568 This provides an efficient mechanism to support network slicing. 570 o Isolation: Each virtual network can have independent SR path 571 instantiation and computation. In addition, a virtual network can 572 be associated with a set of network resources, which can avoid 573 resource competition and performance interference from other 574 services in the network. The proposed mechanism also allows 575 resource sharing between different services in the same enhanced 576 VPN, or between a set of enhanced VPNs which are provisioned in 577 the same virtual network. This gives the operator and the 578 enhanced VPN customer flexibility in network planning and service 579 provisioning. The performance of critical services in a 580 particular enhanced VPN can be further ensured using the 581 mechanisms defined in [DetNet]. 583 o Scalability: The proposed mechanism seeks to achieve a compromise 584 between the state limitations of traditional end-to-end TE 585 mechanism and the lack of resource awareness in basic segment 586 routing. Following the segment routing paradigm, network 587 resources are allocated to network segments of the virtual 588 networks, there is no per-flow state introduced in the network. 589 Operator can choose the granularity of resource allocation to 590 network segments. In network segments where resource is scarce 591 such that the service requirement may not always be met, the SR 592 approach can be used to allocate specific resources to the segment 593 in a particular virtual network. By contrast, in other segment of 594 the network where resource is considered plentiful, the resource 595 may be shared between a number of virtual networks. The decision 596 to do this is in the hands of the operator. Because of the 597 segmented nature of the virtual network, resource aggregation is 598 easier and more flexible than RSVP-TE based approach. 600 7. Service Assurance 602 In order to provide service assurance for enhanced VPNs, it is 603 necessary to instrument the network at multiple levels. The network 604 operator needs to ascertain that the underlay is operating correctly. 605 A tenant needs to ascertain that their services are operating 606 correctly. In principle these can use existing techniques. These 607 are well known problems and solutions either exist or are in 608 development to address them. 610 New work is needed to instrument the virtual networks that are 611 created for the enhanced VPNs. Such instrumentation needs to operate 612 without causing disruption to other services using the network. 613 Given the sensitivity of some applications, care needs to be taken to 614 ensure that the instrumentation itself does not cause disruption 615 either to the service being instrumented or to other services. In 616 case of failure or performance degradation of a service path in a 617 particular virtual network, it is necessary that either local 618 protection or end-to-end protection mechanism is used to switch to 619 another path which could meet the service performance requirement and 620 does not impact other services in the network. 622 8. IANA Considerations 624 This document makes no request of IANA. 626 Note to RFC Editor: this section may be removed on publication as an 627 RFC. 629 9. Security Considerations 631 The normal security considerations of VPNs are applicable and it is 632 assumed that industry best practise is applied to an enhanced VPN. 634 The security considerations of segment routing are applicable and it 635 is assumed that these are applied to an enhanced VPN that uses SR 636 based virtual networks. 638 Some applications of enhanced VPNs are sensitive to packet latency; 639 the enhanced VPNs provisioned to carry their traffic have latency 640 SLAs. By disrupting the latency of such traffic an attack can be 641 directly targeted at the customer application, or can be targeted at 642 the network operator by causing them to violate their SLA, triggering 643 commercial consequences. Dynamic attacks of this sort are not 644 something that networks have traditionally guarded against, and 645 networking techniques need to be developed to defend against this 646 type of attack. By rigorously policing ingress traffic and carefully 647 provisioning the resources provided to critical services this type of 648 attack can be prevented. However case needs to be taken when 649 providing shared resources, and when the network needs to be 650 reconfigured as part of ongoing maintenance or in response to a 651 failure. 653 The details of the underlay MUST NOT be exposed to third parties, to 654 prevent attacks aimed at exploiting a shared resource. 656 10. Contributors 658 The following people contributed to the content of this document. 660 11. Acknowledgements 662 The authors would like to thank Mach Chen, Zhenbin Li, Stefano 663 Previdi, Charlie Perkins and Bruno Decraene for the discussion and 664 suggestions to this document. 666 12. References 668 12.1. Normative References 670 [I-D.ietf-spring-segment-routing-mpls] 671 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 672 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 673 data plane", draft-ietf-spring-segment-routing-mpls-22 674 (work in progress), May 2019. 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, 679 . 681 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 682 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 683 May 2017, . 685 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 686 Decraene, B., Litkowski, S., and R. Shakir, "Segment 687 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 688 July 2018, . 690 12.2. Informative References 692 [BBF-SD406] 693 "BBF SD-406: End-to-End Network Slicing", 2016, 694 . 697 [DetNet] "DetNet WG", 2016, 698 . 700 [I-D.dong-lsr-sr-enhanced-vpn] 701 Dong, J. and S. Bryant, "IGP Extensions for Segment 702 Routing based Enhanced VPN", draft-dong-lsr-sr-enhanced- 703 vpn-01 (work in progress), October 2018. 705 [I-D.ietf-6man-segment-routing-header] 706 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 707 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 708 Routing Header (SRH)", draft-ietf-6man-segment-routing- 709 header-21 (work in progress), June 2019. 711 [I-D.ietf-idr-bgpls-segment-routing-epe] 712 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 713 S., and J. Dong, "BGP-LS extensions for Segment Routing 714 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 715 segment-routing-epe-19 (work in progress), May 2019. 717 [I-D.ietf-spring-segment-routing-policy] 718 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 719 bogdanov@google.com, b., and P. Mattes, "Segment Routing 720 Policy Architecture", draft-ietf-spring-segment-routing- 721 policy-03 (work in progress), May 2019. 723 [I-D.ietf-spring-srv6-network-programming] 724 Filsfils, C., Camarillo, P., Leddy, J., 725 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 726 Network Programming", draft-ietf-spring-srv6-network- 727 programming-00 (work in progress), April 2019. 729 [I-D.ietf-teas-enhanced-vpn] 730 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 731 Framework for Enhanced Virtual Private Networks (VPN+) 732 Service", draft-ietf-teas-enhanced-vpn-01 (work in 733 progress), February 2019. 735 [NGMN-NS-Concept] 736 "NGMN NS Concept", 2016, . 740 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 741 "Definition of the Differentiated Services Field (DS 742 Field) in the IPv4 and IPv6 Headers", RFC 2474, 743 DOI 10.17487/RFC2474, December 1998, 744 . 746 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 747 and W. Weiss, "An Architecture for Differentiated 748 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 749 . 751 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 752 Label Switching Architecture", RFC 3031, 753 DOI 10.17487/RFC3031, January 2001, 754 . 756 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 757 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 758 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 759 . 761 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 762 (TE) Extensions to OSPF Version 2", RFC 3630, 763 DOI 10.17487/RFC3630, September 2003, 764 . 766 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 767 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 768 2008, . 770 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 771 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 772 DOI 10.17487/RFC5439, February 2009, 773 . 775 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 776 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 777 DOI 10.17487/RFC5440, March 2009, 778 . 780 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 781 and A. Bierman, Ed., "Network Configuration Protocol 782 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 783 . 785 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 786 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 787 RFC 6790, DOI 10.17487/RFC6790, November 2012, 788 . 790 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 791 Previdi, "OSPF Traffic Engineering (TE) Metric 792 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 793 . 795 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 796 S. Ray, "North-Bound Distribution of Link-State and 797 Traffic Engineering (TE) Information Using BGP", RFC 7752, 798 DOI 10.17487/RFC7752, March 2016, 799 . 801 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 802 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 803 RFC 7810, DOI 10.17487/RFC7810, May 2016, 804 . 806 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 807 RFC 7950, DOI 10.17487/RFC7950, August 2016, 808 . 810 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 811 (IPv6) Specification", STD 86, RFC 8200, 812 DOI 10.17487/RFC8200, July 2017, 813 . 815 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 816 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 817 IGP Traffic Engineering Performance Metric Extensions", 818 RFC 8571, DOI 10.17487/RFC8571, March 2019, 819 . 821 [TS23501] "3GPP TS23.501", 2016, 822 . 825 [TS28530] "3GPP TS28.530", 2016, 826 . 829 Authors' Addresses 831 Jie Dong 832 Huawei Technologies 834 Email: jie.dong@huawei.com 836 Stewart Bryant 837 Huawei Technologies 839 Email: stewart.bryant@gmail.com 841 Takuya Miyasaka 842 KDDI Corporation 844 Email: ta-miyasaka@kddi.com 846 Yongqing Zhu 847 China Telecom 849 Email: zhuyq@gsta.com 851 Fengwei Qin 852 China Mobile 854 Email: qinfengwei@chinamobile.com 856 Zhenqiang Li 857 China Mobile 859 Email: li_zhenqiang@hotmail.com