Subject: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

From: Qiong <[email-masked]>
Date: Sun, 24 Jun 2012 13:35:53 +0800

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/ *
===============================================

---

From: Satoru Matsushima <[email-masked]>
Date: Sun, 24 Jun 2012 15:00:22 +0900

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
> 
> lightweight 4over6: http://sourceforge.net/projects/laft6/
> PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/ 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Qi Sun <[email-masked]>
Date: Sun, 24 Jun 2012 16:52:34 +0800

Hi Satoru,

1. I don't know whether the new draft has been discussed in DT, but
has it achieved consensus within the DT?
what's more, this draft hasn't got the consensus in the softwires WG
where the mdt-map-03 draft was adopted as WG draft before it was
submitted.  l'm wondering how this
draft-XX-softwire-mapping-address-and-port-04 got adopted as a WG
draft.

2. From the draft, I can feel that this mode is NOT the kind with
other rules.  it is stated separately with others unnaturally.

3. AFAIK, stateless solutions are featured with decouple of IPv4 and
ipv6 addredssing, which leads to no states kept on the carrier side.
once you abandon the feature using so called  1:1 mode which has to
maitain state (no matter how you try to hide the fact),  MAP will
become neither total stateless nor stateful. this does no good to
promote MAP for further development.

BRs!

Qi Sun

On 6/24/12, Satoru Matsushima <[email-masked]> wrote:
> 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
>
>
>> 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.
>>
>> 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:
>>
>> 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.
>>
>> 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
>>

---

From: Qiong <[email-masked]>
Date: Sun, 24 Jun 2012 23:13:55 +0800

Hi Satoru,

Every solution has its solution space with respective application scenarios
as well as pros and cons.
The essence of stateless solution, which follows the stateless motivation
approved by the WG, is to achieve efficient address mapping by algorithmic
embedding part of IPv4 address+port set into IPv6 address/prefix, while the
essence of stateful solution is to maintain the subscriber-based state
on-demand. IPv4 address and IPv6 address is not coupled, and there is no
requirement on IPv6 addressing format. It is twisty to mix them together in
one document as in the current draft-ietf-softwire-map. It is not clear for
vendors to implement and for operators to deploy, and will lose the
features for both.

I'm not saying I'm against the work of stateless solutions, but it is
really not fair to just extend one solution arbitrarily to cover another
one without the permission from the WG and the authors. In particular,
lightweight 4over6 is a collaborative work of 15 co-authors for more than
one and a half years, including operators from China Telecom, Tsinghua,
Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and also
the vendors from Huawei, Juniper and Cisco.

Our WG or DT has never reached the consensus to have one unified document
for both stateful and stateless sotluion. And the motivation draft has
never been extended to include the stateful features as well. So unless we
reach the consensus first in the WG, we can then move forward with this
document.

Best wishes

On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima <
[email-masked]> wrote:

> 2. MAP just covers so called '1:1 mode' with most granular mapping rule
> for CEs provisioning, which is as one of its characteristics.
> 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.
> >
> addressing, has never been discussed openly in the WG mailing list, or even
> in the MAP design team either.
> >
> of solutions assumes a dependency between an IPv6 prefix and IPv4 address.
> >
> as draft-XX-softwire-mapping-address-and-port-04. It is not even the output
> of MAP design team.
> >
> > Best wishes
> >

-- 

Open source code:

---

From: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 00:21:02 +0800

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.

---

From: "Lee, Yiu" <[email-masked]>
Date: Sun, 24 Jun 2012 17:32:33 +0000

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-masked]> wrote:

>>>IPv6 addressing, has never been discussed openly in the WG mailing
>>>list, or even in the MAP design team either.
>>>
>>>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.
>>>
>>>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.
>>>
>>>as draft-XX-softwire-mapping-address-and-port-04. It is not even the
>>>output of MAP design team.
>>>
>>> Best wishes
>>>

---

From: xiechf01 <[email-masked]>
Date: Mon, 25 Jun 2012 07:47:55 +0800

I agree with Qiong, Peng and Yiu,  since this big change has never been discussed  in the WG,  it is inappropriate for MAP being accepted as WG document.  

Chongfeng

From: Lee, Yiu
Date: 2012-06-25 01:32
To: Peng Wu; Satoru Matsushima; [email-masked]; Yong Cui
CC: [email-masked]
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
Dear Satoru and MAP-DT

Thanks,
Yiu

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 10:55:36 +0900

Hi Qiong,

Thanks you to carefully express your thought. I understand that.

First point, let me answer for the question, 'Is MAP stateless or stateful', the answer is: "MAP is *not* stateful solution itself". It was discussed in the interim meeting in Beijing about 'per-subscriber mapping' could be one characteristic of MAP solution. It does not introduce 'per-flow NAT binding' or 'per-subscriber state on demand' on network side. As MAP specification, there is a case when ea-bits length indicates zero so that MAP needs explain this case and clearly define specification that's what we did.

Second, I don't have any intention to deprecate those who work hard for that solutions.  I didn't figure out that MAP possibly cover existing solutions untill you rise this point. Now I remember that 'multi-protocol socket v2.0', talked from the chair, which has been deeply engraved in my mind. I believe that it is right direction for the working group.

I agree on that we need discussion. That would be there's another choice to define in the case of ea-bits length indicates zero.

Best regards,
--satoru

On 2012/06/25, at 0:13, Qiong wrote:

> Hi Satoru,
> 
> Every solution has its solution space with respective application scenarios as well as pros and cons. 
> The essence of stateless solution, which follows the stateless motivation approved by the WG, is to achieve efficient address mapping by algorithmic embedding part of IPv4 address+port set into IPv6 address/prefix, while the essence of stateful solution is to maintain the subscriber-based state on-demand. IPv4 address and IPv6 address is not coupled, and there is no requirement on IPv6 addressing format. It is twisty to mix them together in one document as in the current draft-ietf-softwire-map. It is not clear for vendors to implement and for operators to deploy, and will lose the features for both.
> 
> I'm not saying I'm against the work of stateless solutions, but it is really not fair to just extend one solution arbitrarily to cover another one without the permission from the WG and the authors. In particular,  lightweight 4over6 is a collaborative work of 15 co-authors for more than one and a half years, including operators from China Telecom, Tsinghua, Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and  also the vendors from Huawei, Juniper and Cisco.
> 
> Our WG or DT has never reached the consensus to have one unified document for both stateful and stateless sotluion. And the motivation draft has never been extended to include the stateful features as well. So unless we reach the consensus first in the WG, we can then move forward with this document. 
> 
> Best wishes
> 
> On Sun, Jun 24, 2012 at 2:00 PM, Satoru Matsushima <[email-masked]> wrote:
> Hi Qiong,
>

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 11:27:44 +0900

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

---

From: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 11:06:18 +0800

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?

---

From: Maoke <[email-masked]>
Date: Mon, 25 Jun 2012 12:07:39 +0900

hi Satoru-san, Qiong, and all,

i think the current 1:1 mode text of the draft should be tuned or, it would
be better, to be removed.

technically, i expect MAP as a completely per-session, per-subscriber
stateless solution and therefore per-subscriber mapping rule is not
accepted. in theory, of course, it could be an extension mode of MAP
operation but, in practice, it makes the solution quite fuzzy, the code
quite heavy. we (me and my company) wouldn't like to have a standard where
supporting for both per-subscribe stateless and per-subscribe stateful
mappings should be done together within a monolithic implementation. we
support the lightweight 4over6 as an independent standard.

thanks and regards,
maoke

2012/6/25 Satoru Matsushima <[email-masked]>

> First point, let me answer for the question, 'Is MAP stateless or
> stateful', the answer is: "MAP is *not* stateful solution itself". It was
> discussed in the interim meeting in Beijing about 'per-subscriber mapping'
> could be one characteristic of MAP solution. It does not introduce
> 'per-flow NAT binding' or 'per-subscriber state on demand' on network side.
> As MAP specification, there is a case when ea-bits length indicates zero so
> that MAP needs explain this case and clearly define specification that's
> what we did.
>
> Second, I don't have any intention to deprecate those who work hard for
> that solutions.  I didn't figure out that MAP possibly cover existing
> solutions untill you rise this point. Now I remember that 'multi-protocol
> socket v2.0', talked from the chair, which has been deeply engraved in my
> mind. I believe that it is right direction for the working group.
>
> I agree on that we need discussion. That would be there's another choice
> to define in the case of ea-bits length indicates zero.
>
> Best regards,
> --satoru
>
>
> > The essence of stateless solution, which follows the stateless
> motivation approved by the WG, is to achieve efficient address mapping by
> algorithmic embedding part of IPv4 address+port set into IPv6
> address/prefix, while the essence of stateful solution is to maintain the
> subscriber-based state on-demand. IPv4 address and IPv6 address is not
> coupled, and there is no requirement on IPv6 addressing format. It is
> twisty to mix them together in one document as in the current
> draft-ietf-softwire-map. It is not clear for vendors to implement and for
> operators to deploy, and will lose the features for both.
> >
> Comcast, France telecom, Deutsche Telekom, Bouygues Telecom, etc., and
>  also the vendors from Huawei, Juniper and Cisco.
> >
> > Our WG or DT has never reached the consensus to have one unified
> document for both stateful and stateless sotluion. And the motivation draft
> has never been extended to include the stateful features as well. So unless
> we reach the consensus first in the WG, we can then move forward with this
> document.
> >
> > Best wishes
> >
> is owned by the whole WG, rather than just the editors. Just as Remi said,
> 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,
> 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: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 11:10:45 +0800

If I recall correctly, the Interim meeting dicussed the rationality of
per-subsriber stateful solutions ASIDE FROM the stateless solutions,
rather than " 'per-subscriber mapping' could be one characteristic of
MAP solution"

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 25 Jun 2012 03:40:40 +0000

Dear Satoru,

I do not understand how to create "per-subscriber mapping" in a stateless
manner. In the end, the BR must contain all mapping rules for all 1:1
subscribers. This is stateful to my understanding. Could you please
explain how not to maintain any mapping rule in BR to achieve this?

Thanks and regards,
Yiu

On 6/24/12 10:27 PM, "Satoru Matsushima" <[email-masked]>
wrote:

>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'.
>

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 12:45:04 +0900

Peng,

> Or you are saying that this binding is purely static?

Static, right.
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 12:47:34 +0900

Hi Yiu,

> explain how not to maintain any mapping rule in BR to achieve this?

This could be same operation with any other, configure FMRs into a map tunnel.
Nothing changed.

cheers,
--satoru

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 25 Jun 2012 03:50:42 +0000

Hi Satoru,

To me, this changes the stateless operation model. I respectfully disagree
your statement "Nothing changed".

Regards,
Yiu

---

From: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 13:13:14 +0800

+1. Exactly.

---

From: Qiong <[email-masked]>
Date: Mon, 25 Jun 2012 14:06:57 +0800

Hi Satoru,

Would you please point out in which presentation in the Beijing Interim
meeting illustrated "per-subscriber mapping" as one characteristic of MAP
solution? I recall which xiaohong presented was a stateful one.

Best wishes

Open source code:

---

From: "Qi Sun" <[email-masked]>
Date: Mon, 25 Jun 2012 14:51:46 +0800

Hi Satoru,

In MAP 1:1 mode, if there are 10000000 subscribers, there would be 10000000 MAP domains which a BR has to manage. I think that will create a huge mapping table on the BR, which is called 'state' that stateful solutions deal with.

Best Regards!

Qi Sun

From: Satoru Matsushima
Date: 2012-06-25 10:27
To: Lee, Yiu
CC: [email-masked]; Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
Hi Yiu,

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 15:59:08 +0900

Hi Qiong,

On 2012/06/25, at 15:06, Qiong wrote:

> Hi Satoru,
> 
> Would you please point out in which presentation in the Beijing Interim meeting illustrated "per-subscriber mapping" as one characteristic of MAP solution? I recall which xiaohong presented was a stateful one.

Please find it out on page 14 from following url:

http://www.ietf.org/proceedings/82/slides/softwire-2.pdf

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 16:01:58 +0900

Hi Qiong,

A MAP domain can have several/some/many mapping rules in the domain. How many is threshold for either stateless or stateful?

cheers,
--satoru

---

From: "Qi Sun" <[email-masked]>
Date: Mon, 25 Jun 2012 15:13:40 +0800

Hi Satoru,

What I emphasize is that with per-subscriber as a MAP domain (in 1:1 mode), there will be a huge mapping table for the BR to maintain. That's state on BR, which is different from non-1:1-mode.

Best Regards!

Qi Sun

From: Satoru Matsushima
Date: 2012-06-25 15:01
To: sunqi.csnet.thu
CC: Satoru Matsushima; softwires WG; Yong Cui; Lee, Yiu
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
Hi Qiong,

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 16:18:47 +0900

Hi Maoke-san,

On 2012/06/25, at 12:07, Maoke wrote:

> i think the current 1:1 mode text of the draft should be tuned or, it would be better, to be removed.
> 
> technically, i expect MAP as a completely per-session, per-subscriber stateless solution and therefore per-subscriber mapping rule is not accepted. in theory, of course, it could be an extension mode of MAP operation but, in practice, it makes the solution quite fuzzy, the code quite heavy. we (me and my company) wouldn't like to have a standard where supporting for both per-subscribe stateless and per-subscribe stateful mappings should be done together within a monolithic implementation. we support the lightweight 4over6 as an independent standard. 
> 

Hmm, I've read 'draft-cui-softwire-b4-translated-ds-lite' as you called 'lightweight 4over6'. LW46 for short, it looks me that MAP just provides LW46 a provisioning means which would be described in the section 5, or appendix section because following text described in section 5:

"Other optional alternatives to retrieve the public address and port-
 set also exist.  The specific protocol extensions are out of scope in
 this document, however some alternatives are mentioned in the Appendix
 section."

I think that MAP and LW46 is in relation of mutual complement. MAP doesn't obsolete LW46, and vice versa.
Thought?

cheers,
--satoru

---

From: Mark Townsley <[email-masked]>
Date: Mon, 25 Jun 2012 10:35:46 +0200

A "map domain" that supports a single customer is no more "heavy" than a LW46 mapping table entry that supports a single customer. You are comparing 10000000 of this vs. 10000000 of that, where this and that are effectively equal in terms of resources necessary for support. 

There are a lot of people working on this same problem space, attacking it from different directions. We are bound to run into one another, and that's what is happening here. The more we can do to collapse the alternatives into fewer things with fewer fancy names, the better. 

- Mark

---

From: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 16:37:52 +0800

Hi Satoru,

> http://www.ietf.org/proceedings/82/slides/softwire-2.pdf

I think that's not what Alain meant. If you look back and forth a bit,
you can see that:
B1 stands for per-subscriber stateufl/mapping/binding...
B2 stand for stateless Hub & Spoke (in MAP case, FMRs not provisoned to CE)
B3 stand for stateless Mesh (in MAP case, FMRs provisoned to CE)
The confusion comes from the use of per-subscriber in the slides.
It's not the sementic we took in this thread.

---

From: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 16:50:51 +0800

Satoru,

>  this document, however some alternatives are mentioned in the Appendix
Let me take a step further following your direction:
You are saying MAP is a provisioning mean in lw4over6. Then, what exactly?
With IPv4-IPv6 addressing independency, you proivde an IPv4 address
and port set, within another DHCPv6 option?
No BMR, No FMR, No embedding address. Look at what's left. how is this
even similar to MAP?

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 17:52:47 +0900

Hi Peng,

> It's not the sementic we took in this thread.

What's the differences from the semantics in this thread?
Since per-subscriber mapping operation should naturally be a hub-and-spoke means, it is just a case of stateless solution operation.

cheers,
--satoru

---

From: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 16:56:28 +0800

Mark,

On Mon, Jun 25, 2012 at 4:35 PM, Mark Townsley <[email-masked]> wrote:
>
> A "map domain" that supports a single customer is no more "heavy" than a
> LW46 mapping table entry that supports a single customer. You are comparing
> 10000000 of this vs. 10000000 of that, where this and that are effectively
> equal in terms of resources necessary for support.
I think the point is not comparison between the two. The point is MAP
loses its essential STATELESS feature in this case

>
> There are a lot of people working on this same problem space, attacking it
> from different directions. We are bound to run into one another, and that's
> what is happening here. The more we can do to collapse the alternatives into
> fewer things with fewer fancy names, the better.
One targets at the problem directly while the other not developed
originally for the case and later twisted to fit the problem space,
with loss of its essential feature.

> In MAP 1:1 mode, if there are 10000000 subscribers, there would be 10000000
> MAP domains which a BR has to manage. I think that will create a huge
> mapping table on the BR, which is called 'state' that stateful solutions
> deal with.
>
> Best Regards!
>
> ________________________________
> Qi Sun
>
> From: Satoru Matsushima
> Date: 2012-06-25 10:27
> To: Lee, Yiu

---

From: Qiong <[email-masked]>
Date: Mon, 25 Jun 2012 17:02:22 +0800

Hi Satoru,

It is not only about the exact number of mapping rules, but also the
dynamic feature of it.

For the number of mapping rules, it is obviously its objective to keep the
least number of mapping rules in stateless solution. See section 3.1.1 in
the motivation draft:

3.1.1.  Network Dimensioning
   Because no per-user state [RFC1958] is required, a stateless solution
   does not need to take into account the maximum number of simultaneous
   user-sessions and the maximum number of new user-sessions per second
   to dimension its networking equipment.  Like current network
   dimensioning practices, only considerations related to the customers
   number, traffic trends and the bandwidth usage need be taken into
   account.

Does it still fit for 1:1 mapping mode ?

On Mon, Jun 25, 2012 at 3:01 PM, Satoru Matsushima <
[email-masked]> wrote:

> Hi Qiong,
>
> A MAP domain can have several/some/many mapping rules in the domain. How
> many is threshold for either stateless or stateful?
>
> cheers,
> --satoru
>
> > In MAP 1:1 mode, if there are 10000000 subscribers, there would be
> 10000000 MAP domains which a BR has to manage. I think that will create a
> huge mapping table on the BR, which is called 'state' that stateful
> solutions deal with.
> >
> > Best Regards!
> >
> > Qi Sun
> >
> > From: Satoru Matsushima
> > Date: 2012-06-25 10:27
> > To: Lee, Yiu
> ³response
> motivation,

Open source code:

---

From: "Qi Sun" <[email-masked]>
Date: Mon, 25 Jun 2012 17:03:26 +0800

Hi Mark,

Please see inlines :)

Thank you !

Qi Sun

From: Mark Townsley
Date: 2012-06-25 16:35
To: sunqi.csnet.thu
CC: Satoru Matsushima; softwires WG; Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

[Qi Sun] Sorry for not making it clearly. As stated in my previous email, what I'm focusing on is NOT whether it's 'heavy' for the BR but BR will have to maintain a mapping table to manage this. That's to say, states are maintained here, which is not the feature of MAP.

[Qi Sun]  Actually, i'm not attacking anything but try to make things more specific. It's true that fewer fancy names the better, but when the mechanisms belong to different categories it's proper to keep the way they were.

- Mark

Hi Satoru,

Best Regards!

Qi Sun

From: Satoru Matsushima
Date: 2012-06-25 10:27
To: Lee, Yiu

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 18:05:02 +0900

Hi Peng,

> No BMR, No FMR, No embedding address. Look at what's left. how is this

Let's think that a CE provisioned with following BMR comes from MAP DHCPv6 options.

BMR:
 o Rule-ipv6-prefix  : {exact matched with CE's delegated prefix}
 o Rule-ipv4-prefix  : x.x.x.x/32
 o EA-length         : 0
 o Port-param option : {PSID/length}

This BMR could be a LW46 provisioning means.

cheers,
--satoru

---

From: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 17:08:07 +0800

> Since per-subscriber mapping operation should naturally be a hub-and-spoke means, it is just a case of stateless solution operation.

The discussion in this thread falls in the case of B1. Not the slide
you refered to (slide 14) at all.
I sincely suggest you look into the slides again, or look at my
summary in last mail, copied as following
=============================================
B1 stands for per-subscriber stateufl/mapping/binding...
B2 stand for stateless Hub & Spoke (in MAP case, FMRs not provisoned to CE)
B3 stand for stateless Mesh (in MAP case, FMRs provisoned to CE)
=============================================

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 18:12:16 +0900

Hi Peng,

> you refered to (slide 14) at all.

Not true. I discuss this thread in the context of B2.
Please read the slides, again.

cheers,
--satoru

---

From: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 17:22:51 +0800

This is ... ...

Just take a look at the title of slide 15: so you are for the
statement of "MAP is a solution of per subscriber mappings on CPE"?

On Mon, Jun 25, 2012 at 5:12 PM, Satoru Matsushima
<[email-masked]> wrote:tak

---

From: Tetsuya Murakami <[email-masked]>
Date: Mon, 25 Jun 2012 09:27:34 +0000

Hi Qi,

Even though there are a bunch of mapping rules, each mapping rule has no state. Since each mapping rules is set manually, BR does not maintain each mapping rule and just store them in its own memory. So, I am not sure why you are calling the "state" if there are a bunch of mapping rules. If you are saying that, do you assume how many entries should be existed in the table in order to call it to the "state". From the implementation perspective, even though there are 10000000 entries in the table, the problem is just how much memory is needed.

Thanks,
Tetsuya Murakami

On 2012/06/24, at 23:51, Qi Sun wrote:

Hi Satoru,

Best Regards!

From: Satoru Matsushima<mailto:[email-masked]>
Date: 2012-06-25 10:27
To: Lee, Yiu<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>; Yong Cui<mailto:[email-masked]>
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
Hi Yiu,

cheers,
--satoru

On 2012/06/25, at 2:32, Lee, Yiu wrote:

> On 6/24/12 12:21 PM, "Peng Wu" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> <[email-masked]<mailto:[email-masked]>> wrote:
>>> Hi Qiong,
>>>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 18:27:55 +0900

> statement of "MAP is a solution of per subscriber mappings on CPE"?

???
--satoru

---

From: Peng Wu <[email-masked]>
Date: Mon, 25 Jun 2012 17:34:00 +0800

Satoru,

> This BMR could be a LW46 provisioning means.

Again, all the information needed is the IPv4 address and port set.

1) The item like rule-ipv6-prefix is not needed at all.
2) Port set or PSID still needs extra provisioning (while in regular
MAP it's embedded in IPv6 address)

So why make it so difficult and obscure

---

From: Tetsuya Murakami <[email-masked]>
Date: Mon, 25 Jun 2012 09:36:28 +0000

Hi Qi,

In addition, our MAP implementation can handle such a bunch of entries. Of course, it requires enough memory in order to store all of them in its own memory. But I could not see any other problems except required memory size. Also, each entry is stored statically and so MAP implementation does not maintain the "state" for each entry.

Thanks,
Tetsuya Murakami

On 2012/06/25, at 2:27, Tetsuya Murakami wrote:

Hi Qi,

Thanks,
Tetsuya Murakami

Hi Satoru,

Best Regards!

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 18:46:18 +0900

Hi Peng,

> So why make it so difficult and obscure

Not difficult, easy business for CE which implemented MAP. Other difficulty in operator side in particular provisioning complex, that should be same with LW46. It also makes to complete MAP spec in the ea-len zero case.

cheers,
--satoru

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 25 Jun 2012 14:31:32 +0200

Some points for the record:

* lightweight 4over6 is not a WG draft nor does it have a monopoly on the
shape of final solutions.

* Discussion on what lw 4over6 actually solves is still expected.

* Nothing in the stateless solution (eg MAP) says that they have to be used
with stateful elements, or at what scale they are to be deployed. The fact
MAP devices can be used with stateful elements is a basic fact deriving
from the use of common IPv6 data-planes.

* Lw 4over6 is co-authored by one of the current and also one of the past
WG chairs...

-Woj.

---

From: "Qi Sun" <[email-masked]>
Date: Mon, 25 Jun 2012 21:01:29 +0800

Hi Testsuya,

1. If a bunch of entries forming a binding table is not "state", please clarify what is "state" ? And what is so called stateless?

2. You said the entries are "stored", do you mean once it is created it will be never changed? 
If the number of users keeps growing so that it exceeds the number of entries "stored", does BR add new entries? 
If users leave the network, should BR delete those unused entries for saving address resources ?

3. When there are packets inbound on Border Relay(BR), the BR has to look through the binding table for proper destination addresses. That is exactly what lw4over6 does.

Thank you!

Qi Sun

From: Tetsuya Murakami
Date: 2012-06-25 17:36
To: Tetsuya Murakami
CC: sunqi.csnet.thu; Satoru Matsushima; softwires WG; Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
Hi Qi, 

In addition, our MAP implementation can handle such a bunch of entries. Of course, it requires enough memory in order to store all of them in its own memory. But I could not see any other problems except required memory size. Also, each entry is stored statically and so MAP implementation does not maintain the "state" for each entry.
[Qi Sun] If a bunch of entries forming a mapping table is not "state", please clarify what is "state" ? And what is so called stateless?
[Qi Sun] You said the entries are "stored", do you mean once it is created it will be never changed? 

Thanks,
Tetsuya Murakami

Hi Qi, 

Thanks,
Tetsuya Murakami 

Hi Satoru,

Best Regards!

Qi Sun

From: Satoru Matsushima
Date: 2012-06-25 10:27
To: Lee, Yiu

cheers,
--satoru

---

From: "Jiang Dong" <[email-masked]>
Date: Mon, 25 Jun 2012 21:15:59 +0800

Hi, Satoru,

see in lines.

Regards!
Jiang Dong

From: Satoru Matsushima
Date: 2012-06-25 17:46
To: Peng Wu
CC: softwires; Yong Cui

[DJ] In this case, for the MAP draft, each CE only need to know the IPv6 address of BR, and BR needs mapping rules for every CE; for the lightweight4over6, which has been persistently developed for about two years by a large number of experts, each TI also need to know the IPv6 address of TC, and TC needs to maintain the per-subscriber mapping for each TI. I really cannot find what's the difference. Could you please tell me how "stateless" comes in the 1:1 mode of MAP draft? And if the number of mapping rules is proportional to the number of subscribers, I will then confused by the meaning of stateless.
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: "Qi Sun" <[email-masked]>
Date: Mon, 25 Jun 2012 21:30:55 +0800

Hi Satoru, 

As you said, the draft-ietf-softwire-map-00 (actually the draft-XX-softwire-mapping-address-and-port-04) has been discussed in the DT. Any consensus has been achieved among within the DT? And has the softwire working group adopted all the changes you have put in the "new" MAP draft?

Thank you!

Qi Sun

From: Satoru Matsushima
Date: 2012-06-24 14:00
To: Qiong
CC: softwires; Yong Cui

Best regards,
--satoru

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 Jun 2012 09:39:50 -0400

This appears to mix different kinds of state.
In particular, with regard to state in network resident boxes, there can be:
General state covering all subscribers;
Per subscriber state provisioned state;
Per subscriber dynamic, but not flow specific state;
per flow state.

All are state.
The first is clearly permitted.
The fourth is clearly not permitted in a "stateless" solution.
Some descriptions of "stateless" have allowed for the middle two, while 
others have prohibited it.  I have no opinion on what the WG "agreement" 
is on the scoping.  But we need to be careful about what we mean about 
"state".

Yours,
Joel

On 6/25/2012 2:51 AM, Qi Sun wrote:
> 10000000 MAP domains which a BR has to manage. I think that will create
> a huge mapping table on the BR, which is called 'state' that stateful
> solutions deal with.
> Best Regards!
> Qi Sun

---

From: Qiong <[email-masked]>
Date: Mon, 25 Jun 2012 22:05:41 +0800

Hi Woj,

I can not agree with your points. Here is my points:

* Lightweight 4over6 is a collaborative work of 15 co-authors for more than
one and a half years, including  China Telecom, Tsinghua, Comcast, France
telecom, Deutsche Telekom, Bouygues Telecom, Freebits, etc., and also the
vendors from Huawei, Juniper and Cisco.  It has been presented in Beijing
Interim meeting, Taipei meeting, and Pairs, and demoed in IETF 81th.

* The motivation/senario which lw 4over6 actually solves has been discussed
several times, and it has been approved as an valueable requirement in the
WG. It belongs to per-subscriber stateful and per-session stateless
solution space.

* Our lw4over6 group are doing the actual work all the time around. We have
improved our draft serveral times according to the WG decision, implemented
the running code (we have also published it recently for the sake of the
community), taken the field trial in China. All these tests have been
proved to be a success.

* Our VP has announced publicly on 2012 world IPv6 launch day that China
Telecom, which has more than 70 million broandband access customers, will
use lw4over6 as a major transition solution. As the first few operators who
are truely facing such a great pressure IPv4 address shortage problem in
the world, we really find lw4over6 is a very efficient way to solve our
problem. It is clean, easy to manage and efficient, and we are doing
seriously for the sake of the whole community.

* Lightweight 4over6 itself is simple, easy to understand and consistent.
The flexible addressing feature has brought us a lot of benifits including
network management, development and future usage. It can solve both the
dynamic mode of IPv4/IPv6 address mapping on-demand, and explicit
pre-determined mapping. And it has also improved the scalability problem of
traditional CGN to a great extend.

* For operators who only need stateful solutions do not need to deploy a
huge "heavy" solution to include both stateful and stateless features. It
is not only useless, but will also enlarge the possibility of
troubleshooting.

Best wishes
Qiong

On Mon, Jun 25, 2012 at 8:31 PM, Wojciech Dec <[email-masked]> wrote:

> * Nothing in the stateless solution (eg MAP) says that they have to be
> used with stateful elements, or at what scale they are to be deployed. The
> fact MAP devices can be used with stateful elements is a basic fact
> deriving from the use of common IPv6 data-planes.
>

Open source code:

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 25 Jun 2012 16:24:44 +0200

Hi,

taking a step back to discuss some items in more detail, and hopefully move
this discussion forward:

1. Domain size
The MAP architecture does not prescribe the size of a domain, and neither
does it prescribe the number of rules to be used. There is nothing in the
technology, except vendor implementation limits or practical sense (or
both), to prevent MAP domains from defining 1 domain = 1 CPE. This was a
day 1 characteristic of MAP drafts.
Choosing to deploy or implement MAP with a configuration supporting 1 rule,
100 rules or 100k rules or domains is a vendor's and/or operator's choice.
Nobody is stating that deployment is to be limited to X rules, nor that a
near infinite number of rules is reasonable. These are general points that
apply to DS-lite state as well as the "Light Weight 4 over 6" or "stateless
deterministic NAT", and pretty much any technology for that matter.

2. Stateless DOES NOT mean configuration-less
There appears to be confusion between the concept of stateless and
configuration-less. MAP domains are based on configured rules, that are
provisioned/applied through means that are currently outside the scope of
Softwire drafts - this is configuration state, and this was and continues
to be a characteristic of MAP.
Further more, unlike some of the other proposals, MAP allows to optimize
the amount of configuration needed in cases where this is viable. In other
words, MAP does NOT exclusively force 1:1 rule configuration, but also
allows N:1.

3. Stateless has no data plane induced state
A major difference between stateless (eg MAP) and stateful (eg Carrier
Grade NAT44/Ds-Lite) solutions is that the latter are characterised by
dynamic core node forwarding state that is directly driven by user
data-plane traffic (eg new IP flows). MAP does not rely on such dynamic
state, never did.

4. No change of MAP spec
The updated MAP draft does not change the MAP architecture nor its
technical underpinnings. In fact there are no changes, bar editorial to the
normative parts of MAP, something that is proven by existing
implementations prior to this draft supporting the current draft. A few
individuals appear to object to new descriptive text which highlights the
usage of MAP, eg in 1:1. Removing that text will not change the matter that
MAP allows such usage. Prohibiting such use by specification would actually
require a spec change, besides being unreasonable.

5. What is the problem?
We're  pleased to see a growing understanding of MAP's applicability to
solve problems, incl v4-v6 address independence, when needed. Given that
the emails on this thread do not appear to bring forward any technical
issues with the MAP solution, could we know WHY we need other solutions to
the problem, or what is the problem that remains to be solved?

Taking the liberty to speak on behalf of the other MAP authors, I would
like to say that we all remain open for collaboration with all WG members
in terms of arriving at a minimal set of reasonable solutions that solve
problems that the community cares about. We also trust that our renewed WG
leadership will finally help us all in getting there.

Regards,
Woj.

On 25 June 2012 08:51, Qi Sun <[email-masked]> wrote:

> **
> ------------------------------
> Qi Sun
>
>  *From:* Satoru Matsushima <[email-masked]>
> *Date:* 2012-06-25 10:27
> *To:* Lee, Yiu <[email-masked]>
> *CC:* [email-masked]; Yong Cui <[email-masked]>
> *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT
> reflect the consensus from the WG
>  Hi Yiu,
>

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 25 Jun 2012 23:48:33 +0900

+1.
It all covers what I argued in the long thread just on today, thanks Woj.

cheers,
--satoru

On 2012/06/25, at 23:24, Wojciech Dec wrote:

> Hi,
> 
> taking a step back to discuss some items in more detail, and hopefully move this discussion forward:
> 
> 1. Domain size
> The MAP architecture does not prescribe the size of a domain, and neither does it prescribe the number of rules to be used. There is nothing in the technology, except vendor implementation limits or practical sense (or both), to prevent MAP domains from defining 1 domain = 1 CPE. This was a day 1 characteristic of MAP drafts. 
> Choosing to deploy or implement MAP with a configuration supporting 1 rule, 100 rules or 100k rules or domains is a vendor's and/or operator's choice. Nobody is stating that deployment is to be limited to X rules, nor that a near infinite number of rules is reasonable. These are general points that apply to DS-lite state as well as the "Light Weight 4 over 6" or "stateless deterministic NAT", and pretty much any technology for that matter.
> 
> There appears to be confusion between the concept of stateless and configuration-less. MAP domains are based on configured rules, that are provisioned/applied through means that are currently outside the scope of Softwire drafts - this is configuration state, and this was and continues to be a characteristic of MAP.
> Further more, unlike some of the other proposals, MAP allows to optimize the amount of configuration needed in cases where this is viable. In other words, MAP does NOT exclusively force 1:1 rule configuration, but also allows N:1. 
> 
> A major difference between stateless (eg MAP) and stateful (eg Carrier Grade NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic core node forwarding state that is directly driven by user data-plane traffic (eg new IP flows). MAP does not rely on such dynamic state, never did.
> 
> 4. No change of MAP spec
> The updated MAP draft does not change the MAP architecture nor its technical underpinnings. In fact there are no changes, bar editorial to the normative parts of MAP, something that is proven by existing implementations prior to this draft supporting the current draft. A few individuals appear to object to new descriptive text which highlights the usage of MAP, eg in 1:1. Removing that text will not change the matter that MAP allows such usage. Prohibiting such use by specification would actually require a spec change, besides being unreasonable.
> 
> 5. What is the problem?
> We're  pleased to see a growing understanding of MAP's applicability to solve problems, incl v4-v6 address independence, when needed. Given that the emails on this thread do not appear to bring forward any technical issues with the MAP solution, could we know WHY we need other solutions to the problem, or what is the problem that remains to be solved? 
> 
> Taking the liberty to speak on behalf of the other MAP authors, I would like to say that we all remain open for collaboration with all WG members in terms of arriving at a minimal set of reasonable solutions that solve problems that the community cares about. We also trust that our renewed WG leadership will finally help us all in getting there.
> 
> Regards,
> Woj.
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Jun 2012 17:28:42 +0200

2012-06-25 à 16:24, Wojciech Dec:
...
> The updated MAP draft does not change the MAP architecture nor its technical underpinnings. In fact there are no changes, bar editorial to the normative parts of MAP,

Having asked several times for a list of substantial evolutions from previous MAP drafts, with their justifications, and having received no answer, I see this statement as an indirect but first answer.

But it doesn't seem acceptable (*):
- AFAIK, the added 5th parameter of basic mapping rules is more than editorial
- I didn't find the equivalent of the following sentence in previous drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in the 1:1 case, and with no IPv4 address and port range configured by other  means, MUST disable its NAT44 functionality."

=> A carefully studied list of substantial changes MAP supporters have found appropriate after the Paris meeting remains to be due.

> something that is proven by existing implementations prior to this draft supporting the current draft.

Please understand that your stating that some tests (for which we don't have detailed reports) should be considered a proof that what you say is true, is difficult to accept. 
Especially if what you say seems contradicted by a verifiable fact (see (*) above).

RD

---

From: Tetsuya Murakami <[email-masked]>
Date: Mon, 25 Jun 2012 22:50:56 +0000

+1.

In fact, we have already done the implementation prior to the current MAP draft. But there is no change in our implementation in order to support the current draft. In addition, our implementation has no limitation for the number of mapping rules. It depends on the available memory size only. So, our implementation can allow 1:1 as well as N:1.

Thanks,
Tetsuya Murakami

On 2012/06/25, at 7:24, Wojciech Dec wrote:

Hi,

1. Domain size

4. No change of MAP spec

5. What is the problem?

Regards,
Woj.

On 25 June 2012 08:51, Qi Sun <[email-masked]<mailto:[email-masked]>> wrote:
Hi Satoru,

Best Regards!

Date: 2012-06-25 10<tel:2012-06-25%C2%A010>:27

cheers,
--satoru

---

From: Peng Wu <[email-masked]>
Date: Tue, 26 Jun 2012 11:34:46 +0800

Hi Joel,

Thanks for the clarification. Fully agree with the 4 types.

Two additional comments:
1. From implementation view, the 2nd and the 3rd are more close to the
4th because there are binding table lookup procedure in data plane,
while the 1st depends on algorithmic address calculation essentially.
Some may argue that there are mutliple rules even in the 1st case, but
that's a specific feature in IPv4-over-IPv6 scenario with address
sharing demand, only because we want to include port set information
into IPv6 address beside the IPv4 address and there may be not enough
bits in IPv6 address. Generally this is not a necessary feature for
pure stateless solution.(take 6RD and SIIT as example)
2. In this specific context, I quote what is the defined in the
stateless  motivation
draft(http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivation/):
" Stateless 4/6 solution  (or stateless solution in short): 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."

On Mon, Jun 25, 2012 at 9:39 PM, Joel M. Halpern <[email-masked]> wrote:
> others have prohibited it.  I have no opinion on what the WG "agreement" is
> on the scoping.  But we need to be careful about what we mean about "state".
>
> Yours,
> Joel
>
>

---

From: Peng Wu <[email-masked]>
Date: Tue, 26 Jun 2012 12:07:35 +0800

Woj,

On Mon, Jun 25, 2012 at 10:24 PM, Wojciech Dec <[email-masked]> wrote:
> both), to prevent MAP domains from defining 1 domain = 1 CPE. This was a day
> 1 characteristic of MAP drafts.
Yes from the theoretical view you could. But that's not the exact 1:1
mode the "ietf-map-00" described. You have to change the specification
and twist the mechanism definiation to particularly support the 1:1
mode.

> Softwire drafts - this is configuration state, and this was and continues to
> be a characteristic of MAP.
If you have  per-user specific configuration, that definitely changes
the operation model.

> Further more, unlike some of the other proposals, MAP allows to optimize the
> amount of configuration needed in cases where this is viable. In other
That's not what is discussed in this thread at all...
> A major difference between stateless (eg MAP) and stateful (eg Carrier Grade
> NAT44/Ds-Lite) solutions is that the latter are characterised by dynamic
> core node forwarding state that is directly driven by user data-plane
> traffic (eg new IP flows). MAP does not rely on such dynamic state, never
> did.
I think you only mean per-session stateful. For per-user stateful
mechanisms, you run the provisioning process to avoid state creating
from the data plane. That's one of the essential design goals and
benifits of the per-user stateful mechanisms and reflected in
lw4over6.

>
> 4. No change of MAP spec
> The updated MAP draft does not change the MAP architecture nor its technical
> underpinnings. In fact there are no changes, bar editorial to the normative
> parts of MAP, something that is proven by existing implementations prior to
> this draft supporting the current draft. A few individuals appear to object
> to new descriptive text which highlights the usage of MAP, eg in 1:1.
> Removing that text will not change the matter that MAP allows such usage.
> Prohibiting such use by specification would actually require a spec change,
> besides being unreasonable.
Sorry, no. You need to change specifications, and you need to twist
the definations of the terminology.
For example, you need to explicitly provisio the port set information,
which is not the usual case at all.

> solve problems, incl v4-v6 address independence, when needed. Given that the
> emails on this thread do not appear to bring forward any technical issues
> with the MAP solution, could we know WHY we need other solutions to the
> problem, or what is the problem that remains to be solved?
The problem is that there are apparently three types of solutions with
perspective application scenarios, while the MAP solution, originally
strongly customized for the pure stateless scenario, is now twisting
itself in a somehow weired way, dropping the essential feature of
statelessness, to include the per-user state/mapping scenario which
can be solved by a more pure and clear solution.

> Taking the liberty to speak on behalf of the other MAP authors, I would like
> to say that we all remain open for collaboration with all WG members in
> terms of arriving at a minimal set of reasonable solutions that solve
No objection to MAP at all, AS LONG AS  it follows the original,
suitable problem space which it is expected to developed for.

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Jun 2012 08:04:05 +0200

On 25 June 2012 17:28, Rémi Després <[email-masked]> wrote:

> normative parts of MAP,
> Having asked several times for a list of substantial evolutions from
> previous MAP drafts, with their justifications, and having received no
> answer, I see this statement as an indirect but first answer.
>

Woj> You were provided with an answer (pls see Ole's mail).

> - AFAIK, the added 5th parameter of basic mapping rules is more than

Woj> Please indicate what the new parameter in your opinion is.

- I didn't find the equivalent of the following sentence in previous
> drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in the
> 1:1 case, and with no IPv4 address and port range configured by other
>  means, MUST disable its NAT44 functionality."
>

Woj> Well, perhaps you would like to suggest what the CPE should do in the
case the CPE is issued with a default mapping rule, ie a default route in
map terms, and the absence of an assigned IPv4 address or other parameters
(BMR). The above appears to be reasonable behaviour.

>
> => A carefully studied list of substantial changes MAP supporters have
> found appropriate after the Paris meeting remains to be due.
>

Woj> Take it from the other people who have done implementations,
technically there are no changes.

-Woj.

> Please understand that your stating that some tests (for which we don't
> have detailed reports) should be considered a proof that what you say is
> true, is difficult to accept.

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Jun 2012 08:27:20 +0200

Hi,

IMO The MAP solution fullfills most, if not all of the points in the
stateless motivations draft. The fact that it can do more, or can be used
differently doesn't alter the solution.
Now, it would appear that you're arbitrarily trying to make sure that MAP
does not solve a problem you care about. This would require a change to the
MAP spec, and all it's predecessors, and also implementations which pre
date this draft.
It also raises the question of what should the solution to this problem,
which you appear to exclusively intend to be "another draft" ( that likely
happens to be your draft, but that is probably just a mere coincidence).
If the WG wants multiple solutions to the same problem, that's for the WG
to decide based on some rational argument. Breaking or changing a solution
just so that another solution can be given "exclusivity" to some problem
solution seems not rational.

The argument below, and it's a repeat of what you've stated earlier, does
not appear to be technically motivated. I would like to bring the
discussion to a technical level, but with you continuing to voice rhetoric
and not addressing the key question of what is the technical problem, it
appears difficult to proceed.

Regards,
Woj.

On 24 June 2012 07:35, Qiong <[email-masked]> wrote:

> 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

---

From: Qi Sun <[email-masked]>
Date: Tue, 26 Jun 2012 14:37:46 +0800

+1 support.
I respect what the MAP authors have worked on. But besides what Peng has
said, could you clarify where the so called "ietf"-map-00 achieves
consensus?

Qi Sun

On Tue, Jun 26, 2012 at 12:07 PM, Peng Wu <[email-masked]> wrote:

> the
> Grade
> technical
> the
> like

---

From: "Jiang Dong" <[email-masked]>
Date: Tue, 26 Jun 2012 14:49:00 +0800

Hi, Peng,

I totally agree with you.

AFAIK, the originally MAP draft is designed to solve the stateless scenarios in a IPv4 info embedded way. Now one day, the 1:1 mode was suddenly added by setting the EA bits to zero without any consent from the WG, which also abandoned the essence of original MAP.

Since I cannot find any words in earlier MAP drafts talking about 1:1 mode, what I can imagine is that the two years hard works by the real 1:1 mapping guys are ignored  in the new MAP draft.

Best Regards!
Jiang Dong

From: Peng Wu
Date: 2012-06-26 12:07
To: Wojciech Dec
CC: softwires WG; Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG
Woj,

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Jun 2012 09:13:01 +0200

> Woj> You were provided with an answer (pls see Ole's mail).

Could you please indicate which one?

> Woj> Please indicate what the new parameter in your opinion is.

In Section 5, "Forwarding mode" has become a BMR 5th parameter. 
In Section 5 of the mdt draft of january 30, there were only 4 BMR parameter.

Anything missed?

> - I didn't find the equivalent of the following sentence in previous drafts: "A MAP-E CE provisioned with only a Default Mapping Rule, as in the 1:1 case, and with no IPv4 address and port range co…

Is there such an equivalent?
Please answer (not answering the question isn't a way to eliminate it).

> Woj> Well, perhaps you would like to suggest what the CPE should do in the case the CPE is issued with a default mapping rule, ie a default route in map terms, and the absence of an assigned IPv4 address or other parameters (BMR). The above appears to be reasonable behaviour.
> 
> Woj> Take it from the other people who have done implementations, technically there are no changes.

In their implementation, maybe, but we talk about the specification.

RD

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Jun 2012 09:37:12 +0200

> In Section 5 of the mdt draft of january 30, there were only 4 BMR

Ok, so fair point. MAP-E and -T have been merged in the draft, based on
previous feedback from the WG incl discussions at the last meeting. We
thought having less drafts is more as was discussed at the last meeting.
The updated draft also highlights how much commonality there is.
We're welcome to suggestions on how to provide information on which
transport mode to use, or if the merger is no desired.

> Please answer (not answering the question isn't a way to eliminate it).

Equivalent of what?
Note: I asked you how you would propose dealing with the DMR but no BMR
corner case, and await your proposal..

-Woj.

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Jun 2012 10:37:16 +0200

...
> Could you please indicate which one?

Since you claim there has been an answer, and suggest I find it, I suppose you can find it yourself.
=> Please answer (or implicitly acknowledge that the list of MAP substantial evolutions is still awaited).

> Ok, so fair point. MAP-E and -T have been merged in the draft, based on previous feedback from the WG incl discussions at the last meeting. We thought having less drafts is more as was discussed at the last meeting. The updated draft also highlights how much commonality there is.

- A parameter PER DOMAIN was an obvious result of a merger.
- But a parameter PER RULE is a significant novelty.
OK?

> We're welcome to suggestions on how to provide information on which transport mode to use, or if the merger is no desired. 
> 

Is there in previous drafts the sentence above (or an equivalent) "A MAP-E CE... MUST disable its NAT44 functionality."? 
- If yes, please indicate where.
- If not, IT IS an evolution, to be identified as such.

> Note: I asked you how you would propose dealing with the DMR but no BMR corner case, and await your proposal..  

- In the 4rd draft, appendix D, there is a deployment example with only on mapping rule (the BR mapping rule, AKA the DMR in your MAP draft).
- If this isn't sufficient to answer your concern, please point to the mail in which you asked the unanswered question. 
 
Thanks,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 26 Jun 2012 10:50:55 +0200

On 26 June 2012 10:37, Rémi Després <[email-masked]> wrote:

> => Please answer (or implicitly acknowledge that the list of MAP
> substantial evolutions is still awaited).
>

http://www.ietf.org/mail-archive/web/softwires/current/msg04358.html
It's a short list :
- MAP-E and MAP-T drafts have been merged.
- Handling of the corner cases regarding DMR but no BMR added
- Non normative text regarding use (eg backwards compatibility) added.

> That was not intended, and appears to be a genuine mistake in draft-00.
Thanks for spotting.
It is a parameter per domain, as discussed on the design team alias.

-Woj.

> Is there in previous drafts the sentence above (or an equivalent) "A MAP-E
> CE... MUST disable its NAT44 functionality."?
> - In the 4rd draft, appendix D, there is a deployment example with only on
> mapping rule (the BR mapping rule, AKA the DMR in your MAP draft).
> - If this isn't sufficient to answer your concern, please point to the
> mail in which you asked the unanswered question.
>
> Thanks,
> RD
>
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Jun 2012 11:53:58 +0200

> http://www.ietf.org/mail-archive/web/softwires/current/msg04358.html

Sorry, but I am lost!
This reference is that of my query, not that of an answer by Ole.

> - Handling of the corner cases regarding DMR but no BMR added

An explanation on this point would be appreciated.
Which sentences of the draft deal with this?

> - Non normative text regarding use (eg backwards compatibility) added.

A less "short" list has yet to be made. It should include AFAIK:
- 5th DMR parameter addition (as long as the deletion you suggest below hasn't been discussed an approved in the WG)
- ability to disable NAT functionality (which has a normative MUST in the draft)

> That was not intended, and appears to be a genuine mistake in draft-00. Thanks for spotting.

The specification is AFAIK viable with this 5th parameter, and some may find it useful. 
Since it is now a WG matter, individuals who would like to delete it from the specification should propose it on the mailing list. 
(FWIW, I have personally no objection to its deletion).

RD

> - If this isn't sufficient to answer your concern, please point to the mail in which you asked the unanswered question. 

Subject closed, I suppose.

---

From: Leaf yeh <[email-masked]>
Date: Tue, 26 Jun 2012 11:07:32 +0000

RD - The specification is AFAIK viable with this 5th parameter, and some may find it useful.
Since it is now a WG matter, individuals who would like to delete it from the specification should propose it on the mailing list. 
(FWIW, I have personally no objection to its deletion).

I suggested one code for the forwarding mode (mesh or H&S) in BMR on the MDT ML before, because I supposed MAP-base intended to support the mode of Hub&Spoke.

Best Regards,
Leaf

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: Tuesday, June 26, 2012 5:54 PM
To: Wojciech Dec
Cc: softwires WG; Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

Sorry, but I am lost!

It's a short list : 

Anything missed?

RD

-Woj.

Equivalent of what?

 
Thanks,
RD

---

From: Leaf yeh <[email-masked]>
Date: Tue, 26 Jun 2012 11:27:16 +0000

Satoru - Let's think that a CE provisioned with following BMR comes from MAP DHCPv6 options.
BMR:

If the intention is only for the independence provision of IPv4 address assignment and IPv6 prefix delegation, I guess we could also think the alternative scenario that CE provisioned with following BMR comes from MAP DHCPv6 options.

BMR:
 o Rule-ipv6-prefix  : the length of Rule-ipv6-prefix + PSID length = the length of CE's IPv6 delegated prefix
 o Rule-ipv4-prefix  : x.x.x.x/32
 o EA-length       : PSID length

That means PSID still be embedded in the CE's IPv6 delegated prefix.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Satoru Matsushima
Sent: Monday, June 25, 2012 5:05 PM
To: Peng Wu
Cc: [email-masked]; Yong Cui
Subject: Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG

Hi Peng,

BMR:

cheers,
--satoru

---

From: Simon Perreault <[email-masked]>
Date: Tue, 26 Jun 2012 09:58:03 -0400

> It is a parameter per domain, as discussed on the design team alias.

Now that MAP is a softwires WG item, wouldn't it be best for all to move 
MAP discussions to the softwires mailing list?

Thanks,
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

---

From: Leaf yeh <[email-masked]>
Date: Wed, 27 Jun 2012 01:56:54 +0000

+1 for draft-ietf-softwire-map-00

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Tuesday, June 26, 2012 9:58 PM
To: [email-masked]
Subject: [Softwires] MAP design team [Was: Re: [Softwire] draft-ietf-softwire-map-00 does NOT reflect the consensus from the WG]

Thanks,
Simon

---

From: Qiong <[email-masked]>
Date: Thu, 28 Jun 2012 09:01:41 +0800

Hi Tetsuya,

With regard to implementaion, what did you configure in BR ?

In the specification, it says the BR and CE MUST be configured with the
following MAP elements.
o  The End-User IPv6 prefix (Part of the normal IPv6 provisioning).
o  The Basic Mapping Rule and optionally the Forwarding Mapping Rules
o  The Default Mapping Rule with the BR IPv6 prefix or address
o  Hub and spoke mode or Mesh mode.

Did you configure PSID explicitly ?

If yes, the implementation does not consistent with the specification. If
not, it can not been applied to the so-called 1:1 mode.

Best wishes
Qiong

On Tue, Jun 26, 2012 at 6:50 AM, Tetsuya Murakami <
[email-masked]> wrote:

>  +1.
>
>  In fact, we have already done the implementation prior to the current
> MAP draft. But there is no change in our implementation in order to support
> the current draft. In addition, our implementation has no limitation for
> the number of mapping rules. It depends on the available memory size only.
> So, our implementation can allow 1:1 as well as N:1.
>
>  Thanks,
> Tetsuya Murakami
>
> Choosing to deploy or implement MAP with a configuration supporting 1
> rule, 100 rules or 100k rules or domains is a vendor's and/or operator's
> choice. Nobody is stating that deployment is to be limited to X rules, nor
> that a near infinite number of rules is reasonable. These are general
> points that apply to DS-lite state as well as the "Light Weight 4 over 6"
> or "stateless deterministic NAT", and pretty much any technology for that
> matter.
>
>>  *Subject:* Re: [Softwires] [Softwire] draft-ietf-softwire-map-00 does
>> NOT reflect the consensus from the WG
>>    Hi Yiu,
>>

Open source code:

---

From: Qiong <[email-masked]>
Date: Thu, 28 Jun 2012 10:08:40 +0800

Hi Tetsuya,

Well, then you mean this implementation is mode 1:1 A (raised by Maoke in
review on the mode 1:1 thread).

Sorry I misunderstand your meaning about this 1:1 mode. It clarifies a lot!

Thanks!

Best wishes
Qiong

On Thu, Jun 28, 2012 at 9:58 AM, Tetsuya Murakami <
[email-masked]> wrote:

>  Hi Qiong,
>
>  According to our current implementation, BR requires the following
> configuration.
>
>  - Rule IPv6 prefix
> - Rule IPv4 prefix
> - EA-bit length
> - PSID offset length (optional. default value is 4)
> - subnet id (optional)
>
>  BR can maintain multiple set of the information described above as
> BMR/FMR.
>
>  CE can also have multiple set of informations as BMR/FMR. In addition,
> CE can have a DMR including BR prefix/address.
>
>  In terms of the forwarding mode, this can be configured per the map
> tunnel instance which is associated with BMR. Right now, we don't allow to
> configure PSID itself explicitly. This can be gotten from a delegated IPv6
> prefix with the above mapping rule.
>
>  If the ea-bit length is set to 0, then our implementation does not
> retrieve any value from a delegated IPv6 prefix which is matched to Rule
> IPv6 prefix.
>
>  Thanks,
> Tetsuya Murakami
>
>   On 2012/06/27, at 18:01, Qiong wrote:
>
> Hi Tetsuya,
>

Open source code: