Bug 1652192 - [Doc-Bug] [RFE] RHOSP14-OpenDaylight - Steps to validate VXLAN DSCP inheritance in OpenDaylgiht Integration
Summary: [Doc-Bug] [RFE] RHOSP14-OpenDaylight - Steps to validate VXLAN DSCP inheritan...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 14.0 (Rocky)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Documentation Team
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-21 16:29 UTC by Pradipta Kumar Sahoo
Modified: 2019-03-06 16:17 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-06 16:16:24 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Pradipta Kumar Sahoo 2018-11-21 16:29:44 UTC
Description of problem:
As per RHOSP14 release doc, in OpenDaylight VXLAN DSCP (Differentiated Services Code Point) inheritance is supported which means ODL netvirt table has extended with QOS policy for QOS_DSCP data model.

Netvirt Table ID:
90: QOS_DSCP

Version-Release number of selected component (if applicable):
Red Hat OpenStack 14
OpenDaylight Oxygen

Currently, RHOSP14 Opendaylight document has updated with odl-dscp-marking-inheritance.yaml integration steps for OVS-DPDK, SRIOV, and L2GW.

In addition, the document needs to include below the VXLAN DSCP section for better understanding of the tech preview features.

Below scenario should include.
- In Director based deployement the steps to need follow to include QOS service plugin for Neutron and configuration details.
- Steps to validate VXLAN DSCP in OpenDaylight and neutron end.
- If is there any DSCP limitation in NFV scenario w.r.t OVS-DPDK and SRIOV, need to include.


Additional Info:
Reference Upstream doc: https://docs.opendaylight.org/projects/netvirt/en/stable-oxygen/specs/qos.html

Comment 2 Mike Kolesnik 2018-11-22 13:50:15 UTC
(In reply to Pradipta Kumar Sahoo from comment #0)
> Description of problem:
> As per RHOSP14 release doc, in OpenDaylight VXLAN DSCP (Differentiated
> Services Code Point) inheritance is supported which means ODL netvirt table
> has extended with QOS policy for QOS_DSCP data model.
> 
> Netvirt Table ID:
> 90: QOS_DSCP
> 
> Version-Release number of selected component (if applicable):
> Red Hat OpenStack 14
> OpenDaylight Oxygen

As explained in bug 1652428 this is only for DSCP inheritance and doesn't guarantee that Neutron QoS is supported.

> 
> Currently, RHOSP14 Opendaylight document has updated with
> odl-dscp-marking-inheritance.yaml integration steps for OVS-DPDK, SRIOV, and
> L2GW.
> 
> In addition, the document needs to include below the VXLAN DSCP section for
> better understanding of the tech preview features.
> 
> Below scenario should include.
> - In Director based deployement the steps to need follow to include QOS
> service plugin for Neutron and configuration details.

Not supported yet, planned to be in Bug 1329358 

> - Steps to validate VXLAN DSCP in OpenDaylight and neutron end.
> - If is there any DSCP limitation in NFV scenario w.r.t OVS-DPDK and SRIOV,
> need to include.

Not sure what you mean in these 2..

> 
> 
> Additional Info:
> Reference Upstream doc:
> https://docs.opendaylight.org/projects/netvirt/en/stable-oxygen/specs/qos.
> html

Comment 3 Pradipta Kumar Sahoo 2018-12-20 13:51:05 UTC
Hi Mike,

Thank you for the update. It looks like DSCP inheritance is associated with Netvirt flow table. Please do correct me if I am wrong. Since this is a tech preview feature doesn't guarantee that Neutron QoS is supported. But would it possible to include ODL DSCP inheritance validation steps after the OSP deployment which helps to ensure that the DSCP inheritance install.

Regards,
Pradipta

Comment 4 Mike Kolesnik 2018-12-23 09:58:37 UTC
@Tim porbably knows better than me

Comment 5 Tim Rozet 2019-01-03 21:06:12 UTC
The DSCP inheritance is not a flow based mechanism, it is actually configured on the tunnel itself as a TOS option:

options : tos: optional string
Optional The value of the ToS bits to be set on the encapsulating packet ToS is interpreted as DSCP and ECN bits, ECN part must be zero It may also be the word inherit, in which case the ToS will be copied from the inner packet if it is IPv4 or IPv6 (otherwise it will be 0) The ECN fields are always inherited Default is 0

I believe you should be able to see it configured on the tunnel itself doing a ovs-vsctl show.

Comment 8 Pradipta Kumar Sahoo 2019-01-06 04:13:18 UTC
Hi,

We will resume the documentation BZ once we validate the steps in parent Bug: 1663648

-- Pradipta

Comment 9 Franck Baudin 2019-03-06 16:16:24 UTC
As per depreciation notice [1], closing this bug. Please reopen if relevant for RHOSP13, as this is the only version shipping ODL.

[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14/html-single/release_notes/index#deprecated_functionality

Comment 10 Franck Baudin 2019-03-06 16:17:43 UTC
As per depreciation notice [1], closing this bug. Please reopen if relevant for RHOSP13, as this is the only version shipping ODL.

[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14/html-single/release_notes/index#deprecated_functionality


Note You need to log in before you can comment on or make changes to this bug.