On 6/27/2012 Wednesday 11:30 PM, Behcet Sarikaya wrote:
On Mon, Jun 25, 2012 at 6:36 PM, Jacni Qin <[email protected]> wrote:
Re-,
On 6/26/2012 Tuesday 2:50 AM, Behcet Sarikaya wrote:
On Mon, Jun 25, 2012 at 1:09 AM, Jacni Qin<[email protected]> wrote:
Hi Behcet, all,
On Friday, June 22, 2012 2:23:34 AM, Behcet Sarikaya wrote:
Folks,
We have published revised version of our draft on multicast extensions
to DS-Lite at
http://www.ietf.org/id/draft-sarikaya-softwire-dslitemulticast-01.txt
It's been discussed on the list and in the 81st meeting, and concluded
quite
clearly by the WG why this is abandoned.
It tunnels the IGMP packets upwards, replicates the multicast traffic
"per
tunnel", opposite to the property of multicast technology. And these are
problems we're trying to solve.
draft-ietf-softwire-dslite-multicast-02 has nothing to do with
DS-Lite and therefore it is not a DS-Lite multicast extensions
document as the charter requires.
OTOH, draft-sarikaya-softwire-dslitemulticast-01.txt integrates
multicast into DS-Lite tunnel.
It is not against multicast technology.
In this way, the efficiency is lost. If operators put the AFTR box deeply in
the network, far from the end users, as you process the singling messages
and replicate of traffic per tunnel, the network and the box will crash
because of the huge burden.
That's a big IF. Not everybody has to do it the same way.
No, even you distribute AFTRs in the networks, e.g., co-locate the boxes
beside BRAS/BNGs, the problems are still there.
The solution in draft-ietf-softwire-dslite-multicast-02
builds itself something without considering what DS-Lite is doing.
Not true, please see below.
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?
Let's remind you again,
What you described in your approach ("Simply enabling multicast based on
RFC6333") is the problem that needs to be solved.
You're running multicast inside the UNICAST tunnels between B4s and AFTR.
By contrast, we considered it.
If following your approach to run multicast in the DS-Lite deployment
(as stated earlier, we just consider this scenario), there will be
problems (e.g., lost of efficiency of multicast, burden of network and
devices, ... please see above).
That is what we're trying to solve in draft-ietf-softwire-dslite-mulitcast.
There is no necessity to initiate that kind of discussion once again.
I did not start this discussion. Please check the list.
Again please see above, or check the archive and the offlist messages where
we've explained it to you in detail.
I also had explained to you that the chairs wanted the two drafts
merged in detail.
No, it's been clarified during the meeting and previous discussions,
that your approach is the problem that needs to be solved.
Cheers,
Jacni
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
