[Teas] Re: Routing Directorate Early Review of "Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration (POI)" - draft-ietf-teas-actn-poi-applicability-18

[Italo Busi <[e-mail]>]

Hi Acee,

Thanks for your review and comments

We have discussed them during our bi-weekly call this Tuesday: see our feedbacks in line marked as [Authors]

We may need some time to develop some text to address some of your comments

If you wish you can track the progress in github:

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

Anyhow, we will notify you and the TEAS WG mailing list as soon as we have submitted the updated I-D addressing your comments

Thanks, Italo (on behalf of co-authors/contributors)

> -----Original Message-----
> From: Acee Lindem <[e-mail]>
> Sent: giovedì 16 aprile 2026 17:31
> To: Routing ADs <[e-mail]>; draft-ietf-teas-actn-poi-
> [e-mail]
> Cc: TEAS WG <[e-mail]>; Routing Directorate <[e-mail]>
> Subject: Routing Directorate Early Review of "Applicability of Abstraction and
> Control of Traffic Engineered Networks (ACTN) to Packet Optical Integration
> (POI)" - draft-ietf-teas-actn-poi-applicability-18
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing ADs.
> For more information about the Routing Directorate, please see:
> 
>   http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Early
> Review/Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
> 
> Document: draft-ietf-teas-actn-poi-applicability-18.txt
> Reviewer: Acee Lindem
> Review Date: 04/15/2026
> IETF LC End Date: N/A
> Intended Status: Informational
> 
> Summary:
>   As indicated by the introduction, this document covers the
>   applicability of Abstraction and Control of TE Networks (ACTN)
>   to provide the full automation of management and control for
>   Service Providers' transport networks, spanning IP/MPLS,
>   optical, and microwave technologies, is crucial to addressing
>   customer demands for high-bandwidth applications, such as
>   ultra-fast mobile broadband for 5G and fiber connectivity services.
> 
>   This is an extremely broad topic and requires a lot of pre-knowledge.
>   While the document does a good job of providing references, I found
>   myself feeling like I'd walked into the middle of a movie and almost
>   wished I hadn't agreed to review it since my understanding of optical
>   networks is limited. I guess I should have known by the length of the
>   draft title.
> 
>   However, I think the document is very useful in that it provides
>   references to applicable protocols and YANG models for accomplishing
>   this multi-layer discovery and path automation. It also identifies
>   functional gaps required to accomplish ACTN POI.
> 
> 
> Major Issues: N/A
> 
> 
> Minor Issues:
> 
>  1. Perhaps, the introduction could include a list of prerequisite
>     understanding and a better preview of what follows than the
>     3 paragraphs on page 5.
> 

[Authors] We will add some text in the Introduction

>  2. The second sentence below is awkwardly phrased.
> 
>      PNC Domain:  Part of the network under the control of a single PNC
>       instance.  It is subject to the capabilities of the PNC which
>       technology is controlled.
> 

[Authors] We will rephrase as "PNC Domain: A portion of the network controlled by one PNC instance, where capabilities are defined by the technologies supported by both the PNC instance and its managed network elements."

>  3. Why not H-MDSC and L-MDSC rather than inverting the compound
> acronym?
> 

[Authors] The MDSC-H and MDSC-L acronyms are defined in RFC8453 and we prefer to keep alignment with that RFC

>  4. ROADM, CNC, WSON, OTN, OTS, OTSi, ILA, CBR, and WDM are used
>     without expansion of definition. Possibly other optical acronyms
>     are not expanded on first use .
> 

[Authors] We will expand the acronyms at first use

>  5. In section 4, what do you mean by "IETF notifications"?
> 

[Authors] We will rephrase as "through notifications over the MPIs, from the PNCs when any network inventory/topology/service change occurs"

>  6. Assuming the plug-id concept for LTPs is described in one of the
>     reference documents.
> 

[Authors] Yes, it is described in section 4.3 RFC8795, as mentioned in Section 4.5

>  7. Section 7.1, add that LLDP can be authenticated/encrypted using the
>     IEEE 802.1AE [MACsec] standard.
> 

[Authors] We will add some text as proposed

>  8. Add a reference or definition of "muxponder".
> 

[Authors] 

We will add the following definition for muxponder:

Muxponder: an optical device that aggregates multiple lower-rate client signals into a single higher-speed optical signal, combining multiplexing and transponder functionalities to maximize network efficiency.

[\Authors]

> 
> Nits: See attached RFC diff.
> 

[Authors] 

We will update as proposed, with few exceptions:
- we think that the text "Optical PNC (O-PNC): A PNC controlling an optical network domain." and "Packet PNC (P-PNC): A PNC controlling a packet network domain." in the current draft are correct
- we would change the title of section 6 to "Conclusions and Gaps" (we think there was a typo in the attached RFC diff)
- "makeLink" was a typo so we will replace it with just "Link"

[\Authors]

> Thanks,
> Acee