[ovs-dev] [PATCH v4 0/4] Support native dhcp in ovn controller

[Russell Bryant]

On Mon, Mar 14, 2016 at 9:57 AM, Ben Pfaff <blp at ovn.org> wrote:

> On Wed, Mar 09, 2016 at 07:09:55PM +0530, Numan Siddique wrote:
> > On 12/22/2015 01:31 PM, Ben Pfaff wrote:
> > > Hi Babu and Numan.
> > >
> > > So far, we've been able to build OVN so that the logic of the system is
> > > implemented in terms of OVN logical flows.  That is, the logical flow
> > > table determines what happens in every significant way in OVN.  It
> would
> > > be nice to preserve this property for DHCP.  A design of this form
> would
> > > have to include a way for the flow table to extract DHCP header and
> > > option information from packets, and for the flow table to create new
> > > DHCP packets and set their header and option values.  It would be more
> > > work, but then the DHCP behavior could be controlled entirely from
> > > ovn-northd by modifying the flow table.
> > >
> > > I'd like to discuss whether this is practical and worth the effort.
> > >
> > > Do you have any initial thoughts?
> >
> > Hi Ben and everyone,
> >
> > We propose to support native dhcp in OVN in the following way
> >
> >  - For every logical switch port a new logical flow will be added if the
> >    Logical_Port.options has atleast "dhcp-opt-router=<ROUTER_IP>"
> defined.
> >
> >    For eg. If there is a logical port "por1" with Logical_Port.options
> defined as
> >    ["dhcp-opt-router=10.0.0.1", "dhcp-opt-netmask=255.255.254.0"] and it
> has ip address
> >    "10.0.0.3", then the flow would look like
> >
> >    table=1( ls_in_dhcp), priority= 50, match=(inport == "port1" &&
> eth.src == <ETH_ADDR> && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255
> && udp.src == 68 && udp.dst == 67), action=(dhcp_offer { offerip =
> 10.0.0.3; router = 10.0.0.1; netmask = 255.255.254.0; }; eth.dst = eth.src;
> ip4.dst = 10.0.0.3; udp.src = 67; udp.dst = 68; outport = inport; inport =
> ""; / Allow sending out inport. / output;)
>
>
This is a fairly minor thing, but I'm wondering if the syntax of dhcp_offer
{ ... }; should be dhcp_offer(...); instead.

Logical flows currently support:

    next(<table>);
    arp { action; ... };
    icmp4 { action; ... };

In the arp and icmp4 cases, we're executing a set of logical flow actions
on a temporary replacement packet.  For "next", it's a parameter to "next",
not something that could also be executed outside of the context of "next".

Setting the offerip, router, and netmask seem more like parameters to a
dhcp_offer action since they aren't actions that also make sense outside of
"dhcp_offer".

Thoughts?

-- 
Russell Bryant