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

From: Zhen Cao <[email-masked]>
Date: Mon, 12 Dec 2016 14:01:06 +0800

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

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.

Thanks for draft the document.

-zhen

---

From: <[email-masked]>
Date: Mon, 12 Dec 2016 06:45:19 +0000

Dear Zhen,

Thank you for the review.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Zhen Cao [mailto:[email-masked]]
> Envoyé : lundi 12 décembre 2016 07:01
> À : [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : Int-Dir Review of draft-ietf-softwire-dslite-multicast-12
> 
> Hi, authors and editors,
> 
> 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
> 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.

> report associted with this transaction, it will forward such multicast
[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.

---

From: Zhen Cao <[email-masked]>
Date: Mon, 12 Dec 2016 15:16:28 +0800

Hello Med,

Thanks for the quick response which sounds good to me.

BR,
Zhen

---

From: <[email-masked]>
Date: Mon, 12 Dec 2016 07:57:27 +0000

Re-,

Ok, thank you. 

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

Cheers,
Med

> Envoyé : lundi 12 décembre 2016 08:16
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]; int-
> [email-masked]; [email-masked]
> Objet : Re: Int-Dir Review of draft-ietf-softwire-dslite-multicast-12
> 
> Hello Med,
> 
> > [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:
> > [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:
> >

---

From: Tim Chown <[email-masked]>
Date: Mon, 12 Dec 2016 09:47:35 +0000

Hi,

I'm the other reviewer - I should have my review with you soon.

Best wishes,
Tim 

> On 12 Dec 2016, at 07:57, [email-masked] wrote:
> 
> Re-,
> 
> Ok, thank you. 
> 
> _______________________________________________
> Int-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-dir

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 14 Dec 2016 03:55:04 +0000

Hi Med and Zhen,

Actually mB4 doesn’t need to do any check. Once decap is done, it will use the standard IPv4 mcast forwarding rule. If the v4 group address is in the mroute table, it will be forwarded, if not, it will be dropped. I propose the following: 

When the mB4 receives an IP multicast packet, it MUST check the group address and the source address. If the IPv6 multicast group prefix is mPrefix64 and IPv6 source prefix is uPrefix64, the mB4 MUST decapsulate the IPv6 header. The decapsulated IPv4 multicast packet will be forwarded based on standard IPv4 multicast forwarding rule.

Thanks,
Yiu

---

From: <[email-masked]>
Date: Wed, 14 Dec 2016 12:32:40 +0000

Hi Yiu, 

I think that we are saying the same thing. 

As agreed with Zhen, no change is required to the current text. 

Cheers,
Med

> De : Lee, Yiu [mailto:[email-masked]]
> Envoyé : mercredi 14 décembre 2016 04:55
> À : BOUCADAIR Mohamed IMT/OLN; Zhen Cao; draft-ietf-softwire-dslite-
> [email-masked]
> Actually mB4 doesn’t need to do any check. Once decap is done, it will use
> the standard IPv4 mcast forwarding rule. If the v4 group address is in the
> mroute table, it will be forwarded, if not, it will be dropped. I propose
> the following:
> 
> When the mB4 receives an IP multicast packet, it MUST check the group
> address and the source address. If the IPv6 multicast group prefix is
> mPrefix64 and IPv6 source prefix is uPrefix64, the mB4 MUST decapsulate
> the IPv6 header. The decapsulated IPv4 multicast packet will be forwarded
> based on standard IPv4 multicast forwarding rule.
> 
> Thanks,
> Yiu
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 14 Dec 2016 14:20:00 +0000

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.

    Dear Zhen,

    Please see inline.
    
    Cheers,
    Med