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

From: Rémi Després <[email-masked]>
Date: Fri, 1 Jun 2012 09:25:45 +0200

Support.
RD

Le 2012-05-27 à 16:28, Yong Cui a écrit :

> Hi folks,
> 
> This is a wg last call on draft-ietf-softwire-stateless-4v6-motivation-01.
> http://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivatio
> n/
> 
> As usual, please send editorial comments to the authors and
> substantive comments to the mailing list.
> 
> This wg last call will end on 2012 June 10 at 12pm EDT.
> 
> 
> Yong & Alain
> 
> 
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: liu dapeng <[email-masked]>
Date: Tue, 5 Jun 2012 16:49:26 +0800

Hello all,

I am not sure this version resolves my concerns regarding the possible
misleading by the word "stateless". To avoid this misleading, I
suggest the following changes:

1. Change the title to "Motivations for Carrier-side Stateless IPv4
over IPv6 Migration Solutions". Since this document is mainly about
carrier-side stateless, the new title is more precise to reflect the
content of this document.

2. Add a subsection in introduction, clarify that this document is
only about carrier side stateless.

I would like to support it if the document was updated accordingly.

Thanks,
Best regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Thu, 7 Jun 2012 13:50:18 +0200

Dear Dapeng,

Please see inline. 

Cheers;
Med 

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de liu dapeng
>Envoyé : mardi 5 juin 2012 10:49
>À : Yong Cui
>Cc : [email-masked]
>Objet : Re: [Softwires] WG last call on 
>draft-ietf-softwire-stateless-4v6-motivation-01
>
>Hello all,
>

Med: Done. I updated my local copy with the proposed title.

>only about carrier side stateless.

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.

>I would like to support it if the document was updated accordingly.

Thanks.

---

From: liu dapeng <[email-masked]>
Date: Fri, 8 Jun 2012 19:49:14 +0800

> Med: Done. I updated my local copy with the proposed title.

==>
Thanks

> 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.
-------

Thanks,

Best regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Fri, 8 Jun 2012 14:12:22 +0200

Dear Dapeng,

Please see inline.

Cheers, 

>De : liu dapeng [mailto:[email-masked]] 
>Envoyé : vendredi 8 juin 2012 13:49
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Yong Cui; [email-masked]
>IPv6, which resolve the concern of "stateless" terminology. This

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?

---

From: liu dapeng <[email-masked]>
Date: Mon, 11 Jun 2012 11:46:56 +0800

Hi Med:

> 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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 10 Jun 2012 23:26:28 -0500

I am not fond of the proposed change. 

After all, most of the other documents refer to stateful without taking a "side" (e.g. carrier-side), and so this document should state stateless in the same regard.

Of course, where it makes sense to clarify, it must be clarified that stateless is in the carrier-side, with or without stateful NAT44 in the customer-side. We must not make the assumption that stateless and stateful go together, though they will likely.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of liu dapeng
> Sent: Sunday, June 10, 2012 11:47 PM
> To: [email-masked]
> Cc: [email-masked]; Yong Cui
> Subject: Re: [Softwires] WG last call ondraft-ietf-softwire-stateless-4v6-
> motivation-01
> 
> Hi Med:
> 
> >>De : liu dapeng [mailto:[email-masked]] Envoyé : vendredi 8 juin
> >>2012 13:49 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Yong Cui;
> >>[email-masked] Objet : Re: [Softwires] WG last call on
> > Med: Thanks for the proposal. I shortened your proposal and updated
> > the text
> > to:
> >
> >
> 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

---

From: <[email-masked]>
Date: Mon, 11 Jun 2012 08:05:33 +0200

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 

>Envoyé : lundi 11 juin 2012 05:47
>> Med: Thanks for the proposal. I shortened your proposal and 
>updated the text
>> to:
>>
>>

---

From: liu dapeng <[email-masked]>
Date: Mon, 11 Jun 2012 14:10:28 +0800

I would prefer IETF more strict about what accurate terminology we are
using other than favorite. At this moment this document go through
working group last call which I have reviewed, and believe it should
be Revised for not misleading other people. Thanks for your
suggestion.

Regards,
Dapeng Liu
2012/6/11, Rajiv Asati (rajiva) <[email-masked]>:
> After all, most of the other documents refer to stateful without taking a
> "side" (e.g. carrier-side), and so this document should state stateless in
> the same regard.
>
> Of course, where it makes sense to clarify, it must be clarified that
> stateless is in the carrier-side, with or without stateful NAT44 in the
> customer-side. We must not make the assumption that stateless and stateful
> go together, though they will likely.
>
> Cheers,
> Rajiv
>
>

-- 

------
Best Regards,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Mon, 11 Jun 2012 15:10:44 +0800

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 <[email-masked]>:
>> Med: Thanks for the proposal. I shortened your proposal and updated the
>> text
>> to:
>>
>>

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Mon, 11 Jun 2012 09:21:21 +0200

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 

>Envoyé : lundi 11 juin 2012 09:11
>updated the

---

From: liu dapeng <[email-masked]>
Date: Mon, 11 Jun 2012 15:32:21 +0800

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. we need clarify that in this document for
other readers.

Best Regards,
Dapeng Liu
2012/6/11, [email-masked] <[email-masked]>:
> 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:
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Jun 2012 09:45:59 +0200

Le 2012-06-11 à 09:32, liu dapeng a écrit :

> 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.
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

---

From: liu dapeng <[email-masked]>
Date: Mon, 11 Jun 2012 18:32:19 +0800

> Even a host without NAT has to maintain per-connection states for its

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

-- 

------
Best Regards,
Dapeng Liu

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 11 Jun 2012 14:54:08 +0000

Hi Med and Dapeng,

In order to close the gap, I suggest a slight modification:

"Current standardization effort that is meant to address this IPv4
   service continuity issue focuses mainly on stateful mechanisms that
sharing of global IPv4 addresses between
Customers is 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 that the stateless solution elaborated in this
document
focuses on the carrier-side stateless IPv4 over IPv6 solution. States may
still exist in other equipments such as customer-premises equipment."

Thanks,
Yiu

On 6/8/12 8:12 AM, "[email-masked]"
<[email-masked]> wrote:

>text to:

---

From: <[email-masked]>
Date: Mon, 11 Jun 2012 17:37:18 +0200

Hi Yiu,

Works for me. Thanks.

Cheers,
Med 

>De : Lee, Yiu [mailto:[email-masked]] 
>Envoyé : lundi 11 juin 2012 16:54
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; liu dapeng
>Cc : [email-masked]; Yong Cui

---

From: liu dapeng <[email-masked]>
Date: Tue, 12 Jun 2012 14:39:29 +0800

Hi Yiu,

> still exist in other equipments such as customer-premises equipment."

I am out of office this morning thence miss your mail. I suggest to
change "may" to "should" in the above sentence.

Regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu