<div dir="ltr">Hi, Xu Han,<div>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?</div><div><br></div><div>BTW, Why not the format is directly opt_name_value:opt_value_value, like "<span style="font-family:arial,sans-serif;font-size:12.8000001907349px">server-ip-address</span>":"1.1.1.1"?</div><div><br></div><div>BR,</div><div>Germy</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 26, 2014 at 2:39 PM, Xu Han Peng <span dir="ltr"><<a href="mailto:pengxuhan@gmail.com" target="_blank">pengxuhan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Currently the extra_dhcp_opts has the following API interface on a
    port:<br>
    <br>
    {<br>
        "port":<br>
        {<br>
    
            "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. (
    
    <a href="https://bugs.launchpad.net/neutron/+bug/1356383" target="_blank">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:feed:7ac0::1]", "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:feed:7ac0::1]",
    "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>
    Thanks,<br>
    Xu Han<br>
  </div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>