Refinement to structure and home page

docs/admin_guide/Ansible/ansible.md

+# Ansible
+
+## Design
+
+## Ansible roles and playbooks
+
+## Troubleshooting
\ No newline at end of file

docs/admin_guide/WFO/iptrunks.md

+# IP trunks
+
+IPtrunks are core links between two GÈANT routers.
+IPtrunk is a special service since on the interfaces at the end of the trunk no VLAN multiplexing is allowed.
+For this reason in case of IPtrunk we do not use the canonical decomposition that leverages demarcation point.
+
+## Modelling and attributes
+
+The relevant attributes for an IPTrunk are the following|
+
+| Attribute name | Attribute type | Description |
+| -------------- | -------------- | ----------- |
+| 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_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_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.|
+|iptrunk_sideA_ae_members| list[str] = Field(default_factory=list)|A list of interface members that make up the aggregated Ethernet interface.|
+|iptrunk_sideA_ae_members_description| list[str] = Field(default_factory=list)|The list of descriptions that describe the list of interface members.|
+|iptrunk_sideB_node| DeviceBlock|The router that hosts the B side of the trunk. It possesses the same attributes as the A-side, including the interfaces and its descriptions.|
+|iptrunk_sideB_ae_iface| str | Same as iptrunk_sideA_ae_iface but for B side|
+|iptrunk_sideB_ae_geant_a_sid| str | Same as iptrunk_sideA_ae_geant_a_sid but for B side |
+|iptrunk_sideB_ae_members| list[str] = Field(default_factory=list) | Same as iptrunk_sideA_ae_members but for B side|
+|iptrunk_sideB_ae_members_description| list[str] = Field(default_factory=list) | Same as iptrunk_sideA_ae_members_description but for B side|
+
+
+## Workflows
+
+### Deployment
+
+This the workflow that brings the subscription from INACTIVE to PROVISIONING and finally to ACTIVE.
+The deployment of a new IPtrunk consist in the following steps:
+
+- Fill the form with the necessary fields:
+    - SID
+    - Type
+    - Speed
+    - Nodes
+    - 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```)
+- 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```
+
+The trunk is deployed with an initial ISIS metric of 9000 to prevent traffic to pass.
+
+
+### Undeployment
+
+This workflow deletes all the configuration related with an IPtrunk from the network and brings the subscription from ACTIVE to TERMINATED.
+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
+    - reference in LLDP protocol (if juniper)
+    - reference in ISIS protocol
+- Delete the IPv4/IPv6 networks from IPAM
+
+
+### Modification
+
+To modify IPtrunks we have 2 different workflows:
+- Modify ISIS metric - modifies protocols/isis/interface
+- Modify Trunk interface - modifies lag interfaces and members. This is used to increase capacity or to change SID/Iface descriptions.
+
+In both cases, the strategy is to re-apply the necessary template to the configuration construct: using a "replace" strategy only the necessary modifications will be applied.
+
+At the time of writing, the deletion of members from an existing IPtrunk is not supported.
+
+
+### Migration
+

docs/admin_guide/WFO/overview.md

+# Diagram
+
+``` mermaid
+classDiagram
+  Site <|-- Router :belong
+
+  class Site{
+    +UUId name
+    +String phoneNumber
+    +String emailAddress
+  }
+
+  class Router{
+    +int studentNumber
+    +int averageMark
+    +isEligibleToEnrol()
+    +getSeminarsTaken()
+  }
+```
\ No newline at end of file

docs/admin_guide/WFO/routers.md

+# Routers

docs/admin_guide/WFO/sites.md

+# Sites
\ No newline at end of file

docs/admin_guide/WFO/wfo.md

+# Workflow Orchestrator
+
+## Modelling and workflows
+
+### [Sites](./sites.md)
+### [Routers](./routers.md)
+### [IPtrunks](./iptrunks.md)
+
+## Maintainance
+
+## Troubleshooting
+

docs/architecture/components/ansible/index.md

+# Ansible
\ No newline at end of file

docs/architecture/components/netbox/index.md

+# Netbox
\ No newline at end of file

docs/architecture/components/wfo/index.md

+# Workflow Orchestrator
\ No newline at end of file

docs/architecture/dtap/acceptance.md

+# Acceptance environment
\ No newline at end of file

docs/architecture/dtap/index.md

+# DTAP Process
\ No newline at end of file

docs/architecture/dtap/production.md

+# Production environment
\ No newline at end of file

docs/architecture/dtap/test.md

+# Test environment

docs/architecture/modeling/index.md

-# Data models
-
-To be able to model network objects, a data model must exist for every configuration item in the network. This allows
-for describing the network, and the services as a composition of abstract objects.
-
-## Decomposition of objects
-
-Every object -- both services and access ports -- is composed of the following building blocks:
-
-* Administrative metadata
-  * Object ID
-  * Status
-  * Owner
-* Configuration data that depends on the specific service, some examples:
-  * Access port
-    * Access port type
-    * Physical interfaces
-  * IP trunk
-    * IPv4 network
-    * IPv6 network
-    * IS-IS metric
-* Placement metadata
-  * Access node
-  * Service delivery point

docs/architecture/modeling/ports.md

-# Services and ports
-
-While a port shouldn't be configured in case there is no service insisting on it, it could happen that more than one
-service is insisting on one port. For this reason, the following entities exist:
-
-SDP
-: Service Delivery Point: the logical interface where a service is delivered
-
-GA
-: Access Port: an access point into the GÉANT network
-
-GP
-: Physical Port: the physical boundary for the GA
-
-GAN
-: Access Node: the node where a service is delivered
-
-These concepts apply to both CFSes and IFSes.
-
-![GÉANT service entities](../../assets/images/access_port_diagram.png)
-
-*A visualisation of how services insist on ports.*
-
-## Peer-to-peer and multipoint services
-
-There is a distinction between services -- as mentioned in [configuration (de)composition](#configuration-decomposition)
--- between peer-to-peer and multipoint services. In both cases, SDP is the delivery point of a service.
-However, for multipoint services customers are supposed to be dual-homed in at least two different GANs.
-
-To give some examples, the figure below shows a decomposition of a GeantIP service for an NREN.
-
-![GeantIP service entities](../../assets/images/geant_ip_ports_diagram.png)
-
-*A visualisation of an instance of a GeantIP service that consists of different configuration objects.*