From 91c194ba14320e5d11f99aed1a39c08016f23b36 Mon Sep 17 00:00:00 2001 From: Martin Stiemerling <martin.stiemerling@h-da.de> Date: Mon, 21 Sep 2020 15:01:19 +0000 Subject: [PATCH] Update 05-implementation.md --- documentation/design/05-implementation.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/documentation/design/05-implementation.md b/documentation/design/05-implementation.md index 1f1408814..5fab53191 100644 --- a/documentation/design/05-implementation.md +++ b/documentation/design/05-implementation.md @@ -35,7 +35,8 @@ There seem to be two classes of information to be stored in the controller: * short-living information, such as, current configured network flows or obtained network configuration out of use case #1 (CoCSN) * long-time information, such as, information about principle network domains, elements in such a domain if directly learned from SBI, etc -This may or may not result in two different places to store data. Unclear yet. +Long-time information should be persistenly stored in the database and survive reboots of goSDN etc. Short-Living information doesn't have to survive reboots of goSDN + ### Some more details for implementation for the database(s) @@ -45,4 +46,6 @@ Specification of a PND: * Human readable name of PND * Textual description for further information * Set of supported Southbound-Interfaces, e.g., RESTCONF, TAPI, OpenFlow etc -* Phyiscal Inventory Network Elements, hosts and links \ No newline at end of file +* Physical Inventory Network Elements, hosts and links, pontentially only the SBI SDN controller + +A PND entry must be explicitly generated, though some information can be automatically be generated, e.g., the physical inventory for use-case #1 (CoCSN) would mean that the information about the SBI domain specific SDN controller is entered. \ No newline at end of file -- GitLab