Subject: Re: [Policy] 'config' vs. 'policy'

From: John Schnizlein <[email-masked]>
Date: Wed, 12 Jun 2002 17:26:05 -0400

Answers embedded ..

At 04:52 PM 6/12/2002, Michael Carr wrote:
>Apologize in advance if this question isn't appropriate for this list, but not sure who/where else to ask.

This list is probably as good as you get, since this WG established the
design team that wrote RFC 3198, which attempted to deal with your question.
Without claiming that the issue is clear, you might find some guidance there.

>I'm wrestling with trying to explain to developers the difference between a 'policy' (e.g., 'if packet_type = X, put it on queue Y') and other switch/router 'configuration' (e.g., ethernet interface 2 autosense = on).  What I have said thus far is that a policy is something that can be expressed in an "If condition then action" clause.  Also, I've made the bold statement that static policies are part of configuration, but not all configuration data is policy.

I don't recall any consensus that the distinction between policy and
configuration is the distinction between dynamic and static configuration.

> But then I hear high level "policies" in the storage networking space like "Minimum backup count for file X is 2".  To me this is configuration, not policy.

We included both statements of the goal state such as "voice traffic will
get less than 100 ms variation in delay across the network" and rules as
possible definitions of policy, but the framework settled on rules as the
way to represent policies in an information model. Without proof, we
concluded that statements of goals could be re-stated as rules.

>I guess I'm looking for a clearer definition.  Why does it matter?  When trying to design and build an extensible policy engine framework (side issue: does anyone already do this?), it helps to know the domain of the problem set first, and optimize for that domain.  Throwing things that aren't really policies into such an engine might lead to a suboptimal/inefficient design with respect to the ones that really are policies.

We would be gratified if our adventure in practical semantics actually
mattered for a system you developed.

John

_______________________________________________
Policy mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/policy

---

From: "Michael Carr" <[email-masked]>
Date: Thu, 13 Jun 2002 14:32:40 -0400

John,

Most of the discussions I've followed, and web literature I've read
regarding PBNM really falls into what could also be called
template-based network management.  I.e., more of a convenience-driven
technology or framework, to make it easier for a manager to setup a
large network of disparate devices.  When I think of networking policy,
I think more along the lines of a technology for
programmable/configurable wire-speed decision making.

Shoehorning interface_MTU into a policy statement just because it works
and fits a configuration framework has performance impacting
side-effects.  If the underlying policy engine stores policies in an
embedded database, that database is burdened with elements it could
other wise jettison and achieve faster lookups, insertions, conflict
detection and resolution, etc.

Thoughts?

Thanks

--Michael

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]] 
> Sent: Wednesday, June 12, 2002 5:26 PM
> To: Michael Carr
> Cc: [email-masked]
> Subject: Re: [Policy] 'config' vs. 'policy'
> 
> 
> Answers embedded ..
> 
> >Apologize in advance if this question isn't appropriate for 
> this list, 
> >but not sure who/where else to ask.
> 
> This list is probably as good as you get, since this WG 
> established the design team that wrote RFC 3198, which 
> attempted to deal with your question. Without claiming that 
> the issue is clear, you might find some guidance there.
> 
> >I'm wrestling with trying to explain to developers the difference 
> >between a 'policy' (e.g., 'if packet_type = X, put it on 
> queue Y') and 
> >other switch/router 'configuration' (e.g., ethernet interface 2 
> >autosense = on).  What I have said thus far is that a policy is 
> >something that can be expressed in an "If condition then action" 
> >clause.  Also, I've made the bold statement that static policies are 
> >part of configuration, but not all configuration data is policy.
> 
> I don't recall any consensus that the distinction between 
> policy and configuration is the distinction between dynamic 
> and static configuration.
> 
> > But then I hear high level "policies" in the storage 
> networking space 
> > like "Minimum backup count for file X is 2".  To me this is 
> > configuration, not policy.
> 
> We included both statements of the goal state such as "voice 
> traffic will get less than 100 ms variation in delay across 
> the network" and rules as possible definitions of policy, but 
> the framework settled on rules as the way to represent 
> policies in an information model. Without proof, we concluded 
> that statements of goals could be re-stated as rules.
> 
> >I guess I'm looking for a clearer definition.  Why does it matter?  
> >When trying to design and build an extensible policy engine 
> framework 
> >(side issue: does anyone already do this?), it helps to know 
> the domain 
> >of the problem set first, and optimize for that domain.  Throwing 
> >things that aren't really policies into such an engine might 
> lead to a 
> >suboptimal/inefficient design with respect to the ones that 
> really are 
> >policies.
> 
> We would be gratified if our adventure in practical semantics 
> actually mattered for a system you developed.
> 
> John
> 
> 
>

---

From: John Schnizlein <[email-masked]>
Date: Thu, 13 Jun 2002 15:15:08 -0400

I think we agree that more-flexible template-based configuration
for appropriate sets of network devices (not just one at a time)
is a good thing. I suspect that this particular good thing is
included in the goals of many of the people pursuing Policy-Based
Network Management.

You might have drawn the distinction between the rules that set
configuration parameters based on policy (on the time-scale of when 
policy changes) and rule-based execution of the policy engine in
the process of forwarding an individual packet more clearly than
we have. There was a distinction (not captured in the evolution)
between packet-level rules and those that could be translated into
relatively static configuration (such as time of day) by Silvano
Gai in early discussions.

I am not sure how much of an inference engine (to apply the rules)
people would be comfortable standardizing for operation per packet.

These are just my thoughts, as requested. Other perspectives probably
differ.

John