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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding
From:       Peter Psenak <ppsenak () cisco ! com>
Date:       2019-03-12 11:09:45
Message-ID: 0e8b3753-7263-900d-7d6c-e103c25b5689 () cisco ! com
[Download RAW message or body]

Robert,

On 12/03/2019 10:42 , Robert Raszuk wrote:
> 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 ?

when the local link that is on FT is lost, the FT is recalculated, 
either locally, or centrally and flooded. That should provide 
bi-connectivity again, if available.

Temporary flooding is only triggered when node itself or its neighbor 
becomes isolated.

thanks,
Peter

>
> Many thx,
> R.
>
>
>
> On Tue, Mar 12, 2019 at 7:45 AM Peter Psenak <ppsenak@cisco.com
> <mailto:ppsenak@cisco.com>> 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
>     > Lsr@ietf.org <mailto:Lsr@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/lsr
>     >
>

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[prev in list] [next in list] [prev in thread] [next in thread] 