Dear Italo, Thank you for addressing my comments. I am OK with your suggestions.
Best regards, Ines On Wed, 7 Oct 2026, 21.18 Italo Busi, <[email protected]> wrote: > 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 <[email protected]> > > Sent: lunedì 21 settembre 2026 14:30 > > To: [email protected] > > Cc: [email protected]; > [email protected]; > > [email protected] > > 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. > > > >
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
