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