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

[Tore Anderson <[e-mail]>]

* Job Snijders <[e-mail]>

> TEXT:
>     In network topologies where BGP speaking routers are directly
>     attached to each other, or use fault detection mechanisms such as
>     <xref target="RFC5880">BFD</xref>, detecting and acting upon a link
>     down event (for example when someone yanks the physical connector)
>     in a timely fashion is straightforward.
> 
> So we should add something that even though detection is
> straightforward, and initiating action as a result of this event can be
> done timely, we cannot be sure of timely termination of whatever actions
> are taken because of the event, and therefor the recommendation is to
> shutdown sessions before doing maintenance, even though networks are
> directly connected to each other.
> 
> The above matches my operational experience and aligns with how we
> perform router maintenance.
> 
> There are a number of considerations:
> 
>     - an operator may not know whether they are directly connected
>     - even if directly connected, the remote side might not be able to
>       convergence in a timely fashion
> 
> Perhaps the paragraph should just be removed?

Yes.

Here's a quick suggestion or starting point for discussion (intended to
replace section 1 in its entirety):

   BGP Session Culling is the practice of ensuring BGP sessions are
   forcefully torn down before maintenance activities on a lower layer
   network commence, which otherwise would affect the flow of data
   between the BGP speakers.

   BGP Session Culling ensures that network maintenance activities
   cause the minimum possible amount of disruption, by giving BGP
   speakers advance notice of an impending outage, so they may
   preemptively react to it by gracefully converging onto alternate
   paths while the forwarding plane is still fully operational.

   The grace period required for a successful implementation BGP Session
   Culling is the sum of the time needed to detect the BGP session loss
   plus the time required for the BGP speaker to converge on alternate
   paths. The first value is in the worst case governed by the BGP Hold
   Timer (section 6.5 of [RFC4271]). The second value is implementation
   specific, but could be as much as 15 minutes or more in the case of
   sessions where a router with a slow control plane is receiving a full
   set of Internet routes.

   Operators implementing BGP Session Culling are in any case
   encouraged to avoid using a fixed grace period, but instead monitor
   forwarding plane activity while the culling is taking place and
   consider it complete once traffic levels have dropped to a minimum
   [Section 2.3].

Tore