Task 2b Scope – Processing Construct (L=ChrisH) Purpose –re-look at ControlComponent vs ProcessingConstruct Specifically – recommend how to align PC and CC Includes – updating the PC document and model as required Excludes – updating the control document or model External Dependencies – solution for ControlComponent will depend on Task13 Assumptions – that task 13 completes in time Risks – task 13 is late and we can’t make these changes

Team Members Leader - Chris Hartley chrhartl@cisco.com Members Nigel Davis Malcolm Betts Augie J

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.

TR-512.8_v1.3_OnfCoreIm-Control.docx, fig 3-3 Background The key question is if ControlComponent is actually needed at all If it’s just a copy of the PC / CD model, what value is it adding ? Control component seems oddly absolute (this is a CC, this is not) where a more sensible model would be a relative role (PC controls / is controlled by PC) ControlSystemView is not really a view but a boundary of control ConstraintDomain and ControlDomain are both examples of constraint boundaries (as is ForwardingDomain) ControlConstruct CtC Controls CD (ManagementAgent) ControlConstruct Controls ControlDomains CD Constrains CtC CD Constrains CD ControlDomain (ManagementContext)

Suggested CIM changes based on Software work CdRepresentsEqBoundary * FdConstrainsFc * AsymmetricCdHasPorts AsymmetricPcHasPorts AsymmetricFdHasPorts 0..1 FdPortAllowsFcPort SymmetricFd IsBoundedByLtp SymmetricCd IsBoundedByLtp FcPortBoundToLtp SymmetricPc IsBoundedByLtp *

Model Used for instance Diagrams

NE - Basic Use Case Before After addition of CtrlConstruct and CD for control domain CD = Phy(Chassis) CD = Phy(Chassis) CD = NE CD = NE Ctrl Construct Port CtrlConstruct controls CtrlDom Note, to keep the diagrams simple, we are using PC to represent all of the functions PC, LTP, FC, FD, SoftwareProcess … CD=CtrlD PC PC PC PC

NE - Basic Use Case Cc ex1

‘Traditional’ Representation- Revisited NE1 NE2 Management Plane MC MC Root MC per MA Control / Data Planes Logical View Root CD per physical scope Physical Root per physical scope Physical View We see that this is just a special case, where we can easily draw the NE boundaries. Root MC, Root CD and Physical Inventory have same scope.

Basic Use Case CD = Network CD=CtrlD Port CD = NE Port CD=CtrlD PC PC Ctrl Construct Port PortBound ToPort CD = NE Master Ctrl Construct Port CtrlConstruct controls CtrlDom Slave CtrlConstruct controls CtrlDom CD=CtrlD PC PC

Basic Use Case Cc ex2

Why we don’t have a Control Domain Class If we had a separate ControlDomain class, then we would need to associate it to PC, LTP, FC, FD, SoftwareProcess …, duplicating the ones from CD to these classes

The basic model ControlDomain is a ‘hub class’ (similar to LTP) that decouples separate parts of the model

‘Controller’ Via LTP, Link, FC etc. CD=CtrlD CD = NE CD=CtrlD Port PC CtrlC Controls CtrlDdom CD=CtrlD CD = NE CdConstrainsFD CD=CtrlD Ctrl Construct Port PC Ctrl Construct Port FdConstrainsFc PortBound ToPort Slave CtrlConstruct controls CtrlDom PC Master CD=NE CD=CtrlD Ctrl Construct Port Ctrl Construct Port PC PC CtrlConstruct controls CtrlDom Allows for primary and secondary controllers etc. (CtrlC role in a CD=CtrlD) CtrlC Controls CtrlDdom CD=CtrlD

What about a control port to PC port binding ? It could be possible to add ports to every construct for control purposes and then bind these to the control construct ports This may make sense architecturally and provides a nice consistency, but : Locally within a NE, the binding is usually implied rather than explicitly defined and managed (I define a BGP process via the control construct so its binding is implicit) It adds a lot of complexity to the instance graph, to create and manage all these ports and bindings Since we expect some sort of local management agent, the bindings are local, so there are no transport (via FC ) implications CD = Phy(Chassis) CD = NE CD=CtrlD CtrlC Controls CtrlDdom PortBound ToPort Slave Ctrl Construct Port Ctrl Construct Port PC Master PortBound ToPort Slave Master

Why we are showing the NE boundary The NE concept is deeply ingrained and it will help people to relate the new concepts to the old The following scenarios are ones where the NE concept was problematic and there may be more than one way that people may consider the NE to be defined Hopefully over time the NE concept will be replaced by the use of the Physical and Control Boundaries as well as a more meaningful focus on the network functions PC, LTP, FC, FD, SoftwareProcess …

Constraint Domain (CD) enforces scope constraints Device Partitions Management context per partition MC MC Management Plane MC Root Mgt Context scoped by Management Agent Management Context Processing Constructs scoped within the partition CD’s Control/Data Planes Logical View Partition scope constraint boundary Constraint Domain (CD) enforces scope constraints CD per partition Equipment scope constraint boundary Root CD based on ‘chassis’ physical scope (really backplane / scope of address and data busses) Pattern in Combine Partition Pattern.pptx Physical View The management plane may be global or partitioned, or both (as shown). Root MC, Root CD and Physical Inventory have same scope.

Device Partitions CD = Phy(Chassis) CD = NE(Root) CD=CtrlD(Root) ControlConstruct per partition + root CtrlC Device Partitions CD = Phy(Chassis) Master CD = NE(Root) Ctrl Construct Port Slave CtrlConstruct controls CtrlDom CD=CtrlD(Root) CD = NE CD = NE Ctrl Construct Port Ctrl Construct Port CtrlConstruct controls CtrlDom CtrlConstruct controls CtrlDom PC CD=CtrlD CD=CtrlD PC PC PC PC PC

Distributed Device – Separate MA Management Context Aggregated MC Management Plane Root MC per MA MC MC MC Distributed PC Control/Data Planes Logical View Separate PC Aggregation scope constraint boundary Aggregated CD Equipment scope constraint boundary Root CD per physical scope Equipment with PhysicalConnectors and PhysicalLinks Physical View The management plane may be global or partitioned, or both (as shown). Root MC, Root CD and Physical Inventory have same scope.

Distributed Device – Separate MA CD = NE Master CD = Phy(Master Chassis) CD = Phy(Remote Chassis) CD=CtrlD Ctrl Construct Port optional Ctrl Construct Port Slave CtrlConstruct controls CtrlDom CtrlConstruct controls CtrlDom CD=CtrlD CD=CtrlD PC-1 PC-2 PC-3

Distributed Device – Single MA Management Plane MC Root MC per MA Distributed PC Control/Data Planes Logical View Separate PC Aggregation scope constraint boundary Aggregated CD Equipment scope constraint boundary Root CD per physical scope Physical View Here a single MA manages the complete distributed device. Root MC has different scope from Root CD and Physical Inventory.

Distributed Device – Single MA Slave CtrlC not externally accessible CD = NE Master CD = Phy(Master Chassis) CD = Phy(Remote Chassis) CD = Phy(Remote Chassis) CD=CtrlD PortBound ToPort Master Slave Ctrl Construct Port Ctrl Construct Port Slave CtrlConstruct controls CtrlDom CD=CtrlD CD=CtrlD PC-1 PC-2 PC-3 Via LTP, Link, FC etc.

Distributed Device – Split Chassis Management Plane Root MC per MA MC-A+B+C MC-D MC-E Distributed PC Control/Data Planes A+B+C Logical View D E A B D Separate PC Aggregation scope constraint boundary C E Aggregated CD Partition scope constraint boundary A + B + C CD per MA scope B D C E Equipment scope constraint boundary Root CD per physical scope A Physical View The management plane may be global or partitioned, or both (as shown). Root MC, Root CD and Physical Inventory have same scope.

Distributed Device – Split Remote Chassis Master CD = NE Master CD = Phy(Master Chassis) CD = Phy(Remote Chassis) CD = Phy(Remote Chassis) CD=CtrlD PortBound ToPort Master Ctrl Construct Port Slave Ctrl Construct Port Slave CtrlConstruct controls CtrlDom CD=CtrlD CD=CtrlD PC-1 PC-2 PC-3 CD = NE Ctrl Construct Port Slave CD=CtrlD PC-4 Via LTP, Link, FC etc.

From other Slidepacks

Suggested CIM changes based on Software work CdRepresentsEqBoundary * FdConstrainsFc * AsymmetricCdHasPorts AsymmetricPcHasPorts AsymmetricFdHasPorts 0..1 FdPortAllowsFcPort SymmetricFd IsBoundedByLtp SymmetricCd IsBoundedByLtp FcPortBoundToLtp SymmetricPc IsBoundedByLtp *

Constraint Domain (CD) enforces scope constraints ‘Virtual’ Device Management context per partition MC MC Management Plane MC Root Mgt Context scoped by Management Agent Management Context Processing Constructs scoped within the VM/Container CD’s Control/Data Planes Logical View Partition scope constraint boundary Constraint Domain (CD) enforces scope constraints CD per VM or container Equipment scope constraint boundary Root CD based on ‘chassis’ physical scope (really backplane / scope of address and data busses) Pattern in Combine Partition Pattern.pptx Host Physical View

‘Virtual’ Distributed Device Management Context Aggregated MC Management Plane Root MC per MA MC MC MC Distributed PC Control/Data Planes Logical View Separate PC Aggregation scope constraint boundary Aggregated CD CD per VM Equipment scope constraint boundary Root CD per physical scope Host Physical View Equipment with PhysicalConnectors and PhysicalLinks Host Host

Proposed Model – Linking into the CIM Core PC unlikely to be directly Hardware related. FC, FD & LTP are more likely to be directly hardware related, but they would be best linked via CD anyway.

Proposed Model – Linking into the CIM Core Linking the inventory model to the Location model via CD decouples the two modules. It allows inventory items to be grouped, reducing the number of association instances to be managed and also giving more sensible semantics. It also reduces the number of associations in the model. * CdHasRelatedLocationRoles *

Proposed Model – Linking into the CIM Core Linking the inventory model to the Party model via CD decouples the two modules. It allows inventory items to be grouped, reducing the number of association instances to be managed and also giving more sensible semantics. It also reduces the number of associations in the model. * CdHasRelatedPartyRoles *

TMF TR-225 didn’t have CD to use as an intermediate grouping class

ERP G.8032 Concept Example Ports to local Network CD=“NE” Eth0 Eth1 CD=ERP Node X PortBoundToLTP ERP Node could be only one of many functions in the “NE” Perhaps has PTP BC too !! Port Possible that a NE could contain >1 ERP node ? CD=ERP Node X Ring Y Ctrl Construct ERP Node X Ring Y Instance Z ControlConstruct Controls ConstraintDomain FC Port0 = East Port1 = West P0 P1 Eth4 Eth5 Peer ERP Node Peer ERP Node

ERP Network Example 1 Port CD=ERP Main Ring Ctrl Construct ControlDomain Controls ConstraintDomain CD=ERP Main Ring CD=ERP Main Ring Ctrl Construct 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” 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”

Deprecated Slides

Basic Use Case (With CtrlDomain) CD = Network CtrlD Ctrl Construct Port CD = NE Ctrl Construct Port CtrlConstruct controls CtrlDom CtrlConstruct controls CtrlDom CtrlD PC PC