Summary
- On 9 September the IESG opened Last Call on an Informational draft applying ACTN to packet/optical integration. Comments are due on 23 September; the document has not been approved or published as an RFC.
- Under partial summarisation, a coordinator can know the packet topology in detail while receiving only an abstract optical view. The optical controller keeps local path computation and may conceal internal or vendor-specific facts under policy.
- That view describes potential connectivity for a control decision. It is not, without further records, proof of physical inventory, a resource commitment, realised configuration or observed end-to-end service.
The event is a request for final comments
The IESG announcement of 9 September asks the IETF community for final comments on Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI). The deadline is 23 September and the intended destination is an Informational RFC. At this article's reporting cutoff, the Datatracker record still says “In Last Call,” with no approval or RFC publication to report.
That status is more than procedural housekeeping. The document surveys how existing IETF protocols and YANG models could support coordinated control across IP/MPLS and optical networks. It also marks gaps and operational cautions. A Last Call invites scrutiny of that account; it does not certify a product architecture or compel an operator to adopt it.
The public shepherd write-up summarises the technical scope and names the responsible people, but its template questions about Working Group controversy, implementations and vendor plans remain unanswered. That silence is not evidence that no implementation exists. It is a reason not to attach an implementation claim to the standards record.
A useful map can omit the machinery
Packet/optical integration confronts a familiar coordination problem. A service request may cross routers, packet links, optical transponders, wavelengths and several administrative or technology domains. A single controller with every physical fact might calculate across all of them, but that controller would become a difficult scaling, confidentiality and authority centre.
ACTN distributes the work. A Multi-Domain Service Coordinator, or MDSC, coordinates service decisions. Provisioning Network Controllers, or PNCs, control their packet or optical domains. The interface between them can expose enough traffic-engineering information for coordination without handing the MDSC every internal detail.
The revision 20 draft lays out several visibility choices. Under partial summarisation, the MDSC sees the packet-domain TE topology completely but receives an abstracted view of optical topology. The optical PNC computes its local optical path. Under full knowledge, the coordinator gets a more detailed view of both layers, yet the draft warns of scalability issues and of optical calculations that depend on vendor-specific attributes which can vary between domains.
This is not a ladder from bad data to good data. It is a choice about where knowledge and computation reside. More detail can improve central calculation while enlarging exposure, coupling and operating burden. Less detail can protect domain autonomy and scale while requiring the coordinator to trust delegated computation. Governance begins with making that trade visible.
“Abstract” names a policy boundary
The foundational ACTN framework in RFC 8453 treats abstraction as the application of policy to network information. A PNC can present potential connectivity while concealing technology-specific attributes or internal topology. The recipient of a view and the level of detail are meant to be authenticated, access-restricted, configurable and policy-based.
RFC 7926 gives the earlier architecture behind that exchange. Its abstract topologies can be configured to advertise potential connectivity between selected boundary points, with parameters such as bandwidth or latency. It also notes that an abstract topology may need periodic or incremental updates when the underlying network or its resource use changes.
RFC 8795 makes the information boundary even clearer. A TE topology is a control-plane representation of a data-plane topology. A provider can customise a topology for an individual client, while the provider's native topology remains a distinct object known in full to the provider. The model also uses transitional TE links as helper constructs representing potential connectivity; once a server-layer trail is established, the state has changed.
An abstract view can therefore be accurate for its purpose without being an inventory. It can truthfully say, “under policy P, client C may ask for connectivity of kind K,” while saying nothing about a particular fibre, transponder slot or wavelength. Another client can legitimately receive a different view. A later policy revision can remove or reshape the advertised possibility even if no cable moved.
The correct challenge is not “show me everything or the map is false.” It is “whose view is this, under which policy, based on what source state, and how fresh is it?”
Potential connectivity is not committed capacity
The word “link” is especially easy to overread. On a physical inventory it may mean an installed cable or port relationship. On a TE view it can mean a construct usable for path computation. A transitional link in RFC 8795 exists to express a possible layer transition before the supporting server-layer trail has been created.
That distinction changes what a coordinator can prove. An advertised connection may be eligible under current policy and reported availability. A path computation may find a route across that representation. Neither event, by itself, shows that a domain accepted a reservation, that optical resources were assigned, that packet interfaces were configured or that the end-to-end service passed an observation test.
The ACTN/POI draft preserves some of this separation through delegation. An MDSC can give a PNC a strict route or a loose route. With a loose route, the PNC chooses the complete path inside its own domain and reports the selected path back. The mechanisms an optical PNC uses for local discovery and path setup are commonly vendor-specific and outside the document's scope.
A coordinator log that contains only its input view and computed end-to-end route can consequently miss the decisive local facts. It may not reveal which optical path the PNC selected, whether a reservation expired before configuration, whether a muxponder constraint forced another choice or whether a protection action subsequently moved the service.
The safe evidence equation is deliberately longer:
view advertised ≠ path computed ≠ domain committed ≠ configuration realised ≠ service observed.
Each state can be legitimate. None should borrow the proof belonging to the next.
The gaps are part of the public record
Revision 20 is unusually helpful because it does not describe a frictionless finished system. Its gap list includes augmentations for path computation, SR-TE setup, the minimum number of active links needed for a LAG to remain up, traffic splitting that is not ordinary load balancing and constraints imposed by some muxponder designs.
These gaps have different operational meanings. If a topology model cannot express the minimum active members for a LAG, “link up” at the abstract level may conceal a materially weaker protection state. If fixed muxponder connectivity is not described, a seemingly available client-to-client pairing can fail after local constraint checking. If traffic splitting semantics are incomplete, a feasible aggregate capacity does not establish where flows will actually travel.
This is not evidence that an ACTN deployment fails. The draft is identifying the borders of the common description so implementers know where additional models, procedures or local knowledge remain necessary. Treating the gaps as invisible would be misleading; treating them as proven incidents would be equally wrong.
The operational section asks operators to decide how tightly to integrate the layers, check vendor support and build monitoring across packet and optical domains. It warns that diagnosis can become more complex and that faults in one layer can cascade into the other. An abstract view can simplify the planner's screen while making the forensic chain more dependent on records retained below that screen.
Access control answers “who may ask,” not “what happened”
Cross-domain control is an authority surface. The draft invokes secure transport for RESTCONF, NETCONF and PCEP and points to granular controls for connectivity and resource requests. RFC 8341 defines the Network Configuration Access Control Model. RFC 8040 specifies RESTCONF, and RFC 6241 supplies the NETCONF protocol context.
These controls matter. They can restrict which authenticated principal reads a topology view, invokes a computation or changes configuration. They can protect a domain from an unauthorised coordinator and confine a coordinator to the resources it is allowed to request.
They do not turn an authorised request into delivery evidence. A principal may be entitled to ask for 100 Gbit/s between two edges, yet a later local constraint can block commitment. A protected response may report a calculated path, yet configuration can fail. A correctly configured service can later degrade. Authentication, authorisation, computation, commitment and observation are separate questions.
That separation also prevents a security log from becoming an accidental commercial claim. “An authorised MDSC issued the request” says who acted. It does not say capacity was available throughout the interval, latency stayed within promise or restoration worked.
A cross-layer decision receipt
Operators do not need to publish their native topology to preserve accountability. A privacy- and confidentiality-bounded cross-layer decision receipt can keep the proof states joined without collapsing them.
The first part identifies the advertised view: topology identifier and version, intended client, issuing PNC, abstraction-policy owner, creation time, validity window and freshness declaration. The full native topology can remain with the domain owner. A stable digest or internal reference can link the receipt to the source state without disclosing fibre routes publicly.
The second part records the request and authority: service intent, constraints, requesting principal, access decision, MDSC software and policy revision. It states which computations were central and which were delegated. For a loose path it records the boundary points and constraints given to the PNC, not a fictional centrally chosen internal route.
The third part captures commitment and realisation separately. Each domain acknowledges whether it reserved or committed resources, the scope and expiry of that commitment, and the local path reference returned. Configuration results come afterwards, with packet and optical timestamps, failed constraints, protection state and any divergence from the computed route.
The final part contains observation: the measurement window, reachability, throughput, latency or other service indicators actually collected; alarms across both layers; restoration or rollback; and the correction issued if the public service statement was wrong. Sensitive topology, customer identity and exploitable thresholds need not appear in a reader-facing record.
This receipt is an editorial proposal, not a field set required by ACTN, the IETF or the RFCs cited here. It applies Heng Lu's Policy Mirror to a layered control system: record the actor, the policy view and the evidence appropriate to each state. His Minimum Initial Specification argues for a narrow common surface that preserves local implementation choice. Why BTW Media Exists supplies the final discipline: do not convert an architecture's promise into an observed fact.
ACTN abstraction can be valuable because it lets domains coordinate without surrendering every detail or every local decision. Its legitimacy does not require pretending the abstraction is a physical ledger. It requires preserving the hand-offs by which a policy-shaped possibility becomes—or fails to become—a delivered service.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance