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

[<[e-mail]>]

Hi Tim,

Thank you for the review.

Please see inline.

Cheers,
Med

De : Tim Chown [mailto:[e-mail]]
Envoyé : mercredi 14 décembre 2016 16:31
À : [e-mail]; [e-mail]; [e-mail]
Objet : INT-DIR review of draft-ietf-softwire-dslite-multicast-12

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.
[Med] Thank you.

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.

[Med] The document is designed without making any assumption whether SSM/ASM is (to be) used; this is really deployment-specific.

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.
[Med] This is mentioned in Section B.4. If you think it is better to mention it earlier, I can move that text to Section 4.

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?
[Med] Again, it is up to taste of the entity that deploys the multicast solution to decide what option is more appropriate for its context. This document does not require nor preclude the use of embedded-RP, in particular.

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.
[Med] Will consider this point.

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)?
[Med] I guess you meant dual-stack host on an IPv6 access network. Yes, this is in scope (see Section 6.4). I added this NEW text:

“Also, the document covers host built-in mB4 function.”

- It’s content singular, not plural (many instances in the document/Appendix).
[Med] Fixed.

p.6
- Section 4.1 perhaps add emphasis here that the mapping is stateless?
[Med] Done.

- 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.
[Med] A note was added to clarify the point raised by Zhen:

“Note: "64" is used as an abbreviation for IPv6-IPv4 interconnection.”

 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?
[Med] Makes sense.

- Further to this, is a well-known /96 uPrefix64 useful for your draft as well?
[Med] Whether an NSP or WKP is used is deployment-specific. This document adheres to RFC6052.

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?
[Med] Yes, but I don’t think adding it to the figure will have a value.

- There is a missing “^" in the diagram for the MLD Report (currently a “:")
[Med] Fixed. Thank you for catching this.

- 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?
[Med] The cloud is meant to indicate how these elements are interconnected. The text indicates whether this is an IPv4 or IPv6 leg.

- Add an IPv4 DR label to the mAFTR in the diagram?
[Med] The diagram does not aim to be exhaustive but to capture the location of mAFTR and mB and how IPv6 multicast tree is grafted to an IPv4 one. Adding other roles to the diagram will overload it.


p.7
- Para 3 - say it’s the IPv4 DR for clarity.
[Med] Changed:

   The mAFTR acts as the DR to which the uPrefix64-derived S6 is
   connected

to


   The mAFTR acts as the IPv4 DR to which the uPrefix64-derived S6 is

   connected


- 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?
[Med] Yes, if we add that recommendation, the text will be modified accordingly.

- 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.
[Med] Fixed. Thanks.

- 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.
[Med] This is not an issue. I added this NEW text:

“Injecting internal /96 routes is not problematic given the recommendation in [RFC7608] that requires that forwarding processes must be designed to process prefixes of any length up to /128.”

p.9
- Section 5.2 - “Concatenate the /96 mPrefix64….” adding “the /96” (else it’s not concatenation)
[Med] The text says that we are concatenating bits not prefixes. FWIW, this is the same wording we used in RFC6052. I changed the text to:

OLD:
Concatenate the mPrefix64 and the 32 bits of the IPv4 address to obtain a 128-bit address.

NEW:
Concatenate the mPrefix64 96 bits and the 32 bits of the IPv4 address to obtain a 128-bit address.

p.10
- “located upstream” - more specifically, it’s the first hop IPv6 router, I think?
[Med] Yes. I changed the text accordingly.

- What do you mean by “router portion” here?  You use this phrase in a number of places.  Clarify?
[Med] We meant this part: https://tools.ietf.org/html/rfc3376#section-6. We are using the same terminology defined in https://tools.ietf.org/html/rfc4605 (search for “host portion” and “router portion”). Please let me know that a modification is required to the text.

p.11
- In 6.2, you mean destination multicast group, not destination address?
[Med] Yes. Fixed.

- 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?
[Med] This is done following https://tools.ietf.org/html/rfc2365#section-8. I added a pointer to the text.

And why would you have more than one mPrefix64 per mAFTR - can you give an example - is this for multiple content provider networks?
[Med] A typical example is an enterprise network that provides both internal multicast content but also external one; the use of distinct prefixes can accommodate its usage. Such details are not added to the text because those are deployment-specific.

p.13
- In 7.3, for IPv6, if using SSM or where the RP is in the mAFTR, this point is moot?
[Med] This section is about switching from RPT to SPT, whether SSM or RP(mAFTR) are in use in the IPv6 multicast leg, the behavior will be the same in the AFTR. Do you have something in mind that needs to be discussed here?

- In 7.4, destination address is destination multicast group, and remove “multicast” from "IPv6 multicast source address"
[Med] Fixed. Thanks.

- 7.5 seems to repeat much of 6.5?
[Med] scope preservation is a requirement for both mB4 and mAFTR.


p.14
- Section 8 - not clear to me how that scope mapping would be configured. Can you give a brief example?
[Med] If scope are misconfigured (i.e., does not follow https://tools.ietf.org/html/rfc2365#section-8), some content may be leaked outside a local network, an administrative domain, etc. This is why we identified this point undert the security considerations.

p.16
- Appendix A - “players intervene” -> “types of provider are involved”
[Med] Fixed. Thanks.

p.17
- Which "issue mentioned above”?  Please clarify.
[Med] s/issue mentioned above/the version mismatch issue

Tim