Summary

  • RFC 5291 lets a BGP receiver send typed Outbound Route Filters that its peer can add to locally configured outbound policy, avoiding updates the receiver would otherwise discard. The entries are negotiated by AFI/SAFI, ORF type and Send/Receive direction.
  • ADD, REMOVE and REMOVE-ALL mutate session-scoped peer-supplied state; PERMIT and DENY express preference. None can remove the sender's local export filters, and the peer may decline to honor the request.
  • IMMEDIATE commits the filter change with re-advertisement; DEFER stores it until a later commit. Proof therefore crosses intended entries, wire encoding, received state, local export policy, Adj-RIB-Out, UPDATEs and the receiver's RIB—and repeats after every session reset.

In this illustrative change, the initial troubleshooting evidence is seductive. A before-and-after command on the customer shows a full-table count becoming a few hundred routes. CPU falls. Memory settles. The operator concludes that the provider now sends only the requested feed.

That conclusion does not follow. An inbound prefix-list can produce exactly the same local view while the provider still generates, queues and transmits the full table. The receiver has proven its rejection, not the sender's avoidance. Outbound Route Filtering exists to close that evidence gap operationally, but only if both sides prove the negotiated and applied state.

The request travels in the opposite direction to the routes

Ordinary BGP policy is easy to describe from one box. A sender selects routes for a peer through local outbound policy and forms an Adj-RIB-Out. The receiver accepts, changes or rejects those updates with local inbound policy. Each operator controls its own side.

ORF adds a carefully bounded reverse signal. The receiver sends filter entries to the sender. The sender can incorporate them into the outbound filter associated with that receiver, preventing unwanted updates from being generated or transmitted in the first place. The routes still travel sender to receiver; the preference travels receiver to sender.

RFC 5291 is explicit about composition. Peer-supplied ORFs apply in addition to locally configured outbound filters. A customer can ask for less, but cannot use ORF to remove a provider's safety filter, commercial export rule or confidentiality boundary. REMOVE-ALL means all entries in the specified received ORF, not all outbound policy.

The standard also calls the entries a local preference that the peer may or may not honor. Capability negotiation creates a protocol surface, not a right to remote execution. A receiver that depends on the narrower feed must verify the peer's actual behavior and retain its own inbound protection.

This is practical data sovereignty rather than rhetorical control. Each side can express its desired interface. The sender still owns disclosure; the receiver still owns admission. ORF economizes their shared boundary without merging the two policy domains.

Capability negotiation is a typed, directional intersection

ORF Capability code 3 is advertised during OPEN. Its values are not a universal supports ORF bit. They name an AFI/SAFI, an ORF type and whether the speaker is willing to receive entries, wants to send entries, or both.

A valid exchange exists only at the intersection. If the customer wants to send Address Prefix ORF for IPv4 unicast but the provider offers receive support only for a different family or type, there is no IPv4 Address Prefix ORF relationship. An IPv6 result cannot prove IPv4. The ability to receive an ORF cannot be inferred from the ability to send one.

That intersection changes initial state. For a family where the relevant sets intersect, RFC 5291 says the prospective sender should not advertise routes before it receives a qualifying Route Refresh for that AFI/SAFI: either a plain request or an ORF-bearing request marked IMMEDIATE. This allows the receiver to install its desired filter before the first large feed.

Where the intersection is empty, normal BGP procedures apply. One session may therefore begin silent for IPv4 while IPv6 starts ordinary advertisement, or vice versa. Established compresses away capability direction, type and first-refresh status.

The inventory must retain the OPEN sent and received for the exact session epoch. Static configuration claiming orf send or orf receive is intent. Negotiated capability, active family and accepted type are the running interface.

A filter is a typed state machine, not a copied prefix-list

RFC 5291 models every entry as AFI/SAFI, ORF type, action, match and a type-specific value. ADD installs an entry. REMOVE deletes a matching installed entry. REMOVE-ALL clears the entries for the specified received ORF. PERMIT asks for matching updates to pass; DENY asks that they not pass.

RFC 5292 supplies the common Address Prefix ORF type. Its entry carries a sequence number, a prefix, the prefix's length and minimum and maximum lengths for matching NLRI. That supports exact prefixes, address ranges and more-specific boundaries. Sequence matters because an ORF type needs an unambiguous first matching entry.

A local prefix-list and the remote serialized entry set are different evidence objects. A generator can reverse sequence, mishandle a minimum length, omit a deny, encode the wrong AFI or fail to send the latest revision. Hashing only the local source proves none of the remote state.

Record four identities: the editor's source list, the compiled local ORF entries, the bytes in Route Refresh and the peer's decoded received ORF. Then test the filter's negative space. A canary should include an exact prefix, a permitted more-specific inside the length range, a route one bit beyond the maximum, an explicit deny and a route the sender's local policy blocks regardless of the ORF.

With multiple non-empty ORFs of different types, a route passes through each. RFC 5291 defines the combination so that PERMIT plus DENY yields DENY. A dashboard that displays only one prefix ORF can therefore misstate the effective filter.

DEFER separates writing state from changing the feed

ORF mutations ride in Route Refresh but carry an extra transaction choice. IMMEDIATE tells the peer to process the entries and re-advertise affected routes for the family under the new ORF state. The sender must re-advertise affected routes and may also send unaffected ones.

DEFER tells the peer to store the modifications without yet re-advertising. A later plain Route Refresh or ORF message marked IMMEDIATE commits the visible change. When other policy changes also require a complete re-advertisement, RFC 5291 requires updated entries to be sent with DEFER followed by a plain Route Refresh.

That gap is useful. Several entries can be staged before one coherent feed transition. It is also dangerous. The operator can see the desired entries in local configuration and the peer can show received pending state while the old Adj-RIB-Out remains externally effective.

Treat DEFER as a transaction, not a status adjective. Give it an identifier, expected entry-set hash, intended commit, deadline and rollback. Alert when a deferred mutation survives beyond its window or when an IMMEDIATE arrives with an unexpected set.

Plain Route Refresh does not clear the ORF. It asks the peer to re-advertise under the ORFs previously received. Enhanced Route Refresh markers can demarcate an update exchange, but they do not substitute for the ORF mutation record. Sharing a message family does not collapse these acts into one authority.

Removal can broaden a request, never erase local refusal

Removing a peer-supplied DENY may allow more routes to pass the ORF. Removing the last entry removes that ORF. Yet the new maximum feed remains bounded by the sender's local outbound filters and its decision to honor the request.

This makes rollback asymmetric. A customer can restore its previous request, clear the received ORF or stop negotiating the capability. None of those acts should weaken the provider's explicit export policy. If a provider relied on customer ORF as its only safety control, it has already confused preference with authorization.

The receiver must also keep its own inbound limit. A peer may choose not to honor ORF, may lose state, may support a different type or may re-establish without the expected intersection. Resource optimization must not become the sole admission barrier.

Invalid state has a deliberately sharp failure path

Unsupported AFI/SAFI and ORF types outside negotiated willingness are ignored. REMOVE for an entry that is not present is ignored. Those paths tend to preserve existing state.

An unrecognized value inside an otherwise selected ORF is different: RFC 5291 says the whole specified ORF previously received is removed. The intent is to avoid retaining a partially understood filter, but the operational result can be feed expansion up to the local export boundary.

That deserves a canary. Send a safe malformed or unsupported test only in an isolated relationship designed for it. Predict whether the message will be ignored, the entry ignored or the existing ORF removed. Confirm the resulting Adj-RIB-Out rather than reading a parser log alone.

Security review must consider both scarcity and reachability. A malicious or compromised receiver can send frequent filter mutations, provoking computation and re-advertisement. A compromised sender can claim support while ignoring preferences. Neither party should grant ORF automation unlimited frequency, entry count or unreviewed scope.

Session scope is the natural expiry boundary

An ORF lives for the BGP session in which it was exchanged. When the session ends, the received remote state ends with it. A configuration screenshot taken before reset is not proof after re-establishment.

The next session negotiates capability again. For an intersecting family, the first qualifying Route Refresh governs when the sender begins its feed. A race, missing initial request or changed capability can alter the route set even when the local prefix-list file never changed.

Session epoch should therefore be a primary key in evidence. Store OPEN capabilities, first ORF or plain refresh, exact received entries, activation result and the first Adj-RIB-Out snapshot together. Alarm if routes appear before the expected initial request or if a request expected by the receiver never reaches the sender.

This is also the clean rollback boundary. Ending the session clears peer-supplied state, but it is a high-impact reset, not the default fix. Prefer an explicit reverse mutation and observed withdrawal or re-advertisement. Use session reset only when the plan predicts the entire restart sequence.

A two-sided canary proves saved work

Begin with a small peer and one address family. Prove the baseline with ordinary local export and inbound filters. Measure sender export candidates, transmitted updates, receiver input and receiver rejection.

Negotiate Address Prefix ORF in the intended directions. Before the first feed, send an IMMEDIATE request containing a narrow permit and deny. On the sender, confirm the decoded entries and local-policy intersection. Compare pre-ORF export candidates with Adj-RIB-Out. On the wire and receiver, prove that excluded updates were never sent, not merely discarded.

Stage a second revision with DEFER. Confirm that remote stored state changes while the feed does not. Commit it with a plain Route Refresh, then match the exact delta. Exercise REMOVE, nonexistent REMOVE, REMOVE-ALL and last-entry removal. Rebuild the prior state without weakening local export.

Finally reset the session. Prove that old received ORF state is gone and that capability plus first-refresh sequencing reconstructs the expected feed. Repeat for every enabled AFI/SAFI.

The acceptance result is not “ORF enabled”. It is a ledger of saved work and preserved authority: which routes the sender did not generate for this peer, which local rules still prevented disclosure, which exact request produced the change and which receiver observations confirmed it.

ORF creates a narrow right to ask a neighbor for fewer statements. Its safety comes from refusing the tempting inverse. The receiver cannot demand more disclosure, cannot erase the sender's rules and cannot assume old session state survives. Cooperation becomes efficient precisely because neither network has to surrender its boundary.