Open Stack

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.lure at 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 <akilesh1597 at 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 <henry4hly at 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.lure at 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 <akilesh1597 at 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 <carl at 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 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20141107/93e8ab7f/attachment.html>