Remi, to summarize my view: - the 4rd-u proposal (including the changes you plan) are well understood - the main ideas from 4rd-* are already incorporated into MAP - 4rd-u is a slightly different way of doing translation (calling mapping doesn't change that fact) go to behave to argue if yours is better than what was specified there. - I think it is the wrong thing for this working group to encourage development of yet another solution, when we already have many. - I would also like to see one solution, my choice is encapsulation. given that all the building blocks already exist, I would expect we'll see translation in the wild too, whatever we choose to do in the IETF. ref: NAT464.
I really hope this is the last I'll ever write on this topic. cheers, Ole On Nov 29, 2011, at 19:11 , Rémi Després wrote: > 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
