draft-ietf-idr-as-migration-05.txt   draft-ietf-idr-as-migration-06.txt 
Internet Engineering Task Force W. George Internet Engineering Task Force W. George
Internet-Draft Time Warner Cable Internet-Draft Time Warner Cable
Updates: 4271 (if approved) S. Amante Updates: 4271 (if approved) S. Amante
Intended status: Standards Track Apple, Inc. Intended status: Standards Track Apple, Inc.
Expires: October 30, 2015 April 28, 2015 Expires: January 7, 2016 July 6, 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-05 draft-ietf-idr-as-migration-06
Abstract Abstract
This draft discusses some existing commonly-used BGP mechanisms for This draft discusses some existing commonly-used BGP mechanisms for
ASN migration that are not formally part of the BGP4 protocol ASN migration that are not formally part of the BGP4 protocol
specification. It is necessary to document these de facto standards specification. It is necessary to document these de facto standards
to ensure that they are properly supported in future BGP protocol to ensure that they are properly supported in future BGP protocol
work. work.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 30, 2015. This Internet-Draft will expire on January 7, 2016.
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 AS Migration . . . . . . . . . . . . . . . . 9 4.1. Internal BGP AS Migration . . . . . . . . . . . . . . . . 10
4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 4.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12
5. Additional Operational Considerations . . . . . . . . . . . . 13 5. Additional Operational Considerations . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Implementation report . . . . . . . . . . . . . . . 15 Appendix A. Implementation report . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This draft discusses some existing commonly-used BGP mechanisms for This draft discusses some existing commonly-used BGP mechanisms for
Autonomous System Number (ASN) migration that are not formally part Autonomous System Number (ASN) migration that are not formally part
of the BGP4 [RFC4271] protocol specification. These mechanisms are of the BGP4 [RFC4271] protocol specification. These mechanisms are
local to a given BGP Speaker and do not require negotiation with or local to a given BGP Speaker and do not require negotiation with or
cooperation of BGP neighbors. The deployment of these mechanisms do cooperation of BGP neighbors. The deployment of these mechanisms do
not need to interwork with one another to accomplish the desired not need to interwork with one another to accomplish the desired
results, so slight variations between existing vendor implementations results, so slight variations between existing vendor implementations
skipping to change at page 6, line 9 skipping to change at page 6, line 9
[RFC4271] with a locally defined AS value for a specific BGP neighbor [RFC4271] with a locally defined AS value for a specific BGP neighbor
or group of neighbors. 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 of route
C would appear as: 64510, whereas the same RIB on ISP A' (ISP B announcements received from customer C would appear as: 64496,
routers post-migration) would contain AS_PATH: 64510 64496. whereas the same RIB on ISP A' (ISP B routers post-migration) would
contain AS_PATH: 64510 64496.
A second instrument, referred to as "No Prepend Inbound", is enabled A second instrument, referred to as "No Prepend Inbound", is enabled
on PE routers migrating from ISP B. The "No Prepend Inbound" on PE routers migrating from ISP B. The "No Prepend Inbound"
capability causes ISP B's routers to not prepend the legacy AS, AS capability causes ISP B's routers to not prepend the legacy AS, AS
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' for route announcements received
just one ASN in length: 64496. from 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": 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 installing or advertising routes received from a the AS_PATH when installing or advertising routes received from a
CE to iBGP neighbors inside the Autonomous System. CE to iBGP neighbors inside the Autonomous System.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
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: 64500 Inbound" on PE-B, then CE-A would have seen an AS_PATH of: 64500
64510 64496, which results in an unacceptable lengthening of the 64510 64496, which results in an unacceptable lengthening of the
AS_PATH). AS_PATH). NOTE: If there are still routers in the old ASN (64510),
it is possible for them to accept these manipulated routes (i.e.
those with 64510 removed from the AS_PATH by this command) as if they
have not already passed through their ASN, potentially causing a
loop, since BGP's normal loop-prevention behavior of rejecting routes
that include its ASN in the path will not catch these. Careful
filtering between routers remaining in the old ASN and routers
migrated to the new ASN is necessary to minimize the risk of routing
loops.
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"
skipping to change at page 8, line 6 skipping to change at page 8, line 15
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.
Figure 4: Replace AS BGP UPDATE Diagram Figure 4: Replace AS BGP UPDATE Diagram
By default, without the use of "Replace Old AS", CE-B would see an By default, without the use of "Replace Old AS", CE-B would see an
AS_PATH of: 64510 64500 64499, which is artificially lengthened, AS_PATH of: 64510 64500 64499. After ISP A' changes PE-B to use
typically by use of the "Local AS" and/or "No Prepend" capabilities "Replace Old AS", CE-B would receive an AS_PATH of: 64510 64499,
during the course of the ASN Migration. After ISP A' changes PE-B to which is the same AS_PATH length pre-AS migration.
use "Replace Old AS", CE-B would receive an AS_PATH of: 64510 64499,
which is the same AS_PATH length pre-AS migration. NOTE: If there
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
their ASN, potentially causing a loop, since BGP's normal loop-
prevention behavior of rejecting routes that include its ASN in the
path will not catch these. Careful filtering between routers
remaining in the old ASN and routers migrated to the new ASN is
necessary to minimize the risk of routing loops.
3.3. Implementation 3.3. Implementation
The mechanisms introduced in this section MUST be configurable on a The mechanisms introduced in this section MUST be configurable on a
per-neighbor or per neighbor group (i.e. a group of similar BGP per-neighbor or per neighbor group (i.e. a group of similar BGP
neighbor statements that reuse some common configuration to simplify neighbor statements that reuse some common configuration to simplify
provisioning) basis to allow for maximum flexibility. When the provisioning) basis to allow for maximum flexibility. When the
"Local AS" capability is used, a local ASN will be provided in the "Local AS" capability is used, a local ASN will be provided in the
configuration that is different from the globally-configured ASN of configuration that is different from the globally-configured ASN of
the BGP router. To implement this mechanism, a BGP speaker SHOULD the BGP router. To implement this mechanism, a BGP speaker SHOULD
skipping to change at page 8, line 48 skipping to change at page 8, line 48
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.
Note that this procedure will vary slightly if the locally or
globally configured ASN is a 4-octet ASN. See section 3 of
[RFC4893].
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 SHOULD append the configured "Local AS" ASN 1. Internal: the router SHOULD append the configured "Local AS" ASN
in the AS_PATH attribute before installing the route or in the AS_PATH attribute before installing the route or
advertising the UPDATE to an iBGP neighbor. advertising the UPDATE to an iBGP neighbor. The decision of when
to append the ASN is an implementation detail outside the scope
of this document. Some considerations factoring into this
decision include consistency in the AS_PATH throughout the AS,
and implementation of the loop detection mechanism.
2. External: the BGP router SHOULD 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 installing the route or advertising that UPDATE to iBGP when installing the route or advertising that UPDATE to iBGP
neighbors, but it MUST still append the globally configured ASN neighbors, but it MUST still append the globally configured ASN
as normal when advertising the UPDATE to other local eBGP as normal when advertising the UPDATE to other local eBGP
neighbors (i.e. those natively peering with the globally neighbors (i.e. those natively peering with the globally
configured ASN). 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 append the globally configured
configured ASN from the AS_PATH attribute. The BGP router MUST ASN from the AS_PATH attribute. The BGP router MUST append only
append only the configured "Local AS" ASN value to the AS_PATH the configured "Local AS" ASN value to the AS_PATH attribute
attribute before sending the BGP UPDATEs outbound to the eBGP 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 AS Migration 4.1. Internal BGP AS Migration
skipping to change at page 12, line 42 skipping to change at page 12, line 50
4.2. Implementation 4.2. Implementation
The mechanism introduced in this section MUST be configurable on a The mechanism introduced in this section MUST be configurable on a
per-neighbor or per neighbor group basis to allow for maximum per-neighbor or per neighbor group basis to allow for maximum
flexibility. When configured with this mechanism, a BGP speaker MUST flexibility. When configured with this mechanism, a BGP speaker MUST
accept BGP OPEN and establish an iBGP session from configured iBGP accept BGP OPEN and establish an iBGP session from configured iBGP
peers if the ASN value in "My Autonomous System" is either the peers if the ASN value in "My Autonomous System" is either the
globally configured ASN or a locally configured ASN provided when globally configured ASN or a locally configured ASN provided when
this capability is utilized. Additionally, a BGP router configured this capability is utilized. Additionally, a BGP router configured
with this mechanism MUST send its own BGP OPEN [RFC4271] (see section with this mechanism MUST send its own BGP OPEN [RFC4271] (see section
4.2) using both the globally configured and the locally configured 4.2) using either the globally configured or the locally configured
ASN in "My Autonomous System". To avoid potential deadlocks when two ASN in "My Autonomous System" as follows. To avoid potential
BGP speakers are attempting to establish a BGP peering session and deadlocks when two BGP speakers are attempting to establish a BGP
are both configured with this mechanism, the speaker SHOULD send BGP peering session and are both configured with this mechanism, the
OPEN using the globally configured ASN first, and only send a BGP speaker SHOULD send BGP OPEN using the globally configured ASN first,
OPEN using the locally configured ASN as a fallback if the remote and only send a BGP OPEN using the locally configured ASN as a
neighbor responds with the BGP error "Bad Peer AS". In each case, fallback if the remote neighbor responds with the BGP error "Bad Peer
the BGP speaker MUST treat UPDATEs sent and received to this peer as AS". In each case, the BGP speaker MUST treat UPDATEs sent and
if this was a natively configured iBGP session, as defined by received to this peer as if this was a natively configured iBGP
[RFC4271] and [RFC4456]. session, as defined by [RFC4271] and [RFC4456].
Note that this procedure will vary slightly if the locally or
globally configured ASN is a 4-octet ASN. See section 3 of
[RFC4893].
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 14, line 19 skipping to change at page 14, line 32
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]
8. Acknowledgements 8. 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, Juan David Farmer, Jaroslaw Adam Gralak, Gunter Van de Velde, Juan
Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, and Alvaro Retana Alcaide, Jon Mitchell, Thomas Morin, Alia Atlas, Alvaro Retana, and
for their comments. John Scudder for their comments.
9. References 9. References
9.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.
skipping to change at page 15, line 10 skipping to change at page 15, line 23
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>.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007.
[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.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007. (GTSM)", RFC 5082, October 2007.
[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.
 End of changes. 17 change blocks. 
44 lines changed or deleted 58 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/