Subject: Re: [Softwires] [SPAM] Re: WG last call on draft-ietf-softwire-dslite-multicast-02

From: Jacni Qin <[email-masked]>
Date: Tue, 03 Jul 2012 00:00:26 +0800

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.

We ever know trying a single solution for all is not a good idea.
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-masked]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>
>
>
>

---

From: Stig Venaas <[email-masked]>
Date: Mon, 02 Jul 2012 10:57:37 -0700

Hi

> 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Jul 2012 15:46:49 -0500

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

---

From: Jacni Qin <[email-masked]>
Date: Fri, 13 Jul 2012 11:21:39 +0800

> Well, from the so many mails below it is clear that
No, it's clearly clarified from the mails, about the motive, and the 
problems to be solved.

> extensions document for DS-Lite.
And it's clear that the "extensions" are definitely NOT to simply use 
the unicast tunnel for multicast delivery
in DS-Lite deployment.

Cheers,
Jacni

---

From: Stig Venaas <[email-masked]>
Date: Thu, 12 Jul 2012 22:44:13 -0700

> the unicast tunnel for multicast delivery

FWIW, I think the document is a good solution for multicast in a DS-Lite
environment. I just would like some modifications to the document to
reflect that it is a more generic solution.

Stig

---

From: Tom Taylor <[email-masked]>
Date: Fri, 13 Jul 2012 09:22:56 -0400

> reflect that it is a more generic solution.
..
I heartily agree with Stig. I think the WG has the choice either to 
generalize this document or accept draft-tsou-softwire-6rd-multicast-01 
as a parallel solution for the 6rd environment. A single more general 
document makes more sense.

Tom

---

From: Jacni Qin <[email-masked]>
Date: Mon, 16 Jul 2012 23:47:25 +0800

On 7/13/2012 Friday 9:22 PM, Tom Taylor wrote:
> generalize this document or accept 
> draft-tsou-softwire-6rd-multicast-01 as a parallel solution for the 
> 6rd environment. A single more general document makes more sense.
What you're talking is totally different from Stig's.
As we all know, the ONLY target scenario of this document is DS-Lite 
environment, even we loose the text and make the door open for the 
current mechanisms to be reused by future possible scenarios, there 
won't be any overlap with the target scenario of 
draft-tsou-softwire-6rd-multicast-01.

So I think parallel solutions are better.

Cheers,
Jacni