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

["Lee, Yiu" <[e-mail]>]

Great! We will add it. 

On Jun 14, 2012, at 5:50 PM, "liu dapeng" <[e-mail]> wrote:

> Hi Gang,
> 
> This works for me, thanks.
> 
> Best Regards,
> Dapeng
> 
> 2012/6/14, 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
>>> 
>> 
> 
> 
> -- 
> 
> ------
> Best Regards,
> Dapeng Liu
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires