Jaime,

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.

Thanks,

*Brady Johnson*
bjohn...@inocybe.ca

<https://twitter.com/inocybetech> <http://www.inocybe.com/>
<https://www.linkedin.com/company/2661537?trk=tyah&trkInfo=clickedVertical%3Acompany%2CclickedEntityId%3A2661537%2Cidx%3A1-1-1%2CtarId%3A1441300264767%2Ctas%3Ainocybe>
[image:
Screenshot 2017-02-14 at 10.43.55 AM.png]
<https://www.youtube.com/channel/UC9uUWABdPR0Je9Du_15FCkw>



On Mon, May 14, 2018 at 1:35 PM, Jaime Caamaño Ruiz <jcaam...@suse.de>
wrote:

> 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 [1], 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 [2], where as
> coincidental fields are to be migrated to the new enconding in a future
> patch.
>
> 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 [3].
> 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 [4].
>
> - 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
> instead.
>
> 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 [2], but Anil sugested if we could
> avoid this. I think we could but I would like to understand why.
> - As propoosed in [3], 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
> regardless?
>
> [1] https://github.com/yyang13/ovs_nsh_patches
> [2] https://git.opendaylight.org/gerrit/#/c/71895/
> [3] https://git.opendaylight.org/gerrit/#/c/71917/
> [4] https://git.opendaylight.org/gerrit/#/c/71999/
>
> Thanks and BR
> Jaime.
>
>
> _______________________________________________
> openflowplugin-dev mailing list
> openflowplugin-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
>
_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

Reply via email to