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]