* Nick Hilliard <n...@foobar.org> > 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 _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
