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

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Aug 2007 13:48:58 +0200

I'm concerned that the proposed mechanism (as described
in section 5) completely deprives senders of the ability
to choose which of a destinations locators to use, in
accordance with their local policy (whatever it may be).
I don't think this is acceptable as it alllows receivers
or the operators of default APT mappers to constrain senders'
choice of ISP. That settles a business "tussle" in advance,
and I don't think technology should do that.

I'm also a bit concerned (section 5.1) that failover will be
delayed. In today's model, a sender can try a second address
after a sender-decided timeout on the first one. In APT, it
looks as if the sender will have to depend on a timeout in
the default mapper. But the only real test of reachability
is end to end.

And the standard question: how will this work with SCTP?

     Brian

--
to unsubscribe send a message to [email-masked] 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

---

From: Michael R Meisel <[email-masked]>
Date: Fri, 12 Oct 2007 02:24:31 -0700

Hi Brian, thanks for your comments. Sorry to take so long to get back to
you, Dan Jen and I were both away from UCLA this summer. Please see my
(overdue) responses to your comments below.

>and I don't think technology should do that.

Actually, the customer of an ISP is ultimately the authority for their 
own mapping information. Of course, since it's the ISP that announces
the mapping, the customer has to trust them not to modify it. One detail
that didn't make it into the 00 version of our draft is that we plan to
allow mappings to be cryptographically signed with a customer's private
key. We haven't yet determined how public keys will be distributed in a
secure manner, but we're working on it. This would prevent their ISPs
from modifying their mappings without invalidating them.

>the default mapper. But the only real test of reachability

I think you may be confusing user-space addresses (used for end-to-end 
communications) with multihoming of user networks. In fact, we are 
currently working on some terminology changes to help clarify this 
distinction.

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.

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.

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

-Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Oct 2007 14:23:50 +1300

> from modifying their mappings without invalidating them.

OK, that wasn't completely clear to me on first reading, but
seems fine.

> currently working on some terminology changes to help clarify this 

I didn't think I was confusing those. In any case, host software
doesn't know about that distinction - it only knows about addresses,
and it's standard procedure to try addresses in sequence if you get
more than one from A/AAAA records.

> will work the same way with APT as it would today.

Logically, yes, but...
> 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.

> 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?

    Brian

---

From: Michael R Meisel <[email-masked]>
Date: Mon, 15 Oct 2007 09:10:45 -0700

Hi Brian, see my responses below.

Brian E Carpenter wrote:
>> 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.
> 

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.

> 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

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 30 Nov 2007 01:29:57 -0800

On Oct 15, 2007, at 9:10 AM, Michael R Meisel wrote:

>>> APT will be invisible to end users. This means that it should not  
>>> have any effect on any transport-layer protocol.

my apology for this belated comment, but a clarification might be  
worthwhile even though it is late.  Michael's comment below is  
exactly right:

- a SCTP node can have multiple IP addresses only when it has
   multiple interfaces (physical or virtual).

- i.e. it is the host-multihoming that allows a SCTP node
   to "explicitly chooses to change to an alternative address".

- A SCTP node, as far as I understand (as co-author of the first SCTP  
spec), does not have a power to choose alternative paths out of  
*site* multihoming--which is what we are talking about here--if those  
paths are not reflected in the node's choice of its IP addresses.

> 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