1 Complex Types and Typed Instance Identifiers IETF #75 NETMOD WG

2 DISCLAIMER We dont want to delay YANG 1.0 ! This is just to start a discussion on –features as we believe are not supported sufficiently in YANG today. We dont want to achieve any decision today

3 complex-type EquipmentHolder { extends ManagedHardware; abstract true; element-list equipment { type Equipment; } element-list holder { type EquipmentHolder; } Complex type nesting Recursive containment with unknown depth open for name suggestions Recursive Structures in Model and Payload

4 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

5 complex-type PhysicalPort { abstract true; key portNumber; leaf portNumber { type int32; mandatory true; } } complex-type Card { element-list port { type PhysicalPort; } … complex-type PluginModule { element-list port { type PhysicalPort; } Base Type Substitution complex-type ExtPhysicalPort { 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 Possibility to define managed objects with actions Derived complex-type:

6 Rich Type Definitions complex-type PhysicalPort { key portNumber; abstract true; leaf portNumber { type int32; mandatory true; } } complex-type Card { element-list port { type PhysicalPort; } complex-type PluginModule { element-list port { type PhysicalPort; } Definition of abstract types no need to indicate the quality of the type in the description text Definition of types with a key no need to add key definitions at every place of use

7 Type Information In Payload R31s2 hw:Slot 1 hw:EquipmentHolder ATM hw:STMCard 16 hw:Card 1 true A2 1 A b ATM-ADM 2 T-K x45 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

8 Instance Identifiers Restricted by Type complex-type PhysicalPort { extends ManagedHardware; leaf portNumber { type int32; mandatory true; } } complex-type PhysicalLink { extends ManagedHardware; leaf-list connectedPort { type instance-identifier { type PhysicalPort; } min-elements 2; } It should be possible to constrains what type of entity may be identified Allowing derived type instances as target nodes wherever the base type is referred derived types added later

9 Further development Issues to solve: –Module update support –Invocation of operations –Creation of notifications for certain types of entities Many thanks for comments and suggestions: Balazs Lengyel, Martin Björklund, Gerhard Münz, Martin Storch Interested to join us?