draft-ietf-idr-as-migration-04.txt   draft-ietf-idr-as-migration-05.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 Updates: 4271 (if approved) S. Amante
Expires: October 11, 2015 Apple, Inc. Intended status: Standards Track Apple, Inc.
April 9, 2015 Expires: October 30, 2015 April 28, 2015
Autonomous System Migration Mechanisms and Their Effects on the BGP Autonomous System Migration Mechanisms and Their Effects on the BGP
AS_PATH Attribute AS_PATH Attribute
draft-ietf-idr-as-migration-04 draft-ietf-idr-as-migration-05
Abstract Abstract
This draft discusses some commonly-used BGP mechanisms for ASN This draft discusses some existing commonly-used BGP mechanisms for
migration that are not formally part of the BGP4 protocol ASN migration that are not formally part of the BGP4 protocol
specification and may be vendor-specific in exact implementation. It specification. It is necessary to document these de facto standards
is necessary to document these de facto standards to ensure that they to ensure that they are properly supported in future BGP protocol
are properly supported in future BGP protocol work. work.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 11, 2015. This Internet-Draft will expire on October 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Documentation note . . . . . . . . . . . . . . . . . . . 3 1.2. Documentation note . . . . . . . . . . . . . . . . . . . 3
2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3 2. ASN Migration Scenario Overview . . . . . . . . . . . . . . . 3
3. External BGP Autonomous System Migration Mechanisms . . . . . 5 3. External BGP Autonomous System Migration Mechanisms . . . . . 5
3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 5 3.1. Modify Inbound BGP AS_PATH Attribute . . . . . . . . . . 5
3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7 3.2. Modify Outbound BGP AS_PATH Attribute . . . . . . . . . . 7
3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8 3.3. Implementation . . . . . . . . . . . . . . . . . . . . . 8
4. Internal BGP Autonomous System Migration Mechanisms . . . . . 9 4. Internal BGP Autonomous System Migration Mechanisms . . . . . 9
4.1. Internal BGP Alias . . . . . . . . . . . . . . . . . . . 9 4.1. Internal BGP AS Migration . . . . . . . . . . . . . . . . 9
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12
5. Additional Operational Considerations . . . . . . . . . . . . 13 5. Additional Operational Considerations . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. Appendix: Implementation report . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Implementation report . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This draft discusses some commonly-used BGP mechanisms for Autonomous This draft discusses some existing commonly-used BGP mechanisms for
System Number (ASN) migration that are not formally part of the BGP4 Autonomous System Number (ASN) migration that are not formally part
[RFC4271] protocol specification and may be vendor-specific in exact of the BGP4 [RFC4271] protocol specification. These mechanisms are
implementation. These mechanisms are local to a given BGP Speaker local to a given BGP Speaker and do not require negotiation with or
and do not require negotiation with or cooperation of BGP neighbors. cooperation of BGP neighbors. The deployment of these mechanisms do
The deployment of these mechanisms do not need to interwork with one not need to interwork with one another to accomplish the desired
another to accomplish the desired results, so slight variations results, so slight variations between existing vendor implementations
between existing vendor implementations exist, and will not exist, and will not necessarily be harmonized due to this document.
necessarily be harmonized due to this document. However, it is However, it is necessary to document these de facto standards to
necessary to document these de facto standards to ensure that new ensure that new implementations can be successful, and any future
implementations can be successful, and any future protocol protocol enhancements to BGP that propose to read, copy, manipulate
enhancements to BGP that propose to read, copy, manipulate or compare or compare the AS_PATH attribute can do so without inhibiting the use
the AS_PATH attribute can do so without inhibiting the use of these of these very widely used ASN migration mechanisms.
very widely used ASN migration mechanisms.
The migration mechanisms discussed here are useful to ISPs and The migration mechanisms discussed here are useful to ISPs and
organizations of all sizes, but it is important to understand the organizations of all sizes, but it is important to understand the
business need for these mechanisms and illustrate why they are so business need for these mechanisms and illustrate why they are so
critical for ISPs' operations. During a merger, acquisition or critical for ISPs' operations. During a merger, acquisition or
divestiture involving two organizations it is necessary to seamlessly divestiture involving two organizations it is necessary to seamlessly
migrate both internal and external BGP speakers from one ASN to a migrate both internal and external BGP speakers from one ASN to a
second ASN. The overall goal in doing so is to simplify operations second ASN. The overall goal in doing so is to simplify operations
through consistent configurations across all BGP speakers in the through consistent configurations across all BGP speakers in the
combined network. In addition, given that the BGP Path Selection combined network. In addition, given that the BGP Path Selection
skipping to change at page 5, line 48 skipping to change at page 5, line 47
mechanisms eliminate the artificial lengthening of the AS_PATH both mechanisms eliminate the artificial lengthening of the AS_PATH both
transmitted from and received by the Service Provider that is transmitted from and received by the Service Provider that is
undergoing AS Migration, which would have negative implications on undergoing AS Migration, which would have negative implications on
path selection by external networks. path selection by external networks.
3.1. Modify Inbound BGP AS_PATH Attribute 3.1. Modify Inbound BGP AS_PATH Attribute
The first instrument used in the process described above is called The first instrument used in the process described above is called
"Local AS". This allows the router to supersede the globally "Local AS". This allows the router to supersede the globally
configured ASN in the "My Autonomous System" field of the BGP OPEN configured ASN in the "My Autonomous System" field of the BGP OPEN
[RFC4271] with a locally defined AS value, usually configured on a [RFC4271] with a locally defined AS value for a specific BGP neighbor
per-neighbor basis. This mechanism allows the PE router that was or group of neighbors. This mechanism allows the PE router that was
formerly in ISP B to establish an eBGP session toward the existing CE formerly in ISP B to establish an eBGP session toward the existing CE
devices using the legacy AS, AS 64510. Ultimately, the CE devices devices using the legacy AS, AS 64510. Ultimately, the CE devices
(i.e.: customer C) are completely unaware that ISP B has reconfigured (i.e.: customer C) are completely unaware that ISP B has reconfigured
its router to participate as a member of a new AS. Within the its router to participate as a member of a new AS. Within the
context of the former ISP B PE router, the second effect this context of the former ISP B PE router, the second effect this
specific mechanism has on AS_PATH is that, by default, it prepends specific mechanism has on AS_PATH is that, by default, it prepends
all received BGP UPDATEs with the legacy AS of ISP B: AS 64510, while all received BGP UPDATEs with the legacy AS of ISP B: AS 64510, while
advertising it (Adj-RIB-Out) to other BGP speakers (A'). Within the advertising it (Adj-RIB-Out) to other BGP speakers (A'). Within the
Loc-RIB on ISP B prior to the migration, the AS_PATH toward customer Loc-RIB on ISP B prior to the migration, the AS_PATH toward customer
C would appear as: 64510, whereas the same RIB on ISP A' (ISP B C would appear as: 64510, whereas the same RIB on ISP A' (ISP B
skipping to change at page 6, line 27 skipping to change at page 6, line 26
64510, when advertising UPDATES received from customer C. This 64510, when advertising UPDATES received from customer C. This
restores the AS_PATH within ISP A' toward customer C so that it is restores the AS_PATH within ISP A' toward customer C so that it is
just one ASN in length: 64496. just one ASN in length: 64496.
In the direction of CE -> PE (inbound): In the direction of CE -> PE (inbound):
1. "Local AS": Allows the local BGP router to generate a BGP OPEN to 1. "Local AS": Allows the local BGP router to generate a BGP OPEN to
an eBGP neighbor with the old, legacy ASN value in the "My an eBGP neighbor with the old, legacy ASN value in the "My
Autonomous System" field. When this capability is activated, it Autonomous System" field. When this capability is activated, it
also causes the local router to prepend the <old_ASN> value to also causes the local router to prepend the <old_ASN> value to
the AS_PATH when advertising routes received from a CE to iBGP the AS_PATH when installing or advertising routes received from a
neighbors inside the Autonomous System. CE to iBGP neighbors inside the Autonomous System.
2. "No Prepend Inbound (of Local AS)": the local BGP router does not 2. "No Prepend Inbound (of Local AS)": the local BGP router does not
prepend <old_ASN> value to the AS_PATH when advertising routes prepend <old_ASN> value to the AS_PATH when installing or
received from the CE to iBGP neighbors inside the Autonomous advertising routes received from the CE to iBGP neighbors inside
System the Autonomous System
PE-B is a PE that was originally in ISP B, and has a customer eBGP PE-B is a PE that was originally in ISP B, and has a customer eBGP
session to CE-B. PE-B has had its global configuration ASN changed session to CE-B. PE-B has had its global configuration ASN changed
from AS 64510 to AS 64500 to make it part of the permanently retained from AS 64510 to AS 64500 to make it part of the permanently retained
ASN. This now makes PE-B a member of ISP A'. PE-A is a PE that was ASN. This now makes PE-B a member of ISP A'. PE-A is a PE that was
originally in ISP A, and has a customer peer CE-A. Although its originally in ISP A, and has a customer peer CE-A. Although its
global configuration ASN remains AS 64500, throughout this exercise global configuration ASN remains AS 64500, throughout this exercise
we also consider PE-A a member of ISP A'. we also consider PE-A a member of ISP A'.
ISP A' ISP A' ISP A' ISP A'
skipping to change at page 7, line 9 skipping to change at page 7, line 9
New_ASN: 64500 New_ASN: 64500
Note: Direction of BGP UPDATE as per the arrows. Note: Direction of BGP UPDATE as per the arrows.
Figure 3: Local AS and No Prepend BGP UPDATE Diagram Figure 3: Local AS and No Prepend BGP UPDATE Diagram
As a result using both the "Local AS" and "No Prepend Inbound" As a result using both the "Local AS" and "No Prepend Inbound"
capabilities on PE-B, CE-A will see an AS_PATH of: 64500 64496. CE-A capabilities on PE-B, CE-A will see an AS_PATH of: 64500 64496. CE-A
will not receive a BGP UPDATE containing AS 64510 in the AS_PATH. will not receive a BGP UPDATE containing AS 64510 in the AS_PATH.
(If only the "Local AS" mechanism was configured without "No Prepend (If only the "Local AS" mechanism was configured without "No Prepend
Inbound" on PE-B, then CE-A would have seen an AS_PATH of: 64496 Inbound" on PE-B, then CE-A would have seen an AS_PATH of: 64500
64510 64500, which results in an unacceptable lengthening of the 64510 64496, which results in an unacceptable lengthening of the
AS_PATH). AS_PATH).
3.2. Modify Outbound BGP AS_PATH Attribute 3.2. Modify Outbound BGP AS_PATH Attribute
The two aforementioned mechanisms, "Local AS" and "No Prepend The two aforementioned mechanisms, "Local AS" and "No Prepend
Inbound", only modify the AS_PATH Attribute received by the ISP's Inbound", only modify the AS_PATH Attribute received by the ISP's
PE's in the course of processing BGP UPDATEs from CE devices when CE PE's in the course of processing BGP UPDATEs from CE devices when CE
devices still have an eBGP session established with the ISPs legacy devices still have an eBGP session established with the ISPs legacy
AS, (AS64510). AS (AS64510).
In some existing implementations, "Local AS" and "No Prepend Inbound" In some existing implementations, "Local AS" and "No Prepend Inbound"
does not concurrently modify the AS_PATH Attribute for BGP UPDATEs does not concurrently modify the AS_PATH Attribute for BGP UPDATEs
that are transmitted by the ISP's PE's to CE devices. In these that are transmitted by the ISP's PE's to CE devices. In these
implementations, with "Local AS" and "No Prepend Inbound" used on PE- implementations, with "Local AS" and "No Prepend Inbound" used on PE-
B, it automatically causes a lengthening of the AS_PATH in outbound B, it automatically causes a lengthening of the AS_PATH in outbound
BGP UPDATEs from ISP A' toward directly attached eBGP speakers, BGP UPDATEs from ISP A' toward directly attached eBGP speakers,
(Customer C in AS 64496). The externally observed result is that (Customer C in AS 64496). The externally observed result is that
customer C, in AS 64496, will receive the following AS_PATH: 64510 customer C, in AS 64496, will receive the following AS_PATH: 64510
64500 64499. Therefore, if ISP A' takes no further action, it will 64500 64499. Therefore, if ISP A' takes no further action, it will
cause an unacceptable increase in AS_PATH length within customer's cause an unacceptable increase in AS_PATH length within customer's
networks directly attached to ISP A'. networks directly attached to ISP A'.
A tertiary mechanism is used to resolve this problem, referred to as A tertiary mechanism, referred to as "Replace Old AS", is used to
"Replace Old AS". This capability allows ISP A' to prevent routers resolve this problem. This capability allows ISP A' to prevent
from appending the globally configured ASN in outbound BGP UPDATEs routers from appending the globally configured ASN in outbound BGP
toward directly attached eBGP neighbors that are using the "Local AS" UPDATEs toward directly attached eBGP neighbors that are using the
mechanism. Instead, only the old (or previously used) AS will be "Local AS" mechanism. Instead, only the old (or previously used) AS
prepended in the outbound BGP UPDATE toward the customer's network, will be prepended in the outbound BGP UPDATE toward the customer's
restoring the AS_PATH length to what it what was before AS Migration network, restoring the AS_PATH length to what it what was before AS
occurred. Migration occurred.
To re-use the above diagram, but in the opposite direction, we have: To re-use the above diagram, but in the opposite direction, we have:
ISP A' ISP A' ISP A' ISP A'
CE-A ---> PE-A -------------------> PE-B ---> CE-B CE-A ---> PE-A -------------------> PE-B ---> CE-B
64499 New_ASN: 64500 Old_ASN: 64510 64496 64499 New_ASN: 64500 Old_ASN: 64510 64496
New_ASN: 64500 New_ASN: 64500
Note: Direction of BGP UPDATE as per the arrows. Note: Direction of BGP UPDATE as per the arrows.
skipping to change at page 8, line 21 skipping to change at page 8, line 21
are still routers in the old ASN, it is possible for them to accept are still routers in the old ASN, it is possible for them to accept
these manipulated routes as if they have not already passed through these manipulated routes as if they have not already passed through
their ASN, potentially causing a loop, since BGP's normal loop- their ASN, potentially causing a loop, since BGP's normal loop-
prevention behavior of rejecting routes that include its ASN in the prevention behavior of rejecting routes that include its ASN in the
path will not catch these. Careful filtering between routers path will not catch these. Careful filtering between routers
remaining in the old ASN and routers migrated to the new ASN is remaining in the old ASN and routers migrated to the new ASN is
necessary to minimize the risk of routing loops. necessary to minimize the risk of routing loops.
3.3. Implementation 3.3. Implementation
While multiple implementations already exist, the following documents The mechanisms introduced in this section MUST be configurable on a
the expected behavior such that a new implementation of this per-neighbor or per neighbor group (i.e. a group of similar BGP
mechanism could be done on other platforms. neighbor statements that reuse some common configuration to simplify
provisioning) basis to allow for maximum flexibility. When the
These mechanisms MUST be configurable on a per-neighbor or per peer- "Local AS" capability is used, a local ASN will be provided in the
group basis to allow for maximum flexibility. When the "Local AS" configuration that is different from the globally-configured ASN of
capability is used, a local ASN will be provided in the configuration the BGP router. To implement this mechanism, a BGP speaker SHOULD
that is different from the globally-configured ASN of the BGP router. send BGP OPEN [RFC4271] (see section 4.2) messages to the configured
To implement this mechanism, a BGP speaker MUST send BGP OPEN eBGP peer(s) using the local ASN configured for this session as the
[RFC4271] (see section 4.2) messages to the configured eBGP peer(s) value sent in "My Autonomous System". The BGP router SHOULD NOT use
using the local ASN configured for this session as the value sent in the ASN configured globally within the BGP process as the value sent
"My Autonomous System". The BGP router MUST NOT use the ASN in "My Autonomous System" in the OPEN message. This will avoid
configured globally within the BGP process as the value sent in "My causing the eBGP neighbor to unnecessarily generate a BGP OPEN Error
Autonomous System" in the OPEN message. This will avoid causing the message "Bad Peer AS". This method is typically used to re-establish
eBGP neighbor to unnecessarily generate a BGP OPEN Error message "Bad eBGP sessions with peers expecting the legacy ASN after a router has
Peer AS". This method is typically used to re-establish eBGP been moved to a new ASN.
sessions with peers expecting the legacy ASN after a router has been
moved to a new ASN.
Implementations MAY support a more flexible model where the eBGP Implementations MAY support a more flexible model where the eBGP
speaker attempts to open the BGP session using either the ASN speaker attempts to open the BGP session using either the ASN
configured as "Local AS" or the globally configured AS as discussed configured as "Local AS" or the globally configured AS as discussed
in BGP Alias (Section 4.2). If the session is successfully in BGP Alias (Section 4.2). If the session is successfully
established to the globally configured ASN, then the modifications to established to the globally configured ASN, then the modifications to
AS_PATH described in this document SHOULD NOT be performed, as they AS_PATH described in this document SHOULD NOT be performed, as they
are unnecessary. The benefit to this more flexible model is that it are unnecessary. The benefit to this more flexible model is that it
allows the remote neighbor to reconfigure to the new ASN without allows the remote neighbor to reconfigure to the new ASN without
direct coordination between the ISP and the customer. direct coordination between the ISP and the customer.
When the BGP router receives UPDATEs from its eBGP neighbor When the BGP router receives UPDATEs from its eBGP neighbor
configured with the "Local AS" mechanism, it processes the UPDATE as configured with the "Local AS" mechanism, it processes the UPDATE as
described in RFC4271 section 5.1.2 [RFC4271]. However the presence described in RFC4271 section 5.1.2 [RFC4271]. However the presence
of a second ASN due to "Local AS" adds the following behavior to of a second ASN due to "Local AS" adds the following behavior to
processing UPDATEs received from an eBGP neighbor configured with processing UPDATEs received from an eBGP neighbor configured with
this mechanism: this mechanism:
1. Internal: the router MUST append the configured "Local AS" ASN in 1. Internal: the router SHOULD append the configured "Local AS" ASN
the AS_PATH attribute before advertising the UPDATE to an iBGP in the AS_PATH attribute before installing the route or
neighbor. advertising the UPDATE to an iBGP neighbor.
2. External: the BGP router MUST first append the globally 2. External: the BGP router SHOULD first append the globally
configured ASN to the AS_PATH immediately followed by the "Local configured ASN to the AS_PATH immediately followed by the "Local
AS" value before advertising the UPDATE to an eBGP neighbor. AS" value before advertising the UPDATE to an eBGP neighbor.
Two options exist to manipulate the behavior of the basic "Local AS" Two options exist to manipulate the behavior of the basic "Local AS"
mechanism. They modify the behavior as described below: mechanism. They modify the behavior as described below:
1. "No Prepend Inbound" - When the BGP router receives inbound BGP 1. "No Prepend Inbound" - When the BGP router receives inbound BGP
UPDATEs from its eBGP neighbor configured with this option, it UPDATEs from its eBGP neighbor configured with this option, it
MUST NOT append the "Local AS" ASN value in the AS_PATH attribute MUST NOT append the "Local AS" ASN value in the AS_PATH attribute
when advertising that UPDATE to iBGP neighbors, but it MUST still when installing the route or advertising that UPDATE to iBGP
append the globally configured ASN as normal when advertising the neighbors, but it MUST still append the globally configured ASN
UPDATE to other local eBGP neigbors (i.e. those natively peering as normal when advertising the UPDATE to other local eBGP
with the globally configured ASN). neighbors (i.e. those natively peering with the globally
configured ASN).
2. "Replace Old AS", (outbound) - When the BGP router generates 2. "Replace Old AS", (outbound) - When the BGP router generates
outbound BGP UPDATEs toward an eBGP neighbor configured with this outbound BGP UPDATEs toward an eBGP neighbor configured with this
option, the BGP speaker MUST NOT (first) append the globally option, the BGP speaker MUST NOT (first) append the globally
configured ASN from the AS_PATH attribute. The BGP router MUST configured ASN from the AS_PATH attribute. The BGP router MUST
append only the configured "Local AS" ASN value to the AS_PATH append only the configured "Local AS" ASN value to the AS_PATH
attribute before sending the BGP UPDATEs outbound to the eBGP attribute before sending the BGP UPDATEs outbound to the eBGP
neighbor. neighbor.
4. Internal BGP Autonomous System Migration Mechanisms 4. Internal BGP Autonomous System Migration Mechanisms
The following section describes mechanisms that assist with a gradual The following section describes mechanisms that assist with a gradual
and least service impacting migration of Internal BGP sessions from a and least service impacting migration of Internal BGP sessions from a
legacy ASN to the permanently retained ASN. The following mechanism legacy ASN to the permanently retained ASN. The following mechanism
is very valuable to networks undergoing AS migration, but its use is very valuable to networks undergoing AS migration, but its use
does not cause changes to the AS_PATH attribute. does not cause changes to the AS_PATH attribute.
4.1. Internal BGP Alias 4.1. Internal BGP AS Migration
In this case, all of the routers to be consolidated into a single, In this case, all of the routers to be consolidated into a single,
permanently retained ASN are under the administrative control of a permanently retained ASN are under the administrative control of a
single entity. Unfortunately, the traditional method of migrating single entity. Unfortunately, the traditional method of migrating
all Internal BGP speakers, particularly within larger networks, is all Internal BGP speakers, particularly within larger networks, is
both time consuming and widely service impacting. both time consuming and widely service impacting.
The traditional method to migrate Internal BGP sessions was strictly The traditional method to migrate Internal BGP sessions was strictly
limited to reconfiguration of the global configuration ASN and, limited to reconfiguration of the global configuration ASN and,
concurrently, changing all iBGP neighbors' remote ASN from the legacy concurrently, changing all iBGP neighbors' remote ASN from the legacy
skipping to change at page 10, line 36 skipping to change at page 10, line 36
permits the coexistence of the legacy and permanently retained ASN permits the coexistence of the legacy and permanently retained ASN
within a single network, allowing for uniform BGP path selection within a single network, allowing for uniform BGP path selection
among all routers within the consolidated network. among all routers within the consolidated network.
The iBGP router with the "Internal BGP AS Migration" capability The iBGP router with the "Internal BGP AS Migration" capability
enabled allows the receipt of a BGP OPEN message with either the enabled allows the receipt of a BGP OPEN message with either the
legacy ASN value or the new, globally configured ASN value in the "My legacy ASN value or the new, globally configured ASN value in the "My
Autonomous System" field of the BGP OPEN message from iBGP neighbors. Autonomous System" field of the BGP OPEN message from iBGP neighbors.
It is important to recognize that enablement of the "Internal BGP AS It is important to recognize that enablement of the "Internal BGP AS
Migration" mechanism preserves the semantics of a regular iBGP Migration" mechanism preserves the semantics of a regular iBGP
session, (using identical ASNs). Thus, the BGP attributes session (i.e. using identical ASNs). Thus, the BGP attributes
transmitted by and the acceptable methods of operation on BGP transmitted by and the acceptable methods of operation on BGP
attributes received from iBGP sessions configured with "Internal BGP attributes received from iBGP sessions configured with "Internal BGP
AS Migration" capability are no different than those exchanged across AS Migration" capability are no different than those exchanged across
an iBGP session without "Internal BGP AS Migration" configured, as an iBGP session without "Internal BGP AS Migration" configured, as
defined by [RFC4271] and [RFC4456]. defined by [RFC4271] and [RFC4456].
Typically, in medium to large networks, BGP Route Reflectors Typically, in medium to large networks, BGP Route Reflectors
[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 routers. Furthermore, BGP session maintenance between adjacent iBGP routers. Furthermore, BGP
skipping to change at page 12, line 34 skipping to change at page 12, line 34
resultant packet loss -- during the period the configuration changes resultant packet loss -- during the period the configuration changes
are underway to complete the AS Migration. On the other hand, with are underway to complete the AS Migration. On the other hand, with
"Internal BGP AS Migration", the migration from the legacy ASN to the "Internal BGP AS Migration", the migration from the legacy ASN to the
permanently retained ASN can occur over a period of days or weeks permanently retained ASN can occur over a period of days or weeks
with reduced customer disruption. (The only observable service with reduced customer disruption. (The only observable service
disruption should be when each PE undergoes the changes discussed in disruption should be when each PE undergoes the changes discussed in
step 4 above.) step 4 above.)
4.2. Implementation 4.2. Implementation
When configured with this mechanism, a BGP speaker MUST accept BGP The mechanism introduced in this section MUST be configurable on a
OPEN and establish an iBGP session from configured iBGP peers if the per-neighbor or per neighbor group basis to allow for maximum
ASN value in "My Autonomous System" is either the globally configured flexibility. When configured with this mechanism, a BGP speaker MUST
ASN or a locally configured ASN provided when this capability is accept BGP OPEN and establish an iBGP session from configured iBGP
utilized. Additionally, a BGP router configured with this mechanism peers if the ASN value in "My Autonomous System" is either the
MUST send its own BGP OPEN [RFC4271] (see section 4.2) using both the globally configured ASN or a locally configured ASN provided when
globally configured and the locally configured ASN in "My Autonomous this capability is utilized. Additionally, a BGP router configured
System". To avoid potential deadlocks when two BGP speakers are with this mechanism MUST send its own BGP OPEN [RFC4271] (see section
attempting to establish a BGP peering session and are both configured 4.2) using both the globally configured and the locally configured
with this mechanism, the speaker SHOULD send BGP OPEN using the ASN in "My Autonomous System". To avoid potential deadlocks when two
globally configured ASN first, and only send a BGP OPEN using the BGP speakers are attempting to establish a BGP peering session and
locally configured ASN as a fallback if the remote neighbor responds are both configured with this mechanism, the speaker SHOULD send BGP
with the BGP error "Bad Peer AS". In each case, the BGP speaker MUST OPEN using the globally configured ASN first, and only send a BGP
treat UPDATEs sent and received to this peer as if this was a OPEN using the locally configured ASN as a fallback if the remote
natively configured iBGP session, as defined by [RFC4271] and neighbor responds with the BGP error "Bad Peer AS". In each case,
[RFC4456]. 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].
5. Additional Operational Considerations 5. Additional Operational Considerations
This document describes several mechanisms to support ISPs and other This document describes several mechanisms to support ISPs and other
organizations that need to perform ASN migrations. Other variations organizations that need to perform ASN migrations. Other variations
of these mechanisms may exist, for example, in legacy router software of these mechanisms may exist, for example, in legacy router software
that has not been upgraded or reached End of Life, but continues to that has not been upgraded or reached End of Life, but continues to
operate in the network. Such variations are beyond the scope of this operate in the network. Such variations are beyond the scope of this
document. document.
skipping to change at page 13, line 43 skipping to change at page 13, line 43
completing the migration from iBGP sessions using the legacy ASN to completing the migration from iBGP sessions using the legacy ASN to
the permanently retained ASN is more straightforward and could be the permanently retained ASN is more straightforward and could be
accomplished in a matter of days to months. Finally, good accomplished in a matter of days to months. Finally, good
operational hygiene would dictate that it is good practice to avoid operational hygiene would dictate that it is good practice to avoid
using "Internal BGP AS Migration" capability over a long period of using "Internal BGP AS Migration" capability over a long period of
time for reasons of not only operational simplicity of the network, time for reasons of not only operational simplicity of the network,
but also reduced reliance on that mechanism during the ongoing but also reduced reliance on that mechanism during the ongoing
lifecycle management of software, features and configurations that lifecycle management of software, features and configurations that
are maintained on the network. are maintained on the network.
6. Acknowledgements 6. IANA Considerations
Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson,
David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan
Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, and Alvaro Retana
for their comments.
7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 7. Security Considerations
This draft discusses a process by which one ASN is migrated into and This draft discusses a process by which one ASN is migrated into and
subsumed by another. This involves manipulating the AS_PATH subsumed by another. This involves manipulating the AS_PATH
Attribute with the intent of not increasing the AS_PATH length, which Attribute with the intent of not increasing the AS_PATH length, which
would typically cause the BGP route to no longer be selected by BGP's would typically cause the BGP route to no longer be selected by BGP's
Path Selection Algorithm in others' networks. This could result in Path Selection Algorithm in others' networks. This could result in
sudden and unexpected shifts in traffic patterns in the network, sudden and unexpected shifts in traffic patterns in the network,
potentially resulting in congestion. potentially resulting in congestion.
Given that these mechanisms can only be enabled through configuration Given that these mechanisms can only be enabled through configuration
of routers within a single network, standard security measures should of routers within a single network, standard security measures should
be taken to restrict access to the management interface(s) of routers be taken to restrict access to the management interface(s) of routers
that implement these mechanisms. Additionally, BGP sessions SHOULD that implement these mechanisms. Additionally, BGP sessions SHOULD
be protected using TCP Authentication Option [RFC5925] and the be protected using TCP Authentication Option [RFC5925] and the
Generalized TTL Security Mechanism [RFC5082] Generalized TTL Security Mechanism [RFC5082]
9. Appendix: Implementation report 8. Acknowledgements
As noted elsewhere in this document, this set of migration mechanisms
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 Thanks to Kotikalapudi Sriram, Stephane Litkowski, Terry Manderson,
do exist in other implementations, however the authors were unable to David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan
find publicly available documentation of the vendor-specific Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, and Alvaro Retana
implementation to reference. for their comments.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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.
10.2. Informative References 9.2. Informative References
[ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012, [ALU] Alcatel-Lucent, "BGP Local AS attribute", 2006-2012,
<https://infoproducts.alcatel-lucent.com/html/0_add- <https://infoproducts.alcatel-lucent.com/html/0_add-
h-f/93-0074-10-01/7750_SR_OS_Routing_Protocols_Guide/BGP- h-f/93-0074-10-01/7750_SR_OS_Routing_Protocols_Guide/BGP-
CLI.html#709567>. CLI.html#709567>.
[CISCO] Cisco Systems, Inc., "BGP Support for Dual AS [CISCO] Cisco Systems, Inc., "BGP Support for Dual AS
Configuration for Network AS Migrations", 2003, Configuration for Network AS Migrations", 2003,
<http://www.cisco.com/c/en/us/td/docs/ios- <http://www.cisco.com/c/en/us/td/docs/ios-
xml/ios/iproute_bgp/configuration/xe-3s/asr1000/ xml/ios/iproute_bgp/configuration/xe-3s/asr1000/
skipping to change at page 15, line 43 skipping to change at page 15, line 26
[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.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for
Private Use", BCP 6, RFC 6996, July 2013. Private Use", BCP 6, RFC 6996, July 2013.
Appendix A. Implementation report
As noted elsewhere in this document, this set of migration mechanisms
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.
Authors' Addresses Authors' Addresses
Wesley George Wesley George
Time Warner Cable Time Warner Cable
13820 Sunrise Valley Drive 13820 Sunrise Valley Drive
Herndon, VA 20171 Herndon, VA 20171
US US
Phone: +1 703-561-2540 Phone: +1 703-561-2540
Email: wesley.george@twcable.com Email: wesley.george@twcable.com
 End of changes. 28 change blocks. 
120 lines changed or deleted 120 lines changed or added

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