Re: delayed multihoming/mobility set-up

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Dave Crocker;

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

And a 90 second hold time is already too long.

> The reason that BGP has a long hold is because short times lead to route
> flapping.
>
> 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.

And the definition on "too quick" is affected by time required
for BGP route computation, IGP route propagation and so on, all
of which are reduced with smaller routing table.

I think hold time for EBGP peering over point to point optical
ethernet should be (like SONET) several tens of milli seconds
(though it violates BGP4). However, the same timing can not
be applicable to IBGP peering.

Have smaller global routing table and make BGP converge as quickly
as that of telephone routing.

> 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.)

In this case, it does not help at all, as a notification of "one
goes out" is delayed 90 or 180 seconds.

							Masataka Ohta