idnits 2.17.1 draft-ietf-idr-bgp-identifier-01.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 3 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 4 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-17 -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-4BYTE-AS' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 2003 Redback Networks 6 AS-wide Unique BGP Identifier for BGP-4 8 draft-ietf-idr-bgp-identifier-01.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 To accommodate situations where the current requirements for the BGP 34 Identifier are not met, this document relaxes the definition of the 35 BGP Identifier to be a 4-octet unsigned, non-zero integer, and 36 relaxes the "uniqueness" requirement so that only AS-wide uniqueness 37 of the BGP Identifiers is required. These revisions to the base BGP 38 specification do not introduce any backward compatibility issue. 40 3. Introduction 42 Currently the BGP Identifier of a BGP speaker is specified as a valid 43 IPv4 host address assigned to the BGP speaker [BGP-4]. In addition, 44 the deployed BGP code requires that two BGP speakers be of distinct 45 BGP Identifiers in order to establish a BGP connection. 47 To accommodate situations where the current requirements for the BGP 48 Identifier are not met, this document relaxes the definition of the 49 BGP Identifier to be a 4-octet unsigned, non-zero integer, and 50 relaxes the "uniqueness" requirement so that only AS-wide uniqueness 51 of the BGP Identifiers is required. These revisions to the base BGP 52 specification do not introduce any backward compatibility issue. 54 4. Protocol Revisions 56 The revisions to the base BGP specification [BGP-4] include the 57 definition of the BGP Identifier and procedures for a BGP speaker 58 that supports the AS-wide Unique BGP Identifier. 60 4.1. Definition of the BGP Identifier 62 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 63 the BGP Identifier is specified as the following: 65 The BGP Identifier is a 4-octet unsigned, non-zero integer that 66 should be unique within an AS. The value of the BGP Identifier for 67 a BGP speaker is determined on startup and is the same for every 68 local interface and every BGP peer. 70 4.2. Open Message Error Handling 72 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 73 the OPEN message error handling related to the BGP Identifier is 74 modified as follows: 76 If the BGP Identifier field of the OPEN message is zero, or if 77 it is the same as the BGP Identifier of the local BGP speaker 78 and the message is from an internal peer, then the Error Subcode 79 is set to "Bad BGP Identifier". 81 4.3. Connection Collision Resolution 83 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 84 the procedures for connection collision resolution are extended as 85 follows to deal with the case in which the two BGP speakers share the 86 same BGP Identifier (thus it is only applicable to an external peer): 88 If the BGP Identifiers of the peers involved in the connection 89 collision are identical, then the connection initiated by the BGP 90 speaker with the larger AS number is preserved. 92 This extension covers cases in which the four-octet AS numbers are 93 involved [BGP-4BYTE-AS]. 95 5. Remarks 97 It is noted that a BGP Identifier allocated based on [BGP-4] fits the 98 revised definition. 100 In case of BGP Confederation, the whole confederation is considered 101 as one AS for the purpose of supporting the AS-wide Unique BGP 102 Identifier. 104 A BGP speaker that supports the AS-wide Unique BGP Identifier can not 105 share a BGP Identifier with its external neighbor until the remote 106 BGP speaker is upgraded with software that supports the proposed 107 revisions. 109 In addition to the OPEN message, the BGP Identifier is currently also 110 used in the following areas: 112 o In the AGGREAGTOR attribute of a route where the combination of 113 a BGP Identifier and an AS number uniquely identifies the BGP 114 speaker that performs the route aggregation. 116 o In the Route Reflection (in lieu of the Cluster-id) within an 117 AS, where only the BGP Identifier of an internal neighbor may 118 be propagated in the route reflection related attributes. 120 o In the route selection, where the BGP Identifier is not used 121 in comparing a route from an internal neighbor and a route from 122 an external neighbor. In addition, routes from BGP speakers with 123 identical BGP Identifiers have been dealt with (e.g., parallel 124 BGP sessions between two BGP speakers). 126 Therefore it is concluded that the revisions proposed in this 127 document do not introduce any backward compatibility issue with the 128 current usage of the BGP Identifier. 130 6. Security Considerations 132 This extension to BGP does not change the underlying security issues. 134 7. Acknowledgments 136 The authors would like to thank members of the IDR Working Group for 137 discussions on the "IPv6-only Network" related issues that inspired 138 this document. 140 8. References 142 [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 143 draft-ietf-idr-bgp4-17.txt, January 2002. 145 [BGP-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS 146 number space", Work in Progress, , 147 May 2002. 149 9. Author Information 151 Enke Chen 152 Redback Networks, Inc. 153 350 Holger Way 154 San Jose, CA 95134 155 e-mail: enke@redback.com 157 Jenny Yuan 158 Redback Networks, Inc. 159 350 Holger Way 160 San Jose, CA 95134 161 e-mail: jenny@redback.com