Open luismcontreras opened 9 months ago
boucadair
commented
9 months ago How about creating a generic grouping to cover these matters and similar ones:
grouping generic-schedule-parameters
danielkinguk
commented
9 months ago Maybe a wider consideration, and I'm just thinking aloud as I write text for the TVR Requirements I-D.
It will be important for devices to have the ability to operate autonomously, yet their autonomy should be appropriately limited to prevent excessive freewheeling. Equally, the capability to differentiate between real-time adjustments, which may necessitate immediate alterations to the schedule, and modifications made by a centralized authority as part of a strategic planning process. Furthermore, the effectiveness of these scheduling updates, whether comprehensive or incremental, is significantly influenced by the reliability of communication to network nodes. Factors such as weather conditions can impact connectivity, thereby affecting the communication between the nodes and the central scheduling entity.
danielkinguk
commented
9 months ago We also need to define "source data" in our TVR Requirements I-D.
For a TVR schedule generation system, "source data" refers to the raw, original data inputs that are used to create, populate, and inform the TVR scheduling process. This data serves as the foundational information from which the system generates schedules for network resource scheduling. The nature and structure of source data may vary depending on the specific application of the scheduling system, but it typically includes the following elements:
Resource Availability: Information about the availability of the resources to be scheduled. Resource Constraints: Constraints related to schedule resources. Resource Details: Required resources, dependencies, and any specific requirements. Time Constraints: Restrictions related to time.
danielkinguk
commented
9 months ago How to manage the freshness of a received schedule. How to manage multiple schedules from different sources and possible time variance? Any precedence requirements, et al.? Should perceived level of "Trust" be a factor, based on the originating source of schedule?
Some capabilities could be part of schedule-yang data model. Timestamps and versioning in the schedule data to track when the schedule was last updated. Providing rules to nodes in order to determine the freshness of the schedule they have received.
Another approach could be NETCONF event notification to inform nodes of updates. I guess nodes can also actively poll the central scheduling authority at regular intervals to ensure they have the latest schedule - although far from ideal in some environments.
boucadair
commented
9 months ago Great inputs, Daniel.
An exercise we need to do is to articulate aspects that make sense in the common schedule spec (which is reusable by others) and other interesting matters that may feed a generic schedule management module.
For example, these ones can made it easily to the common model:
Timestamps and versioning in the schedule data to track when the schedule was last updated.
together with a "status".
In order to protect or ensure consistency on the system processing the schedules, maybe it could be recommended a maximum time of anticipation. E.g. one year. More that that could originate problems, and could be exploited as a system attack as well (i.e. flooding the system with multiple future schedules)