On-Demand Distributing BGP SR Policy Using Outbound Route Filtering Capability

Segment Routing Policy Architecture enables traffic engineering by utilizing an ordered list of segments. In large-scale networks, manually or universally pushing thousands of distinct SR Policies to every provider edge (PE) router leads to severe scalability constraints. Many policies remain dormant, occupying valuable BGP Routing Information Base (RIB) resources without steering any active live traffic. defines a cooperative mechanism for Outbound Route Filtering (ORF), allowing a BGP speaker to advertise its route filtering entries to a peer. By advertising these filters, the upstream peer can suppress sending routes that would otherwise be dropped by the receiver. This document applies the RFC 5291 ORF framework to the BGP SR Policy NLRI (AFI 1, SAFI 73) . By implementing an "On-Demand Pull" model, a head-end router dynamically sends a BGP ROUTE_REFRESH message containing the desired <Color, Endpoint> tuple ORF entries when a localized service or color-coded traffic flow becomes active. The centralized controller or Route Reflector (RR) then pushes only the matched policies, keeping the router's control-plane lightweight.

A BGP speaker supporting the mechanisms defined in this document MUST negotiate the Cooperative Route Filtering Capability as defined in , using the BGP SR Policy AFI/SAFI (AFI=1, SAFI=73). The Capability Value fields MUST contain: AFI: 1 (IPv4) or 2 (IPv6) SAFI: 73 (BGP SR Policy) ORF Type: TBD (SR Policy Tuple ORF) Send/Receive: A head-end router sets this to "Receive-ORF" (0x01). A controller/RR sets this to "Send-ORF" (0x02). BGP speakers MUST negotiate Capability Advertisements for AFI=TBD1 / SAFI=TBD2 during the BGP session initialization phase.

This document defines a new ORF type called SR Policy Tuple ORF (Suggested Value: TBD1 by IANA). An SR Policy is uniquely identified by the 2-tuple: `<Color, Endpoint>`. The type-specific entry encoded within the standard BGP ROUTE_REFRESH [RFC2918] ORF message body is structured as follows:

Action: Encoded as specified in (ADD, REMOVE, or REMOVE-ALL). Match: Encoded as specified in (Permit/Deny). In the context of "On-Demand Pull", a 'Permit' match behaves as a subscription request. Color: A 4-octet unsigned integer indicating the targeted Color value. Endpoint Length: 1 octet indicating the length of the Endpoint address. Typically 4 (IPv4) or 16 (IPv6). Endpoint Address: The network address representing the destination endpoint of the requested SR Policy.

By default, the upstream controller/RR applies an implicit "Deny All" outbound filter for SAFI 73 toward the head-end router until an ORF entry is received. When a service route (e.g., EVPN or VPNv4) with a specific BGP Color Extended Community is received by the head-end router, or when local traffic profiling demands steering toward `<Color, Endpoint>`, the router initiates the pull mechanism: The router constructs a BGP ROUTE_REFRESH message containing an SR Policy Tuple ORF entry. The Action field is set to ADD, and Match is set to Permit. The targeted Color and Endpoint are written into the respective fields. The router sends this message to its upstream controller or Route Reflector.

Upon receiving the ROUTE_REFRESH message with the SR Policy Tuple ORF: The controller parses the requested `<Color, Endpoint>`. It dynamic looks up or computes the segment lists satisfying the request. It dynamically constructs a BGP SR Policy UPDATE message containing the requested policy data and transmits it down to the head-end node.

If the service route is withdrawn, or if the traffic flow ceases to exist over an implementation-specific idle timer, the head-end router MUST tear down the subscription. It sends a ROUTE_REFRESH message with Action set to REMOVE for that specific tuple. The upstream controller then withdraws the corresponding BGP SR Policy route to free up remote memory.

Malicious ORF injections could allow an attacker to trigger policy-request loops or flush out necessary policies on the controller, leading to Denial of Service (DoS). Standard BGP security practices, including GTSM and TCP-AO , MUST be enforced on the peering session.

This document requests IANA to define a new type code in the "BGP Outbound Route Filtering (ORF) Types" registry:

The following people made significant contributions to this document:

The authors would like to acknowledge the review and inputs from xxx.