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

From: Stig Venaas <[email-masked]>
Date: Wed, 22 Aug 2012 10:39:01 -0700

On 7/30/2012 12:06 AM, [email-masked] 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:[email-masked]]
>> Envoyé : vendredi 27 juillet 2012 18:29
>> À : 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
>>
>> Hi
>>
>> On 7/27/2012 4:48 AM, [email-masked] 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:[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/>
>>>>
>>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>
>>
>

---

From: Jacni Qin <[email-masked]>
Date: Thu, 23 Aug 2012 12:19:42 +0800

Stig,

Thanks a lot for the comments and the proposed text, we'll consider that.

Cheers,
Jacni