draft-ietf-idr-bgp-identifier-14.txt		rfc6286.txt
	Network Working Group E. Chen		Internet Engineering Task Force (IETF) E. Chen
	Internet Draft J. Yuan		Request for Comments: 6286 J. Yuan
	Intended Status: Standards Track Cisco Systems		Updates: 4271 Cisco Systems
	Updates: RFC 4271 May 4, 2011		Category: Standards Track June 2011
	Expiration Date: November 5, 2011		ISSN: 2070-1721
	AS-wide Unique BGP Identifier for BGP-4
	draft-ietf-idr-bgp-identifier-14.txt
	Status of this Memo		Autonomous-System-Wide Unique BGP Identifier for BGP-4
	This Internet-Draft is submitted to IETF in full conformance with the		Abstract
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		To accommodate situations where the current requirements for the BGP
	Task Force (IETF), its areas, and its working groups. Note that		Identifier are not met, this document relaxes the definition of the
	other groups may also distribute working documents as Internet-		BGP Identifier to be a 4-octet, unsigned, non-zero integer and
	Drafts.		relaxes the "uniqueness" requirement so that only Autonomous-System-
			wide (AS-wide) uniqueness of the BGP Identifiers is required. These
			revisions to the base BGP specification do not introduce any backward
			compatibility issues. This document updates RFC 4271.
	Internet-Drafts are draft documents valid for a maximum of six months		Status of This Memo
	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		This is an Internet Standards Track document.
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		This document is a product of the Internet Engineering Task Force
	http://www.ietf.org/shadow.html		(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by the
			Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on November 5, 2011.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc6286.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Abstract		1. Introduction
	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.
	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
	IPv4 host address assigned to the BGP speaker [RFC4271]. In		valid IPv4 host address assigned to the BGP speaker [RFC4271]. In
	addition, the deployed BGP code requires that two BGP speakers be of		addition, the deployed BGP code requires that two BGP speakers be of
	distinct 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 (such as in the case of an IPv6-only network),		Identifier are not met (such as in the case of an IPv6-only network),
	this document relaxes the definition of the BGP Identifier to be a		this document relaxes the definition of the BGP Identifier to be a
	4-octet unsigned, non-zero integer, and relaxes the "uniqueness"		4-octet, unsigned, non-zero integer and relaxes the "uniqueness"
	requirement so that only AS-wide uniqueness of the BGP Identifiers is		requirement so that only AS-wide uniqueness of the BGP Identifiers is
	required. These revisions to the base BGP specification do not		required. These revisions to the base BGP specification do not
	introduce any backward compatibility issue.		introduce any backward compatibility issues.
	2. Protocol Revisions		2. Protocol Revisions
	The revisions to the base BGP specification [RFC4271] 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
	a BGP speaker is determined on startup and is the same for every		for a BGP speaker is determined on startup and is the same for
	local interface and every BGP peer.		every local interface and every BGP peer.
	2.2. Open Message Error Handling		2.2. Open Message Error Handling
	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 OPEN message error handling related to the BGP Identifier is		the OPEN message error handling related to the BGP Identifier is
	modified as follows:		modified as follows:
	If the BGP Identifier field of the OPEN message is zero, or if		If the BGP Identifier field of the OPEN message is zero, or if it
	it is the same as the BGP Identifier of the local BGP speaker		is the same as the BGP Identifier of the local BGP speaker and the
	and the message is from an internal peer, then the Error Subcode		message is from an internal peer, then the Error Subcode is set to
	is set to "Bad BGP Identifier".		"Bad BGP Identifier".
	2.3. Connection Collision Resolution		2.3. Connection Collision Resolution
	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 4-octet AS numbers are
	involved [RFC4893].		involved [RFC4893].
	3. Remarks		3. Remarks
	It is noted that a BGP Identifier allocated based on [RFC4271] fits		It is noted that a BGP Identifier allocated based on [RFC4271] fits
	the 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 cannot
	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 specified		BGP speaker is upgraded with software that supports the specified
	revisions.		revisions.
	In addition to the OPEN message, the BGP Identifier is currently also		In addition to the OPEN message, the BGP Identifier is currently also
	used in the following areas:		used in the following areas:
	o In the AGGREAGTOR attribute of a route where the combination of		o In the AGGREAGTOR attribute of a route where the combination of a
	a BGP Identifier and an AS number uniquely identifies the BGP		BGP Identifier and an AS number uniquely identifies the BGP speaker
	speaker that performs the route aggregation.		that performs the route aggregation.
	o In the Route Reflection within an AS, where only the BGP		o In the Route Reflection within an AS, where only the BGP Identifier
	Identifier of an internal neighbor may be propagated in the		of an internal neighbor may be propagated in the route reflection
	route reflection related attributes.		related attributes.
	o In the route selection, where the BGP Identifier is not used		o In the route selection, where the BGP Identifier is not used in
	in comparing a route from an internal neighbor and a route from		comparing a route from an internal neighbor and a route from an
	an external neighbor. In addition, routes from BGP speakers with		external neighbor. In addition, routes from BGP speakers with
	identical BGP Identifiers have been dealt with (e.g., parallel		identical BGP Identifiers have been dealt with (e.g., parallel BGP
	BGP sessions between two BGP speakers).		sessions between two BGP speakers).
	Therefore it is concluded that the revisions specified in this		Therefore, it is concluded that the revisions specified in this
	document do not introduce any backward compatibility issue with the		document do not introduce any backward compatibility issues with the
	current usage of the BGP Identifier.		current usage of the BGP Identifier.
	4. Security Considerations		4. Security Considerations
	This extension to BGP does not introduce new security considerations.		This extension to BGP does not introduce new security considerations.
	BGP security considerations are discussed in [RFC4271].		BGP security considerations are discussed in [RFC4271].
	5. IANA Considerations		5. Acknowledgments
	This document has no actions for IANA.
	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		6. Normative References
	[RFC4271] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4893] 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. Authors' Addresses		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.
End of changes. 36 change blocks.
	87 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/