[openflowplugin-dev] [controller-dev] Flow actions were reordered.


Ed Warnicke (eaw) <eaw@...>
 

If I recall correctly order is user settable.

On Jul 8, 2014, at 6:05 PM, "Colin Dixon" <colin@...> wrote:

I'm fairly certain that _order is an internal parameter set by the MD-SAL and not accessible when you send data, but I could be wrong.

--Colin


On Tue, Jul 8, 2014 at 6:02 PM, Rob Adams <readams@...> wrote:
Shouldn't it sort by the "order" parameter?  I presume that's what its for...


On Tue, Jul 8, 2014 at 3:58 PM, Colin Dixon <colin@...> wrote:
My guess is that this is a bug in openflowjava's (adding openflowjava-dev) openflow-action.yang where they should specify that the list of actions in actions-grouping is ordered-by-user.

Right now it is not:
    grouping actions-grouping {
        list action {
            config false;
            leaf type {
                type identityref {
                    base oft:action-base;
                }
            }
        }
    }

It should be a simple fix.

I've proposed a simple fix here:
https://git.opendaylight.org/gerrit/8830

You can try pulling that and building to see if it fixes your problem.

Cheers,
--Colin


On Tue, Jul 8, 2014 at 5:16 PM, Kiran Agrahara Sreenivasa <kkoushik@...> wrote:
If you have the YANG data model, have you tried specifying "ordered-by-user" in the list?
Thanks
Kiran


-----Original Message-----
From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Shigeru Yasuda
Sent: Tuesday, July 08, 2014 11:18 AM
To: controller-dev@...; openflowplugin-dev@...; vtn-dev@...
Subject: [controller-dev] Flow actions were reordered.

Hi folks,

I observed that flow actions in a flow entry were reordered unexpectedly when I tested VTN with OF13 plugin.

I configured 3 actions in a flow entry (via sal-compatibility):

   action[0]: PUSH_VLAN
   action[1]: SET_FIELD (VLAN_VID)
   action[2]: OUTPUT

But above actions were encoded into an OF13 FLOW_MOD as follows:

   action[0]: OUTPUT
   action[1]: PUSH_VLAN
   action[2]: SET_FIELD (VLAN_VID)

I embedded some trace logs into the controller source, then I observed that flow actions in MD-SAL flow were already reordered when
FlowChangeListener.add() was called.

  _applyActions=ApplyActions [
    _action=[
      Action [
        _order=2, _key=ActionKey [_order=2],
        _action=OutputActionCase [
          _outputAction=OutputAction [
            _outputNodeConnector=Uri [_value=openflow:4:1],
            augmentation=[]
          ],
          augmentation=[]
        ],
        augmentation=[]
      ],
      Action [
        _order=0, _key=ActionKey [_order=0],
        _action=PushVlanActionCase [
          _pushVlanAction=PushVlanAction [
            _ethernetType=33024,
            augmentation=[]
          ],
          augmentation=[]
        ],
        augmentation=[]
      ],
      Action [
        _order=1, _key=ActionKey [_order=1],
        _action=SetVlanIdActionCase [
          _setVlanIdAction=SetVlanIdAction [
            _vlanId=VlanId [_value=10],
            augmentation=[]
          ],
          augmentation=[]
        ],
        augmentation=[]
      ]
    ],
    augmentation=[]
  ], ...


And I enabled trace logging for BindingToNormalizedNodeCodec class in sal-binding-broker, then I observed that MD-SAL actions were deserialized out of order.

  2014-07-09 00:37:40.849 GMT+09:00 [pool-17-thread-1] TRACE \
    o.o.c.m.s.b.i.BindingToNormalizedNodeCodec - \
    InstanceIdentifier Path Deserialization: [... snipped ..] \
    action/(urn:opendaylight:flow:inventory?revision=2013-08-19)output-action

  2014-07-09 00:37:40.851 GMT+09:00 [pool-17-thread-1] TRACE \
    o.o.c.m.s.b.i.BindingToNormalizedNodeCodec - \
    InstanceIdentifier Path Deserialization: [... snipped ..] \
    action/(urn:opendaylight:flow:inventory?revision=2013-08-19)set-vlan-id-action

  2014-07-09 00:37:40.851 GMT+09:00 [pool-17-thread-1] TRACE \
    o.o.c.m.s.b.i.BindingToNormalizedNodeCodec - \
    InstanceIdentifier Path Deserialization: [... snipped ..] \
    action/(urn:opendaylight:flow:inventory?revision=2013-08-19)push-vlan-action

The order of elements in a YANG data list seems to be unspecified because it may be randomized by deserialization. My understanding is correct?
If so, I think openflowplugin should sort MD-SAL actions according to action order (Action.getOrder()) when it converts MD-SAL actions into OF actions.

Regards,

--
Shigeru Yasuda
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev


_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev



_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev


Michal Polkorab
 

Hello,


Colin: +1. Order is not send to switch.


Regards

Michal Polkorab


From: Ed Warnicke (eaw) <eaw@...>
Sent: 09 July 2014 03:47
To: Colin Dixon
Cc: Kiran Agrahara Sreenivasa; openflowplugin-dev@...; openflowjava-dev@...; Rob Adams; controller-dev@...; vtn-dev@...
Subject: Re: [openflowplugin-dev] [controller-dev] Flow actions were reordered.
 
If I recall correctly order is user settable.

On Jul 8, 2014, at 6:05 PM, "Colin Dixon" <colin@...> wrote:

I'm fairly certain that _order is an internal parameter set by the MD-SAL and not accessible when you send data, but I could be wrong.

--Colin


On Tue, Jul 8, 2014 at 6:02 PM, Rob Adams <readams@...> wrote:
Shouldn't it sort by the "order" parameter?  I presume that's what its for...


On Tue, Jul 8, 2014 at 3:58 PM, Colin Dixon <colin@...> wrote:
My guess is that this is a bug in openflowjava's (adding openflowjava-dev) openflow-action.yang where they should specify that the list of actions in actions-grouping is ordered-by-user.

Right now it is not:
    grouping actions-grouping {
        list action {
            config false;
            leaf type {
                type identityref {
                    base oft:action-base;
                }
            }
        }
    }

It should be a simple fix.

I've proposed a simple fix here:
https://git.opendaylight.org/gerrit/8830

You can try pulling that and building to see if it fixes your problem.

Cheers,
--Colin


On Tue, Jul 8, 2014 at 5:16 PM, Kiran Agrahara Sreenivasa <kkoushik@...> wrote:
If you have the YANG data model, have you tried specifying "ordered-by-user" in the list?
Thanks
Kiran


-----Original Message-----
From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Shigeru Yasuda
Sent: Tuesday, July 08, 2014 11:18 AM
To: controller-dev@...; openflowplugin-dev@...; vtn-dev@...
Subject: [controller-dev] Flow actions were reordered.

Hi folks,

I observed that flow actions in a flow entry were reordered unexpectedly when I tested VTN with OF13 plugin.

I configured 3 actions in a flow entry (via sal-compatibility):

   action[0]: PUSH_VLAN
   action[1]: SET_FIELD (VLAN_VID)
   action[2]: OUTPUT

But above actions were encoded into an OF13 FLOW_MOD as follows:

   action[0]: OUTPUT
   action[1]: PUSH_VLAN
   action[2]: SET_FIELD (VLAN_VID)

I embedded some trace logs into the controller source, then I observed that flow actions in MD-SAL flow were already reordered when
FlowChangeListener.add() was called.

  _applyActions=ApplyActions [
    _action=[
      Action [
        _order=2, _key=ActionKey [_order=2],
        _action=OutputActionCase [
          _outputAction=OutputAction [
            _outputNodeConnector=Uri [_value=openflow:4:1],
            augmentation=[]
          ],
          augmentation=[]
        ],
        augmentation=[]
      ],
      Action [
        _order=0, _key=ActionKey [_order=0],
        _action=PushVlanActionCase [
          _pushVlanAction=PushVlanAction [
            _ethernetType=33024,
            augmentation=[]
          ],
          augmentation=[]
        ],
        augmentation=[]
      ],
      Action [
        _order=1, _key=ActionKey [_order=1],
        _action=SetVlanIdActionCase [
          _setVlanIdAction=SetVlanIdAction [
            _vlanId=VlanId [_value=10],
            augmentation=[]
          ],
          augmentation=[]
        ],
        augmentation=[]
      ]
    ],
    augmentation=[]
  ], ...


And I enabled trace logging for BindingToNormalizedNodeCodec class in sal-binding-broker, then I observed that MD-SAL actions were deserialized out of order.

  2014-07-09 00:37:40.849 GMT+09:00 [pool-17-thread-1] TRACE \
    o.o.c.m.s.b.i.BindingToNormalizedNodeCodec - \
    InstanceIdentifier Path Deserialization: [... snipped ..] \
    action/(urn:opendaylight:flow:inventory?revision=2013-08-19)output-action

  2014-07-09 00:37:40.851 GMT+09:00 [pool-17-thread-1] TRACE \
    o.o.c.m.s.b.i.BindingToNormalizedNodeCodec - \
    InstanceIdentifier Path Deserialization: [... snipped ..] \
    action/(urn:opendaylight:flow:inventory?revision=2013-08-19)set-vlan-id-action

  2014-07-09 00:37:40.851 GMT+09:00 [pool-17-thread-1] TRACE \
    o.o.c.m.s.b.i.BindingToNormalizedNodeCodec - \
    InstanceIdentifier Path Deserialization: [... snipped ..] \
    action/(urn:opendaylight:flow:inventory?revision=2013-08-19)push-vlan-action

The order of elements in a YANG data list seems to be unspecified because it may be randomized by deserialization. My understanding is correct?
If so, I think openflowplugin should sort MD-SAL actions according to action order (Action.getOrder()) when it converts MD-SAL actions into OF actions.

Regards,

--
Shigeru Yasuda
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev


_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev



_______________________________________________
openflowplugin-dev mailing list
openflowplugin-dev@...
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev

MichalPolkoráb

Software Developer


Mlynské Nivy 56 / 821 05 Bratislava / Slovakia
+421 918 378 907
/ michal.polkorab@...
reception: +421 2 206 65 111
/ www.pantheon.sk

logo