idnits 2.17.1 draft-dong-lsr-sr-enhanced-vpn-06.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 (July 12, 2021) is 1011 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 563, but not defined == Missing Reference: 'RFC5311' is mentioned on line 573, but not defined == Missing Reference: 'RFC5316' is mentioned on line 569, but not defined ** Obsolete undefined reference: RFC 5316 (Obsoleted by RFC 9346) == Missing Reference: 'RFC5308' is mentioned on line 521, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-15 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-14 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-02 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-for-enhanced-vpn-00 ** Downref: Normative reference to an Informational draft: draft-ietf-spring-sr-for-enhanced-vpn (ref. 'I-D.ietf-spring-sr-for-enhanced-vpn') == Outdated reference: A later version (-06) exists of draft-dong-6man-enhanced-vpn-vtn-id-03 == Outdated reference: A later version (-04) exists of draft-dong-teas-enhanced-vpn-vtn-scalability-02 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-07 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 Z. Hu 4 Intended status: Standards Track Z. Li 5 Expires: January 13, 2022 Huawei Technologies 6 X. Tang 7 R. Pang 8 China Unicom 9 L. JooHeon 10 LG U+ 11 S. Bryant 12 Futurewei Technologies 13 July 12, 2021 15 IGP Extensions for Scalable Segment Routing based Enhanced VPN 16 draft-dong-lsr-sr-enhanced-vpn-06 18 Abstract 20 Enhanced VPN (VPN+) aims to provide enhanced VPN services to support 21 some application's needs of enhanced isolation and stringent 22 performance requirements. VPN+ requires integration between the 23 overlay VPN connectivity and the characteristics provided by the 24 underlay network. A Virtual Transport Network (VTN) is a virtual 25 underlay network which has a customized network topology and a set of 26 network resources allocated from the physical network. A VTN could 27 be used to support one or a group of VPN+ services. 29 This document specifies the IGP mechanisms with necessary extensions 30 to advertise the associated topology and resource attributes for 31 scalable Segment Routing (SR) based VTNs. Each VTN can have a 32 customized topology and a set of network resources allocated from the 33 physical network. Multiple VTNs may shared the same topology, and 34 multiple VTNs may share the same set of network resources on some 35 network segments. A group of resource-aware SIDs are allocated for 36 each VTN. This allows flexible combination of the network topology 37 and network resource attributes to build a relatively large number of 38 VTNs with a small number of logical topologies. The proposed 39 mechanism is applicable to both Segment Routing with MPLS data plane 40 (SR-MPLS) and segment routing with IPv6 data plane (SRv6). This 41 document also describes the mechanisms of using dedicated VTN-ID in 42 the data plane instead of the per-VTN resource-aware SIDs to further 43 reduce the control plane overhead. 45 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [RFC2119]. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at https://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on January 13, 2022. 68 Copyright Notice 70 Copyright (c) 2021 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (https://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 2. VTN Definition Advertisement . . . . . . . . . . . . . . . . 4 87 3. Advertisement of VTN Topology Attribute . . . . . . . . . . . 5 88 3.1. MTR based Topology Advertisement . . . . . . . . . . . . 6 89 3.2. Flex-Algo based Topology Advertisement . . . . . . . . . 7 90 4. Advertisement of VTN Resource Attribute . . . . . . . . . . . 7 91 4.1. Option 1: L2 Bundle based Approach . . . . . . . . . . . 8 92 4.2. Option 2: Per-VTN Link TE Attributes . . . . . . . . . . 9 94 5. Advertisement of VTN specific Data Plane Identifiers . . . . 11 95 5.1. Advertisement of VTN-specific SR-MPLS SIDs . . . . . . . 11 96 5.2. Advertisement of VTN-specific SRv6 Locators and SIDs . . 14 97 5.3. Advertisement of Dedicated Data Plane VTN IDs . . . . . . 15 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 100 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 101 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 104 10.2. Informative References . . . . . . . . . . . . . . . . . 18 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 107 1. Introduction 109 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 110 needs of new applications, particularly the applications that are 111 associated with 5G services. These applications require enhanced 112 isolation and have more stringent performance requirements than that 113 can be provided with traditional overlay VPNs. These properties 114 require integration between the underlay and the overlay networks. 115 [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN 116 and describes the candidate component technologies in different 117 network planes and layers. An enhanced VPN can be used for 5G 118 network slicing, and will also be of use in more generic scenarios. 120 To meet the requirement of different enhanced VPN services, a number 121 of virtual underlay networks need to be created, each with a 122 customized network topology and a set of network resources allocated 123 from the physical network to meet the requirement of one or a group 124 of VPN+ services. Such a virtual underlay network is called Virtual 125 Transport Network (VTN) in [I-D.ietf-teas-enhanced-vpn]. 127 [I-D.ietf-spring-resource-aware-segments] introduces resource-aware 128 segments by associating existing type of SIDs with network resource 129 attributes (e.g. bandwidth, processing or storage resources). These 130 resource-aware SIDs retain their original functionality, with the 131 additional semantics of identifying the set of network resources 132 available for the packet processing 133 action.[I-D.ietf-spring-sr-for-enhanced-vpn] describes the use of 134 resource-aware segments to build SR based VTNs. To allow the network 135 controller and network nodes to perform VTN-specific explicit path 136 computation and/or shortest path computation, the group of resource- 137 aware SIDs allocated by network nodes to each VTN and the associated 138 topology and resource attributes need to be distributed using the 139 control plane. 141 [I-D.dong-teas-enhanced-vpn-vtn-scalability] analyzes the scalability 142 requirements and the control plane and data plane scalability 143 considerations of enhanced VPN, more specifically, the scalability of 144 the VTNs. In order to support a relatively large number of VTNs in 145 the network, one proposed approach is to separate the topology and 146 resource attributes of the VTN in control plane, so that the 147 advertisement and processing of each type of attribute could be 148 decoupled. Multiple VTNs may shared the same topology, and multiple 149 VTNs may share the same set of network resources on some network 150 segments, while the difference in either the topology or resource 151 attributes makes them different VTNs. This allows flexible 152 combination of network topology and network resource attributes to 153 build a large number of VTNs with a relatively small number of 154 logical topologies. 156 This document specifies the IGP control plane mechanisms with 157 necessary extensions for scalable SR based VTNs. The proposed 158 mechanism is applicable to both segment routing with MPLS data plane 159 (SR-MPLS) and segment routing with IPv6 data plane (SRv6). This 160 document also describes the mechanisms of using dedicated VTN-ID in 161 the data plane instead of the per-VTN resource-aware SIDs to further 162 reduce the control plane overhead. 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 or in a separate document. 170 2. VTN Definition Advertisement 172 According to [I-D.ietf-teas-enhanced-vpn], a VTN has a customized 173 network topology and a set of dedicated or shared network resources. 174 Thus a VTN can be defined as the combination of a set of network 175 attributes, which include the topology attribute and other 176 attributes, such as the network resources. IS-IS Virtual Transport 177 Network Definition (VTND) sub-TLV is used to advertise the definition 178 of a VTN. It is a sub-TLV of the IS-IS Router-Capability TLV 242 as 179 defined in [RFC7981]. 181 The format of IS-IS VTND sub-TLV is as below: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length | VTN ID | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | VTN ID (Continue) | MT-ID | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Algorithm | Flags | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | | 193 ~ Sub-TLVs ~ 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Where: 199 o Type: TBD 201 o Length: The length of the value field of the sub-TLV. It is 202 variable dependent on the included sub-TLVs. 204 o VTN ID: A global significant 32-bit identifier which is used to 205 identify a VTN. 207 o MT-ID: 16-bit field which indicates the multi-topology identifier 208 as defined in [RFC5120]. The first 4-bit are set to zero. 210 o Algorithm: 8-bit identifier which indicates the algorithm which 211 applies to this VTN. It can be either a normal algorithm 212 [RFC8402] or a Flex-Algorithm [I-D.ietf-lsr-flex-algo]. 214 o Flags: 8-bit flags. Currently all the flags are reserved for 215 future use. They SHOULD be set to zero on transmission and MUST 216 be ignored on receipt. 218 o Sub-TLVs: optional sub-TLVs to specify the additional attributes 219 of a VTN. Currently no sub-TLV is defined in this document. 221 The VTND Sub-TLV MAY be advertised in an LSP of any number. A node 222 MUST NOT advertise more than one VTND Sub-TLV for a given VTN ID. 224 3. Advertisement of VTN Topology Attribute 226 This section describes the mechanisms used to advertise the topology 227 attribute associated with SR based VTNs. Basically the topology of a 228 VTN can be determined by the MT-ID and/or the algorithm ID included 229 in the VTN definition. In practice, it could be described using two 230 optional approaches. 232 The first approach is to use Multi-Topology Routing (MTR) [RFC4915] 233 [RFC5120] with the segment routing extensions to advertise the 234 topology associated with the SR based VTNs. Different algorithms MAY 235 be used to further specify the computation algorithm or the metric 236 type used for path computation within the topology. Multiple VTNs 237 can be associated with the same , and the IGP 238 computation with the tuple can be shared by 239 these VTNs. 241 The second approach is to use Flex-Algo [I-D.ietf-lsr-flex-algo] to 242 describe the topological constraints of SR based VTNs on a shared 243 network topology (e.g. the default topology). Multiple VTNs can be 244 associated with the same Flex-Algo, and the IGP computation with this 245 Flex-Algo can be shared by these VTNs. 247 3.1. MTR based Topology Advertisement 249 Multi-Topology Routing (MTR) has been defined in [RFC4915] and 250 [RFC5120] to create different network topologies in one network. It 251 also has the capability of specifying customized attributes for each 252 topology. The traditional use cases of multi-topology are to 253 maintain separate topologies for unicast and multicast services, or 254 to create different topologies for IPv4 and IPv6 in a network. There 255 are some limitations when MTR is used with native IP forwarding, the 256 considerations about MT based IP forwarding are described in 257 [RFC5120]. 259 MTR can be used with SR-MPLS data plane. [RFC8667] specifies the IS- 260 IS extensions to support SR-MPLS data plane, in which the Prefix-SID 261 sub-TLVs can be carried in IS-IS TLV 235 (MT IP Reachability) and TLV 262 237 (MT IPv6 IP Reachability), and the Adj-SID sub-TLVs can be 263 carried in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor 264 Attribute). 266 MTR can also be used with SRv6 data plane. 267 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 268 support SRv6 data plane, in which the MT-ID is carried in the SRv6 269 Locator TLV. The SRv6 End SIDs are carried as sub-TLVs in the SRv6 270 Locator TLV, and inherit the topology/algorithm from the parent 271 locator. The SRv6 End.X SIDs are carried as sub-TLVs in the IS-IS 272 TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute), and inherit 273 the topology/algorithm from the parent locator. 275 These IGP extensions for SR-MPLS and SRv6 can be used to advertise 276 and build the topology for a group of SR based VTNs. 278 An algorithm ID MAY be used to further specify the computation 279 algorithm or the metric type used for path computation within the 280 topology. 282 3.2. Flex-Algo based Topology Advertisement 284 [I-D.ietf-lsr-flex-algo] specifies the mechanisms to provide 285 distributed computation of constraint-based paths, and how the SR- 286 MPLS prefix-SIDs and SRv6 locators can be used to steer packets along 287 the constraint-based paths. 289 The Flex-Algo Definition (FAD) can be used to describe the 290 topological constraints for path computation on a network topology. 291 According to the network nodes' participation of a Flex-Algo, and the 292 rules of including or excluding specific Administrative Groups 293 (colors) and the Shared Risk Link Groups (SRLGs), the topology of a 294 VTN can be determined using the associated Flex-Algo on a particular 295 topology (e.g. the default topology). 297 With the mechanisms defined in[RFC8667] [I-D.ietf-lsr-flex-algo], 298 prefix-SID advertisement can be associated with a tuple, in which the algorithm can be a Flex-Algo. This 300 allows network nodes to use the prefix-SID to steer traffic along 301 distributed computed paths according to the identified Flex-Algo in 302 the topology. 304 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 305 support SRv6 data plane, in which the SRv6 locators advertisement can 306 be associated with a specific topology and a specific algorithm, 307 which can be a Flex-Algo. With the mechanism defined in 308 [I-D.ietf-lsr-flex-algo], The SRv6 locator can be used to steer 309 traffic along distributed computed paths according to the identified 310 Flex-Algo in the topology. In addition, topology/algorithm specific 311 SRv6 End SID and End.X SID can be used to enforce traffic over the 312 LFA computed backup path. 314 Multiple Flex-Algos MAY be defined to describe the topological 315 constraints on a shared network topology (e.g. the default topology). 317 4. Advertisement of VTN Resource Attribute 319 This section specifies the mechanisms to advertise the network 320 resource attributes associated with the VTNs. The mechanism of 321 advertising the link resources and attributes associated with VTNs is 322 described. The mechanism of advertising node resources and 323 attributes associated with VTNs are for further study. Two optional 324 approaches are described in the following sub-sections: the first 325 option is the L2 Bundle [RFC8668] based approach, the second option 326 is to extend IGP to advertise per-VTN link TE attributes. 328 4.1. Option 1: L2 Bundle based Approach 330 On a Layer-3 interface, each VTN can be allocated with a subset of 331 link resources (e.g. bandwidth). A subset of link resources may be 332 dedicated to a VTN, or may be shared by a group of VTNs. Each subset 333 of link resource can be represented as a virtual layer-2 member link 334 under the Layer-3 interface, and the Layer-3 interface is considered 335 as a virtual Layer-2 bundle. The Layer-3 interface may also be a 336 physical Layer 2 link bundle, in this case a subset of link resources 337 allocated to a VTN may be provided by one of the physical Layer-2 338 member links. 340 [RFC8668] describes the IS-IS extensions to advertise the link 341 attributes of the Layer 2 member links which comprise a Layer 3 342 interface. Such mechanism can be extended to advertise the 343 attributes of each physical or virtual member links, and its 344 associated VTNs. 346 A new flag "V" (Virtual) is defined in the flag field of the Parent 347 L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV (25). 349 0 1 2 3 4 5 6 7 350 +-+-+-+-+-+-+-+-+ 351 |P|V| | 352 +-+-+-+-+-+-+-+-+ 354 V flag: When the V flag is set, it indicates the member links under 355 the Parent L3 link are virtual member links. When the V flag is 356 clear, it indicates the member links are physical member links. This 357 flag may be used to determine whether all the member links share 358 fates with the parent interface. 360 A new VTN-ID sub-TLV is carried under the L2 Bundle Attribute 361 Descriptors to describe the mapping relationship between the VTNs and 362 the virtual or physical member links. As one or more VTNs may use 363 the same set of link resource on a specific network segment, these 364 VTN IDs will be advertised under the same virtual or physical member 365 link. 367 The format of the VTN-ID Sub-TLV is as below: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type | Length | Flags | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | VTN ID-1 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 ~ ... ~ 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | VTN ID-n | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Where: 383 o Type: TBD 385 o Length: The length of the value field of the sub-TLV. It is 386 variable dependent on the number of VTN IDs included. 388 o Flags: 16 bit flags. All the bits are reserved for future use, 389 which SHOULD be set to 0 on transmission and MUST be ignored on 390 receipt. 392 o VTN IDs: One or more 32-bit identifier to identify the VTNs this 393 member link belongs to. 395 Each physical or virtual member link MAY be associated with a 396 different group of VTNs. Thus each L2 Bundle Attribute Descriptor 397 may carry the link local identifier and attributes of only one Layer 398 2 member link. Multiple L2 Bundle Attribute Descriptors will be used 399 to carry the attributes and the associated VTN-IDs of all the Layer 2 400 member links. 402 The TE attributes of each virtual or physical member link, such as 403 the bandwidth attributes and the SR SIDs, can be advertised using the 404 mechanism as defined in [RFC8668]. 406 4.2. Option 2: Per-VTN Link TE Attributes 408 A Layer-3 interface can participate in multiple VTNs, each of which 409 is allocated with a subset of the forwarding resources of the 410 interface. For each VTN, the associated resources can be described 411 using per-VTN TE attributes. A new VTN-specific TE attribute sub-TLV 412 is defined to advertise the link attributes associated with a VTN. 413 This sub-TLV MAY be advertised as a sub-TLV of the following TLVs: 415 TLV-22 (Extended IS reachability) [RFC5305] 417 TLV-23 (IS Neighbor Attribute) [RFC5311] 419 TLV-141 (Inter-AS Reachability Information) [RFC5316] 421 TLV-222 (MT ISN) [RFC5120] 423 TLV-223 (MT IS Neighbor Attribute) [RFC5311] 425 The format of the sub-TLV is shown as below: 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type | Length | Flags | Reserved | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | VTN ID | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 ~ Sub-sub-TLVs ~ 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Where: 439 o Type: TBD 441 o Length: The length of the value field of the sub-TLV. It is 442 variable dependent on the length of the Sub-sub-TLVs field. 444 o Flags: 8-bit flags. All the 8 bits are reserved for future use, 445 which SHOULD be set to 0 on transmission and MUST be ignored on 446 receipt. 448 o Reserved: 8-bit field reserved for future use, SHOULD be set to 0 449 on transmission and MUST be ignored on receipt. 451 o VTN ID: A 32-bit identifier to identify the VTN the TE attributes 452 associated with. 454 o Sub-sub-TLVs: the optional TLVs which carry the TE attributes 455 associated with the VTN. 457 One sub-sub-TLV "VTN bandwidth sub-sub-TLV" is defined in this 458 document. Its format is shown as below: 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | Length | Flags | Reserved | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Bandwidth | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Where: 470 o Type: TBD 472 o Length: The length of the value field of the sub-sub-TLV. It is 473 set to 6. 475 o Flags: 8-bit flags. All the 8 bits are reserved for future use, 476 which SHOULD be set to 0 on transmission and MUST be ignored on 477 receipt. 479 o Reserved: 8-bit field reserved for future use, SHOULD be set to 0 480 on transmission and MUST be ignored on receipt. 482 o Bandwidth: The bandwidth allocated to the VTN, encoded in 32 bits 483 in IEEE floating point format. 485 The VTN-specific Bandwidth sub-sub-TLV is optional. This sub-sub-TLV 486 SHOULD appear once at most in each VTN-specific TE attribute sub-TLV. 488 5. Advertisement of VTN specific Data Plane Identifiers 490 In order to steer packets to the VTN-specific paths which are 491 computed taking the topology and network resources of the VTN as the 492 constraints, some fields in the data packet needs to be used to infer 493 or identify the VTN the packet belongs to. As multiple VTNs may 494 share the same topology or Flex-Algo, the topology/Flex-Algo specific 495 SR SIDs or Locators cannot be used to distinguish the packets which 496 belong to different VTNs. Some additional data plane identifiers 497 would be needed to identify the VTN a packet belongs to. 499 This section describes the mechanisms to advertise the VTN 500 identifiers in different data plane encapsulations. 502 5.1. Advertisement of VTN-specific SR-MPLS SIDs 504 With SR-MPLS data plane, the VTN identification information can be 505 implicitly carried in the VTN-specific SIDs. Each node SHOULD 506 allocate a unique Prefix-SID for each VTN it participates in. On a 507 Layer-3 interface, if each Layer 2 member link is associated with 508 only one VTN, the adj-SIDs of the L2 member links could also identify 509 the VTNs. If a member link is associated with multiple VTNs, VTN- 510 specific adj-SIDs MAY need to be allocated to help the VTN-specific 511 local protection. 513 A new VTN-specific prefix-SID sub-TLV is defined to advertise the 514 prefix-SID and its associated VTN. This sub-TLV MAY be advertised as 515 a sub-TLV of the following TLVs: 517 TLV-135 (Extended IPv4 Reachability) defined in [RFC5305]. 519 TLV-235 (MT IP Reachability) defined in [RFC5120]. 521 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 523 TLV-237 (MT IPv6 IP Reachability) defined in [RFC5120]. 525 The format of the sub-TLV is shown as below: 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Type | Length | Flags | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | VTN ID | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | SID/Index/Label(Variable) | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Where: 539 o Type: TBD 541 o Length: The length of the value field of the sub-TLV. It is 542 variable dependent on the length of the SID/Index/Label field. 544 o Flags: 16-bit flags. The high-order 8 bits are the same as in the 545 Prefix-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits 546 are reserved for future use, which SHOULD be set to 0 on 547 transmission and MUST be ignored on receipt. 549 o VTN ID: A 32-bit identifier to identify the VTN this prefix-SID 550 associates with. 552 o SID/Index/Label: The same as defined in [RFC8667]. 554 One or more of VTN-specific Prefix-SID sub-TLVs MAY be carried in the 555 Multi-topology IP Reachability TLVs (TLV 235 or TLV 237), the MT-ID 556 of the TLV SHOULD be the same as the MT-ID in the definition of these 557 VTNs. 559 A new VTN-specific Adj-SID sub-TLV is defined to advertise the adj- 560 SID and its associated VTN. This sub-TLV may be advertised as a sub- 561 TLV of the following TLVs: 563 TLV-22 (Extended IS reachability) [RFC5305] 565 TLV-23 (IS Neighbor Attribute) [RFC5311] 567 TLV-25 (L2 Bundle Member Attributes) [RFC8668] 569 TLV-141 (Inter-AS Reachability Information) [RFC5316] 571 TLV-222 (MT ISN) [RFC5120] 573 TLV-223 (MT IS Neighbor Attribute) [RFC5311] 575 The format of the sub-TLV is shown as below: 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Type | Length | Flags | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | VTN ID | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | SID/Index/Label(Variable) | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Where: 589 o Type: TBD 591 o Length: The length of the value field of the sub-TLV. It is 592 variable dependent on the length of the SID/Index/Label field. 594 o Flags: 16-bit flags. The high-order 8 bits are the same as in the 595 Adj-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits are 596 reserved for future use, which SHOULD be set to 0 on transmission 597 and MUST be ignored on receipt. 599 o VTN ID: A 32-bit local identifier to identify the VTN this Adj-SID 600 associates with. 602 o SID/Index/Label: The same as defined in [RFC8667]. 604 One or more VTN-specific Adj-SID sub-TLV MAY be carried in the Multi- 605 topology ISN or Multi-topology IS Attribute TLVs (TLV 222 or TLV 606 223), the MT-ID of the TLV SHOULD be the same as the MT-ID in the 607 definition of these VTNs. 609 5.2. Advertisement of VTN-specific SRv6 Locators and SIDs 611 With SRv6 data plane, the VTN identification information can be 612 implicitly or explicitly carried in the SRv6 Locator of the 613 corresponding VTN, this is to ensure that all network nodes 614 (including both the end nodes and the transit nodes) can identify the 615 VTN to which a packet belongs to. Network nodes SHOULD allocate VTN- 616 specific Locators for each VTN it participates in. The VTN-specific 617 Locators are used as the covering prefix of VTN-specific SRv6 End 618 SIDs, End.X SIDs and other types of SIDs. 620 Each VTN-specific SRv6 Locator MAY be advertised in a separate TLV. 621 When a group of VTNs share the same topology/algorithm, the topology/ 622 algorithm specific Locator is the covering prefix of such group of 623 VTN-specific Locators. Then the advertisement of VTN-specific 624 locators can be optimized to reduce the amount of Locator TLVs 625 advertised in the control plane. 627 A new VTN locator-block sub-TLV under the SRv6 Locator TLV is defined 628 to advertise a set of sub-blocks which follows the topology/algorithm 629 specific Locator. Each VTN locator-block value is assigned to one of 630 the VTNs which share the same topology/algorithm. 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Type | Length | Number of VTNs| Block Length | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | VTN ID #1 | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 ~ Locator Block Value ~ 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 ~ ... ~ 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | VTN ID #n | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 ~ Locator Block Value ~ 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Where: 650 o Type: TBD 651 o Length: The length of the value field of the sub-TLV. It is 652 variable dependent on the number of VTNs and the Block Length. 654 o Number of VTNs: The number of VTNs which share the same topology/ 655 algorithm specific Locator as the covering prefix. 657 o Block Length: The length of the VTN locator-block which follows 658 the length of the topology/algorithm specific Locator. 660 o VTN ID: A 32-bit local identifier to identify the VTN the locator- 661 block is associates with. 663 o Block Value: The value of the VTN locator-block for each VTN. 665 With the VTN locator-block sub-TLV, the VTN-specific Locator can be 666 obtained by concatenating the topology/algorithm specific locator and 667 the locator-block value advertised for the VTN. 669 The SRv6 SIDs inherit the topology/algorithm and the VTN from the 670 parent VTN-specific Locator. 672 5.3. Advertisement of Dedicated Data Plane VTN IDs 674 As the number of VTNs increases, with the mechanism described in 675 [I-D.ietf-spring-sr-for-enhanced-vpn], the number of SR SIDs and SRv6 676 Locators allocated for different VTNs would also increase. In 677 network scenarios where the number of SIDs or Locators becomes a 678 concern, some data plane optimization may be needed to reduce the 679 amount of SR SIDs and Locators allocated. As described in 680 [I-D.dong-teas-enhanced-vpn-vtn-scalability], one approach is to 681 decouple the data plane identifiers used for topology based 682 forwarding and the identifiers used for the VTN-specific processing. 683 Thus a dedicated data plane VTN-ID could be encapsulated in the 684 packet. One possible encapsulation of VTN-ID in IPv6 data plane is 685 proposed in [I-D.dong-6man-enhanced-vpn-vtn-id]. One possible 686 encapsulation of VTN-ID in MPLS data plane is proposed in 687 [I-D.li-mpls-enhanced-vpn-vtn-id]. 689 In that case, the VTN-ID encapsulated in data plane can have the same 690 value as the VTN-ID in control plane, so that the overhead of 691 advertising the mapping between the control plane VTN-IDs and the 692 corresponding data plane identifiers could be saved. 694 6. Security Considerations 696 This document introduces no additional security vulnerabilities to 697 IS-IS. 699 The mechanism proposed in this document is subject to the same 700 vulnerabilities as any other protocol that relies on IGPs. 702 7. IANA Considerations 704 IANA is requested to assign a new code point in the "sub-TLVs for TLV 705 242" registry. 707 Type: TBD1 708 Description: Virtual Transport Network Definition 710 IANA is requested to assign two new code points in the "sub-TLVs for 711 TLVs 22, 23, 25, 141, 222, and 223" registry. 713 Type: TBD2 714 Description: Virtual Transport Network Identifiers 716 Type: TBD3 717 Description: VTN-specific TE attribute sub-TLV 719 Type: TBD4 720 Description: VTN-specific Adj-SID 722 IANA is requested to assign two new code points in the "Sub-TLVs for 723 TLVs 27, 135, 235, 236 and 237 registry". 725 Type: TBD5 726 Description: VTN-specific Prefix-SID 728 Type: TBD6 729 Description: VTN locator-block 731 8. Contributors 733 Hongjie Yang 734 Email: hongjie.yang@huawei.com 736 9. Acknowledgments 738 The authors would like to thank Mach Chen and Dean Cheng for their 739 review and discussion of this document. 741 10. References 742 10.1. Normative References 744 [I-D.ietf-lsr-flex-algo] 745 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 746 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 747 algo-15 (work in progress), April 2021. 749 [I-D.ietf-lsr-isis-srv6-extensions] 750 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 751 Z. Hu, "IS-IS Extension to Support Segment Routing over 752 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-14 753 (work in progress), April 2021. 755 [I-D.ietf-spring-resource-aware-segments] 756 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 757 Z., and F. Clad, "Introducing Resource Awareness to SR 758 Segments", draft-ietf-spring-resource-aware-segments-02 759 (work in progress), February 2021. 761 [I-D.ietf-spring-sr-for-enhanced-vpn] 762 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 763 Z., and F. Clad, "Segment Routing based Virtual Transport 764 Network (VTN) for Enhanced VPN", draft-ietf-spring-sr-for- 765 enhanced-vpn-00 (work in progress), February 2021. 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, 769 DOI 10.17487/RFC2119, March 1997, 770 . 772 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 773 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 774 RFC 4915, DOI 10.17487/RFC4915, June 2007, 775 . 777 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 778 Topology (MT) Routing in Intermediate System to 779 Intermediate Systems (IS-ISs)", RFC 5120, 780 DOI 10.17487/RFC5120, February 2008, 781 . 783 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 784 for Advertising Router Information", RFC 7981, 785 DOI 10.17487/RFC7981, October 2016, 786 . 788 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 789 Decraene, B., Litkowski, S., and R. Shakir, "Segment 790 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 791 July 2018, . 793 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 794 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 795 Extensions for Segment Routing", RFC 8667, 796 DOI 10.17487/RFC8667, December 2019, 797 . 799 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 800 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 801 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 802 December 2019, . 804 10.2. Informative References 806 [I-D.dong-6man-enhanced-vpn-vtn-id] 807 Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual 808 Transport Network Identifier in IPv6 Extension Header", 809 draft-dong-6man-enhanced-vpn-vtn-id-03 (work in progress), 810 February 2021. 812 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 813 Dong, J., Li, Z., Qin, F., Yang, G., and J. N. Guichard, 814 "Scalability Considerations for Enhanced VPN (VPN+)", 815 draft-dong-teas-enhanced-vpn-vtn-scalability-02 (work in 816 progress), February 2021. 818 [I-D.ietf-teas-enhanced-vpn] 819 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 820 Framework for Enhanced Virtual Private Network (VPN+) 821 Services", draft-ietf-teas-enhanced-vpn-07 (work in 822 progress), February 2021. 824 [I-D.li-mpls-enhanced-vpn-vtn-id] 825 Li, Z. and J. Dong, "Carrying Virtual Transport Network 826 Identifier in MPLS Packet", February 2021, 827 . 830 Authors' Addresses 832 Jie Dong 833 Huawei Technologies 835 Email: jie.dong@huawei.com 836 Zhibo Hu 837 Huawei Technologies 839 Email: huzhibo@huawei.com 841 Zhenbin Li 842 Huawei Technologies 844 Email: lizhenbin@huawei.com 846 Xiongyan Tang 847 China Unicom 849 Email: tangxy@chinaunicom.cn 851 Ran Pang 852 China Unicom 854 Email: pangran@chinaunicom.cn 856 Lee JooHeon 857 LG U+ 859 Email: playgame@lguplus.co.kr 861 Stewart Bryant 862 Futurewei Technologies 864 Email: stewart.bryant@gmail.com