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
