2019-07-31 Meeting notes (SDN-R)

Date

Jul 31, 2019

Attendees

  • @Dongho Kim

  • @Martin Skorupski

  • @Jeff Hartley

  • @Sandeep Shah

  • @John Keeney (Ericsson EST)

  • @Payam Forghani

    Please add yourself. Thanks!

Informed

  • @alexander.dehn

  • @George Clapp

  • @Herbert Eiselt

  • @Latha Ramamurthy

  • @Tracy Van Brakle

Goals

  • Share information

Discussion items



Who

Notes



Who

Notes

entire meeting
to be continued next week

@Jeff Hartley

@Dongho Kim

Generic YANG-model-driven DMaaP Agent on CCSDK (consumer/provider; RestConf)

Use Cases

  • devices with well-known yang modules (already operational fluent)

  • a new device with "unknown" yangs 

Overall Workflow

  1. 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
    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  
         [Dongho] here node-id is like yang file name for a device? [sko] node-id could be a device-name - fqdn of the device, ... SO → pnfName from AAI
                         can we have an example? [sko] Here you go: https://docs.opendaylight.org/en/stable-oxygen/user-guide/netconf-user-guide.html#spawning-new-netconf-connectors  
    Let's call it "generic mount listener". 


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


  3. 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?)


  4. 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)


  5. ‘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 (look at the methodology that swagger uses for yang modules - RFC yang to restConf ).   
    Note, already know yang-modules (known devices, payloads, ...) don't need that discovery. 


    1. 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
            by Sandeep: per node-id might not be the best option → add the ability to be generic → more discussion needed. 
         > 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?
      Jeff: such codes are available already in the karaf logs and should be used
      b) operational data 
      TO BE CONTINUED
          what is the main difference to a)? topic, and responses. 
         no PUT/POST
         changeEventNotifications
         topic is sdnc/node-id/specificIdToSubscribeTo ( container, yang-module ???)
      c) notifications
          A subscription mechanism will drive the topic and whether the NetConf notification can be added as is to DMaaP.
          topic: sdnc/node-id/notification (generic way, maybe in a second step more specific)
          reuse whatever data structure comes from the device, will be forwarded to DMaaP.
          how to expose the schema of notifications - to be defined. 
          
      d) (yang-statement) rpc 
         Each RPC gets its own topic to add the response on the DMaaP.
         Will be HTTP-POSTs
         topic is sdnc/node-id (similar to HTTP-PUT, see a))
         
         
      [Dongho] one Q: is it easy to translate DMaaP msg to RESTCONF? A: 

  6. Our new module will get it and translate received DMaaP (json) message to RESTCONF (Q. will this be feasible?)
    see 5. 

  7. once the new module gets a response, it posts a response message to a topic.  
    see 5. 

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

  1. 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 ? 

  2. 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 ?  

  3. md-sal agent 
    most effort, most future-proofed 


Action items