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

From: Shailesh Suman <[email-masked]>
Date: Tue, 26 Jun 2012 17:37:17 +0530

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.

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.

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.

Regards
-Shailesh

> Message: 1
> Date: Tue, 26 Jun 2012 07:36:41 +0800
> From: Jacni Qin <[email-masked]>
> To: [email-masked]
> Cc: Softwires-wg <[email-masked]>, Behcet Sarikaya
>        <[email-masked]>
> Subject: Re: [Softwires] [SPAM] Re: WG last call on
>        draft-ietf-softwire-dslite-multicast-02
> Message-ID: <[email-masked]>
> 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-masked]>  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-masked]
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>>
>
>
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 26 Jun 2012 13:41:35 +0000

Hi Shailesh,

Thanks very much of reviewing the draft. Please read comments inline:

>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.

>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.

>    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

---

From: Shailesh Suman <[email-masked]>
Date: Wed, 27 Jun 2012 22:12:53 +0530

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

---

From: Jacni Qin <[email-masked]>
Date: Thu, 28 Jun 2012 12:56:06 +0800

Re-,

Thanks a lot for your review and comments, we'll update it accordingly.

Cheers,
Jacni