Subject: Re: criticality of extended conditions and actions

From: "Robert Moore" <[email-masked]>
Date: Mon, 23 Apr 2001 08:17:07 -0400

Mircea,

There's another alternative, which, given your
numbering scheme, would most appropriately be
numbered 0:

0. the entire aggregation tree of Policy Groups
   and Policy Rules containing the rule in
   question fails to load on the PDP or to be
   communicated to the PEP

The motivation for this alternative would be
concern about unpredictable (and potentially
undesirable) results if *anything* about the
entire "policy" (which I'm interpreting as the
entire aggregation tree, complete with its
priorities and execution strategies) is
unrecognized / unsupported.

This may result in a whole lot of cases where
policies don't load at all, because some
component or other of them is unrecognized /
unsupported.  But if your overriding goal
(maybe "overriding constraint" is a better way
to say it) with policy-based management is
"no surprises," then this is exactly how you'd
want it to work.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
[email-masked]

"Mircea Pana" <[email-masked]>@raleigh.ibm.com on 04/20/2001
06:00:48 PM

Please respond to "Mircea Pana" <[email-masked]>

Sent by:  [email-masked]

To:   IETF Policy <[email-masked]>
cc:
Subject:  Re: criticality of extended conditions and actions

Marcus, in a previous message you suggested that in case of unsupported
components (conditions, actions) "the loading of the whole rule fails".
In the message below you suggest that "a unsupported action could be
regarded an action failure" which is different from the first one.
Please excuse me if I got it wrong!

In case of a set of actions aggregated in a rule, if an action is
unsupported on the PDP or PEP, then which one of the following cases is
the right one?

1. the entire rule fails to load on the PDP or to be communicated to the
PEP
2. the unsupported action is ignored and the others are executed in
conformance with the execution strategy.
3. the unsupported action is considered failed and depending on the
execution strategy, the other actions may be executed

Neither PCIM nor PCIMe define a clear behavior for a PDP and/or PEP
relative to unsupported extensions.

Regards,
Mircea.

Marcus Brunner wrote:
>
> Michael,
>
> I think in PCIMe we covered the case of failing Action by the
> ExecutionStrategy in CompoundActions (do until sucess, do until failure).
> So dealing with a unsupported action could be regarded an action failure.
>
> Marcus
>
> --On Friday, April 20, 2001 9:40 AM -0400 Michael See
> <[email-masked]> wrote:
>
> >
> >
> > Marcus Brunner wrote:
> >
> >> Lee, Mircea,
> >>
> >> I am not happy with the proposed solution, nevertheless we need to
deal
> >> with the problem of "unsupported" or "optional" elements in a policy
> >> rule.
> >>
> >> What does exclude a condition mean (Lees first handling)? replace it
by
> >> FALSE, by TRUE? or skip it?
> >>
> >> The second question is what entity detects a policy with unsupported
> >> conditions and actions? And at what point in the policy lifecycle it
> >> is/needs to be detected?
> >> 1) policy definition language to LDAP translator detects it (needs to
> >> know what policy engine is used)
> >> 2) at load time of policies from a database into the execution engine
> >> 3) at run-time, execution engine fails evaluating a condition or
> >> performing an action, because it is not known.
> >>
> >
> > There is also the case where the execution of a rule fails because the
> > action defined in the rule cannot be implemented.
> >
>
> --------------------------------------
> Dr. Marcus Brunner
> C&C Research Laboratories
> NEC Europe Ltd.
>
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.tik.ee.ethz.ch/~brunner
>
> Adenauerplatz 6
> D-69115 Heidelberg
> Germany
>
> Phone: +49 (0)6221/ 9051129
> Fax:   +49 (0)6221/ 9051155

---

From: "Mircea Pana" <[email-masked]>
Date: Mon, 23 Apr 2001 14:32:32 -0400

In order to illustrate the advantages of the options 2. and 3. compared
with 0. and 1., please consider the following case:

An administration runs a policy based QoS product (PDPs and PEPs) "QP".
This product supports actions of type "qpAction" (subclass of
policyAction). Most probably the administrators have created complex
aggregations that represent their business and network objectives. For
example:
qpGroup1 (policyGroup)
  qpGroup2 (policyGroup)
    qp...
      qpPolicy1 (policyRule)
        qp...
          qpPolicy2 (policyRule)
            qpCondition1 (qpCondition)
            qpAction1 (policyCompoundAction)
              qpAction11 (qpAction)
              qpAction12 (qpAction)
            qpAction2 (qpAction)

Subsequently, the administration decides to deploy a new policy based
QoS product (PDPs and PEPs) "QPplus" by selectively replacing some of
the old "QP" systems (PDPs and PEPs).
Let's say, for example, that the "QPplus" supports all the features of
"QP" and, in addition, a new type of action: "qpLoging" (subclass of
policyAction). Let's say that this action type is non critical to the
delivery of business value but rather is useful for network engineering,
utilization data collection for statistics etc.

In case of the options 0. and 1. since "QP" does not understand the new
action type, the  aggregation trees are cloned and the clones upgraded
with instances of "qpLoging". Also, the clones will receive
different/additional policyRoles/policyKeywords in order to be
distinguished from the originals.
The cloned and upgraded aggregation tree for "QPPlus" might be:
qpPlusGroup1 (policyGroup)
  qpPlusGroup2 (policyGroup)
    qpPlus...
      qpPlusPolicy1 (policyRule)
        qpPlus...
          qpPlusPolicy2 (policyRule)
            qpCondition1 (qpCondition) -- can be shared with "QP"
            qpPlusAction1 (policyCompoundAction)
              qpPlusAction11: strategy=all (policyCompoundAction)
                qpAction11 (qpAction) -- can be shared with "QP"
                qpPlusLog11 (qpLogging)
              qpPlusAction12: strategy=all (policyCompoundAction)
                qpAction12 (qpAction) -- can be shared with "QP"
                qpPlusLog12 (qpLogging)
            qpPlusAction2: strategy=all (policyCompoundAction)
              qpAction2 (qpAction) -- can be shared with "QP"
              qpPlusLog2 (qpLogging)

Note that most of the instances are cloned and renamed "qpPlus*" while
very few instances are shared. Since in this situation, two separate
sets of aggregation trees have to be maintained, scaleability and
manageability issues will occur sooner or later.

In case of options 2. and 3. since it is acceptable to have unknown
action types aggregated together with the supported ones, the existing
aggregation tree is upgraded and shared among the "QP" and "QPPlus"
systems.

Therefore, the arguments in favor of the latter options (2. and/or 3.)
derive from the ability to share more data structures across functional
domains: especially the scaleability and manageability in an environment
with several policy based functional domains.

IMO options 0. and 1. lead to data partitioning by PDP (vendor)type and
(vendor)version which may be unacceptable in large scale a deployment of
policy based products.

Regards,
Mircea.

---

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 24 Apr 2001 09:52:14 -0400

Mircea,

Let's break this down into it's component parts:  rule compilation unit of
failure and optional rule components.

It's difficult for me to imagine that there are sets of rules that can have
a rule removed and still somehow reflect the intent of the administrator.
So I think that the unit of failure should be the whole aggregated set of
rules.

Your example does, however, raise a good point about extending sets of
actions.  (I still don't see this extending to conditions, however.) It
seems reasonable to me that we could define a boolean in PolicyAction that
indicates that a recognition failure for a given action instance does not
constitute a compilation failure.  (Actually, this should really be a class
variable, but we don't have class variables in our model.  CIM has
qualifiers that can serve as class variables but they're a clumsy
substitute.)

How's this?

  NAME         MayIgnoreAction
  DESCRIPTION  This boolean may be set to indicate that an
               action instance may be ignored by rule engine.
               Actions that may be ignored extend the actions of
               a rule but, if not supported, may be ignored and
               do not cause the set of rules to be rejected by
               the PDP or PEP.
  SYNTAX       boolean
  DEFAULT      false

Implementations MAY support the property.  If not supported and an action is
not recognized by the implementation, the aggregation of rules (we need a
name for this thing) is rejected as in other rule parsing errors.

This would permit the extensibility you describe in your example without
compromising the integrity of the policy.

Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Home email: [email-masked]

---

From: "Mircea Pana" <[email-masked]>
Date: Tue, 24 Apr 2001 10:33:05 -0400

I'm re-posting this message because I believe that it did not make it to
the list. Sorry for the inconvenience.

Thanks,
Mircea.

> > Application Integration Middleware Division
[snip]

---

From: "Mircea Pana" <[email-masked]>
Date: Tue, 24 Apr 2001 10:33:05 -0400

Thanks,
Mircea.

[snip]

---

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 24 Apr 2001 09:52:14 -0400

Mircea,

How's this?

  NAME         MayIgnoreAction

Lee M. Rafalow

---

From: "Mircea Pana" <[email-masked]>
Date: Wed, 25 Apr 2001 15:11:37 -0400

Lee,

Your proposal sounds good. I've added a few comments in-line and marked
them <mpana>.

Thanks,
Mircea.

> a rule removed and still somehow reflect the intent of the administrator.

<mpana>
The policyGroup can be used to group together other policyGroups and/or
policyRules under the same administrative role. If the components of the
group serve different functional domains, the policyGroup itself can be
thought as a policy bundle.
Let's consider an example: An organization has edge devices serving
connections with its (1)customers and (2)providers. These devices
implement different functions: (1) firewall, (2) QoS, (3) encryption.
One way of bundling the policies may be:
   Group1: role=customer
     Rule1: if TrafficToInternetExceptSomeSites then Firewall-Allow
     Rule2: if Mon-Fri AND 08:00-17:00 then QoS-HighPriority
     Rule3: if TrafficToOrFromBank then VPN-Encrypt
   Group2: role=provider
     etc.
Therefore, Group1 is applicable to all the firewalls, QoS interfaces,
VPN gateways that serve the role "customer". There may be different PDPs
per functionality and/or PDPs combining some or all functions. The fact
that the QoS PDP/PEP does not support Rule1 and Rule3 should not stop it
from enforcing Rule2.
However, if the policyGroup is not suitable for such use, then may be we
should define a separate policyBundle that is allowed to span across
functional domains. Is this in scope for the Policy WG?
</mpana>

> So I think that the unit of failure should be the whole aggregated set of

<mpana>
I understand the reason behind this but I'm not comfortable with its
potential impact on the network. There should be an easy way to evaluate
the impact * before * it happens.
</mpana>

> actions.  (I still don't see this extending to conditions, however.) It

<mpana>
How about a condition like this:
(SourceOSIAddress = X25Value)
 OR (SourceIPAddress = IPv4Value)
 OR (SourceIPAddress = IPv6Value)
loaded/evaluated by a device with no X25 support. Should the rule (or
the entire aggreg.) fail? How about a device that only implements IPv4
(no IPv6)?
</mpana>

> qualifiers that can serve as class variables but they're a clumsy

<mpana>
I'm happy with the instance variable, it gives more control to the
administrator.
</mpana>

> Implementations MAY support the property.  If not supported and an action is

<mpana>
Sounds good but...
What if we make it: "implementations SHOULD". The reason is that
implementations that do not support this flag can hardly share data with
other similar ones.
</mpana>

---

From: John Schnizlein <[email-masked]>
Date: Wed, 25 Apr 2001 17:30:59 -0400

Mircea,

Yes, the strategy of distributing policies and hoping they
work (with some conflict detection late in the process) has
been broken for a long time. I appreciate your raising this
problem again.

John

At 03:11 PM 4/25/2001, Mircea Pana wrote:
>Lee Rafalow wrote:
>
>> So I think that the unit of failure should be the whole 
>> aggregated set of rules.
>
><mpana>
>I understand the reason behind this but I'm not comfortable 
>with its potential impact on the network. There should be an 
>easy way to evaluate the impact * before * it happens.
></mpana>