> On Nov 21, 2021, at 3:09 AM, Aijun Wang <[email protected]> wrote:
> 
> Hi, Tony:
> 
> Aijun Wang
> China Telecom
> 
>> On Nov 21, 2021, at 15:17, Tony Li <[email protected]> wrote:
>> 
>> 
>> Hi Aijun,
>> 
>>> The ABR should do the summary work based on the liveness, right?
>> 
>> 
>> No. ABRs advertised statically configured prefixes for the area. Anything 
>> else would cause flap. And it’s purely reachability, not liveness. There can 
>> be zero live nodes within an area and the ABR should still advertise its 
>> summary.
> 
> [WAJ] What the usage of the summary advertisement in such conditions excepts 
> it misleads the nodes within the area it attached?

Perhaps it would help to consider another example of reachability vs liveness. 
Summaries are just one form of the more general concept of aggregation. 
Consider the Internet and aggregation done at the AS level. Would you have BGP 
flapping routes in the entire Internet based on hosts going up and down at the 
originating AS? No, we do not expect it. When you try to connect to a server in 
azure or aws etc you don’t expect routing to let you know that a server is down 
through an unreachable routing message, you expect TCP to tell you it can’t 
connect to it.

Thanks,
Chris.


>> 
>> 
>>> Pub/Sub style notification seems promising, but it will require the ABR 
>>> store the subscription state which will certainly degrade its performance. 
>> 
>> 
>> Baloney. A notification list address post-SPF is wholly outside of the 
>> performance path.
> 
> [WAJ] Is there any existing mechanism to accomplish your proposal among the 
> PEs?
> 
>> 
>> 
>>> On the other hand, let the receiver decides whether to utilize such 
>>> information is distributed design and more robust? There is no much work to 
>>> be done when they receive the PUAM message. Just to judge the originator of 
>>> the prefix is valid or not.
>> 
>> 
>> Correct, you just flood information throughout the network that most of the 
>> nodes don’t care about, burdening others with additional flooding and 
>> database scale issues, just when there are failures.
> 
> [WAJ] Within the network, the number of PEs often surpasses the number of P 
> nodes. Even with P nodes, such information can also help them reroute/switch 
> to other endpoints along the SRv6 tunnel backup path.
> I think you could imagine the signal just as the alert information that often 
> seen on the highway. It can certainly save the driver’s time. Wouldn’t you 
> like to know such information immediately? Or you just drive as planned until 
> near the target to know the road is broken?
> 
>> 
>> Tony

_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to