Subject: [Softwires] 4rd mapping rule separation

From: Satoru Matsushima <[email-masked]>
Date: Fri, 19 Aug 2011 10:08:23 +0900

Hello Remi-san,

I've found this mail now.

On 2011/07/16, at 22:55, Rémi Després wrote:

> Hi all,
> 
> 1.
> Being active in the IETF community has been overall enjoyable but, for various personal reasons including financial,
> I will no longer contribute as much as before on v4/v6 transition solutions (6rd, 4rd, 6a44).

I'd happy to see you now on the list, more actively than before.:)

--snip--

> 2.
> Both the proposed translation-based solution (draft-murakami-softwire-4v6-translation) and the proposed tunnel-based solution (draft-murakami-softwire-4rd) use the v4v6 address mapping algorithm, that of 4rd.
> 
> It would therefore be advantageous to have an autonomous I-D on the 4rd address mapping, and two I-D's pointing to it (for the translation-based and for the tunnel-based solution).
> 

I think that it is interesting idea. I heard you're personally work on that with some authors. On the other hand, I don't heard there is consensus among current 4rd authors for the separation. Do you have enough discussion on this? 

Since collided two documents for same specification would make much confusion for people, I recommend you to collaborate with your friend. 

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Aug 2011 09:58:38 +0200

> I'd happy to see you now on the list, more actively than before.:)

Thanks.
(For other personal reasons, which I shared with you privately, I decided to come back and to meet meet financial expenses at least until the Taipei meeting.

Hope it will be useful to the community.

> I think that it is interesting idea.

Thanks.
Several supports on the list, with no opposition, looks like a good start for a rough consensus.

> I heard you're personally work on that with some authors.

Indeed, as I have written to you, a draft is coming, now very soon.

> On the other hand, I don't heard there is consensus among current 4rd authors for the separation.

Fair enough.
A draft submitted under responsibility is its authors is a practical ways to test consensus.
 
> Do you have enough discussion on this? 

I think so.
I know that some, although expressing nothing against the idea, would prefer to wait and see. 
But others believe that, concerning the best way to structure drafts, the earlier is the better.

> Since collided two documents for same specification would make much confusion for people,

It isn't difficult, in my understanding, to replace sec. 5 of the Encapsulation draft by a pointer to the stateless-address-mapping draft.

As you know, I personally believe that the Encapsulation method of a sufficient tunneling method for stateless operation. (It is more transparent than the double-translation tunneling method, and adds header overheads that are small enough in practice).
Yet, I understand that (at least for the time being) there is no consensus on that. 
Both proposals will therefore be discussed. 

Whether Encapsulation and Double-translation methods will remain in separate drafts or might be regrouped in a single one including their comparison is, as far as I am concerned, an open question (neither in favor nor against). 

> I recommend you to collaborate with your friend.

No need to recommend it!
I have always worked on subjects I find important with whoever is welcoming my cooperation ;-).

To conclude, I do hope you will appreciate the 4rd Address-Mapping draft as much as its authors do, and that it will be a good basis for our further collaboration.

Cheers,
RD

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 19 Aug 2011 17:15:21 +0900

> I know that some, although expressing nothing against the idea, would prefer to wait and see.

I haven't heard so.

> But others believe that, concerning the best way to structure drafts, the earlier is the better.

IMHO, document structure is a last discussion item of standardization.

> It isn't difficult, in my understanding, to replace sec. 5 of the Encapsulation draft by a pointer to the stateless-address-mapping draft.

The problem is, there's no consensus before you post the draft. Why do
you think they do so?

> Both proposals will therefore be discussed.

We can discuss well with current drafts, no need alternatives.
Without collaboration, it must be a troublemaker.

> I have always worked on subjects I find important with whoever is welcoming my cooperation ;-).

Why don't you introduce them to us?

> To conclude, I do hope you will appreciate the 4rd Address-Mapping draft as much as its authors do, and that it will be a good basis for our further collaboration.

I don't appreciate. I continue to recommend you to collaborate with
current 4rd draft authors.

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Aug 2011 11:17:59 +0200

>> I know that some, although expressing nothing against the idea, would prefer to wait and see.

If I misinterpreted what I saw, that's even better.

> IMHO, document structure is a last discussion item of standardization.

Not from my experience, but different views are possible..

> The problem is, there's no consensus before you post the draft. Why do

They do, of course, what they wish.
I certainly don't pretend to impose anything!
I was just making a suggestion. 

> We can discuss well with current drafts, no need alternatives.

Sure, no problem.
 
> Why don't you introduce them to us?

I suppose you refer to co-authors of the draft.
Since we are very busy closing this phase, wishing to share asap our proposal with the WG, I preferred to avoid being distracted from that goal until the draft is posted.

It should be now only a matter of hours.

> I don't appreciate.

Sorry to hear that before you have seen it. 

> I continue to recommend you to collaborate with

Now, since you insist, let one point be clear. In Quebec, the presenter of the 4rd draft mentioned my contribution to 4rd to only say that the previous 4rd draft had been submitted to Intarea "because Remi wanted it despite a different view from others". This is as you know completely false, and is an offense. Also, one of his slides has "4rd aka Stateless DS-lite". He knows, as you know, that I had expressed strong opposition to this badly reductive view (DS lite is hub and spoke, has no NAT in CPE's, ...). I prefer to collaborate with co-authors who have respect for my contributions.

I was hoping not to have to say that, and hope I won't have to expand.
But I am tired of being told what to do, an not to do, by a group that accepts my being publicly humiliated.

Your contribution to progress of 4rd in IETF deserves great recognition, and nothing will change my mind on this. 
I deserve respect too.

Sorry to have felt obliged to give this explanation.
Hope future will be brighter.

Regards,
RD

---

From: Tetsuya Murakami <[email-masked]>
Date: Fri, 19 Aug 2011 02:19:33 -0700

Hi Satoru-san,

Please see my comments inline.

> I think that it is interesting idea. I heard you're personally work on that with some authors. On the other hand, I don't heard there is consensus among current 4rd authors for the separation. Do y…

From my perspective as the co-author of 4rd draft, I don't think we have enough discussion on this separation idea. So, I think it is good to have some discussion for this before deciding to create a separated document for only 4rd mapping rule.

From my perspective, I prefer to create a single document for 4rd because it looks for me to be very understandable for everyone.

Also, right now we have two draft as shown below.

draft-murakami-softwire-4rd
draft-murakami-softiwire-4v6-translation

I think it might be good to combine these 2 drafts to create one unified document for 4rd specification. Note that this idea has been already proposed among authors. Anyway, in order to decide a document structure, I think we need to discuss about this more to figure out the pros & cons of creating the separated draft for 4rd mapping rule.

> Since collided two documents for same specification would make much confusion for people, I recommend you to collaborate with your friend. 

 +1
Agreed. We need to discuss about this more.

Thanks,
Tetsuya Murakami

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

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Aug 2011 08:18:45 -0400

Particularly when targeting the consumer appliance space,  fewer documents are better than many. Softwires should be working to converge on a single concise and clear RFC for the "stateless ds-lite" mode of operation.  

- Mark

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Aug 2011 08:57:40 -0400

On 2011-08-19 05:19, Tetsuya Murakami wrote:
> I think it might be good to combine these 2 drafts to create one unified document for 4rd specification.

The problem I see with this is:

- We (the IETF) might need to specify both translation and encapsulation
protocols, because they have different applicability. (Still needs to be
decided.)

- Operators will choose translation or encapsulation for each
deployment, probably not both.

- Implementations of translation vs encapsulation will probably be very
different. I see this as leading to different "products" or "feature
sets" targeted to different markets. For example 3GPP products might
want to implement translation while broadband products might want to
implement encapsulation.

So in the end, I see an operator A needing the 4rd-Translation solution
and operator B needing the 4rd-Encapsulation solution. This fits nicely
with two different RFCs, is more easily cited in RFPs, etc.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 19 Aug 2011 09:22:36 -0400

I would agree with Mark on this %100.  The v6 space is already confusing enough for some due to the number of options; lets not continue that.

	--Tom

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 19 Aug 2011 09:25:37 -0400

+1. 

The RFP angle is an important one, Simon.

Cheers,
Rajiv

Sent from Phone....

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Aug 2011 11:11:27 -0400

On Aug 19, 2011, at 5:17 AM, Rémi Després wrote:

> Also, one of his slides has "4rd aka Stateless DS-lite". He knows, as you know, that I had expressed strong opposition to this badly reductive view (DS lite is hub and spoke, has no NAT in CPE's, ...). 

Let me fill you in on some history.

The term "Dual Stack Lite" came into being during a discussion at a cafe between Alain Durand and I. It was June 2008, and Alain was in Paris for the ICANN meeting while still working for Comcast. We had been discussing the various pros and cons of tunneling vs. dual-translation for a while. Alain was emphasizing that what was of most importance to him as an ISP, was that he not be burdened with provisioning IPv4 within the ISP network itself. However, in all cases the service to the subscriber was intended to be dual-stack. So: "Dual-stack" service but "lighter" on the ISP in terms of management and provisioning. Thus the term "dual-stack lite" was born. 

From the beginning the "lite" term was about having less IPv4 in the access network for the operator to manage and provision, while still providing dual-stack service to the subscriber. 4rd fits that, as does RFC 6333. The solution details are just that - details. 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Aug 2011 11:21:38 -0400

When the RFP is coming from Best Buy for a consumer device, you want fewer alternatives.

- Mark

---

From: Simon Perreault <[email-masked]>
Date: Fri, 19 Aug 2011 11:30:47 -0400

> When the RFP is coming from Best Buy for a consumer device, you want fewer alternatives.

That's overly simplifying.

I would expect the standard bodies such as Cable Labs, BBF, 3GPP, etc.
to specify applicability of translation vs encapsulation to their
scenarios. In the end, only one would be needed in each case.

I'd be surprised if I ever see a home router implementing both.

Simon

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 19 Aug 2011 11:44:53 -0400

Precisely. Fewer alternatives means cheaper, simpler hardware that is ultimately required to run the software necessary to support the features.   A myriad of options whether complex or not, is not that.

	--Tom

---

From: Satoru Matsushima <[email-masked]>
Date: Sat, 20 Aug 2011 00:48:28 +0900

> with two different RFCs, is more easily cited in RFPs, etc.

No problem. We usually cite part of RFC section/subsection to specify what we want.
Thanks for your much taking care of your customers.

cheers,
--satoru

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Aug 2011 09:36:30 -0700 (PDT)

Hi Marc,
I am having trouble to see how this thing could be stateless?
Also I don't see why we should, in view of NAT64 which is already standardized and there are implementations, why not use it?

Of course no offense to my friend Xing Li.

Regards,

Behcet

> Particularly when targeting the consumer appliance space,  fewer documents are 
> better than many. Softwires should be working to converge on a single concise 
> and clear RFC for the "stateless ds-lite" mode of operation.  
> 
> - Mark
>

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Aug 2011 18:37:10 +0200

> When the RFP is coming from Best Buy for a consumer device, you want fewer alternatives.

Having the address mapping part separated from the tunneling part doesn't increase the number of alternatives, does it?

To reduce the number of alternatives, encapsulation, which is completely transparent in all cases (shared and non shared addresses) would be the natural choice, but if two solutions are found better for different use cases, double translation (à la dIVI or 4rd-T which are essentially the same) also makes sense.

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Aug 2011 19:08:58 +0200

> The term "Dual Stack Lite" came into being during a discussion at a cafe between Alain Durand and I. It was June 2008, and Alain was in Paris for the ICANN meeting while still working for Comcast.…

That's a good clarification.

But in the mean time, DS-lite got specified in an RFC that won't change.
RFC6333 says:
- "Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT)."
- "the Dual-Stack Lite model is  built on IPv4-in-IPv6 tunnels to cross the network to reach a carrier-grade IPv4-IPv4 NAT (the AFTR)," 
- etc.

> From the beginning the "lite" term was about having less IPv4 in the access network for the operator to manage and provision, while still providing dual-stack service to the subscriber. 4rd fits th…

The devil is in details.

Too bad 4rd wasn't invented before DS-lite. It would have better deserved the "lite" qualifier, but that's not how things happened.

Because of what RFC6333 says, suggesting NOW that solutions that don't need NATs are variants of DS-lite is a sure way to confuse people.

I do hope this discussion will now stop: there are so many technical "details" that need to reach common understanding, and agreement. 
In any case thank you for the really interesting explanation on history.

Cheers.
RD

---

From: Tina TSOU <[email-masked]>
Date: Fri, 19 Aug 2011 20:53:36 +0000

+1.
It is fair enough.
But the operators will probably meet more difficulties to change v4 CPE than to change v6 CPE. (Maybe irrelevant to this thread.)

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv Asati (rajiva)
Sent: Friday, August 19, 2011 6:26 AM
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [Softwires] 4rd mapping rule separation

+1. 

Cheers,
Rajiv

Sent from Phone....

---

From: Nejc Škoberne <[email-masked]>
Date: Sat, 20 Aug 2011 00:22:11 +0100

Dear Rémi,

> Whether Encapsulation and Double-translation methods will remain in separate drafts or might be regrouped in a single one including their comparison is, as far as I am concerned, an open question (…

Not being in favor of a wide palette of different documents for very 
similar things, I am very inclined to the idea of merging them into
one document.

Nejc

---

From: Nejc Škoberne <[email-masked]>
Date: Sat, 20 Aug 2011 01:04:12 +0100

+1

Nejc

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Aug 2011 21:55:31 -0400

>> Because of what RFC6333 says, suggesting NOW that solutions that don't need NATs are variants of DS-lite is a sure way to confuse people.

Then we're already confused:

http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Aug 2011 22:05:19 -0400

> But in the mean time, DS-lite got specified in an RFC that won't change.

But RFC's get updated all the time, as does terminology. Adding an adjective to something that is well understood to indicate that it can serve the same purpose but in a different way is quite useful during the introduction of that technology. Think "Horseless Carriage" 

http://en.wikipedia.org/wiki/Retronym

A retronym is a type of neologism that provides a new name for an object or concept to differentiate the original form or version of it from a more recent form or version.[1] The original name is most often augmented with an adjective (rather than being completely displaced) to account for later developments of the object or concept itself. Much retronymy is driven by advances in technology.

- Mark

---

From: Rémi Després <[email-masked]>
Date: Sat, 20 Aug 2011 09:20:05 +0200

> http://tools.ietf.org/html/draft-boucadair-softwire-cgn-bypass-03

Could you explain more which confusion you are referring to?

RD

---

From: Mark Townsley <[email-masked]>
Date: Sat, 20 Aug 2011 05:46:55 -0400

> Could you explain more which confusion you are referring to?

Nejc suggested that DS-Lite without NATs (which I assumed meant without a CGN NAT, aka AFTR) would be confusing at this stage.

The title of the referenced document is "Procedure to bypass DS-Lite AFTR"

- Mark

---

From: Rémi Després <[email-masked]>
Date: Sat, 20 Aug 2011 15:04:00 +0200

>> Le 20 août 2011 à 03:55, Mark Townsley a écrit :
...
>>>  we're already confused:

> The title of the referenced document is "Procedure to bypass DS-Lite AFTR"

Indeed, but so what?
(I don't see which confusion would result from using "4rd address mapping" to designate the stateless mapping called that way so far.)

RD

---

From: Rémi Després <[email-masked]>
Date: Sun, 21 Aug 2011 07:50:31 +0200

Mark,

Interesting definition of "retronym".

It remains, though, that an analogue clock, the example given in the given reference) is a clock variant (a device for measuring time).
A 4rd-encapsulation solution is in no way a DS-lite variant ("built on a tunnel to reach a CGN").

It would be nice, therefore, if the idea of using "stateless DS-lite" as a valuable substitute to "4rd" would no longer need to be discussed.

Thanks,
RD

Le 20 août 2011 à 04:05, Mark Townsley a écrit :

> Aug 19, 2011, at 1:08 PM, Rémi Després wrote:
>> 
...

---

From: Mark Townsley <[email-masked]>
Date: Sun, 21 Aug 2011 09:37:48 -0400

> (I don't see which confusion would result from using "4rd address mapping" to designate the stateless mapping called that way so far.)

I'm not sure how many ways I can say this.

The comment I was responding to was whether it was "confusing" to take ds-lite and remove the centralized CGN portion while still calling it ds-lite. The point in referencing the other document is that ds-lite itself has already done this by having a mode that removes the CGN.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sun, 21 Aug 2011 10:19:12 -0400

Remi, I really do not understand the aversion to classifying 4rd as a stateless version of ds-lite. I'm not suggesting getting rid of the "4rd" name, this is really just a classification. 

Let's look at the example of "clock" you brought up. The word "clock" comes from  "clocc, clokke, cloque, cloch", likely Celtic or Latin origin, meaning "bell." If you look at mechanism rather than how people actually use the device, it makes no sense whatsoever for a "digital time indicator" made with LEDs and run with semiconductors to be called something that means "bell". Even so, everyone who knew what a clock was at the time could immediately understand what a "digital clock" was the moment (no pun intended) they saw one. Teaching the world an entire new "Electronic Digital Time Indicator (EDTI)" term would have been futile. Hence the "analog clock" retronym was born, and today you have an "analog or digital" setting for your clock on your Mac.

It takes me about 30 seconds to describe at a high-level what 4rd is to someone who already understands ds-lite by referring to it as "a stateless version of ds-lite". That's a good thing. 

- Mark

Ref: http://www.etymonline.com/index.php?term=clock

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Aug 2011 07:26:42 -0400

Mark Townsley wrote, on 08/21/2011 10:19 AM:
> It takes me about 30 seconds to describe at a high-level what 4rd is to someone
> who already understands ds-lite by referring to it as "a stateless version of
> ds-lite". That's a good thing. 

To someone who already understands 6rd:

"4rd is to IPv4 what 6rd is to IPv6."

Simon

---

From: Nejc Škoberne <[email-masked]>
Date: Mon, 22 Aug 2011 17:19:46 +0100

Dear Mark,

>>>>> Because of what RFC6333 says, suggesting NOW that solutions that 
>>>>> don't need NATs are variants of DS-lite is a sure way to confuse 
>>>>> people.
>>>
> Nejc suggested that DS-Lite without NATs (which I assumed meant without 
> a CGN NAT, aka AFTR) would be confusing at this stage.
> 

For the record, it was Remi who suggested that, I just +1-ed it.

I don't think that the referenced draft really causes confusion, since it 
clearly states what is the "nominal behavior" of DS-Lite: using NAT44 in
the AFTR.

That said, I would be happy too if we could just make two big groups of
all these mechanisms, like "stateful" and "stateless" DS-Lite. However, I
think that is easier said than done. What about stateful A+P solutions like
draft-cui-softwire-b4-translated-ds-lite-01? Is this then stateful or 
stateless DS-Lite?
Compared to 4rd or dIVI, this one has customer-state in the core and if we
consider static port allocation in CGN with DS-Lite, we end up with RFC6333
and draft-cui-softwire-b4-translated-ds-lite-01 very similar amount
of state for both mechanisms. Just the location of the NAPT44 is different.

Nejc