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 <[email protected]
<mailto:[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] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/lsr
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
