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

From: Stewart Bryant <[email-masked]>
Date: Thu, 21 Sep 2017 09:21:29 +0100

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
> [email-masked] mailing lists by 2017-10-04. Exceptionally, comments may be
> sent to [email-masked] 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/
>
>
>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 Sep 2017 10:27:49 +0200

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 ?

Thx,
R.

On Thu, Sep 21, 2017 at 10:21 AM, Stewart Bryant <[email-masked]>
wrote:

> 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
> quiet time, or the loss of connectivity has moved to the network to a state
> of fragility such that disruption is acceptable.
>
> - Stewart
>
>
>
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 21 Sep 2017 09:36:22 +0100

On 21/09/2017 09:27, Robert Raszuk wrote:
> 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) ?
>

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 
> <[email-masked] <mailto:[email-masked]>> 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
>
>
>
>         [email-masked] <mailto:[email-masked]> mailing lists by
>         2017-10-04. Exceptionally, comments may be
>         sent to [email-masked] <mailto:[email-masked]> instead. In
>         either case, please retain the beginning of
>         <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/>
>
>         <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/ballot/>
>
>         <https://datatracker.ietf.org/ipr/2565/>
>
>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/rtgwg>
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 21 Sep 2017 17:04:56 +0000 (UTC)

Hi all,I concur with Stewart regarding a simple advice to the operator. In most cases a link that goes down will not repair itself without some external intervention.
And if we deal with a flapping link, it is a probkem by abd of itself,  and probably should be disabled until the underlying problem is fixed.
My 2c,Sasha Vainshtein

Sent from Yahoo Mail on Android 
 
  On Thu, Sep 21, 2017 at 11:21, Stewart Bryant<[email-masked]> wrote:   
The draft states that

- Stewart

---

From: <[email-masked]>
Date: Wed, 27 Sep 2017 08:19:47 +0000

Hi Stewart,

Thanks for your comment.
Managing the link up is more tricky than the link down. We had a proposal to tweak the flooding in the first versions of the draft but there was not a good support of that as it touches an important component of the protocol, so it was removed to keep the solution simple but yes it reduces the benefit.

There is nothing that we can really do to prevent the impact of the link up. Even if the operator implements an interface dampening mechanism to ensure that the link is stable, the link will eventually goes up and may create a microloop.
Now keeping the link down until a quiet time is theorically doable but practically it is not. When a link is down, there are two situations: the operator has lost some capacity that leads to a congestion somewhere or if there is no congestion, the network becomes at risk as if another component fails, there will be not enough capacity. So practically, we want the link to go back up as soon as possible.

Other approaches like using "incremental" metrics may be used for the up case to prevent the uloop. 

Brgds,

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, September 21, 2017 10:21
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-ietf-rtgwg-uloop-delay-06.txt> (Micro-loop prevention by introducing a local convergence delay) to Proposed Standard

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:
> (rtgwg) to consider the following document: - 'Micro-loop prevention 
> by introducing a local convergence delay'
> 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 
> [email-masked] mailing lists by 2017-10-04. Exceptionally, comments may 
> be sent to [email-masked] instead. In either case, please retain the 
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 27 Sep 2017 11:14:34 +0100

Yes, I admit it is tricky, but I think that we have to be honest with 
the reader, since as we both agree this only solves part of the problem.

Incremental metrics is certainly one local solution that can be 
deployed, and if the metric of the link is low that need not take many 
cycles to complete.

The key point for me is that the text needs to describe the shortfall of 
the solution, and whilst ideally it should provide mitigation if it 
cannot do that, it needs to be clear on the consequences of not 
providing it so that those not schooled in the detail of IPFRR 
understand what will happen to their network when they deploy this.

Something that Benoit has been encouraging people to write for a while 
is an Operational  Considerations section, which would be an ideal place 
to put this discussion.

- Stewart

---

From: <[email-masked]>
Date: Wed, 27 Sep 2017 13:20:45 +0000

I'm fine with that. It could fit in the deployment considerations section.
Do you want to propose a short text ?

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, September 27, 2017 12:15
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-ietf-rtgwg-uloop-delay-06.txt> (Micro-loop prevention by introducing a local convergence delay) to Proposed Standard

Yes, I admit it is tricky, but I think that we have to be honest with the reader, since as we both agree this only solves part of the problem.

Incremental metrics is certainly one local solution that can be deployed, and if the metric of the link is low that need not take many cycles to complete.

The key point for me is that the text needs to describe the shortfall of the solution, and whilst ideally it should provide mitigation if it cannot do that, it needs to be clear on the consequences of not providing it so that those not schooled in the detail of IPFRR understand what will happen to their network when they deploy this.

Something that Benoit has been encouraging people to write for a while is an Operational  Considerations section, which would be an ideal place to put this discussion.

- Stewart

On 27/09/2017 09:19, [email-masked] wrote:
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: Last Call: <draft-ietf-rtgwg-uloop-delay-06.txt> 
> (Micro-loop prevention by introducing a local convergence delay) to 
> Proposed Standard
>
>
> The draft states that
>
>> final comments on this action. Please send substantive comments to 
>> the [email-masked] mailing lists by 2017-10-04. Exceptionally, 
>> comments may be sent to [email-masked] instead. In either case, please 
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
> ______________________________________________________________________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.