Hi, Ive been meaning to put out a draft, but since i havent gathered the energy to do so, I figured at minimal i should post my notes.
I'd like to have the ForCES data model be put to consideration for I2RS and I hope to make some basic case for its validity with this post. Really, I was hoping there would be requirements put out first (but). There is no publicly available tutorial of ForCES(we are working on it); closest I can point you to at the moment is: https://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-2.pdf A few of the slides in that presentation talk about the model. But to get a detailed grasp of the model, please read RFC 5812. Highlights of the ForCES data model ------------------------------------------------------ -Hierarchical control/config/state data models -reusable atomic types, complex/compound types, grouping of compound types in the form of indexed/keyed tables and Logical Functional Blocks(LFB) -informational-modeled metadata and expectations -Built in capability definition/advertisement -publish/subscribe event model with expressive trigger and report definitions -data model flexibility/extensibility through augmentations, inheritance -backward and forward compatibility -formal constraints for validation of defined components -data model modularity through LFB modules -versioning rules -produced by _the smart people_ of the IETF (Paraphrasing Jürgen ;->) On meeting the needs for I2RS -------------------------------------------- If one was to start with the floated Yang models (I think there was route, IP address and port models), then we can express any of those using ForCES language. I believe it would be useful for I2RS WG to come up with some simple information model that can be then used to do some gap analysis of the different contending data models. Yes, Ive seen the debate on the list but it is getting silly when we have engineering solutions being pushed forward to ignore this fact. And since I couldnt find "requirements" for a data model anywhere, as a starting point, I am going to use Alia's excellent summary post at: https://www.ietf.org/mail-archive/web/i2rs/current/msg00580.html and try to address only the issues I think relate to the model. If i missed something let me know. I think the relevant points on the model expressed in Alia's post are: 1) client ownership. ============== ForCES has rudimentary ACLs (read/write permissions) which are defined as properties of a controlled/configured component. In my opinion, client ownership of a specific runtime state could be: a) made as an additional ForCES component property. A 32 bit id identifying some owner client would suffice. One could go further and make this look like unix permissions with the read/write ACL having world/group/owner ids as properties This will require an additional extension to add a new ForCES property but has the nice feature of being exposable as a unix filesystem and therefore re-use all the good (and bad) attributes of filesystems. b) Make it part of the model definition. In classical route entries, the client that inserted a route is typically specified and stored at the FIB (in my experience for debug purposes). If you take this approach you dont need to make any ForCES extensions. In both #a and #b, inheritted ACL/ownership will work because of the hierarchical nature of ForCES data model. I am also ignoring the credential vetting which i believe belongs in an orthogonal interface. 2) Notifications when written state changes ============================================ Trivial to achieve in ForCES. Part of the data model definition of whatever is decided as the data model. 3) Filtered threshold notifications. ==================================== Supported by ForCES. Refer to: https://tools.ietf.org/html/rfc5812#section-4.8.5 Event filtering supported by ForCES includes: a) hysteresis - used to suppress generation of notifications for oscillations around a condition value. example: generate an event if the link laser goes below 10 or goes above 15. b) count - used to suppress event generation around occurence count. Example, report the event to the client only after 5 consecutive occurances. c) time interval - used to suppress event generation around a time limit Example: Generate an event if some table row hasnt been used in the last 10 minutes. There could be multiple filters defined per event and any one triggers then a subscribed to event is generated. Example of compound filtering: Generate an event when the count reaches 5 or every 10 minutes when there is at least one event. 4) Different Operational models ============================= a) Persistence. In ForCES this is part of what we call the Protocol Object LFB; a config LFB which states the graceful properties of state. I would envision something equivalent would be needed for I2RS. b) Start-time modes. I was a little confused by this. Shouldnt such state be installed by some client when ready to be used (i.e use some external approach such as crontab) c) state expiration. One could use the ForCES event mechanism to express different views of this. Example, you could age state based on timer filtering or expire state based on complex filter which includes a timer and table hits Ok, what else did i miss? cheers, jamal _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
