"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
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,
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
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:
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
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
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
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
"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
"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
Les,
if we assume that this is a real case, it appears to me that it is a rear
one. Thus, I don't see a good enough reason standardizing something that
solves a rear case when there's already a standard-based solution that
addresses 80%, if not 90% of cases. Yes, it is interesting problem but, in
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.
However, If you still want to continue to advocate for BFD, I will say no
Hi all,
I suggest that we all agree to disagree.
Since we cannot make progress, we simply drop all proposals, adopt none of
them, and give up.
Tony
> On Jan 25, 2022, at 6:16 PM, Aijun Wang wrote:
>
> Hi, All:
>
> As Peter’s example and Acee’s suggestions, let’s focus on the following
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 configuration/operational
Hi Aijun,
I believe that under Option D you can add multihop BFD per RFC 5883. No new
protols needed.
Regards,
Greg
On Tue, Jan 25, 2022, 18:17 Aijun Wang wrote:
> Hi, All:
>
>
>
> As Peter’s example and Acee’s suggestions, let’s focus on the following
> problem to think how to solve it
Hi, All:
As Peter's example and Acee's suggestions, let's focus on the following
problem to think how to solve it efficiently and reasonably:
Scenario: 100 areas each with 1000 PEs (100K total PEs) with 2 ABRs per area
Problem: Overlay services(BGP or Tunnel) that rely on the IGP needs to be
16 matches
Mail list logo
