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
