Peng, On 2012/06/25, at 12:06, Peng Wu wrote:
> Satoru, > > Mapping, binding, rule, state,call it whatever you want, essentially > it's the same thing: per-user IPv6 address<=>IPv4 address+port-set. > Or you are saying that this binding is purely static? > Static, right. --satoru > On Mon, Jun 25, 2012 at 10:27 AM, Satoru Matsushima > <[email protected]> wrote: >> Hi Yiu, >> >> No, that's a misunderstanding. >> Current MAP specify the case for ea-len is 'zero'. It is 'per-subscriber >> mapping' in stateless manner, not to introduce 'per-flow NAT binding' or >> 'per-subscriber state on demand'. >> >> cheers, >> --satoru >> >> On 2012/06/25, at 2:32, Lee, Yiu wrote: >> >>> Dear Satoru and MAP-DT >>> >>> I echo what Peng and Qiong said. When the WG agreed working on the >>> stateless solution, it was very clear stated that the solution would not >>> maintain states in the network. If the 1:1 mode changed this, this no >>> longer matched the requirements stated in the stateless motivation draft, >>> thus, it would disqualify MAP as a solution for the motivation draft. >>> >>> AFAIK, the MAP Design Team could propose a change, but such a dramatic >>> change by introducing states in the network would require WG approval. I >>> would like the chairs to clarify this. >>> >>> Thanks, >>> Yiu >>> >>> >>> On 6/24/12 12:21 PM, "Peng Wu" <[email protected]> wrote: >>> >>>> Hi Qiong, Satoru and all, >>>> >>>> I should thank Qiong for pointing this out. I gotta say I'm a bit shocked. >>>> If I understand the procedures of IETF correctly, a WG document should >>>> reflect the consensus of the WG. MAP is approved by the WG as a >>>> stateless solution. As a participator in Softwire, I didn't get the >>>> information anywhere that the MAP WG document would cover the >>>> so-called 1:1, in fact per-user stateful mode before it was released, >>>> not to say discuss in the WG. Don't the WG need to approve such big >>>> change anymore? >>>> >>>> Now let me provide my impression as an outsider of the MAP DT. You >>>> guys make great effort to build the solution, The address composition, >>>> the GMA algorithm, the different types of address mapping rules. >>>> should be quite difficult to pull together such sophisticated ideas. I >>>> guess that's what it takes to achieve the benifits of statelessness. >>>> And I admire that, bravo. Then, all of a sudden, you guys are saying, >>>> let's apply this sophisticated method to the different problem, by >>>> dropping quite some comlexity and twistting the mechanism a bit, seems >>>> it may work. Considering the problem are now solved in a more pure and >>>> clear way, I'm sorry but I CANNOT follow the logic here. >>>> >>>> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima >>>> <[email protected]> wrote: >>>>> Hi Qiong, >>>>> >>>>> I'm disagree with your opinion. >>>>> >>>>> 1. Recent changes in draft-ietf-softwire-map-00 has been discussed in >>>>> the DT. >>>>> 2. MAP just covers so called '1:1 mode' with most granular mapping rule >>>>> for CEs provisioning, which is as one of its characteristics. >>>>> 3. The motivation draft does not restrict that as you stated, just >>>>> 'assumed', it's neither 'MUST' nor 'SHOULD'. >>>>> >>>>> Best regards, >>>>> --satoru >>>>> >>>>> >>>>> On 2012/06/24, at 14:35, Qiong wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> As we all know, once an individual draft is adopted as a WG draft, it >>>>>> is owned by the whole WG, rather than just the editors. Just as Remi >>>>>> said, the normal procedure to follow is to reach WG consensus _before_ >>>>>> posting a newly edited version. >>>>>> >>>>>> From draft-mdt-softwire-mapping-address-and-port-03 to >>>>>> draft-ietf-softwire-map-00, there are several changes between them. In >>>>>> particular, the newly introduced "1:1 mode", which decouples IPv4 and >>>>>> IPv6 addressing, has never been discussed openly in the WG mailing >>>>>> list, or even in the MAP design team either. >>>>>> >>>>>> Actually, this "1:1 mode" is against the stateless-4v6-motivation >>>>>> draft. The motivation draft has clearly defines the "Stateless 4/6 >>>>>> solution" as follows: >>>>>> >>>>>> Stateless 4/6 solution denotes a solution which does not require any >>>>>> per-user state (see Section 2.3 of [RFC1958]) to be maintained by any >>>>>> IP address sharing function in the Service Provider's network. This >>>>>> category of solutions assumes a dependency between an IPv6 prefix and >>>>>> IPv4 address. >>>>>> >>>>>> AFAIK what the WG has adopted MAP related draft is >>>>>> draft-mdt-softwire-mapping-address-and-port-03, NOT >>>>>> draft-ietf-softwire-map-00. And the stateless solution should ³response >>>>>> to the solution motivation document² according to the Softwire charter. >>>>>> That means draft-ietf-softwire-map-00 IS NOT QUALIFIED to be a WG draft. >>>>>> >>>>>> We can all recall that our softwire WG has worked on stateless >>>>>> solutions for more than one and a half years, and we have achieved a >>>>>> lot of work which has been documented in charter, stateless motivation, >>>>>> 4rd-varients, MAP-03, etc. AFAIK all the authors have kept the basic >>>>>> "stateless" principle and the MAP design team is also working on it >>>>>> together to find a better algorithm, address format, etc. So it is >>>>>> really not appropriate to make such changes when MAP is adopted as a WG >>>>>> item in such a short time. >>>>>> >>>>>> From this perspective, draft-ietf-softwire-map-00 can only be regarded >>>>>> as draft-XX-softwire-mapping-address-and-port-04. It is not even the >>>>>> output of MAP design team. >>>>>> >>>>>> Best wishes >>>>>> >>>>>> ============================================== >>>>>> Qiong Sun >>>>>> China Telecom Beijing Research Institude >>>>>> >>>>>> >>>>>> Open source code: >>>>>> lightweight 4over6: http://sourceforge.net/projects/laft6/ >>>>>> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ >>>>>> =============================================== >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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
