idnits 2.17.1 draft-dong-lsr-sr-enhanced-vpn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2010 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) == Missing Reference: 'RFC5305' is mentioned on line 206, but not defined == Missing Reference: 'RFC5311' is mentioned on line 214, but not defined == Missing Reference: 'RFC5316' is mentioned on line 210, but not defined ** Obsolete undefined reference: RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-01 ** Downref: Normative reference to an Informational draft: draft-dong-spring-sr-for-enhanced-vpn (ref. 'I-D.dong-spring-sr-for-enhanced-vpn') == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-01 == Outdated reference: A later version (-03) exists of draft-dong-teas-enhanced-vpn-02 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-04) exists of draft-geng-detnet-info-distribution-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-04 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-15 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-00 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group J. Dong 3 Internet-Draft S. Bryant 4 Intended status: Standards Track Huawei Technologies 5 Expires: April 25, 2019 October 22, 2018 7 IGP Extensions for Segment Routing based Enhanced VPN 8 draft-dong-lsr-sr-enhanced-vpn-01 10 Abstract 12 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 13 needs of new applications, particularly including the applications 14 that are associated with 5G services. These applications require 15 better isolation and have more stringent performance requirements 16 than that can be provided with traditional overlay VPNs. An enhanced 17 VPN may form the underpin of 5G transport network slicing, and will 18 also be of use in its own right. This document describes how Multi- 19 Topology Routing (MTR) as described in RFC 5120, RFC 4915 and 20 RFC5340, can be extended to signal the network resources allocated in 21 the underlay network to construct the customized virtual networks for 22 enhanced VPN services, together with the Segment Routing Identifiers 23 (SIDs) used to identify and access the network resources allocated 24 for each virtual network in the data plane. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 62 3. Overview of Approach . . . . . . . . . . . . . . . . . . . . 3 63 4. SR Virtual Topology with Resource Guarantee . . . . . . . . . 4 64 4.1. Topology specific Link Resource Allocation and 65 Identification . . . . . . . . . . . . . . . . . . . . . 5 66 4.2. Topology specific Node Resource Allocation and 67 Identification . . . . . . . . . . . . . . . . . . . . . 6 68 5. Multiple Services in SR Virtual Topology . . . . . . . . . . 6 69 5.1. Common Service Types . . . . . . . . . . . . . . . . . . 7 70 5.1.1. Best Effort . . . . . . . . . . . . . . . . . . . . . 7 71 5.1.2. Assured Bandwidth . . . . . . . . . . . . . . . . . . 7 72 5.1.3. Deterministic . . . . . . . . . . . . . . . . . . . . 8 73 6. Topology and Algorithm . . . . . . . . . . . . . . . . . . . 8 74 7. SRv6 Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 8. Fast Repair . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9. LAN interface . . . . . . . . . . . . . . . . . . . . . . . . 10 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 13.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 The framework for an enhanced virtual private network (VPN+) is 88 described in [I-D.dong-teas-enhanced-vpn]. 90 Driven largely by needs arising from the 5G mobile network design, 91 the concept of network slicing has gained traction. There is a need 92 to create a VPN service with enhanced isolation and performance 93 characteristics. Specifically, there is a need for a transport 94 network to support a set of virtual networks, each of which provides 95 the client with some dedicated (private) network resources drawn from 96 a shared pool. The tenant of such a virtual network can require a 97 degree of isolation and performance that previously could only be 98 satisfied by dedicated networks. Additionally the tenant may ask for 99 some level of control of their virtual networks e.g. to customize the 100 service paths in their network slices. 102 These properties cannot be met with pure overlay networks, as they 103 require tighter coordination and integration between the underlay and 104 the overlay network. [I-D.dong-teas-enhanced-vpn] provides the 105 framework of enhanced VPN and describes the candidate component 106 technologies. [I-D.dong-spring-sr-for-enhanced-vpn] describes how 107 segment routing (SR) [I-D.ietf-spring-segment-routing] is used to 108 construct the required virtual networks with the network resources 109 allocated for enhanced VPN services. 111 This document describes how Multi-Topology Routing (MTR), as 112 described in [RFC5120] [RFC4915] and [RFC5340] , is extended to 113 signal the resources allocated in the underlay to construct the 114 virtual networks for enhanced VPN services, together with the segment 115 routing identifiers (SIDs) used to identify and access the resource 116 allocated for different virtual networks in the data plane. The 117 mechanism is applicable to both SR with MPLS data plane and SR with 118 IPv6 data plane (SRv6). 120 2. Specification of Requirements 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. Overview of Approach 128 To meet the requirement of enhance VPN services, a number of virtual 129 networks can be created, each representing a subset of the underlay 130 network topology and resources to be used by a specific customer. In 131 a 5G context, each virtual network is considered as a network slice 132 which serves one slice tenant. Depending on the service 133 requirements, different virtual networks can either share the same 134 physical links or nodes, or use separate links or nodes in the 135 network, while the required level of isolation and performance SHOULD 136 be guaranteed in both cases. 138 IGP multi-topology routing can be seen as a candidate mechanism to 139 create multiple network topologies in one network. Different from 140 the traditional multi-topology mechanism, which only provides logical 141 topological isolation, in the proposed mechanism network resources 142 can be partitioned and allocated to different virtual network 143 topologies to meet the isolation and performance requirements of 144 enhanced VPN. Service in one virtual topology can be instructed to 145 be processed only using the network resources allocated to this 146 virtual topology. This is achieved by using multi-topology routing 147 (MTR) together with segment routing, and extending the SR paradigm to 148 use Segment Identifiers (SIDs) to identify different set of resources 149 allocated from a particular network element (e.g. link or node). 150 Different set of SIDs are associated with different virtual 151 topologies, and are used to create the SID lists within different 152 virtual topologies. In some cases, it is also possible for several 153 virtual network topologies to share some network resources, this can 154 be achieved by using the same SR SIDs between those topologies. The 155 detailed mechanism of resource sharing will be described in a future 156 version. 158 Within one SR virtual network, one or more type of services can be 159 deployed using the resources allocated to that topology, some of 160 which may have different characteristics and require dedicated 161 resources or special treatment. The concept is similar to the DS-TE 162 model [RFC4124] of RSVP-TE based mechanism, while in this case the SR 163 paradigm is applied, which avoids the introduction of per-path state 164 into the network. 166 In general this approach applies to both IS-IS and OSPF, while the 167 specific protocol extensions and encodings are different. In the 168 current version of this document, the required IS-IS extensions are 169 described. The required OSPF extensions will be described in a 170 future version. 172 4. SR Virtual Topology with Resource Guarantee 174 As described in [I-D.ietf-isis-segment-routing-extensions], IS-IS 175 TLV-222 (MT-ISN) and TLV-223 (MT IS Neighbor Attribute) have been 176 enhanced to carry the Adj-SID sub-TLV, and TLV-235 (Multitopology 177 IPv4 Reachability) and TLV-237 (Multitopology IPv6 IP Reachability) 178 have been enhanced to carry the Prefix-SID sub-TLV. With these 179 enhancements, dedicated Segment Identifiers (SIDs) can be assigned 180 for each SR virtual network topology. The topology-specific SIDs can 181 be used as distinguisher in packet forwarding of different 182 topologies. 184 This section specifies the necessary extensions to enable the 185 deployment of resource guaranteed SR virtual topologies. Each 186 virtual topology can be allocated with a particular partition of 187 network resources from the underlay network, the SIDs can be used to 188 identify the set of resources allocated for different virtual 189 topologies on each involved network element. 191 4.1. Topology specific Link Resource Allocation and Identification 193 A network link can participate in one or multiple SR virtual 194 topologies, each virtual topology is assigned with a dedicated adj- 195 SID. In order to describe the amount of link resource allocated to a 196 particular SR virtual topology, a new IS-IS sub-TLV called "SR 197 Bandwidth" sub-TLV is defined: 199 The SR-Bandwidth sub-TLV is an optional sub-TLV carrying the 200 aggregated bandwidth allocated to a particular SR adj-SID, which is 201 associated witha particular virtual topology. In the data plane, the 202 allocated bandwidth and the associated functional components are 203 identified by the adj-SID of the virtual topology. This sub-TLV may 204 be advertised as a sub-TLV of the following TLVs: 206 TLV-22 (Extended IS reachability) [RFC5305] 208 TLV-23 (IS Neighbor Attribute) [RFC5311] 210 TLV-141 (inter-AS reachability information) [RFC5316] 212 TLV-222 (Multitopology IS)[RFC5120] 214 TLV-223 (Multitopology IS Neighbor Attribute) [RFC5311] 216 The SR bandwidth sub-TLV can appear at most once for a particular 217 topology. Multiple SR Bandwidth sub-TLVs MAY be associated with a 218 single IS neighbor. 220 The following format is defined for the SR Bandwidth sub-TLV: 222 0 1 2 3 223 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Length | Bandwidth 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Bandwidth Cont | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 SR Bandwidth sub-TLV 231 where: 233 Type: TBD, to be assigned by IANA. 235 Length: variable. 237 The SR bandwidth is encoded in 32 bits in IEEE floating 238 point format. The units are bytes (not bits!) per second. 240 [I-D.ietf-teas-sr-rsvp-coexistence-rec] describes several options for 241 traffic engineering in networks where RSVP-TE and SR LSPs coexist. 242 Note that section 3.1 of [I-D.ietf-teas-sr-rsvp-coexistence-rec] 243 proposes to partition the network bandwidth between RSVP-TE and SR. 244 The can be considered as a special case of creating one default SR 245 virtual topology with dedicated bandwidth allocated, so that the 246 network resources and operation of SR are isolated from the RSVP-TE 247 based LSPs. 249 4.2. Topology specific Node Resource Allocation and Identification 251 A network node can participate in one or multiple SR virtual 252 topologies, each virtual topology is assigned with a dedicated node- 253 SID. In SR loose path forwarding, the topology specific node-SIDs 254 can be used by transit network nodes to identify the virtual topology 255 the packet belongs to, so as to steer the packet through the set of 256 link resources allocated to the identified virtual topology. A 257 prefix-SID sub-TLV describing the dedicated node-SID for each virtual 258 topology is needed, this is supported in 259 [I-D.ietf-isis-segment-routing-extensions] for SR using MPLS data 260 plane. The mechanism for SRv6 is described in section 7. 262 In addition, similar to the allocation of link resource to virtual 263 topologies, it is possible to allocate a subset of nodal resources to 264 a particular virtual topology to ensure end-to-end service delivery. 265 The nodal resources can be identified by topology specific node-SIDs. 266 During packet forwarding, the node SIDs can be used to steer a packet 267 through the set of nodal resources allocated to this topology. 268 Optional sub-TLVs describing the resources allocated at the node 269 level for a particular virtual topology can be defined in future. 270 The specification of nodal resources is for further study. 272 5. Multiple Services in SR Virtual Topology 274 Within one SR virtual topology, one or more types of service can be 275 deployed using the resources allocated to this virtual topology. 276 Each service type can have specific resource constraints and 277 characteristics. The concept is similar to the DS-TE model [RFC4124] 278 of RSVP-TE based mechanism, while in this case the SR paradigm is 279 applied, which avoids the introduction of per-flow state into the 280 network. 282 Some mechanism is needed to identify different service types and 283 specify the different service characteristics within one virtual 284 topology. The detailed protocol extensions will be provided in a 285 future version. 287 5.1. Common Service Types 289 A service type is fundamentally the sum of the properties of a group 290 of services. The authors considered specifically creating a number 291 of specific service types within the protocol but concluded that this 292 was meaningless. The following sections show how a number of well 293 known service types can be constructed. 295 5.1.1. Best Effort 297 Best effort service can be the only service type in a particular 298 virtual topology. In this case, all of the resources allocated to 299 this virtual topology instance are available to the best effort 300 services. 302 Where there are multiple service types being carried in a virtual 303 topology, best effort service will be transmitted over the links and 304 nodes when there is an opportunity. The maximum resources which can 305 be used by best effort service may be constrained to a subset of the 306 topology resource. The Traffic Class (TC) of the best effort service 307 SHOULD be set to lower than any other service types. 309 In the data plane, the SID and the Traffic Class value in the packet 310 can be used to identify the service type and steer the best effor 311 packets into the correct forwarding resources, such as queues. 313 Best effort services may or may not be protected at the discretion of 314 the network operator. 316 5.1.2. Assured Bandwidth 318 An Assured Bandwidth service is one in which the bandwidth is assured 319 but the latency is not. Thus, some bandwidth can be allocated to the 320 assured bandwidth service, and traffic up to that bandwidth will be 321 transmitted over the service, but the traffic may be delayed by other 322 traffic. 324 It is likely that the assured bandwidth service will be carried in a 325 virtual topology together with other service types, such as the best 326 effort service. The maximum resources which can be used by assured 327 bandwidth service SHOULD be constrained to a subset of the topology 328 resource. 330 There will frequently be more than one assured bandwidth service 331 running on a topology, and the Traffic Class (TC) could be used to 332 determine how the various services compete for access to the link. 333 Whilst the bandwidth is assured over the long term, over the short 334 term it is not and such services will interact with similar and lower 335 service classes in such a way that packet delay and jitter is not 336 assured. 338 In the data plane, the SID and the Traffic Class value in the packet 339 can be used to identify the service type and priority and steer the 340 assured bandwidth service packets into the correct forwarding 341 resources, such as queues. 343 5.1.3. Deterministic 345 A Deterministic service is a service that may have controlled delay/ 346 jitter characteristics and/or an enhanced packet delivery assurance. 347 Delay/Jitter may be addressable through the provision of sufficient 348 bandwidth, or it may require some form of packet scheduling. 349 Enhanced delivery assurance may require the use of packet replication 350 and elimination mechanism. The design of a deterministic network is 351 discussed in [I-D.ietf-detnet-architecture]. Note that delay 352 protection and delivery protection are orthogonal characteristics and 353 a service may provide just one of the characteristics or it may 354 provide both. 356 The details of a deterministic service will be provided in a future 357 version. Such a service may be specified using the TLVs defined in 358 [I-D.geng-detnet-info-distribution] 360 6. Topology and Algorithm 362 In the proposed mechanism, SR is used with IGP multi-topology to 363 create one or more SR virtual topologies, each associated with a set 364 of network resources allocated for the virtual topology. The service 365 paths used between nodes in one virtual topology are not constrained 366 to be shorted path by IGP metric, and can be any non-looping path 367 that best suits the needs of the service. These paths may be imposed 368 by the network controller, or calculated using a distributed method. 369 For example, different SR algorithms as defined in 370 [I-D.ietf-isis-segment-routing-extensions] can be used within one 371 virtual topology. The Flex-Algo mechanism defined in 372 [I-D.ietf-lsr-flex-algo] may also be used in one virtual topology to 373 meet different service requirements. 375 7. SRv6 Considerations 377 The mechanism to create virtual network topologies with guaranteed 378 resource using SRv6 data plane is similar to SR with MPLS data plane, 379 while there are some differences to be considered. 381 As described in [I-D.filsfils-spring-srv6-network-programming], an 382 SRv6 SID is represented with the format of LOC:FUNCT, where LOC is 383 the locator field, and FUNCT is the function field. the Locator of 384 the SID is routable and leads to the node which instantiates that 385 SID. The function of the SID is an opaque identification of a local 386 function bound to the SID, which means the function field can only be 387 parsed by the node which instantiates the SRv6 SID. In order to 388 build multiple virtual topologies with SRv6 data plane, all the nodes 389 in one particular topology must have consistent forwarding behavior. 390 On one node which participate in multiple topologies, it MUST to be 391 able to distinguish packets of different topologies to perform 392 correct packet forwarding. 394 Taking the above into consideration, each node MUST allocate 395 dedicated SRv6 locator for each virtual topology it participates in, 396 the mapping of locator to topology MUST be advertised into the 397 network. For one virtual topology, all the SRv6 SIDs on a node MUST 398 be allocated from the SID space identified by the topology-specific 399 locator which is associated with the topology. 401 In the latest version of [I-D.bashandy-isis-srv6-extensions], the 402 SRv6 Locator TLV is defined to advertise the locators for each 403 topology/algorithm pair. The SRv6 SIDs are defined as sub-TLVs of 404 SRv6 Locator TLV, except for SRv6 End.X SIDs/LAN End.X SIDs which are 405 associated with a specific Neighbor/Link. Such protocol extensions 406 can support the advertisement of topology-specific locators, and the 407 SRv6 SIDs which inherits the topology information from the locator. 409 In order to advertise the SRv6 End.X SID/LAN End.X SIDs associated 410 with different topologies the node participates in, the SRv6 End.X 411 SID sub-TLV as defined in [I-D.bashandy-isis-srv6-extensions] MUST be 412 advertised as sub-TLVs in the MT Intermediate Systems TLV (type 222). 413 The SR bandwidth sub-TLV as defined in this document SHOULD also be 414 carried in the MT Intermediate Systems TLV. 416 8. Fast Repair 418 In some instances it is desirable to provide some form of fast repair 419 for a failed link or node. The methods available fall into two 420 categories, end-to-end, for example 1+1, and IP fast reroute. 421 Whichever of these is used, it is desirable that the repair path 422 provides the same level of service to the tenant as the tenant's 423 normal service. This would mean that the repair path needs to be 424 constrained to the tenant's topology and resource, or to some repair 425 topology and resource reserved exclusively for that tenant for the 426 duration of the repair. The normal way that IPFRR operates is that 427 the point of local repair (PLR) calculates the repair path based on 428 the information flooded by the routing protocol. How the PLR can 429 maintain the level of service through the repair is for further 430 study. 432 9. LAN interface 434 The use of multi-point to multi-point (MP2MP) interfaces is currently 435 out of scope for this design. 437 A LAN interface MUST be used in point to point mode. 439 Note support for MP2MP may be needed in the future, and this is for 440 further study. 442 10. Security Considerations 444 This document introduces no additional security vulnerabilities to 445 IS-IS and OSPF. 447 The mechanism proposed in this document is subject to the same 448 vulnerabilities as any other protocol that relies on IGPs. 450 11. IANA Considerations 452 This document requests IANA to allocate a sub-TLV type as defined in 453 Section 4 from "Sub-TLVs for TLVs 22, 23, 25, 141, 222 and 223" 454 registry. 456 Value Description Reference 457 ----- -------------------- ------------- 458 TBA1 SR bandwidth sub-TLV This document 460 Per TLV information where SR bandwidth sub-TLV can be part of: 462 TLV 22 23 25 141 222 223 463 --- -------------------- 464 y y n y y y 466 12. Acknowledgments 468 The authors would like to thank Mach Chen, Robin Li and Dean Cheng 469 for the review and discussion of this document. 471 13. References 473 13.1. Normative References 475 [I-D.dong-spring-sr-for-enhanced-vpn] 476 Dong, J., Bryant, S., Li, Z., and T. Miyasaka, "Segment 477 Routing for Enhanced VPN Service", draft-dong-spring-sr- 478 for-enhanced-vpn-01 (work in progress), July 2018. 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 486 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 487 RFC 4915, DOI 10.17487/RFC4915, June 2007, 488 . 490 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 491 Topology (MT) Routing in Intermediate System to 492 Intermediate Systems (IS-ISs)", RFC 5120, 493 DOI 10.17487/RFC5120, February 2008, 494 . 496 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 497 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 498 . 500 13.2. Informative References 502 [I-D.bashandy-isis-srv6-extensions] 503 Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene, 504 "IS-IS Extensions to Support Routing over IPv6 Dataplane", 505 draft-bashandy-isis-srv6-extensions-01 (work in progress), 506 September 2017. 508 [I-D.dong-teas-enhanced-vpn] 509 Dong, J., Bryant, S., Li, Z., and T. Miyasaka, "A 510 Framework for Enhanced Virtual Private Networks (VPN+)", 511 draft-dong-teas-enhanced-vpn-02 (work in progress), 512 October 2018. 514 [I-D.filsfils-spring-srv6-network-programming] 515 Filsfils, C., Camarillo, P., Leddy, J., 516 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 517 Network Programming", draft-filsfils-spring-srv6-network- 518 programming-05 (work in progress), July 2018. 520 [I-D.geng-detnet-info-distribution] 521 Geng, X. and M. Chen, "IGP-TE Extensions for DetNet 522 Information Distribution", draft-geng-detnet-info- 523 distribution-01 (work in progress), September 2017. 525 [I-D.ietf-detnet-architecture] 526 Finn, N., Thubert, P., Varga, B., and J. Farkas, 527 "Deterministic Networking Architecture", draft-ietf- 528 detnet-architecture-04 (work in progress), October 2017. 530 [I-D.ietf-isis-segment-routing-extensions] 531 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 532 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 533 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 534 segment-routing-extensions-15 (work in progress), December 535 2017. 537 [I-D.ietf-lsr-flex-algo] 538 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 539 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 540 algo-00 (work in progress), May 2018. 542 [I-D.ietf-spring-segment-routing] 543 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 544 Litkowski, S., and R. Shakir, "Segment Routing 545 Architecture", draft-ietf-spring-segment-routing-15 (work 546 in progress), January 2018. 548 [I-D.ietf-teas-sr-rsvp-coexistence-rec] 549 Sitaraman, H., Beeram, V., Minei, I., and S. Sivabalan, 550 "Recommendations for RSVP-TE and Segment Routing LSP co- 551 existence", draft-ietf-teas-sr-rsvp-coexistence-rec-04 552 (work in progress), May 2018. 554 [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of 555 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 556 DOI 10.17487/RFC4124, June 2005, 557 . 559 Authors' Addresses 561 Jie Dong 562 Huawei Technologies 564 Email: jie.dong@huawei.com 566 Stewart Bryant 567 Huawei Technologies 569 Email: stewart.bryant@gmail.com