[Gen-art] Re: draft-ietf-teas-actn-poi-applicability-20 ietf last call Genart review

[Italo Busi <[e-mail]>]

Hi Ines,

Thanks a lot for your review and comments

Please find some initial feedbacks in line below

We are tracking in github the authors' discussion and proposed text changes, addressing yours and Rtgdir review comments:

https://github.com/IETF-TEAS-WG/actn-poi/issues/143

https://github.com/IETF-TEAS-WG/actn-poi/pull/144

We are planning to upload an updated version of the I-D as soon as the text updates are finalized

Thanks, Italo

> -----Original Message-----
> From: Ines Robles via Datatracker <[e-mail]>
> Sent: lunedì 21 settembre 2026 14:30
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: draft-ietf-teas-actn-poi-applicability-20 ietf last call Genart review
> 
> Document: draft-ietf-teas-actn-poi-applicability
> Title: Applicability of Abstraction and Control of Traffic Engineered Networks
> (ACTN) to Packet Optical Integration (POI) Reviewer: Ines Robles Review result:
> Almost Ready
> 
> 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?
> 

In general, no mechanism can guarantee a mathematically optimal path. In this case, by querying individual PNCs for paths across multiple ingress/egress combinations, the MDSC achieves the highest practical level of optimization for multi-domain/multi-layer path computation. Therefore, we prefer to keep the text as is, aligning directly with the established use of 'optimal path' in RFC 8453.

> 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?
> 

The text was written assuming no LAG and before adding the description of LAG.

Proposed update to section 5.1:

OLD

As described in Section 4.1, Section 4.5, and Section 4.6, there is a
one-to-one relationship between a multi-layer intra-domain IP link

NEW

As described in Section 4.1, Section 4.5, and Section 4.6, without LAG, there is a
one-to-one relationship between a multi-layer intra-domain IP link

Proposed update to section 5.2:

OLD

As described in Section 5.1, there is a one-to-one relationship
between a multi-technology intra-domain IP link and its underlay
optical tunnel.

NEW

As described in Section 5.1, there is a one-to-one relationship
between a multi-technology intra-domain Ethernet link and its underlay
optical tunnel.

> 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?
> 

We would add some text to clarify that "failure to do so could result in miscalculating two path candidates as being fully SRLG-disjoint when they actually share a hidden failure point"

> 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.
> 

We would propose to rephrase as:

"Furthermore, access control techniques can also provide additional security features. Both NETCONF and RESTCONF support the Network Configuration Access Control Model (NACM) [RFC8341], which provides group-based (role-based) access control, ensuring that MDSC to PNC communication is based on authorised use and granular control of connectivity and resource requests."

> 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?
> 

We would remove ", and network inventory discovery" and add an "e.g.," at the beginning. The rationale is that network inventory discovery is part of resource discovery but not yet supported by the YANG models analyzed in this document ([I-D.ietf-ivy-network-inventory-yang] is out of scope of this document) and the provided support is claimed as "useful" (I would change to "good") but not "full" or "complete", since gaps have been identified.

> 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?.
> 

My understanding of the difference between predictable versus deterministic is that this might depend on the TE technology being used. What about saying "ensuring deterministic or predictable latency performance"?

> 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"?
> 

I think it is a "Peer SID": still checking with the main author of this section for confirmation

> Thanks for this document,
> 
> Ines.
>