Summary

  • RFC 6428 interleaves CC and one-second proactive CV packets in one BFD session.
  • CC and CV use distinct G-ACh code points: 0x0022 for BFD CC and 0x0023 for BFD proactive CV.
  • CV carries an immutable Source MEP-ID TLV. The sink MEP uses it, together with encapsulation, label and discriminator evidence, to detect mis-connectivity.
  • RDI is meaningful only in the CC diagnostic field. The diagnostic field in CV must be ignored; CV cannot authorize an RDI interpretation.

The mechanism matters because “UP” is a continuity statement, not a universal service verdict. In normal operation, CC packets are interleaved with one CV packet per second. Loss of continuity is detected after the session periodicity multiplied by the remote Detect Multiplier, while mis-connectivity is detected within one second. A sink MEP should use diagnostic 1 when detection time expires, diagnostic 5 after Link Down Indication, and diagnostic 9 for detected mis-connectivity.

The sink checks wrong encapsulation; an unexpected Source MEP-ID or MEP type; a discriminator mapped to a different label; an expected discriminator arriving on the wrong label; and invalid authentication when authentication is enabled. A mis-connectivity defect requires 3.5 seconds without receiving a CV message exhibiting that defect before exit. On entry, the sink asserts signal fail toward client processes, but traffic blocking is governed by the consequent action defined by the MPLS-TP OAM framework—not by packet receipt alone.

All BFD state changes and Poll/Final exchanges use CC packets. State and Poll/Final information in CV packets must be ignored. In coordinated operation, one bidirectional session tracks defect state. In independent operation, two sessions are used; one session may remain UP while receiving RDI. That is why a monitoring dashboard must show direction, diagnostic field, source identity and defect classification separately.

The authority boundary is deliberate. The operator configures the MEG, MEP-ID, CC periodicity, desired CV state, authentication and key where used, and discriminator policy. The source MEP emits identity-bearing evidence but cannot unilaterally declare correct connectivity at the receiver. The sink MEP classifies the defect. RFC 6371’s OAM framework and consequent-action context constrain what happens to client traffic. No single UP/DOWN value replaces those roles.

A CC-only implementation can demonstrate recurring continuity but cannot establish the intended source identity. Misusing a CV diagnostic field would manufacture RDI semantics that the specification says to ignore. A wrong Source MEP-ID or wrong label mapping remains a defect even when packets arrive. The sources do not establish vendors, deployments, adoption, false-positive rates, customer-impact duration, commercial cost or restoration outcomes; they also do not prove that an UP session equals application health. The frozen errata page is only a retrieval snapshot, not a correction claim.

Operator decision path

  1. Confirm the packet is on the intended MPLS-TP path and, when GAL is used, that GAL is at the bottom of stack with TTL at least one.
  2. Classify the G-ACh code point: 0x0022 is CC; 0x0023 is proactive CV. Do not read CV diagnostics as RDI.
  3. Correlate CC timing, remote Detect Multiplier, diagnostic code and Poll/Final behavior; calculate the continuity deadline from the configured periodicity.
  4. For CV, verify the unchanged Source MEP-ID and expected MEP type, discriminator-to-label mapping, received label, encapsulation and authentication result.
  5. Decide whether the evidence is loss of continuity, mis-connectivity, remote defect or no defect; then apply the configured RFC 6371 consequent action rather than an improvised traffic block.
  6. In independent mode, report session state and received RDI as separate facts; never collapse them into “service healthy.”

Sources

  • RFC 6428 — primary CC, CV and RDI mechanism.
  • RFC 5880 — base BFD state machine and diagnostics.
  • RFC 5586 — GAL and G-ACh carriage.
  • RFC 5921 — MPLS-TP framework and identifiers.
  • RFC 6371 — MPLS-TP OAM framework and consequent-action context.
  • RFC 5860 — MPLS-TP OAM requirements.
  • RFC 5884 — BFD for MPLS LSPs.
  • RFC 5885 — BFD VCCV and CC-only compatibility.
  • RFC 6428 errata — frozen retrieval snapshot only.