(Luis) Issue #5 for draft-ma-opsawg-schedule-yang – Complementary information for the schedules

[luismcontreras]

It seems convenient to add some additional general parameters to the schedules. The suggested parameters are the following:

• Schedule-id: it seems convenient to take track of each schedule so that the action and the result of the scheduled action can be associated to a particular schedule. This can be relevant for troubleshooting, historical records, etc. Also for retrieving existing programmed schedules in the system.
• Who: it can be important to identify who has provide the schedule (e.g., NOC, Planning, etc). This can be associated to privileges for the schedules, precedence in the schedules, etc. Basically, management actions around the schedules.
• Schedule-override: one schedule can substitute / eliminate other schedules. With the schedule-id as defined before it is possible to indicate the override of a previously created schedule. Note that with the current approach in draft-ma-opsawg-schedule-yang, there is no way of eliminating or changing an existing schedule.
• Schedule-removal: just for eliminating completely a previously activated schedule.

[boucadair]

• Schedule-id: it seems convenient to take track of each schedule so that the action and the result of the scheduled action can be associated to a particular schedule. This can be relevant for troubleshooting, historical records, etc. Also for retrieving existing programmed schedules in the system.

We can indeed consider defining variants of these groupings (recurrence, recurrence-with-date-times, and icalendar-recurrence) to include a name. The name can be used as a key of list of sch is needed in a given context.

Not sure the other parameters make sense in a common model.

[QiufangMa]

This ticket seems to propose the CRUD of scheduling status, which I agree would be important and useful. But I share the concern that these have jumped out of the schedule itself, and thus kind of beyond the scope of current document.

That said, if we can define some scheduling based framework in the future, schedule status management would be something very useful. There are others that i think also be good to know:

• occurrence list info
• next occurrence timestamp
• isOccurrencing now?

[luismcontreras]

I like that idea of scheduling based framework. Maybe is the way to follow for the mahnaging the lifecycle of this automatic actiosn in teh network. Aspects such knowing who was responsible of some actions is relevant for operations. If you follow that way I would be delighted ot help.

[danielkinguk]

We talked about a common scheduling framework last year as we discussed the direction of the work. Given all the interest and schedule YANG models being developed, it seems even more important to have now so people can see which models provide specific functionality and the components involved, we can identify the external interfaces and what function they provide as well. One aspect of the I-D would be to address/highlight some of the scalability concerns folks might have, providing clear and consistent methods for handling time-based configurations across numerous devices, would be crucial for automation in large-scale network management. Thinking aloud, we could also consider some use cases with code examples, maybe time-based QoS, energy-saving and link management, use cases. Some JSON examples as an appendix in the I-D or a WG wiki/GitHub.

Hmm... Given the scope of the scheduling discussion and 1-2 additional I-Ds, it could also be a focused/short lived WG - as OPSAWG is already rather overloaded.