Germy,
We considered this but not all option are address based, therefore we
cannot determine the IP version by opt value only.
I am not familiar about how the format was original determined either.
Maybe someone who works on this format before can help clarify?
Xu Han
On 09/26/2014 03:17 PM, Germy Lure wrote:
Hi, Xu Han,
Can we distinguish version by parsing the opt_value? Is there any
service binding v4 address but providing service for v6? or v6 for v4?
BTW, Why not the format is directly opt_name_value:opt_value_value,
like "server-ip-address":"1.1.1.1"?
BR,
Germy
On Fri, Sep 26, 2014 at 2:39 PM, Xu Han Peng <[email protected]
<mailto:[email protected]>> wrote:
Currently the extra_dhcp_opts has the following API interface on a
port:
{
"port":
{
"extra_dhcp_opts": [
{"opt_value": "testfile.1","opt_name": "bootfile-name"},
{"opt_value": "123.123.123.123", "opt_name":
"tftp-server"},
{"opt_value": "123.123.123.45", "opt_name":
"server-ip-address"}
],
....
}
}
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. (
https://bugs.launchpad.net/neutron/+bug/1356383)
Here are some thoughts about the new format:
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.
"extra_dhcp_opts": [
{"opt_value": "testfile.1","opt_name": "bootfile-name"},
{"opt_value": "123.123.123.123", "opt_name":
"*v4:*tftp-server"},
{"opt_value": "[2001:0200:feed:7ac0::1]", "opt_name":
"*v6:*dns-server"}
]
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.
"extra_dhcp_opts": {
"ipv4": [
{"opt_value": "testfile.1","opt_name":
"bootfile-name"},
{"opt_value": "123.123.123.123", "opt_name":
"tftp-server"},
],
"ipv6": [
{"opt_value": "[2001:0200:feed:7ac0::1]",
"opt_name": "dns-server"}
]
}
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.
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?
Thanks,
Xu Han
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
