info: current and failover INT flows of a sink switch can have overlapping svlans

[viniarck]

I'm opening this issue as informational:

• current_path and failover_path INT flows of a sink switch can have overlapping svlans in some cases (when both paths have allocated the same svlans on the terminating NNIs links), which isn't an issue, but this has some implications that it's not safe to always remove the loop flows of a failover path due to this potential overlap that will result in the external loop.

• Here's one example, take this sw1 sink switch, which has two NNI ports 11 and 2, and the failover_path is setup on port 2 and the current_path on port 11:

                 external loop             
               +--------+                  
               |        |                  
               |        |                  
               |        |                  
         17 (NNI)     18|(NNI)             
          +-------------+----+             
          |                  | 11 (NNI)    
          |                  +-------------
          |                  |             
15 (UNI)  |      sw1         |             
----------+                  |             
          |                  | 2 (NNI)     
          |                  +-------------
          |                  |             
          +------------------+             

• Notice below the incoming flows from ports 11 and 2, they have the same cookie and match key values except for the in_port as expected, and sending out to port 17 (external loop):

    flow: {
      table_id: 0,
      owner: 'telemetry_int',
      table_group: 'evpl',
      priority: 20100,
      cookie: Decimal128("12148364083879497538"),
      idle_timeout: 0,
      hard_timeout: 0,
      match: { in_port: 11, dl_type: 2048, dl_vlan: 1, nw_proto: 6 },
      instructions: [
        {
          instruction_type: 'apply_actions',
          actions: [
            { action_type: 'add_int_metadata' },
            { action_type: 'output', port: 17 }
          ]
        }
      ]
    },

    flow: {
      table_id: 0,
      owner: 'telemetry_int',
      table_group: 'evpl',
      priority: 20100,
      cookie: Decimal128("12148364083879497538"),
      idle_timeout: 0,
      hard_timeout: 0,
      match: { in_port: 2, dl_type: 2048, dl_vlan: 1, nw_proto: 6 },
      instructions: [
        {
          instruction_type: 'apply_actions',
          actions: [
            { action_type: 'add_int_metadata' },
            { action_type: 'output', port: 17 }
          ]
        }
      ]
    },

However, notice that now in the loop the incoming port is the same, and since these flows are from the same EVC, same cookie, their match will overlap, which still works, but these flow entry will be used by both current_path and failover_path so, when removing the failover_path is not always safe to try to remove the loop flows, otherwise it'll break the current_path flows:

    flow: {
      table_id: 0,
      owner: 'telemetry_int',
      table_group: 'evpl',
      priority: 20000,
      cookie: Decimal128("12148364083879497538"),
      idle_timeout: 0,
      hard_timeout: 0,
      match: { in_port: 18, dl_vlan: 1 },
      instructions: [
        {
          instruction_type: 'apply_actions',
          actions: [ { action_type: 'send_report' } ]
        },
        { instruction_type: 'goto_table', table_id: 2 }
      ]
    },
    flow: {
      table_id: 2,
      owner: 'telemetry_int',
      table_group: 'evpl',
      priority: 20000,
      cookie: Decimal128("12148364083879497538"),
      idle_timeout: 0,
      hard_timeout: 0,
      match: { in_port: 18, dl_vlan: 1 },
      instructions: [
        {
          instruction_type: 'apply_actions',
          actions: [
            { action_type: 'pop_int' },
            { action_type: 'pop_vlan' },
            { action_type: 'output', port: 15 }
          ]
        }
      ]
    },

Nevertheless, currently, eventually they'll get removed in these cases:

• If the EVC no longer has any paths after another link down
• If the EVC gets deactivated (either after an admin update or another link down)
• If the EVC gets redeployed

Implications

• When failover_path terminating NNI is using a different svlan, if it doesn't get removed, then it would leak, it wouldn't break the data plane, but still it's not desirable. So, to try to solve this, mef_eline should also include current_path in the failover_old_path and failover_deployed events, just so telemetry_int can try to differentiate if the current_path and the removed flows of sink switches are using different svlans, if they are, then removing it should be OK. I'll address on feat: publish kytos/mef_eline.(failover_link_down|failover_old_path|failover_deployed) mef_eline#455, which is in-progress.