Hi Aijun, As your co-author on the OSPF Prefix Originator RFC, I have stated many times (e.g. [1]) that overloading semantics of Prefix Originator is not a good or clean protocol encoding. Semantically, it is wrong and a very bad protocol design in my opinion. Going by this logic, tomorrow, someone would want to encode some different meaning for all 1's value in the originator address. We cannot be doing such (IMHO) HACKS in the protocol encodings.
It is better to signal the semantics/meaning explicitly using specific flags that are meaningful. The authors of draft-ppsenak (now a WG document) agreed to this feedback from WG members and incorporated the U/UP flags in their draft. However, the authors of draft-wang seem to continue to refuse to accept feedback. It is perhaps one of the reasons why the WG adopted the draft-ppsenak and not draft-wang. WG chairs, is there a way to put an end to this debate such that it does not continue endlessly? Thanks, Ketan [1] thread https://mailarchive.ietf.org/arch/msg/lsr/FNbqHPhphY3GOfw-NWkLjmoRDVs/ On Mon, Nov 6, 2023 at 7:31 PM John Drake <je_drake= 40yahoo....@dmarc.ietf.org> wrote: > Aijun, > > You castigated Peter for his lack of rigor in his reply to your email, > however, I think that was completely unfounded. Further, your reply to > Peter seems to be argument by emphatic assertion, rather than "technical > analysis/comparison". > > Thanks, > > John > > On Monday, November 6, 2023 at 08:41:38 AM PST, Aijun Wang < > wangai...@tsinghua.org.cn> wrote: > > > Hi, Peter: > > Let’s focus on the technical analysis/comparison for the mentioned issues, > and don’t repeat the subjective comments that without any solid analysis. > > Detail replies inline below. > > Aijun Wang > China Telecom > > On Nov 6, 2023, at 14:53, Peter Psenak <ppse...@cisco.com> wrote: > > Aijun, > > please see inline: > > On 06/11/2023 13:23, Aijun Wang wrote: > > Hi, all: > > > Here are some technical questions for the hurry adopted draft about > unreachable prefixes announcement: > > > 1) There exists already “prefix originator” sub-TLV to indicate the > associated prefix is unreachable, what’s the advantage of using other > undefined, to-be-standardized, to-be-implemented sub-TLV? > > > many people have already commented on why overloading the “prefix > originator” sub-TLV to signal unreachability is a bad idea. Please accept > that feedback. > > > [WAJ] No one gives the technical analysis. Can you explain technically in > detail? > > You can set the prefix metric to LS-infinity to indicate the > unreachability, why can’t we the prefix originator to NULL to indicate the > unreachability?———The key idea for using “prefix originator” is here: if > there is no router originate the associated prefix, then it is certainly > unreachable. It is more straightforward than the LS_Infinity, and is also > more easily implemented, deployed than the to-be-defined, > to-be-standardized sub-TLV. > > > > 2) It is unnecessary to define the “UP” flag——if the operator know the > unreachable event in advance, they can also schedule the switchover of the > related services in advance. Why bother IGP to transfer such information? > > > looks like there are folks that see the value in it. I let them to comment > more, but I don't necessarily see a problem in an extra bit. If you don't > like it, don't use it. > > > > 3) There is very limited usage of LS_Infinity in current network. From the > operator’s viewpoint, we will decrease its usage also in future. Then the > solution should try their best to avoid their usages——Current solutions > instead enhance its usage——It is unacceptable. Let’s keep the network > simple. > > > the reasons for using the LSInfinity for unreachability has been discussed > at great length a;ready. It's the backward compatibility for routers not > supporting the new signalling - we need to avoid them interpreting the > unreachability as reachability. > > > [WAJ] My emphasis is that we shouldn’t enhance the usage of > LS-Infinity(you propose that the LS-Infinity metric must be carried) > Instead, we should try to fade them out: > 1) If all routers within one area/domain all support the new capabilities, > we need not require the summary LSA to carry LS-infinity metric. > > 2) The Maxage of LSA can also be used to achieve the similar effects of > legacy node bypassing. > > > > 4) We can’t ignore the partitions scenarios or let’s it go. > > > if you feel like the partition is the problem, you can write a separate > draft and address it there. We are NOT trying to solve it with UPA draft. > And for a reason. > > > [WAJ] They are coupled. If you don’t consider it now, you need to update > your proposal later. > > > > > 5) There should be some mechanisms to control the volume of advertised > unreachable information, when compared with reachable information, as done > in > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6 > . > > > > please look at the section 6 of the UPA draft. > > > [WAJ] I am referring to the balance advertisement of reachable > information, as did in the above link, not the simple statement as the > following: “It is also recommended that implementations limit the number > of UPA advertisements which can be originated at a given time. “ > > Actually, even for your above statement, > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#name-deployment-considerations-4 > gives > more guidelines, I think you can refer to it again. > > > thanks, > Peter > > > > Please consider the above technical issues carefully before evaluating and > adopted any proposal. > > > If the above issues can’t be solved, we request the WG to adopt also the > https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which > cover and solve all of the above issues. > > > Aijun Wang > > China Telecom > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
