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

[Stig Venaas <[e-mail]>]

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