2012/4/9 Sheng Jiang <[email protected]> > Please allow me to clarify myself: I support both MAP and 4rd-u. > > > > MAP has been a good effort with many experts together in IPv4/IPv6 > transition area and has been proved by running code. It also need to > improve itself before being published as a RFC later. This process will > take several months. > > > > Personally, I think 4rd-u is a little bit behind MAP in maturity aspect > for now. But, it is only matter of time. The authors have agreed to remove > the architectural conflict, if there was any. We have offered to help on > the improvement by implementation. > > > > Giving time, both solution can be mature enough for operations. IETF does > not have to choose one by now. And, these two solutions are not necessary > to be a same pace. >
what if, giving time, people can be mature enough to identify 4rd-U is really a flawed donkorse? ;-) if the 4rd-u designers are so confident, why not do the real coding work first and then propose it as a replacement of MAP suite? i don't see any unfairness here. - maoke > > > 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
