On Mon, Mar 14, 2016 at 9:57 AM, Ben Pfaff <b...@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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
