idnits 2.17.1 draft-dong-spring-sr-for-enhanced-vpn-13.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 469: '... packet SHOULD be encapsulated with ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2021) is 1194 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8660' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 711, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-dong-idr-bgpls-sr-enhanced-vpn-02 == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-04 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 == Outdated reference: A later version (-04) exists of draft-xie-idr-bgpls-sr-vtn-mt-01 == Outdated reference: A later version (-03) exists of draft-xie-lsr-isis-sr-vtn-mt-02 == Outdated reference: A later version (-01) exists of draft-zhu-idr-bgpls-sr-vtn-flexalgo-00 == Outdated reference: A later version (-07) exists of draft-zhu-lsr-isis-sr-vtn-flexalgo-01 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 2 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: Informational S. Bryant 5 Expires: July 22, 2021 Futurewei Technologies 6 T. Miyasaka 7 KDDI Corporation 8 Y. Zhu 9 China Telecom 10 F. Qin 11 Z. Li 12 China Mobile 13 F. Clad 14 Cisco Systems 15 January 18, 2021 17 Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN 18 draft-dong-spring-sr-for-enhanced-vpn-13 20 Abstract 22 Segment Routing (SR) leverages the source routing paradigm. A node 23 steers a packet through an ordered list of instructions, called 24 "segments". A segment can represent topological or service based 25 instructions. A segment can further be associated with a set of 26 network resources used for executing the instruction. Such a segment 27 is called resource-aware segment. 29 Resource-aware Segment Identifiers (SIDs) may be used to build SR 30 paths with a set of reserved network resources. In addition, a group 31 of resource-aware SIDs may be used to build SR based virtual underlay 32 networks, which has customized network topology and resource 33 attributes required by one or a group of customers and/or services. 34 Such virtual networks are the SR instantiations of Virtual Transport 35 Networks (VTNs). 37 This document describes a suggested use of resource-aware SIDs to 38 build SR based VTNs. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on July 22, 2021. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Resource-Aware SIDs for VTN . . . . . . . . . . . . . . . . . 3 76 2.1. SR-MPLS based VTN . . . . . . . . . . . . . . . . . . . . 4 77 2.2. SRv6 based VTN . . . . . . . . . . . . . . . . . . . . . 4 78 2.3. VTN Identification . . . . . . . . . . . . . . . . . . . 5 79 2.4. Scalability Considerations . . . . . . . . . . . . . . . 5 80 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3.1. VTN Topology and Resource Planning . . . . . . . . . . . 6 82 3.2. VTN Network Resource and SID Allocation . . . . . . . . . 7 83 3.3. Construction of SR based VTNs . . . . . . . . . . . . . . 9 84 3.4. Mapping Service to SR based VTN . . . . . . . . . . . . . 11 85 3.5. VTN Visibility to Customer . . . . . . . . . . . . . . . 11 86 4. Characteristics of SR based VTN . . . . . . . . . . . . . . . 12 87 5. Service Assurance of VTN . . . . . . . . . . . . . . . . . . 13 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 90 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 91 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 10.2. Informative References . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 100 through an ordered list of segments. A segment is referred to by its 101 Segment Identifier (SID). With SR, explicit source routing can be 102 achieved without introducing per-path state into the network. 103 [I-D.ietf-spring-resource-aware-segments] proposes to extend SR by 104 associating SIDs with network resource attributes (e.g. bandwidth, 105 processing or storage resources). These resource-aware SIDs retain 106 their original functionality, with the additional semantics of 107 identifying the set of network resources available for the packet 108 processing action. On a network segment, multiple resource-aware 109 SIDs may be allocated, each of which is associated with a subset of 110 network resources assigned to meet the requirements of one or a group 111 of customers and/or services. 113 Once allocated, Resource-aware SIDs can be used to build SR paths 114 with a set of reserved network resources. In addition, a group of 115 resource-aware SIDs may be used to build SR based virtual networks, 116 which has customized network topology and resource attributes 117 required by one or a group of customers and/or services. Such 118 virtual networks are the SR instantiations of Virtual Transport 119 Networks (VTNs) as defined in [I-D.ietf-teas-enhanced-vpn], and can 120 be used to enable the enhanced VPN (VPN+) services. 122 This document describes a suggested use of resource-aware SIDs to 123 build SR based VTNs. Although the procedure is illustrated using SR- 124 MPLS, the proposed mechanism is applicable to both SR over MPLS data 125 plane (SR-MPLS) and SR over IPv6 data plane (SRv6). 127 2. Resource-Aware SIDs for VTN 129 A VTN is a virtual underlay network which has a specific network 130 topology and a subset of network resources allocated from the 131 physical network. 133 When SR is used as the data plane to construct VTNs in the network, 134 it is necessary to compute and instantiate the SR paths with the 135 topology and/or algorithm constraints of the VTN, and steer the 136 traffic to only use the set of network resources allocated to the 137 VTN. 139 Based on the resource-aware segments defined in 140 [I-D.ietf-spring-resource-aware-segments], a group of resource-aware 141 SIDs can be allocated to represent the network segments of one VTN. 142 These resource-aware SIDs are associated with the group of network 143 resources allocated to the VTN on network nodes and links which 144 participate in the VTN. These resource-aware SIDs can also identify 145 the network topological or functional instructions associated with 146 the VTN. 148 The resource-aware SIDs may be allocated either by a centralized 149 network controller or by network nodes. The control plane mechanisms 150 for advertising the resource-aware SIDs for VTNs can be based on 151 [RFC4915], [RFC5120] and [I-D.ietf-lsr-flex-algo] with necessary 152 extensions. This is further described in section 3.3. 154 2.1. SR-MPLS based VTN 156 This section describes a mechanism of allocating resource-aware SIDs 157 to SR-MPLS based VTNs. 159 For one IGP link, multiple Adj-SIDs are allocated, each of which is 160 associated with a VTN that link participates in, and represents a 161 subset of the link resources allocated to the VTN. For one IGP node, 162 multiple prefix-SIDs are allocated, each of which is associated with 163 a VTN which the node participates in, and identifies the set of 164 network resources allocated to the VTN on network nodes which 165 participate in the VTN. These set of resources will be used to 166 process packets which have the resource-aware SIDs as the active 167 segment. 169 In the case of multi-domain VTNs, on an inter-domain link, multiple 170 BGP peering SIDs [I-D.ietf-idr-bgpls-segment-routing-epe] are 171 allocated, each of which is associated with a VTN which spans 172 multiple domains, and represents a subset of resources allocated on 173 the inter-domain link. 175 2.2. SRv6 based VTN 177 This section describes a mechanism of allocating resource-aware SRv6 178 Locators and SIDs to SRv6 based VTN.s 180 For a network node, multiple SRv6 Locators are allocated, each of 181 which is associated with a VTN the node participates in, and 182 identifies the set of network resources allocated to the VTN on 183 network nodes which participate in the VTN. The SRv6 SIDs associated 184 with a VTN are allocated from the SID space using the VTN-specific 185 Locator as the prefix. These SRv6 SIDs can be used to represent VTN- 186 specific SRv6 functions, and can identify the set of resources used 187 by network nodes to process packets. 189 2.3. VTN Identification 191 In a simple case, each VTN can be mapped to a unique topology or 192 algorithm. Then the VTNs can be distinguished by the topology ID or 193 algorithm ID in control plane, and the resource-aware SIDs associated 194 with a VTN can be identified using the tuple as 195 described in [RFC8402]. The number of VTNs supported in a network 196 relies on the number of topologies or algorithms supported. 198 In a more complicated case, multiple VTNs may be mapped to the same 199 tuple, while each is allocated with a separate 200 set of network resources. Then a new VTN Identifier (VTN-ID) in the 201 control plane is needed to identify the VTN. The resource-aware SIDs 202 associated with different VTNs can be distinguished using VTN-IDs. 204 In the data plane, The resource-aware SIDs are used to identify the 205 VTN, and are also used to determine the forwarding instructions and 206 the set of network resources used for the packet processing action. 208 2.4. Scalability Considerations 210 Since multiple VTNs can be created in a network, and each VTN is 211 allocated with a group of resource-aware SIDs, the mechanism of SR 212 based VTNs increases the number of SIDs and SRv6 Locators needed in a 213 network. There may be some concern, especially about the SR-MPLS 214 prefix-SIDs, which are allocated from the Segment Routing Global 215 Block (SRGB). The amount of network state will also increase 216 accordingly. However, based on the SR paradigm, resource-aware SIDs 217 and the associated network state are allocated and maintained per 218 VTN, thus per-path network state is avoided in the SR network. 220 3. Procedures 222 This section describes possible procedures for creating SR based VTNs 223 and the corresponding forwarding tables and entries. Although it is 224 illustrated using SR-MPLS, the proposed mechanism is applicable to 225 both SR-MPLS and SRv6. 227 Suppose a virtual network is requested by some customer or service. 228 One of the basic requirement is that customer or service is allocated 229 with some dedicated network resource, so that it does not experience 230 unexpected interference from other services in the same network. 231 Other possible requirements may include the required topology, 232 bandwidth, latency, reliability, etc. 234 According to the received requirement, a centralized network 235 controller calculates a subset of the underlay network topology to 236 support the service. With this topology, the set of network 237 resources required on each network element is also determined. The 238 subset of network topology and network resources are the two major 239 characteristics of a VTN. Depending on the service requirement, the 240 network topology and network resource of this VTN can be dedicated 241 for an individual customer or service, or can be shared by a group of 242 customers and/or services. 244 Based on the mechanisms described in section 2, a group of resource- 245 aware SIDs can be allocated for the VTN. With SR-MPLS, it is a group 246 of prefix-SIDs and adj-SIDs which are allocated to identify the 247 network nodes and links in the VTN, and also identify the set of 248 network resources allocated on these network nodes and links for the 249 VTN. As the resource-aware SIDs can be allocated either by a 250 centralized network controller or by the network nodes, control plane 251 protocols such as IGP (e.g. IS-IS or OSPF) and BGP-LS can be used to 252 distribute the SIDs and the associated resource and topology 253 information of a VTN to other nodes in the same VTN and also to the 254 controller, so that both the network nodes and the controller can 255 generate the VTN-specific forwarding entries based on the resource- 256 aware SIDs of the VTN. The detailed control plane mechanisms and 257 possible extensions are described in separate documents and are out 258 of the scope of this document. 260 3.1. VTN Topology and Resource Planning 262 A centralized network controller can be responsible for the planning 263 of a VTN to meet the received service request. The controller needs 264 to collect the information on network connectivity, network 265 resources, network performance and any other relevant network states 266 from the underlay network. This can be done using either IGP TE 267 extensions such as [RFC5305] [RFC3630] [RFC7471] [RFC8570], and/or 268 BGP-LS [RFC7752] [RFC8571], or any other form of control plane 269 signaling. 271 Based on the information collected from the underlay network, the 272 controller obtains the underlay network topology and the information 273 about the allocated and available network resources. When a service 274 request is received, the controller determines the subset of the 275 network topology, and the set of the resources needed on each network 276 segment (e.g. links and nodes) in the sub-topology to meet the 277 service requirements, whilst maintaining the needs of the existing 278 services that are using the same network. The subset of the network 279 topology and network resources will be used to constitute a VTN, and 280 will be used as the virtual underlay network of the requested 281 service. 283 3.2. VTN Network Resource and SID Allocation 285 According to the result of VTN planning, the network controller 286 instructs the set of network nodes involved to join the VTN and 287 allocate the required set of network resources for the VTN. This may 288 be done with PCEP [RFC5440], Netconf/YANG [RFC6241] [RFC7950] or with 289 any other control or management plane mechanism with necessary 290 extensions. Thus, the controller not only allocates the resources to 291 the newly computed VTN but also keeps track of the remaining 292 available resources in order to cope with subsequent VTN requests. 294 On each network node involved in the VTN, a set of network resources 295 (e.g. link bandwidth) are allocated to the VTN. Such set of network 296 resources can be dedicated for the processing of traffic in that VTN, 297 and cannot be used by traffic in other VTNs. Note it is also 298 possible that a group of VTNs may share a set of network resources on 299 some network segments. A group of resource-aware SIDs, such as 300 prefix-SIDs and adj-SIDs are allocated to identify both the network 301 segments and the set of resources allocated on the network segments 302 for the VTN. Such group of resource-aware SIDs, e.g. prefix-SIDs and 303 adj-SIDs are used as the data plane identifiers of the nodes and 304 links in the VTN. 306 In the underlying forwarding plane, there can be multiple ways of 307 allocating a subset of network resources to a VTN. The candidate 308 data plane technologies to support resource partitioning or 309 reservation can be found in [I-D.ietf-teas-enhanced-vpn]. The 310 resource-aware SIDs are considered as abstract data plane identifiers 311 in the network layer, which can work with various network resource 312 partitioning or reservation mechanisms in the underlying forwarding 313 plane. 315 Prefix-SIDs: Prefix-SIDs: 316 r:101 r:102 317 g:201 Adj-SIDs: g:202 318 b:301 r:1001:1G r:1001:1G b:302 319 +-----+ g:2001:2G g:2001:2G +-----+ 320 | A | b:3001:1G b:3001:1G | B |Adj-SIDs: 321 | +------------------------+ + r:1003:1G 322 Adj-SIDs +--+--+ +--+--+\g:2003:2G 323 r:1002:1G| r:1002:1G| \ 324 g:2002:2G| g:2002:2G| \ r:1001:1G 325 b:3002:3G| b:3002:2G| \g:2001:2G 326 | | \ +-----+Prefix-SIDs: 327 | | \+ E | r:105 328 | | /+ | g:205 329 r:1001:1G| r:1002:1G| / +-----+ 330 g:2001:2G| g:2002:2G| /r:1002:1G 331 b:3001:3G| b:3002:2G| / g:2002:2G 332 +--+--+ +--+--+ / 333 | | | |/r:1003:1G 334 | C +------------------------+ D + g:2003:2G 335 +-----+ r:1002:1G r:1001:1G +-----+ 336 Prefix-SIDs: g:2002:1G g:2001:1G Prefix-SIDs: 337 r:103 b:3002:2G b:3001:2G r:104 338 g:203 g:204 339 b:303 b:304 341 Figure 1. SID and resource allocation for multiple VTNs 343 Figure 1 shows an example of providing multiple VTNs in an SR based 344 network. Note that the format of the SIDs in this figure is for 345 illustration, both SR-MPLS and SRv6 can be used as the data plane. 346 In this example, three VTNs: red (r) , green (g) and blue (b) are 347 created to carry traffic of different customers or services. Both 348 the red and green VTNs consist of nodes A, B, C, D, and E with all 349 their interconnecting links, whilst the blue VTN only consists of 350 nodes A, B, C and D with all their interconnecting links. Note that 351 different VTNs may have a set of shared nodes and links. On each 352 node, a resource-aware prefix-SID is allocated for each VTN it 353 participates in. And on each link, a resource-aware adj-SID is 354 allocated for each VTN it participates in. 356 In Figure 1, the notation x:nnnn:y means that in VTN x, the adj-SID 357 nnnn will steer the packet over a link which has bandwidth y reserved 358 for that VTN. For example, r:1002:1G in link C->D says that the VTN 359 red has a reserved bandwidth of 1Gb/s on link C->D, and will be used 360 by packets arriving at node C with an adj-SID 1002 at the top of the 361 label stack. Similarly, on each node, a resource-aware prefix-SID is 362 allocated for each VTN it participates in. Each resource-aware adj- 363 SID can be associated with a set of link resources (e.g. bandwidth) 364 allocated to different VTNs, so that different adj-SIDs can be used 365 to steer service traffic into different set of link resources in 366 packet forwarding. A resource-aware prefix-SIDs in a VTN can be 367 associated with the set of network resources allocated to this VTN on 368 each involved network node and link. Thus the prefix-SIDs can be 369 used to build loose SR path within a VTN, and can be used by the 370 transit nodes to steer traffic into the set of local network 371 resources allocated to the VTN. 373 3.3. Construction of SR based VTNs 375 The network controller needs to obtain the information of all the 376 VTNs in the network it oversees, including the resource-aware SIDs 377 and their associated network resources and topology information. 378 Based on this information, the controller can have a global view of 379 the VTN topology, network resources and the associated SIDs, so as to 380 perform VTN-specific explicit path computation, taking both the 381 topology and resource constraints of the VTN into consideration, and 382 use the resource-aware SIDs to build the SID list for the explicit 383 path. The controller may also compute the shortest paths in the VTN 384 based on the resource-aware prefix-SIDs. 386 The network nodes also need to obtain the information of the VTNs 387 they participate in, including the resource-aware SIDs and their 388 associated network resources and topology information. Based on the 389 collected information, the network nodes which are the headend of a 390 path can perform VTN-specific path computation, and build the SID 391 list using the collected resource-aware adj-SIDs and prefix-SIDs. 392 The network nodes also need to generate the forwarding entries for 393 the resource-aware prefix-SIDs in each VTN they participates in, and 394 associate these forwarding entries with the set of local network 395 resources (e.g. a set of bandwidth on the outgoing interface) 396 allocated to the corresponding VTN. 398 Thus each network node needs to advertise the VTNs it participates 399 in, the group of resource-aware SIDs allocated to each VTN, and the 400 resource attributes (e.g. bandwidth) associated with the resource- 401 aware SIDs in the network. Each resource-aware adj-SID is advertised 402 with the set of associated link resources, and each resource-aware 403 prefix-SID is advertised with the identifier of the associated VTN, 404 as all the prefix-SIDs in a VTN are associated with the same set of 405 network resources allocated to the VTN. Note as described in section 406 2.3, the VTN can be identified in the control plane either by 407 existing IDs, or a new VTN ID. 409 The IGP mechanisms which reuse the existing IDs such as Multi- 410 Topology [RFC5120] or Flex-Algo [I-D.ietf-lsr-flex-algo] as the 411 identifier of VTNs, and distribute the resource-aware SIDs and the 412 associated topology and resource information are described in 413 [I-D.xie-lsr-isis-sr-vtn-mt] and [I-D.zhu-lsr-isis-sr-vtn-flexalgo] 414 respectively. The corresponding BGP-LS mechanisms which can be used 415 to distribute both the intra-domain VTN information and the inter- 416 domain VTN-specfic link information to the controller are described 417 in [I-D.xie-idr-bgpls-sr-vtn-mt] and 418 [I-D.zhu-idr-bgpls-sr-vtn-flexalgo] respectively. Note that with 419 these mechanisms, the number of VTNs supported relies on the number 420 of topologies or algorithms supported. 422 The IGP mechanisms described in [I-D.dong-lsr-sr-enhanced-vpn] 423 introduce a new VTN-ID in control plane, so that multiple VTNs can be 424 mapped to the same tuple, while each VTN can 425 have different resource attributes. This allows flexible combination 426 of network topology and network resources attributes to build a large 427 number of VTNs with a relatively small number of topologies or 428 algorithms. The corresponding BGP-LS mechanisms which can be used to 429 distribute the intra-domain VTN information and the inter-domain VTN- 430 specific link information to the controller are described in 431 [I-D.dong-idr-bgpls-sr-enhanced-vpn]. 433 Figure 2 shows the three SR based VTNs created in the network in 434 Figure 1. 436 1001 1001 2001 2001 3001 3001 437 101---------102 201---------202 301---------302 438 | | \1003 | | \2003 | | 439 1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002| 440 | | 105 | | 205 | | 441 1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002| 442 | | / 1003 | | / 2003 | | 443 103---------104 203---------204 303---------304 444 1002 1001 1002 2001 3002 3001 445 VTN Red VTN Green VTN Blue 447 Figure 2. SR based VTNs with different groups of SIDs 449 For each SR based VTN, SR paths are computed within the VTN, taking 450 the VTN topology and resources as constraints. The SR path can be an 451 explicit path instantiated using SR policy 452 [I-D.ietf-spring-segment-routing-policy], in which the SID-list is 453 built only with the SIDs allocated to the VTN. The SR path can also 454 be an IGP computed path associated with a prefix-SID or SRv6 End SID 455 allocated by a node for the VTN, the IGP path computation is also 456 based on the topology and/or algorithm constraints of the VTN. 457 Different SR paths in the same VTN may use shared network resources 458 when they use the same resource-aware SIDs allocated to the VTN, 459 while SR paths in different VTNs are steered to use different set of 460 network resources even when they traverse the same network links or 461 nodes. These VTN-specific SR paths need to be installed in the 462 corresponding forwarding tables. 464 For example, to create an explicit path A-B-D-E in VTN red in 465 Figure 2, the SR SID-list encapsulated in the service packet would be 466 (1001, 1002, 1003). For the same explicit path A-B-D-E in VTN green, 467 the SR segment list would be (2001, 2002, 2003). In the case where 468 we wish to construct a loose path A-D-E in VTN green, the service 469 packet SHOULD be encapsulated with the SR SID-list (201, 204, 205). 470 At node A, the packet can be sent towards D via either node B or C 471 using the network resources allocated by these nodes for VTN green. 472 At node D the packet is forwarded to E using the link and node 473 resource allocated for VTN green. Similarly, a packet to be sent via 474 loose path A-D-E in VTN red would be encapsulated with segment list 475 (101, 104, 105). In the case where an IGP computed path can meet the 476 service requirement, the packet can be simply encapsulated with the 477 prefix-SID of egress node E in the corresponding VTN. 479 3.4. Mapping Service to SR based VTN 481 Network services can be provisioned using SR based VTNs as the 482 virtual underlay networks. For example, different services may be 483 provisioned in different SR based VTNs, each of which would use the 484 network resources allocated to the VTN, so that their data traffic 485 will not interfere with each other. In another case, a group of 486 services which have similar characteristics and requirements may be 487 provisioned in the same VTN, in this case the network resources 488 allocated to the VTN are only shared among this group of services, 489 but will not be shared with other services in the network. The 490 steering of service traffic to SR based VTNs can be based on either 491 local policy or the mechanisms as defined in 492 [I-D.ietf-spring-segment-routing-policy]. 494 3.5. VTN Visibility to Customer 496 VTNs can be used by network operators to organize and split their 497 network infrastructure into different virtual underlay networks for 498 different customers or services. Some customers may also request 499 different granularity of visibility to the VTN which is used to 500 deliver the service. Depending on the requirement, VTN can be 501 exposed to the customer either as a virtual network with both the 502 edge nodes and the intermediate nodes, or a set of paths with some of 503 the transit nodes, or simply a set of virtual connections between the 504 endpoints without any transit node information. The visibility may 505 be delivered through different possible mechanisms, such as IGPs 506 (e.g. IS-IS, OSPF), BGP-LS or Netconf/YANG. On the other hand, 507 network operators may want to restrict the visibility of the underlay 508 network information it delivers to the customer by either hiding the 509 transit nodes between sites (and only delivering the endpoints 510 connectivity), or by hiding portions of the transit nodes 511 (summarizing the path into fewer nodes). Mechanisms such as BGP-LS 512 allow the flexibility of the advertisement of aggregated virtual 513 network information. 515 4. Characteristics of SR based VTN 517 The proposed mechanism provides several key characteristics: 519 o Customization: Different customized VTNs can be created in a 520 shared network to meet different customers' connectivity and 521 service requirement. Each customer is only aware of the topology 522 and attributes of his own VTN, and provision services on the VTN 523 instead of the shared physical network. This provides an 524 practical mechanism to support network slicing. 526 o Resource Isolation: The computation and instantiation of SR paths 527 in one VTN can be independent from other VTNs or other services in 528 the network. In addition, a VTN can be associated with a set of 529 dedicated network resources, which can avoid resource competition 530 and performance interference from other VTNs or other services in 531 the network. The proposed mechanism also allows resource sharing 532 between different service flows of the same customer, or between a 533 group of services which are provisioned in the same VTN. This 534 gives the operators and the customers the flexibility in network 535 planning and service provisioning. In a VTN, the performance of 536 critical services can be further ensured using other mechanisms, 537 e.g. those as defined in [DetNet]. 539 o Scalability: The introduction of resource aware SIDs for different 540 VTNs would increase the amount of SIDs and state in the network. 541 While the increased network state is considered an inevitable 542 price in meeting the requirements of some customers or services, 543 the SR based VTN mechanism seeks to achieve a balance between the 544 state limitations of traditional end-to-end TE mechanism and the 545 lack of resource awareness in classic segment routing. Following 546 the segment routing paradigm, network resources are allocated on 547 network segments in a per VTN manner and represented as SIDs, this 548 ensures that there is no per-path state introduced in the network. 549 In addition, operators can choose the granularity of resource 550 allocation on different network segments. In network segments 551 where resource is scarce such that the service requirement may not 552 always be met, the proposed approach can be used to allocate a set 553 of resources to a VTN which contains such network segment to avoid 554 possible competition. By contrast, in other segment of the 555 network where resource is considered plentiful, the resource may 556 be shared between a number of VTNs. The decision to do this is in 557 the hands of the operator. Because of the segmented nature of the 558 SR based VTN, resource aggregation is easier and more flexible 559 than RSVP-TE based approach. 561 5. Service Assurance of VTN 563 In order to provide assurance for services provisioned in the SR 564 based VTNs, it is necessary to instrument the network at multiple 565 levels, e.g. in both the underlay network level and the VTN level. 566 The operator or the customer may also monitor and measure the 567 performance of the services carried by the VTN. In principle these 568 can be achieved using existing or in development techniques in IETF. 569 The detailed mechanisms are out of the scope of this document. 571 In case of failure or service performance degradation happens in a 572 VTN, it is necessary that some recovery mechanisms, e.g. local 573 protection or end-to-end protection mechanism is used to switch the 574 traffic to another path in the same VTN which could meet the service 575 performance requirement. Care must be taken that the service or path 576 recovery mechanism in one VTN does not impact other VTNs in the same 577 network. 579 6. IANA Considerations 581 This document makes no request of IANA. 583 Note to RFC Editor: this section may be removed on publication as an 584 RFC. 586 7. Security Considerations 588 The security considerations of segment routing and resource-aware 589 SIDs are applicable to this document. 591 The SR VTNs may be used carry services with specific SLA parameters. 592 An attack can be directly targeted at the customer application by 593 disrupting the SLA, and can be targeted at the network operator by 594 causing them to violate their SLA, triggering commercial 595 consequences. By rigorously policing ingress traffic and carefully 596 provisioning the resources provided to the VTN, this type of attack 597 can be prevented. However care needs to be taken when shared 598 resources are provided between VTNs at some point in the network, and 599 when the network needs to be reconfigured as part of ongoing 600 maintenance or in response to a failure. 602 The details of the underlying network should not be exposed to third 603 parties, some abstraction would be needed, this is also to prevent 604 attacks aimed at exploiting a shared resource between VTNs. 606 8. Contributors 608 Zhenbin Li 609 Email: lizhenbin@huawei.com 611 Zhibo Hu 612 Email: huzhibo@huawei.com 614 9. Acknowledgements 616 The authors would like to thank Mach Chen, Stefano Previdi, Charlie 617 Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein, Joel 618 Halpern, James Guichard and Adrian Farrel for the valuable discussion 619 and suggestions to this document. 621 10. References 623 10.1. Normative References 625 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 626 Decraene, B., Litkowski, S., and R. Shakir, "Segment 627 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 628 July 2018, . 630 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 631 Decraene, B., Litkowski, S., and R. Shakir, "Segment 632 Routing with the MPLS Data Plane", RFC 8660, 633 DOI 10.17487/RFC8660, December 2019, 634 . 636 10.2. Informative References 638 [DetNet] "DetNet WG", 2016, 639 . 641 [I-D.dong-idr-bgpls-sr-enhanced-vpn] 642 Dong, J., Hu, Z., Li, Z., Tang, X., and R. Pang, "BGP-LS 643 Extensions for Segment Routing based Enhanced VPN", draft- 644 dong-idr-bgpls-sr-enhanced-vpn-02 (work in progress), June 645 2020. 647 [I-D.dong-lsr-sr-enhanced-vpn] 648 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 649 and S. Bryant, "IGP Extensions for Segment Routing based 650 Enhanced VPN", draft-dong-lsr-sr-enhanced-vpn-04 (work in 651 progress), June 2020. 653 [I-D.ietf-idr-bgpls-segment-routing-epe] 654 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 655 S., and J. Dong, "BGP-LS extensions for Segment Routing 656 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 657 segment-routing-epe-19 (work in progress), May 2019. 659 [I-D.ietf-lsr-flex-algo] 660 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 661 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 662 algo-13 (work in progress), October 2020. 664 [I-D.ietf-spring-resource-aware-segments] 665 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 666 Z., and F. Clad, "Introducing Resource Awareness to SR 667 Segments", draft-ietf-spring-resource-aware-segments-00 668 (work in progress), July 2020. 670 [I-D.ietf-spring-segment-routing-policy] 671 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 672 P. Mattes, "Segment Routing Policy Architecture", draft- 673 ietf-spring-segment-routing-policy-09 (work in progress), 674 November 2020. 676 [I-D.ietf-spring-srv6-network-programming] 677 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 678 Matsushima, S., and Z. Li, "SRv6 Network Programming", 679 draft-ietf-spring-srv6-network-programming-28 (work in 680 progress), December 2020. 682 [I-D.ietf-teas-enhanced-vpn] 683 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 684 Framework for Enhanced Virtual Private Networks (VPN+) 685 Service", draft-ietf-teas-enhanced-vpn-06 (work in 686 progress), July 2020. 688 [I-D.xie-idr-bgpls-sr-vtn-mt] 689 Xie, C., Li, C., Dong, J., and Z. Li, "BGP-LS with Multi- 690 topology for Segment Routing based Virtual Transport 691 Networks", draft-xie-idr-bgpls-sr-vtn-mt-01 (work in 692 progress), July 2020. 694 [I-D.xie-lsr-isis-sr-vtn-mt] 695 Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi- 696 Topology (MT) for Segment Routing based Virtual Transport 697 Network", draft-xie-lsr-isis-sr-vtn-mt-02 (work in 698 progress), October 2020. 700 [I-D.zhu-idr-bgpls-sr-vtn-flexalgo] 701 Zhu, Y., Dong, J., and Z. Hu, "BGP-LS with Flex-Algo for 702 Segment Routing based Virtual Transport Networks", draft- 703 zhu-idr-bgpls-sr-vtn-flexalgo-00 (work in progress), March 704 2020. 706 [I-D.zhu-lsr-isis-sr-vtn-flexalgo] 707 Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment 708 Routing based VTN", draft-zhu-lsr-isis-sr-vtn-flexalgo-01 709 (work in progress), September 2020. 711 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 712 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 713 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 714 . 716 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 717 (TE) Extensions to OSPF Version 2", RFC 3630, 718 DOI 10.17487/RFC3630, September 2003, 719 . 721 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 722 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 723 RFC 4915, DOI 10.17487/RFC4915, June 2007, 724 . 726 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 727 Topology (MT) Routing in Intermediate System to 728 Intermediate Systems (IS-ISs)", RFC 5120, 729 DOI 10.17487/RFC5120, February 2008, 730 . 732 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 733 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 734 2008, . 736 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 737 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 738 DOI 10.17487/RFC5440, March 2009, 739 . 741 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 742 and A. Bierman, Ed., "Network Configuration Protocol 743 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 744 . 746 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 747 Previdi, "OSPF Traffic Engineering (TE) Metric 748 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 749 . 751 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 752 S. Ray, "North-Bound Distribution of Link-State and 753 Traffic Engineering (TE) Information Using BGP", RFC 7752, 754 DOI 10.17487/RFC7752, March 2016, 755 . 757 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 758 RFC 7950, DOI 10.17487/RFC7950, August 2016, 759 . 761 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 762 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 763 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 764 2019, . 766 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 767 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 768 IGP Traffic Engineering Performance Metric Extensions", 769 RFC 8571, DOI 10.17487/RFC8571, March 2019, 770 . 772 Authors' Addresses 774 Jie Dong 775 Huawei Technologies 777 Email: jie.dong@huawei.com 779 Stewart Bryant 780 Futurewei Technologies 782 Email: stewart.bryant@gmail.com 783 Takuya Miyasaka 784 KDDI Corporation 786 Email: ta-miyasaka@kddi.com 788 Yongqing Zhu 789 China Telecom 791 Email: zhuyq8@chinatelecom.cn 793 Fengwei Qin 794 China Mobile 796 Email: qinfengwei@chinamobile.com 798 Zhenqiang Li 799 China Mobile 801 Email: li_zhenqiang@hotmail.com 803 Francois Clad 804 Cisco Systems 806 Email: fclad@cisco.com