> > 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 ? 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 ? Thx, R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
