1 / 12

Enhancing YANG with RPCs and Notifications within Lists

Explore the benefits and solutions for integrating RPCs and Notifications within YANG lists to streamline management entities and improve operational efficiency. Discover how placing RPC definitions within lists adds clarity and specificity to network management tasks.

elias
Download Presentation

Enhancing YANG with RPCs and Notifications within Lists

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. RPCs and Notifications inside Listsin YANG Balazs Lengyel, Ericsson IETF-72 Dublin 2008 July

  2. Issue 1: Procedures in Objects • A good number of people do object oriented modeling • Assumption Objects will end up as lists • Objects contain procedures/Functions beside data • Solution: Define YANG RPCs inside lists

  3. Issue 2: Similar Procedure for different management entities • Often the same management action is relevant for different managed entities • Restart: router, OSPF, Interface, file-transfer • Block: Interface, port, user • Today they can’t all have the simple intuitive name: e.g. restart due to naming clashes • Solution: Name should be scoped by a List i.e. place of definition in the model

  4. Issue 3: RPCs in a Master-Subagent setup • Need to route the Netconf operations to individual sub-agents without understanding their meaning • Sub-agents usually handle a specific part of the global model e.g. a subtree • With RPCs defined on the top level, no easy way to select sub-agent without understanding the RPC • Solution: Allow RPCs on lower levels inside the model tree. The location of their definition can be used to choose the correct sub-agent

  5. Solution: RPCs defined in Lists • The list will anchor the RPC to a specific place in the management tree • The list will scope the name of the RPC

  6. RPC in List - YANG container mib-2 { list interface { key “ifId”; leaf ifId { type int32; } rpc shutDown { input { leaf mode { type enumeration { enum immediate; enum graceful; } } } } …

  7. RPC in List - XML • <rpc xmlns=“…" message-id="239"> • <action> • <mib-2> • <interface> • <ifId>3</ifId> • <shutDown> • <mode>immediate</mode> • </shutDown> • </interface> • </mib-2> • </action> • </rpc> • Using a generic action RPC

  8. RPC/Operation in List - XML • <rpc message-id="101“ xmlns=“…"> • <shutDown • callingPoint=“/mib-2/interface[‘ifId=3’]”> • <mode>immediate</name> • </shutDown> • </rpc> • Adding the special attribute “callingPoint” to • today’s YANG • All RPC names must be unique in a module • (to allow DSDL mapping)

  9. Notifications inside Lists • Would make YANG easier to use because: • Notifications always have a specific source, providing that is natural • It is nice to have the notification definition at the same place where the source entity is defined

  10. Thank You

  11. RPC in List – XML Unpreferred alternative • <netconf:rpc xmlns=… message-id="239"> • <shutDown> • <callingPoint> • /mib-2/interface[“ifId=3"] • </callingPoint> • <input> • <mode>immediately</mode> • </input> • </shutDown> • </netconf:rpc> • Adding an extra element ad a wrapper for the input parameters

  12. RPC in List - XML – Unpreferred alternative • <netconf:rpc xmlns=… message-id="239"> • <action> • <actionName>shutDown</actionName> • <callingPoint> • /mib-2/interface[“ifId=3"] • </callingPoint> • <input> • <mode>immediate</mode> • </input> • </action> • </netconf:rpc> • Using a generic action RPC

More Related