<div dir="ltr"><div class="gmail_extra">Sorry for jumping into this thread late...there's lots of details to process, and I needed time to digest!</div><div class="gmail_extra"><br></div><div class="gmail_extra">Having said that, I'd like to recap before moving the discussion forward, at the Summit and beyond.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As it's being pointed out, there are a few efforts targeting this area; I think that is sensible to adopt the latest spec system we have been using to understand where we are, and I mean Gerrit and the spec submissions.</div><div class="gmail_extra"><br></div><div class="gmail_extra">To this aim I see the following specs:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><a href="https://review.openstack.org/93613" target="_blank">https://review.openstack.org/93613</a> - <span style="color:rgb(0,0,0)">Service API for L2 bridging tenants/provider networks</span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><a href="https://review.openstack.org/100278" target="_blank">https://review.openstack.org/100278</a> - <span style="color:rgb(0,0,0)">API Extension for l2-gateway</span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><font color="#000000"><a href="https://review.openstack.org/94612" target="_blank">https://review.openstack.org/94612</a> - </font><span style="color:rgb(0,0,0)">VLAN aware VMs</span><br></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><font color="#000000"><a href="https://review.openstack.org/97714" target="_blank">https://review.openstack.org/97714</a> - </font><span style="color:rgb(0,0,0)">VLAN trunking networks for NFV</span></font></div><div class="gmail_extra"><font face="arial, helvetica, sans-serif"><span style="color:rgb(0,0,0)"><br></span></font></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif">First of all: did I miss any? I am intentionally leaving out any vendor specific blueprint for now.</font></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif">When I look at these I clearly see that we jump all the way to implementations details. From an architectural point of view, this clearly does not make a lot of sense.<br></font></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_extra"><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">In order to ensure that everyone is on the same page, I would suggest to have a discussion where we focus on the following aspects:</span></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif">- Identify the use cases: what are, in simple terms, the possible interactions that an actor (i.e. the tenant or the admin) can have with the system (an OpenStack deployment), when these NFV-enabling capabilities are available? What are the observed outcomes once these interactions have taken place?</font></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif">-  Management API: what abstractions do we expose to the tenant or admin (do we augment the existing resources, or do we create new resources, or do we do both)? This should obviously driven by a set of use cases, and we need to identify the minimum set or logical artifacts that would let us meet the needs of the widest set of use cases.</font></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_extra"><font color="#000000" face="arial, helvetica, sans-serif">- </font><font color="#000000" face="arial, helvetica, sans-serif">Core Neutron changes: what needs to happen to the core of Neutron, if anything, so that we can implement this NFV-enabling constructs successfully? Are there any changes to the core L2 API? Are there any changes required to the core framework (scheduling, policy, notifications, data model etc)?<br></font></div><div class="gmail_extra"><br></div><div class="gmail_extra">- Add support to the existing plugin backends: the openvswitch reference implementation is an obvious candidate, but other plugins may want to leverage the newly defined capabilities too. Once the above mentioned points have been fleshed out, it should be fairly straightforward to have these efforts progress in autonomy.</div><div class="gmail_extra"><br></div><div class="gmail_extra">IMO, until we can get a full understanding of the aspects above, I don't believe like the core team is in the best position to determine the best approach forward; I think it's in everyone's interest in making sure that something cohesive comes out of this; the worst possible outcome is no progress at all, or even worse, some frankenstein system that no-one really know what it does, or how it can be used.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I will go over the specs one more time in order to identify some answers to my points above. I hope someone can help me through the process.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Many thanks,</div><div class="gmail_extra">Armando</div></div>