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 network topologies where BGP speaking routers are directly > attached to each other, or use fault detection mechanisms such as BFD > [RFC5880], detecting and acting upon a link down event (for example > when someone yanks the physical connector) in a timely fashion is > straightforward. > > Not necessarily. Speaking from direct [painful] experiences, a router > with a slow control plane (such as the Juniper MX80) can easily need 15 > minutes or so to fully converge after link down has been detected on an > interface to which it had a large number of active routes. The prime > example would be a connection to an IP-transit provider advertising > full DFZ tables. > > 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 speakers». > > 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.
I think you make a valid point, would you be willing to prepare a change proposal to address this? The document's authoritive source is on github: https://github.com/bgpculling/draft-bgp-session-culling > 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. For single-homed customers of an IP-transit provider, on the > other hand, any amount of culling only contributes to making the outage > longer than necessary. So maybe it should be a suggestion to make it > possible to opt out of the culling behaviour. The myriad of issues resulting from a network single-homing on a single connection behind a single router might be out of scope for this document. Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
