Re-,
Thanks a lot for your review and comments, we'll update it accordingly.
Cheers,
Jacni
On 6/28/2012 Thursday 12:42 AM, Shailesh Suman wrote:
Hi Lee,
Thanks for your reply. It clarifies some of my queries now. Hope
to see the revison tries to address these points.
Regards..
-Shailesh
On Tue, Jun 26, 2012 at 7:11 PM, Lee, Yiu <[email protected]> wrote:
Hi Shailesh,
Thanks very much of reviewing the draft. Please read comments inline:
On 6/26/12 8:07 AM, "Shailesh Suman" <[email protected]> wrote:
Hi All,
I see few points of this draft need to be addressed to address
complete solution.
1). Section 6.2 mentions the mB4 must drop non-matching (mPrefix64 and
uPrefix64) packets silently. There can be scenarios, where some of LAN
Multicast receivers are supporting native IPv6. How will such packets
reach the v6 Multicast Receivers, in case they get silently discarded
by mB4. Hence, the hybrid scenario of having both v6 and v4 Multicast
Receivers in LAN should also be looked into.
[YL] mB4 is a logical function and should be implemented along side with
normal MLD listener in the same CPE. If the multicast address header
contains mPrefix64 and uPrefix64, it should pass to mB4. Otherwise, the
normal MLD listener will handle it. That sentence tries to prevent normal
multicast message from accidentally passing to mB4.
2). It is also possible for LAN to have Multicast Originators rather
than only Multicast Receivers. This solution currently restricts the
scope to downstream Multicast traffic only and there should be some
exploration for Originators as well.
[YL] Our main focus on this to support home user (i.e. IPTV service). You
can find more discussion in
http://tools.ietf.org/html/draft-ietf-mboned-v4v6-mcast-ps-00. This is why
we limit the scope. We can add more words to expect our motives.
3). Fragmentation issues can surface for any transition techniques.
However for DS-Lite (applicable to Unicast traffic only) Path-MTU can
come for rescue. But for Multicast traffic Path-MTU can not be run.
This can lead to Fragmentation and Assembly Overheads in mAFTR and mB4
respectively.
I think, addressing these points would be vital for this I.D.
[YL] I agree. We will propose some text in next revision.
Thanks,
Yiu
Regards
-Shailesh
Message: 1
Date: Tue, 26 Jun 2012 07:36:41 +0800
From: Jacni Qin <[email protected]>
To: [email protected]
Cc: Softwires-wg <[email protected]>, Behcet Sarikaya
<[email protected]>
Subject: Re: [Softwires] [SPAM] Re: WG last call on
draft-ietf-softwire-dslite-multicast-02
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
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.
Cheers,
Jacni
Regards.
Behcet
Cheers,
Jacni
We think that this draft should be part of
draft-ietf-softwire-dslite-multicast.
Regards,
Behcet
_______________________________________________
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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
