Nephio R4 Developer Summit - 2024 (Day 1)
LFN Welcome!
Arpit Joshipura
GM/SVP, Networking + Edge/IoT, The Linux Foundation
Jenn Bonner��Sr. Program Manager, The Linux Foundation
Logistics items
Nephio Momentum
https://docs.google.com/document/d/1yGCKM1wvGkGLAkIb8ZcjC1ND8OmtYSWXMHM1obj_DMc/edit
Nephio & OSS Networking: Where We Are
! 3nncCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC Q111111111111111111`````````````````````````````
SMB/Store
Residential
Mobile
Service Provider Edge
User Edge
Carrier
Access
Enterprise & IIOT
Carrier Core
Apps/Internet /
Web
Public Cloud
Enterprise
Core & Cloud
Private Cloud
eg Google, Microsoft, AWS, IBM, Huawei, Alibaba, Baidu, Tencent..
NW API, Functions, Workloads, Life Cycle Mgmt
MANAGEMENT
ORCHESTRATION & ANALYTICS
NETWORK �CONTROL
INFRASTRUCTURE
xNFs
* Sample projects only
Network OS &
Data Plane
Last Mile Enhanced Access
Nephio TSC Welcome!
Kandan Kathirvel
Group Manager, Google Cloud
TSC Chair, Nephio
Goals of this Development summit - R4
Discover Nephio
Plan for R4
Build a Community
We started with this Mission!
Nephio’s goal is to deliver carrier-grade, simple, open, Kubernetes-based cloud-native intent automation and common automation templates that materially simplify the deployment and management of multi-vendor cloud infrastructure and network functions across large scale edge deployments. Nephio enables faster onboarding of network functions to production including provisioning of underlying cloud infrastructure with a true cloud native approach, and reduces costs of adoption of cloud and network infrastructure.
Nephio fundamentals
Intent object describes the desired state
APIs & Data Models
AI/ML Analytics
Network Orchestration
Intent
Intent objects validated and compiled
Network state reconciled with intent
Continuous visibility of network state
Network is constantly self-optimized
Solves the real problem!
Efficient Multi-cloud Infrastructure and Multi-vendor Network Function Configuration Management
Telco Network Automation
Cloud Infra Resources
Automation (Public & Private)
End-to-End Service Orchestration + End-to-End Slice Management
Workload Resource
Automation (NFs)
Workload �Configuration (NFs)
K8s Operator
K8s Operator
K8s Operator
CRD
CRD
CRD
CNF
CNF
Kubernetes Engine
Cloud Infrastructure
Open APIs
K8S Custom Resource Definitions (CRD) driven API
Configuration blueprints for network functions (multiple vendors/multiple domains) and corresponding infrastructure
Operator implementation translating intent to actual configuration, continuous observation and reconciliation on deviations
Applying Kubernetes Resource Model principles
This unified approach allows for the use of CI/CD principles and common tooling across all layers.
Nephio community trajectory
A 2+ Years with Nephio, market feedback and new trends
Use cases &
Verticals
Project
Synergies
Evolving
Technologies
Nephio
Adoption
Nephio: Expanding Beyond Telecom
The Automation Challenge: Large-scale edge cloud deployments, whether connected or disconnected, demand robust automation across all sectors.
Nephio's Advantage: Provides a vendor-neutral, open-source platform for managing complex cloud infrastructure.
Cross-Industry Applicability:
Community-Driven Growth: Collaborate to extend Nephio's capabilities and make it the go-to solution for cloud-native automation across all industries.
Community: Things to consider
Network Automation Challenges for Telco
1
2
Heterogeneity and complexity of Network Functions information exchange models
Heterogeneity and complexity of Telco Clouds in Infrastructure Configuration and Automation
3
Heterogeneity and complexity of NF configuration
Nephio attempts to solve these by adoption of ‘common’ Kubernetes Models
How Nephio Solves These Challenges
Nephio R1
Nephio R2
Nephio Experimental
Nephio R4 and Beyond
Readiness for Production
Multi-cloud
Security
Network Functions and Use-Cases
Support for NB APIs (SO, O-RAN SMO …)
Support for NF and NS lifecycle
Synergy with OS and Standards (Sylva, ORAN …)
Nephio User Experience
Enhanced UI, Design Studio
GenAI for automation simplification and LCM Operators SDKs (Helm, Yang/TOSCA )
Nephio R3
Looking Ahead: Nephio R4+ O-RAN Progress
SMO and RAN Domain Management
O-RAN NF
O-Cloud
In Progress
Ready for development
Looking Ahead: Nephio R4+ Platform Evolution
Platform and Infrastructure
Security
Service Assurance and Observability
User Experience, Modeling, and GenAI
Nephio SIG Structure and Roles
SIG1 Architecture
Workgroups:
SIG3 Release
Work areas:
SIG4 Security
Work areas:
SIG2 Automation
Team project boards:
Realizing Nephio Business Value for Telcos
Panel Discussion
Realizing Nephio Business Value for Telcos
Lead Principal Architect, ATT, USA
Cloud Giants Weigh In: Perspectives on Nephio's Network Automation
Panel Discussion
Cloud Giants Weigh In: Perspectives on Nephio's Network Automation
Tomas Fredberg
Senior Expert in IT & Telco Data Center Architectures, Ericsson
Moderator
Jenn Bonner - LFN
Balaji Balasubramanian
Engineering Lead, Google
Bill Wright
Edge and AI specialist, Red Hat
Tom Nadeau
Chief Architect of Solutions & Innovation, WindRiver
Akshatha Sathyanarayan
Director, R&D Management, VMware by Broadcom
Nephio Adoption: Network Function Vendors Navigate the Cloud Native
Panel Discussion
Nephio Adoption: Network Function Vendors Navigate the Cloud Native
Ciaran Johnston
Senior Expert in OSS & Programmable Network Architectures, Ericsson
Moderator
Kandan Kathirvel - Google
Jane Shen
VP Technology Strategy, Mavenir
Wim Henderickx
Head of architecture & technology IP, Nokia
Sundar Nadathur
Principal Engineer, Intel
|
Director, Samsung Electronics
Open Source Synergy: Nephio's Collaborative Ecosystem with CAMARA, O-RAN, Sylva, OpenAirInterface, and Kubenet
Panel Discussion
Open Source Synergy: Nephio's Collaborative Ecosystem with CAMARA, O-RAN, Sylva, OAI, and Kubenet
Eric Debau
Head of R&D
Orange
Sylva
Bill Wright�Edge and AI specialist�Red Hat�CAMARA
Welcome to the Nephio Project
Nephio Architecture, Principles, Technology, and Evolution
Nephio SIG Leads
Nephio’s Evolving Architecture
NFVO/Core Orchestration
ORAN Orchestration (SMO)
CRDs
GitOps/CI/CD
Service Orchestration
Infrastructure
Network Fabric
Cloud
Nephio Core APIs
Resources
Inventory
Infrastructure
Config
Workload
Nephio Core Controllers
Token
Bootstrap pkg
K8 Cluster
Repository
Network
Templates
SDKs
Nephio R4 Architecture
Development Process
Nephio Release Process
O-RAN Automation Nephio R4
Joey, Vish, Bala, Stefan
O-RAN Working Group Objectives
Specification of use cases and APIs
Implementation of use cases and APIs
Working group aims to accelerate standards and make Nephio the de facto reference implementation of O-RAN specifications
O-RAN WG2 R4 User Stories
Ongoing:
Backlog:
O-Cloud Registration
O-Cloud Registration
O-Cloud Registration
O-RAN Integration Architecture for Nephio
The Nephio O-RAN WG has agreed upon an Nephio based O-RAN integration architecture
One key aspect of this architecture is that the SMO FOCOM/NFO and the O-Cloud IMS will be implemented with separate Nephio instances / management clusters
The integration between the two Nephio instances will be done only through the O2ims interface
This will provide an SMO/O-Cloud vendor decoupling and also enable non-Nephio based implementations in either the SMO or the O-Cloud
Federated O-Cloud Orchestration
The role for the SMO FOCOM service is to provide federated infrastructure orchestration across multiple O-Clouds
It will integrate towards multiple O-Cloud IMS systems over their O2ims interfaces
Each O-Cloud IMS will expose its site/HW infrastructure through the O2ims Inventory API and support K8s cluster LCM through the O2ims Provisioning API
O-RAN O-Cloud Template
In the O-RAN WG6 O2 Interface General Aspects and Principles specification the concept of an “O-Cloud Template” has been introduced
The template characteristics will also be used to find O-Cloud Sites with matching characteristics and capacity as part of Service Orchestration homing decisions
O-Cloud Templates in O-Cloud IMS and SMO FOCOM
Both a Nephio based FOCOM and a Nephio based IMS will use the KPT/Porch based cluster package management solution implemented in Nephio R1/R2/R3
The IMS-side O-Cloud Template blueprint package is expected to consist of a common part with O-RAN standardized information that will be shared between the O-Cloud IMS and SMO FOCOM, and an implementation specific part with O-Cloud specific artifacts
The SMO-side O-Cloud Template blueprint package will contain the same shared O-RAN standardized properties plus its own FOCOM specific artefacts for southbound integration over O2ims
Nephio FOCOM and IMS integration
The O2ims provisioning interface exposed by the IMS Nephio implementation will provide a declarative NBI towards FOCOM, supporting a “ProvisioningRequest” CR that is aligned with the O-RAN WG6 O2ims provisioning standardization discussions
The FOCOM Nephio implementation must provide a corresponding declarative NBI towards its clients
Detailed Architecture with Nephio Components: NF Deployment LCM
Detailed Architecture with Nephio Components: Cluster LCM
Cluster Creation User Story implementation scope for R4
Nephio R4 IMS scope (1/2)
SMO/FOCOM shall only be exposed to the O2ims standardized ProvisioningRequest CR
The Nephio IMS implementation shall show how the information in the O-RAN O2ims CR is mapped into the Nephio internal workload cluster package deployment
For R4 it is proposed that the existing “nephio-workload-cluster” blueprint is used as the O-Cloud Template
The O2ims ProvisioningRequest CR will contain the following input parameters:�
The “Nephio-workload-cluster” contains manifest files for the Nephio WorkloadCluster and Porch Package Variants
Nephio R4 IMS scope (2/2)
The Cluster1 package deployment will trigger the normal cluster creation workflow in the IMS Nephio management cluster
ConfigSync will deploy the applicable Package Variant CRs in the IMS management cluster that in turn will clone the relevant example packages into the mgmt and mgmt-staging repo
The IMS Nephio management cluster will use internal IMS specific logic to do the actual cluster deployment. This is illustrated here by the “Cluster1 IMS internal Cluster PV” that will clone the package containing the Cluster1 IMS specific CR manifest files
The packages deployed in the mgmt-staging repo will trigger the Cluster Bootstrap Controller to deploy the included manifests into the new Cluster1 workload cluster
Nephio R4 FOCOM scope (1/2)
Each O-Cloud shall first be registered into FOCOM through an “OcloudRegistration” CR
The SMO-level O-Cloud cluster template KPT package is proposed to contain two manifest files with Nephio-defined CRDs
A “TemplateInfo” CRD with the following parameters:
A “FocomProvisioningRequest” CRD with the following parameters:
•Creation of a new cluster is triggered by cloning an O-Cloud Template package blueprint into a Cluster package deployment and updating it with cluster instance specific input
Nephio R4 FOCOM scope (2/2)
As part of the cluster instance package clone/update/approval process there could be KPT specializer functions that are invoked in order to validate the deployment request
When the new cluster instance package has been approved, the ConfigSync operator will reconcile the FocomProvisioningRequest CR into the etcd database
The FocomProvisioningRequest CR is managed by a FOCOM O2ims Operator controller logic
Outside the scope of Nephio R4:
Kubenet
Kubenet
Initiative focussed to help network engineers understand the potential of Kubernetes principles for network automation/orchestration
Open source projects supporting the initiative
Kubenet: Use cases
- Data Center networking
- WAN networking
- Peering
- Access and campus networking
- Core networking
- Backhaul/Fronthaul
- Cloud Networking
Kubenet: High Level perspective
Resources
Network�Design
Network
Business�Logic
Abstract
DeviceConfig
Abstract
DeviceConfig
Vendor
DeviceConfig
Vendor
DeviceConfig
Kubenet: Resources
Node
Link
Port
Endpoint
Adaptor
Module
ModuleBay
IPIndex
IPClaim
ASIndex
ASClaim
VLANIndex
VLANClaim
…
Network
Topology
NetworkDesign
NodeTemplate
…
…
…
Interface
SubInterface
NetworkInstance
BGP
BGPNeighbor
BGPDynNeighbor
RoutingPolicy
Kubenet: Supporting projects
Cloud native YANG
KRM based inventory and identity management (IPAM, VLAN, AS, etc)
KRM orchestration: Kform/Choreo
KRM Package Manager
Want to learn more, join us
Nephio Core Evolution
Nephio Core Evolution: The Path Forward
Problem Statement
Nephio’s Core technology relies on Porch for package management, manipulation, and lifecycle operations, i.e. package orchestration. This core technology is important for Nephio’s narrative supporting declarative models, specialization and distributed actuation. Nephio community observed challenges with Porch maturity, scalability, and stability, hence there is a need to explore and evaluate or just enhance existing core technologies that can realize Nephio requirements and vision and offer a stable development opportunity to focus on Nephio’s mission to mature cloud native Kubernetes based NF orchestration.
We have looked into 4 technologies: Ansible, TKO, Kubenet, Porch and possibly modified Porch. We also intend to look into Argo CD and Flux CD in the near future.
Criteria for Comparison
Package Management Capabilities
Ability to define, version, and manage KRM-based application packages
Integrations, Developers and Adoption
Ability to work with Kubernetes primitives and resources
Availability of third-party integrations and tools
GitOps Support
Integration with Git-based workflows
Support for declarative configurations
Multi-cloud and Hybrid Cloud Support
Ability to work across different cloud environments
Support for on-premises and edge deployments
Package Hydration
Templating and parameterization capabilities
Ability to create and manage reusable, customizable packages (specialization)
Automation and CI/CD Integration
Support for automated deployments and updates
Integration with existing CI/CD pipelines
Observability and Monitoring
Built-in monitoring capabilities
Integration with popular monitoring and logging tools
Compliance and Security
Support for security policies and compliance standards
Secret management capabilities
Extensibility
Ability to create custom resources and controllers
Plugin architecture for extending functionality
Rollback and Version Control
Support for easy rollbacks
Version control of configurations and deployments
Technology Deep Dive
What Is Ansible?
What Is Ansible AWX?
What AWX Can Do for Nephio
AWX and Existing Orchestration Narratives
Live Demo
TKO and Porch
TKO and Porch: Learnings
TKO Inspiration in Porch
Porch Database Live Demo
Choreo: How did we come here?
KRM -> API -> Extendable
Reconcilers -> Day-2 operations
Etcd
Orchestration/�Specialization
Change Management
Version�Control
Packages
Choreo
KRM -> API -> Extendable
Reconcilers
Version�Control
choreo
Choreo
KRM -> API -> Extendable
Reconcilers
Version�Control
removed all the core k8s API(s)
choreo
simplified the reconcilers (starlark, go templating, jinja2) + added run to completion
support dev and prod (live)
support change mgmt
operates client/server side�enables collaboration
state
config
Choreo demo
Choreo
- Simplification:
- starlark, go templates, jinja2 templates, etc
- linux philosophy (do 1 thing and 1 thing well)
- Dependency management: a lower level abstract impact to higher level abstractions
- Hierarchical choreo resources (upstream ref)
- Dev and Prod (state and config)
- Client side/server side
- Collaboration
- Scale:
- Server side apply (granularity at the parameter level)
- Event driven
- Predicates
- Reconciler Goroutines
- Changes are only push when needed
- Backward compatibility
Porch Evolution
My answer to what’s Nephio’s unique selling point is…
Hydration
or more specifically the user experience it provides
Intents can be so complex that they are �created by multiple actors through multiple steps.
Porch Evolution - Why Nephio?
Porch Evolution - same old Nephio R1
Hydration process with PackageVariants (Isti)
Staging�Package
Package�Variant
Staging�Package
Deployment Package
Deployment Package
Deployment Package
Package�Variant
Package�Variant
Package�Variant
Package�Variant�Set
fan-out
Blueprint
Package
Package�Variant
package �vendor’s�domain
customer’s�domain
Approvals and manual editing of configuration makes sense
fully automated closed loops, �no approvals, no manual edits
Published PackageRevisions �of the package
draft
The draft PackageRevision only exists temporarily here, until specialization produces a “ready” state. Then it is automatically approved/published
Staging�Package
Package�Variant
Staging�Package
Package�Variant
Staging�Package
Package�Variant
Merged Data
Porch Evolution
Porch Evolution - embracing readiness gates
Upstream
Package Revision
�
Package Variant
Downstream
Package Revision
Porch Evolution - built-in mutations
Porch Evolution - mutations
Beyond Config Sync
Feature comparison of gitops reconcilers and possible avenues of continuation
Gitops reconciler for O-RAN NFO
Config Sync
FluxCD
ArgoCD
Drop-in replacement for ConfigSync
| FluxCD | ArgoCD |
Can use CAPI’s kubeconfig format (base64 kubeconfig in a secret) | Yes | No |
Can use Token reconciler’s format of secrets (username, password, token keys in a secret) | Yes | Yes |
Can filter out config.kubernetes.io/local-config resources | Yes | No |
Comparison
| ConfigSync | FluxCD | ArgoCD |
Distributed Setup | Yes | Yes | No (can be federated) |
Centralized Setup | No | Yes | Yes |
Git Webhook notifications | No | Yes | Yes |
Documentation | Sparse | Extensive | Extensive |
Project resources
Create an Account:
Follow LF Documentation at: https://docs.linuxfoundation.org/lfx/sso/create-an-account
Please subscribe to the Nephio developers mailing list. You can do that by sending an email to this address: nephio-dev+subscribe@lists.nephio.org You will receive an auto reply requesting subscription validation. The email content is not important.
To join as Supporter:
There are no documents to sign or fees to join, just the form needs to be filled out with the requested information. https://nephio.org/contact/
Nephio R4 Developer Summit - 2024 (Day 2)
Lightning Talk - Service Experience and GenAI (Tomas Achaval - Wilab)
Lightning Talk - Paraglider (Sarah McClure)
Streamlining Cloud Networking
Agenda
Setting: Enterprise Cloud Deployments
VM
Storage Service
Kubernetes Cluster
?
Motivation
Motivation
Approach
Elevate the abstraction by focusing on connectivity needs between resources
Paraglider provisions the network necessary to achieve the requested connectivity
Approach
Cloud network configuration
Interface
Architecture
Orchestrator
Azure Plugin
GCP Plugin
IBM Plugin
…
Tag Service
User Requests
Paraglider Controller
Example:
Goal
Azure
GCP
A
(us-west)
C
B
(us-east)
Example: Paraglider Steps
Example: Paraglider Steps
glide resource create azure vm-b <path_to_vm_config>
glide resource create gcp vm-c <path_to_vm_config>
glide rule add azure vm-b ping default.azure.vm-a
glide rule add azure vm-a ping default.gcp.vm-c
glide rule add gcp vm-c ping default.azure.vm-a
Example:
Under
the Hood
Azure
GCP
A
(us-west)
C
B
(us-east)
Other Features
Roadmap
Ongoing Work
Longer Term
Opportunities for Collaboration
We’re excited to hear from the Nephio community about other ideas!
How to Get Involved
All the above can be found at paragliderproject.io
Lightning Talk & Demo - Nephio for GenAI Automation Use cases (Josh Joseph, Stanford)
Lightning Talk & Demo - Nephio for GenAI Automation Use cases (Josh Joseph, Stanford)
Nephio’s External APIs
Ciaran Johnston, Ericsson
What APIs do we expose?
Custom Resource Definitions
Package Orchestration
https://docs.nephio.org/docs/apis/porch/
Number of APIs have been reduced from 14 to 9
All existing APIs are at “v1alpha1”
Most important elements:
A number of elements have been removed / cleaned up already from the API
Porch API Stabilisation
Phase 1: stabilize fundamental APIs:
Phase 2: stabilize higher-level APIs:
Porch API Stabilization
Repository
GitRepository struct
PackageRevision
PackageRevision specification
PackageRevision 1
PackageRevision 2x
PackageRevision 2y
PackageRevision 2
PackageRevision 3x
PackageRevision 3
Implicit parent relationship
Implicit parent relationship
Forced rebase
PackageRevision #2
Tasks
Upgrade usecases:�1. Upgrade with new blueprint (inherit what you can from previous PR, add in stuff from blueprint, and add/modify instance specific configuration) -- If this doesn't need to be supported, then tasklist can be discarded.
2. Upgrade with new blueprint without inheriting (add stuff from blueprint, add instance specific configuration)
3. Upgrade/update without blueprint change (inherit from previous PR, and add/modify instance specific configuration)
Is there a better way than tasklist?
O-RAN APIs in Nephio
OAI- CU-C/U
OSC INF Edge Cloud (Nephio Workload Cluster)
SMO Services
RAN Domain Management
O-Cloud
SMOS
Communication
A1
IMS
O1
O2ims
DMS
E2
E2E Services
Service Management and Exposure
Data Management and Exposure
End to End Service Orchestration and Slice Management
Service
Orchestration
Service
Assurance
RAN
Analytics
AI/ML
Workflows
Software Packaging Onboarding
Non-RT RIC <rApp>
RAN NF OAM
FM|CM|PM
Physical Network
RU
O2dms (K8s profile)
OFH
E2
OSC SMO (Nephio
Management Cluster)
OSC INF Central Cloud (Nephio Management Cluster)
OSC Near-RT RIC <xApp>
monitori
inventory
provision
lcm
O1
O1
OAI-DU�-RF-SIM RU-
K8s Operators
Topology and Inventory
NFO
Nephio NBI Adapter
FOCOM
Nephio SBI Adapter
Nephio NBI Adapter
OSC Software (Will discuss)
Target CNF for deployment
O-RAN APIs in Nephio
Nephio should play a role in O-RAN as three different components
Supporting these roles requires implementing multi-vendor interfaces and supporting Nephio in 3 different roles interworking with each other
Nephio modelling will refer to O-RAN APIs and models for these interface specifications
* IMS overlaps with Sylva?
OAI- CU-C/U
OSC INF Edge Cloud (Nephio Workload Cluster)
SMOS
Communication
IMS
O2ims
DMS
Service
Orchestration
Service
Assurance
O2dms (K8s profile)
OSC SMO (Nephio
Management Cluster)
OSC INF Central Cloud (Nephio Management Cluster)
monitori
inventory
provision
lcm
OAI-DU�-RF-SIM RU-
K8s Operators
NFO
NFO NBI Adapter
FOCOM
IMS SBI Adapter
FOCOM NBI Adapter
OSC Software (Will discuss)
Target workloads
Multivendor integration points
IMS NBI Adapter
Git / OCI as a formal interface
Does the Nephio community agree with these means of integration towards Nephio?
WG6: GenAI and Nephio
Sana Tariq, Telus
What GenAI Means for Nephio
Templates generation
GenAI based Operators, CRDs, TOSCA, KRM etc.
Templates hydration
GenAI based data-fill for various environments and context
Nephio User Automation Simplification
Nephio Services Closed Loop
SDKs and APIs
GenAI based SDKs and APIs creation
Cloud Optimization
AI optimizing cloud capacity energy and cost
5GC, RAN and Edge
AI optimizing performance, efficiency and reliability
Network Operations
GenAI provisioning and troubleshooting agents
Nephio and GitOps
Custom Resource
Operator (Reconcile)
Current State
Notification
Change Events
Tracking
Act
I want an eMBB network slice with SLA minimum download speeds of 100 Mbps and latency below 20 millisecond …
Deploy 5G core network with a capacity of supporting 10 million concurrent connections and integrate with an ORAN…
Deploy 5G core CNFs SMF, AMF, UPF and Configure ORAN vDU/vCU with xyz…
Intent
Observability tools, notifies about drift in actual state and desired state
Humans writing CRDs and verifying intent
Ensures the running infrasture converge to the desired state notified and declared in CRDs
WG6: Setting up LLMs RAG and next steps…
Large Dataset
Retrieval Model
Pre-trained LLM
Prompt
Response
Prompt
Prompt
+
Code Repo
Config Files
Network troubleshooting and performance analytics
Search
Relevant Documents
Nephio/Organization/ Domain specific Data
Response
WG6: Focus areas and Next Steps
Nephio R4
Friday 9:00 am PT
Nephio R5
Nephio R4 and Beyond
Call for Community!
Newly created Working Group (SIG1/WG6) especially for GenAI Use Case!
Welcome Vendors, Providers, Startups!
Nephio progress Testing/Release
Rado, Bala
Agenda
SIG Release
Current architecture status
SIG Release
GitHub
Prow
Code submission
GitHub Interaction
Status
Reports
Webhook Events
Job Results
Dashboard
One place to check the results and trends
GitHub Bot
Prow ‘slash’ commands
Keeps repository policies applied
Keeps user roles defined and abide
Runs jobs on code/code changes
Simplifies handling code review and merging
GitHub
Actions
Runs some artifact builds and code checks
Docker Images
VM for
E2E tests
What if?
SIG Release
GitHub
Prow
Code submission
GitHub Interaction
Status
Reports
Webhook Events
Job Results
Dashboard
One place to check the results and trends
GitHub Bot
Prow ‘slash’ commands
Keeps repository policies applied
Keeps user roles defined and abide
Runs jobs on code/code changes
Simplifies handling code review and merging
GitHub
Actions
Runs some artifact builds and code checks
Docker Images
VM for
E2E tests
What’s in works for R4
SIG Release
Move some jobs to GitHub Actions
Run simple E2E test on PR content
Release process automation
Development process standardization
Plans for future ahead
SIG Release
WG7: Nephio Transport Use Case
Evgeniy Zhukov - GlobalLogic
Agenda
Why Transport is needed
Transport User Story scope for R4
Deploy 4 Network Elements:
MPLS Tunnels:
Automation:
User Story:
AUSF
NRF
NSSF
SMF
gNodeB
UPF
AMF
Regional Cluster
Edge Cluster
Edge Cluster
Edge02
Edge01
Edge03
Core
N4
Tunnel
N2
Tunnel
N3
Tunnel
Transport Cluster
Nephio Transport Roadmap
R5
R6
R7
Call for Community!
Newly created Working Group (SIG1/WG7) especially for Transport Use Case!
Welcome Vendors, Providers, Startups!
SIG Security Workload Identity -Rahul
SIG4 Security Charter Progress
We started with a score of 3.6
Workload/Service Identity
Workload/Service Identity Provisioning
R4 Plan
R4 Planning and discussions
Bala, Tal, Sana, Rahul, Wim
Review R4 user-stories
Identify ownership
Finalize R4 scope
SIG1 Architecture [ Sana ]
149
SIG2 Automation [Tal & Wim]
150
Realizing Nephio Business Value for Telcos
Technical Director, Bell Canada
Lead Principal Architect, ATT, USA