[openstack-dev] [neutron] Neutron should disallow /32 CIDR
emagana at plumgrid.com
Tue Jan 28 23:00:49 UTC 2014
Well say Carl!
I am sorry I did not get back to you on this topic before.
In general and after thinking about it, it makes sense to leave could
admin to adage the /32 cases if any.
On 1/28/14 1:46 PM, "Carl Baldwin" <carl at ecbaldwin.net> wrote:
>I think I agree. The new check isn't adding much value and we could
>debate for a long time whether /30 is useful and should be disallowed
>or not. There are bigger fish to fry.
>On Fri, Jan 24, 2014 at 10:43 AM, Paul Ward <wpward at us.ibm.com> wrote:
>> Given your obviously much more extensive understanding of networking
>> mine, I'm starting to move over to the "we shouldn't make this fix"
>> Mostly because of this:
>> "CARVER, PAUL" <pc2929 at att.com> wrote on 01/23/2014 08:57:10 PM:
>>> Putting a friendly helper in Horizon will help novice users and
>>> provide a good example to anyone who is developing an alternate UI
>>> to invoke the Neutron API. I¹m not sure what the benefit is of
>>> putting code in the backend to disallow valid but silly subnet
>>> masks. I include /30, /31, AND /32 in the category of ³silly² subnet
>>> masks to use on a broadcast medium. All three are entirely
>>> legitimate subnet masks, it¹s just that they¹re not useful for end
>>> host networks.
>> My mindset has always been that we should programmatically prevent
>> that are definitively wrong. Of which, these netmasks apparently are
>> So it would seem we should leave neutron server code alone under the
>> assumption that those using CLI to create networks *probably* know what
>> they're doing.
>> However, the UI is supposed to be the more friendly interface and
>> this is the more appropriate place for this change? As I stated before,
>> horizon prevents /32, but allows /31.
>> I'm no UI guy, so maybe the best course of action is to abandon my
>> gerrit and move the launchpad bug back to unassigned and see if someone
>> horizon experience wants to pick this up. What do others think about
>> Thanks again for your participation in this discussion, Paul. It's been
>> very enlightening to me.
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev