idnits 2.17.00 (12 Aug 2021) /tmp/idnits845/draft-wang-idr-vpn-prefix-orf-03.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 : ---------------------------------------------------------------------------- ** There are 66 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o In Option B cross-domain scenario, NEXT_HOP attribute will be changed by ASBRs and cannot identify the source PE. A new Extended Community: Source PE Extended Community is needed to preserve the NEXT_HOP attribute before being rewritten by ASBRs. If a BGP UPDATE message already contains Source PE Extended Community, the community MUST not be changed during the BGP UPDATE message advertisement procedure, so that the source PE information can be preserved by the Source PE Extended Community in BGP. -- The document date (April 13, 2022) is 31 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) == Missing Reference: 'RFC7024' is mentioned on line 122, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-inter-subnet-forwarding' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC4360' is defined on line 659, but no explicit reference was found in the text == Outdated reference: draft-ietf-bess-evpn-inter-subnet-forwarding has been published as RFC 9135 ** Downref: Normative reference to an Informational draft: draft-wang-idr-vpn-routes-control-analysis (ref. 'I-D.wang-idr-vpn-routes-control-analysis') Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group W. Wang 3 Internet-Draft A. Wang 4 Intended status: Standards Track China Telecom 5 Expires: October 15, 2022 H. Wang 6 Huawei Technologies 7 G. Mishra 8 Verizon Inc. 9 S. Zhuang 10 J. Dong 11 Huawei Technologies 12 April 13, 2022 14 VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 15 draft-wang-idr-vpn-prefix-orf-03 17 Abstract 19 This draft defines a new Outbound Route Filter (ORF) type, called the 20 VPN Prefix ORF. The described VPN Prefix ORF mechanism is applicable 21 when the VPN routes from different VRFs are exchanged via one shared 22 BGP session (e.g., routers in a single-domain connect via Route 23 Reflector). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 15, 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Operation process of VPN Prefix ORF mechanism on sender . . . 4 63 4.1. Intra-domain Scenarios and Solutions . . . . . . . . . . 5 64 4.1.1. Scenario-1 and Solution (Unique RD, One RT) . . . . . 5 65 4.1.2. Scenario-2 and Solution (Unique RD, Multiple RTs) . . 7 66 4.1.3. Scenario-3 and Solution (Universal RD) . . . . . . . 8 67 5. VPN Prefix ORF Encoding . . . . . . . . . . . . . . . . . . . 9 68 5.1. Source PE TLV . . . . . . . . . . . . . . . . . . . . . . 10 69 5.2. Route Target TLV . . . . . . . . . . . . . . . . . . . . 11 70 6. Operation process of VPN Prefix ORF mechanism on receiver . . 11 71 7. Withdraw of VPN Prefix ORF entries . . . . . . . . . . . . . 12 72 8. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9. Implementation Considerations . . . . . . . . . . . . . . . . 13 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14 77 13. Normative References . . . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 [I-D.wang-idr-vpn-routes-control-analysis] analysis the scenarios and 83 necessaries for VPN routes control in the shared BGP session. This 84 draft analyzes the existing solutions and their limitations for these 85 scenarios, proposes the new VPN Prefix ORF solution to meet the 86 requirements that described in section 8 of 87 [I-D.wang-idr-vpn-routes-control-analysis]. 89 Now, there are several solutions can be used to alleviate these 90 problem: 92 o Route Target Constraint (RTC) as defined in [RFC4684] 94 o Address Prefix ORF as defined in [RFC5292] 96 o CP-ORF mechanism as defined in [RFC7543] 97 o PE-CE edge peer Maximum Prefix 99 o Configure the Maximum Prefix for each VRF on edge nodes 101 However, there are limitations to existing solutions: 103 1) Route Target Constraint 105 RTC can only filter the VPN routes from the uninterested VRFs, if the 106 "trashing routes" come from the interested VRF, filter on RTs will 107 erase all prefixes from this VRF. 109 2) Address Prefix ORF 111 Using Address Prefix ORF to filter VPN routes need to pre- 112 configuration, but it is impossible to know which prefix may cause 113 overflow in advance. 115 3) CP-ORF Mechanism 117 [RFC7543] defines the Covering Prefixes ORF (CP-ORF). A BGP speaker 118 sends a CP-ORF to a peer in order to pull routes that cover a 119 specified host address. A prefix covers a host address if it can be 120 used to forward traffic towards that host address. 122 CP-ORF is applicable in Virtual Hub-and-Spoke[RFC7024] VPN and also 123 the BGP/MPLS Ethernet VPN (EVPN) [RFC7432]networks, but its main aim 124 is also to get the wanted VPN prefixes and can't be used to filter 125 the overwhelmed VPN prefixes dynamically. 127 4) PE-CE edge peer Maximum Prefix 129 The BGP Maximum-Prefix feature is used to control how many prefixes 130 can be received from a neighbor. By default, this feature allows a 131 router to bring down a peer when the number of received prefixes from 132 that peer exceeds the configured Maximum-Prefix limit. This feature 133 is commonly used for external BGP peers. If it is applied to 134 internal BGP peers, for example the VPN scenarios, all the VPN routes 135 from different VRFs will share the common fate, which is not 136 desirable for the fining control of the VPN Prefixes advertisement. 138 5) Configure the Maximum Prefix for each VRF on edge nodes 140 When a VRF overflows, it stops the import of routes and log the extra 141 VPN routes into its RIB. However, PEs still need to parse the BGP 142 updates. These processes will cost CPU cycles and further burden the 143 overflowing PE. 145 This draft defines a new ORF-type, called the VPN Prefix ORF. This 146 mechanism is event-driven and does not need to be pre-configured. 147 When a VRF of a router overflows, the router will find out the VPN 148 prefix (RD, RT, source PE, etc.) of offending VPN routes in this VRF, 149 and send a VPN Prefix ORF to its BGP peer that carries the relevant 150 information. If a BGP speaker receives a VPN Prefix ORF entry from 151 its BGP peer, it will filter the VPN routes it tends to send 152 according to the entry. 154 The purpose of this mechanism is to control the outrage within the 155 minimum range and avoid churn effects when a VRF on a device in the 156 network overflows. 158 VPN Prefix ORF is applicable when the VPN routes from different VRFs 159 are exchanged via one shared BGP session. 161 2. Conventions used in this document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119] . 167 3. Terminology 169 The following terms are defined in this draft: 171 o RD: Route Distinguisher, defined in [RFC4364] 173 o ORF: Outbound Route Filter, defined in [RFC5291] 175 o AFI: Address Family Identifier, defined in [RFC4760] 177 o SAFI: Subsequent Address Family Identifier, defined in [RFC4760] 179 o EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432] 181 o RR: Router Reflector, provides a simple solution to the problem of 182 IBGP full mesh connection in large-scale IBGP implementation. 184 o VRF: Virtual Routing Forwarding, a virtual routing table based on 185 VPN instance. 187 4. Operation process of VPN Prefix ORF mechanism on sender 189 The operation of VPN Prefix ORF mechanism on each device is 190 independent, each of them makes a local judgement to determine 191 whether it needs to send VPN Prefix ORF to its peers. The operators 192 need to make sure the algorithms in different devices consistent. On 193 PE, each VRF has a prefix limit, and routes associated with each tuple has a pre-configurated quota. 196 o when routes associated with tuple past the quota 197 but the prefix limit of VRF is not exceeded, PE should send 198 warnings to the operator, and the VPN Prefix ORF mechanism should 199 not be triggered. 201 o when routes associated with tuple past the quota 202 and the prefix limit is exceeded and there is no other VRFs on 203 offended PE need VPN routes with this RD, they should be dropped 204 via VPN Prefix ORF mechanism. 206 When the VPN Prefix ORF mechanism is triggered, the device must send 207 an alarm information to network operators. 209 4.1. Intra-domain Scenarios and Solutions 211 For intra-AS VPN deployment, there are three scenarios: 213 o RD is allocated per VPN per PE, each VRF only import one RT (see 214 Section 4.1.1). 216 o RD is allocated per VPN per PE. Multiple RTs are associated with 217 such VPN routes, and are imported into different VRFs in other 218 devices(see Section 4.1.2). 220 o RD is allocated per VPN, each VRF imports one/multiple RTs(see 221 Section 4.1.3). 223 The following sections will describe solutions to the above scenarios 224 in detail. 226 4.1.1. Scenario-1 and Solution (Unique RD, One RT) 228 In this scenario, RD is allocated per VPN per PE. The offending VPN 229 routes only carry one RT. We assume the network topology is shown in 230 Figure 1. 232 +------------------------------------------------------------------------+ 233 | | 234 | | 235 | +-------+ +-------+ | 236 | | PE1 +----------------+ +-----------------+ PE4 | | 237 | +-------+ | | +-------+ | 238 | VPN1(RD11,RT1) | | VPN2(RD12,RT2) | 239 | VPN2(RD12,RT2) | | | 240 | +-+----+-+ | 241 | | RR | | 242 | +-+----+-+ | 243 | | | | 244 | | | | 245 | +-------+ | | +-------+ | 246 | | PE2 +----------------+ +-----------------+ PE3 | | 247 | +-------+ +-------+ | 248 | VPN1(RD21,RT1) VPN1(RD31,RT1) | 249 | VPN2(RD22,RT2,RT1) VPN2(RD32,RT2) | 250 | | 251 | AS 100 | 252 | | 253 +------------------------------------------------------------------------+ 254 Figure 1 Network Topology of Scenario-1 256 When PE3 sends excessive VPN routes with RT1, while both PE1 and PE2 257 import VPN routes with RT1, the process of offending VPN routes will 258 influence performance of VRFs on PEs. PEs and RR should have some 259 mechanisms to identify and control the advertisement of offending VPN 260 routes. 262 On PE1, each VRF has a prefix limit, and each tuple 263 imported into VRF has a quota. When routes associated with tuple past the quota but the prefix limit of VPN1 VRF is not 265 exceeded, PE1 sends a warning message to the operator, and the VPN 266 Prefix ORF mechanism should not be triggered. After the prefix limit 267 of VPN1 VRF is exceeded, due to there is no other VRFs on PE1 need 268 the VPN routes with RT1, PE1 will generate a BGP ROUTE-REFRESH 269 message contains a VPN Prefix ORF entry, and send to RR. RR will 270 withdraw and stop to advertise such offending VPN routes (RD31, RT1, 271 source PE is PE3) to PE1. 273 On PE2, both VPN1 VRF and VPN2 VRF import VPN routes with RT1. If 274 PE2 triggers VPN Prefix ORF mechanism when VPN1 VRF overflows, VPN2 275 VRF cannot receive VPN routes with RT1 as well. PE2 should not 276 trigger the VPN Prefix ORF mechanism to RR (RD31, RT1, source PE is 277 PE3) until all the VRFs that import RT1 on it overflow. 279 4.1.2. Scenario-2 and Solution (Unique RD, Multiple RTs) 281 In this scenario, RD is allocated per VPN per PE. Multiple RTs are 282 associated with the offending VPN routes, and be imported into 283 different VRFs in other devices. We assume the network topology is 284 shown in Figure 2. 286 +------------------------------------------------------------------------+ 287 | | 288 | | 289 | +-------+ +-------+ | 290 | | PE1 +----------------+ +-----------------+ PE4 | | 291 | +-------+ | | +-------+ | 292 | VPN1(RD11,RT1) | | VPN2(RD42,RT2) | 293 | VPN2(RD12,RT2) | | | 294 | +-+----+-+ | 295 | | RR | | 296 | +-+----+-+ | 297 | | | | 298 | | | | 299 | +-------+ | | +-------+ | 300 | | PE2 +----------------+ +-----------------+ PE3 | | 301 | +-------+ +-------+ | 302 | VPN1(RD21,RT1) VPN1(RD31,RT1,RT2) | 303 | VPN2(RD32,RT2) | 304 | | 305 | AS 100 | 306 | | 307 +------------------------------------------------------------------------+ 308 Figure 2 Network Topology of Scenario-2 310 When PE3 sends excessive VPN routes with RT1 and RT2, while both PE1 311 and PE2 import VPN routes with RT1, and PE1 also imports VPN routes 312 with RT2. 314 On PE1, when routes associated with tuple past the quota 315 but the prefix limit of VPN1 VRF is not exceeded, PE1 sends a warning 316 to the operator. When the prefix limit of VPN1 VRF is exceeded, if 317 the VPN2 VRF does not reach its limit at the same time, PE1 should 318 still not send out the trigger message, because if it does so, the 319 VPN2 VRF can't receive the VPN routes too (RR will filter all the VPN 320 prefixes that contain RT1). PE1 just discard the offending VPN 321 routes locally. PE1 should only generate a BGP ROUTE-REFRESH message 322 contains a VPN Prefix ORF entry(RD31, RT1, RT2, comes from PE3) when 323 both the VRFs that import such prefixes are overflow. 325 On PE2, due to there is only one VRF imports VPN routes with RT1. If 326 it overflows, it will trigger VPN Prefix ORF (RD31, RT1, comes from 327 PE3) mechanisms. RR will withdraw and stop to advertise such 328 offending VPN routes to PE2. 330 4.1.3. Scenario-3 and Solution (Universal RD) 332 In this scenario, RD is allocated per VPN. One/Multiple RTs are 333 associated with the offending VPN routes, and be imported into 334 different VRFs in other devices. We assume the network topology is 335 shown in Figure 3. 337 +------------------------------------------------------------------------+ 338 | | 339 | | 340 | +-------+ +-------+ | 341 | | PE1 +----------------+ +-----------------+ PE4 | | 342 | +-------+ | | +-------+ | 343 | VPN1(RD1,RT1) | | VPN2(RD12,RT2) | 344 | VPN2(RD12,RT2) | | | 345 | +-+----+-+ | 346 | | RR | | 347 | +-+----+-+ | 348 | | | | 349 | | | | 350 | +-------+ | | +-------+ | 351 | | PE2 +----------------+ +-----------------+ PE3 | | 352 | +-------+ +-------+ | 353 | VPN1(RD1,RT1) VPN1(RD1,RT1,RT2) | 354 | VPN2(RD32,RT2) | 355 | | 356 | AS 100 | 357 | | 358 +------------------------------------------------------------------------+ 359 Figure 3 Network Topology of Scenario-3 361 When PE3 sends excessive VPN routes with RD1 and attached RT1 and 362 RT2, while both PE1 and PE2 import VPN routes with RT1, the process 363 of offending VPN routes will influence performance of VRFs on PEs. 365 When PE2 overflows and PE1 does not overflow. PE2 triggers the VPN 366 Prefix ORF message (RD1, RT1, comes from PE3). Using Source PE and 367 RD, RR will only withdraw and stop to advertise VPN routes (RD1, RT1) 368 come from PE3 to PE2. The communication between PE2 and PE1 for VPN1 369 will not be influenced. 371 5. VPN Prefix ORF Encoding 373 In this section, we defined a new ORF type called VPN Prefix Outbound 374 Route Filter (VPN Prefix ORF). The ORF entries are carried in the 375 BGP ROUTE-REFRESH message as defined in [RFC5291]. A BGP ROUTE- 376 REFRESH message can carry one or more ORF entries. The ROUTE-REFRESH 377 message which carries ORF entries contains the following fields: 379 o AFI (2 octets) 381 o SAFI (1 octet) 383 o When-to-refresh (1 octet): the value is IMMEDIATE or DEFER 385 o ORF Type (1 octet) 387 o Length of ORF entries (2 octets) 389 A VPN Prefix ORF entry contains a common part and type-specific part. 390 The common part is encoded as follows: 392 o Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL 394 o Match (1 bit): the value is PERMIT or DENY 396 o Reserved (5 bits) 398 VPN Prefix ORF also contains type-specific part. The encoding of the 399 type-specific part is shown in Figure 4. 401 +-----------------------------------------+ 402 | | 403 | Sequence (4 octets) | 404 | | 405 +-----------------------------------------+ 406 | | 407 | Route Distinguisher (8 octets) | 408 | | 409 +-----------------------------------------+ 410 | | 411 | Optional TLVs (variable) | 412 | | 413 +-----------------------------------------+ 415 Figure 4: VPN Prefix ORF type-specific encoding 417 o Sequence: identifying the order in which RD-ORF is generated. 419 o Route Distinguisher: distinguish the different user routes. The 420 VPN Prefix ORF filters the VPN routes it tends to send based on 421 Route Distinguisher. If RD is equal to 0, it means any VPN 422 prefixes. The VPN Prefix ORF message needn't carry any additional 423 Optional TLV then. 425 o Optional TLVs: carry the potential additional information to give 426 the extensibility of the VPN Prefix ORF mechanism. 428 Note that if the Action component of an ORF entry specifies REMOVE- 429 ALL, the ORF entry does not include the type-specific part. 431 When the BGP ROUTE-REFRESH message carries VPN Prefix ORF entries, it 432 must be set as follows: 434 o The ORF-Type MUST be set to VPN Prefix ORF. 436 o The AFI MUST be set to IPv4, IPv6, or Layer 2 VPN (L2VPN). 438 o If the AFI is set to IPv4 or IPv6, the SAFI MUST be set to MPLS- 439 labeled VPN address. 441 o If the AFI is set to L2VPN, the SAFI MUST be set to BGP EVPN. 443 o The Match field should be set to DENY when Sequence is not equal 444 to 0xFFFFFFFF, and be set to PERMIT when Sequence is equal to 445 0xFFFFFFFF. 447 5.1. Source PE TLV 449 Source PE TLV is defined to identify the source of the VPN routes. 450 Using source PE and RD to filter VPN routes together can achieve more 451 refined route control. The source PE TLV contains the following 452 types: 454 o In single-domain or Option C cross-domain scenario, NEXT_HOP 455 attribute is unchanged during routing transmission, so it can be 456 used as source address. 458 Type = 1, Length = 4 octets, value = NEXT_HOP. 460 Type = 2, Length = 16 octets, value = NEXT_HOP. 462 o In Option B cross-domain scenario, NEXT_HOP attribute will be 463 changed by ASBRs and cannot identify the source PE. A new 464 Extended Community: Source PE Extended Community is needed to 465 preserve the NEXT_HOP attribute before being rewritten by ASBRs. 466 If a BGP UPDATE message already contains Source PE Extended 467 Community, the community MUST not be changed during the BGP UPDATE 468 message advertisement procedure, so that the source PE information 469 can be preserved by the Source PE Extended Community in BGP. 471 Type = 3, Length = 6 octets, value = the value field of Source 472 PE Extended Community. 474 In principle, when the device can extract Source PE Extended 475 Community from the received BGP UPDATE message, the value of Source 476 PE TLV should be set to Source PE Extended Community; Otherwise, the 477 value should be set to NEXT_HOP. 479 5.2. Route Target TLV 481 Route Target TLV is defined to identify the RT of the offending VPN 482 routes. RT and RD can be used together to filter VPN routes when the 483 source VRF contains multiple RTs, and the VPN routes with different 484 RTs may be assigned to different VRFs on the receiver. The encoding 485 of Route Target TLV is following: 487 Type = 4, Length = 8*n (n is the number of RTs that the offending 488 VPN routes attached) octets, value = the RT of the offending VPN 489 routes. If multiple RTs are included, there must be an exact 490 match. 492 6. Operation process of VPN Prefix ORF mechanism on receiver 494 The receiver of VPN Prefix ORF entries may be a RR or PE. As it 495 receives the VPN Prefix ORF entries, it will check to find if it already existed in 497 its ORF-Policy table. If not, the receiver will add the VPN Prefix 498 ORF entries into its ORF-Policy table; otherwise, the receiver will 499 discard it. 501 Before the receiver send a VPN route, it should check its ORF-Policy 502 table with tuple of the VPN route. The Route 503 Distinguisher and Route Target information can be extracted directly 504 from the BGP UPDATE message. The source PE information should be 505 compared against the Source PE Extended Community if it is contained 506 in BGP UPDATE message, or else the NEXT_HOP. 508 If there is not a related VPN Prefix ORF entry in ORF-Policy table, 509 the receiver will send this VPN route; otherwise, the receiver will 510 stop sending that VPN route to the peer which sends this VPN Prefix 511 ORF entry. 513 7. Withdraw of VPN Prefix ORF entries 515 When the VPN Prefix ORF mechanism is triggered, the alarm information 516 will be generated and sent to the network operators. Operators 517 should manually configure the network to resume normal operation. 518 Due to devices can record the VPN Prefix ORF entries sent by each 519 VRF, operators can find the entries needs to be withdrawn, and 520 trigger the withdraw process as described in [RFC5291] manually. 521 After returning to normal, the device sends withdraw ORF entries to 522 its peers who have previously received ORF entries. 524 8. Applicability 526 We take the scenario in Section 4.1.1 as an example to illustrate how 527 to determine each field when the sender generates a VPN Prefix ORF 528 entry. We assume it is an IPv4 network. After PE1-PE4 and RR 529 advertising the Outbound Route Filtering Capability, each of PE1-PE4 530 should send a VPN Prefix ORF entry that means "PERMIT-ALL" as 531 follows: 533 o AFI is equal to IPv4. 535 o SAFI is equal to MPLS-labeled VPN address 537 o When-to-refresh is equal to IMMEDIATE 539 o ORF Type is equal to VPN Prefix ORF 541 o Length of ORF entries is equal to 13 543 o Action is equal to ADD 545 o Match is equal to PERMIT 547 o Sequence is equal to 0xFFFFFFFF 549 o Route Distinguisher is equal to 0 551 When the VPN Prefix ORF mechanism is triggered on PE1, PE1 will 552 generate a VPN Prefix ORF contains the following information: 554 o AFI is equal to IPv4 556 o SAFI is equal to MPLS-labeled VPN address 558 o When-to-refresh is equal to IMMEDIATE 560 o ORF Type is equal to VPN Prefix ORF 561 o Length of ORF entries is equal to 33 563 o Action is equal to ADD 565 o Match is equal to DENY 567 o Sequence is equal to 1 569 o Route Distinguisher is equal to RD31 571 o Optional TLV: 573 * Type is equal to 1 (Source PE TLV) 575 * Length is equal to 4 577 * value is equal to PE3's IPv4 address 579 * Type is equal to 4 (Route Target TLV) 581 * Length is equal to 8 583 * value is equal to RT1 585 9. Implementation Considerations 587 Before originating an VPN Prefix ORF message, the device should 588 compare the list of RD and RT(s) carried by VPN routes signaled for 589 filtering and the RD and RT(s) imported by not affected VRF(s). Once 590 they have intersection, the VPN Prefix ORF message MUST NOT be 591 originated. 593 10. Security Considerations 595 A BGP speaker will maintain the VPN Prefix ORF entries in an ORF- 596 Policy table, this behavior consumes its memory and compute 597 resources. To avoid the excessive consumption of resources, 598 [RFC5291] specifies that a BGP speaker can only accept ORF entries 599 transmitted by its interested peers. 601 11. IANA Considerations 603 This document defines a new Outbound Route Filter type - VPN Prefix 604 Outbound Route Filter (VPN Prefix ORF). The code point is from the 605 "BGP Outbound Route Filtering (ORF) Types". It is recommended to set 606 the code point of VPN Prefix ORF to 66. 608 This document also define a VPN Prefix ORF TLV type under "Border 609 Gateway Protocol (BGP) Parameters", three TLV types are defined: 611 +===========================+======+===========================+ 612 | Registry | Type | Meaning | 613 +===========================+======+===========================+ 614 |IPv4 Source PE TLV | 1 |IPv4 address for source PE.| 615 +---------------------------+------+---------------------------+ 616 |IPv6 Source PE TLV | 2 |IPv6 address for source PE.| 617 +---------------------------+------+---------------------------+ 618 |Source PE Extended | 3 |Source PE Extended | 619 |Community TLV | |Community | 620 +---------------------------+------+---------------------------+ 621 |Route Target TLV | 4 |Identify the RT of the | 622 | | |offending VPN routes | 623 +---------------------------+------+---------------------------+ 625 This document also requests a new Transitive Extended Community Type. 626 The new Transitive Extended Community Type name shall be "Source PE 627 Extended Community". 629 Under "Transitive Extended Community:" 630 Registry: "Source PE Extended Community" 631 Registration Procedure(s): First Come, First Served 632 0x0c Source PE Extended Community 634 12. Acknowledgement 636 Thanks Robert Raszuk, Jim Uttaro, Jakob Heitz, Jeff Tantsura, Rajiv 637 Asati, John E Drake, Gert Doering, Shuanglong Chen, Enke Chen and 638 Srihari Sangli for their valuable comments on this draft. 640 13. Normative References 642 [I-D.ietf-bess-evpn-inter-subnet-forwarding] 643 Sajassi, A., Salam, S., Thoria, S., Drake, J. E., and J. 644 Rabadan, "Integrated Routing and Bridging in Ethernet VPN 645 (EVPN)", draft-ietf-bess-evpn-inter-subnet-forwarding-15 646 (work in progress), July 2021. 648 [I-D.wang-idr-vpn-routes-control-analysis] 649 Wang, A., Wang, W., Mishra, G. S., Wang, H., Zhuang, S., 650 and J. Dong, "Analysis of VPN Routes Control in Shared BGP 651 Session", draft-wang-idr-vpn-routes-control-analysis-04 652 (work in progress), September 2021. 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, 656 DOI 10.17487/RFC2119, March 1997, 657 . 659 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 660 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 661 February 2006, . 663 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 664 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 665 2006, . 667 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 668 R., Patel, K., and J. Guichard, "Constrained Route 669 Distribution for Border Gateway Protocol/MultiProtocol 670 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 671 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 672 November 2006, . 674 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 675 "Multiprotocol Extensions for BGP-4", RFC 4760, 676 DOI 10.17487/RFC4760, January 2007, 677 . 679 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering 680 Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, 681 August 2008, . 683 [RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound 684 Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, 685 August 2008, . 687 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 688 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 689 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 690 2015, . 692 [RFC7543] Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, 693 "Covering Prefixes Outbound Route Filter for BGP-4", 694 RFC 7543, DOI 10.17487/RFC7543, May 2015, 695 . 697 Authors' Addresses 698 Wei Wang 699 China Telecom 700 Beiqijia Town, Changping District 701 Beijing, Beijing 102209 702 China 704 Email: weiwang94@foxmail.com 706 Aijun Wang 707 China Telecom 708 Beiqijia Town, Changping District 709 Beijing, Beijing 102209 710 China 712 Email: wangaj3@chinatelecom.cn 714 Haibo Wang 715 Huawei Technologies 716 Huawei Building, No.156 Beiqing Rd. 717 Beijing, Beijing 100095 718 China 720 Email: rainsword.wang@huawei.com 722 Gyan S. Mishra 723 Verizon Inc. 724 13101 Columbia Pike 725 Silver Spring MD 20904 726 United States of America 728 Phone: 301 502-1347 729 Email: gyan.s.mishra@verizon.com 731 Shunwan Zhuang 732 Huawei Technologies 733 Huawei Building, No.156 Beiqing Rd. 734 Beijing, Beijing 100095 735 China 737 Email: zhuangshunwan@huawei.com 738 Jie Dong 739 Huawei Technologies 740 Huawei Building, No.156 Beiqing Rd. 741 Beijing, Beijing 100095 742 China 744 Email: jie.dong@huawei.com