Subject: Re: [midcom] multiple agents accessing the same policy rule

From: Juergen Quittek <[email-masked]>
Date: Thu, 12 Jun 2003 18:49:11 +0200

Dear all,

Martin and I found a better solution to the problem.
Please find it explained below.

-- Juergen Quittek wrote on 20 May 2003 11:45 +0200:

> Dear all,
>
> After working again on the semantics for some days,
> I ran into a potential problem related to the point that
> multiple agents may access the same policy rule on a middlebox.
>
> An example scenario contains a 'regular' agent authorized
> to access just the policies rules created by itself and an
> 'administrator' agent authorized to access all policies
> created by any agent.
>
> Another exampe contains be a 'regular' agent and a 'fail-over'
> agent running stand-by until the regular one fails.
>
> In both scenarios (and several others) it is possible that at a
> time two or more agents have an open session with the middlebox
> and there is a set of policy rules that both may access.
>
> Let's now assume that an agent deletes a policy rule that is
> also accessible to another agent with an open session. The agent
> deleting the policy rule sends a request for deletion and gets
> a successful reply. What happens with the other agent?
>
> I think that according to requirement 2.1.5 (known and stable
> state) the middlebox must send an ARD (Asynchronous Rule Deletion)
> notification to the other agent in order to tell it that one of
> the policies it can access was terminated.
>
> IS THIS AGREED BY THE WORKING GROUP?
>
> Consequences would be that:
>
>   1. Everytime a policy rule is terminated, each agent with open
>      sessions that can access this policy need to receive an
>      individual notification about this event.
>
>   2. Not just termiation of policy rules, but also creation and
>      modification need to be reported to all these agents.
>      Besides our ARD notification we would have to add one or
>      more notifications to the semantics covering at least
>      policy rule creation and lifetime change.
>
> If we agree on this, here are suggestion for modifying the
> semantics:
>
>    - Replace the Asynchronous Policy Rule Deletion (ARD)
>      transaction (that so far just indicated policy rule
>      termination) by a more general Asynchronous Policy Rule
>      Lifetime Event (ALE) notification that notifies the
>      agent about
>         - policy rule lifetime changes initiatd by other agents,
>           indicating the new remaining lifetime,
>         - policy rule termination by other agents, indicating a
>           new remaining lifetime of zero,
>         - policy rule termination by the middlebox, indicating a
>           new remaining lifetime of zero,
>         - regular policy rule termination by lifetime expiration,
>           indicating the remaining lifetime of zero,

There is not need to change the set of transactions.  What is just
missing are further notification MESSAGES.  We started to more
clearly separate the concepts of message and transaction.

When a new policy rule is created or when a policy rule lifetime is
changed, then all we have to do is extending the transaction by
optional notification messages that are sent to agents who are
affected by the change (they can access the created/modified policy
rule) but that are not the requesting agent.

This applies to the PRR, PER, PLC and GLC transaction.
PRR = policy reserve rule
PER = policy enable rule
PLC = policy rule lifetime change
GLC = policy rule group lifetime change

For asynchronous events, such as Asynchronous Session Termination
(AST) and Asynchronous Policy Rule Deletion (ARD),
there is no requesting agent anyway. For session termination, there
is only one agent affected and there is no change required. For
policy rule termination.  We intend to change the semantics for the
transactions slightly in a way that the middlebox checks for the
list of agents that can access the affected policy rule and sends
a notification to each of them.

In order to realize this, we want to define three notification
message formats:
  - session termination notification (so far called AST notification)
    sent in case of an AST transaction only
  - policy rule event notification
    This message carries a notification identifier, a policy rule
    identifier and the remaining policy rule lifetime. It is
    optionally sent within the PRR, PER, PLC, and ARD transaction
  - policy rule group event notification
    This message is similar to the previous one. Instead of a
    policy rule identifier, it contains a group identifier.
    It is optionally sent by the GLC transaction.

Any further suggestions?

    Juergen

>    - Add a new Asynchronous Policy Rule Creation (APC) transaction
>      that indicates the new policy with all its properties to all
>      agents in open sessions that did not create the policy rule
>      but that can access it.

>
>     Juergen
> --
> Juergen Quittek        [email-masked]        Tel: +49 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom

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

---

From: Melinda Shore <[email-masked]>
Date: Sun, 15 Jun 2003 10:01:13 -0400

The next version of the semantics document is the one that
will go into WG last call.  Is there any objection to

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 16 Jun 2003 18:42:04 +0200

Tom,

-- Tom Taylor wrote on 16 June 2003 12:01 -0400:

> The requirement for this is what I meant by "consequential messaging"
> in my earlier review of the document.  The solution looks OK, except
> that protocol terminology crept in slightly in your explanation.
> We are interested in message content, not message format.

Yep, you are right. We should replace the term.
Would you consider message type a better term?

    Juergen

> Juergen Quittek wrote:

---

From: Tom Taylor <[email-masked]>
Date: Mon, 16 Jun 2003 12:01:48 -0400

The requirement for this is what I meant by "consequential messaging" in my earlier 
review of the document.  The solution looks OK, except that protocol terminology 
crept in slightly in your explanation.  We are interested in message content, not 
message format.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 17 Jun 2003 09:20:18 -0400

Yes, that seems appropriate.

> Would you consider message type a better term?
[snip]
>>>    It is optionally sent by the GLC transaction.
[snip]