we rely on the service to indicate failures while kafka relies on routing to be able to come up and get the cluster together (unless we talk a single server). So routing has to be up for kafka to come up and in case of failure this may affect kafka as well so there is no signalling. not that important, was just free-associating ...
-- tony On Wed, Jan 19, 2022 at 9:04 PM Robert Raszuk <[email protected]> wrote: > 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
