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* [email protected] <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 <[email protected]> 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 > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
