Tony,
On 18/11/2021 17:38, Tony Li wrote:
Les,
You are not retaining scalability. You are damaging it. You are
proposing flooding a prefix per router that fails. If there is a mass
failure, that would result in flooding a large number of prefixes. The
last thing you want when there is a mass failure is additional load,
exacerbating the situation.
*/[LES2:] It is reasonable to limit the rate of pulses sent. Peter has
already indicated in an earlier reply that we will address that in a
future version of the event-notification draft. So, good point – and
we are in agreement regarding mass failure./*
The fact that you have to limit the result is a pretty clear indication
that this is not architecturally appropriate.
using that logic, IGPs would not be suitable for half of the things they
are used for. We have areas to limit the flood radius, we have
summarization to limit the prefix scope, we have SPF backoff to limit
the SPFs, etc. The presence of these does not indicate that we use IGPs
inappropriately.
You are signaling the (lack of) liveness of a remote node. I propose
that we instead use existing signaling mechanisms to do this.
Multi-hop BFD seems like an obvious choice.
*/[LES2:] Conceptually this works. But I don’t think it scales./*
How so? Doesn’t this correspond 1:1 with overlay BGP sessions?
PEs typically only peer with RRs, not between themselves.
If you greatly dislike that for some reason, I would suggest that we
create a proxy liveness service, advertised by the ABR. This would
allow correspondents to register for notifications. The ABR could
signal these unicast when it determines that the specific targets are
unreachable.
*/[LES:] This would be a significant effort to provide such a service./*
*/Granted, implementation of “pulse” is also a significant effort – so
I am not objecting to your idea simply based on that. I am just
pointing out that what you propose does not currently exist – so if
you are serious about this alternative you need to provide the details./*
Fear of hard work does not make it the IGP’s problem.
nor should it prevent us to consider IGPs, especially when the
alternative would likely lead to the definition of the new protocol
(e.g. liveness service, advertised by the ABR).
thanks,
Peter
I am not the one with the issue. Those with the issue should propose the
details. At most, the IGP should carry a capability for this service.
Tony
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
