Jeff & Les, The suggested use of "LFA" was completely unrelated to ECMP or to data plane. I realize that some people may just think of LFA in its original meaning :).
It was just a hint how an edge node can determine which links are "towards" the disconnected nodes and which of his local links would be going in the opposite direction just by running SPF virtually putting as initial node your adjacent FT nodes. No more no less. Per section 6.7.9 it seems that implementation is already mandated ot find such links towards the disconnected part of the network, but it does not seems to indicate how. Maybe it is just a matter of local smart implementation. Peter, If I am reading your reply and section 6.7.5 it seems to indicate that you would not start adding any link to FT as long as you have at least one there still being alive. You just advertise new LSA/LSP over still active flooding link indicating change in topology and sit and wait till you get a new FT ? Well perhaps wrong, but my understanding was that if you have two active FT links you start adding new ones (and request your peer over that link to do so too) just after you loose one as a temporary patch till you get a new graph. So what happens when you loose one link and you do not get a new FT for time t. How long do you wait ? Many thx, R. On Tue, Mar 12, 2019 at 7:45 AM Peter Psenak <[email protected]> wrote: > Hi Robert, > > On 11/03/2019 22:28 , Robert Raszuk wrote: > > 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. > > above statement is incorrect. It is absolutely NOT TRUE that "at the > event of failure of any of the FT enabled link additional links are > being added". > > Temporary additions of the links to the FT has its strict rules: > > 6.7.5. Failures of Link On the Flooding Topology > > "If the failed local link represented the only connection to the > flooding topology on the node where the link failed, the node MUST > enable temporary flooding on a subset of its local links." > > 6.7.9. Treatment of Disconnected Adjacent Nodes > > Every time there is a change in the flooding topology a node MUST > check if there are any adjacent nodes that are disconnected from the > current flooding topology. Temporary flooding MUST be enabled > towards a subset of the disconnected nodes. > > > So we are only performing temporary flooding if either we or one of our > neighbors got isolated from the FT, which given the bi-connectivity of > the FT itself is an unlikely event. > > thanks, > Peter > > > > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/lsr > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
