idnits 2.17.1 draft-dong-lsr-sr-enhanced-vpn-05.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 (February 22, 2021) is 1156 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 463, but not defined == Missing Reference: 'RFC5308' is mentioned on line 421, but not defined == Missing Reference: 'RFC5311' is mentioned on line 473, but not defined == Missing Reference: 'RFC5316' is mentioned on line 469, but not defined ** Obsolete undefined reference: RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-11 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-01 ** 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-02 == Outdated reference: A later version (-04) exists of draft-dong-teas-enhanced-vpn-vtn-scalability-01 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 Summary: 2 errors (**), 0 flaws (~~), 11 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: August 26, 2021 Huawei Technologies 6 X. Tang 7 R. Pang 8 China Unicom 9 L. JooHeon 10 LG U+ 11 S. Bryant 12 Futurewei Technologies 13 February 22, 2021 15 IGP Extensions for Segment Routing based Enhanced VPN 16 draft-dong-lsr-sr-enhanced-vpn-05 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 build a set of Segment Routing (SR) based VTNs. Each VTN can have 31 a customized topology and a set of network resources allocated. 32 Multiple VTNs may shared the same topology, and multiple VTNs may 33 share the same set of network resources on some network segments. 34 This allows flexible combination of network topology and network 35 resource attributes to build a relatively large number of VTNs with a 36 small number of logical topologies. The proposed mechanism is 37 applicable to both Segment Routing with MPLS data plane (SR-MPLS) and 38 segment routing with IPv6 data plane (SRv6). 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC2119]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on August 26, 2021. 63 Copyright Notice 65 Copyright (c) 2021 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. VTN Definition Advertisement . . . . . . . . . . . . . . . . 4 82 3. Advertisement of VTN Topology Attribute . . . . . . . . . . . 5 83 3.1. MTR based Topology Advertisement . . . . . . . . . . . . 6 84 3.2. Flex-Algo based Topology Advertisement . . . . . . . . . 6 85 4. Advertisement of VTN Resource Attribute . . . . . . . . . . . 7 86 5. Advertisement of VTN specific Data Plane Identifiers . . . . 9 87 5.1. Advertisement of VTN-specific SR-MPLS SIDs . . . . . . . 9 88 5.2. Advertisement of VTN-specific SRv6 Locators and SIDs . . 12 89 5.3. Advertisement of Dedicated Data Plane VTN IDs . . . . . . 13 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 95 9.2. Informative References . . . . . . . . . . . . . . . . . 16 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 98 1. Introduction 100 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 101 needs of new applications, particularly the applications that are 102 associated with 5G services. These applications require enhanced 103 isolation and have more stringent performance requirements than that 104 can be provided with traditional overlay VPNs. These properties 105 require integration between the underlay and the overlay networks. 106 [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN 107 and describes the candidate component technologies in different 108 network planes and layers. An enhanced VPN can be used for 5G 109 network slicing, and will also be of use in more generic scenarios. 111 To meet the requirement of different enhanced VPN services, a number 112 of virtual underlay networks need to be created, each with a 113 customized network topology and a set of network resources allocated 114 from the physical network to meet the requirement of one or a group 115 of VPN+ services. Such a virtual underlay network is called Virtual 116 Transport Network (VTN) in [I-D.ietf-teas-enhanced-vpn]. 118 [I-D.ietf-spring-resource-aware-segments] introduces resource-aware 119 segments by associating existing type of SIDs with network resource 120 attributes (e.g. bandwidth, processing or storage resources). These 121 resource-aware SIDs retain their original functionality, with the 122 additional semantics of identifying the set of network resources 123 available for the packet processing 124 action.[I-D.ietf-spring-sr-for-enhanced-vpn] describes the use of 125 resource-aware segments to build SR based VTNs. To allow the network 126 controller and network nodes to perform VTN-specific explicit path 127 computation and/or shortest path computation, the group of resource- 128 aware SIDs allocated by network nodes to each VTN and the associated 129 topology and resource attributes need to be distributed using the 130 control plane. 132 [I-D.dong-teas-enhanced-vpn-vtn-scalability] analyzes the scalability 133 requirements and the control plane and data plane scalability 134 considerations of enhanced VPN, more specifically, the scalability of 135 the VTN. In order to support the increasing number of VTNs in the 136 network, one proposed approach is to separate the topology and 137 resource attributes of the VTN in control plane, so that the 138 advertisement and processing of each type of attribute could be 139 decoupled. Multiple VTNs may shared the same topology, and multiple 140 VTNs may share the same set of network resources on some network 141 segments., while the difference in either topology or resource 142 attributes makes them different VTNs. This allows flexible 143 combination of network topology and network resource attributes to 144 build a large number of VTNs with a relatively small number of 145 logical topologies. 147 This document specifies the IGP control plane mechanisms with 148 necessary extensions to build SR based VTNs. The proposed mechanism 149 is applicable to both segment routing with MPLS data plane (SR-MPLS) 150 and segment routing with IPv6 data plane (SRv6). 152 In general this approach applies to both IS-IS and OSPF, while the 153 specific protocol extensions and encodings are different. In the 154 current version of this document, the required IS-IS extensions are 155 described. The required OSPF extensions will be described in a 156 future version or in a separate document. 158 2. VTN Definition Advertisement 160 According to [I-D.ietf-teas-enhanced-vpn], a VTN has a customized 161 network topology and a set of dedicated or shared network resources. 162 Thus a VTN can be defined as the combination of a set of network 163 attributes, which include the topology attribute and other 164 attributes, such as the network resources. IS-IS Virtual Transport 165 Network Definition (VTND) sub-TLV is used to advertise the definition 166 of a VTN. It is a sub-TLV of the IS-IS Router-Capability TLV 242 as 167 defined in [RFC7981]. 169 The format of IS-IS VTND sub-TLV is as below: 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | Length | VTN ID | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | VTN ID (Continue) | MT-ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Algorithm | Flags | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 ~ Sub-TLVs ~ 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Where: 187 o Type: TBD 188 o Length: The length of the value field of the sub-TLV. It is 189 variable dependent on the included sub-TLVs. 191 o VTN ID: A global significant 32-bit identifier which is used to 192 identify a VTN. 194 o MT-ID: 16-bit field which indicates the multi-topology identifier 195 as defined in [RFC5120]. The first 4-bit are set to zero. 197 o Algorithm: 8-bit identifier which indicates the algorithm which 198 applies to this VTN. It can be either a normal algorithm 199 [RFC8402] or a Flex-Algorithm [I-D.ietf-lsr-flex-algo]. 201 o Flags: 8-bit flags. Currently all the flags are reserved for 202 future use. They SHOULD be set to zero on transmission and MUST 203 be ignored on receipt. 205 o Sub-TLVs: optional sub-TLVs to specify the additional attributes 206 of a VTN. Currently no sub-TLV is defined in this document. 208 The VTND Sub-TLV MAY be advertised in an LSP of any number. A node 209 MUST NOT advertise more than one VTND Sub-TLV for a given VTN ID. 211 3. Advertisement of VTN Topology Attribute 213 This section describes the mechanisms used to advertise the topology 214 attribute of SR based VTNs. Basically the topology attribute of a 215 VTN can be determined by the MT-ID and/or the algorithm ID included 216 in the VTN definition. In practice, it could be described using two 217 optional approaches. 219 The first approach is to use Multi-Topology Routing (MTR) [RFC4915] 220 [RFC5120] with the segment routing extensions to advertise the 221 topology associated with the SR based VTNs. Different algorithms MAY 222 be used to further specify the computation algorithm or the metric 223 type used for path computation within the topology. Multiple VTNs 224 can be associated with the same , and the IGP 225 computation with the tuple can be shared by 226 these VTNs. 228 The second approach is to use Flex-Algo [I-D.ietf-lsr-flex-algo] to 229 describe the topological constraints of SR based VTNs on a shared 230 network topology (e.g. the default topology). Multiple VTNs can be 231 associated with the same Flex-Algo, and the IGP computation with this 232 Flex-Algo can be shared. 234 3.1. MTR based Topology Advertisement 236 Multi-Topology Routing (MTR) has been defined in [RFC4915] and 237 [RFC5120] to create different network topologies in one network. It 238 also has the capability of specifying customized attributes for each 239 topology. The traditional use cases of multi-topology are to 240 maintain separate topologies for unicast and multicast services, or 241 to create different topologies for IPv4 and IPv6 in a network. There 242 are some limitations when MTR is used with native IP forwarding, the 243 considerations about MT based IP forwarding are described in 244 [RFC5120]. 246 MTR can be used with SR-MPLS data plane. [RFC8667] specifies the IS- 247 IS extensions to support SR-MPLS data plane, in which the Prefix-SID 248 sub-TLVs can be carried in IS-IS TLV 235 (MT IP Reachability) and TLV 249 237 (MT IPv6 IP Reachability), and the Adj-SID sub-TLVs can be 250 carried in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor 251 Attribute). 253 MTR can also be used with SRv6 data plane. 254 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 255 support SRv6 data plane, in which the MT-ID is carried in the SRv6 256 Locator TLV. The SRv6 End SIDs are carried as sub-TLVs in the SRv6 257 Locator TLV, and inherit the topology/algorithm from the parent 258 locator. The SRv6 End.X SIDs are carried as sub-TLVs in the IS-IS 259 TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute), and inherit 260 the topology/algorithm from the parent locator. 262 These IGP extensions for SR-MPLS and SRv6 can be used to advertise 263 and build the topology of SR based VTNs. 265 An algorithm ID MAY be used to further specify the computation 266 algorithm or the metric type used for path computation within the 267 topology. 269 3.2. Flex-Algo based Topology Advertisement 271 [I-D.ietf-lsr-flex-algo] specifies the mechanisms to provide 272 distributed computation of constraint-based paths, and how the SR- 273 MPLS prefix-SIDs and SRv6 locators can be used to steer packets along 274 the constraint-based paths. 276 The Flex-Algo Definition (FAD) can be used to describe the 277 topological constraints for path computation on a network topology. 278 According to the network nodes' participation of a Flex-Algo, and the 279 rules of including or excluding specific Administrative Groups 280 (colors) and the Shared Risk Link Groups (SRLGs), the topology of a 281 VTN can be determined using the associated Flex-Algo on a particular 282 topology (e.g. the default topology). 284 With the mechanisms defined in[RFC8667] [I-D.ietf-lsr-flex-algo], 285 prefix-SID advertisement can be associated with a tuple, in which the algorithm can be a Flex-Algo. This 287 allows network nodes to use the prefix-SID to steer traffic along 288 distributed computed paths according to the identified Flex-Algo in 289 the topology. 291 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 292 support SRv6 data plane, in which the SRv6 locators advertisement can 293 be associated with a specific topology and a specific algorithm, 294 which can be a Flex-Algo. With the mechanism defined in 295 [I-D.ietf-lsr-flex-algo], The SRv6 locator can be used to steer 296 traffic along distributed computed paths according to the identified 297 Flex-Algo in the topology. In addition, topology/algorithm specific 298 SRv6 End SID and End.X SID can be used to enforce traffic over the 299 LFA computed backup path. 301 Multiple Flex-Algos MAY be defined to describe the topological 302 constraints on a shared network topology (e.g. the default topology). 304 4. Advertisement of VTN Resource Attribute 306 This section specifies the mechanism to advertise the network 307 resource attributes associated with the VTNs. The mechanism of 308 advertising the link resources and attributes associated with VTNs is 309 described. The mechanism of advertising node resources and 310 attributes associated with VTNs are for further study. 312 On a Layer-3 interface, each VTN can be allocated with a subset of 313 link resources (e.g. bandwidth). A subset of link resources may be 314 dedicated to a VTN, or may be shared by a group of VTNs. Each subset 315 of link resource can be represented as a virtual layer-2 member link 316 under the Layer-3 interface, and the Layer-3 interface is considered 317 as a virtual Layer-2 bundle. The Layer-3 interface may also be a 318 physical Layer 2 link bundle, in this case a subset of link resources 319 allocated to a VTN may be provided by one of the physical Layer-2 320 member links. 322 [RFC8668] describes the IS-IS extensions to advertise the link 323 attributes of the Layer 2 member links which comprise a Layer 3 324 interface. Such mechanism can be extended to advertise the 325 attributes of each physical or virtual member links, and its 326 associated VTNs. 328 A new flag "V" (Virtual) is defined in the flag field of the Parent 329 L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV (25). 331 0 1 2 3 4 5 6 7 332 +-+-+-+-+-+-+-+-+ 333 |P|V| | 334 +-+-+-+-+-+-+-+-+ 336 V flag: When the V flag is set, it indicates the member links under 337 the Parent L3 link are virtual member links. When the V flag is 338 clear, it indicates the member links are physical member links. This 339 flag may be used to determine whether all the member links share 340 fates with the parent interface. 342 A new VTN-ID sub-TLV is carried under the L2 Bundle Attribute 343 Descriptors to describe the mapping relationship between the VTNs and 344 the virtual or physical member links. As one or more VTNs may use 345 the same set of link resource on a specific network segment, these 346 VTN IDs will be advertised under the same virtual or physical member 347 link. 349 The format of the VTN-ID Sub-TLV is as below: 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Type | Length | Flags | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | VTN ID-1 | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 ~ ... ~ 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | VTN ID-n | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Where: 365 o Type: TBD 367 o Length: The length of the value field of the sub-TLV. It is 368 variable dependent on the number of VTN IDs included. 370 o Flags: 16 bit flags. All the bits are reserved for future use, 371 which SHOULD be set to 0 on transmission and MUST be ignored on 372 receipt. 374 o VTN IDs: One or more 32-bit identifier to identify the VTNs this 375 member link belongs to. 377 Each physical or virtual member link MAY be associated with a 378 different group of VTNs. Thus each L2 Bundle Attribute Descriptor 379 may carry the link local identifier and attributes of only one Layer 380 2 memer link. Multiple L2 Bundle Attribute Descriptors will be used 381 to carry the attributes and the associated VTN-IDs of all the Layer 2 382 member links. 384 The TE attributes of each virtual or physical member link, such as 385 the bandwidth attributes and the SR SIDs, can be advertised using the 386 mechanism as defined in [RFC8668]. 388 5. Advertisement of VTN specific Data Plane Identifiers 390 In order to steer packets to the VTN-specific paths which are 391 computed taking the topology and network resources of the VTN as the 392 constraints, some fields in the data packet needs to be used to infer 393 or identify the VTN the packet belongs to. As multiple VTNs may 394 share the same topology or Flex-Algo, the topology/Flex-Algo specific 395 SR SIDs or Locators cannot be used to distinguish the packets which 396 belong to different VTNs. Some additional data plane identifiers 397 would be needed to identify the VTN a packet belongs to. 399 This section describes the mechanisms to advertise the VTN 400 identifiers in different data plane encapsulations. 402 5.1. Advertisement of VTN-specific SR-MPLS SIDs 404 With SR-MPLS data plane, the VTN identification information can be 405 implicitly carried in the VTN-specific SIDs. Each node SHOULD 406 allocate a unique Prefix-SID for each VTN it participates in. On a 407 Layer-3 interface, if each Layer 2 member link is associated with 408 only one VTN, the adj-SIDs of the L2 member links could also identify 409 the VTNs. If a member link is associated with multiple VTNs, VTN- 410 specific adj-SIDs MAY need to be allocated to help the VTN-specific 411 local protection. 413 A new VTN-specific prefix-SID sub-TLV is defined to advertise the 414 prefix-SID and its associated VTN. This sub-TLV may be advertised as 415 a sub-TLV of the following TLVs: 417 TLV-135 (Extended IPv4 Reachability) defined in [RFC5305]. 419 TLV-235 (MT IP Reachability) defined in [RFC5120]. 421 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 423 TLV-237 (MT IPv6 IP Reachability) defined in [RFC5120]. 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 | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | VTN ID | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | SID/Index/Label(Variable) | 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 SID/Index/Label field. 444 o Flags: 16-bit flags. The high-order 8 bits are the same as in the 445 Prefix-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits 446 are reserved for future use, which SHOULD be set to 0 on 447 transmission and MUST be ignored on receipt. 449 o VTN ID: A 32-bit identifier to identify the VTN this prefix-SID 450 associates with. 452 o SID/Index/Label: The same as defined in [RFC8667]. 454 One or more of VTN-specific Prefix-SID sub-TLVs MAY be carried in the 455 Multi-topology IP Reachability TLVs (TLV 235 or TLV 237), the MT-ID 456 of the TLV SHOULD be the same as the MT-ID in the definition of these 457 VTNs. 459 A new VTN-specific Adj-SID sub-TLV is defined to advertise the adj- 460 SID and its associated VTN. This sub-TLV may be advertised as a sub- 461 TLV of the following TLVs: 463 TLV-22 (Extended IS reachability) [RFC5305] 465 TLV-23 (IS Neighbor Attribute) [RFC5311] 467 TLV-25 (L2 Bundle Member Attributes) [RFC8668] 469 TLV-141 (Inter-AS Reachability Information) [RFC5316] 471 TLV-222 (MT ISN) [RFC5120] 473 TLV-223 (MT IS Neighbor Attribute) [RFC5311] 475 The format of the sub-TLV is shown as below: 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Type | Length | Flags | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | VTN ID | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | SID/Index/Label(Variable) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Where: 489 o Type: TBD 491 o Length: The length of the value field of the sub-TLV. It is 492 variable dependent on the length of the SID/Index/Label field. 494 o Flags: 16-bit flags. The high-order 8 bits are the same as in the 495 Adj-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits are 496 reserved for future use, which SHOULD be set to 0 on transmission 497 and MUST be ignored on receipt. 499 o VTN ID: A 32-bit local identifier to identify the VTN this Adj-SID 500 associates with. 502 o SID/Index/Label: The same as defined in [RFC8667]. 504 One or more VTN-specific Adj-SID sub-TLV MAY be carried in the Multi- 505 topology ISN or Multi-topology IS Attribute TLVs (TLV 222 or TLV 506 223), the MT-ID of the TLV SHOULD be the same as the MT-ID in the 507 definition of these VTNs. 509 5.2. Advertisement of VTN-specific SRv6 Locators and SIDs 511 With SRv6 data plane, the VTN identification information can be 512 implicitly or explicitly carried in the SRv6 Locator of the 513 corresponding VTN, this is to ensure that all network nodes 514 (including both the end nodes and the transit nodes) can identify the 515 VTN to which a packet belongs to. Network nodes SHOULD allocate VTN- 516 specific Locators for each VTN it participates in. The VTN-specific 517 Locators are used as the covering prefix of VTN-specific SRv6 End 518 SIDs, End.X SIDs and other types of SIDs. 520 Each VTN-specific SRv6 Locator MAY be advertised in a separate TLV. 521 When a group of VTNs share the same topology/algorithm, the topology/ 522 algorithm specific Locator is the covering prefix of such group of 523 VTN-specific Locators. Then the advertisement of VTN-specific 524 locators can be optimized to reduce the amount of Locator TLVs 525 advertised in the control plane. 527 A new VTN locator-block sub-TLV under the SRv6 Locator TLV is defined 528 to advertise a set of sub-blocks which follows the topology/algorithm 529 specific Locator. Each VTN locator-block value is assigned to one of 530 the VTNs which share the same topology/algorithm. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Type | Length | Number of VTNs| Block Length | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | VTN ID #1 | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 ~ Locator Block Value ~ 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 ~ ... ~ 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | VTN ID #n | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 ~ Locator Block Value ~ 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Where: 550 o Type: TBD 552 o Length: The length of the value field of the sub-TLV. It is 553 variable dependent on the number of VTNs and the Block Length. 555 o Number of VTNs: The number of VTNs which share the same topology/ 556 algorithm specific Locator as the covering prefix. 558 o Block Length: The length of the VTN locator-block whih follows the 559 length of the topology/algorithm specific Locator. 561 o VTN ID: A 32-bit local identifier to identify the VTN the locator- 562 block is associates with. 564 o Block Value: The value of the VTN locator-block for each VTN. 566 With the VTN locator-block sub-TLV, the VTN-specific Locator can be 567 obtained by concatenating the topology/algorithm specific locator and 568 the locator-block value advertised for the VTN. 570 5.3. Advertisement of Dedicated Data Plane VTN IDs 572 As the number of VTNs increases, with the mechanism described in 573 [I-D.ietf-spring-sr-for-enhanced-vpn], the number of SR SIDs and SRv6 574 Locators allocated for different VTNs would also increase. In 575 network scenarios where the number of SIDs or Locators becomes a 576 concern, some data plane optimization may be needed to reduce the 577 amount of SR SIDs and Locators allocated. As described in 578 [I-D.dong-teas-enhanced-vpn-vtn-scalability], one approach is to 579 decouple the data plane identifiers used for topology based 580 forwarding and the identifiers used for the VTN-specific processing. 581 Thus a dedicated data plane VTN-ID could be encapsulated in the 582 packet. One possible encapsulation of VTN-ID in IPv6 data plane is 583 proposed in [I-D.dong-6man-enhanced-vpn-vtn-id]. One possible 584 encapsulation of VTN-ID in MPLS data plane is proposed in 585 [I-D.li-mpls-enhanced-vpn-vtn-id]. 587 In that case, the VTN-ID encapsulated in data plane can have the same 588 value as the VTN-ID in control plane, so that the overhead of 589 advertising the mapping between the control plane VTN-IDs and the 590 corresponding data plane identifiers could be saved. 592 6. Security Considerations 594 This document introduces no additional security vulnerabilities to 595 IS-IS. 597 The mechanism proposed in this document is subject to the same 598 vulnerabilities as any other protocol that relies on IGPs. 600 7. IANA Considerations 602 IANA is requested to assign a new code point in the "sub-TLVs for TLV 603 242" registry. 605 Type: TBD1 606 Description: Virtual Transport Network Definition 608 IANA is requested to assign two new code points in the "sub-TLVs for 609 TLVs 22, 23, 25, 141, 222, and 223" registry. 611 Type: TBD2 612 Description: Virtual Transport Network Identifiers 614 Type: TBD3 615 Description: VTN-specific Adj-SID 617 IANA is requested to assign two new code points in the "Sub-TLVs for 618 TLVs 27, 135, 235, 236 and 237 registry". 620 Type: TBD4 621 Description: VTN-specific Prefix-SID 623 Type: TBD5 624 Description: VTN locator-block 626 8. Acknowledgments 628 The authors would like to thank Mach Chen and Dean Cheng for their 629 review and discussion of this document. 631 9. References 633 9.1. Normative References 635 [I-D.ietf-lsr-flex-algo] 636 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 637 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 638 algo-13 (work in progress), October 2020. 640 [I-D.ietf-lsr-isis-srv6-extensions] 641 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 642 Z. Hu, "IS-IS Extension to Support Segment Routing over 643 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 644 (work in progress), October 2020. 646 [I-D.ietf-spring-resource-aware-segments] 647 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 648 Z., and F. Clad, "Introducing Resource Awareness to SR 649 Segments", draft-ietf-spring-resource-aware-segments-01 650 (work in progress), January 2021. 652 [I-D.ietf-spring-sr-for-enhanced-vpn] 653 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 654 Z., and F. Clad, "Segment Routing based Virtual Transport 655 Network (VTN) for Enhanced VPN", February 2021, 656 . 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, 661 DOI 10.17487/RFC2119, March 1997, 662 . 664 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 665 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 666 RFC 4915, DOI 10.17487/RFC4915, June 2007, 667 . 669 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 670 Topology (MT) Routing in Intermediate System to 671 Intermediate Systems (IS-ISs)", RFC 5120, 672 DOI 10.17487/RFC5120, February 2008, 673 . 675 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 676 for Advertising Router Information", RFC 7981, 677 DOI 10.17487/RFC7981, October 2016, 678 . 680 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 681 Decraene, B., Litkowski, S., and R. Shakir, "Segment 682 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 683 July 2018, . 685 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 686 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 687 Extensions for Segment Routing", RFC 8667, 688 DOI 10.17487/RFC8667, December 2019, 689 . 691 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 692 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 693 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 694 December 2019, . 696 9.2. Informative References 698 [I-D.dong-6man-enhanced-vpn-vtn-id] 699 Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual 700 Transport Network Identifier in IPv6 Extension Header", 701 draft-dong-6man-enhanced-vpn-vtn-id-02 (work in progress), 702 November 2020. 704 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 705 Dong, J., Li, Z., Qin, F., and G. Yang, "Scalability 706 Considerations for Enhanced VPN (VPN+)", draft-dong-teas- 707 enhanced-vpn-vtn-scalability-01 (work in progress), 708 November 2020. 710 [I-D.ietf-teas-enhanced-vpn] 711 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 712 Framework for Enhanced Virtual Private Networks (VPN+) 713 Service", draft-ietf-teas-enhanced-vpn-06 (work in 714 progress), July 2020. 716 [I-D.li-mpls-enhanced-vpn-vtn-id] 717 Li, Z. and J. Dong, "Carrying Virtual Transport Network 718 Identifier in MPLS Packet", February 2021, 719 . 722 Authors' Addresses 724 Jie Dong 725 Huawei Technologies 727 Email: jie.dong@huawei.com 729 Zhibo Hu 730 Huawei Technologies 732 Email: huzhibo@huawei.com 734 Zhenbin Li 735 Huawei Technologies 737 Email: lizhenbin@huawei.com 738 Xiongyan Tang 739 China Unicom 741 Email: tangxy@chinaunicom.cn 743 Ran Pang 744 China Unicom 746 Email: pangran@chinaunicom.cn 748 Lee JooHeon 749 LG U+ 751 Email: playgame@lguplus.co.kr 753 Stewart Bryant 754 Futurewei Technologies 756 Email: stewart.bryant@gmail.com