Subject: [forces] Update to Wiki (ForCES for I2RS)

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 7 May 2014 12:20:17 -0400

I have started updating the I2RS wiki on viability of using ForCES
for I2RS. I posted those requirements on the list over the weekend
and checking against them.
To the other proposals (netconf, restconf, yang), it would be nice
if we have a common set of requirements to check against.
I will be updating the wiki as more discussions for requirements come up
as well as put more commentary.

Enjoy!
http://wiki.tools.ietf.org/wg/i2rs/trac/wiki/ForcesAnalysis

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 12 May 2014 10:03:40 -0400

I have made another update.
question to chairs - if there are none of Restconf/netconf/yang
updates to the wiki
does that mean you are going to disqualify them from the process ?
(/me runs).

cheers,
jamal

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 13 May 2014 21:37:37 -0400

Jamal,

> does that mean you are going to disqualify them from the process ?

Probably not. :-)

Thank you for taking the time to fill in the wiki entry. 

I'd like to encourage the WG to spend a few moments looking over the
information Jamal entered.  (And, if our Netconf/Yang champions would care
to crib his text and use it as the basis for their own, that would be
similarly helpful.)

The breakdown of Data Model Requirements is particularly a good one.

-- Jeff

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 May 2014 07:43:10 +0200

> The breakdown of Data Model Requirements is particularly a good one.

I do not understand the meaning of the following:

 3) The data model MUST be able to express semantics of instances. 

I am not sure why this is a MUST:

 2) The model MUST be object oriented.
    This allows it to extensible in the form of templating and sub-classing.

In particular, if 'object oriented' means classes and sub-classes, what
does this have to do with templating? Perhaps this is backwards and the
requirement really is:

 2a) The model MUST be extensible.

 2b) The model MUST allow templating.

But even then I am not even sure what 'templating' means.

/js

PS: I may regret having sent this message. I believe requirement
    discussions like this are not helpful in making a decision since
    this just leads to an endless debate about the requirements.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 May 2014 08:42:19 -0400

Templating is described in the archtiecture document.
However, as I said when i presented the material, this is a topic on 
which the authors disagree.
I personally do not think it should be a protocol behavior, and 
therefore do not see it as something the model needs to represent.

The basic idea of templating is to allow the I2RS client to say to the 
I2RS agent "I want to set this instance to these values, but for all the 
things I don't specify, use this template over here to determine what 
values to set."  This clearly has power.  Equally clearly, it can be 
done at the client rather than at the agent.

Yours,
Joel

On 5/14/14, 1:43 AM, Juergen Schoenwaelder wrote:
...
> But even then I am not even sure what 'templating' means.
...

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 14 May 2014 09:22:09 -0400

Juergen,

>     this just leads to an endless debate about the requirements.

The goal is not to endlessly debate requirements, it's to converge on the
understood set of minimum requirements.  While we've had significant good
discussion about each proposed mechanism, it has largely been in a "compare
and contrast existing mechanisms" format.

At the end of the day (or perhaps week, I believe), we will have made our
choice and will hopefully be crystal clear on what work is missing so we can
move forward in an expeditious fashion.

Thanks for contributing.

-- Jeff

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 14 May 2014 09:58:42 -0400

On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern <[email-masked]> wrote:
> However, as I said when i presented the material, this is a topic on which
> the authors disagree.
> I personally do not think it should be a protocol behavior, and therefore do
> not see it as something the model needs to represent.
>
> The basic idea of templating is to allow the I2RS client to say to the I2RS
> agent "I want to set this instance to these values, but for all the things I
> don't specify, use this template over here to determine what values to set."
> This clearly has power.  Equally clearly, it can be done at the client
> rather than at the agent.
>

Seems like i abused the term "template". I.e it seems to me that would
fall under
" Default values MUST be possible to specify" - which is described in the wiki.
Shouldnt this be a model problem?
I will fix the wiki entry and remove it from that sub-section.

On the OO class/instances:
The motivation is to be able to describe "set blah to RIB instance foo". The
concept for abstracting a "factory" which is essentially a "class" vs
an "instance" of
that class seems to belong to the model.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 May 2014 10:28:58 -0400

(Alia, correct me if I mis-represent this concept.)

No, temnplating is not just "Default values must be possible to specify."

An example is that you might have a scheduling structure.  it has a set 
of defaults which create a specific scheduling discipling.
The Client can create a scheduling instance, and can over-ride any and 
all of those defaults.
So far, that is just modeling with defaults.

The idea with templates is that the Client could also say "For all the 
values I don't specify, use the WFQ template" or the EF template, or ... 
  If the client does that, the agent would treat the values from that 
template which are specified in the template and are not specified in 
the request from the controller as if they had been specified by the 
controller, rather than using the base defaults.

Coupled with this, some mechanism would provide these templates.  The 
power here is that there might be different templates for the "EF 
Scheduling template" on different boxes to reflect how each box should 
be configured to achieve the policy goal.

Conversely, clearly, all of this data can be on the client and the 
client can do the inclusion.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Wed, 14 May 2014 07:49:33 -0700

On Wed, May 14, 2014 at 7:28 AM, Joel M. Halpern <[email-masked]>wrote:

> An example is that you might have a scheduling structure.  it has a set of
> defaults which create a specific scheduling discipling.
> The Client can create a scheduling instance, and can over-ride any and all
> of those defaults.
> template which are specified in the template and are not specified in the
> request from the controller as if they had been specified by the
> Scheduling template" on different boxes to reflect how each box should be
> configured to achieve the policy goal.
>
> Conversely, clearly, all of this data can be on the client and the client
> can do the inclusion.
>

A generic template feature would be interesting, and may not be
a lot of work. If a template includes lots of data, then it
could be much faster (CPU, on-the-wire) than inline edits.

Templates are usually just for convenience and consistency,
but consistency (even across clients) is important.

In the generic sense, a YANG template would be a sub-tree
without keys. Whatever nodes were missing from the client request
would get merged in by the server. (Some NETCONF servers are designed
to do this merge very quickly).  The protocol operation would say
"edit that data with this patch and template X".

> Joel

Andy

>>> therefore do
>>> I2RS

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 May 2014 11:02:57 -0400

Hi Joel,

Just quickly, the key point is to avoid having the client need to
understand all the different ways of making the desired behavior
happen or specifying all the details when there's only a small set
that need to change.

A use-case is something like assigning traffic into a particular queue
or configuring that queue where there aren't good and common
abstractions.

Alia

On Wed, May 14, 2014 at 10:28 AM, Joel M. Halpern <[email-masked]> wrote:
> values I don't specify, use the WFQ template" or the EF template, or ...  If
> the client does that, the agent would treat the values from that template
> which are specified in the template and are not specified in the request
> from the controller as if they had been specified by the controller, rather
> than using the base defaults.
>
> Coupled with this, some mechanism would provide these templates.  The power
> here is that there might be different templates for the "EF Scheduling
> template" on different boxes to reflect how each box should be configured to
> achieve the policy goal.
>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 14 May 2014 11:18:00 -0400

Its not just default values; its more like a set of preconfigured values for a set of objects. 

	--Tom

On May 14, 2014:10:28 AM, at 10:28 AM, Joel M. Halpern <[email-masked]> wrote:

> An example is that you might have a scheduling structure.  it has a set of defaults which create a specific scheduling discipling.
> The Client can create a scheduling instance, and can over-ride any and all of those defaults.
> The idea with templates is that the Client could also say "For all the values I don't specify, use the WFQ template" or the EF template, or ...  If the client does that, the agent would treat the values from that template which are specified in the template and are not specified in the request from the controller as if they had been specified by the controller, rather than using the base defaults.
> 
> Coupled with this, some mechanism would provide these templates.  The power here is that there might be different templates for the "EF Scheduling template" on different boxes to reflect how each box should be configured to achieve the policy goal.
> 
> Conversely, clearly, all of this data can be on the client and the client can do the inclusion.
> 
> Yours,
> Joel
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 14 May 2014 11:29:20 -0400

Ok, I think i get then what Joel was saying. Is this then an
implementation issue?

cheers,
jamal

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 14 May 2014 11:34:51 -0400

Maybe. I think that was the point though. Operationally you specify these things, so as long as you can specify them we are good. 

	--Tom

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 May 2014 12:28:44 -0400

I wish it were just an implementation issue.
If we are going to support this in the protocol then:
1) We need a mechanism explicitly in the protocol to say "use this 
template".
2) We need to include templates in the set of things we model.

Yours,
Joel

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 14 May 2014 12:33:11 -0400

> 2) We need to include templates in the set of things we model.

+1

One of the cases in the pending architecture doc refresh (don't recall if
it's in the existing version) is effectively "copy constructor" behavior for
templates.  

If we had the equivalent of configured state that was scoped to not commit
(yes, obviously ugly but potentially another one of those side data stores
we have been talking about), then you have identified objects that are
"committed" somewhere (not impacting running state) that can be referenced
for such a copy constructor.  Effectively, a form of template.

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 14 May 2014 15:29:51 -0400

So, having gone down this rabiit hole, let me explain my primary 
objection to this feature.

The idea of the feature is that the I2RS client does not ahve to set up 
these templates, but simply uses them.  And that by having different 
templates on different devices it can get the "right result" in 
different places.

Which means that the client does not actually know what its request is 
going to do.  the template may or may not actually do what it wants, 
because the client did not establish the template.

For CLI operation, this kind of template operation seems very useful.
For automated operation, I am concerned by the loss of information at 
the client.

Yours,
Joel

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 May 2014 19:24:01 +0000

Joel's "templates" sound like apply-groups in Junos:

http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/routing-matr
ix-tx-matrix-plus-using-configuration-groups-for-components-solutions.html

K.

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 14 May 2014 16:47:20 -0400

Yep.

Tom 

> On May 14, 2014, at 3:24 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 14 May 2014 18:54:15 -0400

On Wed, May 14, 2014 at 3:29 PM, Joel M. Halpern <[email-masked]> wrote:

> For automated operation, I am concerned by the loss of information at the
> client.

I am still struggling on why  this is not "implementation specific".
ex: the client should be able to pick a template specified (through some
auxillary method), datafill whatever params needed and pass via the
protocol to the agent. Is there is a good reason it has to be the agent that
resolves what the template is?

cheers,
jamal