1. Task 57 Scope – Profile and Template
Purpose – To Propose a Template / Profile to meet Thorsten’s needs
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. Initial Requirements (From Work Task List)
The attributes inside such profile could be of composed datatypes, but would have concrete values, no value ranges.
It would be good, if attributes inside such profile would not be invariant, so they could be changed after instantiation of the profile.
It would not be necessary to be able to individualize the values depending on the referencing instance of the LTP.
There are no limitations, which are individual to the referencing instance of the LTP, to the values inside the profile.
Several profiles might be referenced in an instance of the LTP, but they would be disjunct. Wondered, whether it would be possible to add a generic “Profile” class to the ONF Core IM, which could be loaded with *_Pacs in the same way, which we are currently using for loading the LayerProtocol class.

5. Questions Do we need ? Template version ? Profile version ?
Do you want a class / attribute style structure or a (Yang like) tree style structure or just a bag of attributes (no structure) ?
Use of generics will simplify the result with type safety
Also need to consider event / Kafka support !
Basic Type Square Pattern

6. Basic Starting Point Soft Properties based model

7. Applying a Soft Template to a Soft Model – attempt 1
There is an obvious issue because we don’t really want separate Template attribute definitions
!!!

8. Applying a Soft Template to a Soft Model – with the Occurrence pattern
Soft-soft pattern
Note that we allow a Template to ‘override’ the attribute validation & defaultValue
Note that there is a temporal aspect here that we don’t show, when the profile was applied to the model. We also can’t know if the application actually changed the value or not.
This would be much better in a Kafka log where we can see the changes over time
+ validationPattern (constraint) ?
+ keyValue ?
Replace with
configuredValue +
operationalValue ?
Profile Application

9. Soft Template with locked model value
@ - In this case we have either
1- a normal attribute value Or
2 – a (readonly) reference to a profile value
Soft Template with locked model value
Note that now profile / template and the normal model are intertwined so they effectively become a single model (still splits along operational / knowledge lines) @ #

10. There are 4 basic hard / soft representation options
Model
Soft
Hard
Profile / Template  
Not sensible
Soft = Soft Properties, Hard = normal attribute
For the hard – hard option
Need the attributes in a ‘PAC’
Then the profile is just an instance of the PAC
Do we need the profile to populate ALL values in the PAC ? Do we need all the attributes in the PAC to allow null ? Or extend the metamodel to allow for this ??
Some attributes may not be profile settable and this can be represented too (2)
(1)
(2)
Hard-hard pattern
Profile metadata attribs
(3)

11. Don’t forget to apply the decoration pattern here too
Could be mix of both – composed core attributes and decorated feature attributes
Default values
Could be done using a ‘default’ profile instance
Could be done by adding another assoc from AAttributesClass to AClass

12. There is an issue with applying a soft profile to a hard class model
We don’t have an easy way of relating a soft property to a ‘hard’ attribute
The underlying problem is that the soft property model is representing the UML metamodel as a model so for hard-soft we are trying to associate across meta-layers !
In fact it’s even worse than that, as the soft model could relate to any / every attribute / Entity in the ‘hard’ model – and we don’t want a Top class that it could relate to
Even ‘just’ trying to do it for LTP/port shows the sort of issues to be faced

13. From operations patterns
Look at specifying constraint ranges + actual values
Do with union datatypes ?
Do via (generic) datatypes ?
Profile could be a mix of values and ranges
Some attributes could be a value + a range !

14. WT WRED Model

15. WredLtpSettings allows the same attribute definitions to be shared between the Config and the Profile
Hard-Hard WT Example
The capability is of the LTP, not the profile
Note that WredProfileAppliedToLtp is crude and only shows if a profile is currently applied or not

16. Hard-Hard WT Example with Profile Application
Adding WredLtpProfileUse allows us to represent more information about Profile (re)application

17. Hard-Hard WT Example with Profile Application and WRR Queue
A LTP may have many WRR Queues and the WRED settings would apply per Queue.
Many other variations could be possible, but this shows some possibilities. Capability per Queue also ?
queueName

18. Hard-Hard WT Example – Composite structure Profile
Profile is now defined per LTP and includes all the Queue values
queueName
queueName
profileName

19. Hard-Hard WT Example – Addition of Keystone Class
Addition of WrrLtp reduces coupling from the module back to the core and allows for other additions in the future
# Note that there is no direct association here, to give a decoupled solution (aggregates) #

20. Hard-Hard WT Example – ‘Device’ Profile
Adding the purple classes in the core model would allow assembly of feature level profiles into a ‘device’ level profile using subclassing.
Composition is used within a (feature) module.
‘Device’

21. Wrappered Primitives
This is also where <<Generics>> could be useful
Rather than creating these datatypes per primitive type
Or do via <<Profilable>> <<Configurable>>
Or do via <<Configurable>>
Or do via <<Profilable>>
Note that <<Union>> is not useful here

22. Conclusion
Profiles and Templates will be best produced by a mix of modelling and generation
We need to find a suitable representation for both the modeler and the generator
Stereotypes will be a big help
Need to decide on a composed Entity or Datatype approach
See also the Config vs Operational data slides