idnits 2.17.1 draft-dong-spring-sr-for-enhanced-vpn-03.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 too long lines in the document, the longest one being 1 character in excess of 72. 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 (March 11, 2019) is 1872 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 (-22) exists of draft-ietf-spring-segment-routing-mpls-18 == 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-16 == 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: 1 error (**), 0 flaws (~~), 6 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: September 12, 2019 Z. Li 6 China Mobile 7 T. Miyasaka 8 KDDI Corporation 9 March 11, 2019 11 Segment Routing for Enhanced VPN Service 12 draft-dong-spring-sr-for-enhanced-vpn-03 14 Abstract 16 Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it 17 to support the needs of new applications, particularly applications 18 that are associated with 5G services. These applications require 19 better isolation from both control and data plane's perspective and 20 have more stringent performance requirements than can be provided 21 with overlay VPNs. The characteristics of an enhanced VPN as 22 perceived by its tenant needs to be comparable to those of a 23 dedicated private network. This requires tight integration between 24 the overlay VPN and the underlay network resources in a scalable 25 manner. An enhanced VPN may form the underpinning of 5G network 26 slicing, but will also be of use in its own right. This document 27 describes the use of segment routing based mechanisms to provide the 28 enhanced VPN service with dedicated network resources. The proposed 29 mechanism is applicable to both SR with MPLS data plane and SR with 30 IPv6 data plane (SRv6). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 12, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 68 3. Segment Routing with Resource Awareness . . . . . . . . . . . 4 69 3.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1.1. Singe SID Identifying both Topology and Resource . . 4 71 3.1.2. Dedicated SID Identifying Network Resource . . . . . 5 72 3.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Topology and Resource Computation . . . . . . . . . . . . 8 76 5.2. Network Resource and SID Allocation . . . . . . . . . . . 8 77 5.3. Construction of SR Virtual Networks . . . . . . . . . . . 10 78 5.4. VPN Service to SR Virtual Network Mapping . . . . . . . . 11 79 5.5. Network Visibility to Customer . . . . . . . . . . . . . 11 80 6. Benefits of the Proposed Mechanism . . . . . . . . . . . . . 12 81 6.1. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.2. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 6.3. Basic SR . . . . . . . . . . . . . . . . . . . . . . . . 13 84 6.4. SR with Resource Awareness . . . . . . . . . . . . . . . 13 85 7. Service Assurance . . . . . . . . . . . . . . . . . . . . . . 13 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 91 11.2. Informative References . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 the 99 transport network to support partitioning the network resources to 100 provide the client with dedicated (private) networking, computing, 101 and storage resources drawn from a shared pool. The slices may be 102 seen as (and operated as) virtual networks. 104 Thus there is a need to create virtual networks with enhanced 105 characteristics. The tenant of such a virtual network can require a 106 degree of isolation and performance that previously could only be 107 satisfied by dedicated networks. Additionally the tenant may ask for 108 some level of control to their virtual network e.g. to customize the 109 service paths in the network slice. 111 The enhanced VPN service (VPN+) as described in 112 [I-D.ietf-teas-enhanced-vpn] is targeted at new applications which 113 require better isolation from both control plane and data plane's 114 perspective and have more stringent performance requirements than can 115 be provided with existing overlay VPNs. An enhanced VPN may form the 116 underpinning of network slicing, but will also be of use in its own 117 right. 119 Although each VPN can be associated with a set of dedicated RSVP-TE 120 [RFC3209] LSPs with bandwidth reservation to provide some guarantee 121 to service performance, such mechanisms would introduce per-VPN per- 122 path states into the network, which is known to have scalability 123 issues [RFC5439] and has not been widely adopted in production 124 networks. 126 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 127 through an ordered list of segments. It can achieve explicit source 128 routing without introducing per-path state into the network. Like 129 RSVP-TE, SR also supports source specification of the packet path. 130 However, currently SR does not have the capability of reserving or 131 identifying different network resources for different services or 132 customers. Although the controller can have global view of network 133 state and can provision different services onto different SR paths, 134 in the data plane it still relies on traditional DiffServ QoS model 135 [RFC2474] [RFC2475] to provide coarse-grained traffic differentiation 136 in the network. While this may be sufficient for some traditional 137 services, it cannot meet the requirement of the enhanced VPN service. 139 This document extends the SR paradigm by allocating different Segment 140 Identifiers (SIDs) to represent the different subset of resources 141 allocated on each network elements (links or nodes). The SIDs 142 associated with a particular group of network resources can be used 143 to construct customized virtual networks for different services, the 144 SID can also be used to steer the service traffic to be processed 145 with the corresponding allocated resources. This mechanism can be 146 used to provide the enhanced VPN service with dedicated network 147 resources. The proposed mechanism is applicable to both SR with MPLS 148 data plane and SR with IPv6 data plane (SRv6). 150 2. Requirements Notation 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 RFC 2119 [RFC2119] RFC8174 [RFC8174][when, and only when, they 156 appear in all capitals, as shown here. 158 3. Segment Routing with Resource Awareness 160 In segment routing, several types of segments are defined to 161 represent either topological elements or service instructions. A 162 topological segment may be a node segment or an adjacency segment. 163 Some other types of segments may be associated with specific service 164 functions for service chaining purpose. However, so far none of the 165 SR segments are associated with network resources for the QoS 166 purpose. 168 In order to support the enhanced VPNs which require guaranteed 169 performance and isolation from other services in the network, the 170 overlay VPN needs to be integrated with part of the underlay 171 networks. Some dedicated network resources need to be allocated to 172 an enhanced VPN or a group of enhanced VPNs. When segment routing is 173 used to provide enhanced VPNs, it is necessary to associate the 174 segments with network resources. By extending the segment routing 175 paradigm, different set of network resources can be allocated on 176 network elements, and associated with different SIDs. 178 This section describes the possible mechanisms to bring resource- 179 awareness into two SR data plane instantiations: SR-MPLS and SRv6. 181 3.1. SR-MPLS 183 3.1.1. Singe SID Identifying both Topology and Resource 185 In SR-MPLS [I-D.ietf-spring-segment-routing-mpls], Adjacency Segment 186 (Adj-SID) is an IGP-segment attached to a unidirectional adjacency or 187 a set of unidirectional adjacencies. Node segment is an IGP-Prefix 188 segment that identifies a specific router (e.g., a loopback). These 189 two types of SIDs can be extended to represent both topological 190 elements and the resources allocated on a particular network element. 192 On one particular network link, multiple adjacency segment 193 identifiers (Adj-SIDs) can be allocated, each of which is associated 194 with a subset of the link resource allocated, such as logical sub- 195 interface, bandwidth, queues, etc. For one particular node, multiple 196 node-SIDs can be allocated, each of which may be associated with a 197 subset of resource allocated from the node, such as the processing 198 resources. Per-segment resource allocation complies to the SR 199 paradigm, which avoids introducing per-path state into the network. 201 Different groups of adj-SIDs and node-SIDs which represent different 202 set of network resources can be used to build different virtual 203 networks, which could be further used to provide different enhanced 204 VPNs, so that the isolation and performance requirement of enhanced 205 VPNs could be met. The adj-SIDs are used to steer traffic of 206 different enhanced VPNs into different set of link resources. The 207 node SIDs can be used to steer traffic of different enhanced VPNs 208 into different node resources. The node SIDs can also be used to 209 build loose SR paths for different enhanced VPNs. In this case, the 210 node-SIDs are used by transit nodes to steer traffic into the local 211 resources allocated for the corresponding enhanced VPN. Note in this 212 case Penultimate Hop Popping (PHP) [RFC3031] MUST be disabled, as the 213 node-SID is used to identify the SR virtual network and the 214 corresponding network resources allocated to the enhanced VPN. 216 3.1.2. Dedicated SID Identifying Network Resource 218 Another option to bring resource-awareness into SR-MPLS data plane is 219 to define a dedicated SID called "resource-SID" to identify the group 220 of network resources allocated on a particular link or node. In SR 221 label stack, the resource-SID MUST be encapsulated under the 222 topological SIDs (adj-SID or node-SIDs) which identifies the network 223 element it applies to. 225 Note that a network node can participate in multiple topologies. For 226 each network topology it participates in, a dedicated node-SID is 227 needed for topology-specific path computation and next hop 228 resolution. Dedicated adj-SIDs could also be allocated for different 229 network topologies. 231 In packet forwarding, the adj-SID and node-SID are used to determine 232 the next-hop and the outbound interface in a particular virtual 233 network, then the resource-SID is used to identify the fine granular 234 forwarding plane resource to be used for the processing of the 235 received packet. 237 The benefit of this approach is that it decouples the topology 238 identification and resource identification. In some cases where 239 multiple virtual networks share a same topology but map to different 240 set of network resources, it is possible that the topology-specific 241 processing (for example, SPF computation) could be shared, so that 242 the scalability can be improved. The cost is it increases the depth 243 of the MPLS label stack. 245 The resource-SID can be a global significant identifier, which 246 represents the collection of network resources allocated in the whole 247 network domain to a particular virtual network. In this case, the 248 resource-SID SHOULD appear only once in the label stack, and it 249 SHOULD be parsed by each transit node which performs per virtual 250 network resource reservation. This resource-SID can be either a new 251 type of SID, or it could be embedded in some existing MPLS labels. 252 For example, some fields in the Entroy Label Indicator (ELI) / 253 Entropy Label (EL) [RFC6790] may be used as the resource identifier, 254 the details will be provided in a future version. 256 The resource-SID may be a local significant identifier, which only 257 represents the network resource locally allocated on each network 258 segment to a particular virtual network. In this case, it has to be 259 added to the label stack for each hop which performs per-virtual 260 network resource reservation. As this approach would increase the 261 label stack depth significantly, this approach is NOT RECOMMENDED. 263 3.2. SRv6 265 An SRv6 Segment (SID) is a 128-bit value which consists of a locator 266 (LOC) and a function (FUNCT), optionally it may also contain 267 additional arguments (ARG) 268 [I-D.filsfils-spring-srv6-network-programming]. The locator is used 269 for routing towards a particular node, it needs to be parsed by all 270 nodes in the network. The function and arguments are only parsed by 271 the owner of the SRv6 SID to determine the local behavior on receipt 272 of the SRv6 packet. 274 In order to build multiple virtual networks in an SRv6 network, each 275 node SHOULD allocate a dedicated locator for each virtual network it 276 participates in. In packet forwarding, the locator can be used to 277 identify the virtual network the packet belongs to, so that a virtual 278 network specific next-hop can be determined. In addition, the 279 locator can also be used to identify the group of local network 280 resources allocated to the virtual network. All the SRv6 functions 281 associated with a particular virtual network MUST use the locator of 282 that virtual network as the prefix to construct the SRv6 SID. 284 In some cases where multiple virtual networks share a same topology 285 but maps to different set of network resources, it is possible that 286 the topology-specific processing (for example, SPF computation) could 287 be shared, so that the scalability can be improved. This requires to 288 decouple the topology identification and resource identification in 289 SRv6. The locator can still be used as the identifier of the 290 topology, while another identifier is needed to identify the network 291 resources allocated to a particular virtual network. There are some 292 candidates for the resource identifier in the IPv6 [RFC8200] or SRv6 293 header [I-D.ietf-6man-segment-routing-header], such as the IPv6 Flow 294 Label or the Hop-by-Hop Option. More details will be provided in a 295 future version. 297 4. Control Plane 299 The architecture described in this document makes use of a 300 centralized controller that collects the information about the 301 network (configuration, state, routing databases, etc.) as well as 302 the service information (traffic matrix, performance statistics, 303 etc). The controller is also responsible for the centralized 304 computation and optimization of the virtual networks used for 305 enhanced VPNs. A distributed control plane is needed for the 306 collection and distribution of the topology and state information of 307 the virtual networks. Distributed routing computation for some 308 services in the enhanced VPNs is also possible. 310 5. Procedures 312 This section describes the procedures of provisioning an enhanced VPN 313 service based on segment routing with resource awareness. 315 According to the requirement of an enhanced VPN service, a 316 centralized network controller calculates a subset of the underlay 317 network topology to support this enhanced VPN. Within this topology, 318 the network resources needed on each network element can also be 319 determined. The network resources are allocated in a per-segment 320 manner, and are associated with different node-SIDs and adj-SIDs. 321 The group of the node-SIDs and adj-SIDs allocated for the enhanced 322 VPN will be used by network nodes and the network controller to build 323 a SR virtual topology, which is used as the logical underlay of the 324 enhanced VPN service. The extensions to IGP protocol to distribute 325 the SIDs and the associated resources allocated for a virtual network 326 is specified in [I-D.dong-lsr-sr-enhanced-vpn]. 328 Suppose that customer requests for an enhanced VPN service from the 329 network operator. The fundamental requirement is that customer A's 330 service does not experience interference from other services in the 331 network, such as other customers' VPN services, or the non-VPN 332 services in the network. The detailed requirements can be described 333 with characteristics such as the following: 335 o Service topology: the service sites and the connectivity between 336 them 338 o Service bandwidth: the bandwidth requirement between service sites 340 o Isolation: the level of isolation from other services in the 341 network 343 o Reliability: whether fast repair or end-to-end protection is 344 needed or not. 346 o Latency 348 o Jitter 350 o Visibility: the customer may want to have some form of visibility 351 of the network deliversing the service. 353 5.1. Topology and Resource Computation 355 As described in section 4, a centralized network controller is 356 responsible for the provisioning of enhanced VPNs. The controller 357 needs to determine the information of network connectivity, network 358 resources, network performance and other relevant network state of 359 the underlay network. This is often done using either IGP [RFC5305] 360 [RFC3630] [RFC7471] [RFC7810] or BGP-LS [RFC7752] 361 [I-D.ietf-idr-te-pm-bgp]. 363 Based on the network information collected from the underlay network, 364 the controller computes the underlay topology (possibly using 365 multiple algorithms) and knows the resources that are available and 366 allocated. When a request is received from a tenant, the controller 367 computes the subgraph of the underlay network, along with the 368 resources to be allocated on each network element (e.g. links and 369 nodes) in the topology to meet the tenant's requirements, whilst 370 maintaining the needs of the existing tenants that are using the same 371 network. 373 5.2. Network Resource and SID Allocation 375 According to the output of computation, the network controller 376 instructs the network devices involved in the subgraph to allocate 377 the required network resources for the enhanced VPN. This can be 378 done with either PCEP [RFC5440] or Netconf/YANG [RFC6241] [RFC7950] 379 with necessary extensions. The network resources are allocated in a 380 per-segment manner. In addition, dedicated segment identifiers, e.g. 381 node-SIDs and adj-SIDs are also allocated to represent the network 382 resources allocated for the enhanced VPN on each network segment. 384 In the forwarding plane, there are multiple ways of allocating or 385 reserving network resources to different enhanced VPNs. For example, 386 FlexE may be used to partition the link resource into different sub- 387 channels to achieve hard isolation between each other. The candidate 388 data plane technologies of enhanced VPN can be found in 389 [I-D.ietf-teas-enhanced-vpn]. The SR SIDs are used as a good 390 abstraction of the various types of network resource reservation 391 mechanisms in the forwarding plane. 393 Node-SIDs: Node-SIDs: 394 r:101 r:102 395 g:201 Adj-SIDs: g:202 396 b:301 r:1001:1G r:1001:1G b:302 397 +-----+ g:2001:2G g:2001:2G +-----+ 398 | A | b:3001:1G b:3001:1G | B |Adj-SIDs: 399 | +------------------------+ + r:1003:1G 400 Adj-SIDs +--+--+ +--+--+\g:2003:2G 401 r:1002:1G| r:1002:1G| \ 402 g:2002:2G| g:2002:2G| \ r:1001:1G 403 b:3002:3G| b:3002:2G| \g:2001:2G 404 | | \ +-----+ Node-SIDs: 405 | | \+ E | r:105 406 | | /+ | g:205 407 r:1001:1G| r:1002:1G| / +-----+ 408 g:2001:2G| g:2002:2G| /r:1002:1G 409 b:3001:3G| b:3002:2G| / g:2002:2G 410 +--+--+ +--+--+ / 411 | | | |/r:1003:1G 412 | C +------------------------+ D + g:2003:2G 413 +-----+ r:1002:1G r:1001:1G +-----+ 414 Node-SIDs: g:2002:1G g:2001:1G Node-SIDs: 415 r:103 b:3002:2G b:3001:2G r:104 416 g:203 g:204 417 b:303 b:304 419 Figure 1. SIDs identify resources allocated to different virtual networks 421 Figure 1 shows a network fragment of enhanced VPN supported by SR. 422 Note that the format of the SIDs in this figure are for illustration, 423 both SR-MPLS and SRv6 can be utilized as the data plane. In this 424 example, there are three virtual topologies created for enhanced VPNs 425 red (r) , green (g) and blue (b). The red and green topologies 426 consist of nodes A, B, C, D, and E with all their interconnecting 427 links, whilst the blue topology only consists of nodes A, B, C and D 428 with all their interconnecting links. Each node allocates a 429 dedicated adjacency SID for each link participating in a particular 430 topology. Each node is also allocated with a dedicated node SID for 431 each topology it participates in. The adj-SIDs are associated with 432 the link resources (e.g. bandwidth) allocated to each topology, so 433 that the adj-SIDs can be used to steer service of different enhanced 434 VPNs into different set of reserved resources in the data plane. The 435 node-SIDs can be associated with dedicated nodal resources allocated 436 for each topology. In addition, the node-SIDs of different 437 topologies can be used to build loose SR path within each virtual 438 topology, and steer service of different enhanced VPNs into the 439 different set of reserved resources in the data plane. 441 In Figure 1, the notation x:nnnn:y that in topology colour x, the 442 adj-SID nnnn will steer the packet over that link which has a total 443 bandwidth of y assigned to that topology. Thus the note r:1002:1G in 444 link C->D says that the red topology over link C->D has a reserved 445 bandwidth of 1Gb/s and will be used by packets arriving at node C 446 with an adj-SID 1002 at the top of the label stack. 448 5.3. Construction of SR Virtual Networks 450 Each node MUST advertise its set of resources (allocated and 451 available) and the associated SIDs both to the centralized controller 452 and into the network. This can be achieve by many different means 453 such as (non-exhaustive list) IGP extensions 454 [I-D.dong-lsr-sr-enhanced-vpn], BGP-LS [RFC7752] with possible 455 extensions, NETCONF/YANG [RFC6241] [RFC7950]. 457 With the collected network resource and SIDs information, the 458 controller and network nodes are able to construct the SR virtual 459 topologies and forwarding entries using the node-SIDs and adj-SIDs 460 allocated for each enhanced VPN. Unlike classic segment routing in 461 which network resources are shared by all services and customers, the 462 SR virtual networks are associated with dedicated resource allocated 463 in the underlay, so that they can be used to meet the service 464 requirement of enhanced VPN and provide the required isolation from 465 other services in the same network. 467 Figure 2 shows the virtual SR topologies created from the underlay 468 network in Figure 1. 470 1001 1001 2001 2001 3001 3001 471 101---------102 201---------202 301---------302 472 | | \1003 | | \2003 | | 473 1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002| 474 | | 105 | | 205 | | 475 1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002| 476 | | / 1003 | | / 2003 | | 477 103---------104 203---------204 303---------304 478 1002 1001 1002 2001 3002 3001 479 Topology Red Topology Green Topology Blue 481 Figure 2. SR virtual topologies using different groups of SIDs 483 5.4. VPN Service to SR Virtual Network Mapping 485 The services of an enhanced VPN customer can be provisioned using the 486 customized SR virtual network as the underlay. In this way, services 487 of different enhanced VPNs will only use the network resources 488 allocated and will not interfere with each other. For each enhanced 489 VPN customer, the service paths can be customized for different 490 services within the SR virtual topology, and the allocated network 491 resources are shared by different services of the same enhanced VPN 492 customer. 494 For example, to create a strict path along the path A-B-D-E in the 495 red topology in Figure 2, the SR segment list in the service packet 496 would be (1001, 1002, 1003). For the same strict path in green 497 topology, the SR segment list would be (2001, 2002, 2003). In the 498 case where we wish to construct a loose path A-D-E in the green 499 topology, the service packet SHOULD be set with the SR segment list 500 (201, 204, 205). At node A the packet is sent towards D via either 501 node B or C using the link and node resources allocated for the green 502 topology. At node D the packet is forwarded to E using the link and 503 node resource allocated for the green topology. Similarly, a packet 504 for the loose path A-D-E in the red topology would arrive at node A 505 with the SID list (101, 104, 105). 507 5.5. Network Visibility to Customer 509 The tenants of enhanced VPNs may request different granularity of 510 visibility to the network which deliver the service. Depending on 511 the requirement, the network can be exposed to the tenant either as a 512 virtual network topology, or a set of computed paths with transit 513 nodes, or simply the connectivity between endpoints without any path 514 information. The visibility can be delivered through different 515 possible mechanisms, such as IGPs (e.g. IS-IS, OSPF) or BGP-LS. In 516 addition, the network operator may want to restrict the visibility of 517 the information it delivers to the tenant by either hiding the 518 transit nodes between sites (and only delivering the endpoints 519 connectivity) or by hiding portions of the transit nodes (summarizing 520 the path into fewer nodes). Mechanisms such as BGP-LS allow the 521 flexibility of the advertisement of aggregated network information. 523 6. Benefits of the Proposed Mechanism 525 The proposed mechanism provides several key characteristics: 527 o Flexibility 529 o Scalability 531 o Resource isolation 533 In addition to isolation, the proposed mechanism allows resource 534 sharing between different services of the same enhanced VPN customer. 535 This gives the customer more flexibility and control in service 536 planning and provisioning, the experience would be similar to using a 537 dedicated private network. The performance of critical services 538 flows in a particular enhanced VPN can be further ensured using the 539 mechanisms defined in [DetNet]. 541 The detailed comparison with other candidates technologies are given 542 in the following subsections. 544 6.1. MPLS-TP 546 MPLS-TP could be enhanced to include the allocation of specific 547 resources along the path to a specific LSP. This would require that 548 the SDN system set up and maintain every resource at every path for 549 every customer, and map this to the LSP in the data plane, hence at 550 every hop unique LSP label is needed for each path. Whilst this 551 would be a way to produce a proof of concept for network slicing of 552 an MPLS underlay, delegation would be difficult, resulting in a high 553 overhead and a system needing too much administration. This leads to 554 scaling concerns. The number of labels needed at any node would be 555 the total number of services passing through that node. Experience 556 with early pseudowire designs shows that this can lead to scaling 557 issues. 559 6.2. RSVP-TE 561 RSVP-TE has the same scaling concern as MPLS-TP in terms of the 562 number of LSPs that need to be maintained being equal to the number 563 of services passing through any given node. It also has the two RSVP 564 disadvantages that basic SR seeks to address: 566 o The use of RSVP for path establishment in addition to the routing 567 protocol used to discover the topology and the network resources. 569 o The overhead of the soft-state maintenance associated with RSVP. 570 The impact of this overhead would be exacerbated by the increased 571 number of end to end paths requiring state maintenance. 573 6.3. Basic SR 575 Compared to RSVP, SR reduces the number of control protocols to only 576 the routing protocol. It also attempts to minimize the core state by 577 pushing state into the packet, although in some cases the binding 578 SIDs are required to overcome the limitations in the ability of some 579 nodes to push large label stacks. Moreover, currently SR does not 580 support resource allocation or identification below the level of 581 link, and none at node level. This restricts the extent to which 582 some particular tenant traffic can be isolated from other traffic in 583 the network. 585 6.4. SR with Resource Awareness 587 The approach described in this document seeks to achieve a compromise 588 between the state limitations of traditional TE systems and the lack 589 of resource awareness in basic SR. 591 By segmenting the path and allocating network resources to each 592 element of the virtual network topologies, the operator can choose 593 the granularity of resource to path binding within a virtual 594 topology. In network segments where resource is scarce such that the 595 service requirement may not always be met, the SR approach can 596 allocate specific resources to a particular high priority service. 597 By contrast, in other parts of the network where resource is 598 plentiful, the resource may be shared by a number of services. The 599 decision to do this is in the hands of the operator. Because of the 600 segmented nature of the path, resource aggregation is possible in a 601 way that is more difficult with RSVP-TE and MPLS-TP due to the use of 602 dedicated label to identify each end-to-end path. 604 7. Service Assurance 606 In order to provide service assurance it is necessary to instrument 607 the network at multiple levels. The network operator needs to 608 ascertain that the underlay is operating correctly. A tenant needs 609 to ascertain that their services are correctly operating. In 610 principle these can use existing techniques. These are well known 611 problems and solutions either exist or are in development to address 612 them. 614 New work is needed to instrument the virtual networks that are 615 created. Such instrumentation needs to operate without causing 616 disruption to other services using the network. Given the 617 sensitivity of some applications, care needs to be taken to ensure 618 that the instrumentation itself does not cause disruption either to 619 the service being instrumented or to other services. 621 8. IANA Considerations 623 This document makes no request of IANA. 625 Note to RFC Editor: this section may be removed on publication as an 626 RFC. 628 9. Security Considerations 630 The normal security considerations of VPNs are applicable and it is 631 assumed that industry best practise is applied to an enhanced VPN. 633 The security considerations of segment routing are applicable and it 634 is assumed that these are applied to an enhanced VPN that uses SR. 636 Some applications of enhanced VPNs are sensitive to packet latency; 637 the enhanced VPNs provisioned to carry their traffic have latency 638 SLAs. By disrupting the latency of such traffic an attack can be 639 directly targeted at the customer application, or can be targeted at 640 the network operator by causing them to violate their SLA, triggering 641 commercial consequences. Dynamic attacks of this sort are not 642 something that networks have traditionally guarded against, and 643 networking techniques need to be developed to defend against this 644 type of attack. By rigorously policing ingress traffic and carefully 645 provisioning the resources provided to critical services this type of 646 attack can be prevented. However case needs to be taken when 647 providing shared resources, and when the network needs to be 648 reconfigured as part of ongoing maintenance or in response to a 649 failure. 651 The details of the underlay MUST NOT be exposed to third parties, to 652 prevent attacks aimed at exploiting a shared resource. 654 10. Acknowledgements 656 The authors would like to thank Mach Chen, Zhenbin Li, Stefano 657 Previdi, Charlie Perkins and Bruno Decraene for the discussion and 658 suggestions to this document. 660 11. References 662 11.1. Normative References 664 [I-D.ietf-spring-segment-routing-mpls] 665 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 666 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 667 data plane", draft-ietf-spring-segment-routing-mpls-18 668 (work in progress), December 2018. 670 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, 672 DOI 10.17487/RFC2119, March 1997, 673 . 675 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 676 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 677 May 2017, . 679 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 680 Decraene, B., Litkowski, S., and R. Shakir, "Segment 681 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 682 July 2018, . 684 11.2. Informative References 686 [BBF-SD406] 687 "BBF SD-406: End-to-End Network Slicing", 2016, 688 . 691 [DetNet] "DetNet WG", 2016, 692 . 694 [I-D.dong-lsr-sr-enhanced-vpn] 695 Dong, J. and S. Bryant, "IGP Extensions for Segment 696 Routing based Enhanced VPN", draft-dong-lsr-sr-enhanced- 697 vpn-01 (work in progress), October 2018. 699 [I-D.filsfils-spring-srv6-network-programming] 700 Filsfils, C., Camarillo, P., Leddy, J., 701 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 702 Network Programming", draft-filsfils-spring-srv6-network- 703 programming-07 (work in progress), February 2019. 705 [I-D.ietf-6man-segment-routing-header] 706 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 707 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 708 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 709 progress), February 2019. 711 [I-D.ietf-idr-te-pm-bgp] 712 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 713 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 714 Performance Metric Extensions", draft-ietf-idr-te-pm- 715 bgp-18 (work in progress), December 2018. 717 [I-D.ietf-teas-enhanced-vpn] 718 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 719 Framework for Enhanced Virtual Private Networks (VPN+) 720 Service", draft-ietf-teas-enhanced-vpn-01 (work in 721 progress), February 2019. 723 [NGMN-NS-Concept] 724 "NGMN NS Concept", 2016, . 728 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 729 "Definition of the Differentiated Services Field (DS 730 Field) in the IPv4 and IPv6 Headers", RFC 2474, 731 DOI 10.17487/RFC2474, December 1998, 732 . 734 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 735 and W. Weiss, "An Architecture for Differentiated 736 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 737 . 739 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 740 Label Switching Architecture", RFC 3031, 741 DOI 10.17487/RFC3031, January 2001, 742 . 744 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 745 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 746 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 747 . 749 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 750 (TE) Extensions to OSPF Version 2", RFC 3630, 751 DOI 10.17487/RFC3630, September 2003, 752 . 754 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 755 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 756 2008, . 758 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 759 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 760 DOI 10.17487/RFC5439, February 2009, 761 . 763 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 764 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 765 DOI 10.17487/RFC5440, March 2009, 766 . 768 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 769 and A. Bierman, Ed., "Network Configuration Protocol 770 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 771 . 773 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 774 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 775 RFC 6790, DOI 10.17487/RFC6790, November 2012, 776 . 778 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 779 Previdi, "OSPF Traffic Engineering (TE) Metric 780 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 781 . 783 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 784 S. Ray, "North-Bound Distribution of Link-State and 785 Traffic Engineering (TE) Information Using BGP", RFC 7752, 786 DOI 10.17487/RFC7752, March 2016, 787 . 789 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 790 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 791 RFC 7810, DOI 10.17487/RFC7810, May 2016, 792 . 794 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 795 RFC 7950, DOI 10.17487/RFC7950, August 2016, 796 . 798 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 799 (IPv6) Specification", STD 86, RFC 8200, 800 DOI 10.17487/RFC8200, July 2017, 801 . 803 [TS23501] "3GPP TS23.501", 2016, 804 . 807 [TS28530] "3GPP TS28.530", 2016, 808 . 811 Authors' Addresses 813 Jie Dong 814 Huawei Technologies 816 Email: jie.dong@huawei.com 818 Stewart Bryant 819 Huawei Technologies 821 Email: stewart.bryant@gmail.com 823 Zhenqiang Li 824 China Mobile 826 Email: li_zhenqiang@hotmail.com 828 Takuya Miyasaka 829 KDDI Corporation 831 Email: ta-miyasaka@kddi.com