Hi, Robert: Aijun Wang China Telecom
> On Nov 23, 2021, at 19:42, Robert Raszuk <[email protected]> wrote: > > > > > For IGP solution, the BFD is not required. > > Excuse me ? > > BFD is used on vast majority of the WAN links today as those links are not > always dark fiber such that you can detect LOS. Those WAN links are > (unfortunately) emulated circuits which require BFD to detect failure in a > reasonable time. > > I hope you are not talking about IGP hellos or BGP keepalives here. > > We are talking PE-P or PE-RR. [WAJ] Once there is a link/node failure, upon receiving the updated LSA, the ABR can calculate the missed prefixes within its attached area, as described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-4 > > Thx, > R. > > > >> On Tue, Nov 23, 2021 at 12:38 PM Aijun Wang <[email protected]> >> wrote: >> Hi, Robert: >> >> Aijun Wang >> China Telecom >> >>>> On Nov 23, 2021, at 18:04, Robert Raszuk <[email protected]> wrote: >>>> >>> >>> >>> > When the node is failed, or is detached from the network, it can’t send >>> > the BGP update to other peers already. >>> >>> LOL ... that's given. Same for IGP too. >>> >>> The UPDATE will be generated by the BGP peer of such node - typically RR. >>> And if you run BFD on that session it can be as fast as loosing IGP adj to >>> an IGP neighbour of the failing node. >> [WAJ] Then you depend again the BFD session which there is configuration >> overhead. For IGP solution, the BFD is not required. >> And, for tunnels situations, where you configure the monitor peer? >> >> Aijun Wang >> China Telecom >> >>> >>> Cheers, >>> R. >>> >>> >>> >>> >>>> On Tue, Nov 23, 2021 at 10:03 AM Aijun Wang <[email protected]> >>>> wrote: >>>> Hi, Robert: >>>> >>>> >>>> >>>> When the node is failed, or is detached from the network, it can’t send >>>> the BGP update to other peers already. >>>> >>>> And, as we have discussed, the potential usage of such information is not >>>> only BGP, but may be tunnel endpoints. >>>> >>>> Yes, I agree, the light speed is the same. >>>> >>>> >>>> >>>> >>>> >>>> Best Regards >>>> >>>> >>>> >>>> Aijun Wang >>>> >>>> China Telecom >>>> >>>> >>>> >>>> From: [email protected] <[email protected]> On Behalf Of Robert >>>> Raszuk >>>> Sent: Tuesday, November 23, 2021 4:40 PM >>>> To: Aijun Wang <[email protected]> >>>> Cc: Les Ginsberg (ginsberg) <[email protected]>; Gyan Mishra >>>> <[email protected]>; Christian Hopps <[email protected]>; Tony Li >>>> <[email protected]>; lsr <[email protected]>; Acee Lindem (acee) >>>> <[email protected]>; Tony Przygienda <[email protected]> >>>> Subject: Re: [Lsr] 【Responses for Comments on PUAM Draft】RE: IETF 112 LSR >>>> Meeting Minutes >>>> >>>> >>>> >>>> Aijun, >>>> >>>> >>>> >>>> > or lose the fast convergences >>>> >>>> >>>> >>>> Putting aside all the drawbacks already discussed, what makes you think >>>> that flooding LSPs or LSAs across tens of hops over 2 or maybe soon 8 >>>> areas would be any faster then sending BGP UPDATE message(s) across 2-3 >>>> RRs ? >>>> >>>> >>>> >>>> Assume you need to detect the failure and react to it in your RP/RE >>>> regardless how it is signalled. If triggered by ABRs you not only need to >>>> detect the failure of a node, but also flood it locally within the local >>>> area. >>>> >>>> >>>> >>>> Light propagation speed last time I checked does not seems to be different >>>> for BGP vs OSPF/ISIS packets. >>>> >>>> >>>> >>>> Thx, >>>> >>>> R. >>>> >>>> >>>> >>> _______________________________________________ >>> 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
