On Mon, Jul 30, 2012 at 7:04 AM, <[email protected]> wrote: > Hi Behcet, > > Please see inline. > > Cheers, > Med > >>-----Message d'origine----- >>De : Behcet Sarikaya [mailto:[email protected]] >>Envoyé : vendredi 27 juillet 2012 18:48 >>À : BOUCADAIR Mohamed OLNC/NAD/TIP >>Cc : softwire issue tracker; >>[email protected]; [email protected] >>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, <[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. >>> >> >>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 [email protected] https://www.ietf.org/mailman/listinfo/softwires
