Henk, On Wed, Nov 07, 2018 at 03:06:45PM +0100, Henk Smit wrote: > Jeffrey Haas wrote on 2018-11-06 05:20: > > >I'm ambivalent of the transport, but agree that TCP shouldn't be > >the default > >answer. > > I picked TCP because every router has a working TCP implementation.
Having just done a history lesson on BGP for NLNOG, it's sort of fun to see this. :-) > >My concerns that I tried raising via jabber summarize roughly as > >follows: > >- TCP is prone to interesting backpressure issues, typically as a > >result of > > packet loss or slow receivers. > > If a receiver is slow, that's the same situation as when IS-IS on the > neighbor is slow. Retransmissions happen. Retransmissions with 10589 > flooding are fixed time (5 seconds). (I guess some modern > implementations > do something smarter). So convergence would have been impacted with > native flooding too. I guess my question to those who live in IGP land is how often is this a problem? In the case of an IGP, the backpressure means you have databases that are out of sync and end up with bad forwarding. > Note that our proposal only does TCP over directly connected routers. > I'm sorry to say I have little experience with behaviour of BGP in > real networks. Where did you observe these backpressure issues ? EBGP > or iBGP ? Both iBGP and eBGP. The two general issues are slow receivers (scale) or responses to dropped packets. The general experiment I recommend to people trying to do this sort of thing is take your TCP stream of choice, pace it according to your transmission needs, and then drop 5-30% of the packets. Observe what happens. TCP recovers fine. But the hiccups can do bad things when timeliness is expected. For example, 3 second hold times for aggressive BGP peering may time out. I guess I'd restate my concern as "for this application, ensure that you're okay with the results of stalled trasnmission". Effectively, see the answer to the question I asked above about native behaviors. > Also note that in BGP, every update packet over every peering has > significance. > If one gets delayed, it slow down overall convergence. This is true. It's usually survivable due to hop-by-hop forwarding in BGP's case, but it can still do bad things. > In ISIS > flooding, a router > will receive multiple copies of the same LSP. So if one > TCP-connection is slow, > the router might still receive the same LSPs over other paths. And > the impact > on overall convergence is likely to be less. This, I think, is a better point addressing my concerns. Thanks. > Of course, this implies that routers flood over more than 1 or 2 > interfaces. If > we do one of the flooding-reduction proposals, I hope we'll end up > with a situation > where we have 3 or 4 redundant flooding topologies, so that routers > will still > receive LSPs quickly over other topologies when the primary topology > has problems. :-) -- Jeff _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
