idnits 2.17.1 draft-dong-idr-bgpls-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 (February 22, 2021) is 1130 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) == Unused Reference: 'I-D.ietf-lsr-isis-srv6-extensions' is defined on line 761, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-idr-bgp-ls-flex-algo-05 == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-16 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-05 == Outdated reference: A later version (-17) exists of draft-ietf-idr-rfc7752bis-05 == 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') ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-06) exists of draft-dong-6man-enhanced-vpn-vtn-id-02 == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-04 == Outdated reference: A later version (-04) exists of draft-dong-teas-enhanced-vpn-vtn-scalability-01 == 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 (-17) exists of draft-ietf-teas-enhanced-vpn-06 Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR 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 February 22, 2021 11 BGP-LS Extensions for Segment Routing based Enhanced VPN 12 draft-dong-idr-bgpls-sr-enhanced-vpn-03 14 Abstract 16 Enhanced VPN (VPN+) aims to provide enhanced VPN services to support 17 some applications' needs of enhanced isolation and stringent 18 performance requirements. VPN+ requires integration between the 19 overlay VPN connectivity and the characteristics provided by the 20 underlay network. A Virtual Transport Network (VTN) is a virtual 21 underlay network which consists of a customized network topology and 22 a set of network resource allocated from the physical network. A VTN 23 could be used as the underlay to support one or a group of VPN+ 24 services. 26 This document specifies the BGP-LS mechanisms with necessary 27 extensions to advertise the information of Segment Routing (SR) based 28 VTNs to a centralized network controller. Each VTN can have a 29 customized topology and a set of network resources allocated. 30 Multiple VTNs may shared the same topology, and multiple VTNs may 31 share the same set of network resources on some network segments. 32 This allows flexible combination of network topology and network 33 resource attributes to build a large number of VTNs with a relatively 34 small number of logical topologies. The proposed mechanism is 35 applicable to both segment routing with MPLS data plane (SR-MPLS) and 36 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 August 26, 2021. 61 Copyright Notice 63 Copyright (c) 2021 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. Advertisement of VTN Definition . . . . . . . . . . . . . . . 4 80 3. Advertisement of VTN Topology Attribute . . . . . . . . . . . 5 81 3.1. Intra-domain Topology Advertisement . . . . . . . . . . . 5 82 3.1.1. MTR based Topology Advertisement . . . . . . . . . . 6 83 3.1.2. Flex-Algo based Topology Advertisement . . . . . . . 7 84 3.2. Inter-Domain Topology Advertisement . . . . . . . . . . . 7 85 3.2.1. VTN ID TLV . . . . . . . . . . . . . . . . . . . . . 9 86 4. Advertisement of VTN Resource Attribute . . . . . . . . . . . 10 87 4.1. Link Attribute Flags TLV . . . . . . . . . . . . . . . . 10 88 5. Advertisement of VTN specific Data Plane Identifiers . . . . 11 89 5.1. VTN-specific SR-MPLS SIDs . . . . . . . . . . . . . . . . 11 90 5.1.1. VTN-specific Prefix-SID TLV . . . . . . . . . . . . . 11 91 5.1.2. VTN-specific Adj-SID TLV . . . . . . . . . . . . . . 12 92 5.2. VTN-specific SRv6 Locators . . . . . . . . . . . . . . . 13 93 5.3. Dedicated VTN ID in Data Plane . . . . . . . . . . . . . 14 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 96 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 99 9.2. Informative References . . . . . . . . . . . . . . . . . 16 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 102 1. Introduction 104 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 105 needs of new applications, particularly the applications that are 106 associated with 5G services. These applications require enhanced 107 isolation and have more stringent performance requirements than that 108 can be provided with traditional overlay VPNs. These properties 109 require integration between the underlay and the overlay networks. 110 [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN 111 and describes the candidate component technologies in different 112 network planes and layers. An enhanced VPN can be used for 5G 113 network slicing, and will also be of use in more generic scenarios. 115 To meet the requirement of enhanced VPN services, a number of virtual 116 underlay networks need to be created, each with a subset of the 117 underlay network topology and a set of network resources allocated to 118 meet the requirement of a specific VPN+ service or a group of VPN+ 119 services. Such a virtual underlay network is called Virtual 120 Transport Network (VTN) in [I-D.ietf-teas-enhanced-vpn]. 122 [I-D.ietf-spring-resource-aware-segments] introduces resource- 123 awareness to Segment Routing (SR) [RFC8402] by associating existing 124 type of SIDs with network resource attributes (e.g. bandwidth, 125 processing or storage resources). These resource-aware SIDs retain 126 their original functionality, with the additional semantics of 127 identifying the set of network resources available for the packet 128 processing action. [I-D.ietf-spring-sr-for-enhanced-vpn] describes 129 the use of resource-aware segments to build SR based VTNs. To allow 130 the network controller and network nodes to perform VTN-specific 131 explicit path computation and/or shortest path computation, the group 132 of resource-aware SIDs allocated by network nodes to each VTN and the 133 associated topology and resource attributes need to be distributed in 134 the control plane. 136 When a VTN spans multiple IGP areas or multiple Autonomous Systems 137 (ASes), BGP-LS is needed to advertise the VTN information in each IGP 138 area or AS to the network controller, so that the controller could 139 use the collected information to build the view of inter-area or 140 inter-AS SR VTNs. 142 This document describes BGP-LS [RFC7752] based mechanism with 143 necessary extensions to advertise the topology and resource attribute 144 of inter-area and inter-domain SR based VTNs. Each VTN can have a 145 customized topology and a set of network resources allocated. 146 Multiple VTNs may shared the same topology, and multiple VTNs may 147 share the same set of network resources on some network segments. 148 This allows flexible combination of network topology and network 149 resource attributes to build a large number of VTNs with a relatively 150 small number of logical topologies. The definition of VTN is 151 advertised as a node attribute using BGP-LS. The associated network 152 topology and resources attributes of a VTN are advertised as link 153 attributes using BGP-LS. 155 2. Advertisement of VTN Definition 157 According to [I-D.ietf-teas-enhanced-vpn], a VTN has a customized 158 network topology and a set of dedicated or shared network resources. 159 Thus a VTN can be defined as the combination of a set of network 160 attributes, which include the topology attribute and other 161 attributes, such as the associated network resources. 163 The Virtual Transport Network Definition (VTND) TLV is a new TLV of 164 the optional BGP-LS Attribute which is associated with the node NLRI. 166 The format of VTND TLV is as follows: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type | Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | VTN ID | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | MT-ID | Algorithm | Flags | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Sub-TLVs | 178 ~ ... ~ 179 | | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Where: 184 o Type: TBD 186 o Length: the length of the value field of the TLV. It is variable 187 dependent on the included Sub-TLVs. 189 o VTN ID: A global significant 32-bit identifier which is used to 190 identify a virtual transport network. 192 o MT-ID: 16-bit identifier which indicates the multi-topology 193 identifier of the IGP topology. 195 o Algorithm: 8-bit identifier which indicates the algorithm which 196 applies to this virtual transport network. It can be either a 197 normal algorithm in [RFC8402] or a Flex-Algorithm 198 [I-D.ietf-lsr-flex-algo]. 200 o Flags: 8-bit flags. Currently all the flags are reserved for 201 future use. They SHOULD be set to zero on transmission and MUST 202 be ignored on receipt. 204 o Sub-TLVs: optional sub-TLVs to specify the additional attributes 205 of a virtual transport network. Currently no sub-TLV is defined 206 in this document. 208 3. Advertisement of VTN Topology Attribute 210 [I-D.dong-lsr-sr-enhanced-vpn] describes the IGP mechanisms to 211 distribute the topology attributes of SR based VTNs. This section 212 describes the BGP-LS mechanism to distribute both the intra-domain 213 and inter-domain topology attributes of SR based VTNs. 215 3.1. Intra-domain Topology Advertisement 217 The intra-domain topology attribute of a VTN can be determined by the 218 MT-ID and/or the algorithm ID included in the VTN definition. In 219 practice, it could be described using two optional approaches. 221 The first approach is to use Multi-Topology Routing (MTR) [RFC4915] 222 [RFC5120] with the segment routing extensions to advertise the 223 topology associated with the SR based VTNs. Different algorithms MAY 224 be used to further specify the computation algorithm or the metric 225 type used for path computation within the topology. Multiple VTNs 226 can be associated with the same , and the IGP 227 computation with the tuple can be shared by 228 these VTNs. 230 The second approach is to use Flex-Algo [I-D.ietf-lsr-flex-algo] to 231 describe the topological constraints of SR based VTNs on a shared 232 network topology (e.g. the default topology). Multiple VTNs can be 233 associated with the same Flex-Algo, and the IGP computation with this 234 Flex-Algo can be shared. 236 This section describes the two optional approaches to advertise the 237 intra-domain topology of a VTN using BGP-LS. 239 3.1.1. MTR based Topology Advertisement 241 In section 4.2.2.1 of [I-D.ietf-idr-rfc7752bis], Multi-Topology 242 Identifier (MT-ID) TLV is defined, which can contain one or more IS- 243 IS or OSPF Multi-Topology IDs. The MT-ID TLV MAY be present in a 244 Link Descriptor, a Prefix Descriptor, or the BGP-LS Attribute of a 245 Node NLRI. 247 [I-D.ietf-idr-bgp-ls-segment-routing-ext] defines the BGP-LS 248 extensions to carry the segment routing information using TLVs of 249 BGP-LS Attribute. When MTR is used with SR-MPLS data plane, 250 topology-specific prefix-SIDs and topology-specific Adj-SIDs can be 251 carried in the BGP-LS Attribute associated with the prefix NLRI and 252 link NLRI respectively, the MT-ID TLV is carried in the prefix 253 descriptor or link descriptor to identify the corresponding topology 254 of the SIDs. 256 [I-D.ietf-idr-bgpls-srv6-ext] defines the BGP-LS extensions to 257 advertise SRv6 segments along with their functions and attributes. 258 When MTR is used with SRv6 data plane, the SRv6 Locator TLV is 259 carried in the BGP-LS Attribute associated with the prefix-NLRI, the 260 MT-ID TLV can be carried in the prefix descriptor to identify the 261 corresponding topology of the SRv6 Locator. The SRv6 End.X SIDs are 262 carried in the BGP-LS Attribute associated with the link NLRI, the 263 MT-ID TLV can be carried in the link descriptor to identify the 264 corresponding topology of the End.X SIDs. The SRv6 SID NLRI is 265 defined to advertise other types of SRv6 SIDs, in which the SRv6 SID 266 Descriptors can include the MT-ID TLV so as to advertise topology- 267 specific SRv6 SIDs. 269 [I-D.ietf-idr-rfc7752bis] also defines the rules of the usage of MT- 270 ID TLV: 272 "In a Link or Prefix Descriptor, only a single MT-ID TLV containing 273 the MT-ID of the topology where the link or the prefix is reachable 274 is allowed. In case one wants to advertise multiple topologies for a 275 given Link Descriptor or Prefix Descriptor, multiple NLRIs MUST be 276 generated where each NLRI contains a single unique MT-ID." 278 Editor's note: the above rules indicates that only one MT-ID is 279 allowed to be carried the Link or Prefix descriptors. When a link or 280 prefix needs to be advertised in multiple topologies, multiple NLRIs 281 needs to be generated to report all the topologies the link or prefix 282 participates in, together with the topology-specific segment routing 283 information and link attributes. This may increase the number of BGP 284 Updates needed for advertising MT-specific topology attributes, and 285 may introduce additional processing burden to both the sending BGP 286 speaker and the receiving network controller. When the number of 287 topologies in a network is not a small number, some optimization may 288 be needed for the reporting of multi-topology information and the 289 associated segment routing information in BGP-LS. Based on the WG's 290 opinion, this will be elaborated in a future version. 292 3.1.2. Flex-Algo based Topology Advertisement 294 The Flex-Algo definition [I-D.ietf-lsr-flex-algo] can be used to 295 describe the calculation-type, the metric-type and the topological 296 constraints for path computation on a network topology. As specified 297 in [I-D.dong-lsr-sr-enhanced-vpn], the topology of a VTN can be 298 determined by applying Flex-Algo constraints on a particular 299 topology. 301 BGP-LS extensions for Flex-Algo [I-D.ietf-idr-bgp-ls-flex-algo] 302 provide the mechanisms to advertise the Flex-Algo definition 303 information. BGP-LS extensions for SR-MPLS 304 [I-D.ietf-idr-bgp-ls-segment-routing-ext] and SRv6 305 [I-D.ietf-idr-bgpls-srv6-ext] provide the mechanism to advertise the 306 algorithm-specific segment routing information. 308 In[I-D.ietf-idr-bgp-ls-segment-routing-ext], algorithm-specific 309 prefix-SIDs can be advertised in BGP-LS attribute associated with 310 Prefix NLRI. In [I-D.ietf-idr-bgpls-srv6-ext], algorithm-specific 311 SRv6 Locators can be advertised in BGP-LS Attribute associated with 312 the corresponding Prefix NLRI, and algorithm-specific End.X SID can 313 be advertised in BGP-LS Attribute associated with the corresponding 314 Link NLRI. Other types of SRv6 SIDs can also be algorithm-specific 315 and are advertised using the SRv6 SID NLRI. 317 3.2. Inter-Domain Topology Advertisement 319 In some network scenarios, a VTNs which span multiple areas or ASes 320 needs to be created. The multi-domain VTN could have different 321 inter-domain connectivity, and may be associated with different set 322 of network resources in each domain and also on the inter-domain 323 links. In order to build the multi-domain VTNs using segment 324 routing, it is necessary to advertise the topology and resource 325 attribute of VTN on the inter-domain links and the associated BGP 326 Peering SIDs. 328 [I-D.ietf-idr-bgpls-segment-routing-epe] and 329 [I-D.ietf-idr-bgpls-srv6-ext] defines the BGP-LS extensions for 330 advertisement of BGP topology information between ASes and the 331 associated BGP Peering Segment Identifiers. Such information could 332 be used by a network controller for the computation and instantiation 333 of inter-AS traffic engineering SR paths. 335 Depending on the network scenarios and the requirement of inter- 336 domain VTNs, different mechanisms can be used to specify the inter- 337 domain connections of VTNs. 339 o One EBGP session between two ASes can be established over multiple 340 underlying links. In this case, different underlying links can be 341 used for different inter-domain VTNs which requires link isolation 342 between each other. In another similar case, the EBGP session is 343 established over a single link, while the network resource (e.g. 344 bandwidth) on this link can be partitioned into several pieces, 345 each of which can be considered as a virtual member link. In both 346 cases, different BGP Peer-Adj-SIDs SHOULD be allocated to each 347 underlying physical or virtual member link, and ASBRs SHOULD 348 advertise the VTN identifier associated with each BGP Peer-Adj- 349 SID. 351 o For inter-domain connection between two ASes, multiple EBGP 352 sessions can be established between different set of peering 353 ASBRs. It is possible that some of these BGP sessions are used 354 for one multi-domain VTN, while some other BGP sessions are used 355 for another multi-domain VTN. In this case, different BGP peer- 356 node-SIDs are allocated to each BGP session, and ASBRs SHOULD 357 advertise the VTN identifier associated with each BGP Peer-node- 358 SIDs. 360 o At the AS-level topology, different multi-domain VTNs may have 361 different inter-domain connectivity. Different BGP Peer-Set-SIDs 362 can be allocated to represent the groups of BGP peers which can be 363 used for load-balancing in each multi-domain VTN. 365 In network scenarios where the MT-ID or Flex-Algo is used 366 consistently in multiple areas or ASes covered by a VTN. the 367 approaches to advertise topology-specific BGP peering SIDs are 368 described as below: 370 o Using MT-based mechanism, the topology-specific BGP peering SIDs 371 can be advertised with the MT-ID associated with the VTN carried 372 in the corresponding link NLRI. This can be supported with the 373 existing mechanisms defined in 374 [RFC7752][I-D.ietf-idr-bgpls-segment-routing-epe] and 375 [I-D.ietf-idr-bgpls-srv6-ext]. 377 o Using Flex-Algo based mechanism, the topology-specific BGP peering 378 SIDs can be advertised together with the Admin Group (color) of 379 the corresponding Flex-Algo in the BGP-LS attribute. 381 In network scenarios where consistent usage of MT-ID or Flex-Algo 382 among multiple ASes can not be expected, then the global-significant 383 VTN-ID can be used to define the AS level topologies. Within each 384 domain, the MT or Flex-Algo based mechanism could still be used for 385 topology advertisement. 387 3.2.1. VTN ID TLV 389 A new VTN ID TLV is defined to describe the identifiers of one or 390 more VTNs an intra-domain or inter-domain link belongs to. It can be 391 carried in BGP-LS attribute which is associated with a Link NLRI, or 392 it could be carried as a sub-TLV in the L2 Bundle Member Attribute 393 TLV. 395 The format of VTN ID TLV is as below: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Type | Length | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Flags | Reserved | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | VTN ID-1 | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 ~ ... ~ 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | VTN ID-n | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Where: 413 o Type: TBD 415 o Length: The length of the value field of the sub-TLV. It is 416 variable dependent on the number of VTN IDs included. 418 o Flags: 16 bit flags. All the bits are reserved, which MUST be set 419 to 0 on transmission and ignored on receipt. 421 o Reserved: this field is reserved for future use. MUST be set to 0 422 on transmission and ignored on receipt. 424 o VTN IDs: One or more 32-bit identifiers to specify the VTNs this 425 link or member link belongs to. 427 4. Advertisement of VTN Resource Attribute 429 [I-D.dong-lsr-sr-enhanced-vpn] specifies the mechanism to advertise 430 the resource information associated with each VTN. It is based on 431 the extensions to the advertisement of L2 bundle member links 432 information[RFC8668]. This section defines the corresponding BGP-LS 433 extensions. Two new TLVs are defined to carry the VTN ID and the 434 link attribute flags of either a Layer-3 link or the L2 bundle member 435 links. The VTN ID TLV is defined in section 3.2.1 of this document, 436 and a new Link Attribute Flags TLV is defined in this section. The 437 TE attributes of each Layer 3 link or the L2 bundle member link, such 438 as the bandwidth and the SR SIDs, can be advertised using the 439 mechanism as defined in [I-D.ietf-idr-bgp-ls-segment-routing-ext][I-D 440 .ietf-idr-bgpls-segment-routing-epe] and 441 [I-D.ietf-idr-bgpls-srv6-ext]. 443 4.1. Link Attribute Flags TLV 445 A new Link attribute Flags TLV is defined to specify the 446 characteristics of a link. It can be carried in BGP-LS attribute 447 which is associated with a Link NLRI, or it could be carried as a 448 sub-TLV in the L2 Bundle Member Attribute TLV. The format of the 449 sub-TLV is as below: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Type | Length | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Flags | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Where: 461 Type: TBD 463 Length: 4 octets. 465 Flags: 16-bit flags. This field is consistent with the Flag field 466 in IS-IS Link Attribute sub-TLV in [RFC5029]. In addition to the 467 flags defined in [RFC5029], A new Flag V is defined in this 468 document. When the V flag is set, it indicates this link is a 469 virtual link. 471 5. Advertisement of VTN specific Data Plane Identifiers 473 In network scenarios where each VTN is associated with an independent 474 network topology or Flex-Algo, the topology or Flex-Algo specific 475 SIDs or Locators could be used as the identifier of the VTN in data 476 plane. In network scenarios where multiple VTNs share the same 477 topology or Flex-Algo, additional data plane identifiers would be 478 needed to identify different VTNs. 480 This section describes the mechanisms to advertise the VTN 481 identifiers with different data plane encapsulations. 483 5.1. VTN-specific SR-MPLS SIDs 485 With SR-MPLS data plane, the VTN identification information is 486 implicitly carried in the SR SIDs of the corresponding VTN. Each 487 node SHOULD allocate VTN-specific Prefix-SIDs for each VTN it 488 participates in. Similarly, VTN-specific Adj-SIDs MAY be allocated 489 for each link which participates in the VTN. 491 5.1.1. VTN-specific Prefix-SID TLV 493 A new VTN-specific Prefix-SID TLV is defined to advertise the prefix- 494 SID and its associated VTN. It is derived from VTN specific Prefix- 495 SID sub-TLV of IS-IS [I-D.dong-lsr-sr-enhanced-vpn]. The format of 496 the sub-TLV is as below: 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type | Length | Flags | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | VTN ID | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | SID/Index/Label(Variable) | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Where: 510 o Type: TBD 512 o Length: The length of the value field of the sub-TLV. It is 513 variable dependent on the length of the SID/Index/Label field. 515 o Flags: 16-bit flags. The high-order 8 bits are the same as in the 516 Prefix-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits 517 are reserved for future use, which SHOULD be set to 0 on 518 transmission and MUST be ignored on receipt. 520 o VTN ID: A 32-bit local identifier to identify the VTN this prefix- 521 SID associates with. 523 o SID/Index/Label: The same as defined in [RFC8667]. 525 One or more of VTN-specific Prefix-SID TLVs MAY be carried in BGP-LS 526 attribute of the associated Prefix NLRI. The MT-ID in the Prefix 527 descriptors SHOULD be the same as the MT-ID in the definition of 528 these VTNs. 530 5.1.2. VTN-specific Adj-SID TLV 532 A new VTN-specific Adj-SID TLV is defined to advertise the Adj-SID 533 and its associated VTN. It is derived from VTN specific Adj-SID sub- 534 TLV of IS-IS [I-D.dong-lsr-sr-enhanced-vpn]. The format of the sub- 535 TLV is as below: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type | Length | Flags | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | VTN ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | SID/Index/Label(Variable) | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Where: 549 o Type: TBD 551 o Length: The length of the value field of the sub-TLV. It is 552 variable dependent on the length of the SID/Index/Label field. 554 o Flags: 16-bit flags. The high-order 8 bits are the same as in the 555 Adj-SID sub-TLV defined in [RFC8667]. The lower-order 8 bits are 556 reserved for future use, which SHOULD be set to 0 on transmission 557 and MUST be ignored on receipt. 559 o VTN ID: A 32-bit local identifier to identify the VTN this Adj-SID 560 associates with. 562 o SID/Index/Label: The same as defined in [RFC8667]. 564 Multiple VTN-specific Adj-SID TLVs MAY be carried in BGP-LS attribute 565 of the associated Link NLRI. The MT-ID in the Link descriptors 566 SHOULD be the same as the MT-ID in the definition of these VTNs. 568 5.2. VTN-specific SRv6 Locators 570 With SRv6 data plane, the VTN identification information can be 571 implicitly or explicitly carried in the SRv6 Locator of the 572 corresponding VTN, this is to ensure that all network nodes 573 (including both the SRv6 End nodes and Transit nodes) can identify 574 the VTN to which a packet belongs to. Network nodes SHOULD allocate 575 VTN-specific Locators for each VTN it participates in. The VTN- 576 specific Locators are used as the covering prefix of VTN-specific 577 SRv6 End SIDs, End.X SIDs and other types of SIDs. 579 Each VTN-specific SRv6 Locator MAY be advertised in a separate Prefix 580 NLRI. If multiple VTNs share the same topology/algorithm, the 581 topology/algorithm specific Locator is the covering prefix of a group 582 of VTN-specific Locators. Then the advertisement of VTN-specific 583 locators can be optimized to reduce the amount of information 584 advertised in the control plane. 586 A new VTN locator-block sub-TLV under the SRv6 Locator TLV is defined 587 to advertise a set of sub-blocks which follows the topology/algorithm 588 specific Locator. Each VTN locator-block value is assigned to one of 589 the VTNs which share the same topology/algorithm. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type | Length | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Number of VTNs| Block Length | Reserved | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | VTN ID #1 | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 ~ Locator Block Value ~ 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 ~ ... ~ 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | VTN ID #n | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 ~ Locator Block Value ~ 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Where: 611 o Type: TBD 613 o Length: The length of the value field of the sub-TLV. It is 614 variable dependent on the number of VTNs and the Block Length. 616 o Number of VTNs: The number of VTNs which share the same topology/ 617 algorithm specific Locator as the covering prefix. 619 o Block Length: The length of the VTN locator-block which follows 620 the length of the topology/algorithm specific Locator. 622 o VTN ID: A 32-bit identifier to identify the VTN the locator-block 623 is associates with. 625 o Block Value: The value of the VTN locator-block for each VTN. 627 With the VTN locator-block sub-TLV, the VTN-specific Locator can be 628 obtained by concatenating the topology/algorithm specific locator and 629 the locator-block value advertised for the VTN. 631 5.3. Dedicated VTN ID in Data Plane 633 As the number of VTNs increases, with the mechanism described in 634 [I-D.ietf-spring-sr-for-enhanced-vpn], the number of SR SIDs and SRv6 635 Locators allocated for different VTNs would also increase. In 636 network scenarios where the number of SIDs or Locators becomes a 637 concern, some data plane optimization may be needed to reduce the 638 amount of SR SIDs and Locators allocated. As described in 639 [I-D.dong-teas-enhanced-vpn-vtn-scalability], one approach is to 640 decouple the data plane identifiers used for topology based 641 forwarding and the identifiers used for the VTN-specific processing. 642 Thus a dedicated data plane VTN-ID could be introduced and 643 encapsulated in the packet. One possible encapsulation of VTN-ID in 644 IPv6 data plane is proposed in [I-D.dong-6man-enhanced-vpn-vtn-id]. 645 One possible encapsulation of VTN-ID in MPLS data plane is proposed 646 in [I-D.li-mpls-enhanced-vpn-vtn-id]. 648 In that case, the VTN ID encapsulated in data plane can be the same 649 value as the VTN ID in the control plane, so that the overhead of 650 advertising the mapping between the VTN IDs in the control plane and 651 the corresponding data plane identifiers could be saved. 653 6. Security Considerations 655 This document introduces no additional security vulnerabilities to 656 BGP-LS. 658 The mechanism proposed in this document is subject to the same 659 vulnerabilities as any other protocol that relies on BGP-LS. 661 7. IANA Considerations 663 TBD 665 8. Acknowledgments 667 The authors would like to thank Shunwan Zhuang and Zhenbin Li for the 668 review and discussion of this document. 670 9. References 672 9.1. Normative References 674 [I-D.ietf-idr-bgp-ls-flex-algo] 675 Talaulikar, K., Psenak, P., Zandi, S., and G. Dawra, 676 "Flexible Algorithm Definition Advertisement with BGP 677 Link-State", draft-ietf-idr-bgp-ls-flex-algo-05 (work in 678 progress), November 2020. 680 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 681 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 682 and M. Chen, "BGP Link-State extensions for Segment 683 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-16 684 (work in progress), June 2019. 686 [I-D.ietf-idr-bgpls-segment-routing-epe] 687 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 688 S., and J. Dong, "BGP-LS extensions for Segment Routing 689 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 690 segment-routing-epe-19 (work in progress), May 2019. 692 [I-D.ietf-idr-bgpls-srv6-ext] 693 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 694 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 695 State Extensions for SRv6", draft-ietf-idr-bgpls- 696 srv6-ext-05 (work in progress), November 2020. 698 [I-D.ietf-idr-rfc7752bis] 699 Talaulikar, K., "Distribution of Link-State and Traffic 700 Engineering Information Using BGP", draft-ietf-idr- 701 rfc7752bis-05 (work in progress), November 2020. 703 [I-D.ietf-spring-resource-aware-segments] 704 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 705 Z., and F. Clad, "Introducing Resource Awareness to SR 706 Segments", draft-ietf-spring-resource-aware-segments-01 707 (work in progress), January 2021. 709 [I-D.ietf-spring-sr-for-enhanced-vpn] 710 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 711 Z., and F. Clad, "Segment Routing based Virtual Transport 712 Network (VTN) for Enhanced VPN", February 2021, 713 . 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, 718 DOI 10.17487/RFC2119, March 1997, 719 . 721 [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link 722 Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, 723 September 2007, . 725 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 726 S. Ray, "North-Bound Distribution of Link-State and 727 Traffic Engineering (TE) Information Using BGP", RFC 7752, 728 DOI 10.17487/RFC7752, March 2016, 729 . 731 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 732 Decraene, B., Litkowski, S., and R. Shakir, "Segment 733 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 734 July 2018, . 736 9.2. Informative References 738 [I-D.dong-6man-enhanced-vpn-vtn-id] 739 Dong, J., Li, Z., Xie, C., and C. Ma, "Carrying Virtual 740 Transport Network Identifier in IPv6 Extension Header", 741 draft-dong-6man-enhanced-vpn-vtn-id-02 (work in progress), 742 November 2020. 744 [I-D.dong-lsr-sr-enhanced-vpn] 745 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 746 and S. Bryant, "IGP Extensions for Segment Routing based 747 Enhanced VPN", draft-dong-lsr-sr-enhanced-vpn-04 (work in 748 progress), June 2020. 750 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 751 Dong, J., Li, Z., Qin, F., and G. Yang, "Scalability 752 Considerations for Enhanced VPN (VPN+)", draft-dong-teas- 753 enhanced-vpn-vtn-scalability-01 (work in progress), 754 November 2020. 756 [I-D.ietf-lsr-flex-algo] 757 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 758 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 759 algo-13 (work in progress), October 2020. 761 [I-D.ietf-lsr-isis-srv6-extensions] 762 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 763 Z. Hu, "IS-IS Extension to Support Segment Routing over 764 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 765 (work in progress), October 2020. 767 [I-D.ietf-teas-enhanced-vpn] 768 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 769 Framework for Enhanced Virtual Private Networks (VPN+) 770 Service", draft-ietf-teas-enhanced-vpn-06 (work in 771 progress), July 2020. 773 [I-D.li-mpls-enhanced-vpn-vtn-id] 774 Li, Z. and J. Dong, "Carrying Virtual Transport Network 775 Identifier in MPLS Packet", February 2021, 776 . 779 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 780 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 781 RFC 4915, DOI 10.17487/RFC4915, June 2007, 782 . 784 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 785 Topology (MT) Routing in Intermediate System to 786 Intermediate Systems (IS-ISs)", RFC 5120, 787 DOI 10.17487/RFC5120, February 2008, 788 . 790 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 791 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 792 Extensions for Segment Routing", RFC 8667, 793 DOI 10.17487/RFC8667, December 2019, 794 . 796 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 797 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 798 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 799 December 2019, . 801 Authors' Addresses 803 Jie Dong 804 Huawei Technologies 806 Email: jie.dong@huawei.com 808 Zhibo Hu 809 Huawei Technologies 811 Email: huzhibo@huawei.com 813 Zhenbin Li 814 Huawei Technologies 816 Email: lizhenbin@huawei.com 818 Xiongyan Tang 819 China Unicom 821 Email: tangxy@chinaunicom.cn 823 Ran Pang 824 China Unicom 826 Email: pangran@chinaunicom.cn