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
