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

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

We need to align with the ONF Strategic Plan Word Cloud created using https://worditout.com/ What is our current alignment with the ONF strategic plan ? How can we improve it ? – Actions ! https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2018/03/ONF-Strategic-Plan.pdf

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

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

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)

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

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

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…)

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

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

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

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?

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 https://p4.org/p4-spec/docs/PSA.html

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 https://p4.org/p4-runtime/

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

VOLTHA (Broadband Access) Key part of SEBA RD

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

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

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

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.” https://conference.faucet.nz/slides/Sam%20Ribeiro%20-%20gNMI%20tech%20preso.pdf

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.

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

Industry Trends may shape what and how we model

The ThoughtWorks Technology Radar tracks technology trends (January 2010) https://www.thoughtworks.com/radar https://www.thoughtworks.com/insights/blog/microservices-adopt

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

Events and Microservices are a newer approach that may impact us Moving from synchronous ACID distributed transactions to asynchronous message based eventual consistency https://speakerdeck.com/jboner/how-events-are-reshaping-modern-systems https://info.lightbend.com/ebook-reactive-microservices-the-evolution-of-microservices-at-scale-register.html

Standards Body Liaisons Why are they important to us ?

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?

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

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

Strengths, Weaknesses, Opportunities & Threats SWOT Strengths, Weaknesses, Opportunities & Threats

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)

{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 ?)

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

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

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

Model Team Goals and Vision 12 month goals 6 month goals

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

Our Vision summarises where we want to go

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

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

TR-512 v2.0 plan Model structure

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)

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

Event Driven Solutions

There are a number of Event Related Concepts Domain Event - Captures the memory of something interesting which affects the domain https://www.martinfowler.com/eaaDev/DomainEvent.html Commands vs Events (covered in model structure session) Event Sourcing - Capture all changes to an application state as a sequence of events. https://martinfowler.com/eaaDev/EventSourcing.html CQRS - separates events reading and writing https://martinfowler.com/bliki/CQRS.html 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 https://martinfowler.com/articles/201701- 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 ? http://blog.cimicorp.com/?p=3377

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 https://www.thoughtworks.com/insights/blog/microservices-adopt