[MidoNet-dev] MidoNet: L2 gateway (connecting physical L2 into the virtual topology)

Pino de Candia gdecandia at midokura.com
Thu Feb 28 23:45:33 UTC 2013


On Sunday, February 24, 2013 at 9:10 AM, Ishimoto, Ryu wrote:
> 
> On Tue, Feb 12, 2013 at 11:24 PM, Pino de Candia <gdecandia at midokura.com (mailto:gdecandia at midokura.com)> wrote:
> > One? I think I'm employee number 4 or 5 - not counting the founders.
> > 
> 
> I Am Number Four :-) 
> 
> > Ryu, Tomoe, when you guys have some free time (after the Grizzly commit deadline) could you give an opinion about whether the bonding and vlan adapters might be good extensions to the Quantum? 
> > 
> 
> I believe the blueprint that comes closest to what we are discussing here is this: https://blueprints.launchpad.net/quantum/+spec/provider-networks

Nice read. Finally, a blueprint that's more than a blurb. 
> 
> This is to allow extending the Quantum L2 virtual network to the existing physical provider network.  I need to look into it a bit more to really understand how it's implemented.
Cool - let's both do that and then discuss whether it's compatible with what we want to do (or how hard we should try to make it so). 
> 
>  
> > Also, here are the MidoNet API changes I'm proposing to implement this model. For Bonding Adapters:
> > PortBonds will be a top level URI (obtained from ApplicationDto.getPortBonds - probably at path /port_bonds).
> > You create a new PortBond by doing a POST of a PortBondDto to ApplicationDto.getPortBonds. PortBondDto just has a name and an owner. Later we may add fields like 'forwardingMode' (for choosing between round-robin, xor and others) and 'enableLACP' for changing from static to dynamic link aggregation.
> > PortBondDto.upPort is the URI of the PortBond's interior uplink port. This port is created automatically (unlinked) when the PortBond is created. Although the URI is similar to other virtual port URIs (e.g. in /ports), attempting to DELETE it will result in an HTTP error.
> > If you do a GET on PortBondDto.upPort, the result is an InteriorPortDto - which should now be made an explicit and instantiate-able part of the port hierarchy.
> > PortBondDto.downPorts is the URI for the bond's down-ports. GET on this URI will return a list of ExteriorPortDto objects - which should now be made an explicit and instantiate-able part of the port hierarchy. POST on the 'downPorts' URI will create a new ExteriorPortDto. ExteriorPorts may be bound to host-interfaces.
> > 
> > 
> > For VLAN Adapters:
> > VlanDemuxes will be a top level URI (obtained from ApplicationDto.getVlanDemuxes - probably at path /vlan_demuxes).
> > You create a new VlanDemux by doing a POST of a VlanDemuxDto to ApplicationDto.getVlanDemuxes.VlanDemuxDto just has a name and an owner.
> > VlanDemuxDto.downPort (or call it muxPort?) is the URI of the single Interior OR Exterior virtual port that carries mixed VLAN traffic into/from the adapter. You can POST an ExteriorPortDto or an InteriorPortDto to this URI. However, if you want to change the downPort (e.g. to change from interior to exterior), you must first call DELETE on the current VlanDemuxDto.downPort, and then POST a new one.
> > VlanDemuxDto.upPorts (or should we call it demuxPorts?) is the URI for the vlan adapter's up-ports which carry traffic without VLAN tags. GET on this URI will return a list of VlanPortDto objects. POSTing a VlanPortDto to this URI adds an up-port to the adapter. VlanPortDto is a subclass of InteriorPortDto with a new vlan-tag field that specifies the VLAN tag that is stripped/added to packets that egress/ingress this port. If 'vlan-tag' is set to NULL, the POST will fail (with an appropriate HTTP error) if this adapter already has a VlanPortDto with a null vlan-tag.
> > A VlanPortDto may not be linked to the VlanDemuxDto.downPort of any vlan adapter.
> > 
> > As always, feedback is appreciated. Please let me know if I missed anything.
> > 
> > 
> 
> I really like the adapter approach.  If I understand the proposal correctly, it seems like there are two types of adapters:
> 
> 1. One virtual network interface -> multiple physical network interfaces  (bonding) 
> 2. Multiple virtual network interfaces -> one physical network or another adapter interface (VLAN)
> 
> For the VLAN adapter, we may have other mechanisms in the future in which we would want to extend the virtual network, like VXLAN or NVGRE.  So should we have more generic concepts for these adapters, like 'network extender' adapter that allows you to specify drivers to implement various isolation mechanisms like VLAN and VXLAN?
So, would you want the network extender to have different drivers (VLAN, VXLAN) and you choose the driver by setting a 'driver type' in the extender? I'm worried that the extender/adapter's port configurations will be very specific to the L2 tunneling technology. So I would prefer to have a VLAN adapter and a separate VXLAN adapter for now. Later on if we add a third type of network extender we can try to pull them all into a unified model. 
>  Bonding adapter can remain as is but we can also allow 'drivers' to be injected for the bonding behavior (XOR, round-robin, etc).  In the API, the user would create an adapter, specifying its type, and its driver.  This lets you switch the drivers instead of swapping the entire adapter.
> 
> 
> 
> 
> 

- adapter type? Do you mean you want to have the VLAN adapter and Bonding adapter be interchangeable? Meaning that you can just change the type and instead of a VLAN adapter you suddenly have a Bonding adapter?
- Is 'driver' different from the 'forwardingMode' field that I proposed on the bonding adapter?

thanks for the feedback/ideas!

Pino
>  That's about all I can comment on this at the moment.  
> 
> Thanks,
> Ryu 
> 
> 
> 
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130301/6ccd1b71/attachment.html>


More information about the MidoNet-dev mailing list