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

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 Mar 2019 22:28:04 +0100

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 12 Mar 2019 04:28:09 +0000

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 <[email-masked]> On Behalf Of Robert Raszuk
Sent: Monday, March 11, 2019 2:28 PM
To: [email-masked]
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.

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 11 Mar 2019 22:35:57 -0700

+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) <[email-masked]> wrote:
> 
> Robert –
>  
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Peter Psenak <[email-masked]>
Date: Tue, 12 Mar 2019 07:45:18 +0100

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

> 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 ?
>
> _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.
> /
> /
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 12 Mar 2019 10:42:28 +0100

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.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 12 Mar 2019 12:09:45 +0100

Robert,

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

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Robert,
>
>     > Such optimization is local and optional and does not require any
>     changes
>     > to proposed protocol signalling.
>     >
>     > [email-masked] <mailto:[email-masked]>