Dear Maoke, Comments inline:
From: Maoke <[email protected]> Date: Mon, 9 Apr 2012 07:24:30 +0000 To: Sheng Jiang <[email protected]> Cc: "Yiu L. LEE" <[email protected]>, "Liubing (Leo)" <[email protected]>, Simon Perreault <[email protected]>, "[email protected]" <[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. [YL] I can live with both stay as draft format. When Remi proposed 4rd-u, what he saw was a way to use reverse-header to support encapsulation w/o encapsulation overhead. This is why he called it "Unified". However, this doesn't mean it must replace MAP-E/T. This recalls me when L2-MPLS started the work, we had BGP and LDP for signaling. In the end, we have RFC4761 and RFC4762. It isn't end of the world, is it? 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. [YL] I think we have at least one volunteer in the ML taking this job. Thanks Sheng Jiang. 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. [YL] Sorry for my lack of knowledge. Please explain how MAP isn't coupling address format and header mapping? 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. [YL] Again, MAP has started the work couple years earlier back to double-IVI. Thanks for the good work. 4rd-u only started in few months. All I asked is to give time to understand both protocols better. That's it. [YL] Last remark. MAP and 4rd-u both work inside the operator network, they are connected by IPv4 network, they don't need to interwork with each other, so incompatibility isn't a concern here. In theory, an operator can deploy 4rd-u in one test site and MAP in other test site to compare their good and bad. We do this all the time for other technologies, why when we come to MAP vs 4rd-u, we can't do something similar? 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
