😊 Welcome @electricjesus! This is either your first contribution to the Istio istio repo, or it's been
a while since you've been here.

You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

• ❌ - login: @electricjesus / name: Seth Malaki . The commit (6c88a39) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

Hi @electricjesus. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Hi all! this is still a draft. We're still working on a few things related to this here over at ProjectCalico.

Introduces DSCPMagicMark constant (0x17) and adds iptables rule to redirect TCP packets with matching DSCP mark to ztunnel inbound port (15008).

What’s the exact use case here? If there’s a design doc or any background info on why we are planning to add a DSCP mark to the traffic, could someone share it?

Introduces DSCPMagicMark constant (0x17) and adds iptables rule to redirect TCP packets with matching DSCP mark to ztunnel inbound port (15008).

What’s the exact use case here? If there’s a design doc or any background info on why we are planning to add a DSCP mark to the traffic, could someone share it?

The use case is most likely the fact that ztunnel using dst port 15008 and not the original dst port and this interfers with other network plugins network policy especially in the case of L4 enforcement (L5 is a different story). Since the dst port is no longer 15008, nothing will receive on the ztunnel inbound listener socket, so the change is using iptables Redirect action to do this and use the get original dst sock opt to get the original 5 tuple. istio isn't a full network plugin and relies on the calico, ciliums, or whoever to provide the pod networking. That at least is use case/background that I have (we have already POC'd this a couple months ago). This isn't enabled by default as well which means the user would need to enable this. However the design document to iron out the design decisions would be helpful :-) I am also curious if that document has any throughput/latency metrics.