Hi, MAP-T has been tested in CERNET2 and we have tested applications such as http, telnet, ssh，ftp, icmp echo request/reply, qq, skype, msn, video (for example: youku.com, xunlei.com, etc) without any problem.
Congxiao 2012/4/6 Lee, Yiu <[email protected]> > 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 > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
