Tony P, > though this leads to chicken-egg since kafka needs routing to strip e'thing together
I am not sure I follow the above parenthesis ... Routing will be there already as we are not talking about any reachability distribution hence I am not sure where is the chicken-egg dilemma ? Would you mind clarifying ? Thx, R. On Wed, Jan 19, 2022 at 8:38 PM Tony Przygienda <[email protected]> wrote: > yupp, if we want IGP involved this is definitely a much more sane > alternative than the ones proposed. Use IGP only to advertise the SSAP of > such "notification service" rather than abuse it as a broadcast mechanism. > And for all practical purposes we can simply advertise something like kafka > channels ;-) and put it onto an overlay bus (though this leads to > chicken-egg since kafka needs routing to strip e'thing together). Or we > could use BIER for that as well where e'one sits on mp2mp thing (and > filtering translates into bitmask you multicast the notifications to). > > As only observation, if we do this service as suggested I would like to > see not only port & protocol but also the according address of the endpoint > (since it's really <address/protocol/port> that is the SSAP here. > Operationally it's very often desirable to know what address stuff shows up > to especially if there are filtering/reachability considerations ... > > -- tony > > 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 >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
