Subject: [i2rs] Proposing ForCES model for I2RS

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 4 Apr 2013 06:54:59 -0400

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