Presentation is loading. Please wait.

Presentation is loading. Please wait.

Complex Types and Typed Instance Identifiers as YANG Extension

Similar presentations


Presentation on theme: "Complex Types and Typed Instance Identifiers as YANG Extension"— Presentation transcript:

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="http://example.com/hw"> <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


Download ppt "Complex Types and Typed Instance Identifiers as YANG Extension"

Similar presentations


Ads by Google