Copying my response on the review below: Yes that completely makes sense Sean. In our original proposal we wanted to allow the user to initiate a subnet-create without providing a CIDR, and have an 'ipv6_pd_enabled' flag which could be set in the API call to tell Neutron that this particular subnet needs to have its CIDR defined by PD. The consensus from the community early in the Kilo development cycle was that changes to the API should be avoided if at all possible, and so it was agreed that we would use a special ::/64 CIDR for the initial implementation. In the IPv6 meeting yesterday you mentioned doing this with an extension rather than modifying the core API. Could you go into some detail about how you see this extension looking?
Cheers, John On 18/03/2015 13:12, "Sean M. Collins" <[email protected]> wrote: >Hi all, > >I recently posted this comment in the review for >https://review.openstack.org/#/c/158697/, >and wanted to post it here so that people can respond. Basically, I have >concerns that I raised during the spec submission process >(https://review.openstack.org/#/c/93054/). > >I'm still not totally on board with the proposed user facing API, where >they create a subnet cidr of ::/64, then later it is updated by Neutron >to actually be the cidr that is delegated. My hope is to have a user >facing API that would require little to no user input (since we are >relying on an external system to delegate us a subnet) and Neutron would >create the required constructs internally. My hope is that either the new >IPAM subsystem for subnet allocations would provide this, or that a small >API extension could "paper over" some of the sharper edges. > >Basically, I know we need the user to create a CIDR of ::/64 to satisfy >the Neutron core API's requirement that a subnet MUST have a CIDR when >creating, but I think that in the case of prefix delegation we shouldn't >expose this sharp edge to the user by default. > >Does this make sense? > >-- >Sean M. Collins > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
