Update documentation structure

New structure and folders, integrated some of the contents previously lost.

docs/admin_guide/WFO/iptrunks.md

@@ -13,11 +13,11 @@ The relevant attributes for an IPTrunk are the following|
 | geant_s_sid| String | GÉANT service ID associated with this trunk. |
 |iptrunk_description| str |A human-readable description of this trunk.|
 |iptrunk_type| IptrunkType|The type of trunk, can be either dark fibre or leased capacity.|
-|iptrunk_speed| str  # FIXME| should be of PhyPortCapacity typeThe speed of the trunk, measured per interface associated with it.|
+|iptrunk_speed| str | should be of PhyPortCapacity typeThe speed of the trunk, measured per interface associated with it.|
 |iptrunk_minimum_links| int|The minimum amount of links the trunk should consist of.|
 |iptrunk_isis_metric| int|The IS-IS metric of this link|
-|iptrunk_ipv4_network| ipaddress.IPv4Network|The IPv4 network used for this trunk.|
-|iptrunk_ipv6_network| ipaddress.IPv6Network|The IPv6 network used for this trunk.|
+|iptrunk_ipv4_network| IPv4Network|The IPv4 network used for this trunk.|
+|iptrunk_ipv6_network| IPv6Network|The IPv6 network used for this trunk.|
 |iptrunk_sideA_node| DeviceBlock|The router that hosts the A side of the trunk.|
 |iptrunk_sideA_ae_iface| str|The name of the interface on which the trunk connects.|
 |iptrunk_sideA_ae_geant_a_sid| str|The service ID of the interface.|
@@ -45,8 +45,8 @@ The deployment of a new IPtrunk consist in the following steps:
     - LAG interfaces with description
     - LAG members with description
 - WFO will query IPAM to retrieve the IPv4/IPv6 Networks necessary for the trunk. The container to use is specified in ```oss-params.json```
-- The configuration necessary to deploy the LAG is generated and applied to the destination nodes using the ansible playbook ```iptrunks.yaml``` This is done first in a dry mode (without committing) and then in a real mode committing the configuration. The commit message contains the subscription_id and the process_id. Included in this there is also the configuration necessary to enable LLDP on the physical interfaces.
-- Once the LAG interface is deployed, another ansible playbook is called to verify that IP traffic can actually flow over the trunk ( ```iptrunk_checks.yaml```)
+- The configuration necessary to deploy the LAG is generated and applied to the destination nodes using the Ansible playbook ```iptrunks.yaml``` This is done first in a dry mode (without committing) and then in a real mode committing the configuration. The commit message contains the subscription_id and the process_id. Included in this there is also the configuration necessary to enable LLDP on the physical interfaces.
+- Once the LAG interface is deployed, another Ansible playbook is called to verify that IP traffic can actually flow over the trunk ( ```iptrunk_checks.yaml```)
 - Once the check is passed, the ISIS configuration will take place using the same ```iptrunks.yaml```. Also in this case first there is a dry run and then a commit.
 - After this step the ISIS adjacency gets checked using again ```iptrunks_checks.yaml```
 
@@ -59,7 +59,7 @@ This workflow deletes all the configuration related with an IPtrunk from the net
 The steps are the following:
 - Modify the ISIS metric of the trunks so to evaquate traffic - and wait confirmation from an operator.
 - Delete all the configuration (first dry then actual deletion):
-    - LAG anf members of the LAG
+    - LAG and members of the LAG
     - reference in LLDP protocol (if juniper)
     - reference in ISIS protocol
 - Delete the IPv4/IPv6 networks from IPAM