idnits 2.17.1 draft-dong-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2018) is 2003 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8402' is defined on line 663, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-00 == Outdated reference: A later version (-03) exists of draft-dong-teas-enhanced-vpn-02 == Outdated reference: A later version (-18) exists of draft-ietf-idr-te-pm-bgp-14 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) -- Obsolete informational reference (is this intentional?): RFC 7810 (Obsoleted by RFC 8570) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft S. Bryant 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 25, 2019 Z. Li 6 China Mobile 7 T. Miyasaka 8 KDDI Corporation 9 October 22, 2018 11 Segment Routing for Enhanced VPN Service 12 draft-dong-spring-sr-for-enhanced-vpn-02 14 Abstract 16 Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it 17 to support the needs of new applications, particularly applications 18 that are associated with 5G services. These applications require 19 better isolation from both control and data plane's perspective and 20 have more stringent performance requirements than can be provided 21 with overlay VPNs. The characteristics of an enhanced VPN as 22 perceived by its tenant needs to be comparable to those of a 23 dedicated private network. This requires tight integration between 24 the overlay VPN and the underlay network resources in a scalable 25 manner. An enhanced VPN may form the underpinning of 5G network 26 slicing, but will also be of use in its own right. This document 27 describes the use of segment routing based mechanisms to provide the 28 enhanced VPN service with dedicated network resources. The proposed 29 mechanism is applicable to both SR with MPLS data plane and SR with 30 IPv6 data plane (SRv6). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 25, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 68 3. Segment Routing with Resource Awareness . . . . . . . . . . . 4 69 4. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 5.1. Topology and Resource Computation . . . . . . . . . . . . 6 72 5.2. Network Resource and SID Allocation . . . . . . . . . . . 6 73 5.3. Construction of SR Virtual Networks . . . . . . . . . . . 8 74 5.4. VPN Service to SR Virtual Network Mapping . . . . . . . . 9 75 5.5. Network Visibility to Customer . . . . . . . . . . . . . 9 76 6. Benefits of the Proposed Mechanism . . . . . . . . . . . . . 9 77 6.1. MPLS-TP . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.2. RSVP-TE . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.3. Basic SR . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6.4. SR with Resource Awareness . . . . . . . . . . . . . . . 11 81 7. Service Assurance . . . . . . . . . . . . . . . . . . . . . . 11 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 11.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 Driven largely by needs arising from the 5G mobile network design, 93 the concept of network slicing has gained traction [NGMN-NS-Concept] 94 [TS23501][TS28530] [BBF-SD406]. Network slicing requires the 95 transport network to support partitioning the network resources to 96 provide the client with dedicated (private) networking, computing, 97 and storage resources drawn from a shared pool. The slices may be 98 seen as (and operated as) virtual networks. 100 Thus there is a need to create virtual networks with enhanced 101 characteristics. The tenant of such a virtual network can require a 102 degree of isolation and performance that previously could only be 103 satisfied by dedicated networks. Additionally the tenant may ask for 104 some level of control to their virtual network e.g. to customize the 105 service paths in the network slice. 107 The enhanced VPN service (VPN+) as described in 108 [I-D.dong-teas-enhanced-vpn] is targeted at new applications which 109 require better isolation from both control plane and data plane's 110 perspective and have more stringent performance requirements than can 111 be provided with existing overlay VPNs. An enhanced VPN may form the 112 underpinning of network slicing, but will also be of use in its own 113 right. 115 Although each VPN can be associated with a set of dedicated RSVP-TE 116 [RFC3209] LSPs with bandwidth reservation to provide some guarantee 117 to service performance, such mechanisms would introduce per-VPN per- 118 path states into the network, which is known to have scalability 119 issues [RFC5439] and has not been widely adopted in production 120 networks. 122 Segment Routing (SR) [I-D.ietf-spring-segment-routing] specifies a 123 mechanism to steer packets through an ordered list of segments. It 124 can achieve explicit source routing without introducing per-path 125 state into the network. Like RSVP-TE, SR also supports source 126 specification of the packet path. However, currently SR does not 127 have the capability of reserving or identifying different network 128 resources for different services or customers. Although the 129 controller can have global view of network state and can provision 130 different services onto different SR paths, in the data plane it 131 still relies on traditional DiffServ QoS model to provide coarse- 132 grained traffic differentiation in the network. While this may be 133 sufficient for some traditional services, it cannot meet the 134 requirement of the enhanced VPN service. 136 This document extends the SR paradigm by allocating different Segment 137 Identifiers (SIDs) to represent the different subset of resources 138 allocated on each network elements (links or nodes). The SIDs 139 associated with particular network resources can be used to construct 140 customized virtual networks for different services, the SID can also 141 be used to steer the service traffic to be processed with the 142 corresponding allocated resources. This mechanism can be used to 143 provide the enhanced VPN service with dedicated network resources. 145 The proposed mechanism is applicable to both SR with MPLS data plane 146 and SR with IPv6 data plane (SRv6). 148 2. Requirements Notation 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 RFC 2119 [RFC2119] RFC8174 [RFC8174][when, and only when, they 154 appear in all capitals, as shown here. 156 3. Segment Routing with Resource Awareness 158 In segment routing, several types of segments are defined to 159 represent either topological elements or service instructions. A 160 topological segment may be a node segment or an adjacency segment. 161 Some other types of segments may be associated with specific service 162 functions for service chaining purpose. However, so far non of the 163 SR segments are associated with network resources for the QoS 164 purpose. 166 In order to support the enhanced VPNs which require guaranteed 167 performance and isolation from other services in the network, the 168 overlay VPN needs to been integrated with underlay networks. Some 169 dedicated network resources need to be allocated for enhanced VPN. 170 When segment routing is used to build enhanced VPNs, it is necessary 171 to associate the segments with network resources. 173 By extending the segment routing paradigm, different set of network 174 resources are allocated by network elements, and associated with 175 dedicated SIDs. On one particular link, multiple adjacency segment 176 identifiers (Adj-SIDs) can be allocated, each of which is associated 177 with a subset of the link resource allocated, such as bandwidth, 178 queues, etc. For one particular node, multiple node-SIDs can be 179 allocated, each of which may be associated with a subset of resource 180 allocated from the node, such as the processing resources. Per- 181 segment resource allocation complies to the SR paradigm, which avoids 182 introducing per-path state into the network. 184 Different groups of SIDs associated with network resources can be 185 used to build virtual networks for different enhanced VPNs, this 186 provides the required isolation between enhanced VPNs. The adj-SIDs 187 are used to steer traffic of different enhanced VPNs into different 188 set of link resources. The node SIDs can be used to steer traffic of 189 different enhanced VPNs into different node resources. The node SIDs 190 can also be used to build loose SR paths for different enhanced VPNs. 191 In this case, the node-SIDs are used by transit nodes to steer 192 traffic into the local link resources allocated for the corresponding 193 enhanced VPN. Note in this case Penultimate Hop Popping (PHP) 194 [RFC3031] MUST be disabled, as the node-SID is used to identify the 195 SR virtual network and the corresponding network resources allocated 196 to the enhanced VPN. 198 4. Control Plane 200 The architecture described in this document makes use of a 201 centralized controller that collects the information about the 202 network (configuration, state, routing databases, etc.) as well as 203 the service information (traffic matrix, performance statistics, 204 etc). The controller is also responsible for the centralized 205 computation and optimization of the virtual network used for enhanced 206 VPN. A distributed control plane is needed for the collection and 207 distribution of the network topology and state information. 208 Distributed routing computation for some services in the enhanced 209 VPNs is also possible. 211 5. Procedures 213 This section describes the procedures of provisioning an enhanced VPN 214 service based on segment routing with resource awareness. 216 According to the requirement of an enhanced VPN service, a 217 centralized network controller calculates a subset of the underlay 218 network topology to support this enhanced VPN. Within this topology, 219 the network resources needed on each network element can also be 220 determined. The network resources are allocated in a per-segment 221 manner, and are associated with different node-SIDs and adj-SIDs. 222 The group of the node-SIDs and adj-SIDs allocated for the enhanced 223 VPN will be used by network nodes and the network controller to build 224 a SR virtual topology, which is used as the logical underlay of the 225 enhanced VPN service. The extensions to IGP protocol to distribute 226 the SIDs and the associated resources allocated for a virtual network 227 topology is specified in [I-D.dong-lsr-sr-enhanced-vpn]. 229 Suppose that customer requests for an enhanced VPN service from the 230 network operator. The fundamental requirement is that customer A's 231 service does not experience interference from other services in the 232 network, such as other customers' VPN services, or the non-VPN 233 services in the network. The detailed requirements can be described 234 with characteristics such as the following: 236 o Service topology: the service sites and the connectivity between 237 them 239 o Service bandwidth: the bandwidth requirement between service sites 240 o Isolation: the level of isolation from other services in the 241 network 243 o Reliability: whether fast repair or end-to-end protection is 244 needed or not. 246 o Latency 248 o Jitter 250 o Visibility: the customer may want to have some form of visibility 251 of the network deliversing the service. 253 5.1. Topology and Resource Computation 255 As described in section 4, a centralized network controller is 256 responsible for the provisioning of enhanced VPNs. The controller 257 needs to determine the information of network connectivity, network 258 resources, network performance and other relevant network state of 259 the underlay network. This is often done using either IGP [RFC5305] 260 [RFC3630] [RFC7471] [RFC7810] or BGP-LS [RFC7752] 261 [I-D.ietf-idr-te-pm-bgp]. 263 Based on the network information collected from the underlay network, 264 the controller computes the underlay topology (possibly using 265 multiple algorithms) and knows the resources that are available and 266 allocated. When a request is received from a tenant, the controller 267 computes the subgraph of the underlay network, along with the 268 resources to be allocated on each network element (e.g. links and 269 nodes) in the topology to meet the tenant's requirements, whilst 270 maintaining the needs of the existing tenants that are using the same 271 network. 273 5.2. Network Resource and SID Allocation 275 According to the output of computation, the network controller 276 instructs the network devices involved in the subgraph to allocate 277 the required network resources for the enhanced VPN. This can be 278 done with either PCEP [RFC5440] or Netconf/YANG [RFC6241] [RFC7950] 279 with necessary extensions. The network resources are allocated in a 280 per-segment manner. In addition, dedicated segment identifiers, e.g. 281 node-SIDs and adj-SIDs are also allocated to represent the network 282 resources allocated for the enhanced VPN on each network segment. 284 In the forwarding plane, there are multiple ways of allocating or 285 reserving network resources to different enhanced VPNs. For example, 286 FlexE may be used to partition the link resource into different sub- 287 channels to achieve hard isolation between each other. The candidate 288 data plane technologies of enhanced VPN can be found in 289 [I-D.dong-teas-enhanced-vpn]. The SR SIDs are used as a good 290 abstraction of the various types of network resource reservation 291 mechanisms in the forwarding plane. 293 Node-SIDs: Node-SIDs: 294 r:101 r:102 295 g:201 Adj-SIDs: g:202 296 b:301 r:1001:1G r:1001:1G b:302 297 +-----+ g:2001:2G g:2001:2G +-----+ 298 | A | b:3001:1G b:3001:1G | B |Adj-SIDs: 299 | +------------------------+ + r:1003:1G 300 Adj-SIDs +--+--+ +--+--+\g:2003:2G 301 r:1002:1G| r:1002:1G| \ 302 g:2002:2G| g:2002:2G| \ r:1001:1G 303 b:3002:3G| b:3002:2G| \g:2001:2G 304 | | \ +-----+ Node-SIDs: 305 | | \+ E | r:105 306 | | /+ | g:205 307 r:1001:1G| r:1002:1G| / +-----+ 308 g:2001:2G| g:2002:2G| /r:1002:1G 309 b:3001:3G| b:3002:2G| / g:2002:2G 310 +--+--+ +--+--+ / 311 | | | |/r:1003:1G 312 | C +------------------------+ D + g:2003:2G 313 +-----+ r:1002:1G r:1001:1G +-----+ 314 Node-SIDs: g:2002:1G g:2001:1G Node-SIDs: 315 r:103 b:3002:2G b:3001:2G r:104 316 g:203 g:204 317 b:303 b:304 319 Figure 1. SIDs identify resources allocated to different virtual networks 321 Figure 1 shows a network fragment of enhanced VPN supported by SR. 322 Note that the format of the SIDs in this figure are for illustration, 323 both SR-MPLS and SRv6 can be utilized as the data plane. In this 324 example, there are three virtual topologies created for enhanced VPNs 325 red (r) , green (g) and blue (b). The red and green topologies 326 consist of nodes A, B, C, D, and E with all their interconnecting 327 links, whilst the blue topology only consists of nodes A, B, C and D 328 with all their interconnecting links. Each node allocates a 329 dedicated adjacency SID for each link participating in a particular 330 topology. Each node is also allocated with a dedicated node SID for 331 each topology it participates in. The adj-SIDs are associated with 332 the link resources (e.g. bandwidth) allocated to each topology, so 333 that the adj-SIDs can be used to steer service of different enhanced 334 VPNs into different set of reserved resources in the data plane. The 335 node-SIDs can be associated with dedicated nodal resources allocated 336 for each topology. In addition, the node-SIDs of different 337 topologies can be used to build loose SR path within each virtual 338 topology, and steer service of different enhanced VPNs into the 339 different set of reserved resources in the data plane. 341 In Figure 1, the notation x:nnnn:y that in topology colour x, the 342 adj-SID nnnn will steer the packet over that link which has a total 343 bandwidth of y assigned to that topology. Thus the note r:1002:1G in 344 link C->D says that the red topology over link C->D has a reserved 345 bandwidth of 1Gb/s and will be used by packets arriving at node C 346 with an adj-SID 1002 at the top of the label stack. 348 5.3. Construction of SR Virtual Networks 350 Each node MUST advertise its set of resources (allocated and 351 available) and the associated SIDs both to the centralized controller 352 and into the network. This can be achieve by many different means 353 such as (non-exhaustive list) IGP extensions 354 [I-D.dong-lsr-sr-enhanced-vpn], BGP-LS [RFC7752] with possible 355 extensions, NETCONF/YANG [RFC6241] [RFC7950]. 357 With the collected network resource and SIDs information, the 358 controller and network nodes are able to construct the SR virtual 359 topologies and forwarding entries using the node-SIDs and adj-SIDs 360 allocated for each enhanced VPN. Unlike classic segment routing in 361 which network resources are shared by all services and customers, the 362 SR virtual networks are associated with dedicated resource allocated 363 in the underlay, so that they can be used to meet the service 364 requirement of enhanced VPN and provide the required isolation from 365 other services in the same network. 367 Figure 2 shows the virtual SR topologies created from the underlay 368 network in Figure 1. 370 1001 1001 2001 2001 3001 3001 371 101---------102 201---------202 301---------302 372 | | \1003 | | \2003 | | 373 1002| 1002| \ 1001 2002| 2002| \ 2001 3002| 3002| 374 | | 105 | | 205 | | 375 1001| 1002| / 1002 2001| 2002| / 2002 3001| 3002| 376 | | / 1003 | | / 2003 | | 377 103---------104 203---------204 303---------304 378 1002 1001 1002 2001 3002 3001 379 Topology Red Topology Green Topology Blue 381 Figure 2. SR virtual topologies using different groups of SIDs 382 5.4. VPN Service to SR Virtual Network Mapping 384 The services of an enhanced VPN customer can be provisioned using the 385 customized SR virtual network as the underlay. In this way, services 386 of different enhanced VPNs will only use the network resources 387 allocated and will not interfere with each other. For each enhanced 388 VPN customer, the service paths can be customized for different 389 services within the SR virtual topology, and the allocated network 390 resources are shared by different services of the same enhanced VPN 391 customer. 393 For example, to create a strict path along the path A-B-D-E in the 394 red topology in Figure 2, the SR segment list in the service packet 395 would be (1001, 1002, 1003). For the same strict path in green 396 topology, the SR segment list would be (2001, 2002, 2003). In the 397 case where we wish to construct a loose path A-D-E in the green 398 topology, the service packet SHOULD be set with the SR segment list 399 (201, 204, 205). At node A the packet is sent towards D via either 400 node B or C using the link and node resources allocated for the green 401 topology. At node D the packet is forwarded to E using the link and 402 node resource allocated for the green topology. Similarly, a packet 403 for the loose path A-D-E in the red topology would arrive at node A 404 with the SID list (101, 104, 105). 406 5.5. Network Visibility to Customer 408 The tenants of enhanced VPNs may request different granularity of 409 visibility to the network which deliver the service. Depending on 410 the requirement, the network can be exposed to the tenant either as a 411 virtual network topology, or a set of computed paths with transit 412 nodes, or simply the connectivity between endpoints without any path 413 information. The visibility can be delivered through different 414 possible mechanisms, such as IGPs (e.g. IS-IS, OSPF) or BGP-LS. In 415 addition, the network operator may want to restrict the visibility of 416 the information it delivers to the tenant by either hiding the 417 transit nodes between sites (and only delivering the endpoints 418 connectivity) or by hiding portions of the transit nodes (summarizing 419 the path into fewer nodes). Mechanisms such as BGP-LS allow the 420 flexibility of the advertisement of aggregated network information. 422 6. Benefits of the Proposed Mechanism 424 The proposed mechanism provides several key characteristics: 426 o Flexibility 428 o Scalability 429 o Resource isolation 431 In addition to isolation, the proposed mechanism allows resource 432 sharing between different services of the same enhanced VPN customer. 433 This gives the customer more flexibility and control in service 434 planning and provisioning, the experience would be similar to using a 435 dedicated private network. The performance of critical services 436 flows in a particular enhanced VPN can be further ensured using the 437 mechanisms defined in [DetNet]. 439 The detailed comparison with other candidates technologies are given 440 in the following subsections. 442 6.1. MPLS-TP 444 MPLS-TP could be enhanced to include the allocation of specific 445 resources along the path to a specific LSP. This would require that 446 the SDN system set up and maintain every resource at every path for 447 every customer, and map this to the LSP in the data plane, hence at 448 every hop unique LSP label is needed for each path. Whilst this 449 would be a way to produce a proof of concept for network slicing of 450 an MPLS underlay, delegation would be difficult, resulting in a high 451 overhead and a system needing too much administration. This leads to 452 scaling concerns. The number of labels needed at any node would be 453 the total number of services passing through that node. Experience 454 with early pseudowire designs shows that this can lead to scaling 455 issues. 457 6.2. RSVP-TE 459 RSVP-TE has the same scaling concern as MPLS-TP in terms of the 460 number of LSPs that need to be maintained being equal to the number 461 of services passing through any given node. It also has the two RSVP 462 disadvantages that basic SR seeks to address: 464 o The use of RSVP for path establishment in addition to the routing 465 protocol used to discover the topology and the network resources. 467 o The overhead of the soft-state maintenance associated with RSVP. 468 The impact of this overhead would be exacerbated by the increased 469 number of end to end paths requiring state maintenance. 471 6.3. Basic SR 473 Compared to RSVP, SR reduces the number of control protocols to only 474 the routing protocol. It also attempts to minimize the core state by 475 pushing state into the packet, although in some cases the binding 476 SIDs are required to overcome the limitations in the ability of some 477 nodes to push large label stacks. Moreover, currently SR does not 478 support resource allocation or identification below the level of 479 link, and none at node level. This restricts the extent to which 480 some particular tenant traffic can be isolated from other traffic in 481 the network. 483 6.4. SR with Resource Awareness 485 The approach described in this document seeks to achieve a compromise 486 between the state limitations of traditional TE systems and the lack 487 of resource awareness in basic SR. 489 By segmenting the path and allocating network resources to each 490 element of the virtual network topologies, the operator can choose 491 the granularity of resource to path binding within a virtual 492 topology. In network segments where resource is scarce such that the 493 service requirement may not always be met, the SR approach can 494 allocate specific resources to a particular high priority service. 495 By contrast, in other parts of the network where resource is 496 plentiful, the resource may be shared by a number of services. The 497 decision to do this is in the hands of the operator. Because of the 498 segmented nature of the path, resource aggregation is possible in a 499 way that is more difficult with RSVP-TE and MPLS-TP due to the use of 500 dedicated label to identify each end-to-end path. 502 7. Service Assurance 504 In order to provide service assurance it is necessary to instrument 505 the network at multiple levels. The network operator needs to 506 ascertain that the underlay is operating correctly. A tenant needs 507 to ascertain that their services are correctly operating. In 508 principle these can use existing techniques. These are well known 509 problems and solutions either exist or are in development to address 510 them. 512 New work is needed to instrument the virtual networks that are 513 created. Such instrumentation needs to operate without causing 514 disruption to other services using the network. Given the 515 sensitivity of some applications, care needs to be taken to ensure 516 that the instrumentation itself does not cause disruption either to 517 the service being instrumented or to other services. 519 8. IANA Considerations 521 This document makes no request of IANA. 523 Note to RFC Editor: this section may be removed on publication as an 524 RFC. 526 9. Security Considerations 528 The normal security considerations of VPNs are applicable and it is 529 assumed that industry best practise is applied to an enhanced VPN. 531 The security considerations of segment routing are applicable and it 532 is assumed that these are applied to an enhanced VPN that uses SR. 534 Some applications of enhanced VPNs are sensitive to packet latency; 535 the enhanced VPNs provisioned to carry their traffic have latency 536 SLAs. By disrupting the latency of such traffic an attack can be 537 directly targeted at the customer application, or can be targeted at 538 the network operator by causing them to violate their SLA, triggering 539 commercial consequences. Dynamic attacks of this sort are not 540 something that networks have traditionally guarded against, and 541 networking techniques need to be developed to defend against this 542 type of attack. By rigorously policing ingress traffic and carefully 543 provisioning the resources provided to critical services this type of 544 attack can be prevented. However case needs to be taken when 545 providing shared resources, and when the network needs to be 546 reconfigured as part of ongoing maintenance or in response to a 547 failure. 549 The details of the underlay MUST NOT be exposed to third parties, to 550 prevent attacks aimed at exploiting a shared resource. 552 10. Acknowledgements 554 The authors would like to thank Mach Chen, Zhenbin Li, Stefano 555 Previdi and Charlie Perkins for the discussion and suggestions to 556 this document. 558 11. References 560 11.1. Normative References 562 [I-D.ietf-spring-segment-routing] 563 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 564 Litkowski, S., and R. Shakir, "Segment Routing 565 Architecture", draft-ietf-spring-segment-routing-15 (work 566 in progress), January 2018. 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, 570 DOI 10.17487/RFC2119, March 1997, 571 . 573 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 574 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 575 May 2017, . 577 11.2. Informative References 579 [BBF-SD406] 580 "BBF SD-406: End-to-End Network Slicing", 2016, 581 . 584 [DetNet] "DetNet WG", 2016, 585 . 587 [I-D.dong-lsr-sr-enhanced-vpn] 588 Dong, J. and S. Bryant, "IGP Extensions for Segment 589 Routing based Enhanced VPN", draft-dong-lsr-sr-enhanced- 590 vpn-00 (work in progress), June 2018. 592 [I-D.dong-teas-enhanced-vpn] 593 Dong, J., Bryant, S., Li, Z., and T. Miyasaka, "A 594 Framework for Enhanced Virtual Private Networks (VPN+)", 595 draft-dong-teas-enhanced-vpn-02 (work in progress), 596 October 2018. 598 [I-D.ietf-idr-te-pm-bgp] 599 Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. 600 Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering 601 Performance Metric Extensions", draft-ietf-idr-te-pm- 602 bgp-14 (work in progress), October 2018. 604 [NGMN-NS-Concept] 605 "NGMN NS Concept", 2016, . 609 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 610 Label Switching Architecture", RFC 3031, 611 DOI 10.17487/RFC3031, January 2001, 612 . 614 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 615 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 616 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 617 . 619 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 620 (TE) Extensions to OSPF Version 2", RFC 3630, 621 DOI 10.17487/RFC3630, September 2003, 622 . 624 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 625 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 626 2008, . 628 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 629 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 630 DOI 10.17487/RFC5439, February 2009, 631 . 633 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 634 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 635 DOI 10.17487/RFC5440, March 2009, 636 . 638 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 639 and A. Bierman, Ed., "Network Configuration Protocol 640 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 641 . 643 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 644 Previdi, "OSPF Traffic Engineering (TE) Metric 645 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 646 . 648 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 649 S. Ray, "North-Bound Distribution of Link-State and 650 Traffic Engineering (TE) Information Using BGP", RFC 7752, 651 DOI 10.17487/RFC7752, March 2016, 652 . 654 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 655 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 656 RFC 7810, DOI 10.17487/RFC7810, May 2016, 657 . 659 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 660 RFC 7950, DOI 10.17487/RFC7950, August 2016, 661 . 663 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 664 Decraene, B., Litkowski, S., and R. Shakir, "Segment 665 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 666 July 2018, . 668 [TS23501] "3GPP TS23.501", 2016, 669 . 672 [TS28530] "3GPP TS28.530", 2016, 673 . 676 Authors' Addresses 678 Jie Dong 679 Huawei Technologies 681 Email: jie.dong@huawei.com 683 Stewart Bryant 684 Huawei Technologies 686 Email: stewart.bryant@gmail.com 688 Zhenqiang Li 689 China Mobile 691 Email: li_zhenqiang@hotmail.com 693 Takuya Miyasaka 694 KDDI Corporation 696 Email: ta-miyasaka@kddi.com