Hello Qiong, From: Qiong <[email protected]<mailto:[email protected]>> Date: Sunday, 17 February 2013 03:03 To: Wojciech Dec <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Softwires] [softwire] #25: Maintain or remove MAP1:1 Mode?
Hi Woj, Please see inline. On Fri, Feb 15, 2013 at 5:03 PM, Wojciech Dec (wdec) <[email protected]<mailto:[email protected]>> wrote: It is my opinion that we've discussed this 1:1 mode many many times before, and at each time concluded that a) it is a natural characteristic of MAP ii) it would actually require *more text* (and complexity) to remove it. Sorry I can hardly find such conclusion. 1) In the current text, the PSID option is only used in this 1:1 mode which will have impact on both DHCPv6 server and CPE. And so? In any scheme where a port assignment is to be made a configuration component will be involved. 2) From the testing draft, there is a dedicated parameter "-X" to indicate no embedding EA-bits in IPv6 prefix which is not used in normal MAP-E/MAP-T. So for me, it is hard to say this 1:1 mode is a natural characteristic of MAP. The is an artifact of the implementation AFAIK. In fact we have successfully used a software version without –X to test the 1:1 mode. It's also worthwhile adding that other implementations never had a –X parameter, etc, and that in general implementers are free to design and write software as they wish. Long long time ago, we spent two days in Beijing Interim meeting to discuss what need to be covered in MAP, what's the motivation and requirement of each functional element, including Encapsulation, Translation, Hub&Sope and Mesh. That comes to be the draft-ietf-softwire-map-00. But now, 1:1 mode was just simply added without any discussion about the motivation, requirement in the working group, and not covered in stateless motivation draft either. It did raise confusion of why this is needed in MAP (two address sharing mechanisms in one solution), and how it should be used. So I suggest to reach consensus on motivation and requirement text first before processing 1:1 mode in MAP. Update: in Atlanta we discussed the technology (the chairs were present too). It was rather clear that 1:1 mode is inherent in MAP and the Lw46 solution. We also had a all-parties meeting in Ottawa on that topic, where a similar conclusion was reached. Thus, I'll continue to assert that 1:1 was possible in MAP all along (although not exemplified to start with). We come to the IETF to create standards that solve more than just point problems, and to discuss how we can do so in a manner that minimizes the number of solutions - I appreciate that you have a problem with that because your stance appears to indicate that you need a totally separate solution for a point problem. With all due respect, but taking on such a purely rhetorical point as justification is not really how to get a technical standard done IMO. For MAP-base draft, I do think removing 1:1 mode would help MAP to be a more cleaner stateless solution and easy understanding. We've been there before: Stateless doesn't exist. All solutions need configuration. But thanks anyway. It is now clear that what you are proposing is that MAP be technically described as not handling 1:1 mode. There appears to be 0 technical merit to that argument as far as I can tell. The only argument appears to be that you don't care about the problem, but rather about having prefer to a standalone solution draft. Regards, Woj.. Best wishes Qiong
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
