Remi, et al, > In the Softwire meeting of Monday, the key argument against the 4rd unified > approach (4rd-U) was that *Because checksum neutrality of addresses is part > of 4rd-U, it would allegedly cause "address spreading" (addresses used > between a pair of hosts would vary)*. > You had a slide asserting it, and the argument was taken as granted, and > important, in verbal comments from Mark Townsley and Dave Thaler. > I forcefully declared that this was technically false. > Since no time has been granted to explain, I invited anyone in doubt to > contact me for explanations. > Thanks for having taken the time to do it. > > Following our discussion of yesterday, I think you now understand that, as I > said: > - *TCP/UDP checksum neutrality of addresses DOES NOT interfere in any way > with stability of addresses between host pairs*.
acknowledged. as far as I can understand the checksum neutrality proposal will work, and it will result in stable addresses. two flows between two hosts will have the same addresses. and there is no "destination spread" with this mechanism. apologies for the uncertainty and confusion created by questioning this. > - Consequently, the key argument of the meeting against 4rd-U is invalid. that I disagree with. there were multiple arguments. let me try to summarize. - if 4rd-U resulted in one specification as opposed to two then 4rd-U is a good thing. if 4rd-U results in three specifications as opposed to two, then that is a bad thing. I have discussed this with the authors of the other two proposals, and they don't appear to withdraw their proposals in favour of this one. - 4rd-U has destination spread as written with the Max PSID has destination spread. this can obviously be fixed. - 4rd-U has the V octet, which impacts native IPv6 forwarding, and I think in general is problematic - 4rd-U is 'just' another translation proposal; it might provide a 'better' translation than what has been done so far in behave, but that doesn't alleviate the arguments made for encapsulation - 4rd-U has checksum neutrality, there is already a solution for the checksum. that is widely implemented, why bring in another way of doing it, creating two specifications for the same problem instead of using an existing one? cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
