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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]> mailing lists by
2017-10-04. Exceptionally, comments may be
sent to [email protected] <mailto:[email protected]> 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/
<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/
<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/
<https://datatracker.ietf.org/ipr/2565/>
_______________________________________________
rtgwg mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/rtgwg
<https://www.ietf.org/mailman/listinfo/rtgwg>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
