Open Stack

Excellent points guys!

Salvatore, It was you presenting that blueprint in San Diego? Hopefully we
can get more people involved. I will not call it NATaaS Š

Harshad,

I also like to simplify as much as possible NAT configuration, in and out
networks and that is  :-)

Rudra,

IPAM extensions sounds very interesting and some how alignment to have NAT
implemented as individual service allowing vendor-technologies to be
included as well in Neutron but in the case of the AWS I don't see going in
the same direction, it seems like two different approaches, what do you
think?

Thanks,

Edgar


From:  Rudra Rugge <rrugge at juniper.net>
Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
Date:  Thursday, October 10, 2013 5:22 PM
To:  OpenStack List <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [Neutron] Common requirements for services'
discussion

Here are the blueprints (mentioned by Harshad below) to add complete AWS
VPC compatibility in Openstack. AWS EC2 compatibility already exists in
Openstack. 

https://blueprints.launchpad.net/neutron/+spec/ipam-extensions-for-neutron
https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
https://blueprints.launchpad.net/nova/+spec/aws-vpc-support

Services extension is relevant to NATaas (or Natasha :)), VPNaas,
in AWS VPC.

Regards,
Rudra

On Oct 10, 2013, at 6:15 AM, Harshad Nakil <hnakil at contrailsystems.com>
 wrote:

> Agree, 
> I like what AWS had done. Have a concept of NAT instance. 90 % use cases are
> solved by just specifying
> Inside and outside networks for the NAT instance.
> 
> If one wants fancier NAT config they can always use NATaas API(s)
> To configure this instance.
> 
> There is a blueprint for bringing Amazon VPC API compatibility to nova and
> related extensions to quantum already propose concept of NAT instance.
> 
> How the NAT instance is implemented is left to the plugin.
> 
> Regards 
> -Harshad
> 
> 
> On Oct 10, 2013, at 1:47 AM, Salvatore Orlando <sorlando at nicira.com> wrote:
> 
>> Can I just ask you to not call it NATaas... if you want to pick a name for
>> it, go for Natasha :)
>> 
>> By the way, the idea of a NAT service plugin was first introduced at the
>> Grizzly summit in San Diego.
>> One hurdle, not a big one however, would be that the external gateway and
>> floating IP features of the L3 extension already implicitly implements NAT.
>> It will be important to find a solution to ensure NAT can be configured
>> explicitly as well while allowing for configuring external gateway and
>> floating IPs through the API in the same way that we do today.
>> 
>> Apart from this, another interesting aspect would be to be see if we can come
>> up with an approach which will result in an API which abstracts as much as
>> possible networking aspects. In other words, I would like to avoid an API
>> which ends up being "iptables over rest", if possible.
>> 
>> Regards,
>> Salvatore
>> 
>> 
>> On 10 October 2013 09:55, Bob Melander (bmelande) <bmelande at cisco.com> wrote:
>>> Hi Edgar,
>>> 
>>> I'm also interested in a broadening of NAT capability in Neutron using the
>>> evolving service framework.
>>> 
>>> Thanks,
>>> Bob
>>> 
>>> From: Edgar Magana <emagana at plumgrid.com>
>>> Reply-To: OpenStack Development Mailing List
>>> <openstack-dev at lists.openstack.org>
>>> Date: onsdag 9 oktober 2013 21:38
>>> To: OpenStack List <openstack-dev at lists.openstack.org>
>>> Subject: Re: [openstack-dev] [Neutron] Common requirements for services'
>>> discussion
>>> 
>>> Hello all,
>>> 
>>> Is anyone working on NATaaS?
>>> I know we have some developer working on Router as a Service and they
>>> probably want to include NAT functionality but I have some interest in
>>> having NAT as a Service.
>>> 
>>> Please, response is somebody is interested in having some discussions about
>>> it.  
>>> 
>>> Thanks,
>>> 
>>> Edgar
>>> 
>>> From: Sumit Naiksatam <sumitnaiksatam at gmail.com>
>>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>>> Date: Tuesday, October 8, 2013 8:30 PM
>>> To: OpenStack List <openstack-dev at lists.openstack.org>
>>> Subject: [openstack-dev] [Neutron] Common requirements for services'
>>> discussion
>>> 
>>> Hi All,
>>> 
>>> We had a VPNaaS meeting yesterday and it was felt that we should have a
>>> separate meeting to discuss the topics common to all services. So, in
>>> preparation for the Icehouse summit, I am proposing an IRC meeting on Oct
>>> 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common
>>> aspects related to the FWaaS, LBaaS, and VPNaaS.
>>> 
>>> We will begin with service insertion and chaining discussion, and I hope we
>>> can collect requirements for other common aspects such as service agents,
>>> services instances, etc. as well.
>>> 
>>> Etherpad for service insertion & chaining can be found here:
>>> https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining
>>> 
>>> Hope you all can join.
>>> 
>>> Thanks,
>>> ~Sumit.
>>> 
>>> 
>>> _______________________________________________ OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________ OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131011/f3a26a55/attachment.html>