On Apr 3, 2009, at 12:42 PM, Olivier Bonaventure wrote:
Fred,In my opinion, there are two rational outcomes. One is to close the working group pending deployment reports,See http://tools.ietf.org/html/draft-barre-shim6-impl-02 for a detailed implementation report about Linshim6and recharter to address issues that arise in that deployment.We have mainly used this implementation in lab environment. If readersof this list are willing to deploy this implementation, we would be veryinterested in participating in the tests.
That's pretty common for protocols in development. What I am suggesting is that the working group reconvene when there is operational deployment and issues resulting from it.
The other is the locator pairissue, which should IMHO be conjoined with the RFC 3484 update ongoingin 6man. I would ask 6man to pick up the locator pair question.I think that alto could play an interesting role for shim6 as well,although I'm not sure that this fits entirely in the restricted alto charter
My line of reasoning is similarity of objectives. Shim6 would like the originating system to know what address pair to use, knowing that a choice of address pair at some level determines a route - ingress filtering may result in traffic loss if the wrong source address is used, and the RTT through one path is different than another.
A case in point that one of the shim6 chairs will recall was discussed on the IAB perhaps a decade ago. At my request, he simulated the effect of alternative address pair choices by pinging two different addresses in Singapore from his office in Canberra. One route was relatively direct and had an RTT on the order of 80 ms; the other route went via the US west coast, and had an RTT on the order of 600 ms. Assuming those were two addresses for the same server (they weren't, but that's another discussion), choice of address pair would have dramatic effects on the service as perceived by the user. And as it turns out, the lower RTT path isn't necessarily the path through the shortest number of AS's or etc. a list of rules based on prefix matching has value but isn't the final result.
3484bis would like to know how to select a source address given a destination address. If there is only one destination address, that is exactly the same problem, and if there are multiple destination addresses, it only addresses part of the problem.
So I would like, under whatever aegis, for the two efforts to cooperate or merge.