Subject: Re: [dhcwg] Review of draft-ietf-dhc-dynamic-shared-v4allocation-02

From: Qi Sun <[email-masked]>
Date: Wed, 21 Jan 2015 14:15:06 +0100

Dear Tom, 

Thanks a lot for the review! Some responses inline.

On Oct 31, 2014, at 12:19 AM, Tom Taylor <[email-masked]> wrote:

> Hi. Thought I'd respond to the call for review.
> 
> Tom Taylor
> 
> Summary:
> 
> Major issues:
> 
> Minor issues:
> 
> 1) There seems to be an inconsistency between Section 5 and 7 and Section 6 on the other:
> 
> Sec. 5 and 7: The client MAY insert an
>       OPTION_V4_PORTPARAMS with a non-zero value in the PSID-Len field
>       to indicate a preferred size for the restricted port set to the
>       DHCP 4o6 Server.
> 
> Sec. 6, third bullet:
>    o  The address requested in the 'Requested IP Address' option along
>      with the PSID in the OPTION_V4_PORTPARAMS, if the requested pair
>      of address and PSID is valid and not already allocated
> 
> So which is it, PSID value or (much trickier to manage) PSID length? In the latter case, I can see garbage collection issues, as the PSID space gets fragmented by repeated client attachments and detachments from the network.

[Qi] I think the answer is, both are needed but in different scenarios. If a client hasn’t been configured with an IPv4 address with a PSID before, or the client only cares about the port space it wants, then it only specifies the PSID length; If the client would like to use some specific IPv4 address and that PSID value, then it should request both the IPv4 address and the PSID value. On the server side, when receiving a DISCOVER message, if there is ‘Requested IP Address’ option then the server should use the PSID value (and IPv4 address, of course) for valid lease selection. How about we do some rewording to make it clear?

As for the garbage collection issue, I think it’s more an implementation issue than a protocol design problem. The server can certainly allocate a different PSID value from the one that the client requests. So that depends on the server’s policy about port space management. Would this be OK for you?

> 
> 2) The operator configures a reserved set of ports. The advice on PSID assignment to exclude these ports at the end of Section 8 has a SHOULD NOT. Under what circumstances would the server violate its configured policy?

[Qi] What about if we were to make this a MUST NOT, and add text to say 'unless the operator has explicitly configured otherwise (e.g. by allocating a full IPv4 address)’?

> Editorial and nits:

[Qi] All fixed.

Thanks,
Qi

> 
> 1) Abstract, first sentence of second paragraph:
> 
> OLD
> 
>   Due to the nature of IP addresses sharing, some limitations to their
>   applicability are necessary.
> 
> NEW
> 
>   Due to the nature of IP address sharing, some limitations to its
>   applicability are necessary.  ^^                             ^^^
> 
> In English, "address" is sort of a kludged noun-turned-adjective modifying "sharing" and "IP address sharing" is a singular subject.
> 
> 2) Section 2, RFC 2119 reference is duplicated.
> 
> 3) Section 6, end of second last paragraph: s/messages/message/.
> 
> 4) Section 7.1, first bullet, rewrite in active voice:
> 
> OLD
> 
>   o  Only port-aware protocols or ICMP implementing [RFC5508] MUST be
>      used.
> (Doesn't quite say what you want.)
> 
> NEW
> 
>   o  The client MUST use only port-aware protocols or ICMP implementing [RFC5508].
> 
> 5) Section 8, fourth bullet below Figure 1, s/valid/the value/
> 
> 6) Section 8, final paragraph, for accuracy and consistency with previous text. The SHOULD NOT as opposed to MUST NOT is questioned above as a minor issue.
> 
> OLD
> 
> In order to exclude the system ports ([RFC6335]) or ports saved by
>   ISPs, the former port-sets that contain well-known ports SHOULD NOT
>   be assigned.
> 
> NEW
> 
> Some PSIDs may include ports within ranges excluded by the operator (e.g., the well-known ports 0-1023). These SHOULD NOT be assigned to any client.
>

---

From: Qi Sun <[email-masked]>
Date: Thu, 22 Jan 2015 22:29:14 +0100

Dear Tom, 

> [Qi] I think the answer is, both are needed but in different scenarios. If a client hasn’t been configured with an IPv4 address with a PSID before, or the client only cares about the port space it…

[Qi] How about we make the following change to sec 5 & 7:
OLD:
       The client MAY insert an
       OPTION_V4_PORTPARAMS with a non-zero value in the PSID-Len field
       to indicate a preferred size for the restricted port set to the
       DHCP 4o6 Server.
NEW:
       The client MAY include an
       OPTION_V4_PORTPARAMS with a non-zero value in the PSID-Len field
       to indicate a preferred size for the restricted port set to the
       DHCP 4o6 Server.  Also, the client MAY include the ‘requested IP address’
       option along with an OPTION_V4_PORTPARAMS to suggest that a particular 
       pair of IPv4 address and PSID be assigned.

And change to sec 6, bullet 3 & 4:
OLD:
   o  The address requested in the 'Requested IP Address' option along
      with the PSID in the OPTION_V4_PORTPARAMS, if the requested pair
      of address and PSID is valid and not already allocated, ELSE
   o  A new address with a PSID allocated from the server's pool of
      available addresses and PSIDs.
NEW:
   o  The address requested in the 'Requested IP Address’ option along
      with the PSID parameters requested in the OPTION_V4_PORTPARAMS, 
      if that pair of address and PSID is valid and not already allocated, ELSE
   o  A new address with a PSID allocated from the server's pool of
      available addresses and PSIDs.  The server MAY assign a PSID 
      with the length suggested in the OPTION_V4_PORTPARAMS 
      it received.

Would the above changes work for you?

Thanks,
Qi

---

From: Tom Taylor <[email-masked]>
Date: Wed, 28 Jan 2015 23:00:57 -0500

Sorry to be so slow in responding. See responses marked [PTT] below.

Tom Taylor

On 21/01/2015 8:15 AM, Qi Sun wrote:
>> Sec. 5 and 7: The client MAY insert an OPTION_V4_PORTPARAMS with a
>> non-zero value in the PSID-Len field to indicate a preferred size
>> for the restricted port set to the DHCP 4o6 Server.
>>
>> Sec. 6, third bullet: o  The address requested in the 'Requested IP
>> Address' option along with the PSID in the OPTION_V4_PORTPARAMS, if
>> the requested pair of address and PSID is valid and not already
>> allocated
>>
>> So which is it, PSID value or (much trickier to manage) PSID
>> length? In the latter case, I can see garbage collection issues, as
>> the PSID space gets fragmented by repeated client attachments and
>> detachments from the network.
>
> [Qi] I think the answer is, both are needed but in different
> scenarios. If a client hasn’t been configured with an IPv4 address
> with a PSID before, or the client only cares about the port space it
> wants, then it only specifies the PSID length; If the client would
> like to use some specific IPv4 address and that PSID value, then it
> should request both the IPv4 address and the PSID value. On the
> server side, when receiving a DISCOVER message, if there is
> ‘Requested IP Address’ option then the server should use the PSID
> value (and IPv4 address, of course) for valid lease selection. How
> about we do some rewording to make it clear?

[PTT] You could do it by adding a sentence to step 1 in Section 5 and to 
the similar text in the first paragraph of Section 7: "The client MAY 
further insert a value in the PSID field to indicate the specific set of 
ports that it wishes to be allocated."

[PTT] There is a problem here. What if the client wants PSID=0? How does 
one distinguish this from a length-only hint? One possibility is to take 
a bit from the PSID-len field and use it as a flag to indicate that a 
PSID value has been provided.
>
> As for the garbage collection issue, I think it’s more an
> implementation issue than a protocol design problem. The server can
> certainly allocate a different PSID value from the one that the
> client requests. So that depends on the server’s policy about port
> space management. Would this be OK for you?
>
[PTT] OK
>>
>> 2) The operator configures a reserved set of ports. The advice on
>> PSID assignment to exclude these ports at the end of Section 8 has
>> a SHOULD NOT. Under what circumstances would the server violate its
>> configured policy?
>
> [Qi] What about if we were to make this a MUST NOT, and add text to
> say 'unless the operator has explicitly configured otherwise (e.g. by
> allocating a full IPv4 address)’?
>
[PTT] OK
> Thanks, Qi
>> Due to the nature of IP addresses sharing, some limitations to
>> their applicability are necessary.
>>
>> NEW
>>
>> In English, "address" is sort of a kludged noun-turned-adjective
>> modifying "sharing" and "IP address sharing" is a singular
>> subject.
>>
>> o  Only port-aware protocols or ICMP implementing [RFC5508] MUST
>> be used. (Doesn't quite say what you want.)
>>
>> NEW
>>
>> 6) Section 8, final paragraph, for accuracy and consistency with
>> previous text. The SHOULD NOT as opposed to MUST NOT is questioned
>> above as a minor issue.
>>
>> OLD
>>
>> ISPs, the former port-sets that contain well-known ports SHOULD
>> NOT be assigned.
>>
>> NEW
>>
>> Some PSIDs may include ports within ranges excluded by the operator
>> (e.g., the well-known ports 0-1023). These SHOULD NOT be assigned
>> to any client.
>>
>
>

---

From: "Linhui Sun" <[email-masked]>
Date: Thu, 29 Jan 2015 15:03:12 +0800

Hi, Tom

I also reviewed this document, please see some comments inline (marked [Linhui]).
 
From: Tom Taylor
Date: 2015-01-29 12:00
To: Qi Sun
CC: [email-masked] WG; draft-ietf-dhc-dynamic-shared-v4allocation.authors
Subject: Re: [dhcwg] Review of draft-ietf-dhc-dynamic-shared-v4allocation-02
Sorry to be so slow in responding. See responses marked [PTT] below.
 
Tom Taylor

 

[Linhui] I think the key point is whether a client will ask for a specific PSID if it was not configured with an IPv4 address before.
If so, the way you provided is necessary and useful.
If not, a client should always provide a "Requested IP Address" option. And I think this can be used to distinguish from a length-only hint.

[PTT] OK
[PTT] OK
>> (e.g., the well-known ports 0-1023). These SHOULD NOT be assigned
 
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg 

Best Regards,
Linhui

---

From: Qi Sun <[email-masked]>
Date: Thu, 29 Jan 2015 11:07:29 +0100

Dear Tom, 

Thanks for the reply. Please see inline.

Best Regards,
Qi

On Jan 29, 2015, at 5:00 AM, Tom Taylor <[email-masked]> wrote:

> [PTT] You could do it by adding a sentence to step 1 in Section 5 and to the similar text in the first paragraph of Section 7: "The client MAY further insert a value in the PSID field to indicate the specific set of ports that it wishes to be allocated."
> 
> [PTT] There is a problem here. What if the client wants PSID=0? How does one distinguish this from a length-only hint? One possibility is to take a bit from the PSID-len field and use it as a flag to indicate that a PSID value has been provided.

[Qi] I think we need to make it clear that:
1) We’re talking about  DHCPDISCOVER message only.
2) The server can surely ignore those hints and just allocate what it has. 

My proposal here would be, linking the ‘requested ip address’ option and OPTION_V4_PORTPARAMS in the DISCOVER message: 
1) if both ‘requested ip address’ option and OPTION_V4_PORTPARAMS present, then the client is indicating to request both that IP address and that PSID (length and value, no matter PSID is 0 or not).
2) if only OPTION_V4_PORTPARAMS presents, the client is indicating to request a PSID with that length. 
3) if only ‘requested ip address’ option, that’s RFC2131, which is out of scope for this document.

Back to the text in the draft. The server side logic is already there, the bullets in the section of ’Server behavior’. It’s not that clear on the client side. So I propose to make the following changes:

[OLD] Section 5, bullet 1
   1.  When the client constructs the DHCPv4 DHCPDISCOVER message to be
       transported within the DHCPv4-query message, the DHCPDISCOVER
       message MUST include the client identifier option (constructed as
       per [RFC4361] and the Parameter Request List (PRL) option with
       the code of OPTION_V4_PORTPARAMS.  The client MAY insert an
       OPTION_V4_PORTPARAMS with a non-zero value in the PSID-Len field
       to indicate a preferred size for the restricted port set to the
       DHCP 4o6 Server.
[NEW]
   1.  When the client constructs the DHCPv4 DHCPDISCOVER message to be
       transported within the DHCPv4-query message, the DHCPDISCOVER
       message MUST include the client identifier option (constructed as
       per [RFC4361]) and the Parameter Request List (PRL) option with
       the code of OPTION_V4_PORTPARAMS.

[OLD] Section 7
   The client MAY use a non-zero value for the
   PSID-len field within OPTION_V4_PORTPARAMS in the DHCPDISCOVER
   message, for requesting a specific size of port set.
[NEW]
   If a client has been successfully allocated
   and IPv4 address and PSID previously, the client MAY include in the
   DHCPDISCOVER message the 'requested IP address' option along with an
   OPTION_V4_PORTPARAMS to request that a specific IPv4 address and PSID
   be re-assigned.  Alternatively, the client MAY omit the 'requested IP
   address' option, but include an OPTION_V4_PORTPARAMS with a non-zero
   value in only the PSID-Len field, as a hint to the server for the
   preferred size of the port set.

Does it work for you?

Thanks.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 29 Jan 2015 08:28:06 -0500

Your proposed text works for me.

Tom

> Thanks for the reply. Please see inline.
...

>     preferred size of the port set.
...