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]> 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]> 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]> > 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]] >> *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]> >> 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/, >> 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:* [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]> >> 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 >> - 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] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
