# Mission statement
The project objectives are:
1. To release a cloud software framework
2. To develop a reference implementation

# Sylva Framework Working group charter

The purpose of the working group is to document the requirements for the Sylva framework that shall be used as the base for compliant platforms and their workloads. The framework requirements will be based on the requirements defined through the implementation in WG1, Security requirements of WG3, and the Anuket RA2 Specification. The working group might suggest changes to the upstream Anuket specifications when needed. Sylva framework shall maintain additional requirements on top of what is in the scope of the Anuket RA2 specifications where agreed upon in the community.

The working group has a bi-weekly meeting where open technical topics are discussed. The scope of the framework and the technical requirements are defined in a git repository. The GitLab MR process is used as the tool for consensus making. Every MR needs to have an approval from 3 distinct member companies in the reviewer group as well as a representative from WG1 and WG3 in order to be merged. Every member company of the working group can have approval representatives; these are listed in the CODEOWNERS file of the working group repo. Every approver also has write access to the repo. At regular intervals, before every release, the working group shall have an open commenting period by the wider community. After the comment period, the TSC needs to approve the final requirements document before it is released.

The framework requirements have an independent release cycle from the Sylva project. The target is to have one release per year, if the WG sees it necessary, after the initial setup of the framework.

The working group communicates using the Sylva framework-discussion Slack channel which will be renamed to be the working group channel following standard conventions. Meeting minutes are stored in the wiki of the working group.

# Feedback from the TSC

* Have a presentation to the TSC and the relevant WGs (WG1, WG2, WG3, WG7)
* Address how the framework will change the work practices of WG1
* Address what is the relationship of the new WG to WG2
*

# Actions Items:

1. Go over all the official Sylva project docs and collect the correct requirements into a list.
2. Identify what are the current missing requirements and gaps(How Sylva interact with external components).
3. Review and have the broader agreement by the Sylva community(TSC to approve).

# Relevant liks:

[Framework Principles HackMD](https://hackmd.io/npqoRUvWTbGydhMY9ynKww?view)

[The white paper](https://gitlab.com/sylva-projects/sylva/-/blob/main/White_Paper_Operators_Sylva.pdf)

[The FAQ](https://gitlab.com/sylva-projects/sylva/-/blob/main/FAQ_Sylva.pdf)

[The technical charter](https://gitlab.com/sylva-projects/sylva/-/blob/main/Project_Sylva_Technical_Charter.pdf)

[The Technical Steering Committee](https://gitlab.com/sylva-projects/governance/-/wikis/home)

https://sylva-projects.gitlab.io/design/technical-overview/
https://sylva-projects.gitlab.io/doc-preview/design/core-concepts/
https://sylva-projects.gitlab.io/docs/1.3/
https://gitlab.com/sylva-projects/sylva/-/blob/main/README.md

**Anuket RA2 links:**

https://docs.anuket.io/projects/RA2/en/latest/chapters/chapter04.html
https://docs.anuket.io/projects/RA2/en/latest/chapters/chapter02.html

**Conformence testing for Sylva to be comlient with Anuker RA2:**
https://github.com/petorre/functest-kubernetes/tree/master/sylva

# List of requierments from the official Sylva Pages:

Table 1

| **Category** | **Requirement** |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Cloud-Native Infrastructure** | Deployment of Kubernetes clusters across telco edge, regional, and core clouds to provide a uniform cloud-native execution environment. |
| **Distributed Deployment** | Support for modern telco infrastructure that is distributed across multiple locations, including far-edge, near-edge, and regional clouds. |
| **Declarative Management** | Adoption of a declarative approach with a GitOps framework to manage a high volume of physical nodes and Kubernetes clusters. |
| **Lifecycle Management** | Comprehensive infrastructure lifecycle management covering Day 0 (build and deploy), Day 1 (run), and Day 2 (operate) operations, including fault management, updates, and upgrades. |
| **Automation and CI/CD** | Provision of automation with CI/CD pipelines, utilizing scripts that produce and maintain Helm charts for Kubernetes deployment and operational resource definitions. |
| **Cluster Deployment Tooling** | Development of tooling for cluster deployment and lifecycle management (LCM) based on the Flux GitOps tool, ensuring synchronization between clusters and infrastructure components with their definitions in Git repositories. |
| **Bare Metal Provisioning** | Management of Kubernetes clusters and bare metal provisioning using Cluster API (CAPI). |
| **CNF Validation** | Validation of Cloud-Native Network Functions (CNFs) on Sylva platforms to ensure interoperability between CNFs and platforms. |
| **Platform Feature Support** | Verification that deployment platforms support the requirements of CNFs under test, including necessary platform capabilities like SR-IOV, Multus CNI, and Real-time Linux. |
| **Functional Testing** | Execution of functional tests to verify correct deployment of CNFs on the platform, ensuring all necessary Kubernetes pods are healthy and in a ready state. |
| **Additional Testing** | Provision for operators to run additional tests on CNFs if deemed necessary. |
Table 2

# SYLVA Requirements Table (WIP)
Workload Cluster Requirements are controlled by Anuket RA2 except as noted in the table

| # | Category | Requirement Description | Source |
|----|----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------|
| 1 | Functional | Support a scalable, cloud-native infrastructure for telco workloads across RAN, Core, and MEC. | [White Paper](https://gitlab.com/sylva-projects/sylva/-/blob/main/White_Paper_Operators_Sylva.pdf) |
| 2 | Distributed Deployment | Support deployment and management of multiple distributed Kubernetes clusters across edge, MEC, RAN, and core sites, with centralized control and lifecycle management. | [White Paper](https://gitlab.com/sylva-projects/sylva/-/blob/main/White_Paper_Operators_Sylva.pdf) |
| 3 | Platform Management | Use a centralized management cluster to deploy and manage multiple workload clusters. | [Technical Overview](https://sylva-projects.gitlab.io/design/technical-overview/) |
| 4 | Lifecycle Automation | Adopt GitOps with FluxCD for declarative and automated infrastructure and app lifecycle management. | [Core Concepts](https://sylva-projects.gitlab.io/doc-preview/design/core-concepts/) |
| 5 | Kubernetes Lifecycle | Utilize Cluster API (CAPI) to manage the lifecycle of management and workload clusters, enabling declarative provisioning and consistent operations. | [Technical Overview](https://sylva-projects.gitlab.io/design/technical-overview/) |
| 6 | OS & Resources | Support multiple Linux distributions for bootstrap and workload VMs, including Ubuntu LTS versions (e.g., 20.04, 22.04) and RHEL-compatible distros (CentOS, Rocky Linux, AlmaLinux), ensuring kernel and container runtime compatibility. Minimum recommended specs for bootstrap VM: 4 vCPU, 8GB RAM, 50GB storage. | [Docs v1.3](https://sylva-projects.gitlab.io/docs/1.3/) |
| 7 | Networking – CNI | Support multiple Kubernetes CNI plugins (e.g., Calico, Multus) to separate control and data planes. | [Anuket RA2 Ch. 4](https://docs.anuket.io/projects/RA2/en/latest/chapters/chapter04.html) |
| 8 | Networking – SR-IOV | Enable SR-IOV support for high-throughput, low-latency workloads such as 5G UPF and DU. | [Anuket RA2 Ch. 4](https://docs.anuket.io/projects/RA2/en/latest/chapters/chapter04.html) |
| 9 | Networking – DPDK | Include support for DPDK-enabled workloads to enhance packet processing performance. | [Anuket RA2 Ch. 4](https://docs.anuket.io/projects/RA2/en/latest/chapters/chapter04.html) |
| 10 | Hardware Acceleration | Support hardware offload features via PCI passthrough, SR-IOV, and NUMA awareness. | [Anuket RA2 Ch. 4](https://docs.anuket.io/projects/RA2/en/latest/chapters/chapter04.html) |
| 11 | Resource Isolation | Ensure CPU pinning, hugepages, topology manager for deterministic latency and performance isolation. | [Anuket RA2 Ch. 4](https://docs.anuket.io/projects/RA2/en/latest/chapters/chapter04.html) |
| 12 | Security | Enforce Kubernetes RBAC, Pod Security Standards (PSS), and secure bootstrapping with certificate validation. | [Docs v1.3](https://sylva-projects.gitlab.io/docs/1.3/) |
| 13 | Observability | Use Prometheus, Fluent Bit, Loki, and Grafana for observability and troubleshooting. | [Technical Overview](https://sylva-projects.gitlab.io/design/technical-overview/) |
| 14 | Compliance – ETSI | Align with ETSI NFV MANO (SOL018, SOL020) and GSMA Operator Platform requirements. | [White Paper](https://gitlab.com/sylva-projects/sylva/-/blob/main/White_Paper_Operators_Sylva.pdf) |
| 15 | Testing & Conformance | Integrate functest-kubernetes for workload validation against Anuket and internal test suites. | [Functest Sylva](https://github.com/petorre/functest-kubernetes/tree/master/sylva) |
| 16 | Data Sovereignty (EUCS) | Ensure that cloud services comply with EUCS requirements for data locality, control, and protection within the EU. | [EUCS – EC Newsroom](https://ec.europa.eu/newsroom/cipr/items/713799/en) |
| 17 | Operational Control (EUCS) | Ensure cloud services are operated by EU-based legal entities with complete operational autonomy and EU-resident support personnel. | [EUCS – EC Newsroom](https://ec.europa.eu/newsroom/cipr/items/713799/en) |
| 18 | Access Restriction (EUCS) | Restrict physical and logical access from non-EU jurisdictions, as defined by EUCS sovereignty and control criteria. | [EUCS – EC Newsroom](https://ec.europa.eu/newsroom/cipr/items/713799/en) |
| 19 | Encryption (EUCS) | Encrypt all data in transit and at rest using EU-compliant encryption, with key management services located and operated within the EU. | [EUCS – EC Newsroom](https://ec.europa.eu/newsroom/cipr/items/713799/en) |

# List of requirements(WIP):

1. Using CAPI / CAPO /CAPV / CAPD for Cluster LCM
2. CNI Installation and configuration
3. Support MultiCluster deployment
4. Configuration of SR-IOV interface
5. CPU pinning and Huge Pages
6. Support Precision Time Protocol(PTP)
7. Storage
- Persistent storage
- etc..
9. Cluster Monitoring(for energy efficiancy)
10. Policy Management
11. GitOps
12. Compatibility with EUCS
13. CIS Hardening
14. Support Multitenancy
15. Support Service Mesh
16. Real Time OS Kernel
17. O2-IMS et O2-DMS
18. CNF/VNF management
> [name=Cristian Manda] out of scope of Sylva the management of the CNF/VNF
19. Prometheus
20. Sylva Unit format for configuration
21. AI

# Requirement Categories (WIP)
Flavours: Management Cluster, Workload Cluster
1. Platform
1. Cluster Management
1. LCM
2. Importing clusters
2. Cluster Configuration
1. Sylva Units
1. Operators
2. Helm Charts
2. Networking
3. Storage
4. Logging/Telemetry
5. Security
2. CNF
1. Workload Management
1. Deployment
2. Upgrade
2. Workload Configuration
1. Sylva Units (is this really needed for workloads?)
2. Networking
3. Storage
4. Logging/Telemetry
5. Security
3. VNF
1. See CNF categories
2. on OpenStack
3. on Kubevirt
4. Networking
5. Monitoring/telemetry
6. Storage
7. APIs
9. System Configuration Management
10. Deploymemt Models
11. Artificial Intelligence

Scope Questions: (things to dig deeper into)
- Applicable Deployment Methods
1. GitOps
- APIs
- Secrets Management
- Access Control at local work load cluster level
- Testing
1. Test Plan
1. Functionality covered
2. Framework(s)

- Sylva Certification of CNF/VNFs
- Sylva Certification of platforms to run CNF/VNF
-