idnits 2.17.1 draft-zhu-lsr-isis-sr-vtn-flexalgo-04.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (7 March 2022) is 775 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) == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-18 == 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 ** Downref: Normative reference to an Informational draft: draft-ietf-spring-sr-for-enhanced-vpn (ref. 'I-D.ietf-spring-sr-for-enhanced-vpn') == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-09 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-10) exists of draft-dong-lsr-sr-enhanced-vpn-07 == Outdated reference: A later version (-02) exists of draft-dong-teas-nrp-scalability-01 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group Y. Zhu 3 Internet-Draft China Telecom 4 Intended status: Standards Track J. Dong 5 Expires: 8 September 2022 Z. Hu 6 Huawei Technologies 7 7 March 2022 9 Using Flex-Algo for Segment Routing based VTN 10 draft-zhu-lsr-isis-sr-vtn-flexalgo-04 12 Abstract 14 Enhanced VPN (VPN+) aims to provide enhanced VPN service to support 15 some application's needs of enhanced isolation and stringent 16 performance requirements. VPN+ requires integration between the 17 overlay VPN connectivity and the characteristics provided by the 18 underlay network. A Virtual Transport Network (VTN) is a virtual 19 underlay network which has a customized network topology and a set of 20 network resources allocated from the physical network. A VTN could 21 be used as the underlay for one or a group of VPN+ services. 23 The topological constraints of a VTN can be defined using Flex-Algo. 24 In some network scenarios, each VTN can be associated with a unique 25 Flex-Algo, and the set of network resources allocated to a VTN can be 26 instantiated as layer-2 sub-interfaces or member links of the layer-3 27 interfaces. This document describes the mechanisms to build the SR 28 based VTNs using SR Flex-Algo and IGP L2 bundle with minor 29 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 8 September 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Advertisement of SR VTN Topology Attributes . . . . . . . . . 3 67 3. Advertisement of SR VTN Resource Attributes . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . 7 75 9.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 set of network resources allocated 95 from the underlay network to meet the requirement of a specific VPN+ 96 service or a group of VPN+ services. Another possible approach is to 97 create a set of point-to-point paths, each with a set of network 98 resource reserved along the path, such paths are called Virtual 99 Transport Paths (VTPs). Although using a set of dedicated VTPs can 100 provide similar characteristics as VTN, it has some scalability 101 issues due to the per-path state in the network. 103 [I-D.ietf-spring-resource-aware-segments] introduces resource 104 awareness to Segment Routing (SR) [RFC8402]. As described in 105 [I-D.ietf-spring-sr-for-enhanced-vpn], the resource-aware SIDs can be 106 used to build VTNs with the required network topology and network 107 resource attributes to support VPN+ services. With segment routing 108 based data plane, Segment Identifiers (SIDs) can be used to represent 109 both the topology and the set of network resources allocated by 110 network nodes to a VTN. The SIDs of each VTN together with its 111 associated topology and resource attributes need to be distributed 112 using control plane. 114 [I-D.dong-lsr-sr-enhanced-vpn] defines the IGP mechanisms and 115 extensions to provide scalable Segment Routing (SR) based VTNs. The 116 mechanism in [I-D.dong-lsr-sr-enhanced-vpn] allows flexible 117 combination of the topology and resource attribute to provide a 118 relatively large number of VTNs. In some network scenarios, each VTN 119 can be associated with a unique Flex-Algo, and the set of network 120 resources allocated to the VTN can be instantiated using layer-2 sub- 121 interfaces or member links of the L3 interfaces. This document 122 describes a mechanism to build the SR based VTNs using SR Flex-Algo 123 and IGP L2 bundle with minor extensions. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 BCP14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 131 appear in all capitals, as shown here. 133 2. Advertisement of SR VTN Topology Attributes 135 [I-D.ietf-lsr-flex-algo] specifies the mechanism to provide 136 distributed constraint-path computation, and the usage of SR-MPLS 137 prefix-SIDs and SRv6 locators for steering traffic along the 138 constrained paths. 140 The Flex-Algo Definition (FAD) is the combination of calculation- 141 type, metric-type and the topological constraints used for path 142 computation. According to the network nodes' participation of a 143 Flex-Algo, and the rules of including or excluding Admin Groups (i.e. 144 colors) and Shared Risk Link Groups (SRLGs), the topology of a VTN 145 can be described using the associated Flex-Algo. If each VTN is 146 associated with a unique Flex-Algo, the Flex-Algo identifier could be 147 reused as the identifier of the VTN in the control plane. 149 With the mechanisms defined in[RFC8667] [I-D.ietf-lsr-flex-algo], SR- 150 MPLS prefix-SID advertisement can be associated with a specific 151 topology and a specific algorithm, which can be a Flex-Algo. This 152 allows the nodes to use the prefix-SIDs to steer traffic along 153 distributed computed constraint paths according to the associated 154 Flex-Algo in a particular topology. 156 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 157 support SRv6 data plane, in which the SRv6 locators advertisement is 158 associated with a topology and a specific algorithm, which can be a 159 Flex-Algo. This allows the nodes to use the SRv6 locators to steer 160 traffic along distributed computed constraint paths according to the 161 associated Flex-Algo in a particular topology. In addition, 162 topology/algorithm specific SRv6 End SIDs and End.X SIDs can be used 163 to enforce traffic over the Loop-Free Alternatives (LFA) computed 164 backup paths. 166 3. Advertisement of SR VTN Resource Attributes 168 Each VTN can be allocated with a set of dedicated network resources 169 on different network nodes and links. In order to perform constraint 170 based path computation for each VTN on network controller and the 171 ingress nodes, the resource attribute of each VTN also needs to be 172 advertised. This way, the network controller or the ingress node can 173 compute an SR TE path in a VTN by taking both the Flex-Algo 174 constraints and the resource attribute of the VTN into consideration. 176 IS-IS L2 Bundle [RFC8668] was defined to advertise the link 177 attributes of the layer-2 bundle member links. In this section, it 178 is extended to advertise the set of network resource attributes 179 associated with different VTNs on a layer-3 link. 181 The layer-3 link may or may not be a bundle of layer-2 links, as long 182 as it has the capability of partitioning the link resources into 183 different subsets for different VTNs it participates in. One 184 partition of the link resources can be instantiated as a layer-2 sub- 185 interface, which can be seen as a virtual layer-2 member link of the 186 layer-3 link. If the layer-3 link is a layer-2 link bundle, it is 187 possible that the set of link resource allocated to a specific VTN is 188 provided by one or multiple physical layer-2 member links. 190 A new flag "E" (Exclusive) is defined in the flag field of the Parent 191 L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV (25). 193 0 1 2 3 4 5 6 7 194 +-+-+-+-+-+-+-+-+ 195 |P|E| | 196 +-+-+-+-+-+-+-+-+ 198 E flag: When the E flag is set, it indicates each member link under 199 the Parent L3 link are used exclusively for one VTN, and load sharing 200 among the member links is not allowed. When the E flag is clear, it 201 indicates load balancing and sharing among the member links are 202 allowed. 204 For each virtual or physical layer-2 member link, the TE attributes 205 defined in [RFC5305] such as the Maximum Link Bandwidth and Admin 206 Groups SHOULD be advertised using the mechanism as defined in 207 [RFC8668]. The SR-MPLS Adj-SIDs or SRv6 End.X SIDs associated with 208 each of the virtual or physical Layer-2 member links SHOULD also be 209 advertised according to [RFC8668] and [I-D.dong-lsr-l2bundle-srv6]. 211 In order to correlate the virtual or physical layer-2 member links 212 with the Flex-Algo ID which is used to identify the VTN, each VTN 213 SHOULD be assigned with a unique Admin Group (AG) or Extended Admin 214 Group (EAG), and the virtual or physical layer-2 member links 215 associated with this VTN SHOULD be configured with the AG or EAG 216 assigned to the VTN. The AG or EAG of the parent layer-3 link SHOULD 217 be set to the union of all the AGs or EAGs of its virtual or physical 218 layer-2 member links. In the definition of the Flex-Algo 219 corresponding to the VTN, It MUST use the Include-Any Admin Group 220 rule with only the AG or EAG assigned to the VTN as the link 221 constraints, the Include-All Admin Goup rule or the Exclude Admin 222 Group rule MUST NOT be used. This is to ensure that the layer-3 link 223 is included in the Flex-Algo constraint based path computation for 224 each VTN it participates in. 226 4. Forwarding Plane Operations 228 For SR-MPLS data plane, a prefix SID is associated with the paths 229 calculated using the Flex-Algo corresponding to a VTN. An outgoing 230 layer-3 interface is determined for each path. In addition, the 231 prefix-SID also steers the traffic to use the virtual or physical 232 layer-2 member link which is associated with the VTN on the outgoing 233 layer-3 interface for packet forwarding. The Adj-SIDs associated 234 with the virtual or physical member links of a VTN MAY be used with 235 the prefix-SIDs of the same VTN together to build SR-MPLS TE paths 236 with the topological and resource constraints of the VTN. 238 For SRv6 data plane, an SRv6 Locator is a prefix which is associated 239 with the paths calculated using the Flex-Algo corresponding to a VTN. 240 An outgoing Layer-3 interface is determined for each path. In 241 addition, the SRv6 Locator prefix also steers the traffic to use the 242 virtual or physical layer-2 member link which is associated with the 243 VTN on the outgoing layer-3 interface for packet forwarding. The 244 End.XU SIDs associated with the virtual or physical member links of a 245 VTN MAY be used with the SRv6 Locator prefix of the same VTN together 246 to build SRv6 paths with the topological and resource constraints of 247 the VTN. 249 5. Scalability Considerations 251 The mechanism described in this document assumes that each VTN is 252 associated with a unique Flex-Algo, so that the Flex-Algo IDs can be 253 reused to identify the VTNs in the control plane. While this brings 254 the benefit of simplicity, it also has some limitations. For 255 example, it means that even if multiple VTNs share the same 256 topological constraints, they still need to be identified using 257 different Flex-Algo IDs in the control plane, then independent path 258 computation needs to be executed for each VTN. The number of VTNs 259 supported in a network may be dependent on the number of Flex-Algos 260 supported, which is related to the number of Flex-Algos defined in 261 the protocol (which is 128) and the control plane overhead on network 262 nodes. The mechanism described in this document is applicable to 263 network scenarios where the number of required VTN is relatively 264 small. A detailed analysis about the VTN scalability and the 265 possible optimizations for supporting a large number of VTNs is 266 described in [I-D.dong-teas-nrp-scalability]. 268 6. Security Considerations 270 This document introduces no additional security vulnerabilities to 271 IS-IS. 273 The mechanism proposed in this document is subject to the same 274 vulnerabilities as any other protocol that relies on IGPs. 276 7. IANA Considerations 278 This document does not request any IANA actions. 280 8. Acknowledgments 282 The authors would like to thank Zhenbin Li and Peter Psenak for the 283 review and discussion of this document. 285 9. References 286 9.1. Normative References 288 [I-D.dong-lsr-l2bundle-srv6] 289 Dong, J. and Z. Hu, "Advertising SRv6 SIDs for Layer 2 290 Bundle Member Links in IGP", Work in Progress, Internet- 291 Draft, draft-dong-lsr-l2bundle-srv6-01, 24 October 2021, 292 . 295 [I-D.ietf-lsr-flex-algo] 296 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 297 A. Gulko, "IGP Flexible Algorithm", Work in Progress, 298 Internet-Draft, draft-ietf-lsr-flex-algo-18, 25 October 299 2021, . 302 [I-D.ietf-lsr-isis-srv6-extensions] 303 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 304 Z. Hu, "IS-IS Extensions to Support Segment Routing over 305 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 306 ietf-lsr-isis-srv6-extensions-18, 20 October 2021, 307 . 310 [I-D.ietf-spring-resource-aware-segments] 311 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 312 Z., and F. Clad, "Introducing Resource Awareness to SR 313 Segments", Work in Progress, Internet-Draft, draft-ietf- 314 spring-resource-aware-segments-03, 12 July 2021, 315 . 318 [I-D.ietf-spring-sr-for-enhanced-vpn] 319 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 320 Z., and F. Clad, "Segment Routing based Virtual Transport 321 Network (VTN) for Enhanced VPN", Work in Progress, 322 Internet-Draft, draft-ietf-spring-sr-for-enhanced-vpn-01, 323 12 July 2021, . 326 [I-D.ietf-teas-enhanced-vpn] 327 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 328 Framework for Enhanced Virtual Private Network (VPN+) 329 Services", Work in Progress, Internet-Draft, draft-ietf- 330 teas-enhanced-vpn-09, 25 October 2021, 331 . 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 340 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 341 2008, . 343 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 344 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 345 May 2017, . 347 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 348 Decraene, B., Litkowski, S., and R. Shakir, "Segment 349 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 350 July 2018, . 352 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 353 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 354 Extensions for Segment Routing", RFC 8667, 355 DOI 10.17487/RFC8667, December 2019, 356 . 358 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 359 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 360 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 361 December 2019, . 363 9.2. Informative References 365 [I-D.dong-lsr-sr-enhanced-vpn] 366 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 367 and S. Bryant, "IGP Extensions for Scalable Segment 368 Routing based Enhanced VPN", Work in Progress, Internet- 369 Draft, draft-dong-lsr-sr-enhanced-vpn-07, 29 January 2022, 370 . 373 [I-D.dong-teas-nrp-scalability] 374 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 375 Mishra, G., Qin, F., Saad, T., and V. P. Beeram, 376 "Scalability Considerations for Network Resource 377 Partition", Work in Progress, Internet-Draft, draft-dong- 378 teas-nrp-scalability-01, 7 February 2022, 379 . 382 Authors' Addresses 384 Yongqing Zhu 385 China Telecom 386 Email: zhuyq8@chinatelecom.cn 388 Jie Dong 389 Huawei Technologies 390 Email: jie.dong@huawei.com 392 Zhibo Hu 393 Huawei Technologies 394 Email: huzhibo@huawei.com