idnits 2.17.1 draft-ietf-idr-bgp-identifier-14.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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC4271, but the abstract doesn't seem to mention this, which it should. 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 (May 4, 2011) is 4741 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 (~~), 4 warnings (==), 3 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 Updates: RFC 4271 May 4, 2011 6 Expiration Date: November 5, 2011 8 AS-wide Unique BGP Identifier for BGP-4 10 draft-ietf-idr-bgp-identifier-14.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on November 5, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Abstract 52 To accommodate situations where the current requirements for the BGP 53 Identifier are not met, this document relaxes the definition of the 54 BGP Identifier to be a 4-octet unsigned, non-zero integer, and 55 relaxes the "uniqueness" requirement so that only AS-wide uniqueness 56 of the BGP Identifiers is required. These revisions to the base BGP 57 specification do not introduce any backward compatibility issue. 59 1. Introduction 61 Currently the BGP Identifier of a BGP speaker is specified as a valid 62 IPv4 host address assigned to the BGP speaker [RFC4271]. In 63 addition, the deployed BGP code requires that two BGP speakers be of 64 distinct BGP Identifiers in order to establish a BGP connection. 66 To accommodate situations where the current requirements for the BGP 67 Identifier are not met (such as in the case of an IPv6-only network), 68 this document relaxes the definition of the BGP Identifier to be a 69 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" 70 requirement so that only AS-wide uniqueness of the BGP Identifiers is 71 required. These revisions to the base BGP specification do not 72 introduce any backward compatibility issue. 74 2. Protocol Revisions 76 The revisions to the base BGP specification [RFC4271] include the 77 definition of the BGP Identifier and procedures for a BGP speaker 78 that supports the AS-wide Unique BGP Identifier. 80 2.1. Definition of the BGP Identifier 82 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 83 the BGP Identifier is specified as the following: 85 The BGP Identifier is a 4-octet unsigned, non-zero integer that 86 should be unique within an AS. The value of the BGP Identifier for 87 a BGP speaker is determined on startup and is the same for every 88 local interface and every BGP peer. 90 2.2. Open Message Error Handling 92 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 93 the OPEN message error handling related to the BGP Identifier is 94 modified as follows: 96 If the BGP Identifier field of the OPEN message is zero, or if 97 it is the same as the BGP Identifier of the local BGP speaker 98 and the message is from an internal peer, then the Error Subcode 99 is set to "Bad BGP Identifier". 101 2.3. Connection Collision Resolution 103 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 104 the procedures for connection collision resolution are extended as 105 follows to deal with the case in which the two BGP speakers share the 106 same BGP Identifier (thus it is only applicable to an external peer): 108 If the BGP Identifiers of the peers involved in the connection 109 collision are identical, then the connection initiated by the BGP 110 speaker with the larger AS number is preserved. 112 This extension covers cases in which the four-octet AS numbers are 113 involved [RFC4893]. 115 3. Remarks 117 It is noted that a BGP Identifier allocated based on [RFC4271] fits 118 the revised definition. 120 In case of BGP Confederation, the whole confederation is considered 121 as one AS for the purpose of supporting the AS-wide Unique BGP 122 Identifier. 124 A BGP speaker that supports the AS-wide Unique BGP Identifier can not 125 share a BGP Identifier with its external neighbor until the remote 126 BGP speaker is upgraded with software that supports the specified 127 revisions. 129 In addition to the OPEN message, the BGP Identifier is currently also 130 used in the following areas: 132 o In the AGGREAGTOR attribute of a route where the combination of 133 a BGP Identifier and an AS number uniquely identifies the BGP 134 speaker that performs the route aggregation. 136 o In the Route Reflection within an AS, where only the BGP 137 Identifier of an internal neighbor may be propagated in the 138 route reflection related attributes. 140 o In the route selection, where the BGP Identifier is not used 141 in comparing a route from an internal neighbor and a route from 142 an external neighbor. In addition, routes from BGP speakers with 143 identical BGP Identifiers have been dealt with (e.g., parallel 144 BGP sessions between two BGP speakers). 146 Therefore it is concluded that the revisions specified in this 147 document do not introduce any backward compatibility issue with the 148 current usage of the BGP Identifier. 150 4. Security Considerations 152 This extension to BGP does not introduce new security considerations. 153 BGP security considerations are discussed in [RFC4271]. 155 5. IANA Considerations 157 This document has no actions for IANA. 159 6. Acknowledgments 161 The authors would like to thank members of the IDR Working Group for 162 discussions on the "IPv6-only Network" related issues that inspired 163 this document. 165 7. Normative References 167 [RFC4271] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway 168 Protocol 4 (BGP-4)", RFC 4271, January 2006. 170 [RFC4893] Vohra, Q., and E. Chen, "BGP Support for Four-octet AS 171 Number Space", RFC 4893, May 2007. 173 8. Authors' Addresses 175 Enke Chen 176 Cisco Systems, Inc. 177 170 W. Tasman Dr. 178 San Jose, CA 95134 180 EMail: enkechen@cisco.com 182 Jenny Yuan 183 Cisco Systems, Inc. 184 170 W. Tasman Dr. 185 San Jose, CA 95134 187 EMail: jenny@cisco.com