idnits 2.17.1 draft-dong-spring-sr-for-enhanced-vpn-06.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 (December 16, 2019) is 1586 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: 'RFC8174' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC5439' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC6790' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 775, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-dong-idr-bgpls-sr-enhanced-vpn-00 == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-06 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-03 -- 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 SPRING Working Group J. Dong 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track S. Bryant 5 Expires: June 18, 2020 Futurewei Technologies 6 T. Miyasaka 7 KDDI Corporation 8 Y. Zhu 9 China Telecom 10 F. Qin 11 Z. Li 12 China Mobile 13 December 16, 2019 15 Segment Routing for Resource Partitioned Virtual Networks 16 draft-dong-spring-sr-for-enhanced-vpn-06 18 Abstract 20 This document describes the mechanism to associate Segment Routing 21 Identifiers (SIDs) with network resource attributes. The resource- 22 aware SIDs retain their original functionality, with the additional 23 semantics of identifying the set of network resources available for 24 the packet processing action. These SIDs can be used to build SID 25 lists with reserved network resources, which can be used for many 26 network scenarios. One typical use case is to provide SR virtual 27 networks with required network topology and resource attributes. The 28 proposed mechanism is applicable to both segment routing with MPLS 29 data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6). 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 June 18, 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. Segment Routing with Topology and Resource Awareness . . . . 3 73 2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Control Plane Considerations . . . . . . . . . . . . . . . . 6 76 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.1. Virtual Network Topology and Resource Computation . . . . 8 78 4.2. Network Resource and SID Allocation . . . . . . . . . . . 8 79 4.3. Construction of SR based Virtual Networks . . . . . . . . 10 80 4.4. Service to SR Virtual Network Mapping . . . . . . . . . . 11 81 4.5. Virtual Network Visibility to Customer . . . . . . . . . 11 82 5. Benefits of the Proposed Mechanism . . . . . . . . . . . . . 12 83 6. Service Assurance . . . . . . . . . . . . . . . . . . . . . . 13 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 11.2. Informative References . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 96 through an ordered list of segments. A segment is often referred to 97 by its Segment Identifier (SID). With SR, explicit source routing 98 can be achieved without introducing per-path state into the network. 99 Compared with RSVP-TE [RFC3209], currently SR does not have the 100 capability of reserving network resources or identifying a set of 101 network resources reserved for particular services or customers. 102 Although a centralized controller can have a global view of network 103 state and can provision different services onto different SR paths, 104 in packet forwarding it still relies on traditional DiffServ QoS 105 mechanism [RFC2474] [RFC2475] to provide coarse-grained traffic 106 differentiation in the network. While such kind of mechanism may be 107 sufficient for some types of services, it may not meet the stringent 108 requirement of some enhanced services which require dedicated network 109 resources to achieve isolation from other services in the network. 110 Also the number of such enhanced services can be larger than the 111 number of classes in DiffServ QoS. 113 This document extends the SR paradigm by associating SIDs with 114 network resource attributes. These resource-aware SIDs retain their 115 original functionality, with the additional semantics of identifying 116 the set of network resources available for the packet processing 117 action. For a particular network segment, multiple resource-aware 118 SIDs can be allocated, each of which represents different set of 119 network resources allocated to meet different service requirement. 120 This mechanism is applicable to SR with both MPLS data plane (SR- 121 MPLS) and IPv6 data plane (SRv6). 123 The proposed resource-aware SIDs can be used to build SID lists with 124 reserved network resources, which can be used in network scenarios 125 which require to allocate network resources to the processing of 126 particular service traffic. One typical use case is to provide SR 127 based virtual networks with required network topology and resource 128 attributes. A group of resource-aware SIDs can be used to specify 129 the customized topology of a virtual network, and can further be used 130 to steer the service traffic to be processed with the corresponding 131 set of network resources. In this case the proposed mechanism can 132 provide the underlay for enhanced VPN services as described in 133 [I-D.ietf-teas-enhanced-vpn]. 135 2. Segment Routing with Topology and Resource Awareness 137 When SR is used as the data plane to provide different virtual 138 networks in the same network, it is necessary that the SR paths are 139 computed within a virtual network topology, and are instantiated with 140 the corresponding set of network resources. 142 In the segment routing architecture [RFC8402], several types of 143 segments are defined to represent either topological or service 144 instructions. A topological segment can be a node segment or an 145 adjacency segment. A service segment may be associated with specific 146 service function for service chaining purpose. This document 147 introduces additional resource semantics to SIDs, so that the SIDs 148 can be used to identify a particular network topology and the set of 149 network resources. 151 This section describes the mechanisms to identify the virtual network 152 topology and resource information with the two SR data plane 153 instantiations: SR-MPLS and SRv6. 155 2.1. SR-MPLS 157 In SR-MPLS [I-D.ietf-spring-segment-routing-mpls], IGP Adjacency 158 Segment (Adj-SID) is an IGP-segment attached to a unidirectional 159 adjacency or a set of unidirectional adjacencies. IGP Prefix segment 160 is an IGP segment attached to an IGP prefix, and IGP node segment is 161 an IGP segment that identifies a specific router (e.g., a loopback). 162 In [I-D.ietf-idr-bgpls-segment-routing-epe], PeerAdj SID is used as 163 instruction to steer over a specific local interface towards a 164 specific peer node in a peering Autonomous System (AS). These types 165 of SIDs can be extended to represent both topological elements and 166 the resources allocated on a network element. 168 For one IGP link, multiple Adj-SIDs SHOULD be allocated, each of 169 which is associated with a virtual network topology, and MAY 170 represent a subset of link resources. Several approaches can be used 171 to partition the link resource, such as [FLEXE], layer-2 logical sub- 172 interfaces, dedicated queues, etc. The detailed mechanism of 173 resource partitioning is out of scope of this document. Similarly, 174 for one IGP node, multiple prefix-SIDs SHOULD be allocated, each of 175 which is associated with a virtual network topology, and may 176 represent a subset of the node resource (e.g. the processing 177 resources). For one inter-domain link, multiple BGP PeerAdj SIDs 178 [I-D.ietf-idr-bgpls-segment-routing-epe] SHOULD be allocated, each of 179 which is associated with a specific virtual network topology which 180 spans multiple domains, and MAY represent a subset of link resource 181 on the inter-domain link. Note that this per-segment resource 182 allocation complies to the SR paradigm, which avoids introducing per- 183 path state into the network. 185 A group of SIDs associated with the same virtual network can be used 186 to construct the SR SID-lists (either strict or loose) to steer the 187 traffic of a particular service within the virtual network. Each SID 188 in the SID-list MAY also represent the set of network resources 189 reserved on a network segment. 191 In data packet forwarding, the SIDs are used to identify the virtual 192 network the packet belongs to, so that a virtual network specific 193 next-hop can be determined. The adj-SIDs MAY also be used to steer 194 traffic of different services into different set of link resources. 195 The prefix-SIDs MAY be used to steer traffic of different services 196 into different set of node resources. When a prefix-SID is used in 197 the SID-list to build an SR loose path, the transit nodes use the 198 prefix-SID to identify the virtual network, and MAY process the 199 packet using the local resources allocated for the corresponding 200 virtual network. Note in this case, it is RECOMMENDED that 201 Penultimate Hop Popping (PHP) [RFC3031] be disabled, otherwise the 202 inner service label SHOULD be used to infer the set of resources to 203 be used. 205 This mechanism requires to allocate additional prefix-SIDs and adj- 206 SIDs for each virtual network. As the number of virtual networks 207 increases, the number of SIDs would increase accordingly. It is 208 expected that this mechanism is applicable to networks with a limited 209 number of virtual networks. 211 2.2. SRv6 213 As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6 214 Segment Identifier (SID) is a 128-bit value which consists of a 215 locator (LOC) and a function (FUNCT), optionally it may also contain 216 additional arguments (ARG) immediately after the FUNCT. The LOC of 217 the SID is routable and leads to the node which instantiates that 218 SID, which means the LOC can be parsed by all nodes in the network. 219 The FUNCT part of the SID is an opaque identification of a local 220 function bound to the SID, which means the FUNCT and ARG parts can 221 only be parsed by the node which instantiates that SID. 223 In order to support multiple virtual networks in a SRv6 network, all 224 the nodes (including the edge nodes and transit nodes) belonging to 225 the same virtual network MUST have a consistent view of the virtual 226 network, and performs consistent computation and forwarding behavior 227 to comply to the network topology and resource constraints. A node 228 which participates in multiple virtual networks MUST be able to 229 distinguish packets which belong to different virtual networks. 231 Taking the above into consideration, for a network node, multiple 232 SRv6 LOCs SHOULD be allocated, each of which is associated with a 233 virtual network topology, and MAY represent a subset of the network 234 resources associated with the virtual network. The SRv6 SIDs of a 235 particular virtual network SHOULD be allocated from the SID space 236 using the virtual network specific LOC as the prefix. These SRv6 237 SIDs can be used to represent virtual network specific local 238 functions. 240 A group of SRv6 SIDs associated with the same virtual network can be 241 used to construct the SR SID-lists (either strict or loose) to steer 242 the traffic of a particular service within the virtual network. Each 243 SID in the SID-list MAY also represent the set of network resources 244 which are reserved on a network segment. 246 In data packet forwarding, the LOC part of SRv6 SID is used by 247 transit nodes to identify the virtual network the packet belongs to, 248 so that a virtual network specific next-hop can be determined. The 249 LOC MAY also be used to indicate the set of local network resources 250 on the transit nodes to be used for the forwarding of the received 251 packet. The SRv6 segment endpoint nodes use the virtual network 252 specific SRv6 SID to identify the virtual network the packet belongs 253 to, and the particular local function to perform on the received 254 packet. The local SRv6 SID MAY also be used to identify the set of 255 network resource to be used for executing the local function. 257 This mechanism requires to allocate additional SRv6 Locators and SIDs 258 for each virtual network. As the number of virtual networks 259 increases, the number of Locators and SIDs would increase 260 accordingly. It is expected that this mechanism is applicable to 261 networks with a limited number of virtual networks. 263 3. Control Plane Considerations 265 The mechanism described in this document makes use of a centralized 266 controller to collect the information about the network 267 (configuration, state, routing databases, etc.) as well as the 268 service information (traffic matrix, performance statistics, etc.) 269 for the planning of virtual networks. The controller is also 270 responsible for the centralized computation and optimization of the 271 SR paths within different virtual networks. The SR SIDs can be 272 either explicitly provisioned by the controller, or dynamically 273 allocated by network nodes then reported to the controller. The 274 interaction between the controller and the network nodes can be based 275 on PCEP [RFC5440], Netconf/YANG [RFC6241] [RFC7950] and BGP-LS 276 [RFC7752]. In some scenarios, extensions to some of these protocols 277 is needed, which are out of the scope of this document and will be 278 specified in separate documents. In some cases a centralized 279 controller may not be used, but this would complicate the operations 280 and planning therefore not suggested. 282 A distributed control plane can be used for the collection and 283 distribution of the network topology and resource information of the 284 virtual networks among network nodes. Distributed route computation 285 for services within a virtual network is also needed. The 286 distributed control plane is complementary to the centralized 287 controller. 289 4. Procedures 291 This section describes the procedures of creating SR based virtual 292 networks and the corresponding forwarding tables and entries. 294 According to the received service requirement, a centralized network 295 controller calculates a subset of the physical network topology to 296 support the service. Within this topology, the set of network 297 resources required on each network element is also determined. This 298 network topology and the set of network resources together constitute 299 a virtual network. Depending on the service requirement, the network 300 topology and resource can be dedicated for a particular service, or 301 can be shared with other services. 303 Following the segment routing paradigm, the network topology and 304 resource are represented using a group of dedicated SIDs. The group 305 of prefix-SIDs and adj-SIDs allocated for a virtual network will be 306 used by network nodes and the network controller to construct an SR 307 based virtual network, which is considered as the underlay network 308 for the service. IGP and BGP-LS needs to be extended to distribute 309 the SIDs and the associated resource information of each virtual 310 network. The IGP extensions are specified in 311 [I-D.dong-lsr-sr-enhanced-vpn], and the BGP-LS extensions are 312 specified in [I-D.dong-idr-bgpls-sr-enhanced-vpn]. 314 Suppose tenant A requests for a virtual network from the network 315 operator. The requirement is that services of tenant A has dedicated 316 network resource allocated and does not experience unexpected 317 interference from other services in the same network, such as other 318 tenants' VPN services, or non-VPN services in the network. The 319 detailed requirements can be described with characteristics such as 320 the following: 322 o Service topology: the service sites and the connectivity between 323 them. 325 o Service bandwidth: the bandwidth requirement between service 326 sites. 328 o Isolation: the level of isolation from other services in the 329 network. 331 o Reliability: whether fast local repair or end-to-end protection is 332 needed or not. 334 o Latency: the maximum latency between specific service sites. 336 o Visibility: the customer may want to have some form of visibility 337 of the virtual network delivering the service. 339 4.1. Virtual Network Topology and Resource Computation 341 As described in section 4, a centralized network controller is 342 responsible for the planning of a virtual network to meet the 343 received service request. The controller collects the information of 344 network connectivity, network resources, network performance and 345 other relevant network states of the underlay network. This can be 346 done using either IGP [RFC5305] [RFC3630] [RFC7471] [RFC7810] or BGP- 347 LS [RFC7752] [RFC8571]. 349 Based on the information collected from the underlay network, the 350 controller obtains the underlay network topology and the information 351 about the allocated and available network resources. When a service 352 request is received from a tenant, the controller computes the subset 353 of the network topology, along with the set of the resources needed 354 on each network element (e.g. links and nodes) in the topology to 355 meet the tenant's service requirements, whilst maintaining the needs 356 of the existing tenants that are using the same network. The subset 357 of network topology and resource constitute a virtual network, which 358 will be used as the underlay of the requested service. 360 4.2. Network Resource and SID Allocation 362 According to the result of virtual network planning, network 363 controller instructs the network devices involved in the virtual 364 network to join the virtual network and allocate the required network 365 resources for the virtual network. This can be done with either PCEP 366 [RFC5440] or Netconf/YANG [RFC6241] [RFC7950] with necessary 367 extensions. The network resources are allocated in a per-segment 368 manner. In addition, a set of dedicated SIDs, e.g. prefix-SIDs and 369 adj-SIDs are allocated to represent the virtual network and the 370 network resources allocated on each network segment for this virtual 371 network. 373 In the underlay forwarding plane, there can be multiple ways of 374 partitioning and allocating a set of network resource to a virtual 375 network. For example, [FLEXE] may be used to partition the link 376 resource into different sub-channels to achieve hard isolation 377 between each other. The candidate data plane technologies to support 378 resource partitioning can be found in [I-D.ietf-teas-enhanced-vpn]. 379 The SR SIDs are used as a unified abstraction in network layer for 380 various network resource partition and allocation mechanisms in the 381 underlying forwarding plane. 383 Node-SIDs: Node-SIDs: 384 r:101 r:102 385 g:201 Adj-SIDs: g:202 386 b:301 r:1001:1G r:1001:1G b:302 387 +-----+ g:2001:2G g:2001:2G +-----+ 388 | A | b:3001:1G b:3001:1G | B |Adj-SIDs: 389 | +------------------------+ + r:1003:1G 390 Adj-SIDs +--+--+ +--+--+\g:2003:2G 391 r:1002:1G| r:1002:1G| \ 392 g:2002:2G| g:2002:2G| \ r:1001:1G 393 b:3002:3G| b:3002:2G| \g:2001:2G 394 | | \ +-----+ Node-SIDs: 395 | | \+ E | r:105 396 | | /+ | g:205 397 r:1001:1G| r:1002:1G| / +-----+ 398 g:2001:2G| g:2002:2G| /r:1002:1G 399 b:3001:3G| b:3002:2G| / g:2002:2G 400 +--+--+ +--+--+ / 401 | | | |/r:1003:1G 402 | C +------------------------+ D + g:2003:2G 403 +-----+ r:1002:1G r:1001:1G +-----+ 404 Node-SIDs: g:2002:1G g:2001:1G Node-SIDs: 405 r:103 b:3002:2G b:3001:2G r:104 406 g:203 g:204 407 b:303 b:304 409 Figure 1. SID and resource allocation for multiple virtual networks 411 Figure 1 shows an exmple of SR network to support multiple virtual 412 networks. Note that the format of the SIDs in this figure is for 413 illustration, both SR-MPLS and SRv6 can be used as the data plane. 414 In this example, three virtual networks: red (r) , green (g) and blue 415 (b) are created to carry different services. Both the red and green 416 virtual networks consist of nodes A, B, C, D, and E with all their 417 interconnecting links, whilst the blue virtual network only consists 418 of nodes A, B, C and D with all their interconnecting links. Note 419 that different virtual networks may have a set of shared nodes and 420 links. On each link, a dedicated adj-SID is allocated for each 421 virtual network it participates in. In Figure 1, the notation 422 x:nnnn:y means that in virtual network x, the adj-SID nnnn will steer 423 the packet over a link which has bandwidth y reserved for that 424 virtual network. For example, r:1002:1G in link C->D says that the 425 virtual network red has a reserved bandwidth of 1Gb/s on link C->D, 426 and will be used by packets arriving at node C with an adj-SID 1002 427 at the top of the label stack. Similarly, on each node, a dedicated 428 prefix-SID is allocated for each virtual network it participates in. 429 The adj-SIDs can be associated with different set of link resources 430 (e.g. bandwidth) allocated to different virtual networks, so that 431 the adj-SIDs can be used to steer service traffic into different set 432 of link resources in packet forwarding. The prefix-SIDs can be 433 associated with the nodal resources allocated to different virtual 434 network. In addition, the prefix-SIDs can be used to build loose SR 435 path within each virtual network, in this case it can be used by the 436 transit nodes to steer different service traffic into different set 437 of local network resources in the forwarding plane. 439 4.3. Construction of SR based Virtual Networks 441 In order to make both the network controller and network nodes aware 442 of the information of the virtual networks in the network, each 443 network node SHOULD advertise the identifiers of the virtual networks 444 it participates in, together with the group of SIDs and the 445 associated resource attributes both to other nodes in the network and 446 to the controller. This can be achieved by IGP extensions in 447 [I-D.dong-lsr-sr-enhanced-vpn] and BGP-LS extensions 448 in[I-D.dong-idr-bgpls-sr-enhanced-vpn]. 450 Based on the collected information of the virtual network topology, 451 the associated network resource and SIDs information, the controller 452 and network nodes are able to construct the SR virtual network and 453 generate the forwarding tables and entries of each virtual network 454 based on the prefix-SIDs and adj-SIDs allocated for each virtual 455 network. Unlike classic segment routing in which network resources 456 are shared by all the services, different SR virtual networks can be 457 associated with different set of resource allocated in the underlay 458 forwarding plane, so that they can be used to meet the enhanced 459 service requirement and provide the required isolation from other 460 services in the same network. 462 Figure 2 shows the SR based virtual networks created in the network 463 in Figure 1. 465 1001 1001 2001 2001 3001 3001 466 101---------102 201---------202 301---------302 467 | | \1003 | | \2003 | | 468 1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002| 469 | | 105 | | 205 | | 470 1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002| 471 | | / 1003 | | / 2003 | | 472 103---------104 203---------204 303---------304 473 1002 1001 1002 2001 3002 3001 474 Topology Red Topology Green Topology Blue 476 Figure 2. SR based virtual networks with different groups of SIDs 477 For each SR virtual network, SR paths are computed within the virtual 478 network, taking its network topology and resources as constraints. 479 The SR path can be an explicit path instantiated using SR policy 480 [I-D.ietf-spring-segment-routing-policy], in which the SID-list is 481 built only with the SIDs allocated to the virtual network. The SR 482 path can also be an IGP computed path associated with a particular 483 prefix-SID of the virtual network. Different SR paths in the same 484 virtual network would share the network resources allocated to the 485 virtual network, while SR paths in different virtual networks can be 486 steered to use different set of network resources on the shared 487 network links or nodes. 489 For example, to create an explicit path A-B-D-E in virtual network 490 red in Figure 2, the SR SID list encapsulated in the service packet 491 would be (1001, 1002, 1003). For the same explicit path A-B-D-E in 492 virtual network green, the SR segment list would be (2001, 2002, 493 2003). In the case where we wish to construct a loose path A-D-E in 494 virtual network green, the service packet SHOULD be encapsulated with 495 the SR SID list (201, 204, 205). At node A, the packet can be sent 496 towards D via either node B or C using the link and node resources 497 allocated for virtual network green. At node D the packet is 498 forwarded to E using the link and node resource allocated for virtual 499 network green. Similarly, a packet to sent via loose path A-D-E in 500 virtual network red would be encapsulated with segment list (101, 501 104, 105). In the case where an IGP computed path can meet the 502 service requirement, the packet can be simply encapsulated with the 503 node SID of egress node E in the corresponding virtual network. 505 4.4. Service to SR Virtual Network Mapping 507 Network services can be provisioned using customized SR virtual 508 networks as the underlay network. For example, different services 509 may be provisioned in different SR virtual networks, each of which 510 would use the network resources allocated to a particular virtual 511 network, so that they will not interfere with each other. In another 512 case, a group of services which have similar characteristics and 513 requirement can be provisioned in the same SR virtual network, in 514 this case the network resources allocated to the virtual network are 515 shared by these set of services, but will not be shared with other 516 services in the network. 518 4.5. Virtual Network Visibility to Customer 520 The tenants of service may request different granularity of 521 visibility to the network which deliver the service. Depending on 522 the requirement, the network can be exposed to the tenant either as a 523 virtual network, or a set of computed paths with transit nodes, or 524 simply the abstract connectivity between endpoints without any path 525 information. The visibility can be delivered through different 526 possible mechanisms, such as IGPs (e.g. IS-IS, OSPF) or BGP-LS. In 527 addition, network operator may want to restrict the visibility of the 528 information it delivers to the tenant by either hiding the transit 529 nodes between sites (and only delivering the endpoints connectivity), 530 or by hiding portions of the transit nodes (summarizing the path into 531 fewer nodes). Mechanisms such as BGP-LS allow the flexibility of the 532 advertisement of aggregated virtual network information. 534 5. Benefits of the Proposed Mechanism 536 The proposed mechanism provides several key characteristics: 538 o Flexibility: Multiple customized virtual networks can be created 539 in a shared network to meet different tenants' connectivity and 540 service requirement. Each tenant is only aware of the topology 541 and attributes of his own virtual network, and provision services 542 on the virtual network instead of the physical network. This 543 provides an efficient mechanism to support network slicing. 545 o Isolation: Each virtual network can have independent SR path 546 computation and instantiation. In addition, a virtual network can 547 be associated with a set of network resources, which can avoid 548 resource competition and performance interference from other 549 services in the network. The proposed mechanism also allows 550 resource sharing between different services in the same virtual 551 network, or between a group of services which are provisioned in 552 different virtual networks. This gives the operator and the 553 tenants the flexibility in network planning and service 554 provisioning. The performance of critical services can be further 555 ensured using the mechanisms defined in [DetNet]. 557 o Scalability: The proposed mechanism seeks to achieve a balance 558 between the state limitations of traditional end-to-end TE 559 mechanism and the lack of resource awareness in basic segment 560 routing. Following the segment routing paradigm, network 561 resources are allocated on network segments and represented as 562 SIDs, thus there is no per-flow state introduced in the network. 563 Operator can choose the granularity of resource allocation to 564 network segments. In network segments where resource is scarce 565 such that the service requirement may not always be met, the 566 proposed approach can be used to allocate specific resources to 567 the segment in a virtual network. By contrast, in other segment 568 of the network where resource is considered plentiful, the 569 resource may be shared between a number of virtual networks. The 570 decision to do this is in the hands of the operator. Because of 571 the segmented nature of the virtual network, resource aggregation 572 is easier and more flexible than RSVP-TE based approach. 574 6. Service Assurance 576 In order to provide service assurance for services provisioned in the 577 SR virtual networks, it is necessary to instrument the network at 578 multiple levels. The network operator needs to ascertain that the 579 underlay network is operating correctly. A tenant needs to ascertain 580 that their services are operating correctly. In principle these can 581 use existing techniques. These are well known problems and solutions 582 either exist or are in development to address them. 584 New work is needed to instrument the virtual networks that are 585 created for particular services. Such instrumentation needs to 586 operate without causing disruption to other services using the 587 network. Given the sensitivity of some applications, care needs to 588 be taken to ensure that the instrumentation itself does not cause 589 disruption either to the service being instrumented or to other 590 services. In case of failure or performance degradation of a service 591 path in a particular virtual network, it is necessary that either 592 local protection or end-to-end protection mechanism is used to switch 593 to another path in the same virtual network which could meet the 594 service performance requirement and does not impact other services in 595 the network. 597 7. IANA Considerations 599 This document makes no request of IANA. 601 Note to RFC Editor: this section may be removed on publication as an 602 RFC. 604 8. Security Considerations 606 The security considerations of segment routing are applicable to this 607 document. 609 The Resource-aware SIDs may be used for provisioning of SR paths or 610 virtual networks to carry traffic with latency SLAs. By disrupting 611 the latency of such traffic an attack can be directly targeted at the 612 customer application, or can be targeted at the network operator by 613 causing them to violate their SLA, triggering commercial 614 consequences. Dynamic attacks of this sort are not something that 615 networks have traditionally guarded against, and networking 616 techniques need to be developed to defend against this type of 617 attack. By rigorously policing ingress traffic and carefully 618 provisioning the resources provided to such services, this type of 619 attack can be prevented. However care needs to be taken when 620 providing shared resources, and when the network needs to be 621 reconfigured as part of ongoing maintenance or in response to a 622 failure. 624 The details of the underlay network MUST NOT be exposed to third 625 parties, to prevent attacks aimed at exploiting a shared resource. 627 9. Contributors 629 The following people contributed to the content of this document. 631 10. Acknowledgements 633 The authors would like to thank Mach Chen, Zhenbin Li, Stefano 634 Previdi, Charlie Perkins, Bruno Decraene, Loa Andersson and Alexander 635 Vainshtein for the valuable discussion and suggestions to this 636 document. 638 11. References 640 11.1. Normative References 642 [I-D.ietf-spring-segment-routing-mpls] 643 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 644 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 645 data plane", draft-ietf-spring-segment-routing-mpls-22 646 (work in progress), May 2019. 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, 650 DOI 10.17487/RFC2119, March 1997, 651 . 653 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 654 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 655 May 2017, . 657 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 658 Decraene, B., Litkowski, S., and R. Shakir, "Segment 659 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 660 July 2018, . 662 11.2. Informative References 664 [DetNet] "DetNet WG", 2016, 665 . 667 [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, 668 . 671 [I-D.dong-idr-bgpls-sr-enhanced-vpn] 672 Dong, J. and Z. Hu, "BGP-LS Extensions for Segment Routing 673 based Enhanced VPN", draft-dong-idr-bgpls-sr-enhanced- 674 vpn-00 (work in progress), November 2019. 676 [I-D.dong-lsr-sr-enhanced-vpn] 677 Dong, J., Hu, Z., and S. Bryant, "IGP Extensions for 678 Segment Routing based Enhanced VPN", draft-dong-lsr-sr- 679 enhanced-vpn-02 (work in progress), November 2019. 681 [I-D.ietf-idr-bgpls-segment-routing-epe] 682 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 683 S., and J. Dong, "BGP-LS extensions for Segment Routing 684 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 685 segment-routing-epe-19 (work in progress), May 2019. 687 [I-D.ietf-spring-segment-routing-policy] 688 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 689 P. Mattes, "Segment Routing Policy Architecture", draft- 690 ietf-spring-segment-routing-policy-06 (work in progress), 691 December 2019. 693 [I-D.ietf-spring-srv6-network-programming] 694 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 695 Matsushima, S., and Z. Li, "SRv6 Network Programming", 696 draft-ietf-spring-srv6-network-programming-06 (work in 697 progress), December 2019. 699 [I-D.ietf-teas-enhanced-vpn] 700 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 701 Framework for Enhanced Virtual Private Networks (VPN+) 702 Service", draft-ietf-teas-enhanced-vpn-03 (work in 703 progress), September 2019. 705 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 706 "Definition of the Differentiated Services Field (DS 707 Field) in the IPv4 and IPv6 Headers", RFC 2474, 708 DOI 10.17487/RFC2474, December 1998, 709 . 711 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 712 and W. Weiss, "An Architecture for Differentiated 713 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 714 . 716 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 717 Label Switching Architecture", RFC 3031, 718 DOI 10.17487/RFC3031, January 2001, 719 . 721 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 722 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 723 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 724 . 726 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 727 (TE) Extensions to OSPF Version 2", RFC 3630, 728 DOI 10.17487/RFC3630, September 2003, 729 . 731 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 732 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 733 2008, . 735 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 736 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 737 DOI 10.17487/RFC5439, February 2009, 738 . 740 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 741 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 742 DOI 10.17487/RFC5440, March 2009, 743 . 745 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 746 and A. Bierman, Ed., "Network Configuration Protocol 747 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 748 . 750 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 751 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 752 RFC 6790, DOI 10.17487/RFC6790, November 2012, 753 . 755 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 756 Previdi, "OSPF Traffic Engineering (TE) Metric 757 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 758 . 760 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 761 S. Ray, "North-Bound Distribution of Link-State and 762 Traffic Engineering (TE) Information Using BGP", RFC 7752, 763 DOI 10.17487/RFC7752, March 2016, 764 . 766 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 767 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 768 RFC 7810, DOI 10.17487/RFC7810, May 2016, 769 . 771 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 772 RFC 7950, DOI 10.17487/RFC7950, August 2016, 773 . 775 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 776 (IPv6) Specification", STD 86, RFC 8200, 777 DOI 10.17487/RFC8200, July 2017, 778 . 780 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 781 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 782 IGP Traffic Engineering Performance Metric Extensions", 783 RFC 8571, DOI 10.17487/RFC8571, March 2019, 784 . 786 Authors' Addresses 788 Jie Dong 789 Huawei Technologies 791 Email: jie.dong@huawei.com 793 Stewart Bryant 794 Futurewei Technologies 796 Email: stewart.bryant@gmail.com 798 Takuya Miyasaka 799 KDDI Corporation 801 Email: ta-miyasaka@kddi.com 802 Yongqing Zhu 803 China Telecom 805 Email: zhuyq.gd@chinatelecom.cn 807 Fengwei Qin 808 China Mobile 810 Email: qinfengwei@chinamobile.com 812 Zhenqiang Li 813 China Mobile 815 Email: li_zhenqiang@hotmail.com