Hi, all experts: I noticed that during the Ketan and Med’s review of this document, they all recommended that the “operation consideration” part should be added but the authors refused.
Here I want to remind the operators that focus on the UPA feature, that the protocol extension defined in this document is implementable, but NOT practical to be deployed in the network. Any operator try to adopt this feature in their network should be aware that the following issues: 1) The UPA propagation between the areas is conflict with the base OSPF standard(RFC 2328). That is to say, according to the description in RFC 2328, UPA can’t be propagated further to the remote area(only to the neighbor area). For details explanation, please review the discussions at https://mailarchive.ietf.org/arch/msg/lsr/ev2A1DBxSl0DkbwSiAQ2UP1yf3Y/ (Until now, only Ketan faces the question directly, but failed to give the reasonable explanation) 2) The exploitation of LSInfinity feature is one disaster to the operator’s network. One can easily imagine the confusion scenario: One prefix with metric set to slightly lower than LSInfinity will become “unreachable” after several hops because the accumulated cost will exceed the LSInfinity. I noticed until now, among the IESG reviewers, only Med is from the operator, but ignored also the above issues( I appreciate that Med insisted that UP flag was unnecessary, despite of the authors’ unsound resistance to change——Until now, there is no vendor implement the U flag, not to mention UP flag). The above issues are so obvious, I am wondering why it can pass the final IESG review. Is it necessary to appeal to the IAB after the IESG’s review to pass this document? Can IAB amend the so called consensus procedure to eliminate such standards that have flaws, or challenging to be deployed in the operator’s network? I am wondering. Can anyone give some suggestions, or explain the solutions to above issues? Aijun Wang China Telecom > On Sep 24, 2025, at 20:13, Ketan Talaulikar via Datatracker > <[email protected]> wrote: > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-lsr-igp-ureach-prefix-announce-10: 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: > ---------------------------------------------------------------------- > > Thanks to the authors and the WG for their work on this document. > > I believe this is a useful feature in specific deployment use cases where > summarization is used for scaling purposes. > > Thanks to Peter for addressing my comments in the DISCUSS and COMMENTS > sections > as the editor of the document. > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
