idnits 2.17.00 (12 Aug 2021) /tmp/idnits5610/draft-ietf-bess-datacenter-gateway-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 22, 2021) is 296 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: draft-ietf-idr-bgp-ls-segment-routing-ext has been published as RFC 9085 == Outdated reference: draft-ietf-idr-bgpls-segment-routing-epe has been published as RFC 9086 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group A. Farrel 3 Internet-Draft Old Dog Consulting 4 Intended status: Standards Track J. Drake 5 Expires: January 23, 2022 E. Rosen 6 Juniper Networks 7 K. Patel 8 Arrcus, Inc. 9 L. Jalil 10 Verizon 11 July 22, 2021 13 Gateway Auto-Discovery and Route Advertisement for Segment Routing 14 Enabled Site Interconnection 15 draft-ietf-bess-datacenter-gateway-13 17 Abstract 19 Data centers are attached to the Internet or a backbone network by 20 gateway routers. One data center typically has more than one gateway 21 for commercial, load balancing, and resiliency reasons. Other sites, 22 such as access networks, also need to be connected across backbone 23 networks through gateways. 25 This document defines a mechanism using the BGP Tunnel Encapsulation 26 attribute to allow data center gateway routers to advertise routes to 27 the prefixes reachable in the site, including advertising them on 28 behalf of other gateways at the same site. This allows segment 29 routing to be used to identify multiple paths across the Internet or 30 backbone network between different gateways. The paths can be 31 selected for load-balancing, resilience, and quality purposes. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 23, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 69 3. Site Gateway Auto-Discovery . . . . . . . . . . . . . . . . . 5 70 4. Relationship to BGP Link State and Egress Peer Engineering . 7 71 5. Advertising a Site Route Externally . . . . . . . . . . . . . 7 72 6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Manageability Considerations . . . . . . . . . . . . . . . . 10 76 9.1. Relationship to Route Target Constraint . . . . . . . . . 10 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 11.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 Data centers (DCs) are critical components of the infrastructure used 86 by network operators to provide services to their customers. DCs 87 (sites) are interconnected by a backbone network, which consists of 88 any number of private networks and/or the Internet. DCs are attached 89 to the backbone network by gateway routers (GWs). One DC typically 90 has more than one GW for various reasons including commercial 91 preferences, load balancing, or resiliency against connection or 92 device failure. 94 Segment Routing (SR) [RFC8402] is a protocol mechanism that can be 95 used within a DC, and also for steering traffic that flows between 96 two DC sites. In order for a source site (also known as an ingress 97 site) that uses SR to load balance the flows it sends to a 98 destination site (also known as an egress site), it needs to know the 99 complete set of entry nodes (i.e., GWs) for that egress DC from the 100 backbone network connecting the two DCs. Note that it is assumed 101 that the connected set of DC sites and the border nodes in the 102 backbone network on the paths that connect the DC sites are part of 103 the same SR BGP Link State (LS) instance ([RFC7752] and 104 [I-D.ietf-idr-bgpls-segment-routing-epe]) so that traffic engineering 105 using SR may be used for these flows. 107 Other sites, such as access networks, also need to be connected 108 across backbone networks through gateways. For illustrative 109 purposes, consider the ingress and egress sites shown in Figure 1 as 110 separate ASes (noting that the sites could be implemented as part of 111 the ASes to which they are attached, or as separate ASes). The 112 various ASes that provide connectivity between the ingress and egress 113 sites could each be constructed differently and use different 114 technologies such as IP, MPLS using global table routing information 115 from native BGP, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN. That 116 is, the ingress and egress sites can be connected by tunnels across a 117 variety of technologies. This document describes how SR identifiers 118 (SIDs) are used to identify the paths between the ingress and egress 119 sites. 121 The solution described in this document is agnostic as to whether the 122 transit ASes do or do not have SR capabilities. The solution uses SR 123 to stitch together path segments between GWs and through the ASBRs. 124 Thus, there is a requirement that the GWs and ASBRs are SR-capable. 125 The solution supports the SR path being extended into the ingress and 126 egress sites if they are SR-capable. 128 The solution defined in this document can be seen in the broader 129 context of site interconnection in 130 [I-D.farrel-spring-sr-domain-interconnect]. That document shows how 131 other existing protocol elements may be combined with the solution 132 defined in this document to provide a full system, but is not a 133 necessary reference for understanding this document. 135 Suppose that there are two gateways, GW1 and GW2 as shown in 136 Figure 1, for a given egress site and that they each advertise a 137 route to prefix X which is located within the egress site with each 138 setting itself as next hop. One might think that the GWs for X could 139 be inferred from the routes' next hop fields, but typically it is not 140 the case that both routes get distributed across the backbone: rather 141 only the best route, as selected by BGP, is distributed. This 142 precludes load balancing flows across both GWs. 144 ----------------- --------------------- 145 | Ingress | | Egress ------ | 146 | Site | | Site |Prefix| | 147 | | | | X | | 148 | | | ------ | 149 | -- | | --- --- | 150 | |GW| | | |GW1| |GW2| | 151 -------++-------- ----+-----------+-+-- 152 | \ | / | 153 | \ | / | 154 | -+------------- --------+--------+-- | 155 | ||ASBR| ----| |---- |ASBR| |ASBR| | | 156 | | ---- |ASBR+------+ASBR| ---- ---- | | 157 | | ----| |---- | | 158 | | | | | | 159 | | ----| |---- | | 160 | | AS1 |ASBR+------+ASBR| AS2 | | 161 | | ----| |---- | | 162 | --------------- -------------------- | 163 --+-----------------------------------------------+-- 164 | |ASBR| |ASBR| | 165 | ---- AS3 ---- | 166 | | 167 ----------------------------------------------------- 169 Figure 1: Example Site Interconnection 171 The obvious solution to this problem is to use the BGP feature that 172 allows the advertisement of multiple paths in BGP (known as Add- 173 Paths) [RFC7911] to ensure that all routes to X get advertised by 174 BGP. However, even if this is done, the identity of the GWs will be 175 lost as soon as the routes get distributed through an Autonomous 176 System Border Router (ASBR) that will set itself to be the next hop. 177 And if there are multiple Autonomous Systems (ASes) in the backbone, 178 not only will the next hop change several times, but the Add-Paths 179 technique will experience scaling issues. This all means that the 180 Add-Paths approach is effectively limited to sites connected over a 181 single AS. 183 This document defines a solution that overcomes this limitation and 184 works equally well with a backbone constructed from one or more ASes 185 using the Tunnel Encapsulation attribute [RFC9012] as follows: 187 When a GW to a given site advertises a route to a prefix X within 188 that site, it will include a Tunnel Encapsulation attribute that 189 contains the union of the Tunnel Encapsulation attributes 190 advertised by each of the GWs to that site, including itself. 192 In other words, each route advertised by a GW identifies all of the 193 GWs to the same site (see Section 3 for a discussion of how GWs 194 discover each other). I.e., the Tunnel Encapsulation attribute 195 advertised by each GW contains multiple Tunnel TLVs, one or more from 196 each active GW, and each Tunnel TLV will contain a Tunnel Egress 197 Endpoint Sub-TLV that identifies the GW for that Tunnel TLV. 198 Therefore, even if only one of the routes is distributed to other 199 ASes, it will not matter how many times the next hop changes, as the 200 Tunnel Encapsulation attribute will remain unchanged. 202 To put this in the context of Figure 1, GW1 and GW2 discover each 203 other as gateways for the egress site. Both GW1 and GW2 advertise 204 themselves as having routes to prefix X. Furthermore, GW1 includes a 205 Tunnel Encapsulation attribute which is the union of its Tunnel 206 Encapsulation attribute and GW2's Tunnel Encapsulation attribute. 207 Similarly, GW2 includes a Tunnel Encapsulation attribute which is the 208 union of its Tunnel Encapsulation attribute and GW1's Tunnel 209 Encapsulation attribute. The gateway in the ingress site can now see 210 all possible paths to X in the egress site regardless of which route 211 is propagated to it, and it can choose one, or balance traffic flows 212 as it sees fit. 214 2. Requirements Language 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 3. Site Gateway Auto-Discovery 224 To allow a given site's GWs to auto-discover each other and to 225 coordinate their operations, the following procedures are 226 implemented: 228 o A route target ([RFC4360]) MUST be attached to each GW's auto- 229 discovery route (defined below) and its value MUST be set to a 230 value that indicates the site identifier. The rules for 231 constructing a route target are detailed in [RFC4360]. It is 232 RECOMMENDED that a Type x00 or x02 route target be used. 234 o Site identifiers are set through configuration. The site 235 identifiers MUST be the same across all GWs to the site (i.e., the 236 same identifier is used by all GWs to the same site), and MUST be 237 unique across all sites that are connected (i.e., across all GWs 238 to all sites that are interconnected). 240 o Each GW MUST construct an import filtering rule to import any 241 route that carries a route target with the same site identifier 242 that the GW itself uses. This means that only these GWs will 243 import those routes, and that all GWs to the same site will import 244 each other's routes and will learn (auto-discover) the current set 245 of active GWs for the site. 247 The auto-discovery route that each GW advertises consists of the 248 following: 250 o An IPv4 or IPv6 Network Layer Reachability Information (NLRI) 251 [RFC4760] containing one of the GW's loopback addresses (that is, 252 with an AFI/SAFI pair that is one of IPv4/NLRI used for unicast 253 forwarding (1/1), IPv6/NLRI used for unicast forwarding (2/1), 254 IPv4/NLRI with MPLS Labels (1/4), or IPv6/NLRI with MPLS Labels 255 (2/4)). 257 o A Tunnel Encapsulation attribute [RFC9012] containing the GW's 258 encapsulation information encoded in one or more Tunnel TLVs. 260 To avoid the side effect of applying the Tunnel Encapsulation 261 attribute to any packet that is addressed to the GW itself, the 262 address advertised for auto-discovery MUST be a different loopback 263 address than is advertised for packets directed to the gateway 264 itself. 266 As described in Section 1, each GW will include a Tunnel 267 Encapsulation attribute with the GW encapsulation information for 268 each of the site's active GWs (including itself) in every route 269 advertised externally to that site. As the current set of active GWs 270 changes (due to the addition of a new GW or the failure/removal of an 271 existing GW) each externally advertised route will be re-advertised 272 with a new Tunnel Encapsulation attribute which reflects the current 273 set of active GWs. 275 If a gateway becomes disconnected from the backbone network, or if 276 the site operator decides to terminate the gateway's activity, it 277 MUST withdraw the advertisements described above. This means that 278 remote gateways at other sites will stop seeing advertisements from 279 or about this gateway. Note that if the routing within a site is 280 broken (for example, such that there is a route from one GW to 281 another, but not in the reverse direction), then it is possible that 282 incoming traffic will be routed to the wrong GW to reach the 283 destination prefix - in this degraded network situation, traffic may 284 be dropped. 286 Note that if a GW is (mis)configured with a different site identifier 287 from the other GWs to the same site then it will not be auto- 288 discovered by the other GWs (and will not auto-discover the other 289 GWs). This would result in a GW for another site receiving only the 290 Tunnel Encapsulation attribute included in the BGP best route; i.e., 291 the Tunnel Encapsulation attribute of the (mis)configured GW or that 292 of the other GWs. 294 4. Relationship to BGP Link State and Egress Peer Engineering 296 When a remote GW receives a route to a prefix X, it uses the Tunnel 297 Egress Endpoint Sub-TLVs in the containing Tunnel Encapsulation 298 attribute to identify the GWs through which X can be reached. It 299 uses this information to compute SR Traffic Engineering (SR TE) paths 300 across the backbone network looking at the information advertised to 301 it in SR BGP Link State (BGP-LS) 302 [I-D.ietf-idr-bgp-ls-segment-routing-ext] and correlated using the 303 site identity. SR Egress Peer Engineering (EPE) 304 [I-D.ietf-idr-bgpls-segment-routing-epe] can be used to supplement 305 the information advertised in BGP-LS. 307 5. Advertising a Site Route Externally 309 When a packet destined for prefix X is sent on an SR TE path to a GW 310 for the site containing X (that is, the packet is sent in the ingress 311 site on an SR TE path that describes the whole path including those 312 parts that are within the egress site), it needs to carry the 313 receiving GW's SID for X such that this SID becomes the next SID that 314 is due to be processed before the GW completes its processing of the 315 packet. To achieve this, each Tunnel TLV in the Tunnel Encapsulation 316 attribute contains a Prefix-SID sub-TLV [RFC9012] for X. 318 As defined in [RFC9012], the Prefix-SID sub-TLV is only for IPv4/IPV6 319 labelled unicast routes, so the solution described in this document 320 only applies to routes of those types. If the use of the Prefix-SID 321 sub-TLV for routes of other types is defined in the future, further 322 documents will be needed to describe their use for site 323 interconnection consistent with this document. 325 Alternatively, if MPLS SR is in use and if the GWs for a given egress 326 site are configured to allow GWs at remote ingress sites to perform 327 SR TE through that egress site for a prefix X, then each GW to the 328 egress site computes an SR TE path through the egress site to X, and 329 places each in an MPLS label stack sub-TLV [RFC9012] in the SR Tunnel 330 TLV for that GW. 332 Please refer to Section 7 of 333 [I-D.farrel-spring-sr-domain-interconnect] for worked examples of how 334 the SID stack is constructed in this case, and how the advertisements 335 would work. 337 6. Encapsulation 339 If a site is configured to allow remote GWs send packets to the site 340 in the site's native encapsulation, then each GW to the site will 341 also include multiple instances of a Tunnel TLV for that native 342 encapsulation in externally advertised routes: one for each GW and 343 each containing a Tunnel Egress Endpoint sub-TLV with that GW's 344 address. A remote GW may then encapsulate a packet according to the 345 rules defined via the sub-TLVs included in each of the Tunnel TLVs. 347 7. IANA Considerations 349 IANA maintains a registry called "Border Gateway Protocol (BGP) 350 Parameters" with a sub-registry called "BGP Tunnel Encapsulation 351 Attribute Tunnel Types." The registration policy for this registry 352 is First-Come First-Served [RFC8126]. 354 IANA previously assigned the value 17 from this sub-registry for "SR 355 Tunnel", referencing this document. IANA is now requested to mark 356 that assignment as deprecated. IANA may reclaim that codepoint at 357 such a time that the registry is depleted. 359 8. Security Considerations 361 From a protocol point of view, the mechanisms described in this 362 document can leverage the security mechanisms already defined for 363 BGP. Further discussion of security considerations for BGP may be 364 found in the BGP specification itself [RFC4271] and in the security 365 analysis for BGP [RFC4272]. The original discussion of the use of 366 the TCP MD5 signature option to protect BGP sessions is found in 367 [RFC5925], while [RFC6952] includes an analysis of BGP keying and 368 authentication issues. 370 The mechanisms described in this document involve sharing routing or 371 reachability information between sites: that may mean disclosing 372 information that is normally contained within a site. So it needs to 373 be understood that normal security paradigms based on the boundaries 374 of sites are weakened and interception of BGP messages may result in 375 information being disclosed to third parties. Discussion of these 376 issues with respect to VPNs can be found in [RFC4364], while 377 [RFC7926] describes many of the issues associated with the exchange 378 of topology or TE information between sites. 380 Particular exposures resulting from this work include: 382 o Gateways to a site will know about all other gateways to the same 383 site. This feature applies within a site and so is not a 384 substantial exposure, but it does mean that if the BGP exchanges 385 within a site can be snooped or if a gateway can be subverted then 386 an attacker may learn the full set of gateways to a site. This 387 would facilitate more effective attacks on that site. 389 o The existence of multiple gateways to a site becomes more visible 390 across the backbone and even into remote sites. This means that 391 an attacker is able to prepare a more comprehensive attack than 392 exists when only the locally attached backbone network (e.g., the 393 AS that hosts the site) can see all of the gateways to a site. 394 For example, a Denial of Service attack on a single GW is 395 mitigated by the existence of other GWs, but if the attacker knows 396 about all the gateways then the whole set can be attacked at once. 398 o A node in a site that does not have external BGP peering (i.e., is 399 not really a site gateway and cannot speak BGP into the backbone 400 network) may be able to get itself advertised as a gateway by 401 letting other genuine gateways discover it (by speaking BGP to 402 them within the site) and so may get those genuine gateways to 403 advertise it as a gateway into the backbone network. This would 404 allow the malicious node to attract traffic without having to have 405 secure BGP peerings with out-of-site nodes. 407 o An external party intercepting BGP messages anywhere between sites 408 may learn information about the functioning of the sites and the 409 locations of end points. While this is not necessarily a 410 significant security or privacy risk, it is possible that the 411 disclosure of this information could be used by an attacker. 413 o If it is possible to modify a BGP message within the backbone, it 414 may be possible to spoof the existence of a gateway. This could 415 cause traffic to be attracted to a specific node and might result 416 in black-holing of traffic. 418 All of the issues in the list above could cause disruption to site 419 interconnection, but are not new protocol vulnerabilities so much as 420 new exposures of information that SHOULD be protected against using 421 existing protocol mechanisms such as securing the TCP sessions over 422 which the BGP messages flow. Furthermore, it is a general 423 observation that if these attacks are possible then it is highly 424 likely that far more significant attacks can be made on the routing 425 system. It should be noted that BGP peerings are not discovered, but 426 always arise from explicit configuration. 428 Given that the gateways and ASBRs are connected by tunnels that may 429 run across parts of the network that are not trusted, data center 430 operators using the approach set out in this network MUST consider 431 using gateway-to-gateway encryption to protect the data center 432 traffic. Additionally, due consideration MUST be given to encrypting 433 end-to-end traffic as it would be for any traffic that uses a public 434 or untrusted network for transport. 436 9. Manageability Considerations 438 The principal configuration item added by this solution is the 439 allocation of a site identifier. The same identifier MUST be 440 assigned to every GW to the same site, and each site MUST have a 441 different identifier. This requires coordination, probably through a 442 central management agent. 444 It should be noted that BGP peerings are not discovered, but always 445 arise from explicit configuration. This is no different from any 446 other BGP operation. 448 The site identifiers that are configured and carried in route targets 449 (see Section 3) are an important feature to ensure that all of the 450 gateways to a site discover each other. It is, therefore, important 451 that this value is not misconfigured since that would result in the 452 gateways not discovering each other and not advertising each other. 454 9.1. Relationship to Route Target Constraint 456 In order to limit the VPN routing information that is maintained at a 457 given route reflector, [RFC4364] suggests the use of "Cooperative 458 Route Filtering" [RFC5291] between route reflectors. [RFC4684] 459 defines an extension to that mechanism to include support for 460 multiple autonomous systems and asymmetric VPN topologies such as 461 hub-and-spoke. The mechanism in RFC 4684 is known as Route Target 462 Constraint (RTC). 464 An operator would not normally configure RTC by default for any AFI/ 465 SAFI combination, and would only enable it after careful 466 consideration. When using the mechanisms defined in this document, 467 the operator should consider carefully the effects of filtering 468 routes. In some cases this may be desirable, and in others it could 469 limit the effectiveness of the procedures. 471 10. Acknowledgements 473 Thanks to Bruno Rijsman, Stephane Litkowski, Boris Hassanov, Linda 474 Dunbar, Ravi Singh, and Daniel Migault for review comments, and to 475 Robert Raszuk for useful discussions. Gyan Mishra provided a helpful 476 GenArt review, and John Scudder and Benjamin Kaduk made helpful 477 comments during IESG review. 479 11. References 481 11.1. Normative References 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, 485 DOI 10.17487/RFC2119, March 1997, 486 . 488 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 489 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 490 DOI 10.17487/RFC4271, January 2006, 491 . 493 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 494 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 495 February 2006, . 497 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 498 "Multiprotocol Extensions for BGP-4", RFC 4760, 499 DOI 10.17487/RFC4760, January 2007, 500 . 502 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 503 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 504 June 2010, . 506 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 507 S. Ray, "North-Bound Distribution of Link-State and 508 Traffic Engineering (TE) Information Using BGP", RFC 7752, 509 DOI 10.17487/RFC7752, March 2016, 510 . 512 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 513 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 514 May 2017, . 516 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 517 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 518 DOI 10.17487/RFC9012, April 2021, 519 . 521 11.2. Informative References 523 [I-D.farrel-spring-sr-domain-interconnect] 524 Farrel, A. and J. Drake, "Interconnection of Segment 525 Routing Sites - Problem Statement and Solution Landscape", 526 draft-farrel-spring-sr-domain-interconnect-06 (work in 527 progress), May 2021. 529 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 530 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 531 and M. Chen, "BGP Link-State extensions for Segment 532 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-18 533 (work in progress), April 2021. 535 [I-D.ietf-idr-bgpls-segment-routing-epe] 536 Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, 537 S., and J. Dong, "BGP-LS extensions for Segment Routing 538 BGP Egress Peer Engineering", draft-ietf-idr-bgpls- 539 segment-routing-epe-19 (work in progress), May 2019. 541 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 542 RFC 4272, DOI 10.17487/RFC4272, January 2006, 543 . 545 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 546 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 547 2006, . 549 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 550 R., Patel, K., and J. Guichard, "Constrained Route 551 Distribution for Border Gateway Protocol/MultiProtocol 552 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 553 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 554 November 2006, . 556 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 557 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 558 August 2008, . 560 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 561 BGP, LDP, PCEP, and MSDP Issues According to the Keying 562 and Authentication for Routing Protocols (KARP) Design 563 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 564 . 566 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 567 "Advertisement of Multiple Paths in BGP", RFC 7911, 568 DOI 10.17487/RFC7911, July 2016, 569 . 571 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 572 Ceccarelli, D., and X. Zhang, "Problem Statement and 573 Architecture for Information Exchange between 574 Interconnected Traffic-Engineered Networks", BCP 206, 575 RFC 7926, DOI 10.17487/RFC7926, July 2016, 576 . 578 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 579 Writing an IANA Considerations Section in RFCs", BCP 26, 580 RFC 8126, DOI 10.17487/RFC8126, June 2017, 581 . 583 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 584 Decraene, B., Litkowski, S., and R. Shakir, "Segment 585 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 586 July 2018, . 588 Authors' Addresses 590 Adrian Farrel 591 Old Dog Consulting 593 Email: adrian@olddog.co.uk 595 John Drake 596 Juniper Networks 598 Email: jdrake@juniper.net 600 Eric Rosen 601 Juniper Networks 603 Email: erosen52@gmail.com 605 Keyur Patel 606 Arrcus, Inc. 608 Email: keyur@arrcus.com 610 Luay Jalil 611 Verizon 613 Email: luay.jalil@verizon.com