On Mon, Dec 1, 2014 at 4:46 PM, Ian Wells <ijw.ubu...@cack.org.uk> wrote: > On 1 December 2014 at 04:43, Mathieu Rohon <mathieu.ro...@gmail.com> wrote: >> >> This is not entirely true, as soon as a reference implementation, >> based on existing Neutron components (L2agent/L3agent...) can exist. > > > The specific thing I was saying is that that's harder with an edge-id > mechanism than one incorporated into Neutron, because the point of the > edge-id proposal is to make tunnelling explicitly *not* a responsibility of > Neutron. So how do you get the agents to terminate tunnels when Neutron > doesn't know anything about tunnels and the agents are a part of Neutron?
by having modular agents that can drive the dataplane with pluggable components that would be part of any advanced service. This is a way to move forward on splitting out advanced services. > Conversely, you can add a mechanism to the OVS subsystem so that you can tap > an L2 bridge into a network, which would probably be more straightforward. This is an alternative that would say : you want an advanced service for your VM, please stretch your l2 network to this external component, that is driven by an external controller, and make your traffic goes to this component to take benefit of this advanced service. This is a valid alternative of course, but distributing the service directly to each compute node is much more valuable, ASA it is doable. >> But even if it were true, this could at least give a standardized API >> to Operators that want to connect their Neutron networks to external >> VPNs, without coupling their cloud solution with whatever SDN >> controller. And to me, this is the main issue that we want to solve by >> proposing some neutron specs. > > > So the issue I worry about here is that if we start down the path of adding > the MPLS datamodels to Neutron we have to add Kevin's switch control work. > And the L2VPN descriptions for GRE, L2TPv3, VxLAN, and EVPN. And whatever > else comes along. And we get back to 'that's a lot of big changes that > aren't interesting to 90% of Neutron users' - difficult to get in and a lot > of overhead to maintain for the majority of Neutron developers who don't > want or need it. This shouldn't be a lot of big changes, once interfaces between advanced services and neutron core services will be cleaner. The description of the interconnection has to to be done somewhere, and neutron and its advanced services are a good candidate for that. > -- > Ian. > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev