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

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.

Technology Extensions ONF_Txx_EthernetExamples.pptx shows how to decorate the core model with technology extensions Core Model Technology 1 Technology 2 Technology 3

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)

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-87a6-4979-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>

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 ?

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 http://help.eclipse.org/oxygen/index.jsp?topic=/org.eclipse.pde.doc.user/reference/api-tooling/api_javadoc_tags.htm

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

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