draft-ietf-idr-bgp-identifier-09.txt   draft-ietf-idr-bgp-identifier-10.txt 
IDR Working Group E. Chen Network Working Group E. Chen
Internet Draft J. Yuan Internet Draft J. Yuan
Expiration Date: November 2008 Cisco Systems Intended Status: Standards Track Cisco Systems
Expiration Date: February 2010 August 3, 2009
AS-wide Unique BGP Identifier for BGP-4 AS-wide Unique BGP Identifier for BGP-4
draft-ietf-idr-bgp-identifier-09.txt draft-ietf-idr-bgp-identifier-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 4, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
To accommodate situations where the current requirements for the BGP To accommodate situations where the current requirements for the BGP
Identifier are not met, this document relaxes the definition of the Identifier are not met, this document relaxes the definition of the
BGP Identifier to be a 4-octet unsigned, non-zero integer, and BGP Identifier to be a 4-octet unsigned, non-zero integer, and
relaxes the "uniqueness" requirement so that only AS-wide uniqueness relaxes the "uniqueness" requirement so that only AS-wide uniqueness
of the BGP Identifiers is required. These revisions to the base BGP of the BGP Identifiers is required. These revisions to the base BGP
specification do not introduce any backward compatibility issue. specification do not introduce any backward compatibility issue.
1. Introduction 1. Introduction
Currently the BGP Identifier of a BGP speaker is specified as a valid 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, IPv4 host address assigned to the BGP speaker [RFC4271]. In
the deployed BGP code requires that two BGP speakers be of distinct addition, the deployed BGP code requires that two BGP speakers be of
BGP Identifiers in order to establish a BGP connection. distinct BGP Identifiers in order to establish a BGP connection.
To accommodate situations where the current requirements for the BGP To accommodate situations where the current requirements for the BGP
Identifier are not met, this document relaxes the definition of the Identifier are not met, this document relaxes the definition of the
BGP Identifier to be a 4-octet unsigned, non-zero integer, and BGP Identifier to be a 4-octet unsigned, non-zero integer, and
relaxes the "uniqueness" requirement so that only AS-wide uniqueness relaxes the "uniqueness" requirement so that only AS-wide uniqueness
of the BGP Identifiers is required. These revisions to the base BGP of the BGP Identifiers is required. These revisions to the base BGP
specification do not introduce any backward compatibility issue. specification do not introduce any backward compatibility issue.
2. Protocol Revisions 2. Protocol Revisions
The revisions to the base BGP specification [BGP-4] include the The revisions to the base BGP specification [RFC4271] include the
definition of the BGP Identifier and procedures for a BGP speaker definition of the BGP Identifier and procedures for a BGP speaker
that supports the AS-wide Unique BGP Identifier. that supports the AS-wide Unique BGP Identifier.
2.1. Definition of the BGP Identifier 2.1. Definition of the BGP Identifier
For a BGP speaker that supports the AS-wide Unique 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 specified as the following:
The BGP Identifier is a 4-octet unsigned, non-zero integer that 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 should be unique within an AS. The value of the BGP Identifier for
skipping to change at page 3, line 17 skipping to change at page 3, line 19
For a BGP speaker that supports the AS-wide Unique BGP Identifier, For a BGP speaker that supports the AS-wide Unique BGP Identifier,
the procedures for connection collision resolution are extended as the procedures for connection collision resolution are extended as
follows to deal with the case in which the two BGP speakers share the 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): same BGP Identifier (thus it is only applicable to an external peer):
If the BGP Identifiers of the peers involved in the connection If the BGP Identifiers of the peers involved in the connection
collision are identical, then the connection initiated by the BGP collision are identical, then the connection initiated by the BGP
speaker with the larger AS number is preserved. speaker with the larger AS number is preserved.
This extension covers cases in which the four-octet AS numbers are This extension covers cases in which the four-octet AS numbers are
involved [BGP-4BYTE-AS]. involved [RFC4893].
3. Remarks 3. Remarks
It is noted that a BGP Identifier allocated based on [BGP-4] fits the It is noted that a BGP Identifier allocated based on [RFC4271] fits
revised definition. the revised definition.
In case of BGP Confederation, the whole confederation is considered In case of BGP Confederation, the whole confederation is considered
as one AS for the purpose of supporting the AS-wide Unique BGP as one AS for the purpose of supporting the AS-wide Unique BGP
Identifier. Identifier.
A BGP speaker that supports the AS-wide Unique BGP Identifier can not A BGP speaker that supports the AS-wide Unique BGP Identifier can not
share a BGP Identifier with its external neighbor until the remote share a BGP Identifier with its external neighbor until the remote
BGP speaker is upgraded with software that supports the proposed BGP speaker is upgraded with software that supports the proposed
revisions. revisions.
skipping to change at page 4, line 22 skipping to change at page 4, line 26
This document has no actions for IANA. This document has no actions for IANA.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank members of the IDR Working Group for The authors would like to thank members of the IDR Working Group for
discussions on the "IPv6-only Network" related issues that inspired discussions on the "IPv6-only Network" related issues that inspired
this document. this document.
7. Normative References 7. Normative References
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol [RFC4271] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway
4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP-4BYTE-AS] Vohra, Q., and E. Chen, "BGP Support for Four-octet AS [RFC4893] Vohra, Q., and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007. Number Space", RFC 4893, May 2007.
8. Author Information 8. Authors' Addresses
Enke Chen Enke Chen
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
EMail: enkechen@cisco.com EMail: enkechen@cisco.com
Jenny Yuan Jenny Yuan
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 4, line 41 skipping to change at page 5, line 4
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
EMail: enkechen@cisco.com EMail: enkechen@cisco.com
Jenny Yuan Jenny Yuan
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
EMail: jenny@cisco.com EMail: jenny@cisco.com
9. 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.
10. 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.
 End of changes. 15 change blocks. 
21 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/