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

[Job Snijders <[e-mail]>]

On Tue, Mar 14, 2017 at 01:05:08PM +0100, Tore Anderson wrote:
> * Nick Hilliard <[e-mail]>
> > 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.  
> > 
> > probably not much need if bfd is used because that would operate
> > route-to-router.
> 
> Quite the contrary, there is very much a need in this case too. If there
> are many active routes that will become invalid, converging on
> alternate paths (reprogramming the FIB) can take significantly longer
> than actually detecting the outage (even if it's detected only using
> BGP timers).
> 
> > > IXPs aren't at all special regarding the fundamental need for session
> > > culling, only in the method by which it is accomplished (i.e., using
> > > layer-2 ACLs).  
> > 
> > Correct, but for direct peers over PNIs, etc, the operator will usually
> > have control over the bgp session.  What we're talking about here is a
> > situation where there is an intermediate operator which has no direct
> > admin control over bgp sessions.
> 
> The draft is most definitively also talking about the situations where
> the operator does have admin control over the BGP session (section 2.1).

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?

Kind regards,

Job