Covering Prefixes Outbound Route Filter for BGP-4
Extracted elements (17)
CP-ORF implements a 'route pull' paradigm: a spoke (V-spoke or EVPN Spoke) initially receives only default/summary routes from a hub, then on-demand pulls more-specific routes covering particular host addresses by sending CP-ORF entries. This avoids advertising all VPN routes to all spokes upfront.
In EVPN, a spoke initially sends four CP-ORF entries (one per EVPN route type: Autodiscovery, MAC/IP, Inclusive Multicast, Ethernet Segment) to pull all base infrastructure routes from the RR, then sends a fifth MAC-specific CP-ORF to discover direct routes to specific MAC addresses.
Upon receipt of a ROUTE-REFRESH with CP-ORF from a V-spoke, the RR MUST ensure it carries all routes for the relevant VPN. In the special case where all RR clients are V-spokes and none are V-hubs, the RR may lack required routes and MUST send a Route Target Membership NLRI to solicit them from peers.
For an IPv4-VPN or IPv6-VPN route to match a CP-ORF, all of the following MUST be true: the route carries an RT matching the CP-ORF VPN Route Target; the prefix length is within [Minlen+64, Maxlen+64]; the leading Minlen bits match the Host Address; and Loc-RIB contains no more-specific covering route satisfying all conditions.
If AFI is L2VPN and Route Type is MAC/IP Advertisement Route, Minlen MUST be ≤ 48, Maxlen MUST be ≤ 48, Minlen MUST be ≤ Maxlen, and Host Address MUST contain exactly 48 bits.
If the ROUTE-REFRESH AFI is equal to L2VPN, the Route Type MUST be one of: 1 (Ethernet Autodiscovery Route), 2 (MAC/IP Advertisement Route), 3 (Inclusive Multicast Route), or 4 (Ethernet Segment), taken from the IANA EVPN Registry.
Routes bearing a Transitive Opaque Extended Community with sub-type CP-ORF MUST NOT be used to determine Eligible Upstream Multicast Hops (UMH) when applying Multicast VPN procedures.
When a BGP speaker receives a ROUTE-REFRESH message containing a CP-ORF that violates any encoding rule in Section 2, the BGP speaker MUST ignore the entire ROUTE-REFRESH message. It SHOULD also log the event, but MAY apply logging thresholds.
When the BGP ROUTE-REFRESH message carries CP-ORF entries, the ORF Type MUST be equal to CP-ORF (65), the AFI MUST be equal to IPv4, IPv6, or L2VPN, and the Match field MUST be equal to PERMIT.
When the ROUTE-REFRESH message includes only CP-ORF entries, the BGP speaker MUST re-advertise routes affected by those CP-ORF entries. It is RECOMMENDED not to re-advertise routes unaffected by the CP-ORF entries.
CP-ORF (Covering Prefixes Outbound Route Filter) is a new ORF type (code point 65) that a BGP speaker sends to a peer 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.
In EVPN hub-and-spoke, a Default MAC Gateway (DMG) advertises an Unknown MAC Route (UMR) — a MAC/IP Advertisement Route with MAC Address Length 48 and MAC address 00:00:00:00:00:00 — to signal its role. Spokes use CP-ORF to pull specific MAC/IP routes when they determine a more direct path is beneficial.
The CP-ORF clean-up mechanism requires BGP speakers to periodically evaluate and remove unneeded CP-ORF entries, since each CP-ORF consumes memory and compute resources on the supporting device. Criteria for removal are a matter of local policy.
When a route matches a CP-ORF entry and passes remaining Outbound Filter rules, the BGP speaker places it in Adj-RIB-Out, adds the CP-ORF Import Route Target to the route's RT list, and adds a Transitive Opaque Extended Community with sub-type CP-ORF (0x03) before advertising to the peer.
IANA allocated code point CP-ORF (65) in the 'BGP Outbound Route Filtering (ORF) Types' registry and code point CP-ORF (0x03) in the 'Transitive Opaque Extended Community Sub-Types' registry, both from the First Come First Served range, and updated these entries to reference RFC 7543.
To protect against resource exhaustion from CP-ORF oversubscription, a device MUST advertise willingness to receive CP-ORF only to known, trusted iBGP peers, and MUST enforce a per-peer limit on the number of CP-ORFs installable at any given time, ignoring requests that exceed the limit.
CP-ORF Type-specific information encodes: Sequence (32 bits), Minlen (8 bits), Maxlen (8 bits), VPN Route Target (64 bits), Import Route Target (64 bits), Route Type (8 bits), and Host Address (0, 32, 48, or 128 bits depending on AFI).