draft-ietf-idr-bgp-identifier-13.txt   draft-ietf-idr-bgp-identifier-14.txt 
Network Working Group E. Chen Network Working Group E. Chen
Internet Draft J. Yuan Internet Draft J. Yuan
Intended Status: Standards Track Cisco Systems Intended Status: Standards Track Cisco Systems
Expiration Date: July 19, 2011 January 18, 2011 Updates: RFC 4271 May 4, 2011
Expiration Date: November 5, 2011
AS-wide Unique BGP Identifier for BGP-4 AS-wide Unique BGP Identifier for BGP-4
draft-ietf-idr-bgp-identifier-13.txt draft-ietf-idr-bgp-identifier-14.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 33 skipping to change at page 1, line 34
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/1id-abstracts.html 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 July 19, 2011. This Internet-Draft will expire on November 5, 2011.
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
skipping to change at page 2, line 22 skipping to change at page 2, line 23
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 [RFC4271]. In 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, this document relaxes the definition of the Identifier are not met (such as in the case of an IPv6-only network),
BGP Identifier to be a 4-octet unsigned, non-zero integer, and this document relaxes the definition of the BGP Identifier to be a
relaxes the "uniqueness" requirement so that only AS-wide uniqueness 4-octet unsigned, non-zero integer, and relaxes the "uniqueness"
of the BGP Identifiers is required. These revisions to the base BGP requirement so that only AS-wide uniqueness of the BGP Identifiers is
specification do not introduce any backward compatibility issue. required. These revisions to the base BGP specification do not
introduce any backward compatibility issue.
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,
skipping to change at page 3, line 41 skipping to change at page 3, line 41
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 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 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 BGP Identifier and an AS number uniquely identifies the BGP a BGP Identifier and an AS number uniquely identifies the BGP
speaker that performs the route aggregation. speaker that performs the route aggregation.
o In the Route Reflection (in lieu of the Cluster-id) within an o In the Route Reflection within an AS, where only the BGP
AS, where only the BGP Identifier of an internal neighbor may Identifier of an internal neighbor may be propagated in the
be propagated in the route reflection related attributes. route reflection 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 comparing a route from an internal neighbor and a route from in comparing a route from an internal neighbor and a route from
an external neighbor. In addition, routes from BGP speakers with an 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 sessions between two BGP speakers). BGP sessions between two BGP speakers).
Therefore it is concluded that the revisions proposed 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 issue 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 change the underlying security issues. This extension to BGP does not introduce new security considerations.
BGP security considerations are discussed in [RFC4271].
5. IANA Considerations 5. IANA Considerations
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.
 End of changes. 8 change blocks. 
14 lines changed or deleted 17 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/