Subject: Re: I-D Action:draft-axu-addr-sel-00.txt

From: Aleksi Suhonen <[email-masked]>
Date: Fri, 04 Sep 2009 04:58:30 +0300

Hello,

Thank you for comments on the draft. I've been on a short vacation and 
now the students are coming back, so I have a handful of excuses for not 
having responded faster. O:-)

Brian E Carpenter wrote:
>> 2.2.  Autoconfiguration for Global Scope

>>    This usually means that the next hop of that default route will only
>>    be useable with the source address learned from that default router.

> Can you be more explicit that any global scope routing table MAY
> contain a default route and that the default route could be different
> for each source address? (I do mean MAY; there might be source addresses
> with no default route.)

I've been rewriting the draft with this idea in mind:

If an address has a default route, it is global scope.
If an address does not have a defaut route, it's link local, site local 
or some other limited scope.

This means that even 192.168.1.33 can be global scope, when it's behind 
a NAT box that is connected to the Internet.

>> 2.3.  Site Local Scope

> Since we abolished this for IPv6 and it is undefined for IPv4,
> could you try a more neutral phrase such as

I was thinking of RFC1918 and ULA when I was writing this.

>  2.3.  Limited Scope

Is this the term used by the ULA drafts?
  (Maybe I should add them to my reading list too ...)
I'll try to start using this term.

> (For some thoughts about limited scope,
> see draft-carpenter-behave-referral-object.)

I'm trying to keep my algorithm itself completely scope agnostic, 
although your idea of ScopeIDs could be very useful in identifying when 
two or more interfaces belong to the same routing domain and their 
tables could be combined in forwarding or routing protocol cases.

Although right now I'm reconsidering removing the forwarding and routing 
protocol sections from the draft, since they only seem to cause confusion.

>> 3.1.  Route and Table Preferences
> ...
>>    In order to perform source address selection, only one destination
>>    address SHOULD be presented to the algorithm, which will then look
>>    for the address in all tables and sort the source addresses where it
>>    was found according to the precedences.
>>
>>    In order to perform destination address selection, only one source
>>    address SHOULD be presented to the algorithm along with the set of
>>    destination addresses.  The algorithm will then look for all the
>>    given destination addresses in the table associated with the source
>>    address and sort the results according to the precedences.

> I see this as a bit of a problem. The underlying issue for
> host-based multipath approaches (including shim6) is to pick
> the best address pair, not to pick the best source given a
> destination or vice versa. We should allow for such an algorithm
> as well.

Heh, it feels nice to find a kindred spirit. (My original impetus for 
starting to work on this draft was host-based multi-homing :-)

The algorithm presented in the draft works on address pairs ONLY.
The two paragraphs you quoted are there to explain how the algorithm can 
be used to perform "one sided address selection", for backwards 
compatibility with RFC3484 which doesn't support any other notions.

I guess I should move those paragraphs into some other part of the 
document and maybe give them a more descriptive title.

-- 
	Aleksi Suhonen
	Department of Communications Engineering
	Tampere University of Technology