sdntrace_cp isn't currently aware of which table id it's exactly matching, so in cases where you have the same match but in different tables but different actions it can end up tracing incorrectly (depending on which one was last updated and if they both have the same priority).
When performing a trace in a switch, when it hits a "instruction_type": "goto_table",, "table_id": <x>, the subsequent matches of this same switch should only match "table_id": <x>. The initial lookup table should always be table 0.
This is a case where we'll have with telemetry_int as described on EP031, for instance, notice two flows with same match but in different tables (one managed by mef_eline and the other by telemetry_int) but with different actions, so if telemetry_int ends up using sdntrace_cp for consistency then this will need to be supported (this will be discussed in the new update of the blueprint).
We'll need to cover the following:
When sdntrace_cp hits a goto_table it doesn't stop matching
Potentially try to ensure that telemetry_int regardless of the table uses a slightly higher priority to also facilitate for matching, there cases in the blueprint where the priority would be the same, since the table was different, but if it can facilitate we might consider it. To be more robust though, ideally, point 1 should be fully covered and sdntrace_cp fully aware of which table it's matching on a switch.
sdntrace_cp
isn't currently aware of which table id it's exactly matching, so in cases where you have the same match but in different tables but different actions it can end up tracing incorrectly (depending on which one was last updated and if they both have the same priority).When performing a trace in a switch, when it hits a
"instruction_type": "goto_table",
,"table_id": <x>
, the subsequent matches of this same switch should only match"table_id": <x>
. The initial lookup table should always be table 0.This is a case where we'll have with
telemetry_int
as described on EP031, for instance, notice two flows with same match but in different tables (one managed bymef_eline
and the other bytelemetry_int
) but with different actions, so iftelemetry_int
ends up usingsdntrace_cp
for consistency then this will need to be supported (this will be discussed in the new update of the blueprint).We'll need to cover the following:
sdntrace_cp
hits agoto_table
it doesn't stop matchingtelemetry_int
regardless of the table uses a slightly higher priority to also facilitate for matching, there cases in the blueprint where the priority would be the same, since the table was different, but if it can facilitate we might consider it. To be more robust though, ideally, point 1 should be fully covered andsdntrace_cp
fully aware of which table it's matching on a switch.Example of a
mef_eline
andtelemetry_int
flow: