[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

[Acee Lindem <[e-mail]>]

Hi Italo, 

This looks good. I see that RFC 8453 had already defined MDSC-L and MSDC-H. 

Thanks,
Acee

> On Jun 11, 2026, at 11:56 AM, Italo Busi <[e-mail]> wrote:
> 
> Hi Acee,
> 
> Thanks again for your review and comments
> 
> We have just uploaded the -19 revision of the document addressing your comments as discussed below
> 
> Thanks, Italo (on behalf of co-authors/contributors)
> 
> PS: I have just realized that we forgot to add you to the Acknowledgements section: I have just done in github so that will appear in the next I-D update
> 
>> -----Original Message-----
>> From: Italo Busi <[e-mail]>
>> Sent: giovedì 14 maggio 2026 10:24
>> To: Acee Lindem <[e-mail]>; Routing ADs <[e-mail]>;
>> [e-mail]
>> Cc: TEAS WG <[e-mail]>; Routing Directorate <[e-mail]>
>> Subject: 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
>> 
>> 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