[Last-Call] Re: draft-ietf-lsr-igp-ureach-prefix-announce-06 ietf last call Opsdir review

[Peter Psenak <ppsenak=40cisco.com@xxxxxxxxxxxxxx>]

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 <ppsenak@xxxxxxxxx> 
> Sent: Thursday, May 29, 2025 5:29 PM
> To: Giuseppe Fioccola <giuseppe.fioccola@xxxxxxxxxx>; ops-dir@xxxxxxxx
> Cc: draft-ietf-lsr-igp-ureach-prefix-announce.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
> 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
>
>
>
> >       
>
>
>

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx