* Job Snijders <[email protected]> > 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
