[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: successful termination?



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 Linshim6

and recharter to address issues that arise in that deployment.
We have mainly used this implementation in lab environment. If readers
of this list are willing to deploy this implementation, we would be very
interested 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 pair
issue, which should IMHO be conjoined with the RFC 3484 update ongoing
in 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.