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
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
