Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

2017-03-14 Thread Tore Anderson
* Job Snijders > TEXT: > In network topologies where BGP speaking routers are directly > attached to each other, or use fault detection mechanisms such as > BFD, detecting and acting upon a link > down event (for example when someone yanks the physical connector) >

Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

2017-03-14 Thread Job Snijders
On Tue, Mar 14, 2017 at 01:05:08PM +0100, Tore Anderson wrote: > * Nick Hilliard > > Tore Anderson wrote: > > > In other words: in my opinion, BGP session culling should be > > > considered a BCP even in situations where link state signaling > > > and/or BFD is used. IP-transit

Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

2017-03-14 Thread Tore Anderson
* Nick Hilliard > Tore Anderson wrote: > > In other words: in my opinion, BGP session culling should be > > considered a BCP even in situations where link state signaling > > and/or BFD is used. IP-transit providers should perform culling > > towards their customers ahead of

Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

2017-03-14 Thread Nick Hilliard
Tore Anderson wrote: > In other words: in my opinion, BGP session culling should be considered > a BCP even in situations where link state signaling and/or BFD is used. > IP-transit providers should perform culling towards their customers > ahead of maintenance works. Direct peers, likewise.

Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

2017-03-14 Thread Tore Anderson
* Nick Hilliard > Tore Anderson wrote: > > My point here was that if the IXP is doing maintenance, it could shut > > all ports to all members simultaneously, and thus get the exact same > > effect as the «when someone yanks the physical connector» scenario > > described in the

Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

2017-03-14 Thread Nick Hilliard
Tore Anderson wrote: > By the way, as an IXP operator, you also have the possibility to simply > shut down your members' interfaces prior to performing maintenance, > instead of doing culling. Doing so would be completely analogous to the > directly connected BGP speakers scenario discussed in

Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

2017-03-13 Thread Nick Hilliard
Will Hargrave wrote: > 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

Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

2017-03-13 Thread Will Hargrave
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

Re: [GROW] Comment on draft-iops-grow-bgp-session-culling

2017-03-13 Thread Job Snijders
Hi Tore, On Mon, Mar 13, 2017 at 12:11:34PM +0100, Tore Anderson wrote: > While I wholeheartedly agree with the recommendations in the draft and > really wish my providers and peers will all incorporate them into their > maintenance routines, I have one comment on the following text: > >In