diff --git a/docs/installation_guide.md b/docs/installation_guide.md
index 3cfad1c..dab486c 100644
--- a/docs/installation_guide.md
+++ b/docs/installation_guide.md
@@ -17,12 +17,15 @@
 The hardware listed is needed for each POD.
 
 * Everything listed in the BOM of a generic CORD POD
-**WARNING** Currently E-CORD does not support more than 1 fabric switch per POD. While soon will be possible to use more than one fabric switch, it is useless now to buy more than a fabric switch per local site.
+
+**WARNING** Currently E-CORD does not support more than 1 fabric switch per 
+POD. While soon will be possible to use more than one fabric switch, it is useless now to buy more than a fabric switch per local site.
+
 * 1x Centec v350, used as “Ethernet Edge switch”
 * 1x CPE, composed by
     * 1x 2-port TP-Link Gigabit SFP Media converter, model MC220L(UN)
     * 1x Microsemi EA1000 programmable SFP
-    * 1x fiber cable (or DAC) to connect the CPE to the Ethernet Edge switch
+* 1x fiber cable (or DAC) to connect the CPE to the Ethernet Edge switch
 * 1x 40G to 4x10G  QSFP+ module to connect the Ethernet Edge switch to the access leaf fabric switch (EdgeCore QSFP to 4x SFP+ DAC, model ET6402-10DAC-3M, part M0OEC6402T06Z)
  
 **NOTE**: The role of the CPE is to get users’ traffic, tag it with a VLAN id, and forward it to the Ethernet Edge switch. Additionally, the CPE sends and receives OAM probes to let CORD monitor the status of the network. For lab trials, a combination of two components has been used to emulate the CPE functionalities: a media converter, used to collect users’ traffic from an Ethernet CAT5/6 interface (where a traditional host, like a laptop, is connected) and send it out from its other SFP interface; a programmable SFP (plugged into the SFP port of the media converter), that a) tags the traffic with a specific VLAN id and forwards it to the Ethernet Edge switch; b) sends and receives OEM probes to let CORD monitor the network. The programmable SFP is currently configured through NETCONF, using the ONOS Flow Rule abstraction translated into NETCONF XML for the drivers, and the ONOS-based CarrierEthernet application to generate the Flow Rules based on requests.