Hi Gyan, > 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.
“Out-of-band” implies that the signaling is being done using a separate communications channel, such as a different physical link. That would be inaccurate. It would be more accurate to say that it’s carrying information derived from the IGP in another protocol. > 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. More accurately, there will be multiple registrations for a prefix. In a sane implementation, the prefixes are stored in something like a radix trie, with a structure below the prefix to hold the registrations. That could itself be a tree or hash table. But these are implementation nits... > Do you have a sequence # to keep track as well as age of prefixes. No, this is not necessary. You’ll note that BGP’s BRIB has no sequence numbering nor is age necessary for the protocol (tho it’s sometimes included for management purposes). > This is almost like building another LSDB like DB on the ABRs. It’s certainly another data store. It is likely to be far smaller than an LSDB as entries are far smaller. Each entry can be a pointer back to its connection, plus the overhead for data structures. I would suggest a singly-linked thread for the connection (for registration removal) and pointers for the prefix tree. That’s about 5 pointers. On a 64-bit architecture, that’s 40 bytes per registration. In relative terms, that’s tiny. A memory conservative implementation could do far better, possibly at the cost of some time-expensive operations. > 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. There is no need to refresh the database. There is no need for sequence numbering. > Maybe also prefix pacing similar to LSA group pacing to keep the prefixes > refreshed so you don’t have stale entires. There are no stale entries. > Also maybe a method to MAXAGE the prefix similar to LSA MAXAGE to flush the > DB when prefixes go down. There is no need. There are only two cases to remove a registration from the RDB: when the connection closes or when the client chooses to unregister. > 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. This is an important point: This is NOT a distributed database. This is a per-ABR database. Yes, the content of the RDB should be similar between two ABRs that serve the same area(s), that is not necessarily true all the time. > Also possible race conditions based on network triggers and timers. There are no timers. There are no race conditions (that I can see — if I missed something, please call it out). > It does seem as though we are building and IGP layer onto of the existing > IGP. We are building a service adjunct to the IGP. Yes, it has some additional state. > I think the maintenance of the RDB seems it would be quite complex. It is intentionally trivial. > 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. Acee has already given us a provisional node to continue. Given the dependency on the IGP, plus the fact that the problem is being debated here in LSR, this only seems sane. > I wonder about the scalability for larger domains as there is a lot of > control plane overhead that is added with this service. This is not a ‘lot’ of overhead. This is basically BGP-lite and has about the same pain as another 100k prefixes in BGP. In other words, it’s almost free. > 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. I’m not following your math here. If you have 1000 routers in an area, then your ABRs would have 1000 client connections. If you have 1000 other areas and two ABRs from each area, then you would have 2000 connections to other ABRs. In the steady state, these are idle, so this is just a matter of TCB overhead. By contrast, the industry has BGP implementations that are working towards 10,000 fully active connections. Again, this is noise. > That is a lot of overhead in addition to the IGP! This is not a lot of overhead in a modern Tier 1 ABR. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
