draft-ietf-idr-as-migration-00.txt   draft-ietf-idr-as-migration-01.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: Informational S. Amante Intended status: Informational S. Amante
Expires: August 18, 2014 Apple, Inc. Expires: December 15, 2014 Apple, Inc.
February 14, 2014 June 13, 2014
Autonomous System (AS) Migration Features and Their Effects on the BGP Autonomous System (AS) Migration Features and Their Effects on the BGP
AS_PATH Attribute AS_PATH Attribute
draft-ietf-idr-as-migration-00 draft-ietf-idr-as-migration-01
Abstract Abstract
This draft discusses common methods of managing an ASN migration This draft discusses common methods of managing an ASN migration
using some BGP feaures that while commonly-used are not formally part using some BGP feaures that while commonly-used are not formally part
of the BGP4 protocol specification and may be vendor-specific in of the BGP4 protocol specification and may be vendor-specific in
exact implementation. It is necessary to document these de facto exact implementation. It is necessary to document these de facto
standards to ensure that they are properly supported in future BGP standards to ensure that they are properly supported in future BGP
protocol work such as BGPSec. protocol work such as BGPSec.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 August 18, 2014. This Internet-Draft will expire on December 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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. Documentation note . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3 1.2. Documentation note . . . . . . . . . . . . . . . . . . . 3
3. External BGP Autonomous System Migration Features . . . . . . 5 2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 4
3.1. Local AS: Modify Inbound BGP AS_PATH Attribute . . . . . 6 3. External BGP Autonomous System Migration Features . . . . . . 6
3.2. Replace AS: Modify Outbound BGP AS_PATH Attribute . . . . 7 3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 6
4. Internal BGP Autonomous System Migration Features . . . . . . 8 3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 8
4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 9 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 9
5. Additional Operational Considerations . . . . . . . . . . . . 11 4. Internal BGP Autonomous System Migration Features . . . . . . 10
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Additional Operational Considerations . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 10. Appendix: Implementation report . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This draft discusses common methods of managing an ASN migration This draft discusses common methods of managing an ASN migration
using some BGP features that while commonly-used are not formally using some BGP features that while commonly-used are not formally
part of the BGP4 [RFC4271] protocol specification and may be vendor- part of the BGP4 [RFC4271] protocol specification and may be vendor-
specific in exact implementation. This draft does not attempt to specific in exact implementation. These features are local to a
standardize these features, because they are local to a given given BGP Speaker and do not require negotiation with or cooperation
implementation and do not require negotiation with or cooperation of of BGP neighbors. The deployment of these features do not need to
BGP neighbors. The deployment of these features do not need to interwork with one another to accomplish the desired results, so
interwork with one another to accomplish the desired results. slight variations between existing vendor implementations exist.
However, it is necessary to document these de facto standards to However, it is necessary to document these de facto standards to
ensure that any future protocol enhancements to BGP that propose to ensure that any future protocol enhancements to BGP that propose to
read, copy, manipulate or compare the AS_PATH attribute can do so read, copy, manipulate or compare the AS_PATH attribute can do so
without inhibiting the use of these very widely used ASN migration without inhibiting the use of these very widely used ASN migration
features. features.
It is important to understand the business need for these features It is important to understand the business need for these features
and illustrate why they are critical, particularly for ISPs' and illustrate why they are critical, particularly for ISPs'
operations. However, these features are not limited to ISPs and operations. However, these features are not limited to ISPs and
organizations of all sizes use these features for similar reasons to organizations of all sizes use these features for similar reasons to
skipping to change at page 3, line 19 skipping to change at page 3, line 23
the course of a 1-month period, on the customer's PE-CE access the course of a 1-month period, on the customer's PE-CE access
circuit. Given that the BGP Path Selection algorithm selects routes circuit. Given that the BGP Path Selection algorithm selects routes
with the shortest AS_PATH attribute, it is critical for the ISP to with the shortest AS_PATH attribute, it is critical for the ISP to
not increase AS_PATH length during or after ASN migration, toward not increase AS_PATH length during or after ASN migration, toward
both downstream transit customers as well as settlement-free peers, both downstream transit customers as well as settlement-free peers,
who are likely sending or receiving traffic from those transit who are likely sending or receiving traffic from those transit
customers. This would not only result in sudden changes in traffic customers. This would not only result in sudden changes in traffic
patterns in the network, but also (substantially) decrease patterns in the network, but also (substantially) decrease
utilization driven revenue at the ISP. utilization driven revenue at the ISP.
Lastly, it is important to note that by default, the BGP protocol By default, the BGP protocol requires an operator to configure a
requires an operator to configure a single remote ASN for the eBGP single remote ASN for the eBGP neighbor inside a router, in order to
neighbor inside a router, in order to successfully negotiate and successfully negotiate and establish an eBGP session. Prior to the
establish an eBGP session. Prior to the existence of these features, existence of these features, it would have required an ISP to work
it would have required an ISP to work with, in some cases, tens of with, in some cases, tens of thousands of customers. In particular,
thousands of customers. In particular, the ISP would have to the ISP would have to encourage those customers to change their CE
encourage those customers to change their CE router configs to use router configs to use the new ASN in a very short period of time,
the new ASN in a very short period of time, when the customer has no when the customer has no business incentive to do so. Thus, it
business incentive to do so. Thus, it becomes critical to allow the becomes critical to allow the ISP to make this process a bit more
ISP to make this process a bit more asymmetric, so that it could asymmetric, so that it could seamlessly migrate the ASN within its
seamlessly migrate the ASN within its network(s), but not disturb network(s), but not disturb existing customers, and allow the
existing customers, and allow the customers to gradually migrate to customers to gradually migrate to the ISP's new ASN at their leisure.
the ISP's new ASN at their leisure.
1.1. Documentation note 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Documentation note
This draft uses Autonomous System Numbers (ASNs) from the range This draft 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 RFC 6996 [RFC6996]
section 10. section 10.
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,
skipping to change at page 5, line 22 skipping to change at page 5, line 44
the network are not aware of and do not observe any change in the the network are not aware of and do not observe any change in the
length of the AS_PATH attribute. However, after the changes length of the AS_PATH attribute. However, after the changes
discussed in this document are put in place by ISP A', there is a discussed in this document are put in place by ISP A', there is a
change to the contents of the AS_PATH attribute to ensure the AS_PATH change to the contents of the AS_PATH attribute to ensure the AS_PATH
is not artifically lengthened for the duration of time that these AS is not artifically lengthened for the duration of time that these AS
migration parameters are used. 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.
Additional information about this scenario, including vendor-specific There are multiple implementations with equivalent features deployed
implementation details can be found as follows: and in use. Some documentation pointers to these implementations, as
well as additional documentation on migration scenarios can be found
o Cisco [CISCO] in the appendix. The examples cited below use Cisco IOS CLI for ease
of illustration purposes only.
o Juniper [JUNIPER]
o Alcatel-Lucent [ALU]
Equivalent features do exist in other implementations, however the
authors were unable to find publicly available documentation of the
vendor-specific implementation to reference. Finally, the examples
cited below use Cisco IOS CLI for ease of illustration purposes only.
3. External BGP Autonomous System Migration Features 3. External BGP Autonomous System Migration Features
The following section addresses features that are specific to The following section addresses features that are specific to
modifying the AS_PATH attribute at the Autonomous System Border modifying the AS_PATH attribute at the Autonomous System Border
Routers (ASBRs) of an organization, (typically a single Service Routers (ASBRs) of an organization, (typically a single Service
Provider). This ensures that external BGP customers/peers are not Provider). This ensures that external BGP customers/peers are not
forced to make any configuration changes on their CE routers before forced to make any configuration changes on their CE routers before
or during the exact time the Service Provider wishes to migrate to a or during the exact time the Service Provider wishes to migrate to a
new, permanently retained ASN. Furthermore, these features eliminate new, permanently retained ASN. Furthermore, these features eliminate
the artificial lengthening of the AS_PATH both transmitted from and the artificial lengthening of the AS_PATH both transmitted from and
received by the Service Provider that is undergoing AS Migration, received by the Service Provider that is undergoing AS Migration,
which would have negative implications on path selection by external which would have negative implications on path selection by external
networks. networks.
3.1. Local AS: Modify Inbound BGP AS_PATH Attribute 3.1. Modify Inbound BGP AS_PATH Attribute
ISP B needs to reconfigure its router(s) to participate as an ISP B needs to reconfigure its router(s) to participate as an
internal BGP speaker in AS 64500, to realize the business goal of internal BGP speaker in AS 64500, to realize the business goal of
becoming a single Service Provider: ISP A'. ISP B needs to do this becoming a single Service Provider: ISP A'. ISP B needs to do this
without coordinating the change of its ASN with all of its eBGP without coordinating the change of its ASN with all of its eBGP
peers, simultaneously. The first step is for ISP B to change the peers, simultaneously. The first step is for ISP B to change the
global AS in its router configuration, used by the local BGP process global AS in its router configuration, used by the local BGP process
as the system-wide Autonomous System ID, from AS 64510 to AS 64500. as the system-wide Autonomous System ID, from AS 64510 to AS 64500.
The next step is for ISP B to establish iBGP sessions with ISP A's The next step is for ISP B to establish iBGP sessions with ISP A's
existing routers, thus consolidating ISP B into ISP A resulting in existing routers, thus consolidating ISP B into ISP A resulting in
skipping to change at page 7, line 8 skipping to change at page 7, line 23
Ultimately, this ensures that routes learned from ISP B's legacy Ultimately, this ensures that routes learned from ISP B's legacy
customers will be transmitted through legacy eBGP sessions of ISP A, customers will be transmitted through legacy eBGP sessions of ISP A,
toward both customers and peers, will contain only two AS'es in the toward both customers and peers, will contain only two AS'es in the
AS_PATH: 64500 64496. Thus, the legacy customers and peers of ISP A AS_PATH: 64500 64496. Thus, the legacy customers and peers of ISP A
will not see an increase in the AS_PATH length to reach ISP B's will not see an increase in the AS_PATH length to reach ISP B's
legacy customers. Ultimately, it is considered mandatory by legacy customers. Ultimately, it is considered mandatory by
operators that both the "Local AS" and "No Prepend" configuration operators that both the "Local AS" and "No Prepend" configuration
parameters always be used in conjunction with each other in order to parameters always be used in conjunction with each other in order to
ensure the AS_PATH length is not increased. ensure the AS_PATH length is not increased.
PE-1 is a PE that was originally in ISP B. PE-1 has had its global PE-1 is a PE that was originally in ISP B. PE-1 has had its global
configuration ASN changed from AS 64510 to AS 64500 to make it part configuration ASN changed from AS 64510 to AS 64500 to make it part
of the permanently retained ASN. This now makes PE-1 a member of ISP of the permanently retained ASN. This now makes PE-1 a member of ISP
A'. PE-2 is a PE that was originally in ISP A. Although its global A'. PE-2 is a PE that was originally in ISP A. Although its global
configuration ASN remains AS 64500, throughout this exercise we also configuration ASN remains AS 64500, throughout this exercise we also
consider PE-2 a member of ISP A'. consider PE-2 a member of ISP A'.
ISP A' ISP A' ISP A' ISP A'
CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2 CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2
64496 Old_ASN: 64510 New_ASN: 64500 64499 64496 Old_ASN: 64510 New_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
Note: Direction of BGP UPDATE as per the arrows. Note: Direction of BGP UPDATE as per the arrows.
skipping to change at page 7, line 34 skipping to change at page 7, line 49
The final configuration on PE-1 after completing the "Local AS" The final configuration on PE-1 after completing the "Local AS"
portion of the AS migration is as follows: portion of the AS migration is as follows:
router bgp 64500 router bgp 64500
neighbor <CE-1_IP> remote-as 64496 neighbor <CE-1_IP> remote-as 64496
neighbor <CE-1_IP> local-as 64510 no-prepend neighbor <CE-1_IP> local-as 64510 no-prepend
As a result of the "Local AS No Prepend" configuration, on PE-1, CE-2 As a result of the "Local AS No Prepend" configuration, on PE-1, CE-2
will see an AS_PATH of: 64500 64496. CE-2 will not receive a BGP will see an AS_PATH of: 64500 64496. CE-2 will not receive a BGP
UPDATE containing AS 64510 in the AS_PATH. (If only the "local-as UPDATE containing AS 64510 in the AS_PATH. (If only the "local-as
64510" feature was configured without the keyword "no-prepend" on 64510" feature was configured without the keyword "no-prepend" on PE-
PE-1, then CE-2 would see an AS_PATH of: 64496 64510 64500, which is 1, then CE-2 would see an AS_PATH of: 64496 64510 64500, which is
unacceptable). unacceptable).
3.2. Replace AS: Modify Outbound BGP AS_PATH Attribute 3.2. Modify Outbound BGP AS_PATH Attribute
The previous feature, "Local AS No Prepend", was only designed to The previous feature, "Local AS No Prepend", was only designed to
modify the AS_PATH Attribute received from CE devices by the ISP, modify the AS_PATH Attribute received by the ISP in updates from CE
when CE devices still have an eBGP session established with the ISPs devices, when CE devices still have an eBGP session established with
legacy AS, (AS64510). Use of "Local AS No Prepend" has an the ISPs legacy AS, (AS64510). In some existing implementations,
unfortunate side effect where its use does not concurrently modify "Local AS No Prepend" does not concurrently modify the AS_PATH
the AS_PATH Attribute for BGP UPDATEs that are transmitted by the ISP Attribute for BGP UPDATEs that are transmitted by the ISP to CE
to CE devices. Specifically, with "Local AS No Prepend" enabled on devices. Specifically, with "Local AS No Prepend" enabled on ISP A's
ISP A's PE-1, it automatically causes a lengthening of the AS_PATH in PE-1, it automatically causes a lengthening of the AS_PATH in
outbound BGP UPDATEs from ISP A' toward directly attached eBGP outbound BGP UPDATEs from ISP A' toward directly attached eBGP
speakers, (Customer C in AS 64496). This is the result of the "Local speakers, (Customer C in AS 64496). This is the result of the "Local
AS No Prepend" feature automatically appending the new global AS No Prepend" feature automatically appending the new global
configuration ASN, AS64500, after the legacy ASN, AS64510, on ISP A' configuration ASN, AS64500, after the legacy ASN, AS64510, on ISP A'
PE-1 in BGP UPDATEs that are transmitted by PE-1 to CE-1. The end PE-1 in BGP UPDATEs that are transmitted by PE-1 to CE-1. The end
result is that customer C, in AS 64496, will receive the following result is that customer C, in AS 64496, will receive the following
AS_PATH: 64510 64500 64499. Therefore, if ISP A' takes no further AS_PATH: 64510 64500 64499. Therefore, if ISP A' takes no further
action, it will cause an increase in AS_PATH length within customer's action, it will cause an increase in AS_PATH length within customer's
networks directly attached to ISP A', which is unacceptable. networks directly attached to ISP A', which is unacceptable.
A second feature, called "Replace AS", was designed to resolve this A second feature was designed to resolve this problem (continuing the
problem. This feature allows ISP A' to not append the global use of Cisco CLI in the examples, it is called "Replace AS" in the
configured AS in outbound BGP UPDATEs toward its customer's networks examples below). This feature allows ISP A' to prevent routers
configured with the "Local AS" feature. Instead, only the historical configured with this feature from appending the global configured AS
(or, legacy) AS will be prepended in the outbound BGP UPDATE toward in outbound BGP UPDATEs toward its customer's networks configured
with the "Local AS" feature. Instead, only the historical (or
legacy) AS will be prepended in the outbound BGP UPDATE toward
customer's network, restoring the AS_PATH length to what it what was customer's network, restoring the AS_PATH length to what it what was
before AS Migration occurred. 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-1 <--- PE-1 <------------------- PE-2 <--- CE-2 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 New_ASN: 64500 64499 64496 Old_ASN: 64510 New_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
skipping to change at page 8, line 42 skipping to change at page 9, line 11
router bgp 64500 router bgp 64500
neighbor <CE-1_IP> remote-as 64496 neighbor <CE-1_IP> remote-as 64496
neighbor <CE-1_IP> local-as 64510 no-prepend replace-as neighbor <CE-1_IP> local-as 64510 no-prepend replace-as
By default, without "Replace AS" enabled, CE-1 would see an AS_PATH By default, without "Replace AS" enabled, CE-1 would see an AS_PATH
of: 64510 64500 64499, which is artificially lengthened by the ASN of: 64510 64500 64499, which is artificially lengthened by the ASN
Migration. After ISP A' changes PE-1 to include the "Replace AS" Migration. After ISP A' changes PE-1 to include the "Replace AS"
feature, CE-1 would receive an AS_PATH of: 64510 64499, which is the feature, CE-1 would receive an AS_PATH of: 64510 64499, which is the
same AS_PATH length pre-AS migration. same AS_PATH length pre-AS migration.
3.3. Implementation
While multiple implementations already exist, the following should
document the expected behavior such that a new implementation of this
feature could be done on other platforms.
These features MUST be configurable on a per-neighbor or per peer-
group basis to allow for maximum flexibility. When this feature set
is invoked, an ASN that is different from the globally-configured ASN
is provided as a part of the command as exemplified above. To
implement this feature, a BGP speaker MUST send BGP OPEN messages to
the configured eBGP peer using the ASN configured for this session as
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 append the configured ASN
in the AS_PATH attribute before processing the update as normal.
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
modify the behavior as described below:
No prepend inbound - When the BGP speaker configured with this option
receives inbound updates from its neighbor, it MUST NOT append the
configured ASN in the AS_PATH attribute and instead MUST append only
the globally configured ASN.
No prepend outbound - When the BGP speaker configured with this
option generates outbound BGP updates to the configured peer, the BGP
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
scope of this document, the following consideration may be helpful
for implementers: Implementations MAY integrate the behavior of the
options described above into a single command that addresses both
inbound and outbound updates, but if this is done, implementations
MUST provide a method to select its applicability to inbound updates,
outbound updates, or updates in both directions. Several existing
implementations use separate commands (e.g. local-as no-prepend vs
local-as replace-as) for maximum flexibility in controlling the
behavior on the session to address the widest range of possible
migration scenarios.
4. Internal BGP Autonomous System Migration Features 4. Internal BGP Autonomous System Migration Features
The following section describes features that are specific to The following section describes features that are specific to
performing an ASN migration within medium to large networks in order performing an ASN migration within medium to large networks in order
to realize the business and operational benefits of a single network to realize the business and operational benefits of a single network
using one, globally unique Autonomous System. These features assist using one, globally unique Autonomous System. These features assist
with a gradual and least service impacting migration of Internal BGP with a gradual and least service impacting migration of Internal BGP
sessions from a legacy ASN to the permanently retained ASN. It sessions from a legacy ASN to the permanently retained ASN. It
should be noted that the following feature is very valuable to should be noted that the following feature is very valuable to
networks undergoing AS migration, but its use does not cause changes networks undergoing AS migration, but its use does not cause changes
to the AS_PATH attribute. 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, though, the traditional method of single entity. Unfortunately, the traditional method of migrating
migrating all Internal BGP speakers, particularly within larger all Internal BGP speakers, particularly within larger networks, is
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 of iBGP neighbor's remote ASN from the legacy concurrently, changing of iBGP neighbor's 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 speakers.
There is also the concomitant service interruptions as these changes There is also the concomitant service interruptions as these changes
are made to routers within the network, resulting in a reset of iBGP are made to routers within the network, resulting in a reset of iBGP
sessions and subsequent reconvergence times to reestablish optimal sessions and subsequent reconvergence times to reestablish optimal
routing paths. Operators do not and, in some cases, cannot make such routing paths. Operators do not, and in some cases, cannot make such
changes given the associated risks and highly visible service changes given the associated risks and highly visible service
interruption; rather, they require a more gradual method to migrate interruption; rather, they require a more gradual method to migrate
Internal BGP sessions, from one ASN to a second, permanently retained Internal BGP sessions, from one ASN to a second, permanently retained
ASN, that is not visibly service-impacting to its customers. ASN, that is not visibly service-impacting to its customers.
With the "Internal BGP Alias" [JUNIPER] feature, it allows an With the "Internal BGP Alias" [JUNIPER] feature, it allows an
Internal BGP speaker to form a single iBGP session using either the Internal BGP speaker to form a single iBGP session using either the
old, legacy ASN or the new, permanently retained ASN. The benefits old, legacy ASN or the new, permanently retained ASN. The benefits
of using this feature are several fold. First, it allows for a more of using this feature are several fold. First, it allows for a more
gradual and less service-impacting migration away from the legacy ASN gradual and less service-impacting migration away from the legacy ASN
to the permanently retained ASN. Second, it (temporarily) permits to the permanently retained ASN. Second, it (temporarily) permits
the coexistence of the legacy and permanently retained ASN within a the coexistence of the legacy and permanently retained ASN within a
single network, allowing for uniform BGP path selection among all single network, allowing for uniform BGP path selection among all
routers within the consolidated network. routers within the consolidated network. NB: Cisco doesn't have an
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 When the "Internal BGP Alias" feature is enabled, typically just on
one side of a iBGP session, it allows that iBGP speaker to establish one side of a iBGP session, it allows that iBGP speaker to establish
a single iBGP session with either the legacy ASN or the new, a single iBGP session with either the legacy ASN or the new,
permanently retained ASN, depending on which one it receives in the permanently retained ASN, depending on which one it receives in the
"My Autonomous System" field of the BGP OPEN message from its iBGP "My Autonomous System" field of the BGP OPEN message from its iBGP
session neighbor. It is important to recognize that enablement of session neighbor. It is important to recognize that enablement of
the "Internal BGP Alias" feature preserves the semantics of a regular the "Internal BGP Alias" feature preserves the semantics of a regular
iBGP 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
skipping to change at page 10, line 15 skipping to change at page 11, line 40
[RFC4456]. [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 speakers. 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
Alias" feature. It should be noted that Route Reflectors are not a Alias" feature. Note that Route Reflectors are not a prerequisite to
prerequisite to enable "Internal BGP Alias" and this feature can be enable "Internal BGP Alias" and this feature can be enabled
enabled independent of the use of Route Reflectors. 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), take devices that still have a globally configured legacy ASN), take
one member of a redundant pair of RRs and change its global one member of a redundant pair of RRs and change its global
configuration ASN to the permanently retained ASN. Concurrently, configuration ASN to the permanently retained ASN. Concurrently,
enable use of "Internal BGP Alias" on all iBGP sessions. This enable use of "Internal BGP Alias" on all iBGP sessions. This
will comprise Non-Client iBGP sessions to other RRs as well as will comprise Non-Client iBGP sessions to other RRs as well as
Client iBGP sessions, typically to PE devices, both still Client iBGP sessions, typically to PE devices, both still
skipping to change at page 11, line 29 skipping to change at page 13, line 5
permanently retained ASN. permanently retained ASN.
5. The final step is to excise the "Internal BGP Alias" 5. The final step is to excise the "Internal BGP Alias"
configuration from the first half of the legacy RR Client pair -- configuration from the first half of the legacy RR Client pair --
this will expunge "Internal BGP Alias" configuration from all this will expunge "Internal BGP Alias" configuration from all
devices in the network. After this is complete, all routers in devices in the network. After this is complete, all routers in
the network will be using the new, permanently retained ASN for the network will be using the new, permanently retained ASN for
all iBGP sessions with no vestiges of the legacy ASN on any iBGP all iBGP sessions with no vestiges of the legacy ASN on any iBGP
sessions. sessions.
The benefit of using "Internal BGP Alias" is a more gradual and less The benefit of using "Internal BGP Alias" is that it is a more
externally visible, service-impacting change to accomplish an AS gradual and less externally visible, service-impacting change to
migration. Previously, without "Internal BGP Alias", such an AS accomplish an AS migration. Previously, without "Internal BGP
migration change would carry a high risk and need to be successfully Alias", such an AS migration change would carry a high risk and need
accomplished in a very short timeframe, (e.g.: at most several to be successfully accomplished in a very short timeframe, (e.g.: at
hours). In addition, it would cause substantial routing churn and, most several hours). In addition, it would cause substantial routing
likely, rapid fluctuations in traffic carried -- potentially causing churn and, likely, rapid fluctuations in traffic carried --
periods of congestion and resultant packet loss -- during the period potentially causing periods of congestion and resultant packet loss
the configuration changes are underway to complete the AS Migration. -- during the period the configuration changes are underway to
On the other hand, with "Internal BGP Alias", the migration from the complete the AS Migration. On the other hand, with "Internal BGP
legacy ASN to the permanently retained ASN can occur over a period of Alias", the migration from the legacy ASN to the permanently retained
days or weeks with little disruption experienced by customers of the ASN can occur over a period of days or weeks with little disruption
network undergoing AS migration. (The only observable service experienced by customers of the network undergoing AS migration.
disruption should be when each PE undergoes the changes discussed in (The only observable service disruption should be when each PE
step 4 above.) undergoes the changes discussed in step 4 above.)
4.2. Implementation
When configured with this feature, a BGP speaker MUST accept BGP OPEN
and establish an iBGP session from configured iBGP peers if the ASN
value in MY ASN is either the globally configured ASN or the locally
configured ASN provided in this command. Additionally, a BGP speaker
configured with this feature MUST send its own BGP OPEN using both
the globally configured and the locally configured ASN in MY ASN. To
avoid potential deadlocks when two BGP speakers are attempting to
establish a BGP peering session and are both configured with this
feature, the speaker SHOULD send BGP OPEN using the globally
configured ASN first, and only send a BGP OPEN using the locally
configured ASN as a fallback if the remote neighbor responds with the
BGP error BAD PEER ASN. In each case, the BGP speaker MUST treat
updates sent and received to this peer as if this was a natively
configured iBGP session, as defined by [RFC4271] and [RFC4456].
Implementations of this feature MAY integrate the functionality from
the eBGP features (Section 3) section as a part of this command in
order to simplify support for eBGP migrations as well as iBGP
migrations, such that an eBGP session to a configured neighbor could
be established via either the global ASN or the locally configured
ASN. If the eBGP session is established with the global ASN, no
modifications to AS_PATH are required, but if the eBGP session is
established with the locally configured ASN, the modifications
discussed in eBGP features (Section 3) MUST be implemented to
properly manipulate the AS_PATH.
5. Additional Operational Considerations 5. Additional Operational Considerations
This document describes several implementation-specific features to This document describes several features to support ISPs and other
support ISPs and other organizations that need to perform ASN organizations that need to perform ASN migrations. Other variations
migrations. Other variations of these features may exist, for of these features may exist, for example, in legacy router software
example, in legacy router software that has not been upgraded or that has not been upgraded or reached End of Life, but continues to
reached End of Life, but continues to operate in the network. Such operate in the network. Such variations are beyond the scope of this
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 customer's devices, (i.e.: the ISPs control over the configuration of customer's 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
skipping to change at page 12, line 50 skipping to change at page 15, line 8
existence in commercial implementations for well over a decade. existence in commercial implementations for well over a decade.
These features are widely known by the operational community and will These features are widely known by the operational community and will
continue to be a critical necessity in the support of network continue to be a critical necessity in the support of network
integration activities going forward. Therefore, these features are integration activities going forward. Therefore, these features are
extremely unlikely to be deprecated by vendors. As a result, these extremely unlikely to be deprecated by vendors. As a result, these
features must be acknowledged by protocol designers, particularly features must be acknowledged by protocol designers, particularly
when there are proposals to modify BGP's behavior with respect to when there are proposals to modify BGP's behavior with respect to
handling or manipulation of the AS_PATH Attribute. More handling or manipulation of the AS_PATH Attribute. More
specifically, assumptions should not be made with respect to the specifically, assumptions should not be made with respect to the
preservation or consistency of the AS_PATH Attribute as it is preservation or consistency of the AS_PATH Attribute as it is
transmitted along a sequence of ASN's. In addition, proposals to transmitted along a sequence of ASN's. In addition, proposals to
manipulate the AS_PATH that would gratuitously increase AS_PATH manipulate the AS_PATH that would gratuitously increase AS_PATH
length or remove the capability to use these features described in length or remove the capability to use these features described in
this document will not be accepted by the operational community. this document will not be accepted by the operational community.
7. Acknowledgements 7. Acknowledgements
Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson, Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson,
and David Farmer for their comments. David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, and Juan
Alcaide for their comments.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. 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 other's networks. This could result in a Path Selection Algorithm in other's networks. This could result in a
loss of revenue if the ISP is billing based on measured utilization loss of revenue if the ISP is billing based on measured utilization
of traffic sent to/from entities attached to its network. This could of traffic sent to/from entities attached to its network. This could
also result in sudden, and unexpected shifts in traffic patterns in also result in sudden and unexpected shifts in traffic patterns in
the network, potentially resulting in congestion, in the most extreme the network, potentially resulting in congestion, in the most extreme
cases. cases.
Given that these features can only be enabled through configuration Given that these features can only be enabled through configuration
of router's within a single network, standard security measures of router's within a single network, standard security measures
should be taken to restrict access to the management interface(s) of should be taken to restrict access to the management interface(s) of
routers that implement these features. routers that implement these features.
10. References 10. Appendix: Implementation report
10.1. Normative References As noted elsewhere in this document, this set of migration features
has multiple existing implementations in wide use.
o Cisco [CISCO]
o Juniper [JUNIPER]
o Alcatel-Lucent [ALU]
This is not intended to be an exhaustive list, as equivalent features
do exist in other implementations, however the authors were unable to
find publicly available documentation of the vendor-specific
implementation to reference.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, December 2008.
10.2. Informative References 11.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-h-f/ <https://infoproducts.alcatel-lucent.com/html/0_add-
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/en/US/docs/ios/12_3t/12_3t11/feature <http://www.cisco.com/c/en/us/td/docs/ios-
/guide/gtbgpdas.html>. xml/ios/iproute_bgp/configuration/xe-3s/asr1000/
irg-xe-3s-asr1000-book/irg-dual-as.html>.
[JUNIPER] Juniper Networks, Inc., "Configuring the BGP Local [JUNIPER] Juniper Networks, Inc., "Configuring the BGP Local
Autonomous System Attribute", 2012, <https:// Autonomous System Attribute", 2012,
www.juniper.net/techpubs/en_US/junos12.3/topics/reference/ <http://www.juniper.net/techpubs/en_US/junos13.3/topics/
configuration-statement/local-as-edit-protocols-bgp.html>. concept/bgp-local-as-introduction.html>.
[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.
[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, 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.
 End of changes. 31 change blocks. 
112 lines changed or deleted 220 lines changed or added

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