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

Reply via email to