Complex Types and Typed Instance Identifiers as YANG Extension IETF #77 NETMOD WG bernd.linowski.ext@nsn.com mehmet.ersue@nsn.com s.kuryla@jacobs-university.de

Complex Types Motivation Improvements of Language Abstractions Top-down modeling: first abstract entities and then concrete refinements Enables alignment with other SDO's resource models with 1:1 mapping Improvements of Language Abstractions Enables recursive data structures of arbitrary depth Allows extending of self-contained type definitions with rich inner structure Simplifies concept refinement and avoids e.g. huge choice-statements with complex branches Avoids improper usage of abstract concepts based on type-safe modeling

1:1 Mapping to Other Languages NSN O2ML Complex types Blueprint for instances 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 type instances single list Complex types Extensions

New since IETF 76 Complex type can be defined where groupings can be defined Own namespace for complex types Refinement of base type elements Defined support for augmentation of complex types instantiations deviations of complex type instantiations No "config" inside a complex type

Improvements for v02 Agreed with M. Björklund: Proposed by S. Kuryla: Additions of data node in complex type instantiations (instead of ‘augment “.” ’) Use of “instance-type” to refer to complex types Proposed by S. Kuryla: Unrestricted augmentation & deviation of complex type instance trees

Demo: Complex Types in pyang pyang with complex type support available: Validation of complex type definitions complex type instantiations YANG  YIN transformation Extension contributed as pyang plug-in (get pyang snapshot and extension from: http://code.google.com/p/pyang-ct/)

Further steps pyang plug-ins mapping to XSD and RelaxNG libsmi implementation on the way (available end of April) We welcome any comments and discussion! Is this work useful for the WG? Proceed as standard track WG item?

Open Issues Extension of recursive data structures Is augmentation of recursive data structures at all levels needed?

Thank You! Questions?

Advanced Use of Complex Types ct:complex-type Chassis { ct:extends EquipmentHolder; container chassisInfo { config false; leaf numberOfSlots { type uint16; } leaf occupiedSlots { type uint16; } leaf height {type unit16;} leaf width {type unit16;} } ct:instance-list chassis { type Chassis; augment "chassisInfo" { leaf modelId { type string; } deviation “chassis/chassisInfo/occupiedSlots” { deviate not-supported; Augmentation of a complex type instance Deviation definition for a complex type instance 10

Agreed Improvements References via ct:instance-type ct:complex-type EquipmentHolder { // … ct:instance-list holder { type EquipmentHolder; } } ct:complex-type Chassis { ct:extends EquipmentHolder; container chassisInfo { config false; leaf numberOfSlots { type uint16; } // … ct:instance-list chassis { ct:instance-type Chassis; leaf inMaintenance {type boolean; } References via ct:instance-type Addition of data node to a complex type instance 11

Suggested Improvements ct:complex-type EquipmentHolder { // … ct:instance-list holder { type EquipmentHolder; } } ct:complex-type Chassis { ct:extends EquipmentHolder; container chassisInfo { config false; leaf numberOfSlots { type uint16; } // … ct:instance-list chassis { ct:instance-type Chassis; augment “holder/holder” { leaf plugIn {config false; type boolean; } } deviation “chassis/holder/holder/occupiedSlots” { deviate delete; Augmentation of a recursively contained complex type instance (open issue - not implemented yet) Deviation definition for a recursively contained complex type instance Support for all kinds of deviations 12

Complex Types and Typed Instance Identifiers 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 { // …. feature complex-types { description "This feature indicates that the agent supports complex types and instance identifiers."; Specified in form of a YANG module: Extension definitions Feature indicating complex type support

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

Recursive Structures in Model and Payload <holder> <objectId>Rack-A2</objectId> … <objectId>Subrack-1</objectId> <equipment> <objectId>Card-1</objectId> </equipment> <objectId>Backplane-A</objectId> </holder> <holder> // … more holders NETCONF payload reflects instance nesting Simple filter to select sub-tree under a particular tree node <filter type="subtree"> <top xmlns="http://example.com/hw"> <holder> <objectId>Rack-A2</objectId> </holder> </top> </filter>

Base Type Substitution ct:complex-type PhysicalPort { ct:abstract true; key portNumber; leaf portNumber { type int32; mandatory true; } } ct:complex-type Card { ct:instance-list port { ct:instance-type PhysicalPort; … ct:complex-type PluginModule { ct:instance-list port { Derived complex-type: 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

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

Type Information In Payload <holder> <objectId>R31s2</objectId> <ct:type>hw:Slot</ct:type> <slotNumber>1</slotNumber> <ymi:type>hw:EquipmentHolder</ymi:type> <equipment> <objectId>ATM-45252</objectId> <ct:type>hw:STMCard</ct:type> <level>16</level> <ct:type>hw:Card</ct:type> <usedSlots>1</usedSlots> <installed>true</installed> <version>A2</version> <redundancy>1</redundancy> <serialNumber>A-778911-b</serialNumber> <commonName>ATM-ADM 2</commonName> </equipment> <serialNumber>T-K4733890x45</serialNumber> <commonName>CU-Slot</commonName> </holder> Use of predefined set of properties controlled by a type Type information in the payload Enables handling of unknown derived types Does not require explicit type codes Filtering types including derived types

Instance Identifiers Restricted by Type ct:complex-type PhysicalPort { ct:extends ManagedHardware; leaf portNumber { type int32; mandatory true; } } ct:complex-type PhysicalLink { 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