IETF Last Call Review of draft-ietf-teas-actn-poi-applicability-20
review-ietf-teas-actn-poi-applicability-20-genart-lc-robles-2026-09-21-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-teas-actn-poi-applicability-20
Reviewer: Ines Robles
Review Date: 2026-09-21
IETF LC End Date: 2026-09-23
IESG Telechat date: Not scheduled for a telechat

Summary:

This document explores the applicability of the Abstraction and Control of TE
Networks (ACTN) architecture to Packet Optical Integration (POI) within the
context of IP/MPLS and optical internetworking. It examines the YANG data
models defined by the IETF that enable an ACTN-based deployment architecture
and highlights specific scenarios pertinent to Service Providers.

The document is quite complete and covers the relevant aspects of the topic. I
have some questions and comments, as outlined below:

Comments/Questions

1- Section 2.1.2 states "...MDSC...uses the returned information to compute the
optimal multi-domain/multi-layer path..."

Is an optimal end-to-end path always guaranteed when path computation is
delegated to the individual PNCs and the MDSC has only an abstracted view of
some domains?

2-Sections 5.2 states "there is a one-to-one relationship between a
multi-technology intra-domain IP link and its underlay optical tunnel."

    2.1- Is this one-to-one relationship an assumption of the scenario
    considered in this document?

    2.2- How does this one-to-one relationship apply when LAG is used? Could a
    single IP link be supported by multiple Ethernet member links, with the
    members potentially using different optical tunnels?

3- Section 5.2.3 states "Implementation-specific mechanisms can be implemented
...to summarize the SRLGs of an optical tunnel... cares have to be taken to
avoid missing information."

What does “avoid missing information” specifically mean for SRLG-disjoint path
computation?

4- Section 7 states that NETCONF supports NACM, while RESTCONF supports RBAC.

Could you please clarify this distinction? RFC 8341 defines NACM access control
for both NETCONF and RESTCONF.

5- Section 6 states: "Section 3.2 provide useful support for ...( ... network
inventory discovery)", but network inventory is identified as a gap. Is
"network inventory discovery" referring to the proposed
[I-D.ietf-ivy-network-inventory-yang] solution?

Nits:

6- Section 2.1.1 states: "...dedicated TE tunnels, which neither share
resources with other services, nor compete for bandwidth with other tunnels,
ensuring deterministic latency performance...."

My understanding is that avoiding resource sharing and bandwidth competition
can reduce contention and provide more predictable latency, but it is not clear
to me that these conditions alone ensure deterministic end-to-end latency.
Would “predictable latency performance” be more accurate here?.

7-Section 5 refers to "the PE SID assigned by P-PNC1 to the inter-domain link
between BR11 and BR21." Does "PE SID" stand for "Provider Edge SID" or "Peer
SID"?

Thanks for this document,

Ines.