https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWPLUG-454 OpenFlowPlugin <p>In order to support switches with buggy and/or partial implementations (f.e. OVS 2.0) it is necessary to have the option to override the feature set determined durig handshake.</p> <p>Example: force the use of the meter feature (even if the switch does not report them as supported). Force not to use the meter feature (switch reports them as supported but we know it is buggy).</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-454

Provide override for features detected during handshake

Improvement Resolved Done Martin Bobak Anton Ivanov Sat, 23 May 2015 06:30:36 +0000 Mon, 27 Sep 2021 09:01:32 +0000 Tue, 2 Jun 2015 13:14:21 +0000 General 0 7 <p>Current implementation of the new design as per Martin:</p> <p>=============<br/> Martin Bobák: When device connects ofp asks for description (OFPMPDESC). When successfull response is received we ask for meter,group, table and port features. If any of those feature requests (except table features) fails we are not propagating this device furhter. So we don't register its RPC's.<br/> =============</p> <p>This means that the issue is not just OVS 2.0 switches - but other OpenFlow 1.3 switches which do not support groups or meters cannot be used with the new OpenFlow plugin design. Examples of these could be hardware switches which were implemented OpenFlow 1.0 feature set but are now supporting that feature set over the 1.3 wire protocol (because ONF had declared 1.3 as a long term support version if I remember right).</p> <p>Hence we need to back out the change described by Martin.</p> <p>Why do we need to support buggy virtual switch if there is already released fixed version?</p> <p>(In reply to michal rehak from comment #2)<br/> &gt; Why do we need to support buggy virtual switch if there is already released<br/> &gt; fixed version?</p> <p>Because the customer has decided for whatever reason to go with it. It is a reality in telco world - getting customers to upgrade something which they perceive as working is not the easiest task. </p> <p>While not everyone is like one, well known European telco which till recently had 20+ year old equipment and networking in their network, this is still the norm.</p> <p>In any case, in my opinion, the opposite use case (switch reports stuff as working while it is not) is more important. That is something which happens on a regular basis with all vendors. Getting this implemented automatically covers the opposite case (switch working, but does not report all features).</p> <p>(In reply to michal rehak from comment #2)<br/> &gt; Why do we need to support buggy virtual switch if there is already released<br/> &gt; fixed version?</p> <p>Michal - from Martin's description the issue is not just some buggy OVS 2.0 switches - but other OpenFlow 1.3 switches which do not support groups or meters cannot be used with the new OpenFlow plugin design.</p> <p>Also an example Anil mentioned (<a href="https://lists.opendaylight.org/pipermail/openflowplugin-dev/2015-May/003149.html):" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/openflowplugin-dev/2015-May/003149.html):</a></p> <p>ovsdb project will not be able to support compute node running ovs 2.0.2 which is stock install for Ubuntu 14.04 server system. It will force user to explicitly install ovs 2.3.0, which i believe a bit hit to the usability of the plugin and ovsdb solution as such.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/21658/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/21658/</a></p> <p>Gerrit url in previous comment should be a solution for this issue.</p> Development External issue ID 3350 External issue URL Issue Type Rank 0|i03193: