<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Mark's suggestion works for me as well. If no one objects, I am
    going to start the implementation. <br>
    <br>
    Thanks,<br>
    Xu Han<br>
    <br>
    <div class="moz-cite-prefix">On 09/27/2014 01:05 AM, Mark McClain
      wrote:<br>
    </div>
    <blockquote
      cite="mid:AE9B156A-E6B3-4B17-8614-994E3B38E0B7@mcclain.xyz"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <br>
      <div>
        <div>On Sep 26, 2014, at 2:39 AM, Xu Han Peng <<a
            moz-do-not-send="true" 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 moz-do-not-send="true"
              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
              moz-do-not-send="true" 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
              moz-do-not-send="true" 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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>