Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding

[Robert Raszuk <[e-mail]>]

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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/lsr
> >
>
>