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

[GangChen <[e-mail]>]

Hello Dapeng and all,

I agreed Med explained three different cases and also understood
Dapeng's desire.

Trying to clarify cases and converge the discussion, I suggest following words.
Hopefully, that could eliminate your concerns.

"States should be maintained on other equipments, e.g. customer
premises equipment or host, in ADDRESS SHARING CONTEXT"

BRs

Gang

2012/6/14, 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
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>