idnits 2.17.1 draft-dong-lsr-sr-enhanced-vpn-03.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 (March 9, 2020) is 1499 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 443, but not defined == Missing Reference: 'RFC5308' is mentioned on line 401, but not defined == Missing Reference: 'RFC5311' is mentioned on line 451, but not defined == Missing Reference: 'RFC5316' is mentioned on line 447, but not defined ** Obsolete undefined reference: RFC 5316 (Obsoleted by RFC 9346) == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-06 ** Downref: Normative reference to an Informational draft: draft-dong-spring-sr-for-enhanced-vpn (ref. 'I-D.dong-spring-sr-for-enhanced-vpn') == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-06 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-06 == Outdated reference: A later version (-06) exists of draft-dong-6man-enhanced-vpn-vtn-id-00 == Outdated reference: A later version (-04) exists of draft-dong-teas-enhanced-vpn-vtn-scalability-00 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-05 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: September 10, 2020 Huawei Technologies 6 S. Bryant 7 Futurewei Technologies 8 March 9, 2020 10 IGP Extensions for Segment Routing based Enhanced VPN 11 draft-dong-lsr-sr-enhanced-vpn-03 13 Abstract 15 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 16 needs of new applications, particularly including the applications 17 that are associated with 5G services. These applications require 18 enhanced isolation and have more stringent performance requirements 19 than that can be provided with traditional overlay VPNs. An enhanced 20 VPN may be used for 5G transport network slicing, and will also be of 21 use in more generic scenarios. To meet the requirement of enhanced 22 VPN services, a number of Virtual Transport Networks (VTN) need to be 23 created, each with a subset of the underlay network topology and a 24 set of network resources allocated to meet the requirement of a 25 specific VPN+ service, or a group of VPN+ services. 27 This document specifies the IGP mechanisms with necessary extensions 28 to build a set of Segment Routing (SR) based VTNs. The VTNs could be 29 used as the underlay of enhanced VPN service. The proposed mechanism 30 is applicable to both Segment Routing with MPLS data plane (SR-MPLS) 31 and segment routing with IPv6 data plane (SRv6). 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 10, 2020. 56 Copyright Notice 58 Copyright (c) 2020 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. VTN Definition Advertisement . . . . . . . . . . . . . . . . 4 75 3. Advertisement of VTN Topology Attribute . . . . . . . . . . . 5 76 3.1. MTR based Topology Advertisement . . . . . . . . . . . . 5 77 3.2. Flex-Algo based Topology Advertisement . . . . . . . . . 6 78 4. Advertisement of VTN Resource Attribute . . . . . . . . . . . 7 79 5. Advertisement of VTN specific Data Plane Identifiers . . . . 8 80 5.1. Advertisement of VTN-specific MPLS SIDs . . . . . . . . . 9 81 5.2. Advertisement of VTN-specific SRv6 Locators . . . . . . . 11 82 5.3. Advertisement of Dedicated Data Plane VTN IDs . . . . . . 11 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 9.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 94 needs of new applications, particularly including the applications 95 that are associated with 5G services. These applications require 96 enhanced isolation and have more stringent performance requirements 97 than that can be provided with traditional overlay VPNs. These 98 properties cannot be met with pure overlay networks, as they require 99 integration between the underlay and the overlay networks. 100 [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN 101 and describes the candidate component technologies in different 102 network planes and layers. An enhanced VPN can be used for 5G 103 transport network slicing, and will also be of use in more generic 104 scenarios. 106 To meet the requirement of enhanced VPN services, a number of virtual 107 transport networks (VTN) need to be created, each with a subset of 108 the underlay network topology and a set of network resources 109 allocated to meet the requirement of a specific VPN+ service or a 110 group of VPN+ services. 112 [I-D.dong-spring-sr-for-enhanced-vpn] specifies how segment routing 113 (SR) [RFC8402] can be used to build virtual transport networks (VTNs) 114 with the required network topology and network resources to support 115 enhanced VPN services. With segment routing based data plane, 116 Segment Identifiers (SIDs) can be used to represent the topology and 117 the set of network resources allocated by network nodes to a virtual 118 network. The SIDs of each VTN and the associated topology and 119 resource attributes need to be distributed using a control plane. 121 [I-D.dong-teas-enhanced-vpn-vtn-scalability] analyzes the scalability 122 requirements and the control plane and data plane scalability 123 considerations of enhanced VPN, more specificially the scalability of 124 the VTN as the underlay. In order to support the increasing number 125 of VTNs in the network, one proposed approach is to separate the 126 topology and resource attributes of the VTN in the control plane, so 127 that the advertisement and processing of each type of attribute could 128 be decoupled. This also allows flexible combination of topology and 129 resource attribute to build customized VTNs. For example, a group of 130 VTNs can share the same network topology, also a group VTNs can share 131 the same set of network resource on particular network segments. 133 This document specifies the IGP control plane mechanism with 134 necessary extensions to build a set of SR based VTNs. The proposed 135 mechanism is applicable to both segment routing with MPLS data plane 136 (SR-MPLS) and segment routing with IPv6 data plane (SRv6). 138 In general this approach applies to both IS-IS and OSPF, while the 139 specific protocol extensions and encodings are different. In the 140 current version of this document, the required IS-IS extensions are 141 described. The required OSPF extensions will be described in a 142 future version or a separate document. 144 2. VTN Definition Advertisement 146 According to [I-D.ietf-teas-enhanced-vpn], a virtual transport 147 network (VTN) has a customized network topology and a set of 148 dedicated or shared network resources. Thus a VTN can be defined as 149 the combination of a set of network attributes, which include the 150 topology attribute and other attributes, such as network resources. 151 IS-IS Virtual Transport Network Definition (VTND) sub-TLV is used to 152 advertise the definition of a virtual transport network. It is a 153 sub-TLV of the IS-IS Router-Capability TLV 242 as defined in 154 [RFC7981]. 156 The format of IS-IS VTND sub-TLV is as below: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type | Length | VTN ID | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | VTN ID (Continue) | MT-ID | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Algorithm | Flags | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 ~ Sub-TLVs ~ 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Where: 174 o Type: TBD 176 o Length: The length of the value field of the sub-TLV. It is 177 variable dependent on the included sub-TLVs. 179 o VTN ID: A global significant 32-bit identifier which is used to 180 identify a virtual transport network. 182 o MT-ID: 16-bit field which indicates the multi-topology identifier 183 as defined in [RFC5120]. The first 4-bit are set to zero. 185 o Algorithm: 8-bit identifier which indicates the algorithm which 186 applies to this virtual transport network. It can be either a 187 normal algorithm [RFC8402] or a Flex-Algorithm 188 [I-D.ietf-lsr-flex-algo]. 190 o Flags: 8-bit flags. Currently all the flags are reserved for 191 future use. They SHOULD be set to zero on transmission and MUST 192 be ignored on receipt. 194 o Sub-TLVs: optional sub-TLVs to specify the additional attributes 195 of a virtual transport network. Currently no sub-TLV is defined 196 in this document. 198 The VTND Sub-TLV MAY be advertised in an LSP of any number. A node 199 SHOULD advertise the VTND sub-TLV for each VTN it participates in, 200 but it MUST NOT advertise more than one VTND Sub-TLV for a given VTN 201 ID. 203 3. Advertisement of VTN Topology Attribute 205 This section describes the mechanisms used to advertise the topology 206 attribute of SR based VTNs. Basically the topology attribute of a 207 VTN can be determined by the MT-ID and the algorithm included in the 208 VTN definition. In practice, it could be described using two 209 approaches. 211 The first approach is to use Multi-Topology Routing (MTR) [RFC4915] 212 [RFC5120] with the segment routing extensions to advertise the 213 topologies of the SR based VTNs. Different algorithms MAY be used to 214 further specify the computation algorithm or the metric type used for 215 path computation within a topology. 217 The second approach is to use Flex-Algo [I-D.ietf-lsr-flex-algo] to 218 describe the topological constraints of different SR based VTNs on a 219 shared network topology. 221 3.1. MTR based Topology Advertisement 223 Multi-Topology Routing (MTR) has been defined in [RFC4915] and 224 [RFC5120] to create different network topologies in one network. It 225 also has the capability of specifying customized attributes for each 226 topology. The traditional use cases of multi-topology are to 227 maintain separate topologies for unicast and multicast services, or 228 to create different topologies for IPv4 and IPv6 in a network. There 229 are some limitations when MTR is used with native IP forwarding, the 230 considerations about MT based IP forwarding are described in 231 [RFC5120]. 233 MTR can be used with SR-MPLS data plane. [RFC8667] specifies the IS- 234 IS extensions to support SR-MPLS data plane, in which the Prefix-SID 235 sub-TLVs can be carried in IS-IS TLV 235 (MT IP Reachability) and TLV 236 237 (MT IPv6 IP Reachability), and the Adj-SID sub-TLVs can be 237 carried in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor 238 Attribute). 240 MTR can also be used with SRv6 data plane. 241 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 242 support SRv6 data plane, in which the MT-ID is included in the SRv6 243 Locator TLV. The SRv6 End SIDs inherit the topology/algorithm from 244 the parent locator. In addition, the SRv6 End.X SID sub-TLVs can be 245 carried in the IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor 246 Attribute). 248 These IGP extensions for SR-MPLS and SRv6 can be used to advertise 249 and build the topology of SR based VTNs. 251 On each topology, the algorithm MAY be used to further specify the 252 computation algorithm or the metric type used for path computation 253 within the topology. 255 3.2. Flex-Algo based Topology Advertisement 257 [I-D.ietf-lsr-flex-algo] specifies the mechanisms to provide 258 distributed computation of constraint-based paths, and how the SR- 259 MPLS prefix-SIDs and SRv6 locators can be used to steer packets along 260 the constraint-based paths. 262 The Flex-Algo definition can be used to describe the topological 263 constraints for path computation on a network topology. According to 264 the network nodes' participation of a Flex-Algo, and the rules of 265 including or excluding specific Admin Groups (colors) and Shared Risk 266 Link Groups (SRLGs), the topology of a VTN can be determined using 267 the associated Flex-Algo on a default topology. 269 With the mechanisms defined in[RFC8667] [I-D.ietf-lsr-flex-algo], 270 prefix-SID advertisement can be associated with a specific topology 271 and a specific algorithm, which can be a Flex-Algo. This allows the 272 nodes to use the prefix-SID to steer traffic along distributed 273 computed paths according to the identified Flex-Algo in the 274 associated topology. 276 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 277 support SRv6 data plane, in which the SRv6 locators advertisement can 278 be associated with a specific topology and a specific algorithm, 279 which can be a Flex-Algo. With the mechanism defined in 280 [I-D.ietf-lsr-flex-algo], The SRv6 locator can be used to steer 281 traffic along distributed computed paths according to the identified 282 Flex-Algo in the associated topology. In addition, topology/ 283 algorithm specific SRv6 End SID and End.X SID can be used to enforce 284 traffic over the LFA computed backup path. 286 In some cases, multiple Flex-Algos MAY be defined to describe the 287 topological constraints on a shared network topology. 289 4. Advertisement of VTN Resource Attribute 291 This section specifies the mechanism to advertise the network 292 resource attributes associated with the VTNs. The mechanism of 293 advertising the link level resources is described. The mechanism of 294 advertising node resource are for further study. 296 On a Layer 3 interface, a subset of the link resource can be 297 allocated to a specific VTN. This subset of link resource can be 298 represented as a virtual layer-2 member link of the Layer 3 299 interface. If the Layer 3 interface is a Layer 2 link bundle, it is 300 possible that the subset of link resource is provided by a physical 301 Layer 2 member link. 303 [RFC8668] describes the IS-IS extensions to advertise the link 304 attributes of the Layer 2 member links which comprise an Layer 3 305 interface. Such mechanism can be extended to advertise the 306 attributes of each physical or virtual member links, and its 307 associated VTNs. 309 A new flag "V" (Virtual) is defined in the flag field of the Parent 310 L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV (25). 312 0 1 2 3 4 5 6 7 313 +-+-+-+-+-+-+-+-+ 314 |P|V| | 315 +-+-+-+-+-+-+-+-+ 317 V flag: When the V flag is set, it indicates the member links under 318 the Parent L3 link are virtual member links. When the V flag is 319 clear, it indicates the member links are physical member links. 321 A new VTN-ID sub-TLV is carried under the L2 Bundle member attribute 322 to describe the mapping relationship between the VTNs and the virtual 323 or physical member links of a Layer 3 interface. As one or more VTNs 324 may use the same set of link resource on a specific network segment, 325 these VTN IDs will be advertised under the same virtual or physical 326 member link. 328 The format of the VTN-ID Sub-TLV is as below: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | Flags | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Bundle Member Link Local Identifier | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | VTN ID-1 | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 ~ ... ~ 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | VTN ID-n | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Where: 346 o Type: TBD 348 o Length: The length of the value field of the sub-TLV. It is 349 variable dependent on the number of VTN IDs included. 351 o Flags: 16 bit flags. All the bits are reserved for future use, 352 which SHOULD be set to 0 on transmission and MUST be ignored on 353 receipt. 355 o Bundle Member Link Local Identifier: A 32-bit local identifier of 356 a physical or virtual member link. 358 o VTN IDs: One or more 32-bit identifier to identify the VTNs this 359 member link belongs to. 361 Each physical or virtual member link of an L3 link MAY be associated 362 with a different VTN. Thus multiple VTN-ID sub-TLVs will be carried 363 in the L2 Bundle Attribute Descriptors of the L2 Bundle Member 364 Attributes TLV. 366 The TE attributes of each physical or virtual bundle member link, 367 such as the bandwidth and the adj-SIDs, can be advertised using the 368 mechanism as defined in [RFC8668]. 370 5. Advertisement of VTN specific Data Plane Identifiers 372 In order to steer packet of different VTNs to the constraint-based 373 paths computed using the corresponding topology and set of network 374 resources, information which could be used to infer or identify the 375 VTN a packet belongs to SHOULD be carried in the packet. If each VTN 376 is associated with an independent network topology or Flex-Algo, the 377 topology or Flex-Algo specific SIDs or Locators could be used as the 378 identifier of the VTN in data plane. If multiple VTNs share the same 379 topology or Flex-Algo, some additional data plane identifiers would 380 be needed to identify different VTNs. 382 This section describes the mechanisms to advertise the VTN 383 identifiers with different data plane encapsulations. 385 5.1. Advertisement of VTN-specific MPLS SIDs 387 With SR-MPLS data plane, the VTN identification information is 388 implicitly carried in the SR SIDs of the corresponding VTN. Each 389 node SHOULD allocate VTN-specific Prefix-SIDs for each VTN it 390 participates in. Similarly, VTN-specific Adj-SIDs MAY be allocated 391 for each link which participates in the VTN. 393 A new VTN-specific prefix-SID sub-TLV is defined to advertise the 394 prefix-SID and its associated VTN. This sub-TLV may be advertised as 395 a sub-TLV of the following TLVs: 397 TLV-135 (Extended IPv4 Reachability) defined in [RFC5305]. 399 TLV-235 (MT IP Reachability) defined in [RFC5120]. 401 TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. 403 TLV-237 (MT IPv6 IP Reachability) defined in [RFC5120]. 405 The format of the sub-TLV is shown as below: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Type | Length | Flags | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | VTN ID | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | SID/Index/Label(Variable) | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Where: 419 o Type: TBD 421 o Length: The length of the value field of the sub-TLV. It is 422 variable dependent on the length of the SID/Index/Label field. 424 o Flags: 16-bit flags. The high-order 8 bits are the same as in the 425 Adj-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits are 426 reserved for future use, which SHOULD be set to 0 on transmission 427 and MUST be ignored on receipt. 429 o VTN ID: A 32-bit local identifier to identify the VTN this prefix- 430 SID associates with. 432 o SID/Index/Label: The same as defined in [RFC8667]. 434 One or more of VTN-specific Prefix-SID sub-TLVs MAY be carried in the 435 Multi-topology IP Reachability TLVs (TLV 235 or TLV 236), the MT-ID 436 of the TLV SHOULD be the same as the MT-ID in the definition of these 437 VTNs. 439 A new VTN-specific Adj-SID sub-TLV is defined to advertise the adj- 440 SID and its associated VTN. This sub-TLV may be advertised as a sub- 441 TLV of the following TLVs: 443 TLV-22 (Extended IS reachability) [RFC5305] 445 TLV-23 (IS Neighbor Attribute) [RFC5311] 447 TLV-141 (Inter-AS Reachability Information) [RFC5316] 449 TLV-222 (MT ISN)[RFC5120] 451 TLV-223 (MT IS Neighbor Attribute) [RFC5311] 453 The format of the sub-TLV is shown as below: 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length | Flags | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | VTN ID | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | SID/Index/Label(Variable) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Where: 467 o Type: TBD 469 o Length: The length of the value field of the sub-TLV. It is 470 variable dependent on the length of the SID/Index/Label field. 472 o Flags: 16-bit flags. The high-order 8 bits are the same as in the 473 Adj-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits are 474 reserved for future use, which SHOULD be set to 0 on transmission 475 and MUST be ignored on receipt. 477 o VTN ID: A 32-bit local identifier to identify the VTN this Adj-SID 478 associates with. 480 o SID/Index/Label: The same as defined in [RFC8667]. 482 One or more VTN-specific Adj-SID sub-TLV MAY be carried in the Multi- 483 topology ISN or Multi-topology IS Attribute TLVs (TLV 222 or TLV 484 223), the MT-ID of the TLV SHOULD be the same as the MT-ID in the VTN 485 definition. 487 5.2. Advertisement of VTN-specific SRv6 Locators 489 With SRv6 data plane, the VTN identification information can be 490 implicitly or explicitly carried in the SRv6 Locator of the 491 corresponding VTN. Network nodes SHOULD allocate VTN-specific 492 Locators for each VTN it participates in. The VTN-specific Locators 493 are used as the covering prefix of VTN-specific SRv6 End SIDs and 494 End.X SIDs. 496 Each VTN-specific SRv6 Locator MAY be advertised in a separate TLV. 497 If multiple VTNs share the same topology, the topology/algorithm 498 specific Locator is the covering prefix of a group of VTN-specific 499 Locators. Then the advertisement of VTN-specific locators MAY be 500 optimized to reduce the amount of information exchanged in the 501 control plane. More details about this mechanism will be provided in 502 a future version of this document. 504 5.3. Advertisement of Dedicated Data Plane VTN IDs 506 As the number of VTNs increases, some data plane optimization is 507 needed to reduce the amount of SR SIDs and Locators allocated for 508 VTNs. As described in [I-D.dong-teas-enhanced-vpn-vtn-scalability], 509 one approach is to decouple the identifiers used for topology based 510 forwarding and the identifiers used for the VTN-specific processing 511 executed on packets of different VTNs. Thus a dedicated VTN ID could 512 be encapsulated in the packet. One possible encapsulation is 513 proposed in [I-D.dong-6man-enhanced-vpn-vtn-id]. 515 In that case, the VTN ID encapsulated in data plane can have the same 516 value as the VTN ID in control plane, so that the overhead of 517 advertising the mapping between the VTN ID in control plane and the 518 corresponding data plane identifiers could be saved. 520 6. Security Considerations 522 This document introduces no additional security vulnerabilities to 523 IS-IS and OSPF. 525 The mechanism proposed in this document is subject to the same 526 vulnerabilities as any other protocol that relies on IGPs. 528 7. IANA Considerations 530 IANA is requested to assign a new code point in the "sub-TLVs for TLV 531 242" registry. 533 Type: TBD1 534 Description: Virtul Transport Network Definition 536 IANA is requested to assign two new code points in the "sub-TLVs for 537 TLVs 22, 23, 25, 141, 222, and 223" registry. 539 Type: TBD2 540 Description: Virtual Transport Network Identifiers 542 Type: TBD3 543 Description: VTN-specific Adj-SID 545 IANA is requested to assign a new code point in the "Sub-TLVs for 546 TLVs 135,235,236 and 237 registry". 548 Type: TBD4 549 Description: VTN-specific Prefix-SID 551 8. Acknowledgments 553 The authors would like to thank Mach Chen and Dean Cheng for their 554 review and discussion of this document. 556 9. References 558 9.1. Normative References 560 [I-D.dong-spring-sr-for-enhanced-vpn] 561 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., and 562 Z. Li, "Segment Routing for Resource Partitioned Virtual 563 Networks", draft-dong-spring-sr-for-enhanced-vpn-06 (work 564 in progress), December 2019. 566 [I-D.ietf-lsr-flex-algo] 567 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 568 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 569 algo-06 (work in progress), February 2020. 571 [I-D.ietf-lsr-isis-srv6-extensions] 572 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 573 Z. Hu, "IS-IS Extension to Support Segment Routing over 574 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-06 575 (work in progress), March 2020. 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, 579 DOI 10.17487/RFC2119, March 1997, 580 . 582 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 583 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 584 RFC 4915, DOI 10.17487/RFC4915, June 2007, 585 . 587 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 588 Topology (MT) Routing in Intermediate System to 589 Intermediate Systems (IS-ISs)", RFC 5120, 590 DOI 10.17487/RFC5120, February 2008, 591 . 593 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 594 for Advertising Router Information", RFC 7981, 595 DOI 10.17487/RFC7981, October 2016, 596 . 598 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 599 Decraene, B., Litkowski, S., and R. Shakir, "Segment 600 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 601 July 2018, . 603 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 604 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 605 Extensions for Segment Routing", RFC 8667, 606 DOI 10.17487/RFC8667, December 2019, 607 . 609 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 610 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 611 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 612 December 2019, . 614 9.2. Informative References 616 [I-D.dong-6man-enhanced-vpn-vtn-id] 617 Dong, J. and Z. Li, "Carrying Virtual Transport Network 618 (VTN) Identifier in IPv6 Extensison Header for Enhanced 619 VPN", draft-dong-6man-enhanced-vpn-vtn-id-00 (work in 620 progress), February 2020. 622 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 623 Dong, J., Li, Z., and F. Qin, "Virtual Transport Network 624 (VTN) Scalability Considerations for Enhanced VPN", draft- 625 dong-teas-enhanced-vpn-vtn-scalability-00 (work in 626 progress), February 2020. 628 [I-D.ietf-teas-enhanced-vpn] 629 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 630 Framework for Enhanced Virtual Private Networks (VPN+) 631 Services", draft-ietf-teas-enhanced-vpn-05 (work in 632 progress), February 2020. 634 Authors' Addresses 636 Jie Dong 637 Huawei Technologies 639 Email: jie.dong@huawei.com 641 Zhibo Hu 642 Huawei Technologies 644 Email: huzhibo@huawei.com 646 Zhenbin Li 647 Huawei Technologies 649 Email: lizhenbin@huawei.com 651 Stewart Bryant 652 Futurewei Technologies 654 Email: stewart.bryant@gmail.com