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

[Maoke <[e-mail]>]

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

> 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/
> > ===============================================
> >
> >
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>