Network Working Group E. Chen
Internet Draft J. Yuan
Intended Status: Standards Track Cisco Systems
Expiration Date: February 2010 August 3, 2009
AS-wide Unique BGP Identifier for BGP-4
draft-ietf-idr-bgp-identifier-10.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
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
To accommodate situations where the current requirements for the BGP
Chen & Yuan [Page 1]
Internet Draft draft-ietf-idr-bgp-identifier-10.txt August 2009
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
IPv4 host address assigned to the BGP speaker [RFC4271]. 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.
2. Protocol Revisions
The revisions to the base BGP specification [RFC4271] 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
Chen & Yuan [Page 2]
Internet Draft draft-ietf-idr-bgp-identifier-10.txt August 2009
and the message is from an internal peer, then the Error Subcode
is set to "Bad BGP Identifier".
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 [RFC4893].
3. Remarks
It is noted that a BGP Identifier allocated based on [RFC4271] 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
Chen & Yuan [Page 3]
Internet Draft draft-ietf-idr-bgp-identifier-10.txt August 2009
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.
4. Security Considerations
This extension to BGP does not change the underlying security issues.
5. IANA Considerations
This document has no actions for IANA.
6. 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.
7. Normative References
[RFC4271] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4893] Vohra, Q., and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007.
8. Authors' Addresses
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
Chen & Yuan [Page 4]
Internet Draft draft-ietf-idr-bgp-identifier-10.txt August 2009
EMail: jenny@cisco.com
Chen & Yuan [Page 5]