[OPNFLWPLUG-454] Provide override for features detected during handshake Created: 23/May/15  Updated: 27/Sep/21  Resolved: 02/Jun/15

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Anton Ivanov Assignee: Martin Bobak
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All



 Description   

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.

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).



 Comments   
Comment by Abhijit Kumbhare [ 24/May/15 ]

Current implementation of the new design as per Martin:

=============
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.
=============

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).

Hence we need to back out the change described by Martin.

Comment by Michal Rehak [ 27/May/15 ]

Why do we need to support buggy virtual switch if there is already released fixed version?

Comment by Anton Ivanov [ 27/May/15 ]

(In reply to michal rehak from comment #2)
> Why do we need to support buggy virtual switch if there is already released
> fixed version?

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.

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.

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).

Comment by Abhijit Kumbhare [ 27/May/15 ]

(In reply to michal rehak from comment #2)
> Why do we need to support buggy virtual switch if there is already released
> fixed version?

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.

Also an example Anil mentioned (https://lists.opendaylight.org/pipermail/openflowplugin-dev/2015-May/003149.html):

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.

Comment by Martin Bobak [ 02/Jun/15 ]

https://git.opendaylight.org/gerrit/#/c/21658/

Comment by Martin Bobak [ 02/Jun/15 ]

Gerrit url in previous comment should be a solution for this issue.

Generated at Wed Feb 07 20:32:31 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.