idnits 2.17.1 draft-chen-confed-oscillation-reduce-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 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) -- Unexpected draft version: The latest known version of draft-ietf-idr-route-oscillation is -00, but you're referring to -01. ** Downref: Normative reference to an Informational draft: draft-ietf-idr-route-oscillation (ref. '1') ** Obsolete normative reference: RFC 3065 (ref. '2') (Obsoleted by RFC 5065) == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-17 == Outdated reference: A later version (-06) exists of draft-walton-bgp-add-paths-00 -- Possible downref: Normative reference to a draft: ref. '4' Summary: 7 errors (**), 0 flaws (~~), 5 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 Redback Networks 4 Expiration Date: December 2002 6 BGP Route Oscillation Reduction with Confederation 8 draft-chen-confed-oscillation-reduce-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 This document proposes a simple revision to Confederation that allows 34 a BGP speaker in a Confederation to send a route advertisement 35 (instead of a route withdraw) in certain cases. The route 36 advertisement helps narrow the gap between Confederation and IBGP 37 full-mesh in terms of routing information. It has been shown that the 38 proposed mechanism helps achieve stable route selection and eliminate 39 a number of persistent route oscillations involving Confederation. 41 3. Introduction 43 As documented in [1], the routing information reduction by BGP 44 Confederation [2] can result in persistent route oscillations with 45 certain routing setup and network topologies. 47 This document proposes a simple revision to Confederation that allows 48 a BGP speaker in a Confederation to send a route advertisement 49 (instead of a route withdraw) in certain cases. The route 50 advertisement helps narrow the gap between Confederation and IBGP 51 full-mesh in terms of routing information. It has been shown that the 52 proposed mechanism helps achieve stable route selection and eliminate 53 a number of persistent route oscillations involving Confederation. 55 The proposed mechanisms work within the current BGP protocol [4] that 56 limits route advertisement to only one path per prefix. In addition, 57 only the Confederation Sub-AS Border Routers need to be upgraded. One 58 can upgrade one router at a time when required, and then immediately 59 benefit from the route oscillation reduction or elimination. 61 4. Modification to Confederation 63 Currently a BGP speaker in a Confederation [3] follows the basic BGP 64 principle that only the best path is advertised to a BGP peer. 65 Therefore when the overall best path for a speaker is from a peer in 66 a neighboring AS of the same Confederation, none of the paths from 67 peers in the same AS would be advertised by the speaker to a peer in 68 a neighboring AS of the same Confederation, and be considered in 69 route selection. Similarly when the overall best path for a speaker 70 is from a peer in the same AS, none of paths from peers in a 71 neighboring AS of the same Confederation would be advertised by the 72 speaker to a peer in the same AS, and be considered in route 73 selection. 75 In order to increase the routing information advertised in a 76 Confederation, the following modification is proposed: 78 In addition to calculating the overall best path among all the 79 received paths, a BGP speaker in a Confederation may calculate 80 a best path ("I-BEST") among all the paths received from peers 81 within the same AS. It may also calculate a best path ("E-BEST") 82 among all the paths received from peers in neighboring ASs of 83 the same Confederation. 85 When the E-BEST for a speaker exists, and the I-BEST is the 86 overall best path for the speaker, the speaker may advertise the 87 E-BEST to a peer in the same AS of the Confederation. When the 88 E-BEST becomes non-existence, or when it should no longer be 89 advertised, a replacement path or route withdraw must be sent to 90 a peer in the same AS if an E-BEST was advertised to the peer 91 previously. 93 Consider the case in which a BGP speaker in a Confederation 94 maintains BGP sessions with remote speakers in neighboring ASs 95 of the Confederation, and all the remote speakers maintain direct 96 BGP sessions among them. In this case the speaker does not need to 97 advertise routes learned from one such a remote peer to another. 98 When the I-BEST for the speaker exists, and the E-BEST is the 99 overall best path for the speaker, the speaker may advertise 100 the I-BEST to peers in neighboring ASs of the Confederation. 101 When the I-BEST becomes non-existence, or when it should no 102 longer be advertised, a replacement path or route withdraw 103 must be sent to a peer in a neighboring AS of the Confederation 104 if an I-BEST was advertised to the peer previously. 106 It is noted that the advertisement of I-BEST (or E-BEST) is not 107 useful and should not be sent when the overall best path wins 108 over the I-BEST (or E-BEST) prior to (and including) the step 109 of MED comparison in the route selection procedure [3, Sect. 9.1]. 111 This modification allows additional routing information to be 112 advertised, and be available in route selection. 114 5. Remarks 116 The proposed mechanism alleviates to some degree, but does not fully 117 resolve the concern of routing information reduction by 118 Confederation. It is possible that the proposed mechanism may not be 119 adequate for certain persistent route oscillation cases in which the 120 advertisement of multiple paths for a prefix (as proposed in [4]) may 121 be required for their resolution. 123 It should be noted that compared to the existing mechanism of 124 Confederation, the proposed revision may cause memory usage in a 125 network to increase due to the advertisement of additional routing 126 information. 128 6. Intellectual Property Considerations 130 Redback Networks, Inc. may seek patent protection on some of the 131 technology described in this Internet Draft. If technology in this 132 document is adopted as a standard, Redback Networks agrees to 133 license, on reasonable and non-discriminatory terms, any patent 134 rights it obtains covering such technology to the extent necessary to 135 comply with the standard. 137 7. Security Considerations 139 This document introduces no new security concerns to BGP or other 140 specifications referenced in this document. 142 8. Acknowledgments 144 The author would like to thank Naiming Shen and Jenny Yuan for their 145 review and comments. 147 9. References 149 [1] McPherson, D., Gill, V., Walton, D., Retana, A., "BGP Persistent 150 Route Oscillation Condition", Work in Progress (draft-ietf-idr- 151 route-oscillation-01), February 2002. 153 [2] Traina, P., McPherson, D., Scudder, J.. "Autonomous System Con- 154 federations for BGP", RFC 3065, February 2001. 156 [3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 157 Work in Progress (draft-ietf-idr-bgp4-17), January 2002 159 [4] Walton, D., Cook, D., Retana, A., Scudder, J., "Advertisement of 160 Multiple Paths in BGP", Work in Progress (draft-walton-bgp-add- 161 paths-00), May 2002. 163 10. Author Information 165 Enke Chen 166 Redback Networks, Inc. 167 350 Holger Way 168 San Jose, CA 95134 169 Email: enke@redback.com