Add support for custom filters and matchers in TCP/UDPRoute

[aryan9600]

Problem

At the moment, the TCPRoute and UDPRoute APIs are very simple, with the API allowing for only a list of backends to be specified that will receive incoming traffic. In contrast, HTTPRoute offers a plethora of ways to match and modify incoming/outgoing traffic. This is obvious, since HTTP is a L7 protocol and thus has much more data to work with. Since TCP and UDP are L4 protocols, there aren't any obvious ways to provide standardized traffic matchers and filters.

Proposal

But HTTPRoute also allows for custom filters and matchers through the .extensionRef field which points to another object that contains more details about the required operations. We could add the same capability to TCPRoute and UDPRoute. This would allow for implementations to offer their own TCP and UDP traffic extensions, which could then be referred to in a TCPRoute/UDPRoute object.
For example, consider we want to build a custom SSH load balancer. Adding such an extension capability, will then allow redirecting a particular user to a particular backend based on their SSH username. Such behavior is not possible to implement through the existing APIs. Here's a basic example of what this would look like:

apiVersion: ssh.networking.io/v1alpha1
kind: SSHMatch
metadata:
  name: admin-match
spec:
  username: admin
---
apiVersion: ssh.networking.io/v1alpha1
kind: SSHMatch
metadata:
  name: guest-match
spec:
  username: guest

apiVersion: gateway.networking.io/v1alpha2
kind: TCPRoute
metadata:
  name: ssh-route
spec:
  parentRefs:
  - name: metal-lb
  rules:
   - match:
      - type: ExtensionRef
        extensionRef:
            apiVersion: ssh.networking.io/v1alpha1
            kind: SSHMatch
            name: username-match
     backendRefs:
      - name: admin-ssh-svc
        port: 22
   - match:
      - type: ExtensionRef
        extensionRef:
            apiVersion: ssh.networking.io/v1alpha1
            kind: SSHMatch
            name: guest-match
     backendRefs:
      - name: guest-ssh-svc
        port: 22

Since extensions are completely optional, the extensionRef field can be introduced without any friction while enabling implementations to have custom behavior like above.

[shaneutt]

Relates/overlaps with #2618

[candita]

I can see how this would be useful in this example, but I question the use of ExtensionRefs for the implementation. From what I understand, ExtensionRef should be available for custom implementations, not for functionality that we expect to be universally useful. Incorporating a brand-new field would be better. For example, NGINX+ and F5 do TCP/UDP load balancing by grouping backend servers into a resource (upstream group, or origin pools) and applying LB configuration to that resource.

You're probably talking about more than just LB functionality, so in an effort to simplify the requested functionality here, a longer list of use cases would be helpful. There may be more use cases for TCP route than UDP route, as well, so focusing on one at a time could be helpful.

[aryan9600]

ExtensionRef should be available for custom implementations, not for functionality that we expect to be universally useful. Incorporating a brand-new field would be better.

I think there might be a misunderstanding here. I fully agree that extension refs should be available for custom implementations and not for universally useful functionality. But, with TCP and UDP being L4 protocols, its hard to think of functionality that's generic. You can build a SSH load balancer or a DNS load balancer that routes UDP packets based on the domain or record type.
Because of the variety of protocols, its hard to figure out a way to incorporate a brand new field. Extension refs are probably not the best way to enable this, its just the first thought that popped into my head, since the field is already present in other parts of the API. The main goal that I had in my mind is to enable a way for consumers of the TCPRoute/UDPRoute API to let their users configure how traffic is being routed.

[youngnick]

I think at a minimum, having ExtensionRefs available would enable implementations to make a case for why they think that TCPRoute and/or UDPRoute should stick around - #2618 is starting to question their value.

I'd certainly expect that if implementations did add extensions that were or should be commonly available, we would promote those extensions to their own fields (like we have in the HTTPRoute RouteRule.Filters slice with things like RequestHeaderModifier, RequestRedirect, and so on).

[EItanya]

In my opinion this also relates to #2628. In general does the Gateway API want to add extensionRefs/filters to every place that may need extra functionality, or lean into policies or another such mechanism.

[robscott]

This is a very interesting proposal. When I first looked at it, I'd assumed it was analogous to the ExtensionRef filter we already have on HTTPRoute, but this is actually entirely different - a custom matcher... I've got mixed feelings on this. On the one hand, we have no matching logic in either of these routes today (thus #2618), on the other, why included a Route in upstream Gateway API if all of the matching logic is going to be implementation-specific? Would it better to just have an implementation-specific SSHRoute to handle your specific example?

I can see the value in extensions when they augment something significant. For example, HTTPRoute has a lot of capabilities, and some implementations may just want to add one custom filter to the otherwise portable set of capabilities. In the case of TCP/UDPRoute there's not really any substance yet, so I think it's harder to make the case for an ExtensionRef vs just an implementation-specific Route type.