Tony,

Why would we need to deploy a full mesh of BFD or introduce a new proxy
liveness service if BGP can do all what is needed here with just a few
lines of additional cfg on existing and deployed operating systems ?

In respect to using BFD here - let's start with basic question - who would
be the producer to install those host routes into RIB ? Note in the
discussed scenario there are not there today - only summary is there.

Thx,
R.

On Thu, Nov 18, 2021 at 5:06 PM Tony Li <tony...@tony.li> wrote:

>
> Les,
>
> Why would we then punch holes in the summary for member routers?  Just
> because we can?
> *[LES:] No. We are doing it to improve convergence AND retain scalability.*
>
>
>
> You are not improving convergence. You are propagating liveness.  The fact
> that this relates to convergence in the overlay is irrelevant to the IGP.
>
> 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.
>
>
>  Should we corrupt the architecture just because we can?  There are other,
> architecturally appropriate solutions available.  How about we just use
> them?
>
> *[LES:] What are you proposing?*
>
>
>
> 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.
>
> 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.
>
> Tony
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to