[ovs-discuss] Reg. ofport set to -1

[Vishal Deep Ajmera]

Hi,

Gentle reminder for folks to share their thoughts. We have a potential fix for this issue wherein we do not release the ofport number until the failed port is deleted from the ovsdb. Once the failed port is deleted from the ovsdb, the ofport number is appended to the LRU list.

Does this make sense ?

Regards,
Vishal

From: Vishal Deep Ajmera
Sent: Tuesday, November 27, 2018 11:17 AM
To: Vishal Deep Ajmera <vishal.deep.ajmera at ericsson.com>; ovs-discuss at openvswitch.org
Subject: RE: Reg. ofport set to -1

Anyone faced similar issue with other controllers?

From: ovs-discuss-bounces at openvswitch.org<mailto:ovs-discuss-bounces at openvswitch.org> <ovs-discuss-bounces at openvswitch.org<mailto:ovs-discuss-bounces at openvswitch.org>> On Behalf Of Vishal Deep Ajmera
Sent: Wednesday, November 21, 2018 2:14 PM
To: ovs-discuss at openvswitch.org<mailto:ovs-discuss at openvswitch.org>
Subject: [ovs-discuss] Reg. ofport set to -1

Hi,

Currently in OVS we set "-1" for ofport field in interface table of OVS DB when we fail to initialize the interface. This means if we had allocated any ofport number earlier, it is released. When the above failed interface gets initialized successfully later it gets a "new" ofport number again. Due to change in ofport number, any SDN controller will have to change all the openflows corresponding to this interface (due to change in port number). I am not sure why we release the ofport number for the interface, unless it is deleted from the interface table itself.

Does it make sense to preserve the ofport number as long as the interface is present in OVS DB and release it once it is deleted? This will help controller not to modify existing flows but only replay (resync) the same, once interface comes back alive.

Need some guidance here how to handle such cases.

Warm Regards,
Vishal Ajmera


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20190528/fa8d0306/attachment.html>