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