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

From: [email-masked]
Date: Mon, 11 Jun 2012 22:43:06 -0700

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 Carrier-side 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-02.txt
	Pages           : 16
	Date            : 2012-06-11

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-stateless-4v6-motivation

There's also a htmlized version available at:
http://tools.ietf.org/html/submission.filename }}-02

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-stateless-4v6-motivation-02

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

---

From: <[email-masked]>
Date: Tue, 12 Jun 2012 07:47:50 +0200

Dear WG members,

The new version includes the comments received during the WG LC (from Dapeng).

A diff is available here: 

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de 
>[email-masked]
>Envoyé : mardi 12 juin 2012 07:43
>À : [email-masked]
>Cc : [email-masked]
>Objet : [Softwires] I-D Action: 
>draft-ietf-softwire-stateless-4v6-motivation-02.txt
>
>
>	Title           : Motivations for Carrier-side 
>Stateless IPv4 over IPv6 Migration Solutions
>	Filename        : 
>draft-ietf-softwire-stateless-4v6-motivation-02.txt
>	Pages           : 16
>	Date            : 2012-06-11
>
>Abstract:
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires
>

---

From: liu dapeng <[email-masked]>
Date: Tue, 12 Jun 2012 15:13:50 +0800

Hi Med,

Thanks for posting this new version but I guess it doesn't reflect all
the discussion we had. I suggest to make following modifications.

"States still should be maintained in other equipments, e.g.  customer
premises equipment or host, in order to restrict port numbers within a
dedicated range."

Please be undestood all the efforts are for precise expression for the readers.

Thanks,

Best Regards,
Dapeng Liu

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Tue, 12 Jun 2012 10:12:38 +0200

Hi Dapeng,

I can't add the port restriction because stateless IPv4/IPv6 solutions (e.g., MAP, 4RD) support also the ability to assign a full IP address.

Cheers,
Med

>De : liu dapeng [mailto:[email-masked]] 
>Envoyé : mardi 12 juin 2012 09:14
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : [email-masked]
>Objet : Re: [Softwires] I-D Action:

---

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

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

Best Regards,
Dapeng Liu

2012/6/12, [email-masked] <[email-masked]>:
> Hi Dapeng,
>
> I can't add the port restriction because stateless IPv4/IPv6 solutions
> (e.g., MAP, 4RD) support also the ability to assign a full IP address.
>
> Cheers,
> Med
>

-- 

------
Best Regards,
Dapeng Liu

---

From: Ole Trøan <[email-masked]>
Date: Tue, 12 Jun 2012 11:51:18 +0200

> assigned to a standalone host."

I think this is just adding confusion.
the NAT44 on the CPE already does this.

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.

cheers,
Ole

---

From: liu dapeng <[email-masked]>
Date: Tue, 12 Jun 2012 18:21:56 +0800

> 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

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Tue, 12 Jun 2012 13:44:56 +0200

Re-,

Please see inline.

Cheers,
Med  

>Envoyé : mardi 12 juin 2012 11:49
>"States still should be maintained in other equipments,

Med: Why "should"? The NAT is not mandatory and even if port restriction is needed, a host may just restrict its port to be within the range. So, I don't see a reason to change "may" to "should".

 e.g. customer
>assigned to a standalone host."

Med: No need to elaborate what the state is about. You asked to add a sentence to say a state may exist in the LAN side, I updated the text to cover your comment: 

"States may still exist in other equipments such as customer premises equipment."

>>>> The new version includes the comments received during the 
>WG LC (from
>>>> Dapeng).
>>>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 12 Jun 2012 12:46:13 +0000

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. 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.
Adding more text only causes confusion.

Thanks,
Yiu

---

From: liu dapeng <[email-masked]>
Date: Tue, 12 Jun 2012 23:36:04 +0800

2012/6/12, [email-masked] <[email-masked]>:
> Med: Why "should"? The NAT is not mandatory

=>Current candidate solutions told me the NAT44 is mandatory part
i.e.
   "The NAPT MUST in turn be connected
   to a MAP aware forwarding function, that does encapsulation/
   decapsulation or translation to IPv6."

and even if port restriction is
> needed, a host may just restrict its port to be within the range.

=> This part we had discussed yesterday. That is a step back for our
discussion,
since you have acknowledged that is a state.

So, I
> don't see a reason to change "may" to "should".

=> depending on above, I think it should change "may" to "should"

> Med: No need to elaborate what the state is about. You asked to add a
> sentence to say a state may exist in the LAN side, I updated the text to
> cover your comment:
>

=> We have already figured out what state is about, why not stated. If there
is any flawed bug, I'm happy to fix it. But I can't accept push back without
any reasonable justification.

Regards,
Dapeng

-- 

------
Best Regards,
Dapeng Liu

---

From: liu dapeng <[email-masked]>
Date: Tue, 12 Jun 2012 23:45:21 +0800

2012/6/12, Lee, Yiu <[email-masked]>:
> 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
> 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

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Tue, 12 Jun 2012 18:14:37 +0200

Hi Yiu,

+1.

Cheers,
Med 

>[mailto:[email-masked]] De la part de Lee, Yiu
>Envoyé : mardi 12 juin 2012 14:46
>À : [email-masked]
>>>> information into the configured context except that a 
>non-shared IPv4
>>>> address is
>>> I suggest we instead talk about no _additional_ state in 
>the network.
>>>there

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 12 Jun 2012 09:16:52 -0700

+1

Cheers,
Rajiv

Sent from my Phone

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 12 Jun 2012 20:51:23 +0000

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

---

From: liu dapeng <[email-masked]>
Date: Wed, 13 Jun 2012 11:39:57 +0800

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

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Wed, 13 Jun 2012 07:57:43 +0200

Dear Dapeng,

The current text says:

* no state in the (provider) network side
* state may exist in the customer premises side
* focus is on carrier-side stateless solutions

As an editor of the document, I believe the new version solves your concerns. 

Cheers,
Med 

>[mailto:[email-masked]] De la part de liu dapeng
>Envoyé : mercredi 13 juin 2012 05:40
>À : Lee, Yiu
>Cc : [email-masked]
>>>who want to evaluate and adopt such technology. Intentional 
>hiding the
>>>truth
>>>for me is really bad.
>>>
>>>
>>>
>>>>>>> premises equipment or host, in order to restrict IP 
>address or port
>>>>>>> number
>>>>>> is no need to mention the CPE, apart from stating that 
>no additional
>>>>>>state
>>>>>> is required.
>>>>>

---

From: liu dapeng <[email-masked]>
Date: Wed, 13 Jun 2012 18:09:07 +0800

Dear Med:

> * state may exist in the customer premises side

=> I raised the concern yesterday for the term “may”

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

> * focus is on carrier-side stateless solutions

==>Carrier side stateless solution doesn’t mean solution doesn’t cover
CPE. We need to clarify definitely.

Regards,
Dapeng

-- 

------
Best Regards,
Dapeng Liu

---

From: <[email-masked]>
Date: Wed, 13 Jun 2012 13:42:16 +0200

Re-,

Please see inline.

Cheers,
Med 

>Envoyé : mercredi 13 juin 2012 12:09
>=> I raised the concern yesterday for the term "may"
>But didn't get response so far:
>
>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.). 

>==>Carrier side stateless solution doesn't mean solution doesn't cover

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.

>>>>>> is never the focal point. I think the current statement 
>"States may
>>>>>>still
>>>>>> exist in other equipments such as customer premises 
>equipment." is
>>>>>>enough.
>>>>>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 13 Jun 2012 11:43:56 -0400

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, [email-masked] wrote:
>> 2012/6/13, [email-masked]<[email-masked]>:
>>> Dear Dapeng,
>>>
>>> The current text says:
>>>
>>>> 2012/6/13, Lee, Yiu<[email-masked]>:
>>>>> Hi Dapeng,
>>>>>
>>>>> On 6/12/12 11:45 AM, "liu dapeng"<[email-masked]>  wrote:
>>>>>
>>>>>> 2012/6/12, Lee, Yiu<[email-masked]>:
>>>>>>> Hi Dapeng.,
>>>>>>>
>>>>>>> On 6/12/12 6:21 AM, "liu dapeng"<[email-masked]>  wrote:
>>>>>>>
>>>>>>>> 2012/6/12, Ole Trøan<[email-masked]>:

---

From: liu dapeng <[email-masked]>
Date: Thu, 14 Jun 2012 00:38:22 +0800

2012/6/13, [email-masked] <[email-masked]>:
> Med: You didn't answered my question. Pointing to a particular candidate
> solution is not a justification per se.

=>OK. there are great algorithms and working group agreed solutions
but you don't care.

 I can change "may" to "should" to
> please you but it really does make sense.

=> thanks

NAT is an optional feature in
> stateless solutions (e.g., host assigned with port restricted IPv4 address,

=>Please don't change subjects. We are talking about states.
In my proposal, recommended the text is "state should be ..."
NAT is only one sort of states. Port restriction is another.
I already clarify that two days ago.
http://www.ietf.org/mail-archive/web/softwires/current/msg04351.html

> host assigned with a full IPv4 address,

=>Please read last sentence in my proposal, that case was covered

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

CPE assigned with pool of IPv4
> addresses, etc.).

If operator could assign IPv4 pool which is big enought to locate one
public IPv4 address to each user, I would challenge the motivation per
se.
Even you could assign IPv4 pool, NAT state is unavoidable.

>    exist in other equipments such as customer premises equipment.

=> Depending on above, please change "may" to "should". And clarify
state on CPE and host.

(e.g., host assigned with port restricted IPv4 address, host assigned
with a full IPv4 address, CPE assigned with pool of IPv4 addresses,
etc.).
==> quite 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.

Regards,
Dapeng

-- 

------
Best Regards,
Dapeng Liu

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 13 Jun 2012 19:50:34 +0000

I prefer Tom suggestion. It is typical to have a NAT but not a must or
should.

---

From: <[email-masked]>
Date: Thu, 14 Jun 2012 07:53:09 +0200

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 

>De : Tom Taylor [mailto:[email-masked]] 
>Envoyé : mercredi 13 juin 2012 17:44
>Cc : liu dapeng; [email-masked]
>>> 2012/6/13, 
>[email-masked]<[email-masked]>:
>>>> Dear Dapeng,
>>>>
>>>> The current text says:
>>>>
>> 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.).
>>
>>>
>>>>>>> =>  I guess the audience is not only designer of 
>protocol, but also
>>>>>>> operators

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 14 Jun 2012 17:03:59 +0900

As a co-author, I'm comfortable with this.
--satoru

---

From: liu dapeng <[email-masked]>
Date: Thu, 14 Jun 2012 18:17:50 +0800

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

-- 

------
Best Regards,
Dapeng Liu

---

From: GangChen <[email-masked]>
Date: Thu, 14 Jun 2012 19:00:38 +0800

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 <[email-masked]>:
>> Thank for the proposal. I can update the text with your proposed wording
>> if
>> Dapeng is OK.
>>

---

From: liu dapeng <[email-masked]>
Date: Fri, 15 Jun 2012 05:50:40 +0800

Hi Gang,

This works for me, thanks.

Best Regards,
Dapeng

-- 

------
Best Regards,
Dapeng Liu

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 14 Jun 2012 22:00:18 +0000

Great! We will add it.