Hi Greg Very good point made and I agree that UDP would be good to add as available transports.
Kind Regards Gyan On Sun, Jan 23, 2022 at 8:08 PM 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 >> > -- <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
