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

Ishimoto, Ryu ryu at midokura.com
Sun Feb 24 08:10:25 UTC 2013


On Tue, Feb 12, 2013 at 11:24 PM, Pino de Candia <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

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.



> 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?  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.  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/20130224/1822047d/attachment.html>


More information about the MidoNet-dev mailing list