idnits 2.17.1 draft-chen-bgp-avoid-collision-00.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-20 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 BGP Connection Collision Avoidance 8 draft-chen-bgp-avoid-collision-00.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 simplify the BGP session bringup logic, in this document we 34 propose a revision that allows a BGP speaker to play only the active 35 or the passive role in establishing a BGP connection with another BGP 36 speaker. A BGP speaker determines whether it will play the active or 37 passive role based on the AS numbers and/or the peering addresses 38 involved. 40 3. Introduction 42 As described in [1], BGP connection collisions may occur as a BGP 43 speaker currently plays both the active and the passive roles in 44 establishing a BGP connection with another BGP speaker. To resolve 45 the connection collision, one TCP connection must be terminated. 47 Clearly BGP connection collision consumes more system resource. More 48 importantly, it introduces significant complications to the BGP state 49 machine and therefore to the implementation of the BGP session 50 bringup logic. 52 To simplify the BGP session bringup logic, in this document we 53 propose a revision that allows a BGP speaker to play only the active 54 or the passive role in establishing a BGP connection with another BGP 55 speaker. A BGP speaker determines whether it will play the active or 56 passive role based on the AS numbers and/or the peering addresses 57 involved. 59 4. Protocol Revision 61 This revision assumes that the AS numbers and peering addresses are 62 known (e.g., via configuration) before a BGP connection is attempted. 64 A BGP speaker plays either an active or passive role in establishing 65 a BGP connection with another speaker. If a BGP speaker is active, it 66 attempts to establish the BGP TCP connection by connecting to the 67 well-known BGP port at the address of the other speaker. If a BGP 68 speaker is passive, it waits for the other speaker to establish the 69 BGP TCP connection to its well-known BGP port. 71 A BGP speaker (S1) determines whether it will play the active or 72 passive role by first comparing its AS number (AS1) with the AS 73 number (AS2) of the other speaker (S2): 75 If AS1 > AS2, S1 plays the active role. 77 If AS1 < AS2, S1 plays the passive role. 79 If AS1 == AS2, then the peering addresses (A1 for S1, and A2 80 for S2) are compared as unsigned integers. If A1 > A2, S1 plays 81 the active role; otherwise it plays the passive role. 83 The procedure for comparing A1 and A2 as unsigned integers is as 84 follows: 86 If A1 and A2 are not in the same address family, they are 87 incomparable, and no session can be established. 89 Let U1 be the abstract unsigned integer obtained by treating A1 90 as a sequence of bytes, where the byte which appears earliest is 91 the most significant byte of the integer and the byte which 92 appears latest is the least significant byte of the integer. 94 Let U2 be the abstract unsigned integer obtained from A2 in 95 a similar manner. 97 Compare U1 with U2. If U1 > U2, then A1 > A2; if U1 < U2, 98 then A1 < A2. 100 5. Remarks 102 Clearly a BGP speaker (whether active or passive) following the 103 proposed revision would be able to bring up a BGP session with 104 another BGP speaker that plays both active and passive roles in 105 establishing a BGP connection as described in [1]. 107 In certain implementations a BGP speaker would not play the active 108 role using a default route to reach the remote peering address. 109 Nevertheless a BGP connection could still be formed when the remote 110 speaker plays both the active and passive roles in such cases. With 111 the proposed revision, though, the BGP connection would not be formed 112 when the remote speaker plays only the passive role. Such cases are 113 rare, and in particular do not occur with one-hop EBGP sessions. They 114 can be easily identified and corrected by simple re-configuration. We 115 belive that the benefits of the proposed revision outweight the 116 effort involved in identifying and reconfiguring such peers during 117 deployment. 119 6. Security Considerations 121 This revision to BGP does not change the underlying security issues. 123 7. Acknowledgments 125 TBD 127 8. References 129 [1] Y. Rekhter, T. Li and S. Hares, "A Border Gateway Protocol 4 130 (BGP-4)", draft-ietf-idr-bgp4-20.txt, April 2003. 132 9. Author Information 134 Enke Chen 135 Redback Networks, Inc. 136 300 Holger Way 137 San Jose, CA 95134 138 e-mail: enke@redback.com 140 Jenny Yuan 141 Redback Networks, Inc. 142 300 Holger Way 143 San Jose, CA 95134 144 e-mail: enke@redback.com