If user use ff:ff:ff:ff:ff:ff as a ethernet mask for it's ethernet source and destination match, plugin fails to put the flow's statistics on the same flow-id and it uses alien-id to store the flow statistics.

Mainly it's happening because ff:ff:ff:ff:ff:ff is basically like a no-mask, so when plugin fetch the statistics, they don't get this mask from the switch and internal custom comparator fails to match it against the config flow, because it has this full mask. Openflowplugin spec says

"An all-zero-bits oxm_mask is equivalent to omitting the OXM TLV entirely. An all-one-bits oxm_mask is equivalent to specifying 0 for oxm_hasmask and omitting oxm_mask"

As per above text from specification, looks like it's expected behavior if switch doesn't send the mask back if it "ff:ff:ff:ff:ff:ff", but from user perspective also it's not a invalid mask.