Hello, Tore and GROW, I am new here.
On 13 Mar 2017, at 11:11, Tore Anderson wrote:
Another logical consequence of this is that the rather imprecise «a
few
minutes» should ideally be expanded on, taking slow routers such as
the
MX80 into account. While five minutes of culling would be helpful, it
would not be enough to avoid all disruption.
One point of the technique is that the ‘lower layer caretaker’ looks
at their interface traffic counters to ensure traffic has dropped to
near-zero before commencing the ‘destructive’ part of the
maintenance. As a result no traffic is affected.
If a tree falls in the forest and there is no-one for it to land on,
does it matter? :-)
Our operational experience at LONAP shows this does usually happen
within 5 minutes.
If the operator/peer would decide to cull the session, say, 30 minutes
ahead of the maintenance, that would be great for me and others in my
situation.
I suspect this may be unnecessary, but do not have extensive data to
back this up.
With a 30 minute cull window, there is substantial concern that an
operator will begin to debug the ‘problem’, discover ICMP PING works
but TCP/179 doesn’t work, and get very annoyed at this strange
behaviour. I think we should operate on a principle of least surprise
here.
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
