idnits 2.17.00 (12 Aug 2021) /tmp/idnits16828/draft-keyur-prefixlimit-orf-00.txt: 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 3979, Section 5, paragraph 1 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 327. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 279), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (April 2004) is 6603 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) == Unused Reference: 'BGP-4' is defined on line 250, but no explicit reference was found in the text == Unused Reference: 'BGP-DRAFT' is defined on line 253, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) == Outdated reference: draft-ietf-idr-bgp4 has been published as RFC 4271 == Outdated reference: draft-ietf-idr-route-filter has been published as RFC 5291 Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Keyur Patel 2 draft-keyur-prefixlimit-orf-00.txt Chandra Appanna 3 John Scudder 4 Expires: October 2004 April 2004 6 Prefix Limit Based Outbound Route Filter for BGP-4 7 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This document is an individual submission. Comments are solicited and 31 should be addressed to the author(s). 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 The BGP specification allows for "the ability to impose an (locally 40 configured) upper bound on the number of address prefixes the speaker 41 is willing to accept from a neighbor". In this specification, we 42 define a new Outbound Route Filter type for BGP, termed "Prefix Limit 43 Outbound Route Filter", which the speaker can use to communicate that 44 upper bound to its peer. The peer is then required to abide by the 45 limit. This is expected to have benefits in terms of resource 46 consumption and more importantly, transparency of operation. 48 1. Introduction 50 The Cooperative Outbound Route Filtering Capability defined in [BGP- 51 ORF] provides a mechanism for a BGP speaker to send to its BGP 52 neighbor a set of Outbound Route Filters (ORFs) that can be used by 53 its neighbor to filter its outbound routing updates to the speaker. 55 This documents defines a new ORF-type for BGP, termed "Prefix Limit 56 Outbound Route Filter (PrefixLimit ORF)", that can be used to perform 57 Prefix Limit based route filtering. This filtering mechanism imposes 58 a limit on a the number of unique prefixes that the BGP speaker can 59 advertise to its neighbor. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in BCP 14, RFC 2119 64 [RFC2119]. 66 2. Prefix Limit ORF-Type 68 The Prefix Limit ORF-Type allows a BGP speaker to inform its neighbor 69 of its prefix limits. That is, it provides a mechanism through which 70 a BGP speaker can request its neighbor to limit the number of unique 71 prefixes that neighbor will advertise to the BGP speaker. 73 Conceptually a Prefix Limit ORF entry consists of the fields . 76 Action is a two-bit field. The definition and use of the Action 77 field is described in [BGP-ORF]. 79 Match is a one-bit field. The value of this field is 0 for PERMIT 80 and 1 for DENY. In the context of the Prefix Limit ORF-Type, DENY 81 indicates that the BGP speaker sending the ORF will terminate the 82 connection in the event that the Prefix Limit is exceeded. 84 Reserved is a 5-bit field. The definition and use of the Reserved 85 field is described in [BGP-ORF]. 87 The "Prefix-Limit" is a four byte unsigned integer. It states the 88 maximum number of unique prefixes that the ORF sending BGP speaker is 89 willing to accept from the ORF receiving BGP speaker. 91 2.1. Prefix Limit ORF Encoding 93 The value of the ORF-Type for the Prefix Limit ORF-Type is . 95 A Prefix Limit ORF entry is encoded as follows. The "Action", 96 "Match", and the "Reserved" field of the entry is encoded in the 97 common part [BGP-ORF], and the remaining field of the entry is 98 encoded in the "Type specific part" as follows. 100 +--------------------------------------------------+ 101 | Prefix-Limit (4 octets) | 102 +--------------------------------------------------+ 104 3. Capability 106 A BGP speaker signals its compliance with this specification by 107 listing the PrefixLimit ORF type in the Cooperative Route Filtering 108 Capability as defined in [BGP-ORF]. 110 4. Rules for PrefixLimit ORF 112 We describe the rules for PrefixLimit primarily in terms of the rules 113 for the router which sends a PrefixLimit ORF to its peer, which we 114 term the "sending speaker", and for the router which receives a 115 PrefixLimit ORF from its peer, which we term the "receiving speaker". 116 Note that a given router may be either a sending or receiving 117 speaker, or both, with respect to any given peering session. 119 A router which supports PrefixLimit ORF MUST keep track of the number 120 of prefixes it has advertised to its peer -- when a new prefix is 121 advertised, the count is incremented, and when a prefix is withdrawn, 122 the count is decremented. A modification to the route for an 123 already-advertised prefix does not change the count. We refer to 124 this count as the "advertised prefix count" for the session. In 125 effect, the advertised prefix count is equivalent to the size of the 126 Adj-RIB-Out for the session. 128 A router which supports PrefixLimit ORF MAY maintain a received 129 prefix count for its peer, which tracks the number of prefixes it has 130 accepted from the peer. In effect, the received route count is 131 equivalent to the size of the Adj-RIB-In for the session. The use of 132 such a count is elaborated in the following section. 134 4.1. Rules for Sending Speaker 136 If a BGP speaker (the sending speaker) is configured to bound the 137 number of prefixes it is willing to accept from its neighbor, it MAY 138 advertise the value of that upper bound to that neighbor using 139 PrefixLimit ORF. In this section and its subsection, when we refer 140 to "the PrefixLimit" we are referring to the PrefixLimit value most 141 recently advertised by the sending speaker to the receiving speaker. 143 If the sending speaker does not maintain a received prefix count, it 144 is implicitly relying on its peer to correctly abide by this 145 specification and no further action is required. If the sending 146 speaker does maintain a received prefix count, it MAY locally enforce 147 the PrefixLimit, according to the following rules. 149 4.1.1. Enforcing The PrefixLimit 151 When the sending speaker sends a PrefixLimit ORF which is less than 152 its current received prefix count, it SHOULD wait for some interval 153 before enforcing the new PrefixLimit. The interval to be used is a 154 matter of local policy. Also, even if the PrefixLimit ORF is greater 155 than or equal to the current received prefix count, the router may 156 wish to wait for some interval before enforcing the new limit in 157 order to allow for UPDATEs which may have been in flight prior to the 158 receipt of the PrefixLimit ORF by the peer. Subsequent to any such 159 waiting period, the remaining rules in this section SHALL apply. 161 If the PrefixLimit is exceeded (either because of a route announced 162 by the peer or because the peer failed to timely withdraw routes 163 after the PrefixLimit is revised downward), the peer is in violation, 164 and the sending speaker MAY take corrective action. The router MAY 165 also allow the received prefix count to exceed the PrefixLimit by 166 some amount as a matter of local policy. 168 Corrective actions MAY include dropping the BGP session or refusing 169 to accept new prefixes in excess of the PrefixLimit. 171 If the former option -- dropping the BGP session -- is chosen, the 172 router MUST indicate this in advance by advertising its PrefixLimit 173 ORF with the Match flag set to DENY. Also, by default it SHOULD NOT 174 automatically reestablish the session. 176 If the latter option -- refusing to accept new prefixes -- is chosen, 177 the router MUST accept modifications to already-accepted prefixes, 178 and it MUST accept withdrawals of already-accepted prefixes. If 179 prefixes are withdrawn, the received prefix count will drop below the 180 announced PrefixLimit and new prefixes SHOULD be accepted, again up 181 to but not exceeding the limit. Prefixes which are refused SHOULD 182 NOT contribute to the received prefix count. 184 We note that the option of refusing to accept new prefixes will 185 likely lead to desynchronization of the BGP session and is a flawed 186 solution at best; operator intervention will be required in order to 187 restore synchronization (for example, through correction of routing 188 policies and a subsequent route-refresh). 190 4.2. Rules for Receiving Speaker 192 When a PrefixLimit ORF is received, the new Prefix Limit value in the 193 ORF is considered to be the new maximum Prefix Limit for the 194 neighbor. In this section, when we refer to "the PrefixLimit" we are 195 referring to the PrefixLimit value most recently received from the 196 sending speaker by the receiving speaker. 198 The receiving speaker MUST NOT advertise a prefix to its peer if 199 doing so would cause its advertised prefix count to exceed the 200 PrefixLimit. 202 The receiving speaker MAY take local action when its advertised 203 prefix count approaches the PrefixLimit. The nature of the action 204 (logging, etc) is a matter of local policy, as is the threshold at 205 which the action occurs. 207 When the receiving speaker receives a PrefixLimit ORF with When-to- 208 Refresh set to DEFER, it need not take any additional action unless 209 its current advertised prefix count exceeds the new PrefixLimit. In 210 that case, it MUST take immediate steps to correct the violation. 212 Such steps MAY include withdrawing already-advertised prefixes so as 213 to reduce the advertised prefix count to be less than or equal to the 214 PrefixLimit. The selection of which prefixes to withdraw is a matter 215 of local policy. Another option to correct the violation would be to 216 drop the session; in this case the session SHOULD NOT be 217 automatically reestablished. 219 When the receiving speaker receives a PrefixLimit ORF with When-to- 220 Refresh set to IMMEDIATE, it behaves as given for DEFER but in 221 addition advertises its Adj-RIB-Out as specified in [BGP-ORF]. 223 5. Acknowledgments 225 Shyam Suri, David Ward, David Meyer and Robert Raszuk provided 226 valuable comments. 228 This draft was inspired in part by an earlier draft by Srikanth 229 Chavali, Vasile Radoaca, Mo Miri, Luyuan Fang and Susan Hares. 231 6. Security Considerations 233 This specification does not change BGP's principal underlying 234 security considerations. However, it does suggest a mechanism by 235 which certain denial of service risks may be reduced. 237 7. IANA Considerations 239 This specification requests a new Cooperative Route Filter [BGP-ORF] 240 type code. 242 8. References 244 8.1. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to 247 Indicate Requirement Levels" BCP 14, RFC 2119, 248 March 1997. 250 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 251 (BGP-4)", RFC 1771, March 1995. 253 [BGP-DRAFT] Rekhter, Y., T. Li and S. Hares, ""A Border Gateway 254 Protocol 4 (BGP-4)", work in progress, 255 draft-ietf-idr-bgp4-23.txt, November 2003. 257 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 258 Capability for BGP-4", work in progress, 259 draft-ietf-idr-route-filter-10.txt, March 2004. 261 9. Authors' Addresses 263 Keyur Patel 264 Cisco Systems 265 email: keyupate@cisco.com 267 Chandra Appanna 268 Cisco Systems 269 email: achandra@cisco.com 271 John Scudder 272 Cisco Systems 273 email: jgs@cisco.com 275 10. Full Copyright Statement 277 Copyright (C) The Internet Society (2004). This document is subject 278 to the rights, licenses and restrictions contained in BCP 78 and 279 except as set forth therein, the authors retain all their rights. 281 This document and translations of it may be copied and furnished to 282 others, and derivative works that comment on or otherwise explain it 283 or assist in its implementation may be prepared, copied, published 284 and distributed, in whole or in part, without restriction of any 285 kind, provided that the above copyright notice and this paragraph are 286 included on all such copies and derivative works. However, this 287 document itself may not be modified in any way, such as by removing 288 the copyright notice or references to the Internet Society or other 289 Internet organizations, except as needed for the purpose of 290 developing Internet standards in which case the procedures for 291 copyrights defined in the Internet Standards process must be 292 followed, or as required to translate it into languages other than 293 English. 295 The limited permissions granted above are perpetual and will not be 296 revoked by the Internet Society or its successors or assigns. 298 This document and the information contained herein is provided on an 299 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 300 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 301 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 302 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 303 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 305 11. Intellectual Property 307 The IETF takes no position regarding the validity or scope of any 308 Intellectual Property Rights or other rights that might be claimed to 309 pertain to the implementation or use of the technology described in 310 this document or the extent to which any license under such rights 311 might or might not be available; nor does it represent that it has 312 made any independent effort to identify any such rights. Information 313 on the procedures with respect to rights in RFC documents can be 314 found in BCP 78 and BCP 79. 316 Copies of IPR disclosures made to the IETF Secretariat and any 317 assurances of licenses to be made available, or the result of an 318 attempt made to obtain a general license or permission for the use of 319 such proprietary rights by implementers or users of this 320 specification can be obtained from the IETF on-line IPR repository at 321 http://www.ietf.org/ipr. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights that may cover technology that may be required to implement 326 this standard. Please address the information to the IETF at ietf- 327 ipr@ietf.org. 329 12. Acknowledgement 331 Funding for the RFC Editor function is currently provided by the 332 Internet Society.