Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

On 25/01/2022 17:07, Robert Raszuk wrote: Peter, If a given PE needs to get all notifications from all other PEs it is sufficient that it sends to local ABRs a single registration in a form of 0.0.0.0/0 and be done. my calculation was done for case where each PE needs to r

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

Robert Raszuk writes: Peter, If a given PE needs to get all notifications from all other PEs it is sufficient that it sends to local ABRs a single registration in a form of 0.0.0.0/0 and be done.  But realistically speaking the case where services offered by a PE also exist on all 100K other

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

Peter, If a given PE needs to get all notifications from all other PEs it is sufficient that it sends to local ABRs a single registration in a form of 0.0.0.0/0 and be done. But realistically speaking the case where services offered by a PE also exist on all 100K other PEs would be pretty rare.

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

On 25/01/2022 15:18, Robert Raszuk wrote: Peter, You clearly missed the added new sentence to section 4.3 in version -01 It is RECOMMENDED that the ABR register for the most specific prefix that is less specific than the original prefix. I don't think so. I'm talking about PE to ABR registrat

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

Peter, You clearly missed the added new sentence to section 4.3 in version -01 It is RECOMMENDED that the ABR register for the most specific prefix that is less specific than the original prefix. Thx, R On Tue, Jan 25, 2022 at 2:57 PM Peter Psenak wrote: > On 25/01/2022 14:07, Robert Raszuk

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

On 25/01/2022 14:07, Robert Raszuk wrote: Peter, Your math is off. no, it's right. Every local PE in an area registers to different 100 remote addresses to local ABRs. 1k PEs in area * 100 destinations equals to 100k registrations. Peter > 1. 100k registrations in each ABR, 10 millio

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

Peter, Your math is off. > 1. 100k registrations in each ABR, 10 million network wide ABRs will "aggregate" atomic registrations to summaries when passing them to other ABRs. Please recalculate, Thx, R. On Tue, Jan 25, 2022 at 12:25 PM Peter Psenak wrote: > Tony, > > I'm going to use my tar

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

Tony, I'm going to use my target scale of 100k PEs, split in 100 areas, 2 ABRs per area, with the average VPN size of 100. What you propose would result in: 1. 100k registrations in each ABR, 10 million network wide 2. 1200 TCP sessions in each ABR, 220k TCP sessions network wide Above is pr

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

tions. Please find another means to advertise the availability of the service. Les From: Lsr On Behalf Of Tony Li Sent: Tuesday, January 18, 2022 5:05 PM To: lsr Subject: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt FYI. This is a better alternative that PUA/Pulse.

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

Hi Greg, > as that node will catch up with "luckier" neighbors eventually. The crux of the matter is that there is no "luckier" neighbors. There is no database synchronization. Sure service will eventually converge, but what is being tried here is to trigger data plane switchover a bit faster. >

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

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 wrote: > Hi Robert, Gyan, et al, > I got to think about the benefits of using reliable transport for > notifications. If I understand t

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

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 t

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

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 paragra

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

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 se

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

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 tho

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

we rely on the service to indicate failures while kafka relies on routing to be able to come up and get the cluster together (unless we talk a single server). So routing has to be up for kafka to come up and in case of failure this may affect kafka as well so there is no signalling. not that import

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

Tony P, > though this leads to chicken-egg since kafka needs routing to strip e'thing together I am not sure I follow the above parenthesis ... Routing will be there already as we are not talking about any reachability distribution hence I am not sure where is the chicken-egg dilemma ? Would you

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

yupp, if we want IGP involved this is definitely a much more sane alternative than the ones proposed. Use IGP only to advertise the SSAP of such "notification service" rather than abuse it as a broadcast mechanism. And for all practical purposes we can simply advertise something like kafka channels

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

Hi Tony, *Question: * Do you envision any form of aggregation to happen in the messaging between ABRs (for both registrations and notifications) ? *Comment: * I think the pub-sub model is really cool, but I am not clear what are the advantages to do it in the IGP from ABRs vs BGP from area RRs

Re: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

lecom From: lsr-boun...@ietf.org On Behalf Of Tony Li Sent: Wednesday, January 19, 2022 9:05 AM To: lsr Subject: [Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt FYI. This is a better alternative that PUA/Pulse. Tony Begin forwarded message:

[Lsr] Fwd: New Version Notification for draft-li-lsr-liveness-00.txt

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: , "Tony Li" > > > A new version of I-D, draft-li-lsr-li