Embed Size (px)
Citation preview
1
Complex Types and Typed Instance Identifiers
IETF #75NETMOD WG
2
DISCLAIMER
• We don‘t 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 don‘t 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 containmentwith unknown depth
open for name suggestions
Recursive Structures in Model and Payload
4
Recursive Structures in Model and Payload<holder>
<objectId>Rack-A2</objectId>…<holder>
<objectId>Subrack-1</objectId>…<equipment>
<objectId>Card-1</objectId>…
</equipment><holder>
<objectId>Backplane-A</objectId>…<equipment>
<objectId>Card-1</objectId>…
</equipment></holder>
</holder></holder><holder> // … more holders</holder>
<filter type="subtree"> <top xmlns="http://example.com/hw">
<holder> <objectId>Rack-A2</objectId>
</holder></top>
</filter>
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<holder>
<objectId>R31s2</objectId><ymi:type>hw:Slot</ymi:type><slotNumber>1</slotNumber><ymi:type>hw:EquipmentHolder</ymi:type><equipment>
<objectId>ATM-45252</objectId><ymi:type>hw:STMCard</ymi:type><level>16</level><ymi:type>hw:Card</ymi: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>
• 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 Typecomplex-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?
