idnits 2.17.1 draft-zhu-lsr-isis-sr-vtn-flexalgo-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 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 (July 12, 2021) is 1018 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 (-01) exists of draft-dong-lsr-l2bundle-srv6-00 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-15 == 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 ** 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 (-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: 1 error (**), 0 flaws (~~), 10 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: January 13, 2022 Z. Hu 6 Huawei Technologies 7 July 12, 2021 9 Using Flex-Algo for Segment Routing based VTN 10 draft-zhu-lsr-isis-sr-vtn-flexalgo-03 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 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 topology of a VTN can be defined using Flex-Algo. In some 24 network scenarios, each VTN can be associated with a unique Flex- 25 Algo, and the set of network resources of the VTN can be instantiated 26 as sub-interfaces or member links of the L3 interfaces. This 27 document describes the mechanisms to build the SR based VTNs using SR 28 Flex-Algo and IGP L2 bundle with minor 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Advertisement of SR VTN Topology Attribute . . . . . . . . . 3 67 3. Advertisement of SR VTN Resource Attribute . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 9.2. Informative References . . . . . . . . . . . . . . . . . 8 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 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 virtual transport networks (VTNs) with the required 107 network topology and network resource attributes to support enhanced 108 VPN services. With segment routing based data plane, Segment 109 Identifiers (SIDs) can be used to represent both the topology and the 110 set of network resources allocated by network nodes to a VTN. The 111 SIDs of each VTN and the associated topology and resource attributes 112 need to be distributed using control plane. 114 [I-D.dong-lsr-sr-enhanced-vpn] defines the IGP mechanisms with 115 necessary extensions to provide scalable Segment Routing (SR) based 116 VTNs. The VTNs could be used as the underlay of the enhanced VPN 117 services. The mechanism described in [I-D.dong-lsr-sr-enhanced-vpn] 118 allows flexible combination of the topology and resource attribute to 119 provide a relatively large number of VTNs. In some network 120 scenarios, each VTN can be associated with a unique Flex-Algo, and 121 the set of network resources allocated to the VTN can be instantiated 122 using sub-interfaces or member links of the L3 interfaces. This 123 document describes a mechanism to build the SR based VTNs using SR 124 Flex-Algo and IGP L2 bundle with minor extensions. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in 131 BCP14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they 132 appear in all capitals, as shown here. 134 2. Advertisement of SR VTN Topology Attribute 136 [I-D.ietf-lsr-flex-algo] specifies the mechanism to provide 137 distributed constraint-path computation, and the usage of SR-MPLS 138 prefix-SIDs and SRv6 locators for steering traffic along the 139 constrained paths. 141 The Flex-Algo Definition (FAD) is the combination of calculation- 142 type, metric-type and the topological constraints used for path 143 computation. According to the network nodes' participation of a 144 Flex-Algo, and the rules of including or excluding Admin Groups (i.e. 145 colors) and Shared Risk Link Groups (SRLGs), the topology of a VTN 146 can be described using the associated Flex-Algo. If each VTN is 147 associated with a unique Flex-Algo, the Flex-Algo identifier could be 148 reused as the identifier of the VTN in the control plane. 150 With the mechanisms defined in[RFC8667] [I-D.ietf-lsr-flex-algo], SR- 151 MPLS prefix-SID advertisement can be associated with a specific 152 topology and a specific algorithm, which can be a Flex-Algo. This 153 allows the nodes to use the prefix-SIDs to steer traffic along 154 distributed computed constraint paths according to the associated 155 Flex-Algo in a particular topology. 157 [I-D.ietf-lsr-isis-srv6-extensions] specifies the IS-IS extensions to 158 support SRv6 data plane, in which the SRv6 locators advertisement can 159 be associated with a topology and a specific algorithm, which can be 160 a Flex-Algo. This allows the nodes to use the SRv6 locators to steer 161 traffic along distributed computed constraint paths according to the 162 associated Flex-Algo in a particular topology. In addition, 163 topology/algorithm specific SRv6 End SIDs and End.X SIDs can be used 164 to enforce traffic over the Loop-Free Alternatives (LFA) computed 165 backup paths. 167 3. Advertisement of SR VTN Resource Attribute 169 Each VTN can be allocated with a set of dedicated network resources. 170 In order to perform constraint based path computation for each VTN on 171 network controller and the ingress nodes, the resource attribute of 172 each VTN also needs to be advertised. 174 IS-IS L2 Bundle [RFC8668] was defined to advertise the link 175 attributes of the Layer-2 bundle member links. In this section, it 176 is extended to advertise the set of network resource attributes 177 associated with different VTNs on a shared Layer-3 link. 179 The Layer-3 link may or may not be a Layer-2 link bundle, as long as 180 it has the capability of allocating different subsets of link 181 resources to different VTNs it participates in. A subset of the link 182 resources can be considered as a virtual Layer-2 member link (or sub- 183 interface) of the Layer-3 link. If the Layer-3 interface is a 184 Layer-2 link bundle, it is possible that the subset of link resource 185 allocated to a specific VTN is provided by one of the physical 186 Layer-2 member links. 188 A new flag "V" (Virtual) is defined in the flag field of the Parent 189 L3 Neighbor Descriptor in the L2 Bundle Member Attributes TLV (25). 191 0 1 2 3 4 5 6 7 192 +-+-+-+-+-+-+-+-+ 193 |P|V| | 194 +-+-+-+-+-+-+-+-+ 196 V flag: When the V flag is set, it indicates the advertised member 197 links under the Parent Layer-3 link are virtual Layer-2 member links. 198 When the V flag is clear, it indicates the member links are physical 199 member links. This flag may be used to determine whether the member 200 links share fates with the parent interface. 202 For each virtual or physical member link, the TE attributes defined 203 in [RFC5305] such as the Maximum Link Bandwidth and Admin Groups 204 SHOULD be advertised using the mechanism as defined in [RFC8668]. 205 The SR-MPLS Adj-SIDs or SRv6 End.X SIDs associated with each of the 206 virtual or physical Layer-2 member links SHOULD also be advertised 207 according to [RFC8668] and [I-D.dong-lsr-l2bundle-srv6]. 209 In order to correlate the virtual or physical member links with the 210 Flex-Algo used to identify the VTN, each VTN SHOULD be assigned with 211 a unique Admin Group (AG) or Extended Admin Group (EAG), and the 212 virtual or physical member link associated with this VTN SHOULD be 213 configured with the AG or EAG assigned to the VTN. The AG or EAG of 214 the parent Layer 3 link SHOULD be set to the union of all the AGs or 215 EAGs of its virtual or physical member links. In the definition of 216 the Flex-Algo corresponding to the VTN, It MUST use the Include-Any 217 Admin Group rule with only the AG or EAG assigned to the VTN as the 218 link constraints, the Include-All Admin Goup rule or the Exclude 219 Admin Group rule MUST NOT be used. This ensures that the Layer-3 220 link is included in the Flex-Algo specific constraint path 221 computation for each VTN it participates in. 223 4. Forwarding Plane Operations 225 For SR-MPLS data plane, a prefix SID is associated with the paths 226 calculated using the corresponding Flex-Algo of a VTN. An outgoing 227 Layer-3 interface is determined for each path. In addition, the 228 prefix-SID also steers the traffic to use the virtual or physical 229 member link which is associated with the VTN on the outgoing Layer-3 230 interface for packet forwarding. The Adj-SIDs associated with the 231 virtual or physical member links of a VTN MAY be used with the 232 prefix-SIDs of the same VTN together to build SR-MPLS paths with the 233 topological and resource constraints of the VTN. 235 For SRv6 data plane, an SRv6 Locator is a prefix which is associated 236 with the paths calculated using the corresponding Flex-Algo of a VTN. 237 An outgoing Layer-3 interface is determined for each path. In 238 addition, the SRv6 Locator prefix also steers the traffic to use the 239 virtual or physical member link which is associated with the VTN on 240 the outgoing Layer-3 interface for packet forwarding. The End.XU 241 SIDs associated with the virtual or physical member links of a VTN 242 MAY be used with the SRv6 Locator prefix of the same VTN together to 243 build SRv6 paths with the topological and resource constraints of the 244 VTN. 246 5. Scalability Considerations 248 The mechanism described in this document assumes that each VTN is 249 associated with an unique Flex-Algo, so that the Flex-Algo IDs can be 250 reused to identify the VTNs in the control plane. While this brings 251 the benefit of simplicity, it also has some limitations. For 252 example, it means that even if multiple VTNs share the same 253 topological constraints, they would still need to be identified using 254 different Flex-Algo IDs in the control plane, then independent path 255 computation needs to be executed for each VTN. The number of VTNs 256 supported in a network may be dependent on the number of Flex-Algos 257 supported, which is related to the control plane overhead. Another 258 aspect which may impact the number of VTNs supported with this 259 mechanism is that at most 128 Flex-Algos can be used in a network. 260 The mechanism described in this document is applicable to network 261 scenarios where the number of required VTN is relatively small. A 262 detailed analysis about the VTN scalability and the possible 263 optimizations for supporting a large number of VTNs is described in 264 [I-D.dong-teas-enhanced-vpn-vtn-scalability]. 266 6. Security Considerations 268 This document introduces no additional security vulnerabilities to 269 IS-IS. 271 The mechanism proposed in this document is subject to the same 272 vulnerabilities as any other protocol that relies on IGPs. 274 7. IANA Considerations 276 This document does not request any IANA actions. 278 8. Acknowledgments 280 The authors would like to thank Zhenbin Li and Peter Psenak for the 281 review and discussion of this document. 283 9. References 285 9.1. Normative References 287 [I-D.dong-lsr-l2bundle-srv6] 288 Dong, J. and Z. Hu, "Advertising SRv6 SIDs for Layer 2 289 Bundle Member Links in IGP", draft-dong-lsr-l2bundle- 290 srv6-00 (work in progress), February 2021. 292 [I-D.ietf-lsr-flex-algo] 293 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 294 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 295 algo-15 (work in progress), April 2021. 297 [I-D.ietf-lsr-isis-srv6-extensions] 298 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 299 Z. Hu, "IS-IS Extension to Support Segment Routing over 300 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-14 301 (work in progress), April 2021. 303 [I-D.ietf-spring-resource-aware-segments] 304 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 305 Z., and F. Clad, "Introducing Resource Awareness to SR 306 Segments", draft-ietf-spring-resource-aware-segments-02 307 (work in progress), February 2021. 309 [I-D.ietf-spring-sr-for-enhanced-vpn] 310 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., Li, 311 Z., and F. Clad, "Segment Routing based Virtual Transport 312 Network (VTN) for Enhanced VPN", draft-ietf-spring-sr-for- 313 enhanced-vpn-00 (work in progress), February 2021. 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 321 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 322 2008, . 324 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 325 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 326 May 2017, . 328 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 329 Decraene, B., Litkowski, S., and R. Shakir, "Segment 330 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 331 July 2018, . 333 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 334 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 335 Extensions for Segment Routing", RFC 8667, 336 DOI 10.17487/RFC8667, December 2019, 337 . 339 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 340 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 341 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 342 December 2019, . 344 9.2. Informative References 346 [I-D.dong-lsr-sr-enhanced-vpn] 347 Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., JooHeon, L., 348 and S. Bryant, "IGP Extensions for Segment Routing based 349 Enhanced VPN", draft-dong-lsr-sr-enhanced-vpn-05 (work in 350 progress), February 2021. 352 [I-D.dong-teas-enhanced-vpn-vtn-scalability] 353 Dong, J., Li, Z., Qin, F., Yang, G., and J. N. Guichard, 354 "Scalability Considerations for Enhanced VPN (VPN+)", 355 draft-dong-teas-enhanced-vpn-vtn-scalability-02 (work in 356 progress), February 2021. 358 [I-D.ietf-teas-enhanced-vpn] 359 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 360 Framework for Enhanced Virtual Private Network (VPN+) 361 Services", draft-ietf-teas-enhanced-vpn-07 (work in 362 progress), February 2021. 364 Authors' Addresses 366 Yongqing Zhu 367 China Telecom 369 Email: zhuyq8@chinatelecom.cn 371 Jie Dong 372 Huawei Technologies 374 Email: jie.dong@huawei.com 375 Zhibo Hu 376 Huawei Technologies 378 Email: huzhibo@huawei.com