Hi, Chris: Keeping asking whether the peer is healthy or not is obviously not efficient let the proxy(ABR) to notify others when the peer is unhealthy. Imaging that there may be thousands of such nodes are keeping to ask each other node, and almost all of nodes are healthy in almost all of the time.
Don't you think such approach is so noisy and inefficient? Best Regards Aijun Wang China Telecom -----Original Message----- From: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Christian Hopps Sent: Thursday, January 27, 2022 6:23 AM To: Aijun Wang <wang...@chinatelecom.cn> Cc: gregimir...@gmail.com; lsr@ietf.org Subject: Re: [Lsr] How to forward the solutions for "Prefixes Unreachable Notification" problem "Aijun Wang" <wang...@chinatelecom.cn> writes: > Hi, Greg: > > > > Yes. I think so. If we select the “OOB solution“ category, RFC 5883 is > one existing option, and has no new connection states introduced > within the network devices. > > The reason that we prefer to the IGP solution is that we want just to > relieve from the configuration/operational overhead for these “OOB > solution” in the mentioned scenarios. And here it is again, the "configuration is too hard" reasoning ... is not valid. Configurations are built algorithmically and deployed automatically more recently from service models using databases etc. It's not a good justification for not using something. Thanks, Chris. > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > From: gregimir...@gmail.com <gregimir...@gmail.com> > Sent: Wednesday, January 26, 2022 11:06 AM > 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
