1. Complex Types and Typed Instance Identifiers as YANG Extension
IETF #77
NETMOD WG

2. 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

3. 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

4. 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

5. 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

6. 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:

7. 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?

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

9. Thank You!
Questions?

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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="
<holder>
<objectId>Rack-A2</objectId>
</holder>
</top>
</filter>

16. 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

17. 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

18. 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 b</serialNumber>
<commonName>ATM-ADM 2</commonName>
</equipment>
<serialNumber>T-K x45</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

19. 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