[CC-ing OPSAWG list as this discussion should also be archived there]
Hi, Brian, Thanks a lot for getting back to me. Please see my reply inline… -----Original Message----- From: Sipos, Brian J. [mailto:brian.si...@jhuapl.edu] Sent: Saturday, March 2, 2024 12:36 AM To: maqiufang (A) <maqiufa...@huawei.com>; t...@ietf.org Cc: draft-ma-opsawg-schedule-y...@ietf.org Subject: RE: New Version Notification for draft-ma-opsawg-schedule-yang-04.txt Qiufang, I very much appreciate the expressiveness of the current draft schedule options, and I think that these schedules fit well with the proposals and discussions from TVR WG. [Qiufang] Thanks for the feedback, glad to know;-) One aspect of the current repetition-of-event logic is that (I think) it does not allow for time-aligned sequences to repeat. Currently if there was a config change event that happened at time T (on a repeating schedule) and a different change at time T+D (on the same repeating schedule) it seems like this would require two synchronized schedules. Is that correct? There is currently no way to have a single repeating schedule with 'internal' (to the repetition cycle) time offsets? [Qiufang] I think maybe you are referring to the model design in the appendix B, right? Because this draft simply normatively defines a set of groupings associated with scheduling without restricting how those groupings should be used. And in the way the model designed in the appendix B.1, yes, if there is a backup task that is time aligned with another one, it seems that it would still require two schedules given the schedule groupings are used to describe each backup task event. I think it is acceptable if one configuration backup task always happens consistently with another same task, clearly one of them is redundant. But I also understand in some cases the events might be different, e.g., the configuration being backed up at time T is different from another backup at time T+D. I think this is still achievable if we model it slightly differently, e.g., see the following fictional model: list events { key “name”; leaf name {…} //define your event here. } container schedule { uses schedule:icalendar-recurrence; } // the schedule info related to the list of events I believe this is something that won’t be excluded in the draft. Is this what you have in mind? A comment about the way that the schedule is attached to existing data nodes in Section B.2 example: this kind of schedule model requires that each data node to be modified on a schedule has a kind of duplication of definition (the "default-bandwidth" node and the "scheduled-bandwidth" node need to be aligned in definition and implicitly refer to the same time-varying parameter). If instead the schedule contained an "instance-identifier" leaf, to identify the value being changed, and an "anydata" leaf, to indicate the new value, this would avoid duplicate node definition and make the schedule more extensible (in a similar way to how yang-patch functions, but schedule-driven rather than manager-driven). [Qiufang] The example in Appendix B.2 is very similar to the one in draft-united-tvr-schedule-yang-00. We are documenting this example to show how the authors of I-D. united-tvr-schedule-yang could use the groupings in I-D. ma-opsawg-schedule-yang to meet their requirements. It is not asking TVR to follow this way, just an example that could be possible. I think it may also depend on how the discussion around I-D. united-tvr-schedule-yang would evolve, and we may consider removing/adjusting this example accordingly. In your way, are you referring to a schedule-centric model design like the following: list schedules { key “name”; leaf name {…} uses schedule:recurrence-with-date-times; anydata values; // the scheduled values when each recurrence time instance arrives } Note: Actually I think a node-instance-identifier/instance-identifier leaf is not needed as the set of nodes with its values are already specified inside anydata node. I can see some benefits to model this way, since we try to show some flexibility in the way scheduling contexts are defined, maybe this is worth documenting in the draft as another example as well. The authors will take this into consideration, thanks a lot. Thanks for your consideration, Brian S. Best Regards, Qiufang > -----Original Message----- > From: Tvr <tvr-boun...@ietf.org<mailto:tvr-boun...@ietf.org>> On Behalf Of > maqiufang (A) > Sent: Friday, March 1, 2024 3:45 AM > To: t...@ietf.org<mailto:t...@ietf.org> > Cc: > draft-ma-opsawg-schedule-y...@ietf.org<mailto:draft-ma-opsawg-schedule-y...@ietf.org> > Subject: [EXT] [Tvr] FW: New Version Notification for draft-ma-opsawg- > schedule-yang-04.txt > > APL external email warning: Verify sender > forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> > before > clicking links or attachments > > Hi, TVR WG, > > As a co-author of draft-ma-opsawg-schedule-yang, I would like to bring your > awareness of this work given the close association between TVR and > scheduling. > > This draft intends to define a common schedule yang module that could be > applicable for scheduling contexts based on date and time, currently we have > defined a set of reusable groupings as well as examples to show the use of > them > and how future modules can extend the schedule module to support specific > needs. So far the authors identified some existing work that may benefit > from > this common yang model: > 1. https://datatracker.ietf.org/doc/draft-ietf-opsawg-ucl-acl/ (ACL policy > activation based on scheduling) 2. https://datatracker.ietf.org/doc/draft- > contreras-opsawg-scheduling-oam-tests/ (scheduling OAM tests) 3. > https://datatracker.ietf.org/doc/draft-united-tvr-schedule-yang/ (scheduled > attributes for network resources and topologies) And we authors of different > drafts have had a side meeting during IETF 118 to discuss how the model > could > be updated in a modular approach, and thus meet requirements of different > documents, I believe the outcome has already been incorporated into the > current schedule model design and would always welcome any further > comments and suggestions during alignment. > > The authors of draft-ma-opsawg-schedule-yang would like to share this work > and keep TVR up to date, we will also see how we can coordinate with TVR, > please feel free to share any of your thoughts. Thanks a lot! > > Best Regards, > Qiufang (on behalf of authors of draft-ma-opsawg-schedule-yang) > > > -----Original Message----- > From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> > [mailto:internet-dra...@ietf.org] > Sent: Friday, March 1, 2024 4:10 PM > To: Daniel King <d.k...@lancaster.ac.uk<mailto:d.k...@lancaster.ac.uk>>; > Mohamed Boucadair > <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; Qin Wu > <bill...@huawei.com<mailto:bill...@huawei.com>>; Qin Wu > <bill...@huawei.com<mailto:bill...@huawei.com>>; maqiufang (A) > <maqiufa...@huawei.com<mailto:maqiufa...@huawei.com>> > Subject: New Version Notification for draft-ma-opsawg-schedule-yang-04.txt > > A new version of Internet-Draft draft-ma-opsawg-schedule-yang-04.txt has > been successfully submitted by Qiufang Ma and posted to the IETF repository. > > Name: draft-ma-opsawg-schedule-yang > Revision: 04 > Title: A Common YANG Data Model for Scheduling > Date: 2024-03-01 > Group: Individual Submission > Pages: 42 > URL: https://www.ietf.org/archive/id/draft-ma-opsawg-schedule-yang- > 04.txt > Status: https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang/ > HTMLized: https://datatracker.ietf.org/doc/html/draft-ma-opsawg-schedule- > yang > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-ma-opsawg-schedule- > yang-04 > > Abstract: > > This document defines a common schedule YANG module which is designed > to be applicable for scheduling information such as event, policy, > services, or resources based on date and time. For the sake of > better modularity, the module includes basic, intermediate, and > advanced versions of recurrence related groupings. > > > > The IETF Secretariat > > > -- > Tvr mailing list > t...@ietf.org<mailto:t...@ietf.org> > https://www.ietf.org/mailman/listinfo/tvr
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
