Hi. Paul:
Thanks for your constructive responses. For the issue 1), as I respond to Ketan at https://mailarchive.ietf.org/arch/msg/lsr/ev2A1DBxSl0DkbwSiAQ2UP1yf3Y/, it is impossible to “extends the base OSPF protocol behavior specifically for UPAs alone to allow their propagation.”----The UPA is no different from the “normal LSA with Infinity metric”. Extend RFC 2328 in such manner is equal to Update RFC 2328-----But currently, there is no content, or obvious label at the header of this document that indicates it will update RFC 2328. Even to update the RFC 2328, that is to say, erase or relax the description of “Else, if the routing table cost equals or exceeds the value LSInfinity, a summary-LSA cannot be generated for this route.“, will lead to issue 2), that a prefix is reachable in one area, will become unreachable in other area, and trigger the unexpected switchover, or, connect loss. This is what I call may be the “disaster”. Solution to above issue is not depend on the LSInfinity to indicate the “UPA”, just use the explicit “U” flag. Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Paul Wouters Sent: Thursday, September 25, 2025 12:31 AM To: Aijun Wang <[email protected]> Cc: Ketan Talaulikar <[email protected]>; The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: [Lsr] Re: [Remind to the operators]Re: Ketan Talaulikar's No Objection on draft-ietf-lsr-igp-ureach-prefix-announce-10: (with COMMENT) Aijuan, On Wed, Sep 24, 2025 at 12:08 PM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: 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) The quotes link gives an answer Ketan has given many times: www.ietf.org/archive/id/draft-ietf-lsr-igp-ureach-prefix-announce-09.html#section-4.2 <https://www.ietf.org/archive/id/draft-ietf-lsr-igp-ureach-prefix-announce-09.html#section-4.2> - this document extends the base OSPF protocol behavior specifically for UPAs alone to allow their propagation. Therefore, this is not in conflict with RFC2328. The link states: 4.2. <https://www.ietf.org/archive/id/draft-ietf-lsr-igp-ureach-prefix-announce-09.html#section-4.2> Propagation of UPA in OSPF <https://www.ietf.org/archive/id/draft-ietf-lsr-igp-ureach-prefix-announce-09.html#name-propagation-of-upa-in-ospf> OSPF ABRs or ASBRs, which would be responsible for propagating UPA advertisements into other areas MUST recognize such advertisements. Advertising prefix reachability between OSPF areas assumes prefix reachability in a source area. Such requirement of reachability MUST NOT be applied for UPAs, as they are propagating unreachability. At best I could see giving Operational Considerations guidance of deploying this in a mixed environment where some, but not all devices suport this feature. If you really believe that is a concern, please write a sentence of two on how operators should handle this. This could be as simple as "dont enable this feature until all your devices support it". If you cannot give such a short operational advise sentence for consideration, I will assume the issue need no further addressing. 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. Same as above - instead of simply saying "disaster", try to give constructive operational consideration sentences. 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. It can pass review because you have not convinced anyone beyond yourself that there is a problem. 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? The consensus being questioned by a single individual is hardly convincing. Where are the other operators? Until now, we have never seen a single individual predicting the demise of the internet, and being correct. I am wondering. Can anyone give some suggestions, or explain the solutions to above issues? See above. Write constructive text that you think would give proper warning on how/when to use these features or not. Paul
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
