Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
On 7/30/2012 12:06 AM, mohamed.boucad...@orange.com wrote: 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. Sorry for a late reply. I feel that you need to change more. Here are my suggestions. The title is Multicast Extensions to DS-Lite Technique in Broadband Deployments. Could it be changed to something like Delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. Make the abstract something like: This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for for the delivery of multicast service offerings to DS-Lite serviced customers. In the Introduction, add a paragraph in front of the current 1st paragraph. Something like This document specifies a generic solution for delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution was developed with DS-Lite in mind, and we will discuss that below. The solution is however not limited to DS-Lite. Section 3, change beginning of the section to something like: This document focuses only subscription to an IPv4 multicast group and the delivery of IPv4-formatted content to IPv4 receivers over an IPv6-only network. In particular, only the following case is covered: Section 4, maybe change first paragraph to this: In the original DS-Lite specification [RFC6333], an IPv4-in-IPv6 tunnel is used to carry bidirectional IPv4 unicast traffic between a B4 and an AFTR. The solution specified in this document provides an IPv4-in-IPv6 encapsulation scheme to deliver unidirectional IPv4 multicast traffic from an mAFTR to an mB4. Stig Thanks. Cheers, Med -Message d'origine- De : Stig Venaas [mailto:s...@venaas.com] Envoyé : vendredi 27 juillet 2012 18:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org; softwires@ietf.org Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite Hi On 7/27/2012 4:48 AM, mohamed.boucad...@orange.com wrote: 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. 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 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. 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 Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org 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
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Stig, Thanks a lot for the comments and the proposed text, we'll consider that. Cheers, Jacni On 8/23/2012 Thursday 1:39 AM, Stig Venaas wrote: On 7/30/2012 12:06 AM, mohamed.boucad...@orange.com wrote: 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. Sorry for a late reply. I feel that you need to change more. Here are my suggestions. The title is Multicast Extensions to DS-Lite Technique in Broadband Deployments. Could it be changed to something like Delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. Make the abstract something like: This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for for the delivery of multicast service offerings to DS-Lite serviced customers. In the Introduction, add a paragraph in front of the current 1st paragraph. Something like This document specifies a generic solution for delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution was developed with DS-Lite in mind, and we will discuss that below. The solution is however not limited to DS-Lite. Section 3, change beginning of the section to something like: This document focuses only subscription to an IPv4 multicast group and the delivery of IPv4-formatted content to IPv4 receivers over an IPv6-only network. In particular, only the following case is covered: Section 4, maybe change first paragraph to this: In the original DS-Lite specification [RFC6333], an IPv4-in-IPv6 tunnel is used to carry bidirectional IPv4 unicast traffic between a B4 and an AFTR. The solution specified in this document provides an IPv4-in-IPv6 encapsulation scheme to deliver unidirectional IPv4 multicast traffic from an mAFTR to an mB4. Stig Thanks. Cheers, Med -Message d'origine- De : Stig Venaas [mailto:s...@venaas.com] Envoyé : vendredi 27 juillet 2012 18:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org; softwires@ietf.org Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite Hi On 7/27/2012 4:48 AM, mohamed.boucad...@orange.com wrote: 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. 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 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. 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 Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org 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
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
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 -Message d'origine- De : Stig Venaas [mailto:s...@venaas.com] Envoyé : vendredi 27 juillet 2012 18:29 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org; softwires@ietf.org Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite Hi On 7/27/2012 4:48 AM, mohamed.boucad...@orange.com wrote: 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. 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 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. 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 Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org 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/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Hi Behcet, Please see inline. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 27 juillet 2012 18:48 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite Hi Med, My comments below. Please do not take them personal. No offense. Please, please. On Fri, Jul 27, 2012 at 6:48 AM, mohamed.boucad...@orange.com wrote: 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. 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. 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. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
On Mon, Jul 30, 2012 at 7:04 AM, mohamed.boucad...@orange.com wrote: Hi Behcet, Please see inline. Cheers, Med -Message d'origine- De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] Envoyé : vendredi 27 juillet 2012 18:48 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; softwires@ietf.org Objet : Re: [softwire] #10: Nothing in common with DS-Lite Hi Med, My comments below. Please do not take them personal. No offense. Please, please. On Fri, Jul 27, 2012 at 6:48 AM, mohamed.boucad...@orange.com wrote: 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. 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. 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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
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:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org 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/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
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, mohamed.boucad...@orange.com wrote: 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:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org 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/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
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:wdec.i...@gmail.com] Envoyé : vendredi 27 juillet 2012 14:44 À : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : softwire issue tracker; draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org; softwires@ietf.org 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, mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote: 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:trac+softw...@tools.ietf.orgmailto:trac%2bsoftw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.orgmailto:draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.orgmailto:sarik...@ieee.org Cc : softwires@ietf.orgmailto:softwires@ietf.org 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/ ___ Softwires mailing list Softwires@ietf.orgmailto:Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Hi On 7/27/2012 4:48 AM, mohamed.boucad...@orange.com wrote: 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. 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 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. 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 Cheers, Med -Message d'origine- De : softwire issue tracker [mailto:trac+softw...@tools.ietf.org] Envoyé : vendredi 13 juillet 2012 23:55 À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; sarik...@ieee.org Cc : softwires@ietf.org 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/ ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Hi Med, My comments below. Please do not take them personal. No offense. Please, please. On Fri, Jul 27, 2012 at 6:48 AM, mohamed.boucad...@orange.com wrote: 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. 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 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. So you agree that it is a generic solution and nothing in common with DS-Lite. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
