Operating System: All
Platform: All

What you are asking for is to be whole node removed? Or just to remove data as capabilities, etc?

Netconf is reconnecting, so providing
"netconf-node-topology:connection-status": "connecting"
is actually correct.

List of available-capabilities should not be there.

Whole node removed. Netconf session is down, node is not reachable, for all purposes node can not be be used.

As far as "connecting" goes, I waited a long time and state did not change. At some point it needs to give up, change state one final time and remove node. It can not be "connecting" forever...At least that is how I see it.

Also, when node is removed, it needs to be remove from current_config.xml. Otherwise it will be re-added when karaf reboots.

This is the correct behavior since by default there is an infinite reconnect strategy. If you want to eventually run out of reconnect attempts you need to set <max-connection-attempts></max-connection-attempts> in the device configuration when creating the device via restconf/initial configs.
It still won't remove the device from topology after it runs out of attempts, just show connection-status as unable to connect.

Then the topology tree will grow indefinitely. This does not sounds right. I think you have a very limited use-case in mind. In my use-case I can have 10000s of Netconf devices as virtual Service Functions in a data center coming and going.

Actually it seems to cover broader use cases to me. You cannot know if all use cases want to throw away every node once it's unable-to-connect, it should be up to each individual case to decide whether to throw the node away or keep it.
As for your case - there are already mechanisms in place to detect a state change and deleting a node once it's in unable-to-connect state so topology doesn't grow infinitely(notifications, dataChangeListeners).

I disagree with this approach but I will take the discussion internally.

Netconf plug-in should manage its own datastore. It is not up to SFC to manage netconf-topology tree. OVSDB manages its own nodes and so openflow.

If I understand it correctly, when you configure a Netconf device into config space, it immediately appears in the oper space with status down. Is that correct? In other words, the Netconf Connector creates an entry in the oper space for the device when the device is configured in the config space. The status changes to 'connected' when the NC Connector connects to the device.

Now, somebody had to put the device into the configuration space; in other words a NC device MUST be configured by an outside entity so that the Netconf Connector can do something about it. The configuration can be done either by the operator or, in SFC's case, by the SFC application. Is that correct? If yes, the NC Connector can no delete an entry in its configuration by itself - the entry MUST be deleted by somebody from outside. That somebody MAY be either operator or the SFC app. That somebody SHOULD be the same entity that created the configuration entry.

If the above is correct (and if we can agree on it), then it appears to me that the correct behavior would be for the SFC app to listen on status changes of NC devices on the oper space. If a device went down, the SFC app should then delete the entry from the config space.

The configuration is not done by SFC. Each VM image performs a HTTP POST independently as it spins up. SFC app is not involved, this is similar to call-home.

If a VM is destroyed by orchestrator (say, Openstack) Netconf device will not be removed from topology.

> The configuration is not done by SFC. Each VM image performs a HTTP POST
> independently as it spins up. SFC app is not involved, this is similar to
> call-home.

> If a VM is destroyed by orchestrator (say, Openstack) Netconf device will
> not be removed from topology.

It's a neat trick But it inherently lacks the delete event for the VM. It would be better if the VM performs am HTTP POST to a proxy, which then injects the NC config into the NC connector. The VM should have a keepalive with the proxy, so that the proxy can detect that the VM has gone away.

Alternatively, you can have the proxy listen to NC node status changes in the NC topology. When the proxy detects a connection going down, it starts a timer. When the timer expires, the proxy deletes the device.

But, since the NC config was injected into the NC Connector from outside, the NC Connector should not clean it up itself. Also, it would be clean if the same entity that injects the config into the NC connector also cleans it up.

I understand but that is something we can not guarantee even when VM responsible for the HTTP DELETE.

Networks loose packets, machines crash, things happen. The protocol/database design should be self-healing, i.e, if the netconf session is down for a large amount of time data should be removed.

Hi Reinaldo,
from Netconf connector and controller perspective - configuration of controller, that it should try to connect to particular Netconf device was provisioned from external system - that is only information controller have.

The Netconf connector - does what it should do - put data in operational with node, which existence was provisioned by your system, along with status that
it is connecting or connected.

Since Netconf has reversed client-server relationship to openflow - controller
itself does not have any capability to detect that configuration (introduced by external system) of netconf session is invalid.

Also Controller has not enough information to make well-informed decision that
this configuration should be removed - since it was state introduced by external system and does not know intention of external system.

This connection could be unvailable due to several reasons -
1. VM was removed
2. connection issues

From ODL perspective both cases are similar - unable to reach hosts

From deployer perspective - in case n.1 ODL should stop reconnecting to particular VM, case n2. ODL should still try to connect.

Information that VM is removed - tear down is not available to ODL, but system
which was responsible for starting that VM, should have enough information
to remove configuration from ODL regarding that particular VM.

Closing as RESOLVED INVALID - since external system configured ODL to reconnect to remote device and did not cleaned-up ODL configuration once device was removed.

ODL was trying to reconnect since configuration was still applicable and ODL did what was configured trying to connect to remote device.