Fixes based on review

Signed-off-by: Lionel Jouin <lionel.jouin@est.tech>

keps/sig-network/4770-endpointslice-controller-flexibility/README.md

@@ -68,7 +68,7 @@ Additionally, this KEP aims to give more flexibility for the EndpointSlice Recon
 
 As of now, a service can be delegated to a custom Service-Proxy/Gateway if the label `service.kubernetes.io/service-proxy-name` is set. Introduced in [KEP-2447](https://github.com/kubernetes/enhancements/issues/2447), this allows custom Service-Proxies/Gateways to implement services in different ways to address different purpose / use-cases. However, the EndpointSlices attached to this service will still be reconciled in the same way as any other service. Addressing more purpose / use-cases, for example, different pod IP addresses, is therefore not natively possible.
 
-Delegating EndpointSlice control would allow custom controllers to define their own criterias for pod availability, selecting different pod IPs than the pod.status.PodIPs and more. As reference implementation, and since [KEP-3685](https://github.com/kubernetes/enhancements/issues/3685), the reconciler logic used by Kubernetes can be reused by custom EndpointSlice controllers.
+Delegating EndpointSlice control would allow custom controllers to define their own criteria for pod availability, selecting different pod IPs than the pod.status.PodIPs and more. As a reference implementation, and since [KEP-3685](https://github.com/kubernetes/enhancements/issues/3685), the reconciler logic used by Kubernetes can be reused by custom EndpointSlice controllers.
 
 Providing a generic EndpointSlice Reconciler module would allow users to reuse the same code as the Kubernetes EndpointSlice Controller, thus ensuring consistency and reducing the effort needed to implement custom reconciliation logic. As highlighted in this [comment](https://github.com/kubernetes/kubernetes/pull/118953#discussion_r1245970845), the EndpointSlice Mirroring Controller would also benefit from these changes since the generic EndpointSlice Reconciler could be used from the EndpointSlice Mirroring Controller.
 
@@ -82,6 +82,7 @@ Providing a generic EndpointSlice Reconciler module would allow users to reuse t
 * Change / Replace / Deprecate the existing behavior of the Kubernetes EndpointSlice controller.
 * Introduce additional supported types of the EndpointSlice controllers/Reconciler as part of Kubernetes.
 * Modify the Service / EndpointSlice Specs.
+* Add new features to the EndpointSlice Mirroring Controller.
 
 ## Proposal
 
@@ -91,7 +92,7 @@ Providing a generic EndpointSlice Reconciler module would allow users to reuse t
 
 #### Flexibility on the EndpointSlice Reconciler Module
 
-The reconciler structure will support more features to cover the requirements set by the current behavior of the EndpointSlice Mirroring Controller (e.g.: placeholder concept does not exist in the Mirroring Controller).
+The reconciler structure will support more features to cover the requirements set by the current behavior of the EndpointSlice Mirroring Controller (e.g.: placeholder EndpointSlice does not exist in the Mirroring Controller).
 
 The `Reconcile` function definition will be changed to accept general types of data (not specific to Services) and the list of features the endpointslices being reconciled will support (e.g. Traffic Distribution). Functions for specific types (Service/Pods for the EndpointSlice Controller and Endpoints for the EndpointSlice Mirroring Controller) generating data to pass to the `Reconcile` function will be provided by the EndpointSlice Reconciler module.
 
@@ -105,20 +106,22 @@ Finally, the EndpointSlice Mirroring reconciler will be discarded from `pkg/cont
 
 #### Story 1
 
-As a Cloud Native Network Function (CNF) vendor, some of my services are handled by custom Service-Proxies/Gateways over secondary networks provided by, for example, [Multus](https://github.com/k8snetworkplumbingwg/multus-cni). IPs configured in the service and registered by the EndpointSlice controller must be only the secondary IPs provided by the secondary network provider (e.g. [Multus](https://github.com/k8snetworkplumbingwg/multus-cni), also see [KEP-3698](https://github.com/kubernetes/enhancements/issues/3698)).
+As a Cloud Native Network Function (CNF) vendor, some of my services are handled by custom Service-Proxies/Gateways over secondary networks provided by, for example, [Multus](https://github.com/k8snetworkplumbingwg/multus-cni). IPs configured in the service and registered by the EndpointSlice controller must be only the secondary IPs provided by the secondary network provider (e.g. [Multus](https://github.com/k8snetworkplumbingwg/multus-cni)).
 
-Therefore, it must be possible to disable the default Kubernetes EndpointSlice Controller for certain services and re-use the Kubernetes EndpointSlice reconciler implementation to create a controller for secondary network providers.
+Therefore, it must be possible to disable the default Kubernetes Endpoints and EndpointSlice Controller for certain services and re-use the Kubernetes EndpointSlice reconciler implementation to create a controller for secondary network providers.
 
 ### Notes/Constraints/Caveats (Optional)
 
 N/A
 
 ### Risks and Mitigations
 
-The existing behavior will be kept by default, and the Kubernetes EndpointSlice Controller will be disabled only when the service contains this new label. This ensures services without the label to continue to be managed as usual.
+The existing behavior will be kept by default, and the Kubernetes EndpointSlice Controller will not manage the Services with the label. This ensures services without the label to continue to be managed as usual.
 
 This will have no effect on other EndpointSlice controller implementations since they will not be influenced by the presence of this label.
 
+To avoid protential new functionalities to leak into other controllers re-using the EndpointSlice Reconciler (for example, the EndpointSlice Mirroring Controller), new functionnalities must be optional if possible.
+
 ## Design Details
 
 ### Well-Known Label
@@ -127,6 +130,8 @@ The kube-controller-manager should pass to the Endpoints, EndpointSlice and Endp
 
 ### Flexibility on the EndpointSlice Reconciler Module
 
+The current behavior of the EndpointSlice Reconciler if a service exists but does not have any endpoint behind, is to create an placeholder EndpointSlice for that service. The placeholder EndpointSlice will have no endpoints and no ports. If the service is dualstack, then 2 placeholder EndpointSlices will be created, one for each IP Family (IPv4 and IPv6).
+
 New fields will be added to the `Reconciler` struct to cover the needs of the EndpointSlice and EndpointSlice Mirroring Controllers. Unlike the EndpointSlice Mirroring Controller, the EndpointSlice Controller needs placeholders if a service does not contain any endpoint. So a boolean `placeholderEnabled` will be added. The EndpointSlice Mirroring Controller does not verify which resource owns the EndpointSlice before Updating/Deleting it, another boolean `ownershipEnforced` would control this.
 
 #### Reconciler 
@@ -285,8 +290,8 @@ TDB
 ##### e2e tests
 
 - Usage of `service.kubernetes.io/endpoint-controller-name` on services
-    * A service is created with the label and the service has then no endpoints.
-    * A service is created without the label, the service has endpoints. Then service is updated with the label and the service has no longer any endpoints.
+    * A service is created with the label and the service has then no endpoints neither endpointslices. Then service is updated removing the label and the service has now endpoints and endpointslices.
+    * A service is created without the label, the service has endpoints and endpointslices. Then service is updated with the label and the service has no longer any endpoints nor endpointslices.
 
 ### Graduation Criteria