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

Team Members Leader - Members ???

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.

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 ?

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

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

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

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

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

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)

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

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

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

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. ” https://www.researchgate.net/publication/228717535_Evaluation_of_Multi-Gbps_Optical_Transceivers_for_Use_in_Future_HEP_Experiments

SFP Mapping to LTP ETH

Ethernet Model Elements Will use Wireless Transport for our example attributes

Linking into the Expected Eq Model

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 ? * ?

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

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

Ethernet Model Example and Instance Diagram actual expected expected NO actual

Ethernet Model Example and Instance Diagram expected actual