Subject: Re: Core Model Last Call Issue: Execution Semantics

From: [email-masked]
Date: Thu, 13 Apr 2000 10:03:59 -0400

David,

I agree with you that  your objection has been raised by you a number of times
before, on both the mailing list and in policy framework working group meetings
at the IETF.  On each occasion that you raised this objection, discussion of the
issue ensued.  After each of those discussions, John and I declared the
consensus of the working group to be that your objection was invalid for the
purposes of this working group.

 I should also point out:

1. You missed your opportunity to make this objection in the last "last call"
period, which ended on February 3, 2000.  We have already made all the changes
based on feedback from that period, hence we have now moved to the "final" last
call period in which we now find ourselves.

2. The model has been this way (sans algorithms) from the very beginning.

3. You have continued to object, in principle, to this working group's model on
this same point  (that is, whenever you chose to pay attention to the working
group), but I do not recall ever seeing from you a concrete alternative proposal
in the form of a changed model, complete with examples of the algorithms you
want to see standardized, that would benefit from this different, more
precedural approach.     As a number of people have pointed out in our past
discussions of this point, trying to standardize specific algorithms will fail,
because implementors will object to such constraints.  Different implementors
are working with different hardware,  which cannot accomodate a "one-size fits
all" algorithm.

Based on the above, John and I, with the support of our AD's, do indeed declare
that we have (rough) consensus, albeit not unanimous, for declining to
incorporate the corrections which you perceive to be needed, but which do not
reflect the consensus of the working group, and, in any case, which you have not
enumerated.

John and Ed

Ed Ellesson
Tivoli Systems
Research Triangle Park, NC
[email-masked]
919-254-4115

[email-masked] on 04/12/2000 12:54:48 PM

Please respond to [email-masked]

To:   Ed Ellesson/Tivoli Systems@Tivoli Systems, [email-masked]
cc:   [email-masked], [email-masked], [email-masked]
Subject:  Core Model Last Call Issue: Execution Semantics

Allow me to renew my objection to the fact that the core information
model execution semantics are inherently ambiguous, and hence will lead
to implementations that make different policy decisions when given
identical policies and inputs.  This objection has been raised before,
and has been "featurized" rather than addressed in the core info model
draft via the following text in Section 2.2:

2. An important decision to make is the semantic style of the
      representation of the information.

      The declarative approach that we are describing falls short of
      being a "true" declarative model. Such a model would also specify
      the algorithms used to combine the information and policy rules to
      achieve particular behavior. We avoid specifying algorithms for the
      same reason that we avoid specifying sets of steps to be followed
      in a policy rule. However, the design of the information model more
      closely follows that of a declarative language, and may be easier
      to understand if such a conceptual model is used. This leads to our
      third point, acknowledging a lack of "completeness" and instead
      relying on presenting information that the policy processing entity
      will work with.

"presenting information that the policy processing entity will work with"
implies that different entities will work with it in different ways.
This will not lead to interoperation among those entities in a fashion
that implements a single policy in a consistent fashion.  IMHO, this
needs to be corrected here, rather than patched over in the policies
derived from this model, such as the QoS policy.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]  Cellular: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Thu, 13 Apr 2000 17:25:11 -0400

> At some point, we need to go with the consensus,
> which is quite happy with the declarative approach.

I'm also quite happy with the declarative approach.  I just want
to see clearly defined execution semantics so that the results
can be determined from a policy and its inputs without having
to resort to the words "implementation defined".

> I also think that you need to explicitly state why you think
> that the "execution semantics are inherently ambiguous, and
> hence will lead to implementations that make different
> policy decisions when given identical policies and inputs".
> I would like an example,

From my presentation to the policy WG in Minneapolis in March 1999:

	Example:
		Rule 1: Engineers get Bronze service.
		Rule 2: John gets Gold service.
		Fact: John is an Engineer.
		Oops: No rule priority specified
	When and where does John get Gold service?
	Might change at 3am for no good reason

A year later, the core model and schema still
cannot answer the "when and where" question.

> even if I prescribed all of the steps of an algorithm,
> a processing entity could still decide that it needed to
> pre- or post-process those results, or even insert
> additional steps. 

I don't care what algorithm is used.  What I care about is
that for a given set of inputs (policy + conditions) there is
one correct output as far as the model is concerned.
Here's some language from RFC 2401 (IPsec architecture)
that deals with a similar issue in the IPsec Security Association Database:

   The model described below
   is nominal; compliant implementations need not match details of this
   model as presented, but the external behavior of such implementations
   must be mappable to the externally observable characteristics of this
   model.

> That is exactly why we tried to
> avoid specifying all of the nitty gritty detail - it is
> impossible to cover all uses of a generic policy model by
> over-definition.

I agree with the general principle, but would suggest that
not being able to specify the outputs is serious under-definition.

> What do you mean by "patched" in the QoS policy model?

The following sections of the Policy QoS Schema draft:

	8.5. Class qosNamedPolicyContainer
21
	8.5.1. The Attribute qpPriority
21
	8.5.2. The Attribute qpPolicyRuleMatchMethod                     21

This is mostly dealing with the inability of the core model to specify
whether one
or all of the matching rules should be performed.  Unfortunately, the
priority description
matches the core model/schema and hence allows implementation-defined
ordering.
I had thought that this was more strongly worded in the past.

> or at least suggest some clarifying wording.

Again, from RFC 2401, here's a worked example of how the problem was solved
in applying the IPsec Security Policy Database to outbound traffic.
NOTE -- IPsec uses different terminology:
	An IPsec Security Policy is analogous to a rule in the core schema
and model;
		it contains conditions that identify traffic and actions to
indicate how that
		traffic is to be processed.
	The IPsec Security Policy Database a collection of such rules.
Here's the RFC 2401 text from section 4.4.1:

   As described below in Section 4.4.3, selectors may include "wildcard"
   entries and hence the selectors for two entries may overlap.  (This
   is analogous to the overlap that arises with ACLs or filter entries
   in routers or packet filtering firewalls.)  Thus, to ensure
   consistent, predictable processing, SPD entries MUST be ordered and
   the SPD MUST always be searched in the same order, so that the first
   matching entry is consistently selected.  (This requirement is
   necessary as the effect of processing traffic against SPD entries
   must be deterministic, but there is no way to canonicalize SPD
   entries given the use of wildcards for some selectors.)  More detail
   on matching of packets against SPD entries is provided in Section 5.

Note the use of MUST rather than SHOULD.  Someone other than me clearly
thought
that this was important.

This particular solution doesn't map into the hierarchical structure of the
core
model/schema, although I believe that at least one of the efforts to build a
policy-based router did follow such a linear ordering approach.  A solution
I have
proposed in the past is to use DN (fully qualified) lexical ordering to
break ties
when priority does not, but given the additional execution  structure (Named
Policy
Container) that is now present in the QoS schema, some sort of escape
wording is
needed to allow derived schemas to add additional execution control
structures.
IMHO, the fact that control structures expressed solely in terms of rules
have
to be added in the QoS model/schema indicates that the core model/schema has
missed something important.

Summarizing the issues in Ed's mail:
	- Should this have been raised in the earlier last call? Probably.
		Would the results have been any different? Probably not.
	- Does this require specifying "algorithms"?
		No, just consistent repeatable behavior.
	- Has there ever been a concrete alternative proposal?
		Lexical ordering based on DNs was in my presentation at the
		3/99 Minneapolis IETF.

It is up to the WG and the chairs as the determiners of "rough consensus"
to deal with these issues.  I leave this to others on the list to decide
whether this is important or not.

--David

---

From: Andrew Smith <[email-masked]>
Date: Thu, 13 Apr 2000 15:30:37 -0700

All of the technology-specific incarnations of QoS policy models that are
being worked on at IETF have had to face up to the issue of "rule
precedence" issue sooner or later: Diffserv Model/MIB/PIBs, LDAP policy rule
schemas, the new device QoS model from Walter/Dave/Andrea/John, not to
mention all the device CLIs that I've seen. And it came up again in the
SNMPCONF meeting in Adelaide where a whole new crowd of people were seen and
heard grappling with comprehending it.

So, it seems to me, admittedly not ever actually having read the core model
from cover to cover (I've dipped into it many times over the years in
attempts to work out how useful stuff is supposed to be derived from it),
that this issue is *so* fundamental that it ought to be covered somewhere in
a technology-independent fashion. It may be that I don't understand the
purpose of the core model draft but it sure seems like an obvious place to
give this issue some treatment - and that should include MUSTs as
appropriate. 

Of course, the fact that I haven't ever felt an overwhelming need to
dedicate a tree to printing and reading the draft properly might be
indicative of the importance to me of fixing it. So, take that as another
dissenting voice alongside David's (actually, standing behind him would be
more accurate: when volunteers are called for, I won't have the time to
provide the fixes).

Andrew

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, April 13, 2000 2:25 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Core Model Last Call Issue: Execution Semantics

...

> whether this is important or not.

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  [email-masked]
****************************************************************

---

From: [email-masked]
Date: Fri, 14 Apr 2000 09:08:55 -0400

Andrew,

Thanks for your input.  I can't tell from your note, though, whether
you're aware of a key feature of David's position, and of the
discussion related to it that has gone on for more than a year now:
David's concern relates only to predictable behavior among PEPs in
the *absence* of rule priorities.  The PCIM has always given the
policy administrator the ability to tell PEPs how to resolve rule
conflicts, by assigning different values to the Priority property.
(As I look at the document now, I don't see an explicit statement
that a PEP "MUST" respect rule priorities if they're specified.
If the WG feels this is needed, we can certainly add a sentence that
says it.)

David is interested in deterministic behavior in the case where rule
priorities are *not* specified -- hence the "Oops: No rule priority
specified" in the example he cites.  So it's not true in general that
the PCIM makes it impossible to specify the outputs when a PEP
processes a set of Policy Rules.  This is impossible only if the
policy administrator fails to avail him/herself of the mechanism
included in the PCIM to guarantee predictable results.

Now we could have made Priority a mandatory property for a Policy
Rule.  (This, by the way, is how I read the paragraph from RFC 2401
that David cites:  SPD entries must be ordered, and then the
entities that "consume" these entries must respect this ordering.
To be analogous to David's current position, I think that RFC 2401
would have had to require that even if the SPD entries were *not*
ordered, all entities that make use of them would be required to
behave in the same way.)  But given that we didn't make it mandatory,
we've given the policy administrator a way to say "I don't care how
these rules are prioritized relative to each other -- however you do
it is fine with me."  If the policy administrator is uncomfortable
with unpredictable results for a set of Policy Rules, he/she(*) can
always specify Priority values for the rules.

Regards,
Bob

(*) It doesn't even have to be the policy administrator.  If a
Policy Management Tool vendor is uneasy about unpredictable
behavior, then the tool itself can introduce Priority values if
the policy administrator doesn't.  The PEP will then respect these
Priority values, without knowing or caring where they came from.

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

Andrew Smith <[email-masked]>@raleigh.ibm.com on 04/13/2000
06:30:37 PM

Please respond to Andrew Smith <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked]
cc:   "[email-masked]'" <[email-masked]>
Subject:  RE: Core Model Last Call Issue: Execution Semantics

All of the technology-specific incarnations of QoS policy models that are
being worked on at IETF have had to face up to the issue of "rule
precedence" issue sooner or later: Diffserv Model/MIB/PIBs, LDAP policy
rule
schemas, the new device QoS model from Walter/Dave/Andrea/John, not to
mention all the device CLIs that I've seen. And it came up again in the
SNMPCONF meeting in Adelaide where a whole new crowd of people were seen
and
heard grappling with comprehending it.

that this issue is *so* fundamental that it ought to be covered somewhere
in

Andrew

...

---

From: Andrew Smith <[email-masked]>
Date: Fri, 14 Apr 2000 11:46:12 -0700

OK, but why on earth is the priority attribute optional? It's absence should
always be an "oops". I don't see why leaving it out, at the PDP-PEP
boundary, is ever helpful - it is trivial to default it in an
implementation.

Andrew

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 14, 2000 6:09 AM
> To: Andrew Smith
> Cc: [email-masked]; [email-masked]'

---

From: [email-masked]
Date: Fri, 14 Apr 2000 16:01:30 -0400

Andrew,

Even if you make the priority mandatory, and the default is some value, let's
say "zero",  if the administrator doesn't set it, that still doesn't solve
David's problem, because he wants default behavior to be deterministic.  That
is, if all the priorities are set to the same value (the default), he wants a
deterministic order of priority of execution.

Making the priority mandatory with a default is pretty much equivalent to making
it optional, in my opinion, but if that will satisfy the dissenters, I won't
object.

Ed Ellesson
Tivoli Systems

Andrew Smith <[email-masked]> on 04/14/2000 02:46:12 PM

To:   "[email-masked]'" <[email-masked]>
cc:   [email-masked], "[email-masked]'" <[email-masked]>
      (bcc: Ed Ellesson/Tivoli Systems)
Subject:  RE: Core Model Last Call Issue: Execution Semantics

Andrew

---

From: Andrew Smith <[email-masked]>
Date: Fri, 14 Apr 2000 13:07:21 -0700

The difference is that you can then detect the conflict in the PDP before
you bother the poor PEP with the problem i.e. the "oops" error message is
internal to the PDP and we can treate it as a "don't do that" condition at
the PEP-PDP boundary: this is a major win.

Andrew

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 14, 2000 1:02 PM
> To: Andrew Smith
> Cc: [email-masked]'; [email-masked]; 
> [email-masked]'

---

From: [email-masked]
Date: Tue, 18 Apr 2000 02:44:11 -0400

> Yes, I'm not quite clear on why David is insisting on unique priority for
> each rule (I do understand his point that, if you insist on this, you need
> them to be automatically generated/re-generated by any UI tool). If you
find
> 2 rules with the same priority that conflict you just flag the error
> (somewhere close to the UI hopefully) - that's fine I think.

The short answer is "If only conflict detection were that simple ..."
We are likely to see policies that are complex beasts consisting
of parts that interact in subtle ways, complicated by administrative
issues and practices.

For example, the UI may only be editing a part of the policy that
isn't supposed to conflict with any other part, but does due to
an implementation restriction in a new device added to the network
unbeknownst to this policy administrator (at least the new
device addition part happens all the time ...).  Another example
is that a policy may only exhibit a conflict under network
operating conditions that have never been seen before -- 
leading to policy failure when they do occur, which may
be a crucial moment at which policy is most needed.

Beyond that, Boolean Satisfiability is NP-Complete, and seems
sufficiently similar to detecting potential policy conflicts in advance
to make the latter non-trivial and potentially computationally expensive.
This doesn't sound like a responsibility that ought to be imposed
on every PDP and policy tool.  Besides, to err is human ...
including errors in the conflict detection software ...

For the above reasons, among others, I am highly skeptical of any
claim that all policy conflicts can be detected before the policy
is put into use.  The Rule Number proposal ensures that if
an unanticipated conflict does occur, it is resolved in a consistent
fashion across all the PDPs involved.  An important
consequence is that the number of possible policy failure
modes is reduced, which should make the policy
administrator's life simpler.

--David

---

From: Andrew Smith <[email-masked]>
Date: Tue, 18 Apr 2000 11:06:36 -0700

Agreed: as we've discussed before on this list, you need conflict detection
at *all* levels/places in the system and you should try to check as much as
possible as high up as possible in the architecture: of course there are
conflicts that cannot be detected until you get down to the device level but
there a lot that can be and that doesn't make the presence of a "precedence"
any less useful. For your example, an accurate reporting of device
capabilities is an important part of being able to do conflict detection in
the PDP, rather than waiting until "run-time". In my previous message, I was
only talking about that point in the architecture between the UI and the
PDP/PEP boundary.

Andrew

> Sent: Monday, April 17, 2000 11:44 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: Andrew Smith <[email-masked]>
Date: Wed, 26 Apr 2000 11:02:26 -0700

That still sounds like an inconsistency in the thought-processes of the WG
to me. But I guess nobody else is interested in fixing it so let's let
sleeping policy-dogs lie.

Andrew 

> From: John Strassner [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2000 10:58 PM
> To: Andrew Smith; [email-masked]
> Subject: Re: Core Model Last Call Issue: Execution Semantics
> 
> 
> Hi Andrew,
> 
> it actually is NOT inconsistent at all. The WG had decided
> that for the generic policy case, they did NOT want these
> additional semantics. In fact, some people wanted the
> ability to say "evaluate this (third) set of policy rules
> after this (first) set before this other (second) set."
> 
> So the PCIM strove to be as general as possible. This was
> NOT suitable for the application-specific constraints of QoS
> Policies, so we added this information in the QoS PIM.
> 
> regards,
> John
> ----- Original Message -----
> From: "Andrew Smith" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, April 18, 2000 11:15 AM
> > Right, so that section of the QoS PIM has nothing (or very
> little) to do
> > with QoS: either this is a general problem (move Yoram's
> text to the core
> > model) or it is not a problem (remove the text completely
> and save it for a
> > rainy day when we realise we need it again). Otherwise we
> have 2 documents
> > that are inconsistent and that just reflect the differing
> opinions of their
> > authors, rather than an IETF rough consensus (JohnSt -
> your name is on both
> > docs!).
> >
> > Please fix this inconsistency (this message directed at
> the WG, not at you
> > Yoram).
> >
> > Andrew
> >
> > > From: Yoram Snir [mailto:[email-masked]]
> > > Sent: Tuesday, April 18, 2000 1:29 AM
> > > To: 'Andrew Smith'
> > > Maybe, the QoS PIM clearly defines a consistent model of
> > > decision making.
> > > Quating from the QoS PIM: ( I am sorry for the length of
> the
> > > section but it
> > > covers the whole subject and include examples that clear
> up
> > > the relevant
> > > issues)
> > >
> > > -------------- From the QoS PIM ---------------
> > > Section 3.2.4:
> > > "Each policy container is assigned a "match strategy",
> which is a name
> > > of a method to interpret the order of its rules (see
> section 1.2.1.5).
> > > For example, a FirstMatch strategy means that the rules
> will be
> > > "matched" according to ascending order of their Priority
> attribute.
> > > Decision strategy is explained in section 5."
> > >
> >
> >
>