| Internet-Draft | BGP SR Policy ORF | July 2026 |
| Yu, et al. | Expires 7 January 2027 | [Page] |
The BGP SR Policy address family defines a mechanism to distribute Segment Routing (SR) policies from a centralized controller to head-end routers. However, pre-provisioning all candidate SR Policies across massive-scale networks impose significant control-plane memory and processing overhead on edge nodes. This document specifies an extension to the BGP Outbound Route Filtering (ORF) capability, leveraging the framework defined in RFC 5291. It introduces a new SR Policy Tuple ORF type that allows a head-end router to precisely request or subscribe to specific SR Policies based on a Color and Endpoint tuple, enabling pure on-demand, pull-based policy distribution.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 January 2027.¶
Copyright (c) 2026 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Segment Routing Policy Architecture [RFC9256] 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.¶
[RFC5291] 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) [RFC9256]. 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 [RFC5291], 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 [RFC5492] 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:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action (2b) | Match (2b) | Reserved (4b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Length (1 octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Address (4 or 16 octets) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Action: Encoded as specified in [RFC5291] (ADD, REMOVE, or REMOVE-ALL).¶
Match: Encoded as specified in [RFC5291] (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:¶
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 [RFC5082] and TCP-AO [RFC5295], 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:¶
o Type: TBD1 o Description: SR Policy Tuple ORF o Reference: [This-Document]¶
The following people made significant contributions to this document:¶
To be added.¶
The authors would like to acknowledge the review and inputs from xxx.¶