Hi, Ketan:
I think you should notice, what I emphasized is the difference between UPA and “the normal LSA with LSinfinity Metric”, not “normal LSA”. Please do not change the concept. I think you should read carefully RFC 2328, to find the guideline within the base OSPF specification, for the procedure to “normal LSA with LSInfinity Metric“, also the UPA. This document is obviously contradictory to the guideline in RFC 2328, whether it will update RFC 2328, or not update, it will fall into the dilemma. I have given the reasoning analysis before, any expert doesn’t agree or find the hole in my logic, can point me out. I am still wondering why such document can be passed the view of LSR WG, IESG Review. Can Med, Gunter, Jim, or other experts find some wrong in my analysis at https://mailarchive.ietf.org/arch/msg/lsr/ALytEQpW-K8JYn2YyJMjSqXxVgk/? For your convenience, I copy and paste here: ======================================================================================================== 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. ======================================================================================================== Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Ketan Talaulikar Sent: Saturday, September 27, 2025 3:05 PM To: Aijun Wang <[email protected]> Cc: Paul Wouters <[email protected]>; [email protected]; James Guichard <[email protected]>; Gunter van de Velde <[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) Hi Aijun, I think we are going in circles (yet again), and I will stop now. To understand the difference between UPA and normal prefix reachability, please read the document. Thanks, Ketan On Fri, Sep 26, 2025 at 8:08 PM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Ketan: What’s the difference between UPA and normal LSA with LSinfinity Metric? If there is no difference, then should UPA obey the RFC2328? If UPA obey the RFC 2328, then according to the description I quoted before, the advertisement of UPA can only to the neighbor area, and can’t be advertised further to the remote area that is not directly connected to the UPA original area. Aijun Wang China Telecom On Sep 26, 2025, at 20:47, Ketan Talaulikar <[email protected] <mailto:[email protected]> > wrote: Hi Aijun, Here is yet another (of several) attempts to explain this - if only in the hope of saving time of people in the appeals chain. Please check inline below. On Fri, Sep 26, 2025 at 3:32 PM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: 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 KT> This document, along with introducing the UPA, opens up an exception to that handling of LSInfinity during propagation in RFC238 for UPAs alone (i.e., not for regular LSAs) (I hope by now you know which section of the document I am referring to!). This is why the document is not an update to RFC2328 since that base protocol behavior remains unchanged and unaffected. 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. KT> Please see the previous comment to explain why there is no contradiction. There is no need to remove the restriction in RFC2328. This document does not do that. Thanks, Ketan ======================================================================================================== 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] <mailto:[email protected]> ] Sent: Thursday, September 25, 2025 10:14 PM To: Aijun Wang <[email protected] <mailto:[email protected]> > Cc: Ketan Talaulikar <[email protected] <mailto:[email protected]> >; The IESG <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[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] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
