Le 2012-04-09 à 12:16, Maoke a écrit : > > > 2012/4/9 Liubing (Leo) <[email protected]> > >fine. we'd love to see it out with good amount of data and good amount of > >feedback from testing operators. > > >if you invite me to test, i'd love to provide challenging scenarios. ;-) > > >but it doesn't mean we should postpone current process of standardization of > >MAP, because the result of 4rd-u is still unsure. - maoke > > > I’d love to see operators find proper mechanisms respectively according to > their own situations, rather than some mechanisms *out*. > > > joke. operators haven't know what the 4rd-u is.
This is disparaging for operator engineers who took the time to read the specification (not to speak about those who co-autrhored the specification!). > operators never make selection on things not belonging to its knowledge. come > on, believe me, as an engineer in an operator company, the real operators are > more conservative than me. ;-) > > > The transition mechanisms are developed for the operators, but in my > observation, the MAP hasn’t proved sufficiently for operators’ long-term > selection. So why we have to rush to a *stand track*? > > > it is only your observation and it is a different question. > you may argue that the MAP is not mature enough for the wg acceptance but the > wg is doing a consensus decision. Precisely, and people who attended MAP and 4rd presentations couldn't reach consensus. > on the other hand, as i pointed out, > even there is no MAP at all, i don't think 4rd-u now is at the time of > talking about wg acceptance. WKG acceptance of 4rd as experimental isn't a long term commitment. > may i suggest, as you have promised that you will code the stuff, to start > the coding work as soon as possible. i don't like to make out a testing list > but finally see nothing to test. thanks! Could you please at least describe, without waiting for anything else, the worst challenging scenario you have in mind? This is a way to make progress. Thanks, RD > > - maoke > > > > From: Maoke [mailto:[email protected]] > Sent: Monday, April 09, 2012 5:52 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 > > > 2012/4/9 Sheng Jiang <[email protected]> > > Without any objection to MAP, we just start to coding 4rd-u and help to > improve it. > > > fine. we'd love to see it out with good amount of data and good amount of > feedback from testing operators. if you invite me to test, i'd love to > provide challenging scenarios. ;-) but it doesn't mean we should postpone > current process of standardization of MAP, because the result of 4rd-u is > still unsure. - maoke > > > > Multiple transition mechanisms would co-exist in the world. Neither MAP nor > 4rd-U can replace 6rd and DS-Lite. There is no one-suit-all solution. > > > From: Maoke [mailto:[email protected]] > Sent: Monday, April 09, 2012 5:39 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 > > > > 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
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
