16:04:26 #startmeeting networking_ml2 16:04:26 Meeting started Wed Sep 16 16:04:26 2015 UTC and is due to finish in 60 minutes. The chair is rkukura. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:04:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:04:30 The meeting name has been set to 'networking_ml2' 16:04:33 #topic Agenda 16:04:39 #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_Sept_16.2C_2015 16:04:59 Any questions or additions/deletions regarding the agenda? 16:05:37 #topic Announcements 16:06:07 Liberty RC1 is out I believe 16:06:16 #link https://wiki.openstack.org/wiki/Meetings/ML2#Meeting_Sept_16.2C_2015 16:06:55 I will be missing next weeks ML2 meeting, but Sukhdev will chair 16:07:01 Any other announcements? 16:07:31 #topic ML2 pre-cycle meetup 16:08:14 #link https://etherpad.openstack.org/p/Neutron_ML2_Mid-Cycle_Sprint 16:08:50 No changes I’m aware of on this. I’ve booked my travel and plan to be there. I think most others are local. 16:09:12 I certainly encourage anyone who wants to participate to attend. 16:09:35 Any questions/comments on the meetup? 16:09:48 I think yamamoto is local as well - 16:10:06 so, yes, all seem to be local 16:10:44 #topic Mitaka Design Summit 16:11:03 #link https://etherpad.openstack.org/p/neutron-mitaka-designsummit 16:11:47 I see ML2 state sync and SG driver topics on the list 16:12:04 And some others are likely to impact ML2 as well 16:12:41 Is anyone familiar with “ml2 port cross backends extension”? 16:13:28 not me 16:13:39 I'm not. 16:14:22 There is a link to https://bugs.launchpad.net/neutron/+bug/1487978, but this doesn’t seem related to the topic. 16:14:24 Launchpad bug 1487978 in neutron "Performance of L2 population" [Undecided,New] 16:15:13 modular L2 agent is also on the list 16:16:17 Any other questions or comments regarding the upcoming design summit? 16:16:59 moving along then... 16:17:19 #topic Driver API for SGs 16:18:06 I don’t see yamamoto. 16:18:18 Anyone aware of any progress on this? 16:18:51 I am not aware of the progress, but, I have a point to make in this regard and see how others feel 16:19:18 Sukhdev: Go ahead 16:19:52 ACLs in general are a critical feature which spans for Virtual as well Physical environments 16:20:22 more and more people are asking for a comprehensive solution to address them 16:20:53 we do not have a good or clean solution to deal with the physical devices 16:21:24 So, where yamamoto was heading with his discussion was in the right direction 16:21:34 I think we should push for this - 16:22:03 I wonder if mestery is going to make the call or the new PTL as to which topics will be picked up 16:22:57 but, in general, I think, in neutron, we need a framework that will help physical devices as well virtual 16:23:04 any thoughts on this? 16:23:54 Sukhdev: Are you thinking about ironic/baremetal deployments? 16:24:40 Or about using physical devices to enforce the ACLs in the virtual environment? 16:24:59 rkukura: the later 16:25:27 that will take care of the baremetal deployments as well. 16:26:07 My thinking is that ML2 needs to make sure some (one or more) MD is taking responsibility for enforicing the SGs for each port binding. 16:26:15 for instance some ACLs make sense only on the TORs or Spines, where as others make sense on the VMs 16:26:38 So this could be the MD for an agent on the host that uses iptables, or for a ToR switch or fabric or whatever. 16:27:56 If the SG API is exposed through ML2, then drivers can act on it - regardless of if they dealing the virtual or physical 16:27:59 Sukhdev: Do you see the model/API for these ACLs being something different than the current SG API? 16:29:25 not really - the API itself seems OK - we need to build a framework so that drivers can be invoked in a reliable manner to process them 16:31:16 I agree we need a way for MDs that need to see the SG API calls to be called, but we also need to make sure at least one of the MDs in each portbinding takes responsibility for enforcing the SGs, whether it process the SG API calls to do this, or uses the existing RPC approach. 16:31:50 +1 16:32:02 I think we need a somewhat concrete proposal to bring to the design summit. 16:32:51 If we can get a spot for this, then we can work through the details during the sprint 16:33:01 +1 for the generic proposal, so far 16:33:14 I don’t see yamamoto on the list of sprint attendees. 16:33:39 Sukhdev: Did you say he is local to the area? 16:33:53 I suppose yamahata is local. yamamot is not. 16:34:38 yamahata: Thanks 16:35:38 OK, lets try to make some progress on this SG proposal at the sprint, and include yamamoto and anyone else interested remotely if possible. 16:36:01 my bad - sorry for causing the confusion - yes, yamahata needs to attend sprint not yamamoto - one of these days I will get it right 16:36:22 Anything else on the SG driver API topic? 16:36:41 #topic Modular L2 agent & macvtap 16:36:46 yamahata is interested in sync solution and yamamoto is interested in SG API improvements 16:37:01 I don’t see scheuran 16:37:18 banix: Are you involved in modular L2 agent at this point? 16:37:37 rkukura: I am fraid not 16:37:46 banix: OK, thanks 16:38:57 Similarly, I’d hope we could get a semi-concrete proposal for ML2A to discuss at the summit. Lets see if scheuran is here next week. 16:39:06 Anything else on this topic today? 16:39:35 If not, on to the last speciific topic on the agenda… 16:39:56 #topic Physical Topology 16:40:45 As usual, asomya and shivharis couldn’t make this meeting 16:40:55 Does anyone have any update or comments on this one? 16:41:33 If not… 16:41:40 #topic Open Discussion 16:41:53 Anything else to discuss today, or can we wrap up? 16:42:48 I think we are done for today 16:42:53 Thanks everyone! 16:42:58 #endmeeting