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
<[email protected]> 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 WangChina Telecom
On Nov 6, 2023, at 14:53, Peter Psenak <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
