1. Task xx Scope – Model Extensions
Purpose – Document how the core model should be extended for vendor or technology specific cases
Specifically – The UML constructs to use
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. Technology Extensions
ONF_Txx_EthernetExamples.pptx shows how to decorate the core model with technology extensions
Core Model
Technology 1
Technology 2
Technology 3

5. We don’t want Vendor Extension by Subclassing but by Decoration
Assume that vendor A subclasses entity EthernetLtp into entity VendAaEthLtp This will convert the types of the instances and make it hard for a receiver of that instance to know what to do with it.
If instead Vendor A decorates entity EthernetLtp with entity VendAaEthLtpXtn, then a receiver will now get two instances, the standard one i1:EthernetLtp and one that it may or may not know how to deal with i2:VendAaEthLtpXtn
Another benefit of using Decoration rather than Inheritance is the possibility of ‘multiple extensions” For example, a controller could have a number of vendor extension packs installed. When it wants to broadcast details of a new VLAN it broadcasts the core instance details plus the vendor extensions for ALL its installed vendor packs. vlan1:Vlan + v1x1:VendAaVlanXtn + v1x2:VendBbVlanXtn + … v1xn:VendZzVlanXtn Without complex negotiation, each device takes the core instance plus the vendor extension it needs. (We could assume that if a controller is managing a network of devices that the correct extension packs would be installed)

6. We don’t want Vendor Extension by Subclassing but by Decoration
Another option for a device (in non-broadcast situations) may be to negotiate for the best information that it can get. It could ask for VendBbVlanXtn and if that is not available, then ask for VendAaVlanXtn and if that is not available, then drop back to just using the Vlan attributes.
Standard Attributes
A simplistic XML message mockup
<Ltp id = "6457a86a-87a b445-1cdeef4c450a" name = "Eth0/Eth" >
<EthernetLtp duplexMode = "FULL" portSpeed = "SPEED_1GB" macAddress = "00:14:22:01:23:45" autoNegotiate = "true" enableFlowControl = "false" />
<VendAaEthLtpXtn role = "SLAVE“/>
<VendBbEthLtpXtn role="SECONDARY-SLAVE" state = "ENABLED" />
<ieee802-ethernet-interface frame-limit-slow-protocol = "10“/>
</EthernetLtp>
</Ltp>

7. We need to control how the ONF CIM is extended
Assume that we don’t allow vendor specific subclassing at all
how do we enforce it ? Tooling ? Documentation ? Compliance Checks ?
Assume that vendors can only Decorate existing classes in the CIM
Can all / any class be decorated ?
For our Ethernet Example we wouldn’t want a Vendor to Decorate Ltp for VendAaEthLtpXtn, they should Decorate EthernetLtp
Can we control what is Decorated in any way (see next slide) or do we just document preferences ?

8. Additional Stereotypes will help to audit the model design
Copied from ONF_T13_ModelStructure.pptx
Additional Stereotypes will help to audit the model design
Some additional stereotype based restrictions may help us to manage the use of the model.
For example we could implement restrictions like these outside of a module
NoXtrnImplement
NoXtrnExtend
NoXtrnInstantiate
NoXtrnOverride
NoXtrnReference
Or the default could be to have all of these disallowed, unless enabled using
XtrnImplement …
From

9. Items for Further consideration
How / can we extend Enumerations (by adding literals) ?
How / can we extend Datatypes (by adding attributes) ?

10. Enum ‘Extension’ Proposal
Don’t want to ‘Subclass the Enum as it then injects extensions back into the base model
Can we add the additional values in another Enum and then use those additions in a new attribute. Add a stereotype to bind them together.
Optionally could add Enum literal pointers EXTENSION and STANDARD
EXTENSION
<<Extends>>
STANDARD