Operating System: All
Platform: All

I tried to PUT your input to URI
http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/

but it wasn' successfull
following error was obtained
{"errors":{"error":[

]}}

But can't see any error.

Finally I was able to simulate this problem.
After PUT-ting input which you specified (BTW correct URI is http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/1)

I got response 500 from server.

After debuging I found out that JsonNormalizedNodeBodyReader class returns augmentation normalized node + instance identifier to augmentation.

In RestconfImpl method updateConfigurationData() do validation validateTopLevelNodeName() where getNodeType() method of inner class AugmentationIdentifier (belongs to class YangInstanceIdentifier) throw exception UnsupportedOperationException.

Therefore I am moving this bug to restconf.

Was it possible to put this input as you specified before?

I created these flow mods using java code, and not via RESTCONF. The pastebin that I had before was the result of the GET of config, not a PUT.

Note that I think this bug has already been fixed by this gerrit:

https://git.opendaylight.org/gerrit/#/c/18787/

If you look at the following package:

org.opendaylight.openflowplugin.extension.vendor.nicira.converter.match

there is a TunIPv4SrcConverter.java.

Note that there isn't a corresponding match converter for the tunnel destination – I'll open a new bug for that.

Hi Thomas,
you have right and we have two different bug in one bugzilla ticket. But I haven't found any relevant bug in restconf yet, so here is a quick fix for Jozef's description.

https://git.opendaylight.org/gerrit/#/c/21847/

After applying Vaso's and Jan's patch I can see some data also in operational.

Input data and config DS
"id": "openflow:1:5|tunnel|2|3|4|5",
"id": "openflow:1:5|sfcTunnel|2|3|4|5|Ipv4Address [_value=192.168.194.147]",
"id": "openflow:1:3|00:00:00:00:36:02|2|3|4|5|1",
"id": "openflow:1:1|00:00:00:00:35:02|6|3|7|5|1",
"id": "openflow:1:4|00:00:00:00:36:03|2|3|4|5|1",
"id": "drop|null",
"id": "openflow:1:5|sfcTunnel|6|3|7|5|Ipv4Address [_value=192.168.194.147]",
"id": "openflow:1:2|00:00:00:00:35:03|6|3|7|5|1",
"id": "openflow:1:5|tunnel|6|3|7|5

operational DS
FLOW.ID[openflow:1/1] openflow:1:1|00:00:00:00:35:02|6|3|7|5|1
FLOW.ID[openflow:1/1] #UF$TABLE*1-6
FLOW.ID[openflow:1/1] #UF$TABLE*1-7
FLOW.ID[openflow:1/1] openflow:1:4|00:00:00:00:36:03|2|3|4|5|1
FLOW.ID[openflow:1/1] #UF$TABLE*1-5
FLOW.ID[openflow:1/1] openflow:1:2|00:00:00:00:35:03|6|3|7|5|1
FLOW.ID[openflow:1/1] openflow:1:3|00:00:00:00:36:02|2|3|4|5|1

It looks like:

• 2 flows containing Ipv4Address[...] weren't recorded to operational DS.
• 3 other flows containing also text are probably stored as aliens.

It requires more investigation why some of flows aren't stored to operational DS and some are stored as aliens.

Problem with aliens is wiht openflowplugin in Li and in He version.

I tried to store flow which contained
"match": {
"openflowplugin-extension-general:extension-list": [
{
"extension-key": "openflowplugin-extension-nicira-match:nxm-nx-tun-id-key",
"extension": {
"openflowplugin-extension-nicira-match:nxm-nx-tun-id":

}
}
],
"in-port": "openflow:1:5"
},SERIALIZER_KEY

I found out that in NiciraExtensionProvider is converter for TUN_ID created with key (Nxm1Class.class, NxmNxTunId.class) but when this converter is searched in MatchExtensionHelper then values (OpenflowBasicClass, TunnelId) are used. It cause that conveter isn't found and therefore match is incorretly translated to SAL format which causes that match isn't found in flow registry which causes that new flow with alien ID is created in operational datastore.

I wasn't able to find root cause of this problem. Michal Rehak adviced me that problem should be in converting from byte stream to openflowjava. I tried to debug in artifact openflowjava-extension-nicira class TunIdCodec method deserialize(), but this method isn't called.

Hi,
I tried with those 9 flows in json form. First I ended up with 7 flows in device and 7 in DS/operational with 3 aliens. Then I did following:

• changed 2 tunnel-ids to openflow standard tunnel-id matches and got still 7 flows but only 1 alien.

• added empty match to the drop|null flow -> got 8 flows, 1 alien

• changed tunnel-ipv4-src so that they differ (otherwise 2 flows based on tunnel-ipv4-src match were equal) and got finally 9 flows with 2 aliens.

This is the input:
http://pastebin.com/62f6nx72

Now we have the alien issue - is it ok to deal with in in Beryllium?

Lowering the priority to normal - so it does not come in the major & above bug query. Assigning to Michal for his thoughts on this.

Michal - can you do one of these two alternatives:

1. open a new bug with the appropriate title and close this one
2. Change the title to reflect the actual bug