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