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 <rru...@juniper.net> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> Date: Thursday, October 10, 2013 5:22 PM To: OpenStack List <openstack-dev@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 <hna...@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 <sorla...@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) <bmela...@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 <emag...@plumgrid.com> >>> Reply-To: OpenStack Development Mailing List >>> <openstack-dev@lists.openstack.org> >>> Date: onsdag 9 oktober 2013 21:38 >>> To: OpenStack List <openstack-dev@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 <sumitnaiksa...@gmail.com> >>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> >>> Date: Tuesday, October 8, 2013 8:30 PM >>> To: OpenStack List <openstack-dev@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@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
