One document matched: draft-ga-idr-as-migration-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5065 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5065.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ga-idr-as-migration-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="AS Migration Features">Autonomous System (AS) Migration
Features and Their Effects on the BGP AS_PATH Attribute</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Wesley George" initials="W" surname="George">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<phone>+1 703-561-2540</phone>
<email>wesley.george@twcable.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Shane Amante" initials="S" surname="Amante">
<organization>Level 3 Communications</organization>
<address>
<postal>
<street>1025 Eldorado Blvd</street>
<!-- Reorder these if your country does things differently -->
<city>Broomfield</city>
<region>CO</region>
<code>80021</code>
<country>US</country>
</postal>
<phone/>
<email>shane@level3.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2012"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>as-migration, AS-migration, AS_migration, AS migration, IDR, BGP,
AS_PATH, AS-Path</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This draft discusses common methods of managing an ASN migration
using some BGP features that while commonly-used are not formally part
of the BGP4 protocol specification and may be vendor-specific in exact
implementation. It is necessary to document these de facto standards to
ensure that they are properly supported in BGPSec.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This draft discusses common methods of managing an ASN migration
using some BGP features that while commonly-used are not formally part
of the <xref target="RFC4271">BGP4</xref> protocol specification and may
be vendor-specific in exact implementation. This draft does not attempt
to standardize these features, because they are local to given
implementation and do not require negotiation with or cooperation of BGP
neighbors. The deployment of these features do not need to interwork
with one another to accomplish the desired results. However, it is
necessary to document these de facto standards to ensure that any future
protocol enhancements to BGP that propose to read, copy, manipulate or
compare the AS_PATH attribute can do so without inhibiting the use of
these very widely used ASN migration features.</t>
<t>It is important to understand the business need for these features,
as well, to illustrate why they are critical, particularly for ISP's
operations. (It should be noted that these features are not limited to
ISP's and that organizations of all sizes use these features for similar
reasons to ISP's). During a merger, acquisition or divestiture involving
two organizations it is necessary to seamlessly migrate BGP speakers
from one ASN to a second ASN. The overall goal in doing so, particularly
in the case of a merger or acquisition, is to achieve a uniform
operational model through consistent configurations across all BGP
speakers in the combined network. In addition, and perhaps more
importantly, it is common practice in the industry for ISPs to bill
customers based on utilization. ISPs bill customers based on the 95th
percentile of the greater of the traffic sent or received, over the
course of a 1-month period, on the customer's PE-CE access circuit.
Given that the BGP Path Selection algorithm selects routes with the
shortest AS_PATH attribute, it is critical for the ISP to not increase
AS_PATH length during or after ASN migration, toward both downstream
transit customers as well as settlement-free peers, who are likely
sending or receiving traffic from those transit customers. This would
not only result in sudden changes in traffic patterns in the network,
but also (substantially) decrease utilization driven revenue at the ISP.
It can also be bad for the end customers, as they may use AS prepends as
a way to manage the AS_PATH to ensure optimal traffic engineering from
their multiple upstream SPs, and a sudden change in the AS_PATH may
cause an undesirable shift in traffic.</t>
<t>Lastly, it is important to note that, by default, the BGP protocol
requires an operator to configure a single remote ASN for the eBGP
neighbor inside a router, in order to successfully negotiate and
establish an eBGP session. Prior to the existence of these features, it
would have required an ISP to work with, in some cases, tens of
thousands of customers. In particular, the ISP would have to encourage
those customers to change their CE router configs to use the new ASN, in
a very short period of time, when the customer has no business incentive
to do so. Thus, it because critical to allow the ISP to seamlessly
migrate the ASN within its network(s), not disturb existing customers
and allow the customer's to gradually migrate to the ISP's new ASN at
their leisure.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="ASN Migration Scenario Overview">
<t>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
will assume the most common case where there are two ISPs, A and B, that
use AS 200 and 300, respectively, before the ASN migration is to occur.
AS 200 will be the "keep" ASN used across the consolidated set of both
ISPs' network equipment and AS 300 will be retired. Thus, at the
conclusion of the ASN migration, there will be a single ISP A' with all
internal BGP speakers configured to use AS 200. To all external BGP
speakers, the AS_PATH length will not be increased.</t>
<t>In this same scenario, AS 100 and AS 400 represent two, separate
customer networks: C and D, respectively. Originally, customer C (AS
100) is attached to ISP B, which will undergo ASN migration from AS 300
to AS 200. Furthermore, customer D (AS 100) is attached to ISP A, which
does not undergo ASN migration since ISP A's ASN will remain constant,
(AS 200). Although this example refers to AS 100 and 400 as customer
networks, either or both may be settlement-free or other types of peers.
In this use case they are referred to as "customers" merely for
convenience.</t>
<t>The general order of operations, typically carried out in a single
maintenance window by the network undergoing ASN migration, ISP B, are
as follows. First, ISP B, will change the global BGP ASN used by a PE
router, from ASN 300 to 200. At this point, the router will no longer be
able to establish eBGP sessions toward the existing CE devices that are
attached to it and still using AS 300. Second, ISP B will configure two
separate, but related ASN migration features discussed in this document
on all eBGP sessions toward all CE devices. These features modify the
AS_PATH attribute received from and transmitted toward CE devices to
achieve the desired effect of not increasing the length of the
AS_PATH.</t>
<t>At the conclusion of the ASN migration, The subset of eBGP speakers,
AS 400, that were formerly configured to establish a BGP session with
ISP B's legacy AS 300 will still receive AS 300 in the AS_PATH received
from ISP A'. To be clear, that same subset of CE devices, in AS 400,
will not see the new AS 200 in the AS_PATH, until the time those CE
devices have changed their configuration to establish an eBGP session to
the new AS, AS 200.</t>
<t>In this use case, neither ISP is using BGP Confederations <xref
target="RFC5065">RFC 5065</xref> internally.</t>
<t>Additional information about this scenario, including vendor-specific
implementation details can be found here: <xref
target="CISCO">Cisco</xref> and here: <xref
target="JUNIPER">Juniper</xref>. Equivalent features do exist in several
implementations, however publicly available documentation is not
available. Finally, the examples cited below use Cisco IOS CLI for ease
of illustration purposes only.</t>
</section>
<section title="Local AS: Modify Inbound BGP AS_PATH Attribute">
<t>ISP B needs to reconfigure its router(s) to participate as an
internal BGP speaker in AS 200, to realize the business goal of becoming
a single Service Provider: ISP A'. ISP B needs to do this without
coordinating the change of its ASN with all of its eBGP peers,
simultaneously. The first step is for ISP B to change the global AS in
its router configuration, used by the local BGP process as the
system-wide Autonomous System ID, from AS 300 to AS 200. The next step
is for ISP B to establish iBGP sessions with ISP A's existing routers,
thus consolidating ISP B into ISP A operating under a single AS: ISP A',
(AS 200).</t>
<t>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 called
"Local AS". This feature allows ISP B's PE router to re-establish an
eBGP session toward the existing CE devices using the legacy AS, AS 300,
in the eBGP session establishment. Ultimately, 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. Within the context of ISP
B's PE router, the second effect this feature has is that, by default,
it prepends all received BGP UPDATE's with the legacy AS of ISP B: AS
300. Thus, within ISP A' the AS_PATH toward customer C would appear as:
300 100, 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 300, on all received eBGP UPDATE's from customer C.
This restores the AS_PATH within ISP A' toward customer C so that it is
just one AS long: 100.</t>
<t>In the direction of CE -> PE (inbound):</t>
<t><list style="numbers">
<t>'local-as <old_ASN>': appends the <old_ASN> value to
the AS_PATH of routes received from the CE</t>
<t>'local-as <old_ASN> no-prepend': does not prepend
<old_ASN> value to the AS_PATH of routes received from the
CE</t>
</list></t>
<t>As stated previously, local-as <old_ASN> no-prepend,
(configuration #2), is critical because it does not increase the AS_PATH
length. Ultimately, this ensures that routes learned from ISP B's legacy
customers will be transmitted through legacy eBGP sessions of ISP A,
toward both customers and peers, will contain only two ASes in the
AS_PATH: 200 100. Thus, the legacy customers and peers of ISP A will not
see an increase in the AS_PATH length to reach ISP B's legacy
customers.</t>
<t>PE-1 is a PE that was originally in ISP B. PE-1 has had its global
configuration AS changed from AS 300 to AS 200 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
AS remains AS 200 throughout this exercise we also consider PE-2 a
member of ISP A'.</t>
<figure align="left" anchor="local_as"
title="Local AS BGP UPDATE Diagram">
<artwork align="left"><![CDATA[
ISP A' ISP A'
CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2
100 Old_ASN: 300 New_ASN: 200 400
New_ASN: 200
]]></artwork>
<postamble>Note: Direction of BGP UPDATE as per the
arrows.</postamble>
</figure>
<t/>
<t>The final configuration on PE-1 after completing the "Local AS"
portion of the AS migration is as follows: <figure align="left">
<artwork align="left"><![CDATA[
router bgp 200
neighbor <CE-1_IP> remote-as 100
neighbor <CE-1_IP> local-as 300 no-prepend
]]></artwork>
</figure></t>
<t>As a result of the "Local AS No Prepend" configuration, on PE-1, CE-2
will see an AS_PATH of: 200 100. CE-2 will not receive a BGP UPDATE
containing AS 300 in the AS_PATH. (If only the "local-as 300" feature
was configured without the keyword "no-prepend" on PE-1, then CE-2 would
see an AS_PATH of: 100 300 200, which is not desirable).</t>
</section>
<section title="Replace AS: Modify Outbound BGP AS_PATH Attribute">
<t>The previous feature, "Local AS No Prepend", modifies not only the
AS_PATH Attribute received from CE devices, but also the AS_PATH
Attribute transmitted to CE devices as well. Specifically, with "Local
AS No Prepend" enabled on ISP B's PE, it causes outbound BGP UPDATES
toward its directly attached eBGP speakers, customer C in AS 100, to
have the AS_PATH Attribute prepended with the new global configuration
AS on ISP B's PE. The result will be that customer C, in AS 100, will
receive the following AS_PATH: 300 200 400. Therefore, if ISP B takes no
further action, it will cause an increase in AS_PATH length within
customer's networks directly attached to ISP B, which is
unacceptable.</t>
<t>A second feature, called "Replace AS", was designed to resolve this
problem. This feature allows the ISP to not prepend the global
configured AS in outbound BGP UPDATE's toward customer's networks
configured with the "Local AS" feature. Instead, only the historical
(or, legacy) AS will be prepended in the outbound BGP UPDATE toward
customer's network, restoring the AS_PATH length to what it what was
before AS Migration occurred.</t>
<t>To re-use the above diagram, but in the opposite direction, we
have:</t>
<figure align="left" anchor="replace_as"
title="Replace AS BGP UPDATE Diagram">
<artwork align="left"><![CDATA[
ISP A' ISP A'
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
100 Old_ASN: 300 New_ASN: 200 400
New_ASN: 200
]]></artwork>
<postamble>Note: Direction of BGP UPDATE as per the
arrows.</postamble>
</figure>
<t>The final configuration on PE-1 after completing the "Replace AS"
portion of the AS migration is as follows: <figure align="left">
<artwork align="left"><![CDATA[
router bgp 200
neighbor <CE-1_IP> remote-as 100
neighbor <CE-1_IP> local-as 300 no-prepend replace-as
]]></artwork>
</figure></t>
<t>By default, without "Replace AS" enabled, CE-1 would see an AS_PATH
of: 300 200 400, which is artificially lengthened by the ASN Migration.
After ISP A' changes PE-1 to include the "Replace AS" feature, CE-1
would receive an AS_PATH of: 200 400, which is the same AS_PATH length
pre-AS migration.</t>
</section>
<section title="Additional Operational Considerations">
<t>This document describes just two variations of
implementation-specific features to support ISP's and other
organizations that need to perform ASN migrations. Other variations of
these features may exist, for example, in legacy router software 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
document.</t>
<t>Companies routinely go through periods of mergers, acquisitions and
divestitures, which in the case of the former cause them to accumulate
several legacy ASNs over time. Since ISPs often do not have control over
the configuration of customer's devices, (i.e.: the ISPs are often not
providing a managed CE router service, particularly to medium and large
customers that require eBGP), and since the ISP is using methods to
perform ASN migration that do not require coordination with customers,
there is not a finite period of time that the legacy ASNs will be
completely expunged from the ISP's network. In fact, it is common that
legacy ASNs along with the features discussed in this document can and
do persist for several years if not longer. Thus, it is prudent to plan
that legacy ASNs and associated features will persist in a operational
network indefinitely.</t>
</section>
<section title="Conclusion">
<t>Although the features discussed in this document are not formally
recognized as part of the BGP4 specification, they have been in
existence in commercial implementations for well over a decade. These
features are widely known by the operational community and will continue
to be a critical necessity in the support of network integration
activities going forward. Therefore, these features are extremely
unlikely to be deprecated by vendors. As a result, these features must
be acknowledged by protocol designers, particularly when there are
proposals to modify BGP's behavior with respect to handling or
manipulation of the AS_PATH Attribute. More specifically, assumptions
should not be made with respect to the preservation or consistency of
the AS_PATH Attribute as it is transmitted along a sequence of ASNs. In
addition, proposals to manipulate the AS_PATH that would gratuitously
increase AS_PATH length or remove the capability to use these features
described in this document will not be accepted by the operational
community.</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Kotikalapudi Sriram for his comments.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This draft discusses a process by which one ASN is migrated into and
subsumed by another. This involves manipulating the AS_PATH 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 Path
Selection Algorithm in other's networks. This could result in a loss of
revenue if the ISP is billing based on measured utilization of traffic
sent to/from entities attached to its network. This could also result in
sudden, and unexpected shifts in traffic patterns in the network,
potentially resulting in congestion, in the most extreme cases. While
this I-D does not introduce any new security considerations, as it is
simply documenting current functionality, the reader should be aware
that manipulation if the AS_PATH attribute has several known attack
vectors that can result in the same sort of undesired traffic
shifts.</t>
<t>Given that these features can only be enabled through configuration
of router's within a single network, standard security measures should
be taken to restrict access to the management interface(s) of routers
that implement these features.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC4271;
&RFC5065;
<!-- A reference written by by an organization not a person. -->
<reference anchor="CISCO"
target="http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtbgpdas.html">
<front>
<title>BGP Support for Dual AS Configuration for Network AS
Migrations</title>
<author>
<organization>Cisco Systems, Inc.</organization>
</author>
<date year="2003"/>
</front>
</reference>
<reference anchor="JUNIPER"
target="http://www.juniper.net/techpubs/en_US/junos12.2/information-products/topic-collections/nce/bgp-local-as/bgp-local-as-configuring.pdf">
<front>
<title>Configuring the BGP Local Autonomous System Attribute</title>
<author>
<organization>Juniper Networks, Inc.</organization>
</author>
<date year="2012"/>
</front>
</reference>
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:49:53 |