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.com<mailto: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<mailto:trac%2bsoftw...@tools.ietf.org>] >Envoyé : vendredi 13 juillet 2012 23:55 >À : >draft-ietf-softwire-dslite-multic...@tools.ietf.org<mailto:draft-ietf-softwire-dslite-multic...@tools.ietf.org>; >sarik...@ieee.org<mailto:sarik...@ieee.org> >Cc : softwires@ietf.org<mailto: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<mailto:Softwires@ietf.org> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
