draft-ietf-idr-as-migration-03.txt   draft-ietf-idr-as-migration-04.txt 
Internet Engineering Task Force W. George Internet Engineering Task Force W. George
Internet-Draft Time Warner Cable Internet-Draft Time Warner Cable
Intended status: Standards Track S. Amante Intended status: Standards Track S. Amante
Expires: April 2, 2015 Apple, Inc. Expires: October 11, 2015 Apple, Inc.
September 29, 2014 April 9, 2015
Autonomous System Migration Features and Their Effects on the BGP Autonomous System Migration Mechanisms and Their Effects on the BGP
AS_PATH Attribute AS_PATH Attribute
draft-ietf-idr-as-migration-03 draft-ietf-idr-as-migration-04
Abstract Abstract
This draft discusses some BGP features for ASN migration that, while This draft discusses some commonly-used BGP mechanisms for ASN
commonly used, are not formally part of the BGP4 protocol migration that are not formally part of the BGP4 protocol
specification and may be vendor-specific in exact implementation. It specification and may be vendor-specific in exact implementation. It
is necessary to document these de facto standards to ensure that they is necessary to document these de facto standards to ensure that they
are properly supported in future BGP protocol work such as BGPSec. are properly supported in future BGP protocol work.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 2, 2015. This Internet-Draft will expire on October 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . 4 2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3
3. External BGP Autonomous System Migration Features . . . . . . 6 3. External BGP Autonomous System Migration Mechanisms . . . . . 5
3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 6 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 Features . . . . . . 9 4. Internal BGP Autonomous System Migration Mechanisms . . . . . 9
4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 10 4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 9
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12
5. Additional Operational Considerations . . . . . . . . . . . . 13 5. Additional Operational Considerations . . . . . . . . . . . . 13
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Appendix: Implementation report . . . . . . . . . . . . . . . 14
10. Appendix: Implementation report . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This draft discusses some BGP features for ASN migration that, while This draft discusses some commonly-used BGP mechanisms for Autonomous
commonly used, are not formally part of the BGP4 [RFC4271] protocol System Number (ASN) migration that are not formally part of the BGP4
specification and may be vendor-specific in exact implementation. [RFC4271] protocol specification and may be vendor-specific in exact
These features are local to a given BGP Speaker and do not require implementation. These mechanisms are local to a given BGP Speaker
negotiation with or cooperation of BGP neighbors. The deployment of and do not require negotiation with or cooperation of BGP neighbors.
these features do not need to interwork with one another to The deployment of these mechanisms do not need to interwork with one
accomplish the desired results, so slight variations between existing another to accomplish the desired results, so slight variations
vendor implementations exist, and will not necessarily be harmonized between existing vendor implementations exist, and will not
due to this document. However, it is necessary to document these de necessarily be harmonized due to this document. However, it is
facto standards to ensure that new implementations can be successful, necessary to document these de facto standards to ensure that new
and any future protocol enhancements to BGP that propose to read, implementations can be successful, and any future protocol
copy, manipulate or compare the AS_PATH attribute can do so without enhancements to BGP that propose to read, copy, manipulate or compare
inhibiting the use of these very widely used ASN migration features. the AS_PATH attribute can do so without inhibiting the use of these
very widely used ASN migration mechanisms.
The migration features 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 features 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, it is common practice in the industry combined network. In addition, given that the BGP Path Selection
for ISPs to bill customers based on utilization. ISPs bill customers algorithm selects routes with the shortest AS_PATH attribute, it is
based on the 95th percentile of the greater of the traffic sent or critical that the ISP does not increase AS_PATH length during or
received, over the course of a 1-month period, on the customer's after ASN migration, because an increased AS_PATH length would likely
access circuit. Given that the BGP Path Selection algorithm selects result in sudden, undesirable changes in traffic patterns in the
routes with the shortest AS_PATH attribute, it is critical that the network.
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 would not only result in sudden changes in traffic patterns in
the network, but also substantially decrease utilization driven
revenue at the ISP.
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 features, it would have required an ISP to coordinate these migration mechanisms, it would have required an ISP to
an ASN change with, in some cases, tens of thousands of customers. coordinate an ASN change with, in some cases, tens of thousands of
In particular, as each router is migrated to the new ASN, to avoid an customers. In particular, as each router is migrated to the new ASN,
outage due to ASN mismatch, the ISP would have to force all customers to avoid an outage due to ASN mismatch, the ISP would have to force
on that router to change their router configurations to use the new all customers on that router to change their router configurations to
ASN immediately after the ASN change. Thus, it becomes critical to use the new ASN immediately after the ASN change. Thus, it becomes
allow the ISP to make this process a bit more asymmetric, so that it critical to allow the ISP to make this process a bit more asymmetric,
could seamlessly migrate the ASN within its network(s), but allow the so that it could seamlessly migrate the ASN within its network(s),
customers to gradually migrate to the ISP's new ASN at their leisure, but allow the customers to gradually migrate to the ISP's new ASN at
either by coordinating individual reconfigurations, or accepting their leisure, either by coordinating individual reconfigurations, or
sessions using either the old or new ASN to allow for truly accepting sessions using either the old or new ASN to allow for truly
asymmetric migration. asymmetric migration.
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
skipping to change at page 5, line 30 skipping to change at page 5, line 11
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 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, 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 router will no longer be able to establish eBGP sessions toward
the existing Customer Edge (CE) devices that are attached to it and 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 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 coordinating the simultaneous change of its ASN with all of its eBGP
peers, ISP B will configure two separate, but related ASN migration peers, ISP B will configure two separate, but related ASN migration
features discussed in this document on all eBGP sessions toward all mechanisms discussed in this document on all eBGP sessions toward all
CE devices. These features enable the router to establish BGP CE devices. These mechanisms enable the router to establish BGP
neighbors using the legacy ASN, modify the AS_PATH attribute received neighbors using the legacy ASN, modify the AS_PATH attribute received
from a CE device when advertising it further, and modify AS_PATH when from a CE device when advertising it further, and modify AS_PATH when
transmitted toward CE devices to achieve the desired effect of not transmitted toward CE devices to achieve the desired effect of not
increasing the length of the AS_PATH. 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 RFC 5065
[RFC5065] internally. [RFC5065] internally.
There are multiple implementations with equivalent features deployed 3. External BGP Autonomous System Migration Mechanisms
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
The following section addresses features that are specific to The following section addresses optional capabilities that are
modifying the AS_PATH attribute at the Autonomous System Border specific to modifying the AS_PATH attribute at the Autonomous System
Routers (ASBRs) of an organization, (typically a single Service Border Routers (ASBRs) of an organization, (typically a single
Provider). This ensures that external BGP customers/peers are not Service Provider). This ensures that external BGP customers/peers
forced to make any configuration changes on their CE routers before are not forced to make any configuration changes on their CE routers
or during the exact time the Service Provider wishes to migrate to a before or during the exact time the Service Provider wishes to
new, permanently retained ASN. Furthermore, these features eliminate migrate to a new, permanently retained ASN. Furthermore, these
the artificial lengthening of the AS_PATH both transmitted from and mechanisms eliminate the artificial lengthening of the AS_PATH both
received by the Service Provider that is undergoing AS Migration, transmitted from and received by the Service Provider that is
which would have negative implications on path selection by external undergoing AS Migration, which would have negative implications on
networks. path selection by external networks.
3.1. Modify Inbound BGP AS_PATH Attribute 3.1. Modify Inbound BGP AS_PATH Attribute
The first feature used in the process described above is called The first instrument used in the process described above is called
"Local AS". This feature allows the PE router that was formerly in "Local AS". This allows the router to supersede the globally
ISP B to re-establish an eBGP session toward the existing CE devices configured ASN in the "My Autonomous System" field of the BGP OPEN
using the legacy AS, AS 64510. Ultimately, the CE devices (i.e.: [RFC4271] with a locally defined AS value, usually configured on a
customer C) are completely unaware that ISP B has reconfigured its per-neighbor basis. This mechanism allows the PE router that was
router to participate as a member of a new AS. Within the context of formerly in ISP B to establish an eBGP session toward the existing CE
the former ISP B PE router, the second effect this feature has on devices using the legacy AS, AS 64510. Ultimately, the CE devices
AS_PATH is that, by default, it prepends all received BGP UPDATEs (i.e.: customer C) are completely unaware that ISP B has reconfigured
with the legacy AS of ISP B: AS 64510, while advertising it (Adj-RIB- its router to participate as a member of a new AS. Within the
Out) to other BGP speakers (A'). Within Loc-RIB on ISP B prior to context of the former ISP B PE router, the second effect this
the migration, the AS_PATH toward customer C would appear as: 64510, specific mechanism has on AS_PATH is that, by default, it prepends
whereas the same RIB on ISP A' (ISP B routers post-migration) would all received BGP UPDATEs with the legacy AS of ISP B: AS 64510, while
contain AS_PATH: 64510 64496. To avoid changes to the AS_PATH advertising it (Adj-RIB-Out) to other BGP speakers (A'). Within the
length, a secondary feature "No Prepend" is added to the "Local AS" Loc-RIB on ISP B prior to the migration, the AS_PATH toward customer
configuration toward every eBGP neighbor on PE routers migrating from C would appear as: 64510, whereas the same RIB on ISP A' (ISP B
ISP B. The "No Prepend" feature causes those routers to not prepend routers post-migration) would contain AS_PATH: 64510 64496.
the legacy AS, AS 64510, when advertising UPDATES received from
customer C. This restores the AS_PATH within ISP A' toward customer A second instrument, referred to as "No Prepend Inbound", is enabled
C so that it is just one ASN in length: 64496. on PE routers migrating from ISP B. The "No Prepend Inbound"
capability causes ISP B's routers to not prepend the legacy AS, AS
64510, when advertising UPDATES received from customer C. This
restores the AS_PATH within ISP A' toward customer C so that it is
just one ASN in length: 64496.
In the direction of CE -> PE (inbound): In the direction of CE -> PE (inbound):
1. 'local-as <old_ASN>': prepends the <old_ASN> value to the AS_PATH 1. "Local AS": Allows the local BGP router to generate a BGP OPEN to
when advertising routes received from the CE an eBGP neighbor with the old, legacy ASN value in the "My
Autonomous System" field. When this capability is activated, it
also causes the local router to prepend the <old_ASN> value to
the AS_PATH when advertising routes received from a CE to iBGP
neighbors inside the Autonomous System.
2. 'local-as <old_ASN> no-prepend': does not prepend <old_ASN> value 2. "No Prepend Inbound (of Local AS)": the local BGP router does not
to the AS_PATH when advertising routes received from the CE 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 PE-B is a PE that was originally in ISP B, and has a customer eBGP
CE-B. PE-B has had its global configuration ASN changed from AS session to CE-B. PE-B has had its global configuration ASN changed
64510 to AS 64500 to make it part of the permanently retained ASN. from AS 64510 to AS 64500 to make it part of the permanently retained
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 BGP UPDATE Diagram 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 the "Local AS No Prepend" configuration, on PE-B, CE-A As a result using both the "Local AS" and "No Prepend Inbound"
will see an AS_PATH of: 64500 64496. CE-A will not receive a BGP capabilities on PE-B, CE-A will see an AS_PATH of: 64500 64496. CE-A
UPDATE containing AS 64510 in the AS_PATH. (If only the "local-as will not receive a BGP UPDATE containing AS 64510 in the AS_PATH.
64510" feature was configured without the keyword "no-prepend" on PE- (If only the "Local AS" mechanism was configured without "No Prepend
B, then CE-A would see an AS_PATH of: 64496 64510 64500, which Inbound" on PE-B, then CE-A would have seen an AS_PATH of: 64496
results in an unacceptable lengthening of the AS_PATH). 64510 64500, which results in an unacceptable lengthening of the
AS_PATH).
3.2. Modify Outbound BGP AS_PATH Attribute 3.2. Modify Outbound BGP AS_PATH Attribute
The previous feature, "Local AS No Prepend", was designed to modify The two aforementioned mechanisms, "Local AS" and "No Prepend
the AS_PATH Attribute received by the ISP in updates from CE devices, Inbound", only modify the AS_PATH Attribute received by the ISP's
when CE devices still have an eBGP session established with the ISPs PE's in the course of processing BGP UPDATEs from CE devices when CE
legacy AS, (AS64510). In some existing implementations, "Local AS No devices still have an eBGP session established with the ISPs legacy
Prepend" does not concurrently modify the AS_PATH Attribute for BGP AS, (AS64510).
UPDATEs that are transmitted by the ISP to CE devices. Specifically,
with "Local AS No Prepend" enabled on 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 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 to resolve this problem (continuing the In some existing implementations, "Local AS" and "No Prepend Inbound"
use of Cisco CLI in the examples, it is called "Replace AS" in the does not concurrently modify the AS_PATH Attribute for BGP UPDATEs
examples below). This feature allows ISP A' to prevent routers that are transmitted by the ISP's PE's to CE devices. In these
configured with this feature from appending the global configured AS implementations, with "Local AS" and "No Prepend Inbound" used on PE-
in outbound BGP UPDATEs toward its customer's networks configured B, it automatically causes a lengthening of the AS_PATH in outbound
with the "Local AS" feature. Instead, only the historical (or BGP UPDATEs from ISP A' toward directly attached eBGP speakers,
legacy) AS will be prepended in the outbound BGP UPDATE toward the (Customer C in AS 64496). The externally observed result is that
customer's network, restoring the AS_PATH length to what it what was customer C, in AS 64496, will receive the following AS_PATH: 64510
before AS Migration occurred. 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 tertiary mechanism is used to resolve this problem, referred to as
"Replace Old AS". This capability allows ISP A' to prevent routers
from appending the globally configured ASN in outbound BGP UPDATEs
toward directly attached eBGP neighbors that are using the "Local AS"
mechanism. Instead, only the old (or previously used) AS will be
prepended in the outbound BGP UPDATE toward the customer's network,
restoring the AS_PATH length to what it what was before AS Migration
occurred.
To re-use the above diagram, but in the opposite direction, we have: To re-use 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
The final configuration on PE-B after completing the "Replace AS" By default, without the use of "Replace Old AS", CE-B would see an
portion of the AS migration is as follows: AS_PATH of: 64510 64500 64499, which is artificially lengthened,
typically by use of the "Local AS" and/or "No Prepend" capabilities
during the course of the ASN Migration. After ISP A' changes PE-B to
use "Replace Old AS", CE-B would receive an AS_PATH of: 64510 64499,
which is the same AS_PATH length pre-AS migration. NOTE: If there
are still routers in the old ASN, it is possible for them to accept
these manipulated routes as if they have not already passed through
their ASN, potentially causing a loop, since BGP's normal loop-
prevention behavior of rejecting routes that include its ASN in the
path will not catch these. Careful filtering between routers
remaining in the old ASN and routers migrated to the new ASN is
necessary to minimize the risk of routing loops.
router bgp 64500 3.3. Implementation
neighbor <CE-B_IP> remote-as 64496
neighbor <CE-B_IP> local-as 64510 no-prepend replace-as
By default, without "Replace AS" enabled, CE-B would see an AS_PATH While multiple implementations already exist, the following documents
of: 64510 64500 64499, which is artificially lengthened by the ASN the expected behavior such that a new implementation of this
Migration. After ISP A' changes PE-B to include the "Replace AS" mechanism could be done on other platforms.
feature, CE-B would receive an AS_PATH of: 64510 64499, which is the
same AS_PATH length pre-AS migration.
3.3. Implementation These mechanisms MUST be configurable on a per-neighbor or per peer-
group basis to allow for maximum flexibility. When the "Local AS"
capability is used, a local ASN will be provided in the configuration
that is different from the globally-configured ASN of the BGP router.
To implement this mechanism, a BGP speaker MUST send BGP OPEN
[RFC4271] (see section 4.2) messages to the configured eBGP peer(s)
using the local ASN configured for this session as the value sent in
"My Autonomous System". The BGP router MUST NOT use the ASN
configured globally within the BGP process as the value sent in "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". 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.
While multiple implementations already exist, the following should Implementations MAY support a more flexible model where the eBGP
document the expected behavior such that a new implementation of this speaker attempts to open the BGP session using either the ASN
feature could be done on other platforms. configured as "Local AS" or the globally configured AS as discussed
in BGP Alias (Section 4.2). If the session is successfully
established to the globally configured ASN, then the modifications to
AS_PATH described in this document SHOULD NOT be performed, as they
are unnecessary. The benefit to this more flexible model is that it
allows the remote neighbor to reconfigure to the new ASN without
direct coordination between the ISP and the customer.
These features MUST be configurable on a per-neighbor or per peer- When the BGP router receives UPDATEs from its eBGP neighbor
group basis to allow for maximum flexibility. When this feature set configured with the "Local AS" mechanism, it processes the UPDATE as
is invoked, an ASN that is different from the globally-configured ASN described in RFC4271 section 5.1.2 [RFC4271]. However the presence
is provided as a part of the command as exemplified above. To of a second ASN due to "Local AS" adds the following behavior to
implement this feature, a BGP speaker MUST send BGP OPEN messages to processing UPDATEs received from an eBGP neighbor configured with
the configured eBGP peer using the ASN configured for this session as this mechanism:
the value sent in MY ASN. The speaker MUST NOT use the ASN
configured globally within the BGP process as the value sent in MY
ASN in the OPEN message. This will avoid the BGP OPEN Error message
BAD PEER AS, and 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 the BGP speaker configured with this feature
receives updates from its neighbor, it MUST process the update as
normal, but it MUST append the configured ASN in the AS_PATH
attribute before advertising the UPDATE to any other BGP speaker.
Note that processing the update as normal will include appending the
globally configured ASN to the AS_PATH, thus processing this update
will result in the addition of two ASNs to the AS_PATH attribute.
Similarly, for outbound updates sent by the configured BGP speaker to
its neighbor, the speaker MUST append the configured ASN to the
AS_PATH attribute, adding to the existing global ASN in the AS_PATH,
for a total of two ASNs added to the AS_PATH.
Two options exist to manipulate the behavior of this feature. They 1. Internal: the router MUST append the configured "Local AS" ASN in
modify the behavior as described below: the AS_PATH attribute before advertising the UPDATE to an iBGP
neighbor.
No prepend inbound - When the BGP speaker configured with this option 2. External: the BGP router MUST first append the globally
receives inbound updates from its neighbor, it MUST NOT append the configured ASN to the AS_PATH immediately followed by the "Local
configured ASN in the AS_PATH attribute when advertising that UPDATE AS" value before advertising the UPDATE to an eBGP neighbor.
to other peers and instead MUST append only the globally configured
ASN.
No prepend outbound - When the BGP speaker configured with this Two options exist to manipulate the behavior of the basic "Local AS"
option generates outbound BGP updates to the configured peer, the BGP mechanism. They modify the behavior as described below:
speaker MUST remove the globally configured ASN from the AS_PATH
attribute, and MUST append the locally configured ASN 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 1. "No Prepend Inbound" - When the BGP router receives inbound BGP
scope of this document, the following consideration may be helpful UPDATEs from its eBGP neighbor configured with this option, it
for implementers: Implementations MAY integrate the behavior of the MUST NOT append the "Local AS" ASN value in the AS_PATH attribute
options described above into a single command that addresses both when advertising that UPDATE to iBGP neighbors, but it MUST still
inbound and outbound updates, but if this is done, implementations append the globally configured ASN as normal when advertising the
MUST provide a method to select its applicability to inbound updates, UPDATE to other local eBGP neigbors (i.e. those natively peering
outbound updates, or updates in both directions. Several existing with the globally configured ASN).
implementations use separate commands (e.g. local-as no-prepend vs
local-as replace-as) for maximum flexibility in controlling the
behavior on the session to address the widest range of possible
migration scenarios.
4. Internal BGP Autonomous System Migration Features 2. "Replace Old AS", (outbound) - When the BGP router generates
outbound BGP UPDATEs toward an eBGP neighbor configured with this
option, the BGP speaker MUST NOT (first) append the globally
configured ASN from the AS_PATH attribute. The BGP router MUST
append only the configured "Local AS" ASN value to the AS_PATH
attribute before sending the BGP UPDATEs outbound to the eBGP
neighbor.
The following section describes features that assist with a gradual 4. Internal BGP Autonomous System Migration Mechanisms
The following section describes mechanisms that assist with a gradual
and least service impacting migration of Internal BGP sessions from a and least service impacting migration of Internal BGP sessions from a
legacy ASN to the permanently retained ASN. The following feature is legacy ASN to the permanently retained ASN. The following mechanism
very valuable to networks undergoing AS migration, but its use does is very valuable to networks undergoing AS migration, but its use
not cause changes to the AS_PATH attribute. does not cause changes to the AS_PATH attribute.
4.1. Internal BGP Alias 4.1. Internal BGP Alias
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 speakers. networks with with more than a few dozen internal BGP routers. There
There is also the concomitant service interruptions as these changes is also the concomitant service interruptions as these changes are
are made to routers within the network, resulting in a reset of iBGP made to routers within the network, resulting in a reset of iBGP
sessions and subsequent route reconvergence to reestablish optimal sessions and subsequent route reconvergence to reestablish optimal
routing paths. Operators often cannot make such sweeping changes routing paths. Operators often cannot make such sweeping changes
given the associated risks of a highly visible service interruption; given the associated risks of a highly visible service interruption;
rather, they require a more gradual method to migrate Internal BGP rather, they require a more gradual method to migrate Internal BGP
sessions, from one ASN to a second, permanently retained ASN, that is sessions, from one ASN to a second, permanently retained ASN, that is
not visibly service-impacting to its customers. not visibly service-impacting to its customers.
With the "Internal BGP Alias" [JUNIPER] feature, it allows an With the "Internal BGP AS Migration" mechanism described herein, it
Internal BGP speaker to form a single iBGP session using either the allows an Internal BGP speaker to form a single iBGP session using
old, legacy ASN or the new, permanently retained ASN. The benefits either the old, legacy ASN or the new, permanently retained ASN. The
of using this feature are several fold. First, it allows for a more benefits of using this mechanism are several fold. First, it allows
gradual and less service-impacting migration away from the legacy ASN for a more gradual and less service-impacting migration away from the
to the permanently retained ASN. Second, it (temporarily) permits legacy ASN to the permanently retained ASN. Second, it (temporarily)
the coexistence of the legacy and permanently retained ASN within a permits the coexistence of the legacy and permanently retained ASN
single network, allowing for uniform BGP path selection among all within a single network, allowing for uniform BGP path selection
routers within the consolidated network. NB: Cisco doesn't have an among all routers within the consolidated network.
exact equivalent to "Internal BGP Alias", but the combination of the
Cisco features iBGP local-AS and dual-as provides similar
functionality.
When the "Internal BGP Alias" feature is enabled, typically just on The iBGP router with the "Internal BGP AS Migration" capability
one side of a iBGP session, it allows that iBGP speaker to establish enabled allows the receipt of a BGP OPEN message with either the
a single iBGP session with either the legacy ASN or the new, legacy ASN value or the new, globally configured ASN value in the "My
permanently retained ASN, depending on which one it receives in the Autonomous System" field of the BGP OPEN message from iBGP neighbors.
"My Autonomous System" field of the BGP OPEN message from its iBGP It is important to recognize that enablement of the "Internal BGP AS
session neighbor. It is important to recognize that enablement of Migration" mechanism preserves the semantics of a regular iBGP
the "Internal BGP Alias" feature preserves the semantics of a regular session, (using identical ASNs). Thus, the BGP attributes
iBGP session, (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
Alias" are no different than those exchanged across an iBGP session AS Migration" capability are no different than those exchanged across
without "Internal BGP Alias" configured, as defined by [RFC4271] and an iBGP session without "Internal BGP AS Migration" configured, as
[RFC4456]. defined by [RFC4271] and [RFC4456].
Typically, in medium to large networks, BGP Route Reflectors Typically, in medium to large networks, BGP Route Reflectors
[RFC4456] (RRs) are used to aid in reduction of configuration of iBGP [RFC4456] (RRs) 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 speakers. 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 Reflectors to aid in understanding the use of the "Internal BGP AS
Alias" feature. Note that Route Reflectors are not a prerequisite to Migration" mechanism. Note that Route Reflectors are not a
enable "Internal BGP Alias" and this feature can be enabled prerequisite to enable "Internal BGP AS Migration" and this mechanism
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:
1. Within the legacy network, (the routers comprising the set of 1. Within the legacy network, (the routers comprising the set of
devices that still have a globally configured legacy ASN), one devices that still have a globally configured legacy ASN), one
member of a redundant pair of RRs has its global configuration member of a redundant pair of RRs has its global configuration
ASN changed to the permanently retained ASN. Concurrently, ASN changed to the permanently retained ASN. Concurrently, the
"Internal BGP Alias" is configured on all iBGP sessions. This "Internal BGP AS Migration" capability is enabled on all iBGP
will comprise Non-Client iBGP sessions to other RRs as well as sessions on that device. This will comprise Non-Client iBGP
Client iBGP sessions, typically to PE devices, both still sessions to other RRs as well as Client iBGP sessions, typically
utilizing the legacy ASN. Note that during this step there will to PE devices, both still utilizing the legacy ASN. Note that
be a reset and reconvergence event on all iBGP sessions on the during this step there will be a reset and reconvergence event on
RRs whose configuration was modified; however, this should not be all iBGP sessions on the RRs whose configuration was modified;
service impacting due to the use of redundant RRs in each RR however, this should not be service impacting due to the use of
Cluster. redundant RRs in each RR Cluster.
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
"Internal BGP Alias" is now removed from the Non-Client iBGP the "Internal BGP AS Migration" mechanism is now removed from the
sessions toward the other (previously reconfigured) RRs, since it Non-Client iBGP sessions toward the other (previously
is no longer needed. "Internal BGP Alias" is still required on reconfigured) RRs, since it is no longer needed. The "Internal
all RRs for all RR Client iBGP sessions. Also during this step, BGP AS Migration" mechanism is still required on all RRs for all
there will be a reset and reconvergence event on all iBGP RR Client iBGP sessions. Also during this step, there will be a
sessions whose configuration was modified, but this should not be reset and reconvergence event on all iBGP sessions whose
service impacting. At the conclusion of this step, all RRs configuration was modified, but this should not be service
should now have their globally configured ASN set to the impacting. At the conclusion of this step, all RRs should now
permanently retained ASN and "Internal BGP Alias" enabled and in have their globally configured ASN set to the permanently
use toward RR Clients. retained ASN and "Internal BGP AS Migration" enabled and in use
toward RR Clients.
3. At this point, the network administrators would then be able to 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 used by ASN changed to use the permanently retained ASN. The ASN
the PE for the iBGP sessions toward each RR would be changed to configured within the PE for the iBGP sessions toward each RR
use the permanently retained ASN. (It is unnecessary to enable would be changed to use the permanently retained ASN. It is
"Internal BGP Alias" on the migrated iBGP sessions). During the unnecessary to enable "Internal BGP AS Migration" mechanism on
same maintenance window, External BGP sessions would be modified these migrated iBGP sessions. During the same maintenance
to include the above "Local AS No Prepend" and "Replace-AS" window, External BGP sessions would be modified to include the
features described in Section 3 above, since all of the changes above "Local AS", "No Prepend" and "Replace Old AS" mechanisms
are service interrupting to the eBGP sessions of the PE. At this 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 point, all PEs will have been migrated to the permanently
retained ASN. retained ASN.
5. The final step is to excise the "Internal BGP Alias" 5. The final step is to excise the "Internal BGP AS Migration"
configuration from the first half of the legacy RR Client pair -- configuration from the Router Reflectors in an orderly fashion.
this will expunge "Internal BGP Alias" configuration from all After this is complete, all routers in the network will be using
devices in the network. After this is complete, all routers in the new, permanently retained ASN for all iBGP sessions with no
the network will be using the new, permanently retained ASN for vestiges of the legacy ASN on any iBGP sessions.
all iBGP sessions with no vestiges of the legacy ASN on any iBGP
sessions.
The benefit of using "Internal BGP Alias" is that it is a more The benefit of using the aforementioned "Internal BGP AS Migration"
gradual and less externally service-impacting change to accomplish an capability is that it is a more gradual and less externally service-
AS migration. Previously, without "Internal BGP Alias", such an AS impacting change to accomplish an AS migration. Previously, without
migration change would carry a high risk and need to be successfully "Internal BGP AS Migration", such an AS migration change would carry
accomplished in a very short timeframe (e.g.: at most several hours). a high risk and need to be successfully accomplished in a very short
In addition, it would likely cause substantial routing churn and timeframe (e.g.: at most several hours). In addition, it would
rapid fluctuations in traffic carried -- potentially causing periods likely cause substantial routing churn and rapid fluctuations in
of congestion and resultant packet loss -- during the period the traffic carried -- potentially causing periods of congestion and
configuration changes are underway to complete the AS Migration. On resultant packet loss -- during the period the configuration changes
the other hand, with "Internal BGP Alias", the migration from the are underway to complete the AS Migration. On the other hand, with
legacy ASN to the permanently retained ASN can occur over a period of "Internal BGP AS Migration", the migration from the legacy ASN to the
days or weeks with reduced customer disruption. (The only observable permanently retained ASN can occur over a period of days or weeks
service disruption should be when each PE undergoes the changes with reduced customer disruption. (The only observable service
discussed in step 4 above.) disruption should be when each PE undergoes the changes discussed in
step 4 above.)
4.2. Implementation 4.2. Implementation
When configured with this feature, a BGP speaker MUST accept BGP OPEN When configured with this mechanism, a BGP speaker MUST accept BGP
and establish an iBGP session from configured iBGP peers if the ASN OPEN and establish an iBGP session from configured iBGP peers if the
value in MY ASN is either the globally configured ASN or the locally ASN value in "My Autonomous System" is either the globally configured
configured ASN provided in this command. Additionally, a BGP speaker ASN or a locally configured ASN provided when this capability is
configured with this feature MUST send its own BGP OPEN using both utilized. Additionally, a BGP router configured with this mechanism
the globally configured and the locally configured ASN in MY ASN. To MUST send its own BGP OPEN [RFC4271] (see section 4.2) using both the
avoid potential deadlocks when two BGP speakers are attempting to globally configured and the locally configured ASN in "My Autonomous
establish a BGP peering session and are both configured with this System". To avoid potential deadlocks when two BGP speakers are
feature, the speaker SHOULD send BGP OPEN using the globally attempting to establish a BGP peering session and are both configured
configured ASN first, and only send a BGP OPEN using the locally with this mechanism, the speaker SHOULD send BGP OPEN using the
configured ASN as a fallback if the remote neighbor responds with the globally configured ASN first, and only send a BGP OPEN using the
BGP error BAD PEER ASN. In each case, the BGP speaker MUST treat locally configured ASN as a fallback if the remote neighbor responds
updates sent and received to this peer as if this was a natively with the BGP error "Bad Peer AS". In each case, the BGP speaker MUST
configured iBGP session, as defined by [RFC4271] and [RFC4456]. treat UPDATEs sent and received to this peer as if this was a
natively configured iBGP session, as defined by [RFC4271] and
Implementations of this feature MAY integrate the functionality from [RFC4456].
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 5. Additional Operational Considerations
This document describes several features 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 features 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 features discussed ASNs and the associated External BGP AS Migration mechanisms
in this document can and do persist for several years, if not longer. discussed in this document can and do persist for several years, if
Thus, it is prudent to plan that legacy ASNs and associated External not longer. Thus, it is prudent to plan that legacy ASNs and
BGP AS Migration features will persist in a operational network associated External BGP AS Migration mechanisms will persist in a
indefinitely. operational network indefinitely.
With respect to the Internal BGP AS Migration Features, 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 Alias" over a long period of time for reasons of using "Internal BGP AS Migration" capability over a long period of
not only operational simplicity of the network, but also reduced time for reasons of not only operational simplicity of the network,
reliance on that feature during the ongoing lifecycle management of but also reduced reliance on that mechanism during the ongoing
software, features and configurations that are maintained on the lifecycle management of software, features and configurations that
network. 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 6. Acknowledgements
Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson, Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson,
David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan
Alcaide, Jon Mitchell, and Thomas Morin for their comments. Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, and Alvaro Retana
for their comments.
8. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 8. Security Considerations
This draft discusses a process by which one ASN is migrated into and This draft discusses a process by which one ASN is migrated into and
subsumed by another. This involves manipulating the AS_PATH 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 a Path Selection Algorithm in others' networks. This could result in
loss of revenue if the ISP is billing based on measured utilization sudden and unexpected shifts in traffic patterns in the network,
of traffic sent to/from entities attached to its network. This could potentially resulting in congestion.
also result in sudden and unexpected shifts in traffic patterns in
the network, potentially resulting in congestion, in the most extreme
cases.
Given that these features 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 features. that implement these mechanisms. Additionally, BGP sessions SHOULD
be protected using TCP Authentication Option [RFC5925] and the
Generalized TTL Security Mechanism [RFC5082]
10. Appendix: Implementation report 9. Appendix: Implementation report
As noted elsewhere in this document, this set of migration features 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 to
find publicly available documentation of the vendor-specific find publicly available documentation of the vendor-specific
implementation to reference. implementation to reference.
11. References 10. References
11.1. Normative References 10.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, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Documentation Use", RFC 5398, December 2008. Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, April 2006.
11.2. Informative References 10.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/93-0074-10-01/7750_SR_OS_Routing_Protocols_Guide/BGP- h-f/93-0074-10-01/7750_SR_OS_Routing_Protocols_Guide/BGP-
CLI.html#709567>. 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", 2003,
<http://www.cisco.com/c/en/us/td/docs/ios- <http://www.cisco.com/c/en/us/td/docs/ios-
xml/ios/iproute_bgp/configuration/xe-3s/asr1000/ xml/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., "Configuring the BGP Local
Autonomous System Attribute", 2012, Autonomous System Attribute", 2012,
<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>.
[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 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, August 2007. 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 [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for
Private Use", BCP 6, RFC 6996, July 2013. Private Use", BCP 6, RFC 6996, July 2013.
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 US
 End of changes. 71 change blocks. 
370 lines changed or deleted 348 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/