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

From: Sheng Jiang <[email-masked]>
Date: Mon, 09 Jan 2017 19:55:01 -0800

Reviewer: Sheng Jiang
Review result: Has Nits

Summary: This draft is almost ready for publication as a standard
track RFC.

Major issues:

Minor issues:

“the specification of a DHCPv6 option that could be used to discover
   unicast PREFIX64s in environments where multicast is not enabled.
   Such side effect conflicts with the recommendation documented in
   Section 6 of [RFC7051].”

It is unclear how the Section 6 of RFC7051 relevant with the content
above. It would be necessary to quote particular content of RFC7051
and give necessary analysis.

Nits:

“the Pv4 multicast address is inserted in the last 32 bits of the
IPv4-embedded IPv6
   multicast address.”

Pv4//IPv4

---

From: <[email-masked]>
Date: Tue, 10 Jan 2017 06:43:56 +0000

Hi Sheng, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Sheng Jiang [mailto:[email-masked]]
> Envoyé : mardi 10 janvier 2017 04:55
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; draft-ietf-softwire-multicast-
> [email-masked]
> Objet : Review of draft-ietf-softwire-multicast-prefix-option-11
> 
> Reviewer: Sheng Jiang
> Review result: Has Nits
> 

[Med] What about:  

OLD: 

   Note that it was tempting to define three distinct DHCPv6 options,
   but that approach was not adopted because it has a side effect: the
   specification of a DHCPv6 option that could be used to discover
   unicast PREFIX64s in environments where multicast is not enabled.
   Such side effect conflicts with the recommendation documented in
   Section 6 of [RFC7051].

NEW: 
   Note that it was tempting to define three distinct DHCPv6 options,
   but that approach was not adopted because it has a side effect: the
   specification of a DHCPv6 option that could be used to discover
   unicast PREFIX64s in environments where multicast is not enabled.
   Such side effect conflicts with the recommendation documented in
   Section 6 of [RFC7051]. As a reminder, that recommendation is to
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   to support the Well-Known DNS Name heuristic discovery-based method
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   for unicast-only environments.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 

Better?

> “the Pv4 multicast address is inserted in the last 32 bits of the
[Med] Fixed.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 10 Jan 2017 06:47:54 +0000

Hi, Med,

Thanks for reply. The content looks clear now. Reword into one sentence.

Such side effect conflicts with the recommendation documented in
    Section 6 of [RFC7051], in which 
                       ^^^^^^^
    to support the Well-Known DNS Name heuristic discovery-based method 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    for unicast-only environments is recommended.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Cheers,

Sheng

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2017 2:44 PM
> To: Sheng Jiang; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Review of draft-ietf-softwire-multicast-prefix-option-11
> 
> Hi Sheng,
> 
> > De : Sheng Jiang [mailto:[email-masked]] Envoyé : mardi 10
> > janvier 2017 04:55 À : [email-masked] Cc : [email-masked];
> > [email-masked]; draft-ietf-softwire-multicast-
> > [email-masked] Objet : Review of
> > draft-ietf-softwire-multicast-prefix-option-11
> >
> > Reviewer: Sheng Jiang
> > Review result: Has Nits
> >

---

From: <[email-masked]>
Date: Tue, 10 Jan 2017 07:17:19 +0000

Re-,

OK, thanks. 

If you prefer one sentence, then I can reword it to: 

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

Cheers,
Med

> Envoyé : mardi 10 janvier 2017 07:48
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : RE: Review of draft-ietf-softwire-multicast-prefix-option-11
> 
> Hi, Med,
>

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 10 Jan 2017 07:17:59 +0000

Looks good for me, thanks. Sheng

> Sent: Tuesday, January 10, 2017 3:17 PM
> > janvier 2017 07:48 À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Cc
> > : [email-masked]; [email-masked]; draft-ietf-softwire-multicast-
> > [email-masked] Objet : RE: Review of
> > > Subject: RE: Review of
> > > > It is unclear how the Section 6 of RFC7051 relevant with the
> > > > content above. It would be necessary to quote particular content
> > > > of RFC7051 and give necessary analysis.
> > > >
> > >
> > > [Med] What about:
> > >
> > > OLD:
> > >

---

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, 

Please see inline.

Cheers,
Med

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

[Med] Works for me. 

[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:

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

[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!