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

[marcelo bagnulo braun <[e-mail]>]

Hi Francis,

thanks for your feedback

comments below...

El 05/12/2005, a las 10:46, Francis Dupont escribió:

>  In your previous mail you wrote:
>
>    Comments?
>
> => I have some comments:
>  - if the border router for X to A knows the outage it can deprecate
>    the A prefix and propagate the information. Note this idea was
>    described many time but as far as I know is *not* implemented
>    (if such basic idea is not supported I am afraid we'll get
>    no help from routers).
>    Perhaps the document should say something about this, for instance
>    explaining some outages can't be detected so easily...
>

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


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

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

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

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

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

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?

>  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

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

>
>  - in 3.2.1 there are other transport protocols than TCP and UDP.
>    I prefer connection oriented and connection less.
>


agree

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

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)


regards, marcelo


> The only
>    issue is this hint can be obsolete when the list changes but
>    when you look at the rules you can see they should give a stable
>    ordering. Of course, it can be used to get the source address list
>    for a destination...
>
> Thanks
>
> [e-mail]
>


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