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

From: [email-masked]
Date: Fri, 10 Feb 2012 02:03:49 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF.

	Title           : Motivations for Stateless IPv4 over IPv6 Migration Solutions
	Author(s)       : Mohamed Boucadair
                          Satoru Matsushima
                          Yiu Lee
                          Olaf Bonness
                          Isabel Borges
                          Gang Chen
	Filename        : draft-ietf-softwire-stateless-4v6-motivation-01.txt
	Pages           : 16
	Date            : 2012-02-10

   IPv4 service continuity is one of the most pressing problems that
   must be resolved by Service Providers during the IPv6 transition
   period - especially after the exhaustion of the public IPv4 address
   space.  Current standardization effort that addresses IPv4 service
   continuity focuses on stateful mechanisms.  This document elaborates
   on the motivations for the need to undertake a companion effort to
   specify stateless IPv4 over IPv6 approaches.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-stateless-4v6-motivation-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-softwire-stateless-4v6-motivation-01.txt

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 11:20:35 +0100

Dear WG members, 

I would like to close this document so that we can meet the following item from the WG Charter:

"
4. Developments for stateless legacy IPv4 carried over IPv6
- develop a solution motivation document to be published as an
RFC
- develop a protocol specification response to the solution
motivation document; this work item will not be taken through
Working Group last call until the solution motivation document
has been published or approved for publication 
"

Except the a comment asking to include a new section to compare stateful vs. stateless, no further comments have been received.

I didn't considered adding the proposed new section because IMO it is out of scope of this document. That section can justify in its own a dedicated draft.

As for the next step, I see two options:

(1) Either issue a WG LC, or
(2) Withdraw the document and update the WG charter.

WG members, please advise.

Cheers,
Med

---

From: Francis Dupont <[email-masked]>
Date: Sat, 11 Feb 2012 09:30:13 +0100

>  (1) Either issue a WG LC, or

+1

[email-masked]

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sat, 11 Feb 2012 06:43:10 -0500

+1

Cheers,
Rajiv

Sent from my Phone

On Feb 11, 2012, at 3:30 AM, "Francis Dupont" <[email-masked]> wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Rémi Després <[email-masked]>
Date: Sat, 11 Feb 2012 14:52:58 +0100

+1
RD

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 11 Feb 2012 06:30:58 -0800

On Feb 10, 2012 2:20 AM, <[email-masked]> wrote:
> Except the a comment asking to include a new section to compare stateful
vs. stateless, no further comments have been received.
>
> I didn't considered adding the proposed new section because IMO it is out
of scope of this document. That section can justify in its own a dedicated
draft.

I find this omission disappointing. There is a common assumption that
stateless is superior to stateful, but it is not quantified anywhere.

It seems all this stateless work hinges on this assumption without any
quantification.

Honestly, the omission makes me believe the case of stateless being
superior is dubious.

Cb

---

From: Rémi Després <[email-masked]>
Date: Sat, 11 Feb 2012 17:36:22 +0100

Le 2012-02-11 à 15:30, Cameron Byrne a écrit :

> I find this omission disappointing. There is a common assumption that stateless is superior to stateful, but it is not quantified anywhere.
> 
> It seems all this stateless work hinges on this assumption without any quantification.
> 
> Honestly, the omission makes me believe the case of stateless being superior is dubious.
> 

Both stateful AND stateless have their use cases.
This motivation draft shouldn't be taken as advocating that Stateful should be abandoned! 
(Both NAT64 and DS-lite are here to stay. There also have their use cases where they are superior).

Delaying this document would only be IMHO a waste of energy. 

Regards,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 13 Feb 2012 04:14:30 +0100

On 2012/02/11, at 15:30, Cameron Byrne wrote:

--snip--
> Honestly, the omission makes me believe the case of stateless being superior is dubious.

Do you think that it is productive productive analysis that comparison of stateless between stateful? Current motivation draft stands not to beat other solutions, it stands for justifying to start stateless solution work on the WG so some proponents of stateless solution took a pen. My question is that if the comparison is productive for something, who should work for it, and who should read it.

cheers,
--satoru

---

From: liu dapeng <[email-masked]>
Date: Mon, 13 Feb 2012 11:45:40 +0800

> Honestly, the omission makes me believe the case of stateless being

Agree. Stateless and stateful may both have their own use cases.Saying
that stateless is superior than stateful may not be appropriate
considering that there is no comprehensive and quantitative
comparation between them.

BR,
Dapeng

-- 

------
Best Regards,
Dapeng Liu

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 12 Feb 2012 20:02:36 -0800

quantification.
superior is dubious.
> >
> > Cb
>
> Do you think that it is productive productive analysis that comparison of
stateless between stateful? Current motivation draft stands not to beat
other solutions, it stands for justifying to start stateless solution work
on the WG so some proponents of stateless solution took a pen. My question
is that if the comparison is productive for something, who should work for
it, and who should read it.

I assumed this explanation and comparison would be easy for the stateless
experts.  I looked to this as a learning opportunity for me.

I agree with you and RD, there are many good solutions that fit this
problem space and I do not intend to slow progress.

If it is difficult  and the differences in merit cannot be easily
quantified between stateful and stateless , I accept that as an answer.

I suggested they be compared since opposites frequently help define each
other. Black helps define white just as cold helps define hot.  I had
assumed this was true for this case as well. Perhaps I was wrong.

Thanks again for your contribution.

Cb

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 13 Feb 2012 06:19:25 +0100

On 2012/02/13, at 5:02, Cameron Byrne wrote:

> 
> On Feb 12, 2012 7:14 PM, "Satoru Matsushima" <[email-masked]> wrote:
> >
> I assumed this explanation and comparison would be easy for the stateless experts.  I looked to this as a learning opportunity for me.
> 
> I agree with you and RD, there are many good solutions that fit this problem space and I do not intend to slow progress.
> 
> If it is difficult  and the differences in merit cannot be easily  quantified between stateful and stateless , I accept that as an answer.
> 

I agree that the proponents of statless can work for the comparison, but also stateful proponents too.
Does who can work means equal to who should work, which sides is better to explain it for the fairness? Maybe both?

> I suggested they be compared since opposites frequently help define each other. Black helps define white just as cold helps define hot.  I had assumed this was true for this case as well. Perhaps I was wrong.
> 

Agree. but when do we need it? 6rd vs L2TP, OSPF vs ISIS, LDP vs RSVP, etc, etc.,

> Thanks again for your contribution. 

you too, thanks.
--satoru

---

From: Ole Trøan <[email-masked]>
Date: Mon, 13 Feb 2012 10:27:59 +0100

Cameron,

RFC1958 gives the fundamental principles. search for "state".

cheers,
Ole

---

From: <[email-masked]>
Date: Mon, 13 Feb 2012 10:28:44 +0100

Dear Cameron,

Yes, I know it is tempting to have such section but it won't help in making a decision and, furthermore, it may maintain a tension between stateless and stateful camps. We tried in the document to be neutral as much as possible and avoid claiming "stateless is superior to stateful" or "stateful is superior to stateless".

I personally think both stateful and stateless solutions are needed. It is up to each service provider, taking into account its own environment and constraint, to select the flavour of solutions which fit its needs. The selection may even be complex given the diversity of networks and services managed by (large) service providers.

Cheers,
Med

________________________________
De : Cameron Byrne [mailto:[email-masked]]
Envoyé : samedi 11 février 2012 15:31
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]
Objet : Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation

Cb

> [email-masked]<mailto:[email-masked]>

---

From: liu dapeng <[email-masked]>
Date: Mon, 13 Feb 2012 20:10:50 +0800

> RFC1958 gives the fundamental principles. search for "state".

Yes. But do you think it is achievable for "pure stateless"?

BR,
Dapeng

>> > Do you think that it is productive productive analysis that comparison
>> > of stateless between stateful? Current motivation draft stands not to
>> > beat other solutions, it stands for justifying to start stateless
>> > solution work on the WG so some proponents of stateless solution took a
>> > pen. My question is that if the comparison is productive for something,
>> > who should work for it, and who should read it.
>> >
>>

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Mon, 20 Feb 2012 15:24:27 +0100

Dear chairs, WG members,

The answers received so far are in favour of initiating a WG LC on this document.

As an editor of the document, I would like to progress this document for the next IETF meeting. Chairs, could you please issue the WG LC? Thanks.

Cheers,
Med 

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> Envoyé : samedi 11 février 2012 09:30
> Objet : Re: [Softwires] Closing 
> draft-ietf-softwire-stateless-4v6-motivation 
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Feb 2012 16:09:46 +0100

Le 2012-02-20 à 15:24, <[email-masked]> <[email-masked]> a écrit :

> As an editor of the document, I would like to progress this document for the next IETF meeting.

+1
RD

> Chairs, could you please issue the WG LC? Thanks.
> 
> Cheers,
> Med 
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 20 Feb 2012 09:17:58 -0600

+1

Behcet

---

From: liu dapeng <[email-masked]>
Date: Thu, 23 Feb 2012 19:03:44 +0800

Hi Med,

I think it is still not clear about the definition of "stateless", in
current draft, it says:

stateless denotes a solution which does not require any per-user state
(see Section
 2.3 of [RFC1958]) to be maintained by any IP address sharing
function in the Service Provider's network.

But all the candidate solutions: MAP-T/MAP-E/4rd-U all need to maitain
state in CPE. It is obviously contradictory with this definition. We
need more discussion regarding the definition of "stateless".

regards,
Dapeng Liu

2012/2/20, [email-masked] <[email-masked]>:
> As an editor of the document, I would like to progress this document for the
> next IETF meeting. Chairs, could you please issue the WG LC? Thanks.
>
> Cheers,
> Med
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Leaf yeh <[email-masked]>
Date: Thu, 23 Feb 2012 11:22:56 +0000

The stateless sounds only regard to BR, the border router, in the case of MAP-T/MAP-E/4rd-U,
or even CGN ( or AFTR) in the case of Juniper SD-NAT.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of liu dapeng
Sent: Thursday, February 23, 2012 7:04 PM
To: [email-masked]
Cc: [email-masked]; Softwire Chairs
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation

Hi Med,

regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Thu, 23 Feb 2012 13:37:24 +0100

Dear Dapeng,

Are you considering the endpoint (host or CPE) as part of the service provider's network?

If not, please read the definition again with the answer in mind.

Cheers,
Med 

> De : liu dapeng [mailto:[email-masked]] 
> Envoyé : jeudi 23 février 2012 12:04
> Cc : Softwire Chairs; [email-masked]
> > The answers received so far are in favour of initiating a 
> WG LC on this
> > document.
> >

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Feb 2012 14:05:25 +0100

Le 2012-02-23 à 12:03, liu dapeng a écrit :

> state in CPE.

Hi Liu,

Even in mesh topologies, these solutions don't require CPEs to maintain states about other CPEs to communicate directly with them.
In this sense, they are stateless, including with the given definition.
OK? 

regards,
RD

> It is obviously contradictory with this definition. We

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Feb 2012 08:10:43 -0800

On Feb 23, 2012 5:05 AM, "Rémi Després" <[email-masked]> wrote:
> Even in mesh topologies, these solutions don't require CPEs to maintain
states about other CPEs to communicate directly with them.
> In this sense, they are stateless, including with the given definition.

Correct me if I am wrong, but at leas map-t requires stateful nat44 at the
cpe

Cb

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Feb 2012 08:13:19 -0800

> Correct me if I am wrong, but at leas map-t requires stateful nat44 at
the cpe

Never mind. Please excuse me not reading enough about the definition
before sending.

Cb
> > > 2012/2/20, [email-masked] <[email-masked]
>:
> > >> Dear chairs, WG members,
> > >>
> > >> The answers received so far are in favour of initiating a WG LC on
this

---

From: liu dapeng <[email-masked]>
Date: Fri, 24 Feb 2012 20:10:13 +0800

> In this sense, they are stateless, including with the given definition.

CPE have to maintain NAT44 state in all the cases. Is that a state or not?

regards,
Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: Ole Trøan <[email-masked]>
Date: Fri, 24 Feb 2012 13:13:42 +0100

Dapeng,

> CPE have to maintain NAT44 state in all the cases. Is that a state or not?

no _additional_ state in CPE. keep state close to end-user (as it is now), no state in SP network.

cheers,
Ole

---

From: liu dapeng <[email-masked]>
Date: Fri, 24 Feb 2012 20:21:14 +0800

Hi Med,

Yes, I am considering CPE. There are two reasons:

1. The definition of "stateless" should not be bind to the provider's
network. The document should define "stateless" for the Internet not
only for the operator.

2. Even for CPE itself, in many cases, it should be considered as
provider's network since operator need to control/configure the CPE
remotely in that case.

regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: Leaf yeh <[email-masked]>
Date: Fri, 24 Feb 2012 12:23:57 +0000

Supposed the state association turns from Port Unrestricted to be Port Restricted at CE, then CE works as a PRD (Port Restricted Device) in roughly all the cases.

Cheers
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Tr?an
Sent: Friday, February 24, 2012 8:14 PM
To: liu dapeng
Cc: [email-masked]; Softwire Chairs
Subject: Re: [Softwires] Closing draft-ietf-softwire-stateless-4v6-motivation

Dapeng,

cheers,
Ole

---

From: "Lee, Yiu" <[email-masked]>
Date: Sat, 25 Feb 2012 02:49:26 +0000

Hi Dapeng,

IMHO both sides are right. Whether in CPE or in the SP, there are states.
I guess when people say stateless on this list, they always refer to SP
network (vs. CPE). But we all agree that there would be states in the CPE
for the "stateless" solutions we discuss here. If we can clarify
"stateless" refers to SP network, does this work better for you?

We can argue that CPE is part of "SP" network. However, states in CPE
exist since introducing NAT. This is well understood and everybody has
lots of experience of it. States in SP are new to many operators and some
of them prefer keeping the states in the CPE due to various reasons we
discuss in the draft. That said, there are always pros and cons, it is up
to the operators to decide what path they would prefer.

Regards,
Yiu

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Feb 2012 09:41:42 +0100

Liu,
Please see more clarification in line.

Le 2012-02-24 à 13:21, liu dapeng a écrit :

> network.

Agreed.

> The document should define "stateless" for the Internet not
> only for the operator.

Because the document deals only with solutions deployed within individual ISP networks (similar in that to 6rd), it is AFAIK right to limit its stateless concern to individual ISP network.

> provider's network since operator need to control/configure the CPE

Agreed that CPEs, are part of the model.
But the important point AFAIK is that, "stateless 4/6 solution" is defined in the document itself as meaning without "per-user state".
All under-study solutions that refer to this draft are without "per-user" state" in "active data plane network elements". They are therefore din scope of this draft.
If a CPE includes a NAT for its IPv4 operation (with states that are per only session states, and only IPv4), the 4/6 solution proper remains without "per-user state".

Considering that publication of this draft is much expected to pursue the work on solutions themselves, and that it isn't freezing a standard (just clarifying a need that too many wanted to better understand), could you then agree that the draft can proceed as is.

Thank you,
RD

---

From: liu dapeng <[email-masked]>
Date: Mon, 27 Feb 2012 19:04:31 +0800

Hi Remi,

Please see my reply inline:

2012/2/27, Rémi Després <[email-masked]>:
> Because the document deals only with solutions deployed within individual
> ISP networks (similar in that to 6rd), it is AFAIK right to limit its
> stateless concern to individual ISP network.

The solutions currently under study have many requirement&enhancement
to the CPE. So I think the document does not "deals only with
soltuions deployed within individual ISP networks" if not considering
the CPE as part of ISP network.

> But the important point AFAIK is that, "stateless 4/6 solution" is defined
> in the document itself as meaning without "per-user state".
> All under-study solutions that refer to this draft are without "per-user"
> state" in "active data plane network elements". They are therefore din scope
> of this draft.

> If a CPE includes a NAT for its IPv4 operation (with states that are per
> only session states, and only IPv4), the 4/6 solution proper remains without
> "per-user state".

If  having "per-user state" is stateful, why "per session state" is
not stateful?

> Considering that publication of this draft is much expected to pursue the
> work on solutions themselves, and that it isn't freezing a standard (just
> clarifying a need that too many wanted to better understand), could you then
> agree that the draft can proceed as is.

The concern that I have is: If we want to move forward, we need more
clear and strict definition of "stateless" and also need more
investigation before we give the conclusion that "stateless is
superior than stateful".

Thanks.

Regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Mon, 27 Feb 2012 19:20:01 +0800

> "stateless" refers to SP network, does this work better for you?

 The problem is: SP network can not exclude CPE..

> to the operators to decide what path they would prefer.

Yes, I agree that there are always pros and cons but we should try to
avoid confusing&misleading the reader before we decide to move
forward.

Thanks.

Regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Feb 2012 13:48:05 +0100

> the CPE as part of ISP network.

Misunderstanding.
Yes the 4/6 function of the CPE is part of the ISP-network solution, even if the CPE isn't provided by the ISP.
I think we agree on this.

> If  having "per-user state" is stateful, why "per session state" is

It is stateful too, yes, but differently.
Also, if a CPE includes a NAT44, its states are not IPv4-over-IPv6 related (only IPv4 related). 
=> Would you be satisfied if, in the terminology section, definition of Stateless 4/6 solution and  Stateful 4/6 solution would be clarified as follows:

Stateless  4/6 solution (or stateless solution in short): denotes in this document a solution which, as far as IPv4 aver IPv6 is concerned, does not require any per-user state ...

Stateful 4/6 solution  (or stateful solution in short): denotes in this document a solution which, as far as IPv4 aver IPv6 is concerned, requires neither per-customer nor per connection state ...

> investigation before we give the conclusion that "stateless is

The draft only reflects the wish of an number of operators to have a stateless solution standardized, acknowledging that this is in addition to the more advanced stateful solutions (it doesn't even include the word "superior"). 

Hoping that you will be more open to permit parallel progress on stateless,
Regards,

RD

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 27 Feb 2012 07:02:41 -0800

On Feb 27, 2012 4:48 AM, "Rémi Després" <[email-masked]> wrote:
> >>> 2012/2/23, [email-masked] <[email-masked]
>:
> >>>> Dear Dapeng,
> >>>>
> => Would you be satisfied if, in the terminology section, definition of
Stateless 4/6 solution and  Stateful 4/6 solution would be clarified as
follows:
>
> Stateless  4/6 solution (or stateless solution in short): denotes in this
document a solution which, as far as IPv4 aver IPv6 is concerned, does not
require any per-user state ...
>
> Stateful 4/6 solution  (or stateful solution in short): denotes in this
document a solution which, as far as IPv4 aver IPv6 is concerned, requires
neither per-customer nor per connection state ...
> The draft only reflects the wish of an number of operators to have a
stateless solution standardized, acknowledging that this is in addition to
the more advanced stateful solutions (it doesn't even include the word
"superior").
> Hoping that you will be more open to permit parallel progress on
stateless,

+1.

I believe the consensus is that one is not better than the other, or at
least it is not possible to quantify.

In the end, deployments of transition scenarios will be dependent on
operator preference, cost, timeline, features...

Cb

---

From: liu dapeng <[email-masked]>
Date: Tue, 28 Feb 2012 22:06:56 +0800

Hi Remi,

Thanks for the discussion but the fundamental question is:

If we consider [CPE(stateful) + BR(partially stateless maybe)] as a
stateless solution,

then, why  [CPE(stateless) + xlate(stateful)] is not a stateless solution?

Regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Feb 2012 09:41:17 -0500

The fundamental issue is total cost to the operator. Different operators 
have different cost structures, hence need different engineering 
solutions. This isn't a matter of using precise language -- "stateless" 
is a term of convenience fitting the perceptions of the particular group 
of persons interested in the MAP and 4rd work.

Rather than argue over the use of the term, perhaps you could describe 
the engineering solution that interests you (though I suppose the 
question below gives a hint).

Tom Taylor

On 28/02/2012 9:06 AM, liu dapeng wrote:
...
> then, why  [CPE(stateless) + xlate(stateful)] is not a stateless solution?
...

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Feb 2012 15:49:59 +0100

2012-02-28 15:06, liu dapeng :
...
...
...
> then, why  [CPE(stateless) + xlate(stateful)] is not a stateless solution?

What I see as important is that IPv6-only routing can be deployed ASAP without sacrificing a good residual IPv4 service, including where ISPs prefer per-user stateless operation.

The point has already been made that functions are defined in the draft as "stateless" if they don't need (for IPv4 over IPv6) any "per-user" state. 
A CE can therefore be considered stateless *in the draft* even if it has NAT44 (a function that is purely IPv4, and whose statefulness is per session).  
Because of that, the draft is self consistent an doesn't need to be modified.

I do hope that, with these additional explanations, and in order to avoid waste of energy, you can accept to join a consensus that it is time to close this discussion and accept the draft.

Looking forward to further discussions on solutions themselves,
Regards,
RD

---

From: liu dapeng <[email-masked]>
Date: Wed, 29 Feb 2012 17:53:00 +0800

2012/2/28, Rémi Després <[email-masked]>:
> What I see as important is that IPv6-only routing can be deployed ASAP
> without sacrificing a good residual IPv4 service, including where ISPs
> prefer per-user stateless operation.
>
> The point has already been made that functions are defined in the draft as
> "stateless" if they don't need (for IPv4 over IPv6) any "per-user" state.
> A CE can therefore be considered stateless *in the draft* even if it has
> NAT44 (a function that is purely IPv4, and whose statefulness is per
> session).
> I do hope that, with these additional explanations, and in order to avoid
> waste of energy, you can accept to join a consensus that it is time to close
> this discussion and accept the draft.
>
>
Hello Remi

Firstly, this draft will mis-lead other operators thinking that this
is a pure stateless solution from the title and the document (maybe
terminology such as "Maping" is better). IETF WG should not hurry up
without the correct description on what the document is. For my
understanding, both of above two solutions are stateful solution. Even
in the first case of BR' side there are still stateful information for
control plane.

Secondly, since this is also stateful solution principally. Then why
IETF need to invent a second wheel about the same scenario, should
IETF obsolete previous one such as DS-Lite, then start to work on
this?

Thanks

-Dapeng

---

From: Ole Trøan <[email-masked]>
Date: Wed, 29 Feb 2012 11:01:37 +0100

> IETF obsolete previous one such as DS-Lite, then start to work on

- there is new or _additional_ state introduced in the network
- existing state is kept close to the edge (RFC1958)

I don't see how this is going to mislead or confuse anyone.

what point are you trying to make? that the total amount of state in a DS-lite versus stateless solution is about the same? that's correct as far as it goes. but _where_ the state is does matter. no-one would argue against putting state in the end host or application, while adding state in the network is problematic for all the reasons outlined in the draft.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 29 Feb 2012 11:48:09 +0100

Le 2012-02-29 à 10:53, liu dapeng a écrit :

> IETF need to invent a second wheel about the same scenario,

> should

Surely not.
This debate has been finished when it was decided that Softwire would work ALSO on solutions that are stateless, at least in ISP gateways to the IPv4 Internet.

You may have not been personally part of this consensus, which is obviously your right, but the consensus remains.
Since no one prevents you from using stateful solutions of you choice, trying to prevent those who want a more stateless solution to have a specification isn't, IMHO, fair contribution to standardization.

RD