IDR Working Group                                               E. Chen
Internet Draft                                                  J. Yuan
Expiration Date: November 2008                            Cisco Systems


                AS-wide Unique BGP Identifier for BGP-4

                  draft-ietf-idr-bgp-identifier-09.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.

   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.

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.










Chen & Yuan                                                     [Page 1]

 
Internet Draft    draft-ietf-idr-bgp-identifier-09.txt          May 2008


. 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.


. 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.


2.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.


2.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".








Chen & Yuan                                                     [Page 2]

 
Internet Draft    draft-ietf-idr-bgp-identifier-09.txt          May 2008


2.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].


. 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



Chen & Yuan                                                     [Page 3]

 
Internet Draft    draft-ietf-idr-bgp-identifier-09.txt          May 2008


   current usage of the BGP Identifier.


. Security Considerations

   This extension to BGP does not change the underlying security issues.


. IANA Considerations

   This document has no actions for IANA.


. 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.


. Normative References

   [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol
   4 (BGP-4)", RFC 4271, January 2006.

   [BGP-4BYTE-AS] Vohra, Q., and E. Chen, "BGP Support for Four-octet AS
   Number Space", RFC 4893, May 2007.


. Author Information

   Enke Chen
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134

   EMail: enkechen@cisco.com


   Jenny Yuan
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95134

   EMail: jenny@cisco.com






Chen & Yuan                                                     [Page 4]

 
Internet Draft    draft-ietf-idr-bgp-identifier-09.txt          May 2008


. Intellectual Property

   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.


. Full Copyright Notice

   Copyright (C) The IETF Trust (2008).

   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, THE IETF TRUST 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.











Chen & Yuan                                                     [Page 5]