1. Strategy and Direction
Nigel, Chris, Lyndon
Ottawa 2018 – Day 1

2. ONF Strategic Plan & Projects
CORD
MININET
ONOS
OPEN TRANSPORT
STRATUM
TRELLIS
VOLTHA
XOS

3. We need to align with the ONF Strategic Plan
Word Cloud created using
What is our current alignment with the ONF strategic plan ?
How can we improve it ? – Actions !

4. ONF Partner-Level Members
ONF is an Operator-led organization
Operator Partners: AT&T, China Unicom, Comcast, DT, Google, NTT & Turk Telekom
Innovator Members includes 14 other large operators including China Mobile, Microsoft, Telefonica, Vodafone, & Verizon
ONF Supply-Chain Partners today (May 2018)
Accton/Edgecore, Adtran*, Ciena, Dell, Intel, Juniper, Radisys, Samsung

5. Open Source Components
ONF New Processes
Leading to more deployment?
Need key Operators to pledge to buy the results
Exemplar Platforms
Solutions
Trials
Reference Designs
Deployments
Open Source Components

6. ONF Expanded Structure
ONF Leadership and Decision Making:
Operators with 1 at-large board member
ONF Board
Partner-level Operators guide and steer the ONF
Partner-level Vendors assist in technical directions
Operators
TLT
Operators & Invited Supplier Partners
RDT
RDT
RDT
Operator Biased, with Ecosystem represented
UCST
At the project level, open source: technical meritocracy drives leadership
(Including Exemplar Platform work)
Elected Seats Technical meritocracy
With any mix of operators and ecosystem
Component Proj TST
TLT – Tech Leadership Team (Comcast, chair); RDT – Reference Design Teams (led by operators)
UCST – Use Case Steering Team (existing, led by operators); TST – Tech Steering Team (existing)

7. Reference Designs (note 2 Wireless “Pathfinder” Projects also)
ODTN
Reference Design
SEBA – SDN-Enabled Broadband Access
NFV
Fabric
UPAN – Unified, Programmable & Automated Network
NEM (XOS+FCAPS)
ONOS
VOLTHA 2.0
Trellis
ONOS
OF Whitebox
ONOS
TAPI
OpenConfig
Components of ONF Exemplar Platform
Stratum
ONOS++ P4
Trellis
AT&T
Deutsche Telekom
NTT
Türk Telekom
Comcast (deployed and testing)
Google
NTT
Comcast
Operator Support

8. Pathfinder Projects M-CORD Multi-Access Edge General area – Edge Cloud
Greater focus on peer relationships/interfaces
Multi-tenant environments
P4 controlled PNF

9. Reference Design Commonality
Operator 1
SEBA
Operator 2
SEBA
Operator 3
SEBA
Common Software Infrastructure
2 Sources of Operator Leverage
Common Components (ONOS, Trellis…)
Common Reference Designs (SEBA…)

10. Reference Designs Drive Exemplar Platforms Which Underpin Production
ONOS, Trellis...
Develop Components
Exemplar Platforms
Based on RDs
(SEBA…)
Integrate Artifacts/HW
Exemplar PoC
ONF engineering
focus
Supplier engagement
Ecosystem
participation
Test or Trial systems
Integrate Exemplar with rest
of System components
SP specific - other open source and proprietary software
Develop Components
Production systems
Operator focus

11. ONF Open Source Components/Exemplars
Other Open Source
Custom SW
Supplier SW
HW/Existing Systems
Production Systems
A production system is a combination of open source, proprietary and custom software integrated with hardware and existing systems.
ONF* creates open source components and exemplar platforms instantiating common reference designs (RDs).
*ONF == entire ONF community, not just ONF employees

12. ONOS / CORD / XOS
CORD
Need to get Core on this picture (or understand mapping)
XOS
Drive for tooling
ONOS
Need to get TAPI on this picture

13. Open Transport TAPI - Aligned with CIM Wireless and other Tech Models
Part of ODTN (operator driven)
ONOS NBI (multi-technology, multi-domain)
OLS Controller NBI (Photonic/abstraction, single-domain)
Other opportunities?
Wireless and other Tech Models
PoCs, ONAP integration
Other ONF projects? Pathfinder Wireless RDs?

14. P4 Language Could we generate P4 ? Would that make sense ?
More likely that we could define data structures that could be filled out to generate P4
Rules and intent
Do the same work we did with OpenFlow

15. P4 Runtime (NMI) https://p4.org/p4-runtime/
Source Code
P4 Network Management Interface
Uses ProtoBuf messages sent via gRPC to manage the P4 tables on the device (create / read / edit / delete)
There is a CLI interface that looks to be easier to understand than the Protobuf messages

16. Trellis (Data Center Switching)
Part of NFV Fabric RD
Need to get Core on this picture (or understand mapping)

17. VOLTHA (Broadband Access)
Key part of SEBA RD

18. Operator Systems / Backends
UPAN RD from 10,000’
UPAN – Unified, Programmable & Automated Network
Reference Design for Stratum
Unify whiteboxes with different switching chipsets
Focus on data center and edge cloud
Note showing both SBI and NBI, Topology model
Unified Control Plane
Control, Configuration, Management, Telemetry, Inventory, Orchestration
Data Plane
Switches, Routers, Network Functions
Unified gRPC Interfaces - P4Runtime, gNMI, gNOI
Unified gRPC Interfaces and Models - WIP
Operator Systems / Backends
OSS/BSS, Global Orchestrators, Policy Engines, Inventory Databases, etc.
Scope for UPAN RD
Debugging, Network Verification, Testing
Tool Kit

19. UPAN Exemplar Platform - Extend to the Access Edge?
Inventory
DHCP Server
ONOS ++
NNI
OLT
ONU
UNI
P4Runtime
gNMI (OpenConfig - QoS)
gNOI
vOLT
dhcp SR
SDN Control Services
P4Runtime
Config & Admin Services
gNMI (OpenConfig)
gNOI
Monitoring & Telemetry Services
gNMI
Orchestration Services
VOLTHA + Stratum
spine.p4
leaf.p4
+ bng.p4
Stratum

20. Exemplar Platform Components
ONOS ++ - evolution of the ONOS SDN controller platform to support the unified control plane
Control services - provide runtime control of P4 defined pipelines via P4Runtime
Config & admin services - provide config and operations support via gNMI and gNOI
Monitoring & telemetry services - provide visibility into network elements, enabling enhanced troubleshooting throughout the network
Orchestration services - resource and network aware orchestration of VNFs on compute resources on servers and networking devices
Trellis - extended to include a P4 fabric
Stratum - switch agent providing providing control, config, and operations via P4Runtime, gNMI (using OpenConfig models), and gNOI

21. STRATUM
“gNMI with OpenConfig data models is used to manage device configuration. Initial work in SDN did not address these requirements, and instead SNMP, Netconf and CLI were used in an ad-hoc manner (inhibiting interoperability)”.
“gNOI is used for operations, for one-time events like device testing or reboots that do not require maintenance of state. This too was not specified in earlier SDN initiatives, resulting in inconsistent implementations and limiting interoperability.”

22. Stratum (continued) OpenConfig Yang
Based on OpenConfig work
Having JSON + Protobuf generators would allow us to provide equivalent artifacts (+ Python and Go generators ?)
Adding Command & Event definitions would align with telemetry streaming
gNMI - The set of actions that are allowed between Client and Server is defined by a Service Definition, which is also a Protocol Buffer
gNMI is a unified management protocol for streaming telemetry and configuration management that leverages the open source gRPC framework.

23. We need to determine any ONF Project Actions
Which Project(s) to target ? – prioritize
How can we add value to them – think from their point of view
Action plan !
Demonstrate relevance
Takes work to bridge
Need to identify mutual value

24. Industry Trends may shape what and how we model

25. The ThoughtWorks Technology Radar tracks technology trends
(January 2010)

26. Some technology best practices trends impact how we should model
Greater emphasis on modularity – don’t want a monolithic model – need to modularise model and manage dependencies – gives implementations the ability to scale up and scale down
Need to support implementation modularity – NMS monolith on Physical Server  Virtual Machine  MicroService1 on Container
Greater emphasis on Commands and Events (streaming telemetry) – less on database CRUD. If components react to and generate events, then we achieve a form of behaviour closure
1http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html

27. Events and Microservices are a newer approach that may impact us
Moving from synchronous ACID distributed transactions to asynchronous message based eventual consistency

28. Standards Body Liaisons
Why are they important to us ?

29. Current Standards Body Liaisons
ITU-T – not reinvent. Ownership. Detailed technology.
MEF – Ownership, route to ONAP, unification of standards work
TOSCA – Cloud relevance, similar patterns, they need our model (although they have not fully realized yet), new techniques, orchestration
IEEE
OIF
TMF
ETSI? IETF?

30. Possible Future Standards Open Source Body Liaisons
ONAP – carrier relevance, potential proving ground, link to MEF
Linux Foundation

31. We need to determine our reason for liaising with each body – rewards & risks
Each additional body takes effort – don’t want to spread ourselves too thin
We need some level of strategic alignment with the other body
We need to be careful of trying to please everyone and end up pleasing no-one

32. Strengths, Weaknesses, Opportunities & Threats
SWOT
Strengths, Weaknesses, Opportunities & Threats

33. Brainstorm these as a team.
SWOT Stage 1
Brainstorm these as a team.
A good way is to draw the table on a whiteboard and use yellow sticky notes for each item (allowing them to be added quickly and easily moved and consolidated)

34. {Project Name Here} SWOT
Internal
Strengths (Build On)
Weaknesses (Resolve these)
External
Opportunities (Exploit these – what are benefits of doing ?)
Threats (if nothing is done – how do we avoid these ?)

35. SWOT Stage 2
Once the Strengths, Weaknesses , Opportunities and Threats have been determined, use the next slides to determine actions that can be taken to exploit / address them

36. Determining SWOT Actions
Strengths
Weaknesses
Add these actions to the Project Plan
Opportunities
List actions that can be performed by utilising our strengths to take advantage of these opportunities
List actions that can be performed by utilising our strengths to minimise the likelihood and impact of these threats
List actions that can be performed to overcome our weaknesses to take advantage of these opportunities
List actions that can be performed by overcome our weaknesses to minimise the likelihood and impact of these threats
Threats

37. {Project Name Here} SWOT Actions
Strengths
Weaknesses
Add these actions to the Project Plan
Opportunities
Threats

38. Model Team Goals and Vision
12 month goals
6 month goals

39. Definition of Strategic Planning Terms
Project Vision / Mission
Principles : defines fundamental truths to be used in constructing the plan
Vision : The overall statement of where we want to be after the plan is implemented
Goal : an outcome that we want to attain to move towards the vision
Strategy : an approach (or path) to achieve one or more Goals (can think of as general types of Initiatives)
Initiative : specific tasks to be performed in the project
Alternative : If there is more than one sensible way of achieving the Goals then these Initiative groupings can be compared and the best one chosen (based on resources, risk, time to achieve ...) 1 *
Goal *
Why ?
How ? *
Strategy * *
Initiative * *
Alternative

40. Our Vision summarises where we want to go

41. Our 12 month strategic goals implement our vision
These can be broken down into actual tasks on Day 5

42. Our 6 month tactical goals implement our vision
These can be broken down into actual tasks on Day 5

43. TR-512 v2.0 plan
Model structure

44. Strong Architectural rules are needed to grow our models
This is a complex topic with many subtle interactions, which will be covered in detail in the later 1 ½ hour session (~ 30 slides), so what I can say in 10 minutes is :
Real modularity and dependency management is key, and from that flows the required modelling rules
Once we have the rules agreed, we need to determine the impact on the existing model
We really need some sort of tooling support to close the loop and allow us to easily determine rule compliance – repeated manual checks will be very hard to enforce
These principles aren’t new or controversial in the modelling industry at large – they are considered current ‘best practice’, but they are likely to be a paradigm shift for many network management modellers who are still modelling like we did back in the 1990s (e.g. large inheritance trees)

45. Further model structure thoughts
The best way of enforcing the rules would be in the modelling tool. Another option is some sort of validator (similar to a language generator) that can be run over the model, manually or as part of a continuous build process on model check-in
Some network management models qualify as ‘worst practice’ examples, for example having a ‘rooted’ inheritance tree – where every class inherits back to a ‘top’ or ‘root’ class – an obvious anti-pattern

48. Event Driven Solutions

49. There are a number of Event Related Concepts
Domain Event - Captures the memory of something interesting which affects the domain
Commands vs Events (covered in model structure session)
Event Sourcing - Capture all changes to an application state as a sequence of events.
CQRS - separates events reading and writing
Events are key to making microServices work (distributed systems)
Event Storming is a group meeting technique to uncover events in a problem domain
This video compares a number of these event driven architectural options event-driven.html
OpenConfig and Stratum seem to be based on a sort of event driven architecture (using ProtoBuf messages)
Events are a critical part of ‘serverless’ cloud function efforts like Amazon Lambda, Microsoft Azure Functions and Google Cloud Functions
Is a controller just a cloud function ? What can we learn from cloud for networking ?

50. How should we react to this ?
Does it require us to think differently (verbs vs nouns) ?
What are the implications for the current model ?
What work items should we add to the task register ?
Does it make sense to prototype something ?
Some of the issues in adopting microservices