idnits 2.17.1 draft-hegde-spring-mpls-seamless-sr-05.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 22, 2021) is 1153 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.hegde-rtgwg-egress-protection-sr-networks' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-performance-routing' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'I-D.kaliraj-idr-bgp-classful-transport-planes' is defined on line 921, but no explicit reference was found in the text == Unused Reference: 'I-D.zzhang-bess-bgp-multicast' is defined on line 927, but no explicit reference was found in the text == Unused Reference: 'RFC8669' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'I-D.hegde-spring-node-protection-for-sr-te-paths' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-link-bandwidth' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-tunnel-encaps' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mpls-seamless-mpls' is defined on line 976, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-segment-routing-ti-lfa' is defined on line 987, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 993, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-sr-service-programming' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-network-programming' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: 'I-D.saad-sr-fa-link' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: 'RFC1997' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: 'RFC4684' is defined on line 1031, but no explicit reference was found in the text == Unused Reference: 'RFC5357' is defined on line 1043, but no explicit reference was found in the text == Unused Reference: 'RFC7311' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'RFC7471' is defined on line 1059, but no explicit reference was found in the text == Unused Reference: 'RFC7510' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'RFC8287' is defined on line 1080, but no explicit reference was found in the text == Unused Reference: 'RFC8402' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'RFC8679' is defined on line 1103, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hegde-rtgwg-egress-protection-sr-networks-01 == Outdated reference: A later version (-17) exists of draft-kaliraj-idr-bgp-classful-transport-planes-06 ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-21 == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-02 == Outdated reference: A later version (-13) exists of draft-ietf-rtgwg-segment-routing-ti-lfa-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 == Outdated reference: A later version (-03) exists of draft-saad-sr-fa-link-02 Summary: 1 error (**), 0 flaws (~~), 35 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING S. Hegde 3 Internet-Draft C. Bowers 4 Intended status: Informational Juniper Networks Inc. 5 Expires: August 26, 2021 X. Xu 6 Alibaba Inc. 7 A. Gulko 8 EdwardJones 9 A. Bogdanov 10 Google Inc. 11 J. Uttaro 12 ATT 13 L. Jalil 14 Verizon 15 M. Khaddam 16 Cox communications 17 A. Alston 18 Liquid Telecom 19 LM. Contreras 20 Telefonica 21 February 22, 2021 23 Seamless SR Problem Statement 24 draft-hegde-spring-mpls-seamless-sr-05 26 Abstract 28 This draft documents a set of use cases and requirements for end-to- 29 end intent-based paths spanning multi-domain packet networks. The 30 document explicitly focuses on use cases that require high scale and 31 availability, which will likely benefit from distributed solutions. 32 It is intended that the requirements in this document serve as a 33 basis for future IETF work to develop distributed solutions for 34 inter-domain intent-based transport paths. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on August 26, 2021. 59 Copyright Notice 61 Copyright (c) 2021 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Large scale networks . . . . . . . . . . . . . . . . . . . . 4 78 2.1. Service provider networks . . . . . . . . . . . . . . . . 4 79 2.2. Cloud provider WAN networks . . . . . . . . . . . . . . . 5 80 2.3. Data Center WAN Networks . . . . . . . . . . . . . . . . 6 81 3. Use Cases for Inter-domain Intent-based Transport . . . . . . 6 82 3.1. Inter-domain Data Sovereignty . . . . . . . . . . . . . . 6 83 3.2. Inter-domain Low-Latency Services . . . . . . . . . . . . 7 84 3.3. Network Mergers . . . . . . . . . . . . . . . . . . . . . 7 85 3.4. Inter-domain Service Function Chaining . . . . . . . . . 8 86 3.5. AS Confederation . . . . . . . . . . . . . . . . . . . . 8 87 3.6. Inter-domain Multicast Use cases . . . . . . . . . . . . 8 88 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 89 4.1. AS and IGP Domain Models . . . . . . . . . . . . . . . . 9 90 4.1.1. Multiple ASes connected with E-BGP . . . . . . . . . 9 91 4.1.2. Single AS multiple IGP domains . . . . . . . . . . . 10 92 4.1.3. Single AS, Multiple IGP domains with no common border 93 node . . . . . . . . . . . . . . . . . . . . . . . . 11 94 4.2. Transport tunneling Requirements . . . . . . . . . . . . 11 95 4.2.1. Unicast tunneling Requirements . . . . . . . . . . . 11 96 4.2.2. Multicast tunneling Requirements . . . . . . . . . . 12 98 4.3. Inter-domain SLA Requirements . . . . . . . . . . . . . . 13 99 4.3.1. Latency, Delay Variation, and Link Loss Constraints . 13 100 4.3.2. Bandwidth Constraints . . . . . . . . . . . . . . . . 13 101 4.3.3. Link Inclusion/Exclusion Constraints . . . . . . . . 13 102 4.3.4. Node Inclusion/Exclusion Constraints . . . . . . . . 14 103 4.3.5. Domain Inclusion/Exclusion Constraints . . . . . . . 14 104 4.3.6. Diverse Paths . . . . . . . . . . . . . . . . . . . . 14 105 4.3.7. Constraint applicability to a subset of domains . . . 15 106 4.3.8. Service function chaining . . . . . . . . . . . . . . 15 107 4.4. Multicast specific requirements . . . . . . . . . . . . . 15 108 4.5. Interoperate with BGP-LU . . . . . . . . . . . . . . . . 15 109 4.6. Merger and Migration Requirements . . . . . . . . . . . . 16 110 4.6.1. Option A and Option B Usecases . . . . . . . . . . . 16 111 4.6.2. Inter-Domain Intent Translation . . . . . . . . . . . 16 112 4.6.3. Native Support for Best Effort Paths . . . . . . . . 16 113 4.6.4. Interoperate with Other tunneling Mechanisms . . . . 16 114 4.7. Scalability Requirements . . . . . . . . . . . . . . . . 16 115 4.8. Availability Requirements . . . . . . . . . . . . . . . . 17 116 4.9. Operations and Automation Requirements . . . . . . . . . 17 117 4.10. Service Mapping Requirements . . . . . . . . . . . . . . 18 118 4.10.1. Traffic service mapping . . . . . . . . . . . . . . 18 119 4.10.2. 1 to N service mapping . . . . . . . . . . . . . . . 19 120 4.11. Interaction with Other Approaches . . . . . . . . . . . . 19 121 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 20 122 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 123 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 124 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 125 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 126 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 127 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 128 10.2. Informative References . . . . . . . . . . . . . . . . . 21 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 131 1. Introduction 133 Evolving trends in wireless access technology, cloud applications, 134 virtualization, and network consolidation all contribute to the 135 increasing demands being placed on a common packet network. In order 136 to meet these demands, a given network will need to scale 137 horizontally in terms of its bandwidth, absolute number of nodes, and 138 geographical extent. The same network will need to scale vertically 139 in terms of the different services that it needs to simultaneously 140 support. 142 In order to operate networks with large numbers of devices, network 143 operators organize networks into multiple smaller network domains. 144 Each network domain typically runs an IGP which has complete 145 visibility within its own domain, but limited visibility outside of 146 its domain. Network operators will continue to use multiple domains 147 to scale horizontally. These multi-domain networks will also need to 148 scale vertically, to allow a common multi-domain network to carry all 149 of an organization's services. 151 Evolving network requirements (e.g., 5G, native cloud) motivate 152 network operators to deploy tunnels that span multiple AS's and 153 maintain specific transport characteristics (e.g., bandwidth, 154 latency). There is a need to provide flexible, scalable, and 155 reliable end-to-end connectivity for multiple services across 156 independent network domains. 158 2. Large scale networks 160 2.1. Service provider networks 162 Service Provider networks can contain many nodes distributed over a 163 large geographic area. 5G networks can include as many as one million 164 nodes, with the majority of those being radio access nodes. Radio 165 and access nodes may be constrained by their memory and processing 166 capabilities. 168 Service provider transport networks use multiple domains to support 169 scalability. For this analysis, we consider a representative network 170 design with four level of hierarchy: access domains, pre-aggregation 171 domains, aggregation domains and a core. (See Figure 1). The 172 separation of domains internal to the service provider can be 173 performed by using either IGP or BGP. 175 +-------+ +-------+ +------+ +------+ 176 | | | | | | | | 177 +--+ P-AGG1+---+ AGG1 +---+ ABR1 +---+ LSR1 +--> to ABR 178 / | | /| | | | | | 179 +----+/ +-------+\/ +-------+ +------+ /+------+ 180 | AN | /\ \/ 181 +----+\ +-------+ \+-------+ +------+/\ +------+ 182 \ | | | | | | \| | 183 +--+ P-AGG2+---+ AGG2 +---+ ABR2 +---+ LSR2 +--> to ABR 184 | | | | | | | | 185 +-------+ +-------+ +------+ +------+ 187 ISIS L1 ISIS L2 ISIS L2 189 |-Access-|--Aggregation Domain--|---------Core-----------------| 191 Figure 1: 5G network 193 5G networks support a variety of service use cases that require end- 194 to-end slicing. In certain cases the end-to-end connectivity 195 requires the ability to forward over intent-based paths. The inter- 196 domain solution should support end-to-end Service Level 197 Objectives(SLO) to allow the creation of network slices. 199 2.2. Cloud provider WAN networks 201 As WAN networks grow beyond several thousand nodes, it is often 202 useful to divide the network into multiple IGP domains, as 203 illustrated in Figure 2. Separate IGP domains increase service 204 availability by establishing a constrained failure domain. Smaller 205 IGP domains may also improve network performance and health by 206 reducing the device scale profile (including protocol and FIB scale). 208 +-------+ +-------+ +-------+ 209 | | | | | | 210 | ABR1 ABR2 ABR3 ABR4 | 211 | | | | | | 212 PE1+ D1 +-----+ D2 +-----+ D3 +PE2 213 | | | | | | 214 | ABR11 ABR22 ABR33 ABR44 | 215 | | | | | | 216 +-------+ +-------+ +-------+ 218 |-ISIS1-| |-ISIS2-| |-ISIS3-| 220 Figure 2: WAN Network 222 These large WAN networks often cross national boundaries. In order 223 to meet data sovereignty requirements, operators need to maintain 224 strict control over end-to-end traffic-engineered (TE) paths. A goal 225 of a distributed inter-domain solution is to be able to create highly 226 constrained inter-domain TE paths in a scalable manner. 228 Some deployments may use a centralized controller to acquire the 229 topologies of multiple domains and build end-to-end constrained 230 paths. This centralized approach can be scaled with hierarchical 231 controllers. However, there is still significant risk of a loss of 232 network connectivity to one or more controllers, which can result in 233 a failure to satisfy the strict requirements of data sovereignty. 234 The network should have pre-established TE paths end-to-end that 235 don't rely on controllers in order to address these failure 236 scenarios. 238 2.3. Data Center WAN Networks 240 Data centers are playing an increasingly important role in providing 241 access to information and applications. Geographically diverse data 242 centers usually connect via a high speed, reliable and secure DC WAN 243 core network. 245 +-------+ +-------+ +-------+ 246 | ASBR1 ASBR2 ASBR3 ASBR4 | 247 | | | DC WAN| | | 248 PE1+ DC1 +-----+ CORE +-----+ DC2 +PE2 249 | ASBR11 ASBR22 ASBR33 ASBR44 | 250 | | | | | | 251 +-------+ +-------+ +-------+ 253 |-ISIS1-| |-ISIS2-| |-ISIS3-| 255 Figure 3: DCI Network 257 In many DC WAN deployments, applications require end-to-end path 258 diversity and end-to-end low latency paths. The DC WAN networks may 259 consist of large number of devices owing to global presence. In some 260 DC WAN deployments the tunneling mechanisms used within the data 261 centers are the same as those used in the DC WAN core. For example, 262 a network may use MPLS in both data center and DC WAN core. Or it 263 may use SRv6 in both data center and DC WAN core. This can simplify 264 network deployments. 266 However, in some DC WAN deployments the traffic within data centers 267 and the traffic over the DC WAN core use different tunneling 268 mechanisms, such as SRv6 in the data center and MPLS in the DC WAN 269 core. It is important for DC WAN network operators to have 270 flexibility in the choice of tunneling mechanisms across domains. 272 3. Use Cases for Inter-domain Intent-based Transport 274 The use cases for inter-domain intent-based packet transport 275 described in this section are intended to provide motivation for the 276 requirements that follow. 278 3.1. Inter-domain Data Sovereignty 279 +-----------+ +-----------+ +-----------+ 280 | | | +-+ AS2 | | | 281 | A1+--+A2 | | A3+--+A4 | 282 PE1+ AS1 | | |Z| | | AS3 +PE3 283 | A5+--+A6 | | A7+--+A8 | 284 | | | +-+ | | | 285 +--A13--A15-+ +-A17--A19--+ +-----------+ 286 | | | | 287 | | | | 288 | | | | 289 +--A14--A16-+ +-A18--A20--+ 290 | | | | 291 | A9+--+A10 | 292 PE4+ AS4 | | AS5 | 293 | A11+-+A12 | 294 | | | | 295 +-----------+ +-----------+ 297 Figure 4: Multi domain Network 299 Figure Figure 4 depicts a WAN with multiple ASes. Each AS is resides 300 serves a continent (e.g., Asia). Certain traffic from PE1 (in AS1) 301 to PE3 (in AS3) must not traverse country Z in AS2. However, all 302 paths from AS1 to AS3 traverse AS 2. The inter-domain solution 303 should provide end-to-end path creation that traverses AS 2 but 304 avoids country Z. 306 3.2. Inter-domain Low-Latency Services 308 Service provider networks running L2 and L3VPNs carry traffic for 309 particular VPNs on low-latency paths that traverse multiple domains. 311 3.3. Network Mergers 313 +-----------+ +-----------+ 314 | ASBR1 ASBR2 | 315 | | | | 316 PE1+ AS1 +----------------+ AS2 +PE2 317 | ASBR11 ASBR22 | 318 | | | | 319 +-----------+ +-----------+ 321 Figure 5: Network Mergers 323 In diagram Figure 5 above, AS1 and AS2 which were previously under 324 independent administration, merge to come under a single 325 administration. The network operator may decide to merge the two 326 domains into single AS which would need bigger operational effort. 327 Network operators may also retain the two ASes and build end-to-end 328 paths across the two Ases. In this case, the paths in AS1 and AS2 329 corresponding to the same intent may use different representations in 330 the two ASes. In some cases, organizations may continue to use 331 option A or option B [RFC4364] style interconnectivity in which case 332 the inter-domain solution should satisfy intent of the path on inter- 333 domain links for the service prefixes. In other cases, organizations 334 may prefer to use option C style connectivity from PE1 to PE2. In 335 this case, an inter-domain solution should provide effective 336 mechanisms to translate intent across domains without requiring 337 renumbering of the intent representation. 339 3.4. Inter-domain Service Function Chaining 341 [RFC7665] defines service function chaining as an ordered set of 342 service functions and automated steering of traffic through this set 343 of service functions. There could be a variety of service functions 344 such as firewalls, parental control, CGNAT etc. In 5G networks these 345 functions may be completely virtualized or could be a mix of 346 virtualized functions and physical appliances. It is required that 347 the inter-domain solution caters to the service function chaining 348 requirements. The service functions may be virtualized and spread 349 across different data centers attached to different domains. 351 3.5. AS Confederation 353 BGP confederation allows the division of a public AS in multiple sub- 354 AS, usually with private identifiers. From outside, the 355 confederation is seen as a single and common AS, the public one. BGP 356 sessions are maintained among sub-AS. In the internals of the 357 confederation, each sub-AS can be configured and run autonomously, 358 even though some BGP parameters (like e.g. LOCAL_PREF or MED) are 359 preserved across sub-AS. Thus, it can be of interest to define end- 360 to-end paths of specific characteristics in terms of SLOs across the 361 sub-AS as well as internally to each sub-AS. 363 3.6. Inter-domain Multicast Use cases 365 Multicast services such as IPTV and multicast VPN also need to be 366 supported across a multi-domain service provider network. 368 +---------+---------+---------+ 369 | | | | 370 S1 ABR1 ABR2 R1 371 | Metro1 | Core | Metro2 | 372 | | | | 373 S2 ABR11 ABR22 R2 374 | | | | 375 +---------+---------+---------+ 377 |-ISIS1-| |-ISIS2-| |-ISIS3-| 379 Figure 6: Multicast usecases 381 Figure 6 shows a simplified multi-domain network supporting 382 multicast. Multicast sources S1 and S2 lie in a different domain 383 from the receivers R1 and R2. Using multiple IGP domains presents a 384 problem for the establishment of multicast replication trees. 385 Typically, a multicast receiver does a reverse path forwarding (RPF) 386 lookup for a multicast source. One solution is to leak the routes 387 for multicast sources across the IGP domains. However, this can 388 compromise the scaling properties of the multi-domain architecture. 389 A distributed inter-domain solution should accommodate a mixture of 390 existing and newer technologies to better facilitate coexistence and 391 migration. A distributed solution should avoid leaking RPF routes 392 into the IGP domains. 394 4. Requirements 396 The requirements described in this document are mostly applicable to 397 network under a single administrative domain that are organized into 398 multiple network domains. The requirements are also applicable to 399 multi-AS networks with closely cooperating administration. 401 4.1. AS and IGP Domain Models 403 This section describes three different ways that multi-domain 404 networks are organized today. The requirements in subsequent 405 sections are applicable to all three types of multi-domain networks 406 described below. 408 4.1.1. Multiple ASes connected with E-BGP 409 ----IBGP------EBGP----IBGP------EBGP-----IBGP--- 410 | | | | | | 412 +-----------+ +-----------+ +-----------+ 413 | | | | | | 414 | ASBR1+--+ASBR2 ASBR3+--+ASBR4 | 415 PE1+ AS1 | X | AS2 | X | AS3 +PE2 416 | ASBR5+--+ASBR6 ASBR7+--+ASBR8 | 417 | | | | | | 418 +-----+-----+ +-----------+ +-----------+ 419 PE3 421 |---ISIS1---| |---ISIS2---| |---ISIS3---| 423 Figure 7: Multiple ASes connected with E-BGP 425 The above diagram Figure 7 shows three different ASes (AS1, AS2 and 426 AS3.) ASBR1 to ASBR8 are border nodes between the ASes. A given 427 ASBR runs E-BGP sessions with the ASBRs in adjacent ASes. The ASBR 428 also runs I-BGP sessions with other ASBRs in the same AS. Route 429 reflectors can also be used to achieve this full mesh of I-BGP 430 information exchange.Similar scenario applies when considering BGP 431 confederations [RFC5065]. 433 4.1.2. Single AS multiple IGP domains 435 ----IBGP-----------IBGP-------------IBGP---- 436 | | | | 437 +-----------+ +------------+ +-----------+ 438 / \ / \/ \ 439 | ABR1 ABR3 | 440 | | | | 441 PE1+ Metro1 + Core + Metro2 +PE2 442 | | | | 443 | ABR2 ABR4 | 444 \ /\ /\ / 445 +------------+ +-----------+ +------------+ 447 Figure 8: Single AS with Multiple IGP domains 449 The above diagram Figure 8 shows three different IGP domains, Metro1, 450 Core, and Metro2. The three IGP domains may be realized with 451 multiple levels in ISIS or multiple areas in OSPF. They can also be 452 realized using separate IGP instances. 454 This single-AS network uses I-BGP sessions. ABRs and PEs achieve a 455 full mesh of I-BGP information sharing by configuring the ABRs as 456 inline route reflectors. 458 4.1.3. Single AS, Multiple IGP domains with no common border node 460 ----IBGP-----IBGP----IBGP------IBGP-----IBGP--- 461 | | | | | | 463 +-----------+ +-----------+ +-----------+ 464 | | | | | | 465 | ABR1+--+ABR2 ABR3+--+ABR4 | 466 PE1+ AS1:D1 | X | AS1:D2 | X | AS1:D3 +PE2 467 | ABR5+--+ABR6 ABR7+--+ABR8 | 468 | | | | | | 469 +-----+-----+ +-----------+ +-----------+ 470 PE3 472 |---ISIS1---| |---ISIS2---| |---ISIS3---| 474 Figure 9: Single AS multiple IGP domains with no common Border node 476 The above diagram Figure 9 shows a single AS1 with three different 477 IGP domains, D1, D2, and D3. ABR1 to ABR8 are border nodes for the 478 IGP domains and they participate in only one IGP domain. 480 This single-AS network uses I-BGP sessions. ABRs and PEs achieve a 481 full mesh of I-BGP information sharing by configuring the ABRs as 482 inline route reflectors. 484 4.2. Transport tunneling Requirements 486 4.2.1. Unicast tunneling Requirements 488 The inter-domain solution should support the following unicast 489 tunneling mechanisms: 491 SR-MPLS tunnels with IPv4 underlay 493 SR-MPLS tunnels with IPv6 underlay 495 SR-MPLS tunnels with dual stack underlay 496 SRv6 tunneling end-to-end 498 Segment routing TE tunnels and color-only policies as described in 499 [I-D.ietf-idr-segment-routing-te-policy] (both SR-MPLS and SRv6) 501 Flex-algo [I-D.ietf-lsr-flex-algo] (both SR-MPLS and SRv6) 503 Pure IP fabric (incapable of supporting MPLS or SRv6 tunneling 504 mechanisms) 506 RSVP and LDP based tunnels 508 The inter-domain solution should support the ability to have 509 different domains running different unicast tunneling mechanisms. 511 The solution should support inter-domain paths that fulfil a common 512 intent using different unicast tunneling mechanisms in different 513 domains. 515 4.2.2. Multicast tunneling Requirements 517 The inter-domain solution should support the following multicast 518 tunneling mechanisms: 520 All of the unicast tunneling mechanisms described in Section 4.2.1 521 should be supported for multicast service for the purpose of 522 ingress replication. 524 SR-P2MP as defined in [I-D.voyer-pim-sr-p2mp-policy] 526 PIM based multicast 528 RSVP-P2MP and mLDP [RFC6388] based tunnels 530 BGP based multicast (hop-by-hop or controller-driven, for native 531 IP, labelled, or SRv6 forwarding planes) 533 The inter-domain solution should support the ability to have 534 different domains running different multicast tunneling mechanisms 535 and should not require to leak RPF routes into IGP domains. 537 The solution should support inter-domain paths that fulfil a common 538 intent using different multicast tunneling mechanisms in different 539 domains. 541 4.3. Inter-domain SLA Requirements 543 This section discusses the end-to-end constraints that intent-based 544 inter-domain path may have to adhere to. The requirements described 545 in this section are applicable to the three types of AS and IGP 546 domain partitioning described in Section 4.1. 548 4.3.1. Latency, Delay Variation, and Link Loss Constraints 550 Link delay, delay variation and link loss values can be advertised 551 within a domain using the IGP as described in [RFC8570]. Within an 552 IGP domain, minimum latency, minimum delay variation, and minimum 553 link loss paths can be built using flex-algo 554 [I-D.ietf-lsr-flex-algo]. The end-to-end low latency, low delay 555 variation, or low link loss path requires accumulated metrics for 556 latency, delay variation, and link loss. 558 The solution should allow the creation of inter-domain paths with low 559 values of latency as calculated over the end-to-end path. It is not 560 necessary that the solution produce the absolute minimum end-to-end 561 latency, delay variation, or link loss path. However, the solution 562 should provide the ability to balance scalability with optimality. 564 Best path selection at any intermediate border node should be 565 allowed. 567 The inter-domain solution should allow advertising multiple paths 568 end-to-end and compare the accumulated metric across all of the paths 569 at the ingress. 571 4.3.2. Bandwidth Constraints 573 A distributed solution should support the creation of inter-domain 574 paths using intra-domain bandwidth guaranteed paths. 576 A distributed solution may support optimized path placement with end- 577 to-end bandwidth guarantees. 579 4.3.3. Link Inclusion/Exclusion Constraints 581 The links are associated with link-affinity or admin-groups. The 582 link-affinity can be used to indicate a characteristic of a link, 583 such as capacity, encryption, geography, etc. The inter-domain 584 solution should support the creation of paths across different 585 domains that satisfy link inclusion/exclusion constraints. The link 586 constraints should also be satisfied for inter-domain links, such as 587 those between ASBRs. 589 4.3.4. Node Inclusion/Exclusion Constraints 591 Creating an inter-domain path that includes or excludes a certain set 592 of nodes in each domain should be supported. The inter-domain 593 solution should be independent of the mechanisms used to achieve the 594 node inclusion/exclusion constraints within a domain. For example, 595 an RSVP-based domain may use link affinities to achieve node 596 exclusion constraints, while an SR-based domain may use flex-algo, 597 which natively supports excluding nodes. 599 4.3.5. Domain Inclusion/Exclusion Constraints 601 +-----------+ +-----------+ +-----------+ 602 | | | AS2 | | | 603 | A1+--+A2 A3+--+A4 | 604 PE1+ AS1 | | | | AS3 +PE3 605 | A5+--+A6 A7+--+A8 | 606 | | | | | | 607 +--A13--A15-+ +-A17--A19--+ +-AS22--AS23+ 608 | | | | 609 | | | | 610 | | | | 611 +--A14--A16-+ +-A18--A20--+ | | 612 | | | | | | 613 | A9+--+A10 AS20---- | 614 PE4+ AS4 | | AS5 | | 615 | A11+-+A12 AS21------------ 616 | | | | 617 +-----------+ +-----------+ 619 Figure 10: Multi-domain Network 621 Diagram Figure 10 shows a multi-domain, multi-AS network with the 622 possibility for AS-diverse paths. The inter-domain solution should 623 support creation of end-to-end paths that includes/excludes a certain 624 domain entirely. For example, a network operator should be able to 625 use the solution to create a path from PE1 to PE3 that automatically 626 avoids passing through nodes belonging to AS2. 628 4.3.6. Diverse Paths 630 The solution should support the creation of node and link-diverse 631 inter-domain paths. 633 The intra-domain portion of the end-to-end paths should make use of 634 existing mechanisms for computing and instantiating diverse paths 635 within a domain. 637 Inter-domain links (such as those connecting ASBRs) should also be 638 taken into account for diverse inter-domain paths. 640 The solution should support SRLG-aware inter-domain diverse paths. 642 4.3.7. Constraint applicability to a subset of domains 644 Use cases such as data sovereignty described in Section 3.1 require 645 that the paths with certain constraints are applicable to only a 646 subset of domains. In domains where a constraint is not applicable, 647 the end-to-end path should not create any state on the internal 648 nodes. 650 4.3.8. Service function chaining 652 Support the case where the set of service functions to be applied 653 are deployed in single domain. 655 Support the case where the set of service functions to be applied 656 are deployed across multiple domains. 658 Support virtualized service functions as well as service functions 659 based on physical appliances. 661 Support the movement of a virtualized service function from one 662 location to another. 664 Support high availability for service functions. 666 4.4. Multicast specific requirements 668 Many of the requirements above are applicable to multicast traffic as 669 well. Some requirements need to be refined with respect to 670 multicast. Multicast also has some unique requirements not shared by 671 unicast. These requirements will be covered in a future version of 672 this document. 674 4.5. Interoperate with BGP-LU 676 Seamless MPLS architecture is widely deployed and BGP-LU [RFC3107] is 677 used to connect different domains. The inter-domain solution for 678 intent-based paths should be interoperable with BGP-LU. 680 4.6. Merger and Migration Requirements 682 4.6.1. Option A and Option B Usecases 684 Options A and B require additional state on border nodes, so they are 685 typically less scalable than option C. However, options A and B can 686 be advantageous when it is necessary to do filtering or policing on 687 border nodes. When option A or B is deployed, the solution should 688 still meet the SLA requirements described in Section 4.3. 690 4.6.2. Inter-Domain Intent Translation 692 In cases where two network domains previously under different 693 administrations merge to come under a single administration, it may 694 be preferable to use option C connectivity between the domains. The 695 paths that fulfill the same intent may be represented using different 696 conventions in each domain. The inter-domain solution should support 697 efficient translation of intent from one representation to another. 699 4.6.3. Native Support for Best Effort Paths 701 The inter-domain solution for intent-based paths should also provide 702 the ability to create end-to-end best effort paths with accumulated 703 IGP metric across the domains. A deployment should not require two 704 different mechanisms to be deployed for best effort and intent-based 705 paths. 707 4.6.4. Interoperate with Other tunneling Mechanisms 709 As described in Section 4.2.1 and Section 3.6 the inter-domain 710 solution should support one domain having one type of tunneling 711 mechanism and another domain having another type of tunneling 712 mechanism. The different tunneling mechanisms may completely differ 713 in control plane and data plane operations (e.g. SRv6 and MPLS.) 714 The inter-domain solution should provide interoperability between 715 various tunneling mechanisms and provide the ability to create end- 716 to-end intent-based paths. 718 4.7. Scalability Requirements 720 The inter-domain solution should be able to support up to 1 721 million nodes. 723 The inter-domain solution should facilitate the use of access 724 nodes with low RIB/FIB and low CPU capabilities. 726 The inter-domain solution should facilitate the use of access 727 nodes with low label stacking capability. 729 The inter-domain solution should allow for a scalable response to 730 network events. An individual node should only need to respond to 731 a limited subset of network events. 733 Service routes on the border nodes should be minimized. 735 Non-MPLS versions of the inter-domain solution should support 736 summarization of prefixes in order achieve scalability. 738 The inter-domain solution should facilitate filtering in order to 739 ensure the access nodes need to receive and process only the 740 endpoint prefixes that the access node needs to send traffic to. 742 The inter-domain solution should minimize state on the border 743 nodes in order to reduce label and FIB resource consumption on 744 border nodes. 746 4.8. Availability Requirements 748 Traffic should be Fast Reroute (FRR) protected against link, node, 749 and SRLG failures within a domain. 751 Traffic should be FRR protected against border node failures. 753 Traffic should be FRR protected against inter-domain link 754 failures. 756 Traffic should be FRR protected against egress node and egress 757 link failures. 759 4.9. Operations and Automation Requirements 761 Each domain should be independent and should not depend on the 762 transport technology in another domain. This allows for more 763 flexible evolution of the network. 765 Basic MPLS OAM mechanisms described in [RFC8029] should be 766 supported for MPLS based solutions. 768 End-to-end ping and traceroute procedures should be supported. 770 The ability to validate the path inside each domain should be 771 supported. 773 Statistics for inter-domain intent-based paths should be supported 774 on a per path basis on the ingress and egress PE nodes as well as 775 border nodes. 777 The choice of transport tunnels that make up the inter-domain path 778 should be derived automatically from the intent that the path 779 fulfills. 781 The intent defined as color in the SR-TE architecture 782 [I-D.ietf-idr-segment-routing-te-policy] should map automatically 783 for all controller to router protocols such as BGP-SR-TE 784 [I-D.ietf-idr-segment-routing-te-policy], PCEP-SR 785 [I-D.ietf-pce-segment-routing-policy-cp], and NETCONF. 787 The intent should be mapped automatically from flex-algo number 788 [I-D.ietf-lsr-flex-algo]. 790 When access devices have CPU and memory constraints, it is useful 791 to be able to filter prefix advertisements using policies as 792 described in Section 4.7 For large networks it is operationally a 793 tedious and erroneous process to manage this. The inter-domain 794 solution should facilitate filtering the advertisements 795 automatically, based on the service prefixes it receives from end- 796 points. 798 4.10. Service Mapping Requirements 800 The above requirements focus on the service independent aspects of 801 inter-domain intent-based paths. In order for different services to 802 effectively use these paths, flexible service mapping is required. 803 The sections below summarize the requirements needed to achieve 804 flexible service mapping. 806 4.10.1. Traffic service mapping 808 Automated steering of traffic onto transport paths based on 809 communities carried in the service prefix advertisements should be 810 supported. 812 Steering of traffic on to transport paths based on the DSCP value 813 carried in IPv4/IPv6 packets should be supported. 815 Traffic steering based on EXP bits in the MPLS header should be 816 supported. 818 Traffic steering based on 5-tuple packet filter should be 819 supported. Source address, destination address, source port, 820 destination port and protocol fields should be allowed. 822 All the above traffic steering mechanisms should be supported for 823 all common types of service traffic, including L2 VPN and L3 VPN 824 traffic and global internet traffic. 826 When a path that fulfills the desired intent is not available, 827 fallback to a path that fulfills a secondary intent should be 828 supported. 830 When a path that fulfills the desired intent is not available, 831 fallback to a best-effort path should be supported. 833 When a path that fulfills the desired intent is not available, the 834 option of not using a fallback path (i,e. dropping the traffic) 835 should be supported. 837 4.10.2. 1 to N service mapping 839 The core domain is expected to have more traffic engineering 840 constraints as compared to metros. The ability to map the services 841 to appropriate transport tunnels at service attachment points should 842 be supported. 844 4.11. Interaction with Other Approaches 846 This document focuses on use cases and requirements that may benefit 847 from a distributed solution. Many of these same use cases and 848 requirements can be addressed with centralized approaches or other 849 distributed TE solutions. One example of a centralized approach is 850 described in "Interconnecting Millions of Endpoints with Segment 851 Routing" ([RFC8604]). 853 Distributed and centralized approaches have inherent tradeoffs. Some 854 networks may use a single approach. Other networks may choose to use 855 both distributed and centralized approaches to get the benefits of 856 both. A distributed inter-domain solution should support the 857 requirements below: 859 Support scenarios where some traffic uses paths created using a 860 centralized approach, and other traffic uses paths created using 861 the distributed solution. 863 Support scenarios where part of the distributed inter-domain path 864 is created using a centralized approach. 866 Support scenarios where traffic uses a centralized inter-domain 867 solution for primary traffic, and uses a distributed inter-domain 868 solution as a backup. 870 The distributed solution should not have any inherent dependencies 871 on centralized approaches. 873 The distributed solution should co-exist with other distributed TE 874 solutions. 876 5. Backward Compatibility 878 6. Security Considerations 880 TBD 882 7. IANA Considerations 884 8. Acknowledgements 886 Many thanks to Kireeti Kompella, Ron Bonica, Krzysztof Szarcowitz, 887 Srihari Sangli, Julian Lucek, Ram Santhanakrishnan, for discussions 888 and inputs. Thanks to Colby Barth, John Scudder, Joel Halpern for 889 review and comments. 891 9. Contributors 893 1.Kaliraj Vairavakkalai 895 Juniper Networks 897 kaliraj@juniper.net 899 2. Jeffrey Zhang 901 Juniper Networks 903 zzhang@juniper.net 905 10. References 907 10.1. Normative References 909 [I-D.hegde-rtgwg-egress-protection-sr-networks] 910 Hegde, S., Lin, W., and S. Peng, "Egress Protection for 911 Segment Routing (SR) networks", draft-hegde-rtgwg-egress- 912 protection-sr-networks-01 (work in progress), November 913 2020. 915 [I-D.ietf-idr-performance-routing] 916 Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C. 917 Jacquenet, "Performance-based BGP Routing Mechanism", 918 draft-ietf-idr-performance-routing-03 (work in progress), 919 December 2020. 921 [I-D.kaliraj-idr-bgp-classful-transport-planes] 922 Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., 923 Mishra, G., Khaddam, M., and X. Xu, "BGP Classful 924 Transport Planes", draft-kaliraj-idr-bgp-classful- 925 transport-planes-06 (work in progress), January 2021. 927 [I-D.zzhang-bess-bgp-multicast] 928 Zhang, Z., Giuliano, L., Patel, K., Wijnands, I., mishra, 929 m., and A. Gulko, "BGP Based Multicast", draft-zzhang- 930 bess-bgp-multicast-03 (work in progress), October 2019. 932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, 934 DOI 10.17487/RFC2119, March 1997, 935 . 937 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 938 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 939 . 941 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 942 A., and H. Gredler, "Segment Routing Prefix Segment 943 Identifier Extensions for BGP", RFC 8669, 944 DOI 10.17487/RFC8669, December 2019, 945 . 947 10.2. Informative References 949 [I-D.hegde-spring-node-protection-for-sr-te-paths] 950 Hegde, S., Bowers, C., Litkowski, S., Xu, X., and F. Xu, 951 "Node Protection for SR-TE Paths", draft-hegde-spring- 952 node-protection-for-sr-te-paths-07 (work in progress), 953 July 2020. 955 [I-D.ietf-idr-link-bandwidth] 956 Mohapatra, P. and R. Fernando, "BGP Link Bandwidth 957 Extended Community", draft-ietf-idr-link-bandwidth-07 958 (work in progress), March 2018. 960 [I-D.ietf-idr-segment-routing-te-policy] 961 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 962 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 963 Routing Policies in BGP", draft-ietf-idr-segment-routing- 964 te-policy-11 (work in progress), November 2020. 966 [I-D.ietf-idr-tunnel-encaps] 967 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 968 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 969 encaps-21 (work in progress), January 2021. 971 [I-D.ietf-lsr-flex-algo] 972 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 973 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 974 algo-13 (work in progress), October 2020. 976 [I-D.ietf-mpls-seamless-mpls] 977 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 978 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 979 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 981 [I-D.ietf-pce-segment-routing-policy-cp] 982 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 983 Bidgoli, "PCEP extension to support Segment Routing Policy 984 Candidate Paths", draft-ietf-pce-segment-routing-policy- 985 cp-02 (work in progress), January 2021. 987 [I-D.ietf-rtgwg-segment-routing-ti-lfa] 988 Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., 989 and D. Voyer, "Topology Independent Fast Reroute using 990 Segment Routing", draft-ietf-rtgwg-segment-routing-ti- 991 lfa-05 (work in progress), November 2020. 993 [I-D.ietf-spring-segment-routing-policy] 994 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 995 P. Mattes, "Segment Routing Policy Architecture", draft- 996 ietf-spring-segment-routing-policy-09 (work in progress), 997 November 2020. 999 [I-D.ietf-spring-sr-service-programming] 1000 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 1001 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 1002 Henderickx, W., and S. Salsano, "Service Programming with 1003 Segment Routing", draft-ietf-spring-sr-service- 1004 programming-03 (work in progress), September 2020. 1006 [I-D.ietf-spring-srv6-network-programming] 1007 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 1008 Matsushima, S., and Z. Li, "SRv6 Network Programming", 1009 draft-ietf-spring-srv6-network-programming-28 (work in 1010 progress), December 2020. 1012 [I-D.saad-sr-fa-link] 1013 Saad, T., Beeram, V., Barth, C., and S. Sivabalan, 1014 "Segment-Routing over Forwarding Adjacency Links", draft- 1015 saad-sr-fa-link-02 (work in progress), July 2020. 1017 [I-D.voyer-pim-sr-p2mp-policy] 1018 Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z. 1019 Zhang, "Segment Routing Point-to-Multipoint Policy", 1020 draft-voyer-pim-sr-p2mp-policy-02 (work in progress), July 1021 2020. 1023 [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities 1024 Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, 1025 . 1027 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1028 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1029 2006, . 1031 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 1032 R., Patel, K., and J. Guichard, "Constrained Route 1033 Distribution for Border Gateway Protocol/MultiProtocol 1034 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 1035 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 1036 November 2006, . 1038 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 1039 System Confederations for BGP", RFC 5065, 1040 DOI 10.17487/RFC5065, August 2007, 1041 . 1043 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1044 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1045 RFC 5357, DOI 10.17487/RFC5357, October 2008, 1046 . 1048 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 1049 Thomas, "Label Distribution Protocol Extensions for Point- 1050 to-Multipoint and Multipoint-to-Multipoint Label Switched 1051 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 1052 . 1054 [RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro, 1055 "The Accumulated IGP Metric Attribute for BGP", RFC 7311, 1056 DOI 10.17487/RFC7311, August 2014, 1057 . 1059 [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. 1060 Previdi, "OSPF Traffic Engineering (TE) Metric 1061 Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, 1062 . 1064 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 1065 "Encapsulating MPLS in UDP", RFC 7510, 1066 DOI 10.17487/RFC7510, April 2015, 1067 . 1069 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1070 Chaining (SFC) Architecture", RFC 7665, 1071 DOI 10.17487/RFC7665, October 2015, 1072 . 1074 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 1075 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 1076 Switched (MPLS) Data-Plane Failures", RFC 8029, 1077 DOI 10.17487/RFC8029, March 2017, 1078 . 1080 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 1081 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 1082 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 1083 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 1084 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 1085 . 1087 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1088 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1089 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1090 July 2018, . 1092 [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, 1093 D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) 1094 Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 1095 2019, . 1097 [RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., 1098 Henderickx, W., and D. Cooper, "Interconnecting Millions 1099 of Endpoints with Segment Routing", RFC 8604, 1100 DOI 10.17487/RFC8604, June 2019, 1101 . 1103 [RFC8679] Shen, Y., Jeganathan, M., Decraene, B., Gredler, H., 1104 Michel, C., and H. Chen, "MPLS Egress Protection 1105 Framework", RFC 8679, DOI 10.17487/RFC8679, December 2019, 1106 . 1108 [TS.23.501-3GPP] 1109 3rd Generation Partnership Project (3GPP), "System 1110 Architecture for 5G System; Stage 2, 3GPP TS 23.501 1111 v16.4.0", March 2020. 1113 Authors' Addresses 1115 Shraddha Hegde 1116 Juniper Networks Inc. 1117 Exora Business Park 1118 Bangalore, KA 560103 1119 India 1121 Email: shraddha@juniper.net 1123 Chris Bowers 1124 Juniper Networks Inc. 1126 Email: cbowers@juniper.net 1128 Xiaohu Xu 1129 Alibaba Inc. 1130 Beijing 1131 China 1133 Email: xiaohu.xxh@alibaba-inc.com 1135 Arkadiy Gulko 1136 EdwardJones 1138 Email: arkadiy.gulko@edwardjones.com 1140 Alex Bogdanov 1141 Google Inc. 1143 Email: bogdanov@google.com 1145 James Uttaro 1146 ATT 1148 Email: ju1738@att.com 1149 Luay Jalil 1150 Verizon 1152 Email: luay.jalil@verizon.com 1154 Mazen Khaddam 1155 Cox communications 1157 Email: mazen.khaddam@cox.com 1159 Andrew Alston 1160 Liquid Telecom 1162 Email: andrew.alston@liquidtelecom.com 1164 Luis M. Contreras 1165 Telefonica 1166 Ronda de la Comunicacion, s/n 1167 Sur-3 building, 3rd floor 1168 Madrid 28050 1169 Spain 1171 Email: luismiguel.contrerasmurillo@telefonica.com 1172 URI: http://lmcontreras.com/