[Int-dir] INT-DIR review of draft-ietf-softwire-dslite-multicast-12

[Tim Chown <[e-mail]>]

Hi,

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 <http://www.ietf.org/iesg/directorate.html>.

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

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

Specific comments:
--------------------------

p.5
- 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).

p.6
- 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?

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

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

p.10
- “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?

p.11
- 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?

p.13
- 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 6.5?

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

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

p.17
- Which "issue mentioned above”?  Please clarify.

Tim