Use Cases
- 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 unique [Dongho] here node-id is like yang file name for a device? can we have an example?
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? [Dongho] I think we might need some level of status of config request in a response message.. not sure how much detail we need.. did we have some agreement about it at the call?
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.
[Dongho] one Q: is it easy to translate DMaaP msg to RESTCONF?
- 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
[Dongho] one more topic to be discussed: do we need to define a generic set of header for dmaap message such as msgID, closedloopname, msgtype(e.g. request, response) etc. ?
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
[Dongho] here will websocket be used for getting and sending a msg from/to dmaap ? - 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}}
[Dongho] is this an existing code? how can we integrate this to our solution ? - md-sal agent
most effort, most future-proofed