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

[Qiong <[e-mail]>]

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 <
[e-mail]> 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,
>
> 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 <
> [e-mail]> 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
>>
>>   On 2012/06/25, at 7: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.
>>
>> 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 <[e-mail]> 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 <[e-mail]>
>>> *Date:* 2012-06-25 10:27
>>> *To:* Lee, Yiu <[e-mail]>
>>> *CC:* [e-mail]; Yong Cui <[e-mail]>
>>>  *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" <[e-mail]> 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
>>> >> <[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
>>> >>>
>>> >>> _______________________________________________
>>> >>> Softwires mailing list
>>> >>> [e-mail]
>>> >>> https://www.ietf.org/mailman/listinfo/softwires
>>> >> _______________________________________________
>>> >> Softwires mailing list
>>> >> [e-mail]
>>> >> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>> _______________________________________________
>> 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/ *
> ===============================================
>
>
>
>


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


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