Summary

  • The PCE working-group draft, revision 03, proposes an OPEN capability and a per-path S-BFD flag in PCEP. A PCE sends a request in PCInit or PCUpd; a path computation client reports state in PCRpt.
  • B=1 requires a remote discriminator. B=0 calls for removal or non-application, but the draft also discusses ignoring parameters and carries an editor's alternative in which an absent TLV means removal. Those are different instructions for a control loop.

The control panel has two owners

The draft's current archived text offers a tempting picture: a path computation element, or PCE, can tell a path computation client, or PCC, to enable Seamless Bidirectional Forwarding Detection for a particular label-switched path. The PCE has the planning view and the PCEP connection. The PCC has the path and the local machinery that would run the detector. Giving the controller a switch sounds tidy. It also creates a place where a sent command can be mistaken for an applied configuration.

The first switch is actually in the PCEP session's OPEN exchange. A speaker advertises the proposed LSP-S-BFD-Capability TLV; B=1 there says it supports S-BFD configuration and can exchange the new TLVs. If that capability is absent, or if its B flag is zero, the peer must not send S-BFD TLVs in the LSPA object toward it. The advertised Path Setup Types must also fit the session's supported list. A mismatch in that list calls for PCErr type 21/value 2 and session closure. If the two peers share no S-BFD Path Setup Type, the draft does not let PCEP configure S-BFD for a created LSP between them. A PCC can still make a local choice about its own S-BFD use. The controller's inability to speak this extension is a protocol boundary, not a ban on the local diagnostic tool.

Negotiation is only admission to the conversation. It says the peer understands a proposed grammar. It does not say the peer has armed any detector. The draft places the per-LSP LSP-S-BFD TLV in LSPA, carried by the PCC's PCRpt report and by the PCE's PCInit or PCUpd message. That gives the control loop a proposed request side and a report side. It does not collapse them into one event. A sent PCUpd, a PCC's report, the router's effective local configuration and a running S-BFD session are four records an operator should keep separate.

One bit, two jobs, and a mandatory number

Inside the per-LSP TLV, B=1 calls for S-BFD to be applied to the specified LSP. The draft requires a Remote Discriminator sub-TLV when that bit is one; it proposes a missing-discriminator error if the field is absent. The other parameters sub-TLV can carry a minimum transmit interval and a multiplier in the 1–255 range. These are not cosmetic fields. Without the remote discriminator, the enabled request lacks a value the draft itself treats as mandatory. A controller that records only “S-BFD on” while dropping the discriminator has recorded an intention, not a valid proposed configuration.

The B flag in the OPEN capability and the B flag in the per-LSP TLV also have different jobs. The first announces whether a peer can use the extension. The second controls a particular LSP. A capable peer can have an LSP on which S-BFD is disabled. Equally, a locally configured detector can exist even when the peers have no shared S-BFD Path Setup Type for PCEP control. A dashboard that presents one green “S-BFD supported” badge for all of this has saved a column by discarding the decision.

Now turn the per-LSP bit off. Section 4.3.2.1 says a received B=0 removes S-BFD on a PCE update or prevents it from being applied on a PCE-initiated LSP. Section 4.2 says a PCC shall ignore a B=0 update when S-BFD was not applied in the first place. It says a PCE may ignore the same condition for a PCC-initiated LSP. Those branches have sensible subjects: a router with no configuration to remove and a controller looking at a path it did not initiate. They still need to be represented accurately in the operator's record. “Disable requested” and “configuration removed” are different claims.

The harder corner is the accompanying parameter. Section 4.2 says a speaker may ignore an S-BFD parameters sub-TLV sent with B=0 and calls ignoring or saving the configuration an implementation decision. Section 4.3.2.2 says the speaker shall ignore that sub-TLV when B=0. The text has not chosen one clean rule for what survives a disable message. An editor's note then floats another design: if the entire LSP-S-BFD TLV is absent, remove S-BFD from the specified LSP. That note is an alternative under discussion, not the operative removal rule in this draft. Absence and an explicit B=0 message are different wire events. Software cannot treat them as synonyms just because a diagram has only one “off” box.

The report cannot certify the path

The draft's error handling makes some failures visible. If a speaker receives an S-BFD TLV without the peer having advertised the capability, it must ignore the TLV and return a proposed PCErr type 19 value. An out-of-range multiplier gets a proposed type 23 value. The IANA section still labels these new values and the TLV types TBD. A planning system can therefore distinguish at least a rejected command from an accepted conversation, while avoiding the false precision of printing unassigned error numbers as if they were registry facts.

The implementation note exposes another ownership boundary. Some implementations, it says, require LSPs in one association group to share identical S-BFD parameters. When their minimum transmit interval, multiplier or remote discriminator differs, the draft says a speaker should return a type 26 association error. “Some implementations” is doing real work in that sentence. It identifies a possible local constraint; it does not make every association group in every network obey one universal S-BFD value set. A central controller that assumes otherwise may misdiagnose a local rejection as a failed PCEP negotiation.

RFC 7880 describes the S-BFD mechanism. RFC 8231 and RFC 8281 provide the stateful and PCE-initiated LSP setting in which PCEP requests and reports matter. The draft also points to the PCE-as-central-controller architecture in RFC 9050. None of those established RFCs is a receipt that this proposed extension has been implemented on a named PCC. Revision 03 supplies wire rules under discussion, not a test result. Revision 02 and 03 differ in date and expiry furniture, not in the substantive control rules examined here; a new revision number did not settle the off switch.

One packet capture would not settle the whole question either. The useful chain is the capability offered in OPEN, the Path Setup Type intersection, the per-LSP request in PCInit or PCUpd, the PCC's subsequent PCRpt, the effective S-BFD configuration and the detector's own session state. A PCUpd can prove what the PCE sent. PCRpt can show what the PCC reported. Local configuration and session state tell the operator what ran. If a path later fails, those records allow a failure-detection investigation to begin; the configuration request alone cannot report the health of the path it was meant to watch.

The current official packet contains the proposed draft and the underlying RFCs, but no named interoperation trace or observed S-BFD session for this extension. A trace pairing a controller's B=0 or B=1 message with the PCC's report and effective detector state would change that assessment for a specific implementation. Until then, the exact words in Sections 4.2 and 4.3.2 matter more than a product slide that says the switch exists.

Sources