Re: I-D ACTION:draft-bagnulo-ipv6-rfc3484-update-00.txt

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

   i agree this is a useful tool for multihomed environments (i have 
   included it in draft-bagnulo-shim6-addr-selection-00.txt) and i agree 
   that this should be detailed in a document related to initiating 
   communications in multihomed environments
   However, i am not sure if this would belong to a new version of RFC3484 
   which is the goal of this document...
   
=> to be complete the document in its introduction should explain
there are some cases without solutions so should list the possible
solutions to find cases where none applies. This is the way I'll
quickly explain the deprectation of prefixes from broken ISPs.

   >  - the document should address as soon as possible the orders between
   >    destination and source addresses, i.e., it is S1-D1, S2-D1, S1-D2,
   >    S2-D2 or S1-D1, S1-D2, S2-D1, S2-D2?
   >
   
   right, this would be the optimal approach, since it would provide an 

=> note I didn't ask for a solution but for the set out of the problem
(it seems I was not clear enough, I apologize).

   order of address pairs (as opposed to an order of destiantion addresses 
   and for each deatiantion address, an ordered list of source addresses) 
   but the difficulty with this is that current functions do not return 
   address pairs, but destination addresses and source addresses 
   separately. I guess that one option would be to define new function 
   calls that return list of src,dst address pairs, but this wouldn't be 
   compatible with current apps, since they don't use these to-be-defined 
   functions

=> this can be easily done by a middleware (aka bump in the API),
including the very special one named the shim6 layer...

   I guess that an option would be to define the two approaches, on one 
   hand the approach to define the list of dest addresses and for each 
   dest address an ordered list of source addresses and the other approach 
   (for updated apps) the returns an ordered list of src,dst address pairs
   
=> I don't believe in updated apps: we have to support this idea but
we have more to never rely on it!

   >  - note that many applications which specify source addresses in
   >    fact simply use source addresses returned by the selection
   >    mechanism (connect() then getsockname())...
   
   right
   the idea would be that the src addresses returned are ordered. The 
   difficulty is that this fucntion call does not refers to any specific 
   destiantion address

=> in the common mechanism I describe the destination is clearly taken
into account (it is the argument of connect()).

   and providing an order independent of the 
   destiantion is of little use imho
   so, the option would be to define a new function call that returns an 
   ordered list of source address available for a particular destiantion 
   address
   
=> a function or a simpler mechanism.

   >  - the Rule 0 is not enough accurate: it assumes some state is kept
   >    (what state? how? lifetime? etc). IMHO the document has to
   >    provide guidelines!
   
   agree
   in draft-bagnulo-shim6-addr-selection-00.txt there is a proposal to use 
   information in incoming packets as hints to determine which address 
   pairs are working. This information is cached and can be used to 
   determine if an address pair is working
   
=> so you have to cite this document and even to explain how to use
its ideas outside the shim6 context.

   >  - in the Rule 0 the term "unreachable" is not the right one, IMHO
   >    it is more "not working for D"?
   >
   
   agree
   an alternative would be to talk about working/non-working address pairs
   
=> you can't talk about an address pair in a function about an argument:
you have to find a better wording.

   >  - it is not true that RFC 3484 provides an ordered list of destination
   >    address, it only orders the list provided by DNS & co.
   
   I am not sure i understand the difference here...
   
=> it does not create the destination address list. BTW it is just
a wording issue.

   the rationale behind this is that a host wants to communicate with a 
   given host identified by a fqdn
   It then obtains the list of destiantion addresses for that fqdn from 
   the dns
   then rfc3484 orders the list provided by the dns
   so, i would say that rfc3484 returns an ordered list of destiantion 
   addresses...
   
   what is the aspect that i am missing here?
   
=> a function is not defined by its return value but by its return value
in function of its arguments (this is why it is named "function").
Sorry but I began in functional programming and I do important
differences for things which can be considered as details, like
"(f x) y" is not the same than "f (x,y)" cf a previous comment.

   >  BTW it should
   >    be useful to know when the tail of a list contains unusable
   >    addresses or to remove them.
   
   yes this could be an option
   otoh, an address pair working/non-working status may change over time 
   (and quite fast)
   so, possibly it may worth trying with address pairs that were not 
   working some minutes ago, if there are no other options (i.e. other 
   options have been tried later and they are not working)
   
   so including the addresses that were not working at the end of the list 
   may be of some use
   
=> a good alternative is to provide a reliability judgement so
a clever implementation can adapt its strategy in looking for
a working pair (I think about a sorting on address pairs).

   >  - IMHO it should be fine to get a support for address pairs because
   >    it is needed for any scheme which replaces the last "longest
   >    prefix match" rules by a better thing. I think about NAROS but
   >    there should be many similar ideas.
   
   i am not sure i understand this point...
   
=> look at draft-de-launois-multi6-naros-00.txt or read Cedric's PhD
document. To apply this kind of ideas you both have to replace
last rules and to give address pairs to the application.
So to be able to handle address pairs is an important goal in a
larger scope than this I-D.

   >  - in 3.2.2 the amount of tried source addresses has to be controlled.
   >    IMHO a better mechanism for both TCP and UDP is a new setsockopt()
   >    which the N first elements of the source address list.
   
   in this case the application would be:
   - first obtaining the src address list for a given destiantion with a 
   new call setting, and then

=> no, I don't see why this step is useful. Even the src address list
length is not important.

   - it would be setting the list of source addresses to be tried by 
   TCP/UDP using this new option, passing the list (or part of) obtained 
   in the previous point
   right?
   
=> you didn't understand my idea. In place to handle in the application
the source address list per destination you just specify the destination
and the number of the item of the source address list.
Of course you can get by connect() then getsockname() the source
address but you don't need to do this.

   This is an interesting middle ground option indeed, where the 
   application does not select a single address (as with bind()) nor it 
   leaves the src address unspecified (which is the actual scenario 
   considered in section 3.2.2)
   
=> the idea is to replace the bind() by a simpler setsockopt()
with a counter.

Thanks

[e-mail]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------