[RFE] Does not support ipv6 N-S qos

Bug #1787792 reported by Na Zhu on 2018-08-19
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Wishlist
Unassigned

Bug Description

The N-S bandwidth is alwawys limited of data center, so it is common use case to limit N-S bandwidth of tenant.
For ipv4, there is floatingip, we can limit N-S bandwidth by floatingip qos, but for ipv6, the address is enough so no need NAT any more. In this way, we can not do N-S bandwidth for ipv6, I think we should find a way to fix it.

PS, the port qos limit both E-W and N-S bandwidth, not a good chice.

Slawek Kaplonski (slaweq) wrote :

That would IMO require to implement classful bandwidth limits but as for now I don't think we have resources to implement that.
If You would like to work on that - it would be great. I can of course help You with that as much as it will be possible.
We have Neutron QoS meetings on IRC every second Tuesday (http://eavesdrop.openstack.org/#Neutron_QoS_Meeting) - if You have any questions or You wants to discuss that, You are welcome :)

Hongbin Lu (hongbin.lu) on 2018-08-22
summary: - Does not support ipv6 N-S qos
+ [RFE] Does not support ipv6 N-S qos
tags: added: rfe
Miguel Lavalle (minsel) wrote :

Let's discuss first in the QoS meeting of next week. After that we can bring it up to the drivers meeting

Changed in neutron:
importance: Undecided → Wishlist
tags: added: rfe-confirmed
removed: rfe
zhaobo (zhaobo6) wrote :

Ha, I ask yulong, he has no plan to support this, ;-(. So I think we should treat it as a total new feature. ;-). Gogogo, fight for neutron. ;-)

zhaobo (zhaobo6) wrote :

@Slawek Kaplonski, totally agree with you, the current qos bw should be more classified. As I think the current tc-wrapper is too specific for very limite use cases. We should refact it, I think.

Slawek Kaplonski (slaweq) wrote :

@zhaobo: yes, I agree that it will have to be changed. Also in case of QoS for vpnaas it will require some changes and support for classful rules in tc. So that should help :)

LIU Yulong (dragon889) wrote :

During the qos meeting, ipv6 traffic control need some validation.
So here is my testing, the following rules can be successfully installed to the host:
tc filter add dev bond1 parent 1: protocol ipv6 prio 1 u32 match ip6 src fe80::fc16:3eff:fe2a:d740 flowid 1:10
tc filter add dev bond1 parent 1: protocol ipv6 prio 1 u32 match ip6 src fe80::fc16:3eff:fe57:d2c5 flowid 1:11

The testing ENV,
kernal version: 3.10.0-514.26.2.el7.x86_64
iproute-3.10.0-74.el7.x86_64

Miguel Lavalle (minsel) wrote :

This topic has been scheduled for discussion during the Denver PTG on Friday 14th at 10:45: https://etherpad.openstack.org/p/neutron-stein-ptg

Slawek Kaplonski (slaweq) wrote :

As discussed on PTG next steps can be:
1. Investigate how we can use Common Classifier Framework to associate QoS rules with some classifiers and apply it then only for specific class of traffic - then it will be able to use it for BW limit on FIP and on L2 port levels as well as for e.g. DSCP marking rules and other things,
2. Make some PoC of such solution or maybe find if there are other ways to do something like that,
3. In case of VPN QoS we will also have to implement some support for classful bw limits in tc driver so it may be reused in case of this RFE also.

Both in LB and OVS, you have QoS support in both directions (egress and ingress). Of course, the QoS rule is applied at L2 (no IP classification). The QoS policies are applied in the compute node, relieving the network node from applying those QoS policies and reducing the network traffic in the OpenStack cluster.

A VM usually have one external IP (IPv4 FIP or IPv6). Just applying L2 QoS in the compute node could be enough to shape the traffic.

Let me ask you, just to understand better the context of this RFE. Why do you need specifically IPv6 QoS? What are the use cases? Having a set of use cases could increase the goal of this RFE.

If IPv6 doesn't go trough a NAT router (as you pointed out, is not like IPv4 FIP), are you proposing to introduce L3 classification in the current QoS implementation? Let me rephrase this: currently the QoS rules applied to the VM ports or interfaces (depending on the back-end), are only for the ML2 QoS extension. If we combine IPv6 L3 QoS and ML2 QoS in the same interfaces, we need to be very careful on how we manage those rules.

Miguel Lavalle (minsel) on 2019-06-13
tags: added: rfe-postponed
removed: rfe-confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers