Based on the IESG expert’s review, some unsolved issues are emerging again.
Top post two points of Eric’s review and Peter’s response, and I would like to hear the IESG expert’s opinions(also the author’s explanations): 1) ### Section 2 There are two "SHOULD" in this section but nothing is written the cases when these "SHOULD" can be bypassed and/or what are the consequences. ##PP I added: "Not withdrawing the UPA would result in stale information being kept in the link state database of all routers in the area." [WAJ] How to “withdrawing the UPA” ? There is no EXPLICIT UPA withdraw message. Does “Stop advertising the UPA” equal to “withdrawing the UPA”? 2) ### Section 3.1 `Those ABRs or ASBRs, which are responsible for propagating UPA advertisements into other areas or domains MUST also recognize UPA advertisements.` what are the consequences if this is not the case (e.g., not all ABR/ASBR have been upgraded). Should this be mentioned in an operational considerations section ? ##PP added: "Failure to do so would prevent UPA to reach the routers in the remote areas or domains." [WAJ] I think Eric raised one interesting question. Such question actually relate to the network partition scenario, which this draft try to avoid. The added sentence can’t be implemented-----Image there are two ABRs, and one ABR(ABR A) can recognize the UPA advertisements, another ABR(ABR B) can’t. How can ABR B(which is not upgraded) “prevent UPA to reach the routers in the remote areas or domains” (ABR A has already send out the UPA advertisements) 3) There are also other unsolved issues in this document, which I have responses to the IETF chair at https://mailarchive.ietf.org/arch/msg/lsr/drZyz2YIucydqXImG05C75APDZU/ (especially item 1) I wonder that are there any expert can response/consider carefully the existing issues, which will stop the mechanism work in the network. Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Peter Psenak Sent: Thursday, September 18, 2025 5:57 PM To: Éric Vyncke <[email protected]>; The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [Lsr] Re: Éric Vyncke's No Objection on draft-ietf-lsr-igp-ureach-prefix-announce-09: (with COMMENT) Hi Eric, thanks for your comments, please see my responses inline (##PP): On 17/09/2025 17:35, Éric Vyncke via Datatracker wrote: Éric Vyncke has entered the following ballot position for draft-ietf-lsr-igp-ureach-prefix-announce-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-igp-ureach-prefix-announce-09 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Yingzhen Qu for the shepherd's detailed write-up including the WG consensus (important to note for this I-D) _but it lacks_ the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Title s/IGP Unreachable Prefix Announcement/Unreachable Prefix *IGP* Announcement/ sounds clearer to me but English is not my primary language. ##PP I let the RFC Editors to decide, I feel what we have is better. ### Abstract s/This document describes/This document *specifies*/ as this is proposed standard. ##PP done ### Section 1 Who is the "we" in `we want to signal unreachability` ? The authors ? The LSR WG ? The IETF ? Please avoid using ambiguous "we" by rephrasing the sentence. ##PP done s/ISIS/IS-IS/ ? and in other places. ##PP done ### Section 2 s/for a prefix that is summarized by the summary *address*/for a prefix that is summarized by the summary *prefix*/ ? ##PP done There are two "SHOULD" in this section but nothing is written the cases when these "SHOULD" can be bypassed and/or what are the consequences. ##PP I added: "Not withdrawing the UPA would result in stale information being kept in the link state database of all routers in the area." Add "and OSPFv3" at the end of `so the above optimisation does not apply to OSPF` ? It seems that the I-D sometimes uses OSPF for OSPFv2 alone and sometimes for OSPFv2 and OSPFv3. ##PP I added and OSPFv3 at the end of the sentence, ### Section 3.1 Add "to support this specification" after `without the need to upgrade all nodes in a network.` ? ##PP done `Those ABRs or ASBRs, which are responsible for propagating UPA advertisements into other areas or domains MUST also recognize UPA advertisements.` what are the consequences if this is not the case (e.g., not all ABR/ASBR have been upgraded). Should this be mentioned in an operational considerations section ? ##PP added: "Failure to do so would prevent UPA to reach the routers in the remote areas or domains." ### Section 5.1 Was the use of a 2-bit field considered rather than using 2 flags ? It would have allowed 4 values as opposed as the current 3 values. Out of curiosity because it is probably too late to change it... ##PP RFC7444 defines the "IPv4/IPv6 Extended Reachability Attribute Flags" TLV, which is a variable length bitfield. We are simply adding two new bits in that bitfield. ### Section 8 It is often preferable to add an informational reference to the URI of the registries. #PP never done it, can you please provide an example RFC/draft, I'll follow that. thanks, Peter
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
