chore: rename TrafficMatches->AddressRouteMatches

As per PR review request, multiple reviewiers felt
this was easier to understand naming.

apis/v1alpha2/shared_types.go

@@ -384,9 +384,9 @@ type AnnotationKey string
 // +kubebuilder:validation:MaxLength=4096
 type AnnotationValue string
 
-// TrafficMatches defines AddressMatch rules for inbound traffic according to
+// AddressRouteMatches defines AddressMatch rules for inbound traffic according to
 // source and/or destination address of a packet or connection.
-type TrafficMatches struct {
+type AddressRouteMatches struct {
 	// SourceAddresses indicates the originating (source) network
 	// addresses which are valid for routing traffic.
 	//

apis/v1alpha2/tcproute_types.go

@@ -62,7 +62,7 @@ type TCPRouteRule struct {
 	// Matches are rules for routing traffic to backends based on addresses.
 	//
 	// +optional
-	Matches *TrafficMatches `json:"matches,omitempty"`
+	Matches *AddressRouteMatches `json:"matches,omitempty"`
 
 	// BackendRefs defines the backend(s) where matching requests should be
 	// sent. If unspecified or invalid (refers to a non-existent resource or a

apis/v1alpha2/udproute_types.go

@@ -62,7 +62,7 @@ type UDPRouteRule struct {
 	// Matches add rules for filtering traffic to backends based on addresses.
 	//
 	// +optional
-	Matches *TrafficMatches `json:"matches,omitempty"`
+	Matches *AddressRouteMatches `json:"matches,omitempty"`
 
 	// BackendRefs defines the backend(s) where matching requests should be
 	// sent. If unspecified or invalid (refers to a non-existent resource or a

site-src/geps/gep-735.md

@@ -32,7 +32,7 @@ level of tuning options for L4 traffic routing at a level below the `Gateway`.
 The API changes include the following new types:
 
 - `AddressMatch` to indicate the IP for address matching
-- `TrafficMatches` to configure matching according to network address
+- `AddressRouteMatches` to configure matching according to network address
 
 These types enable the address matching required, with some active
 considerations about how to leave these open ended for later expansion.
@@ -78,13 +78,13 @@ type AddressMatch struct {
 }
 ```
 
-### TrafficMatches Type
+### AddressRouteMatches Type
 
 Using the new `AddressMatch` type matches can be expressed in topical lists on
-`TCPRoute` and `UDPRoute` using the new `TrafficMatches` type:
+`TCPRoute` and `UDPRoute` using the new `AddressRouteMatches` type:
 
 ```go
-type TrafficMatches struct {
+type AddressRouteMatches struct {
 	// SourceAddresses indicates the originating (source) network
 	// addresses which are valid for routing traffic.
 	//
@@ -100,17 +100,21 @@ type TrafficMatches struct {
 ```
 
 This type becomes an optional field and shared by both `TCPRouteRule` and
-`UDPRouteRule`:
+`UDPRouteRule` as a list:
 
 ```go
 type TCPRouteRule struct {
 	// Matches add rules for filtering traffic to backends based on addresses.
 	//
 	// +optional
-	Matches *TrafficMatches `json:"matches,omitempty"`
+	Matches []AddressRouteMatches `json:"matches,omitempty"`
 }
 ```
 
+Each element in `[]AddressRouteMatches` should be implemented as an `OR` style
+match (e.g. the inbound traffic matches as long as at least one of the separate
+`AddressRouteMatches` rules is matched).
+
 The above would make the following YAML examples possible:
 
 ```yaml