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
