Summary

  • draft-ietf-ccamp-fgotn-yang-02 describes a bidirectional, potentially multi-domain fgODUflex resize that is successful only after both directions complete, while the source controller alone reports the final status to the MDSC.
  • A reported lsp-bandwidth-modified-ok does not independently prove current tributary-slot allocation, agreement across working and protection paths, absence of a forced hit, or preserved customer traffic.
  • Operators need a transaction receipt that preserves every controller’s observation, reconciles configuration with operational state and closes on measured service postconditions rather than on one aggregated label.

The multi-domain service asks for more bandwidth. Controller 1 starts the change. Nodes alter the forward direction one by one. The far end triggers the reverse direction. Controller 3 reports that the return path has begun. Eventually Controller 1 tells the multi-domain service coordinator: lsp-bandwidth-modified-ok.

The dashboard turns green.

What, exactly, became true?

The answer in draft-ietf-ccamp-fgotn-yang-02 is narrower than the dashboard suggests. The source controller has reached the point at which it reports completion. The document also says that bidirectional success requires both directions, that every domain controller must report topology and tunnel resource changes, and that 1+1 protection makes both working and protection paths participate. Those are several evidence streams compressed into one final status.

Compression is useful for orchestration. It is dangerous as audit.

Revision 02, posted on 30 September 2026, is an active CCAMP Working Group Internet-Draft. Datatracker records no intended RFC status, responsible Area Director or IESG state. Its manageability, security and IANA sections still contain placeholders. It is not an RFC, a deployment report or proof that any product implements the scenario. The document is valuable because it exposes a hard operational boundary early: a distributed resize can have one final reporter without having one omniscient observer.

Fine-grain capacity is still physical capacity

Fine-grain OTN is intended to carry low-rate client signals efficiently, including services below 1 Gbit/s. Rather than dedicate an unnecessarily large container, an fgODUflex service uses fine-grain tributary slots inside server-layer ODU capacity. The draft models a configurable bandwidth value from 1 to 119 slots and adds slot-list labels to primary, reverse-primary, secondary, reverse-secondary and actual-route information.

That vocabulary makes capacity addressable. It does not make capacity self-proving.

A controller can request 20 slots. A YANG datastore can show 20. A route object can name the slot ranges. A topology view can reduce available capacity while leaving maximum link bandwidth unchanged. Each record describes a different layer. None alone proves that every device reserved the same non-overlapping slots, switched at the intended generation, or carried the customer’s frames without loss.

The practical invariant is not “the bandwidth leaf equals 20.” It is “the same authorized transaction reserved and applied an admissible set of slots across every required segment and direction, with no collision, and the service postcondition held.” That statement needs more than a leaf value.

RFC 8342’s distinction among intended, applied and operational state is useful here. A configuration is a request. Operational state is a device’s present report. Customer traffic is an external observation. Those facts may converge; the model must not assume that one substitutes for the others.

Two directions make one service and two failure histories

The draft’s sequence is directional. The client sends an fgODUflex identifier and target bandwidth to the source-node controller. Resources are reserved or marked before adjustment. The forward Node 1-to-Node 6 change proceeds through the data plane, and the far end automatically triggers the reverse Node 6-to-Node 1 change.

The text is explicit: the bidirectional adjustment is successful only when both directions have completed.

That condition is necessary, but “both complete” still needs identity and time. Did both directions apply the same target? Did the reverse operation belong to the same request generation or to a retry? Were resource reservations still valid when the second direction began? Did an intermediate domain report a later correction after the source controller concluded success? Did either direction revert after a local alarm?

Without a shared transaction identity and immutable participant receipts, matching values can be accidental. A stale forward completion and a fresh reverse completion can look symmetric in a dashboard. They are not one transaction.

Each direction therefore needs its own request digest, start time, controller generation, domain path, reservation set, applied result and operational readback. The end-to-end receipt may join them, but it must not erase their separate histories.

One final reporter is not one source of truth

Appendix A gives the source controller a convenient role. Controller 1 reports the start, Controller 3 reports that reverse adjustment has begun, and Controller 1 later reports success or failure to the MDSC. The appendix also requires all domain controllers, including the intermediate one, to report topology and tunnel resource changes throughout the process.

These requirements reveal two different ledgers.

The first is the decision ledger: who asked, who admitted the request, what target was authorized, and who concluded that the workflow finished. The second is the evidence ledger: which domain saw which resource change, for which direction and generation, at what time, with what readback.

The source controller may be the designated narrator of the first ledger. It cannot become the author of observations it did not make. If the MDSC stores only its final message, controller failover or a disputed result leaves no independently inspectable path back to the participating domains.

Preserve participant reports as signed or otherwise attributable records. Let the source controller reference them rather than replace them. A final status should contain a transaction ID, target, required participant set, evidence-set digest, completion policy version and unresolved exceptions. Then a later auditor can determine what the final reporter knew and what it merely assumed.

Protection doubles the evidence surface

For 1+1 protection, the draft says both working and protection paths initiate the adjustment protocol and signaling, and that each node checks signals from both paths during state processing.

That means a single “service resized” status hides at least four paths of concern: forward working, reverse working, forward protection and reverse protection. The service can continue on the working path while the protection path lags. The dashboard can remain green until the next fault reveals that the standby capacity never converged.

Protection readiness is not a decorative property. It is a future service promise. The completion policy must decide whether a resize is allowed to close when working traffic is healthy but protection is not, whether such a state is degraded rather than successful, and how long it may persist.

Readback must also distinguish configured slots from active forwarding. A protection path may hold the target label while lacking the server-layer resource it will need at switchover. Conversely, temporary reservation may exist without final service association. The receipt should record both resource ownership and path role.

Forced consistency can spend the very property being claimed

The draft names the uncomfortable case: one direction succeeds and the other fails. A controller may issue a forced bandwidth adjustment to restore consistent status, and that action may be hit-impairing.

This is not a minor error branch. It is a governance decision.

The system can preserve the successful direction temporarily, roll it back, retry the failed direction, or force the two sides into a common state. Each choice distributes risk differently. Forced consistency may simplify the control plane while interrupting traffic. A rollback may discard newly available capacity and itself create churn. Waiting may leave asymmetric state that confuses later allocations.

No automatic policy should turn “symmetry is desirable” into “impairment is authorized.” A forced action needs a named authority, a reason, a maintenance or emergency context, a predicted blast radius and an explicit customer-service verification. The result must record whether “hitless” remained true. If the system used a hit-impairing repair, the final status cannot honestly reuse the same success label without qualification.

This is the Heng Lu boundary in operational form: coordination machinery may propose and execute a narrow recovery step, but it does not acquire authority to redefine the consequence. Running traffic decides whether the transition was hitless.

Schema-valid is not transaction-complete

Datatracker’s automated YANG validation reports zero errors and zero warnings for the extracted revision-02 modules. That is useful evidence about schema conformance. It is not evidence that a controller implementation coordinates a safe resize.

The modules expose topology, tunnel bandwidth and labels. The narrative supplies a five-step multi-domain scenario. The document does not yet define a complete transaction protocol with a mandatory global identifier, participant quorum, timeout, rollback state machine, idempotency rule, notification ordering, durable audit record or customer-traffic test. Its manageability and security sections are unfinished.

That immaturity should not be inflated into a defect report. It should shape deployment claims. A vendor can implement the leaves while choosing different orchestration semantics. Two controllers can serialize the same data while disagreeing about when success is safe to report. A lab can validate the YANG and never inject a split-direction failure.

Conformance needs layers: schema validation, RPC behavior, datastore transition, device actuation, multi-controller convergence, protection readiness and traffic outcome. Each layer can pass while the next fails.

The completion receipt

A defensible resize receipt begins before the write. Record the service and fgODUflex identity, current bandwidth, target bandwidth, server-layer ceiling, topology generation, maintenance context, policy version, authorized actor and transaction generation. Hash the intended working and protection path sets.

At reservation, record every domain’s proposed slot ranges, current availability generation, conflict check and reservation expiry. Slot identifiers must be joined to the server ODU context; a number without its link and layer is not globally meaningful.

During execution, keep separate forward and reverse timelines. Record each domain’s start, applied configuration, operational readback, resource delta and exception. For 1+1, repeat those facts by working/protection role. Notifications must be idempotent and ordered by transaction generation, not only by arrival time.

At closure, the source controller should reference an evidence-set digest. The MDSC should verify the required participant set, direction parity, target parity, resource conservation and absence—or explicit authorization—of forced actions. It should not accept a late success from an older generation.

Finally, test the service. Measure loss, defects, delay and throughput over a defined pre/post window. Confirm that protection is ready, not merely configured. Record customer-visible alarms and any automatic reversion. Only then may the operator say “hitless” with evidence.

The last step matters most. A controller can prove that it followed a state machine. It cannot prove, from its own status alone, that the service experienced no hit.