idnits 2.17.1 draft-ietf-l3vpn-orf-covering-prefixes-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 22, 2014) is 3505 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Routing Working Group H. Jeng 3 Internet-Draft AT&T 4 Intended status: Standards Track L. Jalil 5 Expires: March 26, 2015 Verizon 6 R. Bonica 7 Y. Rekhter 8 Juniper Networks 9 K. Patel 10 Cisco Systems 11 L. Yong 12 X. Xu 13 Huawei Technologies 14 September 22, 2014 16 Covering Prefixes Outbound Route Filter for BGP-4 17 draft-ietf-l3vpn-orf-covering-prefixes-02 19 Abstract 21 This document defines a new ORF-type, called the "Covering Prefixes 22 ORF (CP-ORF)". CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. 23 It also is applicable in BGP/MPLS Ethernet VPN (EVPN) Networks. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 26, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Applicability In Virtual Hub-and-Spoke VPNs . . . . . . . . . 9 70 4.1. Multicast Considerations . . . . . . . . . . . . . . . . 12 71 5. Applicability In BGP/MPLS Ethernet VPN (EVPN) . . . . . . . . 12 72 6. Clean-up . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 76 10. Normative References . . . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Problem Statement 81 A BGP [RFC4271] speaker can send Outbound Route Filters (ORF) 82 [RFC5291] to a peer. The peer uses ORFs to filter routing updates 83 that it sends to the BGP speaker. Using ORF, a BGP speaker can 84 realize a "route pull" paradigm, in which the BGP speaker, on demand, 85 pulls certain routes from the peer. 87 This document defines a new ORF-type, called the "Covering Prefixes 88 ORF (CP-ORF)". CP-ORF is applicable in Virtual Hub-and-Spoke VPNs 89 [RFC7024] [RFC4364]. It also is applicable BGP/MPLS Ethernet VPN 90 (EVPN) [I-D.ietf-l2vpn-evpn] Networks. 92 1.1. Terminology 94 This document uses the following terms: 96 o Address Family Indicator (AFI) - defined in [RFC4760] 98 o Subsequent Address Family Indicator (SAFI) - defined in [RFC4760] 100 o VPN IP Default Route - defined in [RFC7024]. 102 o V-Hub - defined in [RFC7024]. 104 o V-Spoke - defined in [RFC7024]. 106 o BGP/MPLS Ethernet VPN (EVPN) - defined in [I-D.ietf-l2vpn-evpn] 108 o EVPN Instance (EVI) - defined in [I-D.ietf-l2vpn-evpn] 110 o Unknown MAC Route (UMR) - A regular EVPN MAC/IP Advertisement 111 route where the MAC Address Length is set to 48 and the MAC 112 address to 00:00:00:00:00:00 114 o Default MAC Gateway (DMG) - An EVPN PE that advertises a UMR 116 2. CP-ORF Encoding 118 [RFC5291] augments the BGP ROUTE-REFRESH message so that it can carry 119 ORF entries. When the ROUTE-REFRESH message carries ORF entries, it 120 includes the following fields: 122 o AFI [IANA.AFI] 124 o SAFI [IANA.SAFI] 126 o When-to-refresh (IMMEDIATE or DEFERRED) 128 o ORF Type 130 o Length (of ORF entries) 132 The ROUTE-REFRESH message also contains a list of ORF entries. Each 133 ORF entry contains the following fields: 135 o Action (ADD, REMOVE, or REMOVE-ALL) 137 o Match (PERMIT or DENY) 138 The ORF entry may also contain Type-specific information. Type- 139 specific information is present only when the Action is equal to ADD 140 or REMOVE. It is not present when the Action is equal to REMOVE-ALL. 142 When the BGP ROUTE-REFRESH message carries CP-ORF entries, the 143 following conditions MUST be true: 145 o ORF Type MUST be equal to CP-ORF. (The value of CP-ORF is TBD. 146 See Section 7 for details.) 148 o The AFI MUST be equal to IPv4, IPv6 or L2VPN 150 o If the AFI is equal to IPv4 or IPv6, SAFI MUST be equal to MPLS- 151 labeled VPN address 153 o If the AFI is equal to L2VPN, the SAFI MUST be equal to BGP EVPN 155 o Match field MUST be equal to PERMIT 157 Figure 1 depicts the encoding of the CP-ORF type-specific 158 information. 160 +--------------------------------+ 161 | Sequence (32 bits) | 162 +--------------------------------+ 163 | Minlen (8 bits) | 164 +--------------------------------+ 165 | Maxlen (8 bits) | 166 +--------------------------------+ 167 | VPN Route Target (64 bits) | 168 +--------------------------------+ 169 | Import Route Target (64 bits) | 170 +--------------------------------+ 171 | Route Type (8 bits) | 172 +--------------------------------+ 173 | Host Address | 174 | (0, 32, 48 or 128 bits) | 175 | .... 176 +--------------------------------+ 178 Figure 1: CP-ORF Type-specific Encoding 180 The Sequence field specifies the relative ordering of the entry among 181 all CP-ORF entries. 183 The CP-ORF recipient uses the following fields to identify routes 184 that match the CP-ORF: 186 o Minlen 188 o Maxlen 190 o VPN Route Target 192 o Route Type 194 o Host Address 196 See Section 3 for details. 198 The CP-ORF recipient marks routes that match CP-ORF with the Import 199 Route Target before advertising those routes to the CP-ORF 200 originator. See Section 3 for details. 202 If the ROUTE-REFRESH AFI is equal to IPv4: 204 o The value of Minlen MUST be less than or equal to 32 206 o The value of Maxlen MUST be less than or equal to 32 208 o The value of Minlen MUST be less than or equal to the value of 209 Maxlen 211 o The value of Route Type MUST be 0 (i.e., undefined) 213 o The Host Address MUST contain exactly 32 bits 215 If the ROUTE-REFRESH AFI is equal to IPv6: 217 o The value of Minlen MUST be less than or equal to 128 219 o The value of Maxlen MUST be less than or equal to 128 221 o The value of Minlen MUST be less than or equal to the value of 222 Maxlen 224 o The value of Route Type MUST be 0 (i.e., undefined) 226 o The Host Address MUST contain exactly 128 bits 228 If the ROUTE-REFRESH AFI is equal to L2VPN, the value of Route Type 229 MUST be one of the following: 231 o 1 - Ethernet Autodiscovery Route 233 o 2 - MAC/IP Advertisement Route 234 o 3 - Inclusive Multicast Route 236 o 4 - Ethernet Segment Route 238 If the ROUTE-REFRESH AFI is equal to L2VPN and the value of Route 239 Type is equal to Ethernet Autodiscovery Route, Inclusive Multicast 240 Route, or Ethernet Segment Route: 242 o The value of Minlen MUST be equal to 0 244 o The value of Maxlen MUST be equal to 0 246 o The Host Address MUST be absent (i.e., contain 0 bits) 248 If the ROUTE-REFRESH AFI is equal to L2VPN and the value of Route 249 Type is equal to MAC/IP Advertisement Route: 251 o The value of Minlen MUST be less than or equal to 48 253 o The value of Maxlen MUST be less than or equal to 48 255 o The value of Minlen MUST be less than or equal to the value of 256 Maxlen 258 o The Host Address MUST contain exactly 48 bits. 260 3. Processing Rules 262 According to [RFC4271], every BGP speaker maintains a single Loc-RIB. 263 For each of its peers, the BGP speaker also maintains an Outbound 264 Filter and an Adj-RIB-Out. The Outbound Filter defines policy that 265 determines which Loc-RIB entries are processed into the corresponding 266 Adj-RIB-Out. Mechanisms such as RT-Contstrain [RFC4684] and ORF 267 [RFC5291] enable a router's peer to influence the Outbound Filter. 268 Therefore, the Outbound Filter for a given peer is constructed using 269 a combination of the locally configured policy and the information 270 received via RT-Constrain and ORF from the peer. 272 Using this model we can describe the operations of CP-ORF as follows: 274 When a BGP speaker receives a ROUTE-REFRESH message that contains a 275 CP-ORF, and that ROUTE-REFRESH message that violates any of the 276 encoding rules specified in Section 2, the BGP speaker MUST log the 277 event and ignore the entire ROUTE-REFRESH message. 279 Otherwise, the BGP speaker processes each CP-ORF entry as indicated 280 by the Action field. If the Action is equal to ADD, the BGP speaker 281 adds the CP-ORF entry to the Outbound Filter associated with the peer 282 in the position specified by the Sequence field. If the Action is 283 equal to REMOVE, the BGP speaker removes the CP-ORF entry from the 284 Outbound Filter. If the Action is equal to REMOVE-ALL, the BGP 285 speaker removes all CP-ORF entries from the Outbound Filter. 287 Whenever the BGP speaker applies an Outbound Filter to a route 288 contained in its Loc-RIB, it evaluates the route in terms of the CP- 289 ORF entries first. It then evaluates the route in terms of the 290 remaining, non-CP-ORF entries. The rules for the former are 291 described below. The rules for the latter are outside the scope of 292 this document. 294 The following route types can match a CP-ORF: 296 o IPv4-VPN 298 o IPv6-VPN 300 o L2VPN 302 In order for an IPv4-VPN route or IPv6-VPN route to match a CP-ORF, 303 all of the following conditions MUST be true: 305 o the route carries an RT whose value is the same as the CP-ORF VPN 306 Route Target 308 o the route prefix length is greater than or equal to the CP-ORF 309 Minlen plus 64 (i.e., the length of a VPN Route Distinguisher) 311 o the route prefix length is less than or equal to the CP-ORF Maxlen 312 plus 64 (i.e., the length of a VPN Route Distinguisher) 314 o ignoring the Route Distinguisher, the leading bits of the route 315 prefix are identical to the leading bits of the CP-ORF Host 316 Address. CP-ORF Minlen defines the number of bits that must be 317 identical. 319 The BGP speaker ignores Route Distinguishers when determining whether 320 a prefix matches a host address. For example, assume that a CP-ORF 321 carries the following information: 323 o Minlen equal to 1 325 o Maxlen equal to 32 327 o Host Address equal to 192.0.2.1 328 Assume also that Loc-RIB contains routes for the following IPv4-VPN 329 prefixes, and that all of these routes carry an RT whose value is the 330 same as the CP-ORF VPN Route Target: 332 o 1:0.0.0.0/64. 334 o 2:192.0.2.0/88 336 o 3:192.0.2.0/89 338 For the purposes of this evaluation, 2:192.0.2.0/88 and 339 3:192.0.2.0/89 match 192.0.2.1. This is because the search algorithm 340 ignores Route Distinguishers. However, 1:0.0.0.0/64 does not cover 341 192.0.2.1, because its length (64) is less than the CP-ORF Minlen (1) 342 plus the length of an L3VPN Route Distinguisher (64). 344 In order for an EVPN route to match a CP-ORF, all of the following 345 conditions MUST be true: 347 o the EVPN route type is equal to the CP-ORF Route Type 349 o the route carries an RT whose value is equal to the CP-ORF VPN 350 Route Target 352 In addition, if the CP-ORF Route Type is equal to MAC/IP 353 Advertisement Route, the following conditions also MUST be true: 355 o the EVPN Route MAC Address Length is greater than or equal to the 356 CP-ORF Minlen plus 64 (i.e., the length of a VPN Route 357 Distinguisher) 359 o the EVPN Route MAC Address Length is less than or equal to the CP- 360 ORF Maxlen plus 64 (i.e., the length of a VPN Route Distinguisher) 362 o ignoring the Route Distinguisher, the leading bits of the EVPN 363 Route MAC Address are identical to the leading bits of the CP-ORF 364 Host Address. CP-ORF Minlen defines the number of bits that must 365 be identical. 367 If a route matches the selection criteria of a CP-ORF entry, and it 368 does not violate any subsequent rule specified by the Outbound Filter 369 (e.g., rules that reflect local policy, or rules that are due to RT- 370 Constrains), the BGP speaker places the route into the Adj-RIB-Out. 371 In Adj-RIB-Out, the BGP speaker adds the CP-ORF Import Route Target 372 to the list of Route Targets that the route already carries. The BGP 373 speaker also adds a Transitive Opaque Extended Community [RFC4360] 374 with subtype equal to CP-ORF. As a result of being placed in Adj- 375 RIB-Out, the route is advertised to the peer associated with the Adj- 376 RIB-Out. 378 Receiving CP-ORF entries with REMOVE or REMOVE-ALL Actions may cause 379 a route that has previously been installed in a particular Adj-RIB- 380 Out be excluded from that Adj-RIB-Out. In this case, as specified in 381 [RFC4271], "the previously advertised route in that Adj-RIB-Out MUST 382 be withdrawn from service by means of an UPDATE message". 384 [RFC5291] states that a BGP speaker should respond to a ROUTE REFRESH 385 message as follows: 387 "If the When-to-refresh indicates IMMEDIATE, then after processing 388 all the ORF entries carried in the message the speaker re-advertises 389 to the peer routes from the Adj-RIB-Out associated with the peer that 390 have the same AFI/SAFI as what is carried in the message, and taking 391 into account all the ORF entries for that AFI/SAFI received from the 392 peer. The speaker MUST re-advertise all the routes that have been 393 affected by the ORF entries carried in the message, but MAY also re- 394 advertise the routes that have not been affected by the ORF entries 395 carried in the message." 397 When the ROUTE-REFRESH message includes one or more CP-ORF entries, 398 the BGP speaker MUST re-advertise routes that have been affected by 399 ORF entries carried by the message. While the speaker MAY also re- 400 advertise the routes that have not been affected by the ORF entries 401 carried in the message, this memo RECOMMENDS not to re-advertise the 402 routes that have not been affected. 404 4. Applicability In Virtual Hub-and-Spoke VPNs 406 In a Virtual Hub-and-Spoke environment, VPN sites are attached to 407 Provider Edge (PE) routers. For a given VPN, a PE router acts in 408 exactly one of the following roles: 410 o As neither a V-hub nor a V-Spoke 412 o As a V-hub 414 o As a V-spoke 416 To illustrate CP-ORF operation in conjunction with Virtual Hub-and- 417 Spoke assume the following: 419 o One of the sites in a particular VPN, RED-VPN, is connected to a 420 PE that acts as neither a V-hub nor a V-Spoke for RED-VPN. We 421 refer to this PE as PE1. 423 o Another site in RED-VPN is connected to another PE, and that PE 424 acts as a V-hub for RED-VPN. We refer to this PE as V-hub1. 426 o Yet another site in RED-VPN is connected to another PE, and that 427 PE acts as a V-spoke for RED-VPN. We refer to this PE as 428 V-spoke1. 430 All of these PEs advertise RED-VPN routes to a route reflector (RR). 431 They mark these routes with a route target, which we will call RT- 432 RED. In particular, PE1 advertises a RED-VPN route to a prefix that 433 we will call P. P covers a host address, that we will call H. 435 For the purpose of illustration also assume that the PEs and the RRs 436 use Route Target Constraint [RFC4684]. 438 V-hub1 serves the RED-VPN. Therefore, V-hub1 advertises a VPN IP 439 default route for the RED-VPN to the RR, carrying the route target 440 RT-RED-FROM-HUB1. 442 V-spoke1 establishes a BGP session with the RR, negotiating the CP- 443 ORF capability, as well as the Multiprotocol Extensions Capability 444 [RFC4760]. Upon establishment of the BGP session, the RR does not 445 advertise any routes to V-spoke1. The RR will not advertise any 446 routes until it receives either a ROUTE-REFRESH message or a BGP 447 UPDATE message containing a Route Target Membership NLRI [RFC4684]. 449 Immediately after the BGP session is established, V-spoke1 sends the 450 RR a BGP UPDATE message containing a Route Target Membership NLRI. 451 The Route Target Membership NLRI specifies RT-RED-FROM-HUB1 as its 452 route target. In response to the BGP-UPDATE message, the RR 453 advertises the VPN IP default route for the RED-VPN to V-spoke1. 454 This route carries the route target RT-RED-FROM-HUB1. V-spoke1 455 subjects this route to its import policy and accepts it because it 456 carries the route target RT-RED-FROM-HUB1. 458 Now, V-spoke1 begins normal operation, sending all of its RED-VPN 459 traffic through V-hub1. At some point, V-spoke1 determines that it 460 might benefit from a more direct route to H. (Criteria by which 461 V-spoke1 determines that it needs a more direct route to H are beyond 462 the scope of this document.) 464 In order to discover a more direct route, V-spoke1 assigns a unique 465 numeric identifier to H. V-spoke1 then sends a ROUTE-REFRESH message 466 to the RR, containing the following information: 468 o AFI is equal to IPv4 or IPv6, as appropriate 470 o SAFI is equal to "MPLS-labeled VPN address" 471 o When-to-refresh is equal IMMEDIATE 473 o Action is equal to ADD 475 o Match is equal to PERMIT 477 o ORF Type is equal to CP-ORF 479 o CP-ORF Sequence is equal to the identifier associated with H 481 o CP-ORF Minlen is equal to 1 483 o CP-ORF Maxlen is equal to 32 or 128, as appropriate 485 o CP-ORF VPN Route Target is equal to RT-RED 487 o CP-ORF Import Route Target is equal to RT-RED-FROM-HUB1 489 o CP-ORF Route Type is equal to 0 (i.e., undefined) 491 o CP-ORF Host Address is equal H 493 Upon receipt of the ROUTE-REFRESH message, the RR MUST ensure that it 494 carries all routes belonging to the RED-VPN. In at least one special 495 case, where all of the RR clients are V-spokes and none of the RR 496 clients are V-hubs, the RR will lack some or all of the required RED- 497 VPN routes. So, the RR sends a BGP UPDATE message containing a Route 498 Target Membership NLRI for VPN-RED to all of its peers. This causes 499 the peers to advertise VPN-RED routes to the RR, if they have not 500 done so already. 502 Next, the RR adds the received CP-ORF to the Outbound Filter 503 associated with V-spoke1. Using the procedures in Section 3, the RR 504 determines whether any of the routes in its Loc-RIB satisfy the 505 selection criteria of the newly updated Outbound Filter. If any 506 routes satisfy the match criteria, they are added to the Adj-RIB-Out 507 associated with V-spoke1. In Adj-RIB-Out, the RR adds RT-RED-FROM- 508 HUB1 to the list of Route Targets that the route already carries. 509 The RR also adds a Transitive Opaque Extended Community [RFC4360] 510 with subtype equal to CP-ORF. Finally, RR advertises the newly added 511 routes to V-spoke1. In this example, the RR advertises P to V-Spoke1 512 with a next-hop of PE1. 514 V-spoke1 subjects the advertised routes to its import policy and 515 accepts them because they carry the route target RT-RED-FROM-HUB1. 517 V-spoke1 may repeat this process whenever it discovers another flow 518 that might benefit from a more direct route to its destination. 520 4.1. Multicast Considerations 522 When applying Multicast VPN [RFC6513][RFC6514] procedures, routes 523 bearing a Transitive Opaque Extended Community [RFC4360] with subtype 524 equal to CP-ORF MUST NOT be used to determine Eligible Upstream 525 Multicast Hops (UMH). 527 5. Applicability In BGP/MPLS Ethernet VPN (EVPN) 529 In a EVPN environment, CE devices are attached to Provider Edge (PE) 530 routers. A CE can be a host, a router or a switch. For a given EVPN 531 Instance (EVI), a PE router acts in exactly one of the following 532 roles: 534 o As neither a Default MAC Gateway (DMG) nor a Spoke 536 o As a DMG 538 o As a Spoke 540 To illustrate CP-ORF operation in the EVPN environment assume the 541 following: 543 o A CE device in a particular EVI, RED-EVI, is connected to a PE 544 that acts as neither a DMG nor a Spoke for RED-EVI. We refer to 545 this PE as PE1. 547 o Another CE device in RED-EVI is connected to another PE, and that 548 PE acts as a DMG for RED-EVI. We refer to this PE as DMG1. 550 o Yet another CE device in RED-EVI is connected to another PE, and 551 that PE acts as a Spoke for RED-EVI. We refer to this PE as 552 Spoke1. 554 All of these PEs advertise RED-EVI routes to a RR. They mark these 555 routes with a route target, which we will call RT-RED. In 556 particular, PE1 advertises a RED-EVI route to a MAC Address that we 557 will call M. 559 The RED-EVI VRFs on all of these PEs are provisioned to import EVPN 560 routes that carry RT-RED. 562 Since DMG1 acts as a DMG for RED-EVI, DMG1 advertises a Unknown MAC 563 Route (UMR) for the RED-EVI to the RR, carrying the route target RT- 564 RED. The UMR is characterized as follows: 566 o EVPN Route Type is equal to MAC/IP Advertisement Route 567 o MAC address length is equal to 0 569 o IP address length is equal to 0 571 Spoke1 establishes a BGP session with the RR, negotiating the CP-ORF 572 capability, as well as the Multiprotocol Extensions Capability 573 [RFC4760]. Upon establishment of the BGP session, the RR does not 574 advertise any routes to Spoke1. The RR will not advertise any routes 575 until it receives a ROUTE-REFRESH message. 577 Immediately after the BGP session is established, Spoke1 sends the RR 578 a ROUTE REFRESH message containing the following information: 580 o AFI is equal to L2VPN 582 o SAFI is equal to BGP EVPN 584 o When-to-refresh is equal IMMEDIATE 586 o Action is equal to ADD 588 o Match is equal to PERMIT 590 The ROUTE REFRESH message also contains four ORF entries. The first 591 ORF entry contains the following information: 593 o ORF Type is equal to CP-ORF 595 o CP-ORF Sequence is equal 1 597 o CP-ORF Minlen is equal to 0 599 o CP-ORF Maxlen is equal to 0 601 o CP-ORF VPN Route Target is equal to RT-RED 603 o CP-ORF Import Route Target is equal to RT-RED 605 o CP-ORF Route Type is equal to 1 (Ethernet Autodiscovery Route) 607 The second ORF entry contains the following information: 609 o ORF Type is equal to CP-ORF 611 o CP-ORF Sequence is equal 2 613 o CP-ORF Minlen is equal to 0 614 o CP-ORF Maxlen is equal to 0 616 o CP-ORF VPN Route Target is equal to RT-RED 618 o CP-ORF Import Route Target is equal to RT-RED 620 o CP-ORF Route Type is equal to 2 (MAC/IP Advertisement Route) 622 The third ORF entry contains the following information: 624 o ORF Type is equal to CP-ORF 626 o CP-ORF Sequence is equal 3 628 o CP-ORF Minlen is equal to 0 630 o CP-ORF Maxlen is equal to 0 632 o CP-ORF VPN Route Target is equal to RT-RED 634 o CP-ORF Import Route Target is equal to RT-RED 636 o CP-ORF Route Type is equal to 3 (Inclusive Multicast Route) 638 The fourth ORF entry contains the following information: 640 o ORF Type is equal to CP-ORF 642 o CP-ORF Sequence is equal 4 644 o CP-ORF Minlen is equal to 0 646 o CP-ORF Maxlen is equal to 0 648 o CP-ORF VPN Route Target is equal to RT-RED 650 o CP-ORF Import Route Target is equal to RT-RED 652 o CP-ORF Route Type is equal to 4 (Ethernet Segment Route) 654 In response to the ROUTE REFRESH message, the RR advertises the 655 following to V-spoke1: 657 o All Ethernet Autodiscovery Routes belonging to RED-EVI 659 o A UMR advertised by DMG1 and belonging to RED-EVI 661 o All Inclusive Multicast Routes belonging to RED-EVI 662 o All Ethernet Segment Routes belonging to RED-EVI 664 All of these routes carries the route target RT-RED. Spoke1 subjects 665 these routes to its import policy and accepts them because they carry 666 the route target RT-RED. 668 Now, Spoke1 begins normal operation, sending all of its RED-VPN 669 traffic through DMG1. At some point, Spoke1 determines that it might 670 benefit from a more direct route to M. (Criteria by which Spoke1 671 determines that it needs a more direct route to M are beyond the 672 scope of this document.) 674 In order to discover a more direct route, Spoke1 assigns a unique 675 numeric identifier to M. V-spoke1 then sends a ROUTE-REFRESH message 676 to the RR, containing the following information: 678 o AFI is equal to L2VPN 680 o SAFI is equal to BGP EVPN 682 o When-to-refresh is equal IMMEDIATE 684 o Action is equal to ADD 686 o Match is equal to PERMIT 688 o ORF Type is equal to CP-ORF 690 o CP-ORF Sequence is equal to the identifier associated with M 692 o CP-ORF Minlen is equal to 1 694 o CP-ORF Maxlen is equal to 48 696 o CP-ORF VPN Route Target is equal to RT-RED 698 o CP-ORF Import Route Target is equal to RT-RED 700 o CP-ORF Route Type is equal to 2 (i.e., MAC/IP Advertisement Route) 702 o CP-ORF Host Address is equal M 704 Next, the RR adds the received CP-ORF to the Outbound Filter 705 associated with Spoke1. Using the procedures in Section 3, the RR 706 determines whether any of the routes in its Loc-RIB satisfy the 707 selection criteria of the newly updated Outbound Filter. If any 708 routes satisfy the match criteria, they are added to the Adj-RIB-Out 709 associated with Spoke1. The RR adds a Transitive Opaque Extended 710 Community [RFC4360] with subtype equal to CP-ORF. Note that as these 711 routes are added to the Adj-RIB-Out, the RR does not change the list 712 of Route Targets that the route already carries. Finally, RR 713 advertises the newly added routes to V-spoke1. In this example, the 714 RR advertises M to V-Spoke1 with a next-hop of PE1. 716 Spoke1 subjects the advertised routes to its import policy and 717 accepts them because they carry the route target RT-RED. 719 Spoke1 may repeat this process whenever it discovers another flow 720 that might benefit from a more direct route to its destination. 722 Note that in general an EVI may have more than one DMG, in which case 723 each spoke would receive a UMR from each of them. The spoke should 724 follow its local route selection procedures to select one of them as 725 the "best", and use the selected one. 727 6. Clean-up 729 Each CP-ORF consumes memory and compute resources on the device that 730 supports it. Therefore, in order to obtain optimal performance, BGP 731 speakers periodically evaluate all CP-ORFs that they have originated 732 and remove unneeded CP-ORFs. The criteria by which a BGP speaker 733 identifies unneeded CP-ORF entries is a matter of local policy, and 734 is beyond the scope of this document. 736 7. IANA Considerations 738 IANA is requested to add a new ORF type to the BGP Outbound Route 739 Filtering (ORF) Registry [IANA.ORF]. The name of the new ORF type is 740 CP-ORF. The value of the new ORF type is TBD, to be drawn from the 741 "first come first served" range (64-127). 743 IANA is also requested to add a new sub-type to the Transitive Opaque 744 Extended Community Registry [IANA.TOEC]. The name of the new sub- 745 type is CP-ORF. The value of the new subtype is TBD, to be drawn 746 from the "first come first served" range (0x00-0xbf ). 748 8. Security Considerations 750 Each CP-ORF consumes memory and compute resources on the device that 751 supports it. Therefore, a device supporting CP-ORF take the 752 following steps to protect itself from oversubscription: 754 o When negotiating the ORF capability, advertise willingness to 755 receive the CP-ORF only to known, trusted iBGP peers 757 o Enforce a per-peer limit on the number of CP-ORFs that can be 758 installed at any given time. Ignore all requests to add CP-ORFs 759 beyond that limit 761 9. Acknowledgements 763 The authors wish to acknowledge Han Nguyen and James Uttaro for their 764 comments and contributions. 766 10. Normative References 768 [I-D.ietf-l2vpn-evpn] 769 Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. 770 Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- 771 evpn-08 (work in progress), September 2014. 773 [IANA.AFI] 774 IANA, "Address Family Numbers", 775 . 778 [IANA.ORF] 779 IANA, "BGP Outbound Route Filtering (ORF) Types", 780 . 783 [IANA.SAFI] 784 IANA, "Subsequent Address Family Identifiers (SAFI) 785 Parameters", . 788 [IANA.TOEC] 789 IANA, "Transitive Opaque Extended Community Sub-Types", 790 . 793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 794 Requirement Levels", BCP 14, RFC 2119, March 1997. 796 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 797 Protocol 4 (BGP-4)", RFC 4271, January 2006. 799 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 800 Communities Attribute", RFC 4360, February 2006. 802 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 803 Networks (VPNs)", RFC 4364, February 2006. 805 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 806 R., Patel, K., and J. Guichard, "Constrained Route 807 Distribution for Border Gateway Protocol/MultiProtocol 808 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 809 Private Networks (VPNs)", RFC 4684, November 2006. 811 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 812 "Multiprotocol Extensions for BGP-4", RFC 4760, January 813 2007. 815 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 816 Capability for BGP-4", RFC 5291, August 2008. 818 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 819 VPNs", RFC 6513, February 2012. 821 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 822 Encodings and Procedures for Multicast in MPLS/BGP IP 823 VPNs", RFC 6514, February 2012. 825 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 826 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 827 VPNs", RFC 7024, October 2013. 829 Authors' Addresses 831 Huajin Jeng 832 AT&T 834 Email: hj2387@att.com 836 Luay Jalil 837 Verizon 839 Email: luay.jalil@verizon.com 841 Ron Bonica 842 Juniper Networks 843 2251 Corporate Park Drive 844 Herndon, Virginia 20170 845 USA 847 Email: rbonica@juniper.net 848 Yakov Rekhter 849 Juniper Networks 850 1194 North Mathilda Ave. 851 Sunnyvale, California 94089 852 USA 854 Email: yakov@juniper.net 856 Keyur Patel 857 Cisco Systems 858 170 W. Tasman Drive 859 San Jose, California 95134 860 USA 862 Email: keyupate@cisco.com 864 Lucy Yong 865 Huawei Technologies 866 Austin, Texas 867 USA 869 Email: lucy.yong@huawei.com 871 Xiaohu Xu 872 Huawei Technologies 873 Beijing 874 China 876 Email: xuxiaohu@huawei.com