[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Jari,

thanks for the reading and commenting the draft...

El 05/10/2005, a las 8:44, Jari Arkko escribió:



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.



right


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.



right, i will add some comments about 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.
well, dhcp6 does have a push option AFAIU, which means that the dhcp server could actually push the changes on the policyt table to the hosts when a change is needed. I guess that this would deal with dynamic outages.
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.
well, as i recall the naros idea, was to also allow some traffic engineering possibilities, which is why querying each time may make sense. OTOH, this does introduce some overhead, so, omitting it as you suggest makes also sense 




  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.
Well, actually i am talking about every time that the address selection mechanism (RFC 3484) is performed. This includes the moment that a TCP connection is initiated (as you mention) but also each time an UDP packet is sent i guess. It does not includes subsequent packets once that a TCP connection is initiated, since selected addresses are used, as you point out. 

I will add more detail explaining this clearly.

Thanks, marcelo



You can't change source address on the fly from an existing
TCP sessions.

--Jari