* 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)
> in a timely
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 providers should pe
* 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. Di
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.
proba
* 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 draft.
>
> this
Hi,
On Tue, Mar 14, 2017 at 07:22:25AM +0100, 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.
You can, but if you have a LARGE IXP (like DECIX or AMSIX
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 draft.
this doesn't work because 1. some ixp p
* 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 speaker
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 sect
* "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 fiv
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 h
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
On Mon, Mar 13, 2017 at 03:57:08PM +0100, Job Snijders wrote:
> > So in my opinion, BGP Session Culling really ought to be the BCP in all
> > topologies, not just the ones «where upper layer fast fault detection
> > mechanisms are unavailable and the lower layer topology is hidden from
> > the BGP
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 ne
Hi,
[I'm not subscribed to grow@ietf.org so apologies for breaking threading
and possibly bringing up an issue that has been raised before. Please
Cc me on replies.]
While I wholeheartedly agree with the recommendations in the draft and
really wish my providers and peers will all incorporate them
15 matches
Mail list logo
