I also followed the discussion. I appreciate both teams bought up the technical details for both designs. To be honest, I fail to see which one is better than other (yet). I like the fact that 4rd-u can do what MAP-T does w/o introducing any encap overhead. But I understand the concerns others brought up in the ML such as V-octet. For MAP-T, I like it not introducing any new requirement to the IPv6 header, but I need more published data to determine whether the double-translation would cause any transparent issue or not. For example: I would very appreciate if somebody who trial MAP can publish data such as what applications they have tested, what pass and what fail.
This piece of work is very important because once we select it, this technology will stay for long time. I do not want to rush to make a decision and come back to regret in future. On 4/6/12 6:00 AM, "Liubing (Leo)" <[email protected]> wrote: >+1 > >I've read the endless discussion, and found that is seems the MAP also >has not fully convinced the ISP operation guys. >Since there's explicit controversy, why not just publish them both as >experimental. why we must chose one as a "standard track"? Being a >standard track can eliminate operators' misgiving? > >If the technology is really appropriate, I don't think the "experimental" >status would be a issue for the operators to adopt. Just let the operator >decide by themselves. > >I remembered in the meeting venue, Joel Halpern who chairs Karp and lisp >WG, suggested we publish both of them as experimental, and that was >exactly how they handle the similar situation in their WG. I think his >suggestion is reasonable to be considered. (To Joel: Pardon me if I >improperly quoted your comment, or I just misunderstood your suggestion >). > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Simon Perreault >> Sent: Tuesday, April 03, 2012 8:16 PM >> To: [email protected] >> Subject: Re: [Softwires] Path to move forward with 4rd 4rd-U as >>transparent >> as MAP-E >> >> On 2012-04-03 05:40, Ole Trøan wrote: >> > 1) MAP-E supports independence of IPv4 and IPv6 addressing. by using >>hub >> and spoke mode with a separate >> > mapping rule per subscriber. in this mode e.g only ports could be >> embedded in the address. this is not >> > possible in a translation solution like 4rd-U. >> >> This mode of operation was suggested last week during the SD-NAT >> presentation. There seemed to be consensus among operators that it was >> not practically feasible. >> >> > 2) a node inside the network will treat translated packets different >>from >> encapsulated ones. >> > e.g. for the purposes of counting or for applying features. for an >> encapsulated packet both the complete >> > IPv4 datagram and the IPv6 header is available, and different >>features >> can be applied to both. >> >> In practice, the contents of encapsulated packets are rarely inspected >> by firewalls and other such devices. >> >> >> IMHO at this point we should let the market decide. Publish both as >> experimental. Let's work on something else now. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >_______________________________________________ >Softwires mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/softwires
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
