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

List:       ietf
Subject:    RE: Last Call: <draft-ietf-rtgwg-uloop-delay-06.txt> (Micro-loop prevention by introducing a local c
From:       <stephane.litkowski () orange ! com>
Date:       2017-09-27 13:20:45
Message-ID: 12148_1506518446_59CBA5AE_12148_328_1_9E32478DFA9976438E7A22F69B08FF921EA81766 () OPEXCLILMA4 ! corporate ! adroot ! infra ! ftgroup
[Download RAW message or body]

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:stewart.bryant@gmail.com] 
Sent: Wednesday, September 27, 2017 12:15
To: LITKOWSKI Stephane OBS/OINIS; ietf@ietf.org
Cc: rtgwg-chairs@ietf.org; akatlas@gmail.com; draft-ietf-rtgwg-uloop-delay@ietf.org; \
                rtgwg@ietf.org
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, stephane.litkowski@orange.com wrote:
> 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:stewart.bryant@gmail.com]
> Sent: Thursday, September 21, 2017 10:21
> To: ietf@ietf.org
> Cc: rtgwg-chairs@ietf.org; akatlas@gmail.com; 
> draft-ietf-rtgwg-uloop-delay@ietf.org; rtgwg@ietf.org
> 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:
> > 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@ietf.org mailing lists by 2017-10-04. Exceptionally, 
> > comments may be sent to iesg@ietf.org 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/
> > 
> > 
> > 
> > 
> > 
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.
> 


_________________________________________________________________________________________________________________________


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.


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