Hi Tony,

*Question: *

Do you envision any form of aggregation to happen in the messaging between
ABRs (for both registrations and notifications) ?

*Comment: *

I think the pub-sub model is really cool, but I am not clear what are the
advantages to do it in the IGP from ABRs vs BGP from area RRs (note that in
the latter case no new protocol is required).

Also if we do it from local area RRs we do not need registrations - local
RRs know which next hops are attached to local service routes. And it would
go only where the service route goes.

*Concern: *

Last I am a bit concerned with the scale here. If we keep registrations and
notifications at the atomic level the ABRs may need to keep pretty large
RDB and efficiently generate *targetted* notifications upon each local area
node transition or reception of notification from other ABR(s).

Last what protection would be in place to suppress the network wide
meltdown when client would (say by mistake or a bug) inject 1 million of
registrations ? Would that not result in a bit of load to all ABRs ?

Kind regards,
Robert


On Wed, Jan 19, 2022 at 2:05 AM Tony Li <[email protected]> wrote:

>
> FYI.  This is a better alternative that PUA/Pulse.
>
> Tony
>
>
> Begin forwarded message:
>
> *From: *[email protected]
> *Subject: **New Version Notification for draft-li-lsr-liveness-00.txt*
> *Date: *January 18, 2022 at 5:04:22 PM PST
> *To: *<[email protected]>, "Tony Li" <[email protected]>
>
>
> A new version of I-D, draft-li-lsr-liveness-00.txt
> has been successfully submitted by Tony Li, and posted to the
> IETF repository.
>
> Name: draft-li-lsr-liveness
> Revision: 00
> Title: Node Liveness Protocol
> Document date: 2022-01-18
> Group: Individual Submission
> Pages: 9
> URL:
> https://www.ietf.org/archive/id/draft-li-lsr-liveness-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-li-lsr-liveness/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-li-lsr-liveness
>
>
> Abstract:
>   Prompt notification of the loss of node liveness or reachability is
>   useful for restoring services in tunneled topologies.  IGP
>   summarization precludes remote nodes from directly observing the
>   status of remote nodes.  This document proposes a service that, in
>   conjunction with the IGP, provides prompt notifications without
>   impacting IGP summarization.
>
>
>
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> Lsr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lsr
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to