Open Stack

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" <sean at coreitpro.com> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev