idnits 2.17.1 draft-ietf-idr-bgp-identifier-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (August 3, 2009) is 5373 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: 2 errors (**), 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: February 2010 August 3, 2009 7 AS-wide Unique BGP Identifier for BGP-4 9 draft-ietf-idr-bgp-identifier-10.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 February 4, 2010. 34 Copyright Notice 36 Copyright (c) 2009 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 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 1. Introduction 56 Currently the BGP Identifier of a BGP speaker is specified as a valid 57 IPv4 host address assigned to the BGP speaker [RFC4271]. In 58 addition, the deployed BGP code requires that two BGP speakers be of 59 distinct BGP Identifiers in order to establish a BGP connection. 61 To accommodate situations where the current requirements for the BGP 62 Identifier are not met, this document relaxes the definition of the 63 BGP Identifier to be a 4-octet unsigned, non-zero integer, and 64 relaxes the "uniqueness" requirement so that only AS-wide uniqueness 65 of the BGP Identifiers is required. These revisions to the base BGP 66 specification do not introduce any backward compatibility issue. 68 2. Protocol Revisions 70 The revisions to the base BGP specification [RFC4271] include the 71 definition of the BGP Identifier and procedures for a BGP speaker 72 that supports the AS-wide Unique BGP Identifier. 74 2.1. Definition of the BGP Identifier 76 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 77 the BGP Identifier is specified as the following: 79 The BGP Identifier is a 4-octet unsigned, non-zero integer that 80 should be unique within an AS. The value of the BGP Identifier for 81 a BGP speaker is determined on startup and is the same for every 82 local interface and every BGP peer. 84 2.2. Open Message Error Handling 86 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 87 the OPEN message error handling related to the BGP Identifier is 88 modified as follows: 90 If the BGP Identifier field of the OPEN message is zero, or if 91 it is the same as the BGP Identifier of the local BGP speaker 92 and the message is from an internal peer, then the Error Subcode 93 is set to "Bad BGP Identifier". 95 2.3. Connection Collision Resolution 97 For a BGP speaker that supports the AS-wide Unique BGP Identifier, 98 the procedures for connection collision resolution are extended as 99 follows to deal with the case in which the two BGP speakers share the 100 same BGP Identifier (thus it is only applicable to an external peer): 102 If the BGP Identifiers of the peers involved in the connection 103 collision are identical, then the connection initiated by the BGP 104 speaker with the larger AS number is preserved. 106 This extension covers cases in which the four-octet AS numbers are 107 involved [RFC4893]. 109 3. Remarks 111 It is noted that a BGP Identifier allocated based on [RFC4271] fits 112 the revised definition. 114 In case of BGP Confederation, the whole confederation is considered 115 as one AS for the purpose of supporting the AS-wide Unique BGP 116 Identifier. 118 A BGP speaker that supports the AS-wide Unique BGP Identifier can not 119 share a BGP Identifier with its external neighbor until the remote 120 BGP speaker is upgraded with software that supports the proposed 121 revisions. 123 In addition to the OPEN message, the BGP Identifier is currently also 124 used in the following areas: 126 o In the AGGREAGTOR attribute of a route where the combination of 127 a BGP Identifier and an AS number uniquely identifies the BGP 128 speaker that performs the route aggregation. 130 o In the Route Reflection (in lieu of the Cluster-id) within an 131 AS, where only the BGP Identifier of an internal neighbor may 132 be propagated in the route reflection related attributes. 134 o In the route selection, where the BGP Identifier is not used 135 in comparing a route from an internal neighbor and a route from 136 an external neighbor. In addition, routes from BGP speakers with 137 identical BGP Identifiers have been dealt with (e.g., parallel 138 BGP sessions between two BGP speakers). 140 Therefore it is concluded that the revisions proposed in this 141 document do not introduce any backward compatibility issue with the 142 current usage of the BGP Identifier. 144 4. Security Considerations 146 This extension to BGP does not change the underlying security issues. 148 5. IANA Considerations 150 This document has no actions for IANA. 152 6. Acknowledgments 154 The authors would like to thank members of the IDR Working Group for 155 discussions on the "IPv6-only Network" related issues that inspired 156 this document. 158 7. Normative References 160 [RFC4271] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway 161 Protocol 4 (BGP-4)", RFC 4271, January 2006. 163 [RFC4893] Vohra, Q., and E. Chen, "BGP Support for Four-octet AS 164 Number Space", RFC 4893, May 2007. 166 8. Authors' Addresses 168 Enke Chen 169 Cisco Systems, Inc. 170 170 W. Tasman Dr. 171 San Jose, CA 95134 173 EMail: enkechen@cisco.com 175 Jenny Yuan 176 Cisco Systems, Inc. 177 170 W. Tasman Dr. 178 San Jose, CA 95134 179 EMail: jenny@cisco.com