devices with well-known yang modules (already operational fluent)
new device with "unknown" yangs
Overall Workflow
A new netconf device is attached. available: create mount point in odl-netconf topology (Q: Is there a topic "odl mount"? yes: e.g. PNF-PnP (add link to the use case)) Note: may or may not be usable for the use case - at least needs to be extended. Assumption: new topic, specific to the NetConf node, but is generic for all message from and to the node. topic-name: sdnc/node-id → makes it globally unique Let's call it "generic mount listener".
ODL gets a yang model and creates a relevant RESTCONF N/B. available: NetConf hello-message, plus existing odl functionality. Note: RestConf already exists for known yang modules for already mounted devices.
A user configures something for the DMaaP interface of that new device (e.g. topic name, Message Router service name, etc.) User puts changes in the message bus and ODL needs to "grep" it (new functionality → generic DMaaP Listener) (Q. not sure if we can automate this step?) (A: There is nothing which cannot be automated. Q: What do you think we are missing?)
Then, our new module start listening to that topic for the specified MR. This happens in step 1 already due to the change we made in step 1 - generic mount listener)
‘Somehow’ yang model should be exposed to uS developer ( Q. do you have any idea about how uS can see such yang model? I know you already have GUI in sdn-r, can we see yang model there?) A: look at the function used by the apidoc/explorer (swagger.json). Note, already know yang-modules (known devices, payloads, ...) don't need that discovery.
Based on that yang model, uS sends a DMaaP message to a topic.. 4 cases need to be defined: a) config and 1x GET operations (happens only one time) > no need for its own (new) topic → topic is sdnc/node-id > operation: GET, PUT, DELETE and url and payload are part of the message. Q: What to do with the response - 200, 201, 401, 500? Do we need such responses on DMaaP? b) operational data TO BE CONTINUED what is the main difference to a)? topic, and responses. c) notifications A subscription mechanism will drive the topic and whether the NetConf notification can be added as is to DMaaP. d) rpc Each RPC gets its own topic to add the response on the DMaaP.
Our new module will get it and translate received DMaaP (json) message to RESTCONF (Q. will this be feasible?) see 5.
once the new module gets a response, it posts a response message to a topic. see 5.
uS will get the response. via DMaaP
Implementation options Three options from Jeff Hartleyfor implementation of the "generic DMaaP listener".
generic message bus agent to and from RestConf and WebSocket in JVM
json-rpc The example provided by Lumina from an app for Juniper: {{lsc_ip}}:{{lsc_port}}/restconf/config/jsonrpc:config/configured-endpoints/devicedb/yang-ext:mount/ldk-device-database:devices/device/{{vmx02_name}}
