Open Stack

We are trying to frame a model for the logical Quantum resources that will
be required to provide a Firewall service interface. In general, the
Quantum logical resource model is always independent of any particular
backend implementation, and it does not prescribe support via physical
devices or virtual appliances; that is left to the backend implementation.
Same assumptions are true in this case as well.

This is a DC use case.

Thanks,
~Sumit.

On Sat, Apr 6, 2013 at 10:16 AM, balaji patnala <patnala003 at gmail.com>wrote:

> Hi Sumit,
>
> Do you mean that the vendor plugin-agent must be capable of mapping this
> quantum firewall instance and support both physical firewall and virtual
> firewall deployments.?
>
> I know that tenant will not have any visibility on physical/virtual
> firewall. I think we need to have more robust architecture for firewall so
> that it can be adapted to the DC networks.
>
> Regards,
> Balaji.P
>
> On Fri, Apr 5, 2013 at 11:15 AM, Sumit Naiksatam <sumitnaiksatam at gmail.com
> > wrote:
>
>> Inline...
>>
>>  On Thu, Apr 4, 2013 at 10:37 PM, balaji patnala <patnala003 at gmail.com>wrote:
>>
>>> Hi Sumit,
>>>
>>> "* The firewall resource as expressed in the model is a logical instance
>>> in the Quantum model. It's mapping to a physical/virtual appliance is left
>>> to the backend."
>>>
>>> Is it like we are trying to create a "firewall instance" in Quantum for
>>> a Tenant and then we want to map this Quantum Instance to "Physical" or
>>> "Virtual" Firewall Appliance.?
>>>
>>
>> Sumit: Yes, the backend/plugin implementation would do this but may not
>> be necessarily visible to the tenant.
>>
>>>
>>> Can you through some light on this?
>>>
>>> Regards,
>>> Balaji.P
>>>
>>> On Fri, Apr 5, 2013 at 6:03 AM, Sumit Naiksatam <
>>> sumitnaiksatam at gmail.com> wrote:
>>>
>>>> Just wanted to give an update on the call today - we had a fairly large
>>>> number of people attending from PayPal, VMware, Cisco, Big Switch (to name
>>>> a few that I noted).
>>>>
>>>> Discussion notes:
>>>>
>>>> * Decided to focus in the firewall_rule attributes - current definition
>>>> of attributes is not clear. Although the intent is to capture these as
>>>> flexible placeholder objects, the document is not very indicative. Needs to
>>>> be articulated better (e.g. source_ip_address should just be a "source"
>>>> string).
>>>>
>>>> * Need a little more deliberation on which attributes in the
>>>> firewall_rules need to form the core set of attributes; other lesser
>>>> used/vendor-centric attributes can be modeled as "extended attributes".
>>>>
>>>> * The zone attribute/resource definition needs to be expanded.
>>>>
>>>> * It might be more practical to model a firewall_rule to
>>>> firewall_policy relationship as 1:1. If we take that approach, it might be
>>>> helpful to have a sequence number attribute in the firewall_rule.
>>>>
>>>> * It might be helpful to model firewall instance to firewall_policy
>>>> relationship as 1:many
>>>>
>>>> * The firewall resource as expressed in the model is a logical instance
>>>> in the Quantum model. It's mapping to a physical/virtual appliance is left
>>>> to the backend.
>>>>
>>>> * Details on use cases are required. Will help to validate against the
>>>> model.
>>>>
>>>> In general, we seem to have a decent start to the base model. No major
>>>> objections on the workflow.
>>>>
>>>> We will continue to have discussions over emails, and have another call
>>>> next week.
>>>>
>>>> Please feel free to add anything I might have missed.
>>>>
>>>> Thanks,
>>>>
>>>> ~Sumit.
>>>>
>>>>  On Wed, Apr 3, 2013 at 10:47 AM, Sumit Naiksatam <
>>>> sumitnaiksatam at gmail.com> wrote:
>>>>
>>>>> We have set up a conference call scheduled for Thursday April 4th to
>>>>> discuss this topic as a preparation for the upcoming summit.
>>>>>
>>>>> Agenda:
>>>>> Current draft: https://wiki.openstack.org/wiki/Quantum/FWaaS/API
>>>>>
>>>>> Logistics (thanks to Vinay/Anand, PayPal):
>>>>>
>>>>> Where: Conference Bridge - (855) 227 1767 x 7152259
>>>>>
>>>>> When: Thursday, April 04, 2013 2:00 PM-3:00 PM. (UTC-08:00) Pacific Time (US & Canada)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Where: Conference Bridge - (855) 227 1767 x 7152259
>>>>>
>>>>> Conf. Code 7152259
>>>>> Phones Numbers:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    - (855) 227-1767(USA) - 08003765931(UK)
>>>>>    - 0008006103229 (India – Toll Free)
>>>>>    -
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>    81080024322044 (Moscow), 4992701688(Moscow)
>>>>>
>>>>> Web Conf: https://myroom-na.adobeconnect.com/anandpalanisamy/
>>>>>
>>>>>
>>>>>
>>>>> More Numbers: https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=7152259&name=&email=&selectedProduct=joinMeeting
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130406/d4892250/attachment.html>