idnits 2.17.1 draft-ietf-lsr-isis-sr-vtn-mt-02.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 (13 January 2022) is 834 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-03 == Outdated reference: A later version (-07) exists of draft-ietf-spring-sr-for-enhanced-vpn-01 == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-06 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-09 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group C. Xie 3 Internet-Draft C. Ma 4 Intended status: Informational China Telecom 5 Expires: 17 July 2022 J. Dong 6 Z. Li 7 Huawei Technologies 8 13 January 2022 10 Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual 11 Transport Network 12 draft-ietf-lsr-isis-sr-vtn-mt-02 14 Abstract 16 Enhanced VPN (VPN+) aims to provide enhanced VPN service to support 17 some application's 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 subset of network resources 22 allocated on network nodes and links in a customized topology of the 23 physical network. A VTN could be used as the underlay to support one 24 or a group of VPN+ services. 26 In some network scenarios, each VTN can be associated with a unique 27 logical network topology. This document describes a mechanism to 28 build the SR based VTNs using IS-IS Multi-Topology together with 29 other well-defined IS-IS extensions. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 17 July 2022. 48 Copyright Notice 50 Copyright (c) 2022 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Advertisement of SR VTN Topology Attribute . . . . . . . . . 4 66 3. Advertisement of SR VTN Resource Attribute . . . . . . . . . 4 67 3.1. Advertising Topology-specific TE attributes . . . . . . . 5 68 4. Forwarding Plane Operations . . . . . . . . . . . . . . . . . 5 69 5. Scalability Considerations . . . . . . . . . . . . . . . . . 6 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 9.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Enhanced VPN (VPN+) is an enhancement to VPN services to support the 81 needs of new applications, particularly the applications that are 82 associated with 5G services. These applications require enhanced 83 isolation and have more stringent performance requirements than that 84 can be provided with traditional overlay VPNs. Thus these properties 85 require integration between the underlay and the overlay networks. 86 [I-D.ietf-teas-enhanced-vpn] specifies the framework of enhanced VPN 87 and describes the candidate component technologies in different 88 network planes and layers. VPN+ can be used to underpin network 89 slicing, but could also be of use in its own right providing enhanced 90 connectivity services between customer sites. 92 To meet the requirement of VPN+ services, a number of virtual 93 transport networks (VTN) can be created, each with a subset of 94 network resources allocated on network nodes and links in a 95 customized topology of the physical network. A VTN could be used as 96 the underlay to meet the requirement of one or a group of VPN+ 97 services. Another possible approach is to create a set of point-to- 98 point paths, each with a set of network resource reserved along the 99 path, such paths are called Virtual Transport Path (VTP). Although 100 using a set of dedicated VTPs can provide similar characteristics as 101 a VTN, it has some scalability issues due to the per-path state in 102 the network. 104 [I-D.ietf-spring-resource-aware-segments] introduces resource 105 awareness to Segment Routing (SR) [RFC8402]. The resource-aware SIDs 106 have additional semantics to identify the set of network resources 107 available for the packet processing action associated with the SIDs. 108 As described in [I-D.ietf-spring-sr-for-enhanced-vpn], the resource- 109 aware SIDs can be used to build SR based VTNs with the required 110 network topology and network resource attributes to support VPN+ 111 services. With segment routing based data plane, Segment Identifiers 112 (SIDs) can be used to represent both the topological instructions and 113 the set of network resources allocated by network nodes to a VTN. 114 The SR SIDs and the associated topology and resource attributes of a 115 VTN need to be distributed using control plane. 117 [I-D.dong-lsr-sr-enhanced-vpn] defines the IGP mechanisms with 118 necessary extensions to provide scalable Segment Routing (SR) based 119 VTNs. The VTNs could be used as the underlay of the VPN+ service. 120 The mechanism described in [I-D.dong-lsr-sr-enhanced-vpn] allows 121 flexible combination of the topology and resource attribute to build 122 a relatively large number of VTNs. In some network scenarios, it is 123 assumed that each VTN is associated with an independent topology and 124 has a set of dedicated or shared network resources. This document 125 describes a simplified mechanism to build SR based VTNs in those 126 scenarios. The resource-aware segments can be used with this 127 approach to provide resource guaranteed SR VTNs, while the normal SR 128 segments may also be used to provide SR VTNs with shared network 129 resources in the forwarding plane. 131 The proposed approach is to use IS-IS Multi-Topology [RFC5120] with 132 segment routing [RFC8667] to define the independent network topology 133 of each VTN. The attribute of network resources allocated to a VTN 134 can be advertised using IS-IS MT with the Traffic Engineering (TE) 135 extensions defined in [RFC5305] and [RFC8570]. 137 2. Advertisement of SR VTN Topology Attribute 139 IS-IS Multi-Topology Routing (MTR) [RFC5120] has been defined to 140 create independent topologies in one network. In [RFC5120], MT-based 141 TLVs are introduced to carry topology-specific link-state 142 information. The MT-specific Link or Prefix TLVs are defined by 143 adding additional two bytes, which includes 12-bit MT-ID field in 144 front of the ISN TLV and IP or IPv6 Reachability TLVs. This provides 145 the capability of specifying the customized attributes of each 146 topology. When each VTN is associated with an independent network 147 topology, MT-ID could be used as the identifier of VTN in control 148 plane. 150 MTR can be used with segment routing based data plane. Thus the 151 topology attribute of an SR based VTN could be advertised using MTR 152 with segment routing. The IS-IS extensions to support the 153 advertisement of topology-specific MPLS SIDs are specified in 154 [RFC8667]. Topology-specific Prefix-SIDs can be advertised by 155 carrying the Prefix-SID sub-TLVs in the IS-IS TLV 235 (MT IP 156 Reachability) and TLV 237 (MT IPv6 IP Reachability). Topology- 157 specific Adj-SIDs can be advertised by carrying the Adj-SID sub-TLVs 158 in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). 159 The topology-specific Prefix-SIDs and Adj-SIDs can be resource-aware 160 segments or normal SR segments. 162 The IS-IS extensions to support the advertisement of topology- 163 specific SRv6 Locators and SIDs are specified in 164 [I-D.ietf-lsr-isis-srv6-extensions]. The topology-specific SRv6 165 locators are advertised using SRv6 Locator TLV, and SRv6 End SIDs 166 inherit the MT-ID from the parent locator. The topology-specific 167 End.X SID are advertised by carrying SRv6 End.X SID sub-TLVs in the 168 IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). The 169 topology-specific SRv6 locators can be resource-aware locator or 170 normal SRv6 locator, and accordingly the topology-specific SRv6 SIDs 171 can be resource-aware SRv6 segments or normal SRv6 segments. 173 3. Advertisement of SR VTN Resource Attribute 175 In order to perform constraint based path computation for each VTN on 176 the network controller or on the ingress nodes, the network resource 177 attributes and other attributes associated with each VTN need to be 178 advertised. 180 3.1. Advertising Topology-specific TE attributes 182 On each network link, the information of the network resources and 183 other attributes associated with a VTN can be specified by carrying 184 the TE attributes sub-TLVs [RFC5305] and [RFC8570] in the IS-IS TLV 185 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute) of the 186 corresponding topology. 188 When Maximum Link Bandwidth sub-TLV is carried in the MT-ISN TLV of a 189 topology, it indicates the amount of link bandwidth allocated to the 190 corresponding VTN. The bandwidth allocated to a VTN can be exclusive 191 for services carried in the corresponding VTN. The usage of other TE 192 attributes in topology-specific TLVs is for further study. 194 Editor's note1: It is noted that carrying per-topology TE attributes 195 was considered as a possible feature in future when the encoding of 196 IS-IS multi-topology was defined in [RFC5120]. 198 4. Forwarding Plane Operations 200 For SR-MPLS data plane, the Adj-SIDs and Prefix-SIDs associated with 201 the same VTN can be used together to build SR-MPLS paths with the 202 topological and resource constraints of the VTN taken into 203 consideration. A Prefix-SID is associated with the paths calculated 204 in the corresponding topology of a VTN. An outgoing interface is 205 determined for each path. In addition, the resource-aware prefix-SID 206 can steer the traffic to use the subset of network resources 207 allocated to the VTN on the outgoing interface for packet forwarding. 208 Similarly, the resource-aware Adj-SID is associated with a subset of 209 network resources allocated to a VTN on the link it identifies. 211 For SRv6 data plane, the End.X SIDs and the SRv6 Locator prefixes 212 associated with the same VTN can be used together to build SRv6 paths 213 with the topological and resource constraints of the VTN taken into 214 consideration. An SRv6 Locator is a prefix which is associated with 215 the paths calculated in the corresponding topology of a VTN. An 216 outgoing interface is determined for each path. In addition, the 217 resource-aware SRv6 Locator prefix also steers the traffic to use the 218 subset of network resources which are allocated to the VTN on the 219 outgoing interface for packet forwarding. Similarly, an End.X SID is 220 associated with a subset of network resources allocated to a VTN on 221 the link it identifies. 223 5. Scalability Considerations 225 The mechanism described in this document assumes that each VTN is 226 associated with a unique topology, so that the MT-IDs can be reused 227 to identify the VTNs in the control plane. While this brings the 228 benefit of simplicity, it also has some limitations. For example, it 229 means that even if multiple VTNs have the same topology, they would 230 still need to be identified using different MT-IDs in the control 231 plane, then independent path computation needs to be executed for 232 each VTN. Thus the number of VTNs supported in a network may be 233 dependent on the number of topologies supported, which is related to 234 the number of topologies supported in the protocol and the control 235 plane overhead on network nodes. The mechanism described in this 236 document is applicable to network scenarios where the number of 237 required VTN is relatively small. A detailed analysis about the VTN 238 scalability and the possible optimizations for supporting a large 239 number of VTNs is described in 240 [I-D.dong-teas-enhanced-vpn-vtn-scalability]. 242 6. Security Considerations 244 This document introduces no additional security vulnerabilities to 245 IS-IS. 247 The mechanism proposed in this document is subject to the same 248 vulnerabilities as any other protocol that relies on IGPs. 250 7. IANA Considerations 252 This document does not request any IANA actions. 254 8. Acknowledgments 256 The authors would like to thank Zhibo Hu, Dean Cheng, Les Ginsberg 257 and Peter Psenak for the review and discussion of this document. 259 9. References 261 9.1. Normative References 263 [I-D.ietf-lsr-isis-srv6-extensions] 264 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 265 Z. Hu, "IS-IS Extensions to Support Segment Routing over 266 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 267 ietf-lsr-isis-srv6-extensions-18, 20 October 2021, 268 . 271 [I-D.ietf-spring-resource-aware-segments] 272 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 273 Z., and F. Clad, "Introducing Resource Awareness to SR 274 Segments", Work in Progress, Internet-Draft, draft-ietf- 275 spring-resource-aware-segments-03, 12 July 2021, 276 . 279 [I-D.ietf-spring-sr-for-enhanced-vpn] 280 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 281 Z., and F. Clad, "Segment Routing based Virtual Transport 282 Network (VTN) for Enhanced VPN", Work in Progress, 283 Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-01, 284 12 July 2021, . 287 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 288 Topology (MT) Routing in Intermediate System to 289 Intermediate Systems (IS-ISs)", RFC 5120, 290 DOI 10.17487/RFC5120, February 2008, 291 . 293 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 294 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 295 2008, . 297 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 298 Decraene, B., Litkowski, S., and R. Shakir, "Segment 299 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 300 July 2018, . 302 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 303 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 304 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 305 2019, . 307 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 308 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 309 Extensions for Segment Routing", RFC 8667, 310 DOI 10.17487/RFC8667, December 2019, 311 . 313 9.2. Informative References 315 [I-D.dong-lsr-sr-enhanced-vpn] 316 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 317 and S. Bryant, "IGP Extensions for Scalable Segment 318 Routing based Enhanced VPN", Work in Progress, Internet- 319 Draft, draft-dong-lsr-sr-enhanced-vpn-06, 11 July 2021, 320 . 323 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 324 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 325 Mishra, G., and F. Qin, "Scalability Considerations for 326 Enhanced VPN (VPN+)", Work in Progress, Internet-Draft, 327 draft-dong-teas-enhanced-vpn-vtn-scalability-04, 25 328 October 2021, . 331 [I-D.ietf-teas-enhanced-vpn] 332 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 333 Framework for Enhanced Virtual Private Network (VPN+) 334 Services", Work in Progress, Internet-Draft, draft-ietf- 335 teas-enhanced-vpn-09, 25 October 2021, 336 . 339 Authors' Addresses 341 Chongfeng Xie 342 China Telecom 343 China Telecom Beijing Information Science & Technology, Beiqijia 344 Beijing 345 102209 346 China 348 Email: xiechf@chinatelecom.cn 350 Chenhao Ma 351 China Telecom 352 China Telecom Beijing Information Science & Technology, Beiqijia 353 Beijing 354 102209 355 China 357 Email: machh@chinatelecom.cn 358 Jie Dong 359 Huawei Technologies 360 Huawei Campus, No. 156 Beiqing Road 361 Beijing 362 100095 363 China 365 Email: jie.dong@huawei.com 367 Zhenbin Li 368 Huawei Technologies 369 Huawei Campus, No. 156 Beiqing Road 370 Beijing 371 100095 372 China 374 Email: lizhenbin@huawei.com