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...
- 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? - note that many applications which specify source addresses in fact simply use source addresses returned by the selection mechanism (connect() then getsockname())... - 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! - in the Rule 0 the term "unreachable" is not the right one, IMHO it is more "not working for D"? - it is not true that RFC 3484 provides an ordered list of destination address, it only orders the list provided by DNS & co. BTW it should be useful to know when the tail of a list contains unusable addresses or to remove them. - 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. - in 3.2.1 there are other transport protocols than TCP and UDP. I prefer connection oriented and connection less. - 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. 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 [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
