Hi Madhu, I completely agree with your opinion. Regards, Hideyuki Tai

So I see the value of this... But what about Affinity? Ed On Dec 2, 2013, at 7:57 PM, "Hideyuki Tai" <h-tai@...> wrote:

As explained in today's call, I started this discussion with neutron in mind. I have to understand the problem with affinity before I can expand this discussion beyond neutron. I think Suchi is

Hi Ed, Madhu’s proposal focus on the co-existing problem between southbound drivers for Neutron Interface. I explained about this problem in the following

Hey all, I'm documenting the steps I'm doing to get ML2/ODL working (mostly for myself), but maybe some bits will be useful to someone, so I thought I share it. I know there are better tutorials out

As we've discussed at some length, Affinity is not in the same category of function as the virtualization implementations, and also doesn't implement the Neutron APIs, so I don't think the issue of

Madhu, I don't think this is the right way to handle this -- IMO Neutron shouldn't need to be aware of details of the virtualization implementation. In keeping with the notion of Neutron being

Anees, I would say OpenStack already is somewhat aware of the details of the virtualization implementation, since you get to choose between VLAN, GRE, and VXLAN tunneling. So I agree with Madhu that

In addition to the basic metadata setting/getting, the affinity engine has a way to set forwarding rules for traffic redirection. This is the feature required for Radware. We have a couple of options

Hi Suchi, Good questions. I will not pretend to be an expert in this area as I have had little time to dig into these projects unfortunately. My reaction/response is therefore one of practicality.

Ok, I'll schedule a meeting to decide resolution for next release.

So from what I understand from this and other previous conversations, it looks like there are 2 trends for the Virtualization edition: 1) Run all apps together but try to use only one

Lori, my understanding of the the multi-segment support in ML2 is different -- I would say its intent is to allow OpenStack to work over multiple network types at the same time, not to force the

Anees, I don’t much like the notion of turning one and only one participant off by default in an Edition. Its possible we have to fall back to starting all off and having the user decide which to

Yep, I know :) And as I said, I like your solution as far as it goes :) Ed On Dec 2, 2013, at 9:47 PM, Madhu Venugopal <mvenugop@...> wrote:

On Dec 2, 2013, at 9:55 PM, Hideyuki Tai <h-tai@...> wrote: Agreed… I was just calling attention to the fact that while I think Madhu has made an elegant proposal for the Neutron side of this

IMHO VTN,Dove,Affinity are the virtualization solution on top of ODL platform and openstack should be agnostic of these virtualization solution. ODL should be a southbound for openstack rather then

Anees, Lori, Yes. I had the same conflicting thought within me when I proposed this & hence kept both the options open. We can infact keep this an ODL specific configuration if it is understood that

Anil, Seems like we are converging on keeping this a ODL side configuration & am perfectly fine with that. I kind of sensed this from Kyle on the IRC as well (though he hasnt

Hi Suchi, Its my fault that I had not participated in the previous discussions on Affinity + VTN in the virtualization edition & would like to understand it better. It would