First theory text about topo inventory and hints towards potential implementation

documentation/design/05-implementation.md

@@ -17,12 +17,14 @@ static process, at least when one considers potential changes over time.
 Typically such network elements are added to a network and they will remain in
 the network for a longer time, i.e., multiple minutes or even longer.
 
-### Topology Inventories
+### Topology Inventory
 
 Every network has one given physical topology (G<sub>physical</sub> ) and on
 top of this at least one logical topology (G<sub>logical1</sub>). There may be
 multiple logical topologies (G<sub>n+1</sub>) on top logical topologies
-(G<sub>n</sub>), i.e., a recursion.
+(G<sub>n</sub>), i.e., a recursion. Such logical topologies (G<sub>n+1</sub>)
+can again have other logical topologies as recursion or other logical topologies
+in parallel.
 
 A topology consists out of interfaces, which are attached to their respective
 network elements, and links between these interfaces.
@@ -33,6 +35,15 @@ the edges.
 
 G<sub>physical</sub> ist a superset of G<sub>logical1</sub>.
 
+The topology inventory has to store the particular graph for any topology and
+also the connections between the different levels of topologies. For instance,
+the G<sub>logical1</sub> is linked to G<sub>physical</sub>. (needs to be clear
+if changes in n-1 graph has impact on n graph).
+
+For further study at this point: Which type of database and implementation of
+databases should be used to store the different topology graphs and their
+pontential dependencies? How should the interface between gosdn and this
+database look like?
 
 ### Potential other Inventories