RE: 'config' vs. 'policy'

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 protected]] 
> Sent: Wednesday, June 12, 2002 5:26 PM
> To: Michael Carr
> Cc: [email protected]
> Subject: Re: [Policy] 'config' vs. 'policy'
> 
> 
> 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
> 
> 
>