Summary

  • draft-ietf-idr-fsv2-ip-basic-08 gives FlowSpec rules user order, mandatory and optional components, and a Dependent Filters Chain, but those controls are evaluated locally and do not create a network-wide installation acknowledgement.
  • Operators need a separate receipt for each target node: what it received, understood, validated, ordered, installed, omitted, counted and removed, followed by packet evidence. BGP propagation alone cannot close that chain.

The route reflector did its job

The emergency filter left the controller. Every route reflector accepted it. The expected peers received it. Looking only at BGP, the operation is green.

At the first edge, the complete match and action set reached the forwarding plane. At the second, an unsupported mandatory component made the rule ineligible, so its dependent rules were withheld too. At the third, an optional component was omitted and the remaining rule was installed. A fourth device propagated an action community it did not understand. The same control-plane object produced several effective packet policies.

This is not a hypothetical defect smuggled into the standard from outside. It is the operating surface described by revision 08 of draft-ietf-idr-fsv2-ip-basic, dated 28 September 2026. The draft defines a more expressive and deterministic successor to the first version of BGP Flow Specification. It also explains where determinism ends.

The uncomfortable sentence arrives late in the document: BGP still does not have an action-reply feature. Distribution is fast and scalable. Reporting that a filter was installed belongs to another mechanism.

That sentence changes what a green BGP session is allowed to mean. It can prove carriage. It cannot prove execution.

Revision 08 is current work, not deployed law

The Datatracker lists revision 08 as an active IDR working-group Internet-Draft. Its text says Standards Track; the metadata table leaves intended RFC status unspecified. It is in the I-D Exists state, not the RFC Series. The document also retains provisional AFI, SAFI and filter-family values marked TBD, plus visible editorial notes and mechanisms deferred to companion work.

Those details are not cosmetic caveats. They define the claim boundary. The draft is strong evidence of the design problem the working group is trying to solve. It does not establish that a particular router supports revision 08, that any operator has deployed it, or that its unfinished portions will survive unchanged.

The design comes from operational pressure in FlowSpec version 1. RFC 8955 defines IPv4 distribution, RFC 8956 extends it to IPv6, and RFC 9117 revises validation behavior. FSv2 separates itself with new address-family and service-family identifiers. The two versions can therefore travel as “ships in the night”. A transition network may contain peers that support both, one or neither.

That clean protocol separation creates an operational composition problem. Packets do not travel through two ships. They encounter one ordered set of effective filters on a device.

User order is an instruction, not a receipt

Each FSv2 NLRI contains a 32-bit User Order. Lower values receive better precedence. When the default component ordering does not express the operator’s intent, this field can tell an implementation where the rule belongs.

The field is useful because filtering is order-sensitive. A narrow permit followed by a broad drop is not equivalent to the broad drop arriving first. Revision 08 recommends that FSv2 filters precede FSv1 filters and sketches a common database in which FSv1 entries receive order values beyond the FSv2 range.

But User Order is carried intent. A receiver still has to parse it, combine it with all locally present FSv1 and FSv2 rules, resolve ties, validate the match and actions, translate the result into a device representation and program the relevant software or hardware table. A BGP UPDATE does not return that effective sequence to its originator.

The receipt must therefore preserve both numbers: the advertised order and the installed order. If they differ, the reason is part of the incident record, not an implementation footnote.

The dependency chain fails locally

FSv2’s Dependent Filters Chain addresses a real partial-installation hazard. The draft gives an example in which a more-specific rule permits SMTP traffic and sets a DSCP value, while a less-specific rule drops the larger prefix. If the first device cannot perform the DSCP action and installs only the broad drop, legitimate traffic is lost.

A non-zero DFC value associates rules that should share fate. When a rule is locally invalid, every locally received rule with the same DFC value becomes invalid and is not installed. This is a valuable fail-closed mechanism.

It is not a distributed transaction.

One node can deem the cohort valid while another rejects it. A route reflector can check syntax and propagate the rules without implementing their semantic meaning. An upgrading network can contain new and old filter capabilities at once. DFC does not send an acknowledgement to the originator, compare outcomes among devices, or roll back an already installed cohort elsewhere.

Calling the chain “atomic” would therefore promise more than the draft supplies. It coordinates local eligibility. Network-wide convergence still needs an inventory of intended targets and a receipt from each one.

Optional means the installed rule may be different

Revision 08 puts an Optional flag on match components. If a device cannot implement an unsupported mandatory component, the rule is invalid. If the component is optional, the device may omit it and install the rest of the rule as valid.

That distinction enables incremental deployment. It also changes the effective match.

Suppose a rule combines a destination prefix with a newer qualifier intended to narrow the traffic set. On a capable node, both components constrain the match. On an older node, an optional qualifier can disappear while the prefix and action remain. The received rule and the installed rule now cover different traffic sets even though both are labelled valid.

This does not make optionality a mistake. It makes omission an event that must be observable. An operator should know which component was removed, what set of packets the residual rule can match, which action remains, and whether that broader or different treatment was authorised for that node.

The same uncertainty exists for actions. Revision 08 says an implementation unable to install a traffic action may decide validity according to implementation defaults or configuration. It also says ordered-action and validity features may be considered in future work. That is not a stable basis for assuming identical behavior across a mixed fleet.

An unknown action can travel farther than its meaning

FSv2 actions can be associated with filters through Extended Communities. RFC 4360 supplies the general carriage and transitivity machinery. A device that does not understand a newer transitive action can still propagate it.

The draft is explicit about the consequence. An older implementation may be unable even to determine that the action was requested. Its default becomes best-effort execution of the actions it does understand.

The control plane therefore preserves bytes more reliably than meaning. Downstream peers may receive the complete object because an intermediate node carried it correctly. That intermediate node may nevertheless apply a different local policy—or none at all—to matching packets.

The distinction matters most during mitigation. A filter intended to sample, mark and redirect traffic may be reduced on one device to the subset it recognizes. Revision 08 discusses how multiple actions interact and says a complete solution requires later Action Community Container work. A successful UPDATE is not a certificate that the ordered action set exists in the dataplane.

Validation protects the route, not the outcome

The draft defines several validation stages: the NLRI must be well formed; the route’s properties are checked; and actions are evaluated. By default, feasibility depends on a destination prefix and related unicast-routing evidence, although explicit configuration can relax parts of the rule.

These checks reduce unsafe distribution. They do not collapse validation into installation.

Some malformed NLRIs require a BGP session reset because boundaries cannot be recovered. Other detectable failures use RFC 7606’s treat-as-withdraw behavior so the receiver can continue parsing later NLRIs. Revision 08 additionally warns that a malformed withdrawal of a previously valid rule can leave a stuck route and requires operator notification.

That warning gives withdrawal its own evidence boundary. The origin can send a withdrawal. A peer can parse it. Its RIB can remove the route. The filter can still remain in a downstream policy store, software classifier or hardware table until removal is observed. “No longer advertised” is not the same statement as “no longer acting on packets”.

BGP is fast because it does not wait for execution

The design deliberately uses protocol strengths. RFC 4760 lets BGP carry different families through the same peer system. Route reflectors can distribute policy at scale. Extended Communities carry associated actions. None of that requires the sender to hold the transaction open until every forwarding device has programmed hardware.

Revision 08 says the historical validation of distributed filters occurred outside BGP. NETCONF and RESTCONF have request/reply patterns; the draft suggests combining rapid BGP distribution with longer-term management requests that report installation.

That is an architecture suggestion, not a magic adapter. A management response can itself mean several things: request accepted, intended configuration changed, operational datastore updated, software classifier programmed, hardware table committed, counter created or packets actually affected. RFC 6241 and RFC 8040 give management protocols structured exchanges. They do not make a vendor-neutral FlowSpec installation receipt appear without an appropriate data model and implementation.

The useful pattern is two-speed control. BGP opens the intervention quickly. A slower evidence loop determines whether each target installed the exact rule, whether the intended packet class encountered it, and whether the intervention may remain in force.

The receipt an FSv2 operation needs

A defensible record should keep at least fourteen layers separate:

  1. the exact draft or RFC revision, AFI/SAFI and filter-family identifiers;
  2. the commissioning authority, incident or policy ticket and intended target set;
  3. the complete NLRI, User Order, DFC and match-component flags;
  4. every action community, its transitivity, precedence and mandatory status;
  5. the origin and route-validation inputs, including any explicit relaxations;
  6. peer-by-peer advertisement and receipt timestamps;
  7. each node’s supported filter and action versions;
  8. unknown, unsupported or omitted components and actions;
  9. the locally computed eligibility of every DFC cohort;
  10. the final combined FSv1/FSv2 order on the node;
  11. installed software and hardware entries with generation or transaction identity;
  12. counters or sampled packet evidence for the intended match and action;
  13. expiry, withdrawal, operational removal and any stuck-state alarm; and
  14. the decision to continue, narrow, roll back or close the intervention.

No single one of these records substitutes for all the others. Route receipt proves that a peer obtained a control object. A local validation result proves that the object met a rule set. A hardware entry proves that something was programmed. Packet counters prove that traffic met a classifier. Recovery requires its own observed state.

This is the practical meaning of running-code primacy. The specification describes what compliant code should do. The operational decision depends on evidence of what particular code did, on a particular device, for a particular rule, at a particular time.

Sources