Hi Henry, Thanks for your suggestion. As you wrote, your approach can solve part problem. I believe there's a good reason(Maybe Carl's guess is right. It's a programmer's "good" habit to leave something for latecomers :).) for AT coupled with Router, but on the face of it, AT should be separated from Router, at least SNAT. IMHO it's better to provide a unified service including all kinds of AT, such as FIP, SNAT and DNAT.
BR, Germy On Fri, Nov 7, 2014 at 2:42 PM, Germy Lure <germy.l...@gmail.com> wrote: > Hi Akilesh, > Thanks for your response. I have some comments inline. > > BR, > Germy > > On Thu, Nov 6, 2014 at 10:56 PM, Akilesh K <akilesh1...@gmail.com> wrote: > >> Hi Geremy, >> >> It is necessary to not think of openstack as a way to replace all >> functionality of your enterprise data center, but rather to better utilize >> your resources. So I believe you should still continue to use your >> enterprise devices to do Address Translation outside of OpenStack. Why I >> say so is Address Translation is not necessarily a 'cloud' service. All you >> want in your cloud is servers, private and public networks, and firewall to >> secure them. >> > As you said, we really need private and public networks. And we also need > communication between them, from private to public and the opposite > direction. So how to do this without AT? I think this is just the reason > that the community introduces AT into Neutron so early, although, it is a > little simple IMO. > >> >> Anything more than that should be kept external and decoupled to >> OpenStack. But as I said before OpenStack is to an extent modular and I >> believe its getting better. As of now if you are using just >> 'neutron-l3-agent' it will do 'snat' to the ip address of your router >> attaching to 'external network' , but you can always add an extra service >> on top of 'neutron-l3-agent' to do address translation alone as per your >> needs. >> > Good idea. But I think as a cloud platform, a flexible and extendable > architecture is more important. Agent-style or Controller-style is just an > implementation for the architecture. People can always deal with such a > problem. My ugly extension and your "add an extra service" are both one of > those "solution". But they should not be the Neutron's solution. I don't > think Neutron's goal is keeping AT external. > >> >> On Thu, Nov 6, 2014 at 6:28 PM, Henry <henry4...@gmail.com> wrote: >> >>> So, do you mean that we need a better way to control snat ip address? I >>> think it make sense, but maybe simple attribute extension can solve part >>> problem, no need to separate it at this time. For example, add a snat-ip >>> field in the route, like fip. >>> >>> However if multiple snat ip is needed, and control which tenant ip is >>> served by each snat ip, separate plugin may be needed. >>> >>> >>> Sent from my iPad >>> >>> On 2014-11-6, at 下午6:21, Germy Lure <germy.l...@gmail.com> wrote: >>> >>> Hi Carl and Akilesh, >>> >>> Thank you for your response and explanation. >>> My manager tells me that enterprises usually use several IP addresses >>> and ports for AT while Neutron just use external gateway port fixed IP for >>> SNAT. I found that if I extended the SNAT attributes, the L3 plugin will be >>> very complex. So I must tolerate this to provider more useful SNAT feature >>> which is really what customer needs. >>> I think as a separated service, SNAT will be easier to do this or even >>> it can support those scenarios. >>> We known that VPNaaS and FwaaS dependent on L3 route service but not AT >>> which also dependents on L3. From this point, L2 is the core of network >>> service and L3 is the core of other advanced services. ML3 is coming. >>> Besides, It's strange that L3's API contains a field called >>> "snat_enable". Isn't it? >>> >>> BR, >>> Germy >>> >>> On Wed, Nov 5, 2014 at 5:37 PM, Akilesh K <akilesh1...@gmail.com> wrote: >>> >>>> @Germy Lure, >>>> I cannot give you a direct answer as I am not a developer. >>>> >>>> But let me point out that openstack can make use of many agents for l3 >>>> and above and not just neutron-l3-agent. You may even create your own >>>> agent. >>>> >>>> The 'neutron-l3-agent' works that way just to keep things simple. One >>>> point to consider is that Tenants may share same network space. So it >>>> becomes necessary to tie a router which belongs to a tenant to the tenant's >>>> security groups. If you try to distribute routing and firewall service you >>>> might end up making it too complicated. >>>> >>>> >>>> On Wed, Nov 5, 2014 at 2:40 PM, Carl Baldwin <c...@ecbaldwin.net> >>>> wrote: >>>> >>>>> I don't think I know the precise answer to your question. My best >>>>> guess is that floating ips were one of the initial core L3 features >>>>> implemented before other advanced services existed. Implementing them in >>>>> this way may have been the path of least resistance at the time. >>>>> >>>>> Are you suggesting a change? What change? What advantages would your >>>>> change bring? Do you see something fundamentally wrong with the current >>>>> approach? Does it have some deficiency that you can point out? >>>>> Basically, >>>>> we need a suggested modification with some good justification to spend >>>>> time >>>>> making that modification. >>>>> >>>>> Carl >>>>> Hi, >>>>> >>>>> Address Translation(FIP, snat and dnat) looks like an advanced >>>>> service. Why it is integrated into L3 router? Actually, this is not how >>>>> it's done in practice. They are usually provided by Firewall device but >>>>> not >>>>> router. >>>>> >>>>> What's the design concept? >>>>> >>>>> Thanks&Regards, >>>>> Germy >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
