RFC 9830 - Advertising Segment Routing Policies in BGP¶
| Field | Value |
|---|---|
| Title | Advertising Segment Routing Policies in BGP |
| Authors | S. Previdi, C. Filsfils, K. Talaulikar (Ed.), P. Mattes, D. Jain |
| Date | September 2025 |
| Status | Proposed Standard |
| Updates | RFC 9012 (Color Extended Community) |
| Link | rfc-editor.org/info/rfc9830 |
Summary¶
RFC 9830 defines the BGP SR Policy SAFI (SAFI 73), the standard way for a controller, or an egress router, to push the candidate paths of an SR Policy to the headends that should instantiate them. It is the BGP counterpart of PCEP (RFC 9603) for SR Policy provisioning, and it works for both SR-MPLS and SRv6.
BGP is only the transport. A headend runs normal BGP best-path selection, then hands the received candidate path to its SR Policy Module (SRPM), which validates it, selects the active candidate path per the SR Policy Architecture (RFC 9256), binds the Binding SID and programs forwarding. BGP itself never installs the policy and does not validate the meaning of the segment lists.
Its companion RFC 9857 closes the loop in the other direction: controllers push policies with this SAFI and read their operational state back through BGP-LS.
Key Sections¶
| Section | Topic | Description |
|---|---|---|
| 2.1 | SR Policy SAFI NLRI | SAFI 73 with AFI 1 or 2; NLRI = Distinguisher + Color + Endpoint |
| 2.2 | Tunnel Encapsulation Attribute | The policy rides in Tunnel Type 15, "SR Policy" |
| 2.4 | SR Policy sub-TLVs | Preference, Binding SIDs, segment lists, ENLP, priority, names |
| 2.4.3 | SRv6 Binding SID | 16-octet SRv6 BSID with optional endpoint behavior and SID structure |
| 2.4.4 | Segment List and segments | Explicit paths, weights, segment types A (SR-MPLS) and B (SRv6) |
| 3 | Color Extended Community | Color-Only bits that control endpoint matching for steering |
| 4 | Advertisement and validation | Route Targets vs NO_ADVERTISE, usability, propagation rules |
| 5 | Error handling | Treat-as-withdraw for invalid NLRI, TLVs and sub-TLVs |
The NLRI¶
| Field | Size | Meaning |
|---|---|---|
| Distinguisher | 4 octets | No semantic value; separates several candidate paths of one policy, or policies for different headends with the same Color and Endpoint |
| Color | 4 octets | Non-zero value that matches destination prefixes (via their Color Extended Community) to the policy |
| Endpoint | 4 or 16 octets | IPv4 or IPv6 endpoint; can be the null endpoint (0.0.0.0 or ::) |
The policy content travels in the Tunnel Encapsulation Attribute (type 23) with Tunnel Type 15. Only one SR Policy TLV is allowed per attribute.
SR Policy Sub-TLVs¶
| Sub-TLV | Type | Notes |
|---|---|---|
| Preference | 12 | Candidate path preference used by the SRPM |
| Binding SID | 13 | Generic BSID (SR-MPLS label or SRv6 SID) |
| SRv6 Binding SID | 20 | 16-octet SID, flags S/I/B, optional endpoint behavior and SID structure; recommended over type 13 for SRv6 |
| Segment List | 128 | One explicit path; may repeat for multiple weighted paths |
| Weight | 9 | Inside a Segment List; zero is invalid |
| ENLP | 14 | Explicit NULL Label Policy (values 1–4) |
| Priority | 15 | Order in which policies are recomputed after a topology change |
| Candidate Path Name | 129 | Symbolic name of the candidate path |
| SR Policy Name | 130 | Symbolic name of the policy |
None of these sub-TLVs affect BGP best-path selection or how the route propagates.
SRv6-Specific Pieces¶
| Element | Detail |
|---|---|
| Segment Type B (type 13) | One 16-octet SRv6 SID per segment |
| Endpoint behavior and SID structure | Optional on Type B segments and the SRv6 BSID: a 2-octet RFC 8986 behavior codepoint (0xFFFF = opaque, headend decides) plus Locator Block / Locator Node / Function / Argument lengths, which must total 128 bits or less |
| No mixing | A segment list must not mix SR-MPLS and SRv6 segments |
| More segment types | Types C–K (including SRv6 SIDs expressed as node or adjacency addresses) are defined in the companion RFC 9831 |
Who Gets the Policy: Route Targets vs NO_ADVERTISE¶
- An advertisement SHOULD carry Route Targets in IPv4-address format that identify the intended headends; a headend treats the update as usable only if one Route Target matches its BGP Identifier.
- Without a Route Target, the update MUST carry the NO_ADVERTISE community, which makes it usable by the receiving neighbor and never propagated further.
- SR Policy routes are not sent to EBGP neighbors by default, but they follow normal IBGP rules, so route reflectors can carry them.
- An update with unrecognized sub-TLVs should be treated as not usable; if an update becomes unusable, BGP removes the candidate path from the SRPM.
Common Pitfalls
- The Distinguisher is not a policy identifier. Two candidate paths of the same policy differ only by Distinguisher; the policy is Color + Endpoint (+ headend).
- Forgetting both a matching Route Target and NO_ADVERTISE makes the update invalid, not just unusable, so it never reaches the SRPM.
- Dynamic and composite candidate paths from RFC 9256 are out of scope; this SAFI carries explicit candidate paths.
- SR Policies can expose sensitive topology. Keep SAFI 73 on dedicated sessions inside the trusted SR domain.
Related Drafts & Updates¶
| Document | Relationship | Description |
|---|---|---|
| draft-ietf-idr-sr-policy-safi | Draft lineage | Draft that became RFC 9830 |
| RFC 9831 | Companion | Segment Type Extensions for BGP SR Policy (types C–K) |
| RFC 9857 | Complement | Reports SR Policy state back to controllers through BGP-LS |
| RFC 9012 | Updated | BGP Tunnel Encapsulation Attribute (Color Extended Community) |
Related¶
- SR Policy - Candidate paths, Binding SIDs, color steering and ODN
- Traffic Engineering - SRv6 traffic engineering with SR Policies
- RFC 9256 - SR Policy Architecture
- RFC 9603 - PCEP Extensions for SRv6
- RFC 9857 - SR Policies in BGP-LS