"Les Ginsberg (ginsberg)" <[email protected]> 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 <[email protected]> On Behalf Of Greg Mirsky Sent: Tuesday, January 25, 2022 7:06 PM To: Aijun Wang <[email protected]> Cc: lsr <[email protected]> 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 <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
