yahoo-eng-team team mailing list archive

[Lajos Katona <2015471@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

ERSPAN (Encapsulated Remote Switch Port Analyzer) is a videly used tool
to analyse traffic of switch ports. The whole concept first was used
widely in Cisco switches.

ERSPAN protocol is used in 2 versions, version 1 (Type II), and version
2 (Type III) (Note: Type I was not widely used) ERSPAN version 2 adds an
extra ERSPAN header over GRE, and a similar but more flexible extra
ERSPAN header is used for version 3 (see [1]).

Since OVS 2.10 it is possible to use ERSPAN with OVS (see [2], and [3]) both ERSPAN v1 and v2.
Since OVN v22.12.0 it is possible to create mirrors with OVN (see [4], I can't find it in the release-notes or in any OVN docs, I suppose that is my lack of experience with OVN).
NOTE: OVN only supports ERSPAN v1, and with OVN it is also possible to create a clean GRE type mirror.

There's a few things to consider, I add here now only the question of
how the API should look like.

The current TAAS API deals with 2 high level objects:
* The Tap Service identifies the destination of the mirroring, which is a Neutron port (see [5])
* The Tap Flow identifies the source of the mirroring, which is again a Neutron port (see [6]). There is a N:1 relationship between tap-flows and tap-services, so multiple tap-flows can be the source of one tap-service.

With ERSPAN this model is not that useful:

* one way forward can be to keep the current API with extra fields for both Tap Service and for Tap flow:
Tap Service: new field that mark the tap-service as ERSPAN destination port (in this case the port field should not be obligatory)
Tap Flow: new fields: erspan_dst_ip and erspan_idx.

* Another option is to encode this in the Tap Service and we could keep
at least the Tap Flow unchanged. This would mean that for "legacy"
mirroring with OVS or SRIOV the API behaves differently, or used
differenltly.

* Yet another option is to introduce a new API for ERSPAN to make as
simple as possible.

[1]: https://datatracker.ietf.org/doc/id/draft-foschiano-erspan-02.txt => Note this is a draft, and I think ERSPAN was not standardized.
[2]: https://docs.openvswitch.org/en/latest/faq/configuration/
[3]: http://www.openvswitch.org//support/dist-docs/ovs-fields.7.txt
[4]: https://github.com/ovn-org/ovn/commit/323f978cbf4599568fcca9edec8ed53c076d2664
[5]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-service
[6]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-flow

** Affects: neutron
     Importance: Wishlist
         Status: New


** Tags: rfe

** Changed in: neutron
   Importance: Undecided => Wishlist

** Description changed:

  ERSPAN (Encapsulated Remote Switch Port Analyzer) is a videly used tool
  to analyse traffic of switch ports. The whole concept first was used
  widely in Cisco switches.
  
  ERSPAN protocol is used in 2 versions, version 1 (Type II), and version
  2 (Type III) (Note: Type I was not widely used) ERSPAN version 2 adds an
  extra ERSPAN header over GRE, and a similar but more flexible extra
  ERSPAN header is used for version 3 (see [1]).
  
  Since OVS 2.10 it is possible to use ERSPAN with OVS (see [2], and [3]) both ERSPAN v1 and v2.
- Since OVN v22.12.0 it is possible to create mirrors with OVN (see [4], I can't find it in the release-notes or in any OVN docs, I suppose that is my lack of experience with OVN). 
+ Since OVN v22.12.0 it is possible to create mirrors with OVN (see [4], I can't find it in the release-notes or in any OVN docs, I suppose that is my lack of experience with OVN).
  NOTE: OVN only supports ERSPAN v1, and with OVN it is also possible to create a clean GRE type mirror.
  
  There's a few things to consider, I add here now only the question of
  how the API should look like.
  
  The current TAAS API deals with 2 high level objects:
  * The Tap Service identifies the destination of the mirroring, which is a Neutron port (see [5])
  * The Tap Flow identifies the source of the mirroring, which is again a Neutron port (see [6]). There is a N:1 relationship between tap-flows and tap-services, so multiple tap-flows can be the source of one tap-service.
  
  With ERSPAN this model is not that useful:
  
  * one way forward can be to keep the current API with extra fields for both Tap Service and for Tap flow:
  Tap Service: new field that mark the tap-service as ERSPAN destination port (in this case the port field should not be obligatory)
  Tap Flow: new fields: erspan_dst_ip and erspan_idx.
  
  * Another option is to encode this in the Tap Service and we could keep
  at least the Tap Flow unchanged. This would mean that for "legacy"
  mirroring with OVS or SRIOV the API behaves differently, or used
  differenltly.
  
  * Yet another option is to introduce a new API for ERSPAN to make as
  simple as possible.
  
- 
  [1]: https://datatracker.ietf.org/doc/id/draft-foschiano-erspan-02.txt => Note this is a draft, and I think ERSPAN was not standardized.
  [2]: https://docs.openvswitch.org/en/latest/faq/configuration/
  [3]: http://www.openvswitch.org//support/dist-docs/ovs-fields.7.txt
  [4]: https://github.com/ovn-org/ovn/commit/323f978cbf4599568fcca9edec8ed53c076d2664
  [5]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-service
  [6]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-flow
- [7]: https://review.opendev.org/c/openstack/tap-as-a-service/+/693366

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2015471

Title:
  [RFE] Add ERSPAN for tap-as-a-service with OVS and OVN

Status in neutron:
  New

Bug description:
  ERSPAN (Encapsulated Remote Switch Port Analyzer) is a videly used
  tool to analyse traffic of switch ports. The whole concept first was
  used widely in Cisco switches.

  ERSPAN protocol is used in 2 versions, version 1 (Type II), and
  version 2 (Type III) (Note: Type I was not widely used) ERSPAN version
  2 adds an extra ERSPAN header over GRE, and a similar but more
  flexible extra ERSPAN header is used for version 3 (see [1]).

  Since OVS 2.10 it is possible to use ERSPAN with OVS (see [2], and [3]) both ERSPAN v1 and v2.
  Since OVN v22.12.0 it is possible to create mirrors with OVN (see [4], I can't find it in the release-notes or in any OVN docs, I suppose that is my lack of experience with OVN).
  NOTE: OVN only supports ERSPAN v1, and with OVN it is also possible to create a clean GRE type mirror.

  There's a few things to consider, I add here now only the question of
  how the API should look like.

  The current TAAS API deals with 2 high level objects:
  * The Tap Service identifies the destination of the mirroring, which is a Neutron port (see [5])
  * The Tap Flow identifies the source of the mirroring, which is again a Neutron port (see [6]). There is a N:1 relationship between tap-flows and tap-services, so multiple tap-flows can be the source of one tap-service.

  With ERSPAN this model is not that useful:

  * one way forward can be to keep the current API with extra fields for both Tap Service and for Tap flow:
  Tap Service: new field that mark the tap-service as ERSPAN destination port (in this case the port field should not be obligatory)
  Tap Flow: new fields: erspan_dst_ip and erspan_idx.

  * Another option is to encode this in the Tap Service and we could
  keep at least the Tap Flow unchanged. This would mean that for
  "legacy" mirroring with OVS or SRIOV the API behaves differently, or
  used differenltly.

  * Yet another option is to introduce a new API for ERSPAN to make as
  simple as possible.

  [1]: https://datatracker.ietf.org/doc/id/draft-foschiano-erspan-02.txt => Note this is a draft, and I think ERSPAN was not standardized.
  [2]: https://docs.openvswitch.org/en/latest/faq/configuration/
  [3]: http://www.openvswitch.org//support/dist-docs/ovs-fields.7.txt
  [4]: https://github.com/ovn-org/ovn/commit/323f978cbf4599568fcca9edec8ed53c076d2664
  [5]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-service
  [6]: https://docs.openstack.org/api-ref/network/v2/index.html#create-tap-flow

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2015471/+subscriptions