Open Stack

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 <pengxuhan at gmail.com 
> <mailto:pengxuhan at gmail.com>> 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
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140926/14426766/attachment.html>