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 <hayabusa...@gmail.com> 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 <gregimir...@gmail.com> > 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 <tony...@tony.li> wrote: >> >>> >>> FYI. This is a better alternative that PUA/Pulse. >>> >>> Tony >>> >>> >>> Begin forwarded message: >>> >>> *From: *internet-dra...@ietf.org >>> *Subject: **New Version Notification for draft-li-lsr-liveness-00.txt* >>> *Date: *January 18, 2022 at 5:04:22 PM PST >>> *To: *<t...@ietfa.amsl.com>, "Tony Li" <tony...@tony.li> >>> >>> >>> 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 >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr >>> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > _______________________________________________ > 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
