idnits 2.17.00 (12 Aug 2021) /tmp/idnits34957/draft-ietf-spring-sr-for-enhanced-vpn-02.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 document date (6 March 2022) is 69 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3209' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 773, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-spring-resource-aware-segments-03 == Outdated reference: A later version (-10) exists of draft-ietf-teas-enhanced-vpn-09 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-flex-algo-18 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-04) exists of draft-zhu-lsr-isis-sr-vtn-flexalgo-03 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: 7 September 2022 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 6 March 2022 17 Segment Routing based Virtual Transport Network (VTN) for Enhanced VPN 18 draft-ietf-spring-sr-for-enhanced-vpn-02 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 have 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 7 September 2022. 57 Copyright Notice 59 Copyright (c) 2022 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 (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Resource-Aware SIDs for VTN . . . . . . . . . . . . . . . . . 3 75 2.1. SR-MPLS based VTN . . . . . . . . . . . . . . . . . . . . 4 76 2.2. SRv6 based VTN . . . . . . . . . . . . . . . . . . . . . 4 77 2.3. VTN Identification . . . . . . . . . . . . . . . . . . . 5 78 2.4. Scalability Considerations . . . . . . . . . . . . . . . 5 79 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3.1. VTN Topology and Resource Planning . . . . . . . . . . . 6 81 3.2. VTN Network Resource and SID Allocation . . . . . . . . . 7 82 3.3. Construction of SR based VTNs . . . . . . . . . . . . . . 9 83 3.4. Mapping Service to SR based VTN . . . . . . . . . . . . . 11 84 3.5. VTN Visibility to Customers . . . . . . . . . . . . . . . 11 85 4. Characteristics of SR based VTNs . . . . . . . . . . . . . . 12 86 5. Service Assurance of VTNs . . . . . . . . . . . . . . . . . . 13 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 93 10.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 99 through an ordered list of segments. A segment is referred to by its 100 Segment Identifier (SID). With SR, explicit source routing can be 101 achieved without introducing per-path state into the network. 102 [I-D.ietf-spring-resource-aware-segments] extends SR by associating 103 SIDs with network resource attributes (e.g., bandwidth, processing or 104 storage resources). These resource-aware SIDs retain their original 105 functionality, with the additional semantics of identifying the set 106 of network resources available for the packet processing action. On 107 a network segment, multiple resource-aware SIDs may be allocated, 108 each of which is associated with a subset of network resources 109 assigned to meet the requirements of one or a group of customers and/ 110 or services. 112 Once allocated, Resource-aware SIDs can be used to build SR paths 113 with a set of reserved network resources. In addition, a group of 114 resource-aware SIDs may be used to build SR based virtual networks, 115 which have customized network topology and resource attributes 116 required by one or a group of customers and/or services. Such 117 virtual networks are the SR instantiations of Virtual Transport 118 Networks (VTNs) as defined in [I-D.ietf-teas-enhanced-vpn], and can 119 be used to enable the enhanced VPN (VPN+) services. 121 This document describes a suggested use of resource-aware SIDs to 122 build SR based VTNs. Although the procedure is illustrated using SR- 123 MPLS, this mechanism is applicable to both SR over MPLS data plane 124 (SR-MPLS) [RFC8660] and SR over IPv6 data plane (SRv6) [RFC8986]. 126 2. Resource-Aware SIDs for VTN 128 A VTN is a virtual underlay network which has a specific network 129 topology and a subset of network resources allocated from the 130 physical network. 132 When SR is used as the data plane to construct VTNs in the network, 133 it is necessary to compute and instantiate the SR paths with the 134 topology and/or algorithm constraints of the VTN, and steer the 135 traffic to only use the set of network resources allocated to the 136 VTN. 138 Based on the resource-aware segments defined in 139 [I-D.ietf-spring-resource-aware-segments], a group of resource-aware 140 SIDs can be allocated to represent the network segments of one VTN. 141 These resource-aware SIDs are associated with the group of network 142 resources allocated to the VTN on network nodes and links which 143 participate in the VTN. These resource-aware SIDs can also identify 144 the network topological or functional instructions associated with 145 the VTN. 147 The resource-aware SIDs may be allocated either by a centralized 148 network controller or by network nodes. The control plane mechanisms 149 for advertising the resource-aware SIDs for VTNs can be based on 150 [RFC4915], [RFC5120] and [I-D.ietf-lsr-flex-algo] with necessary 151 extensions. This is further described in section 3.3. 153 2.1. SR-MPLS based VTN 155 This section describes a mechanism of allocating resource-aware SIDs 156 to SR-MPLS based VTNs. 158 For one IGP link, multiple Adj-SIDs are allocated, each of which is 159 associated with a VTN that link participates in, and represents a 160 subset of the link resources allocated to the VTN. For one IGP node, 161 multiple prefix-SIDs are allocated, each of which is associated with 162 a VTN which the node participates in, and identifies the set of 163 network resources allocated to the VTN on network nodes which 164 participate in the VTN. These set of resources will be used to 165 process packets which have the resource-aware SIDs as the active 166 segment. 168 In the case of multi-domain VTNs, on an inter-domain link, multiple 169 BGP peering SIDs [RFC9086] are allocated, each of which is associated 170 with a VTN which spans multiple domains, and represents a subset of 171 resources allocated on the inter-domain link. 173 2.2. SRv6 based VTN 175 This section describes a mechanism of allocating resource-aware SRv6 176 Locators and SIDs to SRv6 based VTNs. 178 For a network node, multiple SRv6 Locators are allocated, each of 179 which is associated with a VTN the node participates in, and 180 identifies the set of network resources allocated to the VTN on 181 network nodes which participate in the VTN. The SRv6 SIDs associated 182 with a VTN are allocated from the SID space using the VTN-specific 183 Locator as the prefix. These SRv6 SIDs can be used to represent VTN- 184 specific SRv6 functions, and can identify the set of resources used 185 by network nodes to process packets. 187 2.3. VTN Identification 189 In a simple case, each VTN can be mapped to a unique topology or 190 algorithm. Then the VTNs can be distinguished by the topology ID or 191 algorithm ID in control plane, and the resource-aware SIDs associated 192 with a VTN can be identified using the tuple as 193 described in [RFC8402]. In this case, the number of VTNs supported 194 in a network relies on the number of topologies or algorithms 195 supported. 197 In a more complicated case, multiple VTNs may be mapped to the same 198 tuple, while each is allocated with a separate 199 set of network resources. Then a new VTN identifier (VTN-ID) in the 200 control plane is needed to identify the VTN. The resource-aware SIDs 201 associated with different VTNs can be distinguished using VTN-IDs in 202 the control plane. 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. In 219 the control plane, the amount of information to be distributed for 220 different VTNs may also become a concern for the IGP protocols. The 221 scalability of resource-aware SIDs based VTNs are further analysed in 222 [I-D.dong-teas-nrp-scalability]. 224 3. Procedures 226 This section describes possible procedures for creating SR based VTNs 227 and the corresponding forwarding tables and entries. Although it is 228 illustrated using SR-MPLS, this mechanism is applicable to both SR- 229 MPLS and SRv6. 231 Suppose a virtual network is requested by some customer or service. 232 One of the basic requirement is that customer or service is allocated 233 with some dedicated network resource, so that it does not experience 234 unexpected interference from other services in the same network. 235 Other possible requirements may include the required topology, 236 bandwidth, latency, reliability, etc. 238 According to the received requirement, a centralized network 239 controller calculates a subset of the underlay network topology to 240 support the service. With this topology, the set of network 241 resources required on each network element is also determined. The 242 subset of network topology and network resources are the two major 243 characteristics of a VTN. Depending on the service requirement, the 244 network topology and network resource of this VTN can be dedicated 245 for an individual customer or service, or can be shared by a group of 246 customers and/or services. 248 Based on the mechanisms described in section 2, a group of resource- 249 aware SIDs can be allocated for the VTN. With SR-MPLS, it is a group 250 of prefix-SIDs and adj-SIDs which are allocated to identify the 251 network nodes and links in the VTN, and also identify the set of 252 network resources allocated on these network nodes and links for the 253 VTN. As the resource-aware SIDs can be allocated either by a 254 centralized network controller or by the network nodes, control plane 255 protocols such as IGP (e.g., IS-IS or OSPF) and BGP-LS can be used to 256 distribute the SIDs and the associated resource and topology 257 information of a VTN to other nodes in the same VTN and also to the 258 controller, so that both the network nodes and the controller can 259 generate the VTN-specific forwarding table or forwarding entries 260 based on the resource-aware SIDs of the VTN. The detailed control 261 plane mechanisms and possible extensions are described in the 262 accompanying documents and are out of the scope of this document. 264 3.1. VTN Topology and Resource Planning 266 A centralized network controller can be responsible for the planning 267 of a VTN to meet the received service request. The controller needs 268 to collect the information on network connectivity, network 269 resources, network performance and any other relevant network states 270 from the underlay network. This can be done using either IGP TE 271 extensions such as [RFC5305] [RFC3630] [RFC7471] [RFC8570], and/or 272 BGP-LS [RFC7752] [RFC8571], or any other form of control plane 273 signaling. 275 Based on the information collected from the underlay network, the 276 controller obtains the underlay network topology and the information 277 about the allocated and available network resources. When a service 278 request is received, the controller determines the subset of the 279 network topology, and the set of the resources needed on each network 280 segment (e.g., links and nodes) in the sub-topology to meet the 281 service requirements, whilst maintaining the needs of the existing 282 services that are using the same network. The subset of the network 283 topology and network resources will be used to constitute a VTN, and 284 will be used as the virtual underlay network of the requested 285 service. 287 3.2. VTN Network Resource and SID Allocation 289 According to the result of VTN planning, the network controller 290 instructs the set of network nodes involved to join a specific VTN 291 and allocate the required set of network resources for the VTN. This 292 may be done with Netconf/YANG [RFC6241] [RFC7950] or with any other 293 control or management plane mechanism with necessary extensions. 294 Thus, the controller not only allocates the resources to the newly 295 computed VTN but also keeps track of the remaining available 296 resources in order to cope with subsequent VTN requests. 298 On each network node involved in the VTN, a set of network resources 299 (e.g., link bandwidth) are allocated to the VTN. Such set of network 300 resources can be dedicated for the processing of traffic in that VTN, 301 and cannot be used by traffic in other VTNs. Note it is also 302 possible that a group of VTNs may share a set of network resources on 303 some network segments. A group of resource-aware SIDs, such as 304 prefix-SIDs and adj-SIDs are allocated to identify both the network 305 segments and the set of resources allocated on the network segments 306 for the VTN. Such group of resource-aware SIDs, e.g., prefix-SIDs 307 and adj-SIDs are used as the data plane identifiers of the nodes and 308 links in the VTN. 310 In the underlying forwarding plane, there can be multiple ways of 311 allocating a subset of network resources to a VTN. The candidate 312 data plane technologies to support resource partitioning or 313 reservation can be found in [I-D.ietf-teas-enhanced-vpn]. The 314 resource-aware SIDs are considered as abstract data plane identifiers 315 in the network layer, which can work with various network resource 316 partitioning or reservation mechanisms in the underlying forwarding 317 plane. 319 Prefix-SIDs: Prefix-SIDs: 320 r:101 r:102 321 g:201 Adj-SIDs: g:202 322 b:301 r:1001:1G r:1001:1G b:302 323 +-----+ g:2001:2G g:2001:2G +-----+ 324 | A | b:3001:1G b:3001:1G | B |Adj-SIDs: 325 | +------------------------+ + r:1003:1G 326 Adj-SIDs +--+--+ +--+--+\g:2003:2G 327 r:1002:1G| r:1002:1G| \ 328 g:2002:2G| g:2002:2G| \ r:1001:1G 329 b:3002:3G| b:3002:2G| \g:2001:2G 330 | | \ +-----+Prefix-SIDs: 331 | | \+ E | r:105 332 | | /+ | g:205 333 r:1001:1G| r:1002:1G| / +-----+ 334 g:2001:2G| g:2002:2G| /r:1002:1G 335 b:3001:3G| b:3002:2G| / g:2002:2G 336 +--+--+ +--+--+ / 337 | | | |/r:1003:1G 338 | C +------------------------+ D + g:2003:2G 339 +-----+ r:1002:1G r:1001:1G +-----+ 340 Prefix-SIDs: g:2002:1G g:2001:1G Prefix-SIDs: 341 r:103 b:3002:2G b:3001:2G r:104 342 g:203 g:204 343 b:303 b:304 345 Figure 1. SID and resource allocation for multiple VTNs 347 Figure 1 shows an example of providing multiple VTNs in an SR based 348 network. Note that the format of the SIDs in this figure is for 349 illustration, both SR-MPLS and SRv6 can be used as the data plane. 350 In this example, three VTNs: red (r) , green (g) and blue (b) are 351 created to carry traffic of different customers or services. Both 352 the red and green VTNs consist of nodes A, B, C, D, and E with all 353 their interconnecting links, whilst the blue VTN only consists of 354 nodes A, B, C and D with all their interconnecting links. Note that 355 different VTNs may have a set of shared nodes and links. On each 356 node, a resource-aware prefix-SID is allocated for each VTN it 357 participates in. And on each link, a resource-aware adj-SID is 358 allocated for each VTN it participates in. 360 In Figure 1, the notation x:nnnn:y means that in VTN x, the adj-SID 361 nnnn will steer the packet over a link which has bandwidth y reserved 362 for that VTN. For example, r:1002:1G in link C->D says that the VTN 363 red has a reserved bandwidth of 1Gb/s on link C->D, and will be used 364 by packets arriving at node C with an adj-SID 1002 at the top of the 365 label stack. Similarly, on each node, a resource-aware prefix-SID is 366 allocated for each VTN it participates in. Each resource-aware adj- 367 SID can be associated with a set of link resources (e.g., bandwidth) 368 allocated to different VTNs, so that different adj-SIDs can be used 369 to steer service traffic into different set of link resources in 370 packet forwarding. A resource-aware prefix-SIDs in a VTN can be 371 associated with the set of network resources allocated to this VTN on 372 each involved network node and link. Thus the prefix-SIDs can be 373 used to build loose SR path within a VTN, and can be used by the 374 transit nodes to steer traffic into the set of local network 375 resources allocated to the VTN. 377 3.3. Construction of SR based VTNs 379 The network controller needs to obtain the information of all the 380 VTNs in the network it oversees, including the resource-aware SIDs 381 and their associated network resources and topology information. 382 Based on this information, the controller can have a global view of 383 the VTN topology, network resources and the associated SIDs, so as to 384 perform VTN-specific explicit path computation, taking both the 385 topology and resource constraints of the VTN into consideration, and 386 use the resource-aware SIDs to build the SID list for the explicit 387 path. The controller may also compute the shortest paths in the VTN 388 based on the resource-aware prefix-SIDs. 390 The network nodes also need to obtain the information of the VTNs 391 they participate in, including the resource-aware SIDs and their 392 associated network resources and topology information. Based on the 393 collected information, the network nodes which are the headend of a 394 path can perform VTN-specific path computation, and build the SID 395 list using the collected resource-aware adj-SIDs and prefix-SIDs. 396 The network nodes also need to generate the forwarding entries for 397 the resource-aware prefix-SIDs in each VTN they participates in, and 398 associate these forwarding entries with the set of local network 399 resources (e.g., a set of bandwidth on the outgoing interface) 400 allocated to the corresponding VTN. 402 Thus after receiving the network controller's instruction of network 403 resource and SID allocation, each network node needs to advertise the 404 identifier of the VTNs it participates in, the group of resource- 405 aware SIDs allocated to each VTN, and the resource attributes (e.g., 406 bandwidth) associated with the resource-aware SIDs in the network. 407 Each resource-aware adj-SID is advertised with the set of associated 408 link resources, and each resource-aware prefix-SID is advertised with 409 the identifier of the associated VTN, as all the prefix-SIDs in a VTN 410 are associated with the same set of network resources allocated to 411 the VTN. Note that as described in section 2.3, the VTNs can be 412 identified in the control plane either using existing identifiers, 413 such as the MT-ID or Flex-Algo ID, or using a newly defined VTN ID. 415 The IGP mechanisms which reuse the existing IDs such as Multi- 416 Topology [RFC5120] or Flex-Algo [I-D.ietf-lsr-flex-algo] as the 417 identifier of VTNs, and distribute the resource-aware SIDs and the 418 associated topology and resource information are described in 419 [I-D.ietf-lsr-isis-sr-vtn-mt] and [I-D.zhu-lsr-isis-sr-vtn-flexalgo] 420 respectively. The corresponding BGP-LS mechanisms which can be used 421 to distribute both the intra-domain VTN information and the inter- 422 domain VTN-specfic link information to the controller are described 423 in [I-D.ietf-idr-bgpls-sr-vtn-mt] and 424 [I-D.zhu-idr-bgpls-sr-vtn-flexalgo] respectively. Note that with 425 these mechanisms, the number of VTNs supported relies on the number 426 of topologies or algorithms supported. 428 The IGP mechanisms described in [I-D.dong-lsr-sr-enhanced-vpn] 429 introduce a new VTN-ID in the control plane, so that multiple VTNs 430 can be mapped to the same tuple, while each VTN 431 can have different resource attributes. This allows flexible 432 combination of network topology and network resources attributes to 433 build a large number of VTNs with a relatively small number of 434 topologies or algorithms. The corresponding BGP-LS mechanisms which 435 can be used to distribute the intra-domain VTN information and the 436 inter-domain VTN-specific link information to the controller are 437 described in [I-D.dong-idr-bgpls-sr-enhanced-vpn]. 439 Figure 2 shows the three SR based VTNs created in the network in 440 Figure 1. 442 1001 1001 2001 2001 3001 3001 443 101---------102 201---------202 301---------302 444 | | \1003 | | \2003 | | 445 1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002| 446 | | 105 | | 205 | | 447 1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002| 448 | | / 1003 | | / 2003 | | 449 103---------104 203---------204 303---------304 450 1002 1001 2002 2001 3002 3001 451 VTN Red VTN Green VTN Blue 453 Figure 2. SR based VTNs with different groups of SIDs 455 For each SR based VTN, SR paths are computed within the VTN, taking 456 the VTN topology and resources as constraints. The SR path can be an 457 explicit path instantiated using SR policy 458 [I-D.ietf-spring-segment-routing-policy], in which the SID-list is 459 built only with the SIDs allocated to the VTN. The SR path can also 460 be an IGP computed path associated with a prefix-SID or SRv6 End SID 461 allocated by a node for the VTN, the IGP path computation is also 462 based on the topology and/or algorithm constraints of the VTN. 464 Different SR paths in the same VTN may use shared network resources 465 when they use the same resource-aware SIDs allocated to the VTN, 466 while SR paths in different VTNs are steered to use different set of 467 network resources even when they traverse the same network links or 468 nodes. These VTN-specific SR paths need to be installed in the 469 corresponding forwarding tables. 471 For example, to create an explicit path A-B-D-E in VTN red in 472 Figure 2, the SR SID-list encapsulated in the service packet would be 473 (1001, 1002, 1003). For the same explicit path A-B-D-E in VTN green, 474 the SR segment list would be (2001, 2002, 2003). In the case where 475 we wish to construct a loose path A-D-E in VTN green, the service 476 packet should be encapsulated with the SR SID-list (201, 204, 205). 477 At node A, the packet can be sent towards D via either node B or C 478 using the network resources allocated by these nodes for VTN green. 479 At node D the packet is forwarded to E using the link and node 480 resource allocated for VTN green. Similarly, a packet to be sent via 481 loose path A-D-E in VTN red would be encapsulated with segment list 482 (101, 104, 105). In the case where an IGP computed path can meet the 483 service requirement, the packet can be simply encapsulated with the 484 prefix-SID of egress node E in the corresponding VTN. 486 3.4. Mapping Service to SR based VTN 488 Network services can be provisioned using SR based VTNs as the 489 virtual underlay networks. For example, different services may be 490 provisioned in different SR based VTNs, each of which would use the 491 network resources allocated to the VTN, so that their data traffic 492 will not interfere with each other. In another case, a group of 493 services which have similar characteristics and requirements may be 494 provisioned in the same VTN, in this case the network resources 495 allocated to the VTN are only shared among this group of services, 496 but will not be shared with other services in the network. The 497 steering of service traffic to SR based VTNs can be based on either 498 local policy or the mechanisms as defined in 499 [I-D.ietf-spring-segment-routing-policy]. 501 3.5. VTN Visibility to Customers 503 VTNs can be used by network operators to organize and split their 504 network infrastructure into different virtual underlay networks for 505 different customers or services. Some customers may also request 506 different granularity of visibility to the VTN which is used to 507 deliver the service. Depending on the requirement, VTNs may be 508 exposed to the customer either as a virtual network with both the 509 edge nodes and the intermediate nodes, or a set of paths with some of 510 the transit nodes, or simply a set of virtual connections between the 511 endpoints without any transit node information. The visibility may 512 be delivered through different possible mechanisms, such as IGPs 513 (e.g., IS-IS, OSPF), BGP-LS or Netconf/YANG. On the other hand, 514 network operators may want to restrict the visibility of the underlay 515 network information it delivers to the customer by either hiding the 516 transit nodes between sites (and only delivering the endpoints 517 connectivity), or by hiding portions of the transit nodes 518 (summarizing the path into fewer nodes). The information of VTNs 519 which are not used by the customer should also be filtered. 520 Mechanisms such as BGP-LS allow the flexibility of the advertisement 521 of aggregated virtual network information and configurable filtering 522 policies. 524 4. Characteristics of SR based VTNs 526 The mechanism described in this document provides several key 527 characteristics: 529 * Customization: Different customized VTNs can be created in a 530 shared network to meet different customers' connectivity and 531 service requirement. The customers are only aware of the topology 532 and attributes of their own VTNs, and provision services on the 533 VTN instead of the physical network. This provides a practical 534 mechanism to support network slicing. 536 * Resource Isolation: The computation and instantiation of SR paths 537 in one VTN can be independent from other VTNs or other services in 538 the network. In addition, a VTN can be associated with a set of 539 dedicated network resources, which can avoid resource competition 540 and performance interference from other VTNs or other services in 541 the network. This mechanism also allows resource sharing between 542 different service flows of the same customer, or between a group 543 of services which are provisioned in the same VTN. This gives the 544 operators and the customers the flexibility in network planning 545 and service provisioning. In a VTN, the performance of critical 546 services can be further ensured using other mechanisms, e.g., 547 those as defined in [DetNet]. 549 * Scalability: The introduction of resource aware SIDs for different 550 VTNs would increase the amount of SIDs and state in the network. 551 While the increased network state is considered an inevitable 552 price in meeting the requirements of some customers or services, 553 the SR based VTN mechanism seeks to achieve a balance between the 554 state limitations of traditional end-to-end TE mechanism and the 555 lack of resource awareness in classic segment routing. Following 556 the segment routing paradigm, network resources are allocated on 557 network segments in a per VTN manner and represented as SIDs, this 558 ensures that there is no per-path state introduced in the network. 559 In addition, operators can choose the granularity of resource 560 allocation on different network segments. In network segments 561 where resource is scarce such that the service requirement may not 562 always be met, this approach can be used to allocate a set of 563 resources to a VTN which contains such network segment to avoid 564 possible competition. By contrast, in other segment of the 565 network where resource is considered plentiful, the resource may 566 be shared between a number of VTNs. The decision to do this is in 567 the hands of the operator. 569 5. Service Assurance of VTNs 571 In order to provide assurance for services provisioned in the SR 572 based VTNs, it is necessary to instrument the network at multiple 573 levels, e.g., in both the underlay network level and the VTN level. 574 The operator or the customer may also monitor and measure the 575 performance of the services carried by the VTN. In principle these 576 can be achieved using existing or in development techniques in IETF, 577 such as network telemetry [I-D.ietf-opsawg-ntf]. The detailed 578 mechanisms are out of the scope of this document. 580 In case of failure or service performance degradation in a VTN, it is 581 necessary that some recovery mechanisms, e.g., local protection or 582 end-to-end protection mechanism is used to switch the traffic to 583 another path in the same VTN which could meet the service performance 584 requirement. Care must be taken that the service or path recovery 585 mechanism in one VTN does not impact other VTNs in the same network. 587 6. IANA Considerations 589 This document makes no request of IANA. 591 Note to RFC Editor: this section may be removed on publication as an 592 RFC. 594 7. Security Considerations 596 The security considerations of segment routing and resource-aware 597 SIDs are applicable to this document. 599 The SR VTNs may be used carry services with specific SLA parameters. 600 An attack can be directly targeted at the customer application by 601 disrupting the SLA, and can be targeted at the network operator by 602 causing them to violate their SLA, triggering commercial 603 consequences. By rigorously policing ingress traffic and carefully 604 provisioning the resources provided to the VTN, this type of attack 605 can be prevented. However care needs to be taken when shared 606 resources are provided between VTNs at some point in the network, and 607 when the network needs to be reconfigured as part of ongoing 608 maintenance or in response to a failure. 610 Considering the scalability of the SR VTN mechanism, the system may 611 be destabilised by an attack or accident) that causes a large number 612 of VTNs to be configured. This can be mitigated by placing 613 thresholds (for alarms or cut-off) in the configuration process. 615 The details of the underlying network should not be exposed to third 616 parties, some abstraction would be needed, this is also to prevent 617 attacks aimed at exploiting a shared resource between VTNs. 619 8. Contributors 621 Zhenbin Li 622 Email: lizhenbin@huawei.com 624 Zhibo Hu 625 Email: huzhibo@huawei.com 627 9. Acknowledgements 629 The authors would like to thank Mach Chen, Stefano Previdi, Charlie 630 Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein, Joel 631 Halpern, James Guichard, Adrian Farrel and Shunsuke Homma for the 632 valuable discussion and suggestions to this document. 634 10. References 636 10.1. Normative References 638 [I-D.ietf-spring-resource-aware-segments] 639 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 640 Z., and F. Clad, "Introducing Resource Awareness to SR 641 Segments", Work in Progress, Internet-Draft, draft-ietf- 642 spring-resource-aware-segments-03, 12 July 2021, 643 . 646 [I-D.ietf-teas-enhanced-vpn] 647 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 648 Framework for Enhanced Virtual Private Network (VPN+) 649 Services", Work in Progress, Internet-Draft, draft-ietf- 650 teas-enhanced-vpn-09, 25 October 2021, 651 . 654 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 655 Decraene, B., Litkowski, S., and R. Shakir, "Segment 656 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 657 July 2018, . 659 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 660 Decraene, B., Litkowski, S., and R. Shakir, "Segment 661 Routing with the MPLS Data Plane", RFC 8660, 662 DOI 10.17487/RFC8660, December 2019, 663 . 665 10.2. Informative References 667 [DetNet] "DetNet WG", 2016, 668 . 670 [I-D.dong-idr-bgpls-sr-enhanced-vpn] 671 Dong, J., Hu, Z., Li, Z., Tang, X., and R. Pang, "BGP-LS 672 Extensions for Scalable Segment Routing based Enhanced 673 VPN", Work in Progress, Internet-Draft, draft-dong-idr- 674 bgpls-sr-enhanced-vpn-04, 4 March 2022, 675 . 678 [I-D.dong-lsr-sr-enhanced-vpn] 679 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 680 and S. Bryant, "IGP Extensions for Scalable Segment 681 Routing based Enhanced VPN", Work in Progress, Internet- 682 Draft, draft-dong-lsr-sr-enhanced-vpn-07, 29 January 2022, 683 . 686 [I-D.dong-teas-nrp-scalability] 687 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 688 Mishra, G., Qin, F., Saad, T., and V. P. Beeram, 689 "Scalability Considerations for Network Resource 690 Partition", Work in Progress, Internet-Draft, draft-dong- 691 teas-nrp-scalability-01, 7 February 2022, 692 . 695 [I-D.ietf-idr-bgpls-sr-vtn-mt] 696 Xie, C., Li, C., Dong, J., and Z. Li, "BGP-LS with Multi- 697 topology for Segment Routing based Virtual Transport 698 Networks", Work in Progress, Internet-Draft, draft-ietf- 699 idr-bgpls-sr-vtn-mt-00, 4 February 2022, 700 . 703 [I-D.ietf-lsr-flex-algo] 704 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 705 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 706 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 707 2021, . 710 [I-D.ietf-lsr-isis-sr-vtn-mt] 711 Xie, C., Ma, C., Dong, J., and Z. Li, "Using IS-IS Multi- 712 Topology (MT) for Segment Routing based Virtual Transport 713 Network", Work in Progress, Internet-Draft, draft-ietf- 714 lsr-isis-sr-vtn-mt-02, 13 January 2022, 715 . 718 [I-D.ietf-opsawg-ntf] 719 Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and 720 A. Wang, "Network Telemetry Framework", Work in Progress, 721 Internet-Draft, draft-ietf-opsawg-ntf-13, 3 December 2021, 722 . 725 [I-D.ietf-spring-segment-routing-policy] 726 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 727 P. Mattes, "Segment Routing Policy Architecture", Work in 728 Progress, Internet-Draft, draft-ietf-spring-segment- 729 routing-policy-18, 17 February 2022, 730 . 733 [I-D.zhu-idr-bgpls-sr-vtn-flexalgo] 734 Zhu, Y., Dong, J., and Z. Hu, "BGP-LS with Flex-Algo for 735 Segment Routing based Virtual Transport Networks", Work in 736 Progress, Internet-Draft, draft-zhu-idr-bgpls-sr-vtn- 737 flexalgo-01, 22 February 2021, 738 . 741 [I-D.zhu-lsr-isis-sr-vtn-flexalgo] 742 Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment 743 Routing based VTN", Work in Progress, Internet-Draft, 744 draft-zhu-lsr-isis-sr-vtn-flexalgo-03, 11 July 2021, 745 . 748 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 749 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 750 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 751 . 753 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 754 (TE) Extensions to OSPF Version 2", RFC 3630, 755 DOI 10.17487/RFC3630, September 2003, 756 . 758 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 759 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 760 RFC 4915, DOI 10.17487/RFC4915, June 2007, 761 . 763 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 764 Topology (MT) Routing in Intermediate System to 765 Intermediate Systems (IS-ISs)", RFC 5120, 766 DOI 10.17487/RFC5120, February 2008, 767 . 769 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 770 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 771 2008, . 773 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 774 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 775 DOI 10.17487/RFC5440, March 2009, 776 . 778 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 779 and A. Bierman, Ed., "Network Configuration Protocol 780 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 781 . 783 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 784 Previdi, "OSPF Traffic Engineering (TE) Metric 785 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 786 . 788 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 789 S. Ray, "North-Bound Distribution of Link-State and 790 Traffic Engineering (TE) Information Using BGP", RFC 7752, 791 DOI 10.17487/RFC7752, March 2016, 792 . 794 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 795 RFC 7950, DOI 10.17487/RFC7950, August 2016, 796 . 798 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 799 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 800 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 801 2019, . 803 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 804 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 805 IGP Traffic Engineering Performance Metric Extensions", 806 RFC 8571, DOI 10.17487/RFC8571, March 2019, 807 . 809 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 810 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 811 (SRv6) Network Programming", RFC 8986, 812 DOI 10.17487/RFC8986, February 2021, 813 . 815 [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., 816 Ray, S., and J. Dong, "Border Gateway Protocol - Link 817 State (BGP-LS) Extensions for Segment Routing BGP Egress 818 Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 819 2021, . 821 Authors' Addresses 823 Jie Dong 824 Huawei Technologies 825 Email: jie.dong@huawei.com 827 Stewart Bryant 828 Futurewei Technologies 829 Email: stewart.bryant@gmail.com 831 Takuya Miyasaka 832 KDDI Corporation 833 Email: ta-miyasaka@kddi.com 834 Yongqing Zhu 835 China Telecom 836 Email: zhuyq8@chinatelecom.cn 838 Fengwei Qin 839 China Mobile 840 Email: qinfengwei@chinamobile.com 842 Zhenqiang Li 843 China Mobile 844 Email: li_zhenqiang@hotmail.com 846 Francois Clad 847 Cisco Systems 848 Email: fclad@cisco.com