Python Extensions

[craig-riecke]

Writing the Frenetic Programmers Guide, I've noticed a few non-orthogonal constructs that require a disproportionate amount of explanation. These can all be straightened out in Python in backwards-compatible ways:

• SetPort(n) should be usable in a Packet Out as a synonym for Output(Physical(n)). Other Set's (synonyms for Mod(Field())) can be used in either a Packet Out action list or a NetKAT policy.
• A Seq of policies should be able to used in a Packet Out command as a synonym for a list of policies.
• SetPort(p1, p2, ... pn) should be a synonym for SetPort(p1) | SetPort(p2) | ... | SetPort(pn). This makes the NetKAT combination rules a little easier to explain. I'm a little uneasy about calling it SetPort with a list, maybe SetPorts or MultiplexPort would be better.
• Parsing a packet and testing header values using RYU Packet Library treads the same ground as a NetKAT predicate. You should be able to use NetKAT predicates directly in the controller's Packet In handler - e.g. self.matches(payload, PortEq(23) & EthTypeEq(0x800)). That way you have to only learn one predicate language: NetKAT. Python then pretty much emulates the OpenFlow matcher.
• Similarly, you should be able to extract values from a payload without touching RYU Packet library at all. A simple packet = self.parse(payload) should return a packet with all the OpenFlow fields in a dict, so that packet.EthType is 0x800. Though this doesn't cover cases where the fields you want are not exposed by OpenFlow (e.g. ARP opcodes or custom probe packet information), it makes the majority of cases MUCH easier.

All of these can be done without extensions to Frenetic proper. Comments welcome!

[jnfoster]

Well spotted. I agree with all of this!

On Wed, Apr 27, 2016 at 10:13 AM, Craig Riecke notifications@github.com wrote:

Writing the Frenetic Programmers Guide, I've noticed a few non-orthogonal constructs that require a disproportionate amount of explanation. These can all be straightened out in Python in backwards-compatible ways:

• SetPort(n) should be usable in a Packet Out as a synonym for Output(Physical(n)). Other Set's (synonyms for Mod(Field())) can be used in either a Packet Out action list or a NetKAT policy.
• A Seq of policies should be able to used in a Packet Out command as a synonym for a list of policies.
• SetPort(p1, p2, ... pn) should be a synonym for SetPort(p1) | SetPort(p2) | ... | SetPort(pn). This makes the NetKAT combination rules a little easier to explain. I'm a little uneasy about calling it SetPort with a list, maybe SetPorts or MultiplexPort would be better.
• Parsing a packet and testing header values using RYU Packet Library treads the same ground as a NetKAT predicate. You should be able to use NetKAT predicates directly in the controller's Packet In handler - e.g. self.matches(payload, PortEq(23) & EthTypeEq(0x800)). That way you have to only learn one predicate language: NetKAT. Python then pretty much emulates the OpenFlow matcher.
• Similarly, you should be able to extract values from a payload without touching RYU Packet library at all. A simple packet = self.parse(payload) should return a packet with all the OpenFlow fields in a dict, so that packet.EthType is 0x800. Though this doesn't cover cases where the fields you want are not exposed by OpenFlow (e.g. ARP opcodes or custom probe packet information), it makes the majority of cases MUCH easier.

All of these can be done without extensions to Frenetic proper. Comments welcome!

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/frenetic-lang/frenetic/issues/491

[craig-riecke]

There's also a small bug in syntax.py that we'll fix at the same time:

        assert type(json['port_id']) == int and json['switch_id'] >= 0