1. 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

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

3. 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.

4. 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)

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

6. Model Used for instance Diagrams

7. 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

8. NE - Basic Use Case
Cc ex1

9. ‘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.

10. 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

11. Basic Use Case
Cc ex2

12. 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

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

14. ‘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

15. 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

16. 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 …

17. 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.

18. 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

19. 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.

20. 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

21. 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.

22. 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.

23. 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.

24. 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.

25. From other Slidepacks

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

27. 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

28. ‘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

29. 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.

30. 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 *

31. 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 *

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

33. 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

34. 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”

35. Deprecated Slides

36. 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