DeviceReachability - DR

[PrathibaJee]

This proposal is to develop an application that provides APIs to check the RESTCONF , NETCONF , IP reachability of a Microwave(MW) device, IP reachability of the ospf-area of a MW device managed by a SDN controller.

Please find the attached document for the detailed requirement of the application. 220718 Requirement for DeviceRechability Application.docx

[openBackhaul]

The abbreviation "DR" is already in use. The application name "DeviceReachability" is not following the general concept of application names Structure of ApplicationNames (see: "institution or authority"). New names proposed:

• ControlPlaneAnalyzer - CPA
• ControlPlaneExaminer - CPE
• SdnControlPlaneAnalyzer - SCPA
• SdnControlPlaneExaminer - SCPE

Please find the attached document for comments on the detailed requirements to the application 220719.Requirement.for.DeviceRechability.Application.docx

If this application would be seriously considered for implementation, it would be strongly recommended to create a repository and to convert the .doc into a .md for making it available to collaboratively commenting and contributing.

[PrathibaJee]

Thank you for providing comments and corrections in the document. Please find the attached document that consist of replies for your comments. 220719.Requirement.for.DeviceRechability.Application.docx

Sorry about the ApplicationName.

Following is the main use-case of the application : If a device is not responding as expected , to narrow down the rootcause we are using this application. We can identify whether problem is in the ,

1. REST layer(controller NBI) or in the
2. NETCONF server(mediator instance)
3. NE's IP's connectivity. If NE's IP address is not reachable , we can also check the if the nearby neighbor device-IPs are reachable.

Since this application focus on examining the connection status of a device in different layers can we have the following for consideration ,

• DeviceConnectionStatusExaminer (DCSE)
• DeviceConnectivityAnalyzer (DCA)

Also , while replying your comments in the document , I realized that , internally in this application we are having so many functionalities apart from the main use-case,

1. Finding a NE’s current IP address (from MediatorInstanceManager we have a possibility to get this information)
2. Finding the vendor-name of a device
3. Finding the model-name of a device

Instead of having own functionalities within this application , if any microservice provides this functionalities we can make use of it. We have to further work on identifying this.

[openBackhaul]

Maybe, main stakeholder will volunteer for ApplicationOwner. Particularly, since he is also participant in the ApplicationOwner training.

"Connectivity" of a device is used for number and type of connectors at a device in internal communication. "Connection status of a device" will be applied with payload interfaces in future applications. Maybe, we will manage to identify an application name that relates to the type of connection that gets analysed.

Tailoring the scope of the application will be a very interesting task that will challenge also our concept of microservices. Maybe, making data, which is already available somewhere (e.g. in the Controller or other applications), available for generic representation is a valid scope. Maybe, it's wiser to complement with a little representation application that represents data from several different REST applications.