V.0.1.0 Codename Threadbare

Development branch for milestone v.0.1.0 Codename Threadbare.

Please keep using feature branches and merge them against v.0.1.0-codename-threadbare.

documentation/design/01-introduction.md

 # Introduction
-Lorem ipsum at nusquam appellantur his, labitur bonorum pri no [@dueck:trio]. His no decore nemore graecis. In eos meis nominavi, liber soluta vim cu. Sea commune suavitate interpretaris eu, vix eu libris efficiantur.
+Data networks consists out of a variety of different network elements, link types, end hosts, services and requirements of such services. Further data networks consists not only of a single plane, but have different (logical) networking planes that have different tasks within any data network, i.e., the control plane, data plane and the network management plane. Keeping track of the different elements, links, hosts, services, their interactions, their runtime behavior on the 3 networking planes is a non-trivial tasks that is usually subsumed under the very broad term of network operations. 
+
+There are different approaches for network operations that are not only divided by their logical distinction but also how an implementer, typically network equipment vendor, is implementing the network elements and the particular operations. 
+
+We outline two basic approaches to network operation:
+
+1.  fully integrated network operations of all networking planes, i.e., usually called the traditional approach.
+2. separation of control- and data planes, i.e., usually called the Software Defined Networking (SDN) approch, though there have been implementations of this concept earlier than SDN with other names, e.g., Forwarding and Control Separation (ForCeS) and others. 
+
 
 ## Motivation
 
 ## Overarching Project Goals
 
 * Keep It Simple, Stupid (KISS)
-* Reuse existing technologies bits wherever possible
+* Reuse existing technologies bits wherever possible if those are stable, i.e., documented, maintained etc,  on a long time scale
 * Integrate state-of-the-art technologies and methodologies
-* Document, Document, Document
 * Automate almost everything right from the beginning
+* Document, Document, Document
 * be an excellent citizen: test, test, test
+* no hacks! 
 
 Some unsorted thoughts the be ordered yet:
 
@@ -22,4 +31,30 @@ Some unsorted thoughts the be ordered yet:
 * modules should be loaded (or unloaded) during runtime of the controller core
 
 
+## Use Cases to be considered
+
+The development of a general purpose SDN controller is not the primary goal at this early stage of the project.
+Instead there are two use cases to be considered in the implemenation works that are currently ongoing:
+* Primary: optical domain SDN-controller for the CoCSN project
+* Secondary: SDN-controller for our local labs to manage an Ethernet-based lab environment
+
+### Primary: optical domain SDN-controller for the CoCSN project
+
+For this use case we initally do not consider the direct control of optical network elements, e.g., Optical Add-Drop Multiplexer (OADM) but we focus on optical network domains managed by another (SDN) controllers. The goSDN controller communicates with this domain controller and can request information about the optical network elements, the links between them and the optical and logical configuration of the network domain. 
+
+In a second step, the goSDN controller has to communicate with multiple domain controllers and has to find potential interchange points between these multiple domains. This is the preparation for a later step in this use case, when the goSDN controller has to find a network path between two end-points across multiple optical domains, including backup paths. 
+
+The intention here is to use an existing SDN southbound interface, very likely based on RESTCONF. 
+
+### Secondary: SDN-controller for our local labs to manage an Ethernet-based lab environment
+
+For this use case we consider one of our local labs, e.g., either the telecommunications or networking lab, and how this lab with all its networking parts can be managed by the goSDN controller. In this case, the controller has to learn about all (network) elements, the links and the topology by obtaining all the required information and its own topology computation. This will require an interface between goSDN and the network components that is potentially beyond the typical SDN southbound interfaces. 
+
 ## Structure of this Memo
+
+This memo starts with this introduction that sets the stage for the theoretical underpinings of the SDN-controller
+and the acutal implementation (and the various choice for this). Chapter 2 discusses the related work and chapter 3
+outlines the theoretical foundations related to the control of networks and their relation to SDN. Chapter 4 uses
+the output of Chapter 3 to define the conceptual design of the goSDN controller and some discussions about the pro
+and cons of conceptual design. Chapter 5 describes the actual design of the current goSDN implementation and is 
+meant to be a compendium for the source code.