To address a point or two that Armando has raised here that weren't covered
in my other mail:

On 28 October 2014 11:00, Armando M. <> wrote:

> - 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)?

In the L2 API, I think this involves
- adding capability flag for trunking on networks and propagating that into
ML2's drivers (for what it's worth, this needs solving anyway; MTUs need
propagation as well)
- adding the trunk ports API and somehow implementing that in ML2

The L2GW block is in fact a new service and a reference implemenation can
be made with a namepsace, independently of the L2 plugin.

- Add support to the existing plugin backends: the openvswitch reference
> implementation is an obvious candidate,

Actually, it isn't.  The LB reference implementation is the obvious
candidate.  Because of the way it's implemented, it's easiest if the OVS
implementation refuses to make trunk networks (and therefore couldn't use
an L2GW block), but that's fine: we need one reference implementation and
it doesn't have to be OVS.

OVS may still be suitable to show off a trunk port reference
implementation; trunk ports would need addressing in the L2 plugin (in that
they're VM-to-network connectivity, which falls under its responsibility).
OpenStack-dev mailing list

Reply via email to