idnits 2.17.1 draft-ietf-idr-bgp-identifier-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 4, 2010) is 5192 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Chen 3 Internet Draft J. Yuan 4 Intended Status: Standards Track Cisco Systems 5 Expiration Date: August 2010 February 4, 2010 7 AS-wide Unique BGP Identifier for BGP-4 9 draft-ietf-idr-bgp-identifier-11.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on August 5, 2010. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 To accommodate situations where the current requirements for the BGP 52 Identifier are not met, this document relaxes the definition of the 53 BGP Identifier to be a 4-octet unsigned, non-zero integer, and 54 relaxes the "uniqueness" requirement so that only AS-wide uniqueness 55 of the BGP Identifiers is required. These revisions to the base BGP 56 specification do not introduce any backward compatibility issue. 58 1. Introduction 60 Currently the BGP Identifier of a BGP speaker is specified as a valid 61 IPv4 host address assigned to the BGP speaker [RFC4271]. In 62 addition, the deployed BGP code requires that two BGP speakers be of 63 distinct BGP Identifiers in order to establish a BGP connection. 65 To accommodate situations where the current requirements for the BGP 66 Identifier are not met, this document relaxes the definition of the 67 BGP Identifier to be a 4-octet unsigned, non-zero integer, and 68 relaxes the "uniqueness" requirement so that only AS-wide uniqueness 69 of the BGP Identifiers is required. These revisions to the base BGP 70 specification do not introduce any backward compatibility issue. 72 2. Protocol Revisions 74 The revisions to the base BGP specification [RFC4271] include the 75 definition of the BGP Identifier and procedures for a BGP speaker 76 that supports the AS-wide Unique BGP Identifier. 78 2.1. Definition of the BGP Identifier 80 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 81 the BGP Identifier is specified as the following: 83 The BGP Identifier is a 4-octet unsigned, non-zero integer that 84 should be unique within an AS. The value of the BGP Identifier for 85 a BGP speaker is determined on startup and is the same for every 86 local interface and every BGP peer. 88 2.2. Open Message Error Handling 90 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 91 the OPEN message error handling related to the BGP Identifier is 92 modified as follows: 94 If the BGP Identifier field of the OPEN message is zero, or if 95 it is the same as the BGP Identifier of the local BGP speaker 96 and the message is from an internal peer, then the Error Subcode 97 is set to "Bad BGP Identifier". 99 2.3. Connection Collision Resolution 101 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 102 the procedures for connection collision resolution are extended as 103 follows to deal with the case in which the two BGP speakers share the 104 same BGP Identifier (thus it is only applicable to an external peer): 106 If the BGP Identifiers of the peers involved in the connection 107 collision are identical, then the connection initiated by the BGP 108 speaker with the larger AS number is preserved. 110 This extension covers cases in which the four-octet AS numbers are 111 involved [RFC4893]. 113 3. Remarks 115 It is noted that a BGP Identifier allocated based on [RFC4271] fits 116 the revised definition. 118 In case of BGP Confederation, the whole confederation is considered 119 as one AS for the purpose of supporting the AS-wide Unique BGP 120 Identifier. 122 A BGP speaker that supports the AS-wide Unique BGP Identifier can not 123 share a BGP Identifier with its external neighbor until the remote 124 BGP speaker is upgraded with software that supports the proposed 125 revisions. 127 In addition to the OPEN message, the BGP Identifier is currently also 128 used in the following areas: 130 o In the AGGREAGTOR attribute of a route where the combination of 131 a BGP Identifier and an AS number uniquely identifies the BGP 132 speaker that performs the route aggregation. 134 o In the Route Reflection (in lieu of the Cluster-id) within an 135 AS, where only the BGP Identifier of an internal neighbor may 136 be propagated in the route reflection related attributes. 138 o In the route selection, where the BGP Identifier is not used 139 in comparing a route from an internal neighbor and a route from 140 an external neighbor. In addition, routes from BGP speakers with 141 identical BGP Identifiers have been dealt with (e.g., parallel 142 BGP sessions between two BGP speakers). 144 Therefore it is concluded that the revisions proposed in this 145 document do not introduce any backward compatibility issue with the 146 current usage of the BGP Identifier. 148 4. Security Considerations 150 This extension to BGP does not change the underlying security issues. 152 5. IANA Considerations 154 This document has no actions for IANA. 156 6. Acknowledgments 158 The authors would like to thank members of the IDR Working Group for 159 discussions on the "IPv6-only Network" related issues that inspired 160 this document. 162 7. Normative References 164 [RFC4271] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway 165 Protocol 4 (BGP-4)", RFC 4271, January 2006. 167 [RFC4893] Vohra, Q., and E. Chen, "BGP Support for Four-octet AS 168 Number Space", RFC 4893, May 2007. 170 8. Authors' Addresses 172 Enke Chen 173 Cisco Systems, Inc. 174 170 W. Tasman Dr. 175 San Jose, CA 95134 177 EMail: enkechen@cisco.com 179 Jenny Yuan 180 Cisco Systems, Inc. 181 170 W. Tasman Dr. 182 San Jose, CA 95134 184 EMail: jenny@cisco.com