What is the probability and severity of the issue? I.e. the overall risk
A: When external network's MTU is lower then the internal ones, this option allows OVN to send a "need to frag" back to the sender so packets can be adjusted. As for severity, I think the main issue is because ML2/OVN and ML2/OVS will differ on this, where ML2/OVS has this featured enabled by default and ML2/OVN does not. So it can be considered a "gap" between the two drivers. But, one can always enable this option for ML2/OVN if needed (as long as the kernel version is  >= 5.2 to support it)

Does this affect specific configurations, hardware, environmental factors, etc.?
A: This is a configuration option in ML2/OVN

Are any partners relying on this functionality in order to ship an ecosystem product?
A: Not that I am aware of

What proportion of our customers could hit this issue?
A: So far we had one customer hitting this issue after migration

Does this happen for only a specific use case?
A: Yes, when there's different MTUs for internal and external networks.

What proportion of our CI infrastructure, automation, and test cases does this issue impact?
A: Perhaps some unit or functional tests, but I don't think we have any CI that would test this feature in Neutron. Perhaps there's one in core OVN but I am not aware of.

Is this a regression in supported functionality from a previous release?
A: It was never enabled by default in ML2/OVN due to the kernel requirements at the time but, it is default in ML2/OVS. So could be consider a "regression" in case of migration.

Is there a clear workaround?
A: Yes, just enable a configuration option

Is there potential doc impact?
A: No

If this is a UI issue:
Is the UI still fit for its purpose/goal?

Does the bug compromise the overall trustworthiness of the UI?

Overall context and effort – is the overall impact bigger/worse than the bug in isolation? For example, 1 workaround might seem ok, 5 is getting ugly, 20 might be unacceptable (rough numbers).