KEP 1645: add more conflict condition on asymetrical traffic

[MrFreezeex]

• One-line PR description: add more conflict condition on asymetrical traffic

• Issue link: Multi-Cluster Services API #1645

• Other comments:

Make ports raise a conflict when it's not a exact match and a note describing that implementation must not redirect traffic to endpoints from services that actually doesn't declare this port.

Also suggest doing the same for IPFamilies which might have asymmetrical issues. It's merely a suggestion as IPfamilies handling are implementation defined and some implementation may not have issues like that.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: MrFreezeex
Once this PR has been reviewed and has the lgtm label, please assign jeremyot for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• keps/sig-multicluster/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mikemorris]

Suggested approach makes sense to me and feels less disruptive than changing the guidance from union to intersection.

/lgtm

[zhiying-lin]

LGTM, thank you Arthur!

[lauralorenz]

In sentence for how IPFamilies should be handled above, its directed that the implementer "may" raise a conflict, while this one I'm commenting on here which is for ports says they "will". This line about ports is also more strict on what must be done for routing ("must be directed only") vs how it is described above for IPFamilies ("might result in network traffic reaching only a subset"). Is the difference in how these are treated on purpose? Based on what I saw from the notes from when we discussed in SIG-MC (ref) I think they should both mandate that the conflict raise should be required but how the implementation routes should be implementation defined.

[MrFreezeex]

Ah yes indeed, I used "may" for IPFamilies because the exact handling is all implementation defined but since there is a "when" in the sentence which may not apply to some implementations it seems fine to change the "may" by a "must" and some implementations won't need to care about that at all. We would most likely not be able to check that in the conformance tests though but that's a separate concerns from the KEP anyway!

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.