Subject: Re: delayed multihoming/mobility set-up

From: Masataka Ohta <[email-masked]>
Date: Mon, 01 Dec 2003 14:07:10 +0900

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

---

From: "Tony Li" <[email-masked]>
Date: Mon, 8 Dec 2003 15:57:51 -0800

Catching up...

Christian,

I would agree with your timeline but would suggest one small tweak:

Once the "set of equivalent addresses" has been exchanged, then for
implementation reasons, it makes some sense to locate an alternate
set of working addresses BEFORE the transport event happens.  This
is necessary because this is an O(N^2) problem and you don't want
to have to solve it in real time.  Of course, some intelligence
in the host to choose "better" addresses could make for some
implementation differentiation too.

Tony

|  -----Original Message-----
|  From: Christian Huitema [mailto:[email-masked]] 
|  Sent: Monday, December 01, 2003 9:19 AM
|  To: Masataka Ohta; [email-masked]
|  Cc: Iljitsch van Beijnum; Multi6 Mailing List
|  Subject: RE: delayed multihoming/mobility set-up
|  
|  
|  > > 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.
|  
|  ... which is why I am convinced that the solution to 
|  preserving existing
|  communication is closest to "transport protocols" than "routing
|  protocols". The time scale of transport protocols is the 
|  RTT; the time
|  scale of routing protocols is the minute. If we wait for a 
|  routing event
|  to be somehow signaled to the transport stack, the connection will be
|  gone. The natural solution is to use a transport event, e.g. a
|  retransmission timer. This event can trigger an end-to-end 
|  "connection
|  rehoming" exchange.
|  
|  My preferred time-line would be:
|  
|  1) Start a communication using one of the available pairs of src/dest
|  addresses.
|  2) If the communication is determined to be worth it (i.e. last long
|  enough), engage in "multi-homing signaling" to obtain a "set of
|  equivalent addresses"
|  3) On a transport event such as retransmission time-out, 
|  probe alternate
|  pairs of src/dest addresses, and pick a "better one" if available.
|  
|  I would note that a lot of the communication we have today 
|  do not meet
|  the "worth it" requirement. The top applications in the 
|  Internet today
|  are web pages, which mostly consist of a large number of very short
|  exchanges, and p2p file sharing, which includes its own application
|  level tools to deal with multi-homing. 
|  
|  -- Christian Huitema
|  
|