idnits 2.17.1 draft-ietf-idr-bgp-identifier-04.txt: ** The Abstract section seems to be numbered 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 3667, Section 5.1 on line 15. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-25 -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-4BYTE-AS' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Enke Chen 3 Internet Draft Jenny Yuan 4 Expiration Date: March 2004 Redback Networks 6 AS-wide Unique BGP Identifier for BGP-4 8 draft-ietf-idr-bgp-identifier-04.txt 10 1. Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 To accommodate situations where the current requirements for the BGP 39 Identifier are not met, this document relaxes the definition of the 40 BGP Identifier to be a 4-octet unsigned, non-zero integer, and 41 relaxes the "uniqueness" requirement so that only AS-wide uniqueness 42 of the BGP Identifiers is required. These revisions to the base BGP 43 specification do not introduce any backward compatibility issue. 45 3. Introduction 47 Currently the BGP Identifier of a BGP speaker is specified as a valid 48 IPv4 host address assigned to the BGP speaker [BGP-4]. In addition, 49 the deployed BGP code requires that two BGP speakers be of distinct 50 BGP Identifiers in order to establish a BGP connection. 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 4. Protocol Revisions 61 The revisions to the base BGP specification [BGP-4] include the 62 definition of the BGP Identifier and procedures for a BGP speaker 63 that supports the AS-wide Unique BGP Identifier. 65 4.1. Definition of the BGP Identifier 67 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 68 the BGP Identifier is specified as the following: 70 The BGP Identifier is a 4-octet unsigned, non-zero integer that 71 should be unique within an AS. The value of the BGP Identifier for 72 a BGP speaker is determined on startup and is the same for every 73 local interface and every BGP peer. 75 4.2. Open Message Error Handling 77 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 78 the OPEN message error handling related to the BGP Identifier is 79 modified as follows: 81 If the BGP Identifier field of the OPEN message is zero, or if 82 it is the same as the BGP Identifier of the local BGP speaker 83 and the message is from an internal peer, then the Error Subcode 84 is set to "Bad BGP Identifier". 86 4.3. Connection Collision Resolution 88 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 89 the procedures for connection collision resolution are extended as 90 follows to deal with the case in which the two BGP speakers share the 91 same BGP Identifier (thus it is only applicable to an external peer): 93 If the BGP Identifiers of the peers involved in the connection 94 collision are identical, then the connection initiated by the BGP 95 speaker with the larger AS number is preserved. 97 This extension covers cases in which the four-octet AS numbers are 98 involved [BGP-4BYTE-AS]. 100 5. Remarks 102 It is noted that a BGP Identifier allocated based on [BGP-4] fits the 103 revised definition. 105 In case of BGP Confederation, the whole confederation is considered 106 as one AS for the purpose of supporting the AS-wide Unique BGP 107 Identifier. 109 A BGP speaker that supports the AS-wide Unique BGP Identifier can not 110 share a BGP Identifier with its external neighbor until the remote 111 BGP speaker is upgraded with software that supports the proposed 112 revisions. 114 In addition to the OPEN message, the BGP Identifier is currently also 115 used in the following areas: 117 o In the AGGREAGTOR attribute of a route where the combination of 118 a BGP Identifier and an AS number uniquely identifies the BGP 119 speaker that performs the route aggregation. 121 o In the Route Reflection (in lieu of the Cluster-id) within an 122 AS, where only the BGP Identifier of an internal neighbor may 123 be propagated in the route reflection related attributes. 125 o In the route selection, where the BGP Identifier is not used 126 in comparing a route from an internal neighbor and a route from 127 an external neighbor. In addition, routes from BGP speakers with 128 identical BGP Identifiers have been dealt with (e.g., parallel 129 BGP sessions between two BGP speakers). 131 Therefore it is concluded that the revisions proposed in this 132 document do not introduce any backward compatibility issue with the 133 current usage of the BGP Identifier. 135 6. Security Considerations 137 This extension to BGP does not change the underlying security issues. 139 7. Acknowledgments 141 The authors would like to thank members of the IDR Working Group for 142 discussions on the "IPv6-only Network" related issues that inspired 143 this document. 145 8. References 147 [BGP-4] Y. Rekhter, T. Li, and S. Hares "A Border Gateway Protocol 4 148 (BGP-4)", draft-ietf-idr-bgp4-25.txt, September 2004. 150 [BGP-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS 151 number space", Work in Progress, , 152 March 2004. 154 9. Author Information 156 Enke Chen 157 Redback Networks, Inc. 158 300 Holger Way 159 San Jose, CA 95134 160 e-mail: enke@redback.com 162 Jenny Yuan 163 Redback Networks, Inc. 164 300 Holger Way 165 San Jose, CA 95134 166 e-mail: jenny@redback.com