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]
