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]
