Re: delayed multihoming/mobility set-up

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 25-nov-03, at 16:51, Dave Crocker wrote:

> IvB> The reason that BGP
> IvB> rerouting can take so long is that the RFC mandates a 90 second 
> hold
> IvB> time,

> The reason that BGP has a long hold is because short times lead to 
> route
> flapping.

Hm, it shouldn't have to. And BGP has route flap dampening.

> This is an inherent property of doing route calculations.  A scheme 
> that
> is too quick to change will be constantly changing.  Hence the
> assessment of a particular route always needs to be pretty slow to
> change the assessment.

I disagree. The right thing to do would be to popagate bad news fast, 
and good news slower. This limits the amount of flapping almost as well 
as delaying both good and bad news, while still allowing fast rerouting 
when failures happen.

Regardless, there is no reasonable scenario where a keepalive comes in 
after 179 seconds. Three minutes is just too long. In my book I 
recommend 15 seconds but this is probably a bit too agressive: 
unfortunately there seem to be some BGP implementations that fail to 
generate keepalives frequently when they're busy, so setting the 
keepalive to 15 seconds leads to frequent flaps. But 30 seconds should 
be ok most of the time, maybe 60 seconds for the conservative crowd.

> That is why I think the way to achieve quick response is with a model 
> of
> parallel paths.  When one goes out, the other is already in use.  (Of
> course, this introduces the costs of out-of-order packets.)

I'm not sure if this is worth the trouble for just failover. Remember 
that by using twice the paths you're also vulnerable to twice the 
outages. But we probably want this for load balancing anyway.