Well, from the so many mails below it is clear that draft-ietf-softwire-dslite-multicast-02 is anything but multicast extensions document for DS-Lite.
Anyway we need to put this into the issue tracker as Suresh asked. Behcet On Mon, Jul 2, 2012 at 12:57 PM, Stig Venaas <[email protected]> wrote: > Hi > > > On 7/2/2012 9:00 AM, Jacni Qin wrote: >> >> Hi Stig, >> >> Inline please, >> >> On 6/29/2012 Friday 1:20 AM, Stig Venaas wrote: >>> >>> On 6/27/2012 10:24 PM, Jacni Qin wrote: >>>> >>>> Hi Stig, >>>> >>>> Thanks for you comments and support, please see below inline. >>>> >>>> On 6/28/2012 Thursday 4:08 AM, Stig Venaas wrote: >>>>> >>>>> FWIW, here is my take on this. >>>>> >>>>> >>>>> On 6/27/2012 8:30 AM, Behcet Sarikaya wrote: >>>>> [...] >>>>>> >>>>>> That's a big IF. Not everybody has to do it the same way. >>>>>> >>>>>> The solution in draft-ietf-softwire-dslite-multicast-02 >>>>>> builds itself something without considering what DS-Lite is doing. >>>>>> As I told you before, DS-Lite unicast is a tunneling technology. If >>>>>> you don't like it it is not DS-Lite multicast to fix this. >>>>>> How many times this should be reminded to you? >>>>> >>>>> >>>>> draft-ietf-softwire-dslite-multicast-02 is a generic solution, nothing >>>>> specific to DS-Lite, and I've been saying that the draft should be >>>>> updated to reflect that. >>>>> >>>>> However, even though it is generic, I think it is a good solution for >>>>> use in DS-Lite deployments (in addition to many other deployments). >>>> >>>> As discussed in the previous messages of the thread, our motive is solve >>>> the problems >>>> for those who want multicast in their DS-Lite deployment. >>>> So we limited the scope. Where the DS-Lite is not deployed, it doesn't >>>> apply. >>> >>> >>> I understand that the motive is to have a solution for DS-Lite, but IMO >>> the key part is the solution itself. I think you should focus on the >>> solution and then discuss how it can be used in several scenarios, where >>> DS-Lite is one of them. >> >> Yes, we're focusing on the solution itself, and there is a Problem >> Statement draft >> discussing several scenarios during the transition of multicast. ;-) >> >>> >>> Wouldn't it be a shame if people have a need for your solution, but are >>> not aware of it, or doesn't consider it because they think it only >>> applies to DS-Lite? >>> >>> Don't you agree that we should generally find good generic solutions and >>> describe them as such? We don't want to write basically identical docs >>> for each scenario. And in the worst case instead of having a single good >>> solution, having solutions that are only almost identical, maybe >>> requiring multiple slightly different implementations to solve each of >>> the problems, where a single solution and a single implementation would >>> be sufficient? >>> >>> As a general principle when you come up with a solution to a problem, >>> don't you try to see what else it can solve, and try to present it as >>> a solution to all the problems? At least that is always my thinking. >> >> I totally understand your point and logic. >> >> In addition to the motive, based on lessons learnt from what we did for >> unicast solutions, it's been concluded that working on the scenarios with >> high priority is a better choice. So we did that following the WG's >> charter. > > > I think you could make it more generic by changing the title, and > minor changes to abstract/intro. > > You could say that this was designed to allow for multicast in DS-Lite, > but that it also applies to other cases where you need to provide IPv4 > multicast through an IPv6 multicast network or something like that. > > >> We ever know trying a single solution for all is not a good idea. > > > Yes, but your solution is more useful than just DS-Lite. You have no > dependency of DS-Lite, right? > > Stig > > >> And as mentioned above, I think the draft, >> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00 >> will say clearly about the background, our choices, what led to this, >> and will >> help people to analyze their requirements/scenarios, then to find an >> appropriate solution. >> >>> >>> It looks like we may disagree on this. I'm hoping I can make people see >>> the merits of making general solutions and presenting them as such. At >>> least for me, that seems like a good thing to strive for. >> >> Ideally, I like general solutions as well. While for transition, as for >> unicast, I believe >> we should try another way. :-) >> >>> >>> I know I've been repeating myself several times in emails to the list. >>> I feel strongly about this as a general principle. I don't know what >>> more I can say to stress my point though. >> >> Thanks for your patience and the discussion anyway, it helps for the >> clarifications. >> >> >> Cheers, >> Jacni >> >>> >>> Stig >>> >>>> >>>> If some pieces of the approach can be reused in the future, to solve the >>>> multicast issues in >>>> other deployments, that'd be good. >>>> While personally, I'd prefer we stay focus on the currently scenario. >>>> Extensions if needed, may be raised respectively for other deployments. >>>> More are detailed in, >>>> http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. >>>> >>>> >>>> Cheers, >>>> Jacni >>>>> >>>>> >>>>> Whether additional solutions are needed for DS-Lite is something the >>>>> WG should consider. Maybe it already has, I haven't paid enough >>>>> attention. >>>>> >>>>> Stig >>>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Softwires mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/softwires >>>> >>> >>> >>> >>> >> >> > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
