Re: [Softwires] WG last call on draft-ietf-softwire-stateless-4v6-motivation-01

[liu dapeng <[e-mail]>]

2012/6/11, Rémi Després <[e-mail]>:
>
> Le 2012-06-11 à 09:32, liu dapeng a écrit :
>
>> Hello Med,
>>
>> Yes, we are almost converged on this final update.
>>
>> As you said here, there still need port translation in the host, that
>> still state in the host.
>
> Note that these states are "per-connection", not "per customer".
> Even a host without NAT has to maintain per-connection states for its
> sockets.

The state you mentioned here is for application, but we are talking
about state on the network layer, they are different. I don't see why
we resist on clarifying and helping reader better understanding.

Besides, I guess the state referred in this document is not specific
to either "per-connection" or "per customer" . AFTR also hold a
"per-connection" state, which is treated as a stateful in the
document.

Best Regards,
Dapeng Liu




> In this respect, the draft is I think acceptable, and hopefully can now
> proceed quickly.
>



> Regards,
> RD
>
>
>> we need clarify that in this document for
>> other readers.
>>
>> Best Regards,
>> Dapeng Liu
>> 2012/6/11, [e-mail] <[e-mail]>:
>>> Re-,
>>>
>>> I was answering to your last proposed wording to include the port
>>> translation in the host. Except that change, all your proposed changes
>>> are
>>> included in my local copy:
>>>
>>> * The title has been updated as your requested
>>> * The introduction has been updated.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : liu dapeng [mailto:[e-mail]]
>>>> Envoyé : lundi 11 juin 2012 09:11
>>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>> Cc : Yong Cui; [e-mail]
>>>> Objet : Re: [Softwires] WG last call on
>>>> draft-ietf-softwire-stateless-4v6-motivation-01
>>>>
>>>> Hi Med,
>>>>
>>>> "end to end argument" is different from" stateful/stateless"
>>>> principally,
>>>> "end to end argument" recommend state in the end point(host),
>>>> but it doesn't say
>>>> it is stateless, it is still stateful.
>>>>
>>>> Based on this, I still believe that we need update the current
>>>> document with the last comment.
>>>>
>>>> Regards,
>>>> Dapeng Liu
>>>> 2012/6/11, liu dapeng <[e-mail]>:
>>>>> Hi Med:
>>>>>
>>>>> 2012/6/8, [e-mail]
>>>> <[e-mail]>:
>>>>>> Dear Dapeng,
>>>>>>
>>>>>> Please see inline.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : liu dapeng [mailto:[e-mail]]
>>>>>>> Envoyé : vendredi 8 juin 2012 13:49
>>>>>>> À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>>>>> Cc : Yong Cui; [e-mail]
>>>>>>> Objet : Re: [Softwires] WG last call on
>>>>>>> draft-ietf-softwire-stateless-4v6-motivation-01
>>>>>>>
>>>>>>>>
>>>>>>>> Med: We have already this text in the introduction:
>>>>>>>>
>>>>>>>>   Current standardization effort that is meant to
>>>> address this IPv4
>>>>>>>>   service continuity issue focuses mainly on stateful
>>>>>>> mechanisms that
>>>>>>>>   assume the sharing of any global IPv4 address that is
>>>> left between
>>>>>>>>   several customers, based upon the deployment of NAT
>>>>>>> (Network Address
>>>>>>>>   Translation) capabilities in the network.  Because of
>>>>>>> some caveats of
>>>>>>>>   such stateful approaches the Service Provider community
>>>>>>> feels that a
>>>>>>>>   companion effort is required to specify stateless IPv4
>>>> over IPv6
>>>>>>>>   approaches.  This document provides elaboration on such need.
>>>>>>>>
>>>>>>>> Isn't this text sufficient enough? If not, it would helpful
>>>>>>> to propose a
>>>>>>>> sentence you want to be added to the introduction.
>>>>>>>
>>>>>>> How about adding the following sentences:
>>>>>>>
>>>>>>> -------
>>>>>>> In many networks today, NAT44 functions is equipped on
>>>>>>> customer-edge device.
>>>>>>> It may impact IPv4 over IPv6 solution to be a stateful solution from
>>>>>>> end-to-end perspectives. The stateless solution also may subject to
>>>>>>> NAT44 state.
>>>>>>> In this document, we mainly refer this stateless paradigm to
>>>>>>> large-scale address Sharing, i.e. carrier-side stateless IPv4 over
>>>>>>> IPv6, which resolve the concern of "stateless" terminology. This
>>>>>>> document provides elaboration on such need.
>>>>>>> -------
>>>>>>>
>>>>>>
>>>>>> Med: Thanks for the proposal. I shortened your proposal and
>>>> updated the
>>>>>> text
>>>>>> to:
>>>>>>
>>>>>>
>>>>>>   Current standardization effort that is meant to address this IPv4
>>>>>>   service continuity issue focuses mainly on stateful
>>>> mechanisms that
>>>>>>   assume the sharing of any global IPv4 address that is
>>>> left between
>>>>>>   several customers, based upon the deployment of NAT
>>>> (Network Address
>>>>>>   Translation) capabilities in the network.  Because of
>>>> some caveats of
>>>>>>   such stateful approaches the Service Provider community
>>>> feels that a
>>>>>>   companion effort is required to specify stateless IPv4 over IPv6
>>>>>>   approaches.  Note stateless IPv4 over IPv6 solutions may
>>>> be enabled
>>>>>>   in conjunction with a port-restricted NAT44 function
>>>> located in the
>>>>>>   customer premises.
>>>>>>
>>>>>>   This document provides elaboration on the need for carrier-side
>>>>>>   stateless IPv4 over IPv6 solution.
>>>>>>
>>>>>>
>>>>>> Are you OK with this new text?
>>>>>
>>>>> [Dapeng]==>
>>>>> I make a minor change of the last two sentences:
>>>>> ---------
>>>>> Because of some caveats of such stateful approaches the Service
>>>>> Provider community feels that a companion effort is required to
>>>>> specify carrier-side stateless IPv4 over IPv6 approaches. Note
>>>>> carrier-side stateless IPv4 over IPv6 solutions may be enabled in
>>>>> conjunction with a port-restricted NAT44 function located in the
>>>>> customer premises or port translation in the host and that is still
>>>>> stateful in the whole.
>>>>> ---------
>>>>>
>>>>> Besides, how about changing all the terminology "stateless" to
>>>>> "carrier-side stateless" in the document?
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Best Regards,
>>>>> Dapeng Liu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> ------
>>>>> Best Regards,
>>>>> Dapeng Liu
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> ------
>>>> Best Regards,
>>>> Dapeng Liu
>>>>
>>
>>
>> --
>>
>> ------
>> Best Regards,
>> Dapeng Liu
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>


-- 

------
Best Regards,
Dapeng Liu