1. Task xx Scope – Expected Equipment
Purpose –
Specifically –Includes –
Excludes – none
External Dependencies – none
Assumptions – none
Risks – none

2. Team Members
Leader - Members
???

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. Use Cases We need to cover
Equipment is removed from a holder and we want to keep ‘some’ of the ‘configuration’
Equipment is planned to be installed and we want to ‘pre-configure’ a ‘slot’ so when it’s plugged in, it can be ‘auto-configured’. Pre configuration could be for many hardware options.
The need may typically be for ‘port’ configuration but we should not restrict the solution / pattern to just that
To be able to determine when some equipment is plugged in and ‘some or all’ of the pre-config is inconsistent with what is now installed
To be able to decide what to do on equipment removal (policy)
What config to remove
What to keep
To be able to decide what to do on inconsistent equipment install
Just raise an alert ?
Update , delete old config ? Use what we can ?

5. Re-thinking the functionality we wish to achieve
To be able to ‘pre-provision’ hardware, that is to store config values that can be applied when hardware is plugged in to existing hardware
To be able to keep hardware related config values when hardware is removed from existing hardware
To be able to raise an alert if the installed hardware doesn’t match the stored config values expectation
The need of “config values that can be applied ” sounds very much like a Profile, so now we will work through a model from that starting point and see where that leads us
This is not a point for debate ! It’s a thinking mechanism to get us out of a solution rut

6. Define Connector Spec and use the Occurrence pattern
This is in preparation for our later needs
A similar pattern should be applied for Contained FRU

7. A simple(ish) starting point
Config Values
Here we are not really concerned if the profile is ‘soft’ or ‘hard’, just assume ExpectedEqProfile and ExpectedConnProfile contain our values
Connector has been deliberately split out rather than trying to have shared classes (at least for now to keep the semantics clear)
We have a ‘device’ and can attach these values to various pieces of existing Equipment for that device
Obviously there are a few things to clean up, but it’s already starting to make sense
Config Values

8. Applying the Profiles to Equipment Holder
Config Values
Let’s change the Applied Profile to refer to the holder rather than the Equipment
This means that we can now apply profiles to ‘expected’ Equipment that is not there (an empty Holder)
This can be thought of as “apply these config values to any Equipment in this Holder if the Equipment is of one of these types”
Note that things are now a bit inconsistent with Connector
Note connector profile etc. not shown

9. Replacing ‘Device’ with ConstraintDomain
Config Values
We will use ConstraintDomain to represent the ‘device’ boundary
Rather than giving CD more responsibilities of containing the profile applications, we will reverse the dependency and decorate a new class onto CD
This model will suffice for ‘1 level’ hardware, but not for nested hardware, like removing an item with plugins (such as a line card with SFP)
The Connector profile application also still looks inconsistent compared to Equipment
Note connector profile etc. not shown

10. Adding Placeholder Eq to support multi-level Eq
This will enable us to get away from applying profiles to Equipment Holder while ensuring the EqConfig is always linked to something.
Many Placeholder Equipment can ‘occupy’ a real holder (even if there is real Eq in the holder)
Placeholder Holders can only hold Placeholder Equipment
Placeholder entries have an id attribute and not much else (the Spec should cover the rest), so Placeholder subclassing Equipment wouldn’t make sense (as it has less attributes than real equipment)

11. With Placeholders, the Association from AppliedEqProfile to EqHolder can be removed
Functions
Config Values
Config Values
Note EquipmentHolder not shown

12. Sanity Checking what we have
We can have an empty Chassis and ‘pre-provision’ it by adding in placeholder Modules in the slots. Then we can attach profiles to the placeholders. When a Module is plugged in a slot, we can see if it matches any of the placeholder Spec classes (or the placeholder could have a match Constraint attached). If we get a match then the profile can be applied to configure the Module. Then the placeholder records could all be removed (or kept).
Assume we have a Module in a Slot and there are no placeholders. The Module is removed. The removal event triggers the creation of a placeholder Module and the current config is saved in the profile. The profile can then be restored if another card of a compatible type is later installed in that position.
These 8 new classes link nicely into the existing model classes (white fill) by decorating on top of them

13. Converting the Placeholders to Constraints
Currently the Placeholder classes don’t have any function other than as Profile attachment points
They could easily be converted into Constraint classes so that we could constrain by more than just by type of Equipment

14. SFP Example
From “Amaral, Luis & Troska, Jan & Jimenez Pacheco, Alberto & Dris, Stefanos & Ricci, Daniel & Sigaud, Christophe & Vasey, Francois. (2019). Evaluation of Multi-Gbps Optical Transceivers for Use in Future HEP Experiments. ”

15. SFP Mapping to LTP
ETH

16. Ethernet Model Elements
Will use Wireless Transport for our example attributes

17. Linking into the Expected Eq Model

18. We don’t want to have to make the <<Decorates>> 0
We don’t want to have to make the <<Decorates>> 0..1 at the decorated end, so we need to have a lifecycle state in LTP and pre-provision LTP / leave LTP when Eq removed
Simplifying the model ?
* ?

19. Does Logical Signal Help ?
Class diagram copied from ONF_Txx_ConnectorPinStrand.pptx
Does Logical Signal Help ?
The key difficulty here is that we are configuring a LTP based on a connector.
LogicalSignal links LTP and connector, but doesn’t seem to help in this case

20. Ethernet Model Example and Instance Diagram1 2 3 4
Chassis with 4 slots. Slot 1 occupied with 4 Eth port card
Slot 2 pre-configured / or had 2 port card

21. Ethernet Model Example and Instance Diagram
actual
expected
expected
NO actual

22. Ethernet Model Example and Instance Diagram
expected
actual