idnits 2.17.1 draft-keyur-idr-bgp-prefix-limit-orf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 31, 2016) is 2727 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) == Missing Reference: 'TBD' is mentioned on line 116, but not defined == Unused Reference: 'RFC2119' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'RFC3392' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC5292' is defined on line 289, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR K. Patel 3 Internet-Draft Arrcus, Inc 4 Intended status: Standards Track J. Scudder 5 Expires: May 4, 2017 Juniper Networks 6 M. Marzetti 7 PCCW Global 8 J. Heitz 9 Cisco 10 October 31, 2016 12 Prefix Limit Based ORF for BGP-4 13 draft-keyur-idr-bgp-prefix-limit-orf-00.txt 15 Abstract 17 The BGP specification allows for "the ability to impose an (locally 18 configured) upper bound on the number of address prefixes the speaker 19 is willing to accept from a neighbor". In this specification, we 20 define a new Outbound Route Filter type for BGP, termed "Prefix Limit 21 Outbound Route Filter", which the speaker can use to communicate that 22 upper bound to its peer. The peer is then required to abide by the 23 limit. This is expected to have benefits in terms of resource 24 consumption and more importantly, transparency of operation. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 4, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Prefix Limit ORF-Type . . . . . . . . . . . . . . . . . . . . 2 62 3. Prefix Limit ORF encoding . . . . . . . . . . . . . . . . . . 3 63 4. Capability Specification for Cooperative route filtering with 64 Prefix Limit . . . . . . . . . . . . . . . . . . . . . . . . 3 65 5. Rules for Prefix Limit ORF . . . . . . . . . . . . . . . . . 3 66 5.1. Rules for Sending Speaker . . . . . . . . . . . . . . . . 4 67 5.1.1. Enforcing the Prefix Limit . . . . . . . . . . . . . 4 68 5.2. Rules for Receiving Speaker . . . . . . . . . . . . . . . 5 69 6. Error handling . . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 The Cooperative Outbound Route Filtering Capability defined in 79 [RFC5291] provides a mechanism for a BGP speaker to send to its BGP 80 neighbor a set of Outbound Route Filters (ORFs) that can be used by 81 its neighbor to filter its outbound routing updates to the speaker. 83 This documents defines a new ORF-type for BGP, termed "Prefix Limit 84 Outbound Route Filter (PrefixLimit ORF)", that can be used to perform 85 Prefix Limit based route filtering. This filtering mechanism imposes 86 a limit on a the number of unique prefixes that the BGP speaker can 87 advertise to its neighbor. 89 2. Prefix Limit ORF-Type 91 The Prefix Limit ORF-Type allows a BGP speaker to inform its neighbor 92 of its prefix limits. That is, it provides a mechanism through which 93 a BGP speaker can request its neighbor to limit the number of unique 94 prefixes that neighbor will advertise to the BGP speaker. 96 Conceptually a Prefix Limit ORF entry consists of the fields "Action, 97 Match, Reserved, Prefix-Limit". 99 Action is a two-bit field. The definition and use of the Action 100 field is described in [RFC5291]. 102 Match is a one-bit field. The value of this field is 0 for PERMIT 103 and 1 for DENY. In the context of the Prefix Limit ORF-Type, DENY 104 indicates that the BGP speaker sending the ORF will terminate the 105 connection in the event that the Prefix Limit is exceeded. 107 Reserved is a 5-bit field. The definition and use of the Reserved 108 field is described in [RFC5291]. 110 The "Prefix-Limit" is a four byte unsigned integer. It states the 111 maximum number of unique prefixes that the ORF sending BGP speaker 112 is willing to accept from the ORF receiving BGP spea 114 3. Prefix Limit ORF encoding 116 The value of the ORF-Type for the Prefix Limit ORF-Type is [TBD]. 118 A Prefix Limit ORF entry is encoded as follows. The "Action", 119 "Match", and the "Reserved" field of the entry is encoded in the 120 common part [RFC5291], and the remaining field of the entry is 121 encoded in the "Type specific part" as follows. 123 +--------------------------------------------------+ 124 | Prefix-Limit (4 octets) | 125 +--------------------------------------------------+ 127 4. Capability Specification for Cooperative route filtering with Prefix 128 Limit 130 A BGP speaker signals its compliance with this specification by 131 listing the PrefixLimit ORF type in the Cooperative Route Filtering 132 Capability as defined in [RFC5291]. 134 5. Rules for Prefix Limit ORF 136 We describe the rules for PrefixLimit primarily in terms of the rules 137 for the router which sends a PrefixLimit ORF to its peer, which we 138 term the "sending speaker", and for the router which receives a 139 PrefixLimit ORF from its peer, which we term the "receiving speaker". 140 Note that a given router may be either a sending or receiving 141 speaker, or both, with respect to any given peering session. 143 A router which supports PrefixLimit ORF MUST keep track of the number 144 of prefixes it has advertised to its peer -- when a new prefix is 145 advertised, the count is incremented, and when a prefix is withdrawn, 146 the count is decremented. A modification to the route for an 147 already-advertised prefix does not change the count. We refer to 148 this count as the "advertised prefix count" for the session. In 149 effect, the advertised prefix count is equivalent to the size of the 150 Adj-RIB-Out for the session. 152 A router which supports PrefixLimit ORF MAY maintain a received 153 prefix count for its peer, which tracks the number of prefixes it has 154 accepted from the peer. In effect, the received route count is 155 equivalent to the size of the Adj-RIB-In for the session. The use of 156 such a count is elaborated in the following section. 158 5.1. Rules for Sending Speaker 160 If a BGP speaker (the sending speaker) is configured to bound the 161 number of prefixes it is willing to accept from its neighbor, it MAY 162 advertise the value of that upper bound to that neighbor using 163 PrefixLimit ORF. In this section and its subsection, when we refer 164 to "the PrefixLimit" we are referring to the PrefixLimit value most 165 recently advertised by the sending speaker to the receiving speaker. 167 If the sending speaker does not maintain a received prefix count, it 168 is implicitly relying on its peer to correctly abide by this 169 specification and no further action is required. If the sending 170 speaker does maintain a received prefix count, it MAY locally enforce 171 the PrefixLimit, according to the following rules. 173 5.1.1. Enforcing the Prefix Limit 175 When the sending speaker sends a PrefixLimit ORF which is less than 176 its current received prefix count, it SHOULD wait for some interval 177 before enforcing the new PrefixLimit. The interval to be used is a 178 matter of local policy. Also, even if the PrefixLimit ORF is greater 179 than or equal to the current received prefix count, the router may 180 wish to wait for some interval before enforcing the new limit in 181 order to allow for UPDATEs which may have been in flight prior to the 182 receipt of the PrefixLimit ORF by the peer. Subsequent to any such 183 waiting period, the remaining rules in this section SHALL apply. 185 If the PrefixLimit is exceeded (either because of a route announced 186 by the peer or because the peer failed to timely withdraw routes 187 after the PrefixLimit is revised downward), the peer is in violation, 188 and the sending speaker MAY take corrective action. The router MAY 189 also allow the received prefix count to exceed the PrefixLimit by 190 some amount as a matter of local policy. 192 Corrective actions MAY include dropping the BGP session or refusing 193 to accept new prefixes in excess of the PrefixLimit. 195 If the former option -- dropping the BGP session -- is chosen, the 196 router MUST indicate this in advance by advertising its PrefixLimit 197 ORF with the Match flag set to DENY. Also, by default it SHOULD NOT 198 automatically reestablish the session. 200 If the latter option -- refusing to accept new prefixes -- is chosen, 201 the router MUST accept modifications to already-accepted prefixes, 202 and it MUST accept withdrawals of already-accepted prefixes. If 203 prefixes are withdrawn, the received prefix count will drop below the 204 announced PrefixLimit and new prefixes SHOULD be accepted, again up 205 to but not exceeding the limit. Prefixes which are refused SHOULD 206 NOT contribute to the received prefix count. 208 We note that the option of refusing to accept new prefixes will 209 likely lead to desynchronization of the BGP session and is a flawed 210 solution at best; operator intervention will be required in order to 211 restore synchronization (for example, through correction of routing 212 policies and a subsequent route-refresh). 214 5.2. Rules for Receiving Speaker 216 When a PrefixLimit ORF is received, the new Prefix Limit value in the 217 ORF is considered to be the new maximum Prefix Limit for the 218 neighbor. In this section, when we refer to "the PrefixLimit" we are 219 referring to the PrefixLimit value most recently received from the 220 sending speaker by the receiving speaker. 222 The receiving speaker MUST NOT advertise a prefix to its peer if 223 doing so would cause its advertised prefix count to exceed the 224 PrefixLimit. 226 The receiving speaker MAY take local action when its advertised 227 prefix count approaches the PrefixLimit. The nature of the action 228 (logging, etc) is a matter of local policy, as is the threshold at 229 which the action occurs. 231 When the receiving speaker receives a PrefixLimit ORF with When-to- 232 Refresh set to DEFER, it need not take any additional action unless 233 its current advertised prefix count exceeds the new PrefixLimit. In 234 that case, it MUST take immediate steps to correct the violation. 236 Such steps MAY include withdrawing already-advertised prefixes so as 237 to reduce the advertised prefix count to be less than or equal to the 238 PrefixLimit. The selection of which prefixes to withdraw is a matter 239 of local policy. Another option to correct the violation would be to 240 drop the session; in this case the session SHOULD NOT be 241 automatically reestablished. 243 When the receiving speaker receives a PrefixLimit ORF with When-to- 244 Refresh set to IMMEDIATE, it behaves as given for DEFER but in 245 addition advertises its Adj-RIB-Out as specified in [RFC5291]. 247 6. Error handling 249 ORFs provide information that guides future sending, but any 250 malformed ORF is simply missed filtering information. If Prefix 251 Limit ORF is malformed, then the Refresh messages shall simply be 252 discarded. 254 7. Security Considerations 256 This extension to BGP does not change the underlying security issues. 257 However, it does suggest a mechanism by which certain denial of 258 service risks may be reduced. 260 8. Acknowledgements 262 The authors would like to thank ... for their valuable comments. 264 9. IANA Considerations 266 This specification requests a new Cooperative Route Filter [RFC5291] 267 type code. 269 10. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 277 with BGP-4", RFC 3392, DOI 10.17487/RFC3392, November 278 2002, . 280 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 281 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 282 DOI 10.17487/RFC4271, January 2006, 283 . 285 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 286 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 287 August 2008, . 289 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 290 Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, 291 August 2008, . 293 Authors' Addresses 295 Keyur Patel 296 Arrcus, Inc 298 Email: keyur@arrcus.com 300 John Scudder 301 Juniper Networks 303 Email: jgs@juniper.net 305 Marco Marzetti 306 PCCW Global 307 450 Spring Park Place, Suite 100 308 Herndon , VA 20170 310 Email: mmarzetti@pccwglobal.com 312 Jakob Heitz 313 Cisco 314 170 W. Tasman Drive 315 San Jose, CA 95124 317 Email: jheitz@cisco.com