One document matched: draft-hares-asconfed-edge-01.txt
Differences from draft-hares-asconfed-edge-00.txt
Inter-domain Working Group S.Hares
Internet Draft Nexthop Technologies
P. Bose
Lockheed-Martin
Expires: January 2006 July 18, 2005
Dynamic AS Switching at AS Confederation Edge
draft-hares-asconfed-edge-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 18, 2006.
Hares-Bose Expires January 18, 2006 [Page 1]
Internet-Draft draft-hares-asconfed-edge-01 July 2005
Copyright Notice
Copyright (C) The Internet Society (2005).
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
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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. BGP peer mechanisms............................................4
4. AS Edge Confederation Open Capability..........................7
5. Capability Message.............................................8
6. Security Considerations........................................9
7. Acknowledgments................................................9
8. References....................................................10
8.1. Normative References.....................................10
8.2. Informative References...................................10
Author's Addresses...............................................10
Intellectual Property Statement..................................10
Disclaimer of Validity...........................................11
Copyright Statement..............................................11
Acknowledgment...................................................11
Hares-Bose Expires January 18, 2006 [Page 2]
Internet-Draft draft-hares-asconfed-edge-01 July 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 AS-Confederation 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 January 18, 2006 [Page 3]
Internet-Draft draft-hares-asconfed-edge-01 July 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.
3. BGP peer mechanisms
The mechanism has two parts:
1) An AS-Confederation Edge capability
The ASConfed-Edge capability signals that a BGP peer ability to
use the Dynamic AS Dynamic-Capability exchange on an AS
Confederation Edge.
The format of the ASConfed-Edge capability is described in
section 4 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.
Within an AS, any BGP peer that will send an ASConfed-Edge
Capability to an Exterior peer MUST send the ASConfed-Edge
capability to all IBGP peers. Only if all IBGP Peers
successfully negotiated the ASConfed-Edge capability, can BGP
dynamically switch over to another AS.
2) Signaling the Dynamic AS Switch-over - Originator
Signaling a Dynamic Switch is done via the Dynamic Capability
message with the Dynamic AS capability (format in section 4).
Hares-Bose Expires January 18, 2006 [Page 4]
Internet-Draft draft-hares-asconfed-edge-01 July 2005
The BGP peer decides to initiate the dynamic AS switch over by
using local policy and implementation specific mechanisms. To
signal the Dynamic AS switch over, the initiating BGP peer has
two steps.
Step 1: Upon receiving a "Dynamic AS change" indication to the
BGP process, the BGP process will send to IBGP peers a "Dynamic
AS Switch-over" message. Upon receiving the ACK from all IBGP
peers for the Dynamic AS Capability, the BGP peer can start
step 2.
In case of the receiving IBGP peer's local BGP implementation
detecting a failure to switch to a new AS, the Dynamic
Capability will be signaled with a "failure" flag. This
failure will halt the originating Peer switch to the new AS.
If the IBGP peers are part of a Route-Reflection hierarchy, a
Route Reflector MUST wait to send an ack to the Dynamic AS
change after it has signaled all of its clients and all of it
total mesh peers. In this way, when the initiating IBGP peer
receives the Dynamic Capability ACK, the rest of the IBGP peer
has been informed.
Note: that the Dynamic Capability ACK may pass back success or
failure. A failure anywhere in an IBGP cloud will not allow
the BGP to progress to step 2.
Step 2: Send all EBGP peers the Dynamic AS Change.
Each EBGP peers signal the Dynamic AS change to its neighbor
with a Dynamic Capability.
Upon receiving this dynamic capability from an E-BGP peer, the
BGP speaker associated with the AS Edge processes 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 January 18, 2006 [Page 5]
Internet-Draft draft-hares-asconfed-edge-01 July 2005
3) E-BGP Receiving a Signaling the Dynamic AS Switch-over
Upon receiving a "Dynamic AS Change" Dynamic capability from
an EBGP peer, the EBGP peer will follow 2 steps:
Step 1: Upon receiving a "Dynamic AS change" capability to the
BGP process, the BGP process will send to IBGP peers "Dynamic
AS Switch-over" message with the E-BGP peer flag set. Upon
receiving the Dynamic Capability with the "Ack" bit set from
all IBGP peers for the Dynamic AS Capability, the BGP peer can
start step 2.
Again, if the IBGP peers of the receiving BGP are part of a
Route-Reflection hierarchy, a Route Reflector MUST only send
an ACK to the Dynamic AS change after it has successfully sent
the Dynamic Capability to its clients and all of it total mesh
peers. In this way, when the initiating IBGP peer receives
the Dynamic capability ACK, the rest of the IBGP peer has been
informed.
In case of errors in resetting the Dynamic AS capability, the
receiving IBGP peer can set the "Failure" flag in the Dynamic
capability that is being ACK. Any failures will be signaled
to the originating AS, and the Dynamic AS switch terminated.
Step 2: Respond to E-BGP AS with Dynamic AS change
The E-BGP peer responds to the originated AS with a Dynamic AS
change with an EBGP flag set.
Upon receiving this dynamic capability from an E-BGP peer, the
BGP speaker associated with the AS 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 January 18, 2006 [Page 6]
Internet-Draft draft-hares-asconfed-edge-01 July 2005
4. 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)
+------------------------------+
| Reserved (5 bits) | - Reserved
+------------------------------+
| resend prefix flag (3 bits) | - 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 January 18, 2006 [Page 7]
Internet-Draft draft-hares-asconfed-edge-01 July 2005
5. Capability Message
This BGP dynamic capability uses the new BGP Capability format of:
[DYN-CAP]
+------------------------------+
| Init/Ack (1 bit) |
+------------------------------+
| Ack Request (1 bit) | - always set to 1
+------------------------------+
| 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
+------------------------------+
| Source (1 bits) | - Source flag
+------------------------------+
| Failure flag (1 bits) | - Resend/AS Flag
+------------------------------+
| AS-in USE Flag (1 bit) | - AS in Use flag
+------------------------------+
| resend prefix flag (3 bits) | - Resend/AS Flag
+------------------------------+
| AS Confederation number | - AS Confederation number
+------------------------------+
| AS internal number | - internal AS number
+------------------------------+
Hares-Bose Expires January 18, 2006 [Page 8]
Internet-Draft draft-hares-asconfed-edge-01 July 2005
Source Flag flag (1 bits)
0 - node originated
1 - EBGP peer originated
Failiure Flag (1 bit)
1 - failure
0 - success
AS in USE:
0x01 - Internal AS number
0x00 - AS Confederation number
Resend flag values:
0x00 - Resend routes based on local timer (in bataches)
0x01 - Resend routes immediately
0x02 - Don't resend routes (leave with old AS confederation).
6. 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
7. 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.
Hares-Bose Expires January 18, 2006 [Page 9]
Internet-Draft draft-hares-asconfed-edge-01 July 2005
8. 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
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
8.2. Informative References
[3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-
1583, March 19
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@nexthop.com
Intellectual Property Statement
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
Hares-Bose Expires January 18, 2006 [Page 10]
Internet-Draft draft-hares-asconfed-edge-01 July 2005
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
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 January 18, 2006 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 02:50:28 |