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