<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Sep 26, 2014, at 2:39 AM, Xu Han Peng <<a href="mailto:pengxuhan@gmail.com">pengxuhan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<div bgcolor="#FFFFFF" text="#000000">
Currently the extra_dhcp_opts has the following API interface on a
port:<br>
<br>
{<br>
"port":<br>
{<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
"extra_dhcp_opts": [<br>
{"opt_value": "testfile.1","opt_name": "bootfile-name"},<br>
{"opt_value": "123.123.123.123", "opt_name":
"tftp-server"},<br>
{"opt_value": "123.123.123.45", "opt_name":
"server-ip-address"}<br>
],<br>
....<br>
}<br>
}<br>
<br>
During the development of DHCPv6 function for IPv6 subnets, we found
this format doesn't work anymore because an port can have both IPv4
and IPv6 address. So we need to find a new way to specify
extra_dhcp_opts for DHCPv4 and DHCPv6, respectively. (
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="https://bugs.launchpad.net/neutron/+bug/1356383">https://bugs.launchpad.net/neutron/+bug/1356383</a>)<br>
<br>
Here are some thoughts about the new format:<br>
<br>
Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4
or v6) so we can distinguish opts for v4 or v6 by parsing the
opt_name. For backward compatibility, no prefix means IPv4 dhcp opt.
<br>
<br>
"extra_dhcp_opts": [<br>
{"opt_value": "testfile.1","opt_name": "bootfile-name"},<br>
{"opt_value": "123.123.123.123", "opt_name": "<b>v4:</b>tftp-server"},<br>
{"opt_value": "[2001:0200:<a href="feed:7ac0::1]">feed:7ac0::1]</a>", "opt_name": "<b>v6:</b>dns-server"}<br>
]<br>
<br>
Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For
backward compatibility, both old format and new format are
acceptable, but old format means IPv4 dhcp opts. <br>
<br>
"extra_dhcp_opts": {<br>
"ipv4": [<br>
{"opt_value": "testfile.1","opt_name":
"bootfile-name"},<br>
{"opt_value": "123.123.123.123", "opt_name": "tftp-server"},<br>
],<br>
"ipv6": [<br>
{"opt_value": "[2001:0200:<a href="feed:7ac0::1]">feed:7ac0::1]</a>",
"opt_name": "dns-server"}<br>
]<br>
}<br>
<br>
The pro of Option1 is there is no need to change API structure but
only need to add validation and parsing to opt_name. The con of
Option1 is that user need to input prefix for every opt_name which
can be error prone. The pro of Option2 is that it's clearer than
Option1. The con is that we need to check two formats for backward
compatibility. <br>
<br>
We discussed this in IPv6 sub-team meeting and we think Option2 is
preferred. Can I also get community's feedback on which one is
preferred or any other comments?<br>
<br></div></blockquote><br></div><div>I’m -1 for both options because neither is properly backwards compatible. Instead we should add an optional 3rd value to the dictionary: “version”. The version key would be used to make the option only apply to either version 4 or 6. If the key is missing or null, then the option would apply to both. </div><div><br></div><div>mark</div><br></body></html>