One document matched: draft-hares-bose-dynamic_as-00.txt
Inter-domain Working Group S. Hares
Internet Draft NextHop Technologies
P. Bose
Lockheed-Martin
Expires: August 2005 February 16, 2005
Dynamic AS Re-Associaiton
draft-hares-bose-dynamic_as-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
This document may not be modified, and derivative works of it may not
be created.
This document may only be posted in an Internet-Draft.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 16, 2005.
Hares & Bose Expires August 2005 [Page 1]
draft-hares-bose-dynamic_as-00.txt February 2005
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document provides a mechanism for Autonomous Systems within an AS
Confederation to survive the disconnection to other AS within the AS
confederation without dropping peers. When all links to the other AS in
the Confederation break, this mechanism allows the AS to revert to local
AS to continue communication with E-BGP peers. This mechanism has two
parts: Capability signaling between the two parties at connection start
to save two AS (internal and AS Confederation AS) and a mechanism to
signal the switch between AS Confederation AS and internal AS.
Conventions used in this document
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 RFC-2119 [1].
Table of Contents
1. Overview of Dynamic AS Re-Association..........................3
2. Mechanism overview for Dynamic AS Re-association...............3
3. Dynamic AS Capability..........................................4
4. Capability Message.............................................5
5. Security Considerations........................................6
6. Acknowledgments................................................6
7. References.....................................................6
7.1. Normative References......................................6
Author's Addresses................................................7
Intellectual Property Statement...................................7
Disclaimer of Validity............................................7
Copyright Statement...............................................8
Acknowledgment....................................................8
Hares & Bose Expires August 2005 [Page 2]
draft-hares-bose-dynamic_as-00.txt February 2005
1. Overview of Dynamic AS Re-Association
This mechanism provides a mechanism for two BGP peers switching AS
values within a BGP association without dropping the AS connection.
When two BGP wish to re-configure with a different Autonomous
numbers, the current mechanisms in BGP require that the AS drop the
connection. If an AS has considerable fan-in of peers, this dropping
of the connection to re-associate a new AS may cause significant
outages.
This Dynamic AS re-association capability allows two Autonomous
Systems and their BGP peers to collude to reset the AS associated
with a BGP peer session without dropping the AS connection. The two
BGP peers agree upon a fail-over to another AS based on a list of
Autonomous Systems.
2. Mechanism overview for Dynamic AS Re-association
The mechanism has two parts:
1) An Dynamic AS capability
The Dynamic AS capability signals the ability to use the
Dynamic AS Re-association function.
The format of the ASConfed-Edge capability is described in
section 2 and contains a list of Autonomous systems that the
BGP peer may re-associated to. This capability also indicates
the mechanism by which the node will signal the switch is the
dynamic capabilities message.
2) Signaling the Dynamic AS Switch-over
Signaling a Dynamic Switch is done via the Dynamic Capability
message with the Dynamic AS capability.
Upon receiving this dynamic capability, the BGP speaker
associated with the AS-Confederation Edge process the switch of
the peer from the current AS number to the one specified in the
capability.
All checking of the local AS in BGP packets utilizes the new
AS.
All new routes will be announced with the new AS number. All
older routes will be re-announced based on the AS resend flag.
Hares & Bose Expires August 2005 [Page 3]
draft-hares-bose-dynamic_as-00.txt February 2005
3. Dynamic AS Capability
[RFC3992] describes the open capability mechanisms. This document
describes a new Capability: Dynamic AS:
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
Where the Capability value is:
+------------------------------+
| Length of AS (1 octet) | - length of AS field (2 or 4)
+------------------------------+
| resend prefix flag (1 octet) | - Resend/AS Flag
+------------------------------+
| Number of AS supported | - Number of AS in re-
+------------------------------+ associate list
| Autonomous System 1 | - AS 1 - for dynamic re-
+------------------------------+ association
| ... |
+------------------------------+
| Autonomous System n | - AS N - for dynamic re-
+------------------------------+ association
The resend prefix flag indicates when the AS will resend the
routes with the new AS. The flag values are set as a bit pattern
to indicate that
0x00 - Resend routes based on local timer (in bataches)
0x01 - Resend routes immediately
0x02 - Don't resend routes (leave with old AS confederation).
The number of AS supported field gives the number of the
Autonomous Systems fin the dynamic re-associations list. The
Autonomous Systems in the AS list are the list of ASes that this
peer may switch to in when dynamically re-association from the
original AS to a new AS.
Hares & Bose Expires August 2005 [Page 4]
draft-hares-bose-dynamic_as-00.txt February 2005
Each side of the peer will send a list of Autonomous Systems that
it will dynamic re-associate with. Upon start-up the re-
associations list can be check by policy to determine that each
side can support the required re-associations.
4. Capability Message
This BGP dynamic capability uses the new BGP Capability format of:
[DYN-CAP]
+------------------------------+
| Init/Ack (1 bit) |
+------------------------------+
| Ack Request (1 bit) |
+------------------------------+
| Reserved (5 bits) |
+------------------------------+
| Action (1 bit) |
+------------------------------+
| Sequence Number (4 octets) |
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (2 octets) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
The capability value is:
+------------------------------+
| Length of AS | - length of AS field
+------------------------------+
| resend prefix flag (1 octet) | - AS State
+------------------------------+
| Current AS number | - Old AS number
+------------------------------+
| New AS number | - new AS number
+------------------------------+
Resend flag values:
0x00 - Resend routes based on local timer
0x01 - Resend routes immediately
0x02 - Don't resend routes (leave with old AS confederation).
Hares & Bose Expires August 2005 [Page 5]
draft-hares-bose-dynamic_as-00.txt February 2005
5. Security Considerations
The security of the exchange is optionally secured by the TCP MD5
key.
Upon discussion with security reviewers, the addition of this feature
will neither improve nor detract from the TCP MD5 level of security.
The authors considered adding a "cookie" feature to further secure
this exchange. Again, review with security experts indicated this
"cookied" feature would not improve the security level.
The TCP session security will continue across the dynamic BGP peer
re-association. The TCP sessions dynamic MD5 re-association or key
switch would also allow TCP sessions to continue for a long period.
6. Acknowledgments
My thanks to Russ White(Cisco) and Dan Voce (LCM) for reviewing the
document.
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
7.2 Informative References
[DYN-CAP] Chen, E., Sangli, S.
"Dynamic Capability for BGP-4"
draft-ietf-idr-dynamic-cap-06.txt
[RFC3392] Chandra, R. , Scudder, S.,
"Capabilities Advertisement with BGP-4",
RFC3392, November 2002
Hares & Bose Expires August 2005 [Page 6]
draft-hares-bose-dynamic_as-00.txt February 2005
Author's Addresses
Susan Hares
NextHop Technologies
825 Victors Way, Suite 100
Ann Arbor, MI 48108
Phone: 734.222.1610
Email: skh@nexthop.com
Pratik Bose
Lockheed Martin
Email: Pratik.bose@lmco.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. By submitting this Internet-Draft, I certify that
any applicable patent or other IPR claims of which I am aware have
been disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
Hares & Bose Expires August 2005 [Page 7]
draft-hares-bose-dynamic_as-00.txt February 2005
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hares & Bose Expires August 2005 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 02:49:12 |