"Les Ginsberg (ginsberg)" <ginsb...@cisco.com> 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 if every PE actually would need the liveness
detection for every other PE (full-mesh) and Peter indicated that this was not
the case. So 5M, while not unreasonable for a network of this size, is
additionally a pathological case. I think it's important to consider this
less-than-full-mesh attribute when talking about this deployment.
Finally, for this model deployment I'll ask again, how many *total* routers are
there in this network?
Thanks,
Chris.
[as wg member]
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 versus using some approach which only triggers network-wide traffic
when some topology change is locally detected. There are multiple approaches
being discussed which do the latter - but BFD is not one of them.
You can disagree - or - as Greg has done - say we don’t really have to consider
this scale. I am not going to try to convince you otherwise.
But if so you aren’t solving the problem we have been asked to solve.
Les
-----Original Message-----
From: Christian Hopps <cho...@chopps.org>
Sent: Wednesday, January 26, 2022 2:15 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: Greg Mirsky <gregimir...@gmail.com>; Aijun Wang
<wang...@chinatelecom.cn>; lsr@ietf.org
Subject: Re: [Lsr] How to forward the solutions for "Prefixes Unreachable
Notification" problem
"Les Ginsberg (ginsberg)" <ginsberg=40cisco....@dmarc.ietf.org> 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 off with this GINORMOUS network with 100,000 PE routers!
Why would 5 million sessions of anything over this gigantic network of
routers be a reason to disregard it as a solution? (How many total routers are
there BTW?)
If you build something gignatic *everything* is going to scale way up. To use
an oldie but a goodie: TANSTAAFL.
Thanks,
Chris.
>
>
> However, If you still want to continue to advocate for BFD, I will
> say no more.
>
>
>
> Les
>
>
>
> From: Lsr <lsr-boun...@ietf.org> On Behalf Of Greg Mirsky
> Sent: Tuesday, January 25, 2022 7:06 PM
> To: Aijun Wang <wang...@chinatelecom.cn>
> Cc: lsr <lsr@ietf.org>
> Subject: Re: [Lsr] How to forward the solutions for "Prefixes
> Unreachable Notification" problem
>
>
>
> 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 <wang...@chinatelecom.cn>
> wrote:
>
> 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 notified immediately when the remote Peer failed, to
> assist such overlay service accomplish fast switchover(how to
> switchover is out of the discussion)
>
> Potential Solutions:
>
> There are now mainly four categories of the solutions, as
> described below and their brief analysis:
>
> Category A: PUA/PULSE. Utilizes the existing IGP mechanism to
> transport/flooding the notification message.
>
> Category B: Detail/Important Prefixes Leaks. Bypass the
> summary side-effect for some detailed/important prefixes by
> leaking/not summarize them into each area.
>
> Category C: BGP based solution: Utilize the existing BGP
> infrastructure to transport the notification message
>
> Category D: OOB Solution. Design some new OOB protocol to
> transport the notification message.
>
>
>
> Because we are in LSR WG, and people are all IGP experts. After
> the intense discussion, can we now focus on the Category A/B?
>
> It is very curious that LSR WG will and should produce some BGP
> or OOB based solution. I think they may be feasible, but should
> be evaluated/discussed by other WGs.
>
> Or else, I think we can’t converge to one standard solution.
>
>
>
> >From the POV of the operator, we prefer to the IGP based
> solution. If there is no unsolvable concerns, let’s accept it. I
> think there is enough interests and experts to accomplish this
> task.
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
