How should implementations handle backendRef.TargetPort

[robscott]

The relevant part of the Gateway API Spec leaves this rather ambiguous.

Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. In this case, the port number is the service port number, not the target port. For other resources, destination port might be derived from the referent resource or this field.

I think we have 3 options here:

1. HTTPRoute.BackendRef.Port must equal InferencePool.TargetPortNumber
2. HTTPRoute.BackendRef.Port must not be set when the target is InferencePool
3. HTTPRoute.BackendRef.Port must equal InferencePool.TargetPortNumber when set, but can be left unspecified
4. HTTPRoute.BackendRef.Port is always ignored when the target is InferencePool
5. Gateway implementations put a warning on HTTPRoute status when HTTPRoute.BackendRef.Port is set and an InferencePool is targeted, saying that the port will be ignored. Gateway API v1.4 includes validation that prevents BackendRef.Port from being set when the target is an InferencePool.

IMO, 4 is a non-starter as it would result in a great deal of confusion. 1 and 2 are the easiest to implement, and 3 may be the best UX.

Any opinions @danehans, @LiorLieberman, @spencerhance?

[zetxqx]

Are options 1, 2, and 3 all breaking changes for our early adopters? I want to make sure I'm understanding that correctly.

To add some context, in our conformance tests (specifically #911), we're looking at these scenarios:

1. HTTPRoute.BackendRef.Port unspecified
2. HTTPRoute.BackendRef.Port is set and equals to InferencePool.TargetPortNumber
3. HTTPRoute.BackendRef.Port is set and not equal to InferencePool.TargetPortNumber

Right now, both the Istio and GKE Gateway implementations successfully route requests in all these cases. This means HTTPRoute.BackendRef.Port is currently ignored, which aligns with the behavior described in your option 4.

(small nit in the discussion title @robscott, it should be backendRef.Port )

[danehans]

+1 on option 5

[robscott]

I added an option 5 that I think describes what we discussed at the meeting yesterday, does that one make sense to you?

[danehans]

xref kubernetes-sigs/gateway-api#3840 to clarify Port ambiguity.

[nirrozenbaum]

+1 on option 5.
thinking forward, Gateway v1.4 or higher version will be used in the future although it could take time.
would be good to prevent inconsistent behavior or confusion using validation