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

[<[e-mail]>]

Re-,

Ok, thank you. 

I will wait for the second IntDir review before submitting an updated version with the change we agreed. 

Cheers,
Med

> -----Message d'origine-----
> De : Zhen Cao [mailto:[e-mail]]
> Envoyé : lundi 12 décembre 2016 08:16
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [e-mail]; int-
> [e-mail]; [e-mail]
> Objet : Re: Int-Dir Review of draft-ietf-softwire-dslite-multicast-12
> 
> 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