Summary

  • The IETF published revision 18 of Traffic Steering using BGP FlowSpec with SR Policy on 5 September 2026. At the research cutoff it remained an active Internet-Draft in AD Evaluation::External Party, not an approved RFC.
  • Revision 17 required ordinary Redirect-to-IP fallback when an instruction carried a redirect target but lacked a valid Color for SR Policy selection. Revision 18 reverses that treatment when explicit SR intent is present: a supporting headend must not redirect normally and must drop the matching traffic or apply local failure policy.
  • A valid FlowSpec route stays in the control plane and continues downstream even when the resolved SR Policy is down or cannot be installed. Its forwarding action is separately marked inactive, making route receipt different from packet treatment.
  • The current compatibility section says a non-supporting headend can ignore an unfamiliar Prefix-SID attribute and use ordinary Redirect-to-IP. Mixed support can therefore turn the same received instruction into a drop on one device and a redirection on another.
  • The earlier Working Group Last Call covered revision 13. After revision 17, the responsible Area Director asked the IDR chairs to poll the group again. Revision 18 now needs a version-bound consensus and rollout receipt covering every failure row, capability boundary and observed packet outcome.

One missing field, two forwarding results

FlowSpec distributes packet-matching rules and actions through BGP. The new draft combines a Redirect-to-IP target with a Color Extended Community to form the (Endpoint, Color) tuple that selects a Segment Routing Policy. A second mode can also carry a BGP Prefix-SID attribute containing an SRv6 egress service SID, so that the far end performs a particular table lookup or cross-connect action.

That makes omission more consequential than a malformed label. A redirect target by itself already has a meaning under the separate Redirect-to-IP proposal. A redirect target plus a valid Color expresses the new SR Policy steering. A Prefix-SID beside the redirect target but without a valid Color looks like an incomplete attempt to express the latter.

Revision 17 chose a permissive interpretation for that incomplete case. It said the headend must fall back to ordinary Redirect-to-IP and ignore the Prefix-SID for SR Policy steering. Revision 18 chooses containment instead. When the route explicitly signals SR intent but lacks a valid Color, the headend must not use a default or null-colour policy, must not use the service attribute, and must not fall back to ordinary redirection. Matching traffic is dropped or handled under local failure policy.

The distinction remains narrow. A route carrying only a valid Redirect-to-IP community, without an SR-specific attribute or invalid Color, still means ordinary IP redirection. The new rule is not “drop every redirect without Color”. It is “do not reinterpret an incomplete SR instruction as a plain redirect”. That sentence is the difference between protecting an intended engineered path and unexpectedly cutting a legitimate flow.

The route can live while the forwarding action dies

Revision 18 also sharpens the separation between the control and forwarding planes. If the matching SR Policy is down, unresolved or absent from the forwarding plane, a syntactically valid FlowSpec route remains in the Loc-RIB and continues to be advertised under ordinary BGP rules. Underlay or policy failure alone must not invalidate or withdraw it.

The associated steering state is different. It must not become active in the FIB or TCAM, or must be marked down. If the SR Policy works but the egress service SID is unreachable, the headend must likewise avoid silent shortest-path forwarding toward the target. The default local action should be drop, although the operator may define another failure policy. Other valid non-steering actions, such as rate limits or DSCP changes, continue to apply.

This is useful discipline. A route withdrawal would conflate “the instruction is structurally valid” with “this device can execute it now”. Retention allows the instruction to propagate and become usable after recovery. But a dashboard showing the route as present does not establish what happened to matching packets. A credible receipt needs at least three independent states: route accepted, steering installed, and packet action observed.

The new operational text asks implementations to expose failure reasons, notifications and drop counters. It allows per-event logging to be rate-limited, aggregated or suppressed during floods and resource exhaustion, provided summary telemetry remains. That exception is sensible for control-plane survival. It also means silence is not evidence of absence. Operators need the suppression state and aggregate denominator alongside the alarm count.

Unsupported equipment follows another branch

The most important compatibility sentence sits outside the new failure table. A headend that supports base FlowSpec and Redirect-to-IP but not this specification treats the optional transitive Prefix-SID attribute as unfamiliar. It can ignore that attribute for forwarding and fall back to ordinary Redirect-to-IP behaviour.

The current draft therefore contains two legitimate readings by capability. A supporting revision-18 headend recognises incomplete SR intent and refuses the ordinary fallback. A non-supporting headend does not possess that meaning and may redirect. This is not a contradiction inside one implementation. It is a mixed-fleet boundary.

The prescribed containment is administrative: controls should enable or disable SRv6 service-steering attributes by neighbour and service, and domain boundaries should filter them. That reduces exposure, but it does not prove a receiver's support level. Before rollout, the sender needs an inventory or negotiated deployment condition that identifies which headends implement the current rules. Otherwise a single BGP update can preserve its bytes across the network while changing operational meaning at the last hop.

The tests must include planned absence, not only successful steering. Send each meaningful attribute combination to a supporting node and a non-supporting node. Make the policy unavailable. Make the service SID unreachable. Exhaust the forwarding resource. Confirm Loc-RIB state, onward advertisement, installed FIB action, drop and redirect counters, user-packet result, notification and recovery. A happy-path policy binding cannot expose this divergence.

Consensus belongs to a text, not a project name

The process record explains why this is a governance story. The shepherd write-up says revision 13 emerged from a short one-week Working Group Last Call with positive support. During Area Director review, the document then acquired two explicit operating modes, a sequential attribute-resolution model, revised failure behaviour, broader service actions, compatibility rules and stronger operational and security text.

After revision 17, on 26 August, the responsible Area Director asked the IDR chairs to poll the Working Group to check consensus before the document could progress. The Datatracker moved to AD Evaluation::External Party. Revision 18 appeared on 5 September with another substantial set of changes, including the reversal of incomplete-intent fallback, explicit service-SID failure handling and more detailed boundary, notification and observability rules.

Requesting another poll is not procedural delay for its own sake. A participant can support the goal of FlowSpec-to-SR steering while opposing a particular fail-open or fail-closed rule. A network carrying emergency mitigation traffic may prefer containment. Another service may regard an avoidable drop as the larger harm. Rough consensus must show that the material objection was understood and addressed in the text; it cannot be inherited automatically from a version whose decision table said the opposite.

The poll should therefore identify the exact revision and question. “Does the group still support the document?” is less reproducible than: “Does the group support revision 18, including no ordinary Redirect-to-IP fallback for incomplete SR intent, separation of route validity from forwarding installation, local drop-on-failure and the stated mixed-support behaviour?” The archive should retain objections and the chairs' reasoning, not just a binary result.

Running code does not time-travel

The draft reports four router implementations and four controllers that passed joint interoperability testing organised by China Mobile between July and October 2021. It also reports active production use on China Mobile's backbone since August 2022. Those facts are relevant. The implementation-status disclaimer is equally relevant: the information was supplied by contributors, was not independently verified and does not imply IETF endorsement.

The dates create a further boundary. Historical testing can demonstrate that a useful mechanism existed. The checked record does not establish that the 2021 suite exercised revision 18's present attribute matrix, its replace-or-append service-SID rule, the newly explicit unreachable-SID branch, or a fleet split between supporting and non-supporting headends. Later prose cannot retroactively add those cases to an earlier test.

That is not an argument to discard the deployment evidence. It is an argument to version it. Each implementation entry should state the draft revision, feature subset, exact attribute combinations, negative cases, peer capability and observed packet action. A current retest can then extend the historical record instead of borrowing its authority.

Publish the receipt before progression

A compact version-bound receipt can join the two governance acts that are now separate. Its first section records revision 18, a source hash, poll opening and closing times, the question asked, archived responses, substantive objections and the chairs' assessment. Its second section records what implementations actually tested.

The test matrix should distinguish valid plain redirect, valid Mode 1, valid Mode 2, missing or malformed Color, down or unresolved policy, unreachable service SID and failed FIB programming. For every row it should show the supporting-node action, the non-supporting-node action, Loc-RIB and advertisement state, installed forwarding state, packet result, counters, alarms and any suppressed diagnostics.

A rollout section identifies the sender, receivers, version and capability map, boundary filters, authorised service-SID ranges, local failure policy, retry/backoff behaviour and rollback trigger. Corrections append rather than replace the first result. Sensitive addresses and policy values can be pseudonymised; the evidence does not require publishing the network map.

Heng Lu's minimum-specification discipline is useful here only as an editorial test. The shared standard should make the common message and failure meaning deterministic enough to verify. The operator should retain authority over local failure policy and deployment scope. Neither side works if the revision, capability boundary or actual packet effect is hidden.

Revision 18 may be safer than revision 17. That judgment belongs to the Working Group and to operators who will carry the loss. The immediate requirement is more basic: consent to the rule that exists now, and prove what both new and old headends do when the route stops being complete.

Sources

  1. IETF Datatracker — Traffic Steering using BGP FlowSpec with SR Policy
  2. IETF — revision 18 text
  3. IETF — revision 17 text
  4. IETF Author Tools — revision 17 to 18 comparison
  5. IETF Datatracker — document history
  6. IDR list — request to check consensus after the changes
  7. IETF — document shepherd write-up
  8. RFC 8955 — Dissemination of Flow Specification Rules
  9. RFC 9256 — Segment Routing Policy Architecture
  10. RFC 7942 — Improving Awareness of Running Code
  11. RFC 7282 — On Consensus and Humming in the IETF
  12. Heng Lu — Minimum Initial Specification