Re: [RRG] Small comment on draft-jen-apt-00.txt

Michael R Meisel <meisel@cs.ucla.edu> Mon, 15 October 2007 16:10 UTC

Envelope-to: rrg-data@psg.com
Delivery-date: Mon, 15 Oct 2007 16:12:03 +0000
Message-ID: <47139105.1020502@cs.ucla.edu>
Date: Mon, 15 Oct 2007 09:10:45 -0700
From: Michael R Meisel <meisel@cs.ucla.edu>
User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: rrg@psg.com
Subject: Re: [RRG] Small comment on draft-jen-apt-00.txt
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit

Hi Brian, see my responses below.

Brian E Carpenter wrote:
> On 2007-10-12 22:24, Michael R Meisel wrote:
>> If you have more than one user-space destination address, such as from 
>> DNS A records, which you could address a (end-to-end) packet to, that 
>> will work the same way with APT as it would today.
> 
> Logically, yes, but...
>>
>> APT failover handles the case where the tunnel exit point (that is, 
>> the ETR) for a given user-space *prefix* fails. Note that this is in 
>> the middle of the network, not at an endpoint. In the existing 
>> network, the failure would have caused a BGP route change. With APT, 
>> there is no announcement or timeout involved, the first packet is 
>> simply re-routed to a working ETR if possible, and the ITR is notified 
>> so that subsequent packets are tunneled directly to the working ETR.
> 
> Yes, if there *is* a working path. But if there isn't, it will be a long 
> time
> before the upper layer tries the next address that it knows about, I think.
> Or do you think the upper layer will just time out anyway? In any case,
> the upper layer code will be trying to get around apt instead of working
> with it.

The upper layer will certainly just time out anyway. This would work 
exactly the same as if there were no BGP path to your destination prefix 
in the network today. If none of the ETRs for a destination user-space 
prefix are reachable, APT isn't doing anything to make the destination 
address /appear/ reachable. That address is simply unreachable 
currently, and packets can't get to it. This isn't "getting around" APT 
any more than timing out and trying a different address is "getting 
around" BGP today.

>>> And the standard question: how will this work with SCTP?
>>
>> APT will be invisible to end users. This means that it should not have 
>> any effect on any transport-layer protocol.
> 
> But SCTP doesn't *want* that invisibility, because it explicitly chooses
> to change to an alternative address in order to use an alternative path.
> How do you allow SCTP to do its job?

The same way BGP allows SCTP to do its job today. If you try a different 
address, you are just as likely to get a different path through the 
network with APT in place are you are without it. When I say that APT is 
invisible, I mean that end hosts shouldn't be able to tell whether it's 
being used or not -- everything should work the same as it does today 
from their perspective.

-Michael

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg