Thank you Peter for addressing my comments! Regards, Giuseppe
From: Peter Psenak <[email protected]> Sent: Friday, May 30, 2025 11:44 AM To: Giuseppe Fioccola <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: draft-ietf-lsr-igp-ureach-prefix-announce-06 ietf last call Opsdir review Hi Giuseppe, I have uploaded a new version that addressed your comments. thanks, Peter On 30/05/2025 10:35, Giuseppe Fioccola wrote: Hi Peter, Thank you for considering my comments. Please see inline [GF]. Regards, Giuseppe -----Original Message----- From: Peter Psenak <[email protected]><mailto:[email protected]> Sent: Thursday, May 29, 2025 5:29 PM To: Giuseppe Fioccola <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: draft-ietf-lsr-igp-ureach-prefix-announce-06 ietf last call Opsdir review Hi Giuseppe, thanks for your comments, please see inline: On 29/05/2025 12:14, Giuseppe Fioccola via Datatracker wrote: Document: draft-ietf-lsr-igp-ureach-prefix-announce Title: IGP Unreachable Prefix Announcement Reviewer: Giuseppe Fioccola Review result: Has Nits This document defines two new flags in IS-IS and OSPF to signal loss of reachability to an individual prefix in case of summarization. I think that it has a well defined scope and is almost ready for publication. In this regard, I noticed the normative reference to draft-ietf-lsr-ospf-prefix-extended-flags, which, I guess, will be published before this document. yes, I will update the reference when that draft changes to RFC. [GF]: Yes I have only few minor comments for your consideration: - In the Abstract, I suggest to replace 'In the presence of summarization,' with 'Summarization is often used in IGP to improve network efficiency, but'. will do. [GF]: Ok - In the Introduction, I suggest to swap the last two paragraphs, otherwise it is not clear how they are sequential. will do [GF]: Ok - Section 4 on "Generation of the UPA" could be moved before section 2 on "Supporting UPA in IS-IS" and section 3 on "Supporting UPA in OSPF". I think it would be more logical. will do [GF]: Ok - Section 6 on "Deployment Considerations for UPA" seems to discuss only the case of area/domain partition. I would also highlight what are the operational benefits of UPA, as briefly mentioned in the Introduction. Maybe we can rename the section 6 to "Area Partition". [GF]: If the goal is to discuss only Area Partition, I agree to rename the title of the section. - In section 9 on "Security Considerations", you can also add the reference to RFC7794 and draft-ietf-lsr-ospf-prefix-extended-flags. will do. [GF]: Ok thanks, Peter
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
