3.6. Handling Maintenance Windows
Whenever network components are under maintenance, the operator wants to inhibit the emission of symptoms from those components. A typical use case is device maintenance, during which the device is not supposed to be operational. As such, symptoms related to the device health should be ignored. Symptoms related to the device-specific subservices, such as the interfaces, might also be ignored because their state changes are probably the consequence of the maintenance.¶
The ietf-service-assurance model described in [RFC9418] enables flagging subservices as under maintenance and, in that case, requires a string that identifies the person or process that requested the maintenance. When a service or subservice is flagged as under maintenance, it must report a generic "Under Maintenance" symptom for propagation towards subservices that depend on this specific subservice. Any other symptom from this service or by one of its impacting dependencies must not be reported.¶
We illustrate this mechanism on three independent examples based on the assurance graph depicted in Figure 2:¶
- Device maintenance, for instance, upgrading the device OS. The operator flags the subservice "Peer1" device as under maintenance. This inhibits the emission of symptoms, except "Under Maintenance" from "Peer1 Physical Interface", "Peer1 Tunnel Interface", and "Tunnel Service Instance". All other subservices are unaffected.¶
- Interface maintenance, for instance, replacing a broken optic. The operator flags the subservice "Peer1 Physical Interface" as under maintenance. This inhibits the emission of symptoms, except "Under Maintenance" from "Peer 1 Tunnel Interface" and "Tunnel Service Instance". All other subservices are unaffected.¶
- Routing protocol maintenance, for instance, modifying parameters or redistribution. The operator marks the subservice "IS-IS Routing Protocol" as under maintenance. This inhibits the emission of symptoms, except "Under Maintenance" from "IP connectivity" and "Tunnel Service Instance". All other subservices are unaffected.¶
In each example above, the subservice under maintenance is completely impacting the service instance, putting it under maintenance as well. There are use cases where the subservice under maintenance only partially impacts the service instance. For instance, consider a service instance supported by both a primary and backup path. If a subservice impacting the primary path is under maintenance, the service instance might still be functional but degraded. In that case, the status of the service instance might include "Primary path Under Maintenance", "No redundancy", as well as other symptoms from the backup path to explain the lower health score. In general, the computation of the service instance status from the subservices is done in the SAIN collector whose implementation is out of scope for this document.¶
The maintenance of a subservice might modify or hide modifications of the structure of the assurance graph. Therefore, unflagging a subservice as under maintenance should trigger an update of the assurance graph.¶