diff --git a/doc/SWITCH.md b/doc/SWITCH.md
index 44c317e0b..710fe2ab2 100644
--- a/doc/SWITCH.md
+++ b/doc/SWITCH.md
@@ -5,11 +5,12 @@
 The switch brick is a brick doing what does a switch do in "real life" as described [here](https://en.wikipedia.org/wiki/Network_switch).<br>
 The core feature being that when we receive an incoming packet, trying to reach a mac address, there's two cases:
 
-* We know on which interface we can find it and so we forward it so.
+* We know on which interface we can find it and so we forward it directly through the right interface..
 
 * We don't know where is the packet's destination so we broadcast it on all interfaces. Then, once we get the answer, we update the MAC TABLE linking MAC address with INTERFACES. So the next time we will know where to forward the packet.
 
-Another thing is the forget feature: if a line in the mac table hasn't been used since a long time, we forget it!
+Another thing is the forget feature: if a line in the mac table hasn't been used since a long time, we forget it!<br>
+However it is not working yet!
 
 ## Basic example: connect 3 VMs to a NIC.
 
@@ -40,3 +41,7 @@ Note: it's always a good practice to link at one side all "subnet" devices and t
 Here is the reason:<br>
 Basically, if we heve a brick modifying packets such as VTEP or VXLAN, we should isolate it on a side. In fact, to manage packets faster, we do not copy them so be careful to do not modify them! They would be modified for all bricks on this side.<br>
 Please refer to the [warning section of the brick concept's overview](BRICK_CONCEPT.md) for more informations.
+
+## Let's go deeper into the MAC TABLE.
+
+wip