Page Comparison

Tal is a senior principal software engineer in Red Hat’s Telco Solutions team, where he works with partners and customers to integrate network function workloads into the cloud native stack. In other words: the Nephio scope. He was the liaison to the ONAP project, where he focused on service orchestration and Kubernetes, and is in the core group at OASIS drafting the TOSCA 2.0 specification. In his Telco Solutions role he has initiated many related several projects and PoCs that align with Nephio's goals, including multusctl, Candice, Knap, Puccini, Turandot, Khutulun, Reposure, and CNCK.

Before Red Hat he worked at Cloudify, specifically on OPEN-O (subsumed into ONAP) and the now-retired AriaTosca project.

He has given many public presentations on the topic of cloud native, declarative, intent-driven, policy-oriented orchestration in telco. Evangelist? Prophet? Broken record? Time will tell!

I intend to steer us towards the “Unix philosophy”: Nephio as a collection of focused tools (operators) that solve one problem well. The advantage of the operator pattern in declarative orchestration, on which I have worked and written extensively, is that operators can be chained together to form comprehensive solutions, which we know will differ between vendors. Our reference implementation should reflect this differentiation and encourage innovation at its integration points rather than locking us down with too much opinion.

CRDs will be tricky, requiring a careful balance between abstraction and actual features, all within the confines of Kubernetes’s extensible ecosystem. I’ve seen many modeling efforts in telco fail due to designed-by-committee bloat, shortsightedness, and/or irrelevancy. I hope to lead from experience and help us keep our eyes on the ball: delivering CNFs on Kubernetes, rather than defining them.

In particular we need to solve the “bifurcation” problem of vertically integrated CNFs. Which operators will run on the management cluster and which on the workload cluster? How will our packaging, CRD design, and tooling reflect and connect the two paths? Presentation on this topic is forthcoming. Another topic I want to focus on is networking orchestration, what I call "Multus, part 2". How do we manage Multus at scale without requiring CNFs to package complete CNI configs?

Some words I live by: The best technology is often the most familiar, not the suddenly popular. User experience is a starting point, not an afterthought. Documentation is as important as code.

I’ll do my best to foster a welcoming, open, and diverse development community where everyone feels safe and valued.