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