1 / 12

Complex Types and Typed Instance Identifiers

Complex Types and Typed Instance Identifiers. IETF #76 NETMOD WG bernd.linowski.ext@nsn.com mehmet.ersue@nsn.com. Changes since IETF 75. Complex types as “YANG extensions” Modified complex type syntax: Renamed “element(-list)” to “instance-(list)” New extension keyword “instance-type”

caden
Download Presentation

Complex Types and Typed Instance Identifiers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Complex Types and Typed Instance Identifiers IETF #76 NETMOD WG bernd.linowski.ext@nsn.com mehmet.ersue@nsn.com

  2. Changes since IETF 75 • Complex types as “YANG extensions” • Modified complex type syntax: • Renamed “element(-list)” to “instance-(list)” • New extension keyword “instance-type” • Update rules for complex types added • Complex type feature added • IANA considerations addressed -> Semantics of complex types unchanged!

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

  4. Further steps • pyang plug-ins • complex type validation (under construction) • mapping to XSD and RelaxNG (planned) • Anything to add to the draft? • We welcome any comments • Is anybody interested to co-author? • How should we proceed? • Proposed standard or Experimental?

  5. Thank You! Question?

  6. Support for High-Level abstractions TMF SID: • 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

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

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

  9. 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 { type PhysicalPort; } } … ct:complex-type PluginModule { ct:instance-list port { type PhysicalPort; } } 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

  10. 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 { type PhysicalPort; } } ct:complex-type PluginModule { ct:instance-list port { type PhysicalPort; } } • Definition of types with a key • no need to add key definitions at every place of use

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

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

More Related