 Hello and welcome to the demo of control loop automation using own app. This demo has been jointly prepared by Ericsson and well Canada. This demo is mainly aimed towards showing the integration of different control loop components to achieve the complete life cycle of network automation. In the demo we will be showing a configuration modification on a simulated device. Specified interval based on logic defined in analytics and policy. Configuration modified in the demo is hostname of the device. In general the control loop flow starts from device and goes through collector, enrichment, analytics, policy, controller and then back to the device. Device is the entity that is being managed by the control loop. As you can see on the screen collector collects the data from device periodically. Enrichment adds required information to the collected data. Analytics is analyzing the data and detecting the problem if any. Policy finds the best possible solution for the problem. Controller is the component that performs the action on the device. It could be configuration modification, restart, scale in, scale out, etc. Following components with their related technology are being used in the demo. Device is simulated using ODL, NETCON test tool. Collector, enrichment and analytics are being handled using NIFI with some customizations. Policy execution is being handled by Apex PDP. Controller action is handled by CDS. For inventory we are using ANAI and for operational state management we are using state DB. The use case flow starts from collector collecting hostname and timestamp from the device, which is passed to enrichment using WEST notification event via Kafka. Enrichment reads the notification from Kafka and fetches the IP address from ANAI, adds it to the WEST notification event and publish to analytics via another Kafka topic. On the other side, state analytics will detect the change in hostname. If found, add it to the state DB to maintain a record of various state changes happening in the device. Allowing analytics will detect that the threshold for changing the hostname has crossed or not. If it has crossed, alarming analytics will create a WEST alarm and send that to policy via DMAP. Apex PDP will read the WEST alarm and trigger the respective logic to fetch the device details from ANAI to verify if the hostname provided by analytics is same as the one in ANAI. In case the hostname doesn't match, the execution of alarm is terminated and notification is sent on DMAP. If the hostnames are matching, then corresponding logic is triggered to generate a new hostname and request to update hostname is made to CDS via GRPC. Upon receiving the request, CDS will update the hostname in the device and then in ANAI. That completes one iteration of control loop flow for the use case. And the same will keep continuing while the automation is running. This is a more detailed view of the use case, mentioning the parameter path between components and the high-level logic of each component. I will pause for 10 seconds to let you go through it. In the next few slides are showing the sample events exchanged by various components. Starting from ANAI registration, data published by collector to enrichment, enrichment to analytic, analytic to state DB, analytic to policy, policy to CDS, CDS to device, and finally, CDS to ANAI. As part of demo preparation, collector, enrichment, and analytic rules and flows have been created and deployed in NIFI. Policy has been created and deployed in ApexPDP. CBA has been created and uploaded in CDS. Use case specific code is attached in a wiki and link is provided in the demo booth. We will be doing a live demo using on-app installation, having ANAI, DMAP, policy, framework, and CDS. Simulated device, NIFI, and state DB has been installed as well. At first, let's look at the installation of different components. We have created two separate namespaces to keep separation between platform and use case specific components. All the platform components are deployed in FireAns own-app namespace, and all the use case specific components are deployed in FireAns simple CL namespace. Let's go through the platform components first. As you can see, all the policy framework related pods are up and running. All the CDS pods are up and running as well. ANAI pods are running as well. And finally, the DMAP pods are running as well. Now let's check the use case specific components and see what all is running there. As you can see, Kafka is running here. We have NIFI running as well. We have state DB running as well. And finally, we have the simulated device running here as well. That's all about the installation of the different components for the demo. Now let me take you to Postman and show all that installation is working or not. So this is the API to fetch configuration from the device. As you can see, there is no configuration in the device, so nothing is there. If we check ANAI, PNF name to field is defined as undefined. That means the configuration is not yet set in the device. And to let you know PNF name to is the field that we are utilizing for saving the host name of the device. If we look at state DB, nothing is there at this point because the automation is not yet started. There is no configuration in the device. Also, there should be no notification from policy at this point because the automation is not running. There is no event triggered by analytics. With that context, let me take you to the NIFI UI where we have created the collector, enrichment, state analytic and alarming analytic flows. So these are the four flows that are running the different components that we have shown earlier. As you can see, they are stopped at this point. They're not running. And that's the reason automation is not running. So once we start them, there should be host name added, updated in the device, ANAI and state DB every minute. So we should see a change in host name every minute in these three different components. Let me start the flow and see if the automation is working as expected. So as you can see, the flow has been started. There should be data collection happening now. Let me take you to postman again. Okay, now let me check the device configuration. If there is a new host name. Yes, you can see that the host name has been configured in the device. And if we verify that, is this the host name that is present in ANAI as well? So if we go there and if we verify, yes, that's the one which is saved in ANAI. And we should have the same one in the state DB as well. Yes, we have that in state DB as well. And there should be relevant notifications coming from policy as well. That means the whole flow for the control loop work. Looks like it is more than a minute now. So let me verify and run it again to see if the device has a different host name now. Not yet. So that means one minute has not yet reached. Not even yet. Yes, you can see now that the host name has changed and the change should be reflected in ANAI and also in state DB. So that completes the demo. And I will move back to the presentation to take you through some of the references that we have provided for technologies used in the demo. Thank you for watching the demo.