Robert,
On 04/01/2022 20:05, Robert Raszuk wrote:
no. It's a limit not a delay.
That is directly contradicting the message from Les stating that this is
going to be a rate limit not cut out.
*/"[LES2:] It is reasonable to limit the rate of pulses sent. "/*
If too many edge nodes loose connectivity
to the ABR in its area, it's a result of the severe event like area
partition or loss of area connectivity from ABR. These are not types of
events that we are trying to address with pulses.
Is the proposed solution really sound ?
- It *may* signal PE loopback going down only in subset of deployments,
- It *may* signal PE loopback going down only in some types of failure
scenarios,
- It *may* signal PE loopback going down only if the PE going down is
lucky enough among the list of first N to be processed by the ABR
etc ...
Now what about cases where PEs have 10 IPv4 and 20 IPv6 loopbacks - are
we going to trigger pulses containing all of those 30 addresses ?
How about folks not doing next hop self and using peer's IP address for
some SAFIs ? Are we going to also pulse all connected leaves if they are
part of some summary ?
one can pick which ones to pulse - e.g. tag them at the source and pulse
based on ABR based on the tag value.
So can one set the limit of pulses on ABR if the default value is not
good enough.
So pulse is a hint ... if the blind blast succeeds remote PEs *may*
trigger switchover to a backup path (if available).
Don't we have too much uncertainty in this proposal ?
the proposal addresses 99% of realistic PE down scenarios in network
where summarization is used. That's what we are trying to improve.
For the remaining 1%, things will work as of today, I'm not worried.
thanks,
Peter
Thx,
R.
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
