Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider holding GEP 735 for a future release (after v0.5.0) #1127

Closed
robscott opened this issue Apr 25, 2022 · 3 comments · Fixed by #1139
Closed

Consider holding GEP 735 for a future release (after v0.5.0) #1127

robscott opened this issue Apr 25, 2022 · 3 comments · Fixed by #1139
Labels
api-review Categorizes an issue or PR as actively needing an API review. kind/gep PRs related to Gateway Enhancement Proposal(GEP)
Milestone

Comments

@robscott
Copy link
Member

As discussed in today's community meeting, API Review on v0.5.0 has raised some good questions about address matching. I've tried to answer some of them, but have realized that others will require more significant thought/changes. Here are some of the questions discussed in today's meeting:

  1. Does source address matching act purely as a matching mechanism or is it more of a firewall?
  2. How does merging and conflict resolution work?
  3. Would Gateway be a more natural place for firewall config?
  4. What are primary use cases for dest address matching? I think it's likely mesh + egress implementations, but if so, we should more clearly define how that would work. Does it make sense for traffic flowing through an ingress Gateway?
  5. More broadly, if these concepts don't make sense in TCPRoute, what does?

So at this point I think we may have more questions than answers, and it might make the most sense to leave this for a later release once we've had some time to spend more time answering these kinds of questions. Open to what others think here.

@robscott robscott added api-review Categorizes an issue or PR as actively needing an API review. kind/gep PRs related to Gateway Enhancement Proposal(GEP) labels Apr 25, 2022
@robscott robscott added this to the v1beta1 milestone Apr 25, 2022
@youngnick
Copy link
Contributor

I am +1 to holding this until we have another look at the design.

@markmc
Copy link
Contributor

markmc commented May 3, 2022

+1

For reference, there's a good discussion of the challenge captured in the April 25, 2022 Gateway API meeting. Points include that the use cases and behavior are underspecified and not well understood.

But, in particular, I found the discussion of "is this routing or a firewall?" and "should this be part of the gateway rather than the route?" raises some good questions about whether a fundamentally different design could be more appropriate, depending on the use case. For example, we could decide that definining a "company-internal" vs "public" interfaces could be a cluster operator's responsibility (e.g. by defining different listeners on a gateway, perhaps with source/destination address based rules) and the application developer then just needs to attach their routes to the appropriate listener.

@candita
Copy link
Contributor

candita commented May 11, 2022

Is source IP address persistence/stickiness a consideration?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-review Categorizes an issue or PR as actively needing an API review. kind/gep PRs related to Gateway Enhancement Proposal(GEP)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants