Subject: [RTG-DIR] RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt

From: Stig Venaas <[email-masked]>
Date: Wed, 11 Jan 2017 10:22:37 -0800

Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request. The purpose of the review is
to provide assistance to the Routing ADs. For more information about
the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.

Document: draft-ietf-softwire-dslite-multicast-14.txt
Reviewer: Stig Venaas
Review Date: 2017-01-11
IETF LC End Date: 2017-01-12
Intended Status: Standards Track

Summary:
I have some minor concerns about this document that I think should be
resolved before publication.

Comments:
The document is fairly easy to read, and the solution is technically
sound and is well described. But a couple of statements are
technically wrong and need to be corrected. A few more details could
be added in some places, and there are a couple of very minor issues
that make it less readable.

Major Issues:
No major issues found.

Minor Issues:

In 3 places the documents talks about the MLD querier where it instead
should have said PIM Designated Router, or PIM DR.

In section 2 we have this definition:
   Multicast B4 (mB4):  a functional entity which supports an IGMP-MLD
      interworking function (refer to Section 6.1) that relays
      information conveyed in IGMP messages by forwarding the
      corresponding Multicast Listener Discovery (MLD) messages towards
      the MLD Querier in the IPv6 network.  In addition, the mB4
      decapsulates IPv4-in-IPv6 multicast packets.

It is the DR, not the querier that needs the reports. The reports are
sent by multicast to the all MLDv2-capable routers address though,
which means that DR, querier (they may be the same), and potentially
other routers on the link will get the report. Maybe you can skip some
details and just say that mB4 sends an MLD report.

In 4.2 we have this paragraph:
   The mB4 uses the G6 (and both S6 and G6 in SSM) to create the
   corresponding MLD Report message.  The mB4 sends the Report message
   towards the MLD Querier in the IPv6 network.  The MLD Querier (which
   usually acts as the PIMv6 Designated Router too) receives the MLD
   Report message and sends the PIMv6 Join to join the IPv6 multicast
   distribution tree.  The MLD Querier can send either PIMv6 Join (*,G6)
   in ASM or PIMv6 Join (S6,G6) in SSM to the mAFTR.

It should just say DR here as well.

Also in In 6.1 it says:
   MLD messages are forwarded natively towards the MLD Querier
   located upstream in the IPv6 network (i.e., the first hop IPv6
   router).
It should refer to the PIM DR here as well, and figure 2 should be updated.

More discussion about SSM vs ASM would be useful. In the last
paragraph of section 1 you have some text about SSM versus ASM. would
be good to point out that SSM and ASM IPv4 groups should be mapped to
SSM and and ASM IPv6 groups respectively. That is, if an IPv4 group is
an SSM group, then I believe the respective IPv6 group needs to be SSM
as well. The same for ASM.

In 4.2 it says:
   The mAFTR acts as the IPv4 DR to which the uPrefix64-derived S6 is
   connected.
Shouldn't it say that the mAFTR acts as the IPv6 DR?

Nits:
I found a number of nits.

In the abstract we have:
   This document specifies a solution for the delivery of IPv4 multicast
   services to IPv4 clients over an IPv6 multicast network.  The
   solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme
   and uses the IPv6 multicast distribution tree to deliver IPv4
   multicast traffic.  The solution is particularly useful for the
   delivery of multicast service offerings to DS-Lite serviced
   customers.

This make it sounds like a single IPv6 multicast tree is used for
delivery of all IPv4 multicast. It would be better changing this to
plural (or possible say an IPv6 multicast distribution tree).

In first paragraph of section 1:
   DS-Lite [RFC6333] is a technique that rationalizes the usage of the
   remaining global IPv4 addresses during the transition period by
   sharing a single IPv4 address with multiple users.
Rationalize is the wrong word here I believe. Perhaps it should say
rations, limits or reduces?

In second paragraph of section 2, [RFC7597] is not marked correctly as
a reference, it is just text.

In 4.2 we have this text:
   The mAFTR advertises the route of uPrefix64 with an IPv6 Interior
   Gateway Protocol (IGP), so as to represent the IPv4-embedded IPv6
   source in the IPv6 multicast network, and to run the Reverse Path
   Forwarding (RPF) check procedure on incoming multicast traffic.

It might sound like mAFTR is the router doing the RPF check. It might
be good to clarify that it is announced to allow other IPv6 routers to
perform RPF check.

In 6.2 you have this example:
   As an illustration, if a packet is received from source
   2001:db8::192.0.2.33 and needs to be forwarded to group
   ff3x:1000::233.252.0.1

Note that the latter is not a valid unicast prefix-based multicast
address. It would be better to use something like
ff3x:20:2001:db8::233.252.0.1. This is also the case in 7.4.

In 6.5 there is an issue with the example. It has the address
ff0e::db8::233.252.0.1. You cannot use :: twice.

The section 7.5 heading is TTL/Scope, but it only discusses Scope. It
might make sense to recommend copying the TTL value from the IPv4
packet to the IPv6 packet, and perhaps copying it back after
decapsulation.

I don't understand section 8.1.1 about co-locating MLD querier with
the mAFTR. Doesn't that mean that the mAFTR is on the same link as the
mB4? If that is the case, do you need IPv6 encapsulation at all?

Would it make sense to consider the case where mB4 acts as an IPv6 PIM
router, avoiding sending MLD reports?

Appendix B discusses issues with mismatch of group membership
protocols at mB4. The real issue, which is not mentioned, is if mB4
receives source specific (SSM) reports from IPv4 receivers, and the
upstream IPv6 MLD router only supports MLDv1.

Regards,
Stig

---

From: Jacni Q <[email-masked]>
Date: Thu, 12 Jan 2017 14:55:39 +0800

Re-,

Thanks Stig for the comments, inline please.

On Thu, Jan 12, 2017 at 2:22 AM, Stig Venaas <[email-masked]> wrote:

> ​[Q]: Yes, we borrowed the "Querier" terminology heavily from RFC 3810.
can we simply replace it with "router" or just remove it somewhere like
"... into the IPv6 network"? Since as you mentioned there may be querier, DR
and other routers receiving the message.
 ​

> ​​
> ​[Q]:

-New-
​Multicast B4 (mB4):  a functional entity which supports an IGMP-MLD
interworking function (refer to Section 6.1) that relays
information conveyed in IGMP messages by forwarding the
corresponding Multicast Listener Discovery (MLD) messages into
the IPv6 network.  In addition, the mB4 decapsulates
IPv4-in-IPv6 multicast packets.​

> ​​
> ​[Q]:

-New-
The mB4 uses the G6 (and both S6 and G6 in SSM) to create the
corresponding MLD Report message.  The mB4 sends the Report message
into the IPv6 network.  The MLD router which acts as the PIMv6
Designated Router too, receives the MLD Report message and sends
the PIMv6 Join to join the IPv6 multicast distribution tree.
The router can send either PIMv6 Join (*,G6) in ASM or PIMv6
Join (S6,G6) in SSM to the mAFTR.
​

> ​​
> ​[Q]:

-New-
​

​MLD messages are forwarded natively towards the MLD router
located upstream in the IPv6 network (i.e., the first hop IPv6
router).
​

> ​[Q]: The quote here is just intent to express the preference of SSM.
We can remove
"
the
operation of the translation mechanism is also simplified when SSM is
used, e.g., considerations for placement of the IPv6 the Rendezvous
Point (RP) are no longer relevant.
"
from the last sentence to make it simple.
​

> ​​
> ​[Q]: Yes.
​

> ​[Q]:Ok, maybe "an IPv6 multicast distribution tree".
​

> ​[Q]: not native, so no comment on it :-)
​

> ​​

​[Q]:
​

-
​New-
The mAFTR advertises the route of uPrefix64 with an IPv6 Interior
Gateway Protocol (IGP), so as to represent the IPv4-embedded IPv6
source in the IPv6 multicast network, and for IPv6 multicast
routers to run the Reverse Path Forwarding (RPF) check procedure
on incoming multicast traffic.
​

> ​[Q]: Ok.
​

> ​[Q]: Thanks.
​

> ​[Q]: Co-locating means on the same node, running the two sorts of
functionalities.
​

> ​[Q]: That's possible.
​

> ​[Q]: We have talked about this in the next paragraph.

Thanks again for your review.

​

-- 
Cheers,
-Q

---

From: <[email-masked]>
Date: Thu, 12 Jan 2017 07:55:16 +0000

Hi Stig, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Stig Venaas [mailto:[email-masked]]
> Envoyé : mercredi 11 janvier 2017 19:23
> À : [email-masked]; [email-masked]
> Cc : [email-masked]; [email-masked]
> Objet : RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt
> 
> Hello,
> 

[Med] That definition was drawn from an MLD perspective. OK with your proposal to skip these details. I made this modification:

OLD:
      the corresponding Multicast Listener Discovery (MLD) messages
      towards the MLD Querier in the IPv6 network.

NEW:
      the corresponding Multicast Listener Discovery (MLD) messages
      towards the IPv6 network.

> It should just say DR here as well.

[Med] Same as for the previous comment. I suggest the following:

OLD:

NEW:
   The mB4 uses the G6 (and both S6 and G6 in SSM) to create the
   corresponding MLD Report message.  The mB4 sends the Report message
   towards the IPv6 network.  The MLD Querier, which usually acts as the
   PIMv6 Designated Router too, receives the MLD Report message and
   sends the PIMv6 Join message to join the IPv6 multicast distribution
   tree.  It can send either PIMv6 Join (*,G6) in ASM or PIMv6 Join
   (S6,G6) in SSM to the mAFTR.

> It should refer to the PIM DR here as well, and figure 2 should be

[Med] This one is really specific to IGMP/MLD. The use of Querier in the text and the figure are correct. I suggest to maintain the details.

> as well. The same for ASM.

[Med] We already have this text in Section 5.1 to cover this point: 

The
   mPrefix64 MUST be derived from the corresponding IPv6 multicast
   address space (e.g., the SSM_mPrefix64 must be in the range of
   multicast address space specified in [RFC4607]).

> plural (or possible say an IPv6 multicast distribution tree).

[Med] Fair. Changed "the IPv6 multicast distribution tree" to "an IPv6 multicast distribution tree"

> rations, limits or reduces?

[Med] Actually the text explains how "rationalize" is achived

   DS-Lite [RFC6333] is a technique that rationalizes the usage of the
                                         ^^^^^^^^^^^^
   remaining global IPv4 addresses during the transition period by
                                                                ^^
   sharing a single IPv4 address with multiple users.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's said, I can change the text to: 

NEW:

   DS-Lite [RFC6333] is an IPv4 address-sharing technique that
   enables operators to multiplex public IPv4 addresses while
   provisioning only IPv6 to users. 

> a reference, it is just text.

[Med] It is marked as a reference in the xml file. 

> be good to clarify that it is announced to allow other IPv6 routers to
[Med] Fixed.

> ff3x:20:2001:db8::233.252.0.1. This is also the case in 7.4.

[Med] This is on purpose. The use of unicast-based multicast address is not required or precluded.
If you think this is useful, I can add another example with the unicast-based prefix. Please let me know your preference.   

> ff0e::db8::233.252.0.1. You cannot use :: twice.
[Med] fixed. 

> packet to the IPv6 packet, and perhaps copying it back after

[Med] I added this NEW text: 

"The hop limit of the IPv6 header is derived from the TTL value in the IPv4 header."

> mB4? If that is the case, do you need IPv6 encapsulation at all?

[Med] Encapsulation can be used in the last hop between the mAFTR and mB4 in this case. 

> router, avoiding sending MLD reports?

[Med] Yes, but this is really deployment-specific. 

> upstream IPv6 MLD router only supports MLDv1.

[Med] Isn't this covered by this text? 

   If IGMPv2 operates on the IPv4 receivers while MLDv2 operates on the
   MLD Querier, or if IGMPv3 operates on the IPv4 receivers while MLDv1
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   operates on the MLD Querier, the version mismatch issue will be
   encountered.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 12 Jan 2017 15:40:50 -0800

Hi

Please see comments inline. I see you posted a new revision, but I
still have some remaining concerns.

>       towards the IPv6 network.

This is OK, but I see it says "forwarding the corresponding...". The MLD
message is originated by mB4. "Forwarding" is not quote correct. Also,
the message only goes to the IPv6 routers that are on the same link as
mB4, it may sound like it gets forwarded, but MLD messages are never
forwarded. So just think about whether there is a more precise way of
saying it.

>    (S6,G6) in SSM to the mAFTR.

The Querier is entirely out of the picture, so I would just write "The
PIMv6 Designated Router receives the MLD Report message and sends"...
If you want a reference, maybe see the beginning of
https://tools.ietf.org/html/rfc7761#section-3.1

> [Med] This one is really specific to IGMP/MLD. The use of Querier in the text and the figure are correct. I suggest to maintain the details.

I believe this is incorrect. At least the MLD reports sent by mB4 are
processed by the PIM DR, not the MLD querier. They can be the same
router, but it is always the router functioning as PIM DR that is
responsible for acting on the MLD report. In the text you are talking
about the MLD report/message sent by mB4. One option could be to
replace querier with IPv6 router? Note that "first hop IPv6 router" is
also confusing. For multicast, the term "first hop" is used for the
router connected to the source. While the router receiving MLD reports
(the DR) is the "last hop" router.

I would replace this text "MLD messages are forwarded natively towards
the MLD Querier located upstream in the IPv6 network (i.e., the first
hop IPv6 router)" with something like "MLD messages are sent natively
to the directly connected IPv6 multicast routers (it will be processed
by the PIM DR)."

>    multicast address space specified in [RFC4607]).

Sorry, you're right.

[some quoted text deleted]
> [Med] Encapsulation can be used in the last hop between the mAFTR and mB4 in this case.

The MLD querier is on the same link as mB4, right? They must be
connected to the same layer 3 link (subnet). So if you say you
co-locate MLD querier with the mAFTR, then I believe the mAFTR is on
the same link as mB4. Which means that you IPv6 encapsulate between
two routers that are on the same layer 3 link. Is this useful? Or am I
missing something?

>    MLD Querier, or if IGMPv3 operates on the IPv4 receivers while MLDv1

I understand that you're saying that you downgrade to IGMPv2 if the
IPv6 querier is MLDv1. That is fine. But it might be good to point out
that you cannot support SSM in that case. To support IPv4 SSM, you
need to have MLDv2 in your IPv6 network. Maybe it is obvious, but it
might be worth pointing it out.

Stig

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 13 Jan 2017 02:41:58 +0000

Hi Stig,

Thanks for reviewing the draft. Comments inline.

Thanks,
Yiu

On 1/12/17, 6:40 PM, "Stig Venaas" <[email-masked]> wrote:

    Hi

    

[YL] I understand your concerns of the correctness of the protocol behavior. The mB4 translates and generate the corresponding MLD message. Strictly speaking, no forwarding hs involved. If we change this to:

NEW:
   Multicast B4 (mB4):  a functional entity which supports an IGMP-MLD
         interworking function (refer to Section 6.1) that translates the
         IGMP messages into the corresponding Multicast Listener 
         Discovery (MLD) messages, and send the MLD messages
         to the IPv6 network.  

[YL] I see your point. We should remove MLD Querier.

    

[YL] Thanks. We will update this.

    Sorry, you're right.

    
[YL] Yes, the mB4 and mAFTR are on the same link. In the case the source is IPv4, mAFTR will still need to encap the corresponding IPv4 multicast packets into IPv6 multicast packets and send toward to the mB4.

    
[YL] We will add this in next version.

    Stig

---

From: Stig Venaas <[email-masked]>
Date: Fri, 13 Jan 2017 12:33:19 -0800

Sounds good, I'll still try to have another look when you post the
next revision.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 18 Jan 2017 10:26:41 -0800

Hi

The good version looks pretty good. But I noticed one more thing that
you might want to change. I'll leave it to you.

8.1.1.  The MLD Querier is Co-Located with the mAFTR

   The mAFTR can embed the MLD Querier function (as well as the PIMv6
   DR) for optimization purposes.

I'm wondering if you should say IPv6 DR or PIMv6 DR instead. As you
write after the heading, it must be co-located with the DR as well.
Normally the querier would be the same router, but the querier could
be another router on the link.

Then we have this section:

8.1.2. The DR is Co-Located with the mAFTR

In the text you talk about the DR connected to the IPv4 source. Hence
it is the first hop DR, and IPv4 DR. I'm wondering if it is worth
saying IPv4 DR or something in the title to distinguish it from the
other DR. Basically we have first hop DR and last hop DR, or if you
like IPv4 DR and IPv6 DR.

I'm leaving it to you to decide. This is the only remaining issue I
can find. There is a typo at the end of Appendix B though. It say
"Noet".

Stig

---

From: <[email-masked]>
Date: Mon, 23 Jan 2017 10:51:18 +0000

Hi Stig, 

Please see inline.

Cheers,
Med

> Envoyé : mercredi 18 janvier 2017 19:27
> À : Lee, Yiu
> Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]; draft-ietf-softwire-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Re: RtgDir review: draft-ietf-softwire-dslite-multicast-14.txt
> 
> Hi
> 

[Med] Do you suggest to replace in the title "MLD Querier" with "PIMv6 DR"?

> like IPv4 DR and IPv6 DR.

[Med] Makes sense to be explicit here. I changed DR to IPv4 DR.

> can find. There is a typo at the end of Appendix B though. It say

[Med] Fixed it. Thanks.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 23 Jan 2017 20:56:29 -0800

Hi

> [Med] Do you suggest to replace in the title "MLD Querier" with "PIMv6 DR"?

Yes, or I guess IPv6 DR is better. You used the term IPv4 DR below.

I'm not sure if you have it in your document, I know I should check,
but it would be good somewhere to say that DR is the Designated Router
as defined in RFC 7761.

Stig

---

From: <[email-masked]>
Date: Tue, 24 Jan 2017 07:08:17 +0000

Hi Stig, 

Works for me. 

The changes are implemented copy. I will wait for other reviews before submitting a new revision.

Thank you.

Cheers,
Med

> Envoyé : mardi 24 janvier 2017 05:56
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Lee, Yiu; [email-masked]; draft-ietf-softwire-dslite-
> [email-masked]; [email-masked]; [email-masked]