Le 29 nov. 2011 à 17:15, Ole Troan a écrit : > Remi, > >> For those who attended the Softwire session in Taipei, please note that the >> serious objection against 4rd-U expressed by several participants during the >> meeting has been, soon after, acknowledged to be invalid >> (www.ietf.org/mail-archive/web/softwires/current/msg03281.html). >> Also, other (less important) objections have been answered in >> www.ietf.org/mail-archive/web/softwires/current/msg03284.html, without >> reaction so far. > > I do not think that's a fair representation.
It was intended to be one, and is still believed to be so (see below) > the main objection to 4rd-u is that it is 'just another translation' solution. a) That's not what I heard during the meeting. Both Mark Townsley and Dave Thaler, taking for granted your statement that checksum-neutral addresses of 4rd-U would cause "address spray", said firmly that 4rd-U should be rejected because it wouldn't work. In my understanding, not working is a show stopper, which I call a "main objection". b) If your main objection is that 4rd-U would be 'just another translation', it is ALSO invalid. If you have read my answer to your list of objections, you should know that 4rd-U is a reversible-header-mapping solution, and as such is based on neither translation nor encapsulation. (actually a tunnel closer to encapsulation in my understanding). > how many do we need? Many consider that, if there is the choice, ONE standard is better than several. The point is that 4rd-U combines advantages of double translation and encapsulation with only a slightly different tradeoff between optimizations of header-length and processing time. Doubts are legitimate as long as the specification is incomplete, but that's why more work is needed. > it doesn't appear to offer any benefits compared to the already specified > solution. Which solution? (So far, there are two in the pipe - translation and encapsulation.) Meeting requirements of both solutions is AFAIK a benefit. > as it stands it will just result in 3 ways of doing the same thing, instead > of 2. Different view on this. Three standards would make no sense. > the topic discussed in softwires, wasn't the main objection. as far as I can > see, "checksum neutrality" does not offer any advantages over incrementally > updating the L4 checksum. Again, commenting my previous answer to your list of objections would be be more constructive than repeating that 4rd-U doesn't do anything without arguing on substance. Since there is no obligation to comment, please refrain from criticizing a solution without commenting previous answers made for you. > every node doing this will have to look into the L4 header anyway. Sure. IPv4 address sharing implies _looking_ at port fields (true also for encapsulation). But this doesn't imply that L4 data need to be modified, especially if these modifications need to depend on whether the protocol is TCP UDP, DCCP, etc. Encapsulation and reversible header mapping don't care about this, which is one of their virtues. Cheers, RD _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
