Comments on draft-bagnulo-shim6-addr-selection-00.txt

Jari Arkko <jari.arkko@piuha.net> Wed, 05 October 2005 06:44 UTC

Envelope-to: shim6-data@psg.com
Delivery-date: Wed, 05 Oct 2005 06:44:45 +0000
Message-ID: <43437640.5030501@piuha.net>
Date: Wed, 05 Oct 2005 09:44:16 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
CC: shim6-wg <shim6@psg.com>
Subject: Comments on draft-bagnulo-shim6-addr-selection-00.txt
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit

Hi Marcelo,

And thanks for writing this draft. This is an important
scenario to cover. Generally speaking I like your
solutions. A few comments, however:

>5.1.1.  Direct link failures
>
The title seems a bit misleading. I thought first that
you were talking about the direct link from the host,
but this was really the link from the local router to the
ISP.

Anyway, I think you are missing a discussion of the
first case. Here it may even be that existing mechanisms
already solve the problem, because presumably RFC 3484
would not select source addresses from a link that's down.
But it would still be important to note this.

>   The missing part is a mechanism to convey the information from the
>   server to the host.  A possible option is to define a new DHCP option
>   to transmit policy table information.
>  
>
This does not appear to be able to deal with dynamic
outages, or does it? At the very least the lease times
would have to be set low.

>   It is also possible to enable the multihomed host to query the server
>   to obtain the source address prefix information as proposed in [6] .
>   In this case, each time the multihomed node initiates a communication
>   with a new destiantion, it would query the server for the proper
>   prefix to include in the source address.  The server, would reply
>   based on the routing information it has gathered through BGP.
>  
>
This might be a better alternative, perhaps modified by
only doing the query if you can't establish a connection.

>   The first option is to simply let the upper layers to handle
>   retrials.  In this case, the IP layer only has to make sure that a
>   different source address is used in each retrial as long as there is
>   not a preferred source address in the source address cache.  So, in
>   this approach, when the IP layer receives a packet, it searches the
>   Source Address Cache for a preferred source address associated to the
>   selected destination.  If no entry exists for that destination
>   address, one of the available source addresses is selected randomly.
>   If reply packets arrive, an entry will be created in the Source
>   Address Cache for that destination address.  If no reply packets
>   arrive, no entry will be created, so when the upper layer protocol
>   resends the packet, a new source address will be used.
>  
>
I may be confused here, but I suppose you are not talking
about IP packets, you are talking about connection initiation.
You can't change source address on the fly from an existing
TCP sessions.

--Jari