idnits 2.17.1 draft-ietf-idr-bgpls-sr-vtn-mt-14.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 document date (16 October 2025) is 44 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-spring-resource-aware-segments-15 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group C. Xie 3 Internet-Draft C. Li 4 Intended status: Informational China Telecom 5 Expires: 19 April 2026 J. Dong 6 Z. Li 7 Huawei Technologies 8 16 October 2025 10 Applicability of Border Gateway Protocol - Link State (BGP-LS) with 11 Multi-Topology (MT) for Segment Routing based Network Resource 12 Partitions (NRPs) 13 draft-ietf-idr-bgpls-sr-vtn-mt-14 15 Abstract 17 When Segment Routing (SR) is used for building Network Resource 18 Partitions (NRPs), each NRP can be allocated with a group of Segment 19 Identifiers (SIDs) to identify the topology and resource attributes 20 of network segments in the NRP. This document describes how BGP-Link 21 State (BGP-LS) with Multi-Topology (MT) can be used to distribute the 22 information of SR-based NRPs to a network controller in a specific 23 context where each NRP is associated with a separate logical topology 24 identified by a Multi-Topology ID (MT-ID). This document sets out 25 the targeted scenarios for the approach suggested, and presents the 26 scalability limitations that arise. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 19 April 2026. 45 Copyright Notice 47 Copyright (c) 2025 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Advertisement of Topology Information . . . . . . . . . . . . 4 63 2.1. Intra-domain Topology Advertisement . . . . . . . . . . . 4 64 2.2. Inter-Domain Topology Advertisement . . . . . . . . . . . 4 65 3. Advertisement of Resource related TE Attribute . . . . . . . 6 66 4. Scalability Considerations . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 [RFC9543] discusses the general framework, components, and interfaces 78 for requesting and operating network slices using IETF technologies. 79 [RFC9543] also introduces the concept of the Network Resource 80 Partition (NRP), which is defined as a subset of the buffer/queuing/ 81 scheduling resources and associated policies on each of a connected 82 set of links in an underlay network. An NRP can be associated with a 83 logical network topology to select or specify the set of links and 84 nodes involved. [RFC9732] specifies a framework of NRP-based 85 enhanced VPNs and describes the candidate component technologies in 86 different network planes and network layers. An NRP could be used as 87 the underlay to meet the requirements of one or a group of network 88 slices or enhanced VPN services. The mechanism of enforcing NRP 89 resource allocation and the mechanism of mapping one or group of 90 enhanced VPN services to a specific NRP are outside the scope of this 91 document. Similarly, classification and means to bind packets to 92 NRPs are out of scope this document. 94 [I-D.ietf-spring-resource-aware-segments] introduces resource 95 awareness to Segment Routing (SR) [RFC8402]. As described in 96 [I-D.ietf-spring-sr-for-enhanced-vpn], a group of resource-aware SIDs 97 can be used to build SR-based NRPs with the required network topology 98 and network resource attributes. The group of resource-aware SR SIDs 99 together with the associated topology and resource attributes of an 100 NRP need to be distributed in the network using IGPs. BGP-Link State 101 (BGP-LS) [RFC9552] can then be used to advertise the SR SIDs and the 102 resource related Traffic Engineering (TE) attributes (e.g., link 103 bandwidth) of NRPs in each IGP area or AS to a network controller. 105 As specified in [RFC9543], some NRP realizations may build NRPs with 106 dedicated topologies, while other realizations may use a shared 107 topology for multiple NRPs. The exact NRPs characterization, the 108 number of NRPs, and their binding to a topology are deployment- 109 specific. 111 In some network scenarios, the required number of NRPs may be small, 112 each NRP can be associated with a separate logical topology, i.e., 113 there is 1:1 mapping between an NRP and a Multi-Topology (MT) ID, and 114 the set of dedicated or shared network resources of the NRP can be 115 considered to be associated with the logical topology. 116 [I-D.ietf-lsr-isis-sr-vtn-mt] describes how IS-IS Multi-Topology (MT) 117 [RFC5120] can be used to advertise an independent topology and the 118 associated SR SIDs, together with the topology-specific resource 119 related TE attributes in the network. 121 In some network scenarios, for instance, an operator's network 122 consists of multiple network parts, such as metro area networks, 123 backbone networks, or data center networks, each part being a 124 different AS. NRPs can be enabled independently in each network 125 part. Specifically, it is not required to enable multiple NRPs in 126 all network parts, and the number of NRPs is local to each domain. 127 However, there might be a need to stitch NRPs that span multiple 128 ASes, typically under the same network administration. NRP stitching 129 is likely to require classification, (re)marking, admission control, 130 etc. at ingress nodes of network domains. These considerations are 131 out of scope of this document. 133 This document describes how BGP-LS with MT can be used distribute 134 information of the logical topology, the associated SIDs, and the 135 topology-specific resource information to a network controller for 136 intra-domain and inter-domain SR-based NRPs. The limitations and the 137 targeted scenario of this approach are described in "Scalability 138 Considerations" (Section 4). 140 2. Advertisement of Topology Information 142 This section describes the corresponding BGP-LS mechanism to 143 distribute both the intra-domain and inter-domain topology 144 information and the associated SR SIDs. For the inter-domain case, 145 the involved network domains should be under a common administration, 146 or they belong to the same trusted domain as specified in Section 8 147 of [RFC8402]. 149 2.1. Intra-domain Topology Advertisement 151 Section 5.2.2.1 of [RFC9552] defines the Multi-Topology Identifier 152 (MT-ID) TLV, which can contain one or more Multi-Topology Identifiers 153 for a link, node, or prefix. The MT-ID TLV may be included as a Link 154 Descriptor, as a Prefix Descriptor, or in the BGP-LS Attribute of a 155 Node Network Layer Reachability Information (NLRI). The detailed 156 rules of the usage of MT-ID TLV in BGP-LS is also specified in 157 Section 5.2.2.1 of [RFC9552]. 159 When Multi-Topology is used with the SR-MPLS data plane [RFC8660], 160 topology-specific Prefix-SIDs and topology-specific Adjacency Segment 161 Identifiers (Adj-SIDs) can be carried in the BGP-LS Attribute 162 associated with the Prefix NLRI and Link NLRI respectively (Section 2 163 of [RFC9085]), the MT-ID TLV carried in the Prefix Descriptor or Link 164 Descriptor [RFC9552] can be used to identify the corresponding 165 topology of the SIDs. 167 When Multi-Topology is used with the SRv6 data plane [RFC8754], the 168 SRv6 Locator TLV is carried in the BGP-LS Attribute associated with 169 the Prefix NLRI, the MT-ID TLV can be carried as a Prefix Descriptor 170 to identify the corresponding topology of the SRv6 Locator (Section 6 171 of [RFC9514]). The SRv6 End.X SIDs are carried in the BGP-LS 172 Attribute associated with the Link NLRI, the MT-ID TLV can be carried 173 in the Link Descriptor to identify the corresponding topology of the 174 End.X SIDs. The SRv6 SID NLRI is defined to advertise other types of 175 SRv6 SIDs, in which the SRv6 SID descriptors can include the MT-ID 176 TLV so as to advertise topology-specific SRv6 SIDs. 178 2.2. Inter-Domain Topology Advertisement 180 [RFC9086] defines the BGP-LS extensions for BGP EPE with SR-MPLS. 181 The BGP-LS extensions for Egress Peer Engineering with SRv6 are 182 specified in [RFC9514]. These extensions could be used by a network 183 controller for the collection of inter-domain topology and SR SID 184 information, which can be used for the computation and instantiation 185 of inter-AS SR-TE paths. 187 For the case of inter-domain, the inter-domain connectivity and the 188 BGP peering SR SIDs associated with each logical topology on the 189 inter-domain links need to be advertised. This section describes the 190 applicability of multi-topology for the advertisement of inter-domain 191 topology and the associated SR SIDs using BGP-LS. It does not 192 introduce multi-topology into the operation of BGP sessions on the 193 inter-domain links. 195 In this document, consistent allocation of MT-ID means that the same 196 MT-ID is used in multiple domains for the concatenation of an inter- 197 domain logical topology. When a MT-ID is consistantly allocated in 198 multiple domains, the MT-ID can be carried in the link NLRI of the 199 inter-domain links for the advertisement of inter-domain logical 200 topology and the topology-specific BGP peering SIDs. This can be 201 achieved with the combination of existing mechanisms as defined in 202 [RFC9552][RFC9086] and [RFC9514]. 204 Depending on the different inter-domain scenarios, the approaches for 205 the inter-domain topology advertisement can be one or multiple of the 206 following: 208 * One External BGP (EBGP) session between two ASes can be 209 established over multiple underlying links. In this case, 210 different underlying links may be assigned to different inter- 211 domain logical topologies. In another similar case, the EBGP 212 session is established over a single physical link, while the 213 network resource (e.g., bandwidth) on this link is partitioned, 214 each of which is instantiated as a logical sub-interface, and each 215 logical link can be associated with a separate logical topology. 216 Different BGP Peer-Adj-SIDs or SRv6 End.X SIDs need to be 217 allocated and provisioned to each underlying physical or logical 218 link. The association between the underlying physical or logical 219 links and the corresponding MT-ID, together with the BGP Peer-Adj- 220 SIDs or SRv6 End.X SID need to be advertised by the ASBR to a 221 network controller. 223 * For inter-domain connection(s) between two ASes, multiple EBGP 224 sessions can be established between different sets of peering 225 ASBRs: It is possible that some of these BGP peers are only used 226 for one inter-domain logical topology, while some other BGP peers 227 are used for another inter-domain logical topology. In this case, 228 different BGP Peer Node SIDs can be allocated and provisioned to 229 steer traffic to a specific peer within an inter-domain logical 230 topology. The association between the link of the BGP peering 231 session and the corresponding MT-ID, together with the BGP Peer 232 Node SIDs need to be advertised by the ASBR to a network 233 controller. 235 * At the level inter-AS topology, different inter-domain logical 236 topologies may have different inter-AS connectivity. Different 237 BGP Peer Set SIDs may be allocated and provisioned to represent a 238 group of BGP peers which can be used for load-balancing within 239 each inter-domain logical topology. The BGP Peer Set SIDs may be 240 advertised in the BGP-LS attributes of the link NLRI which carries 241 the corresponding MT-ID. 243 In network scenarios where consistent allocation of MT-ID among 244 multiple domains for an inter-domain logical topology can not be 245 achieved, the MT-IDs advertised by the two peering ASBRs to a network 246 controller for the same inter-domain link in a logical topology could 247 be different. The ASBRs just need to distribute the inter-domain 248 link information with MT-ID to the controllers, it is the 249 controller's job to provide some mapping mechanism to match the 250 different MT-IDs of an inter-domain link in two directions (e.g., for 251 one inter-domain link, MT-ID A in domain X will be matched with MT-ID 252 B in domain Y), and concatenate the inter-domain logical topology. 253 The detailed mechanism is out of the scope of this document. 255 3. Advertisement of Resource related TE Attribute 257 The information of the network resources attributes of a link 258 associated with a specific topology can be specified by carrying the 259 corresponding TE Link attribute TLVs in BGP-LS Attribute [RFC9552], 260 with the associated MT-ID carried in the corresponding Link NLRI. 262 For example, a subset of the bandwidth resource on a link for a 263 specific logical topology can be advertised by carrying the Maximum 264 Link Bandwidth sub-TLV in the BGP-LS Attribute associated with the 265 Link NLRI which carries the corresponding MT-ID. The bandwidth 266 advertised can be exclusive for this logical topology. The 267 advertisement of other topology-specific TE attributes in BGP-LS is 268 for further study. The receiving BGP-LS speaker should be prepared 269 to receive any TE attributes in BGP-LS Attribute with the associated 270 MT-ID carried in the corresponding Link NLRI. 272 4. Scalability Considerations 274 This document assumes that each NRP is associated with an independent 275 logical topology, and for the inter-domain NRPs, the MT-IDs used in 276 the involved domains are consistent, or some mapping mechanism is 277 used, so that the associated MT-ID can be used to identify the NRP in 278 the control plane. Using MT-ID to identify NRP allows to reuse the 279 multi-topology related control plane mechanisms for the distribution 280 of NRP topology and resource information, while this 1:1 mapping 281 between NRP and MT-ID also has some limitations. For example, even 282 if multiple NRPs share the same topology, each NRP still need to be 283 identified using a unique MT-ID in the control plane. Therefore 284 independent path computation needs be executed for each NRP. The 285 number of NRPs supported in a network may be dependent on the number 286 of topologies supported, which is related to both the number of 287 topologies supported in the protocol and the control plane overhead 288 which the network could afford. Since no new control protocol 289 extension is required, the mechanism described in this document is 290 considered useful for network scenarios in which the required number 291 of NRPs is small (e.g., less than 10). For network scenarios where 292 the number of required NRPs is large, more scalable solutions would 293 be needed which may require further protocol extensions and 294 enhancements. 296 5. Security Considerations 298 The security considerations in [RFC9552] [RFC9085] and [RFC9514] 299 apply to this document. 301 This document introduces no additional security vulnerabilities to 302 BGP-LS. The mechanism proposed in this document is subject to the 303 same vulnerabilities as any other protocol that relies on BGP-LS. 305 6. IANA Considerations 307 This document does not request any IANA actions. 309 7. Acknowledgments 311 The authors would like to thank Shunwan Zhuang, Adrian Farrel, Susan 312 Hares, Jeffrey Haas, Ketan Talaulikar and Mohamed Boucadair for the 313 review and discussion of this document. 315 8. References 317 8.1. Normative References 319 [I-D.ietf-lsr-isis-sr-vtn-mt] 320 Xie, C., Ma, C., Dong, J., and Z. Li, "Applicability of 321 IS-IS Multi-Topology (MT) for Segment Routing based 322 Network Resource Partition (NRP)", Work in Progress, 323 Internet-Draft, draft-ietf-lsr-isis-sr-vtn-mt-11, 13 324 October 2025, . 327 [I-D.ietf-spring-resource-aware-segments] 328 Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li, 329 "Introducing Resource Awareness to SR Segments", Work in 330 Progress, Internet-Draft, draft-ietf-spring-resource- 331 aware-segments-15, 3 September 2025, 332 . 335 [I-D.ietf-spring-sr-for-enhanced-vpn] 336 Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li, 337 "Segment Routing based Network Resource Partition (NRP) 338 for Enhanced VPN", Work in Progress, Internet-Draft, 339 draft-ietf-spring-sr-for-enhanced-vpn-09, 10 June 2025, 340 . 343 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 344 Topology (MT) Routing in Intermediate System to 345 Intermediate Systems (IS-ISs)", RFC 5120, 346 DOI 10.17487/RFC5120, February 2008, 347 . 349 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 350 Decraene, B., Litkowski, S., and R. Shakir, "Segment 351 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 352 July 2018, . 354 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 355 Decraene, B., Litkowski, S., and R. Shakir, "Segment 356 Routing with the MPLS Data Plane", RFC 8660, 357 DOI 10.17487/RFC8660, December 2019, 358 . 360 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 361 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 362 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 363 . 365 [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, 366 H., and M. Chen, "Border Gateway Protocol - Link State 367 (BGP-LS) Extensions for Segment Routing", RFC 9085, 368 DOI 10.17487/RFC9085, August 2021, 369 . 371 [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., 372 Ray, S., and J. Dong, "Border Gateway Protocol - Link 373 State (BGP-LS) Extensions for Segment Routing BGP Egress 374 Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 375 2021, . 377 [RFC9514] Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M., 378 Bernier, D., and B. Decraene, "Border Gateway Protocol - 379 Link State (BGP-LS) Extensions for Segment Routing over 380 IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December 381 2023, . 383 [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., 384 Makhijani, K., Contreras, L., and J. Tantsura, "A 385 Framework for Network Slices in Networks Built from IETF 386 Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, 387 . 389 [RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and 390 Traffic Engineering Information Using BGP", RFC 9552, 391 DOI 10.17487/RFC9552, December 2023, 392 . 394 8.2. Informative References 396 [RFC9732] Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 397 Framework for NRP-Based Enhanced Virtual Private 398 Networks", RFC 9732, DOI 10.17487/RFC9732, March 2025, 399 . 401 Authors' Addresses 403 Chongfeng Xie 404 China Telecom 405 China Telecom Beijing Information Science & Technology, Beiqijia 406 Beijing 407 102209 408 China 409 Email: xiechf@chinatelecom.cn 411 Cong Li 412 China Telecom 413 China Telecom Beijing Information Science & Technology, Beiqijia 414 Beijing 415 102209 416 China 417 Email: licong@chinatelecom.cn 418 Jie Dong 419 Huawei Technologies 420 Huawei Campus, No. 156 Beiqing Road 421 Beijing 422 100095 423 China 424 Email: jie.dong@huawei.com 426 Zhenbin Li 427 Huawei Technologies 428 Huawei Campus, No. 156 Beiqing Road 429 Beijing 430 100095 431 China 432 Email: lizhenbin@huawei.com