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

[Qiong <[e-mail]>]

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

On Mon, Jun 25, 2012 at 9:55 AM, Satoru Matsushima <
[e-mail]> wrote:

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


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


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