Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?
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? ThanksRegards, 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
Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?
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? ThanksRegards, 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
Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?
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. 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. 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? ThanksRegards, 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
Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?
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? ThanksRegards, Germy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list
Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?
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,
Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?
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? ThanksRegards, 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
Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?
@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? ThanksRegards, 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] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?
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? ThanksRegards, Germy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
