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

[Tim Chown <[e-mail]>]

Hi Med,

On 15 Dec 2016, at 07:24, [e-mail]<mailto:[e-mail]> wrote:

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]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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.

I understand the assumption, it was simply a suggestion that we should be recommending use of SSM ahead of ASM, to simplify operation, and that there’s an opportunity to captured that recommendation in this text. The topic has come up in at least the two most recent mboned meetings.

You could for example change the first paragraph of section 4.2 from:

"When an IPv4 receiver connected to the device that embeds the mB4

   capability wants to subscribe to an IPv4 multicast group, it sends an
   IGMP Report message towards the mB4.  The mB4 creates the IPv6
   multicast group (G6) address using mPrefix64 and the original IPv4
   multicast group address.  If the receiver sends a source-specific
   IGMPv3 Report message, the mB4 will create the IPv6 source address
   (S6) using uPrefix64 and the original IPv4 source address.”


To:


"When an IPv4 receiver connected to the device that embeds the mB4
   capability wants to subscribe to an IPv4 multicast group, it sends an
   IGMP Report message towards the mB4.  The mB4 creates the IPv6
   multicast group (G6) address using mPrefix64 and the original IPv4
   multicast group address.


As described in Section 1 of RFC 4607, use of SSM is recommended.  SSM

   also simplifies the operation of the stateless translation mechanism

   described in the document. In the SSM case, the receiver will send a source-specific

   IGMPv3 Report message, and the mB4 will create the IPv6 source address
   (S6) using uPrefix64 and the original IPv4 source address."

or you could add at the end of Section 1 something like this:

"This document describes a stateless translation mechanism that supports either
SSM or ASM operation. The recommended in section 1 of RFC 4607 is that multicast
services use SSM where possible; the operation of this translation mechanism is
also simplified when SSM is used, e.g. considerations for placement of the IPv6 RP
are no longer relevant."

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.

I see you have done this, thanks.

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.

So at the end of 5.1 you could say:

“The stateless translation mechanism described in this document does not preclude use of Embedded-RP [RFC 3956]."

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

Sorry, yes I did mean IPv6, and thanks.

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

Thanks.

 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.

OK, so the mechanism described in the document could use the 64:ff9b::/96 prefix for uPrefix64, or not?  I guess this is covered in 5.2, but you could clarify this.

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.

OK.

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

Fair enough.

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

OK.

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

Thanks.

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.

RFC6052 does allow prefixes that are not /96, e.g. /64, as described in 2.2, but I think in your document we’re always using a /96 for uPrefix64 and mPrefix64, in which case the above is good?

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.

So add a reference to that for the first use of “router portion”?

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.

Thanks.

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.

OK.

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?

I think the whole section only applies to ASM?

- 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

Thanks.

Best wishes,
Tim