Thanks for the information.
I would imagine backwards compatibility with the old branched version of
OVS 2.6 wont be necessary, especially since this work will get us on a
mainstream version of OVS.
I'll be with you at the OpenFlow Plugin meeting on Monday. We can discuss
more in person then.
Screenshot 2017-02-14 at 10.43.55 AM.png]
On Mon, May 14, 2018 at 1:35 PM, Jaime Caamaño Ruiz <jcaam...@suse.de>
> Hello all
> I am working on adding to openflowplugin the nsh support that has been
> available since OVS 2.8. Some of us had some discussions about this on
> DDF, that have continued on the project meetings and now continue on
> this email.
> Openflowplugin already had nsh support for an OVS 2.5/2.6 unoficially
> patched out of branch with , but now the official available support
> is somewhat different to that.
> Early discussions we had about this we talked about preserving backward
> compatibility, but it seems that some of us understood different things
> about backward compatibility: whether we wanted API backward
> compatibility for applications or whether we want to support both old
> OSV+nsh patch and new OVS nsh implementations at the same time. I
> assumed the former, but needs to be further discussed. Afaik, user
> applications are SFC, Netvirt and GBP. Unaware about downstreamers, but
> users unlikely due to being a patched OVS.
> The main difference between both implementations is that the same nsh
> match fields are now experimenter oxm_class=0xFFFF with experimenter ID
> NXOXM_NSH=0x005ad650. These are the first of its kind, as existing
> nicira fields up until now, including the previous version of nsh
> fields already implemented for patched OVS, are all standard OXM fields
> under nicira vendor/class (NXM_OF=0x0000, NXM_NX=0x0001). For
> reference, new nsh fields introduced with OVS 2.8 that did not exist on
> the patched OVS are already proposed on patch , where as
> coincidental fields are to be migrated to the new enconding in a future
> Aside from the fields themselves, some of the existing openflowplugin
> nicira actions that were being used to manipulate these fields require
> changes to be able to support experimenter fields:
> - NXAST_REG_LOAD action is used to set values to nicira fields. This
> action does not support oxm experimenter fields. NXAST_REG_LOAD2 needs
> to be used instead. There is already a patch proposed for this .
> This patch will keep intact the existing application API for reg load
> action, and internally implement NXAST_REG_LOAD or NXAST_REG_LOAD2
> depending on whether the field to be set is experimenter or not.
> - NXAST_RAW_REG_MOVE action is used to copy values between nicira oxm
> fields. It does support experimenter fields, but not as implemented on
> its current form as it allows only 4 byte for oxm headers. Needs to be
> extended to support 8 byte experimenter oxm headers. There is already a
> patch proposed for this .
> - NXAST_RAW_OUTPUT_REG action is used to out to a port based on the
> value of a field. Similarly to NXAST_REG_LOAD, it does not support
> experimenter oxm headers, NXAST_RAW_OUTPUT_REG2 needs to be used
> Topics I would like to discuss:
> - What kind of backward compatibility would we like? OVS backward
> compatibility to an unofficial out of branch patched OVS? API backward
> compatibility for applications? Both? None?
> - As these are experimenter fields, we are extending the experimenter
> id case in the model as proposed on , but Anil sugested if we could
> avoid this. I think we could but I would like to understand why.
> - As propoosed in , is it accetable to keep a single API for
> openflow actions that have two versions, non-experimenter vs
> experimenter? Initially thought to be API backward compatible, but even
>  https://github.com/yyang13/ovs_nsh_patches
>  https://git.opendaylight.org/gerrit/#/c/71895/
>  https://git.opendaylight.org/gerrit/#/c/71917/
>  https://git.opendaylight.org/gerrit/#/c/71999/
> Thanks and BR
> openflowplugin-dev mailing list
openflowplugin-dev mailing list