idnits 2.17.1 draft-ietf-idr-route-filter-11.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 3667, Section 5.1 on line 38. -- Found old boilerplate from RFC 3978, Section 5.5 on line 460. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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) == Missing Reference: 'RFC2026' is mentioned on line 426, but not defined == Unused Reference: 'BGP-4' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'BGP-MP' is defined on line 473, 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: 14 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Enke Chen 3 Internet Draft Cisco Systems 4 Expiration Date: June 2005 Yakov Rekhter 5 Juniper Networks 7 Cooperative Route Filtering Capability for BGP-4 9 draft-ietf-idr-route-filter-11.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 except that the right to 15 produce derivative works is not granted. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 IPR Disclosure Acknowledgement 35 By submitting this Internet-Draft, I certify that any applicable 36 patent or other IPR claims of which I am aware have been disclosed, 37 and any of which I become aware will be disclosed, in accordance with 38 RFC 3668. 40 Abstract 42 This document defines a BGP-based mechanism that allows a BGP speaker 43 to send to its BGP peer a set of route filters that the peer would 44 use to constrain/filter its outbound routing updates to the speaker. 46 1. Specification of Requirements 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC2119 [RFC2119]. 52 2. Introduction 54 Currently it is not uncommon for a BGP speaker to receive, and then 55 filter out some unwanted routes from its peers based on its local 56 routing policy. Since the generation and transmission of routing 57 updates by the sender, as well as the processing of routing updates 58 by the receiver consume resources, it may be beneficial if the 59 generation of such unwanted routing updates can be avoided in the 60 first place. 62 This document defines a BGP-based mechanism that allows a BGP speaker 63 to send to its BGP peer a set of Outbound Route Filters (ORFs). The 64 peer would then apply these filters, in addition to its locally 65 configured outbound filters (if any), to constrain/filter its 66 outbound routing updates to the speaker. 68 3. Outbound Route Filter (ORF) 70 Conceptually an ORF entry is a tuple of the form ; an ORF consists of one or more ORF entries 72 that have a common AFI/SAFI and ORF-Type. An ORF is identified by 73 . 75 The "AFI/SAFI" component provides a coarse granularity control by 76 limiting the ORF to only the routes whose NLRI matches the "AFI/SAFI" 77 component of the ORF. 79 The "ORF-Type" component determines the content of the ORF-value. 81 The "Action" component controls handling of the ORF Request by the 82 remote peer. Action can be one of ADD, REMOVE, REMOVE-ALL. ADD adds 83 an ORF entry to the ORF on the remote peer; REMOVE deletes a 84 previously installed ORF entry on the remote peer; REMOVE-ALL deletes 85 the previously installed entries in the specified ORF on the remote 86 peer. 88 The "Match" component is used if support matching granularity on a 89 per ORF entry basis is needed, in which case the "Match" component 90 can be one of PERMIT or DENY. The semantics of PERMIT is to ask the 91 peer to pass updates for the set of routes that match the ORF entry. 92 The semantics of DENY is to ask the peer not to pass updates for the 93 set of routes that match the ORF entry. 95 3.1. Communities ORF-Type 97 The Community ORF-Type allows to express ORFs in terms of BGP 98 Communities [BGP-COMMUNITIES]. That is, the Communities ORF-Type 99 provides Communities-based route filtering. 101 Conceptually the ORF-value of the Communities ORF-Type consists of a 102 single Community. 104 The sender SHOULD set the value of the Match field to PERMIT; the 105 receiver SHOULD ignore the value of the Match field. 107 The remote peer should consider only those routes whose Communities 108 attribute has at least one Community in common with the Communities 109 list specified in the ORF. 111 3.2. Extended Communities ORF-Type 113 The Extended Community ORF-Type allows to express ORFs in terms of 114 BGP Extended Communities [BGP-EXT-COMMUNITIES]. That is, the Extended 115 Communities ORF-Type provides Extended Communities-based route 116 filtering. 118 Conceptually the ORF-value of the Extended Communities ORF-Type 119 consists of a single Extended Community. 121 The sender SHOULD set the value of the Match field to PERMIT; the 122 receiver SHOULD ignore the value of the Match field. 124 The remote peer should consider only those routes whose Extended 125 Communities attribute has at least one Extended Community in common 126 with the Extended Communities list specified in the ORF. 128 4. Carrying ORF entries in BGP 130 ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR]. 132 A BGP speaker can distinguish an incoming ROUTE-REFRESH message that 133 carries one or more ORF entries from an incoming plain ROUTE-REFRESH 134 message by using the Message Length field in the BGP message header. 136 A single ROUTE-REFRESH message could carry multiple ORF entries, as 137 long as all these entries share the same AFI/SAFI. 139 From the encoding point of view each ORF entry consists of a common 140 part and type-specific part. 142 The common part consists of , and 143 is encoded as follows: 145 The AFI/SAFI component of an ORF entry is encoded in the AFI/SAFI 146 field of the ROUTE-REFRESH message. 148 Following the AFI/SAFI component is the one-octet When-to-refresh 149 field. The value of this field can be one of IMMEDIATE (0x01) or 150 DEFER (0x02). The semantics of IMMEDIATE and DEFER are discussed 151 in the "Operation" section of this document. 153 Following the When-to-refresh field is a collection of one or more 154 ORFs, grouped by ORF-Type. 156 The ORF-Type component is encoded as a one-octet field. 158 The Length of ORFs component is a two-octets field that contains 159 the length (in octets) of the ORF entries that follows. 161 +--------------------------------------------------+ 162 | Address Family Identifier (2 octets) | 163 +--------------------------------------------------+ 164 | Reserved (1 octet) | 165 +--------------------------------------------------+ 166 | Subsequent Address Family Identifier (1 octet) | 167 +--------------------------------------------------+ 168 | When-to-refresh (1 octet) | 169 +--------------------------------------------------+ 170 | ORF Type (1 octet) | 171 +--------------------------------------------------+ 172 | Length of ORFs (2 octets) | 173 +--------------------------------------------------+ 174 | First ORF entry (variable) | 175 +--------------------------------------------------+ 176 | Second ORF entry (variable) | 177 +--------------------------------------------------+ 178 ......... 179 +--------------------------------------------------+ 180 | N-th ORF entry (variable) | 181 +--------------------------------------------------+ 182 | ORF Type (1 octet) | 183 +--------------------------------------------------+ 184 | Length of ORFs (2 octets) | 185 +--------------------------------------------------+ 186 | First ORF entry (variable) | 187 +--------------------------------------------------+ 188 | Second ORF entry (variable) | 189 +--------------------------------------------------+ 190 ......... 191 +--------------------------------------------------+ 192 | N-th ORF entry (variable) | 193 +--------------------------------------------------+ 194 ......... 196 Fig 1. Carrying ORF entries in the ROUTE-REFRESH message 198 The rest of the components in the common part are encoded in first 199 octet of each ORF-entry as follows (from the most significant to the 200 least significant bit): 202 Action is a two-bit field. The value of this field is 0 for ADD, 1 203 for REMOVE, and 2 for REMOVE-ALL. 205 Match is a one-bit field. The value of this field is 0 for PERMIT 206 and 1 for DENY. This field is significant only when the value of 207 the Action field is either ADD or REMOVE. 209 Reserved is a 5-bit field. It is set to 0 on transmit and ignored 210 on receive. 212 +---------------------------------+ 213 | Action (2 bit) | 214 +---------------------------------+ 215 | Match (1 bit) | 216 +---------------------------------+ 217 | Reserved (5 bits) | 218 +---------------------------------+ 219 | Type specific part (variable) | 220 +---------------------------------+ 221 Fig 2. ORF entry encoding 223 When the Action component of an ORF entry specifies REMOVE-ALL, 224 the entry consists of only the common part. 226 4.1. Type specific encoding (Communities ORF-Type) 228 The value of the ORF-Type for the Communities ORF-Type is 2. 230 The type-specific part of Communities ORF-Type consists of single 231 Community encoded as a four-octets field. 233 4.2. Type specific encoding (Extended Communities ORF-Type) 235 The value of the ORF-Type for the Extended Communities ORF-Type is 3. 237 The type-specific part of Extended Communities ORF-Type consists of a 238 single Extended Community encoded as an eight-octets field. 240 5. Cooperative Route Filtering Capability 242 A BGP speaker that is willing to receive ORF entries from its peer, 243 or a BGP speaker that would like to send ORF entries to its peer 244 advertises this to the peer by using the Cooperative Route Filtering 245 Capability, as described below. 247 The Cooperative Route Filtering Capability is a new BGP capability 248 [BGP-CAP] defined as follows: 250 Capability code: 3 252 Capability length: variable 254 Capability value: one or more of the following entries: 256 +--------------------------------------------------+ 257 | Address Family Identifier (2 octets) | 258 +--------------------------------------------------+ 259 | Reserved (1 octet) | 260 +--------------------------------------------------+ 261 | Subsequent Address Family Identifier (1 octet) | 262 +--------------------------------------------------+ 263 | Number of ORFs (1 octet) | 264 +--------------------------------------------------+ 265 | ORF Type (1 octet) | 266 +--------------------------------------------------+ 267 | Send/Receive (1 octet) | 268 +--------------------------------------------------+ 269 | ... | 270 +--------------------------------------------------+ 271 | ORF Type (1 octet) | 272 +--------------------------------------------------+ 273 | Send/Receive (1 octet) | 274 +--------------------------------------------------+ 276 Fig 4. Capability encoding 278 The use and meaning of these fields are as follows: 280 Address Family Identifier (AFI): 282 This field carries the identity of the Network Layer protocol 283 associated with the Network Address that follows. Presently 284 defined values for this field are specified in RFC1700 (see the 285 Address Family Numbers section). 287 Subsequent Address Family Identifier (SAFI): 289 This field provides additional information about the type of 290 the Network Layer Reachability Information carried in the 291 attribute. 293 Number of ORF Types: 295 This field contains the number of Filter Types to be listed in 296 the following fields. 298 ORF Type: 300 This field contains the value of an ORF Type. 302 Send/Receive: 304 This field indicates whether the sender is (a) willing to 305 receive ORF entries from its peer (value 1), (b) would like to 306 send ORF entries to its peer (value 2), or (c) both (value 3) 307 for the ORF Type that follows. 309 6. Operation 311 A BGP speaker that is willing to receive ORF entries from its peer, 312 or would like to send ORF entries to its peer SHOULD advertise the 313 Cooperative Route Filtering Capability to the peer using BGP 314 Capabilities advertisement [BGP-CAP]. 316 A BGP speaker that implements the Cooperative Route Filtering 317 Capability must support BGP ROUTE-REFRESH message, as defined in 318 [BGP-RR]. A BGP speaker that advertises the Cooperative Route 319 Filtering Capability to a peer using BGP Capabilities advertisement 320 [BGP-CAP] doesn't have to advertise the BGP Route Refresh capability 321 to that peer. 323 Consider a BGP speaker that advertises the Cooperative Route 324 Filtering Capability indicating its willingness to receive a 325 particular set of from its peer, and that 326 receives the Cooperative Route Filtering Capability indicating the 327 desire of the peer to send a particular set to 328 the speaker. If for a given the intersection between 329 these two sets are not-empty, the speaker SHOULD NOT advertise to the 330 peer any routes with that prior to receiving from the 331 peer any ROUTE-REFRESH message carrying that , where the 332 message could be either without any ORF entries, or with one or more 333 ORF entry and When-to-refresh field set to IMMEDIATE. If, on the 334 other hand, for a given the intersection between these 335 two sets is empty, the speaker SHOULD follow normal BGP procedures. 337 A BGP speaker may send a ROUTE-REFRESH message with one or more ORF 338 entries to its peer only if the peer advertises to the speaker the 339 Cooperative Route Filtering Capability indicating its willingness to 340 receive ORF entries from the speaker, and the speaker advertises to 341 the peer the Cooperative Route Filtering Capability indicating its 342 desire to send ORF entries to the peer. The message may contain only 343 ORF entries of that the peer is willing to 344 receive, as advertised to the speaker in the Cooperative Route 345 Filtering Capability. 347 When a BGP speaker receives a ROUTE-REFRESH message with one or more 348 ORF entries from its peer, then the speaker performs the following 349 actions. If the carried by the message doesn't 350 match that the speaker is willing to receive 351 from the peer (as advertised to the peer in the Cooperative Route 352 Filtering Capability), the specified ORF is ignored. Otherwise, the 353 speaker modifies the specified ORF, as specified in the ORF entries 354 carried by the message. If any of the fields within an ORF entry 355 contain an unrecognized value, the whole specified ORF is removed. 357 If the Action component of an ORF entry is REMOVE, but the ORF 358 doesn't contain the specified entry, the entry is ignored. 360 ORF entries with either REMOVE or REMOVE-ALL can not remove locally 361 configured outbound route filters. 363 If the When-to-Refresh indicates IMMEDIATE, then after processing all 364 the ORF entries carried in the message the speaker re-advertises to 365 the peer routes from the Adj-RIB-Out associated with the peer that 366 have the same AFI/SAFI as what is carried in the message, and taking 367 into account all the ORF entries received from the peer. However, 368 the routes that have not be affected by the ORF entries carried in 369 the message SHOULT NOT be re-advertised to the peer. 371 If the When-to-Refresh indicates DEFER, then after processing all the 372 ORF entries carried in the message the speaker defers re- 373 advertisement to the peer routes from the Adj-RIB-Out associated with 374 the peer that have the same AFI/SAFI as what is carried in the 375 message, and taking into account all the ORF entries received from 376 the peer until the speaker receives a subsequent ROUTE-REFRESH 377 message for the same AFI/SAFI either without any ORF entries, or with 378 one or more ORF entries and When-to-refresh set to IMMEDIATE. 380 If the speaker receives from the peer a ROUTE-REFRESH message without 381 any ORF entries, then the speaker sends to the peer all routes from 382 the Adj-RIB-Out associated with the peer whose AFI/SAFI is the same 383 as what is carried in the message and taking into account the ORF 384 received from the peer. 386 The set of ORF entries that the speaker sends to the peer expresses 387 the speaker's local preference, that the peer may or may not decide 388 to honor. 390 During a single BGP session the speaker may pass multiple ORF entries 391 to the peer. 393 The lifetime of an ORF is the duration of the BGP session during 394 which the ORF is exchanged. 396 An ORF is removed when the last ORF entry is remove (either via 397 REMOVE-ALL, or via a sequence of REMOVE). 399 If a particular route maintained by a BGP speaker doesn't match any 400 of the ORF entries of any of the (non-empty) ORFs associated with a 401 particular peer, then this route SHOULD NOT be advertised to the 402 peer. 404 If a BGP speaker maintains multiple ORFs of different ORF-Types for a 405 particular peer, then the decision by the speaker to advertise a 406 route to the peer is determined by passing the route through each 407 such ORF, and and-ing the results (and-ing of PERMIT and DENY results 408 in DENY). 410 7. IANA Considerations 412 As specified in this document, an ORF enty contains the ORF-Type 413 field. ORF-Type value 0 is reserved. ORF-Type values 1 through 63 414 are to be assigned by IANA using the "IETF Consensus" policy defined 415 in RFC2434. ORF-Type values 64 through 127 are to be assigned by 416 IANA, using the "First Come First Served" policy defined in RFC2434. 417 ORF-Type values 128 through 255 are vendor-specific, and values in 418 this range are not to be assigned by IANA. 420 8. Security Considerations 422 This extension to BGP does not change the underlying security issues. 424 9. Intellectual Property Considerations 426 This section is taken from Section 10.4 of [RFC2026]. 428 The IETF takes no position regarding the validity or scope of any 429 intellectual property or other rights that might be claimed to 430 pertain to the implementation or use of the technology described in 431 this document or the extent to which any license under such rights 432 might or might not be available; neither does it represent that it 433 has made any effort to identify any such rights. Information on the 434 IETF's procedures with respect to rights in standards-track and 435 standards-related documentation can be found in BCP-11. Copies of 436 claims of rights made available for publication and any assurances of 437 licenses to be made available, or the result of an attempt made to 438 obtain a general license or permission for the use of such 439 proprietary rights by implementors or users of this specification can 440 be obtained from the IETF Secretariat. 442 The IETF invites any interested party to bring to its attention any 443 copyrights, patents or patent applications, or other proprietary 444 rights which may cover technology that may be required to practice 445 this standard. Please address the information to the IETF Executive 446 Director. 448 10. Copyright Notice 450 Copyright (C) The Internet Society (year). This document is subject 451 to the rights, licenses and restrictions contained in BCP 78, and 452 except as set forth therein, the authors retain all their rights. 454 This document and the information contained herein are provided on an 455 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 456 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 457 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 458 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 459 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 460 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 462 11. Acknowledgements 464 Some of the material in the document is "borrowed" from a proposal 465 for selective updates by Yakov Rekhter, Kannan Varadhan, and Curtis 466 Villamizar. 468 12. Normative References 470 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 471 (BGP-4)", RFC 1771, March 1995. 473 [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., 474 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 476 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 477 BGP-4", RFC2842, May 2000 479 [BGP-COMMUNITIES] Chandra, R., Traina, P., and Li, T., "BGP 480 Communities Attribute", RFC1997, August 1996. 482 [BGP-EXT-COMMUNITIES] Ramachandra, S., Tappan, D., "BGP Extended 483 Communities Attribute", draft-ramachandra-bgp-ext-communities-02.txt 485 [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, 486 September 2000 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, March 1997. 491 13. Author Information 493 Enke Chen 494 Cisco Systems, Inc. 495 e-mail: enkechen@cisco.com 497 Yakov Rekhter 498 Juniper Networks 499 e-mail: yakov@juniper.net