Re: Last Call: <draft-ietf-rtgwg-uloop-delay-06.txt> (Micro-loop prevention by introducing a local convergence delay) to Proposed Standard

[Stewart Bryant <stewart.bryant@xxxxxxxxx>]

On 21/09/2017 09:27, Robert Raszuk wrote:

Stewart,

Since you brought the link up scenario .... 

>  keeping the link out of service until a quiet time

How would a router know when there is a "quiet time" network wide which would not cause disruption for the sensitive applications when the link is flooded again ? 

Or do you mean that such quiet time is a preconfigure window on the router by operator (say to match local after hours times) ? 

Or you mean that link up would always require operator's action ?

My assumption is that a chosen time is probably better than a random time autonomously chosen by the routing system. How that time is chosen is a matter for further consideration.

It seems to me that if you care about uloop disruption you care about it (full stop). A reduction in occurrence of 50% may or may not be of significant practical benefit depending on the degree of concern.

If nothing else the text should delve a little deeper into the shortcomings and mitigations of this approach.

- Stewart

Thx,

R.

On Thu, Sep 21, 2017 at 10:21 AM, Stewart Bryant <stewart.bryant@xxxxxxxxx> wrote:

The draft states that

" The proposed mechanism is limited to the link down event in order to keep the mechanism simple."

Since a link that goes down will normally also come up again, the draft ought to provide some guidance to the operator on how they should handle that situation. Applications that care about the disruption caused by microloops presumably have no care as to whether they are cause by link up or link down, and so would prefer a complete elimination of that disruption. However I accept that complete elimination has wider network impact and that this approach which is really microloop mitigation has utility.

The advice might be as simple as keeping the link out of service until a quiet time, or the loss of connectivity has moved to the network to a state of fragility such that disruption is acceptable.

- Stewart

On 20/09/2017 19:44, The IESG wrote:

The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document: - 'Micro-loop prevention by
introducing a local convergence delay'
   <draft-ietf-rtgwg-uloop-delay-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2017-10-04. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


    This document describes a mechanism for link-state routing protocols
    to prevent local transient forwarding loops in case of link failure.
    This mechanism proposes a two-step convergence by introducing a delay
    between the convergence of the node adjacent to the topology change
    and the network wide convergence.

    As this mechanism delays the IGP convergence it may only be used for
    planned maintenance or when fast reroute protects the traffic between
    the link failure time and the IGP convergence.

    The proposed mechanism is limited to the link down event in order to
    keep the mechanism simple.

    Simulations using real network topologies have been performed and
    show that local loops are a significant portion (>50%) of the total
    forwarding loops.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/ballot/

The following IPR Declarations may be related to this I-D:

    https://datatracker.ietf.org/ipr/2565/

_______________________________________________
rtgwg mailing list
rtgwg@xxxxxxxx
https://www.ietf.org/mailman/listinfo/rtgwg