Internet Engineering Task Force                                W. George
Internet-Draft                                         Time Warner Cable
Intended status: Standards Track                               S. Amante
Expires: April 2, October 11, 2015                                    Apple, Inc.
                                                      September 29, 2014
                                                           April 9, 2015

  Autonomous System Migration Features Mechanisms and Their Effects on the BGP
                           AS_PATH Attribute
                     draft-ietf-idr-as-migration-03
                     draft-ietf-idr-as-migration-04

Abstract

   This draft discusses some commonly-used BGP features mechanisms for ASN
   migration that, while
   commonly used, that are not formally part of the BGP4 protocol
   specification and may be vendor-specific in exact implementation.  It
   is necessary to document these de facto standards to ensure that they
   are properly supported in future BGP protocol work such as BGPSec. work.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 April 2, October 11, 2015.

Copyright Notice

   Copyright (c) 2014 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Documentation note  . . . . . . . . . . . . . . . . . . .   3
   2.  ASN Migration Scenario Overview . . . . . . . . . . . . . . .   4   3
   3.  External BGP Autonomous System Migration Features Mechanisms . . . . . .   6   5
     3.1.  Modify Inbound BGP AS_PATH Attribute  . . . . . . . . . .   6   5
     3.2.  Modify Outbound BGP AS_PATH Attribute . . . . . . . . . .   7
     3.3.  Implementation  . . . . . . . . . . . . . . . . . . . . .   8
   4.  Internal BGP Autonomous System Migration Features . Mechanisms . . . . .   9
     4.1.  Internal BGP Alias  . . . . . . . . . . . . . . . . . . .  10   9
     4.2.  Implementation  . . . . . . . . . . . . . . . . . . . . .  12
   5.  Additional Operational Considerations . . . . . . . . . . . .  13
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   8.  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   10.
   9.  Appendix: Implementation report . . . . . . . . . . . . . . .  15
   11.  14
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16  15

1.  Introduction

   This draft discusses some commonly-used BGP features mechanisms for ASN Autonomous
   System Number (ASN) migration that, while
   commonly used, that are not formally part of the BGP4
   [RFC4271] protocol specification and may be vendor-specific in exact
   implementation.  These features mechanisms are local to a given BGP Speaker
   and do not require negotiation with or cooperation of BGP neighbors.
   The deployment of these features 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 features. mechanisms.

   The migration features mechanisms discussed here are useful to ISPs and
   organizations of all sizes, but it is important to understand the
   business need for these features 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, it is common practice in the industry
   for ISPs to bill customers based on utilization.  ISPs bill customers
   based on the 95th percentile of the greater of the traffic sent or
   received, over the course of a 1-month period, on the customer's
   access circuit.  Given given that the BGP Path Selection
   algorithm selects routes with the shortest AS_PATH attribute, it is
   critical that the ISP does not increase AS_PATH length during or
   after ASN migration
   toward downstream transit customers or settlement-free peers, who are
   likely sending or receiving traffic from those transit customers.
   This migration, because an increased AS_PATH length would not only likely
   result in sudden sudden, undesirable changes in traffic patterns in the network, but also substantially decrease utilization driven
   revenue at the ISP.
   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 features, 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 becomes
   critical to allow the ISP to make this process a bit more asymmetric,
   so that it could seamlessly migrate the ASN within its network(s),
   but allow the customers to gradually migrate to the ISP's new ASN at
   their leisure, either by coordinating individual reconfigurations, or
   accepting sessions using either the old or new ASN to allow for truly
   asymmetric migration.

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 draft 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 RFC 6996 [RFC6996]
   section 5.

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.

   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),
   are 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 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 with all of its eBGP
   peers, ISP B will configure two separate, but related ASN migration
   features
   mechanisms discussed in this document on all eBGP sessions toward all
   CE devices.  These features 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 RFC 5065
   [RFC5065] internally.

   There are multiple implementations with equivalent features deployed
   and in use.  Some documentation pointers to these implementations, as
   well as additional documentation on migration scenarios can be found
   in the appendix.  The examples cited below use Cisco IOS CLI for ease
   of illustration purposes only.

3.  External BGP Autonomous System Migration Features Mechanisms

   The following section addresses features 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 features
   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 feature instrument used in the process described above is called
   "Local AS".  This feature 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, usually configured on a
   per-neighbor basis.  This mechanism allows the PE router that was
   formerly in ISP B to re-establish 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 feature
   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) (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.  To avoid changes

   A second instrument, referred to the AS_PATH
   length, a secondary feature as "No Prepend" Prepend Inbound", is added to the "Local AS"
   configuration toward every eBGP neighbor enabled
   on PE routers migrating from ISP B.  The "No Prepend" feature Prepend Inbound"
   capability causes those 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.

   In the direction of CE -> PE (inbound):

   1.  'local-as <old_ASN>': prepends  "Local AS": Allows the <old_ASN> value local BGP router to generate a BGP OPEN to
       an eBGP neighbor with the AS_PATH
       when advertising routes received from old, legacy ASN value in the "My
       Autonomous System" field.  When this capability is activated, it
       also causes the local router to prepend the CE

   2.  'local-as <old_ASN> no-prepend': value to
       the AS_PATH when advertising routes received from a CE to iBGP
       neighbors inside the Autonomous System.

   2.  "No Prepend Inbound (of Local AS)": the local BGP router does not
       prepend <old_ASN> value to the AS_PATH when 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 peer 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

   The final configuration on PE-B after completing the "Local AS"
   portion of the AS migration is as follows:

   router bgp 64500
        neighbor <CE-B_IP> remote-as 64496
        neighbor <CE-B_IP> local-as 64510 no-prepend

   As a result of using both the "Local AS No Prepend" configuration, 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
   64510" feature "Local AS" mechanism was configured without the keyword "no-prepend" "No Prepend
   Inbound" on PE-
   B, PE-B, then CE-A would see have seen an AS_PATH of: 64496
   64510 64500, which results in an unacceptable lengthening of the
   AS_PATH).

3.2.  Modify Outbound BGP AS_PATH Attribute

   The previous feature, two aforementioned mechanisms, "Local AS No Prepend", was designed to AS" and "No Prepend
   Inbound", only modify the AS_PATH Attribute received by the ISP ISP's
   PE's in updates the course of processing BGP UPDATEs from CE devices, devices when CE
   devices still have an eBGP session established with the ISPs legacy
   AS, (AS64510).

   In some existing implementations, "Local AS No
   Prepend" AS" and "No Prepend Inbound"
   does not concurrently modify the AS_PATH Attribute for BGP UPDATEs
   that are transmitted by the ISP ISP's PE's to CE devices.  Specifically,  In these
   implementations, with "Local AS No Prepend" enabled AS" and "No Prepend Inbound" used on PE-B, PE-
   B, it automatically causes a lengthening of the AS_PATH in outbound
   BGP UPDATEs from ISP A' toward directly attached eBGP speakers,
   (Customer C in AS 64496).  This is
   the result of the "Local AS No Prepend" feature automatically
   appending the new global configuration ASN, AS64500, after the legacy
   ASN, AS64510, in BGP UPDATEs that are transmitted by PE-B to CE-B.  The end 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, it will
   cause an unacceptable increase in AS_PATH length within customer's
   networks directly attached to ISP A'.

   A second feature was designed tertiary mechanism is used to resolve this problem (continuing the
   use of Cisco CLI in the examples, it is called problem, referred to as
   "Replace AS" in the
   examples below). Old AS".  This feature capability allows ISP A' to prevent routers
   configured with this feature
   from appending the global globally configured AS ASN in outbound BGP UPDATEs
   toward its customer's networks configured
   with directly attached eBGP neighbors that are using the "Local AS" feature.
   mechanism.  Instead, only the historical old (or
   legacy) 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.

   To re-use 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

   The final configuration on PE-B after completing the "Replace AS"
   portion of the AS migration is as follows:

   router bgp 64500
        neighbor <CE-B_IP> remote-as 64496
        neighbor <CE-B_IP> local-as 64510 no-prepend replace-as

   By default, without the use of "Replace AS" enabled, Old AS", CE-B would see an
   AS_PATH of: 64510 64500 64499, which is artificially lengthened 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 include the
   use "Replace AS"
   feature, 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

   While  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.

3.3.  Implementation

   While multiple implementations already exist, the following should
   document documents
   the expected behavior such that a new implementation of this
   feature
   mechanism could be done on other platforms.

   These features mechanisms MUST be configurable on a per-neighbor or per peer-
   group basis to allow for maximum flexibility.  When this feature set the "Local AS"
   capability is invoked, an used, a local ASN will be provided in the configuration
   that is different from the globally-configured ASN
   is provided as a part of the command as exemplified above. BGP router.
   To implement this feature, mechanism, a BGP speaker MUST send BGP OPEN
   [RFC4271] (see section 4.2) messages to the configured eBGP peer peer(s)
   using the local ASN configured for this session as the value sent in MY ASN.
   "My Autonomous System".  The speaker BGP router MUST NOT use the ASN
   configured globally within the BGP process as the value sent in MY
   ASN "My
   Autonomous System" in the OPEN message.  This will avoid causing the
   eBGP neighbor to unnecessarily generate a BGP OPEN Error message
   BAD PEER AS, and "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.  Additionally, when

   Implementations MAY support a more flexible model where the BGP eBGP
   speaker configured with this feature
   receives updates from its neighbor, it MUST process attempts to open the update BGP session using either the ASN
   configured as
   normal, but it MUST append "Local AS" or the globally configured ASN 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
   attribute before advertising described in this document SHOULD NOT be performed, as they
   are unnecessary.  The benefit to this more flexible model is that it
   allows the UPDATE remote neighbor to any other reconfigure to the new ASN without
   direct coordination between the ISP and the customer.

   When the BGP speaker.
   Note that processing router receives UPDATEs from its eBGP neighbor
   configured with the "Local AS" mechanism, it processes the update UPDATE as normal will include appending
   described in RFC4271 section 5.1.2 [RFC4271].  However the
   globally configured presence
   of a second ASN due to "Local AS" adds the AS_PATH, thus following behavior to
   processing UPDATEs received from an eBGP neighbor configured with
   this update
   will result in mechanism:

   1.  Internal: the addition of two ASNs to router MUST append the configured "Local AS" ASN in
       the AS_PATH attribute.
   Similarly, for outbound updates sent by attribute before advertising the configured BGP speaker UPDATE to
   its neighbor, an iBGP
       neighbor.

   2.  External: the speaker BGP router MUST first append the globally
       configured ASN to the AS_PATH attribute, adding to immediately followed by the existing global ASN in "Local
       AS" value before advertising the AS_PATH,
   for a total of two ASNs added UPDATE to the AS_PATH. an eBGP neighbor.

   Two options exist to manipulate the behavior of this feature. the basic "Local AS"
   mechanism.  They modify the behavior as described below:

   No prepend inbound

   1.  "No Prepend Inbound" - When the BGP speaker configured with this option router receives inbound updates BGP
       UPDATEs from its neighbor, eBGP neighbor configured with this option, it
       MUST NOT append the
   configured "Local AS" ASN value in the AS_PATH attribute
       when advertising that UPDATE to other peers and instead iBGP neighbors, but it MUST still
       append only the globally configured
   ASN.

   No prepend outbound ASN as normal when advertising the
       UPDATE to other local eBGP neigbors (i.e. those natively peering
       with the globally configured ASN).

   2.  "Replace Old AS", (outbound) - When the BGP speaker configured with this
   option router generates
       outbound BGP updates to the UPDATEs toward an eBGP neighbor configured peer, with this
       option, the BGP speaker MUST remove NOT (first) append the globally
       configured ASN from the AS_PATH
   attribute, and attribute.  The BGP router MUST
       append only the locally configured "Local AS" ASN value to the AS_PATH
   attribute before sending outbound BGP updates to the configured peer.

   While the exact command syntax is an implementation detail beyond the
   scope of this document, the following consideration may be helpful
   for implementers: Implementations MAY integrate the behavior of the
   options described above into a single command that addresses both
   inbound and outbound updates, but if this is done, implementations
   MUST provide a method to select its applicability to inbound updates,
   outbound updates, or updates in both directions.  Several existing
   implementations use separate commands (e.g. local-as no-prepend vs
   local-as replace-as) for maximum flexibility in controlling the
   behavior on AS_PATH
       attribute before sending the session BGP UPDATEs outbound to address the widest range of possible
   migration scenarios. eBGP
       neighbor.

4.  Internal BGP Autonomous System Migration Features Mechanisms

   The following section describes features 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 feature 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 Alias

   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 with more than a few dozen internal BGP speakers. routers.  There
   is 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 Alias" [JUNIPER] feature, 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 feature 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.  NB: Cisco doesn't have an
   exact equivalent to "Internal BGP Alias", but the combination of the
   Cisco features

   The iBGP local-AS and dual-as provides similar
   functionality.

   When router with the "Internal BGP Alias" feature is enabled, typically just on
   one side of a iBGP session, it AS Migration" capability
   enabled allows that iBGP speaker to establish the receipt of a single iBGP session BGP OPEN message with either the
   legacy ASN value or the new,
   permanently retained ASN, depending on which one it receives globally configured ASN value in the "My
   Autonomous System" field of the BGP OPEN message from its iBGP
   session neighbor. neighbors.
   It is important to recognize that enablement of the "Internal BGP Alias" feature AS
   Migration" mechanism preserves the semantics of a regular iBGP
   session, (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
   Alias"
   AS Migration" capability are no different than those exchanged across
   an iBGP session without "Internal BGP Alias" AS Migration" configured, as
   defined by [RFC4271] and [RFC4456].

   Typically, in medium to large networks, BGP Route Reflectors
   [RFC4456] (RRs) 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 speakers. 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
   Alias" feature. AS
   Migration" mechanism.  Note that Route Reflectors are not a
   prerequisite to enable "Internal BGP Alias" AS Migration" and this feature 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 Alias" AS Migration" capability is configured enabled on all iBGP sessions.
       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 Alias" 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 Alias" 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 should now
       have their globally configured ASN set to the permanently
       retained ASN and "Internal BGP Alias" 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.

   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 used by
       configured within the PE for the iBGP sessions toward each RR
       would be changed to use the permanently retained ASN.  (It  It is
       unnecessary to enable "Internal BGP Alias" AS Migration" mechanism on the
       these migrated iBGP sessions). sessions.  During the same maintenance
       window, External BGP sessions would be modified to include the
       above "Local AS No AS", "No Prepend" and "Replace-AS"
       features "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 Alias" AS Migration"
       configuration from the first half of the legacy RR Client pair --
       this will expunge "Internal BGP Alias" configuration from all
       devices Router Reflectors in the network. 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 Alias" AS Migration"
   capability is that it is a more gradual and less externally service-impacting service-
   impacting change to accomplish an AS migration.  Previously, without
   "Internal BGP Alias", AS Migration", such an AS migration change would carry
   a high risk and need to be successfully accomplished in a very short
   timeframe (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 the configuration changes
   are underway to complete the AS Migration.  On the other hand, with
   "Internal BGP Alias", 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

   When configured with this feature, mechanism, a BGP speaker MUST accept BGP
   OPEN and establish an iBGP session from configured iBGP peers if the
   ASN value in MY ASN "My Autonomous System" is either the globally configured
   ASN or the a locally configured ASN provided in when this command. capability is
   utilized.  Additionally, a BGP speaker router configured with this feature mechanism
   MUST send its own BGP OPEN [RFC4271] (see section 4.2) using both the
   globally configured and the locally configured ASN in MY ASN. "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
   feature, 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 ASN. "Bad Peer AS".  In each case, the BGP speaker MUST
   treat
   updates UPDATEs sent and received to this peer as if this was a
   natively configured iBGP session, as defined by [RFC4271] and
   [RFC4456].

   Implementations of this feature MAY integrate the functionality from
   the eBGP features (Section 3) section as a part of this command in
   order to simplify support for eBGP migrations as well as iBGP
   migrations, such that an eBGP session to a configured neighbor could
   be established via either the global ASN or the locally configured
   ASN.  If the eBGP session is established with the global ASN, no
   modifications to AS_PATH are required, but if the eBGP session is
   established with the locally configured ASN, the modifications
   discussed in eBGP features (Section 3) MUST be implemented to
   properly manipulate the AS_PATH.

5.  Additional Operational Considerations

   This document describes several features mechanisms to support ISPs and other
   organizations that need to perform ASN migrations.  Other variations
   of these features 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 features 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 features mechanisms will persist in a
   operational network indefinitely.

   With respect to the Internal BGP AS Migration Features, 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 Alias" AS Migration" capability over a long period of
   time for reasons of not only operational simplicity of the network,
   but also reduced reliance on that feature mechanism during the ongoing
   lifecycle management of software, features and configurations that
   are maintained on the network.

6.  Conclusion

   Although the features discussed in this document are not formally
   recognized as part of the BGP4 specification, they have been in
   existence in commercial implementations for well over a decade.
   These features are widely known by the operational community and will
   continue to be a critical necessity in the support of network
   integration activities going forward.  Therefore, these features are
   extremely unlikely to be deprecated by vendors.  As a result, these
   features must be acknowledged by protocol designers, particularly
   when there are proposals to modify BGP's behavior with respect to
   handling or manipulation of the AS_PATH Attribute.  More
   specifically, assumptions should not be made with respect to the
   preservation or consistency of the AS_PATH Attribute as it is
   transmitted along a sequence of ASNs.  In addition, proposals to
   manipulate the AS_PATH that would gratuitously increase AS_PATH
   length or remove the capability to use these features described in
   this document will not be accepted by the operational community.

7.  Acknowledgements

   Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson,
   David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan
   Alcaide, Jon Mitchell, and Thomas Morin Morin, Alia Atlas, and Alvaro Retana
   for their comments.

8.

7.  IANA Considerations

   This memo includes no request to IANA.

9.

8.  Security Considerations

   This draft 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 a
   loss of revenue if the ISP is billing based on measured utilization
   of traffic sent to/from entities attached to its network.  This could
   also result in
   sudden and unexpected shifts in traffic patterns in the network,
   potentially resulting in congestion, in the most extreme
   cases. congestion.

   Given that these features 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 features.

10. mechanisms.  Additionally, BGP sessions SHOULD
   be protected using TCP Authentication Option [RFC5925] and the
   Generalized TTL Security Mechanism [RFC5082]

9.  Appendix: Implementation report

   As noted elsewhere in this document, this set of migration features 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.

11.

10.  References

11.1.

10.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.

   [RFC5398]  Huston, G., "Autonomous System (AS) Number Reservation for
              Documentation Use",

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 5398, December 2008.

11.2. 4456, April 2006.

10.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>.

   [CISCO]    Cisco Systems, Inc., "BGP Support for Dual AS
              Configuration for Network AS Migrations", 2003,
              <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., "Configuring the BGP Local
              Autonomous System Attribute", 2012,
              <http://www.juniper.net/techpubs/en_US/junos13.3/topics/
              concept/bgp-local-as-introduction.html>.

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, April 2006.

   [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.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, June 2010.

   [RFC6996]  Mitchell, J., "Autonomous System (AS) Reservation for
              Private Use", BCP 6, RFC 6996, July 2013.

Authors' Addresses

   Wesley George
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171
   US

   Phone: +1 703-561-2540
   Email: wesley.george@twcable.com
   Shane Amante
   Apple, Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   US

   Email: samante@apple.com