Le 2012-04-09 à 09:56, Sheng Jiang a écrit : > ... > Giving time, both solution can be mature enough for operations. IETF does not > have to choose one by now.
+1 Besides, in view of the clear lack of WG consensus in Paris, that is the only fair approach at this stage. Regards, RD > And, these two solutions are not necessary to be a same pace. > > Best regards, > > Sheng > > From: Maoke [mailto:[email protected]] > Sent: Monday, April 09, 2012 3:24 PM > To: Sheng Jiang > Cc: Lee, Yiu; Liubing (Leo); Simon Perreault; [email protected] > Subject: Re: [Softwires] Path to move forward with 4rdŠ 4rd-U as transparent > as MAP-E > > hi Yiu and others, > > 1. "both published" does surely conflict with the design goal of 4rd-U > itself: > unification of multiple standards. politically speaking, the 4rd-u authors' > positition is now quite confusing. > > 2. operators surely need to choose IPv6 transition mechanisms but such a > choice > is based on their demand and understanding to the existing and > well-tested, > well-practiced building blocks. i don't think any operators are waiting > for > an option of choice they never see and never understand. and the "enough > technical supports" is now still "a check without signature". i do suggest > the 4rd-u authors and supporters say that after making something real. > > on the other hand, 4rd-u makes a tight coupling between the address format > and its own header mapping mechanism. this makes an operator unable to > have > different choices of transition mechanism as long as it chooses 4rd-u. if > you concern the choice of IPv6 transition mechanism, i do recommend MAP, > as > either encapsulation or translation is operatable with MAP address/port > mapping without difficulty. > > 3. surely MAP still has room of improvement but i don't think there are > architectural uncertainty as 4rd-U has. request on more testing data is > surely appreciated but please think it over again if it is a correct way > to require further data of a counterpart in order to defense a solution > without any data. > > 4. even there were no MAP at all, current level of 4rd-U is far premature to > be > talked about any working group acception. > > the authors and supporters will be appreciated if they talk about the > acception > after their coding and testing and refinement on the document according to > their > practical experiences, and understanding the problem again and again. > > thanks, > maoke > > 2012/4/9 Sheng Jiang <[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. > > We would like to see both solution published. So that, operators can choose > according to their own networks and preference. There are enormous number of > operators, who do not come to IETF meeting or do not participate in ML > either. They also need to choose IPv6 transition mechanisms. They should be > provided enough technical supports. That's the response of IETF, in our > understanding. > > > 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
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
