Subject: Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite

From: <[email-masked]>
Date: Fri, 27 Jul 2012 13:48:34 +0200

Dear all,

I really don't understand this issue. 
It is even misplaced to have this comment at this stage, since this is a document which has been adopted by the WG and the solution it specifies is the same as the one reviewed by the WG prior to its adoption (i.e., since April 2011). 

Anyway, below a tentative to explain the overall rationale: 

DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be first seen as an IP connectivity service. This service can be defined as follows:
 
* delivery of IPv4 connectivity over an IPv6-capable network.
* delivery of native IPv6 connectivity
* DS-Lite serviced customers are assigned with IPv6 prefix and no IPv4 address.

The unicast portion of the service is defined in RFC6333 and is implemented using a tunnel + CGN.
 
The multicast portion of the service is defined in draft-ietf-softwire-dslite-multicast. This portion of the service can be defined as follows:

* delivery of IPv4 multicast content using native IPv6 multicast capabilities
* delivery of native IPv6 multicast content

The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services.

A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the change of scope of use cases. We didn't had the ambition to define a generic solution when we wrote this draft, we focused mainly on the DS-Lite context. If there is no objection from the WG, we can implement that change. 

Cheers,
Med

>-----Message d'origine-----
>De : softwire issue tracker [mailto:[email-masked]] 
>Envoyé : vendredi 13 juillet 2012 23:55
>À : [email-masked]; 
>[email-masked]
>Cc : [email-masked]
>Objet : Re: [softwire] #10: Nothing in common with DS-Lite
>
>#10: Nothing in common with DS-Lite
>
>Changes (by sarikaya@.):
>
> * owner:  sarikaya@. => draft-ietf-softwire-dslite-multicast@.
>
>
>-- 
>-------------------------+-------------------------------------
>------------
> Reporter:  sarikaya@.   |       Owner:  draft-ietf-softwire-dslite-
>     Type:  defect       |  multicast@.
> Priority:  major        |      Status:  new
>Component:  dslite-      |   Milestone:  milestone1
>  multicast              |     Version:  2.0
> Severity:  In WG Last   |  Resolution:
>  Call                   |
> Keywords:  tunneling    |
>-------------------------+-------------------------------------
>------------
>
>Ticket URL: 
><http://trac.tools.ietf.org/wg/softwire/trac/ticket/10#comment:1>
>softwire <http://tools.ietf.org/softwire/>
>
>

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 27 Jul 2012 14:44:01 +0200

Med,

the point is that the DS-Lite (CGN AFTR) solution is not necessary to be
deployed for the multicast solution described here to work.
As to how this ended up being charterd in Softwire I don't know and IMO it
doesn't make much sense.

Regards,
Woj.

On 27 July 2012 13:48, <[email-masked]> wrote:

> It is even misplaced to have this comment at this stage, since this is a
> document which has been adopted by the WG and the solution it specifies is
> the same as the one reviewed by the WG prior to its adoption (i.e., since
> April 2011).
>
> DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should be
> first seen as an IP connectivity service. This service can be defined as
> follows:
>
> The multicast portion of the service is defined in
> draft-ietf-softwire-dslite-multicast. This portion of the service can be
> defined as follows:
>
> The solution proposed in draft-ietf-softwire-dslite-multicast is designed
> to allow DS-Lite serviced customers be delivered IPv4 multicast services.
>
> A side note, I agree with Stig and Woj the proposed solution can be
> generalized to cover any 4-6-4 scenario. This can be done easily by
> updating the draft (abstract and introduction) to reflect the change of
> scope of use cases. We didn't had the ambition to define a generic solution
> when we wrote this draft, we focused mainly on the DS-Lite context. If
> there is no objection from the WG, we can implement that change.
>
> Cheers,
> Med
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 15:14:56 +0200

Re-,

Yes, the CGN is not required. This design choice is motivated in the draft (read the Introduction text).

What is the issue then?

If you are saying this is a generic solution and it does not apply only to ds-lite, this point is taken (see the note below).

Cheers,
Med

________________________________
De : Wojciech Dec [mailto:[email-masked]]
Envoyé : vendredi 27 juillet 2012 14:44
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : softwire issue tracker; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite

Med,

the point is that the DS-Lite (CGN AFTR) solution is not necessary to be deployed for the multicast solution described here to work.
As to how this ended up being charterd in Softwire I don't know and IMO it doesn't make much sense.

Regards,
Woj.

On 27 July 2012 13:48, <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Cheers,
Med

>De : softwire issue tracker [mailto:[email-masked]<mailto:[email-masked]>]
>À : [email-masked]<mailto:[email-masked]>;
>[email-masked]<mailto:[email-masked]>
>Cc : [email-masked]<mailto:[email-masked]>
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 27 Jul 2012 15:19:30 +0200

On 27 July 2012 15:14, <[email-masked]> wrote:

> **
> If you are saying this is a generic solution and it does not apply only to
> ds-lite, this point is taken (see the note below
>

Well, so what's not clear about the issue? You appear to recognize it.

-Woj.

> ).
>
> Cheers,
> Med
>
>  ------------------------------
> *De :* Wojciech Dec [mailto:[email-masked]]
> *Envoyé :* vendredi 27 juillet 2012 14:44
> *À :* BOUCADAIR Mohamed OLNC/NAD/TIP
> *Cc :* softwire issue tracker;
> [email-masked]; [email-masked];
> [email-masked]
> *Objet :* Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
>
> Med,
>
>> DS-Lite model can not be reduced to a CGN/AFTR + tunnel. DS-Lite should
>> be first seen as an IP connectivity service. This service can be defined as
>> follows:
>>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 27 Jul 2012 09:29:26 -0700

Hi

> The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services.

I think I agree with the above.

> A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the…

This is all I've been asking for. An update to abstract/introduction to
indicate that it is a generic solution. And then say that DS-Lite is one
of the use-cases. You can even say that the solution was developed to
solve the problem for DS-Lite. All I want is to make it clear that it is
a generic solution.

Stig

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Jul 2012 11:48:19 -0500

Hi Med,

My comments below. Please do not take them personal. No offense.
Please, please.

> The solution proposed in draft-ietf-softwire-dslite-multicast is designed to allow DS-Lite serviced customers be delivered IPv4 multicast services.

These are religious arguments.
Translation multicast integrates well with several IPv6 transition
technologies. MAP-T is one. NAT64 is another, 4rd also. But not MAP-E.
Let's use translation multicast with those technologies.

No matter what you want to believe, DS-Lite is a tunneling technology.
Why do you think DS-Lite was standardized in Softwires WG? Same thing
with 6rd.
Remember softwire means tunnel.
Translation has only been added to Softwires WG recently after Behave
WG stopped working on it.

> A side note, I agree with Stig and Woj the proposed solution can be generalized to cover any 4-6-4 scenario. This can be done easily by updating the draft (abstract and introduction) to reflect the…

So you agree that it is a generic solution and nothing in common with DS-Lite.

Regards,

Behcet

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 09:06:16 +0200

Hi Stig,

Wouldn't be sufficient enough to add this sentence to the abstract and the Introduction:

   "The proposed solution can be deployed for other 4-6-4 use cases."

Thanks. 

Cheers,
Med 

>De : Stig Venaas [mailto:[email-masked]] 
>Envoyé : vendredi 27 juillet 2012 18:29
>Cc : softwire issue tracker; 
>[email-masked]; 
>[email-masked]; [email-masked]
>> It is even misplaced to have this comment at this stage, 
>since this is a document which has been adopted by the WG and 
>the solution it specifies is the same as the one reviewed by 
>the WG prior to its adoption (i.e., since April 2011).
>>
>> DS-Lite model can not be reduced to a CGN/AFTR + tunnel. 
>DS-Lite should be first seen as an IP connectivity service. 
>This service can be defined as follows:
>>
>draft-ietf-softwire-dslite-multicast. This portion of the 
>service can be defined as follows:
>>
>> The solution proposed in 
>draft-ietf-softwire-dslite-multicast is designed to allow 
>DS-Lite serviced customers be delivered IPv4 multicast services.
>
>> A side note, I agree with Stig and Woj the proposed solution 
>can be generalized to cover any 4-6-4 scenario. This can be 
>done easily by updating the draft (abstract and introduction) 
>to reflect the change of scope of use cases. We didn't had the 
>ambition to define a generic solution when we wrote this 
>draft, we focused mainly on the DS-Lite context. If there is 
>no objection from the WG, we can implement that change.
>

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 14:04:32 +0200

Hi Behcet,

Please see inline. 

Cheers,
Med 

>De : Behcet Sarikaya [mailto:[email-masked]] 
>Envoyé : vendredi 27 juillet 2012 18:48
>[email-masked]; [email-masked]

Med: I failed to get the point you are trying to make. Do you want draft-ietf-softwire-dslite-multicast to cover the translation case also?
Let me remind that draft-ietf-softwire-dslite-multicast covers only the encapsulation scheme: IPv4 multicast packets are encapsulated in IPv6 ones.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 30 Jul 2012 18:26:20 -0500

On Mon, Jul 30, 2012 at 7:04 AM,  <[email-masked]> wrote:
> Med: I failed to get the point you are trying to make. Do you >want draft-ietf-softwire-dslite-multicast to cover the translation
>case also?

Really?
Take a look at Fig. 1,
IGMP Report (join) received at so-called mB4 becomes MLD Report sent upstream.

How is this encapsulation?

> Let me remind that draft-ietf-softwire-dslite-multicast covers only the encapsulation scheme: IPv4 multicast packets are encapsulated in IPv6 ones.

You are talking about multicast data, and it is curious why you are doing it?

Anyway, what I want is clear:
draft-sarikaya-softwire-dslitemulticast-01.txt
is the solution that integrates with DS-Lite and that is the solution
we need :-).

Regards,

Behcet