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
