Telechat Review of draft-ietf-softwire-dslite-multicast-16
review-ietf-softwire-dslite-multicast-16-opsdir-telechat-chown-2017-02-02-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

I notice draft-ietf-softwire-dslite-multicast-17 was released this morning. My
review is based on -16, and I’ve removed a couple of comments covered off in
the -17 update.

The draft describes how IPv4 multicast can be delivered between an IPv4 sender
and IPv4 receiver(s) over an intermediate IPv6-only network. The draft is thus
focused specifically on the 4-6-4 case.  It is particularly relevant to the DS
Lite service model, though it is in principle applicable to other models.

Overall, I believe the document is Ready with Nits, though I also have a
handful of general comments.

** General comments **

DS Lite (RFC 6333) has broader discussion of fragmentation and path MTU
settings (in 5.3 and 6.3). Would such expanded coverage be useful in the draft
as well, or might this draft usefully refer back to that?

Is it worth citing RFC 4213 alongside RFC 2473?

DS Lite describes how the AFTR and B4 handle issuing of RFC1918 address space
and NAT within the AFTR function.  Does there need to be discussion of NAT
here? It seems that so long as the IPv4 receiver is only a receiver,
consideration of NAT is not necessary, but it may be worth explicitly stating
that the model is agnostic to the use of IPv4 NAT in the receiver IPv4 network
behind the mB4.

Is there any useful discussion to be had in Section 8 with respect to how, when
this draft is used with DS Lite, the AFTR/mAFTR and B4/mB4 functions co-exist?

** Specific nits **

Is there a 3rd point to make on page 3/4 about the additional load caused by
fragmentation and reassembly?

In section 4.2, paragraph 3, I fund the text a little confusing. Isn’t the
first upstream IPv6 router in the IPv6 network the IPv6 DR from the perspective
of the IPv4 receiver’s mB4 function?  Perhaps this can be clarified here?  My
understanding is that the mB4 and mAFTR split the IPv4 DR function for the IPv4
receiver, in that the mB4 provides downstream IPv4 multicast router
functionality to the client (via IGMP) and the mAFTR the upstream router
functionality via PIMv4 JOINs. (and I think you capture this in the figure in
section 6.1)

In Section 4.3 paragraph 3, I would say “towards the receivers”.

In Section 6.2, should the address start ff3x:80: given the prefix is a /96 not
a /32?  The same applies in Section 7.4 (where you might also refer back to
this section, as I think it’s the same example?)

In Section 6.3, again I’m not sure “forward to the hosts” is quite right,
rather the mB4 forwards the multicast packet on its interface towards the
receiver(s).

In Section 6.5, I think the example of matching global scope is relatively
obvious, whereas the devil is in the details of non-global scopes.  Do you mean
“closest match scope”?  You say “must select the appropriate scope”.  For IPv6,
you might typically see in a site either scope 5 (site) or scope 8
(organisation) - which of these would you say is “appropriate” for an IPv4
group under 239.0.0.0/8 (“organisation local”)?  Is it 8?  And if so, if only 5
(site) and e (global) scopes are available, would you use 5?

In Section 7.1, perhaps add at the start of the second sentence “When
forwarding IPv4 multicast content over the IPv6 network, the AFTR….” ?

In Section 7.5, the text on scope matching is repeating earlier text in 6.5. 
Perhaps just have this in one place?

In Section 8.2, perhaps also say how the scalability concerns expressed in
points 1 and 2 in Section 1 are addressed?

In Section 9.1, perhaps say MLD messages from the internal network and
multicast traffic from the external network?

In the references, is RFC 2236 normative?

In the last line before the authors’ addresses, change to “requires MLDv2 to be
enabled"

Tim