Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status of OpenFlow 1.3 support. #126

Open
vitalivanov opened this issue Apr 25, 2014 · 5 comments
Open

Status of OpenFlow 1.3 support. #126

vitalivanov opened this issue Apr 25, 2014 · 5 comments

Comments

@vitalivanov
Copy link

Can anyone describe the status of openflow 1.3 protocol support?
What is done and what is to be done?

TIA

@stephenfin
Copy link
Contributor

From what I can see, OFTest relies heavily on loxigen. That project has recently added support for 1.3.1 so OFTest needs to be updated accordingly. When/if this will happen though I'm unsure?

@capveg
Copy link

capveg commented Nov 30, 2014

Fwiw, we've been using OFTest internally to do lots of OF-1.3 testing, so
all of the knobs are there. The problem is that OF1.3 is hard to test
without making assumptions about the packet processing pipeline (that is,
the order and capabilities of the match action tables). The set of tests
that you can run without making assumptions about the packet processing
pipeline is fairly trivial and not terribly useful.

OpenFlow in general hasn't really solved that problem - it's not really an
OFTest issue.

  • Rob
    .

On Thu, Nov 27, 2014 at 3:59 AM, Stephen Finucane [email protected]
wrote:

From what I can see, OFTest relies heavily on loxigen
https://github.com/floodlight/loxigen. That project has recently added
support for 1.3.1 so OFTest needs to be updated accordingly. When/if this
will happen though I'm unsure?


Reply to this email directly or view it on GitHub
#126 (comment).

@jonstout
Copy link
Contributor

jonstout commented Dec 1, 2014

I believe parsing/packing of table_feature_prop types have not yet been resolved. Other than that, I think everything is fine. floodlight/loxigen#198

@capveg
Copy link

capveg commented Dec 1, 2014

True -- I had forgotten about that. Is this something that's significantly
an issue? If so, I might be able to get someone on our side to look into
it.

  • Rob
    .

On Mon, Dec 1, 2014 at 9:21 AM, Jonathan Stout [email protected]
wrote:

I believe parsing/packing of table_feature_prop types have not yet been
resolved. Other than that, I think everything is fine.


Reply to this email directly or view it on GitHub
#126 (comment).

@jonstout
Copy link
Contributor

jonstout commented Dec 1, 2014

There are two main cases were these message types are used in conformance style tests.

  1. We generally check if a table claims support for a feature before we go on and test it.
  2. The specification allows for tables to be configured using these messages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants