Description: when a switch X needs to be replaced (e.g., due to hardware failure), the orchestration tool needs to provide means to move the services using X to a different switch in the topology.
Expected deliverables:
The orchestration tool must support the procedure described below:
The following situations are possible:
a) same hardware and same datapath id: no action from Kytos
---> just create an MW, disconnect cables from the old switch and connect to the new (as part of the MW, the operator needs to schedule a maintenance which will then move the services out of the switch. Actually, we need to discuss whether this will be part of the Maintenance Napp or a different Napp)
---> the maintenance and mef_eline napps already do this
---> it'd be good to know if mef_eline did the Right Thing, and the MW could be confirmed
---> how to know impact? mef_eline return how many circuits will be affected. one of those won't have an alternate path
---> check again at the beginning of the maintenance window
b) same hardware and different datapath id: the network operator adds a new datapath-id to the switch (or change the current one) and activate it (a MW needs to be schedule before, to move the circuits out of this switch). We need to save all information of the equipment to keep the historic. All operation should generate a log entry (e.g., switch changed serial number, switch changed datapath-id, etc)
c) different hardware and different datapath id (this case will be left for further discussion):
c.1) The network operator submits a "map of ports" (a list mapping the old ports to the new ones, with possible overlapping. Example: eth1 > eth2/1; eth2 > eth2/2; eth3 > eth2/1; eth4 > eth2/4; ...)
c.2) The orchestration tool check for inconsistencies on port mapping (e.g., services conflicting with the same VLAN id), and it tries to solve the inconsistency automatically (e.g., using different VLAN id along the path). In case some conflicts are not possible to fix automatically, return to the operator and ask for a new port mapping
c.3) change the services according to the port mapping
c.4) deactivate the old switch on the topology (if it is a replacement, wouldn't the "old" become the "new"? Yes, good idea! Let's keep only one and update the history of this node)
d) different hardware and same datapath id: very similar to previousews case (very similar to which one? If both switches will be online at the same time, it will be a problem. So, maybe it is not similar and it is the most dangerous case. let's split this in two problems: 1) let's assume that kytos can handle two switches with the same datapath-id, so this case is very similar to case C; 2) if Kytos doesn't support two switches with the same datapath-id we just need to disable the first, activate the new switch and apply procedure on C) (question: what happens if two switches with the same DPID connect to Kytos? good question, we need to check)
Original issue opened by @italovalcy at https://github.com/kytos/maintenance/issues/18.
Description: when a switch X needs to be replaced (e.g., due to hardware failure), the orchestration tool needs to provide means to move the services using X to a different switch in the topology.
Expected deliverables:
The following situations are possible:
a) same hardware and same datapath id: no action from Kytos ---> just create an MW, disconnect cables from the old switch and connect to the new (as part of the MW, the operator needs to schedule a maintenance which will then move the services out of the switch. Actually, we need to discuss whether this will be part of the Maintenance Napp or a different Napp) ---> the maintenance and mef_eline napps already do this ---> it'd be good to know if mef_eline did the Right Thing, and the MW could be confirmed ---> how to know impact? mef_eline return how many circuits will be affected. one of those won't have an alternate path ---> check again at the beginning of the maintenance window b) same hardware and different datapath id: the network operator adds a new datapath-id to the switch (or change the current one) and activate it (a MW needs to be schedule before, to move the circuits out of this switch). We need to save all information of the equipment to keep the historic. All operation should generate a log entry (e.g., switch changed serial number, switch changed datapath-id, etc)
c) different hardware and different datapath id (this case will be left for further discussion): c.1) The network operator submits a "map of ports" (a list mapping the old ports to the new ones, with possible overlapping. Example: eth1 > eth2/1; eth2 > eth2/2; eth3 > eth2/1; eth4 > eth2/4; ...) c.2) The orchestration tool check for inconsistencies on port mapping (e.g., services conflicting with the same VLAN id), and it tries to solve the inconsistency automatically (e.g., using different VLAN id along the path). In case some conflicts are not possible to fix automatically, return to the operator and ask for a new port mapping c.3) change the services according to the port mapping c.4) deactivate the old switch on the topology (if it is a replacement, wouldn't the "old" become the "new"? Yes, good idea! Let's keep only one and update the history of this node) d) different hardware and same datapath id: very similar to previousews case (very similar to which one? If both switches will be online at the same time, it will be a problem. So, maybe it is not similar and it is the most dangerous case. let's split this in two problems: 1) let's assume that kytos can handle two switches with the same datapath-id, so this case is very similar to case C; 2) if Kytos doesn't support two switches with the same datapath-id we just need to disable the first, activate the new switch and apply procedure on C) (question: what happens if two switches with the same DPID connect to Kytos? good question, we need to check)