Hmm I am not sure I follow what you just said.
1000s of PEs in an area ? Even if so you are worried about 1000s of multihop BFD sessions to be handled at ABRs ? But ABRs can be good vendor boxes and offload those 1000s of sessions to LCs. I was talking about PEs where they only do less then 10 multihop BFD sessions to local area ABRs. Please clarify. Thx, R. On Sun, Jul 17, 2022 at 10:57 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > Throughout the discussions of various alternatives to solving this problem > we have been consistently saying that the solution MUST work at scale – up > to thousands of PEs. > > That’s because there are customers asking for this. > > > > Les > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Sunday, July 17, 2022 1:12 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Christian Hopps <cho...@chopps.org>; Peter Psenak (ppsenak) < > ppse...@cisco.com>; lsr <lsr@ietf.org> > *Subject:* Re: [Lsr] UPA > > > > Hi Les, > > > > Your excerpted top posting may not have enough context for everyone to > easily follow the point being discussed – hopefully that is not the case. > > > > Well just trying to respond to the points raised. > > > > *[LES:] Sooo, you apparently think it is OK to declare a node unreachable > even though the criteria for determining that the link(s) being used to > reach the node are down have not yet been met.* > > > > Yes. In fact I am not worrying about hard down. I am more worried > about brownouts. > > > > *I would think this is prone to false negatives.* > > > > Well maybe yes maybe no. > > > > But let's think about it in the bigger context of UPA which is the subject > here. > > > > Nodes receiving UPA will only deprioritize paths with such next hop. If > there is no backup paths it will not harm anything. If there are > backup paths the indication that some remote PE has a hiccup seems to me > like very good signalling to use alternative path instead of continuing to > go via potentially breaking node. > > > > > > Not if multihop BFD is going to RP/RE. Perhaps some vendors can handle it > on LCs. > > > > *[LES:] Indeed they can – and if they cannot then the scalability of your > proposed solution is limited.* > > > > Really ? How ? > > > > Do you see any scalability issues with 2 (oh maybe 4-8) multihop BFD > sessions to *local* ABRs ? How is this not scalable ? Of course if your LC > <--> RE/RP path takes up to 100 ms in the box your multihop timers must > keep this in mind however this is I think obvious. > > > > Many thx, > > R. >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
