idnits 2.17.1 draft-ietf-idr-route-filter-16.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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 419. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 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 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The set of ORF entries that the speaker sends to the peer expresses the speaker's local preference, that the peer MAY or MAY NOT decide to honor. -- 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) -- No information found for draft-ietf-idr-rfc1858bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BGP-MP' ** Obsolete normative reference: RFC 3392 (ref. 'BGP-CAP') (Obsoleted by RFC 5492) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Chen 3 Internet Draft Cisco Systems 4 Expiration Date: March 2007 Y. Rekhter 5 Juniper Networks 7 Outbound Route Filtering Capability for BGP-4 9 draft-ietf-idr-route-filter-16.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document defines a BGP-based mechanism that allows a BGP speaker 37 to send to its BGP peer a set of route filters that the peer would 38 use to constrain/filter its outbound routing updates to the speaker. 40 1. Specification of Requirements 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC 2119 [RFC-2119]. 46 2. Introduction 48 Currently it is not uncommon for a BGP speaker [BGP-4] to receive, 49 and then filter out some unwanted routes from its peers based on its 50 local routing policy. Since the generation and transmission of 51 routing updates by the sender, as well as the processing of routing 52 updates by the receiver consume resources, it may be beneficial if 53 the generation of such unwanted routing updates can be avoided in the 54 first place. 56 This document defines a BGP-based mechanism that allows a BGP speaker 57 to send to its BGP peer a set of Outbound Route Filters (ORFs). The 58 peer would then apply these filters, in addition to its locally 59 configured outbound filters (if any), to constrain/filter its 60 outbound routing updates to the speaker. 62 3. Outbound Route Filter (ORF) 64 This document uses the terms "Address Family Identifier (AFI)" and 65 "Subsequent Address Family Identifier (SAFI)". In the context of this 66 document the meaning of these terms is the same as in [BGP-MP]. 68 Conceptually an ORF entry is a tuple of the form ; an ORF consists of one or more ORF entries 70 that have a common AFI/SAFI and ORF-Type. An ORF is identified by 71 . 73 The "AFI/SAFI" component provides a coarse granularity control by 74 limiting the ORF to only the routes whose NLRI matches the "AFI/SAFI" 75 component of the ORF. 77 The "ORF-Type" component determines the content of the ORF-value. 79 The "Action" component controls handling of the ORF Request by the 80 remote peer. Action can be one of ADD, REMOVE, REMOVE-ALL. ADD adds 81 an ORF entry to the ORF on the remote peer; REMOVE deletes a 82 previously installed ORF entry on the remote peer; REMOVE-ALL deletes 83 the previously installed entries in the specified ORF on the remote 84 peer. 86 The "Match" component is used if support matching granularity on a 87 per ORF entry basis is needed, in which case the "Match" component 88 can be one of PERMIT or DENY. The semantics of PERMIT is to ask the 89 peer to pass updates for the set of routes that match the ORF entry. 90 The semantics of DENY is to ask the peer not to pass updates for the 91 set of routes that match the ORF entry. 93 4. Carrying ORF Entries in BGP 95 ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR]. 97 A BGP speaker can distinguish an incoming ROUTE-REFRESH message that 98 carries one or more ORF entries from an incoming plain ROUTE-REFRESH 99 message by using the Message Length field in the BGP message header. 101 A single ROUTE-REFRESH message MAY carry multiple ORF entries, as 102 long as all these entries share the same AFI/SAFI. 104 From the encoding point of view each ORF entry consists of a common 105 part and type-specific part as shown in Figure 1. 107 The common part consists of , and 108 is encoded as follows: 110 The AFI/SAFI component of an ORF entry is encoded in the AFI/SAFI 111 field of the ROUTE-REFRESH message. 113 Following the AFI/SAFI component is the one-octet When-to-refresh 114 field. The value of this field can be one of IMMEDIATE (0x01) or 115 DEFER (0x02). The semantics of IMMEDIATE and DEFER are discussed 116 in the "Operation" section of this document. 118 Following the When-to-refresh field is a collection of one or more 119 ORFs, grouped by ORF-Type. 121 The ORF-Type component is encoded as a one-octet field. 123 The Length of ORFs component is a two-octets field that contains 124 the length (in octets) of the ORF entries that follows. 126 +--------------------------------------------------+ 127 | Address Family Identifier (2 octets) | 128 +--------------------------------------------------+ 129 | Reserved (1 octet) | 130 +--------------------------------------------------+ 131 | Subsequent Address Family Identifier (1 octet) | 132 +--------------------------------------------------+ 133 | When-to-refresh (1 octet) | 134 +--------------------------------------------------+ 135 | ORF Type (1 octet) | 136 +--------------------------------------------------+ 137 | Length of ORFs (2 octets) | 138 +--------------------------------------------------+ 139 | First ORF entry (variable) | 140 +--------------------------------------------------+ 141 | Second ORF entry (variable) | 142 +--------------------------------------------------+ 143 | ... | 144 +--------------------------------------------------+ 145 | N-th ORF entry (variable) | 146 +--------------------------------------------------+ 147 | ORF Type (1 octet) | 148 +--------------------------------------------------+ 149 | Length of ORFs (2 octets) | 150 +--------------------------------------------------+ 151 | First ORF entry (variable) | 152 +--------------------------------------------------+ 153 | Second ORF entry (variable) | 154 +--------------------------------------------------+ 155 | ... | 156 +--------------------------------------------------+ 157 | N-th ORF entry (variable) | 158 +--------------------------------------------------+ 159 | ... | 160 +--------------------------------------------------+ 162 Figure 1: Carrying ORF Entries in the ROUTE-REFRESH Message 164 The rest of the components in the common part are encoded in the 165 first octet of each ORF-entry (from the most significant to the least 166 significant bit) as shown in Figure 2: 168 Action is a two-bit field. The value of this field is 0 for ADD, 1 169 for REMOVE, and 2 for REMOVE-ALL. 171 Match is a one-bit field. The value of this field is 0 for PERMIT 172 and 1 for DENY. This field is significant only when the value of 173 the Action field is either ADD or REMOVE. 175 Reserved is a 5-bit field. It is set to 0 on transmit and ignored 176 on receive. 178 +---------------------------------+ 179 | Action (2 bit) | 180 +---------------------------------+ 181 | Match (1 bit) | 182 +---------------------------------+ 183 | Reserved (5 bits) | 184 +---------------------------------+ 185 | Type specific part (variable) | 186 +---------------------------------+ 188 Figure 2: ORF Entry Encoding 190 When the Action component of an ORF entry specifies REMOVE-ALL, 191 the entry consists of only the common part. 193 5. Outbound Route Filtering Capability 195 A BGP speaker that is willing to receive ORF entries from its peer, 196 or a BGP speaker that would like to send ORF entries to its peer 197 advertises this to the peer by using the Outbound Route Filtering 198 Capability, as described below. 200 The Outbound Route Filtering Capability is a new BGP capability 201 [BGP-CAP] defined as follows: 203 Capability code: 3 205 Capability length: variable 207 Capability value: one or more of the entries as shown in Figure 3. 209 +--------------------------------------------------+ 210 | Address Family Identifier (2 octets) | 211 +--------------------------------------------------+ 212 | Reserved (1 octet) | 213 +--------------------------------------------------+ 214 | Subsequent Address Family Identifier (1 octet) | 215 +--------------------------------------------------+ 216 | Number of ORFs (1 octet) | 217 +--------------------------------------------------+ 218 | ORF Type (1 octet) | 219 +--------------------------------------------------+ 220 | Send/Receive (1 octet) | 221 +--------------------------------------------------+ 222 | ... | 223 +--------------------------------------------------+ 224 | ORF Type (1 octet) | 225 +--------------------------------------------------+ 226 | Send/Receive (1 octet) | 227 +--------------------------------------------------+ 229 Figure 3: Outbound Route Filtering Capability Encoding 231 The use and meaning of these fields are as follows: 233 Address Family Identifier (AFI): 235 This field is the same as the one used in [BGP-MP]. 237 Subsequent Address Family Identifier (SAFI): 239 This field is the same as the one used in [BGP-MP]. 241 Number of ORF Types: 243 This field contains the number of Filter Types to be listed in 244 the following fields. 246 ORF Type: 248 This field contains the value of an ORF Type. 250 Send/Receive: 252 This field indicates whether the sender is (a) willing to 253 receive ORF entries from its peer (value 1), (b) would like to 254 send ORF entries to its peer (value 2), or (c) both (value 3) 255 for the ORF Type that follows. 257 6. Operation 259 A BGP speaker that is willing to receive ORF entries from its peer, 260 or would like to send ORF entries to its peer SHOULD advertise the 261 Outbound Route Filtering Capability to the peer using BGP 262 Capabilities advertisement [BGP-CAP]. 264 A BGP speaker that implements the Outbound Route Filtering Capability 265 MUST support the BGP ROUTE-REFRESH message, as defined in [BGP-RR]. A 266 BGP speaker that advertises the Outbound Route Filtering Capability 267 to a peer using BGP Capabilities advertisement [BGP-CAP] does not 268 have to advertise the BGP Route Refresh capability to that peer. 270 Consider a BGP speaker that advertises the Outbound Route Filtering 271 Capability indicating its willingness to receive a particular set of 272 from its peer, and that receives the Outbound 273 Route Filtering Capability indicating the desire of the peer to send 274 a particular set to the speaker. If for a given 275 the intersection between these two sets are not-empty, 276 the speaker SHOULD NOT advertise to the peer any routes with that 277 prior to receiving from the peer any ROUTE-REFRESH 278 message carrying that , where the message could be either 279 without any ORF entries, or with one or more ORF entry and When-to- 280 refresh field set to IMMEDIATE. If, on the other hand, for a given 281 the intersection between these two sets is empty, the 282 speaker SHOULD follow normal BGP procedures. 284 A BGP speaker may send a ROUTE-REFRESH message with one or more ORF 285 entries to its peer only if the peer advertises to the speaker the 286 Outbound Route Filtering Capability indicating its willingness to 287 receive ORF entries from the speaker, and the speaker advertises to 288 the peer the Outbound Route Filtering Capability indicating its 289 desire to send ORF entries to the peer. The message may contain only 290 ORF entries of that the peer is willing to 291 receive, as advertised to the speaker in the Outbound Route Filtering 292 Capability. 294 When a BGP speaker receives a ROUTE-REFRESH message with one or more 295 ORF entries from its peer, then the speaker performs the following 296 actions. If the carried by the message does not 297 match that the speaker is willing to receive 298 from the peer (as advertised to the peer in the Outbound Route 299 Filtering Capability), the specified ORF is ignored. Otherwise, the 300 speaker modifies the specified ORF, as specified in the ORF entries 301 carried by the message. If any of the fields within an ORF entry 302 contain an unrecognized value, the whole specified ORF is removed. 304 If the Action component of an ORF entry is REMOVE, but the ORF does 305 not contain the specified entry, the entry is ignored. 307 ORF entries with either REMOVE or REMOVE-ALL can not remove locally 308 configured outbound route filters. 310 If the When-to-refresh indicates IMMEDIATE, then after processing all 311 the ORF entries carried in the message the speaker re-advertises to 312 the peer routes from the Adj-RIB-Out associated with the peer that 313 have the same AFI/SAFI as what is carried in the message, and taking 314 into account all the ORF entries for that AFI/SAFI received from the 315 peer. The speaker MUST re-advertise all the routes that have been 316 affected by the ORF entries carried in the message, but MAY also re- 317 advertise the routes that have not been affected by the ORF entries 318 carried in the message. 320 If the When-to-refresh indicates DEFER, then after processing all the 321 ORF entries carried in the message the speaker defers re- 322 advertisement to the peer routes from the Adj-RIB-Out associated with 323 the peer that have the same AFI/SAFI as what is carried in the 324 message, and taking into account all the ORF entries received from 325 the peer until the speaker receives a subsequent ROUTE-REFRESH 326 message for the same AFI/SAFI either without any ORF entries, or with 327 one or more ORF entries and When-to-refresh set to IMMEDIATE. 329 If the speaker receives from the peer a ROUTE-REFRESH message without 330 any ORF entries, then the speaker sends to the peer all routes from 331 the Adj-RIB-Out associated with the peer whose AFI/SAFI is the same 332 as what is carried in the message and taking into account the ORF 333 received from the peer. 335 The set of ORF entries that the speaker sends to the peer expresses 336 the speaker's local preference, that the peer MAY or MAY NOT decide 337 to honor. 339 During a single BGP session the speaker MAY pass multiple ORF entries 340 to the peer. 342 After a BGP speaker makes changes to the ORF entries previously sent 343 to a peer, the speaker SHOULD send to the peer the updated ORF 344 entries with either (a) When-to-refresh set to IMMEDIATE, or (b) 345 When-to-refresh set to DEFER followed by a ROUTE-REFRESH message. The 346 latter SHALL be used by the speaker when there are other policy 347 changes (in addition to the ORF entries) that require the peer to 348 re-advertise all the routes. 350 The lifetime of an ORF is the duration of the BGP session during 351 which the ORF is exchanged. 353 An ORF is removed when the last ORF entry is removed (either via 354 REMOVE-ALL, or via a sequence of REMOVE). 356 If a particular route maintained by a BGP speaker does not match any 357 of the ORF entries of any of the (non-empty) ORFs associated with a 358 particular peer, then this route SHOULD NOT be advertised to the 359 peer. 361 If a BGP speaker maintains multiple ORFs of different ORF-Types for a 362 particular peer, then the decision by the speaker to advertise a 363 route to the peer is determined by passing the route through each 364 such ORF, and and-ing the results (and-ing of PERMIT and DENY results 365 in DENY). 367 7. IANA Considerations 369 This document defines a new BGP Capability - Outbound Route Filtering 370 Capability. The Capability Code for the Outbound Route Filtering 371 Capability is 3. 373 As specified in this document, an ORF entry contains the ORF-Type 374 field for which IANA is to create and maintain a registry entitled 375 "BGP ORF Type". 377 IANA will maintain and register values for ORF-Type field as follows: 379 - ORF-Type value 0 is reserved. 381 - ORF-Type values 1 through 63 are to be assigne dby IANA using 382 either the Standards Action process defined in RFC 2434, or the 383 Early IANA Allocation process defined in RFC 4020. 385 - ORF-Type values 64 through 127 are to be assigned by IANA, using 386 the "First Come First Served" policy defined in RFC 2434. 388 - ORF-Type values 128 through 255 are vendor-specific, and values 389 in this range are not to be assigned by IANA. 391 8. Security Considerations 393 This extension to BGP does not change the underlying security issues. 395 9. Intellectual Property Considerations 397 This section is taken from Section 5 of RFC 3668. 399 The IETF takes no position regarding the validity or scope of any 400 Intellectual Property Rights or other rights that might be claimed to 401 pertain to the implementation or use of the technology described in 402 this document or the extent to which any license under such rights 403 might or might not be available; nor does it represent that it has 404 made any independent effort to identify any such rights. Information 405 on the procedures with respect to rights in RFC documents can be 406 found in BCP 78 and BCP 79. 408 Copies of IPR disclosures made to the IETF Secretariat and any 409 assurances of licenses to be made available, or the result of an 410 attempt made to obtain a general license or permission for the use of 411 such proprietary rights by implementers or users of this 412 specification can be obtained from the IETF on-line IPR repository at 413 http://www.ietf.org/ipr. 415 The IETF invites any interested party to bring to its attention any 416 copyrights, patents or patent applications, or other proprietary 417 rights that may cover technology that may be required to implement 418 this standard. Please address the information to the IETF at ietf- 419 ipr@ietf.org. 421 10. Copyright Notice 423 Copyright (C) The Internet Society (2006). 425 This document is subject to the rights, licenses and restrictions 426 contained in BCP 78, and except as set forth therein, the authors 427 retain all their rights. 429 This document and the information contained herein are provided on an 430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 432 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 433 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 434 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 437 11. Acknowledgements 439 Some of the material in the document is adapted from a proposal for 440 selective updates by Yakov Rekhter, Kannan Varadhan, and Curtis 441 Villamizar. 443 12. Normative References 445 [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 446 4 (BGP-4)", RFC 4271, January 2006. 448 [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., 449 "Multiprotocol Extensions for BGP-4", draft-ietf-idr-rfc1858bis- 450 10.txt. 452 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 453 BGP-4", RFC 3392, November 2002. 455 [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, 456 September 2000. 458 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 459 Requirement Levels", BCP 14, RFC 2119, March 1997. 461 13. Author Information 463 Enke Chen 464 Cisco Systems, Inc. 465 170 W. Tasman Dr. 466 San Jose, CA 95134 468 Email: enkechen@cisco.com 470 Yakov Rekhter 471 Juniper Networks 472 1194 N. Mathilda Ave 473 Sunnyvale, CA 94089 475 Email: yakov@juniper.net