HI, Paul：
“I will leave this to the routing experts, as it is somewhat outside the area of my expertise. But I do note you seem to be the only person seeing this as a problem.“ This is also my expectation-----for the routing experts to answer the core question. As I said before, until now(even some persons say that I raised it again and again), only Ketan as the routing AD, has tried to face the question. Here I just summary it again the FLAW of this protocol when it is in deployment, I would like to Med, Ketan, Jim or Gunter can response my following reasoning: ======================================================================================================== 1) UPA depends on LSA with LSInfinity metric. 2) LSA with LSInfinity metric can’t pass the ABR(which is stated clearly in RFC 2328--(“Else, if the routing table cost equals or exceeds the value LSInfinity, a summary-LSA cannot be generated for this route.”)) 3) UPA, which is no different from the normal LSA with LSInfinity metric, can’t pass to the remote area if this document doesn’t’ update RFC 2328 If this document wants to update RFC 2328, it will fall into another contradictory: 1) Remove the restriction in RFC 2328, that is, the sentence (“Else, if the routing table cost equals or exceeds the value LSInfinity, a summary-LSA cannot be generated for this route.”) 2) The network will be filled with various false UPA trigger accidents-----that is to say, introduce the “disaster” into the network------because any reachable prefix with the metric lower than the LSInifinity value MAY become unreachable after several hops, advertised by the ABR as UPA, and trigger the FALSE action. ======================================================================================================== I know IESG has passed this document based on the consensus ballot. But, if no routing ADs or experts can respond the above reasoning(if some persons feel the above reasoning has been answered, please give me the link directly), I will try to appeal to IAB, to let some experts solve the above puzzle. The authors of this draft can also respond. And one reminder of the overlong process-----I have raised the useless of “UP” flag from the beginning of its proposal, and until now, although other AD has raised the concerns, the author refuses to make any change.-----this is just another example, to show how it is difficult to convince the author. Best Regards Aijun Wang China Telecom From: Paul Wouters [mailto:[email protected]] Sent: Thursday, September 25, 2025 10:14 PM To: Aijun Wang <[email protected]> Cc: Ketan Talaulikar <[email protected]>; The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Lsr] Re: [Remind to the operators]Re: Ketan Talaulikar's No Objection on draft-ietf-lsr-igp-ureach-prefix-announce-10: (with COMMENT) On Thu, Sep 25, 2025 at 5:43 AM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: 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/> 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. Unfortunately the Updates: header is interpreted differently by different people/areas. If extensions can be implemented without requiring modification of the existing protocol, then usually the Updates: clause is not used. Only if an extension would require core protocol modifications would an Update: clause be added. 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. I will leave this to the routing experts, as it is somewhat outside the area of my expertise. But I do note you seem to be the only person seeing this as a problem. Paul Best Regards Aijun Wang China Telecom From: <mailto:[email protected]> [email protected] [mailto: <mailto:[email protected]> [email protected]] On Behalf Of Paul Wouters Sent: Thursday, September 25, 2025 12:31 AM To: Aijun Wang < <mailto:[email protected]> [email protected]> Cc: Ketan Talaulikar < <mailto:[email protected]> [email protected]>; The IESG < <mailto:[email protected]> [email protected]>; <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected]; <mailto:[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]
