idnits 2.17.1 draft-ietf-idr-bgp-identifier-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 192. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 (ref. 'BGP-4BYTE-AS') (Obsoleted by RFC 6793) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group E. Chen 3 Internet Draft J. Yuan 4 Expiration Date: November 2008 Cisco Systems 6 AS-wide Unique BGP Identifier for BGP-4 8 draft-ietf-idr-bgp-identifier-09.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 To accommodate situations where the current requirements for the BGP 36 Identifier are not met, this document relaxes the definition of the 37 BGP Identifier to be a 4-octet unsigned, non-zero integer, and 38 relaxes the "uniqueness" requirement so that only AS-wide uniqueness 39 of the BGP Identifiers is required. These revisions to the base BGP 40 specification do not introduce any backward compatibility issue. 42 1. Introduction 44 Currently the BGP Identifier of a BGP speaker is specified as a valid 45 IPv4 host address assigned to the BGP speaker [BGP-4]. In addition, 46 the deployed BGP code requires that two BGP speakers be of distinct 47 BGP Identifiers in order to establish a BGP connection. 49 To accommodate situations where the current requirements for the BGP 50 Identifier are not met, this document relaxes the definition of the 51 BGP Identifier to be a 4-octet unsigned, non-zero integer, and 52 relaxes the "uniqueness" requirement so that only AS-wide uniqueness 53 of the BGP Identifiers is required. These revisions to the base BGP 54 specification do not introduce any backward compatibility issue. 56 2. Protocol Revisions 58 The revisions to the base BGP specification [BGP-4] include the 59 definition of the BGP Identifier and procedures for a BGP speaker 60 that supports the AS-wide Unique BGP Identifier. 62 2.1. Definition of the BGP Identifier 64 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 65 the BGP Identifier is specified as the following: 67 The BGP Identifier is a 4-octet unsigned, non-zero integer that 68 should be unique within an AS. The value of the BGP Identifier for 69 a BGP speaker is determined on startup and is the same for every 70 local interface and every BGP peer. 72 2.2. Open Message Error Handling 74 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 75 the OPEN message error handling related to the BGP Identifier is 76 modified as follows: 78 If the BGP Identifier field of the OPEN message is zero, or if 79 it is the same as the BGP Identifier of the local BGP speaker 80 and the message is from an internal peer, then the Error Subcode 81 is set to "Bad BGP Identifier". 83 2.3. Connection Collision Resolution 85 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 86 the procedures for connection collision resolution are extended as 87 follows to deal with the case in which the two BGP speakers share the 88 same BGP Identifier (thus it is only applicable to an external peer): 90 If the BGP Identifiers of the peers involved in the connection 91 collision are identical, then the connection initiated by the BGP 92 speaker with the larger AS number is preserved. 94 This extension covers cases in which the four-octet AS numbers are 95 involved [BGP-4BYTE-AS]. 97 3. Remarks 99 It is noted that a BGP Identifier allocated based on [BGP-4] fits the 100 revised definition. 102 In case of BGP Confederation, the whole confederation is considered 103 as one AS for the purpose of supporting the AS-wide Unique BGP 104 Identifier. 106 A BGP speaker that supports the AS-wide Unique BGP Identifier can not 107 share a BGP Identifier with its external neighbor until the remote 108 BGP speaker is upgraded with software that supports the proposed 109 revisions. 111 In addition to the OPEN message, the BGP Identifier is currently also 112 used in the following areas: 114 o In the AGGREAGTOR attribute of a route where the combination of 115 a BGP Identifier and an AS number uniquely identifies the BGP 116 speaker that performs the route aggregation. 118 o In the Route Reflection (in lieu of the Cluster-id) within an 119 AS, where only the BGP Identifier of an internal neighbor may 120 be propagated in the route reflection related attributes. 122 o In the route selection, where the BGP Identifier is not used 123 in comparing a route from an internal neighbor and a route from 124 an external neighbor. In addition, routes from BGP speakers with 125 identical BGP Identifiers have been dealt with (e.g., parallel 126 BGP sessions between two BGP speakers). 128 Therefore it is concluded that the revisions proposed in this 129 document do not introduce any backward compatibility issue with the 130 current usage of the BGP Identifier. 132 4. Security Considerations 134 This extension to BGP does not change the underlying security issues. 136 5. IANA Considerations 138 This document has no actions for IANA. 140 6. Acknowledgments 142 The authors would like to thank members of the IDR Working Group for 143 discussions on the "IPv6-only Network" related issues that inspired 144 this document. 146 7. Normative References 148 [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 149 4 (BGP-4)", RFC 4271, January 2006. 151 [BGP-4BYTE-AS] Vohra, Q., and E. Chen, "BGP Support for Four-octet AS 152 Number Space", RFC 4893, May 2007. 154 8. Author Information 156 Enke Chen 157 Cisco Systems, Inc. 158 170 W. Tasman Dr. 159 San Jose, CA 95134 161 EMail: enkechen@cisco.com 163 Jenny Yuan 164 Cisco Systems, Inc. 165 170 W. Tasman Dr. 166 San Jose, CA 95134 168 EMail: jenny@cisco.com 170 9. Intellectual Property 172 The IETF takes no position regarding the validity or scope of any 173 Intellectual Property Rights or other rights that might be claimed to 174 pertain to the implementation or use of the technology described in 175 this document or the extent to which any license under such rights 176 might or might not be available; nor does it represent that it has 177 made any independent effort to identify any such rights. Information 178 on the procedures with respect to rights in RFC documents can be 179 found in BCP 78 and BCP 79. 181 Copies of IPR disclosures made to the IETF Secretariat and any 182 assurances of licenses to be made available, or the result of an 183 attempt made to obtain a general license or permission for the use of 184 such proprietary rights by implementers or users of this 185 specification can be obtained from the IETF on-line IPR repository at 186 http://www.ietf.org/ipr. 188 The IETF invites any interested party to bring to its attention any 189 copyrights, patents or patent applications, or other proprietary 190 rights that may cover technology that may be required to implement 191 this standard. Please address the information to the IETF at ietf- 192 ipr@ietf.org. 194 10. Full Copyright Notice 196 Copyright (C) The IETF Trust (2008). 198 This document is subject to the rights, licenses and restrictions 199 contained in BCP 78, and except as set forth therein, the authors 200 retain all their rights. 202 This document and the information contained herein are provided on an 203 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 204 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 205 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 206 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 207 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 208 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.