idnits 2.17.1 draft-dong-spring-sr-for-enhanced-vpn-10.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 387: '... 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 (August 31, 2020) is 1328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8660' is defined on line 542, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 592, 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-10 == 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-08 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-18 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 10 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: March 4, 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 August 31, 2020 17 Segment Routing based Virtual Transport Network for Enhanced VPN 18 draft-dong-spring-sr-for-enhanced-vpn-10 20 Abstract 22 I-D.ietf-spring-resource-aware-segments describes the mechanism to 23 associate network resource attributes to Segment Routing Identifiers 24 (SIDs). The resource-aware SIDs can be used to build SR paths with a 25 set of reserved network resources. In addition, the resource-aware 26 SIDs can be used to build SR based virtual networks, which can be 27 used as virtual underlay networks with the network topology and 28 resource attributes required by different customers or services. 29 Such virtual networks are called virtual transport networks (VTNs). 30 This document describes the mechanism of using resource-aware SIDs to 31 build SR based VTNs. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 4, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Resource-Aware SIDs for VTN . . . . . . . . . . . . . . . . . 3 69 2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. VTN Topology and Resource Computation . . . . . . . . . . 5 73 3.2. VTN Network Resource and SID Allocation . . . . . . . . . 6 74 3.3. Construction of SR based VTNs . . . . . . . . . . . . . . 8 75 3.4. Mapping Service to SR based VTN . . . . . . . . . . . . . 9 76 3.5. VTN Visibility to Customer . . . . . . . . . . . . . . . 9 77 4. Benefits of the Proposed Mechanism . . . . . . . . . . . . . 10 78 5. Service Assurance . . . . . . . . . . . . . . . . . . . . . . 11 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets 91 through an ordered list of segments. A segment is referred to by its 92 Segment Identifier (SID). With SR, explicit source routing can be 93 achieved without introducing per-path state into the network. While 94 compared with RSVP-TE [RFC3209], currently SR does not have the 95 capability of reserving network resources or identifying a set of 96 network resources reserved for services or customers. 97 [I-D.ietf-spring-resource-aware-segments] extends the SR paradigm by 98 associating SIDs with network resource attributes. On a network 99 segment, multiple resource-aware SIDs can be allocated, each of which 100 represents a subset of network resources allocated to meet the 101 requirement of some customers or services. The resource-aware SIDs 102 can be used to build SR paths with a set of reserved network 103 resources. In addition, the resource-aware SIDs can also be used to 104 build SR based virtual networks with the required network topology 105 and resource attributes. A group of resource-aware SIDs together can 106 be used to specify the customized topology of a virtual network, and 107 can further be used to steer the service traffic to be processed with 108 the set of network resources allocated to the virtual network. Such 109 virtual networks are called virtual transport networks (VTNs), which 110 can be used as the underlay of enhanced VPN services as described in 111 [I-D.ietf-teas-enhanced-vpn]. 113 This document describes the mechanism of using resource-aware SIDs to 114 build SR based VTNs. Although the procedure is illustrated using SR- 115 MPLS, the proposed mechanism is applicable to both segment routing 116 over MPLS data plane (SR-MPLS) and segment routing over IPv6 data 117 plane (SRv6). 119 2. Resource-Aware SIDs for VTN 121 When SR is used as the data plane to provide multiple VTNs in one 122 network, it is necessary that SR paths in a VTN are computed with the 123 topology constraints, and are instantiated with the set of network 124 resources allocated to the VTN. With the mechanism defined in 125 [I-D.ietf-spring-resource-aware-segments], multiple SR SIDs can be 126 allocated for each network segment, and each SID can be used to 127 identify both the network topology and the set of network resources 128 allocated on the network segment for a VTN. The mechanisms to 129 identify the network topology or forwarding path with a SID as 130 defined in [RFC8402] are reused, and the control plane can be based 131 on [RFC4915], [RFC5120] and [I-D.ietf-lsr-flex-algo]. 133 2.1. SR-MPLS 135 For one IGP link, multiple Adj-SIDs are allocated, each of which is 136 associated with a VTN the link participates, and represents a subset 137 of the link resources allocated to the VTN. Similarly, for one IGP 138 node, multiple prefix-SIDs are allocated, each of which is associated 139 with a VTN the node participate, and represent a subset of the node 140 level processing resources allocated to the VTN. 142 In the case of multi-domain VTNs, on an inter-domain link, multiple 143 BGP peering SIDs [I-D.ietf-idr-bgpls-segment-routing-epe] are 144 allocated, each of which is associated with a VTN which spans 145 multiple domains, and represents a subset of resources allocated on 146 the inter-domain link. 148 This way, a group of resource-aware SIDs associated with the same VTN 149 can be used to represent the VTN topology and the allocated resources 150 in data plane. An SR SID-list built with such group of SIDs can be 151 used to steer service traffic to follow a path within the VTN 152 topology, and each SID in the SID-list can also be used to steer the 153 service traffic to be processed with the set of network resources 154 allocated to the VTN. 156 Note that the introduction of SR-MPLS based VTN increases the number 157 of SIDs needed, and the amount network states is also increased. 158 While thanks to the SR paradigmn, the resource-aware SIDs are 159 associated with different VTNs rather than different paths, thus per- 160 path state is still avoided inside the SR network. 162 2.2. SRv6 164 In order to support multiple VTNs with SRv6, network nodes (including 165 both the edge nodes and transit nodes) belonging to the same VTN need 166 to have a consistent view of the VTN, and perform consistent 167 computation and forwarding behavior to comply to the VTN topology and 168 resource constraints. The mechanisms to ensure the consistency of 169 such view can be based on [RFC4915], [RFC5120] and 170 [I-D.ietf-lsr-flex-algo]. In data plane, some mechanism is needed 171 for nodes to identify the VTN a packets belongs to. 173 Based on the mechanisms defined in 174 [I-D.ietf-spring-resource-aware-segments], for a network node, 175 multiple SRv6 LOCs are allocated, each of which is associated with a 176 VTN it participates, and represents a subset of the network resources 177 allocated to the VTN. The SRv6 SIDs of a particular VTN are 178 allocated from the SID space using the VTN-specific LOC as the 179 prefix. These SRv6 SIDs can be used to represent VTN-specific local 180 functions. 182 A group of SRv6 SIDs associated with the same VTN can be used to 183 represent the VTN topology and the allocated resources in data plane. 184 An SRv6 SID-list built with such SIDs can be used to steer the 185 service traffic to follow a path within the VTN topology, and each 186 SID in the SID-list can also be used to steer the service traffic to 187 be processed with the set of network resources allocated to the VTN. 189 Note that the introduction of SRv6 based VTN increases the number of 190 SRv6 Locators and SIDs needed, and the amount network states is also 191 increased. While thanks to the SR paradigmn, the resource-aware SIDs 192 are associated with different VTNs rather than different paths, thus 193 per-path state is still avoided in the SR network. 195 3. Procedures 197 This section describes the procedures of creating SR based VTNs and 198 the corresponding forwarding tables and entries. Although it is 199 illustrated using SR-MPLS, the proposed mechanism is applicable to 200 both SR-MPLS and SRv6. 202 According to the received service requirement, a centralized network 203 controller calculates a subset of the network topology to support the 204 service. Within this topology, the set of network resources required 205 on each network element is also determined. The subset of network 206 topology and network resources together constitute a VTN. Depending 207 on the service requirement, the network topology and resource can be 208 dedicated for a individual service or customer, or can be shared by a 209 group of services or customers. 211 Based on the mechanisms defined in 212 [I-D.ietf-spring-resource-aware-segments], the network topology and 213 resources of a VTN can be represented by a group of resource-aware 214 SIDs. With SR-MPLS, a group of prefix-SIDs and adj-SIDs will be used 215 by network nodes and the network controller to construct an SR based 216 VTN, which is considered as the virtual underlay network for the 217 service. Control plane protocols such as IGP and BGP-LS needs to be 218 extended to distribute the SIDs and the associated resource 219 information of each VTN. The detailed control plane extensions are 220 out of the scope of this document. 222 Suppose a virtual network is requested by some customer or service. 223 The basic requirement is that customer or service is allocated with 224 some dedicated network resource and does not experience unexpected 225 interference from other services in the same network. Other possible 226 requirements may include the required topology, bandwidth, latency, 227 reliability, etc. 229 3.1. VTN Topology and Resource Computation 231 A centralized network controller can be responsible for the planning 232 of a VTN to meet the received service request. The controller needs 233 to collect the information of network connectivity, network 234 resources, network performance and other relevant network states of 235 the underlay network. This can be done using either IGP [RFC5305] 236 [RFC3630] [RFC7471] [RFC8570] or BGP-LS [RFC7752] [RFC8571]. 238 Based on the information collected from the underlay network, the 239 controller obtains the underlay network topology and the information 240 about the allocated and available network resources. When a service 241 request is received, the controller computes the subset of the 242 network topology, along with the set of the resources needed on each 243 network segment (e.g. links and nodes) in the topology to meet the 244 service requirements, whilst maintaining the needs of the existing 245 services that are using the same network. The subset of network 246 topology and network resources constitute a VTN, which will be used 247 as the virtual underlay network of the requested service. 249 3.2. VTN Network Resource and SID Allocation 251 According to the result of VTN planning, the network controller 252 instructs the network nodes with the information of the VTN 253 identifier and the required network resources to be allocated to the 254 VTN, so that the involved network nodes could join the VTN and 255 allocate the network resources accordingly. This can be done with 256 either PCEP [RFC5440] or Netconf/YANG [RFC6241] [RFC7950] with 257 necessary extensions. On each network node involved in the VTN, a 258 set of network resources are allocated on a per virtual network 259 basis, and a group of resource-aware SIDs are allocated to represent 260 the set of resources allocated on the network node and the attached 261 links. Such group of resource-aware SIDs, e.g. prefix-SIDs and adj- 262 SIDs are used as data plane identifiers of the node and links in the 263 VTN. 265 In underlying forwarding plane, there can be multiple ways of 266 partitioning and allocating a set of network resource to a VTN. For 267 example, [FLEXE] may be used to partition the link resource into 268 different sub-channels to achieve resource isolation between each 269 other. The candidate data plane technologies to support resource 270 partitioning can be found in [I-D.ietf-teas-enhanced-vpn]. The SR 271 SIDs are considered as a unified abstraction in network layer , which 272 can work with various network resource partition and allocation 273 mechanisms in the underlying forwarding plane. 275 Node-SIDs: Node-SIDs: 276 r:101 r:102 277 g:201 Adj-SIDs: g:202 278 b:301 r:1001:1G r:1001:1G b:302 279 +-----+ g:2001:2G g:2001:2G +-----+ 280 | A | b:3001:1G b:3001:1G | B |Adj-SIDs: 281 | +------------------------+ + r:1003:1G 282 Adj-SIDs +--+--+ +--+--+\g:2003:2G 283 r:1002:1G| r:1002:1G| \ 284 g:2002:2G| g:2002:2G| \ r:1001:1G 285 b:3002:3G| b:3002:2G| \g:2001:2G 286 | | \ +-----+ Node-SIDs: 287 | | \+ E | r:105 288 | | /+ | g:205 289 r:1001:1G| r:1002:1G| / +-----+ 290 g:2001:2G| g:2002:2G| /r:1002:1G 291 b:3001:3G| b:3002:2G| / g:2002:2G 292 +--+--+ +--+--+ / 293 | | | |/r:1003:1G 294 | C +------------------------+ D + g:2003:2G 295 +-----+ r:1002:1G r:1001:1G +-----+ 296 Node-SIDs: g:2002:1G g:2001:1G Node-SIDs: 297 r:103 b:3002:2G b:3001:2G r:104 298 g:203 g:204 299 b:303 b:304 301 Figure 1. SID and resource allocation for multiple VTNs 303 Figure 1 shows an example of providing multiple VTNs in an SR based 304 network. Note that the format of the SIDs in this figure is for 305 illustration, both SR-MPLS and SRv6 can be used as the data plane. 306 In this example, three VTNs: red (r) , green (g) and blue (b) are 307 created to carry different services. Both the red and green VTNs 308 consist of nodes A, B, C, D, and E with all their interconnecting 309 links, whilst the blue VTN only consists of nodes A, B, C and D with 310 all their interconnecting links. Note that different VTNs may have a 311 set of shared nodes and links. On each link, a resource-aware adj- 312 SID is allocated for each VTN it participates in. 314 In Figure 1, the notation x:nnnn:y means that in VTN x, the adj-SID 315 nnnn will steer the packet over a link which has bandwidth y reserved 316 for that VTN. For example, r:1002:1G in link C->D says that the VTN 317 red has a reserved bandwidth of 1Gb/s on link C->D, and will be used 318 by packets arriving at node C with an adj-SID 1002 at the top of the 319 label stack. Similarly, on each node, a resource-aware prefix-SID is 320 allocated for each VTN it participates in. The adj-SIDs can be 321 associated with different set of link resources (e.g. bandwidth) 322 allocated to different VTNs, so that the adj-SIDs can be used to 323 steer service traffic into different set of link resources in packet 324 forwarding. The prefix-SIDs can be associated with the nodal 325 resources allocated to different VTNs. In addition, the prefix-SIDs 326 can be used to build loose SR path within each VTN, in this case it 327 can be used by the transit nodes to steer service traffic into the 328 set of local network resources allocated to the VTN in forwarding 329 plane. 331 3.3. Construction of SR based VTNs 333 In order to make both the network controller and network nodes aware 334 of the information of the VTNs in the network, each network node 335 needs to advertise the identifiers of the VTNs it participates in, 336 together with the group of SIDs and the associated resource 337 attributes both to other network nodes and the controller. This can 338 be achieved by IGP extensions in [I-D.dong-lsr-sr-enhanced-vpn] and 339 BGP-LS extensions in[I-D.dong-idr-bgpls-sr-enhanced-vpn]. 341 Based on the collected information of the topology, the allocated 342 network resource information and the associated SIDs of VTN, the 343 controller and network nodes are able to construct the SR based VTNs 344 and generate the forwarding tables and entries of each VTN based on 345 the prefix-SIDs and adj-SIDs of each VTN. Unlike classic segment 346 routing in which network resources on a network segment are shared by 347 all the SR traffic, different SR VTNs can be associated with 348 different set of resources allocated in the underlay forwarding 349 plane, so that they can be used to meet the enhanced service 350 requirement and provide the required resource isolation from other 351 services in the same network. 353 Figure 2 shows the SR based VTNs created in the network in Figure 1. 355 1001 1001 2001 2001 3001 3001 356 101---------102 201---------202 301---------302 357 | | \1003 | | \2003 | | 358 1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002| 359 | | 105 | | 205 | | 360 1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002| 361 | | / 1003 | | / 2003 | | 362 103---------104 203---------204 303---------304 363 1002 1001 1002 2001 3002 3001 364 VTN Red VTN Green VTN Blue 366 Figure 2. SR based VTNs with different groups of SIDs 368 For each SR based VTN, SR paths are computed within the VTN, taking 369 the VTN topology and resources as constraints. The SR path can be an 370 explicit path instantiated using SR policy 372 [I-D.ietf-spring-segment-routing-policy], in which the SID-list is 373 built only with the SIDs allocated to the VTN. The SR path can also 374 be an IGP computed path associated with a prefix-SID of the VTN, the 375 IGP computation is based on the VTN constraints. Different SR paths 376 in the same VTN may use shared network resources according to the 377 resource-aware SIDs allocated to the VTN, while SR paths in different 378 VTNs can be steered to use different set of network resources over 379 the shared network links or nodes. These VTN-specific SR paths need 380 to be installed in the corresponding forwarding tables. 382 For example, to create an explicit path A-B-D-E in VTN red in 383 Figure 2, the SR SID-list encapsulated in the service packet would be 384 (1001, 1002, 1003). For the same explicit path A-B-D-E in VTN green, 385 the SR segment list would be (2001, 2002, 2003). In the case where 386 we wish to construct a loose path A-D-E in VTN green, the service 387 packet SHOULD be encapsulated with the SR SID-list (201, 204, 205). 388 At node A, the packet can be sent towards D via either node B or C 389 using the link and node resources allocated for VTN green. At node D 390 the packet is forwarded to E using the link and node resource 391 allocated for VTN green. Similarly, a packet to sent via loose path 392 A-D-E in VTN red would be encapsulated with segment list (101, 104, 393 105). In the case where an IGP computed path can meet the service 394 requirement, the packet can be simply encapsulated with the prefix- 395 SID of egress node E in the corresponding VTN. 397 3.4. Mapping Service to SR based VTN 399 Network services can be provisioned using customized SR based VTN as 400 the underlay network. For example, different services may be 401 provisioned in different SR based VTNs, each of which would use the 402 network resources allocated to the VTN, so that they will not 403 interfere with each other. In another case, a group of services 404 which have similar characteristics and requirement may be provisioned 405 in the same VTN, in this case the network resources allocated to the 406 VTN are only shared among this group of services, but will not be 407 shared with other services in the network. The steering of service 408 traffic to SR based VTNs can be based on either local policy or 409 mechanisms as defined in [I-D.ietf-spring-segment-routing-policy]. 411 3.5. VTN Visibility to Customer 413 The customer may request different granularity of visibility to the 414 network which deliver the service. Depending on the requirement, the 415 network can be exposed to the customer either as a virtual network, 416 or a set of computed paths with transit nodes, or simply the abstract 417 connectivity between endpoints without any path information. The 418 visibility can be delivered through different possible mechanisms, 419 such as IGPs (e.g. IS-IS, OSPF) or BGP-LS. In addition, network 420 operator may want to restrict the visibility of the information it 421 delivers to the customer by either hiding the transit nodes between 422 sites (and only delivering the endpoints connectivity), or by hiding 423 portions of the transit nodes (summarizing the path into fewer 424 nodes). Mechanisms such as BGP-LS allow the flexibility of the 425 advertisement of aggregated virtual network information. 427 4. Benefits of the Proposed Mechanism 429 The proposed mechanism provides several key characteristics: 431 o Flexibility: Multiple customized VTNs can be created in a shared 432 network to meet different customers' connectivity and service 433 requirement. Each customer is only aware of the topology and 434 attributes of his own VTN, and provision services on the VTN 435 instead of the physical network. This provides an efficient 436 mechanism to support network slicing. 438 o Resource Isolation: The computation and instantiation of SR paths 439 in one VTN can be independent from other VTNs or other services in 440 the network. In addition, a VTN can be associated with a set of 441 network resources, which can avoid resource competition and 442 performance interference from other services in the network. The 443 proposed mechanism also allows resource sharing between different 444 service flows of the same customer, or between a group of services 445 which are provisioned in the same VTN. This gives the operator 446 and the customers the flexibility in network planning and service 447 provisioning. The performance of critical services can be further 448 ensured using the mechanisms defined in [DetNet]. 450 o Scalability: The introduction of resource guaranteed paths or 451 virtual networks would increase the amount of state to the 452 network. The proposed mechanism seeks to achieve a balance 453 between the state limitations of traditional end-to-end TE 454 mechanism and the lack of resource awareness in classic segment 455 routing. Following the segment routing paradigm, network 456 resources are allocated on network segments per VTN and 457 represented as SIDs, thus there is no per-flow state introduced in 458 the network. Operator can choose the granularity of resource 459 allocation to network segments. In network segments where 460 resource is scarce such that the service requirement may not 461 always be met, the proposed approach can be used to allocate 462 specific resources to a VTN which contains such network segment. 463 By contrast, in other segment of the network where resource is 464 considered plentiful, the resource may be shared between a number 465 of VTNs. The decision to do this is in the hands of the operator. 466 Because of the segmented nature of the SR based VTN, resource 467 aggregation is easier and more flexible than RSVP-TE based 468 approach. 470 5. Service Assurance 472 In order to provide service assurance for services provisioned in the 473 SR based VTNs, it is necessary to instrument the network at multiple 474 levels. The network operator needs to ascertain that the underlay 475 network is operating correctly. A tenant needs to ascertain that 476 their services are operating correctly. In principle these can use 477 existing techniques. These are well known problems and solutions 478 either exist or are in development to address them. 480 New work may be needed to instrument the VTNs that are created for 481 particular services. Such instrumentation needs to operate without 482 causing disruption to other services using the network. Given the 483 sensitivity of some applications, care needs to be taken to ensure 484 that the instrumentation itself does not cause disruption either to 485 the service being instrumented or to other services. In case of 486 failure or performance degradation of a service path in a particular 487 VTN, it is necessary that either local protection or end-to-end 488 protection mechanism is used to switch to another path in the same 489 VTN which could meet the service performance requirement and does not 490 impact other services in the network. 492 6. IANA Considerations 494 This document makes no request of IANA. 496 Note to RFC Editor: this section may be removed on publication as an 497 RFC. 499 7. Security Considerations 501 The security considerations of segment routing and resource-aware 502 SIDs are applicable to this document. 504 The SR VTNs may be used carry services with specific SLA parameters. 505 An attack can be directly targeted at the customer application by 506 disrupting the SLA, and can be targeted at the network operator by 507 causing them to violate their SLA, triggering commercial 508 consequences. By rigorously policing ingress traffic and carefully 509 provisioning the resources provided to the VTN, this type of attack 510 can be prevented. However care needs to be taken when shared 511 resources are provided between VTNs at some point in the network, and 512 when the network needs to be reconfigured as part of ongoing 513 maintenance or in response to a failure. 515 The details of the underlying network should not be exposed to third 516 parties, some abstraction would be needed, this is also to prevent 517 attacks aimed at exploiting a shared resource between VTNs. 519 8. Contributors 521 Zhenbin Li 522 Email: lizhenbin@huawei.com 524 Zhibo Hu 525 Email: huzhibo@huawei.com 527 9. Acknowledgements 529 The authors would like to thank Mach Chen, Stefano Previdi, Charlie 530 Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein and Joel 531 Halpern for the valuable discussion and suggestions to this document. 533 10. References 535 10.1. Normative References 537 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 538 Decraene, B., Litkowski, S., and R. Shakir, "Segment 539 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 540 July 2018, . 542 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 543 Decraene, B., Litkowski, S., and R. Shakir, "Segment 544 Routing with the MPLS Data Plane", RFC 8660, 545 DOI 10.17487/RFC8660, December 2019, 546 . 548 10.2. Informative References 550 [DetNet] "DetNet WG", 2016, 551 . 553 [FLEXE] "Flex Ethernet Implementation Agreement", March 2016, 554 . 557 [I-D.dong-idr-bgpls-sr-enhanced-vpn] 558 Dong, J., Hu, Z., Li, Z., Tang, X., and R. Pang, "BGP-LS 559 Extensions for Segment Routing based Enhanced VPN", draft- 560 dong-idr-bgpls-sr-enhanced-vpn-02 (work in progress), June 561 2020. 563 [I-D.dong-lsr-sr-enhanced-vpn] 564 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 565 and S. Bryant, "IGP Extensions for Segment Routing based 566 Enhanced VPN", draft-dong-lsr-sr-enhanced-vpn-04 (work in 567 progress), June 2020. 569 [I-D.ietf-idr-bgpls-segment-routing-epe] 570 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 571 S., and J. Dong, "BGP-LS extensions for Segment Routing 572 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 573 segment-routing-epe-19 (work in progress), May 2019. 575 [I-D.ietf-lsr-flex-algo] 576 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 577 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 578 algo-10 (work in progress), August 2020. 580 [I-D.ietf-spring-resource-aware-segments] 581 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 582 Z., and F. Clad, "Introducing Resource Awareness to SR 583 Segments", draft-ietf-spring-resource-aware-segments-00 584 (work in progress), July 2020. 586 [I-D.ietf-spring-segment-routing-policy] 587 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 588 P. Mattes, "Segment Routing Policy Architecture", draft- 589 ietf-spring-segment-routing-policy-08 (work in progress), 590 July 2020. 592 [I-D.ietf-spring-srv6-network-programming] 593 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 594 Matsushima, S., and Z. Li, "SRv6 Network Programming", 595 draft-ietf-spring-srv6-network-programming-18 (work in 596 progress), August 2020. 598 [I-D.ietf-teas-enhanced-vpn] 599 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 600 Framework for Enhanced Virtual Private Networks (VPN+) 601 Service", draft-ietf-teas-enhanced-vpn-06 (work in 602 progress), July 2020. 604 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 605 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 606 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 607 . 609 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 610 (TE) Extensions to OSPF Version 2", RFC 3630, 611 DOI 10.17487/RFC3630, September 2003, 612 . 614 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 615 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 616 RFC 4915, DOI 10.17487/RFC4915, June 2007, 617 . 619 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 620 Topology (MT) Routing in Intermediate System to 621 Intermediate Systems (IS-ISs)", RFC 5120, 622 DOI 10.17487/RFC5120, February 2008, 623 . 625 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 626 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 627 2008, . 629 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 630 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 631 DOI 10.17487/RFC5440, March 2009, 632 . 634 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 635 and A. Bierman, Ed., "Network Configuration Protocol 636 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 637 . 639 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 640 Previdi, "OSPF Traffic Engineering (TE) Metric 641 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 642 . 644 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 645 S. Ray, "North-Bound Distribution of Link-State and 646 Traffic Engineering (TE) Information Using BGP", RFC 7752, 647 DOI 10.17487/RFC7752, March 2016, 648 . 650 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 651 RFC 7950, DOI 10.17487/RFC7950, August 2016, 652 . 654 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 655 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 656 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 657 2019, . 659 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 660 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 661 IGP Traffic Engineering Performance Metric Extensions", 662 RFC 8571, DOI 10.17487/RFC8571, March 2019, 663 . 665 Authors' Addresses 667 Jie Dong 668 Huawei Technologies 670 Email: jie.dong@huawei.com 672 Stewart Bryant 673 Futurewei Technologies 675 Email: stewart.bryant@gmail.com 677 Takuya Miyasaka 678 KDDI Corporation 680 Email: ta-miyasaka@kddi.com 682 Yongqing Zhu 683 China Telecom 685 Email: zhuyq8@chinatelecom.cn 687 Fengwei Qin 688 China Mobile 690 Email: qinfengwei@chinamobile.com 692 Zhenqiang Li 693 China Mobile 695 Email: li_zhenqiang@hotmail.com 696 Francois Clad 697 Cisco Systems 699 Email: fclad@cisco.com