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

[<[e-mail]>]

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