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

2016-03-31 Thread Russell Bryant 
On Thu, Mar 31, 2016 at 11:48 AM, Ben Pfaff  wrote:

> On Thu, Mar 31, 2016 at 09:07:38PM +0530, Numan Siddique wrote:
> > > I'm not sure if a src of 0.0.0.0 is a good idea.  Wouldn't that
> typically
> > > be the IP address of the DHCP server?  I'd be worried about some
> clients
> > > treating it as invalid.
> > >
> > > I think it should be specified by logical flows.  Something like:
> > >
> > > dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0,
> > > mtu=1300, dns={8.8.8.8, 7.7.7.7}); eth.dst = eth.src; eth.src =
> > > ; ip.src = ; outport = inport; inport = "";
> output;
> > >
> > > As for what addresses to use ... I don't know.  I think it should be
> > > specified via OVN_Northbound, somehow.  It's easy enough for Neutron to
> > > generate an IP and MAC to use.  It already creates DHCP ports for this
> > > purpose.  Maybe it could just be additional logical port options, like
> > > you're doing for the rest of the DHCP parameters?
> > >
> > >
> > ​Thanks Russel for the comments.
> > Since most of the dhcp options are common to all the ports of ​a virtual
> > network, I was thinking may be it's good to add a new column -
> > 'dhcp_options' in Logical_Switch table. This can be used to store all the
> > dhcp options including the server ip and mac.
> >
> > ​We can still use Logical_Port.options to store extra dhcp options
> specific
> > to a port.​
>
> That seems reasonable to me.
>

Same here.  Thanks!

-- 
Russell Bryant
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-31 Thread Ben Pfaff 
On Thu, Mar 31, 2016 at 09:07:38PM +0530, Numan Siddique wrote:
> > I'm not sure if a src of 0.0.0.0 is a good idea.  Wouldn't that typically
> > be the IP address of the DHCP server?  I'd be worried about some clients
> > treating it as invalid.
> >
> > I think it should be specified by logical flows.  Something like:
> >
> > dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0,
> > mtu=1300, dns={8.8.8.8, 7.7.7.7}); eth.dst = eth.src; eth.src =
> > ; ip.src = ; outport = inport; inport = ""; output;
> >
> > As for what addresses to use ... I don't know.  I think it should be
> > specified via OVN_Northbound, somehow.  It's easy enough for Neutron to
> > generate an IP and MAC to use.  It already creates DHCP ports for this
> > purpose.  Maybe it could just be additional logical port options, like
> > you're doing for the rest of the DHCP parameters?
> >
> >
> ​Thanks Russel for the comments.
> Since most of the dhcp options are common to all the ports of ​a virtual
> network, I was thinking may be it's good to add a new column -
> 'dhcp_options' in Logical_Switch table. This can be used to store all the
> dhcp options including the server ip and mac.
> 
> ​We can still use Logical_Port.options to store extra dhcp options specific
> to a port.​

That seems reasonable to me.
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-31 Thread Numan Siddique 
> I'm not sure if a src of 0.0.0.0 is a good idea.  Wouldn't that typically
> be the IP address of the DHCP server?  I'd be worried about some clients
> treating it as invalid.
>
> I think it should be specified by logical flows.  Something like:
>
> dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0,
> mtu=1300, dns={8.8.8.8, 7.7.7.7}); eth.dst = eth.src; eth.src =
> ; ip.src = ; outport = inport; inport = ""; output;
>
> As for what addresses to use ... I don't know.  I think it should be
> specified via OVN_Northbound, somehow.  It's easy enough for Neutron to
> generate an IP and MAC to use.  It already creates DHCP ports for this
> purpose.  Maybe it could just be additional logical port options, like
> you're doing for the rest of the DHCP parameters?
>
>
​Thanks Russel for the comments.
Since most of the dhcp options are common to all the ports of ​a virtual
network, I was thinking may be it's good to add a new column -
'dhcp_options' in Logical_Switch table. This can be used to store all the
dhcp options including the server ip and mac.

​We can still use Logical_Port.options to store extra dhcp options specific
to a port.​

I wanted to know if this is fine.

Thanks
Numan
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-28 Thread Russell Bryant 
On Mon, Mar 28, 2016 at 10:16 AM, Numan Siddique 
wrote:

>
>
> On Mon, Mar 28, 2016 at 6:58 PM, Russell Bryant  wrote:
>
>>
>>
>> On Thu, Mar 17, 2016 at 2:34 AM, Numan Siddique 
>> wrote:
>>
>>> On 03/16/2016 10:44 PM, Russell Bryant wrote:
>>> > It could also be this:
>>> >
>>> > dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0, mtu=1300,
>>> > dns={8.8.8.8, 7.7.7.7});
>>>
>>> Thanks. This seems better to me.
>>>
>>
>> Where do you get the source MAC and IP for the DHCP responses?
>>
>>
> ​For the initial testing I had harcoded source MAC to some value and left
> the source ip unchanged i.e it 0.0.0.0
>
>
> https://github.com/numansiddique/ovs/blob/dhcp_pause_rfc_working/ovn/northd/ovn-northd.c#L1132
>
> I think it should be ok if the ovn-controller sets the source ip to
> 0.0.0.0, but not sure what should be set for source mac.
>

I'm not sure if a src of 0.0.0.0 is a good idea.  Wouldn't that typically
be the IP address of the DHCP server?  I'd be worried about some clients
treating it as invalid.

I think it should be specified by logical flows.  Something like:

dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0,
mtu=1300, dns={8.8.8.8, 7.7.7.7}); eth.dst = eth.src; eth.src =
; ip.src = ; outport = inport; inport = ""; output;

As for what addresses to use ... I don't know.  I think it should be
specified via OVN_Northbound, somehow.  It's easy enough for Neutron to
generate an IP and MAC to use.  It already creates DHCP ports for this
purpose.  Maybe it could just be additional logical port options, like
you're doing for the rest of the DHCP parameters?

-- 
Russell Bryant
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-28 Thread Numan Siddique 
On Mon, Mar 28, 2016 at 6:58 PM, Russell Bryant  wrote:

>
>
> On Thu, Mar 17, 2016 at 2:34 AM, Numan Siddique 
> wrote:
>
>> On 03/16/2016 10:44 PM, Russell Bryant wrote:
>> > It could also be this:
>> >
>> > dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0, mtu=1300,
>> > dns={8.8.8.8, 7.7.7.7});
>>
>> Thanks. This seems better to me.
>>
>
> Where do you get the source MAC and IP for the DHCP responses?
>
>
​For the initial testing I had harcoded source MAC to some value and left
the source ip unchanged i.e it 0.0.0.0

https://github.com/numansiddique/ovs/blob/dhcp_pause_rfc_working/ovn/northd/ovn-northd.c#L1132

I think it should be ok if the ovn-controller sets the source ip to
0.0.0.0, but not sure what should be set for source mac.

​
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-28 Thread Russell Bryant 
On Thu, Mar 17, 2016 at 2:34 AM, Numan Siddique  wrote:

> On 03/16/2016 10:44 PM, Russell Bryant wrote:
> > It could also be this:
> >
> > dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0, mtu=1300,
> > dns={8.8.8.8, 7.7.7.7});
>
> Thanks. This seems better to me.
>

Where do you get the source MAC and IP for the DHCP responses?

-- 
Russell Bryant
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-19 Thread Russell Bryant 
On Wed, Mar 16, 2016 at 12:11 AM, Numan Siddique 
wrote:

> On 03/16/2016 11:55 AM, Russell Bryant wrote:
>
> 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();
> 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?
>
>
> I thought about what you mentioned. Since there are many dhcp options and
> if we want to
> support extra dhcp options, We couldn't find a better way.
>
> With this approach, if CMS has set the below dhcp options in the
> Logical_Port.options
>   - "dhcp-opt-router=10.0.0.1", dhcp-opt-netmask=255.255.255.0",
> "dhcp-opt-mtu=1300", "dhcp-opt-dns=8.8.8.8,7.7.7.7",
>
> We could express this as "dhcp_offer{ offer_ip = 10.0.0.3; router =
> 10.0.0.1; netmask = 255.255.255.0; mtu = 1300; dns = 8.8.8.8, 7.7.7.7 ; }
> And the userdata would be stored as "
> 00.00.00.02.00.00.00.00.0a.00.00.03.03.04.0a.00.00.01.01.04.ff.ff.fe.00.1A.02.05.14.06.08.08.08.08.08.07.07.07.07".
>
> Please let us know if there is any better way to define this.
>

It could also be this:

dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0, mtu=1300,
dns={8.8.8.8, 7.7.7.7});

This is probably the least important detail, though.  We can always revisit
syntax later.  Sorry for the distraction.  :-)

-- 
Russell Bryant
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-19 Thread Ben Pfaff 
On Thu, Mar 17, 2016 at 12:04:19PM +0530, Numan Siddique wrote:
> On 03/16/2016 10:44 PM, Russell Bryant wrote:
> > It could also be this:
> >
> > dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0, mtu=1300,
> > dns={8.8.8.8, 7.7.7.7});
> 
> Thanks. This seems better to me.

Yes, I agree.  I prefer to use the "action_name { ... }" syntax for
nested actions.
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-19 Thread Numan Siddique 
On 03/16/2016 10:44 PM, Russell Bryant wrote:
> It could also be this:
>
> dhcp_offer(offer_ip=10.0.0.3, netmask=255.255.255.0, mtu=1300,
> dns={8.8.8.8, 7.7.7.7});

Thanks. This seems better to me.

Regards
Numan

___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-16 Thread Numan Siddique 
On 03/16/2016 11:55 AM, Russell Bryant wrote:
> 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();
> 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?

I thought about what you mentioned. Since there are many dhcp options and if we 
want to
support extra dhcp options, We couldn't find a better way.

With this approach, if CMS has set the below dhcp options in the 
Logical_Port.options
  - "dhcp-opt-router=10.0.0.1", dhcp-opt-netmask=255.255.255.0", 
"dhcp-opt-mtu=1300", "dhcp-opt-dns=8.8.8.8,7.7.7.7",

We could express this as "dhcp_offer{ offer_ip = 10.0.0.3; router = 10.0.0.1; 
netmask = 255.255.255.0; mtu = 1300; dns = 8.8.8.8, 7.7.7.7 ; }
And the userdata would be stored as 
"00.00.00.02.00.00.00.00.0a.00.00.03.03.04.0a.00.00.01.01.04.ff.ff.fe.00.1A.02.05.14.06.08.08.08.08.08.07.07.07.07".

Please let us know if there is any better way to define this.

Thanks
Numan

___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-15 Thread Russell Bryant 
On Mon, Mar 14, 2016 at 9:57 AM, Ben Pfaff  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="
> 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 ==  && 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();
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
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-14 Thread Ben Pfaff 
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=" 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 == 
>  && 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;)
> 
>   - ovn-controller would parse the action 'dhcp_offer' and store the dhcp 
> options in the
> 'userdata' of the packet-in and set 'pause' to true.
> 
>The corresponding OF Flow would look like
> 
> table=17, n_packets=7, n_bytes=2394, idle_age=1197, hard_age=2535, 
> priority=50,udp,reg6=0x2,metadata=0x1,dl_src=fa:16:3e:0b:73:79,nw_src=0.0.0.0,nw_dst=255.255.255.255,tp_src=68,tp_dst=67
>  
> actions=controller(userdata=00.00.00.02.00.00.00.00.0a.00.00.03.03.04.0a.00.00.01.01.04.ff.ff.fe.00,pause),move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_nw_dst:10.0.0.3,mod_tp_src:67,mod_tp_dst:68,move:NXM_NX_REG6[]->NXM_NX_REG7[],load:0->NXM_NX_REG6[],load:0->NXM_OF_IN_PORT[],resubmit(,32)
> 
> 
>  - When the ovn-controller receives the packet-in for the dhcp request, it 
> would
>frame a new dhcp packet with almost the same contents of the original 
> packet
>and copy the dhcp options from the 'userdata' to the packet dhcp options
>and resume the flow. OpenvSwitch would resume and apply the other actions.
> 
> We have a dirty poc code based on this approach here [1].
> 
> We would like to know if this solution is reasonable, so that we can proceed
> further with the implementation.

I like it.  Thank you for working on this!
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2016-03-09 Thread Numan Siddique 
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=" 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 == 
 && 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;)

  - ovn-controller would parse the action 'dhcp_offer' and store the dhcp 
options in the
'userdata' of the packet-in and set 'pause' to true.

   The corresponding OF Flow would look like

table=17, n_packets=7, n_bytes=2394, idle_age=1197, hard_age=2535, 
priority=50,udp,reg6=0x2,metadata=0x1,dl_src=fa:16:3e:0b:73:79,nw_src=0.0.0.0,nw_dst=255.255.255.255,tp_src=68,tp_dst=67
 
actions=controller(userdata=00.00.00.02.00.00.00.00.0a.00.00.03.03.04.0a.00.00.01.01.04.ff.ff.fe.00,pause),move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],mod_nw_dst:10.0.0.3,mod_tp_src:67,mod_tp_dst:68,move:NXM_NX_REG6[]->NXM_NX_REG7[],load:0->NXM_NX_REG6[],load:0->NXM_OF_IN_PORT[],resubmit(,32)


 - When the ovn-controller receives the packet-in for the dhcp request, it would
   frame a new dhcp packet with almost the same contents of the original packet
   and copy the dhcp options from the 'userdata' to the packet dhcp options
   and resume the flow. OpenvSwitch would resume and apply the other actions.

We have a dirty poc code based on this approach here [1].

We would like to know if this solution is reasonable, so that we can proceed
further with the implementation.

Please let us know your comments.

[1] - 
https://github.com/numansiddique/ovs/commit/13c4a2865bb81ce32e323bdabcb576598c411eb8

Thanks
Babu and Numan

___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2015-12-22 Thread Numan Siddique 
On 12/22/2015 01:31 PM, Ben Pfaff wrote:
> On Tue, Nov 24, 2015 at 04:48:59PM +0530, [email protected] wrote:
>> This patch series introduces native dhcp support in ovn controller.
>> v4 has few bug fixes in the test cases
>>
>> Babu Shanmugam (3):
>>   ovn: Dedicated connection handler for packet-ins
>>   ovn: New flows for DHCP tranffic
>>   ovn: Process dhcp packet-ins and respond through packet-outs
>>
>> Numan Siddique (1):
>>   ovn: Add tests for ovn dhcp
> 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?

Thanks Ben for your comments. We agree with you. It would be better that 
logical flows
tell what the reply should be for dhcp.

 What we understood from your comments is
 - that the dhcp packets will still be handled as packet-in/packet-out
 - the logical flows could like some thing like this
   "match=(inport="some port" and udp src port = 68 and dst port-67), 
action=(dhcp(
offer_ip, gw_ip, netmask, (and other options))


The "dhcp" action would add the packet-in flow  and also store the dhcp options 
something
similar to your patch "
14/14] ovn: Implement basic ARP support for L3 logical routers. 
"

When the dhcp packet is received as packet-in, the controller would just frame 
the dhcp reply by getting the dhcp options specified in the logical flows.

If our understanding is wrong, could you please provide with sample of logical 
flow to handle dhcp packets if you
have something in mind.

Thanks
Numan and Babu



> ___
> dev mailing list
> [email protected]
> http://openvswitch.org/mailman/listinfo/dev

___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2015-12-22 Thread Ben Pfaff 
On Tue, Nov 24, 2015 at 04:48:59PM +0530, [email protected] wrote:
> This patch series introduces native dhcp support in ovn controller.
> v4 has few bug fixes in the test cases
> 
> Babu Shanmugam (3):
>   ovn: Dedicated connection handler for packet-ins
>   ovn: New flows for DHCP tranffic
>   ovn: Process dhcp packet-ins and respond through packet-outs
> 
> Numan Siddique (1):
>   ovn: Add tests for ovn dhcp

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?
___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

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

2015-11-24 Thread bschanmu 
This patch series introduces native dhcp support in ovn controller.
v4 has few bug fixes in the test cases

Babu Shanmugam (3):
  ovn: Dedicated connection handler for packet-ins
  ovn: New flows for DHCP tranffic
  ovn: Process dhcp packet-ins and respond through packet-outs

Numan Siddique (1):
  ovn: Add tests for ovn dhcp

 lib/ofp-util.c  |  14 ++
 lib/ofp-util.h  |   3 +
 ovn/controller/automake.mk  |   4 +
 ovn/controller/ovn-controller.c |   6 +
 ovn/controller/ovn-dhcp.c   | 493 
 ovn/controller/ovn-dhcp.h   |  34 +++
 ovn/controller/physical.c   |  25 +-
 ovn/controller/pinctrl.c| 224 ++
 ovn/controller/pinctrl.h|  36 +++
 ovn/ovn-nb.xml  |  29 +++
 ovn/ovn-sb.xml  |  29 +++
 tests/automake.mk   |   1 +
 tests/ovn.at| 184 +++
 tests/test-ovn-dhcp.c   | 228 +++
 14 files changed, 1308 insertions(+), 2 deletions(-)
 create mode 100644 ovn/controller/ovn-dhcp.c
 create mode 100644 ovn/controller/ovn-dhcp.h
 create mode 100644 ovn/controller/pinctrl.c
 create mode 100644 ovn/controller/pinctrl.h
 create mode 100644 tests/test-ovn-dhcp.c

-- 
1.9.1

___
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev