Hi Dan,
Thanks for your response.
> ** vif port parameter handling (or portprofile)
> VIF Driver should be available to handle plugin-specific port parameters and/or helper functions.
> This is required in just some plugins now, but necessary to be designed in Quantum Community.
> In my experience of implementing NEC OpenFlow Plugin, I think it is tough to create Nova drivers and Quantum
>extension APIs.
> To help those who wants to write a new Quantum plugin without "agent", we should design a common (or just
>sample) Nova driver and
> Quantum extension APIs for passing or retrieving plugin-specific information.
>
>
>
>I believe the Cisco driver actually does something like this already, you might want to look at it as an example.
>
>However, I think the goal should be that code that is in Nova is not specific to the plugin. As we talked about
>earlier in the thread, you may need different types of vif-plugging to attach to different types of switching
>technologies (e.g., OVS vs. bridge vs. VEPA/VNTAG), but I think that different plugins that use the same switching
>technology should be able to use the same vif-plugging (for example, there are several plugins that all use the OVS
>vif-plugging). Our goal here should be to minimize churn in the Nova codebase.
Yes, I checked the Cisco driver and the portprofile extension.
The Cisco driver seems to pass and retrieve the plugin-specific data with PUT method.
I just thought that this kind of vif-plugging could be a general model for plugins that work without "agent".
I agree with you that we should minimize churn in the Nova codebase.
But, I still feel that the "agent" model, especially polling, is not so good.
Although there are many topics on the summit,
I hope that we could have discussion about vif-plugging changes.
> I think there is another sub topic, but I am not sure yet.
> I agree that a configurable VIF driver is much better.
> For designing the configuration of vif-plugging, it is required that we discuss the granularity of selecting
>VIF Driver.
> Should The granularity of selecting VIF Driver be per node, VM, or VIF?
> Currently, VIF Driver would be configured in nova-compute.conf.
> This means that the granularity is per Hypervisor Node.
> To be more flexible, we might consider the case where VIF1 of VM1 connects to bridge and VIF2 of VM1 maps
>to a physical NIC
> directly.
> If so, it may raise another issue; how to determine connection type of VIF.
>
>
>
>That's an interesting use case, and something that we haven't tried to deal with yet. In your use case, who would
>determine how a VIF was mapped? Would it be a policy described by the service provider? Would it be part of the
>VM flavor? Adding this kind of flexibility is certainly possible, though you are the first person who has expressed
>a need for this type of flexibility.
It could be mixed.
I think that a cloud user specifies vNIC option like "physical NIC mapping" as a VM flavor,
then a service provider determines a hypervisor node and it's available physical NIC.
It is not suitable that the cloud user specifies physical NIC itself.
But this though is not clear enough to having a session on the summit,
I hope that we discuss this issue on vif-plugging session or somewhere in the summit.
> Is there any blueprint of Security Group in NetStack?
> I have a primitive proposal for an firewall model and API, and a firewall implementation on Quantum OpenFlow
>Plugin.
> That is just a prototype based on Quantum L2 API.
> But, this proposal shows how firewalling API should be.
> I think the first point in designing firewalling models is to which entity each rule is associated.
> Is the entity network or port?
> I hope that we will have discussions for firewalling leads much more functionalities and APIs than security
>group has currently.
>
>
>
>Dave Lapsley (on netstack list) is doing a session on this at the summit. Feel free to join as a driver. My thinking
>on the topic is that each Quantum port could be assigned one or more security groups. There is also scope, I believe,
>for more advanced ACLs that could be associated with each port, essentially consisting of inbound/outbound lists
>of rules that each have a "match" and an "action" (allow/deny). There is also the topic of NAT, which in my mind
>makes the most sense to think about in terms of our "L3 forwarding" discussion (see etherpad).
>
I found it.
I'll join the sessions.
Thanks!
> Finally, I would like to suggest that the Security Group session would be suitable to be held after Quantum
>L3 session.
> I think the Security Group is a cross layer function and its design should better be coupled with L3 design.
>
>
>
>I think our first task needs to be properly scoping each of these discussions, particularly on the many topics loosely
>call "L3". I've sent another email to the list with thoughts on breaking up those discussions.
>
Thanks,
Ryota MIBU
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
Thanks for your response.
> ** vif port parameter handling (or portprofile)
> VIF Driver should be available to handle plugin-specific port parameters and/or helper functions.
> This is required in just some plugins now, but necessary to be designed in Quantum Community.
> In my experience of implementing NEC OpenFlow Plugin, I think it is tough to create Nova drivers and Quantum
>extension APIs.
> To help those who wants to write a new Quantum plugin without "agent", we should design a common (or just
>sample) Nova driver and
> Quantum extension APIs for passing or retrieving plugin-specific information.
>
>
>
>I believe the Cisco driver actually does something like this already, you might want to look at it as an example.
>
>However, I think the goal should be that code that is in Nova is not specific to the plugin. As we talked about
>earlier in the thread, you may need different types of vif-plugging to attach to different types of switching
>technologies (e.g., OVS vs. bridge vs. VEPA/VNTAG), but I think that different plugins that use the same switching
>technology should be able to use the same vif-plugging (for example, there are several plugins that all use the OVS
>vif-plugging). Our goal here should be to minimize churn in the Nova codebase.
Yes, I checked the Cisco driver and the portprofile extension.
The Cisco driver seems to pass and retrieve the plugin-specific data with PUT method.
I just thought that this kind of vif-plugging could be a general model for plugins that work without "agent".
I agree with you that we should minimize churn in the Nova codebase.
But, I still feel that the "agent" model, especially polling, is not so good.
Although there are many topics on the summit,
I hope that we could have discussion about vif-plugging changes.
> I think there is another sub topic, but I am not sure yet.
> I agree that a configurable VIF driver is much better.
> For designing the configuration of vif-plugging, it is required that we discuss the granularity of selecting
>VIF Driver.
> Should The granularity of selecting VIF Driver be per node, VM, or VIF?
> Currently, VIF Driver would be configured in nova-compute.conf.
> This means that the granularity is per Hypervisor Node.
> To be more flexible, we might consider the case where VIF1 of VM1 connects to bridge and VIF2 of VM1 maps
>to a physical NIC
> directly.
> If so, it may raise another issue; how to determine connection type of VIF.
>
>
>
>That's an interesting use case, and something that we haven't tried to deal with yet. In your use case, who would
>determine how a VIF was mapped? Would it be a policy described by the service provider? Would it be part of the
>VM flavor? Adding this kind of flexibility is certainly possible, though you are the first person who has expressed
>a need for this type of flexibility.
It could be mixed.
I think that a cloud user specifies vNIC option like "physical NIC mapping" as a VM flavor,
then a service provider determines a hypervisor node and it's available physical NIC.
It is not suitable that the cloud user specifies physical NIC itself.
But this though is not clear enough to having a session on the summit,
I hope that we discuss this issue on vif-plugging session or somewhere in the summit.
> Is there any blueprint of Security Group in NetStack?
> I have a primitive proposal for an firewall model and API, and a firewall implementation on Quantum OpenFlow
>Plugin.
> That is just a prototype based on Quantum L2 API.
> But, this proposal shows how firewalling API should be.
> I think the first point in designing firewalling models is to which entity each rule is associated.
> Is the entity network or port?
> I hope that we will have discussions for firewalling leads much more functionalities and APIs than security
>group has currently.
>
>
>
>Dave Lapsley (on netstack list) is doing a session on this at the summit. Feel free to join as a driver. My thinking
>on the topic is that each Quantum port could be assigned one or more security groups. There is also scope, I believe,
>for more advanced ACLs that could be associated with each port, essentially consisting of inbound/outbound lists
>of rules that each have a "match" and an "action" (allow/deny). There is also the topic of NAT, which in my mind
>makes the most sense to think about in terms of our "L3 forwarding" discussion (see etherpad).
>
I found it.
I'll join the sessions.
Thanks!
> Finally, I would like to suggest that the Security Group session would be suitable to be held after Quantum
>L3 session.
> I think the Security Group is a cross layer function and its design should better be coupled with L3 design.
>
>
>
>I think our first task needs to be properly scoping each of these discussions, particularly on the many topics loosely
>call "L3". I've sent another email to the list with thoughts on breaking up those discussions.
>
Thanks,
Ryota MIBU
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp