One document matched: draft-hares-asconfed-edge-00.txt
Inter-domain Working Group S.Hares
Internet Draft NextHop Technologies
P.Bose
Lockheed-Martin
Expires: August 2005 February 13, 2005
Dynamic AS Switching at AS Confederation Edge
draft-hares-asconfed-edge-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 2005.
Hares-Bose Expires August 2005 [Page 1]
draft-ietf-hares-bose-ASConfed-edge-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 switching for AS Confederation Edge.....3
2. Mechanism Overview.............................................3
3. AS Edge Confederation Open Capability..........................5
4. Capability Message.............................................6
5. Security Considerations........................................7
6. Acknowledgments................................................7
7. References.....................................................7
Author's Addresses................................................8
Intellectual Property Statement...................................8
Disclaimer of Validity............................................8
Copyright Statement...............................................9
Acknowledgment....................................................9
Hares-Bose Expires - August 2005 [Page 2]
draft-ietf-hares-bose-ASConfed-edge-00.txt February 2005
1. Overview of Dynamic AS switching for AS Confederation Edge
This mechanism provides a mechanism for an Autonomous System within
an AS confederation to survive disconnection from the rest of the
Autonomous Systems within the AS Confederation. When an AS is
connected to the rest of an AS confederation, it acts as a single AS.
If all links between the AS to other members of the AS confederation
are broken, the AS Confederation is broken in two (or more) parts,
and the individual sub-Autonomous Systems (sub-AS-es) within the
confederation may need to "back off" to their local AS number to
restore connectivity through some external path.
If a router along the edge of an AS determines the sub-AS has lost
its connection to the remainder of the confederation AS, it will need
to change the AS number with which it is peering to eBGP peers. This
restart of all EBGP connections can be onerous for the AS that has
broken away from the AS Confederation. This draft provides a
mechanism for the AS within the AS confederation to use a pre-agreed
upon fail-over to the internal AS, so its eBGP connections will not
be reset.
Upon return of the AS Confederation links, this mechanism can signal
the Edge AS returning to the AS Confederation.
2. Mechanism Overview
The mechanism has two parts:
1. An ASConfed-Edge capability
The ASConfed-Edge capability signals the ability to fail-over
upon "AS confederation disconnect" by changing the local AS
number without resetting the eBGP peering session.
The format of the ASConfed-Edge capability is described in
section 2 and contains the AS of the Confederation and a list
of Internal AS that the BGP peer will back off to. This
capability also indicates the mechanism by which the node will
signal the switch via the dynamic capabilities.
Note: The detection of the "AS confederation disconnect" is a
locally determined feature that includes (but is not limited
to): determining that all AS Confederation BGP peers are
disconnected from this peer.
Hares-Bose Expires - August 2005 [Page 3]
draft-ietf-hares-bose-ASConfed-edge-00.txt February 2005
2. Signaling the AS back off via dynamic capabilities
Signaling an AS fail-over is done via a Dynamic Capability with
the ASConfed_Edge capability with AS flag on.
Upon receiving this dynamic capability, the BGP speaker
associated with the AS-Confederation Edge switches from the AS
confederation to the AS number specified for the session to the
internal session.
All checking of the local AS in BGP packets utilizes the new
AS.
When the AS Confederations links are re-established, the BGP
speaker on the AS Confederation sends a Dynamic Capability with
the ASConfed_Edge Capability (with Confed flag on). All AS
checking for the local BGP speaker reverts to the original AS.
Hares-Bose Expires - August 2005 [Page 4]
draft-ietf-hares-bose-ASConfed-edge-00.txt February 2005
3. AS Edge Confederation Open Capability
[RFC3992] describes the open capability mechanisms. This document
describes a new Capability: ASConfed-Switch:
+------------------------------+
| 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
+------------------------------+
| AS Confederation number | - Confederation AS
+------------------------------+
| AS internal number 1 | - Internal AS 1
+------------------------------+
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 (may send in groups)
0x01 - Resend routes immediately
0x02 - Don't resend routes (leave with old AS confederation).
Hares-Bose Expires - August 2005 [Page 5]
draft-ietf-hares-bose-ASConfed-edge-00.txt February 2005
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
+------------------------------+
| AS in Use (1 octet) | - AS in Use
+------------------------------+
| resend prefix flag (1 octet) | - AS State
+------------------------------+
| AS Confederation number | - AS Confederation number
+------------------------------+
| AS internal number | - internal AS number
+------------------------------+
AS in USE:
0x01 - Internal AS number
0x00 - AS Confederation number
Resend flag values:
Hares-Bose Expires - August 2005 [Page 6]
draft-ietf-hares-bose-ASConfed-edge-00.txt February 2005
0x00 - Resend routes based on local timer (in bataches)
0x01 - Resend routes immediately
0x02 - Don't resend routes (leave with old AS confederation).
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.
6. Acknowledgments
Our thanks to Russ White(Cisco) and Dan Voce (LCM) for reviewing the
document. Our thanks to members of the IDR working group for the
review of the concepts of this document at the November 2004 IETF.
7. 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
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Hares-Bose Expires - August 2005 [Page 7]
draft-ietf-hares-bose-ASConfed-edge-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 8]
draft-ietf-hares-bose-ASConfed-edge-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 9]
| PAFTECH AB 2003-2026 | 2026-04-24 02:51:39 |