idnits 2.17.1 draft-keyur-idr-bgp-prefix-limit-orf-03.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 date (April 26, 2018) is 2191 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 125, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR M. Marzetti 3 Internet-Draft PCCW Global 4 Intended status: Standards Track K. Patel 5 Expires: October 28, 2018 Arrcus, Inc 6 J. Scudder 7 Juniper Networks 8 J. Heitz 9 Cisco 10 J. Snijders 11 NTT 12 April 26, 2018 14 Prefix Limit Based ORF for BGP-4 15 draft-keyur-idr-bgp-prefix-limit-orf-03 17 Abstract 19 The BGP specification allows for "the ability to impose an (locally 20 configured) upper bound on the number of address prefixes the speaker 21 is willing to accept from a neighbor". In this specification, we 22 define a new Outbound Route Filter type for BGP, termed "Prefix Limit 23 Outbound Route Filter", which the speaker can use to communicate that 24 upper bound to its peer. The peer is then required to abide by the 25 limit. This is expected to have benefits in terms of resource 26 consumption and more importantly, transparency of operation. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 28, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Prefix Limit ORF-Type . . . . . . . . . . . . . . . . . . . . 3 65 4. Prefix Limit ORF encoding . . . . . . . . . . . . . . . . . . 3 66 5. Capability Specification for Cooperative route filtering with 67 Prefix Limit . . . . . . . . . . . . . . . . . . . . . . . . 4 68 6. Rules for Prefix Limit ORF . . . . . . . . . . . . . . . . . 4 69 6.1. Rules for Sending Speaker . . . . . . . . . . . . . . . . 4 70 6.1.1. Enforcing the Prefix Limit . . . . . . . . . . . . . 5 71 6.2. Rules for Receiving Speaker . . . . . . . . . . . . . . . 5 72 7. Error handling . . . . . . . . . . . . . . . . . . . . . . . 6 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 11. Normative References . . . . . . . . . . . . . . . . . . . . 7 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 The Cooperative Outbound Route Filtering Capability defined in 82 [RFC5291] provides a mechanism for a BGP speaker to send to its BGP 83 neighbor a set of Outbound Route Filters (ORFs) that can be used by 84 its neighbor to filter its outbound routing updates to the speaker. 86 This documents defines a new ORF-type for BGP, termed "Prefix Limit 87 Outbound Route Filter (PrefixLimit ORF)", that can be used to perform 88 Prefix Limit based route filtering. This filtering mechanism imposes 89 a limit on a the number of unique prefixes that the BGP speaker can 90 advertise to its neighbor. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 3. Prefix Limit ORF-Type 100 The Prefix Limit ORF-Type allows a BGP speaker to inform its neighbor 101 of its prefix limits. That is, it provides a mechanism through which 102 a BGP speaker can request its neighbor to limit the number of unique 103 prefixes that neighbor will advertise to the BGP speaker. 105 Conceptually a Prefix Limit ORF entry consists of the fields "Action, 106 Match, Reserved, Prefix-Limit". 108 Action is a two-bit field. The definition and use of the Action 109 field is described in [RFC5291]. 111 Match is a one-bit field. The value of this field is 0 for PERMIT 112 and 1 for DENY. In the context of the Prefix Limit ORF-Type, DENY 113 indicates that the BGP speaker sending the ORF will terminate the 114 connection in the event that the Prefix Limit is exceeded. 116 Reserved is a 5-bit field. The definition and use of the Reserved 117 field is described in [RFC5291]. 119 The "Prefix-Limit" is a four byte unsigned integer. It states the 120 maximum number of unique prefixes that the ORF sending BGP speaker 121 is willing to accept from the ORF receiving BGP speaker. 123 4. Prefix Limit ORF encoding 125 The value of the ORF-Type for the Prefix Limit ORF-Type is [TBD]. 127 A Prefix Limit ORF entry is encoded as follows. The "Action", 128 "Match", and the "Reserved" field of the entry is encoded in the 129 common part [RFC5291], and the remaining field of the entry is 130 encoded in the "Type specific part" as follows. 132 +--------------------------------------------------+ 133 | Prefix-Limit (4 octets) | 134 +--------------------------------------------------+ 136 5. Capability Specification for Cooperative route filtering with Prefix 137 Limit 139 A BGP speaker signals its compliance with this specification by 140 listing the PrefixLimit ORF type in the Cooperative Route Filtering 141 Capability as defined in [RFC5291]. 143 6. Rules for Prefix Limit ORF 145 We describe the rules for PrefixLimit primarily in terms of the rules 146 for the router which sends a PrefixLimit ORF to its peer, which we 147 term the "sending speaker", and for the router which receives a 148 PrefixLimit ORF from its peer, which we term the "receiving speaker". 149 Note that a given router may be either a sending or receiving 150 speaker, or both, with respect to any given peering session. 152 A router which supports PrefixLimit ORF MUST keep track of the number 153 of prefixes it has advertised to its peer -- when a new prefix is 154 advertised, the count is incremented, and when a prefix is withdrawn, 155 the count is decremented. A modification to the route for an 156 already-advertised prefix does not change the count. We refer to 157 this count as the "advertised prefix count" for the session. In 158 effect, the advertised prefix count is equivalent to the size of the 159 Adj-RIB-Out for the session. 161 A router which supports PrefixLimit ORF MAY maintain a received 162 prefix count for its peer, which tracks the number of prefixes it has 163 accepted from the peer. In effect, the received route count is 164 equivalent to the size of the Adj-RIB-In for the session. The use of 165 such a count is elaborated in the following section. 167 6.1. Rules for Sending Speaker 169 If a BGP speaker (the sending speaker) is configured to bound the 170 number of prefixes it is willing to accept from its neighbor, it MAY 171 advertise the value of that upper bound to that neighbor using 172 PrefixLimit ORF. In this section and its subsection, when we refer 173 to "the PrefixLimit" we are referring to the PrefixLimit value most 174 recently advertised by the sending speaker to the receiving speaker. 176 If the sending speaker does not maintain a received prefix count, it 177 is implicitly relying on its peer to correctly abide by this 178 specification and no further action is required. If the sending 179 speaker does maintain a received prefix count, it MAY locally enforce 180 the PrefixLimit, according to the following rules. 182 6.1.1. Enforcing the Prefix Limit 184 When the sending speaker sends a PrefixLimit ORF which is less than 185 its current received prefix count, it SHOULD wait for some interval 186 before enforcing the new PrefixLimit. The interval to be used is a 187 matter of local policy. Also, even if the PrefixLimit ORF is greater 188 than or equal to the current received prefix count, the router may 189 wish to wait for some interval before enforcing the new limit in 190 order to allow for UPDATEs which may have been in flight prior to the 191 receipt of the PrefixLimit ORF by the peer. Subsequent to any such 192 waiting period, the remaining rules in this section SHALL apply. 194 If the PrefixLimit is exceeded (either because of a route announced 195 by the peer or because the peer failed to timely withdraw routes 196 after the PrefixLimit is revised downward), the peer is in violation, 197 and the sending speaker MAY take corrective action. The router MAY 198 also allow the received prefix count to exceed the PrefixLimit by 199 some amount as a matter of local policy. 201 Corrective actions MAY include dropping the BGP session or refusing 202 to accept new prefixes in excess of the PrefixLimit. 204 If the former option -- dropping the BGP session -- is chosen, the 205 router MUST indicate this in advance by advertising its PrefixLimit 206 ORF with the Match flag set to DENY. Also, by default it SHOULD NOT 207 automatically reestablish the session. 209 If the latter option -- refusing to accept new prefixes -- is chosen, 210 the router MUST accept modifications to already-accepted prefixes, 211 and it MUST accept withdrawals of already-accepted prefixes. If 212 prefixes are withdrawn, the received prefix count will drop below the 213 announced PrefixLimit and new prefixes SHOULD be accepted, again up 214 to but not exceeding the limit. Prefixes which are refused MUST NOT 215 contribute to the received prefix count. 217 We note that the option of refusing to accept new prefixes will 218 likely lead to desynchronization of the BGP session and is a flawed 219 solution at best; operator intervention will be required in order to 220 restore synchronization (for example, through correction of routing 221 policies and a subsequent route-refresh). 223 6.2. Rules for Receiving Speaker 225 When a PrefixLimit ORF is received, the new Prefix Limit value in the 226 ORF is considered to be the new maximum Prefix Limit for the 227 neighbor. In this section, when we refer to "the PrefixLimit" we are 228 referring to the PrefixLimit value most recently received from the 229 sending speaker by the receiving speaker. 231 If Match field is set to DENY the advertised Prefix-Limit value is 232 purely informational and the receiving speaker SHOULD advertise the 233 prefix even if doing so would cause its advertised prefix count to 234 exceed the Prefix-Limit. 236 Else, if Match field is set to PERMIT, the receiving speaker MUST NOT 237 advertise a prefix to its peer if doing so would cause its advertised 238 prefix count to exceed the PrefixLimit. 240 The receiving speaker MAY take local action when its advertised 241 prefix count approaches or reaches the PrefixLimit. The nature of 242 the action (logging, incrementing counters, etc) is a matter of local 243 policy, as is the threshold at which the action occurs. 245 When the receiving speaker receives a PrefixLimit ORF with When-to- 246 Refresh set to DEFER, it need not take any additional action unless 247 its current advertised prefix count exceeds the new PrefixLimit. In 248 that case, it MUST take immediate steps to correct the violation. 250 Such steps MAY include withdrawing already-advertised prefixes so as 251 to reduce the advertised prefix count to be less than or equal to the 252 PrefixLimit. The selection of which prefixes to withdraw is a matter 253 of local policy. Another option to correct the violation would be to 254 drop the session; in this case the session SHOULD NOT be 255 automatically reestablished. 257 When the receiving speaker receives a PrefixLimit ORF with When-to- 258 Refresh set to IMMEDIATE, it behaves as given for DEFER but in 259 addition advertises its Adj-RIB-Out as specified in [RFC5291]. 261 7. Error handling 263 ORFs provide information that guides future sending, but any 264 malformed ORF is simply missed filtering information. If Prefix 265 Limit ORF is malformed, then the Refresh messages shall simply be 266 discarded. 268 8. Security Considerations 270 This extension to BGP does not change the underlying security issues. 271 However, it does suggest a mechanism by which certain denial of 272 service risks may be reduced. 274 9. Acknowledgements 276 The authors would like to thank ... for their valuable comments. 278 10. IANA Considerations 280 IANA is requested to assign value TBD (PrefixLimit ORF) in the "BGP 281 Outbound Route Filtering (ORF) Types" subregistry under the "Border 282 Gateway Protocol (BGP) Parameters" registry. 284 11. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, 288 DOI 10.17487/RFC2119, March 1997, 289 . 291 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 292 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 293 August 2008, . 295 Authors' Addresses 297 Marco Marzetti 298 PCCW Global 299 Via Palma il Vecchio, 55 300 Chiuduno, BG 24060 301 Italy 303 Email: mmarzetti@pccwglobal.com 305 Keyur Patel 306 Arrcus, Inc 308 Email: keyur@arrcus.com 310 John Scudder 311 Juniper Networks 313 Email: jgs@juniper.net 315 Jakob Heitz 316 Cisco 317 170 W. Tasman Drive 318 San Jose, CA 95124 320 Email: jheitz@cisco.com 321 Job Snijders 322 NTT Communications 323 Theodorus Majofskistraat 100 324 Amsterdam 1065 SZ 325 The Netherlands 327 Email: job@ntt.net