idnits 2.17.1 draft-dong-lsr-sr-enhanced-vpn-00.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 (June 20, 2018) is 2135 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 202, but not defined == Missing Reference: 'RFC5316' is mentioned on line 206, but not defined ** Obsolete undefined reference: RFC 5316 (Obsoleted by RFC 9346) == Unused Reference: 'RFC0791' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC7810' is defined on line 527, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-00 ** Downref: Normative reference to an Informational draft: draft-dong-spring-sr-for-enhanced-vpn (ref. 'I-D.dong-spring-sr-for-enhanced-vpn') ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 7810 (Obsoleted by RFC 8570) == Outdated reference: A later version (-05) exists of draft-bashandy-isis-srv6-extensions-01 == Outdated reference: A later version (-02) exists of draft-bryant-rtgwg-enhanced-vpn-01 == 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: 4 errors (**), 0 flaws (~~), 14 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: December 22, 2018 June 20, 2018 7 IGP Extensions for Segment Routing based Enhanced VPN 8 draft-dong-lsr-sr-enhanced-vpn-00 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 and RFC 4915, can be 20 extended to signal the resources allocated in the underlay network to 21 construct the virtual networks for enhanced VPN services, together 22 with the Segment Routing Identifiers (SIDs) used to identify and 23 access the network resources allocated for the virtual networks in 24 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 December 22, 2018. 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 . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 11 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 13.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The framework for an enhanced virtual private network (VPN+) is 88 described in [I-D.bryant-rtgwg-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.bryant-rtgwg-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] , is extended to signal the 113 resources allocated in the underlay to construct the virtual networks 114 for enhanced VPN services, together with the segment routing 115 identifiers used to identify and access the resource allocated for 116 different virtual networks in the data plane. 118 2. Specification of Requirements 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. Overview of Approach 126 To meet the requirement of enhance VPN services, a number of virtual 127 networks can be created, each representing a subset of the underlay 128 network topology and resources to be used by a specific customer. In 129 a 5G context, each virtual network is considered as a network slice 130 which serves one slice tenant. Depending on the service 131 requirements, differernt virtual networks can either share the same 132 physical links or nodes, or use separate links or nodes in the 133 network, while the required level of isolation and performance SHOULD 134 be guaranteed in both cases. 136 IGP multi-topology routing can be seen as a candidate mechanism to 137 create multiple network topologies in one network. Different from 138 the traditional multi-topology mechanism which only provides logical 139 topological isolation, in the proposed mechanism network resources 140 can be partitioned and allocated to different virtual network 141 topologies to meet the isolation and performance requirements of 142 enhanced VPN. Service in one virtual topology can be instructed to 143 be processed using the network resources allocated to this virtual 144 topology. This is achieved by using multi-topology together with 145 segment routing, and extending the SR paradigm to use Segment 146 Identfiers (SIDs) to identify different set of resources allocated 147 from a particular network element (e.g. link or node). Different set 148 of SIDs are associated with different virtual topologies, and are 149 used to create the SID lists in different topologies. In some cases 150 it is also possible for several virtual network topologies to share 151 some network resources, this can be achieved by using the same SR 152 SIDs between those topologies. The detailed mechanism of resource 153 sharing will be described in a future version. 155 Within one SR virtual network, one or more type of services can be 156 deployed using the resources allocated to that topology, some of 157 which may have different characteristics and require dedicated 158 resources or special treatment. This is similar to the DS-TE model 159 of the RSVP-TE based mechanism. The concept is similar to the DS-TE 160 model [RFC4124] of RSVP-TE based mechanism, while in this case the SR 161 paradigm is applied, which avoids the introduction of per-path state 162 into the network. 164 In general this approach applies to both IS-IS and OSPF, while the 165 specific protocol extensions and encodings are different. In the 166 current version of this document, the required IS-IS extensions are 167 described. The required OSPF extensions will be described in a 168 future version. 170 4. SR Virtual Topology with Resource Guarantee 172 As described in [I-D.ietf-isis-segment-routing-extensions], the IS-IS 173 TLV-222 (MT-ISN) and TLV-223 (MT IS Neighbor Attribute) have been 174 enhanced to carry the Adj-SID sub-TLV, and TLV-235 (Multitopology 175 IPv4 Reachability) and TLV-237 (Multitopology IPv6 IP Reachability) 176 have been enhanced to carry the Prefix-SID sub-TLV. With these 177 enhancements, dedicated Segment Identifiers (SIDs) can be assigned 178 for each SR virtual network topology. 180 This section specifies the necessary extensions to enable the 181 deployment of resource guaranteed SR virtual topologies. Each 182 virtual topology can be allocated with a particular partition of 183 network resources from the underlay network, the SIDs associated with 184 each SR virtual topology are used to identify the set of resources 185 allocated from the network elements. 187 4.1. Topology specific Link Resource Allocation and Identification 189 A network link can participate in one or multiple SR virtual 190 topologies, each virtual topology is assigned with a dedicated adj- 191 SID. In order to describe the amount of link resource allocated to a 192 particular SR virtual topology, a new IS-IS sub-TLV called "SR 193 Bandwidth" sub-TLV is defined: 195 The SR-Bandwidth sub-TLV is an optional sub-TLV carrying the 196 aggregated bandwidth allocated to a particular SR adj-SID, which is 197 associated witha particular virtual topology. In the data plane, the 198 allocated bandwidth and the associated functional components are 199 identified by the adj-SID of the virtual topology. This sub-TLV may 200 be advertised as a sub-TLV of the following TLVs: 202 TLV-22 (Extended IS reachability) [RFC5305] 204 TLV-23 (IS Neighbor Attribute) [RFC5311] 206 TLV-141 (inter-AS reachability information) [RFC5316] 208 TLV-222 (Multitopology IS)[RFC5120] 210 TLV-223 (Multitopology IS Neighbor Attribute) [RFC5311] 212 The SR bandwidth sub-TLV can appear at most once for a particular 213 topology. Multiple SR Bandwidth sub-TLVs MAY be associated with a 214 single IS neighbor. 216 The following format is defined for the SR Bandwidth sub-TLV: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type | Length | Bandwidth 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Bandwidth Cont | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 SR Bandwidth sub-TLV 227 where: 229 Type: TBD, to be assigned by IANA. 231 Length: variable. 233 The SR bandwidth is encoded in 32 bits in IEEE floating 234 point format. The units are bytes (not bits!) per second. 236 [I-D.ietf-teas-sr-rsvp-coexistence-rec] describes several options for 237 traffic engineering in networks where RSVP-TE and SR LSPs coexist. 238 Note that section 3.1 of [I-D.ietf-teas-sr-rsvp-coexistence-rec] 239 proposes to partition the network bandwidth between RSVP-TE and SR. 241 The can be considered as a special case of creating one default SR 242 virtual topology with dedicated bandwidth allocated, so that the 243 network resources and operation of SR are isolated from the RSVP-TE 244 based LSPs. 246 4.2. Topology specific Node Resource Allocation and Identification 248 A network node can participate in one or multiple SR virtual 249 topologies, each virtual topology is assigned with a dedicated node- 250 SID. In SR loose path forwarding, the topology specific node-SIDs 251 can be used by transit network nodes to identify the virtual topology 252 the packet belongs to, so as to steer the packet through the set of 253 link resources allocated for the identified virtual topology. A 254 prefix-SID sub-TLV describing the dedicated node-SID for each virtual 255 topology is needed, this is supported in 256 [I-D.ietf-isis-segment-routing-extensions]. 258 In addition, similar to the allocation of link resource to virtual 259 topologies, it is possible to allocate a subset of nodal resources 260 for a particular virtual topology to ensure end-to-end service 261 delivery. The nodal resources can be identified by the topology 262 specific node-SIDs, so that in data plane the node SIDs can be used 263 to steer a packet through the set of nodal resources allocated to 264 this topology. Optional sub-TLVs describing the allocated resources 265 at the node level for a particular virtual topology may be defined in 266 future. The specification of nodal resources is for further study. 268 5. Multiple Services in SR Virtual Topology 270 Within one SR virtual topology, one or more types of service can be 271 deployed using the resources allocated to this virtual topology. 272 Each service type can have specific resource constraints and 273 characteristics. The concept is similar to the DS-TE model [RFC4124] 274 of RSVP-TE based mechanism, while in this case the SR paradigm is 275 applied, which avoids the introduction of per-flow state into the 276 network. 278 Some mechanism is needed to identify different service types and 279 specify the different service characteristics within one virtual 280 topology. The detailed protocol extensions will be provided in a 281 future version. 283 5.1. Common Service Types 285 A service type is fundamentally the sum of the properties of a group 286 of services. The authors considered specifically creating a number 287 of specific service types within the protocol but concluded that this 288 was meaningless. The following sections show how a number of well 289 known service types can be constructed. 291 5.1.1. Best Effort 293 Best effort service can be the only service type in a particular 294 virtual topology. In this case, all of the resources allocated to 295 this virtual topology instance are available to the best effort 296 services. 298 Where there are multiple service types being carried in a virtual 299 topology, best effort service will be transmitted over the links and 300 nodes when there is an opportunity. The maximum resources which can 301 be used by best effort service may be constrained to a subset of the 302 topology resource. The Traffic Class (TC) of the best effort service 303 SHOULD be set to lower than any other service types. 305 In the data plane, the SID and the Traffic Class value in the packet 306 can be used to identify the service type and steer the best effor 307 packets into the correct forwarding resources, such as queues. 309 Best effort services may or may not be protected at the discretion of 310 the network operator. 312 5.1.2. Assured Bandwidth 314 An Assured Bandwidth service is one in which the bandwidth is assured 315 but the latency is not. Thus, some bandwidth can be allocated to the 316 assured bandwidth service, and traffic up to that bandwidth will be 317 transmitted over the service, but the traffic may be delayed by other 318 traffic. 320 It is likely that the assured bandwidth service will be carried in a 321 virtual topology together with other service types, such as the best 322 effort service. The maximum resources which can be used by assured 323 bandwidth service SHOULD be constrained to a subset of the topology 324 resource. 326 There will frequently be more than one assured bandwidth service 327 running on a topology, and the Traffic Class (TC) could be used to 328 determine how the various services compete for access to the link. 329 Whilst the bandwidth is assured over the long term, over the short 330 term it is not and such services will interact with similar and lower 331 service classes in such a way that packet delay and jitter is not 332 assured. 334 In the data plane, the SID and the Traffic Class value in the packet 335 can be used to identify the service type and priority and steer the 336 assured bandwidth service packets into the correct forwarding 337 resources, such as queues. 339 5.1.3. Deterministic 341 A Deterministic service is a service that may have controlled delay/ 342 jitter characteristics and/or an enhanced packet delivery assurance. 343 Delay/Jitter may be addressable through the provision of sufficient 344 bandwidth or it may require some form of packet scheduling. Enhanced 345 delivery assurance may require the use of packet replication and 346 elimination mechanism. The design of a deterministic network is 347 discussed in [I-D.ietf-detnet-architecture]. Note that delay 348 protection and delivery protection are orthogonal characteristics and 349 a service may provide just one of the characteristics or it may 350 provide both. 352 The details of a deterministic service will be provided in a future 353 version. Such a service may be specified using the TLVs defined in 354 [I-D.geng-detnet-info-distribution] 356 6. Topology and Algorithm 358 In the proposed mechanism, SR is used with IGP multi-topology to 359 create one or more SR virtual topologies, each associated with a set 360 of network resources allocated for the virtual topology. The service 361 paths used between nodes in one virtual topology are not constrained 362 to be shorted path by IGP metric, and can be any non-looping path 363 that best suits the needs of the service. These paths may be imposed 364 by the network controller, or calculated using a distributed method. 365 For example, different SR algorithms as defined in 366 [I-D.ietf-isis-segment-routing-extensions] can be used within one 367 virtual topology. The flex-algo mechanism defined in 368 [I-D.ietf-lsr-flex-algo] may also be used in one virtual topology to 369 meet different service requirements. 371 7. SRv6 Considerations 373 The mechanisms to create virtual network topologies with allocated 374 resources using an SRv6 data-plane are similar to SR with an MPLS 375 data plane, although there are some differences to be considered. 376 This section specifies the necessary protocol extensions to enable 377 SRv6 with multi-topology and the mechanisms defined in this document. 378 Detailed method of operating enhanced VPN over an SRv6 data-plane 379 will be described in a future version. 381 In [I-D.bashandy-isis-srv6-extensions], the SRv6 node SID TLV is 382 defined as a top-level TLV, which cannot be carried under the MT IPv6 383 IP Reach TLV (type 237). In order to specify the association between 384 SRv6 node SIDs and differernt virtual topologies, a new sub-TLV 385 called "MT-ID sub-TLV" under the SRv6 node SID TLV is introduced. 386 The format of the sub-TLV is as follows: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type | Length |R|R|R|R| MT-ID | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 MT-ID sub-TLV 395 In addition, in order to advertise multiple algorithms used for 396 calculating reachability to nodes within a particular topology, a new 397 sub-TLV called "SR algorithm sub-TLV" under the SRv6 node SID TLV is 398 introduced. The format of the sub-TLV is as follows: 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type | Length | Flags | Algorithm | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 SR Algorithm sub-TLV 407 In order to advertise the SRv6 adj-SIDs associated with different 408 topologies the network node participates in, the SRv6 Adjacency SID 409 sub-TLV as defined in [I-D.bashandy-isis-srv6-extensions] MUST be 410 carried in the MT Intermediate Systems TLV (type 222). The SR 411 bandwidth sub-TLV as defined in this document SHOULD also be carried 412 in the MT Intermediate Systems TLV. 414 8. Fast Repair 416 In some instances it is desirable to provide some form of fast repair 417 for a failed link or node. The methods available fall into two 418 categories, end-to-end, for example 1+1, and IP fast reroute. Which 419 ever of these is used it is desirable that the repair path provides 420 the same level of service to the tenant as the tenant's normal 421 service. This would mean that the repair path needs to be 422 constrained to the tenant's topology, or to some repair topology 423 reserved exclusively for that tenant for the duration of the repair. 424 The normal way that IPFRR operates is that the point of local repair 425 (PLR) calculates the repair path based on the information flooded by 426 the routing protocol. How the PLR can maintain the level of service 427 through the repair is for further study. 429 9. LAN interface 431 The use of multi-point to multi-point (MP2MP) interfaces is currently 432 out of scope for this design. 434 A LAN interface MUST be used in point to point mode. 436 Note support for MP2MP may be needed in the future, and this is for 437 further study. 439 10. Security Considerations 441 This document introduces no additional security vulnerabilities to 442 IS-IS and OSPF. 444 The mechanism proposed in this document is subject to the same 445 vulnerabilities as any other protocol that relies on IGPs. 447 11. IANA Considerations 449 This document requests IANA to allocate a sub-TLV type as defined in 450 Section 4 from "Sub-TLVs for TLVs 22, 23, 25, 141, 222 and 223" 451 registry. 453 Value Description Reference 454 ----- -------------------- ------------- 455 TBA1 SR bandwidth sub-TLV This document 457 Per TLV information where SR bandwidth sub-TLV can be part of: 459 TLV 22 23 25 141 222 223 460 --- -------------------- 461 y y n y y y 463 This document requests IANA to allocate 2 sub-TLVs type as defined in 464 Section 7 from the "Sub-TLVs for TLVs 27, 135, 235, 236 and 237" 465 registry. 467 Value Description Reference 468 ----- -------------------- ------------- 469 TBA2 MT-ID sub-TLV This document 470 TBA3 SR Algorithm sub-TLV This document 472 Per TLV information where the sub-TLVs can be part of: 474 TLV 27 135 235 236 237 475 --- -------------------- 476 TBA2 y n n n n 477 TBA3 y n n n n 479 12. Acknowledgments 481 The authors would like to thank Mach Chen and Robin Li for the review 482 and discussion of this document. 484 13. References 486 13.1. Normative References 488 [I-D.dong-spring-sr-for-enhanced-vpn] 489 Dong, J., Bryant, S., Li, Z., and T. Miyasaka, "Segment 490 Routing for Enhanced VPN Service", draft-dong-spring-sr- 491 for-enhanced-vpn-00 (work in progress), March 2018. 493 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 494 DOI 10.17487/RFC0791, September 1981, 495 . 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 503 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 504 December 1998, . 506 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 507 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 508 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 509 . 511 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 512 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 513 RFC 4915, DOI 10.17487/RFC4915, June 2007, 514 . 516 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 517 Topology (MT) Routing in Intermediate System to 518 Intermediate Systems (IS-ISs)", RFC 5120, 519 DOI 10.17487/RFC5120, February 2008, 520 . 522 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 523 Shand, "Simplified Extension of Link State PDU (LSP) Space 524 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 525 . 527 [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and 528 Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", 529 RFC 7810, DOI 10.17487/RFC7810, May 2016, 530 . 532 13.2. Informative References 534 [I-D.bashandy-isis-srv6-extensions] 535 Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene, 536 "IS-IS Extensions to Support Routing over IPv6 Dataplane", 537 draft-bashandy-isis-srv6-extensions-01 (work in progress), 538 September 2017. 540 [I-D.bryant-rtgwg-enhanced-vpn] 541 Bryant, S. and J. Dong, "Enhanced Virtual Private Networks 542 (VPN+)", draft-bryant-rtgwg-enhanced-vpn-01 (work in 543 progress), October 2017. 545 [I-D.geng-detnet-info-distribution] 546 Geng, X. and M. Chen, "IGP-TE Extensions for DetNet 547 Information Distribution", draft-geng-detnet-info- 548 distribution-01 (work in progress), September 2017. 550 [I-D.ietf-detnet-architecture] 551 Finn, N., Thubert, P., Varga, B., and J. Farkas, 552 "Deterministic Networking Architecture", draft-ietf- 553 detnet-architecture-04 (work in progress), October 2017. 555 [I-D.ietf-isis-segment-routing-extensions] 556 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 557 Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, 558 "IS-IS Extensions for Segment Routing", draft-ietf-isis- 559 segment-routing-extensions-15 (work in progress), December 560 2017. 562 [I-D.ietf-lsr-flex-algo] 563 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 564 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 565 algo-00 (work in progress), May 2018. 567 [I-D.ietf-spring-segment-routing] 568 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 569 Litkowski, S., and R. Shakir, "Segment Routing 570 Architecture", draft-ietf-spring-segment-routing-15 (work 571 in progress), January 2018. 573 [I-D.ietf-teas-sr-rsvp-coexistence-rec] 574 Sitaraman, H., Beeram, V., Minei, I., and S. Sivabalan, 575 "Recommendations for RSVP-TE and Segment Routing LSP co- 576 existence", draft-ietf-teas-sr-rsvp-coexistence-rec-04 577 (work in progress), May 2018. 579 [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of 580 Diffserv-aware MPLS Traffic Engineering", RFC 4124, 581 DOI 10.17487/RFC4124, June 2005, 582 . 584 Authors' Addresses 586 Jie Dong 587 Huawei Technologies 589 Email: jie.dong@huawei.com 591 Stewart Bryant 592 Huawei Technologies 594 Email: stewart.bryant@gmail.com