OVN-K: Support SCTP session survivability with OVN service egress traffic steering

1. Proposed title of this feature request
OVN-K: Support SCTP session survivability with OVN service egress traffic steering

2. What is the nature and description of the request?
OVN service egress traffic steering feature that is currently in development addresses the need for certain telco use cases where the source IP of egress traffic originating from the pods backing the service is identical to the destination IP they use to reach them - i.e the LoadBalancer's ingress IP. the node that is selected as the ingress/egress node will SNAT traffic exiting from the pods to the service's ingress IP. In case the node becomes unavailable, OVN-K will detect the node failure and move the EgressIP to a different node and all active TCP/SCTP connections will be reset.

Samsung's request is to maintain the SCTP connection in case of the failure of node with egress IP.

3. Why does the customer need this? (List the business requirements here)
Samsung wants to use MetalLB, however they have one specific use case (S1AP connections - eNB to MME ) where they need two things 1) The ability to ingress on an egress IP (egress traffic steering), and true survivability (no connection reset) for SCTP sessions during failover. Samsung's in-house LB CNLB provides both of these, but comes with other complications for routing and implementation in the cluster.

Samsung is already using their CNLB Load Balancer in production deployments today.

Samsung is exploring if they can use multiple (two) LBs with OCP , i.e use MetalLB as their DEFAULT LB, and use CNLB for the single use case where they need these two features.

4. List any affected packages or components.
OVN-K