Re: delayed multihoming/mobility set-up

[Geoff Huston <gih@telstra.net>]

> I'm afraid these two issues aren't really related. The reason that BGP 
> rerouting can take so long is that the RFC mandates a 90 second hold time, 
> but Cisco and presumably others use an even longer default hold time of 
> 180 seconds. Operators are often reluctant to change the default.
>
> Once the BGP session goes down there is of course the issue of updating 
> all the related routes, which can also take some time depending on the 
> number of routes that ran over the neighbor. But this is usually a matter 
> of seconds (think a one digit number).
>
> > It, instead, is the reference for BGP++.
>
> We already have BGP4+, but now we need BGP++?

Iljtsch is of course right - its also useful to bear in mind that _any_ 
distance vector
algorithm takes time to propagate, and any distance vector algorithm that
needs to also synch itself with interior routing systems will take more time.

The trade-offs here is speed vs stability. BGP is biased towards stability as
that is the best path we know for scaleability. I'm not sure that BGPn for any
n>4 will break out of this need to strike a balance between these two 
attributes.

That being said, all this strikes me as wandering off into the weeds for this
topic! :-)

  Geoff