Re: [Softwires] I-D Action: draft-ietf-softwire-stateless-4v6-motivation-02.txt

[liu dapeng <[e-mail]>]

2012/6/13, [e-mail] <[e-mail]>:
> Re-,
>
> Please see inline.
>
> Cheers,
> Med
>
>>-----Message d'origine-----
>>De : liu dapeng [mailto:[e-mail]]
>>Envoyé : mercredi 13 juin 2012 12:09
>>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>Cc : [e-mail]
>>Objet : Re: [Softwires] I-D Action:
>>draft-ietf-softwire-stateless-4v6-motivation-02.txt
>>
>>Dear Med:
>>
>>
>>2012/6/13, [e-mail] <[e-mail]>:
>>> Dear Dapeng,
>>>
>>> The current text says:
>>>
>>> * no state in the (provider) network side
>>> * state may exist in the customer premises side
>>
>>=> I raised the concern yesterday for the term "may"
>>But didn't get response so far:
>>
>>> Med: Why "should"? The NAT is not mandatory
>>
>>=>Current candidate solutions told me that the NAT44 is mandatory part
>>i.e.
>>  "The NAPT MUST in turn be connectedto a MAP aware forwarding
>>function, that does encapsulation/decapsulation or translation to
>>IPv6."
>>
>>http://www.ietf.org/mail-archive/web/softwires/current/msg04379.html
>>please read that. Otherwise, I don't think we should move forward.
>>
>
> Med: You didn't answered my question. Pointing to a particular candidate
> solution is not a justification per se.

=>OK. there are great algorithms and working group agreed solutions
but you don't care.


 I can change "may" to "should" to
> please you but it really does make sense.

=> thanks

NAT is an optional feature in
> stateless solutions (e.g., host assigned with port restricted IPv4 address,

=>Please don't change subjects. We are talking about states.
In my proposal, recommended the text is "state should be ..."
NAT is only one sort of states. Port restriction is another.
I already clarify that two days ago.
http://www.ietf.org/mail-archive/web/softwires/current/msg04351.html


> host assigned with a full IPv4 address,

=>Please read last sentence in my proposal, that case was covered

"States still should be maintained in other equipments, e.g. customer
premises equipment or host, in order to restrict L3 or L4 information
into the configured context EXCEPT that a non-shared IPv4 address is
assigned to a standalone host."



CPE assigned with pool of IPv4
> addresses, etc.).

If operator could assign IPv4 pool which is big enought to locate one
public IPv4 address to each user, I would challenge the motivation per
se.
Even you could assign IPv4 pool, NAT state is unavoidable.


>>
>>> * focus is on carrier-side stateless solutions
>>
>>==>Carrier side stateless solution doesn't mean solution doesn't cover
>>CPE. We need to clarify definitely.
>
> Med: Clarify what? The document already says:
>
>    carrier-side stateless IPv4 over IPv6 solution.  States may still
>    exist in other equipments such as customer premises equipment.

=> Depending on above, please change "may" to "should". And clarify
state on CPE and host.

(e.g., host assigned with port restricted IPv4 address, host assigned
with a full IPv4 address, CPE assigned with pool of IPv4 addresses,
etc.).
==> quite clear that you have three type cases in your mind already, I
don't see why we reluctant to explain them correctly in the document.

Regards,
Dapeng

>
>>
>>Regards,
>>Dapeng
>>
>>> As an editor of the document, I believe the new version solves your
>>> concerns.
>>>
>>> Cheers,
>>> Med
>>>
>>>>-----Message d'origine-----
>>>>De : [e-mail]
>>>>[mailto:[e-mail]] De la part de liu dapeng
>>>>Envoyé : mercredi 13 juin 2012 05:40
>>>>À : Lee, Yiu
>>>>Cc : [e-mail]
>>>>Objet : Re: [Softwires] I-D Action:
>>>>draft-ietf-softwire-stateless-4v6-motivation-02.txt
>>>>
>>>>As a reader of the document, not co-author any related document, I
>>>>believe people who is not involved the whole process (e.g. edit the
>>>>documents, design the solutions,etc) couldn't understand the story
>>>>behind that. I personally have sincerely heard some people presenting
>>>>and evaluating this technology incorrectly somewhere before
>>because of
>>>>ambiguous understanding on the term.
>>>>
>>>>My purpose is that IETF has the responsibility to clarify what we are
>>>>documenting clearly to prevent from misleading.
>>>>
>>>>I'm thankful to your discussion that made all things clear
>>than before.
>>>>
>>>>And I don't understand why we don't document something we already
>>>>agreed on, but let the misleading to continue.
>>>>
>>>>Regards,
>>>>Dapeng Liu
>>>>
>>>>2012/6/13, Lee, Yiu <[e-mail]>:
>>>>> Hi Dapeng,
>>>>>
>>>>> This draft was written by operators, we do not have any problem
>>>>> understanding it. Besides, I disagree we "intentionally hide
>>>>the truth".
>>>>> Please explain to the WG what truth we are trying to hide in
>>>>this draft? I
>>>>> am not convinced we need to say anymore than what we have
>>>>stated in the
>>>>> new version.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Yiu
>>>>>
>>>>>
>>>>> On 6/12/12 11:45 AM, "liu dapeng" <[e-mail]> wrote:
>>>>>
>>>>>>2012/6/12, Lee, Yiu <[e-mail]>:
>>>>>>> Hi Dapeng.,
>>>>>>>
>>>>>>> This is not a specification draft. This is a draft to discuss the
>>>>>>> motivations. IMHO, people who are working in this area
>>>>would be able to
>>>>>>> understand this draft.
>>>>>>
>>>>>>=> I guess the audience is not only designer of protocol, but also
>>>>>>operators
>>>>>>who want to evaluate and adopt such technology. Intentional
>>>>hiding the
>>>>>>truth
>>>>>>for me is really bad.
>>>>>>
>>>>>>
>>>>>>
>>>>>>The focus of it is about the carrier network, CPE
>>>>>>> is never the focal point. I think the current statement
>>"States may
>>>>>>>still
>>>>>>> exist in other equipments such as customer premises
>>equipment." is
>>>>>>>enough.
>>>>>>
>>>>>>=>Please see my reply in previous mail. "may" is not sufficient.
>>>>>>
>>>>>>> Adding more text only causes confusion.
>>>>>>
>>>>>>=>What I do is objectively to elaborate what we are. Why
>>>>would that cause
>>>>>>confusion?
>>>>>>
>>>>>>Regards,
>>>>>>Dapeng
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Yiu
>>>>>>>
>>>>>>> On 6/12/12 6:21 AM, "liu dapeng" <[e-mail]> wrote:
>>>>>>>
>>>>>>>>2012/6/12, Ole Trøan <[e-mail]>:
>>>>>>>>>> Ok, then we can make this more clear in our document.
>>>>>>>>>>
>>>>>>>>>> "States still should be maintained in other equipments,
>>>>e.g. customer
>>>>>>>>>> premises equipment or host, in order to restrict IP
>>>>address or port
>>>>>>>>>> number
>>>>>>>>>> information into the configured context except that a
>>>>non-shared IPv4
>>>>>>>>>> address is
>>>>>>>>>> assigned to a standalone host."
>>>>>>>>>
>>>>>>>>> I think this is just adding confusion.
>>>>>>>>> the NAT44 on the CPE already does this.
>>>>>>>>
>>>>>>>>=>First off, we are not only talking about NAT44 here, but port
>>>>>>>>translation and non-shared address. Secondly, NAT44 on the
>>>>CPE is not
>>>>>>>>doing what today NAT44 does. For example, override ID in
>>ICMP with
>>>>>>>>port information.
>>>>>>>>
>>>>>>>>that reminds me to update the proposed text a bit,
>>>>>>>>
>>>>>>>>"States still should be maintained in other equipments,
>>>>e.g. customer
>>>>>>>>premises equipment or host, in order to restrict L3 or L4
>>>>information
>>>>>>>>into the configured context except that a non-shared IPv4
>>>>address is
>>>>>>>>assigned to a standalone host."
>>>>>>>>
>>>>>>>>> I suggest we instead talk about no _additional_ state in
>>>>the network.
>>>>>>>>>there
>>>>>>>>> is no need to mention the CPE, apart from stating that
>>>>no additional
>>>>>>>>>state
>>>>>>>>> is required.
>>>>>>>>
>>>>>>>>=>I believe the above is clear for reader and designer. I
>>>>don't see why
>>>>>>>>we resist on clarifying and helping reader better understanding.
>>>>>>>>
>>>>>>>>Regards,
>>>>>>>>Dapeng Liu
>>>>>>>>
>>>>>>>>
>>>>>>>>> cheers,
>>>>>>>>> Ole
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>--
>>>>>>>>
>>>>>>>>------
>>>>>>>>Best Regards,
>>>>>>>>Dapeng Liu
>>>>>>>>_______________________________________________
>>>>>>>>Softwires mailing list
>>>>>>>>[e-mail]
>>>>>>>>https://www.ietf.org/mailman/listinfo/softwires
>>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>
>>>>>>------
>>>>>>Best Regards,
>>>>>>Dapeng Liu
>>>>>
>>>>
>>>>
>>>>--
>>>>
>>>>------
>>>>Best Regards,
>>>>Dapeng Liu
>>>>_______________________________________________
>>>>Softwires mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/softwires
>>>>
>>
>>
>>--
>>
>>------
>>Best Regards,
>>Dapeng Liu
>>


-- 

------
Best Regards,
Dapeng Liu