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

[liu dapeng <[e-mail]>]

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