draft-ietf-idr-as-migration-01.txt   draft-ietf-idr-as-migration-02.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: Standards Track S. Amante
Expires: December 15, 2014 Apple, Inc. Expires: January 30, 2015 Apple, Inc.
June 13, 2014 July 29, 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-01 draft-ietf-idr-as-migration-02
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 December 15, 2014. This Internet-Draft will expire on January 30, 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 4, line 21 skipping to change at page 4, line 21
is to occur. AS 64500 will be the permanently retained ASN used is to occur. AS 64500 will be the permanently retained ASN used
going forward across the consolidated set of both ISPs network going forward across the consolidated set of both ISPs network
equipment and AS 64510 will be retired. Thus, at the conclusion of equipment and AS 64510 will be retired. Thus, at the conclusion of
the ASN migration, there will be a single ISP A' with all internal the ASN migration, there will be a single ISP A' with all internal
BGP speakers configured to use AS 64500. To all external BGP BGP speakers configured to use AS 64500. To all external BGP
speakers, the AS_PATH length will not be increased. speakers, the AS_PATH length will not be 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 64496) 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 ISP A's ASN will
remain constant, (AS 64500). Although this example refers to AS 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 29 skipping to change at page 5, line 29
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 PE router, from ASN 64510 to 64500. At this point, the router will
no longer be able to establish eBGP sessions toward the existing CE no longer be able to establish eBGP sessions toward the existing CE
devices that are attached to it and still using AS 64510. Second, devices that are attached to it and still using AS 64510. Second,
ISP B will configure two separate, but related ASN migration features ISP B will configure two separate, but related ASN migration features
discussed in this document on all eBGP sessions toward all CE discussed in this document on all eBGP sessions toward all CE
devices. These features modify the AS_PATH attribute received from devices. These features modify the AS_PATH attribute received from a
and transmitted toward CE devices to acheive the desired effect of CE device when advertising it further, and modify AS_PATH when
not increasing the length of the AS_PATH. transmitted toward CE devices to achieve the desired effect of not
increasing the length of the AS_PATH.
At the conclusion of the ASN migration, the CE devices at the edge of 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 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
skipping to change at page 6, line 39 skipping to change at page 6, line 39
existing routers, thus consolidating ISP B into ISP A resulting in existing routers, thus consolidating ISP B into ISP A resulting in
operating under a single AS: ISP A', (AS 64500). operating under a single AS: ISP A', (AS 64500).
The next step is for ISP B to reconfigure its PE router(s) so that The next step is for ISP B to reconfigure its PE router(s) so that
each of its eBGP sessions toward all eBGP speakers with a feature each of its eBGP sessions toward all eBGP speakers with a feature
called "Local AS". This feature allows ISP B's PE router to re- called "Local AS". This feature allows ISP B's PE router to re-
establish a eBGP session toward the existing CE devices using the establish a eBGP session toward the existing CE devices using the
legacy AS, AS 64510, in the eBGP session establishment. Ultimately, legacy AS, AS 64510, in the eBGP session establishment. Ultimately,
the CE devices, (i.e.: customer C), are completely unaware that ISP B the CE devices, (i.e.: customer C), are completely unaware that ISP B
has reconfigured its router to participate as a member of a new AS. has reconfigured its router to participate as a member of a new AS.
Within the context of ISP B's PE router, the second effect this Within the context of ISP B's PE router, The second effect this
feature has is that, by default, it prepends all received BGP feature has on AS_PATH is that, by default, it prepends all received
UPDATE's with the legacy AS of ISP B: AS 64510. Thus, within ISP A' BGP UPDATEs with the legacy AS of ISP B: AS 64510, while advertising
the AS_PATH toward customer C would appear as: 64510 64496, which is (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 an increase in AS_PATH length from previously. Therefore, a
secondary feature "No Prepend" is required to be added to the "Local secondary feature "No Prepend" is required to be added to the "Local
AS" configuration toward every eBGP neighbor on ISP B's PE router. 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 The "No Prepend" feature causes ISP B's PE router to not prepend the
legacy AS, AS 64510, on all received eBGP UPDATE's from customer C. legacy AS, AS 64510, when advertising UPDATES received from customer
This restores the AS_PATH within ISP A' toward customer C so that it C. This restores the AS_PATH within ISP A' toward customer C so that
is just one ASN in length: 64496. 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>': appends the <old_ASN> value to the AS_PATH 1. 'local-as <old_ASN>': prepends the <old_ASN> value to the AS_PATH
of 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 of 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 As stated previously, local-as <old_ASN> no-prepend, (configuration
#2), is critical because it does not increase the AS_PATH length. #2), is critical because it does not increase the AS_PATH length.
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
skipping to change at page 7, line 50 skipping to change at page 8, line 4
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 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 is 1, then CE-2 would see an AS_PATH of: 64496 64510 64500, which
unacceptable). 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 only designed to
modify the AS_PATH Attribute received by the ISP in updates from CE modify the AS_PATH Attribute received by the ISP in updates from CE
devices, when CE devices still have an eBGP session established with devices, when CE devices still have an eBGP session established with
the ISPs legacy AS, (AS64510). In some existing implementations, the ISPs legacy AS, (AS64510). In some existing implementations,
"Local AS No Prepend" does not concurrently modify the AS_PATH "Local AS No Prepend" does not concurrently modify the AS_PATH
Attribute for BGP UPDATEs that are transmitted by the ISP to CE Attribute for BGP UPDATEs that are transmitted by the ISP to CE
devices. Specifically, with "Local AS No Prepend" enabled on ISP A's devices. Specifically, with "Local AS No Prepend" enabled on 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 unacceptable increase in AS_PATH length
networks directly attached to ISP A', which is unacceptable. 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
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.
skipping to change at page 9, line 29 skipping to change at page 9, line 33
is invoked, an ASN that is different from the globally-configured ASN is invoked, an ASN that is different from the globally-configured ASN
is provided as a part of the command as exemplified above. To is provided as a part of the command as exemplified above. To
implement this feature, a BGP speaker MUST send BGP OPEN messages 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 configured eBGP peer using the ASN configured for this session as
the value sent in MY ASN. The speaker MUST NOT use the ASN 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 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 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 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 peers expecting the legacy ASN after a router has been moved to a new
ASN. Additionally, when the BGP speaker configured with this feature ASN. Additionally, when the BGP speaker configured with this feature
receives updates from its neighbor, it MUST append the configured ASN receives updates from its neighbor, it MUST process the update as
in the AS_PATH attribute before processing the update as normal. normal, but it MUST append the configured ASN in the AS_PATH
attribute before advertising the UPDATE to any other BGP speaker.
Note that processing the update as normal will include appending the Note that processing the update as normal will include appending the
globally configured ASN to the AS_PATH, thus processing this update globally configured ASN to the AS_PATH, thus processing this update
will result in the addition of two ASNs to the AS_PATH attribute. will result in the addition of two ASNs to the AS_PATH attribute.
Similarly, for outbound updates sent by the configured BGP speaker to Similarly, for outbound updates sent by the configured BGP speaker to
its neighbor, the speaker MUST append the configured ASN to the its neighbor, the speaker MUST append the configured ASN to the
AS_PATH attribute, adding to the existing global ASN in the AS_PATH, AS_PATH attribute, adding to the existing global ASN in the AS_PATH,
for a total of two ASNs added to 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 Two options exist to manipulate the behavior of this feature. They
modify the behavior as described below: modify the behavior as described below:
No prepend inbound - When the BGP speaker configured with this option No prepend inbound - When the BGP speaker configured with this option
receives inbound updates from its neighbor, it MUST NOT append the receives inbound updates from its neighbor, it MUST NOT append the
configured ASN in the AS_PATH attribute and instead MUST append only configured ASN in the AS_PATH attribute when advertising that UPDATE
the globally configured ASN. to other peers and instead MUST append only the globally configured
ASN.
No prepend outbound - When the BGP speaker configured with this No prepend outbound - When the BGP speaker configured with this
option generates outbound BGP updates to the configured peer, the BGP option generates outbound BGP updates to the configured peer, the BGP
speaker MUST remove the globally configured ASN from the AS_PATH speaker MUST remove the globally configured ASN from the AS_PATH
attribute, and MUST append the locally configured ASN to 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. attribute before sending outbound BGP updates to the configured peer.
While the exact command syntax is an implementation detail beyond the While the exact command syntax is an implementation detail beyond the
scope of this document, the following consideration may be helpful scope of this document, the following consideration may be helpful
for implementers: Implementations MAY integrate the behavior of the for implementers: Implementations MAY integrate the behavior of the
 End of changes. 13 change blocks. 
27 lines changed or deleted 32 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/