Open matzf opened 1 year ago
Very broadly, a goal of the SCION Association currently is to make the open-source SCION implementation directly operationally usable; the open-source SCION implementation should be (at least minimally) operationally viable on its own, not "only" serve as basis for an actually usable proprietary implementation.
Myself, and in the near future one more software engineer directly employed by the SCION Association, are prioritizing these topics.
Is there any need for CI automation and regression testing? (Maybe that falls under Software packaging/releases). Or continuous validation of the SCION stack working on various bare metal service providers? @alicecuii - perhaps this would be a good project for you? Or if you want to tackle something larger, I'd love to see a message bus ported over to native SCION.
@JbainMartincoit - I'd like you to stay in the loop and see how you can help out with "General usability enhancements Documentation (reference manuals, guides, tutorials)"
Looking at a recent CI run gives a bit of an overview of the set of checks that we run. This gives us a relative broad coverage already. Of course there can always be more and better tests, but I don't know of a subsystem or topic that is simply lacking tests.
One specific topic related automated testing where we could use help is this: there is a test harness called braccept
(for border router acceptance tests). This sets up a SCION border router in a specific configuration, sends individual packets to it and validates that the router behaves as expected. Currently, this is very strict and tolerates no deviations from the open-source "reference implementation". Ideally, we'd want to reuse the same test harness to assess other router implementations, but for this it would need to be redesigned so it can accept and report on different behavior allowed by the of the specification (with all its "SHOULD"s and "MAY"s etc). The data plane specification document is currently being worked on, so it could be a good timing to work on this.
If this sounds like an interesting topic, we could create a github issue describing the requirements, so that you could then start to work out the details.
Currently, I am working on the following items on that list:
I also have interest in tackling:
I would kindly ask for whoever is interested on this to coordinate together :)
Below is a tentative categorization of the ongoing SCION work at the OVGU NetSys Lab.
These are topics and projects that we are working on that (might) affect the core protocol in some way and thereby seem most relevant to this roadmap.
The following topics probably have less impact on the protocol itself but depend (or are based) on SCION in some way. Many are centered on the end-host and seem less relevant to this roadmap but possibly still of interest.
Some further project ideas we have been throwing around but didn't do any work on yet
The SCION Association's TC Implementation has compiled a roadmap document. Find the full document here: 2023-10 Open-Source SCION Implementation Roadmap
Summary
The open-source implementation of SCION aspires to be complete, i.e. not missing any required components or critical features, and and of sufficient quality (in terms of correctness, performance and usability), and with sufficient documentation to be minimally operationally viable.
The scope of the project and these components is the “base” SCION protocol. For the time being expressly not in scope are experimental SCION-extensions such as Colibri, or EPIC.
When major work topics are complete, we'll publish releases consisting of:
The focus for the planned work in this period is to improve operational readiness and deployability of the open-source components.
Infrastructure components (router, control service, gateway):
End host stack, SCION-native applications:
Possible sequence of work items and rough estimated time of arrival, covering the period of about one year starting from now.
Disclaimer: this is based on rough estimates for the effort and many of these topics will require upfront discussion and detailed design work. The timing may depend on the availability of independent collaborators and their voluntary contributions. The included release milestones illustrate that we will release after completing major work topics and should not be mistaken to indicate a commitment to release these version numbers at the indicated dates or feature sets.
We'll update this post with links to issues/milestones to track the progress of individual topics.
This roadmap intends to guide the development work for the coming year or so, but it's not meant to be set in stone. We may amend the roadmap if circumstances change, and everyone is still welcome to contribute to this planning process by commenting or discussing in the chat.
In a recent TC Implementation meeting, we've discussed the idea to develop and publish roadmaps for the development of the open-source SCION implementation. The idea is to make planned development activity visible, to communicate planned features to users and help coordinate between developers. It's not meant to be a binding commitment, and contributions outside of this process are still very welcome.
To start, we'll use a very simple process:
Everybody: please comment to this issue on development topics that you're either planning to work on yourself or that you would be keen to have someone else work on.