Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

"Les Ginsberg (ginsberg)" writes: Chris - The scale request comes from real customers. So, it is understandable for you to be "aghast" - but it is a real request. I'm not aghast. The exclamation point was just a period scaled to the 100K PE level. :) BTW, earlier in the thread I asked

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Not each information carried within the LSP will be consumed by every Node within the IGP, and the PUA/PULSE message doesn’t trigger the SPF calculation. What are the melt down effect that you are worrying then? PUB/SUB model introduces again the connection states to the network devices,

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Right, I also saw req' up to 0.5M nodes in flat IGP core by some customers thinking they'll have the money & need for such things (though I know only one company in the world right now that runs anything deployed of this scale give it 2-3 multiplier of total networking devices including switches

Re: [Lsr] BGP vs PUA/PULSE

Maybe even use SDN / PCE centralized controller , stateful PCE which has peer to each node to instantiate the LSP as well as now manage the component prefixes state. So we can drift completely out of the IGP realm but we are choosing to stay in IGP realm with PUB/SUB. The PUB/SUB model has been

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Hi, Greg: I think PUA/PULSE solution can eliminate all of the your mentioned concerns for BFD based solution. And it is reasonable to find the more optimal solution. Best Regards Aijun Wang China Telecom From: gregimir...@gmail.com Sent: Thursday, January 27, 2022 9:10 AM To:

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Les, it appears that you bear some misconceptions about multihop BFD that make you believe that by its nature it cannot scale to the level your customers need. I'd point out that all objections to using BFD, as I see them can be grouped as follows: - operational cost - configuration and

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Hi, Chris: Keeping asking whether the peer is healthy or not is obviously not efficient let the proxy(ABR) to notify others when the peer is unhealthy. Imaging that there may be thousands of such nodes are keeping to ask each other node, and almost all of nodes are healthy in almost all of the

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Hi Les, Yes you are correct. It is a classic pull vs push model. Push gives you notification about state. That's it. Pull gives you much more as it includes e2e elements of the data plane - of course for a bit higher cost. I would not disregard any of the above. We have been having similar

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

Chris - The scale request comes from real customers. So, it is understandable for you to be "aghast" - but it is a real request. As far as BFD goes, my opinion is this won’t scale. There is a significant difference between operating sessions which continuously monitor liveness in a full mesh

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

"Aijun Wang" writes: Hi, Greg: Yes. I think so. If we select the “OOB solution“ category, RFC 5883 is one existing option,  and has no new connection states introduced within the network devices. The reason that we prefer to the IGP solution is that we want just to relieve from the

Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem

"Les Ginsberg (ginsberg)" writes: Greg – With 100K PE scale, we are talking about 100K BFD sessions/PE and close to 5 million BFD sessions network-wide. Eliminating one of the options we are discussing is admittedly a small step, but still worthwhile. Hang on a sec. :) We are starting

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

Tony, On 26/01/2022 16:46, Tony Li wrote: Peter, The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs. yes, but how much data? Minimal.

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

Peter, >> > The pulse solution does not suffer from the scale issues. >> It shifts that "suffering" to flood the entire domain with information which >> is not needed on P routers and selectively useful on the remote PEs. > > yes, but how much data? Minimal. It's not an issue, no matter how

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

On 26/01/2022 10:40, Robert Raszuk wrote: > The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs. yes, but how much data? Minimal. It's not

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

> The pulse solution does not suffer from the scale issues. It shifts that "suffering" to flood the entire domain with information which is not needed on P routers and selectively useful on the remote PEs. Also fast signaling the fact that PE may have been disconnected from the network for a few

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

Tony, On 25/01/2022 17:11, Tony Li wrote: Peter, we just moved the problem from IGPs to some "other" application. That was the entire point. Hopefully, you see that as a good thing. actually I don't. I want to solve the problem, not to move it to other app running on the same nodes.

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