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