idnits 2.17.00 (12 Aug 2021) /tmp/idnits7294/draft-muley-hares-idr-orf-order-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 565. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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.) -- The document date (February 24, 2008) is 5193 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'BGP-ORF' on line 301 -- Looks like a reference, but probably isn't: 'ASPATH-ORF' on line 127 -- Looks like a reference, but probably isn't: 'TBD' on line 133 -- Looks like a reference, but probably isn't: 'Group' on line 169 -- Looks like a reference, but probably isn't: 'BGP-CAP' on line 252 ** Obsolete normative reference: RFC 3392 (ref. '3') (Obsoleted by RFC 5492) == Outdated reference: draft-ietf-idr-route-filter has been published as RFC 5291 -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-13) exists of draft-ietf-idr-aspath-orf-09 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR S. Hares 3 Internet-Draft Green Hills Software 4 Expires: August 27, 2008 P. Muley 5 Alcatel 6 K. Patel 7 Cisco Systems 8 B. Schliesser 9 Saavis Communications 10 February 24, 2008 12 Group Co-operative Route Filtering capability for BGP-4 13 draft-muley-hares-idr-orf-order-01 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 27, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 Currently BGP-4 is capable of carrying multiple (Outbound Route 47 Filters) ORFs entries for a given "AFI/SAFI". Each ORF provides a 48 filter that a route whose NLRI matches AFI/SAFI, must pass through to 49 be transmitted in the BGP Update message. Efficient processing of 50 ORF filters may require ordering of individual ORFs in certain 51 sequence and grouping of ORFs that should be applied together. The 52 grouping functionality also provides the support for logical OR 53 operation between the grouped ORFs. 55 This group ORF provides an ORF type that specifies that ordering and 56 grouping. The route set that passes set of ORFs running in a "Group 57 ORF" will pass the same ORFs sent in normal ORFs. 59 Table of Contents 61 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Conventions used in this document . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Past Contriburos . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Group ORF Type . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Group ORF Encoding . . . . . . . . . . . . . . . . . . . . . . 7 67 6. ORF Entry Encoding . . . . . . . . . . . . . . . . . . . . . . 10 68 7. Group Cooperative route filtering capability . . . . . . . . . 11 69 8. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 14 71 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 75 Intellectual Property and Copyright Statements . . . . . . . . . . 21 77 1. Definitions 79 1.1. Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC2119 [1]. 85 2. Introduction 87 Currently it is not uncommon for a BGP speaker to receive set of ORFs 88 from an ORF capable BGP peer. Each ORF provides a filter that a 89 route must pass through to be transmitted in the BGP update message. 90 Today's operational procedure for cooperative route filtering 91 provides the AFI/SAFI as the only context. ORF by definition in its 92 current form have logical OR within ORF entries and logical AND 93 within the ORF types. Efficient processing and expression of filters 94 for ORF may require ordering of ORFs filters and ORF entries in 95 certain sequence. Efficient processing entails both BGP processing 96 and quick processing of the ORF generated from User policies. 98 This document defines GROUP ORF, a new BGP-4 ORF type that allows BGP 99 to send to its peer a group of set of ordered ORF filters. Group ORF 100 provides a context for filtering rules that need to be interpreted 101 together further within that context AFI/SAFI. The grouping 102 functionality also provides the support for logical OR operation 103 between grouped ORFs. 105 Today ORF entries of same ORF type have logical OR functionality 106 only, which limits the flexibility of defining an efficient ORF with 107 less grammar description. Group ORF capability will help in defining 108 the relational meaning within the ORF entries as well. 110 One example of this is the use of ORFs to efficiently handle complex 111 ORF policies applied per VPN per peer, in BGP/MPLS VPN deployment as 112 defined in: RFC4364 [2]. 114 3. Past Contriburos 116 The authors want to acknowledge the contributions of Luyuan Fang and 117 Nabil Bitar. 119 4. Group ORF Type 121 The group ORF type allows a set of ORF entries of different ORF types 122 and ORF entries within the type, to be grouped, and ordered in the 123 BGP ROUTE-REFRESH message RFC2918 [6]. The Group ORF provides group 124 cooperative route filtering. 126 Conceptually a Group ORF consist of multiple different types of ORF 127 entries as defined in [BGP-ORF] [7], [ASPATH-ORF] [9] and [prefix- 128 ORF] [8]. Each such ORF type, will have ordered ORF entries, with an 129 operation of logical OR or logical AND defined with each other. 131 5. Group ORF Encoding 133 The value of the ORF-Type for Group ORF is [TBD]. 135 Conceptually the Route Refresh message carrying Group ORF can be 136 viewed as below. 138 +--------------------------------------------------+ 139 | Address Family Identifier (2 octets) | 140 +--------------------------------------------------+ 141 | Reserved (1 octet) | 142 +--------------------------------------------------+ 143 | Subsequent Address Family Identifier (1 octet) | 144 +--------------------------------------------------+ 145 | When-to-refresh (1 octet) | 146 +--------------------------------------------------+ 147 | ORF Type (1 octet) (Group) | 148 +--------------------------------------------------+ 149 | ORF Group Flags | 150 +--------------------------------------------------+ 151 | Length of ORFs (2 octets) | 152 +--------------------------------------------------+ 153 | First ORF entry (variable) (Group) | 154 +--------------------------------------------------+ 155 | Second ORF entry (variable) (Group) | 156 +--------------------------------------------------+ 157 ......... 158 +--------------------------------------------------+ 159 | N-th ORF entry (variable) | 160 +--------------------------------------------------+ 162 ORF byte layout 164 Each Group ORF entry will be encoded as follows. 166 +--------------------------------------------------+ 167 | ORF Group id (1 octet) | 168 +--------------------------------------------------+ 169 | ORF Type (1 octet) [Group] | 170 +--------------------------------------------------+ 171 | ORF Action (1 octet) | 172 +--------------------------------------------------+ 173 | ORF FLags (1 octet) | 174 | Length of ORFs (2 octets) | 175 +--------------------------------------------------+ 176 | First ORF entry (variable) | 177 +--------------------------------------------------+ 178 | Second ORF entry (variable) | 179 +--------------------------------------------------+ 180 ......... 181 +--------------------------------------------------+ 182 | N-th ORF entry (variable) | 183 +--------------------------------------------------+ 184 | ORF Type (1 octet) | 185 +--------------------------------------------------+ 186 | Length of ORFs (2 octets) | 187 +--------------------------------------------------+ 188 | First ORF entry (variable) | 189 +--------------------------------------------------+ 190 | Second ORF entry (variable) | 191 +--------------------------------------------------+ 192 ......... 194 Group ORF byte layout 196 ORF Action: 198 Byte that indicates operation of "AND and OR" function within the 199 full Group ORF. 201 Value 000 Use AND or OR specified in Group ORF. OR between GROUP 202 IDs. 204 Value 001 Always AND between attributes in Flag Byte 206 Always ORed between same Route-map's different sequences. 208 ORF FLAG: 210 Value 0000 0001 Route-Map 211 Value 0000 0002 Access Control List 213 Value 1000 0000 Ignore ORF Action BIT 215 6. ORF Entry Encoding 217 As specified in the [BGP-ORF] [7] the ORF entry definition has common 218 part and type specific part. The encoding of common part of the ORF 219 entries on Group ORF capability negotiation as defined below. 221 +---------------------------------+ 222 | Action (2 bit) | 223 +---------------------------------+ 224 | Match (1 bit) | 225 +---------------------------------+ 226 | AND/OR (1 bit) | 227 +---------------------------------+ 228 | Reserved (4 bits) | 229 +---------------------------------+ 230 | Type specific part (variable) | 231 +---------------------------------+ 233 Group ORF Entry Byte 235 The new AND/OR is a one bit field additional to the definition 236 specified in [BGP-ORF] [7]. The value of this field is 0 for 237 expression of logical OR and 1 for logical AND with the next ORF 238 entry. The ORF entries grammar expression for logical OR followed by 239 logical AND ORF entries will be for the over all the group of such 240 and-ed ORF entries. This field in the last entry of the ORF type 241 will be ignored. 243 7. Group Cooperative route filtering capability 245 A BGP speaker that is willing to receive Group ORF entries from its 246 peer, or a BGP speaker that would like to send ORF entries to its 247 peer advertises this to the peer by using the Cooperative Route 248 Filtering Capability, as described below. 250 The Group ORF Capability is a new BGP capability 252 [BGP-CAP] [3] defined as follows 254 Capability code: X [IANA consideration] 256 Capability length: variable 258 Capability value: one or more of the entries as defined for ORF 259 entries in the [BGP-ORF] [7]. 261 The use of ORF entry in Group ORF will depend upon the send/receive 262 value of the ORF type in capability negotiation 264 8. Operation 266 In addition to operational procedures defined in [BGP-ORF] [7] 267 several additional operational rules needs to be followed. 269 The Group ORF Group-ID allows a tag for a group of ORFs. If multiple 270 instances of a Group ORF with the same Group-ID exist within a Route 271 Refresh Message, the additional group information is appended to the 272 set of previously received ORFs with the same Group-ID. The complete 273 list of ORFs within the Group will be included in the "and-ing" 274 process for that Group. 276 When processing multiple Group ORFs into a filter, the Group ORFs 277 will be applied in ascending order of the Group ID. 279 When the BGP speaker receives multiple ORFs within a Group ORF entry, 280 the order of the ORFs is preserved and applied as per first ORF entry 281 match rule. 283 For each Group ORF, a BGP speaker will pass the set of candidate 284 NLRIs (routes) through each ORF that is a member of the Group, and- 285 ing the results (and-ing of PERMIT and DENY results in DENY). If a 286 Group ORF would result in a PERMIT for a given NLRI, it is advertised 287 to the peer and it is removed from the list of candidate NLRIs. If a 288 Group ORF would result in a DENY for a given NLRI, it is not 289 advertised to the peer and it is removed from the list of candidate 290 NLRIs. The remaining list of candidate NLRIs are then filtered 291 through the next Group ORF. 293 This process is repeated until the candidate NRLIs have been filtered 294 through all Group ORFs. The remaining candidate NLRIs are then 295 filtered through any non-Group ORFs that might exist. While 296 processing the ORF entries in the ORF type the result of ORF entry 297 match with AND/OR bit set will be and-ed with the subsequent ORF 298 entry match. The ORF entry with AND/OR bit is set to 0 will OR the 299 match result with subsequent entry match result. Rest of the 300 procedure for treatment of NLRI remains same as described in the 301 [BGP-ORF] [7]. 303 To remove a group ORF then all the ORF entries in the Group ORF will 304 have the action component as REMOVE. 306 The Group ORF MUST always have higher preference than non-Group ORFs, 307 and will be processed first. 309 Note: Group ORF are independent of ORF preference and configuration 310 to occur without concern for order of transmission. Individual ORF 311 type preference within the Group ORF will occur based on 312 configuration policy. 314 9. Deployment Scenarios 316 Following are few deployment examples where Group ORF helps in 317 filtering and offering flexibility in ORF expression. 319 Scenario 1 321 An example of group ORF could be in the IPVPN case is where multiple 322 BGP communities [BGP-COM} [4] and/or extended communities need to be 323 considered together for a given VPN in the filtering rules although 324 all IPVPN routes belong to the same AFI/SAFI. 326 Consider the case where there are two VPNs, red and yellow, have 327 routes belonging to sites tagged by community attributes that express 328 city locations. The Red VPN wants or needs to get routes from 329 certain site locations but not others. Similarly, the yellow VPN 330 wants or needs to get sites from certain location not others. For 331 the purpose of ease in manageability, it would be desired to 332 affiliate the community attribute value with the city location only. 333 That is the red VPN and yellow VPN routes will carry the same city 334 community value when these routes reside in same city. 336 If cooperative route filtering is used without group ORF, it will not 337 be possible to express the ORFs when the the two VPNs have different 338 rules whereby different city routes need to be imported to another 339 city for the two VPNs. This is because of the ORing operation within 340 the same ORF type and ANDing operation across ORF types. 342 To illustrate further consider the following example where routers in 343 the red VPN in city 4 needs to get the routes from city 1 only and 344 not from city 2 and 3. On the other hand, the routers in the yellow 345 VPN in city 4 needs to get routes from city 2 but not city 3 and city 346 1. In current procedures for cooperative route filtering without 347 group ORF, the only way to express that for ORF from the routers 348 hosting VPN sites in city 4 is: 350 AFI/SAFI = IPVPN 352 Extended ORF Type = Target Extended Community 354 Permit Red 356 Permit Yellow 358 ORF Type = Community 360 Permit City1 361 Permit City2 363 Based on this ORF routes tagged with Red and City2 will be permitted 364 and routes tagged with Yellow and City1 will be permitted although 365 these are not deired routes and will need to be filtered out by a 366 local policy on the routers in City4. 368 If group ORF was available, the ORF policy can be more flexibly 369 expressed in the following manner: 371 AFI/SAFI = IPVPN 373 Group 1 (implicitly Red VPN) 375 Extended ORF Type = Target Extended Community 377 Permit Red 379 ORF Type = Community 381 Permit City1 383 Group 2 (implicitly Yellow VPN) 385 Extended ORF Type = Target Extended Community 387 Permit Yellow 389 ORF Type = Community 391 Permit City2 393 Thus Group 1 provides a context for the red VPN and Group 2 provides 394 a context for the yellow VPN. Only routes that are tagged with Red 395 target extended community attributes and City1 community or routes 396 tagged with Yellow target community attributes and City2 community 397 will be permitted to be advertised to the BGP client that sent this 398 ORF, achieving the desired result. 400 It may be argued that in this simple case, the problem could be 401 addressed with existing ORF capabilities by simply tagging the Red 402 and City 1 routes with a new extended community tag (Red_City1) and 403 the routes with the Yellow and City2 tags with a new target extended 404 community tag (Yellow_City2) and including these in the ORF. 405 However, this can get complicated as the number of combinations of 406 BGP extended communities RFC4360 [5] and communities increases. 407 Having group ORF capability offers the needed flexibility. 409 It is also true that the same result can be achieved by defining 410 local policies on the routers but the tradeoff as in any ORF case is 411 between the work done at a client and that done at the route 412 reflector when used in topology. 414 Scenario 2 416 An example Group ORF in the global routing context can be where a BGP 417 speaker wants to learn certain more specific NLRIs only if they 418 traverse certain AS path. Otherwise routes which are less specific 419 than /25. A Group ORF will look like as defined below where X,Y,Z 420 are the more specific NLRIs to be learnt only if it learn it from 421 AS1. 423 AFI/SAFI = IPV4 425 Group 1 427 ORF Type = Prefix 429 Permit X 431 Permit Y 433 Permit Z 435 ORF Type = ASpath 437 Permit AS1 439 Group 2 441 ORF Type = Prefix 443 Deny prefix( */25) or longer 445 Group 3 447 ORF Type = Prefix 449 Permit prefix(*) 451 Although its possible to achieve the above mentioned application by 452 making use of route policies, use of Group ORF helps in simplifying 453 the configuration. 455 10. Security Considerations 457 This extension to BGP does not change the underlying security issues. 459 11. IANA Considerations 461 IANA will need to assign the value of the ORF-Type for Group ORF. 463 12. References 465 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 466 Levels", March 1997, . 468 [2] Cisco and Juniper, "BGP/MPLS VPN", February 2006, 469 . 471 [3] Cisco and Cisco, "Capabilities Advertisement with BGP-4", 472 November 2002, . 474 [4] Cisco, Cisco, and Cisco, "BGP/MPLS VPN", August 1996, 475 . 477 [5] Cisco, Cisco, and Juniper, "BGP Extended Communities Attribute", 478 July 2006, . 480 [6] Cisco, "Route Refresh Capability for BGP-4", Septebmer 2000, 481 . 483 [7] Sangli, S. and Cisco, ""Cooperative Router Filtering for 484 BGP-4"", July 2005, . 487 [8] Sangli, S. and Cisco, ""Address Prefix Based Outbound Route 488 Filter for BGP-4"", March 2005, . 491 [9] Hares, S. and K. Patel, ""Aspath Based Outbound Route Filter for 492 BGP-4"", August 2007, . 495 Authors' Addresses 497 Susan Hares 498 Green Hills Software 499 825 Victors Way 500 Ann Arbor, MI 48108 502 Phone: +1-734-222-1610 503 Email: shares@ghs.com 505 Praveen Muley 506 Alcatel 507 701, E. Middle Field Rd 508 Mountain View, CA 94043 510 Phone: +1-650-623-2622 511 Email: Praveen.Muley@alcatel.com 513 Keyur Patel 514 Cisco Systems 516 Phone: 517 Email: keyupate@cisco.com 519 Benson Schliesser 520 Saavis Communications 521 1 Savvis Parkway 522 Town and Country, MO 63017 524 Phone: +1-314-628-7036 525 Email: bensons@savvis.net 527 Full Copyright Statement 529 Copyright (C) The IETF Trust (2008). 531 This document is subject to the rights, licenses and restrictions 532 contained in BCP 78, and except as set forth therein, the authors 533 retain all their rights. 535 This document and the information contained herein are provided on an 536 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 537 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 538 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 539 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 540 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 541 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 543 Intellectual Property 545 The IETF takes no position regarding the validity or scope of any 546 Intellectual Property Rights or other rights that might be claimed to 547 pertain to the implementation or use of the technology described in 548 this document or the extent to which any license under such rights 549 might or might not be available; nor does it represent that it has 550 made any independent effort to identify any such rights. Information 551 on the procedures with respect to rights in RFC documents can be 552 found in BCP 78 and BCP 79. 554 Copies of IPR disclosures made to the IETF Secretariat and any 555 assurances of licenses to be made available, or the result of an 556 attempt made to obtain a general license or permission for the use of 557 such proprietary rights by implementers or users of this 558 specification can be obtained from the IETF on-line IPR repository at 559 http://www.ietf.org/ipr. 561 The IETF invites any interested party to bring to its attention any 562 copyrights, patents or patent applications, or other proprietary 563 rights that may cover technology that may be required to implement 564 this standard. Please address the information to the IETF at 565 ietf-ipr@ietf.org. 567 Acknowledgment 569 Funding for the RFC Editor function is provided by the IETF 570 Administrative Support Activity (IASA).