Hi Greg, > as that node will catch up with "luckier" neighbors eventually.
The crux of the matter is that there is no "luckier" neighbors. There is no database synchronization. Sure service will eventually converge, but what is being tried here is to trigger data plane switchover a bit faster. > I think that a discussion of adding the UDP transport QUIC already runs over UDP. And it offers hassle free assurance that what you send got to the other end. Thx, R. PS. > for notifications. Well today what is proposed is notifications. But real edge to edge pub-sub model can be used to offer targetted distribution of much more then notifications freeing up flooding from carrying bunch of opaque stuff and focusing on doing what it is really for ie. build underlay topology. On Mon, Jan 24, 2022 at 2:08 AM Greg Mirsky <[email protected]> wrote: > Hi Robert, Gyan, et al, > I got to think about the benefits of using reliable transport for > notifications. If I understand the use case correctly, the proposed > mechanism allows for a faster convergence but is supplemental to slower BGP > convergence. If that is the case, it seems that if a subscriber to the > service missed a notification, the situation would not be worse than it is > today as that node will catch up with "luckier" neighbors eventually. I > think that a discussion of adding the UDP transport to the list of > transport options is a reasonable proposition and might add a useful model > to the proposed mechanism. > > Regards, > Greg > > On Sun, Jan 23, 2022 at 2:09 PM Robert Raszuk <[email protected]> wrote: > >> Gyan, >> >> By design of the proposal there is no synchronization of "state" between >> ABRs needed. In fact the main benefit is that ABRs will be receiving and >> storing a completely different set of registrations and notifications for >> scalability of the overall system. >> >> What you wrote in the second paragraph is FUD. Think about the >> benefits of using reliable transport (as opposed to flooding) and draw >> conclusions. >> >> > That is a lot of overhead in addition to the IGP! >> >> If "that" would be true maybe such a conclusion would be ok ... but it is >> not. >> >> Thx, >> R. >> >> >> >> >> On Sun, Jan 23, 2022 at 10:18 PM Gyan Mishra <[email protected]> >> wrote: >> >>> Hi Tony >>> >>> Thank you for sharing the IGP Based Pub / Sub Proposal. >>> >>> So basically the event notification process done in PUAM / Pulse inband, >>> here we are using an out-of-band transport protocol QUIC / TCP for the >>> Publisher RDB registration DB service on the ABRs which advertises the node >>> liveliness service into the L1 and L2 areas for subscriber client internal >>> routers within the area to use the service. Each subscriber internal >>> router creates a active/active QUIC/TCP session to two ABRs minimum for >>> redundancy for the liveliness service. Since the clients have two Active / >>> Active sessions and so there would be duplicate copies of each prefix. Do >>> you have a sequence # to keep track as well as age of prefixes. This is >>> almost like building another LSDB like DB on the ABRs. >>> >>> For the service all the ABRs providing the PUB service need to be meshed >>> with QUIC/TCP session so they all stay synchronized as well have some type >>> of sequence number and age and maybe a max age value to refresh the >>> database. Maybe also prefix pacing similar to LSA group pacing to keep the >>> prefixes refreshed so you don’t have stale entires. Also maybe a method to >>> MAXAGE the prefix similar to LSA MAXAGE to flush the DB when prefixes go >>> down. As this is a distributed database that has to be synchronized >>> between all the ABRs similar to IGP synchronized database all the similar >>> mechanisms I would think need to be employed here as well to ensure the >>> prefixes in the database are “valid” prefixes so you don’t have a false >>> positive or negative notification. Also possible race conditions based on >>> network triggers and timers. It does seem as though we are building and >>> IGP layer onto of the existing IGP. I think the maintenance of the RDB >>> seems it would be quite complex. >>> >>> I do wonder as this has a tremendous out-of-band framework maybe this is >>> out of scope of LSR and maybe belongs in the transport area with regards to >>> the PUB / SUB framework. >>> >>> I wonder about the scalability for larger domains as there is a lot of >>> control plane overhead that is added with this service. >>> >>> It you can imagine you have 1000+ routers in an area which is typical >>> for core, aggregation layers in a transport domain. Just to show here how >>> the scale factor maybe a significant issue. To keep the math simple you >>> have 2 ABR publishers and 1000 internal router subscribers. So the ABRs >>> would have a singe session between them. However now each ABR would >>> maintain 1000 QUIC/TCP sessions with each ABR. >>> >>> That is a lot of overhead in addition to the IGP! >>> >>> >>> >>> Kind Regards >>> >>> Gyan >>> >>> On Sun, Jan 23, 2022 at 12:19 PM Greg Mirsky <[email protected]> >>> wrote: >>> >>>> Hi Tony, >>>> thank you for sharing this very interesting proposal. I've read the >>>> latest version (-01) and have two comments: >>>> >>>> - It seems that referencing the multi-hop BFD [RFC5883] in the >>>> Introduction section as the existing mechanism detecting the node >>>> liveness can make the document more thorough. >>>> - along with the term "node liveness," the document mentions >>>> "node's reachability". Do you think that the latter might be further >>>> clarified by pointing out that that is reachability from an IGP >>>> perspective? Or, perhaps use only the "node liveness" in the document. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, Jan 18, 2022 at 5:05 PM 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 >>>> >>> -- >>> >>> <http://www.verizon.com/> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions A**rchitect * >>> >>> *Email [email protected] <[email protected]>* >>> >>> >>> >>> *M 301 502-1347* >>> >>> _______________________________________________ >>> 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
