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]
