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 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 <[email protected]> > Sent: Wednesday, January 26, 2022 2:15 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Greg Mirsky <[email protected]>; Aijun Wang > <[email protected]>; [email protected] > Subject: Re: [Lsr] How to forward the solutions for "Prefixes Unreachable > Notification" problem > > > "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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
