> You think Kafka here? Nope ... I meant ZeroMQ message bus as underlaying pub-sub transport for service related info.
Thx, R., On Wed, Mar 10, 2021 at 11:41 AM Tony Przygienda <tonysi...@gmail.com> wrote: > ? Last time I looked @ it (and it's been a while) Open-R had nothing of > that sort, it was basically KV playing LSDB (innovative and clever in > itself). You think Kafka here? Which in turn needs underlying IGP however > and is nothing but BGP problems in new clothes having looked @ their > internal architecture and where it's goiing a while ago. > > -- tony > > On Wed, Mar 10, 2021 at 11:29 AM Robert Raszuk <rob...@raszuk.net> wrote: > >> Peter, >> >> > But suddenly the DOWN event distribution is considered >> > problematic. Not sure I follow. >> >> In routing and IP reachability we use p2mp distribution and flooding as >> it is required to provide any to any connectivity. >> >> Such spray model no longer fits services where not every endpoint >> participates in all services. >> >> So my point is that just because you have transport ready we should not >> continue to announce neither good nor bad news in spray fashion for >> services. >> >> Sure it works, but it is hardly a good design and sound architecture. >> >> It happened to BGP as the convenience of already having TCP sessions >> between nodes was so great that we loaded loads of stuff to go along basic >> routing reachability. >> >> And now it seems time came to do the same with IGPs :). >> >> I think unless we stop and define a real pub-sub messaging protocol (like >> FB does with open-R) we will continue this. >> >> And to me it is like building a tower from the cards ... the higher you >> go the more likely your entire tower is to collapse. >> >> Cheers, >> R. >> >> PS. >> >> > with MPLS loopback address of all PEs is advertised everywhere. >> >> Is this a feature or a day one design bug later fixed by RFC5283 ? >> >> >> >> >> On Wed, Mar 10, 2021 at 9:10 AM Peter Psenak <ppse...@cisco.com> wrote: >> >>> Robert, >>> >>> >>> On 09/03/2021 19:30, Robert Raszuk wrote: >>> > Hi Peter, >>> > >>> > > Example 1: >>> > > >>> > > If session to PE1 goes down, withdraw all RDs received from >>> such PE. >>> > >>> > still dependent on RDs and BGP specific. >>> > >>> > >>> > To me this does sound like a feature ... to you I think it was rather >>> > pejorative. >>> >>> not sure I understand your point with "pejorative"... >>> >>> There are other ways to provide services outside of BGP - think GRE, >>> IPsec, etc. The solution should cover them all. >>> >>> > >>> > We want app independent way of >>> > signaling the reachability loss. At the end that's what IGPs do >>> without >>> > a presence of summarization. >>> > >>> > >>> > Here you go. I suppose you just drafted the first use case for OSPF >>> > Transport Instance. >>> >>> you said it, not me. >>> >>> >>> > >>> > I suppose you just run new ISIS or OSPF Instance and flood info about >>> PE >>> > down events to all other instance nodes (hopefully just PEs and no Ps >>> as >>> > such plane would be OTT one). Still you will be flooding this to 100s >>> > of PEs which may never need this information at all which I think is >>> the >>> > main issue here. Such bad news IMHO should be distributed on a pub/sub >>> > basis only. First you subscribe then you get updates ... not get >>> > everything then keep junk till it get's removed or expires. >>> >>> with MPLS loopback address of all PEs is advertised everywhere. So you >>> keep the state when the remote PE loopback is up and you get a state >>> withdrawal when the remote PE loopback goes down. >>> >>> In Srv6, with summarization we can reduced the amount of UP state to >>> minimum. But suddenly the DOWN event distribution is considered >>> problematic. Not sure I follow. >>> >>> thanks, >>> Peter >>> >>> > >>> > Many thx, >>> > Robert >>> > >>> >>> _______________________________________________ >> 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
