Concurrent field modification in parallel composition

[snizovtsev]

Let

p1 = match(inport=1) >> modify(outport=2, dstip='1.2.3.4')
p2 = match(inport=1) >> modify(outport=3)
p3 = match(inport=1) >> modify(outport=4, dstmac='11:22:33:44:55:66')

According to parallel composition semantics (p1 + p2) should produce two packets: one on port 3 with unmodified fields and one on port 2 with dstip='1.2.3.4'. It's implementable with this openflow 1.0 rule:

in_port=1 actions=output:3,mod_nw_dst:1.2.3.4,output:2

However, Pyretic-generated rule will send modified packet to both ports:

in_port=1 actions=mod_nw_dst:1.2.3.4,output:2,output:3

Second problem is: what we should generate for (p1 + p3)? Seems it isn't implementable with openflow 1.0-1.4. We need to save/restore packet fields or dup entire packet.

[jnfoster]

Hi Sergey,

Yes, this is a known issue with NetCore vs. OpenFlow 1.x. Possible
solutions are either for the compiler to either throw an exception if a
union is "unimplementable" or fall back to reactive rule generation.

-N

On Fri, May 15, 2015 at 2:51 PM, Sergey notifications@github.com wrote:

Let

p1 = match(inport=1) >> modify(outport=2, dstip='1.2.3.4')
p2 = match(inport=1) >> modify(outport=3)
p3 = match(inport=1) >> modify(outport=4, dstmac='11:22:33:44:55:66')

According to parallel composition semantics (p1 + p2) should produce two
packets: one on port 3 with unmodified fields and one on port 2 with
dstip='1.2.3.4'. It's implementable with this openflow 1.0 rule:

in_port=1 actions=output:3,mod_nw_dst:1.2.3.4,output:2

However, Pyretic-generated rule will send modified packet to both ports:

in_port=1 actions=mod_nw_dst:1.2.3.4,output:2,output:3

Second problem is: what we should generate for (p1 + p3)? Seems it isn't
implementable with openflow 1.0-1.4. We need to save/restore packet fields
or dup entire packet.

—
Reply to this email directly or view it on GitHub
#43.