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