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