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

[Brian E Carpenter <[e-mail]>]

On 2007-10-12 22:24, Michael R Meisel wrote:
> 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.

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

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

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.

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

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

    Brian

--
to unsubscribe send a message to [e-mail] 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