k8snetworkplumbingwg / multi-networkpolicy-tc Goto Github PK

What would you like to be added?

Manage SimpleTCGenerator priority in a more explicit manner.

currently we have a base prio for each of the default/pass/drop prios and we use offsets throughout to derive the correct prio for the protocol.

we should have a mapping from protocol to prio as part of the generator implementation and just use that throughout.

In addition, genFilters logic should be split and simplified. it is getting way too long.

What is the use case for this feature / enhancement?

What would you like to be added?

Currently our Generator implementation (SimpleTCGenerator) Generates TC filters for all supported protocols

• ipv4
• ipv6
• VLAN ipv4
• VLAN ipv6
• QinQ ipv4
• QinQ ipv6

We should look into how to reduce the number of filters generated for a given Rule.

some thoughts

• if bridge is not in QinQ mode, should we generate QinQ related filters ? (need to check bridge behaves in this case) - as we only support accelerated bridge CNI ATM.
• should we limit VLAN/QinQ related filters to rules that originate from IPBlock only ?
• a more static approach: config knobs which determines the protocols that multi-network-policy-tc will handle (enforce for only what is specified)

What would you like to be added?

Currently some Flower filter attributes are general strings. while in some places it might make sense (e.g dst IP or port)
in others it may be desirable to define a typed strings to avoid usage issue.

e.g vlanEthType, IPProto

What is the use case for this feature / enhancement?

reduce chance of developer error.

We would like to release initial version of multi-networkpolicy-tc.

Limitations of initial release:

• MultiNetworkPolicy Ingress rules are not supported. Ingress policy will not be enforced
• QinQ traffic is not supported network policy will not be enforced

What happened?

Job is failing. see: https://github.com/k8snetworkplumbingwg/multi-networkpolicy-tc/actions/runs/4123969381/jobs/7122712710

What did you expect to happen?

Job needs to pass so latest tag (which is a manifest) is updated properly

What are the minimal steps needed to reproduce the bug?

run the job / merge a PR :)