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

[liu dapeng <[e-mail]>]

Hello Med and all,

I don't agree we move like this way, as yourself said yesterday.
"(e.g., host assigned with port restricted IPv4 address, host assigned
with a full IPv4 address, CPE assigned with pool of IPv4 addresses,
etc.)."

It isquite 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.

Please kindly help to let readers understand what is your thought.
Thanks a lot for your help.

Best Regards,
-Dapeng


2012/6/14, [e-mail] <[e-mail]>:
> Hi Tom,
>
> Thank for the proposal. I can update the text with your proposed wording if
> Dapeng is OK.
>
> Dapeng, are you happy with the text proposed by Tom?
>
> Cheers,
> Med
>
>>-----Message d'origine-----
>>De : Tom Taylor [mailto:[e-mail]]
>>Envoyé : mercredi 13 juin 2012 17:44
>>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>Cc : liu dapeng; [e-mail]
>>Objet : Re: [Softwires] I-D Action:
>>draft-ietf-softwire-stateless-4v6-motivation-02.txt
>>
>>I think what Dapeng wants to convey would be achieved if you
>>changed the
>>"may" to "will typically":
>>  "... state will typically exist in the customer premises side"
>>
>>Is this acceptable?
>>
>>On the second point, I agree with the existing text.
>>
>>Tom Taylor
>>
>>On 13/06/2012 7:42 AM, [e-mail] wrote:
>>> 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. I
>>can change "may" to "should" to please you but it really does
>>make sense. NAT is an optional feature in stateless solutions
>>(e.g., host assigned with port restricted IPv4 address, host
>>assigned with a full IPv4 address, CPE assigned with pool of
>>IPv4 addresses, etc.).
>>>
>>>>
>>>>> * 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.
>>>
>>>
>>>>
>>>> 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
>>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>


-- 

------
Best Regards,
Dapeng Liu