Summary

  • An individual IETF draft dated 28 October proposes two PCEP FlowSpec match types for standard SRv6 SIDs and compressed SID containers; both peers must advertise a new S-bit before using them.
  • A PCC must send PCErr Error-Type 30 for an unnegotiated or malformed SRv6 match. The draft calls the Error-Value TBD_EV, while its IANA section requests no such value. The current registry already has separate codes for unsupported and malformed FlowSpec.

A controller reaches into the address

PCEP already lets a Path Computation Element send a Flow Specification rule to a Path Computation Client. The new individual draft wants that instruction to look inside the address itself. One proposed TLV describes the locator, function and argument of a standard 128-bit SRv6 SID. Another describes the locator block, locator node and function used for compressed SIDs. The PCE supplies the match; the PCC would enforce it. That is a larger control surface than matching an entire IPv6 destination address.

The authors put a gate in front of it. During session setup, both speakers must advertise an S-bit in the FlowSpec capability TLV before either sends these new matches. Once a PCC receives one, it must check that the stated structural lengths add to no more than 128 bits. A failed length check makes the TLV malformed. Receipt without the negotiated S-bit is also an error. Those are concrete, local checks, and they matter because the controller does not own every router's interpretation of its own SIDs.

Then the rejection receipt goes blank. Section 5.2 says the PCC MUST send a PCErr with Error-Type 30 and Error-Value = TBD_EV for an unnegotiated or malformed SRv6 FlowSpec component. Section 7 asks IANA to allocate the S-bit and two TLV types. It does not request TBD_EV. The current IANA PCEP registry assigns Error-Type 30 values 1 through 5 and leaves 6 through 255 unassigned. The mandatory answer in this proposal has no assigned number.

There is a sharper question than “please fill in the blank.” RFC 9168, the PCEP FlowSpec framework this draft extends, already names value 1 for Unsupported FlowSpec and value 2 for Malformed FlowSpec. The new text combines both cases under one future “Unsupported or Malformed SRv6 FlowSpec Component” value. The authors could map the two cases to the existing answers, or ask IANA for a new SRv6-specific answer. The published text does neither. If two implementations guess differently, the very error meant to make control safe becomes the part that fails to interoperate.

The gap is narrow and repairable. It is also in the wrong place to leave vague. A controller can send a detailed description of how to dissect 128 address bits. A router that refuses that description should be able to return an equally definite reason. Otherwise the wire carries a precise command and a handwritten blank where the evidence of refusal belongs.

The Datatracker record classifies this version as an individual Internet-Draft. Its next revision can settle the issue by naming the existing values or requesting a new one. Until then, operators and implementers have an actual test to apply to the proposal: find the number the PCC is required to send.

Sources