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 <[email protected]> Sent: Sunday, July 17, 2022 1:12 PM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Christian Hopps <[email protected]>; Peter Psenak (ppsenak) <[email protected]>; lsr <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
