TCP specification question

[ivanmatmati]

Hi,
I would like to ask two questions about Gateway API specification for TCP protocol.

1. The specification says that to determine which route is selected when multiple can apply we should select by these rules:

   • The most specific match as defined by the Route type.
   • The oldest Route based on creation timestamp. For example, a Route with
     a creation timestamp of "2020-09-08 01:02:03" is given precedence over
     a Route with a creation timestamp of "2020-09-08 01:02:04".
   • If everything else is equivalent, the Route appearing first in
     alphabetical order (namespace/name) should be given precedence. For
     example, foo/bar is given precedence over foo/baz.

   Could you explain the rationale behind the timestamp and alphabetical ordering of route ?
   I can think of situations where it could be annoying. For example, if I want to insert a route as first choice considering the creation timestamp criteria I guess I should recreate all routes timely ordered.
   Same with alphabetical ordering which can even be impossible if naming convention is present.

2. Suppose two gateways have each a listener on TCP port 8000. Is it forbidden ? Specification does not say if so but I guess it should be because grouping with TCP seems impossible. Am I missing something ?

[shaneutt]

Could you explain the rationale behind the timestamp and alphabetical ordering of route?

The short answer is that this is the best we had at the time that was met with general consensus by contributors and there hasn't been significant enough pressure since then to change it. Keep in mind the conflict guidance was written in 2020, it is definitely on the table to discuss alternatives and the weekly community sync might be a good place to do that.

Suppose two gateways have each a listener on TCP port 8000. Is it forbidden ? Specification does not say if so but I guess it should be because grouping with TCP seems impossible. Am I missing something?

Do you mean two separate Gateways each with a port 8000 listener on the same address, or could you elaborate on this further please?

[ivanmatmati]

The example would be something like:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: gw1
  namespace: ns1
spec:
  gatewayClassName: gwc
  listeners:
  - name: listener1
    protocol: TCP
    port: 8000
---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: gw2
  namespace: ns2
spec:
  gatewayClassName: gwc
  listeners:
  - name: listener2
    protocol: TCP
    port: 8000

I assume the set of addresses will be the same. We will end up with TCP port 8000 tried to be bound two times on same address(es).
As this is TCP we can't expect path matching, hostname or whatever to differentiate the routing so it seems impossible to group the listeners.
The result for TCP is that it doesn't make sense to permit this submission.
And the following rule only applies to listeners in the same gateway :

• If this field specifies multiple Listeners that have the same Port value but are not compatible, the implementation must raise a "Conflicted" condition in the Listener status.

This rule is laking its interpretation at multiple gateways level. To my eyes the repetition of listener port for gateways should be forbidden for TCP. Without this clarification, it's not clear if an implementation should support this combination or not with TCP.

[shaneutt]

I assume the set of addresses will be the same.

So my main confusion comes from this: Two separate Gateway resources in either of the two implementations of Gateway API that I maintain will not share addresses, they will each get unique ones (usually it's the IP provisioned by a LoadBalancer type Service for them).

[ivanmatmati]

Ok, so I guess that because we can manage Gateway the way we want, we can decide if this is valid or not.

[shaneutt]

If you have multiple Gateway resources sharing addresses, then yes I would assume there's some implementation-specific nuances to deal with that aren't limited only to port sharing. It would be interesting to get a write up of your use case, or for you to talk about it at the community sync, because if there are some key takeaways that provide guidance for the broader group we would want to capture them and add them to our docs. 🤔

[ivanmatmati]

I understand there's three possibilities with multiple gateways. They are depicted in the diagram considering gateway controller is coupled with a dataplane. Other possibilities of controller and dataplane relationship also exist.

• The first case shows when an operator is spinning resources, services and controllers, according to the list of managed gateways.
• The second case shows what I've seen in an implementation where a single gateway is chosen and the remaining are ignored.
• The third case would be ours, I don't want to implement an operator to provide the matching resources according to gateways list and I don't want to skip any gateway.
  

I've imagined this third case for the following reason:

• Any gateway with correct gatewayclass should be processed.
• I'm not sure that the specification when saying

Gateway represents an instance of a service-traffic handling infrastructure by binding Listeners to a set of IP addresses

means there can't be multiple gateways bound to a single dataplane instance.

If these reasons are ok, I guess we can then have multiple listeners with same port from different gateways and that are to be bound on a single instance of dataplane resulting in port conflict.
I though the third case is preferable to skipping some/most gateways even if gatewayclass is ok, because of two reasons:

• Compared to ingress management, no ingress would be discarded if they match the ingressclass.
• Because of previous point, many users would call us because their ignored gateways would be unexpected or even if expected they could be rejected not the way they would prefer.

[shaneutt]

Thanks for the detailed response. Would you have time to bring this up at next monday's community sync so that we can discuss it further there?

[ivanmatmati]

Maybe, I've seen many meetings in the calendar. Which one would be appropriate ?

[ivanmatmati]

Oh, 3pm PST would make 1am for Paris. I guess it will be hard.

[shaneutt]

Gotcha. We have been talking recently about trying to have that meeting alternate times as there have been several european community members who have mentioned our current timing being prohibitive. I'll take another shot at seeing if I can get this changed.

[ivanmatmati]

Yes, would be great. Is there a chance that our discussion can still be presented to the committee ?

[ivanmatmati]

If of any help, our Director of Product will be in Detroit for Kubecon, if convenient you could meet him in person and discuss about the ins and outs of this.

[shaneutt]

Sounds good. We have a 2 hour brick of time and some space on Tuesday for Gateway API related things. Have them check in in #sig-network-gateway-api in Kubernetes slack 👍