idnits 2.17.1 draft-xie-lsr-isis-sr-vtn-mt-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 1152 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-11 == Outdated reference: A later version (-08) exists of draft-ietf-spring-resource-aware-segments-01 == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-04 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-06 Summary: 0 errors (**), 0 flaws (~~), 5 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: August 26, 2021 J. Dong 6 Z. Li 7 Huawei Technologies 8 February 22, 2021 10 Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual 11 Transport Network 12 draft-xie-lsr-isis-sr-vtn-mt-03 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 logicial 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 August 26, 2021. 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 . . . . . . . . . . . . . . . . . . . 5 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 virtual transport networks (VTNs) 109 with the required network topology and network resource attributes to 110 support enhanced VPN services. With segment routing based data 111 plane, Segment Identifiers (SIDs) can be used to represent both the 112 topology and the set of network resources allocated by network nodes 113 to a virtual network. The SIDs of each VTN and the associated 114 topology and resource attributes need to be distributed using control 115 plane. 117 [I-D.dong-lsr-sr-enhanced-vpn] defines the IGP mechanisms with 118 necessary extensions to build a set of Segment Routing (SR) based 119 VTNs. The VTNs could be used as the underlay of the enhanced VPN 120 service. The mechanism described in [I-D.dong-lsr-sr-enhanced-vpn] 121 allows flexible combination of the topology and resource attribute to 122 build customized VTNs. In some network scenarios, it is assumed that 123 each VTN can have an independent topology and a set of dedicated 124 network resources. This document describes a simplified mechanism to 125 build SR based VTNs in those scenarios. 127 The approach is to use IS-IS Multi-Topology [RFC5120] with segment 128 routing [RFC8667] to define the independent network topologies of 129 each VTN. The attribute of network resources allocated to a VTN can 130 be advertised by using IS-IS MT with the Traffic Engineering (TE) 131 extensions defined in [RFC5305] and [RFC8570]. 133 2. Advertisement of SR VTN Topology Attribute 135 IS-IS Multi-Topology Routing (MTR) [RFC5120] has been defined to 136 create independent topologies in one network. In [RFC5120], MT-based 137 TLVs are introduced to carry topology-specific link-state 138 information. The MT-specific Link or Prefix TLVs are defined by 139 adding additional two bytes, which includes 12-bit MT-ID field in 140 front of the ISN TLV and IP or IPv6 Reachability TLVs. This provides 141 the capability of specifying the customized attributes of each 142 topology. When each VTN is associated with an independent network 143 topology, MT-ID could be used as the identifier of VTN in control 144 plane. 146 MTR can be used with segment routing based data plane. Thus the 147 topology attribute of an SR based VTN could be advertised using MTR 148 with segment routing. The IS-IS extensions to support the 149 advertisement of topology-specific MPLS SIDs are specified in 150 [RFC8667]. Topology-specific Prefix-SIDs can be advertised by 151 carrying the Prefix-SID sub-TLVs in the IS-IS TLV 235 (MT IP 152 Reachability) and TLV 237 (MT IPv6 IP Reachability). Topology- 153 specific Adj-SIDs can be advertised by carrying the Adj-SID sub-TLVs 154 in IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). 156 The IS-IS extensions to support the advertisement of topology- 157 specific SRv6 Locators and SIDs are specified in 158 [I-D.ietf-lsr-isis-srv6-extensions]. The topology-specific SRv6 159 locators are advertised using SRv6 Locator TLV, and SRv6 End SIDs 160 inherit the MT-ID from the parent locator. The topology-specific 161 End.X SID are advertised by carrying SRv6 End.X SID sub-TLVs in the 162 IS-IS TLV 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute). 164 3. Advertisement of SR VTN Resource Attribute 166 In order to perform constraint based path computation for each VTN on 167 the network controller or on the ingress nodes, the network resource 168 and other attributes associated with each VTN need to be advertised. 170 3.1. Advertising Topology-specific TE attributes 172 On each network link, the information of the network resources and 173 other attributes associated with a VTN can be specified by carrying 174 the TE attributes sub-TLVs [RFC5305] and [RFC8570] in the IS-IS TLV 175 222 (MT-ISN) and TLV 223 (MT IS Neighbor Attribute) of the 176 corresponding topology. 178 When Maximum Link Bandwidth sub-TLV is carried in the MT-ISN TLV of a 179 topology, it indicates the amount of link bandwidth allocated to the 180 corresponding VTN. The bandwidth allocated to a VTN can be exclusive 181 for services carried in the corresponding VTN. The usage of other TE 182 attributes in topology-specific TLVs is for further study. 184 Editor's note1: It is noted that carrying per-topology TE attributes 185 was considered as a possible feature in future when the encoding of 186 IS-IS multi-topology was defined in [RFC5120]. 188 4. Forwarding Plane Operations 190 For SR-MPLS data plane, a Prefix-SID is associated with the paths 191 calculated in the corresponding topology of a VTN. An outgoing 192 interface is determined for each path. In addition, the prefix-SID 193 also steers the traffic to use the subset of network resources 194 allocated to the VTN on the outgoing interface for packet forwarding. 195 An Adj-SID is associated with a subset of network resources allocated 196 to a VTN on the link. The Adj-SIDs and Prefix-SIDs associated with 197 the same VTN can be used together to build SR-MPLS paths with the 198 topological and resource constraints of the VTN. 200 For SRv6 data plane, an SRv6 Locator is a prefix which is associated 201 with the paths calculated in the corresponding topology of a VTN. An 202 outgoing interface is determined for each path. In addition, the 203 SRv6 Locator prefix also steers the traffic to use the subset of 204 network resources which are allocated to the VTN on the outgoing 205 interface for packet forwarding. An End.X SID is associated with a 206 subset of network resources allocated to a VTN on the link. The 207 End.X SIDs and the SRv6 Locator prefixes associated with the same VTN 208 can be used together to build SRv6 paths with the topological and 209 resource constraints of the VTN. 211 5. Scalability Considerations 213 The mechanism described in this document assumes that each VTN is 214 associated with a unique topology, so that the MT-IDs can be reused 215 to identify the VTNs in the control plane. While this brings the 216 benefit of simplicity, it also has some limitations. For example, it 217 means that even if multiple VTNs have the same topology, they would 218 still need to be identified using different MT-IDs in the control 219 plane, then independent path computation needs to be executed for 220 each VTN. Thus the number of VTNs supported in a network may be 221 dependent on the number of topologies supported, which is related to 222 the control plane computation overhead. 224 6. Security Considerations 226 This document introduces no additional security vulnerabilities to 227 IS-IS. 229 The mechanism proposed in this document is subject to the same 230 vulnerabilities as any other protocol that relies on IGPs. 232 7. IANA Considerations 234 This document does not request any IANA actions. 236 8. Acknowledgments 238 The authors would like to thank Zhibo Hu, Dean Cheng, Les Ginsberg 239 and Peter Psenak for the review and discussion of this document. 241 9. References 243 9.1. Normative References 245 [I-D.ietf-lsr-isis-srv6-extensions] 246 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 247 Z. Hu, "IS-IS Extension to Support Segment Routing over 248 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 249 (work in progress), October 2020. 251 [I-D.ietf-spring-resource-aware-segments] 252 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 253 Z., and F. Clad, "Introducing Resource Awareness to SR 254 Segments", draft-ietf-spring-resource-aware-segments-01 255 (work in progress), January 2021. 257 [I-D.ietf-spring-sr-for-enhanced-vpn] 258 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 259 Z., and F. Clad, "Segment Routing based Virtual Transport 260 Network (VTN) for Enhanced VPN", February 2021, 261 . 264 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 265 Topology (MT) Routing in Intermediate System to 266 Intermediate Systems (IS-ISs)", RFC 5120, 267 DOI 10.17487/RFC5120, February 2008, 268 . 270 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 271 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 272 2008, . 274 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 275 Decraene, B., Litkowski, S., and R. Shakir, "Segment 276 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 277 July 2018, . 279 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 280 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 281 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 282 2019, . 284 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 285 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 286 Extensions for Segment Routing", RFC 8667, 287 DOI 10.17487/RFC8667, December 2019, 288 . 290 9.2. Informative References 292 [I-D.dong-lsr-sr-enhanced-vpn] 293 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 294 and S. Bryant, "IGP Extensions for Segment Routing based 295 Enhanced VPN", draft-dong-lsr-sr-enhanced-vpn-04 (work in 296 progress), June 2020. 298 [I-D.ietf-teas-enhanced-vpn] 299 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 300 Framework for Enhanced Virtual Private Networks (VPN+) 301 Service", draft-ietf-teas-enhanced-vpn-06 (work in 302 progress), July 2020. 304 Authors' Addresses 306 Chongfeng Xie 307 China Telecom 308 China Telecom Beijing Information Science & Technology, Beiqijia 309 Beijing 102209 310 China 312 Email: xiechf@chinatelecom.cn 314 Chenhao Ma 315 China Telecom 316 China Telecom Beijing Information Science & Technology, Beiqijia 317 Beijing 102209 318 China 320 Email: machh@chinatelecom.cn 321 Jie Dong 322 Huawei Technologies 323 Huawei Campus, No. 156 Beiqing Road 324 Beijing 100095 325 China 327 Email: jie.dong@huawei.com 329 Zhenbin Li 330 Huawei Technologies 331 Huawei Campus, No. 156 Beiqing Road 332 Beijing 100095 333 China 335 Email: lizhenbin@huawei.com