Subject: [dhcwg] Review of draft-ietf-softwire-multicast-prefix-option-11

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 12 Jan 2017 13:49:24 +0000

Hi:

A few comments on this draft.

Section 2:

The dslite-multicast draft uses uPrefix64 instead of U_PREFIX64? Consistency between the various softwire documents might be useful?

Nit: SSM_PREFIX64 has an extra closing parenthesis (after the RFC4607 reference).

Section 3:

I am not sure that the *-length fields are correctly documented? Can they really be 0-128. I understand 0 if there is none, and I can see 1-96 potentially, but does more than 96 make sense? It seems that the other documents referenced typically say to use the prefix (96 bits – perhaps zero extended if needed to make 96 bits) and then add 32-bits IPv4 for multicast (unicast is a bit more complex when prefix is not 96). But none of this other text seems to imply that the prefix length can be > 96?

Also, while 2001::/96 could be sent as 2001::/16 in terms of the option encoding (as bits 17 to 96 are 0), the two are vastly different in terms of what they might mean (if the prefix is always mapped to /96 it may not matter). I just wonder if this needs to be clarified some? I believe the first encoding (2001::/96 is always intended as that communicate the true prefix length).

Is the reference to “Section 6 of RFC7051” correct? Was this intended to be RFC 7227 (Section 6 there is titled “Avoid Conditional Formatting”).

I think it would be useful to clearly state that multiple instances of this option are allowed. Yes, if you carefully read the text (in Section 4 & 5) this is evident, but it is useful to state this explicitly when defining the option!

Section 5:

Nit: There are two “Pv4 mulitcast” instances; are these supposed to be “IPv4 multicast”?

Note here that the text for ASM and SSM says to insert last 32-bits. This would imply that a prefix length > 96 does not work. (See comments above for section 3.)

And, there is talk here about scope selection and adding the same reference as in Section 4 (to RFC7346) might be useful? Client implementers may not read the server section, so duplicating the reference here would be useful.

- Bernie

---

From: <[email-masked]>
Date: Thu, 12 Jan 2017 14:29:18 +0000

Hi Bernie, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Bernie Volz (volz) [mailto:[email-masked]]
> Envoyé : jeudi 12 janvier 2017 14:49
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; Terry Manderson
> Objet : Review of draft-ietf-softwire-multicast-prefix-option-11
> 
> Hi:
> 
> The dslite-multicast draft uses uPrefix64 instead of U_PREFIX64?
> Consistency between the various softwire documents might be useful?

[Med] Works for me. 

> Nit: SSM_PREFIX64 has an extra closing parenthesis (after the RFC4607

[Med] Fixed.

> 
> Section 3:
> 
> I am not sure that the *-length fields are correctly documented? Can they
> really be 0-128. I understand 0 if there is none, and I can see 1-96
> potentially, but does more than 96 make sense? It seems that the other
> documents referenced typically say to use the prefix (96 bits – perhaps
> zero extended if needed to make 96 bits) and then add 32-bits IPv4 for
> multicast (unicast is a bit more complex when prefix is not 96). But none
> of this other text seems to imply that the prefix length can be > 96?

[Med] As mentioned in Section 5, only 96 is allowed. I already fixed Section 3 accordingly. 

> 
> Also, while 2001::/96 could be sent as 2001::/16 in terms of the option
> encoding (as bits 17 to 96 are 0), the two are vastly different in terms
> of what they might mean (if the prefix is always mapped to /96 it may not
> matter). I just wonder if this needs to be clarified some? I believe the
> first encoding (2001::/96 is always intended as that communicate the true
> prefix length).
> 
> Is the reference to “Section 6 of RFC7051” correct? Was this intended to
> be RFC 7227 (Section 6 there is titled “Avoid Conditional Formatting”).

[Med] Section 6 of RFC7051 is correct. It documents the use of Well-known DNS name for the unicast-only case. I updated the text to make this explicit. 

NEW:
   Such side effect conflicts with the recommendation to support the
   Well-Known DNS Name heuristic discovery-based method for unicast-only
   environments (Section 6 of [RFC7051]).

> 
> I think it would be useful to clearly state that multiple instances of
> this option are allowed. Yes, if you carefully read the text (in Section 4
> & 5) this is evident, but it is useful to state this explicitly when
> defining the option!

[Med] Happily. I added to NEW text to section 3:

"Multiple instances of OPTION_V6_PREFIX64 may be returned to a DHCPv6 client."

> Nit: There are two “Pv4 mulitcast” instances; are these supposed to be

[Med] Fixed.

> 
> Note here that the text for ASM and SSM says to insert last 32-bits. This
> would imply that a prefix length > 96 does not work. (See comments above
> for section 3.)

[Med] Yes, only 96 is allowed. See above.

> 
> And, there is talk here about scope selection and adding the same
> reference as in Section 4 (to RFC7346) might be useful? Client
> implementers may not read the server section, so duplicating the reference
> here would be useful.

[Med] Works for me. Done!