Task 2a Scope – Processing Construct (L=ChrisH) Purpose – look at aligning PC with TOSCA node concept Specifically – produce a presentation pack and present to TOSCA at our Nov face to face Includes – updating the PC document and model as required Excludes – External Dependencies – dependent on TOSCA availability and interest Assumptions – That TOSCA is interested in aligning with us Risks – TOSCA may not be available in Santa Clara to meet in person

Team Members Leader - Chris Hartley chrhartl@cisco.com Members Nigel Davis

IPR Declaration Is there any IPR associated with this presentation NO NOTICE: This contribution has been prepared to assist the ONF. This document is offered to the ONF as a basis for discussion and is not a binding proposal on Cisco or any other company. The requirements are subject to change in form and numerical value after more study. Cisco specifically reserves the right to add to, amend, or withdraw statements contained herein. THE INFORMATION HEREIN IS PROVIDED “AS IS,” WITHOUT ANY WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Background In the ONF OIM&T team, we came to the realization that our use of the traditional concept of NetworkElement was overloaded and needed to be replaced NetworkElement typically is a coarse grain concept that involves some combination of physical and management scopes In many cases, NetworkElement functional scope is assumed to align with both the physical and management scopes (e.g. a ‘Router chassis’) We wanted to replace it with something better aligned with function blocks in a network

NE replaced by PC and CD In the end, we replaced NetworkElement by ProcessingConstruct (PC) and ConstraintDomain (CD) classes ProcessingConstruct represents a block of functionality (in a network) ConstraintDomain is a general scoping class, which can be instantiated to represent the (possibly different) physical and management scopes PC and CD allow for a consistent representation of : Partitioned ‘devices’ Distributed ‘devices’ Partitioned + Distributed ‘devices’ ‘Virtual’ ‘devices’ The finer grained functional focus also enables a more natural topological representation ProcessingConstruct and ConstraintDomain also align better with software application derived functionality

Example : Open vSwitch http://openvswitch.org/ (Slightly redrawn for clarity) Diagram from http://openvswitch.org/support/dist-docs/ovs-vswitchd.conf.db.5.pdf Table Purpose   Open_vSwitch Configuration for an Open vSwitch daemon. There must be exactly one record in the Open_vSwitch table Bridge Configuration for a bridge within an Open_vSwitch. A Bridge record represents an Ethernet switch with one or more ‘‘ports,’’ which are the Port records pointed to by the Bridge’s ports column. Software Process ProcessingConstruct

Network Element to PC BGP PC Application View Chassis – Chassis topology isn’t really helpful Emergent BGP control plane network mesh ‘Chassis boundary CD’ Transport View BGP PC Emergent PTP network tree LTP PC Port PTP (Time) PC PTP (Time) PC Emergent ERPS network ring G.8032 ERPS PC G.8032 ERPS PC G.8032 ERPS PC Bridge PC

ERPS Network Example CD=ERP Main Ring CD=“NE” Node Ring Inst. P0 P1 Node Ring Inst. P0 P1 CD=“NE” Node Ring Inst. P0 P1 CD=“NE” Node Ring Inst. P0 P1 Node Ring Inst. P0 P1 Node Ring Inst. P0 CD=“NE” Node Ring Inst. P1 CD=“NE” Constraint Domains can provide arbitrary, overlapping groupings. Here the NE scopes cross Ring scopes CD=“NE” Node Ring Inst. P0 P1 CD=ERP Sub Ring Note NE TPE/LTP not shown. ERP node local ports not shown, R-APS channel not shown represents local port connections between ERP nodes. An ERP Node is not a “NE”

Second principle of OOD “Favour object composition over class inheritance” [GoF], p.20) To avoid confusion (such as thinking this means to use composition associations instead of inheritance), we will rephrase this as “Favour assembling objects over class inheritance” Object composition is often implemented in code using method delegation Subclassing is often called ‘white-box reuse” and object assembly as ‘black-box reuse” PC and CD objects are designed to be composed into useful assemblies, NE was not

Note the model style – little or no subclassing too TR-512.11_v1.3_OnfCoreIm-ProcessingConstruct.docx, Fig 3-3 Resultant Model Because of the overlap of functionality between ConstraintDomain and ForwardingDomain, it makes sense to review if ForwardingDomain is needed as a separate concept or if it can be deprecated in a future release. For example, one driver for its deprecation would be if we found we were constantly creating CD/FD pairs with the same scope. Note the model style – little or no subclassing too

Think of the network as composed of PC, connected via FC Conclusion While the change hasn’t been easy (as NetworkElement was a fundamental class in our model), we believe that this change provided a stepping block for moving forward with our model. There are some challenges in choosing ProcessingConstruct vs ForwardingConstruct. Basically FC forwards with minimal processing PC processes with minimal forwarding If there is significant processing and forwarding, then perhaps an instance of each may be required Think of the network as composed of PC, connected via FC