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

[Qiong <[e-mail]>]

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