+1 Les. In general - in ECMP cases LFA is meaningless (any ECMP member is loop-free per definition) so commonly used technology is fast-rehash, where in case of failure all the flows that would use the link in question are rehashed over other links in the bundle and that is done in HW.
Regards, Jeff > On Mar 11, 2019, at 21:28, Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > > Robert – > > I don’t think the word “random” is applicable. > > Section 6.7.11 states (emphasis added): > > “In the unlikely event of multiple failures on the flooding topology, > it may become partitioned. The nodes that remain active on the edges > of the flooding topology partitions will recognize this and will try > to repair the flooding topology locally by enabling temporary > flooding towards the nodes that they consider disconnected from the > flooding topology until a new flooding topology becomes connected > again.” > > This isn’t a case of every node in the network trying to decide how to repair > the partition. It is only the nodes at the edge(s) of the partition doing so. > I do not see this as “random”. > > What is being debated on the list is not related to randomness – it is the > degree of temporary flooding along the continuum from “minimal” (one > additional edge) to “maximal” (all edges to nodes which are seen as currently > disconnected). The former risks longer convergence – the latter risks > temporary flooding storms. But neither approach is random. Once the failures > are known, the set of candidates is predictable. > > The concept of LFA also isn’t applicable here. LFA (if we use the term in > this case to mean a precalculated set of temporary flooding edges) is useful > when it can be preinstalled in the forwarding plane, allowing a node to > eliminate waiting for control plane intervention when a local failure is > detected. > But LSP/LSA flooding is always done by the control plane – so having a > precalculated LFA wouldn’t produce a faster response time. If you are going > to suggest that the calculation required to determine a flooding topology > partition is itself costly I think this is not supported by current SPF > calculation times. In addition, given temporary flooding is normally only > required in the event of multiple failures, the combinations required to be > supported in order to have a useful set of pre-calculated temporary flooding > edges becomes quite large – which makes such an approach impractical. > > Les > > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Robert Raszuk > Sent: Monday, March 11, 2019 2:28 PM > To: lsr@ietf.org > Subject: [Lsr] Temporary addition of links to flooding topology in dynamic > flooding > > Hi, > > As of now at the event of failure of any of the FT enabled link additional > links are being added in more or less random fashion by nodes directly > connected to the failed links. > > In the event of 100s of links on such nodes and advisable rate limiting > addition of those links it seems that repair of FT may take some time. > > In order to reduce such time interval better then random addition of > remaining links seems recommended. How about we hint participating nodes to > execute purely in control plane of FT an LFA algorithm for possible future > event of active link failure and use results of the LFA computation to > prioritize links which will be first temporary additions upon active flooding > links failures ? > > Such optimization is local and optional and does not require any changes to > proposed protocol signalling. > > Therefor how about just one sentence addition to section 6.7.1 of > draft-ietf-lsr-dynamic-flooding: > > Temporary additions of links to flooding topology could be more educated if > given node runs a pure control plane LFA ahead of any FT failure on active FT > links completely detached from potential LFA runs for data plane topology. > > Kind regards, > R. > > _______________________________________________ > 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
