Summary

  • The IDR working group's 28 September revision 08 is an active Internet-Draft, not an RFC or an approved allocation of new protocol numbers.
  • Revision 07 placed basic IP matching under proposed filter family 256 and listed IP destination prefix as component 60. Revision 08 separates IPv4 Basic family 1000 from IPv6 Basic family 1100; its IPv4 destination-prefix component is 1000 within the IPv4 family.
  • A family number and a component number form a versioned interpretation. A relay that can carry the route has not thereby demonstrated that it understands, installs or applies the intended filter.

The number is not the whole instruction

FlowSpec distributes traffic-match rules and actions through BGP. Its first version's IPv4 specification is already an RFC; the v2 Basic IP work is not. In July's draft, a common IP Basic family covered the proposed match-component list. September's version gives IPv4 and IPv6 separate families and divides additional material into Queue Pair, CAT and Routing Augment component sets. An operator reading only a component number would miss the family that gives it context. A test fixture written for the July tuple cannot be silently treated as a fixture for September's tuple, even where the human-readable match name sounds familiar.

The change is larger than renumbering a table for publication. Family types set the order in which the draft's TLVs are encoded, and the proposal requires strict ordering and no duplicates within an NLRI. A parser can therefore face an exact wire-format question before any traffic policy is installed. At the same time, the draft is plainly unfinished: its IANA section requests an AFI, two SAFIs and new registries, with AFI/SAFI values still marked TBD. Its proposed family numbers should not be reported as completed assignments.

A route can travel farther than its meaning

Revision 08's partial-deployment section describes nodes that check syntax but not the meaning of a filter family, and upgrades in which only some nodes recognize a new type. Its validation text permits a speaker ignorant of an otherwise well-formed family or component to pass the route onward, subject to configuration. It also acknowledges that a semantically wrong rule may reach a speaker able to interpret it. This is a design boundary, not a reported incident or an allegation about any router.

That boundary matters because receiving, relaying, recognizing and installing are different events. The draft separately discusses local invalidity, dependencies between rules and whether an unsupported match component is optional or mandatory. Even a successful BGP distribution receipt cannot answer what filter entered the forwarding plane, much less what packets actually experienced. The revised family map increases the value of preserving the precise draft revision beside any test result.

Sources