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

[Qiong <[e-mail]>]

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 <[e-mail]> wrote:

> 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.
>
>
> On 24 June 2012 17:13, Qiong <[e-mail]> 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 <
>> [e-mail]> 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
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>>
>>
>> --
>> ==============================================
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>
>


-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================