Proposals for Link S_VLAN choosing criteria.

[Alopalao]

Without testing any implementation I thought and recollected some proposals:

1. Switch order of deletion and installation

• First find a path and choose the VLANs
• Continue whether a path was found or not
• Delete previous path.
• If no VLANS were available, try again.
• Proceed as normal.

Challenges:

• For EVC redeployments and updates, the paths are deleted before deployment. The deletions would need to be performed in evc.deploy() only.
  • evc.deploy() needs to be modified because it will not redeploy if a primary_path and backup_path are used.

2. Toggle per installation, take_last, PR

• EVC has a 'take_last' (or similar name) field with a boolean value.
• When take_last is True, Every link installed is going to take the last VLAN available.
• take_last toggles automatically every successfull installation of current_path. failover_path does toggle its value as it always follows what current_path is taking.

Improvements:

• Another value can be added to EVC so take_last toggles automatically from True to False.

3. Skip 1 VLAN, skip.

• EVC has a skip (or similar name) field with a boolean value.
• skip will indicate that the chosen links will skip 1 VLAN and take the next one available if possible.
• failover_path follows the same pattern as in current_path

Improvements:

• Another value can be added to EVC so that the value of skip can be toggle per each sucessful instalation of current_path

4. Recognize static EVCs and keep path:

• In the case of EVCs with a primary_path or backup_path that are valid and UP, re-use these paths.

1. Check if it would deploy to primary_path or backup_path
   1.1. If true, save the VLANS from path
2. Delete previous path
3. Choose VLANs avoiding the previous path's VLANs
4. Continue as normal.

Challenges:

• This proposal presents the same challenges as solution 1. Path either primary_path or backup_path are discarded before deploying starts.

5. Add an option to API request "redeploy":

• Add parameter to API request PATCH http://localhost:8181/api/kytos/mef_eline/v2/evc/{circuit_id}/redeploy?diff_vlan=True
• Modified evc.deploy() to accept previous_path_dict which would look like {link.id: S_VLAN}, returned from evc.remove_current_flows() and evc.remove().
• previous_path_dict would be a dictionary so Path() can avoid the S_VLAN stored.
• failover_path is not affected.
• Or create a new API request that carefully chooses different VLANs.

[viniarck]

@Alopalao, I think option 5) is a good compromise that specifically solves the problem on-demand, that's very interesting and easy to maintain while empowering network engineers to solve the problem if a conflicting s_vlan case ever happens (which we don't expect anymore). Since network operators want to sometimes be able to redeploy with a diff s_vlan per link they can use this option. Plus, no new issues have been reported on version 2023.2 where network operators had to try to force to change the s_vlan, so this should be something that will only be used on-demand and in specific cases, and the current implementation has been shown to be stable with the current s_vlan allocations.

What's your recommendation @Alopalao? Should we go for 5)? Let's ask @italovalcy if he'd be OK with it and if agrees with the trade offs we're going for here. Can we have the url as diff_s_vlan instead of diff_vlan just so it's clear that's related to s_vlan?

• 1) and 4) are very interesting, but I think optimizations should be handled on a different epic and only handled when issue 394 gets prioritized. My main concern with provisioning a new path and then deleting the old with dynamic paths, is that we'd need to also ensure that it wouldn't use generic switch flow matches otherwise, let's say a new current_path that has some overlapping link or switch might end up getting deleted too, and therefore could end up broken. mef_eline implementation was always assuming that pre-deleting the current path was safe as a clean up procedure.

• 2) and 3) are lightweight but never completely guarantee that each link of a path will have a diff s_vlan, since it depends on the order each path deployment.

Other option 6) that comes to mind would be to track each per EVC per link the last two s_vlans, since each EVC can only have up to 2 paths, and never use any of the prior two vlans, this could be synced in memory, lookups would be cheap, but we'd pay the price to to have to keep storing this in a new collection, and that would be too much too implement and maintain just for this specific functionality, so not worth it.

Nicely done, Aldo, great proposed solutions.