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." Thanks. Cheers, Med >-----Message d'origine----- >De : Stig Venaas [mailto:s...@venaas.com] >Envoyé : vendredi 27 juillet 2012 18:29 >À : 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 > >Hi > >On 7/27/2012 4: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. > >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:trac+softw...@tools.ietf.org] >>> Envoyé : vendredi 13 juillet 2012 23:55 >>> À : draft-ietf-softwire-dslite-multic...@tools.ietf.org; >>> sarik...@ieee.org >>> Cc : 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 >> https://www.ietf.org/mailman/listinfo/softwires >> > > _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
