This page is in draft and is not ready for TAC consumption.
Tungsten Fabric Project Data
This document describes Tungsten Fabric (TF), an open source software-defined
networking (SDN) product. Tungsten Fabric has been continuously developed
since 2012 and is deployed in production at some of the world's largest
enterprises and carriers.
Originally called "OpenContrail", Tungsten Fabric was rebranded in March of
2018 as it transitioned into a fully-fledged Linux Foundation project. Now
managed by the Linux Foundation, Tungsten is working diligently to expand and
diversify its committer base and to finish its induction process into the
Linux Foundation Networking (LFN) fund.
Tungsten Fabric's primary claim to fame is that it is diligently multi-cloud
and multi-stack. Today it supports:
* Multiple compute types: baremetal, VMs and containers
* Multiple cloud stack types: VMware, OpenStack, Kubernetes (via CNI),
* Multiple performance modes: kernel native, DPDK accelerated, and
several different SmartNICs
* Multiple overlay models: MPLS tunnels or direct,
non-overlay mode (no tunneling)
TF fits seamlessly into LF-N mission to foster open source innovation in the
You can find out more about Tungsten at our websites:
Basic information about the candidate project.
* Project name: Tungsten Fabric
* Project creation date: Initiated March 2012 and Open Sourced August 2013
* Project license: Apache 2.0
* Project release schedule: Two major releases per year, plus incremental patch
* History of at least two years or age of project:
Project Age is 6 years old
* Planned future release schedule:
TungstenFabric 5.1 - Q4 2018
TungstenFabric 6.0 - Q2 2019
* Statement of alignment with LFN Charter/Mission:
Tungsten Fabric (TF) seeks to be one of many potential next generation open
source software-defined networking solutions that can be used as part of a
"stack". TF already plays nice with some LFN projects such as DPDK. It also
works closely with related LF open networking projects such as Akraino Edge
Stack, OPNFV, and ONAP. TF seeks to continue to increase coordination and
interoperability with related open source networking projects over time.
Community Historical Trends
History of the candidate project's community.
For each release or year for at least the last two years or the lifespan of
the project, provide the following.
* Contribution statistics
* Number of commits: approx 32K commits
* Number of non-trivial (generated code, version bump, >5k LoC): 105
* Merged by uploader: 33
* Merged by committer from same organization as uploader: 60
* Merged without substantial code review: 83 (best guess)
* The work that was done for this is here:
* If the candidate project has sub-projects, group these by sub-project
Sub-projects have been designated for purposes of LFN admission, but
frankly it wasn't considered important to divide into sub-projects
prior to the effort to enter the Linux Foundation.
* Number of commits per-organization
Project does not track organization affiliation per commit, significant
number of commits are from generic domain accounts. For the last two years
we had commits from 31 different unique domains:
* Contributor statistics
* Number of contributors: 248
* Number of contributors per-organization:
Still working to determine this number. [vmb]
Community Current Status
Snapshot of the candidate project's community.
* Committer statistics
* Number of committers: 139
* Number of committers per-organization:
Juniper - 99
Codilime - 21
Progmatic - 3
AT&T - 2
Cloudops - 1
SDNEssentials - 1
RedHat - 1
Generic domain - 12
* Number of active committers:
Currently the project does not track commiter activity however
approx 100 committers are active
* Number of active committers per-organization:
Juniper - 178
Unknown - 19
Aricent - 1
AT&T - 3
CloudVPS - 1
CloudWatt - 4
Codilime - 23
Intel - 2
IPnett AB - 1
Lenovo - 2
Mellanox - 1
Mirantis - 4
Netronome - 1
NTT (i3) - 1
Red Hat - 8
Reliance Jio - 1
Ril - 1
SemiHalf - 6
Serro - 1
Sproute - 1
SUSE - 1
Symantec - 2
Syseleven - 2
TechTrueUp - 1
Ukraine Consulting Shop - 1
Workday - 1
* Contributor approval process
* Contributor eligibility: Signed ICLA or CCLA to contribute to the project.
* Process to become a contributor:
Submit a signed ICLA or have CCLA admin add.
* Process to remove a contributor:
No process exists to remove a contributor.
* Committer approval process
Governance details are available at:
* Committer eligibility: active technical contributor to a project.
* Process to become a committer: vote by existing committers or TSC
* Process to remove a committer: vote by existing committer or TSC decision.
Project governance structure
* Summary of project governance structure:
- Technical Steering Committee (TSC): Provide overall project
- Technical Committee (TC): Standing sub-committee of the TSC.
Responsible for technical aspects of the project, including
identifying and approving project use cases and technical
definition of product features such as hardware support,
creating technical processes for developers and projects,
setting release and quality criteria, defining release cycle
and other technical matters.
- Architecture Review Board (ARB): Standing sub-committee of
the TSC. Formed of project architects and responsible to
ensure the project conforms to a coherent architecture and
maintains its stability, scalability, and performance. Defines
project architecture and reviews all specs and code (as needed)
to ensure compliance to project goals and architecture. In
2019 the TSC will reconsider the ARB as currently defined
and potentially make several changes around term limits,
corporate diversity, and selection criteria, but not around
- Community Committee (CC): Standing sub-committee of the TSC.
Responsible for non-technical aspects of the project, including
initiating budget proposals, controlling any budget delegated
by LFN directly to the project, drafting community policy
and other governance materials, marketing and other outreach
activities, and other non-technical matters.
* Summary of how project governance was established and can be modified
Project governance was drafted by the TSC and established by community
vote. Project governance can be modified by a super majority TSC vote.
* Links to all public project governance documentation
Information below is fully contained in
* List of all community roles and details of how they are filled/emptied
Technical contributor, community contributor, committer, PTL, ARB member,
Specific role designation is listed in governance document above.
* List of community roles that are elected
Committer, PTL, committee member, committee chair.
* List of community roles that are appointed
Active community contributor is selected by majority TSC vote. Active
technical contributor can be designated by majority TSC vote. But no roles
in the project are strictly appointed.
* Original ARB founding required some creativity due to the shortage of
non-Juniper contributors. After a community discussion (face to face plus
teleconference bridge) we agreed that Juniper should have a majority
initially while we sought new technical contributors. As a result, we
decided that Juniper would appoint 5 and the community would vote for 2.
Joseph Gasparakis and Paul Carver were elected by the community via mailing
Official ARB elections begin in 2019 and should eventually result in a
wider diversity of representation. According to the current governance,
to ensure architectural consistency, no more than 60% of the ARB may
come up for election at any one time. The 2019 TF TSC will be reconsidering
the ARB as currently defined and potentially making several changes around
term limits, corporate diversity, and selection criteria.
* List of people in all community roles and their organization affiliation
- TSC is defined (in governance document) as TC CC plus one
representative of ARB (currently Michael Henkel)
- Technical Committee:
- Community Committee:
- Architecture Review Board:
- TSC list: Joseph Gasparakis (Intel), Paul Carver (AT&T), Valentine
Sinitsyn (Yandex), Vacant (Vacant), Sukhdev Kapur (Juniper)
- CC list: Liza Fung (AT&T), Vacant (Vacant), Ian Rae (Cloud Ops), Jim St.
Leger (Intel), Doug Marschke (SDN Essentials)
- PTLs: Suhkdev Kapur (Juniper), Paul Carver (AT&T), Edward Ting (Lenovo)
- ARB: Joseph Gasparakis (Intel), Paul Carver (AT&T), Suhkdev Kapur
(Juniper), Anantharamu Suryanarayana (Juniper), Nachi Ueno (Juniper),
Sachidanand Vaidya (Juniper), Michael Henkel (Juniper)
* User community
* Summary of project user community
Current user community consists of a significant number of
companies. Active project contributors are Juniper, Codilime,
Progmatic, Intel, Lenovo, Mellanox, Netronome, Yandex,
Details about the functionality of the candidate project.
* Summary of candidate project functionality
Tungsten Fabric is an SDN and Security Fabric, its focus is stability
(production), scalability (1K nodes, up to 8K can be supported),
performance (sufficient for high performance VNFs at 10 gigabit using
software only, hardware accelerated to 40 gigabit/s). It supports key
telco and enterprise features including multi-pop, routing, VNF
injection, Service Chaining, LoadBalancing, Router and Switch
integration, Intent based Security Policy enforcement to L4 extensible
to L7 with VNFs. Project goals enforce a uniform architecture and
prioritize production ready code over features.
* Summary of candidate project technology components and purposes
- Tungsten Fabric is normally an overlay SDN and Security fabric with native
BGP speaker. It supports multi-site deployments and can integrate into
Containers via CNI (Kube, Mesos, etc) and OpenStack via Neutron plugin
or ML2 driver.
- Configuration Node Ã¢â‚¬â€œ manages system configuration DB and provides a UI.
- Analytics Node Ã¢â‚¬â€œ collects system wide stats and provides both raw and
- Control Plane is responsible for managing the dynamic cluster state and
- Vrouter and Vrouter Agent Ã¢â‚¬â€œ On Each Server there is a Vrouter Agent
talking to control plane and programming local forwarding plane.
Vrouter serves as the local forward plane, interfaces to
Containers or KVM, segregates the network between tenants and provides for
security policy enforcement, supported modes of operation is kernel,
DPDK accelerated, SR-IOV, SmartNic forwarding integration Netronome,
Mellanox (in prog),Cavium (in prog).
- Hardware interface is to Gateway Router for EVPN termination, VXLAN tunnels
to OVSDB compliant switches are also supported. Software operates in
overlay mode default MPLS over UDP, but is capable of VXLAN or non-overlay
* Summary of where candidate project complements functionality already provided
by project(s) within LFN
TF interoperates with a wide variety of opensource projects such as DPDK,
FIDO,OpenStack, Kubernetes and others. In the LFN specific ecosystem TF
is complementary to ONAP and OPNFV as alternative SDN provider and has a
FIDO port in progress driven by community members.
* Summary of where candidate project overlaps functionality already provided by
project(s) within LFN
TF overlap with ODL on some of the usecase it addresses, however there is
a signficant divergence and the projects interoperate in the number of
customers where TF is used as DC overlay SDN and ODL is used to manage the
hardware or WAN elements.
Details about the tooling used by the candidate project.
* Bug tracker
* Links to bug trackers used by the candidate project.
* Integrated with any other relevant projects?
Currently no, this may change as we migrate to Jira.
* To what extent are external/private bug trackers used?
Downstream distros use private bug trackers, upstream blueprints and
bugs are on the open system.
* Chat tooling
* Links to chat tooling used by the project.
* Overview of chat tooling used by the candidate project.
Slack is used for all chats.
* To what extent is external/private chat tooling used?
The community uses an open slack community.
In addition downstream distro providers have private slack communities.
* Code repositories
* Links to code repositories used by the candidate project.
Currently code repositories are mirrored from Gerrit at
https://review.opencontrail.org/ to the Juniper namespace at GitHub:
Pending an availability of LFN IT support, a migration of Gerrit to
http://gerrit.tungsten.io/ is planned. After that migration, code
repositories will be mirrored to https://github.com/tungstenfabric
A few repositories already exist at the TF GitHub and will be migrated to
Gerrit pending LFN IT support availability
* Overview of code repositories used by the candidate project.
A large number of repositories exist the important repositories are:
- contrail-controller: all TF controller code
- contrail-vrouter: dataplane
- contrail-sandesh: analytics IDL
- contrail-analytics: analytics
- contrail-third-party: all external dependencies
- contrail-common: all common code
In the development of the plan to transition to LF we are looking at ways
to cleanup, rename, and simplify a number of these repositories. The plan
is being developed between Juniper and Linux Foundation IT staff. Once we
have something more complete we can update this document.
* To what extent are external/private code repositories used?
All repos are hosted on GitHub.
* Code review
* Links to code review systems used by the candidate project.
* Overview of code review norms, practices, conventions, rules.
TF copied OpenStack conventions, all code is subject to code review,
any contributor can submit the code once CLA is registered.
Only committers can commit the code to the repo.
* To what extent are external/private code review systems used?
TF community uses a publicly facing review system for all commits,
current system is hosted by Juniper, however transition to LF
infrastructure is in progress.
* Continuous Integration tooling
* Links to CI jobs.
TF uses Gerrit and Zuul for its CI. Codilime team has built a
preliminary UI for Zuul,
UI url is contained here http://logs.opencontrail.org:8000/
* Links to CI job definitions, infrastructure configuration.
CI source can be found in https://github.com/Juniper/contrail-infra
* Overview of CI related to the candidate project.
TF team copied the OpenStack CI infrastructure and uses Zuul V.3 for
its CI engine.
* To what extent are external/private CI systems used?
Current community CI instance is hosted on Juniper Lab openstack cloud,
this is in the process of being migrated to LF OpenStack cloud.
* Links to documentation for the candidate project.
- Summary deck https://drive.google.com/
- Architecture Doc http://www.opencontrail.org/
- Tech video from last tech summit
* Mailing lists
* Links to mailing lists used by the project and their archives.
* Overview of mailing lists used by the candidate project.
Main lists are dev and announce. But a number of specialized lists
* To what extent are external/private mailing lists used?
LF foundation listserver is used. All lists are public.
* Meeting calendars
* Link to docs about meetings related to the candidate project.
* Overview of meetings held by the candidate project.
Main meetings are TC committee, Community Committee, Infra, Marketing,
* To what extent are meetings public, and clearly publicly documented?
All meetings are public, meetings are listed on community calendar
* Meeting minutes
* Link to archives for meeting minutes taken by the candidate project.
Meeting minutes are in the individual meeting invites.
Older meeting minutes are in Google Docs, newer meeting minutes are on
the Tungsten Fabric wiki. The wiki contains links to the older Google
Docs. The meetings are listed on the front page of
https://wiki.tungsten.io and those links provide access to both meeting
logistics and minutes.
* To what extent are public minutes for meetings taken and shared?
TC and Infra meetings maintain minutes, CC have notes and also are
Details about technical integrations implemented by the candidate project.
* Summarize any existing or planned integrations with other projects.
Integrated with DPDK, OpenStack, and Kubernetes. Future integration
planed for FD.io.
* Summarize any CI/CD integrations with other projects.
networking-opencontrail projects is currently running and passing
Neutron's Tempest tests.
* Summarize any other work that may enable integrations in the future.
3rd party CI integration is supported via Zuul and gerrit hooks
* Continuous Delivery pipelines
No separate CD pipeline exists. The build products are Docker
images, generated by the same system that performs the CI testing.
The current Zuul configuration is in a public Git repo and contains
primarily Ansible playbooks. These playbooks "deliver" the Docker
images to Docker Hub.
TF is in the process of moving its CI/CD from Juniper to LF.
As this will involve transitioning away from Zuul (which LF cannot
support) to another system, this will render any reply to this
section immediately out-of-date. Therefore TF defers further
answers to this question until such a time as CI/CD is settled
in its new LF home (hopefully early 2019).
* Configuration management tooling
Assuming that configuration management means deployment automation:
* Documentation about cross-project integration
Upstream docs are under development, meanwhile downstream docs
https://github.com/Juniper/contrail-docs/tree/master/doc can be used.
* APIs for cross-project integration
Neutron API, CNI API.
Explanations of domain-specific vocabulary.
.. todo:: Look into using special rst to make these definitions into tooltips
.. todo:: Consider extracting this to a stand-along file so can reuse elsewhere
* In this context, typically related to the activity level of a project or
* As a person: "Foo Committer on Bar Project has not sent any patches or done
any code review for Bar in the last 12 months. Bar's Project Lead reached
out to Foo Committer to discuss transitioning to an Emeritus Committer."
* As a project: "Bar Project has not had any non-trivial code changes merged
in the last 12 months. The LFN TAC reached out to Bar Project to discuss
transitioning to the LFN Archived lifecycle state."
* The LFN norm for "active" is about 12 months.
* Person with permission to cause commits to be merged into a project's
source control repositories.
* Person who has contributed to a project. "Contributions" are broadly
defined. Examples include things like code, documentation, and bug tracker
* In this context, typically related to the number of different organizations
involved in a project.
* In this context, typically means the products based on a project.
Community collaborates on upstream project, which is downstreamed by a
company into a product.
* Alternatively, could relate to a relationship between two "upstream" open
source projects (not by-company products) where one consumes (is downstream
of) the other.
* As a verb: "to copy something from the open source project to a product
based on it".
* As a dependency relationship: "Linux is a downstream of C".
* In this context, typically means the main open source project a community
collaborates on. The code, tooling and people that comprise a project.
* As a verb: "to add something to the main open source project".
* As a dependency relationship: "C is an upstream of Linux".