1. 1 Complex Types and Typed Instance Identifiers IETF #76 NETMOD WG bernd.linowski.ext@nsn.com mehmet.ersue@nsn.com

2. 2 Changes since IETF 75 Complex types as “YANG extensions” Modified complex type syntax: –Renamed “element(-list)” to “instance-(list)” –New extension keyword “instance-type” Update rules for complex types added Complex type feature added IANA considerations addressed -> Semantics of complex types unchanged!

3. Complex Types and Typed Instance Identifiers 3 Specified in form of a YANG module: module complex-types { // … prefix "ct"; // … extension complex-type { description "Defines a complex-type."; reference "chapter 2.2., complex-type extension statement"; argument type-identifier { yin-element true; } extension extends { description "Defines the base type of a complex-type."; reference "chapter 2.5., extends extension statement"; argument base-type-identifier { yin-element true; } // …. feature complex-types { description "This feature indicates that the agent supports complex types and instance identifiers."; } Extension definitions Feature indicating complex type support

4. 4 Further steps pyang plug-ins –complex type validation (under construction) –mapping to XSD and RelaxNG (planned) Anything to add to the draft? We welcome any comments –Is anybody interested to co-author? How should we proceed? –Proposed standard or Experimental?

5. 5 Thank You! Question?

6. 6 Support for High-Level abstractions TMF SID: ct:complex-type Equipment { ct:extends PyhsicalContainer; ct:abstract true; leaf installStatus { … } ct:instance-list equipment { type Equipment; } ct:complex-type Card { ct:extends Equipment; … } Complex types Blueprint for instances Complex types Extensions Complex type instances single list

7. 7 ct:complex-type EquipmentHolder { ct:extends ManagedHardware; ct:abstract true; ct:instance-list equipment { type Equipment; } ct:instance-list holder { type EquipmentHolder; } Complex type nesting Recursive containment with unknown depth Recursive Structures in Model and Payload

8. 8 Rack-A2 … Subrack-1 … Card-1 … Backplane-A … Card-1 … // … more holders Rack-A2 NETCONF payload reflects instance nesting Simple filter to select sub-tree under a particular tree node

9. 9 ct:complex-type PhysicalPort { ct:abstract true; key portNumber; leaf portNumber { type int32; mandatory true; } } ct:complex-type Card { ct:instance-list port { type PhysicalPort; } … ct:complex-type PluginModule { ct:instance-list port { type PhysicalPort; } Base Type Substitution ct:complex-type ExtPhysicalPort { ct:extends PhysicalPort; } Substitution of base type instance with derived type instances -wherever the base type is used -no need to know all places it is used Derived complex-type:

10. 10 Rich Type Definitions ct:complex-type PhysicalPort { ct:abstract true; key portNumber; leaf portNumber { type int32; mandatory true; } } ct:complex-type Card { ct:instance-list port { type PhysicalPort; } ct:complex-type PluginModule { ct:instance-list port { type PhysicalPort; } Definition of abstract types enforce common attributes must be extended to be instantiated Definition of types with a key no need to add key definitions at every place of use

11. 11 Type Information In Payload R31s2 hw:Slot 1 hw:EquipmentHolder ATM-45252 hw:STMCard 16 hw:Card 1 true A2 1 A-778911-b ATM-ADM 2 T-K4733890x45 CU-Slot Type information in the payload Enables handling of unknown derived types Does not require explicit type codes Filtering types including derived types Use of predefined set of properties controlled by a type

12. 12 Instance Identifiers Restricted by Type ct:complex-type PhysicalPort { ct:extends ManagedHardware; leaf portNumber { type int32; mandatory true; } } ct:complex-type PhysicalLink { ct:extends ManagedHardware; leaf-list connectedPort { type instance-identifier { ct:instance-type PhysicalPort; } min-elements 2; } Constrains what type of entity may be identified Allows to refer to instances of referred type derived types added later