Re: [openflowplugin-dev] Implementing nsh support available since OVS 2.8

[Anil Vishnoi]

As we discussed in the OpenFlow plugin meeting, all the existing committers
and sfc project is in agreement that we should implement these new standard
NSH API and remove the old (non-standard, non-ga'ed) API's for better
clarity for the downstream consumers. Given that the old API's were based
on the OVS + kernel patch and also limited to OVS only, the impact radius
is pretty much the ODL projects (NetVirt, GBP, SFC). We should bring these
project in the discussion and understand their thoughts about this
approach, if they agree, we can merge the new implementation.

@Brady/@Jamie, can you please take this up with NetVirt/GBP project?

On Wed, May 23, 2018 at 2:56 AM, Jaime Caamaño Ruiz 
wrote:

> Hello
>
> > Something similar happens with output_reg action vs output_reg2 that
> > supports experimenter fields. In this case, there is no functional
> > difference between the two, so it looks like it makes sense to encode
> > output_reg2 for all fields, and drop output_reg alltogether, without
> > any change on APIs.
>
> Changing the existing output_reg encoding from NXAST_OUTPUT_REG to
> NXAST_OUTPUT_REG2 would not work if we need to support upgrade paths
> where the flows existing pre-upgrade persist during the upgrade. I
> guess this is indeed the case? Or does the upgrade procedure mandate
> exporting the database, clean switches, upgrade and then import
> database? Are there any docs on this?
>
> BR
> Jaime.
>
> -Original Message-
> From: Jaime Caamaño Ruiz  
> Reply-To: jcaam...@suse.com
> To: Hema Gopalkrishnan , Prasanna
> Huddar , Abhijit Kumbhare  ail.com>, Shuva Kar , Anil Vishnoi  oia...@gmail.com>, jcaam...@suse.de
> Cc: openflowplugin-dev 
> Subject: Re: [openflowplugin-dev] Implementing nsh support available
> since OVS 2.8
> Date: Mon, 21 May 2018 14:15:51 +0200
>
> Hello Anil
>
> The only standing issue with API backward compatibility is whether to
> expose a reg_load2 action in the API and forcing changes on
> applications to use that for nsh fields, vs using the currently exposed
> reg_load action and internally encode that to reg_load2 for these nsh
> fields.
>
> Even not worrying about backward API compatibility, the second option
> is still worthy of consideration IMHO.
>
> The only useful reason to expose reg_load2 in the API would be to be
> able for the user to set complex structured fields, which there are
> none right now. The fact that right now we need to encode that action
> for experimenter fields is an implementation detail that the user might
> not be concerned about.
>
> Even so, we might want to expose reg_load2 given that it may come the
> day when there is really a use for it. We do need to consider that the
> payload of a reg_load2 action could be any field and this does add a
> level of complexity both in the modelling and conversion logic, an
> extra effort that wouldn't be really useful until that day comes. At
> that time, it has probably more value to work on being able to use
> standard openflow action set_field (functionally equivalent) with
> extension fields.
>
> Something similar happens with output_reg action vs output_reg2 that
> supports experimenter fields. In this case, there is no functional
> difference between the two, so it looks like it makes sense to encode
> output_reg2 for all fields, and drop output_reg alltogether, without
> any change on APIs.
>
> BR
> Jaime.
>
> -Original Message-----
> From: Anil Vishnoi 
> To: Hema Gopalkrishnan , Prasanna
> Huddar , Abhijit Kumbhare  ail.com>, Shuva Kar , jcaam...@suse.de
> Cc: openflowplugin-dev 
> Subject: Re: [openflowplugin-dev] Implementing nsh support available
> since OVS 2.8
> Date: Sun, 20 May 2018 23:12:28 -0700
>
>
>
> On Mon, May 14, 2018 at 11:35 AM, Jaime Caamaño Ruiz 
> 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.

Re: [openflowplugin-dev] Implementing nsh support available since OVS 2.8

[Jaime Caamaño Ruiz]

Hello

> Something similar happens with output_reg action vs output_reg2 that
> supports experimenter fields. In this case, there is no functional
> difference between the two, so it looks like it makes sense to encode
> output_reg2 for all fields, and drop output_reg alltogether, without
> any change on APIs.

Changing the existing output_reg encoding from NXAST_OUTPUT_REG to
NXAST_OUTPUT_REG2 would not work if we need to support upgrade paths
where the flows existing pre-upgrade persist during the upgrade. I
guess this is indeed the case? Or does the upgrade procedure mandate
exporting the database, clean switches, upgrade and then import
database? Are there any docs on this?

BR
Jaime.

-Original Message-
From: Jaime Caamaño Ruiz  
Reply-To: jcaam...@suse.com
To: Hema Gopalkrishnan , Prasanna
Huddar , Abhijit Kumbhare , Shuva Kar , Anil Vishnoi , jcaam...@suse.de
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] Implementing nsh support available
since OVS 2.8
Date: Mon, 21 May 2018 14:15:51 +0200

Hello Anil

The only standing issue with API backward compatibility is whether to
expose a reg_load2 action in the API and forcing changes on
applications to use that for nsh fields, vs using the currently exposed
reg_load action and internally encode that to reg_load2 for these nsh
fields.

Even not worrying about backward API compatibility, the second option
is still worthy of consideration IMHO.

The only useful reason to expose reg_load2 in the API would be to be
able for the user to set complex structured fields, which there are
none right now. The fact that right now we need to encode that action
for experimenter fields is an implementation detail that the user might
not be concerned about.

Even so, we might want to expose reg_load2 given that it may come the
day when there is really a use for it. We do need to consider that the
payload of a reg_load2 action could be any field and this does add a
level of complexity both in the modelling and conversion logic, an
extra effort that wouldn't be really useful until that day comes. At
that time, it has probably more value to work on being able to use
standard openflow action set_field (functionally equivalent) with
extension fields.

Something similar happens with output_reg action vs output_reg2 that
supports experimenter fields. In this case, there is no functional
difference between the two, so it looks like it makes sense to encode
output_reg2 for all fields, and drop output_reg alltogether, without
any change on APIs.

BR
Jaime.

-Original Message-
From: Anil Vishnoi 
To: Hema Gopalkrishnan , Prasanna
Huddar , Abhijit Kumbhare , Shuva Kar , jcaam...@suse.de
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] Implementing nsh support available
since OVS 2.8
Date: Sun, 20 May 2018 23:12:28 -0700



On Mon, May 14, 2018 at 11:35 AM, Jaime Caamaño Ruiz 
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=0x 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=0x, 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 suppo

Re: [openflowplugin-dev] Implementing nsh support available since OVS 2.8

[Jaime Caamaño Ruiz]

Hello Hema

> I tend to agree with Anil, that since the previous NSH APIs were not
> officially supported by OVS, we should be able to remove them and
> just
> implement the new ones and support just one API.

Agreed.

>  Can you elaborate more on exposing reg_load2 to enable the user to
> set
> complex structured fields.

The OXM/NXM fields that you can set with reg_load2 could be modelled
after the same format as the match types that we have already defined
for those same fields. So you would be exposing the format of each
specific different field that you want to set with reg_load2, not just
a generic sequence of bytes as with reg_load. Just like set_field
action is modelled.

BR
Jaime.



-Original Message-
From: Hema Gopalkrishnan 
To: Prasanna Huddar , Abhijit Kumbhare , Shuva Kar , Anil
Vishnoi , jcaam...@suse.de
Cc: openflowplugin-dev 
Subject: RE: [openflowplugin-dev] Implementing nsh support available
since OVS 2.8
Date: Mon, 21 May 2018 14:17:38 +

Hi Jaime,
I tend to agree with Anil, that since the previous NSH APIs were not
officially supported by OVS, we should be able to remove them and just
implement the new ones and support just one API.

 Can you elaborate more on exposing reg_load2 to enable the user to set
complex structured fields.
Maybe, we can discuss this in today's meeting.
Regards,
Hema.

-Original Message-
From: Jaime Caamaño Ruiz [mailto:jcaam...@suse.de] 
Sent: 21 May 2018 17:46
To: Anil Vishnoi ; Hema Gopalkrishnan ; Prasanna Huddar 
; Abhijit Kumbhare ; Shuva Kar 
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] Implementing nsh support available
since OVS 2.8

Hello Anil

The only standing issue with API backward compatibility is whether to
expose a reg_load2 action in the API and forcing changes on
applications to use that for nsh fields, vs using the currently exposed
reg_load action and internally encode that to reg_load2 for these nsh
fields.

Even not worrying about backward API compatibility, the second option
is still worthy of consideration IMHO.

The only useful reason to expose reg_load2 in the API would be to be
able for the user to set complex structured fields, which there are
none right now. The fact that right now we need to encode that action
for experimenter fields is an implementation detail that the user might
not be concerned about.

Even so, we might want to expose reg_load2 given that it may come the
day when there is really a use for it. We do need to consider that the
payload of a reg_load2 action could be any field and this does add a
level of complexity both in the modelling and conversion logic, an
extra effort that wouldn't be really useful until that day comes. At
that time, it has probably more value to work on being able to use
standard openflow action set_field (functionally equivalent) with
extension fields.

Something similar happens with output_reg action vs output_reg2 that
supports experimenter fields. In this case, there is no functional
difference between the two, so it looks like it makes sense to encode
output_reg2 for all fields, and drop output_reg alltogether, without
any change on APIs.

BR
Jaime.

-Original Message-
From: Anil Vishnoi 
To: Hema Gopalkrishnan , Prasanna
Huddar , Abhijit Kumbhare , Shuva Kar , jcaam...@suse.de
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] Implementing nsh support available
since OVS 2.8
Date: Sun, 20 May 2018 23:12:28 -0700



On Mon, May 14, 2018 at 11:35 AM, Jaime Caamaño Ruiz 
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=0x 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 
> f

Re: [openflowplugin-dev] Implementing nsh support available since OVS 2.8

[Hema Gopalkrishnan]

Hi Jaime,
I tend to agree with Anil, that since the previous NSH APIs were not officially 
supported by OVS, we should be able to remove them and just implement the new 
ones and support just one API.

 Can you elaborate more on exposing reg_load2 to enable the user to set complex 
structured fields.
Maybe, we can discuss this in today's meeting.
Regards,
Hema.

-Original Message-
From: Jaime Caamaño Ruiz [mailto:jcaam...@suse.de] 
Sent: 21 May 2018 17:46
To: Anil Vishnoi ; Hema Gopalkrishnan 
; Prasanna Huddar 
; Abhijit Kumbhare ; Shuva 
Kar 
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] Implementing nsh support available since OVS 
2.8

Hello Anil

The only standing issue with API backward compatibility is whether to expose a 
reg_load2 action in the API and forcing changes on applications to use that for 
nsh fields, vs using the currently exposed reg_load action and internally 
encode that to reg_load2 for these nsh fields.

Even not worrying about backward API compatibility, the second option is still 
worthy of consideration IMHO.

The only useful reason to expose reg_load2 in the API would be to be able for 
the user to set complex structured fields, which there are none right now. The 
fact that right now we need to encode that action for experimenter fields is an 
implementation detail that the user might not be concerned about.

Even so, we might want to expose reg_load2 given that it may come the day when 
there is really a use for it. We do need to consider that the payload of a 
reg_load2 action could be any field and this does add a level of complexity 
both in the modelling and conversion logic, an extra effort that wouldn't be 
really useful until that day comes. At that time, it has probably more value to 
work on being able to use standard openflow action set_field (functionally 
equivalent) with extension fields.

Something similar happens with output_reg action vs output_reg2 that supports 
experimenter fields. In this case, there is no functional difference between 
the two, so it looks like it makes sense to encode
output_reg2 for all fields, and drop output_reg alltogether, without any change 
on APIs.

BR
Jaime.

-Original Message-
From: Anil Vishnoi 
To: Hema Gopalkrishnan , Prasanna Huddar 
, Abhijit Kumbhare , 
Shuva Kar , jcaam...@suse.de
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] Implementing nsh support available since OVS 
2.8
Date: Sun, 20 May 2018 23:12:28 -0700



On Mon, May 14, 2018 at 11:35 AM, Jaime Caamaño Ruiz 
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=0x 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=0x, 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 

Re: [openflowplugin-dev] Implementing nsh support available since OVS 2.8

[Jaime Caamaño Ruiz]

Hello Anil

The only standing issue with API backward compatibility is whether to
expose a reg_load2 action in the API and forcing changes on
applications to use that for nsh fields, vs using the currently exposed
reg_load action and internally encode that to reg_load2 for these nsh
fields.

Even not worrying about backward API compatibility, the second option
is still worthy of consideration IMHO.

The only useful reason to expose reg_load2 in the API would be to be
able for the user to set complex structured fields, which there are
none right now. The fact that right now we need to encode that action
for experimenter fields is an implementation detail that the user might
not be concerned about.

Even so, we might want to expose reg_load2 given that it may come the
day when there is really a use for it. We do need to consider that the
payload of a reg_load2 action could be any field and this does add a
level of complexity both in the modelling and conversion logic, an
extra effort that wouldn't be really useful until that day comes. At
that time, it has probably more value to work on being able to use
standard openflow action set_field (functionally equivalent) with
extension fields.

Something similar happens with output_reg action vs output_reg2 that
supports experimenter fields. In this case, there is no functional
difference between the two, so it looks like it makes sense to encode
output_reg2 for all fields, and drop output_reg alltogether, without
any change on APIs.

BR
Jaime.

-Original Message-
From: Anil Vishnoi 
To: Hema Gopalkrishnan , Prasanna
Huddar , Abhijit Kumbhare , Shuva Kar , jcaam...@suse.de
Cc: openflowplugin-dev 
Subject: Re: [openflowplugin-dev] Implementing nsh support available
since OVS 2.8
Date: Sun, 20 May 2018 23:12:28 -0700



On Mon, May 14, 2018 at 11:35 AM, Jaime Caamaño Ruiz 
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=0x 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=0x, 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 bac

Re: [openflowplugin-dev] Implementing nsh support available since OVS 2.8

[Anil Vishnoi]

On Mon, May 14, 2018 at 11:35 AM, Jaime Caamaño Ruiz 
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=0x 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=0x, 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?
>
​Previous NSH related API's in openflowplugin where based on old NSH OVS
(2.6) patches, and these API's were working with OVS 2.6 + NSH patch. Now
if we implement new NSH API's and just keep the API compatibility, but it's
breaks the functionality for OVS2.6, than keeping the API compatibility is
pretty much useless because those API's were designed based on the old NSH
OVS patch. So either we keep the end to end backward compatibility or
nothing.

Ideally deprecating the API takes the process of first deprecating the old
API for one release and remove it during the next release, but given that
these API's are very specific to OVS and  related to NSH functionality that
never existed in formally released OVS version, i believe we should remove
the old API's and implement the new one. That will avoid any confusion for
the end-user. Also as Brady mentioned, i doubt there will be any downstream
consumer apart from the ODL projects (SFC, NetVirt, GBP), so removing these
API's without deprecation process should be safe.

@Abhijit, @Prasanna @Hema, @Shuva @jozef what is your take on it?

- 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?
>
​Answer to these questions depends on how we answer the first question.​


>
> [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
> 

Re: [openflowplugin-dev] Implementing nsh support available since OVS 2.8

[Brady Johnson]

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

 

[image:
Screenshot 2017-02-14 at 10.43.55 AM.png]




On Mon, May 14, 2018 at 1:35 PM, Jaime Caamaño Ruiz 
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=0x 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=0x, 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