draft-ietf-idr-as-migration-02.txt   draft-ietf-idr-as-migration-03.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: January 30, 2015 Apple, Inc. Expires: April 2, 2015 Apple, Inc.
July 29, 2014 September 29, 2014
Autonomous System (AS) Migration Features and Their Effects on the BGP Autonomous System Migration Features and Their Effects on the BGP
AS_PATH Attribute AS_PATH Attribute
draft-ietf-idr-as-migration-02 draft-ietf-idr-as-migration-03
Abstract Abstract
This draft discusses common methods of managing an ASN migration This draft discusses some BGP features for ASN migration that, while
using some BGP feaures that while commonly-used are not formally part commonly used, are not formally part of the BGP4 protocol
of the BGP4 protocol specification and may be vendor-specific in specification and may be vendor-specific in exact implementation. It
exact implementation. It is necessary to document these de facto is necessary to document these de facto standards to ensure that they
standards to ensure that they are properly supported in future BGP are properly supported in future BGP protocol work such as BGPSec.
protocol work such as BGPSec.
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 January 30, 2015. This Internet-Draft will expire on April 2, 2015.
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
skipping to change at page 2, line 16 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . 4
3. External BGP Autonomous System Migration Features . . . . . . 6 3. External BGP Autonomous System Migration Features . . . . . . 6
3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 6 3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 6
3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 8 3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7
3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 9 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8
4. Internal BGP Autonomous System Migration Features . . . . . . 10 4. Internal BGP Autonomous System Migration Features . . . . . . 9
4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 10 4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 10
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 13 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12
5. Additional Operational Considerations . . . . . . . . . . . . 14 5. Additional Operational Considerations . . . . . . . . . . . . 13
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Appendix: Implementation report . . . . . . . . . . . . . . . 15 10. Appendix: Implementation report . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This draft discusses common methods of managing an ASN migration This draft discusses some BGP features for ASN migration that, while
using some BGP features that while commonly-used are not formally commonly used, are not formally part of the BGP4 [RFC4271] protocol
part of the BGP4 [RFC4271] protocol specification and may be vendor- specification and may be vendor-specific in exact implementation.
specific in exact implementation. These features are local to a These features are local to a given BGP Speaker and do not require
given BGP Speaker and do not require negotiation with or cooperation negotiation with or cooperation of BGP neighbors. The deployment of
of BGP neighbors. The deployment of these features do not need to these features do not need to interwork with one another to
interwork with one another to accomplish the desired results, so accomplish the desired results, so slight variations between existing
slight variations between existing vendor implementations exist. vendor implementations exist, and will not necessarily be harmonized
However, it is necessary to document these de facto standards to due to this document. However, it is necessary to document these de
ensure that any future protocol enhancements to BGP that propose to facto standards to ensure that new implementations can be successful,
read, copy, manipulate or compare the AS_PATH attribute can do so and any future protocol enhancements to BGP that propose to read,
without inhibiting the use of these very widely used ASN migration copy, manipulate or compare the AS_PATH attribute can do so without
features. inhibiting the use of these very widely used ASN migration features.
It is important to understand the business need for these features The migration features discussed here are useful to ISPs and
and illustrate why they are critical, particularly for ISPs' organizations of all sizes, but it is important to understand the
operations. However, these features are not limited to ISPs and business need for these features and illustrate why they are so
organizations of all sizes use these features for similar reasons to critical for ISPs' operations. During a merger, acquisition or
ISPs. During a merger, acquisition or divestiture involving two divestiture involving two organizations it is necessary to seamlessly
organizations it is necessary to seamlessly migrate BGP speakers from migrate both internal and external BGP speakers from one ASN to a
one ASN to a second ASN. The overall goal in doing so, particularly second ASN. The overall goal in doing so is to simplify operations
in the case of a merger or acquisition, is to achieve a uniform through consistent configurations across all BGP speakers in the
operational model through consistent configurations across all BGP combined network. In addition, it is common practice in the industry
speakers in the combined network. In addition, and perhaps more for ISPs to bill customers based on utilization. ISPs bill customers
imporantly, it is common practice in the industry for ISPs to bill based on the 95th percentile of the greater of the traffic sent or
customers based on utilization. ISPs bill customers based on the received, over the course of a 1-month period, on the customer's
95th percentile of the greater of the traffic sent or received, over access circuit. Given that the BGP Path Selection algorithm selects
the course of a 1-month period, on the customer's PE-CE access routes with the shortest AS_PATH attribute, it is critical that the
circuit. Given that the BGP Path Selection algorithm selects routes ISP does not increase AS_PATH length during or after ASN migration
with the shortest AS_PATH attribute, it is critical for the ISP to toward downstream transit customers or settlement-free peers, who are
not increase AS_PATH length during or after ASN migration, toward likely sending or receiving traffic from those transit customers.
both downstream transit customers as well as settlement-free peers, This would not only result in sudden changes in traffic patterns in
who are likely sending or receiving traffic from those transit the network, but also substantially decrease utilization driven
customers. This would not only result in sudden changes in traffic revenue at the ISP.
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
single remote ASN for the eBGP neighbor inside a router, in order to router to use a single remote ASN for the BGP neighbor, and the ASN
successfully negotiate and establish an eBGP session. Prior to the must match on both ends of the peering in order to successfully
existence of these features, it would have required an ISP to work negotiate and establish a BGP session. Prior to the existence of
with, in some cases, tens of thousands of customers. In particular, these migration features, it would have required an ISP to coordinate
the ISP would have to encourage those customers to change their CE an ASN change with, in some cases, tens of thousands of customers.
router configs to use the new ASN in a very short period of time, In particular, as each router is migrated to the new ASN, to avoid an
when the customer has no business incentive to do so. Thus, it outage due to ASN mismatch, the ISP would have to force all customers
becomes critical to allow the ISP to make this process a bit more on that router to change their router configurations to use the new
asymmetric, so that it could seamlessly migrate the ASN within its ASN immediately after the ASN change. Thus, it becomes critical to
network(s), but not disturb existing customers, and allow the allow the ISP to make this process a bit more asymmetric, so that it
customers to gradually migrate to the ISP's new ASN at their leisure. could seamlessly migrate the ASN within its network(s), but allow the
customers to gradually migrate to the ISP's new ASN at their leisure,
either by coordinating individual reconfigurations, or accepting
sessions using either the old or new ASN to allow for truly
asymmetric migration.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Documentation note 1.2. Documentation note
This draft uses Autonomous System Numbers (ASNs) from the range This 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 5.
2. ASN Migration Scenario Overview 2. ASN Migration Scenario Overview
The use case being discussed here is an ISP merging two or more ASNs, The use case being discussed here is an ISP merging two or more ASNs,
where eventually one ASN subsumes the other(s). In this use case, we where eventually one ASN subsumes the other(s). In this use case, we
will assume the most common case where there are two ISPs, A and B, will assume the most common case where there are two ISPs, A and B,
that use AS 64500 and 64510, respectively, before the ASN migration that prior to the ASN migration use AS 64500 and 64510, respectively.
is to occur. AS 64500 will be the permanently retained ASN used AS 64500 will be the permanently retained ASN used across the
going forward across the consolidated set of both ISPs network consolidated set of both ISPs network equipment, and AS 64510 will be
equipment and AS 64510 will be retired. Thus, at the conclusion of retired. Thus, at the conclusion of the ASN migration, there will be
the ASN migration, there will be a single ISP A' with all internal a single ISP A' with all internal BGP speakers configured to use AS
BGP speakers configured to use AS 64500. To all external BGP 64500. To all external BGP speakers, the AS_PATH length will not be
speakers, the AS_PATH length will not be increased. increased.
In this same scenario, AS 64496 and AS 64499 represent two, separate In this same scenario, AS 64496 and AS 64499 represent two separate
customer networks: C and D, respectively. Originally, customer C (AS customer networks: C and D, respectively. Originally, customer C (AS
64496) is attached to ISP B, which will undergo ASN migration from AS 64496) is attached to ISP B, which will undergo ASN migration from AS
64510 to AS 64500. Furthermore, customer D (AS 64499) is attached to 64510 to AS 64500. Furthermore, customer D (AS 64499) is attached to
ISP A, which does not undergo ASN migration since ISP A's ASN will ISP A, which does not undergo ASN migration since the ASN for ISP A
remain constant, (AS 64500). Although this example refers to AS will remain constant, (AS 64500). Although this example refers to AS
64496 and 64499 as customer networks, either or both may be 64496 and 64499 as customer networks, either or both may be
settlement-free or other types of peers. In this use case they are settlement-free or other types of peers. In this use case they are
referred to as "customers" merely for convenience. referred to as "customers" merely for convenience.
------ ------ ------ ------
/ ISP A \ / ISP B \ / ISP A \ / ISP B \
| AS 64500 | | AS 64510 | | AS 64500 | | AS 64510 |
\ / \ / \ / \ /
------- ------- ------- -------
| | | |
skipping to change at page 5, line 22 skipping to change at page 5, line 22
/ \ / \
| | | |
------------ ------------- ------------ -------------
| Cust D | | Cust C | | Cust D | | Cust C |
| AS 64499 | | AS 64496 | | AS 64499 | | AS 64496 |
------------ ------------- ------------ -------------
Figure 2: After Migration Figure 2: After Migration
The general order of operations, typically carried out in a single The general order of operations, typically carried out in a single
maintenance window by the network undergoing ASN migration, ISP B, maintenance window by the network undergoing ASN migration (ISP B),
are as follows. First, ISP B, will change the global BGP ASN used by are as follows. First, ISP B will change the global BGP ASN used by
a PE router, from ASN 64510 to 64500. At this point, the router will a Provider Edge (PE) router, from ASN 64510 to 64500. At this point,
no longer be able to establish eBGP sessions toward the existing CE the router will no longer be able to establish eBGP sessions toward
devices that are attached to it and still using AS 64510. Second, the existing Customer Edge (CE) devices that are attached to it and
ISP B will configure two separate, but related ASN migration features still using AS 64510. Second, since ISP B needs to do this without
discussed in this document on all eBGP sessions toward all CE coordinating the simultaneous change of its ASN with all of its eBGP
devices. These features modify the AS_PATH attribute received from a peers, ISP B will configure two separate, but related ASN migration
CE device when advertising it further, and modify AS_PATH when features discussed in this document on all eBGP sessions toward all
CE devices. These features enable the router to establish BGP
neighbors using the legacy ASN, modify the AS_PATH attribute received
from a CE device when advertising it further, and modify AS_PATH when
transmitted toward CE devices to achieve the desired effect of not 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 and do not observe any change in the the network are not aware of the fact that their upstream router is
length of the AS_PATH attribute. However, after the changes now in a new ASN and do not observe any change in the length of the
discussed in this document are put in place by ISP A', there is a AS_PATH attribute. However, after the changes discussed in this
change to the contents of the AS_PATH attribute to ensure the AS_PATH document are put in place by ISP A', there is a change to the
is not artifically lengthened for the duration of time that these AS contents of the AS_PATH attribute to ensure the AS_PATH is not
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 There are multiple implementations with equivalent features deployed
and in use. Some documentation pointers to these implementations, as and in use. Some documentation pointers to these implementations, as
well as additional documentation on migration scenarios can be found well as additional documentation on migration scenarios can be found
in the appendix. The examples cited below use Cisco IOS CLI for ease in the appendix. The examples cited below use Cisco IOS CLI for ease
of illustration purposes only. of illustration purposes only.
skipping to change at page 6, line 21 skipping to change at page 6, line 21
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. 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 The first feature used in the process described above is called
internal BGP speaker in AS 64500, to realize the business goal of "Local AS". This feature allows the PE router that was formerly in
becoming a single Service Provider: ISP A'. ISP B needs to do this ISP B to re-establish an eBGP session toward the existing CE devices
without coordinating the change of its ASN with all of its eBGP using the legacy AS, AS 64510. Ultimately, the CE devices (i.e.:
peers, simultaneously. The first step is for ISP B to change the customer C) are completely unaware that ISP B has reconfigured its
global AS in its router configuration, used by the local BGP process router to participate as a member of a new AS. Within the context of
as the system-wide Autonomous System ID, from AS 64510 to AS 64500. the former ISP B PE router, the second effect this feature has on
The next step is for ISP B to establish iBGP sessions with ISP A's AS_PATH is that, by default, it prepends all received BGP UPDATEs
existing routers, thus consolidating ISP B into ISP A resulting in with the legacy AS of ISP B: AS 64510, while advertising it (Adj-RIB-
operating under a single AS: ISP A', (AS 64500). Out) to other BGP speakers (A'). Within Loc-RIB on ISP B prior to
the migration, the AS_PATH toward customer C would appear as: 64510,
The next step is for ISP B to reconfigure its PE router(s) so that whereas the same RIB on ISP A' (ISP B routers post-migration) would
each of its eBGP sessions toward all eBGP speakers with a feature contain AS_PATH: 64510 64496. To avoid changes to the AS_PATH
called "Local AS". This feature allows ISP B's PE router to re- length, a secondary feature "No Prepend" is added to the "Local AS"
establish a eBGP session toward the existing CE devices using the configuration toward every eBGP neighbor on PE routers migrating from
legacy AS, AS 64510, in the eBGP session establishment. Ultimately, ISP B. The "No Prepend" feature causes those routers to not prepend
the CE devices, (i.e.: customer C), are completely unaware that ISP B the legacy AS, AS 64510, when advertising UPDATES received from
has reconfigured its router to participate as a member of a new AS. customer C. This restores the AS_PATH within ISP A' toward customer
Within the context of ISP B's PE router, The second effect this C so that it is just one ASN in length: 64496.
feature has on AS_PATH is that, by default, it prepends all received
BGP UPDATEs with the legacy AS of ISP B: AS 64510, while advertising
(Adj-RIB-Out) it to other BGP speakers (A'). Thus, within Loc-RIB on
ISP B' the AS_PATH toward customer C would appear as: 64510, whereas
the same RIB on ISP A' would contain AS_PATH: 64510 64496, which is
an increase in AS_PATH length from previously. Therefore, a
secondary feature "No Prepend" is required to be added to the "Local
AS" configuration toward every eBGP neighbor on ISP B's PE router.
The "No Prepend" feature causes ISP B's PE router 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 <old_ASN>': prepends the <old_ASN> value to the AS_PATH
when advertising routes received from the CE when advertising routes received from the CE
2. 'local-as <old_ASN> no-prepend': does not prepend <old_ASN> value 2. 'local-as <old_ASN> no-prepend': does not prepend <old_ASN> value
to the AS_PATH when advertising routes received from the CE to the AS_PATH when advertising routes received from the CE
As stated previously, local-as <old_ASN> no-prepend, (configuration PE-B is a PE that was originally in ISP B, and has a customer peer
#2), is critical because it does not increase the AS_PATH length. CE-B. PE-B has had its global configuration ASN changed from AS
Ultimately, this ensures that routes learned from ISP B's legacy 64510 to AS 64500 to make it part of the permanently retained ASN.
customers will be transmitted through legacy eBGP sessions of ISP A, This now makes PE-B a member of ISP A'. PE-A is a PE that was
toward both customers and peers, will contain only two AS'es in the originally in ISP A, and has a customer peer CE-A. Although its
AS_PATH: 64500 64496. Thus, the legacy customers and peers of ISP A global configuration ASN remains AS 64500, throughout this exercise
will not see an increase in the AS_PATH length to reach ISP B's we also consider PE-A a member of ISP A'.
legacy customers. Ultimately, it is considered mandatory by
operators that both the "Local AS" and "No Prepend" configuration
parameters always be used in conjunction with each other in order to
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
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
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
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-A <--- PE-A <------------------- PE-B <--- CE-B
64496 Old_ASN: 64510 New_ASN: 64500 64499 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 BGP UPDATE Diagram
The final configuration on PE-1 after completing the "Local AS" The final configuration on PE-B 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-B_IP> remote-as 64496
neighbor <CE-1_IP> local-as 64510 no-prepend neighbor <CE-B_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-B, CE-A
will see an AS_PATH of: 64500 64496. CE-2 will not receive a BGP will see an AS_PATH of: 64500 64496. CE-A will not receive a BGP
UPDATE containing AS 64510 in the AS_PATH. (If only the "local-as UPDATE containing AS 64510 in the AS_PATH. (If only the "local-as
64510" feature was configured without the keyword "no-prepend" on PE- 64510" feature was configured without the keyword "no-prepend" on PE-
1, then CE-2 would see an AS_PATH of: 64496 64510 64500, which B, then CE-A would see an AS_PATH of: 64496 64510 64500, which
results in an unacceptable lengthening of the AS_PATH). 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 only designed to The previous feature, "Local AS No Prepend", was designed to modify
modify the AS_PATH Attribute received by the ISP in updates from CE the AS_PATH Attribute received by the ISP in updates from CE devices,
devices, when CE devices still have an eBGP session established with when CE devices still have an eBGP session established with the ISPs
the ISPs legacy AS, (AS64510). In some existing implementations, legacy AS, (AS64510). In some existing implementations, "Local AS No
"Local AS No Prepend" does not concurrently modify the AS_PATH Prepend" does not concurrently modify the AS_PATH Attribute for BGP
Attribute for BGP UPDATEs that are transmitted by the ISP to CE UPDATEs that are transmitted by the ISP to CE devices. Specifically,
devices. Specifically, with "Local AS No Prepend" enabled on ISP A's with "Local AS No Prepend" enabled on PE-B, it automatically causes a
PE-1, it automatically causes a lengthening of the AS_PATH in lengthening of the AS_PATH in outbound BGP UPDATEs from ISP A' toward
outbound BGP UPDATEs from ISP A' toward directly attached eBGP directly attached eBGP speakers, (Customer C in AS 64496). This is
speakers, (Customer C in AS 64496). This is the result of the "Local the result of the "Local AS No Prepend" feature automatically
AS No Prepend" feature automatically appending the new global appending the new global configuration ASN, AS64500, after the legacy
configuration ASN, AS64500, after the legacy ASN, AS64510, on ISP A' ASN, AS64510, in BGP UPDATEs that are transmitted by PE-B to CE-B.
PE-1 in BGP UPDATEs that are transmitted by PE-1 to CE-1. The end The end result is that customer C, in AS 64496, will receive the
result is that customer C, in AS 64496, will receive the following following AS_PATH: 64510 64500 64499. Therefore, if ISP A' takes no
AS_PATH: 64510 64500 64499. Therefore, if ISP A' takes no further further action, it will cause an unacceptable increase in AS_PATH
action, it will cause an unacceptable increase in AS_PATH length length within customer's networks directly attached to ISP A'.
within customer's networks directly attached to ISP A'.
A second feature was designed to resolve this problem (continuing the A second feature was designed to resolve this problem (continuing the
use of Cisco CLI in the examples, it is called "Replace AS" in the use of Cisco CLI in the examples, it is called "Replace AS" in the
examples below). This feature allows ISP A' to prevent routers examples below). This feature allows ISP A' to prevent routers
configured with this feature from appending the global configured AS configured with this feature from appending the global configured AS
in outbound BGP UPDATEs toward its customer's networks configured in outbound BGP UPDATEs toward its customer's networks configured
with the "Local AS" feature. Instead, only the historical (or with the "Local AS" feature. Instead, only the historical (or
legacy) AS will be prepended in the outbound BGP UPDATE toward legacy) AS will be prepended in the outbound BGP UPDATE toward the
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-A ---> PE-A -------------------> PE-B ---> CE-B
64496 Old_ASN: 64510 New_ASN: 64500 64499 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-1 after completing the "Replace AS" The final configuration on PE-B after completing the "Replace 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-B_IP> remote-as 64496
neighbor <CE-1_IP> local-as 64510 no-prepend replace-as neighbor <CE-B_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-B 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-B to include the "Replace AS"
feature, CE-1 would receive an AS_PATH of: 64510 64499, which is the feature, CE-B 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 3.3. Implementation
While multiple implementations already exist, the following should While multiple implementations already exist, the following should
document the expected behavior such that a new implementation of this document the expected behavior such that a new implementation of this
feature could be done on other platforms. feature could be done on other platforms.
These features MUST be configurable on a per-neighbor or per peer- These features MUST be configurable on a per-neighbor or per peer-
group basis to allow for maximum flexibility. When this feature set group basis to allow for maximum flexibility. When this feature set
skipping to change at page 10, line 25 skipping to change at page 9, line 46
inbound and outbound updates, but if this is done, implementations inbound and outbound updates, but if this is done, implementations
MUST provide a method to select its applicability to inbound updates, MUST provide a method to select its applicability to inbound updates,
outbound updates, or updates in both directions. Several existing outbound updates, or updates in both directions. Several existing
implementations use separate commands (e.g. local-as no-prepend vs implementations use separate commands (e.g. local-as no-prepend vs
local-as replace-as) for maximum flexibility in controlling the local-as replace-as) for maximum flexibility in controlling the
behavior on the session to address the widest range of possible behavior on the session to address the widest range of possible
migration scenarios. 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 assist with a gradual
performing an ASN migration within medium to large networks in order and least service impacting migration of Internal BGP sessions from a
to realize the business and operational benefits of a single network legacy ASN to the permanently retained ASN. The following feature is
using one, globally unique Autonomous System. These features assist very valuable to networks undergoing AS migration, but its use does
with a gradual and least service impacting migration of Internal BGP not cause changes to the AS_PATH attribute.
sessions from a legacy ASN to the permanently retained ASN. It
should be noted that the following feature is very valuable to
networks undergoing AS migration, but its use does not cause changes
to the AS_PATH attribute.
4.1. Internal BGP Alias 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 of iBGP neighbor's 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 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 route reconvergence to reestablish optimal
routing paths. Operators do not, and in some cases, cannot make such routing paths. Operators often cannot make such sweeping changes
changes given the associated risks and highly visible service given the associated risks of a highly visible service interruption;
interruption; rather, they require a more gradual method to migrate rather, they require a more gradual method to migrate Internal BGP
Internal BGP sessions, from one ASN to a second, permanently retained sessions, from one ASN to a second, permanently retained ASN, that is
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 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. NB: Cisco doesn't have an routers within the consolidated network. NB: Cisco doesn't have an
skipping to change at page 11, line 51 skipping to change at page 11, line 22
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. Note that Route Reflectors are not a prerequisite to Alias" feature. Note that Route Reflectors are not a prerequisite to
enable "Internal BGP Alias" and this feature can be enabled enable "Internal BGP Alias" and this feature can be 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), one
one member of a redundant pair of RRs and change its global member of a redundant pair of RRs has its global configuration
configuration ASN to the permanently retained ASN. Concurrently, ASN changed to the permanently retained ASN. Concurrently,
enable use of "Internal BGP Alias" on all iBGP sessions. This "Internal BGP Alias" is configured 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
utilizing the legacy ASN. Note that during this step there will utilizing the legacy ASN. Note that during this step there will
be a reset and reconvergence event on all iBGP sessions on the be a reset and reconvergence event on all iBGP sessions on the
RRs whose configuration was modified; however, this should not be RRs whose configuration was modified; however, this should not be
service impacting due to the use of redundant RRs in each RR service impacting due to the use of redundant RRs in each RR
Cluster. Cluster.
2. Repeat the above step for the other side of the redundant pair of 2. The above step is repeated for the other side of the redundant
RRs. The one alteration to the above procedure is to disable use pair of RRs. The one alteration to the above procedure is that
of "Internal BGP Alias" on the Non-Client iBGP sessions toward "Internal BGP Alias" is now removed from the Non-Client iBGP
the other (previously reconfigured) RRs, since it is no longer sessions toward the other (previously reconfigured) RRs, since it
needed. "Internal BGP Alias" is still required on all RRs for is no longer needed. "Internal BGP Alias" is still required on
all RR Client iBGP sessions. Also during this step, there will all RRs for all RR Client iBGP sessions. Also during this step,
be a reset and reconvergence event on all iBGP sessions whose there will be a reset and reconvergence event on all iBGP
configuration was modified, but this should not be service sessions whose configuration was modified, but this should not be
impacting. At the conclusion of this step, all RRs should now service impacting. At the conclusion of this step, all RRs
have their globally configured ASN set to the permanently should now have their globally configured ASN set to the
retained ASN and "Internal BGP Alias" enabled and in use toward permanently retained ASN and "Internal BGP Alias" enabled and in
RR Clients. 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. The next steps to complete the AS migration are to gradually 4. To complete the AS migration, each RR Client (PE) in the legacy
modify each RR Client, (PE), in the legacy network still network still utilizing the legacy ASN is now modified.
utilizing the legacy ASN. Specifically, each legacy PE would Specifically, each legacy PE would have its globally configured
have its globally configured ASN changed to use the permanently ASN changed to use the permanently retained ASN. The ASN used by
retained ASN. The ASN used by the PE for the iBGP sessions, the PE for the iBGP sessions toward each RR would be changed to
toward each RR, would be changed to use the permanently retained use the permanently retained ASN. (It is unnecessary to enable
ASN. (It is unnecessary to enable "Internal BGP Alias" on the "Internal BGP Alias" on the migrated iBGP sessions). During the
migrated iBGP sessions). During the same maintenance window, same maintenance window, External BGP sessions would be modified
External BGP sessions would be modified to include the above to include the above "Local AS No Prepend" and "Replace-AS"
"Local AS No Prepend" and "Replace-AS" features, since all of the features described in Section 3 above, since all of the changes
changes are service interrupting to the eBGP sessions of the PE. are service interrupting to the eBGP sessions of the PE. At this
At this point, all PE's will have been migrated to the point, all PEs will have been migrated to the permanently
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 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 that it is a more The benefit of using "Internal BGP Alias" is that it is a more
gradual and less externally visible, service-impacting change to gradual and less externally service-impacting change to accomplish an
accomplish an AS migration. Previously, without "Internal BGP AS migration. Previously, without "Internal BGP Alias", such an AS
Alias", such an AS migration change would carry a high risk and need migration change would carry a high risk and need to be successfully
to be successfully accomplished in a very short timeframe, (e.g.: at accomplished in a very short timeframe (e.g.: at most several hours).
most several hours). In addition, it would cause substantial routing In addition, it would likely cause substantial routing churn and
churn and, likely, rapid fluctuations in traffic carried -- rapid fluctuations in traffic carried -- potentially causing periods
potentially causing periods of congestion and resultant packet loss of congestion and resultant packet loss -- during the period the
-- during the period the configuration changes are underway to configuration changes are underway to complete the AS Migration. On
complete the AS Migration. On the other hand, with "Internal BGP the other hand, with "Internal BGP Alias", the migration from the
Alias", the migration from the legacy ASN to the permanently retained legacy ASN to the permanently retained ASN can occur over a period of
ASN can occur over a period of days or weeks with little disruption days or weeks with reduced customer disruption. (The only observable
experienced by customers of the network undergoing AS migration. service disruption should be when each PE undergoes the changes
(The only observable service disruption should be when each PE discussed in step 4 above.)
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 feature, a BGP speaker MUST accept BGP OPEN
and establish an iBGP session from configured iBGP peers if the ASN 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 value in MY ASN is either the globally configured ASN or the locally
configured ASN provided in this command. Additionally, a BGP speaker configured ASN provided in this command. Additionally, a BGP speaker
configured with this feature MUST send its own BGP OPEN using both configured with this feature MUST send its own BGP OPEN using both
the globally configured and the locally configured ASN in MY ASN. To the globally configured and the locally configured ASN in MY ASN. To
avoid potential deadlocks when two BGP speakers are attempting to avoid potential deadlocks when two BGP speakers are attempting to
skipping to change at page 14, line 17 skipping to change at page 13, line 36
This document describes several features to support ISPs and other This document describes several features 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 features 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 customer's 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 features discussed
in this document can and do persist for several years, if not longer. in this document can and do persist for several years, if not longer.
Thus, it is prudent to plan that legacy ASNs and associated External Thus, it is prudent to plan that legacy ASNs and associated External
BGP AS Migration features will persist in a operational network BGP AS Migration features will persist in a operational network
skipping to change at page 15, line 8 skipping to change at page 14, line 28
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 ASNs. 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,
David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, and Juan David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan
Alcaide for their comments. Alcaide, Jon Mitchell, and Thomas Morin 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 others' 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 routers within a single network, standard security measures should
should be taken to restrict access to the management interface(s) of be taken to restrict access to the management interface(s) of routers
routers that implement these features. that implement these features.
10. Appendix: Implementation report 10. Appendix: Implementation report
As noted elsewhere in this document, this set of migration features As noted elsewhere in this document, this set of migration features
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]
skipping to change at page 16, line 16 skipping to change at page 15, line 36
find publicly available documentation of the vendor-specific find publicly available documentation of the vendor-specific
implementation to reference. implementation to reference.
11. References 11. References
11.1. Normative References 11.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
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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.
11.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- <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>.
skipping to change at page 16, line 37 skipping to change at page 16, line 16
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>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
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.
[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.
 End of changes. 48 change blocks. 
256 lines changed or deleted 231 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/