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

["Lee, Yiu" <[e-mail]>]

One comment from developer point of view. The current text says: “MUST…. forward the IPv4 multicast packet through each relevant interface.” When I read this, I got an impression that mB4 had to implement something new to “find” each relevant interface and forward the packet. In fact, the mB4 is using the default IPv4 mcast implementation and isn’t required to identify the relevant interfaces. This is what my proposed text tries to clarify.


On 12/12/16, 1:45 AM, "[e-mail]" <[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