Hi Mark
On 2/5/22 03:55, Mark Michelson wrote:
On 1/31/22 01:20, Adrian Moreno wrote:
On 1/28/22 22:18, Ilya Maximets wrote:
On 1/28/22 17:04, Adrian Moreno wrote:
Introduce OFPFlow class and all its decoders.
Most of the decoders are generic (from decoders.py). Some have special
syntax and need a specific implementation.
Decoders for nat are moved to the common decoders.py because it's syntax
is shared with other types of flows (e.g: dpif flows).
Signed-off-by: Adrian Moreno <[email protected]>
---
python/automake.mk | 2 +
python/ovs/flows/decoders.py | 108 +++++++++
python/ovs/flows/ofp.py | 453 +++++++++++++++++++++++++++++++++++
python/ovs/flows/ofp_act.py | 243 +++++++++++++++++++
4 files changed, 806 insertions(+)
create mode 100644 python/ovs/flows/ofp.py
create mode 100644 python/ovs/flows/ofp_act.py
diff --git a/python/automake.mk b/python/automake.mk
index b7debfbd9..7b6d6596f 100644
--- a/python/automake.mk
+++ b/python/automake.mk
@@ -31,6 +31,8 @@ ovs_pyfiles = \
python/ovs/flows/flow.py \
python/ovs/flows/kv.py \
python/ovs/flows/list.py \
+ python/ovs/flows/ofp.py \
+ python/ovs/flows/ofp_act.py \
python/ovs/json.py \
python/ovs/jsonrpc.py \
python/ovs/ovsuuid.py \
diff --git a/python/ovs/flows/decoders.py b/python/ovs/flows/decoders.py
index 2f8e5bd0a..1462b0b9d 100644
--- a/python/ovs/flows/decoders.py
+++ b/python/ovs/flows/decoders.py
@@ -6,6 +6,7 @@ object.
"""
import netaddr
+import re
class Decoder(object):
@@ -414,3 +415,110 @@ class IPMask(Decoder):
def to_json(self):
return str(self)
+
+
+def decode_free_output(value):
+ """The value of the output action can be found free, i.e: without the
+ 'output' keyword. This decoder decodes its value when found this way."""
+ try:
+ return "output", {"port": int(value)}
+ except ValueError:
+ return "output", {"port": value.strip('"')}
+
+
+ipv4 = r"(?:\d{1,3}.?){3}\d{1,3}"
+ipv4_capture = r"({ipv4})".format(ipv4=ipv4)
+"""
+The following IPv6 regexp is a modified version of the one in:
+https://community.helpsystems.com/forums/intermapper/miscellaneous-topics/5acc4fcf-fa83-e511-80cf-0050568460e4?_ga=2.113564423.1432958022.1523882681-2146416484.1523557976
+
+It matches all these types of ipv6 addresses:
+fe80:0000:0000:0000:0204:61ff:fe9d:f156
+fe80:0:0:0:204:61ff:fe9d:f156
+fe80::204:61ff:fe9d:f156
+fe80:0000:0000:0000:0204:61ff:254.157.241.86
+fe80:0:0:0:0204:61ff:254.157.241.86
+fe80::204:61ff:254.157.241.86
+::1
+2001::
+fe80::
+"""
+ipv6 =
r"(?:(?:(?:[0-9A-Fa-f]{1,4}:){7}(?:[0-9A-Fa-f]{1,4}|:))|(?:(?:[0-9A-Fa-f]{1,4}:){6}(?::[0-9A-Fa-f]{1,4}|(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?:\.(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(?:(?:[0-9A-Fa-f]{1,4}:){5}(?:(?:(?::[0-9A-Fa-f]{1,4}){1,2})|:(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?:\.(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3})|:))|(?:(?:[0-9A-Fa-f]{1,4}:){4}(?:(?:(?::[0-9A-Fa-f]{1,4}){1,3})|(?:(?::[0-9A-Fa-f]{1,4})?:(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?:\.(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(?:(?:[0-9A-Fa-f]{1,4}:){3}(?:(?:(?::[0-9A-Fa-f]{1,4}){1,4})|(?:(?::[0-9A-Fa-f]{1,4}){0,2}:(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?:\.(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(?:(?:[0-9A-Fa-f]{1,4}:){2}(?:(?:(?::[0-9A-Fa-f]{1,4}){1,5})|(?:(?::[0-9A-Fa-f]{1,4}){0,3}:(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?:\.(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(?:(?:[0-9A-Fa-f]{1,4}:){1}(?:(?:(?::[0-9A-Fa-f]{1,4}){1,6})|(?:(?::[0-9A-Fa-f]{1,4}){0,4}:(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?:\.(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:))|(?::(?:(?:(?::[0-9A-Fa-f]{1,4}){1,7})|(?:(?::[0-9A-Fa-f]{1,4}){0,5}:(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)(?:\.(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)){3}))|:)))"
# noqa: E501
This line seems to be corrupted the patch in patchwork.
In any case, can we not have this line in the patch?
It doesn't look maintainable.
Can we use something like 'ipaddress' module to parse
ip addresses instead?
I agree having this huge blob is not very maintainable, maybe we can roll back
to the previous, more simplistic, regexp.
The goal of this regexp is not to parse the address but to extract it from the
ip/port range where we can have [ip_start:ip_end]:port_start:port_end. After
the substrings are extracted we use 'netaddr' module to extract it.
I think that regex is not a good choice here. There are too many variables (IPv4
vs IPv6) and optional parameters (ports may or may not be present, range may
only have one value) that regexes become complex very quickly. Throw in the fact
that ":" is the separator for IPv6 address sections AND is the separator between
IP addresses and ports, plus the fact that the presence of a port changes how to
express an IPv6 address, and you're talking about some unmaintainable regexes,
even if they're not as monstrous as the current IPv6 one.
If we go back to the previous approach I think it doesn't get _too_ complicated
since we only need to extract where the addresses are and leave the actual
address parsing to netaddr. So this code:
ipv4 = r"[\d\.]+"
ipv4_capture = r"({ipv4})".format(ipv4=ipv4)
ipv6 = r"[\w:\.]+"
ipv6_capture = r"(?:\[*)?({ipv6})(?:\]*)?".format(ipv6=ipv6)
port_range = r":(\d+)(?:-(\d+))?"
ip_range_regexp = r"{ip_cap}(?:-{ip_cap})?(?:{port_range})?"
ipv4_port_regex = re.compile(
ip_range_regexp.format(ip_cap=ipv4_capture, port_range=port_range)
)
ipv6_port_regex = re.compile(
ip_range_regexp.format(ip_cap=ipv6_capture, port_range=port_range)
)
... properly captures the following ip-port ranges:
("192.168.0.0:1000")
("192.168.0.0:1000-2000"),
("192.168.0.0-192.168.0.200:1000-2000"),
("fe80:0000:0000:0000:0204:61ff:fe9d:f156")
("fe80:0000:0000:0000:0204:61ff:fe9d:f150-fe80:0000:0000:0000:0204:61ff:fe9d:f15f")
("[fe80:0000:0000:0000:0204:61ff:fe9d:f150]-[fe80:0000:0000:0000:0204:61ff:fe9d:f15f]:255")
("[fe80::f150]-[fe80::f15f]:255-300")
("[fe80::204:61ff:254.157.241.86]-[fe80::204:61ff:254.157.241.100]:255-300")
... plus all of the ip/port ranges used in the ofproto unit tests since they
pass with patch 11/18.
Do you think it's worth replacing this with some heuristics in order to
determine what's the format of the ip-range string?
--
Adrián Moreno
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
