--- 1/draft-ietf-idr-as-migration-05.txt 2015-07-06 09:15:03.704866748 -0700 +++ 2/draft-ietf-idr-as-migration-06.txt 2015-07-06 09:15:03.744867717 -0700 @@ -1,20 +1,20 @@ Internet Engineering Task Force W. George Internet-Draft Time Warner Cable Updates: 4271 (if approved) S. Amante Intended status: Standards Track Apple, Inc. -Expires: October 30, 2015 April 28, 2015 +Expires: January 7, 2016 July 6, 2015 Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute - draft-ietf-idr-as-migration-05 + draft-ietf-idr-as-migration-06 Abstract This draft discusses some existing commonly-used BGP mechanisms for ASN migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work. Status of This Memo @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 30, 2015. + This Internet-Draft will expire on January 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,31 +53,31 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Documentation note . . . . . . . . . . . . . . . . . . . 3 2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3 3. External BGP Autonomous System Migration Mechanisms . . . . . 5 3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 5 3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8 4. Internal BGP Autonomous System Migration Mechanisms . . . . . 9 - 4.1. Internal BGP AS Migration . . . . . . . . . . . . . . . . 9 + 4.1. Internal BGP AS Migration . . . . . . . . . . . . . . . . 10 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 5. Additional Operational Considerations . . . . . . . . . . . . 13 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 - 9.2. Informative References . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Implementation report . . . . . . . . . . . . . . . 15 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction This draft discusses some existing commonly-used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 [RFC4271] protocol specification. These mechanisms are local to a given BGP Speaker and do not require negotiation with or cooperation of BGP neighbors. The deployment of these mechanisms do not need to interwork with one another to accomplish the desired results, so slight variations between existing vendor implementations @@ -236,30 +236,31 @@ [RFC4271] with a locally defined AS value for a specific BGP neighbor or group of neighbors. This mechanism allows the PE router that was formerly in ISP B to establish an eBGP session toward the existing CE devices using the legacy AS, AS 64510. Ultimately, the CE devices (i.e.: customer C) are completely unaware that ISP B has reconfigured its router to participate as a member of a new AS. Within the context of the former ISP B PE router, the second effect this specific mechanism has on AS_PATH is that, by default, it prepends all received BGP UPDATEs with the legacy AS of ISP B: AS 64510, while advertising it (Adj-RIB-Out) to other BGP speakers (A'). Within the - Loc-RIB on ISP B prior to the migration, the AS_PATH toward customer - C would appear as: 64510, whereas the same RIB on ISP A' (ISP B - routers post-migration) would contain AS_PATH: 64510 64496. + Loc-RIB on ISP B prior to the migration, the AS_PATH of route + announcements received from customer C would appear as: 64496, + whereas the same RIB on ISP A' (ISP B routers post-migration) would + contain AS_PATH: 64510 64496. A second instrument, referred to as "No Prepend Inbound", is enabled on PE routers migrating from ISP B. The "No Prepend Inbound" capability causes ISP B's routers to not prepend the legacy AS, AS 64510, when advertising UPDATES received from customer C. This - restores the AS_PATH within ISP A' toward customer C so that it is - just one ASN in length: 64496. + restores the AS_PATH within ISP A' for route announcements received + from customer C so that it is just one ASN in length: 64496. In the direction of CE -> PE (inbound): 1. "Local AS": Allows the local BGP router to generate a BGP OPEN to an eBGP neighbor with the old, legacy ASN value in the "My Autonomous System" field. When this capability is activated, it also causes the local router to prepend the value to the AS_PATH when installing or advertising routes received from a CE to iBGP neighbors inside the Autonomous System. @@ -284,21 +285,29 @@ Note: Direction of BGP UPDATE as per the arrows. Figure 3: Local AS and No Prepend BGP UPDATE Diagram As a result using both the "Local AS" and "No Prepend Inbound" capabilities on PE-B, CE-A will see an AS_PATH of: 64500 64496. CE-A will not receive a BGP UPDATE containing AS 64510 in the AS_PATH. (If only the "Local AS" mechanism was configured without "No Prepend Inbound" on PE-B, then CE-A would have seen an AS_PATH of: 64500 64510 64496, which results in an unacceptable lengthening of the - AS_PATH). + AS_PATH). NOTE: If there are still routers in the old ASN (64510), + it is possible for them to accept these manipulated routes (i.e. + those with 64510 removed from the AS_PATH by this command) as if they + have not already passed through their ASN, potentially causing a + loop, since BGP's normal loop-prevention behavior of rejecting routes + that include its ASN in the path will not catch these. Careful + filtering between routers remaining in the old ASN and routers + migrated to the new ASN is necessary to minimize the risk of routing + loops. 3.2. Modify Outbound BGP AS_PATH Attribute The two aforementioned mechanisms, "Local AS" and "No Prepend Inbound", only modify the AS_PATH Attribute received by the ISP's PE's in the course of processing BGP UPDATEs from CE devices when CE devices still have an eBGP session established with the ISPs legacy AS (AS64510). In some existing implementations, "Local AS" and "No Prepend Inbound" @@ -327,32 +336,23 @@ ISP A' ISP A' CE-A ---> PE-A -------------------> PE-B ---> CE-B 64499 New_ASN: 64500 Old_ASN: 64510 64496 New_ASN: 64500 Note: Direction of BGP UPDATE as per the arrows. Figure 4: Replace AS BGP UPDATE Diagram By default, without the use of "Replace Old AS", CE-B would see an - AS_PATH of: 64510 64500 64499, which is artificially lengthened, - typically by use of the "Local AS" and/or "No Prepend" capabilities - during the course of the ASN Migration. After ISP A' changes PE-B to - use "Replace Old AS", CE-B would receive an AS_PATH of: 64510 64499, - which is the same AS_PATH length pre-AS migration. NOTE: If there - are still routers in the old ASN, it is possible for them to accept - these manipulated routes as if they have not already passed through - their ASN, potentially causing a loop, since BGP's normal loop- - prevention behavior of rejecting routes that include its ASN in the - path will not catch these. Careful filtering between routers - remaining in the old ASN and routers migrated to the new ASN is - necessary to minimize the risk of routing loops. + AS_PATH of: 64510 64500 64499. After ISP A' changes PE-B to use + "Replace Old AS", CE-B would receive an AS_PATH of: 64510 64499, + which is the same AS_PATH length pre-AS migration. 3.3. Implementation The mechanisms introduced in this section MUST be configurable on a per-neighbor or per neighbor group (i.e. a group of similar BGP neighbor statements that reuse some common configuration to simplify provisioning) basis to allow for maximum flexibility. When the "Local AS" capability is used, a local ASN will be provided in the configuration that is different from the globally-configured ASN of the BGP router. To implement this mechanism, a BGP speaker SHOULD @@ -369,54 +369,61 @@ Implementations MAY support a more flexible model where the eBGP speaker attempts to open the BGP session using either the ASN configured as "Local AS" or the globally configured AS as discussed in BGP Alias (Section 4.2). If the session is successfully established to the globally configured ASN, then the modifications to AS_PATH described in this document SHOULD NOT be performed, as they are unnecessary. The benefit to this more flexible model is that it allows the remote neighbor to reconfigure to the new ASN without direct coordination between the ISP and the customer. + Note that this procedure will vary slightly if the locally or + globally configured ASN is a 4-octet ASN. See section 3 of + [RFC4893]. + When the BGP router receives UPDATEs from its eBGP neighbor configured with the "Local AS" mechanism, it processes the UPDATE as described in RFC4271 section 5.1.2 [RFC4271]. However the presence of a second ASN due to "Local AS" adds the following behavior to processing UPDATEs received from an eBGP neighbor configured with this mechanism: 1. Internal: the router SHOULD append the configured "Local AS" ASN in the AS_PATH attribute before installing the route or - advertising the UPDATE to an iBGP neighbor. + advertising the UPDATE to an iBGP neighbor. The decision of when + to append the ASN is an implementation detail outside the scope + of this document. Some considerations factoring into this + decision include consistency in the AS_PATH throughout the AS, + and implementation of the loop detection mechanism. 2. External: the BGP router SHOULD first append the globally configured ASN to the AS_PATH immediately followed by the "Local AS" value before advertising the UPDATE to an eBGP neighbor. Two options exist to manipulate the behavior of the basic "Local AS" mechanism. They modify the behavior as described below: 1. "No Prepend Inbound" - When the BGP router receives inbound BGP UPDATEs from its eBGP neighbor configured with this option, it MUST NOT append the "Local AS" ASN value in the AS_PATH attribute when installing the route or advertising that UPDATE to iBGP neighbors, but it MUST still append the globally configured ASN as normal when advertising the UPDATE to other local eBGP neighbors (i.e. those natively peering with the globally configured ASN). 2. "Replace Old AS", (outbound) - When the BGP router generates outbound BGP UPDATEs toward an eBGP neighbor configured with this - option, the BGP speaker MUST NOT (first) append the globally - configured ASN from the AS_PATH attribute. The BGP router MUST - append only the configured "Local AS" ASN value to the AS_PATH - attribute before sending the BGP UPDATEs outbound to the eBGP - neighbor. + option, the BGP speaker MUST NOT append the globally configured + ASN from the AS_PATH attribute. The BGP router MUST append only + the configured "Local AS" ASN value to the AS_PATH attribute + before sending the BGP UPDATEs outbound to the eBGP neighbor. 4. Internal BGP Autonomous System Migration Mechanisms The following section describes mechanisms that assist with a gradual and least service impacting migration of Internal BGP sessions from a legacy ASN to the permanently retained ASN. The following mechanism is very valuable to networks undergoing AS migration, but its use does not cause changes to the AS_PATH attribute. 4.1. Internal BGP AS Migration @@ -553,30 +561,34 @@ 4.2. Implementation The mechanism introduced in this section MUST be configurable on a per-neighbor or per neighbor group basis to allow for maximum flexibility. When configured with this mechanism, a BGP speaker MUST accept BGP OPEN and establish an iBGP session from configured iBGP peers if the ASN value in "My Autonomous System" is either the globally configured ASN or a locally configured ASN provided when this capability is utilized. Additionally, a BGP router configured with this mechanism MUST send its own BGP OPEN [RFC4271] (see section - 4.2) using both the globally configured and the locally configured - ASN in "My Autonomous System". To avoid potential deadlocks when two - BGP speakers are attempting to establish a BGP peering session and - are both configured with this mechanism, the speaker SHOULD send BGP - OPEN using the globally configured ASN first, and only send a BGP - OPEN using the locally configured ASN as a fallback if the remote - neighbor responds with the BGP error "Bad Peer AS". In each case, - the BGP speaker MUST treat UPDATEs sent and received to this peer as - if this was a natively configured iBGP session, as defined by - [RFC4271] and [RFC4456]. + 4.2) using either the globally configured or the locally configured + ASN in "My Autonomous System" as follows. To avoid potential + deadlocks when two BGP speakers are attempting to establish a BGP + peering session and are both configured with this mechanism, the + speaker SHOULD send BGP OPEN using the globally configured ASN first, + and only send a BGP OPEN using the locally configured ASN as a + fallback if the remote neighbor responds with the BGP error "Bad Peer + AS". In each case, the BGP speaker MUST treat UPDATEs sent and + received to this peer as if this was a natively configured iBGP + session, as defined by [RFC4271] and [RFC4456]. + + Note that this procedure will vary slightly if the locally or + globally configured ASN is a 4-octet ASN. See section 3 of + [RFC4893]. 5. Additional Operational Considerations This document describes several mechanisms to support ISPs and other organizations that need to perform ASN migrations. Other variations of these mechanisms may exist, for example, in legacy router software that has not been upgraded or reached End of Life, but continues to operate in the network. Such variations are beyond the scope of this document. @@ -627,22 +639,22 @@ of routers within a single network, standard security measures should be taken to restrict access to the management interface(s) of routers that implement these mechanisms. Additionally, BGP sessions SHOULD be protected using TCP Authentication Option [RFC5925] and the Generalized TTL Security Mechanism [RFC5082] 8. Acknowledgements Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson, David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan - Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, and Alvaro Retana - for their comments. + Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, Alvaro Retana, and + John Scudder for their comments. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. @@ -662,20 +674,23 @@ Configuration for Network AS Migrations", 2003, . [JUNIPER] Juniper Networks, Inc., "Configuring the BGP Local Autonomous System Attribute", 2012, . + [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS + Number Space", RFC 4893, May 2007. + [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, August 2007. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, October 2007. [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, December 2008.