On 12.07.2012 20:21, Jacni Qin wrote:
On 7/10/2012 Tuesday 4:46 AM, Behcet Sarikaya wrote:
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.
draft-ietf-softwire-dslite-multicast-02 is anything but multicast
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.
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
Cheers,
Jacni
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
