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

[Tore Anderson <[e-mail]>]

* Nick Hilliard <[e-mail]>

> 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 section 1 where the draft says «detecting and acting upon a link
> > down event (for example when someone yanks the physical connector)
> > in a timely fashion is straightforward».  
> 
> - if the ixp port is connected to an intermediate switch on the member
> side, the ixp member router won't see the carrier state transition and
> will blackhole traffic on the member side

Yes, but is also true for a point-to-point connection with two BGP
speakers. Your direct peer or transit customer might very well have
inserted a switch or some other device in front his BGP speaker.

> - all other ixp members who peer with that router also won't see the
> carrier state and will leave bgp up, causing traffic to be blackholed on
> the remote side.

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.

So really, the IXP (operator) scenario isn't as different from the
direct connection scenario as the draft currently suggests. n both of
those cases, the party doing maintenance has the possiblity to
explicitly bring the link down and thus avoid relying on BGP timers for
outage detection.

However and IMHO culling is still warranted in both cases, because of
the possibility of intermediate devices defeating the link state
signaling, and to prevent disruption during reconvergence onto
alternate paths even when the link state signaling does work.

Tore