[WIP] Update EVPN-GW API Readme

Signed-off-by: Dimitrios Markou <dimitrios.markou@est.tech>

network/evpn-gw/README.md

@@ -12,9 +12,48 @@ The EVPN Gateway API in the Kubernetes context is used for network provisioning
 
 The API works on four object classes: VRF (Virtual Routing Funtions), SVI (Switched Virtual Interface), LogicalBridge and BridgePort. Their relationship is illustrated in the API data model below.
 
-<p align="center">
-  <img width="500" height="400" src="./images/data-model-evpn-gw-api.png">
-</p>
+```mermaid
+erDiagram
+    LogicalBridge }|..o{ BridgePort : ""
+    LogicalBridge ||..o| SVI: ""
+    SVI }o..|| VRF: ""
+    LogicalBridge ||..o| L2-EVPN : ""
+    VRF ||..o| L3-EVPN : ""
+    LogicalBridge{
+        string name
+        uint vlan_id[key]
+        uint vni[optional]
+    }
+    BridgePort{
+        string name
+        uint vport_id[key]
+        string mac_adrress
+        PortType ptype
+        List vlan_id
+    }
+    VRF{
+        string name[key]
+        uint vni[optional]
+        uint routing_table
+        string loopback_ip
+        string vtep_ip[optional]
+    }
+     L3-EVPN{
+        uint rd
+        string rmac
+        uint route_target
+    }
+    L2-EVPN{
+        uint rd
+        uint route_target
+    }
+    SVI{
+      uint vrf[key]
+      uint vlan_id[key]
+      string mac_adress
+      List gw_ip
+    }
+```
 
 The following objects are managed though the xPU EVPN Gateway API
 
@@ -41,3 +80,13 @@ The following objects are managed though the xPU EVPN Gateway API
     A VRF can optionally be associated with an L3-EVPN instance to provide L3 connectivity to external nodes. In that case the specified VNI value is used as import/export route target (RTs) in EVPN BGP as well as in the VXLAN encapsulation of the tunneled L3-VPN traffic. The VRF loopback IP address is used as basis for the EVPN route distinguisher (RD).
 
     The EVPN GW advertises the VRF loopback IP and the subnet prefixes of the connected SVI interfaces as VPN routes to attract traffic. VPN routes imported from BGP are reachable from locally connected BridgePorts.
+
+    ## EVPN GW offload - Target Architecture
+
+    In the image below is depicted the graphical representation of the target architecture.
+
+    At the top is the single server host which is running a standard Kubernetes system. This consists of the Kubernetes control plane with Kubelet, standard primary networking realized by Calico cni and kube-proxy. Both Calico cni and kube-proxy are relying on Linux routing and IP tables for providing primary networking locally on that host. Subsequently for external connectivity the host is connected through a primary virtual function (VF) to the xPU.
+
+    On top of that in order to accelerate secondary networking a secondary cni (xpu cni) plums in VFs as secondary network interfaces into Kubernetes Pods which are consumed as standard SR-IOV VFs.
+
+    ![evpn gw offload - target architecture](./images/evpn-gw-offload-target-arch.png)