idnits 2.17.1 draft-ietf-idr-route-filter-12.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 33. -- Found old boilerplate from RFC 3978, Section 5.5 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 443. ** 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 11 longer pages, the longest (page 2) being 61 lines 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 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) == Unused Reference: 'BGP-4' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'BGP-MP' is defined on line 472, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. 'BGP-4') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2842 (ref. 'BGP-CAP') (Obsoleted by RFC 3392) == Outdated reference: A later version (-09) exists of draft-ramachandra-bgp-ext-communities-02 -- Possible downref: Normative reference to a draft: ref. 'BGP-EXT-COMMUNITIES' Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Enke Chen 2 Internet Draft Cisco Systems 3 Expiration Date: January 2006 Yakov Rekhter 4 Juniper Networks 6 Cooperative Route Filtering Capability for BGP-4 8 draft-ietf-idr-route-filter-12.txt 10 Status of this Memo 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress". 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 IPR Disclosure Acknowledgement 30 By submitting this Internet-Draft, each author represents that any 31 applicable patent or other IPR claims of which he or she is aware 32 have been or will be disclosed, and any of which he or she becomes 33 aware will be disclosed, in accordance with Section 6 of BCP 79. 35 Abstract 37 This document defines a BGP-based mechanism that allows a BGP speaker 38 to send to its BGP peer a set of route filters that the peer would 39 use to constrain/filter its outbound routing updates to the speaker. 41 1. Specification of Requirements 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC2119 [RFC2119]. 47 2. Introduction 49 Currently it is not uncommon for a BGP speaker to receive, and then 50 filter out some unwanted routes from its peers based on its local 51 routing policy. Since the generation and transmission of routing 52 updates by the sender, as well as the processing of routing updates 53 by the receiver consume resources, it may be beneficial if the 54 generation of such unwanted routing updates can be avoided in the 55 first place. 57 This document defines a BGP-based mechanism that allows a BGP speaker 58 to send to its BGP peer a set of Outbound Route Filters (ORFs). The 59 peer would then apply these filters, in addition to its locally 60 configured outbound filters (if any), to constrain/filter its 61 outbound routing updates to the speaker. 63 3. Outbound Route Filter (ORF) 65 Conceptually an ORF entry is a tuple of the form ; an ORF consists of one or more ORF entries 67 that have a common AFI/SAFI and ORF-Type. An ORF is identified by 68 . 70 The "AFI/SAFI" component provides a coarse granularity control by 71 limiting the ORF to only the routes whose NLRI matches the "AFI/SAFI" 72 component of the ORF. 74 The "ORF-Type" component determines the content of the ORF-value. 76 The "Action" component controls handling of the ORF Request by the 77 remote peer. Action can be one of ADD, REMOVE, REMOVE-ALL. ADD adds 78 an ORF entry to the ORF on the remote peer; REMOVE deletes a 79 previously installed ORF entry on the remote peer; REMOVE-ALL deletes 80 the previously installed entries in the specified ORF on the remote 81 peer. 83 The "Match" component is used if support matching granularity on a 84 per ORF entry basis is needed, in which case the "Match" component 85 can be one of PERMIT or DENY. The semantics of PERMIT is to ask the 86 peer to pass updates for the set of routes that match the ORF entry. 87 The semantics of DENY is to ask the peer not to pass updates for the 88 set of routes that match the ORF entry. 90 3.1. Communities ORF-Type 92 The Community ORF-Type allows to express ORFs in terms of BGP 93 Communities [BGP-COMMUNITIES]. That is, the Communities ORF-Type 94 provides Communities-based route filtering. 96 Conceptually the ORF-value of the Communities ORF-Type consists of a 97 single Community. 99 The sender SHOULD set the value of the Match field to PERMIT; the 100 receiver SHOULD ignore the value of the Match field. 102 The remote peer should consider only those routes whose Communities 103 attribute has at least one Community in common with the Communities 104 list specified in the ORF. 106 3.2. Extended Communities ORF-Type 108 The Extended Community ORF-Type allows to express ORFs in terms of 109 BGP Extended Communities [BGP-EXT-COMMUNITIES]. That is, the Extended 110 Communities ORF-Type provides Extended Communities-based route 111 filtering. 113 Conceptually the ORF-value of the Extended Communities ORF-Type 114 consists of a single Extended Community. 116 The sender SHOULD set the value of the Match field to PERMIT; the 117 receiver SHOULD ignore the value of the Match field. 119 The remote peer should consider only those routes whose Extended 120 Communities attribute has at least one Extended Community in common 121 with the Extended Communities list specified in the ORF. 123 4. Carrying ORF entries in BGP 125 ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR]. 127 A BGP speaker can distinguish an incoming ROUTE-REFRESH message that 128 carries one or more ORF entries from an incoming plain ROUTE-REFRESH 129 message by using the Message Length field in the BGP message header. 131 A single ROUTE-REFRESH message could carry multiple ORF entries, as 132 long as all these entries share the same AFI/SAFI. 134 From the encoding point of view each ORF entry consists of a common 135 part and type-specific part. 137 The common part consists of , and 138 is encoded as follows: 140 The AFI/SAFI component of an ORF entry is encoded in the AFI/SAFI 141 field of the ROUTE-REFRESH message. 143 Following the AFI/SAFI component is the one-octet When-to-refresh 144 field. The value of this field can be one of IMMEDIATE (0x01) or 145 DEFER (0x02). The semantics of IMMEDIATE and DEFER are discussed 146 in the "Operation" section of this document. 148 Following the When-to-refresh field is a collection of one or more 149 ORFs, grouped by ORF-Type. 151 The ORF-Type component is encoded as a one-octet field. 153 The Length of ORFs component is a two-octets field that contains 154 the length (in octets) of the ORF entries that follows. 156 +--------------------------------------------------+ 157 | Address Family Identifier (2 octets) | 158 +--------------------------------------------------+ 159 | Reserved (1 octet) | 160 +--------------------------------------------------+ 161 | Subsequent Address Family Identifier (1 octet) | 162 +--------------------------------------------------+ 163 | When-to-refresh (1 octet) | 164 +--------------------------------------------------+ 165 | ORF Type (1 octet) | 166 +--------------------------------------------------+ 167 | Length of ORFs (2 octets) | 168 +--------------------------------------------------+ 169 | First ORF entry (variable) | 170 +--------------------------------------------------+ 171 | Second ORF entry (variable) | 172 +--------------------------------------------------+ 173 ......... 174 +--------------------------------------------------+ 175 | N-th ORF entry (variable) | 176 +--------------------------------------------------+ 177 | ORF Type (1 octet) | 178 +--------------------------------------------------+ 179 | Length of ORFs (2 octets) | 180 +--------------------------------------------------+ 181 | First ORF entry (variable) | 182 +--------------------------------------------------+ 183 | Second ORF entry (variable) | 184 +--------------------------------------------------+ 185 ......... 186 +--------------------------------------------------+ 187 | N-th ORF entry (variable) | 188 +--------------------------------------------------+ 189 ......... 191 Fig 1. Carrying ORF entries in the ROUTE-REFRESH message 193 The rest of the components in the common part are encoded in first 194 octet of each ORF-entry as follows (from the most significant to the 195 least significant bit): 197 Action is a two-bit field. The value of this field is 0 for ADD, 1 198 for REMOVE, and 2 for REMOVE-ALL. 200 Match is a one-bit field. The value of this field is 0 for PERMIT 201 and 1 for DENY. This field is significant only when the value of 202 the Action field is either ADD or REMOVE. 204 Reserved is a 5-bit field. It is set to 0 on transmit and ignored 205 on receive. 207 +---------------------------------+ 208 | Action (2 bit) | 209 +---------------------------------+ 210 | Match (1 bit) | 211 +---------------------------------+ 212 | Reserved (5 bits) | 213 +---------------------------------+ 214 | Type specific part (variable) | 215 +---------------------------------+ 216 Fig 2. ORF entry encoding 218 When the Action component of an ORF entry specifies REMOVE-ALL, 219 the entry consists of only the common part. 221 4.1. Type specific encoding (Communities ORF-Type) 223 The value of the ORF-Type for the Communities ORF-Type is 2. 225 The type-specific part of Communities ORF-Type consists of single 226 Community encoded as a four-octets field. 228 4.2. Type specific encoding (Extended Communities ORF-Type) 230 The value of the ORF-Type for the Extended Communities ORF-Type is 3. 232 The type-specific part of Extended Communities ORF-Type consists of a 233 single Extended Community encoded as an eight-octets field. 235 5. Cooperative Route Filtering Capability 237 A BGP speaker that is willing to receive ORF entries from its peer, 238 or a BGP speaker that would like to send ORF entries to its peer 239 advertises this to the peer by using the Cooperative Route Filtering 240 Capability, as described below. 242 The Cooperative Route Filtering Capability is a new BGP capability 243 [BGP-CAP] defined as follows: 245 Capability code: 3 247 Capability length: variable 249 Capability value: one or more of the following entries: 251 +--------------------------------------------------+ 252 | Address Family Identifier (2 octets) | 253 +--------------------------------------------------+ 254 | Reserved (1 octet) | 255 +--------------------------------------------------+ 256 | Subsequent Address Family Identifier (1 octet) | 257 +--------------------------------------------------+ 258 | Number of ORFs (1 octet) | 259 +--------------------------------------------------+ 260 | ORF Type (1 octet) | 261 +--------------------------------------------------+ 262 | Send/Receive (1 octet) | 263 +--------------------------------------------------+ 264 | ... | 265 +--------------------------------------------------+ 266 | ORF Type (1 octet) | 267 +--------------------------------------------------+ 268 | Send/Receive (1 octet) | 269 +--------------------------------------------------+ 271 Fig 4. Capability encoding 273 The use and meaning of these fields are as follows: 275 Address Family Identifier (AFI): 277 This field carries the identity of the Network Layer protocol 278 associated with the Network Address that follows. Presently 279 defined values for this field are specified in RFC1700 (see the 280 Address Family Numbers section). 282 Subsequent Address Family Identifier (SAFI): 284 This field provides additional information about the type of 285 the Network Layer Reachability Information carried in the 286 attribute. 288 Number of ORF Types: 290 This field contains the number of Filter Types to be listed in 291 the following fields. 293 ORF Type: 295 This field contains the value of an ORF Type. 297 Send/Receive: 299 This field indicates whether the sender is (a) willing to 300 receive ORF entries from its peer (value 1), (b) would like to 301 send ORF entries to its peer (value 2), or (c) both (value 3) 302 for the ORF Type that follows. 304 6. Operation 306 A BGP speaker that is willing to receive ORF entries from its peer, 307 or would like to send ORF entries to its peer SHOULD advertise the 308 Cooperative Route Filtering Capability to the peer using BGP 309 Capabilities advertisement [BGP-CAP]. 311 A BGP speaker that implements the Cooperative Route Filtering 312 Capability must support BGP ROUTE-REFRESH message, as defined in 313 [BGP-RR]. A BGP speaker that advertises the Cooperative Route 314 Filtering Capability to a peer using BGP Capabilities advertisement 315 [BGP-CAP] doesn't have to advertise the BGP Route Refresh capability 316 to that peer. 318 Consider a BGP speaker that advertises the Cooperative Route 319 Filtering Capability indicating its willingness to receive a 320 particular set of from its peer, and that 321 receives the Cooperative Route Filtering Capability indicating the 322 desire of the peer to send a particular set to 323 the speaker. If for a given the intersection between 324 these two sets are not-empty, the speaker SHOULD NOT advertise to the 325 peer any routes with that prior to receiving from the 326 peer any ROUTE-REFRESH message carrying that , where the 327 message could be either without any ORF entries, or with one or more 328 ORF entry and When-to-refresh field set to IMMEDIATE. If, on the 329 other hand, for a given the intersection between these 330 two sets is empty, the speaker SHOULD follow normal BGP procedures. 332 A BGP speaker may send a ROUTE-REFRESH message with one or more ORF 333 entries to its peer only if the peer advertises to the speaker the 334 Cooperative Route Filtering Capability indicating its willingness to 335 receive ORF entries from the speaker, and the speaker advertises to 336 the peer the Cooperative Route Filtering Capability indicating its 337 desire to send ORF entries to the peer. The message may contain only 338 ORF entries of that the peer is willing to 339 receive, as advertised to the speaker in the Cooperative Route 340 Filtering Capability. 342 When a BGP speaker receives a ROUTE-REFRESH message with one or more 343 ORF entries from its peer, then the speaker performs the following 344 actions. If the carried by the message doesn't 345 match that the speaker is willing to receive 346 from the peer (as advertised to the peer in the Cooperative Route 347 Filtering Capability), the specified ORF is ignored. Otherwise, the 348 speaker modifies the specified ORF, as specified in the ORF entries 349 carried by the message. If any of the fields within an ORF entry 350 contain an unrecognized value, the whole specified ORF is removed. 352 If the Action component of an ORF entry is REMOVE, but the ORF 353 doesn't contain the specified entry, the entry is ignored. 355 ORF entries with either REMOVE or REMOVE-ALL can not remove locally 356 configured outbound route filters. 358 If the When-to-Refresh indicates IMMEDIATE, then after processing all 359 the ORF entries carried in the message the speaker re-advertises to 360 the peer routes from the Adj-RIB-Out associated with the peer that 361 have the same AFI/SAFI as what is carried in the message, and taking 362 into account all the ORF entries received from the peer. However, 363 the routes that have not be affected by the ORF entries carried in 364 the message SHOULT NOT be re-advertised to the peer. 366 If the When-to-Refresh indicates DEFER, then after processing all the 367 ORF entries carried in the message the speaker defers re- 368 advertisement to the peer routes from the Adj-RIB-Out associated with 369 the peer that have the same AFI/SAFI as what is carried in the 370 message, and taking into account all the ORF entries received from 371 the peer until the speaker receives a subsequent ROUTE-REFRESH 372 message for the same AFI/SAFI either without any ORF entries, or with 373 one or more ORF entries and When-to-refresh set to IMMEDIATE. 375 If the speaker receives from the peer a ROUTE-REFRESH message without 376 any ORF entries, then the speaker sends to the peer all routes from 377 the Adj-RIB-Out associated with the peer whose AFI/SAFI is the same 378 as what is carried in the message and taking into account the ORF 379 received from the peer. 381 The set of ORF entries that the speaker sends to the peer expresses 382 the speaker's local preference, that the peer may or may not decide 383 to honor. 385 During a single BGP session the speaker may pass multiple ORF entries 386 to the peer. 388 The lifetime of an ORF is the duration of the BGP session during 389 which the ORF is exchanged. 391 An ORF is removed when the last ORF entry is remove (either via 392 REMOVE-ALL, or via a sequence of REMOVE). 394 If a particular route maintained by a BGP speaker doesn't match any 395 of the ORF entries of any of the (non-empty) ORFs associated with a 396 particular peer, then this route SHOULD NOT be advertised to the 397 peer. 399 If a BGP speaker maintains multiple ORFs of different ORF-Types for a 400 particular peer, then the decision by the speaker to advertise a 401 route to the peer is determined by passing the route through each 402 such ORF, and and-ing the results (and-ing of PERMIT and DENY results 403 in DENY). 405 7. IANA Considerations 407 As specified in this document, an ORF enty contains the ORF-Type 408 field. ORF-Type value 0 is reserved. ORF-Type values 1 through 63 409 are to be assigned by IANA using the "IETF Consensus" policy defined 410 in RFC2434. ORF-Type values 64 through 127 are to be assigned by 411 IANA, using the "First Come First Served" policy defined in RFC2434. 412 ORF-Type values 128 through 255 are vendor-specific, and values in 413 this range are not to be assigned by IANA. 415 8. Security Considerations 417 This extension to BGP does not change the underlying security issues. 419 9. Intellectual Property Considerations 421 This section is taken from Section 5 of RFC 3668. 423 The IETF takes no position regarding the validity or scope of any 424 Intellectual Property Rights or other rights that might be claimed to 425 pertain to the implementation or use of the technology described in 426 this document or the extent to which any license under such rights 427 might or might not be available; nor does it represent that it has 428 made any independent effort to identify any such rights. Information 429 on the procedures with respect to rights in RFC documents can be 430 found in BCP 78 and BCP 79. 432 Copies of IPR disclosures made to the IETF Secretariat and any 433 assurances of licenses to be made available, or the result of an 434 attempt made to obtain a general license or permission for the use of 435 such proprietary rights by implementers or users of this 436 specification can be obtained from the IETF on-line IPR repository at 437 http://www.ietf.org/ipr. 439 The IETF invites any interested party to bring to its attention any 440 copyrights, patents or patent applications, or other proprietary 441 rights that may cover technology that may be required to implement 442 this standard. Please address the information to the IETF at ietf- 443 ipr@ietf.org. 445 10. Copyright Notice 447 Copyright (C) The Internet Society (2005). 449 This document is subject to the rights, licenses and restrictions 450 contained in BCP 78, and except as set forth therein, the authors 451 retain all their rights. 453 This document and the information contained herein are provided on an 454 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 455 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 456 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 457 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 458 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 11. Acknowledgements 463 Some of the material in the document is "borrowed" from a proposal 464 for selective updates by Yakov Rekhter, Kannan Varadhan, and Curtis 465 Villamizar. 467 12. Normative References 469 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 470 (BGP-4)", RFC 1771, March 1995. 472 [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., 473 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 475 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 476 BGP-4", RFC2842, May 2000 478 [BGP-COMMUNITIES] Chandra, R., Traina, P., and Li, T., "BGP 479 Communities Attribute", RFC1997, August 1996. 481 [BGP-EXT-COMMUNITIES] Ramachandra, S., Tappan, D., "BGP Extended 482 Communities Attribute", draft-ramachandra-bgp-ext-communities-02.txt 484 [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, 485 September 2000 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 13. Author Information 492 Enke Chen 493 Cisco Systems, Inc. 494 e-mail: enkechen@cisco.com 496 Yakov Rekhter 497 Juniper Networks 498 e-mail: yakov@juniper.net