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