RFC 7543

Covering Prefixes Outbound Route Filter for BGP-4

📅 published May 2015, from ietf

Covering Prefixes Outbound Route Filter for BGP-4 🎀

Okay bestie, this one is RFC 7543 🧚 It's a Standards Track doc from May 2015, written by a squad from AT&T (H. Jeng), Verizon (L. Jalil), Juniper Networks (R. Bonica), Cisco Systems (K. Patel), and Huawei Technologies (L. Yong). Its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so this one stands on its own 💅

Abstract ✨

okay so this doc defines a brand new Outbound Route Filter (ORF) type called the Covering Prefixes ORF (CP-ORF) 🦋 it's built for Virtual Hub-and-Spoke VPNs, and it's also useful in BGP/MPLS Ethernet VPN (EVPN) networks. iconic, right?

Status of This Memo 📜

this is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741.

for the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7543 💜

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) as they stand on the date of publication. please read these carefully, because they spell out your rights and restrictions for this doc. code components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🫶

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

1. Introduction ✨

okay so a BGP [RFC4271] speaker can send Outbound Route Filters (ORFs) [RFC5291] to a peer. the peer uses those ORFs to filter the routing updates it sends back to the speaker. with ORF, a BGP speaker can do a "route pull" move, where it grabs certain routes from the peer whenever it wants 🧲

this doc defines a new ORF type called the Covering Prefixes ORF (CP-ORF) 💖 a BGP speaker sends a CP-ORF to a peer so it can pull the routes that cover a specific host address. a prefix covers a host address if it can be used to forward traffic toward that host address. Section 3 has the full scoop on how covering prefixes get picked 👀

CP-ORF works in Virtual Hub-and-Spoke VPNs [RFC7024] [RFC4364], and it also works in BGP/MPLS Ethernet VPN (EVPN) [RFC7432] networks 🦋

1.1. Terminology 📖

this doc uses these terms:

  • Address Family Identifier (AFI) - defined in [RFC4760]
  • Subsequent Address Family Identifier (SAFI) - defined in [RFC4760]
  • Route Target (RT) - defined in [RFC4364]
  • VPN-IP Default Route - defined in [RFC7024]
  • Virtual Hub (V-hub) - defined in [RFC7024]
  • Virtual Spoke (V-spoke) - defined in [RFC7024]
  • BGP/MPLS Ethernet VPN (EVPN) - defined in [RFC7432]
  • EVPN Instance (EVI) - defined in [RFC7432]
  • MAC - Media Access Control
  • Unknown MAC Route (UMR) - a regular EVPN MAC/IP Advertisement route where the MAC Address Length is set to 48 and the MAC address is set to 00:00:00:00:00:00 🫠
  • Default MAC Gateway (DMG) - an EVPN Provider Edge (PE) that advertises a UMR

1.2. Requirements Language 🔑

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in RFC 2119 [RFC2119]. these are the keywords that carry the weight, so pay attention to them 🔥

2. CP-ORF Encoding 🧩

RFC 5291 tweaks the BGP ROUTE-REFRESH message so it can carry ORF entries. when a ROUTE-REFRESH message carries ORF entries, it includes these fields:

  • AFI [IANA.AFI]
  • SAFI [IANA.SAFI]
  • When-to-refresh (IMMEDIATE or DEFERRED)
  • ORF Type
  • Length (of ORF entries)

the ROUTE-REFRESH message also holds a list of ORF entries. each ORF entry has these fields:

  • Action (ADD, REMOVE, or REMOVE-ALL)
  • Match (PERMIT or DENY)

an ORF entry may also carry Type-specific information. that info only shows up when the Action is ADD or REMOVE. when the Action is REMOVE-ALL, it's not there at all 🙈

when the BGP ROUTE-REFRESH message carries CP-ORF entries, these conditions MUST be true:

  • The ORF Type MUST be equal to CP-ORF (65).
  • The AFI MUST be equal to IPv4, IPv6, or Layer 2 VPN (L2VPN).
  • If the AFI is equal to IPv4 or IPv6, the SAFI MUST be equal to MPLS-labeled VPN address.
  • If the AFI is equal to L2VPN, the SAFI MUST be equal to BGP EVPN.
  • The Match field MUST be equal to PERMIT.

here's Figure 1, the layout of the CP-ORF Type-specific encoding 📐

                 +--------------------------------+
                 |  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 these fields to pick out the routes that match the CP-ORF:

  • Sequence: the relative position of a CP-ORF entry among other CP-ORF entries
  • Minlen: the minimum length of the selected route (measured in bits)
  • Maxlen: the maximum length of the selected route (measured in bits)
  • VPN Route Target: the VPN Route Target carried by the selected route
  • Route Type: the type of the selected route
  • Host Address: the address covered by the selected route

see Section 3 for the details 🔍

the CP-ORF recipient marks routes that match the CP-ORF with the Import Route Target before it advertises those routes back to the CP-ORF originator. again, see Section 3 for the details 💅

next up, the rules depend on the ROUTE-REFRESH AFI. if the AFI is IPv4:

  • the value of Minlen MUST be less than or equal to 32;
  • the value of Maxlen MUST be less than or equal to 32;
  • the value of Minlen MUST be less than or equal to the value of Maxlen;
  • the value of Route Type MUST be 0 (i.e., RESERVED); and
  • the Host Address MUST contain exactly 32 bits.

if the ROUTE-REFRESH AFI is IPv6:

  • the value of Minlen MUST be less than or equal to 128;
  • the value of Maxlen MUST be less than or equal to 128;
  • the value of Minlen MUST be less than or equal to the value of Maxlen;
  • the value of Route Type MUST be 0 (i.e., RESERVED); and
  • the Host Address MUST contain exactly 128 bits.

if the ROUTE-REFRESH AFI is L2VPN, the value of Route Type MUST be one of these values from the IANA EVPN Registry [IANA.EVPN]:

  • 1 - Ethernet Autodiscovery Route
  • 2 - MAC/IP Advertisement Route
  • 3 - Inclusive Multicast Route
  • 4 - Ethernet Segment

if the ROUTE-REFRESH AFI is L2VPN and the Route Type is Ethernet Autodiscovery Route, Inclusive Multicast Route, or Ethernet Segment:

  • the value of Minlen MUST be equal to 0;
  • the value of Maxlen MUST be equal to 0; and
  • the Host Address MUST be absent (i.e., contain 0 bits).

if the ROUTE-REFRESH AFI is L2VPN and the Route Type is MAC/IP Advertisement Route:

  • the value of Minlen MUST be less than or equal to 48;
  • the value of Maxlen MUST be less than or equal to 48;
  • the value of Minlen MUST be less than or equal to the value of Maxlen; and
  • the Host Address MUST contain exactly 48 bits.

(to be continued... 🧚✨)

3. Processing Rules ✨

okay so bestie, let's talk about how routers actually do this 💅. According to [RFC4271], every BGP speaker keeps one single Loc-RIB 🎀. For each of its peers, it also keeps an Outbound Filter and an Adj-RIB-Out. The Outbound Filter is the policy that decides which Loc-RIB entries get processed into that peer's Adj-RIB-Out 🦋. Mechanisms like RT-Constrain [RFC4684] and ORF [RFC5291] let a router's peer have a say in the Outbound Filter 🫶. So the Outbound Filter for a given peer is built from a mix of the locally configured policy and the info received from that peer via RT-Constrain and ORF 💜.

With that model in mind, here's how CP-ORF works:

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 in Section 2, the BGP speaker MUST ignore the entire ROUTE-REFRESH message. It SHOULD also log the event 😭. That said, an implementation MAY apply logging thresholds so it doesn't spam messages or overflow the log file 🙈.

Otherwise, the BGP speaker processes each CP-ORF entry based on its Action field. If the Action is ADD, the speaker adds the CP-ORF entry to the Outbound Filter for that peer, in the position given by the Sequence field 🧚. If the Action is REMOVE, the speaker removes that CP-ORF entry from the Outbound Filter. If the Action is REMOVE-ALL, the speaker removes all CP-ORF entries from the Outbound Filter 💀.

Whenever the BGP speaker applies an Outbound Filter to a route in its Loc-RIB, it checks the route against the CP-ORF entries first, and then against the remaining non-CP-ORF entries. The rules for the CP-ORF part are described below. The rules for the rest are outside the scope of this document 🌸.

The following route types can match a CP-ORF:

  • IPv4-VPN
  • IPv6-VPN
  • L2VPN

For an IPv4-VPN or IPv6-VPN route to match a CP-ORF, all of the following conditions MUST be true:

  • the route carries an RT whose value is the same as the CP-ORF VPN Route Target;
  • 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);
  • 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);
  • 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
  • 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 working out whether a prefix matches a host address 🔥. Here's an example. Say a CP-ORF carries the following information:

  • Minlen equal to 1
  • Maxlen equal to 32
  • Host Address equal to 192.0.2.1

Now say Loc-RIB has routes for the following IPv4-VPN prefixes, and every one of them carries an RT whose value is the same as the CP-ORF VPN Route Target:

  • 1:0.0.0.0/64.
  • 2:192.0.2.0/88
  • 3:192.0.2.0/89

Only the prefix 3:192.0.2.0/89 matches the CP-ORF 👑. The prefix 1:0.0.0.0/64 doesn't 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 didn't contain 3:192.0.2.0/89, then 2:192.0.2.0/88 would match the CP-ORF. But Loc-RIB also has a more specific covering route (3:192.0.2.0/89), so 2:192.0.2.0/88 does not match. Only 3:192.0.2.0/89 satisfies all of the match criteria. Notice that the matching algorithm ignored the Route Distinguishers 🦋.

For an EVPN route to match a CP-ORF, all of the following conditions MUST be true:

  • the EVPN route type is equal to the CP-ORF Route Type; and
  • the route carries an RT whose value is equal to the CP-ORF VPN Route Target.

On top of that, if the CP-ORF Route Type is equal to MAC/IP Advertisement Route, the following conditions also MUST be true:

  • 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);
  • 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
  • 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 doesn't violate any later rule in the Outbound Filter (like local policy, or rules coming from RT-Constrain), the BGP speaker places the route into the Adj-RIB-Out 🎀. In the Adj-RIB-Out, the speaker adds the CP-ORF Import Route Target to the list of RTs the route already carries. It also adds a Transitive Opaque Extended Community [RFC4360] with the sub-type equal to CP-ORF (0x03) ✨. Once the route is in the Adj-RIB-Out, it gets advertised to the peer tied to that Adj-RIB-Out 🚀.

Receiving CP-ORF entries with REMOVE or REMOVE-ALL Actions can cause a route that was previously installed in a particular Adj-RIB-Out to be excluded from that Adj-RIB-Out 😭. When that happens, as [RFC4271] specifies, "the previously advertised route in that Adj-RIB-Out MUST be withdrawn from service by means of an UPDATE message" 💅.

RFC 5291 says a BGP speaker should respond to a ROUTE REFRESH message like this:

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 the routes affected by those CP-ORF entries 🌈. It is RECOMMENDED not to re-advertise the routes that the CP-ORF entries didn't affect 🧚.

When the ROUTE-REFRESH message includes one or more CP-ORF entries and one or more ORF entries of a different type, the behaviour stays the same as what RFC 5291 describes 🍓.

4. Applicability in Virtual Hub-and-Spoke VPNs ✨

Okay so in a Virtual Hub-and-Spoke setup, VPN sites hang off PE routers 🦋. For any given VPN, a PE is playing exactly one of these roles:

  • as a V-hub
  • as a V-spoke
  • as neither a V-hub nor a V-spoke

To show how CP-ORF works with Virtual Hub-and-Spoke, let's set the scene 🌸. Assume the following:

  • 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 call this one PE1 💖.
  • Another site in RED-VPN is connected to another PE, and that PE acts as a V-hub for RED-VPN. We call this one V-hub1 👑.
  • Yet another site in RED-VPN is connected to another PE, and that PE acts as a V-spoke for RED-VPN. We call this one V-spoke1 🧚.

All of these PEs advertise RED-VPN routes to a Route Reflector (RR) 🫶. They tag these routes with an RT, which we'll call RT-RED. Specifically, PE1 advertises a RED-VPN route to a prefix we'll call P, and P covers a host address we'll call H.

For illustration, also assume the PEs and the RRs use RT-Constrain [RFC4684] 💅.

V-hub1 serves the RED-VPN, so 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 and negotiates the CP-ORF capability as well as the Multiprotocol Extensions capability [RFC4760] 🦋. Once that session is up, the RR does not advertise any routes to V-spoke1. The RR won't advertise anything until it receives either a ROUTE-REFRESH message or a BGP UPDATE message containing a Route Target Membership Network Layering Reachability Information (NLRI) [RFC4684]. Lowkey a whole waiting game 🙈.

Right after the BGP session is established, V-spoke1 sends the RR a BGP UPDATE message containing a Route Target Membership NLRI. That 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, and this route carries the route target RT-RED-FROM-HUB1. V-spoke1 runs this route through its import policy and accepts it because it carries RT-RED-FROM-HUB1 ✨.

Now V-spoke1 is living its best life, sending all of its RED-VPN traffic through V-hub1 💅. At some point, V-spoke1 decides it might benefit from a more direct route to H. (Criteria for how V-spoke1 decides it needs a more direct route to H are beyond the scope of this document, so we're not going there 🙈.)

To discover that more direct route, V-spoke1 assigns a unique numeric identifier to H. Then it sends a ROUTE-REFRESH message to the RR with the following information 🍓:

  • AFI is equal to IPv4 or IPv6, as appropriate
  • SAFI is equal to "MPLS-labeled VPN address"
  • When-to-refresh is equal to IMMEDIATE
  • Action is equal to ADD
  • Match is equal to PERMIT
  • ORF Type is equal to CP-ORF
  • CP-ORF Sequence is equal to the identifier associated with H
  • CP-ORF Minlen is equal to 1
  • CP-ORF Maxlen is equal to 32 or 128, as appropriate
  • CP-ORF VPN Route Target is equal to RT-RED
  • CP-ORF Import Route Target is equal to RT-RED-FROM-HUB1
  • CP-ORF Route Type is equal to 0 (i.e., undefined)
  • CP-ORF Host Address is equal to H

When the RR gets that ROUTE-REFRESH message, it 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 them are V-hubs, the RR will be missing 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. That makes the peers advertise VPN-RED routes to the RR if they haven't 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 checks whether any routes in its Loc-RIB satisfy the selection criteria of the newly updated Outbound Filter. If any routes match, they're 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] with the sub-type equal to CP-ORF. Finally, the 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 runs the advertised routes through its import policy and accepts them because they carry RT-RED-FROM-HUB1 🫶.

V-spoke1 can repeat this whole process whenever it finds 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) 🚫. Hard rule, bestie 😭.

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:

  • as a DMG
  • as a Spoke
  • as neither a DMG nor a Spoke

To illustrate CP-ORF operation in the EVPN environment, assume the following:

  • 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 call this one PE1 💖.
  • Another CE device in RED-EVI is connected to another PE, and that PE acts as a DMG for RED-EVI. We call this one DMG1 👑.
  • Yet another CE device in RED-EVI is connected to another PE, and that PE acts as a Spoke for RED-EVI. We call this one Spoke1 🧚.

All of these PEs advertise RED-EVI routes to an RR 🫶. They tag these routes with an RT, which we'll call RT-RED. Specifically, PE1 advertises a RED-EVI route to a MAC Address we'll call M.

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 RED-EVI to the RR, carrying the route target RT-RED. The UMR is characterized as follows:

  • EVPN Route Type is equal to MAC/IP Advertisement Route
  • MAC address length is equal to 0
  • IP address length is equal to 0

Spoke1 establishes a BGP session with the RR and negotiates the CP-ORF capability as well as the Multiprotocol Extensions capability [RFC4760] 🦋. Once that session is up, the RR does not advertise any routes to Spoke1. The RR won't advertise any routes until it receives a ROUTE-REFRESH message 🙈.

Right after the BGP session is established, Spoke1 sends the RR a ROUTE REFRESH message containing the following information:

  • AFI is equal to L2VPN
  • SAFI is equal to BGP EVPN
  • When-to-refresh is equal to IMMEDIATE
  • Action is equal to ADD
  • Match is equal to PERMIT

The ROUTE REFRESH message also contains four ORF entries 🍓. The first ORF entry contains the following information:

  • ORF Type is equal to CP-ORF
  • CP-ORF Sequence is equal to 1
  • CP-ORF Minlen is equal to 0
  • CP-ORF Maxlen is equal to 0
  • CP-ORF VPN Route Target is equal to RT-RED
  • CP-ORF Import Route Target is equal to RT-RED
  • CP-ORF Route Type is equal to 1 (Ethernet Autodiscovery Route)

The second ORF entry contains the following information:

  • ORF Type is equal to CP-ORF
  • CP-ORF Sequence is equal to 2
  • CP-ORF Minlen is equal to 0
  • CP-ORF Maxlen is equal to 0
  • CP-ORF VPN Route Target is equal to RT-RED
  • CP-ORF Import Route Target is equal to RT-RED
  • CP-ORF Route Type is equal to 2 (MAC/IP Advertisement Route)

The third ORF entry contains the following information:

  • ORF Type is equal to CP-ORF
  • CP-ORF Sequence is equal to 3
  • CP-ORF Minlen is equal to 0
  • CP-ORF Maxlen is equal to 0
  • CP-ORF VPN Route Target is equal to RT-RED
  • CP-ORF Import Route Target is equal to RT-RED
  • CP-ORF Route Type is equal to 3 (Inclusive Multicast Route)

The fourth ORF entry contains the following information:

  • ORF Type is equal to CP-ORF
  • CP-ORF Sequence is equal to 4
  • CP-ORF Minlen is equal to 0
  • CP-ORF Maxlen is equal to 0
  • CP-ORF VPN Route Target is equal to RT-RED
  • CP-ORF Import Route Target is equal to RT-RED
  • CP-ORF Route Type is equal to 4 (Ethernet Segment)

In response to the ROUTE REFRESH message, the RR advertises the following to V-spoke1 🌈:

  • All Ethernet Autodiscovery Routes belonging to RED-EVI
  • A UMR advertised by DMG1 and belonging to RED-EVI
  • All Inclusive Multicast Routes belonging to RED-EVI
  • All Ethernet Segment Routes belonging to RED-EVI

All of these routes carry the route target RT-RED. Spoke1 runs these routes through its import policy and accepts them because they carry RT-RED 💅.

Now Spoke1 is sending all of its RED-VPN traffic through DMG1 ✨. At some point, Spoke1 decides it might benefit from a more direct route to M. (Criteria for how Spoke1 decides it needs a more direct route to M are beyond the scope of this document, so no spoilers 🙈.)

To discover that 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 🍓:

  • AFI is equal to L2VPN
  • SAFI is equal to BGP EVPN
  • When-to-refresh is equal to IMMEDIATE
  • Action is equal to ADD
  • Match is equal to PERMIT
  • ORF Type is equal to CP-ORF
  • CP-ORF Sequence is equal to the identifier associated with M
  • CP-ORF Minlen is equal to 1
  • CP-ORF Maxlen is equal to 48
  • CP-ORF VPN Route Target is equal to RT-RED
  • CP-ORF Import Route Target is equal to RT-RED
  • CP-ORF Route Type is equal to 2 (i.e., MAC/IP Advertisement Route)
  • 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 checks whether any routes in its Loc-RIB satisfy the selection criteria of the newly updated Outbound Filter. If any routes match, they're 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 get added to the Adj-RIB-Out, the RR does not change the list of RTs that the route already carries. Finally, the 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 runs the advertised routes through its import policy and accepts them because they carry the route target RT-RED 🫶.

Spoke1 can repeat this process whenever it finds 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 🧹

okay so, every CP-ORF eats up memory and compute on the device that supports it 😭 which means BGP speakers need to be chill about it. For optimal performance, they periodically check every CP-ORF they originated and delete the ones nobody needs anymore 🗑️✨ The criteria for spotting an unneeded CP-ORF entry is a matter of local policy and is beyond the scope of this document, so that's between you and your network 💅

7. IANA Considerations 🦋

bestie, this memo grabs 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) |
+------------------------------------------------+---------------+

And IANA already updated those registry entries so they point to this memo. Iconic behavior from IANA 👑

8. Security Considerations 🔐

⚠️ Okay, this one is serious, so read it carefully, no skipping 🙈

Every CP-ORF eats up memory and compute on the device that supports it. Because of that, a device supporting CP-ORF takes the following steps to protect itself from oversubscription:

  • 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.
  • 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], and further security analysis of BGP is found in [RFC6952]. Go read those, they're the main character sources here 🎀

9. References 📚

9.1. Normative References 💜

9.2. Informative References ✨

Acknowledgements 🫶

The authors wish to shout out Han Nguyen, James Uttaro, and Alvaro Retana for their comments and contributions. Thank you, queens 👑

Contributors 🌈

The following individuals contributed to the development of this document:

  • Yakov Rekhter
  • Xiaohu Xu

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
📦 where this page comes from