On 7/30/2012 12:06 AM, [email protected] 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 protected]]
Envoyé : vendredi 27 juillet 2012 18:29
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : softwire issue tracker;
[email protected];
[email protected]; [email protected]
Objet : Re: [Softwires] [softwire] #10: Nothing in common with DS-Lite
Hi
On 7/27/2012 4:48 AM, [email protected] 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 protected]]
Envoyé : vendredi 13 juillet 2012 23:55
À : [email protected];
[email protected]
Cc : [email protected]
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 protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
