This page discusses some possible changes to the CONFINE architecture in order to adapt it to the provisioning of long-running services, besides the current support for network experiments.
To get some context on the discussion, we recommend reading Services in CONFINE, and especially section Challenges for Service Developers.
From the experience of Community-Lab and CONFINE, to make Community-Lab more attractive for community members to run nodes and services in them.
Application-only network access for slivers:
Remove isolated interfaces,
Sliver.isolated_vlan_tag: avoids a central consensus point
Avoid centralization points:
Sequential identifiers: use locally-computable identifiers (UUIDs or public/private keypairs): implies changes to Addressing in CONFINE
in the management network
, maybe choosing a model with private addresses derived from locally-created keys, as in CJDNS
VLAN tag associated with a slice: removing them implies dropping isolated interface support
Sequence numbers: allow local modifications to
Explicit permission for node and slice managenent: removing them means that the node manager can decide who to accept slivers from (or to delegate this decision)
Common prefix for the management network?
Or keep a per-testbed prefix
Servers: drop them, allow a node publishing multiple APIs?
Group membership: make any element (user, node, slice) able to declare it, but contrast it against the group itself
Allow management of nodes and slices by individual users?
Or continue with one group per user workaround
Multiple VMs per sliver in the same node?
Specially if each VM carries a single service (like MySQL, web server, PHP…): implies redefining the sliver as a VM (and changes to the node-slice relationship), and the slice as a group of VMs
Private data per VM: data blocks encrypted for the public keys of nodes in a slice, or the node in a sliver?