idnits 2.17.1 draft-ietf-idr-route-filter-09.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 10 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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) == Unused Reference: 'BGP-4' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'BGP-MP' is defined on line 429, 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: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Enke Chen 3 Internet Draft Redback Networks, Inc. 4 Expiration Date: February 2003 Yakov Rekhter 5 Juniper Networks 7 Cooperative Route Filtering Capability for BGP-4 9 draft-ietf-idr-route-filter-09.txt 11 1. 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 2. Specification of Requirements 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC2119 [RFC2119]. 39 3. Abstract 41 This document defines a BGP-based mechanism that allows a BGP speaker 42 to send to its BGP peer a set of route filters that the peer would 43 use to constrain/filter its outbound routing updates to the speaker. 45 4. Introduction 47 Currently it is not uncommon for a BGP speaker to receive, and then 48 filter out some unwanted routes from its peers based on its local 49 routing policy. Since the generation and transmission of routing 50 updates by the sender, as well as the processing of routing updates 51 by the receiver consume resources, it may be beneficial if the 52 generation of such unwanted routing updates can be avoided in the 53 first place. 55 This document defines a BGP-based mechanism that allows a BGP speaker 56 to send to its BGP peer a set of Outbound Route Filters (ORFs). The 57 peer would then apply these filters, in addition to its locally 58 configured outbound filters (if any), to constrain/filter its 59 outbound routing updates to the speaker. 61 5. Outbound Route Filter (ORF) 63 Conceptually an ORF entry is a tuple of the form ; an ORF consists of one or more ORF entries 65 that have a common AFI/SAFI and ORF-Type. An ORF is identified by 66 . 68 The "AFI/SAFI" component provides a coarse granularity control by 69 limiting the ORF to only the routes whose NLRI matches the "AFI/SAFI" 70 component of the ORF. 72 The "ORF-Type" component determines the content of the ORF-value. 74 The "Action" component controls handling of the ORF Request by the 75 remote peer. Action can be one of ADD, REMOVE, REMOVE-ALL. ADD adds 76 an ORF entry to the ORF on the remote peer; REMOVE deletes a 77 previously installed ORF entry on the remote peer; REMOVE-ALL deletes 78 the previously installed entries in the specified ORF on the remote 79 peer. 81 The "Match" component is used if support matching granularity on a 82 per ORF entry basis is needed, in which case the "Match" component 83 can be one of PERMIT or DENY. The semantics of PERMIT is to ask the 84 peer to pass updates for the set of routes that match the ORF entry. 86 The semantics of DENY is to ask the peer not to pass updates for the 87 set of routes that match the ORF entry. 89 5.1. Communities ORF-Type 91 The Community ORF-Type allows to express ORFs in terms of BGP 92 Communities [BGP-COMMUNITIES]. That is, the Communities ORF-Type 93 provides Communities-based route filtering. 95 Conceptually the ORF-value of the Communities ORF-Type consists of a 96 single Community. 98 The sender SHOULD set the value of the Match field to PERMIT; the 99 receiver SHOULD ignore the value of the Match field. 101 The remote peer should consider only those routes whose Communities 102 attribute has at least one Community in common with the Communities 103 list specified in the ORF. 105 5.2. Extended Communities ORF-Type 107 The Extended Community ORF-Type allows to express ORFs in terms of 108 BGP Extended Communities [BGP-EXT-COMMUNITIES]. That is, the Extended 109 Communities ORF-Type provides Extended Communities-based route 110 filtering. 112 Conceptually the ORF-value of the Extended Communities ORF-Type 113 consists of a single Extended Community. 115 The sender SHOULD set the value of the Match field to PERMIT; the 116 receiver SHOULD ignore the value of the Match field. 118 The remote peer should consider only those routes whose Extended 119 Communities attribute has at least one Extended Community in common 120 with the Extended Communities list specified in the ORF. 122 6. Carrying ORF entries in BGP 124 ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR]. 126 A BGP speaker can distinguish an incoming ROUTE-REFRESH message that 127 carries one or more ORF entries from an incoming plain ROUTE-REFRESH 128 message by using the Message Length field in the BGP message header. 130 A single ROUTE-REFRESH message could carry multiple ORF entries, as 131 long as all these entries share the same AFI/SAFI. 133 From the encoding point of view each ORF entry consists of a common 134 part and type-specific part. 136 The common part consists of , and 137 is encoded as follows: 139 The AFI/SAFI component of an ORF entry is encoded in the AFI/SAFI 140 field of the ROUTE-REFRESH message. 142 Following the AFI/SAFI component is the one-octet When-to-refresh 143 field. The value of this field can be one of IMMEDIATE (0x01) or 144 DEFER (0x02). The semantics of IMMEDIATE and DEFER are discussed 145 in the "Operation" section of this document. 147 Following the When-to-refresh field is a collection of one or more 148 ORFs, grouped by ORF-Type. 150 The ORF-Type component is encoded as a one-octet field. 152 The Length of ORFs component is a two-octets field that contains 153 the length (in octets) of the ORF entries that follows. 155 +--------------------------------------------------+ 156 | Address Family Identifier (2 octets) | 157 +--------------------------------------------------+ 158 | Reserved (1 octet) | 159 +--------------------------------------------------+ 160 | Subsequent Address Family Identifier (1 octet) | 161 +--------------------------------------------------+ 162 | When-to-refresh (1 octet) | 163 +--------------------------------------------------+ 164 | ORF Type (1 octet) | 165 +--------------------------------------------------+ 166 | Length of ORFs (2 octets) | 167 +--------------------------------------------------+ 168 | First ORF entry (variable) | 169 +--------------------------------------------------+ 170 | Second ORF entry (variable) | 171 +--------------------------------------------------+ 172 ......... 173 +--------------------------------------------------+ 174 | N-th ORF entry (variable) | 175 +--------------------------------------------------+ 176 | ORF Type (1 octet) | 177 +--------------------------------------------------+ 178 | Length of ORFs (2 octets) | 179 +--------------------------------------------------+ 180 | First ORF entry (variable) | 181 +--------------------------------------------------+ 182 | Second ORF entry (variable) | 183 +--------------------------------------------------+ 184 ......... 185 +--------------------------------------------------+ 186 | N-th ORF entry (variable) | 187 +--------------------------------------------------+ 188 ......... 190 Fig 1. Carrying ORF entries in the ROUTE-REFRESH message 192 The rest of the components in the common part are encoded in first 193 octet of each ORF-entry as follows (from the most significant to the 194 least significant bit): 196 Action is a two-bit field. The value of this field is 0 for ADD, 1 197 for REMOVE, and 2 for REMOVE-ALL. 199 Match is a one-bit field. The value of this field is 0 for PERMIT 200 and 1 for DENY. This field is significant only when the value of 201 the Action field is either ADD or REMOVE. 203 Reserved is a 5-bit field. It is set to 0 on transmit and ignored 204 on receive. 206 +---------------------------------+ 207 | Action (2 bit) | 208 +---------------------------------+ 209 | Match (1 bit) | 210 +---------------------------------+ 211 | Reserved (5 bits) | 212 +---------------------------------+ 213 | Type specific part (variable) | 214 +---------------------------------+ 215 Fig 2. ORF entry encoding 217 When the Action component of an ORF entry specifies REMOVE-ALL, 218 the entry consists of only the common part. 220 6.1. Type specific encoding (Communities ORF-Type) 222 The value of the ORF-Type for the Communities ORF-Type is 2. 224 The type-specific part of Communities ORF-Type consists of single 225 Community encoded as a four-octets field. 227 6.2. Type specific encoding (Extended Communities ORF-Type) 229 The value of the ORF-Type for the Extended Communities ORF-Type is 3. 231 The type-specific part of Extended Communities ORF-Type consists of a 232 single Extended Community encoded as an eight-octets field. 234 7. Cooperative Route Filtering Capability 236 A BGP speaker that is willing to receive ORF entries from its peer, 237 or a BGP speaker that would like to send ORF entries to its peer 238 advertises this to the peer by using the Cooperative Route Filtering 239 Capability, as described below. 241 The Cooperative Route Filtering Capability is a new BGP capability 242 [BGP-CAP] defined as follows: 244 Capability code: 3 246 Capability length: variable 248 Capability value: one or more of the following entries: 250 +--------------------------------------------------+ 251 | Address Family Identifier (2 octets) | 252 +--------------------------------------------------+ 253 | Reserved (1 octet) | 254 +--------------------------------------------------+ 255 | Subsequent Address Family Identifier (1 octet) | 256 +--------------------------------------------------+ 257 | Number of ORFs (1 octet) | 258 +--------------------------------------------------+ 259 | ORF Type (1 octet) | 260 +--------------------------------------------------+ 261 | Send/Receive (1 octet) | 262 +--------------------------------------------------+ 263 | ... | 264 +--------------------------------------------------+ 265 | ORF Type (1 octet) | 266 +--------------------------------------------------+ 267 | Send/Receive (1 octet) | 268 +--------------------------------------------------+ 270 Fig 4. Capability encoding 272 The use and meaning of these fields are as follows: 274 Address Family Identifier (AFI): 276 This field carries the identity of the Network Layer protocol 277 associated with the Network Address that follows. Presently 278 defined values for this field are specified in RFC1700 (see the 279 Address Family Numbers section). 281 Subsequent Address Family Identifier (SAFI): 283 This field provides additional information about the type of 284 the Network Layer Reachability Information carried in the 285 attribute. 287 Number of ORF Types: 289 This field contains the number of Filter Types to be listed in 290 the following fields. 292 ORF Type: 294 This field contains the value of an ORF Type. 296 Send/Receive: 298 This field indicates whether the sender is (a) willing to 299 receive ORF entries from its peer (value 1), (b) would like to 300 send ORF entries to its peer (value 2), or (c) both (value 3) 301 for the ORF Type that follows. 303 8. Operation 305 A BGP speaker that is willing to receive ORF entries from its peer, 306 or would like to send ORF entries to its peer SHOULD advertise the 307 Cooperative Route Filtering Capability to the peer using BGP 308 Capabilities advertisement [BGP-CAP]. 310 A BGP speaker that implements the Cooperative Route Filtering 311 Capability must support BGP ROUTE-REFRESH message, as defined in 312 [BGP-RR]. A BGP speaker that advertises the Cooperative Route 313 Filtering Capability to a peer using BGP Capabilities advertisement 314 [BGP-CAP] doesn't have to advertise the BGP Route Refresh capability 315 to that peer. 317 Consider a BGP speaker that advertises the Cooperative Route 318 Filtering Capability indicating its willingness to receive a 319 particular set of from its peer, and that 320 receives the Cooperative Route Filtering Capability indicating the 321 desire of the peer to send a particular set to 322 the speaker. If for a given the intersection between 323 these two sets are not-empty, the speaker SHOULD NOT advertise to the 324 peer any routes with that prior to receiving from the 325 peer any ROUTE-REFRESH message carrying that , where the 326 message could be either without any ORF entries, or with one or more 327 ORF entry and When-to-refresh field set to IMMEDIATE. If, on the 328 other hand, for a given the intersection between these 329 two sets is empty, the speaker SHOULD follow normal BGP procedures. 331 A BGP speaker may send a ROUTE-REFRESH message with one or more ORF 332 entries to its peer only if the peer advertises to the speaker the 333 Cooperative Route Filtering Capability indicating its willingness to 334 receive ORF entries from the speaker, and the speaker advertises to 335 the peer the Cooperative Route Filtering Capability indicating its 336 desire to send ORF entries to the peer. The message may contain only 337 ORF entries of that the peer is willing to 338 receive, as advertised to the speaker in the Cooperative Route 339 Filtering Capability. 341 When a BGP speaker receives a ROUTE-REFRESH message with one or more 342 ORF entries from its peer, then the speaker performs the following 343 actions. If the carried by the message doesn't 344 match that the speaker is willing to receive 345 from the peer (as advertised to the peer in the Cooperative Route 346 Filtering Capability), the specified ORF is ignored. Otherwise, the 347 speaker modifies the specified ORF, as specified in the ORF entries 348 carried by the message. If any of the fields within an ORF entry 349 contain an unrecognized value, the whole specified ORF is removed. 351 If the Action component of an ORF entry is REMOVE, but the ORF 352 doesn't contain the specified entry, the entry is ignored. 354 ORF entries with either REMOVE or REMOVE-ALL can not remove locally 355 configured outbound route filters. 357 If the When-to-Refresh indicates IMMEDIATE, then after processing all 358 the ORF entries carried in the message the speaker re-advertises to 359 the peer routes from the Adj-RIB-Out associated with the peer that 360 have the same AFI/SAFI as what is carried in the message, and taking 361 into account all the ORF entries received from the peer. However, 362 the routes that have not be affected by the ORF entries carried in 363 the message SHOULT NOT be re-advertised to the peer. 365 If the When-to-Refresh indicates DEFER, then after processing all the 366 ORF entries carried in the message the speaker defers re- 367 advertisement to the peer routes from the Adj-RIB-Out associated with 368 the peer that have the same AFI/SAFI as what is carried in the 369 message, and taking into account all the ORF entries received from 370 the peer until the speaker receives a subsequent ROUTE-REFRESH 371 message for the same AFI/SAFI either without any ORF entries, or with 372 one or more ORF entries and When-to-refresh set to IMMEDIATE. 374 If the speaker receives from the peer a ROUTE-REFRESH message without 375 any ORF entries, then the speaker sends to the peer all routes from 376 the Adj-RIB-Out associated with the peer whose AFI/SAFI is the same 377 as what is carried in the message and taking into account the ORF 378 received from the peer. 380 The set of ORF entries that the speaker sends to the peer expresses 381 the speaker's local preference, that the peer may or may not decide 382 to honor. 384 During a single BGP session the speaker may pass multiple ORF entries 385 to the peer. 387 The lifetime of an ORF is the duration of the BGP session during 388 which the ORF is exchanged. 390 An ORF is removed when the last ORF entry is remove (either via 391 REMOVE-ALL, or via a sequence of REMOVE). 393 If a particular route maintained by a BGP speaker doesn't match any 394 of the ORF entries of any of the (non-empty) ORFs associated with a 395 particular peer, then this route SHOULD NOT be advertised to the 396 peer. 398 If a BGP speaker maintains multiple ORFs of different ORF-Types for a 399 particular peer, then the decision by the speaker to advertise a 400 route to the peer is determined by passing the route through each 401 such ORF, and and-ing the results (and-ing of PERMIT and DENY results 402 in DENY). 404 9. IANA Considerations 406 As specified in this document, an ORF enty contains the ORF-Type 407 field. ORF-Type value 0 is reserved. ORF-Type values 1 through 63 408 are to be assigned by IANA using the "IETF Consensus" policy defined 409 in RFC2434. ORF-Type values 64 through 127 are to be assigned by 410 IANA, using the "First Come First Served" policy defined in RFC2434. 411 ORF-Type values 128 through 255 are vendor-specific, and values in 412 this range are not to be assigned by IANA. 414 10. Security Considerations 416 This extension to BGP does not change the underlying security issues. 418 11. Acknowledgements 420 Some of the material in the document is "borrowed" from a proposal 421 for selective updates by Yakov Rekhter, Kannan Varadhan, and Curtis 422 Villamizar. 424 12. Normative References 426 [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 427 (BGP-4)", RFC 1771, March 1995. 429 [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., 430 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 432 [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with 433 BGP-4", RFC2842, May 2000 435 [BGP-COMMUNITIES] Chandra, R., Traina, P., and Li, T., "BGP 436 Communities Attribute", RFC1997, August 1996. 438 [BGP-EXT-COMMUNITIES] Ramachandra, S., Tappan, D., "BGP Extended 439 Communities Attribute", draft-ramachandra-bgp-ext-communities-02.txt 441 [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC2918, 442 September 2000 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 13. Author Information 449 Enke Chen 450 Redback Networks, Inc. 451 350 Holger Way 452 San Jose, CA 95134 453 e-mail: enke@redback.com 455 Yakov Rekhter 456 Juniper Networks 457 e-mail: yakov@juniper.net