Skip to main content

Early Review of draft-ietf-softwire-dslite-multicast-12

Request Review of draft-ietf-softwire-dslite-multicast
Requested revision No specific revision (document currently at 18)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-12-29
Requested 2016-11-29
Authors Mohamed Boucadair , Jacni Qin , Christian Jacquenet , Yiu Lee , Qian Wang
I-D last updated 2016-12-14
Completed reviews Intdir Early review of -12 by Zhen Cao (diff)
Intdir Early review of -12 by Tim Chown (diff)
Opsdir Last Call review of -14 by Jouni Korhonen (diff)
Genart Last Call review of -14 by Francis Dupont (diff)
Rtgdir Telechat review of -14 by Stig Venaas (diff)
Genart Telechat review of -16 by Francis Dupont (diff)
Opsdir Telechat review of -16 by Tim Chown (diff)
Assignment Reviewer Tim Chown
State Completed
Request Early review on draft-ietf-softwire-dslite-multicast by Internet Area Directorate Assigned
Reviewed revision 12 (document currently at 18)
Result Ready w/issues
Completed 2016-12-14

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

In general, this document is well-written, solves a useful problem for at least
an interim period, and is quite close to being ready to go.

I do have some comments regarding the clarity of the document, and areas that
could be improved.

General comments:

I would suggest that for clarity and to match the recommendation of the mboned
WG that the document be primarily written on the assumption of SSM being used,
and the requirements associated to that, e.g., the IPv4 client uses SSM, the
mB4 understands IGMPv3 and MLDv2, and the MLD Querier supports MLDv2. A
recommendation to this effect would be good to see. It simplifies the whole 464

This should be stated early in the document. You could then say that if ASM
must be used (which I think is only if the v4 client is using ASM, given the
stateless mapping?), then the IPv6 RP should be in the mAFTR.

For the IPv6 ASM case, there is no specific mention of Embedded RP; is it worth
adding this? It could simply deployment if all v6 routers behind the mAFTR
support it, as no explicit RP configuration would be needed, assuming all
mAFTRs could have unicast IPv6 addresses following the requirement of RFC 3956.
Though I’d rather see SSM recommended.  Perhaps this can be mentioned as
possible in 5.1?

You might want to review which notes in Appendix B could be brought forward to
the main text, e.g., B4 on where the IPv6 RP is located, or B3 on load
balancing. Not a big issue, but this information could otherwise be lost in an

Specific comments:

- Section 3 - perhaps mention here that the scope includes a dual-stack host on
an IPv4 access network (integrated mB4 function in the host)? - It’s content
singular, not plural (many instances in the document/Appendix).

- Section 4.1 perhaps add emphasis here that the mapping is stateless?
- I agree with the comments of the other INT-DIR reviewer that the use of
uPrefix64 and mPrefix64 is confusing, given the prefix in practice is a /96. 
While the NAT64 spec has the same issue, that document very clearly states the
prefix is a /96 and also includes the well-known prefix example (64:ff9b::/96)
early in the document. You might consider doing this in Section 2? - Further to
this, is a well-known /96 uPrefix64 useful for your draft as well?

p.6 Figure 1
- Make it clear in the diagram where the MLD Querier lies; presumably the first
hop IPv6 router in the IPv6 network? - There is a missing “^" in the diagram
for the MLD Report (currently a “:") - The mAFTR and the mB4 are technically in
the IPv6 network, or have one interface in it; the diagram could be clearer;
perhaps indicate the protocol with a vertical bar to the left/right? - Add an
IPv4 DR label to the mAFTR in the diagram?

- Para 3 - say it’s the IPv4 DR for clarity.
- Para 3 - The last sentence is in the event that the recommendation to have
the IPv6 RP in the mAFTR is not followed - emphasise that? - There’s a few
instances of “to the” which I think should be “towards the”, e.g. “towards the
mB4” not "to the mB4” on line 3, and “towards the MLD Querier” in paragraph
two. - Section 4.2, last paragraph; any issues routing a /96 internally this
way? I’d assume not, since NAT64 uses a similar type of approach. You’d need to
be clear that /96 prefixes can be routed at least, and not filtered in any way.

- Section 5.2 - “Concatenate the /96 mPrefix64….” adding “the /96” (else it’s
not concatenation)

- “located upstream” - more specifically, it’s the first hop IPv6 router, I
think? - What do you mean by “router portion” here?  You use this phrase in a
number of places.  Clarify?

- In 6.2, you mean destination multicast group, not destination address?
- I’d like to see Section 6.5 expanded, as I find it confusing as is. There are
very different ranges of scopes for IPv4 and IPv6 multicast (IPv4 has 239/8 for
“private” groups, otherwise you can’t tell by looking at the group address,
while IPv6 has 16 explicit scope labels), so how do you map? And why would you
have more than one mPrefix64 per mAFTR - can you give an example - is this for
multiple content provider networks?

- In 7.3, for IPv6, if using SSM or where the RP is in the mAFTR, this point is
moot? - In 7.4, destination address is destination multicast group, and remove
“multicast” from "IPv6 multicast source address" - 7.5 seems to repeat much of

- Section 8 - not clear to me how that scope mapping would be configured. Can
you give a brief example?

- Appendix A - “players intervene” -> “types of provider are involved”

- Which "issue mentioned above”?  Please clarify.