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 management; - extra state information on PEs; - extra traffic load. If my summary is accurate, none of these concerns are related to the BFD protocol itself. Can we agree? Furthermore, as Chris has noted, configuration and management of network functions are automatable. In RFC 9127 anyone can find the BFD YANG data model (RFC 9127bis would not change it beyond recognition) As far as extra traffic is concerned, a single BFD session that would *guarantee* the detection of the network failure between two PEs in 3 sec (one BFD Control message per second from each PE) adds mere 250 bytes (or so) in IPv6 and even less in IPv4 network. As for the amount of BFD state information and ability of an implementation to handle it, I call it the Art of Implementation. I hope I clarified some of the questions you might have regarding the use of BFD in the scenario we're discussing. Regards, Greg On Wed, Jan 26, 2022 at 4:49 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > 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 <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
