Re: [RRG] Small comment on draft-jen-apt-00.txt
Michael R Meisel <meisel@cs.ucla.edu> Fri, 12 October 2007 09:24 UTC
Envelope-to: rrg-data@psg.com
Delivery-date: Fri, 12 Oct 2007 09:27:05 +0000
Message-ID: <470F3D4F.9010907@cs.ucla.edu>
Date: Fri, 12 Oct 2007 02:24:31 -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, 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. Brian E Carpenter wrote: >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. 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. >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. 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 -- 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
- [RRG] Small comment on draft-jen-apt-00.txt Brian E Carpenter
- Re: [RRG] Small comment on draft-jen-apt-00.txt Michael R Meisel
- Re: [RRG] Small comment on draft-jen-apt-00.txt Brian E Carpenter
- Re: [RRG] Small comment on draft-jen-apt-00.txt Michael R Meisel
- Re: [RRG] Small comment on draft-jen-apt-00.txt Lixia Zhang