Hi Dapeng,

A state maintained in the endpoint does not make the solution stateful, see 
this excerpt from RFC1958:

   This principle has important consequences if we require applications
   to survive partial network failures. An end-to-end protocol design
   should not rely on the maintenance of state (i.e. information about
   the state of the end-to-end communication) inside the network. Such
   state should be maintained only in the endpoints, in such a way that
   the state can only be destroyed when the endpoint itself breaks
   (known as fate-sharing).

I didn't considered your last proposed changes for the reason mentioned above. 

Thank you for your help.

Cheers,
Med 


>-----Message d'origine-----
>De : liu dapeng [mailto:[email protected]] 
>Envoyé : lundi 11 juin 2012 05:47
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Yong Cui; [email protected]
>Objet : Re: [Softwires] WG last call on 
>draft-ietf-softwire-stateless-4v6-motivation-01
>
>Hi Med:
>
>2012/6/8, [email protected] <[email protected]>:
>> Dear Dapeng,
>>
>> Please see inline.
>>
>> Cheers,
>>
>>>-----Message d'origine-----
>>>De : liu dapeng [mailto:[email protected]]
>>>Envoyé : vendredi 8 juin 2012 13:49
>>>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>>>Cc : Yong Cui; [email protected]
>>>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
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to