Re: [Int-dir] Int-Dir Review of draft-ietf-softwire-dslite-multicast-12

[Zhen Cao <[e-mail]>]

Hello Med,

Thanks for the quick response which sounds good to me.

BR,
Zhen



On Mon, Dec 12, 2016 at 2:45 PM,  <[e-mail]> wrote:
> Dear Zhen,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Zhen Cao [mailto:[e-mail]]
>> Envoyé : lundi 12 décembre 2016 07:01
>> À : [e-mail]
>> Cc : [e-mail]; [e-mail]
>> Objet : Int-Dir Review of draft-ietf-softwire-dslite-multicast-12
>>
>> Hi, authors and editors,
>>
>> I am an assigned INT directorate reviewer for this draft. These
>> comments were written primarily for the benefit of the Internet Area
>> Directors. Document editors and shepherds should treat these comments
>> just like they would treat comments from any other IETF contributors
>> and resolve them along with any other Last Call comments that have
>> been received. For more details of the INT directorate, see
>> <http://www.ietf.org/iesg/directorate.html>.
>>
>>
>> I do not see any major reason to block the publication of this draft.
>> Below are two comments for discussion.
>>
>> a) uPrefix64 and mPrefix64
>>
>> I was a bit confused when I encounter the name suffix -64, because
>> they somehow imply only 64-bit long prefix could be used, while the
>> fact may be not true.
>
> [Med] Actually, 64 is not used to denote the prefix length but this is a practice widely used in transition mechanisms, you can see for instance:
> https://tools.ietf.org/html/rfc6146
> https://tools.ietf.org/html/rfc6147
> https://tools.ietf.org/html/rfc7050
> https://tools.ietf.org/html/rfc7225
> ...
>
>   If '64' means an IPv6-IPv4 mapping, it may make
>> some sense.  So I highly encourage the editors to put some notes below
>> the items in the terminology section.
>>
>
> [Med] Makes sense. I added a note similar note that we have in https://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-11:
>
>          Note: "64" is used as an abbreviation for IPv6-IPv4
>          interconnection.
>
>>
>> b)
>> 6.2.  Multicast Data Forwarding
>>
>>   When the mB4 receives an IPv6 multicast packet, it MUST check the
>>    group address and the source address.  If the IPv6 multicast group
>>    prefix is mPrefix64 and the IPv6 source prefix is uPrefix64, the mB4
>>    MUST decapsulate the IPv6 header and forward the IPv4 multicast
>>    packet through each relevant interface.  Otherwise, the mB4 MUST
>>    silently drop the packet.
>>
>> comments: the mB4 not only needs to check the validity of mPrefix and
>> uPrefix, but also needs to check if there exists an associated
>> MLD/IGMP requests from that prefixes.  Only if there was an IGMP
>> report associted with this transaction, it will forward such multicast
>> packets.
>>
>>
> [Med] This is actually the intent of the last part of the text you quoted:
>
>    prefix is mPrefix64 and the IPv6 source prefix is uPrefix64, the mB4
>    MUST decapsulate the IPv6 header and forward the IPv4 multicast
>    packet through each relevant interface.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> If no state is found, there won't be any "relevant interface". So the  traffic won't be forwarded.
>
>> Thanks for draft the document.
>>
>> -zhen