Subject: RE: 1:1 relationship of PConsumer to PTarget

From: Francis Reichmeyer -NJ <[email-masked]>
Date: Fri, 29 Oct 1999 09:55:34 -0400

My understanding is that a Target/PEP can be associated with
more than one Consumer/PDP but multiple Comsumers/PDPs cannot
configure the same policy information on the Target/PEP.
The example that used to get thrown around is one where there
are separate Consumers/PDPs for QoS policy, Security policy, etc.
As long as two Consumers/PDPs don't try to set or change the same
piece of policy data on the device, the model works.

-Fran

> -----Original Message-----
> From: Jon Sjoberg [mailto:[email-masked]]
> Sent: Friday, October 29, 1999 8:51 AM
> To: [email-masked]; [email-masked]
> Subject: RE: 1:1 relationship of PConsumer to PTarget
> 
> 
> It seems to me that one Policy Target should be associated 
> with one LOGICAL
> Policy Consumer.  Then it can be explained that a logical PC 
> is one or more
> PC's that appear consitent between each other.
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of 
> [email-masked]
> > Sent: Thursday, October 28, 1999 5:26 PM
> > To: [email-masked]
> > Subject: 1:1 relationship of PConsumer to PTarget
> >
> >
> > Hi,
> >
> > I have a question about the following limitation:
> >
> >       Each  Policy  Target has one Policy Consumer.  To have more
> >       than one Policy Consumer responsible  for  configuring  the
> >       Policy  Target  would  invite contention between the Policy
> >       Consumers.  There may be one or more  Policy  Consumers  to
> >       enable  continued operation in a failure mode, but only one |
> >       at a time is to be the 'active' Policy Consumer.  A  Policy |
> >       Consumer,  though, can work with multiple Policy Targets at |
> >       the same time.
> >       	draft-ietf-policy-req-01-diffs.txt; p10
> >
> > The reason I ask is that on occasion the processing involved in
> > being a Policy Consumer may be such that load sharing would be
> > desired.  This could be the case when a Policy Target would 
> have a great
> > number of capabilities for which it is requesting a PC act
> > as a outsourcing PDP.
> > If this limitation remains then we could end up with a single
> > system having a number of PTs in order to handle a large number of
> > capabilities. This too could become cumbersome.
> >
> > Or can a requirement be imposed on PCs such that they are 
> required to
> > coordinate between themselves and the PT(s)?
> >
> > a.
> > -----------------------------------
> > avri doria
> > +1 617 678 9402
> >
> >
>

---

From: John Schnizlein <[email-masked]>
Date: Fri, 29 Oct 1999 11:07:30 -0400

The point is that there must be only one authoritative source for
any policy, otherwise an uncontrolled opportunity for conflict exists.
If security policy and QoS policy imply different interface/device
configuration, how would this be detected, resolved and/or prevented?

A related question regards the implication of a "role" at at device
if different policy sources have different views of it. Recall that
"roles" are independently configured on device interfaces by the
configuration management system; we have no mechanism specified for
coordinating the interpretation of a "role" (combination) either
between the configuration management and policy management systems,
much less between multiple policy sources.

- John

---

From: Hugh Mahon <[email-masked]>
Date: Fri, 29 Oct 1999 10:52:59 -0600 (MDT)

Hi John,

> configuration, how would this be detected, resolved and/or prevented?

This is an area that has not been discussed much.  In some cases 
security and QoS can be separated, thus allowing separate policies and 
possibly even different administrators configuring different 
capabilities on the same device (I don't recommend it, but it is a 
real possibility).

For functionality that maps to a target that involves multiple 
capabilities I would like to see a single target which is an 
abstraction (i.e., one policy action) of those multiple functions, but 
which allows an administrator to deal with them (via policy rules) as 
a single logical entity.  We need to start putting together some usage 
cases which demonstrate handling multiple capabilities.

> much less between multiple policy sources.

Having a single Policy Consumer (PC) to handle a given feature of a 
device would reduce the possibility for confusion.  Then the PC would 
detect that one policy with Action type X was trying to configure 
Target1 one way, but a different policy with Action type Y (which is a 
superset of Action type X) was doing something else with the same 
target.  If the PCs for different actions types are different (even 
for overlapping capabilities), then the PCs should detect the conflict 
and report it.  The PCs may not be able to correct or resolve the 
conflict, but they should be able to detect it.

> - John

Thanks,

Hugh