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 my opinion, not for an SDO.
Regards, Greg On Tue, Jan 25, 2022, 21:11 Les Ginsberg (ginsberg) <[email protected]> wrote: > 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 > 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
