Le 2012-03-25 à 07:31, Ole Trøan a écrit : > Remi, > >>> the authors did already do that. the dIVI and 4rd authors met 16th of >>> November at the last IETF. >>> we collectively went through the complete feature list. the result is what >>> you find in the MAP document series. >> >> This MAP meeting was immediately after the Taipei Softwire meeting. At this >> meeting, with an invalid technical argument, you had convinced most >> participants that -U couldn't work, so that a majority didn't believe the -U >> approach could be useful. > > that's not quite how I remember it. there were a number of issues discussed > with 4rd-U. > - destination spread, caused by Max PSID, CNP (I was wrong about CNP causing > destination spread). > - V-octet; implications > - how -U achieves transparency by overloading information in the > fragmentation header
No contradiction. - Destination spread was claimed to be caused by CNP. - Max PSID was unanimously abandoned during you meeting. - Your (invalid) objection to CNP was maintained, with no time to argue about it, so that you got a majority vote for not considering CNP anymore in the MAP team. >> During this MAP meeting, a majority consequently expressed no interest in >> considering further, for MAP, new features that were part of the -U proposal >> (Reversible header mapping; Checksum neutrality, AKA CNP; Distinguishable >> address format, AKA V octet). > > the MAP effort has focused on the mandatory functionality and features only. > > all the "features" between 4rd-U and MAP are interchangeable. in this > instance I do believe "less is more" though. > the distinguishing part of 4rd-U is that is uses a different form of > translation than what MAP does. Whatever you call it, its virtue is that: - it never modifies payloads - it completely restores IPv4 headers (except for IPv4 options, but these are not needed for IPv4 applications). Double RFC6145 translation, as you brilliantly explained yourself in Beijing, sometimes breaks e2e transparency. Cheers, RD > > cheers, > Ole > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
