Network Working Group Enke Chen Internet Draft Jenny Yuan Expiration Date:
March 2004 Redback NetworksOctober 2005 Cisco Systems AS-wide Unique BGP Identifier for BGP-4 draft-ietf-idr-bgp-identifier-04.txtdraft-ietf-idr-bgp-identifier-05.txt 1. Status of this Memo By submitting this Internet-Draft, I certifyeach author represents that any applicable patent or other IPR claims of which I amhe or she is aware have been disclosed,or will be disclosed, and any of which I becomehe or she becomes aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions ofSection 106 of RFC2026.BCP 79. 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"work in progress.''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. 2. Abstract To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. 3. Introduction Currently the BGP Identifier of a BGP speaker is specified as a valid IPv4 host address assigned to the BGP speaker [BGP-4]. In addition, the deployed BGP code requires that two BGP speakers be of distinct BGP Identifiers in order to establish a BGP connection. To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. 4. Protocol Revisions The revisions to the base BGP specification [BGP-4] include the definition of the BGP Identifier and procedures for a BGP speaker that supports the AS-wide Unique BGP Identifier. 4.1. Definition of the BGP Identifier For a BGP speaker that supports the AS-wide Unique BGP Identifier, the BGP Identifier is specified as the following: The BGP Identifier is a 4-octet unsigned, non-zero integer that should be unique within an AS. The value of the BGP Identifier for a BGP speaker is determined on startup and is the same for every local interface and every BGP peer. 4.2. Open Message Error Handling For a BGP speaker that supports the AS-wide Unique BGP Identifier, the OPEN message error handling related to the BGP Identifier is modified as follows: If the BGP Identifier field of the OPEN message is zero, or if it is the same as the BGP Identifier of the local BGP speaker and the message is from an internal peer, then the Error Subcode is set to "Bad BGP Identifier". 4.3. Connection Collision Resolution For a BGP speaker that supports the AS-wide Unique BGP Identifier, the procedures for connection collision resolution are extended as follows to deal with the case in which the two BGP speakers share the same BGP Identifier (thus it is only applicable to an external peer): If the BGP Identifiers of the peers involved in the connection collision are identical, then the connection initiated by the BGP speaker with the larger AS number is preserved. This extension covers cases in which the four-octet AS numbers are involved [BGP-4BYTE-AS]. 5. Remarks It is noted that a BGP Identifier allocated based on [BGP-4] fits the revised definition. In case of BGP Confederation, the whole confederation is considered as one AS for the purpose of supporting the AS-wide Unique BGP Identifier. A BGP speaker that supports the AS-wide Unique BGP Identifier can not share a BGP Identifier with its external neighbor until the remote BGP speaker is upgraded with software that supports the proposed revisions. In addition to the OPEN message, the BGP Identifier is currently also used in the following areas: o In the AGGREAGTOR attribute of a route where the combination of a BGP Identifier and an AS number uniquely identifies the BGP speaker that performs the route aggregation. o In the Route Reflection (in lieu of the Cluster-id) within an AS, where only the BGP Identifier of an internal neighbor may be propagated in the route reflection related attributes. o In the route selection, where the BGP Identifier is not used in comparing a route from an internal neighbor and a route from an external neighbor. In addition, routes from BGP speakers with identical BGP Identifiers have been dealt with (e.g., parallel BGP sessions between two BGP speakers). Therefore it is concluded that the revisions proposed in this document do not introduce any backward compatibility issue with the current usage of the BGP Identifier. 6. Security Considerations This extension to BGP does not change the underlying security issues. 7. Acknowledgments The authors would like to thank members of the IDR Working Group for discussions on the "IPv6-only Network" related issues that inspired this document. 8. References [BGP-4] Y. Rekhter, T. Li, and S. Hares "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-25.txt, Septemberdraft-ietf-idr-bgp4-26.txt, October 2004. [BGP-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS number space", Work in Progress, <draft-ietf-idr-as4bytes-08.txt>, March<draft-ietf-idr-as4bytes-09.txt>, December 2004. 9. Author Information Enke Chen Redback Networks,Cisco Systems, Inc. 300 Holger Way170 W. Tasman Dr. San Jose, CA 95134 e-mail: firstname.lastname@example.org@cisco.com Jenny Yuan Redback Networks,Cisco Systems, Inc. 300 Holger Way170 W. Tasman Dr. San Jose, CA 95134 e-mail: email@example.com@cisco.com 10. Full Copyright Notice Copyright (C) The Internet Society (2005). 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. 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.