doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7705.txt b/doc/rfc/rfc7705.txt
new file mode 100644
index 0000000..0be764a
--- /dev/null
+++ b/doc/rfc/rfc7705.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         W. George
+Request for Comments: 7705                             Time Warner Cable
+Updates: 4271                                                  S. Amante
+Category: Standards Track                                    Apple, Inc.
+ISSN: 2070-1721                                            November 2015
+
+
+                 Autonomous System Migration Mechanisms
+             and Their Effects on the BGP AS_PATH Attribute
+
+Abstract
+
+   This document discusses some existing commonly used BGP mechanisms
+   for Autonomous System Number (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
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7705.
+
+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
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+George & Amante              Standards Track                    [Page 1]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+Table of Contents
+
+   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 . . . . . . . . . . . . . . . .  10
+     4.2.  Implementation  . . . . . . . . . . . . . . . . . . . . .  12
+   5.  Additional Operational Considerations . . . . . . . . . . . .  13
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
+   Appendix A.  Implementation Report  . . . . . . . . . . . . . . .  16
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+
+1.  Introduction
+
+   This document 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
+   exist and will not necessarily be harmonized due to this document.
+   However, it is necessary to document these de facto standards to
+   ensure that new implementations can be successful, and any future
+   protocol enhancements to BGP that propose to read, copy, manipulate,
+   or compare the AS_PATH attribute can do so without inhibiting the use
+   of these very widely used ASN migration mechanisms.
+
+   The migration mechanisms discussed here are useful to ISPs and
+   organizations of all sizes, but it is important to understand the
+   business need for these mechanisms and illustrate why they are so
+   critical for ISPs' operations.  During a merger, acquisition, or
+   divestiture involving two organizations it is necessary to seamlessly
+   migrate both internal and external BGP speakers from one ASN to a
+   second ASN.  The overall goal in doing so is to simplify operations
+   through consistent configurations across all BGP speakers in the
+   combined network.  In addition, given that the BGP Path Selection
+   algorithm selects routes with the shortest AS_PATH attribute, it is
+
+
+
+George & Amante              Standards Track                    [Page 2]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   critical that the ISP does not increase AS_PATH length during or
+   after ASN migration, because an increased AS_PATH length would likely
+   result in sudden, undesirable changes in traffic-patterns in the
+   network.
+
+   By default, the BGP protocol requires an operator to configure a
+   router to use a single remote ASN for the BGP neighbor, and the ASN
+   must match on both ends of the peering in order to successfully
+   negotiate and establish a BGP session.  Prior to the existence of
+   these migration mechanisms, it would have required an ISP to
+   coordinate an ASN change with, in some cases, tens of thousands of
+   customers.  In particular, as each router is migrated to the new ASN,
+   to avoid an outage due to ASN mismatch, the ISP would have to force
+   all customers on that router to change their router configurations to
+   use the new ASN immediately after the ASN change.  Thus, it was
+   critical to define a more asymmetric migration method so that the ISP
+   could seamlessly change the ASN within its network(s) but allow the
+   customers to gradually migrate to the ISP's new ASN when convenient.
+   These customer migrations could occur either by coordinating
+   individual session reconfigurations or, to allow for truly asymmetric
+   migration, by accepting sessions using either the old or new ASN.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.2.  Documentation Note
+
+   This document uses Autonomous System Numbers (ASNs) from the range
+   reserved for documentation as described in RFC 5398 [RFC5398].  In
+   the examples used here, they are intended to represent Globally
+   Unique ASNs, not private use ASNs as documented in Section 5 of RFC
+   6996 [RFC6996].
+
+2.  ASN Migration Scenario Overview
+
+   The use case being discussed here is an ISP merging two or more ASNs,
+   where eventually one ASN subsumes the other(s).  In this use case, we
+   will assume the most common case where there are two ISPs, A and B,
+   that prior to the ASN migration use AS 64500 and 64510, respectively.
+   AS 64500 will be the permanently retained ASN used across the
+   consolidated set of both ISPs network equipment, and AS 64510 will be
+   retired.  Thus, at the conclusion of the ASN migration, there will be
+   a single ISP A' with all internal BGP speakers configured to use AS
+   64500.  To all external BGP speakers, the AS_PATH length will not be
+   increased.
+
+
+
+George & Amante              Standards Track                    [Page 3]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   In this same scenario, AS 64496 and AS 64499 represent two separate
+   customer networks: C and D, respectively.  Originally, customer C (AS
+   64496) is attached to ISP B, which will undergo ASN migration from AS
+   64510 to AS 64500.  Furthermore, customer D (AS 64499) is attached to
+   ISP A, which does not undergo ASN migration since the ASN for ISP A
+   will remain constant, (AS 64500).  Although this example refers to AS
+   64496 and 64499 as customer networks, either or both may be
+   settlement-free or other types of peers.  In this use case, they are
+   referred to as "customers" merely for convenience.
+
+         ------                  ------
+       / ISP  A \              / ISP  B \
+      | AS 64500 |            | AS 64510 |
+       \        /              \        /
+        -------                 -------
+           |                       |
+           |                       |
+     ------------             -------------
+     |  Cust D  |             |  Cust C   |
+     | AS 64499 |             | AS 64496  |
+     ------------             -------------
+
+                        Figure 1: Before Migration
+
+                ---------------
+              /                \
+             |     ISP A'       |
+             |     AS 64500     |
+              \                /
+                ---------------
+             /                  \
+           /                      \
+          |                         |
+     ------------             -------------
+     |  Cust D  |             |  Cust C   |
+     | AS 64499 |             | AS 64496  |
+     ------------             -------------
+
+                         Figure 2: After Migration
+
+   The general order of operations, typically carried out in a single
+   maintenance window by the network undergoing ASN migration (ISP B),
+   is as follows.  First, ISP B will change the global BGP ASN used by a
+   Provider Edge (PE) router, from ASN 64510 to 64500.  At this point,
+   the router will no longer be able to establish External BGP (eBGP)
+   sessions toward the existing Customer Edge (CE) devices that are
+   attached to it and still using AS 64510.  Second, since ISP B needs
+   to do this without coordinating the simultaneous change of its ASN
+
+
+
+George & Amante              Standards Track                    [Page 4]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   with all of its eBGP peers, ISP B will configure two separate, but
+   related ASN migration mechanisms discussed in this document on all
+   eBGP sessions toward all CE devices.  These mechanisms enable the
+   router to establish BGP neighbors using the legacy ASN, modify the
+   AS_PATH attribute received from a CE device when advertising it
+   further, and modify AS_PATH when transmitted toward CE devices to
+   achieve the desired effect of not increasing the length of the
+   AS_PATH.
+
+   At the conclusion of the ASN migration, the CE devices at the edge of
+   the network are not aware of the fact that their upstream router is
+   now in a new ASN and do not observe any change in the length of the
+   AS_PATH attribute.  However, after the changes discussed in this
+   document are put in place by ISP A', there is a change to the
+   contents of the AS_PATH attribute to ensure the AS_PATH is not
+   artificially lengthened while these AS migration parameters are used.
+
+   In this use case, neither ISP is using BGP Confederations [RFC5065]
+   internally.
+
+3.  External BGP Autonomous System Migration Mechanisms
+
+   The following section addresses optional capabilities that are
+   specific to modifying the AS_PATH attribute at the Autonomous System
+   Border Routers (ASBRs) of an organization (typically a single Service
+   Provider).  This ensures that external BGP customers/peers are not
+   forced to make any configuration changes on their CE routers before
+   or during the exact time the Service Provider wishes to migrate to a
+   new, permanently retained ASN.  Furthermore, these mechanisms
+   eliminate the artificial lengthening of the AS_PATH both transmitted
+   from and received by the Service Provider that is undergoing AS
+   Migration, which would have negative implications on path selection
+   by external networks.
+
+3.1.  Modify Inbound BGP AS_PATH Attribute
+
+   The first instrument used in the process described above is called
+   "Local AS".  This allows the router to supersede the globally
+   configured ASN in the "My Autonomous System" field of the BGP OPEN
+   [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 --
+
+
+
+George & Amante              Standards Track                    [Page 5]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   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 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.
+
+   The 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' 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 <old_ASN> value to
+       the AS_PATH when installing or advertising routes received from a
+       CE to Internal BGP (iBGP) neighbors inside the Autonomous System.
+
+   2.  "No Prepend Inbound (of Local AS)": The local BGP router does not
+       prepend the <old_ASN> value to the AS_PATH when installing or
+       advertising routes received from the CE to iBGP neighbors inside
+       the Autonomous System
+
+   PE-B is a PE that was originally in ISP B, and has a customer eBGP
+   session to CE-B.  PE-B has had its global configuration ASN changed
+   from AS 64510 to AS 64500 to make it part of the permanently retained
+   ASN.  This now makes PE-B a member of ISP A'.  PE-A is a PE that was
+   originally in ISP A, and has a customer peer CE-A.  Although its
+   global configuration ASN remains AS 64500, throughout this exercise
+   we also consider PE-A a member of ISP A'.
+
+                    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 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
+
+
+
+George & Amante              Standards Track                    [Page 6]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   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).
+   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 PEs
+   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"
+   do not concurrently modify the AS_PATH attribute for BGP UPDATEs that
+   are transmitted by the ISP's PEs to CE devices.  In these
+   implementations, with "Local AS" and "No Prepend Inbound" used on
+   PE-B, there is an automatic lengthening of the AS_PATH in outbound
+   BGP UPDATEs from ISP A' toward directly attached eBGP speakers
+   (customer C in AS 64496).  The externally observed result is that
+   customer C in AS 64496 will receive the following AS_PATH: 64510
+   64500 64499.  Therefore, if ISP A' takes no further action, there
+   will be an unacceptable increase in the AS_PATH length within the
+   customer's networks directly attached to ISP A'.
+
+   A tertiary mechanism, referred to as "Replace Old AS", is used to
+   resolve this problem.  This capability allows ISP A' to prevent
+   routers from appending the globally configured ASN in outbound BGP
+   UPDATEs toward directly attached eBGP neighbors that are using the
+   "Local AS" mechanism.  Instead, only the old (or previously used) AS
+   will be prepended in the outbound BGP UPDATE toward the customer's
+   network, restoring the AS_PATH length to what it what was before AS
+   Migration occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+George & Amante              Standards Track                    [Page 7]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   To reuse the above diagram, but in the opposite direction, we have:
+
+                         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.  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 basis to allow for maximum
+   flexibility.  (Here, "neighbor group" refers to a group of similar
+   BGP neighbor statements that reuse some common configuration to
+   simplify provisioning.)  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 send BGP OPEN [RFC4271] (see
+   Section 4.2) messages to the configured eBGP peer(s) using the local
+   ASN configured for this session as the value sent in "My Autonomous
+   System".  The BGP router SHOULD NOT use the ASN configured globally
+   within the BGP process as the value sent in "My Autonomous System" in
+   the OPEN message.  This prevents causing the eBGP neighbor to
+   unnecessarily generate a BGP OPEN Error message "Bad Peer AS".  This
+   method is typically used to re-establish eBGP sessions with peers
+   expecting the legacy ASN after a router has been moved to a new ASN.
+
+   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
+   [RFC6793].
+
+
+
+George & Amante              Standards Track                    [Page 8]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   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.  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 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.
+
+
+
+
+
+
+George & Amante              Standards Track                    [Page 9]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+4.1.  Internal BGP AS Migration
+
+   In this case, all of the routers to be consolidated into a single,
+   permanently retained ASN are under the administrative control of a
+   single entity.  Unfortunately, the traditional method of migrating
+   all Internal BGP speakers, particularly within larger networks, is
+   both time-consuming and widely service impacting.
+
+   The traditional method to migrate Internal BGP sessions was strictly
+   limited to reconfiguration of the global configuration ASN and,
+   concurrently, changing all iBGP neighbors' remote ASN from the legacy
+   ASN to the new, permanently retained ASN on each router within the
+   legacy AS.  These changes can be challenging to swiftly execute in
+   networks with more than a few dozen internal BGP routers.  There are
+   also the concomitant service interruptions as these changes are made
+   to routers within the network, resulting in a reset of iBGP sessions
+   and subsequent route reconvergence to reestablish optimal routing
+   paths.  Operators often cannot make such sweeping changes given the
+   associated risks of a highly visible service interruption; rather,
+   they require a more gradual method to migrate Internal BGP sessions,
+   from one ASN to a second, permanently retained ASN, that is not
+   visibly service impacting to its customers.
+
+   With the "Internal BGP AS Migration" mechanism described herein, it
+   allows an Internal BGP speaker to form a single iBGP session using
+   either the old, legacy ASN or the new, permanently retained ASN.  The
+   benefits of using this mechanism are several fold.  First, it allows
+   for a more gradual and less service-impacting migration away from the
+   legacy ASN to the permanently retained ASN.  Second, it (temporarily)
+   permits the coexistence of the legacy and permanently retained ASN
+   within a single network, allowing for uniform BGP path selection
+   among all routers within the consolidated network.
+
+   The iBGP router with the "Internal BGP AS Migration" capability
+   enabled allows the receipt of a BGP OPEN message with either the
+   legacy ASN value or the new, globally configured ASN value in the "My
+   Autonomous System" field of the BGP OPEN message from iBGP neighbors.
+   It is important to recognize that enablement of the "Internal BGP AS
+   Migration" mechanism preserves the semantics of a regular iBGP
+   session (i.e., using identical ASNs).  Thus, the BGP attributes
+   transmitted by and the acceptable methods of operation on BGP
+   attributes received from iBGP sessions configured with "Internal BGP
+   AS Migration" capability are no different than those exchanged across
+   an iBGP session without "Internal BGP AS Migration" configured, as
+   defined by [RFC4271] and [RFC4456].
+
+
+
+
+
+
+George & Amante              Standards Track                   [Page 10]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   Typically, in medium to large networks, BGP Route Reflectors (RRs)
+   [RFC4456] are used to aid in reduction of configuration of iBGP
+   sessions and scalability with respect to overall TCP (and BGP)
+   session maintenance between adjacent iBGP routers.  Furthermore, BGP
+   Route Reflectors are typically deployed in pairs within a single
+   Route Reflection cluster to ensure high reliability of the BGP
+   Control Plane.  As such, the following example will use Route
+   Reflectors to aid in understanding the use of the "Internal BGP AS
+   Migration" mechanism.  Note that Route Reflectors are not a
+   prerequisite to enable "Internal BGP AS Migration" and this mechanism
+   can be enabled independent of the use of Route Reflectors.
+
+   The general order of operations is as follows:
+
+   1.  Within the legacy network, (the routers comprising the set of
+       devices that still have a globally configured legacy ASN), one
+       member of a redundant pair of RRs has its global configuration
+       ASN changed to the permanently retained ASN.  Concurrently, the
+       "Internal BGP AS Migration" capability is enabled on all iBGP
+       sessions on that device.  This will comprise Non-Client iBGP
+       sessions to other RRs as well as Client iBGP sessions, typically
+       to PE devices, both still utilizing the legacy ASN.  Note that
+       during this step there will be a reset and reconvergence event on
+       all iBGP sessions on the RRs whose configuration was modified;
+       however, this should not be service impacting due to the use of
+       redundant RRs in each RR Cluster.
+
+   2.  The above step is repeated for the other side of the redundant
+       pair of RRs.  The one alteration to the above procedure is that
+       the "Internal BGP AS Migration" mechanism is now removed from the
+       Non-Client iBGP sessions toward the other (previously
+       reconfigured) RRs, since it is no longer needed.  The "Internal
+       BGP AS Migration" mechanism is still required on all RRs for all
+       RR Client iBGP sessions.  Also during this step, there will be a
+       reset and reconvergence event on all iBGP sessions whose
+       configuration was modified, but this should not be service
+       impacting.  At the conclusion of this step, all RRs will have
+       their globally configured ASN set to the permanently retained ASN
+       and "Internal BGP AS Migration" enabled and in use toward RR
+       Clients.
+
+   3.  At this point, the network administrators would then be able to
+       establish iBGP sessions between all Route Reflectors in both the
+       legacy and permanently retained networks.  This would allow the
+       network to appear to function, both internally and externally, as
+       a single, consolidated network using the permanently retained
+       network.
+
+
+
+
+George & Amante              Standards Track                   [Page 11]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   4.  To complete the AS migration, each RR Client (PE) in the legacy
+       network still utilizing the legacy ASN is now modified.
+       Specifically, each legacy PE would have its globally configured
+       ASN changed to use the permanently retained ASN.  The ASN
+       configured within the PE for the iBGP sessions toward each RR
+       would be changed to use the permanently retained ASN.  It is
+       unnecessary to enable the "Internal BGP AS Migration" mechanism
+       on these migrated iBGP sessions.  During the same maintenance
+       window, External BGP sessions would be modified to include the
+       above "Local AS", "No Prepend", and "Replace Old AS" mechanisms
+       described in Section 3 above, since all of the changes are
+       service interrupting to the eBGP sessions of the PE.  At this
+       point, all PEs will have been migrated to the permanently
+       retained ASN.
+
+   5.  The final step is to excise the "Internal BGP AS Migration"
+       configuration from the Router Reflectors in an orderly fashion.
+       After this is complete, all routers in the network will be using
+       the new, permanently retained ASN for all iBGP sessions with no
+       vestiges of the legacy ASN on any iBGP sessions.
+
+   The benefit of using the aforementioned "Internal BGP AS Migration"
+   capability is that it is a more gradual and less externally service
+   impacting change to accomplish an AS migration.  Previously, without
+   "Internal BGP AS Migration", such an AS migration change would carry
+   a high risk and need to be successfully accomplished in a very short
+   time frame (e.g., at most several hours).  In addition, it would
+   likely cause substantial routing churn and rapid fluctuations in
+   traffic carried -- potentially causing periods of congestion and
+   resultant packet loss -- during the period when the configuration
+   changes are underway to complete the AS Migration.  On the other
+   hand, with "Internal BGP AS Migration", the migration from the legacy
+   ASN to the permanently retained ASN can occur over a period of days
+   or weeks with reduced customer disruption.  (The only observable
+   service disruption should be when each PE undergoes the changes
+   discussed in step 4 above.)
+
+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 either the globally configured or the locally
+
+
+
+George & Amante              Standards Track                   [Page 12]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   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
+   [RFC6793].
+
+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.
+
+   Companies routinely go through periods of mergers, acquisitions, and
+   divestitures, which in the case of the former cause them to
+   accumulate several legacy ASNs over time.  ISPs often do not have
+   control over the configuration of customers' devices (i.e., the ISPs
+   are often not providing a managed CE router service, particularly to
+   medium and large customers that require eBGP).  Furthermore, ISPs are
+   using methods to perform ASN migration that do not require
+   coordination with customers.  Ultimately, this means there is not a
+   finite period of time after which legacy ASNs will be completely
+   expunged from the ISP's network.  In fact, it is common that legacy
+   ASNs and the associated External BGP AS Migration mechanisms
+   discussed in this document can and do persist for several years, if
+   not longer.  Thus, it is prudent to plan that legacy ASNs and
+   associated External BGP AS Migration mechanisms will persist in an
+   operational network indefinitely.
+
+   With respect to the Internal BGP AS Migration mechanism, all of the
+   routers to be consolidated into a single, permanently retained ASN
+   are under the administrative control of a single entity.  Thus,
+   completing the migration from iBGP sessions using the legacy ASN to
+   the permanently retained ASN is more straightforward and could be
+   accomplished in a matter of days to months.  Finally, good
+   operational hygiene would dictate that it is good practice to avoid
+   using "Internal BGP AS Migration" capability over a long period of
+   time for reasons of not only operational simplicity of the network,
+
+
+
+George & Amante              Standards Track                   [Page 13]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   but also reduced reliance on that mechanism during the ongoing life
+   cycle management of software, features, and configurations that are
+   maintained on the network.
+
+6.  Security Considerations
+
+   This document discusses a process by which one ASN is migrated into
+   and subsumed by another.  This involves manipulating the AS_PATH
+   attribute with the intent of not increasing the AS_PATH length, which
+   would typically cause the BGP route to no longer be selected by BGP's
+   Path Selection Algorithm in others' networks.  This could result in
+   sudden and unexpected shifts in traffic patterns in the network,
+   potentially resulting in congestion.
+
+   Given that these mechanisms can only be enabled through configuration
+   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]
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+              DOI 10.17487/RFC4271, January 2006,
+              <http://www.rfc-editor.org/info/rfc4271>.
+
+   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
+              Reflection: An Alternative to Full Mesh Internal BGP
+              (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
+              <http://www.rfc-editor.org/info/rfc4456>.
+
+7.2.  Informative References
+
+   [ALU]      Alcatel-Lucent, "BGP Local AS attribute", 2006-2012,
+              <https://infoproducts.alcatel-lucent.com/html/0_add-h-f/
+              93-0074-10-01/7750_SR_OS_Routing_Protocols_Guide/
+              BGP-CLI.html#709567>.
+
+
+
+
+
+George & Amante              Standards Track                   [Page 14]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+   [CISCO]    Cisco Systems, Inc., "BGP Support for Dual AS
+              Configuration for Network AS Migrations", 2013,
+              <http://www.cisco.com/c/en/us/td/docs/ios-xml/
+              ios/iproute_bgp/configuration/xe-3s/asr1000/
+              irg-xe-3s-asr1000-book/irg-dual-as.html>.
+
+   [JUNIPER]  Juniper Networks, Inc., "Understanding the BGP Local AS
+              Attribute", December 2013,
+              <http://www.juniper.net/techpubs/en_US/junos13.3/topics/
+              concept/bgp-local-as-introduction.html>.
+
+   [RFC5065]  Traina, P., McPherson, D., and J. Scudder, "Autonomous
+              System Confederations for BGP", RFC 5065,
+              DOI 10.17487/RFC5065, August 2007,
+              <http://www.rfc-editor.org/info/rfc5065>.
+
+   [RFC5082]  Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
+              Pignataro, "The Generalized TTL Security Mechanism
+              (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
+              <http://www.rfc-editor.org/info/rfc5082>.
+
+   [RFC5398]  Huston, G., "Autonomous System (AS) Number Reservation for
+              Documentation Use", RFC 5398, DOI 10.17487/RFC5398,
+              December 2008, <http://www.rfc-editor.org/info/rfc5398>.
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
+              June 2010, <http://www.rfc-editor.org/info/rfc5925>.
+
+   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
+              Autonomous System (AS) Number Space", RFC 6793,
+              DOI 10.17487/RFC6793, December 2012,
+              <http://www.rfc-editor.org/info/rfc6793>.
+
+   [RFC6996]  Mitchell, J., "Autonomous System (AS) Reservation for
+              Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July
+              2013, <http://www.rfc-editor.org/info/rfc6996>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+George & Amante              Standards Track                   [Page 15]
+
+RFC 7705                  AS Migration Features            November 2015
+
+
+Appendix A.  Implementation Report
+
+   As noted elsewhere in this document, this set of migration mechanisms
+   has multiple existing implementations in wide use.
+
+   o  Cisco [CISCO]
+
+   o  Juniper [JUNIPER]
+
+   o  Alcatel-Lucent [ALU]
+
+   This is not intended to be an exhaustive list, as equivalent features
+   do exist in other implementations; however, the authors were unable
+   to find publicly available documentation of the vendor-specific
+   implementation to reference.
+
+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, Alvaro Retana, and
+   John Scudder for their comments.
+
+Authors' Addresses
+
+   Wesley George
+   Time Warner Cable
+   13820 Sunrise Valley Drive
+   Herndon, VA  20171
+   United States
+
+   Phone: +1 703-561-2540
+   Email: wesley.george@twcable.com
+
+
+   Shane Amante
+   Apple, Inc.
+   1 Infinite Loop
+   Cupertino, CA  95014
+   United States
+
+   Email: amante@apple.com
+
+
+
+
+
+
+
+
+
+George & Amante              Standards Track                   [Page 16]
+