Hi, Robert: The ABR can detect the prefix unreachable via the SPF calculation once it receives the LSA for link or node failure. What’s the necessary to run multi-hop BFD among ABR and other PEs?
Aijun Wang China Telecom > On Jul 7, 2022, at 20:03, Peter Psenak <[email protected]> > wrote: > > On 07/07/2022 12:26, Robert Raszuk wrote: >> That's true. >> I am pointing out that this in some networks may be much slower then >> invalidating the next hops from BGP route reflectors by running *local* >> multihop BFD sessions to subject PEs (all within an area). >> So I have a question ... Let's forget about BGP and RRs and just stay >> focused on IGP: >> Would it be feasible to trigger UPA on ABRs by running multihop BFD sessions >> between ABRs and local area PEs and not wait for PE-P detection of link down >> as well as flooding to carry the information to ABRs ? > > I would think running BFD on each individual link in the local area would be > a much better solution. And people already often do that. > > thanks, > Peter > >> Thx, >> R. >> On Thu, Jul 7, 2022 at 12:18 PM Peter Psenak <[email protected] >> <mailto:[email protected]>> wrote: >> Robert, >> BGP PIC depends on the IGP convergence. We are not changing any of that >> by UPA. >> thanks, >> Peter >> On 07/07/2022 12:02, Robert Raszuk wrote: >> > Peter, >> > >> > All I am saying is that this may be pretty slow if even directly >> > attached P routers must way say 6 seconds (3 x 2 sec BFD) to declare >> > peer down. >> > >> > And that is in contrast to running BFD from say BGP RR to all PEs >> in an >> > area. >> > >> > The fundamental point is that in the case of PUA you MUST wait >> for all P >> > routers to tell you that PE in fact went down. While in case of >> > invalidating service routes the first trigger is good enough. >> > >> > To me this is significant architectural difference. >> > >> > Many thx, >> > R. >> > >> > >> > On Thu, Jul 7, 2022 at 11:54 AM Peter Psenak <[email protected] >> <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>> wrote: >> > >> > On 07/07/2022 11:38, Robert Raszuk wrote: >> > > >> > > > there is no such thing. >> > > >> > > By far away ABR I mean ABR far away from failing PE >> connecting local >> > > are to the area 0. There can be number of P routers in >> between. >> > >> > ABR has the full visibility of the local area and knows when any >> > node or >> > prefix becomes unreachable. It is determined by the SPF >> computation and >> > prefix processing that is triggered as a result of the change >> in the >> > local area. >> > >> > thanks, >> > Peter >> > >> > > >> > > Let me provide you with an illustration: >> > > >> > > PE can be in Honolulu. ABR in Huston. All in one area. For me >> > this ABR >> > > is far away from PE. >> > > >> > > On Thu, Jul 7, 2022 at 11:35 AM Peter Psenak >> <[email protected] <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>> >> > > <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> wrote: >> > > >> > > Robert, >> > > >> > > On 07/07/2022 11:25, Robert Raszuk wrote: >> > > > Hi Peter, >> > > > >> > > > > Section 4: >> > > > > >> > > > > "The intent of UPA is to provide an event driven >> signal >> > of the >> > > > > transition of a destination from reachable to >> > unreachable." >> > > > >> > > > That is too vague. >> > > >> > > it's all that is needed. >> > > >> > > > >> > > > I am asking how you detect that transition on a >> far away ABR. >> > > >> > > there is no such thing. The detection is done based on >> the prefix >> > > transition from reachable to unreachabile in a local >> area by >> > local >> > > ABRs. >> > > Remote ABRs just propagate the UPA. >> > > >> > > thanks, >> > > Peter >> > > >> > > > >> > > > For example, are you tracking flooding on all links to >> > subject PE >> > > from >> > > > all its neighbours and only when all of them remove >> that >> > link from >> > > > topology you signal PUA ? >> > > > >> > > > If so practically such trigger may be pretty slow and >> > > inconsistent as in >> > > > real networks as links over which PEs are connected are >> > often of a >> > > > very different quality, coming from different >> carriers and may >> > > have for >> > > > stability varying BFD timers. So here you would have to >> > wait for the >> > > > slowest link to be detected on the neighbouring P >> router >> > as down. >> > > > >> > > > Thx, >> > > > R. >> > > > >> > > > On Thu, Jul 7, 2022 at 10:16 AM Peter Psenak >> > <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> > > <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >> > > > <mailto:[email protected] >> <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> > <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>>> wrote: >> > > > >> > > > Robert, >> > > > >> > > > On 06/07/2022 15:07, Robert Raszuk wrote: >> > > > > Hi Peter, >> > > > > >> > > > > Can you please point me in the draft >> > > > > >> > > > >> > > >> > >> >> https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> >> > >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> >> > > >> > >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> >> > > > >> > > >> > >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>> >> > > > >> > > > > >> > > > >> > > >> > >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>> >> > > > >> > > >> > >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt> >> >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt >> <https://www.ietf.org/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt>>>>> >> > > > >> > > > > to some section which specifies based on exactly >> > what network >> > > > flooding >> > > > > changes UPA will be generated by ABRs ? >> > > > >> > > > Section 4: >> > > > >> > > > "The intent of UPA is to provide an event driven >> > signal of the >> > > > transition of a destination from reachable to >> > unreachable." >> > > > > >> > > > > I think such text is not an implementation >> detail, >> > but it is >> > > > critical >> > > > > for mix vendor interoperability. >> > > > > >> > > > > Can UPA also be generated by P node(s) ? >> > > > >> > > > only if they are ABRs or ASBRs. >> > > > >> > > > >> > > > > >> > > > > Specifically I was looking to find some >> information on >> > > how do you >> > > > > achieve assurance that UPA really needs to >> be generated >> > > when using >> > > > > various vendor's nodes with very different >> flooding >> > behaviours >> > > > and when >> > > > > subjects PEs may have a number of different >> links >> > each with >> > > > different >> > > > > node/link down detection timer ? >> > > > >> > > > sorry, I don't understand the above. >> > > > >> > > > thanks, >> > > > Peter >> > > > >> > > > > >> > > > > Many 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
