Subject: Re: gpsPolicyGroup class in qos info model

From: Mahadevan Iyer <[email-masked]>
Date: Mon, 11 Dec 2000 21:34:29 -0800 (PST)

--- John Strassner <[email-masked]> wrote:
> I'm still confused. It sounds like you want to copy
> the

Not copy, let the administrator create higher level
condition traps. They might be very coarse and loose.
They will provide a coarse level of aggregation.
I agree that if we try to directly copy we will run
into the problems as you have pointed out.

> conditions inside different rules that are contained
> in
> different groups to a higher level of containment in
> order
> to trim the tree, right? This is what I meant when I
> said:

Exactly right: "Trim the tree" for the decision
process.

> 
>   "As you say, a policyRule is an atomic object.
> You're
>    asking to "peek inside" a group of policyRules in
> a
>    policyGroup and copy their aggregate conditions
> out
>    into a higher-level condition that you can then
>    trap on."

Not copy as stated earlier.

> 
> Now, while this may work for PCIM, for QPIM I don't
> think it
> can work, because at the very minimum, this means
> that you
> also have to copy the decision strategies that are
> applied
> to each group of conditions. QPIM provides the
> ability to
> CHANGE decision strategies at each containment
> level. This
> means that you now have to re-create the decision
> strategies
> defined at each container and apply them to the
> conditions
> at each level of containment. You haven't addressed
> how this
> will be done.

I agree that it will not be feasable to do this
automatically and will not be feasable to do it at
every level. 
It is upto the administrator to decide whether he
wants to include an aggregated condition at a certain
point or not. It is upto the administrator to manually
build the condition.

> 
> In addition, in QPIM, we have nested rules as well
> as
> sub-rules. You can't flatten out the condition in
> these
> cases, or you lose the hierarchy of the structure of
> the
> rules. You also haven't addressed how this will be
> done.
> 
> That's why I continue to have questions.

I hope I have communicated the problem clearly.
At this point I can't think of an alternative solution
to the problem.

As far as the QPIM if I were to take the example
quoted on page 24 (version 02). 

I am assuming that PDP's within a region would try to
trim the policy tree by picking up policies meant for
their respective regions.(I have posted some related
questions "Policy Target, Policy Domains etc" on the
mailing list)

If most of the policies have to  do with inter-region
traffic or inter-group traffic to a hub there isn't
much trimming I can do on the basis of "policies
required by a region". 

In such cases source and destination of the traffic
can be used to zero in into a policy group which then
defines exactly what policies need to be applied to
the  traffic.

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

---

From: "John Strassner" <[email-masked]>
Date: Tue, 12 Dec 2000 13:43:21 -0800

I think I understand in principle what you want to do, but
just to be clear, is this a fair description:

  you want to be able to trim a tree of policy
  information from consideration to be evaluated
  efficiently; therefore, you want to add a
  condition clause, defined by the admin, on a
  high-level container, to do this

Assuming that this is correct, you still haven't addressed
how you accommodate decision strategy and nested rules. In
other words, are you proposing that you construct these new
trimming rules INDEPENDENTLY of the actual structure of the
rules below that containment point (e.g., taking into
account their individual decision strategies, priorities,
etc.)? How can you be sure that you are capturing the
semantics and maintaining the correct execution order by
your newly defined trimming rules?

regards,
John
----- Original Message -----
From: "Mahadevan Iyer" <[email-masked]>
To: "John Strassner" <[email-masked]>; "Marcus Brunner"
<[email-masked]>; "Ron Cohen" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, December 11, 2000 9:34 PM
Subject: Re: gpsPolicyGroup class in qos info model