[Concept] New controller notification concept

[kmohr-soprasteria]

Vorher gab es 2 getrennte Subscriptions:

1. device-state-change: 1 Subscription am Controller für alle Änderungen bei den gemounteten Devices hinsichtlich des Connection-Status; von den gemeldeten Stati relevant waren "connecting" und "connected"; siehe hier
2. config-change: wenn sich an einem Gerät (d.h. im CC) ein Attributwert geändert hat; siehe hier

Es gab vorher auch je 2 getrennte Requests, um die Subscription zu erzeugen und dann für das eigentliche Abonnieren der Notifications.

s. #87 & #191

---

Neues Konzept:

• Es gibt nur noch eine URL, die man subscriben muss und die für beide Fälle eine Notification schickt
• Subscribe: GET <url>, unsubscribe: DELETE <url>
• Die neue URL ist jetzt immer für je 1 Device, d.h. man muss erstmal (periodisch) die Liste der Devices vom Controller abfragen und dann für jedes relevante Device eine eigene Subscription durchführen
• URL: <controller-ip>:8181/rests/notif/{mount-name}?notificationType=device

Zurückgeliefert werden folgende Strings:

• : ping: kann ignoriert werden
• device-state-change:
  • data: Device disconnected: wenn ein Device entfernt wird oder in den connecting state geht; es gibt keine Unterscheidung mehr zwischen connecting und unable-to-connect in den Notifications
  • data: Device connected: wenn ein Device (wieder) in den connected state kommt
• config-change:
  • data: <Pfad zum geänderten Attribut + Timestamp
  • der neue Attributwert wird nicht mitgeschickt, d.h. man muss entweder das CC nochmal neu abrufen oder besser noch nur das geänderte Attribut und das dann im gecachten CC aktualisieren.

---

---

Was passiert z.B. bei DCN-Wacklern?

• Device ist connected, dann disconnected und kurze Zeit wieder connected
• im MWDI wird das Device aber gelöscht, sobald es disconnected ist, d.h. auch die Subscription und man lernt das Device erst wieder kennen, wenn es beim periodischen Sync mit der Controller DeviceListe neu gefunden wird (wenn es connected ist)
• laut Arun ist 1-2h wurde beobachtet, dass Devices bei derartigen Wacklern meist 1-2h Stunden später wieder stabil sind
• damit nicht bei Wacklern die ganze Zeit neu versucht wird das CC neu abzufragen, könnte man einen Schutzmechanismus einbauen, bei dem zwar das Device aus dem MWDI mit dem CC gelöscht wird, aber auf eine Lösch-Liste kommt mit dem Lösch-Timestamp und dann da diese 1-2h Stunden behalten wird und erst wenn diese Zeit rum ist, darf das Gerät wieder neu zum MWDI hinzugefügt werden; Theoretisch sollte das aber auch kein Problem sein, wenn das versucht wird, weil das CC-Request ja in dem Moment fehlschlägt, in dem das Gerät nicht mehr connected ist.

Was sind die Auswirkungen auf das HMDI?

• Im Prinzip soll das HMDI funktionieren, wie das MWDI, allerdings sollen hier auch die CCs noch eine zeitlang behalten werden, wenn das Device disconnected ist
• altes Konzept: das HMDI bekommt vom Controller oder MWDI eine Notification, dass ein (neues) Device (wieder) connected ist; eigentlich wird das gar nicht gebraucht
• das HMDI ruft vom MWDI neue CCs ab; d.h. es muss eigentlich nur eine Notification bekommen, sobald ein neues/aktualisiertes CC zum Abrufen bereit ist.
• der connection-State muss eigentlich gar nicht getrackt werden, weil ja auch nicht connection-state abhängig gelöscht wird
• man kann stattdessen für jedes Device ein Timestamp führen, wann das CC zuletzt aktualisiert wurde und wenn das eine bestimmte Zeit nicht mehr passiert ist, dann wird das Device aus dem HMDI gelöscht.

[kmohr-soprasteria]

info used in #198

[kmohr-soprasteria]

According to e.g. airInterface spec the notification for attribute change should include the new value already:

Is a retrieval then really necessary? Is it necessary, because the notification is sent to the Controller, which then creates a notification of its own then (and omits that value)

---

• Für jedes config-Attribut gibt es bei Änderung eine Notification:

• Bei capability nicht

• Bei Status-Infos: 2 Fälle (beide Datenarten in Status inkludiert)

  • Status-Info: change = diskret (z.B. Interface = an oder aus; Wert = x oder y), ändert sich nur selten
  • Measurement-Info: nicht diskret, Werte ändern sich kontinuierlich (das sind current-PM-Werte, nicht die Register); daher macht eine Notification keinen Sinn , Status-Info vom MWDI, aber Measurement-Info sollte vom Controller abgefragt werden

[kmohr-soprasteria]

Controller sollte die ganzen Infos, die vom Device bereitstellt werden (ltp & neuer Wert) wenn möglich auch bereitstellen (außer es gibt einen sinnvollen Grund, weshalb das nicht drin ist) -> mit Arun und Zia klären

Das muss getestet werden und falls das fehlen sollte, dann Di. ODL-call (10:15h) ansprechen -> Thorsten Bescheid sagen, wenn das fehlt

---

Info von Zia:

Sure, we will start extensive test especially for attribute notification change for supported configurational attributes with to reference latest yang. Currently network vendor doesn’t support displaying attribute value, raised mantis for those issues.

---

Antwort:

whom exactly are you referring to with network vendor? Can you please push them, so we get this feature quickly? You got any estimation when we will get it?

Reason is that the MWDI shall be designed to update its database directly with the changed value from the notification rather than query the value again from the Controller. (Would just cause unneeded load.)

[kmohr-soprasteria]

Discussion with Senthilvel & Zia:

• Vendors do not support the AttributeChangedValueNotification
• the information that the controller uses is provided directly from netconf
• Huawei: in the past Huawei had at least implemented the AttributeChangedValueNotification
• Ericsson: not all device types support this notification

Senthilvel will discuss with the vendors, then we can have a call with Thorsten to align on that.

[ssomasundara]

Below is the summary notifications support .

Controller Notification

Configuration - Mounting, Deletion, Change of attributes on Mount point confgiuration. Operational - Status Changes

Device Notification

Problem - For alarms or events from device Object Creation - Only for RPC requests (Ex: VLAN Fc Creation, FWDL) Object Deletion - Only for RPC requests (Ex: VLAN Fc Deletion) Attribute Value Change - Only for specific attributes (FWDL Status change, LLDP) - Non harmonized implementation. Netconf Config Change - For all PUT requests from Controller. (Supported by Netconf server framework RFC 6470)

Operational status changes - Not supported

We will validate same with vendors today.

[kmohr-soprasteria]

Austausch Thorsten mit Roberto (Siae):

Thorsten:

yesterday, I had a call with Senthilvel. He said that AttributeValueChangedNotifications and ObjectCreationNotifications would only be partly supported. This is very alarming for me, because our concept for buffing network information is based on these notifications. Could you please provide me with details during a call?

Roberto:

what we mentioned in the private call was that by default our implementation is supporting the standard netconf notification including attribute value changed that is different respect the one described in TR532 model. The management of attribute value changed notification, as requested by the TR532 model, was a pending activity not already completed. Just yesterday me and Danilo had a session on this topic and fixed it. Currently the functionality is already available in our lab and will be delivered with the next mediator release (please see Mantis 386).

Thorsten:

that sounds like very relieving news to me. Maybe, we don’t need to have the call, if you would just allow me to complete my picture.

With the next mediator release …

• … we will receive AttributeValueChangedNotifications according to the TR532 definitions for Configuration and Status attributes (as far as they are marked to provide such notifications in the modelling)
• … we will also receive ObjectCreationNotifications according to the TR532 definitions whenever objects get instantiated e.g. in accordance with the TransmitterEquipment Specification (e.g. when an SFT gets plugged into the device)

Is this understanding correct?

Roberto:

in case of configuration and object creation/deletion I confirm your understanding. Below you can find a couple of screenshot example for "objects creation" in case of: • SFP plug • VLAN creation In case of status change instead we have to investigate a bit the possible management. The point is that the mediator implementation depends on the information sent spontaneously by the device. The device internal model (MIB) is different from TR532 model and for this reason there is no 1 by 1 relationship between SNMP Trap and TR532 objects status change. For this reason, the attribute value changed notification has not already been implemented in case of status change.

[ssomasundara]

Hi Katharina,

E/// confirmed that they could not implement AVC notifications. Huawei checking in the background. Also, status change notifications are not supported by any vendor.

Thorsten and myself discussed on this. I will open this topic in next Tuesday call.

---

Related call: 9:00 AM Interface definition call.

[kmohr-soprasteria]

• ggf. werden nur Änderungen von config-Attribute unterstützt (können vom MWDI abgefragt werden), aber ggf. Status-Attribute nicht (müssten dann vom Controller abgefragt werden)
• Vorgabe von Thorsten: wir sollen für MWDI-Spec davon ausgehen, dass wir die config-change-Notifications MIT dem neuen Value bekommen (Vendoren haben Lieferung von TR532 zugestimmt, müssen das also liefern)

[kmohr-soprasteria]

Bei Modellierung des Callbacks sind noch Probleme aufgetaucht ResponseHeaders vom Controller:

• Beim Ausprobieren im Postman wurden gar keine Nachrichten beim GET-Request angezeigt
  • es kam aber ResponseCode 200 zurück
  • und die Zeit ist auch hochgelaufen, während Postman ständig aktualisiert hat
  • Device-connection/Config-change sind Event-basiert, also klar, dass die nicht auftauchen, wenn sich nichts ändert
  • ABER: die ": ping" Nachricht kam auch nicht
  • wird der ping nur im Browser angezeigt, nur für bestimmte User oder vielleicht mittlerweile geändert?
• Außerdem ist ein DELETE nicht erlaubt

---

Daher Rückfrage an Senthilvel + Arun -> Antwort:

In the latest Controller version, subscription is taken care during mounting the device on the controller. If the device disconnects, the resubscription will be taken care by the controller itself. In production, all devices are already subscribed.

We are writing a listener (script) to listen to all streams (42K devices) and stash to ELK.

Subscriptions are auto killed when mount points are deleted from the controller.

Die Antwort legt nahe, dass sich eine App eigentlich gar nicht subscriben muss, sondern einfach nur ständig den Notification-Stream abfragen muss (also kein push sondern pull)

---

Rückfrage:

okay, so theoretically I would then receive a notification if the device comes up again, because the Controller handles that, right? (Before I had assumed that I would need to rediscover NEs by checking the list of mounted devices periodically, because as soon a device Is not connected anymore it will be deleted from the MWDI completely.)

There could be some chaos inside the MWDI database, when a device goes offline, because then the MWDI will no longer know that it has a subscription for that device. But the Controller does not know, that the MWDI doesn’t have the subscription anymore. But I guess it would be possibly to note down that in such cases the implementers shall just add the device again. So this should not be a major issue.

But – still there should also be a possibility for apps to unsubscribe on their own, to ensure we follow the defined process flow.

E.g. if there’s a new release of the MWDI, then first the subscriptions the old MWDI release has to other apps will be unsubscribed and then the subscriptions will be done by the new release (during bequeath-your-data-and-die). If the Controller does not support the unsubscribe then the MWDI (and possibly other apps) cannot follow the process flow Thorsten defined.

Please have a look at what can be done in that regard. Possibly just allow DELETE for specific users or roles?

And why was nothing shown in the response body? Are the “: ping” messages not shown everywhere?

and another question… so from your description it doesn’t sound like other applications are subscribing for notifications at the Controller, but the Controller subscribes at the devices for changes and then offers a stream where it writes this change info to and others must read this constantly to get the infos.

So it’s not a push from the Controller (like I had expected) but a pull from apps, that want to subscribe.

---

Antwort Senthilvel: fehlt noch

[kmohr-soprasteria]

In principle the MWDI will not subscribe at the Controller or the devices, but the Controller subscribes at the devices and then just streams the notifictions to anyone listening. So theoretically the MWDI just needs to constantly listen to the stream.

[kmohr-soprasteria]

URL darf nicht /rests/notif/{mount-name}?notificationType=device lauten, sondern muss /rests/notif/{mount-name}?notification-type=device lauten -> an Arun gemeldet, wird geändert (TechM = controller team)

[kmohr-soprasteria]

• Subscription ist gar keine echte Subscription (POST/PUT), sondern nur ein GET ; d.h. es wird eine Streaming-Session pro Device geöffnet, die permanent aufbleiben muss; d.h. das MWDI braucht ~40.000 Streams
• dementsprechend gibt es auch kein DELETE
• falls kein push möglich ist, sondern man wirklich die 40.000 Streams braucht, muss ggf. eine neue App eingeführt werden, die sich um die Notifications kümmert und die anderen Apps kommunizieren dann mit dieser, anstatt auf Änderungen am Controller zu lauschen

[kmohr-soprasteria]

Die Infos zu den device-state-changes soll wieder wie vorher beschafft werden, d.h. Subscription am Controller. (Dann muss man auch nicht vorab wissen, welche Geräte da sind und dann auf einzelne Streams lauschen.) s. auch: https://docs.opendaylight.org/projects/netconf/en/latest/user-guide.html#sse-notifications-subscription-process

Für config-change dann wieder eigene Subscription

[kmohr-soprasteria]

• Es wird eine neue App geben, die sich um die Subscriptions am Controller kümmern soll
• soll von TechM implementiert werden
• das MWDI bekommt seine Notifications dann später von der App, statt von den Controllern direkt
• das MWDI funktioniert erst korrekt, wenn die App da ist (wegen den config-changes)