draft-ietf-idr-as-migration-06.txt   rfc7705.txt 
Internet Engineering Task Force W. George Internet Engineering Task Force (IETF) W. George
Internet-Draft Time Warner Cable Request for Comments: 7705 Time Warner Cable
Updates: 4271 (if approved) S. Amante Updates: 4271 S. Amante
Intended status: Standards Track Apple, Inc. Category: Standards Track Apple, Inc.
Expires: January 7, 2016 July 6, 2015 ISSN: 2070-1721 November 2015
Autonomous System Migration Mechanisms and Their Effects on the BGP Autonomous System Migration Mechanisms
AS_PATH Attribute and Their Effects on the BGP AS_PATH Attribute
draft-ietf-idr-as-migration-06
Abstract Abstract
This draft discusses some existing commonly-used BGP mechanisms for This document discusses some existing commonly used BGP mechanisms
ASN migration that are not formally part of the BGP4 protocol for Autonomous System Number (ASN) migration that are not formally
specification. It is necessary to document these de facto standards part of the BGP4 protocol specification. It is necessary to document
to ensure that they are properly supported in future BGP protocol these de facto standards to ensure that they are properly supported
work. in future BGP protocol work.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on January 7, 2016. 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 Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Documentation note . . . . . . . . . . . . . . . . . . . 3 1.2. Documentation Note . . . . . . . . . . . . . . . . . . . 3
2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3 2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3
3. External BGP Autonomous System Migration Mechanisms . . . . . 5 3. External BGP Autonomous System Migration Mechanisms . . . . . 5
3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 5 3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 5
3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7 3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7
3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8
4. Internal BGP Autonomous System Migration Mechanisms . . . . . 9 4. Internal BGP Autonomous System Migration Mechanisms . . . . . 9
4.1. Internal BGP AS Migration . . . . . . . . . . . . . . . . 10 4.1. Internal BGP AS Migration . . . . . . . . . . . . . . . . 10
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12
5. Additional Operational Considerations . . . . . . . . . . . . 13 5. Additional Operational Considerations . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Implementation Report . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Implementation report . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This draft discusses some existing commonly-used BGP mechanisms for This document discusses some existing commonly used BGP mechanisms
Autonomous System Number (ASN) migration that are not formally part for Autonomous System Number (ASN) migration that are not formally
of the BGP4 [RFC4271] protocol specification. These mechanisms are part of the BGP4 [RFC4271] protocol specification. These mechanisms
local to a given BGP Speaker and do not require negotiation with or are local to a given BGP speaker and do not require negotiation with
cooperation of BGP neighbors. The deployment of these mechanisms do or cooperation of BGP neighbors. The deployment of these mechanisms
not need to interwork with one another to accomplish the desired do not need to interwork with one another to accomplish the desired
results, so slight variations between existing vendor implementations results, so slight variations between existing vendor implementations
exist, and will not necessarily be harmonized due to this document. exist and will not necessarily be harmonized due to this document.
However, it is necessary to document these de facto standards to However, it is necessary to document these de facto standards to
ensure that new implementations can be successful, and any future ensure that new implementations can be successful, and any future
protocol enhancements to BGP that propose to read, copy, manipulate protocol enhancements to BGP that propose to read, copy, manipulate,
or compare the AS_PATH attribute can do so without inhibiting the use or compare the AS_PATH attribute can do so without inhibiting the use
of these very widely used ASN migration mechanisms. of these very widely used ASN migration mechanisms.
The migration mechanisms discussed here are useful to ISPs and The migration mechanisms discussed here are useful to ISPs and
organizations of all sizes, but it is important to understand the organizations of all sizes, but it is important to understand the
business need for these mechanisms and illustrate why they are so business need for these mechanisms and illustrate why they are so
critical for ISPs' operations. During a merger, acquisition or critical for ISPs' operations. During a merger, acquisition, or
divestiture involving two organizations it is necessary to seamlessly divestiture involving two organizations it is necessary to seamlessly
migrate both internal and external BGP speakers from one ASN to a migrate both internal and external BGP speakers from one ASN to a
second ASN. The overall goal in doing so is to simplify operations second ASN. The overall goal in doing so is to simplify operations
through consistent configurations across all BGP speakers in the through consistent configurations across all BGP speakers in the
combined network. In addition, given that the BGP Path Selection combined network. In addition, given that the BGP Path Selection
algorithm selects routes with the shortest AS_PATH attribute, it is algorithm selects routes with the shortest AS_PATH attribute, it is
critical that the ISP does not increase AS_PATH length during or critical that the ISP does not increase AS_PATH length during or
after ASN migration, because an increased AS_PATH length would likely after ASN migration, because an increased AS_PATH length would likely
result in sudden, undesirable changes in traffic patterns in the result in sudden, undesirable changes in traffic-patterns in the
network. network.
By default, the BGP protocol requires an operator to configure a 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 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 must match on both ends of the peering in order to successfully
negotiate and establish a BGP session. Prior to the existence of negotiate and establish a BGP session. Prior to the existence of
these migration mechanisms, it would have required an ISP to these migration mechanisms, it would have required an ISP to
coordinate an ASN change with, in some cases, tens of thousands of coordinate an ASN change with, in some cases, tens of thousands of
customers. In particular, as each router is migrated to the new ASN, 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 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 all customers on that router to change their router configurations to
use the new ASN immediately after the ASN change. Thus, it becomes use the new ASN immediately after the ASN change. Thus, it was
critical to allow the ISP to make this process a bit more asymmetric, critical to define a more asymmetric migration method so that the ISP
so that it could seamlessly migrate the ASN within its network(s), could seamlessly change the ASN within its network(s) but allow the
but allow the customers to gradually migrate to the ISP's new ASN at customers to gradually migrate to the ISP's new ASN when convenient.
their leisure, either by coordinating individual reconfigurations, or These customer migrations could occur either by coordinating
accepting sessions using either the old or new ASN to allow for truly individual session reconfigurations or, to allow for truly asymmetric
asymmetric migration. migration, by accepting sessions using either the old or new ASN.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Documentation note 1.2. Documentation Note
This draft uses Autonomous System Numbers (ASNs) from the range This document uses Autonomous System Numbers (ASNs) from the range
reserved for documentation as described in RFC 5398 [RFC5398]. In reserved for documentation as described in RFC 5398 [RFC5398]. In
the examples used here, they are intended to represent Globally the examples used here, they are intended to represent Globally
Unique ASNs, not private use ASNs as documented in RFC 6996 [RFC6996] Unique ASNs, not private use ASNs as documented in Section 5 of RFC
section 5. 6996 [RFC6996].
2. ASN Migration Scenario Overview 2. ASN Migration Scenario Overview
The use case being discussed here is an ISP merging two or more ASNs, 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 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, 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. that prior to the ASN migration use AS 64500 and 64510, respectively.
AS 64500 will be the permanently retained ASN used across the AS 64500 will be the permanently retained ASN used across the
consolidated set of both ISPs network equipment, and AS 64510 will be consolidated set of both ISPs network equipment, and AS 64510 will be
retired. Thus, at the conclusion of the ASN migration, there will be retired. Thus, at the conclusion of the ASN migration, there will be
skipping to change at page 4, line 16 skipping to change at page 4, line 12
64500. To all external BGP speakers, the AS_PATH length will not be 64500. To all external BGP speakers, the AS_PATH length will not be
increased. increased.
In this same scenario, AS 64496 and AS 64499 represent two separate In this same scenario, AS 64496 and AS 64499 represent two separate
customer networks: C and D, respectively. Originally, customer C (AS customer networks: C and D, respectively. Originally, customer C (AS
64496) is attached to ISP B, which will undergo ASN migration from 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 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 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 will remain constant, (AS 64500). Although this example refers to AS
64496 and 64499 as customer networks, either or both may be 64496 and 64499 as customer networks, either or both may be
settlement-free or other types of peers. In this use case they are settlement-free or other types of peers. In this use case, they are
referred to as "customers" merely for convenience. referred to as "customers" merely for convenience.
------ ------ ------ ------
/ ISP A \ / ISP B \ / ISP A \ / ISP B \
| AS 64500 | | AS 64510 | | AS 64500 | | AS 64510 |
\ / \ / \ / \ /
------- ------- ------- -------
| | | |
| | | |
------------ ------------- ------------ -------------
skipping to change at page 4, line 51 skipping to change at page 4, line 47
| | | |
------------ ------------- ------------ -------------
| Cust D | | Cust C | | Cust D | | Cust C |
| AS 64499 | | AS 64496 | | AS 64499 | | AS 64496 |
------------ ------------- ------------ -------------
Figure 2: After Migration Figure 2: After Migration
The general order of operations, typically carried out in a single The general order of operations, typically carried out in a single
maintenance window by the network undergoing ASN migration (ISP B), maintenance window by the network undergoing ASN migration (ISP B),
are as follows. First, ISP B will change the global BGP ASN used by is as follows. First, ISP B will change the global BGP ASN used by a
a Provider Edge (PE) router, from ASN 64510 to 64500. At this point, 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 router will no longer be able to establish External BGP (eBGP)
the existing Customer Edge (CE) devices that are attached to it and sessions toward the existing Customer Edge (CE) devices that are
still using AS 64510. Second, since ISP B needs to do this without attached to it and still using AS 64510. Second, since ISP B needs
coordinating the simultaneous change of its ASN with all of its eBGP to do this without coordinating the simultaneous change of its ASN
peers, ISP B will configure two separate, but related ASN migration with all of its eBGP peers, ISP B will configure two separate, but
mechanisms discussed in this document on all eBGP sessions toward all related ASN migration mechanisms discussed in this document on all
CE devices. These mechanisms enable the router to establish BGP eBGP sessions toward all CE devices. These mechanisms enable the
neighbors using the legacy ASN, modify the AS_PATH attribute received router to establish BGP neighbors using the legacy ASN, modify the
from a CE device when advertising it further, and modify AS_PATH when AS_PATH attribute received from a CE device when advertising it
transmitted toward CE devices to achieve the desired effect of not further, and modify AS_PATH when transmitted toward CE devices to
increasing the length of the AS_PATH. 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 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 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 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 AS_PATH attribute. However, after the changes discussed in this
document are put in place by ISP A', there is a change to the 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 contents of the AS_PATH attribute to ensure the AS_PATH is not
artificially lengthened while these AS migration parameters are used. artificially lengthened while these AS migration parameters are used.
In this use case, neither ISP is using BGP Confederations RFC 5065 In this use case, neither ISP is using BGP Confederations [RFC5065]
[RFC5065] internally. internally.
3. External BGP Autonomous System Migration Mechanisms 3. External BGP Autonomous System Migration Mechanisms
The following section addresses optional capabilities that are The following section addresses optional capabilities that are
specific to modifying the AS_PATH attribute at the Autonomous System specific to modifying the AS_PATH attribute at the Autonomous System
Border Routers (ASBRs) of an organization, (typically a single Border Routers (ASBRs) of an organization (typically a single Service
Service Provider). This ensures that external BGP customers/peers Provider). This ensures that external BGP customers/peers are not
are not forced to make any configuration changes on their CE routers forced to make any configuration changes on their CE routers before
before or during the exact time the Service Provider wishes to or during the exact time the Service Provider wishes to migrate to a
migrate to a new, permanently retained ASN. Furthermore, these new, permanently retained ASN. Furthermore, these mechanisms
mechanisms eliminate the artificial lengthening of the AS_PATH both eliminate the artificial lengthening of the AS_PATH both transmitted
transmitted from and received by the Service Provider that is from and received by the Service Provider that is undergoing AS
undergoing AS Migration, which would have negative implications on Migration, which would have negative implications on path selection
path selection by external networks. by external networks.
3.1. Modify Inbound BGP AS_PATH Attribute 3.1. Modify Inbound BGP AS_PATH Attribute
The first instrument used in the process described above is called The first instrument used in the process described above is called
"Local AS". This allows the router to supersede the globally "Local AS". This allows the router to supersede the globally
configured ASN in the "My Autonomous System" field of the BGP OPEN configured ASN in the "My Autonomous System" field of the BGP OPEN
[RFC4271] with a locally defined AS value for a specific BGP neighbor [RFC4271] with a locally defined AS value for a specific BGP neighbor
or group of neighbors. This mechanism allows the PE router that was 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 formerly in ISP B to establish an eBGP session toward the existing CE
devices using the legacy AS, AS 64510. Ultimately, the CE devices devices using the legacy AS -- AS 64510. Ultimately, the CE devices
(i.e.: customer C) are completely unaware that ISP B has reconfigured (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 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 context of the former ISP B PE router, the second effect this
specific mechanism has on AS_PATH is that, by default, it prepends 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 all received BGP UPDATEs with the legacy AS of ISP B -- AS 64510 --
advertising it (Adj-RIB-Out) to other BGP speakers (A'). Within the while advertising it (Adj-RIB-Out) to other BGP speakers (A').
Loc-RIB on ISP B prior to the migration, the AS_PATH of route Within the Loc-RIB on ISP B prior to the migration, the AS_PATH of
announcements received from customer C would appear as: 64496, route announcements received from customer C would appear as 64496,
whereas the same RIB on ISP A' (ISP B routers post-migration) would whereas the same RIB on ISP A' (ISP B routers post-migration) would
contain AS_PATH: 64510 64496. contain AS_PATH 64510 64496.
A second instrument, referred to as "No Prepend Inbound", is enabled The second instrument, referred to as "No Prepend Inbound", is
on PE routers migrating from ISP B. The "No Prepend Inbound" 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 capability causes ISP B's routers to not prepend the legacy AS (AS
64510, when advertising UPDATES received from customer C. This 64510), when advertising UPDATES received from customer C. This
restores the AS_PATH within ISP A' for route announcements received restores the AS_PATH within ISP A' for route announcements received
from customer C so that it is just one ASN in length: 64496. from customer C so that it is just one ASN in length: 64496.
In the direction of CE -> PE (inbound): In the direction of CE -> PE (inbound):
1. "Local AS": Allows the local BGP router to generate a BGP OPEN to 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 an eBGP neighbor with the old, legacy ASN value in the "My
Autonomous System" field. When this capability is activated, it Autonomous System" field. When this capability is activated, it
also causes the local router to prepend the <old_ASN> value to also causes the local router to prepend the <old_ASN> value to
the AS_PATH when installing or advertising routes received from a the AS_PATH when installing or advertising routes received from a
CE to iBGP neighbors inside the Autonomous System. CE to Internal BGP (iBGP) neighbors inside the Autonomous System.
2. "No Prepend Inbound (of Local AS)": the local BGP router does not 2. "No Prepend Inbound (of Local AS)": The local BGP router does not
prepend <old_ASN> value to the AS_PATH when installing or prepend the <old_ASN> value to the AS_PATH when installing or
advertising routes received from the CE to iBGP neighbors inside advertising routes received from the CE to iBGP neighbors inside
the Autonomous System the Autonomous System
PE-B is a PE that was originally in ISP B, and has a customer eBGP 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 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 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 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 originally in ISP A, and has a customer peer CE-A. Although its
global configuration ASN remains AS 64500, throughout this exercise global configuration ASN remains AS 64500, throughout this exercise
we also consider PE-A a member of ISP A'. we also consider PE-A a member of ISP A'.
ISP A' ISP A' ISP A' ISP A'
CE-A <--- PE-A <------------------- PE-B <--- CE-B CE-A <--- PE-A <------------------- PE-B <--- CE-B
64499 New_ASN: 64500 Old_ASN: 64510 64496 64499 New_ASN: 64500 Old_ASN: 64510 64496
New_ASN: 64500 New_ASN: 64500
Note: Direction of BGP UPDATE as per the arrows. Note: Direction of BGP UPDATE as per the arrows.
Figure 3: Local AS and No Prepend BGP UPDATE Diagram Figure 3: Local AS and No Prepend BGP UPDATE Diagram
As a result using both the "Local AS" and "No Prepend Inbound" 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 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. will not receive a BGP UPDATE containing AS 64510 in the AS_PATH.
(If only the "Local AS" mechanism was configured without "No Prepend (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 Inbound" on PE-B, then CE-A would have seen an AS_PATH of 64500 64510
64510 64496, which results in an unacceptable lengthening of the 64496, which results in an unacceptable lengthening of the AS_PATH).
AS_PATH). NOTE: If there are still routers in the old ASN (64510), Note: If there are still routers in the old ASN (64510), it is
it is possible for them to accept these manipulated routes (i.e. possible for them to accept these manipulated routes (i.e., those
those with 64510 removed from the AS_PATH by this command) as if they with 64510 removed from the AS_PATH by this command) as if they have
have not already passed through their ASN, potentially causing a not already passed through their ASN, potentially causing a loop,
loop, since BGP's normal loop-prevention behavior of rejecting routes since BGP's normal loop-prevention behavior of rejecting routes that
that include its ASN in the path will not catch these. Careful include its ASN in the path will not catch these. Careful filtering
filtering between routers remaining in the old ASN and routers between routers remaining in the old ASN and routers migrated to the
migrated to the new ASN is necessary to minimize the risk of routing new ASN is necessary to minimize the risk of routing loops.
loops.
3.2. Modify Outbound BGP AS_PATH Attribute 3.2. Modify Outbound BGP AS_PATH Attribute
The two aforementioned mechanisms, "Local AS" and "No Prepend The two aforementioned mechanisms, "Local AS" and "No Prepend
Inbound", only modify the AS_PATH Attribute received by the ISP's Inbound", only modify the AS_PATH attribute received by the ISP's PEs
PE's in the course of processing BGP UPDATEs from CE devices when CE in the course of processing BGP UPDATEs from CE devices when CE
devices still have an eBGP session established with the ISPs legacy devices still have an eBGP session established with the ISPs legacy
AS (AS64510). AS (AS64510).
In some existing implementations, "Local AS" and "No Prepend Inbound" In some existing implementations, "Local AS" and "No Prepend Inbound"
does not concurrently modify the AS_PATH Attribute for BGP UPDATEs do not concurrently modify the AS_PATH attribute for BGP UPDATEs that
that are transmitted by the ISP's PE's to CE devices. In these are transmitted by the ISP's PEs to CE devices. In these
implementations, with "Local AS" and "No Prepend Inbound" used on PE- implementations, with "Local AS" and "No Prepend Inbound" used on
B, it automatically causes a lengthening of the AS_PATH in outbound PE-B, there is an automatic lengthening of the AS_PATH in outbound
BGP UPDATEs from ISP A' toward directly attached eBGP speakers, 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). The externally observed result is that
customer C, in AS 64496, will receive the following AS_PATH: 64510 customer C in AS 64496 will receive the following AS_PATH: 64510
64500 64499. Therefore, if ISP A' takes no further action, it will 64500 64499. Therefore, if ISP A' takes no further action, there
cause an unacceptable increase in AS_PATH length within customer's will be an unacceptable increase in the AS_PATH length within the
networks directly attached to ISP A'. customer's networks directly attached to ISP A'.
A tertiary mechanism, referred to as "Replace Old AS", is used to A tertiary mechanism, referred to as "Replace Old AS", is used to
resolve this problem. This capability allows ISP A' to prevent resolve this problem. This capability allows ISP A' to prevent
routers from appending the globally configured ASN in outbound BGP routers from appending the globally configured ASN in outbound BGP
UPDATEs toward directly attached eBGP neighbors that are using the UPDATEs toward directly attached eBGP neighbors that are using the
"Local AS" mechanism. Instead, only the old (or previously used) AS "Local AS" mechanism. Instead, only the old (or previously used) AS
will be prepended in the outbound BGP UPDATE toward the customer's 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 network, restoring the AS_PATH length to what it what was before AS
Migration occurred. Migration occurred.
To re-use the above diagram, but in the opposite direction, we have: To reuse the above diagram, but in the opposite direction, we have:
ISP A' ISP A' ISP A' ISP A'
CE-A ---> PE-A -------------------> PE-B ---> CE-B CE-A ---> PE-A -------------------> PE-B ---> CE-B
64499 New_ASN: 64500 Old_ASN: 64510 64496 64499 New_ASN: 64500 Old_ASN: 64510 64496
New_ASN: 64500 New_ASN: 64500
Note: Direction of BGP UPDATE as per the arrows. Note: Direction of BGP UPDATE as per the arrows.
Figure 4: Replace AS BGP UPDATE Diagram Figure 4: Replace AS BGP UPDATE Diagram
By default, without the use of "Replace Old AS", CE-B would see an 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 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, "Replace Old AS", CE-B would receive an AS_PATH of 64510 64499, which
which is the same AS_PATH length pre-AS migration. is the same AS_PATH length pre-AS migration.
3.3. Implementation 3.3. Implementation
The mechanisms introduced in this section MUST be configurable on a The mechanisms introduced in this section MUST be configurable on a
per-neighbor or per neighbor group (i.e. a group of similar BGP per-neighbor or per-neighbor-group basis to allow for maximum
neighbor statements that reuse some common configuration to simplify flexibility. (Here, "neighbor group" refers to a group of similar
provisioning) basis to allow for maximum flexibility. When the BGP neighbor statements that reuse some common configuration to
"Local AS" capability is used, a local ASN will be provided in the simplify provisioning.) When the "Local AS" capability is used, a
configuration that is different from the globally-configured ASN of local ASN will be provided in the configuration that is different
the BGP router. To implement this mechanism, a BGP speaker SHOULD from the globally configured ASN of the BGP router. To implement
send BGP OPEN [RFC4271] (see section 4.2) messages to the configured this mechanism, a BGP speaker SHOULD send BGP OPEN [RFC4271] (see
eBGP peer(s) using the local ASN configured for this session as the Section 4.2) messages to the configured eBGP peer(s) using the local
value sent in "My Autonomous System". The BGP router SHOULD NOT use ASN configured for this session as the value sent in "My Autonomous
the ASN configured globally within the BGP process as the value sent System". The BGP router SHOULD NOT use the ASN configured globally
in "My Autonomous System" in the OPEN message. This will avoid within the BGP process as the value sent in "My Autonomous System" in
causing the eBGP neighbor to unnecessarily generate a BGP OPEN Error the OPEN message. This prevents causing the eBGP neighbor to
message "Bad Peer AS". This method is typically used to re-establish unnecessarily generate a BGP OPEN Error message "Bad Peer AS". This
eBGP sessions with peers expecting the legacy ASN after a router has method is typically used to re-establish eBGP sessions with peers
been moved to a new ASN. expecting the legacy ASN after a router has been moved to a new ASN.
Implementations MAY support a more flexible model where the eBGP Implementations MAY support a more flexible model where the eBGP
speaker attempts to open the BGP session using either the ASN speaker attempts to open the BGP session using either the ASN
configured as "Local AS" or the globally configured AS as discussed configured as "Local AS" or the globally configured AS as discussed
in BGP Alias (Section 4.2). If the session is successfully in BGP Alias (Section 4.2). If the session is successfully
established to the globally configured ASN, then the modifications to established to the globally configured ASN, then the modifications to
AS_PATH described in this document SHOULD NOT be performed, as they AS_PATH described in this document SHOULD NOT be performed, as they
are unnecessary. The benefit to this more flexible model is that it are unnecessary. The benefit to this more flexible model is that it
allows the remote neighbor to reconfigure to the new ASN without allows the remote neighbor to reconfigure to the new ASN without
direct coordination between the ISP and the customer. direct coordination between the ISP and the customer.
Note that this procedure will vary slightly if the locally or Note that this procedure will vary slightly if the locally or
globally configured ASN is a 4-octet ASN. See section 3 of globally configured ASN is a 4-octet ASN. See Section 3 of
[RFC4893]. [RFC6793].
When the BGP router receives UPDATEs from its eBGP neighbor When the BGP router receives UPDATEs from its eBGP neighbor
configured with the "Local AS" mechanism, it processes the UPDATE as configured with the "Local AS" mechanism, it processes the UPDATE as
described in RFC4271 section 5.1.2 [RFC4271]. However the presence described in RFC4271 Section 5.1.2 [RFC4271]. However, the presence
of a second ASN due to "Local AS" adds the following behavior to of a second ASN due to "Local AS" adds the following behavior to
processing UPDATEs received from an eBGP neighbor configured with processing UPDATEs received from an eBGP neighbor configured with
this mechanism: this mechanism:
1. Internal: the router SHOULD append the configured "Local AS" ASN 1. Internal: The router SHOULD append the configured "Local AS" ASN
in the AS_PATH attribute before installing the route or in the AS_PATH attribute before installing the route or
advertising the UPDATE to an iBGP neighbor. The decision of when advertising the UPDATE to an iBGP neighbor. The decision of when
to append the ASN is an implementation detail outside the scope to append the ASN is an implementation detail outside the scope
of this document. Some considerations factoring into this of this document. Some considerations factoring into this
decision include consistency in the AS_PATH throughout the AS, decision include consistency in the AS_PATH throughout the AS,
and implementation of the loop detection mechanism. and implementation of the loop detection mechanism.
2. External: the BGP router SHOULD first append the globally 2. External: The BGP router SHOULD first append the globally
configured ASN to the AS_PATH immediately followed by the "Local configured ASN to the AS_PATH immediately followed by the "Local
AS" value before advertising the UPDATE to an eBGP neighbor. AS" value before advertising the UPDATE to an eBGP neighbor.
Two options exist to manipulate the behavior of the basic "Local AS" Two options exist to manipulate the behavior of the basic "Local AS"
mechanism. They modify the behavior as described below: mechanism. They modify the behavior as described below:
1. "No Prepend Inbound" - When the BGP router receives inbound BGP 1. "No Prepend Inbound": When the BGP router receives inbound BGP
UPDATEs from its eBGP neighbor configured with this option, it UPDATEs from its eBGP neighbor configured with this option, it
MUST NOT append the "Local AS" ASN value in the AS_PATH attribute MUST NOT append the "Local AS" ASN value in the AS_PATH attribute
when installing the route or advertising that UPDATE to iBGP when installing the route or advertising that UPDATE to iBGP
neighbors, but it MUST still append the globally configured ASN neighbors, but it MUST still append the globally configured ASN
as normal when advertising the UPDATE to other local eBGP as normal when advertising the UPDATE to other local eBGP
neighbors (i.e. those natively peering with the globally neighbors (i.e., those natively peering with the globally
configured ASN). configured ASN).
2. "Replace Old AS", (outbound) - When the BGP router generates 2. "Replace Old AS" (outbound): When the BGP router generates
outbound BGP UPDATEs toward an eBGP neighbor configured with this outbound BGP UPDATEs toward an eBGP neighbor configured with this
option, the BGP speaker MUST NOT append the globally configured option, the BGP speaker MUST NOT append the globally configured
ASN from the AS_PATH attribute. The BGP router MUST append only ASN from the AS_PATH attribute. The BGP router MUST append only
the configured "Local AS" ASN value to the AS_PATH attribute the configured "Local AS" ASN value to the AS_PATH attribute
before sending the BGP UPDATEs outbound to the eBGP neighbor. before sending the BGP UPDATEs outbound to the eBGP neighbor.
4. Internal BGP Autonomous System Migration Mechanisms 4. Internal BGP Autonomous System Migration Mechanisms
The following section describes mechanisms that assist with a gradual The following section describes mechanisms that assist with a gradual
and least service impacting migration of Internal BGP sessions from a and least service-impacting migration of Internal BGP sessions from a
legacy ASN to the permanently retained ASN. The following mechanism legacy ASN to the permanently retained ASN. The following mechanism
is very valuable to networks undergoing AS migration, but its use is very valuable to networks undergoing AS migration, but its use
does not cause changes to the AS_PATH attribute. does not cause changes to the AS_PATH attribute.
4.1. Internal BGP AS Migration 4.1. Internal BGP AS Migration
In this case, all of the routers to be consolidated into a single, In this case, all of the routers to be consolidated into a single,
permanently retained ASN are under the administrative control of a permanently retained ASN are under the administrative control of a
single entity. Unfortunately, the traditional method of migrating single entity. Unfortunately, the traditional method of migrating
all Internal BGP speakers, particularly within larger networks, is all Internal BGP speakers, particularly within larger networks, is
both time consuming and widely service impacting. both time-consuming and widely service impacting.
The traditional method to migrate Internal BGP sessions was strictly The traditional method to migrate Internal BGP sessions was strictly
limited to reconfiguration of the global configuration ASN and, limited to reconfiguration of the global configuration ASN and,
concurrently, changing all iBGP neighbors' remote ASN from the legacy concurrently, changing all iBGP neighbors' remote ASN from the legacy
ASN to the new, permanently retained ASN on each router within the ASN to the new, permanently retained ASN on each router within the
legacy AS. These changes can be challenging to swiftly execute in legacy AS. These changes can be challenging to swiftly execute in
networks with with more than a few dozen internal BGP routers. There networks with more than a few dozen internal BGP routers. There are
is also the concomitant service interruptions as these changes are also the concomitant service interruptions as these changes are made
made to routers within the network, resulting in a reset of iBGP to routers within the network, resulting in a reset of iBGP sessions
sessions and subsequent route reconvergence to reestablish optimal and subsequent route reconvergence to reestablish optimal routing
routing paths. Operators often cannot make such sweeping changes paths. Operators often cannot make such sweeping changes given the
given the associated risks of a highly visible service interruption; associated risks of a highly visible service interruption; rather,
rather, they require a more gradual method to migrate Internal BGP they require a more gradual method to migrate Internal BGP sessions,
sessions, from one ASN to a second, permanently retained ASN, that is from one ASN to a second, permanently retained ASN, that is not
not visibly service-impacting to its customers. visibly service impacting to its customers.
With the "Internal BGP AS Migration" mechanism described herein, it With the "Internal BGP AS Migration" mechanism described herein, it
allows an Internal BGP speaker to form a single iBGP session using allows an Internal BGP speaker to form a single iBGP session using
either the old, legacy ASN or the new, permanently retained ASN. The either the old, legacy ASN or the new, permanently retained ASN. The
benefits of using this mechanism are several fold. First, it allows benefits of using this mechanism are several fold. First, it allows
for a more gradual and less service-impacting migration away from the for a more gradual and less service-impacting migration away from the
legacy ASN to the permanently retained ASN. Second, it (temporarily) legacy ASN to the permanently retained ASN. Second, it (temporarily)
permits the coexistence of the legacy and permanently retained ASN permits the coexistence of the legacy and permanently retained ASN
within a single network, allowing for uniform BGP path selection within a single network, allowing for uniform BGP path selection
among all routers within the consolidated network. among all routers within the consolidated network.
The iBGP router with the "Internal BGP AS Migration" capability The iBGP router with the "Internal BGP AS Migration" capability
enabled allows the receipt of a BGP OPEN message with either the 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 legacy ASN value or the new, globally configured ASN value in the "My
Autonomous System" field of the BGP OPEN message from iBGP neighbors. Autonomous System" field of the BGP OPEN message from iBGP neighbors.
It is important to recognize that enablement of the "Internal BGP AS It is important to recognize that enablement of the "Internal BGP AS
Migration" mechanism preserves the semantics of a regular iBGP Migration" mechanism preserves the semantics of a regular iBGP
session (i.e. using identical ASNs). Thus, the BGP attributes session (i.e., using identical ASNs). Thus, the BGP attributes
transmitted by and the acceptable methods of operation on BGP transmitted by and the acceptable methods of operation on BGP
attributes received from iBGP sessions configured with "Internal BGP attributes received from iBGP sessions configured with "Internal BGP
AS Migration" capability are no different than those exchanged across AS Migration" capability are no different than those exchanged across
an iBGP session without "Internal BGP AS Migration" configured, as an iBGP session without "Internal BGP AS Migration" configured, as
defined by [RFC4271] and [RFC4456]. defined by [RFC4271] and [RFC4456].
Typically, in medium to large networks, BGP Route Reflectors Typically, in medium to large networks, BGP Route Reflectors (RRs)
[RFC4456] (RRs) are used to aid in reduction of configuration of iBGP [RFC4456] are used to aid in reduction of configuration of iBGP
sessions and scalability with respect to overall TCP (and, BGP) sessions and scalability with respect to overall TCP (and BGP)
session maintenance between adjacent iBGP routers. Furthermore, BGP session maintenance between adjacent iBGP routers. Furthermore, BGP
Route Reflectors are typically deployed in pairs within a single Route Reflectors are typically deployed in pairs within a single
Route Reflection cluster to ensure high reliability of the BGP Route Reflection cluster to ensure high reliability of the BGP
Control Plane. As such, the following example will use Route Control Plane. As such, the following example will use Route
Reflectors to aid in understanding the use of the "Internal BGP AS Reflectors to aid in understanding the use of the "Internal BGP AS
Migration" mechanism. Note that Route Reflectors are not a Migration" mechanism. Note that Route Reflectors are not a
prerequisite to enable "Internal BGP AS Migration" and this mechanism prerequisite to enable "Internal BGP AS Migration" and this mechanism
can be enabled independent of the use of Route Reflectors. can be enabled independent of the use of Route Reflectors.
The general order of operations is as follows: The general order of operations is as follows:
skipping to change at page 11, line 38 skipping to change at page 11, line 41
2. The above step is repeated for the other side of the redundant 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 pair of RRs. The one alteration to the above procedure is that
the "Internal BGP AS Migration" mechanism is now removed from the the "Internal BGP AS Migration" mechanism is now removed from the
Non-Client iBGP sessions toward the other (previously Non-Client iBGP sessions toward the other (previously
reconfigured) RRs, since it is no longer needed. The "Internal reconfigured) RRs, since it is no longer needed. The "Internal
BGP AS Migration" mechanism is still required on all RRs for all BGP AS Migration" mechanism is still required on all RRs for all
RR Client iBGP sessions. Also during this step, there will be a RR Client iBGP sessions. Also during this step, there will be a
reset and reconvergence event on all iBGP sessions whose reset and reconvergence event on all iBGP sessions whose
configuration was modified, but this should not be service configuration was modified, but this should not be service
impacting. At the conclusion of this step, all RRs should now impacting. At the conclusion of this step, all RRs will have
have their globally configured ASN set to the permanently their globally configured ASN set to the permanently retained ASN
retained ASN and "Internal BGP AS Migration" enabled and in use and "Internal BGP AS Migration" enabled and in use toward RR
toward RR Clients. Clients.
3. At this point, the network administrators would then be able to 3. At this point, the network administrators would then be able to
establish iBGP sessions between all Route Reflectors in both the establish iBGP sessions between all Route Reflectors in both the
legacy and permanently retained networks. This would allow the legacy and permanently retained networks. This would allow the
network to appear to function, both internally and externally, as network to appear to function, both internally and externally, as
a single, consolidated network using the permanently retained a single, consolidated network using the permanently retained
network. network.
4. To complete the AS migration, each RR Client (PE) in the legacy 4. To complete the AS migration, each RR Client (PE) in the legacy
network still utilizing the legacy ASN is now modified. network still utilizing the legacy ASN is now modified.
skipping to change at page 12, line 4 skipping to change at page 12, line 7
3. At this point, the network administrators would then be able to 3. At this point, the network administrators would then be able to
establish iBGP sessions between all Route Reflectors in both the establish iBGP sessions between all Route Reflectors in both the
legacy and permanently retained networks. This would allow the legacy and permanently retained networks. This would allow the
network to appear to function, both internally and externally, as network to appear to function, both internally and externally, as
a single, consolidated network using the permanently retained a single, consolidated network using the permanently retained
network. network.
4. To complete the AS migration, each RR Client (PE) in the legacy 4. To complete the AS migration, each RR Client (PE) in the legacy
network still utilizing the legacy ASN is now modified. network still utilizing the legacy ASN is now modified.
Specifically, each legacy PE would have its globally configured Specifically, each legacy PE would have its globally configured
ASN changed to use the permanently retained ASN. The ASN ASN changed to use the permanently retained ASN. The ASN
configured within the PE for the iBGP sessions toward each RR configured within the PE for the iBGP sessions toward each RR
would be changed to use the permanently retained ASN. It is would be changed to use the permanently retained ASN. It is
unnecessary to enable "Internal BGP AS Migration" mechanism on unnecessary to enable the "Internal BGP AS Migration" mechanism
these migrated iBGP sessions. During the same maintenance on these migrated iBGP sessions. During the same maintenance
window, External BGP sessions would be modified to include the window, External BGP sessions would be modified to include the
above "Local AS", "No Prepend" and "Replace Old AS" mechanisms above "Local AS", "No Prepend", and "Replace Old AS" mechanisms
described in Section 3 above, since all of the changes are described in Section 3 above, since all of the changes are
service interrupting to the eBGP sessions of the PE. At this service interrupting to the eBGP sessions of the PE. At this
point, all PEs will have been migrated to the permanently point, all PEs will have been migrated to the permanently
retained ASN. retained ASN.
5. The final step is to excise the "Internal BGP AS Migration" 5. The final step is to excise the "Internal BGP AS Migration"
configuration from the Router Reflectors in an orderly fashion. configuration from the Router Reflectors in an orderly fashion.
After this is complete, all routers in the network will be using After this is complete, all routers in the network will be using
the new, permanently retained ASN for all iBGP sessions with no the new, permanently retained ASN for all iBGP sessions with no
vestiges of the legacy ASN on any iBGP sessions. vestiges of the legacy ASN on any iBGP sessions.
The benefit of using the aforementioned "Internal BGP AS Migration" The benefit of using the aforementioned "Internal BGP AS Migration"
capability is that it is a more gradual and less externally service- capability is that it is a more gradual and less externally service
impacting change to accomplish an AS migration. Previously, without impacting change to accomplish an AS migration. Previously, without
"Internal BGP AS Migration", such an AS migration change would carry "Internal BGP AS Migration", such an AS migration change would carry
a high risk and need to be successfully accomplished in a very short a high risk and need to be successfully accomplished in a very short
timeframe (e.g.: at most several hours). In addition, it would time frame (e.g., at most several hours). In addition, it would
likely cause substantial routing churn and rapid fluctuations in likely cause substantial routing churn and rapid fluctuations in
traffic carried -- potentially causing periods of congestion and traffic carried -- potentially causing periods of congestion and
resultant packet loss -- during the period the configuration changes resultant packet loss -- during the period when the configuration
are underway to complete the AS Migration. On the other hand, with changes are underway to complete the AS Migration. On the other
"Internal BGP AS Migration", the migration from the legacy ASN to the hand, with "Internal BGP AS Migration", the migration from the legacy
permanently retained ASN can occur over a period of days or weeks ASN to the permanently retained ASN can occur over a period of days
with reduced customer disruption. (The only observable service or weeks with reduced customer disruption. (The only observable
disruption should be when each PE undergoes the changes discussed in service disruption should be when each PE undergoes the changes
step 4 above.) discussed in step 4 above.)
4.2. Implementation 4.2. Implementation
The mechanism introduced in this section MUST be configurable on a The mechanism introduced in this section MUST be configurable on a
per-neighbor or per neighbor group basis to allow for maximum per-neighbor or per-neighbor-group basis to allow for maximum
flexibility. When configured with this mechanism, a BGP speaker MUST flexibility. When configured with this mechanism, a BGP speaker MUST
accept BGP OPEN and establish an iBGP session from configured iBGP accept BGP OPEN and establish an iBGP session from configured iBGP
peers if the ASN value in "My Autonomous System" is either the peers if the ASN value in "My Autonomous System" is either the
globally configured ASN or a locally configured ASN provided when globally configured ASN or a locally configured ASN provided when
this capability is utilized. Additionally, a BGP router configured this capability is utilized. Additionally, a BGP router configured
with this mechanism MUST send its own BGP OPEN [RFC4271] (see section with this mechanism MUST send its own BGP OPEN [RFC4271] (see
4.2) using either the globally configured or the locally configured Section 4.2) using either the globally configured or the locally
ASN in "My Autonomous System" as follows. To avoid potential configured ASN in "My Autonomous System" as follows. To avoid
deadlocks when two BGP speakers are attempting to establish a BGP potential deadlocks when two BGP speakers are attempting to establish
peering session and are both configured with this mechanism, the a BGP peering session and are both configured with this mechanism,
speaker SHOULD send BGP OPEN using the globally configured ASN first, the speaker SHOULD send BGP OPEN using the globally configured ASN
and only send a BGP OPEN using the locally configured ASN as a 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 fallback if the remote neighbor responds with the BGP error "Bad Peer
AS". In each case, the BGP speaker MUST treat UPDATEs sent and AS". In each case, the BGP speaker MUST treat UPDATEs sent and
received to this peer as if this was a natively configured iBGP received to this peer as if this was a natively configured iBGP
session, as defined by [RFC4271] and [RFC4456]. session, as defined by [RFC4271] and [RFC4456].
Note that this procedure will vary slightly if the locally or Note that this procedure will vary slightly if the locally or
globally configured ASN is a 4-octet ASN. See section 3 of globally configured ASN is a 4-octet ASN. See Section 3 of
[RFC4893]. [RFC6793].
5. Additional Operational Considerations 5. Additional Operational Considerations
This document describes several mechanisms to support ISPs and other This document describes several mechanisms to support ISPs and other
organizations that need to perform ASN migrations. Other variations organizations that need to perform ASN migrations. Other variations
of these mechanisms may exist, for example, in legacy router software of these mechanisms may exist, for example, in legacy router software
that has not been upgraded or reached End of Life, but continues to 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 operate in the network. Such variations are beyond the scope of this
document. document.
Companies routinely go through periods of mergers, acquisitions and Companies routinely go through periods of mergers, acquisitions, and
divestitures, which in the case of the former cause them to divestitures, which in the case of the former cause them to
accumulate several legacy ASNs over time. ISPs often do not have accumulate several legacy ASNs over time. ISPs often do not have
control over the configuration of customers' devices (i.e.: the ISPs control over the configuration of customers' devices (i.e., the ISPs
are often not providing a managed CE router service, particularly to are often not providing a managed CE router service, particularly to
medium and large customers that require eBGP). Furthermore, ISPs are medium and large customers that require eBGP). Furthermore, ISPs are
using methods to perform ASN migration that do not require using methods to perform ASN migration that do not require
coordination with customers. Ultimately, this means there is not a coordination with customers. Ultimately, this means there is not a
finite period of time after which legacy ASNs will be completely finite period of time after which legacy ASNs will be completely
expunged from the ISP's network. In fact, it is common that legacy expunged from the ISP's network. In fact, it is common that legacy
ASNs and the associated External BGP AS Migration mechanisms ASNs and the associated External BGP AS Migration mechanisms
discussed in this document can and do persist for several years, if discussed in this document can and do persist for several years, if
not longer. Thus, it is prudent to plan that legacy ASNs and not longer. Thus, it is prudent to plan that legacy ASNs and
associated External BGP AS Migration mechanisms will persist in a associated External BGP AS Migration mechanisms will persist in an
operational network indefinitely. operational network indefinitely.
With respect to the Internal BGP AS Migration mechanism, all of the With respect to the Internal BGP AS Migration mechanism, all of the
routers to be consolidated into a single, permanently retained ASN routers to be consolidated into a single, permanently retained ASN
are under the administrative control of a single entity. Thus, are under the administrative control of a single entity. Thus,
completing the migration from iBGP sessions using the legacy ASN to completing the migration from iBGP sessions using the legacy ASN to
the permanently retained ASN is more straightforward and could be the permanently retained ASN is more straightforward and could be
accomplished in a matter of days to months. Finally, good accomplished in a matter of days to months. Finally, good
operational hygiene would dictate that it is good practice to avoid operational hygiene would dictate that it is good practice to avoid
using "Internal BGP AS Migration" capability over a long period of using "Internal BGP AS Migration" capability over a long period of
time for reasons of not only operational simplicity of the network, time for reasons of not only operational simplicity of the network,
but also reduced reliance on that mechanism during the ongoing but also reduced reliance on that mechanism during the ongoing life
lifecycle management of software, features and configurations that cycle management of software, features, and configurations that are
are maintained on the network. maintained on the network.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations 6. Security Considerations
This draft discusses a process by which one ASN is migrated into and This document discusses a process by which one ASN is migrated into
subsumed by another. This involves manipulating the AS_PATH and subsumed by another. This involves manipulating the AS_PATH
Attribute with the intent of not increasing the AS_PATH length, which 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 would typically cause the BGP route to no longer be selected by BGP's
Path Selection Algorithm in others' networks. This could result in Path Selection Algorithm in others' networks. This could result in
sudden and unexpected shifts in traffic patterns in the network, sudden and unexpected shifts in traffic patterns in the network,
potentially resulting in congestion. potentially resulting in congestion.
Given that these mechanisms can only be enabled through configuration Given that these mechanisms can only be enabled through configuration
of routers within a single network, standard security measures should of routers within a single network, standard security measures should
be taken to restrict access to the management interface(s) of routers be taken to restrict access to the management interface(s) of routers
that implement these mechanisms. Additionally, BGP sessions SHOULD that implement these mechanisms. Additionally, BGP sessions SHOULD
be protected using TCP Authentication Option [RFC5925] and the be protected using TCP Authentication Option [RFC5925] and the
Generalized TTL Security Mechanism [RFC5082] Generalized TTL Security Mechanism [RFC5082]
8. Acknowledgements 7. References
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.
9. References
9.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Protocol 4 (BGP-4)", RFC 4271, January 2006. 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 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006. (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<http://www.rfc-editor.org/info/rfc4456>.
9.2. Informative References 7.2. Informative References
[ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, [ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012,
<https://infoproducts.alcatel-lucent.com/html/0_add- <https://infoproducts.alcatel-lucent.com/html/0_add-h-f/
h-f/93-0074-10-01/7750_SR_OS_Routing_Protocols_Guide/BGP- 93-0074-10-01/7750_SR_OS_Routing_Protocols_Guide/
CLI.html#709567>. BGP-CLI.html#709567>.
[CISCO] Cisco Systems, Inc., "BGP Support for Dual AS [CISCO] Cisco Systems, Inc., "BGP Support for Dual AS
Configuration for Network AS Migrations", 2003, Configuration for Network AS Migrations", 2013,
<http://www.cisco.com/c/en/us/td/docs/ios- <http://www.cisco.com/c/en/us/td/docs/ios-xml/
xml/ios/iproute_bgp/configuration/xe-3s/asr1000/ ios/iproute_bgp/configuration/xe-3s/asr1000/
irg-xe-3s-asr1000-book/irg-dual-as.html>. irg-xe-3s-asr1000-book/irg-dual-as.html>.
[JUNIPER] Juniper Networks, Inc., "Configuring the BGP Local [JUNIPER] Juniper Networks, Inc., "Understanding the BGP Local AS
Autonomous System Attribute", 2012, Attribute", December 2013,
<http://www.juniper.net/techpubs/en_US/junos13.3/topics/ <http://www.juniper.net/techpubs/en_US/junos13.3/topics/
concept/bgp-local-as-introduction.html>. concept/bgp-local-as-introduction.html>.
[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 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, August 2007. 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., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (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 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for
Documentation Use", RFC 5398, December 2008. 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 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. 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 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for
Private Use", BCP 6, RFC 6996, July 2013. Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July
2013, <http://www.rfc-editor.org/info/rfc6996>.
Appendix A. Implementation report Appendix A. Implementation Report
As noted elsewhere in this document, this set of migration mechanisms As noted elsewhere in this document, this set of migration mechanisms
has multiple existing implementations in wide use. has multiple existing implementations in wide use.
o Cisco [CISCO] o Cisco [CISCO]
o Juniper [JUNIPER] o Juniper [JUNIPER]
o Alcatel-Lucent [ALU] o Alcatel-Lucent [ALU]
This is not intended to be an exhaustive list, as equivalent features This is not intended to be an exhaustive list, as equivalent features
do exist in other implementations, however the authors were unable to do exist in other implementations; however, the authors were unable
find publicly available documentation of the vendor-specific to find publicly available documentation of the vendor-specific
implementation to reference. 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 Authors' Addresses
Wesley George Wesley George
Time Warner Cable Time Warner Cable
13820 Sunrise Valley Drive 13820 Sunrise Valley Drive
Herndon, VA 20171 Herndon, VA 20171
US United States
Phone: +1 703-561-2540 Phone: +1 703-561-2540
Email: wesley.george@twcable.com Email: wesley.george@twcable.com
Shane Amante Shane Amante
Apple, Inc. Apple, Inc.
1 Infinite Loop 1 Infinite Loop
Cupertino, CA 95014 Cupertino, CA 95014
US United States
Email: samante@apple.com Email: amante@apple.com
 End of changes. 85 change blocks. 
237 lines changed or deleted 241 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/