Subject: RE: Result of the compoundPolicyAction

From: "Ron Cohen" <[email-masked]>
Date: Wed, 16 May 2001 07:39:30 +0200

>
> My first question is what means Action 1 fails
> (a) both A1_1 and A1_2 fails
> (b) A1_1 or A1_2 fails

(b) - since the executuion strategy for A1 is do-all

> Second thing, Ron you assume that we can check whether an action
> is possible to
> perform, before performing the action. E.g., the case of RSVP,
> where you setup a
> guaranteed path, you find out whether there is enough resource
> available by
> performing the setup action. However, I have to admit, that the
> action is not so
> difficult to rollback.

So either one, either check before or rollback if this is possible

Ron

>
> Marcus
>
> Zitiere Ron Cohen <[email-masked]>:
>
> > Mircea,
> >
> > This is exactly the purpose of execution strategy. I understand that
> > you
> > think that this tool is needed in the PCIMe. The authors where not fully
> > in
> > agreement whether this is a required feature and whether policy
> > entities
> > (PEPs and PDPs) would be able to implement this. The issue was that
> > some
> > interpreted this to mean do action_1_1, and if you fail to do so, undo
> > the
> > operation (which is not always possible), while others (including me)
> > interpreted this as first check that you can do action_1_1 and
> > action_1_2,
> > if you can not do both don't do either one and move on to action 2.
> >
> > Ron
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of Mircea Pana
> > > Sent: Friday, May 11, 2001 5:48 PM
> > > To: IETF Policy
> > > Subject: Re: Result of the compoundPolicyAction
> > >
> > >
> > > Do the PCIMe authors have any opinion wrt. this subject?
> > >
> > > Here is an example to support the case 2. below. The following NAT
> > rule
> > >
> > > "in the packets from 10.10.10.10,
> > >  change *both* the source addr.
> > >  and the source port or,
> > >  if any of the above fails
> > >  then drop the packet"
> > >
> > > could be implemented as follows:
> > >
> > > Rule: If SourceIP=10.10.10.10 then (ordered, Do_until_success):
> > >   Action_1(compound, unordered, Do_all):
> > >     Action_1_1(simple): Set SourceIP to 1.2.3.4
> > >     Action_1_2(simple): Set SourcePort to 2001
> > >   Action_2: Drop packet
> > >
> > > Action_1 (compound, Do_all) should be considered successful only if
> > both
> > > Action_1_1 and Action_1_2 are successful. Then Action_2 is not
> > executed.
> > > If either Action_1_1 or Action_1_2 fails, then Action_1 should be
> > > considered failed and Action_2 should be executed.
> > >
> > > Thank You,
> > > Mircea.
> > >
> > >
> > > > > The result of the execution of a compoundPolicyAction (success or
> > > > > failure) is important for the execution strategy of the
> > aggregating
> > > > > policyRules or compoundPolicyAction. To avoid ambiguity, it
> > > may be good
> > > > > to add a clarification to the next release of PCIMe.
> > > > >
> > > > > A suggestion might be:
> > > > >
> > > > > 1. For compoundPolicyAction.executionStrategy=Do_Until_Success:
> > > > > The compoundPolicyAction is successful if an aggregated
> > > policyAction is
> > > > > successful. If all the aggregated policyActions fail, then the
> > > > > aggregating compoundPolicyAction is considered failed.
> > > > >
> > > > > 2. For compoundPolicyAction.executionStrategy=Do_All:
> > > > > The compoundPolicyAction is successful if all the aggregated
> > > > > policyActions are successful. If one or more aggregated
> > policyActions
> > > > > fail, then the aggregating compoundPolicyAction is considered
> > failed.
> > > > >
> > > > > (2bis. An alternative to 2 might be:
> > > > > The compoundPolicyAction is successful if one or more aggregated
> > > > > policyActions are successful. If all the aggregated
> > > policyActions fail,
> > > > > then the aggregating compoundPolicyAction is considered failed.
> > > > > If both 2. and 2bis are applicable in various situations then
> > > it may be
> > > > > useful to add a "Do_Any" execution strategy?)
> > > > >
> > > > > 3. For compoundPolicyAction.executionStrategy=Do_Until_Failure:
> > > > > The compoundPolicyAction is successful if one or more aggregated
> > > > > policyActions are successful. If the first attempt to execute an
> > > > > aggregated policyAction fails, then the aggregating
> > > compoundPolicyAction
> > > > > is considered failed.
> > > > >
> > > > > Regards,
> > > > > Mircea.
> > > > >
> > > > > P.S. BTW in PCIMe-01, the example at the end of the paragraph
> > "4.7.2
> > > > > Compound Policy Actions" uses the retired "Mandatory Do All"
> > decision
> > > > > strategy. For consistency with the rest of the document, this
> > > should be
> > > > > corrected.
> >
> >
>

---

From: "Mircea Pana" <[email-masked]>
Date: Wed, 16 May 2001 13:48:22 -0400

> (b) - since the executuion strategy for A1 is do-all
I agree with Ron on this. Actually, the intent of my original message
was to point out that PCIMe should answer the following question: Under
which circumstances a CompoundPolicyAction is considered a success (or a
failure)? IMO the answer depends on the CompoundPolicyAction's
ExecutionStrategy and on the individual results of its
CompoundedPolicyActions.

> So either one, either check before or rollback if this is possible
In my example, a "feasibility check" is optional (an implementation
optimization with no additional semantics) while a rollback is useless:
the packet is dropped any way by A2.

Regards,
Mircea.