From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7543.txt | 1179 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1179 insertions(+) create mode 100644 doc/rfc/rfc7543.txt (limited to 'doc/rfc/rfc7543.txt') diff --git a/doc/rfc/rfc7543.txt b/doc/rfc/rfc7543.txt new file mode 100644 index 0000000..b3d5bc7 --- /dev/null +++ b/doc/rfc/rfc7543.txt @@ -0,0 +1,1179 @@ + + + + + + +Internet Engineering Task Force (IETF) H. Jeng +Request for Comments: 7543 AT&T +Category: Standards Track L. Jalil +ISSN: 2070-1721 Verizon + R. Bonica + Juniper Networks + K. Patel + Cisco Systems + L. Yong + Huawei Technologies + May 2015 + + + Covering Prefixes Outbound Route Filter for BGP-4 + +Abstract + + This document defines a new Outbound Route Filter (ORF) type, called + the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in Virtual + Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN + (EVPN) networks. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7543. + + + + + + + + + + + + + + + + +Jeng, et al. Standards Track [Page 1] + +RFC 7543 Covering Prefixes ORF May 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Applicability in Virtual Hub-and-Spoke VPNs . . . . . . . . . 10 + 4.1. Multicast Considerations . . . . . . . . . . . . . . . . 13 + 5. Applicability in BGP/MPLS Ethernet VPN (EVPN) . . . . . . . . 13 + 6. Clean-up . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 9.2. Informative References . . . . . . . . . . . . . . . . . 19 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + + + + + + + + + + + + + + + + + +Jeng, et al. Standards Track [Page 2] + +RFC 7543 Covering Prefixes ORF May 2015 + + +1. Introduction + + A BGP [RFC4271] speaker can send Outbound Route Filters (ORFs) + [RFC5291] to a peer. The peer uses ORFs to filter routing updates + that it sends to the BGP speaker. Using ORF, a BGP speaker can + realize a "route pull" paradigm in which the BGP speaker, on demand, + pulls certain routes from the peer. + + This document defines a new ORF-type, called the Covering Prefixes + ORF (CP-ORF). A BGP speaker sends a CP-ORF to a peer in order to + pull routes that cover a specified host address. A prefix covers a + host address if it can be used to forward traffic towards that host + address. Section 3 provides a more complete description of covering + prefix selection criteria. + + CP-ORF is applicable in Virtual Hub-and-Spoke VPNs [RFC7024] + [RFC4364]. It also is applicable BGP/MPLS Ethernet VPN (EVPN) + [RFC7432] networks. + +1.1. Terminology + + This document uses the following terms: + + o Address Family Identifier (AFI) - defined in [RFC4760] + + o Subsequent Address Family Identifier (SAFI) - defined in [RFC4760] + + o Route Target (RT) - defined in [RFC4364] + + o VPN-IP Default Route - defined in [RFC7024] + + o Virtual Hub (V-hub) - defined in [RFC7024] + + o Virtual Spoke (V-spoke) - defined in [RFC7024] + + o BGP/MPLS Ethernet VPN (EVPN) - defined in [RFC7432] + + o EVPN Instance (EVI) - defined in [RFC7432] + + o MAC - Media Access Control + + o Unknown MAC Route (UMR) - A regular EVPN MAC/IP Advertisement + route where the MAC Address Length is set to 48 and the MAC + address to 00:00:00:00:00:00 + + o Default MAC Gateway (DMG) - An EVPN Provider Edge (PE) that + advertises a UMR + + + + +Jeng, et al. Standards Track [Page 3] + +RFC 7543 Covering Prefixes ORF May 2015 + + +1.2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. CP-ORF Encoding + + RFC 5291 augments the BGP ROUTE-REFRESH message so that it can carry + ORF entries. When the ROUTE-REFRESH message carries ORF entries, it + includes the following fields: + + o AFI [IANA.AFI] + + o SAFI [IANA.SAFI] + + o When-to-refresh (IMMEDIATE or DEFERRED) + + o ORF Type + + o Length (of ORF entries) + + The ROUTE-REFRESH message also contains a list of ORF entries. Each + ORF entry contains the following fields: + + o Action (ADD, REMOVE, or REMOVE-ALL) + + o Match (PERMIT or DENY) + + The ORF entry may also contain Type-specific information. Type- + specific information is present only when the Action is equal to ADD + or REMOVE. It is not present when the Action is equal to REMOVE-ALL. + + When the BGP ROUTE-REFRESH message carries CP-ORF entries, the + following conditions MUST be true: + + o The ORF Type MUST be equal to CP-ORF (65). + + o The AFI MUST be equal to IPv4, IPv6, or Layer 2 VPN (L2VPN). + + o If the AFI is equal to IPv4 or IPv6, the SAFI MUST be equal to + MPLS-labeled VPN address. + + o If the AFI is equal to L2VPN, the SAFI MUST be equal to BGP EVPN. + + o The Match field MUST be equal to PERMIT. + + + + + +Jeng, et al. Standards Track [Page 4] + +RFC 7543 Covering Prefixes ORF May 2015 + + + Figure 1 depicts the encoding of the CP-ORF Type-specific + information. + + +--------------------------------+ + | Sequence (32 bits) | + +--------------------------------+ + | Minlen (8 bits) | + +--------------------------------+ + | Maxlen (8 bits) | + +--------------------------------+ + | VPN Route Target (64 bits) | + +--------------------------------+ + | Import Route Target (64 bits) | + +--------------------------------+ + | Route Type (8 bits) | + +--------------------------------+ + | Host Address | + | (0, 32, 48, or 128 bits) | + | .... | + +--------------------------------+ + + Figure 1: CP-ORF Type-Specific Encoding + + The CP-ORF recipient uses the following fields to select routes + matching the CP-ORF: + + o Sequence: the relative position of a CP-ORF entry among other + CP-ORF entries + + o Minlen: the minimum length of the selected route (measured in + bits) + + o Maxlen: the maximum length of the selected route (measured in + bits) + + o VPN Route Target: the VPN Route Target carried by the selected + route + + o Route Type: the type of the selected route + + o Host Address: the address covered by the selected route + + See Section 3 for details. + + The CP-ORF recipient marks routes that match CP-ORF with the Import + Route Target before advertising those routes to the CP-ORF + originator. See Section 3 for details. + + + + +Jeng, et al. Standards Track [Page 5] + +RFC 7543 Covering Prefixes ORF May 2015 + + + If the ROUTE-REFRESH AFI is equal to IPv4, + + o the value of Minlen MUST be less than or equal to 32; + + o the value of Maxlen MUST be less than or equal to 32; + + o the value of Minlen MUST be less than or equal to the value of + Maxlen; + + o the value of Route Type MUST be 0 (i.e., RESERVED); and + + o the Host Address MUST contain exactly 32 bits. + + If the ROUTE-REFRESH AFI is equal to IPv6, + + o the value of Minlen MUST be less than or equal to 128; + + o the value of Maxlen MUST be less than or equal to 128; + + o the value of Minlen MUST be less than or equal to the value of + Maxlen; + + o the value of Route Type MUST be 0 (i.e., RESERVED); and + + o the Host Address MUST contain exactly 128 bits. + + If the ROUTE-REFRESH AFI is equal to L2VPN, the value of Route Type + MUST be one of the following values taken from the IANA EVPN Registry + [IANA.EVPN]: + + o 1 - Ethernet Autodiscovery Route + + o 2 - MAC/IP Advertisement Route + + o 3 - Inclusive Multicast Route + + o 4 - Ethernet Segment + + If the ROUTE-REFRESH AFI is equal to L2VPN and the value of Route + Type is equal to Ethernet Autodiscovery Route, Inclusive Multicast + Route, or Ethernet Segment, + + o the value of Minlen MUST be equal to 0; + + o the value of Maxlen MUST be equal to 0; and + + o the Host Address MUST be absent (i.e., contain 0 bits). + + + + +Jeng, et al. Standards Track [Page 6] + +RFC 7543 Covering Prefixes ORF May 2015 + + + If the ROUTE-REFRESH AFI is equal to L2VPN and the value of Route + Type is equal to MAC/IP Advertisement Route, + + o the value of Minlen MUST be less than or equal to 48; + + o the value of Maxlen MUST be less than or equal to 48; + + o the value of Minlen MUST be less than or equal to the value of + Maxlen; and + + o the Host Address MUST contain exactly 48 bits. + +3. Processing Rules + + According to [RFC4271], every BGP speaker maintains a single Loc-RIB. + For each of its peers, the BGP speaker also maintains an Outbound + Filter and an Adj-RIB-Out. The Outbound Filter defines policy that + determines which Loc-RIB entries are processed into the corresponding + Adj-RIB-Out. Mechanisms such as RT-Constrain [RFC4684] and ORF + [RFC5291] enable a router's peer to influence the Outbound Filter. + Therefore, the Outbound Filter for a given peer is constructed using + a combination of the locally configured policy and the information + received via RT-Constrain and ORF from the peer. + + Using this model, we can describe the operations of CP-ORF as + follows: + + When a BGP speaker receives a ROUTE-REFRESH message that contains a + CP-ORF and that ROUTE-REFRESH message violates any of the encoding + rules specified in Section 2, the BGP speaker MUST ignore the entire + ROUTE-REFRESH message. It SHOULD also log the event. However, an + implementation MAY apply logging thresholds to avoid excessive + messaging or log file overflow. + + Otherwise, the BGP speaker processes each CP-ORF entry as indicated + by the Action field. If the Action is equal to ADD, the BGP speaker + adds the CP-ORF entry to the Outbound Filter associated with the peer + in the position specified by the Sequence field. If the Action is + equal to REMOVE, the BGP speaker removes the CP-ORF entry from the + Outbound Filter. If the Action is equal to REMOVE-ALL, the BGP + speaker removes all CP-ORF entries from the Outbound Filter. + + Whenever the BGP speaker applies an Outbound Filter to a route + contained in its Loc-RIB, it evaluates the route in terms of the + CP-ORF entries first. It then evaluates the route in terms of the + remaining non-CP-ORF entries. The rules for the former are described + below. The rules for the latter are outside the scope of this + document. + + + +Jeng, et al. Standards Track [Page 7] + +RFC 7543 Covering Prefixes ORF May 2015 + + + The following route types can match a CP-ORF: + + o IPv4-VPN + + o IPv6-VPN + + o L2VPN + + In order for an IPv4-VPN route or IPv6-VPN route to match a CP-ORF, + all of the following conditions MUST be true: + + o the route carries an RT whose value is the same as the CP-ORF VPN + Route Target; + + o the route prefix length is greater than or equal to the CP-ORF + Minlen plus 64 (i.e., the length of a VPN Route Distinguisher); + + o the route prefix length is less than or equal to the CP-ORF Maxlen + plus 64 (i.e., the length of a VPN Route Distinguisher); + + o ignoring the Route Distinguisher, the leading bits of the route + prefix are identical to the leading bits of the CP-ORF Host + Address, and CP-ORF Minlen defines the number of bits that must be + identical; and + + o Loc-RIB does not contain a more specific route that also satisfies + all of the above listed conditions. + + The BGP speaker ignores Route Distinguishers when determining whether + a prefix matches a host address. For example, assume that a CP-ORF + carries the following information: + + o Minlen equal to 1 + + o Maxlen equal to 32 + + o Host Address equal to 192.0.2.1 + + Assume also that Loc-RIB contains routes for the following IPv4-VPN + prefixes and that all of these routes carry an RT whose value is the + same as the CP-ORF VPN Route Target: + + o 1:0.0.0.0/64. + + o 2:192.0.2.0/88 + + o 3:192.0.2.0/89 + + + + +Jeng, et al. Standards Track [Page 8] + +RFC 7543 Covering Prefixes ORF May 2015 + + + Only the prefix 3:192.0.2.0/89 matches the CP-ORF. The prefix + 1:0.0.0.0/64 does not match, because its length (64) is less than the + CP-ORF Minlen (1) plus the length of an L3VPN Route Distinguisher + (64). If Loc-RIB did not contain the prefix 3:192.0.2.0/89, + 2:192.0.2.0/88 would match the CP-ORF. However, because Loc-RIB also + contains a more specific covering route (3:192.0.2.0/89), + 2:192.0.2.0/88 does not match. Only 3:192.0.2.0/89 satisfies all of + the above listed match criteria. Note that the matching algorithm + ignored Route Distinguishers. + + In order for an EVPN route to match a CP-ORF, all of the following + conditions MUST be true: + + o the EVPN route type is equal to the CP-ORF Route Type; and + + o the route carries an RT whose value is equal to the CP-ORF VPN + Route Target. + + In addition, if the CP-ORF Route Type is equal to MAC/IP + Advertisement Route, the following conditions also MUST be true: + + o the EVPN Route MAC Address Length is greater than or equal to the + CP-ORF Minlen plus 64 (i.e., the length of a VPN Route + Distinguisher); + + o the EVPN Route MAC Address Length is less than or equal to the CP- + ORF Maxlen plus 64 (i.e., the length of a VPN Route + Distinguisher); and + + o ignoring the Route Distinguisher, the leading bits of the EVPN + Route MAC Address are identical to the leading bits of the CP-ORF + Host Address. CP-ORF Minlen defines the number of bits that must + be identical. + + If a route matches the selection criteria of a CP-ORF entry and it + does not violate any subsequent rule specified by the Outbound Filter + (e.g., rules that reflect local policy or rules that are due to + RT-Constrains), the BGP speaker places the route into the Adj-RIB- + Out. In Adj-RIB-Out, the BGP speaker adds the CP-ORF Import Route + Target to the list of RTs that the route already carries. The BGP + speaker also adds a Transitive Opaque Extended Community [RFC4360] + with the sub-type equal to CP-ORF (0x03). As a result of being + placed in Adj-RIB-Out, the route is advertised to the peer associated + with the Adj-RIB-Out. + + + + + + + +Jeng, et al. Standards Track [Page 9] + +RFC 7543 Covering Prefixes ORF May 2015 + + + Receiving CP-ORF entries with REMOVE or REMOVE-ALL Actions may cause + a route that has previously been installed in a particular Adj-RIB- + Out to be excluded from that Adj-RIB-Out. In this case, as specified + in [RFC4271], "the previously advertised route in that Adj-RIB-Out + MUST be withdrawn from service by means of an UPDATE message". + + RFC 5291 states that a BGP speaker should respond to a ROUTE REFRESH + message as follows: + + If the When-to-refresh indicates IMMEDIATE, then after processing + all the ORF entries carried in the message the speaker + re-advertises to the peer routes from the Adj-RIB-Out associated + with the peer that have the same AFI/SAFI as what is carried in + the message, and taking into account all the ORF entries for that + AFI/SAFI received from the peer. The speaker MUST re-advertise + all the routes that have been affected by the ORF entries carried + in the message, but MAY also re-advertise the routes that have not + been affected by the ORF entries carried in the message. + + When the ROUTE-REFRESH message includes only CP-ORF entries, the BGP + speaker MUST re-advertise routes that have been affected by these + CP-ORF entries. It is RECOMMENDED not to re-advertise the routes + that have not been affected by the CP-ORF entries. + + When the ROUTE-REFRESH message includes one or more CP-ORF entries + and one or more ORF entries of a different type, the behavior remains + unchanged from that described in RFC 5291. + +4. Applicability in Virtual Hub-and-Spoke VPNs + + In a Virtual Hub-and-Spoke environment, VPN sites are attached to PE + routers. For a given VPN, a PE router acts in exactly one of the + following roles: + + o as a V-hub + + o as a V-spoke + + o as neither a V-hub nor a V-spoke + + To illustrate CP-ORF operation in conjunction with Virtual Hub-and- + Spoke, assume the following: + + o One of the sites in a particular VPN, RED-VPN, is connected to a + PE that acts as neither a V-hub nor a V-spoke for RED-VPN. We + refer to this PE as PE1. + + + + + +Jeng, et al. Standards Track [Page 10] + +RFC 7543 Covering Prefixes ORF May 2015 + + + o Another site in RED-VPN is connected to another PE, and that PE + acts as a V-hub for RED-VPN. We refer to this PE as V-hub1. + + o Yet another site in RED-VPN is connected to another PE, and that + PE acts as a V-spoke for RED-VPN. We refer to this PE as + V-spoke1. + + All of these PEs advertise RED-VPN routes to a Route Reflector (RR). + They mark these routes with an RT, which we will call RT-RED. In + particular, PE1 advertises a RED-VPN route to a prefix that we will + call P. P covers a host address that we will call H. + + For the purpose of illustration, also assume that the PEs and the RRs + use RT-Constrain [RFC4684]. + + V-hub1 serves the RED-VPN. Therefore, V-hub1 advertises a VPN-IP + default route for the RED-VPN to the RR, carrying the route target + RT-RED-FROM-HUB1. + + V-spoke1 establishes a BGP session with the RR, negotiating the + CP-ORF capability as well as the Multiprotocol Extensions capability + [RFC4760]. Upon establishment of the BGP session, the RR does not + advertise any routes to V-spoke1. The RR will not advertise any + routes until it receives either a ROUTE-REFRESH message or a BGP + UPDATE message containing a Route Target Membership Network Layering + Reachability Information (NLRI) [RFC4684]. + + Immediately after the BGP session is established, V-spoke1 sends the + RR a BGP UPDATE message containing a Route Target Membership NLRI. + The Route Target Membership NLRI specifies RT-RED-FROM-HUB1 as its + RT. In response to the BGP-UPDATE message, the RR advertises the VPN + IP default route for the RED-VPN to V-spoke1. This route carries the + route target RT-RED-FROM-HUB1. V-spoke1 subjects this route to its + import policy and accepts it because it carries the route target + RT-RED-FROM-HUB1. + + Now, V-spoke1 begins normal operation, sending all of its RED-VPN + traffic through V-hub1. At some point, V-spoke1 determines that it + might benefit from a more direct route to H. (Note that criteria by + which V-spoke1 determines that it needs a more direct route to H are + beyond the scope of this document.) + + + + + + + + + + +Jeng, et al. Standards Track [Page 11] + +RFC 7543 Covering Prefixes ORF May 2015 + + + In order to discover a more direct route, V-spoke1 assigns a unique + numeric identifier to H. V-spoke1 then sends a ROUTE-REFRESH message + to the RR, which contains the following information: + + o AFI is equal to IPv4 or IPv6, as appropriate + + o SAFI is equal to "MPLS-labeled VPN address" + + o When-to-refresh is equal to IMMEDIATE + + o Action is equal to ADD + + o Match is equal to PERMIT + + o ORF Type is equal to CP-ORF + + o CP-ORF Sequence is equal to the identifier associated with H + + o CP-ORF Minlen is equal to 1 + + o CP-ORF Maxlen is equal to 32 or 128, as appropriate + + o CP-ORF VPN Route Target is equal to RT-RED + + o CP-ORF Import Route Target is equal to RT-RED-FROM-HUB1 + + o CP-ORF Route Type is equal to 0 (i.e., undefined) + + o CP-ORF Host Address is equal to H + + Upon receipt of the ROUTE-REFRESH message, the RR MUST ensure that it + carries all routes belonging to the RED-VPN. In at least one special + case, where all of the RR clients are V-spokes and none of the RR + clients are V-hubs, the RR will lack some or all of the required + RED-VPN routes. So, the RR sends a BGP UPDATE message containing a + Route Target Membership NLRI for VPN-RED to all of its peers. This + causes the peers to advertise VPN-RED routes to the RR if they have + not done so already. + + Next, the RR adds the received CP-ORF to the Outbound Filter + associated with V-spoke1. Using the procedures in Section 3, the RR + determines whether any of the routes in its Loc-RIB satisfy the + selection criteria of the newly updated Outbound Filter. If any + routes satisfy the match criteria, they are added to the Adj-RIB-Out + associated with V-spoke1. In Adj-RIB-Out, the RR adds + RT-RED-FROM-HUB1 to the list of RTs that the route already carries. + The RR also adds a Transitive Opaque Extended Community [RFC4360] + + + + +Jeng, et al. Standards Track [Page 12] + +RFC 7543 Covering Prefixes ORF May 2015 + + + with the sub-type equal to CP-ORF. Finally, RR advertises the newly + added routes to V-spoke1. In this example, the RR advertises P to + V-spoke1 with a next-hop of PE1. + + V-spoke1 subjects the advertised routes to its import policy and + accepts them because they carry the route target RT-RED-FROM-HUB1. + + V-spoke1 may repeat this process whenever it discovers another flow + that might benefit from a more direct route to its destination. + +4.1. Multicast Considerations + + When applying Multicast VPN [RFC6513] [RFC6514] procedures, routes + bearing a Transitive Opaque Extended Community [RFC4360] with the + sub-type equal to CP-ORF MUST NOT be used to determine Eligible + Upstream Multicast Hops (UMH). + +5. Applicability in BGP/MPLS Ethernet VPN (EVPN) + + In an EVPN environment, Customer Edge (CE) devices are attached to PE + routers. A CE can be a host, a router, or a switch. For a given + EVI, a PE router acts in exactly one of the following roles: + + o as a DMG + + o as a Spoke + + o as neither a DMG nor a Spoke + + To illustrate CP-ORF operation in the EVPN environment, assume the + following: + + o A CE device in a particular EVI, RED-EVI, is connected to a PE + that acts as neither a DMG nor a Spoke for RED-EVI. We refer to + this PE as PE1. + + o Another CE device in RED-EVI is connected to another PE, and that + PE acts as a DMG for RED-EVI. We refer to this PE as DMG1. + + o Yet another CE device in RED-EVI is connected to another PE, and + that PE acts as a Spoke for RED-EVI. We refer to this PE as + Spoke1. + + All of these PEs advertise RED-EVI routes to a RR. They mark these + routes with an RT, which we will call RT-RED. In particular, PE1 + advertises a RED-EVI route to a MAC Address that we will call M. + + + + + +Jeng, et al. Standards Track [Page 13] + +RFC 7543 Covering Prefixes ORF May 2015 + + + The RED-EVI VPN Routing and Forwarding tables (VRFs) on all of these + PEs are provisioned to import EVPN routes that carry RT-RED. + + Since DMG1 acts as a DMG for RED-EVI, DMG1 advertises a UMR for the + RED-EVI to the RR, carrying the route target RT-RED. The UMR is + characterized as follows: + + o EVPN Route Type is equal to MAC/IP Advertisement Route + + o MAC address length is equal to 0 + + o IP address length is equal to 0 + + Spoke1 establishes a BGP session with the RR, negotiating the CP-ORF + capability as well as the Multiprotocol Extensions capability + [RFC4760]. Upon establishment of the BGP session, the RR does not + advertise any routes to Spoke1. The RR will not advertise any routes + until it receives a ROUTE-REFRESH message. + + Immediately after the BGP session is established, Spoke1 sends the RR + a ROUTE REFRESH message containing the following information: + + o AFI is equal to L2VPN + + o SAFI is equal to BGP EVPN + + o When-to-refresh is equal to IMMEDIATE + + o Action is equal to ADD + + o Match is equal to PERMIT + + The ROUTE REFRESH message also contains four ORF entries. The first + ORF entry contains the following information: + + o ORF Type is equal to CP-ORF + + o CP-ORF Sequence is equal to 1 + + o CP-ORF Minlen is equal to 0 + + o CP-ORF Maxlen is equal to 0 + + o CP-ORF VPN Route Target is equal to RT-RED + + o CP-ORF Import Route Target is equal to RT-RED + + o CP-ORF Route Type is equal to 1 (Ethernet Autodiscovery Route) + + + +Jeng, et al. Standards Track [Page 14] + +RFC 7543 Covering Prefixes ORF May 2015 + + + The second ORF entry contains the following information: + + o ORF Type is equal to CP-ORF + + o CP-ORF Sequence is equal to 2 + + o CP-ORF Minlen is equal to 0 + + o CP-ORF Maxlen is equal to 0 + + o CP-ORF VPN Route Target is equal to RT-RED + + o CP-ORF Import Route Target is equal to RT-RED + + o CP-ORF Route Type is equal to 2 (MAC/IP Advertisement Route) + + The third ORF entry contains the following information: + + o ORF Type is equal to CP-ORF + + o CP-ORF Sequence is equal to 3 + + o CP-ORF Minlen is equal to 0 + + o CP-ORF Maxlen is equal to 0 + + o CP-ORF VPN Route Target is equal to RT-RED + + o CP-ORF Import Route Target is equal to RT-RED + + o CP-ORF Route Type is equal to 3 (Inclusive Multicast Route) + + The fourth ORF entry contains the following information: + + o ORF Type is equal to CP-ORF + + o CP-ORF Sequence is equal to 4 + + o CP-ORF Minlen is equal to 0 + + o CP-ORF Maxlen is equal to 0 + + o CP-ORF VPN Route Target is equal to RT-RED + + o CP-ORF Import Route Target is equal to RT-RED + + o CP-ORF Route Type is equal to 4 (Ethernet Segment) + + + + +Jeng, et al. Standards Track [Page 15] + +RFC 7543 Covering Prefixes ORF May 2015 + + + In response to the ROUTE REFRESH message, the RR advertises the + following to V-spoke1: + + o All Ethernet Autodiscovery Routes belonging to RED-EVI + + o A UMR advertised by DMG1 and belonging to RED-EVI + + o All Inclusive Multicast Routes belonging to RED-EVI + + o All Ethernet Segment Routes belonging to RED-EVI + + All of these routes carry the route target RT-RED. Spoke1 subjects + these routes to its import policy and accepts them because they carry + the route target RT-RED. + + Now, Spoke1 begins normal operation, sending all of its RED-VPN + traffic through DMG1. At some point, Spoke1 determines that it might + benefit from a more direct route to M. (Note that criteria by which + Spoke1 determines that it needs a more direct route to M are beyond + the scope of this document.) + + In order to discover a more direct route, Spoke1 assigns a unique + numeric identifier to M. V-spoke1 then sends a ROUTE-REFRESH message + to the RR, containing the following information: + + o AFI is equal to L2VPN + + o SAFI is equal to BGP EVPN + + o When-to-refresh is equal to IMMEDIATE + + o Action is equal to ADD + + o Match is equal to PERMIT + + o ORF Type is equal to CP-ORF + + o CP-ORF Sequence is equal to the identifier associated with M + + o CP-ORF Minlen is equal to 1 + + o CP-ORF Maxlen is equal to 48 + + o CP-ORF VPN Route Target is equal to RT-RED + + o CP-ORF Import Route Target is equal to RT-RED + + + + + +Jeng, et al. Standards Track [Page 16] + +RFC 7543 Covering Prefixes ORF May 2015 + + + o CP-ORF Route Type is equal to 2 (i.e., MAC/IP Advertisement Route) + + o CP-ORF Host Address is equal to M + + Next, the RR adds the received CP-ORF to the Outbound Filter + associated with Spoke1. Using the procedures in Section 3, the RR + determines whether any of the routes in its Loc-RIB satisfy the + selection criteria of the newly updated Outbound Filter. If any + routes satisfy the match criteria, they are added to the Adj-RIB-Out + associated with Spoke1. The RR adds a Transitive Opaque Extended + Community [RFC4360] with the sub-type equal to CP-ORF. Note that as + these routes are added to the Adj-RIB-Out, the RR does not change the + list of RTs that the route already carries. Finally, RR advertises + the newly added routes to V-spoke1. In this example, the RR + advertises M to V-spoke1 with a next-hop of PE1. + + Spoke1 subjects the advertised routes to its import policy and + accepts them because they carry the route target RT-RED. + + Spoke1 may repeat this process whenever it discovers another flow + that might benefit from a more direct route to its destination. + + Note that, in general, an EVI may have more than one DMG, in which + case each spoke would receive a UMR from each of them. The spoke + should follow its local route selection procedures to select one of + them as the "best" and use the selected one. + +6. Clean-up + + Each CP-ORF consumes memory and compute resources on the device that + supports it. Therefore, in order to obtain optimal performance, BGP + speakers periodically evaluate all CP-ORFs that they have originated + and remove unneeded CP-ORFs. The criteria by which a BGP speaker + identifies unneeded CP-ORF entries is a matter of local policy and is + beyond the scope of this document. + +7. IANA Considerations + + This memo uses code points from the First Come First Served [RFC5226] + range of the following registries: + + +------------------------------------------------+---------------+ + | Registry | Code Point | + +------------------------------------------------+---------------+ + | BGP Outbound Route Filtering (ORF) Types | CP-ORF (65) | + | Transitive Opaque Extended Community Sub-Types | CP-ORF (0x03) | + +------------------------------------------------+---------------+ + + + + +Jeng, et al. Standards Track [Page 17] + +RFC 7543 Covering Prefixes ORF May 2015 + + + IANA has updated the above-mentioned registry entries so that they + reference this memo. + +8. Security Considerations + + Each CP-ORF consumes memory and compute resources on the device that + supports it. Therefore, a device supporting CP-ORF takes the + following steps to protect itself from oversubscription: + + o When negotiating the ORF capability, advertise willingness to + receive the CP-ORF only to known, trusted Internal BGP (iBGP) + peers. See Section 5 of RFC 5291 for negotiation details. + + o Enforce a per-peer limit on the number of CP-ORFs that can be + installed at any given time. Ignore all requests to add CP-ORFs + beyond that limit + + Security considerations for BGP are presented in [RFC4271] while + further security analysis of BGP is found in [RFC6952]. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A + Border Gateway Protocol 4 (BGP-4)", RFC 4271, January + 2006, . + + [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended + Communities Attribute", RFC 4360, February 2006, + . + + [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, + R., Patel, K., and J. Guichard, "Constrained Route + Distribution for Border Gateway Protocol/MultiProtocol + Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual + Private Networks (VPNs)", RFC 4684, November 2006, + . + + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, January + 2007, . + + + + + +Jeng, et al. Standards Track [Page 18] + +RFC 7543 Covering Prefixes ORF May 2015 + + + [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering + Capability for BGP-4", RFC 5291, August 2008, + . + + [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ + BGP IP VPNs", RFC 6513, February 2012, + . + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, February 2012, + . + + [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, + Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS + VPNs", RFC 7024, October 2013, + . + + [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., + Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based + Ethernet VPN", RFC 7432, February 2015, + . + +9.2. Informative References + + [IANA.AFI] IANA, "Address Family Numbers", + . + + [IANA.EVPN] IANA, "Ethernet VPN (EVPN)", + . + + [IANA.SAFI] IANA, "Subsequent Address Family Identifiers (SAFI) + Parameters", + . + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, February 2006, + . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, . + + [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of + BGP, LDP, PCEP, and MSDP Issues According to the Keying + and Authentication for Routing Protocols (KARP) Design + Guide", RFC 6952, May 2013, + . + + + +Jeng, et al. Standards Track [Page 19] + +RFC 7543 Covering Prefixes ORF May 2015 + + +Acknowledgements + + The authors wish to acknowledge Han Nguyen, James Uttaro, and Alvaro + Retana for their comments and contributions. + +Contributors + + The following individuals contributed to the development of this + document: + + o Yakov Rekhter + + o Xiaohu Xu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeng, et al. Standards Track [Page 20] + +RFC 7543 Covering Prefixes ORF May 2015 + + +Authors' Addresses + + Huajin Jeng + AT&T + + EMail: hj2387@att.com + + + Luay Jalil + Verizon + + EMail: luay.jalil@verizon.com + + + Ron Bonica + Juniper Networks + 2251 Corporate Park Drive + Herndon, Virginia 20170 + United States + + EMail: rbonica@juniper.net + + + Keyur Patel + Cisco Systems + 170 W. Tasman Drive + San Jose, California 95134 + United States + + EMail: keyupate@cisco.com + + + Lucy Yong + Huawei Technologies + Austin, Texas + United States + + EMail: lucy.yong@huawei.com + + + + + + + + + + + + + +Jeng, et al. Standards Track [Page 21] + -- cgit v1.2.3