Subject: RE: Policy issues: definition of Roles

From: "John C. Strassner" <[email-masked]>
Date: Sun, 06 Feb 2000 17:49:56 -0800

A role is just one of possibly many selectors that is used to download a 
subset of appropriate policies from a much larger set of availale policies.

A role can be specified as part of a policy condition or action, both of 
which are components of a policy rule as defined in the Policy Core 
Information Model.

HTH,
John

At 05:23 PM 1/31/00 -0800, Andrew Smith wrote:
>e.g. "HTTP traffic gets AF treatment on all Ethernet and FDDI interfaces" is
>a policy rule that references two roles: "Ethernet interfaces" and "FDDI
>interfaces". You wouldn't bother sending that rule to token-ring devices.
>
>(I guess I'm really an assembler programmer so I don't understand these
>"class" and "subclass" things you talk about).
>
>Andrew
>
>P.S. Maybe we should drop the "policy framework" list from this thread since
>this appears to be purely a "device" thing. But I did think we were
>attempting the (maybe thankless) task of unifying the terminology between
>all the WGs.
>
>-----Original Message-----
>From: Ken Roberts [mailto:[email-masked]]
>Sent: Monday, January 31, 2000 4:42 PM
>To: Andrew Smith; 'Bob Natale'
>Cc: [email-masked]; [email-masked]'
>Subject: RE: Policy issues: definition of Roles
>
>
>Gents & others,
>I'm a little confused by Andrew's statement of a policy that has multiple
>roles. I understood a policy had rules. Rules may be crafted to include the
>notion of roles but are they separate rules or sub classes of one rule?
>When the statement "A policy that references roles W and X" is made does
>this imply there is a matrix relationship that can be established from one
>parent policy (/rule)? How is this managed? Why is this required? If
>policies have hierarchical structure can this not be done with containment
>or another relationship?
>I think I had better re-read the thread as maybe I've missed something.
>--------------------------------------------------------------------------
>Regards,
>Ken Roberts
>INM Product Architecture
>Nortel Networks
>?ESN   :        655-7844                        ?Direct  : 408-565-7844
>?  Fax    :        408-565-8226
>? email :      [email-masked]
>
>This message may contain information proprietary to Nortel Networks
>Corporation so any
>unauthorised disclosure, copying or distribution of its contents is strictly
>prohibited.
>  -----Original Message-----
>From:   Andrew Smith [mailto:[email-masked]]
>Sent:   Monday, January 31, 2000 3:36 PM
>To:     'Bob Natale'
>Cc:     [email-masked]; [email-masked]'
>Subject:        RE: Policy issues: definition of Roles
>And, in particular, you only need to tell the device about those roles that
>are relevant to it - that is where the big savings are, I think. e.g.
>1. Device A has roles W, X and Y.
>2. Device B has roles W, X and Z.
>3. A policy that references roles W and X should be downloaded to both
>devices.
>4. A policy that references roles W and Y should be downloaded only to
>device A, not device B.
>The role combination concept in the PIB was introduced specifically in order
>
>to do this: you have to be able to list only those roles that are relevant
>to the policy, not necessarily ALL roles on the device, in a role
>combination.
>(Apologies if I'm repeating stuff here).
>Andrew
>
>
> > -----Original Message-----
> > From: Bob Natale [mailto:[email-masked]]
> > Sent: Monday, January 31, 2000 3:27 PM
> > To: Andrew Smith
> > Cc: [email-masked]
> > Subject: RE: Policy issues: definition of Roles
>...
> > That works fine for me.  All I care about on this thread is that a
> > "role combination" DOES NOT HAVE to include ALL of the roles supported
> > by a network entity/component (although there MAY well be a role
> > combination which does incorporate all roles supported by a network
> > entity/component).

---

From: Shai Herzog <[email-masked]>
Date: Sun, 06 Feb 2000 23:48:10 -0500

I think that one of the problems is that we're confusing the
various levels of "roles". Let me try to make the following
observations:

1. Roles and Role Combinations have only meaning (in the
    definition sense) in the PEP.

2. PDPs and DEN Policy Schemas may or may not take advantage of PEP
    roles.

    For example:

    PEP Roles: Edge+Ethernet, Edge+T1
    PDP Policy: If User=Joe, Mark (Traffic Desc) DSCP=AF11.

    Here the PDP may actually track down the ingress router and
    mark on ALL of its interfaces, regardless of Roles. It will
    produce the following instructions:

    Role = Edge+Ethernet: Mark (Traffic Desc) DSCP AF11
    Role = Edge+T1      : Mark (Traffic Desc) DSCP AF11

    My point is that we should stop thinking that the policy is bound
    to roles 1:1.

3. PEPs are not expected to be able to merge policies for Roles in
    Role combination.

    Given the previous example, the PDP is not allowed to send the
    following to the PEP:

    Role=Edge    : Conf1
    Role=Ethernet: Conf2

    Since the PEP that has an interface with both roles in a role
    combination (Edge+Ethernet) is now required to merge Conf1+Conf2.
    This merge is a big NO NO, since the whole point about external
    policy processing is that the PEP doesn't understand policy
    implications and complications and needs to receive very specific
    instructions.

4. PDPs may be smart enough to merge roles (and therefore deal with
    individual roles within a role combination). This is actually
    an implication of observation (2) but I though it needs to be
    clarified.

    For example, in the PDP, lets assume Ethernets get special
    treatment (higher precedence rule).

    Role=Edge    : If Service=Gold then Mark DSCP=xxx
    Role=Ethernet: If Service=Gold then Mark DSCP=yyy

    This will produce the following configuration (using COPS, or equiv):

    Role=Edge+Ethernet: Mark (Traffic Desc) DSCP=yyy
    Role=Edge+T1      : Mark (Traffic Desc) DSCP=xxx

So, going back to the definition I gave a while back, the reason for
the "ALL" comes from observation 3.

PDPs can process policy whatever the hell they wish (within reason)
but they have to respond to the PEP with specific policy for each
COMPLETE role combination, and cannot respond to partial role
combination or a specific role which is only a part of a role
combination.

Shai

>>I think I had better re-read the thread as maybe I've missed something.

__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006

---

From: "Yoram Snir" <[email-masked]>
Date: Mon, 7 Feb 2000 14:13:36 +0200

Following this thread, I think that another problem is that there is a
confusion between a group of policies and the definition of role which is
defined in the context of the PEP,  Shai's first observation.
Policies, via policy groups, are associated to specific roles and role
combination. For example, Policy Group P1 may be associated with Role R1,
policy group P2 may be associated with Role 2.
If a device reports R1 he will be the subject of the rules contained in P1,
if he reports R1+R2 (combination), he may be the subject of the combined
policy set constructed by P1 & P2 policy rules, according to their built-in
priorities.
Mapping specific policy rules to specific roles, directly, is also possible,
and we may look at that as a policy group containing a single rule, but it
would create a problem when we look at the ability to conduct a consistent
decision process, i.e., synchronize the priorities of the policies for a
specific role combination.
Other than that I agree with all of Shai's observations.

Yoram Snir
Cisco Systems
Tel.   972-9-9700085
Mobile 972-54-970085

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Shai Herzog
> Sent: Monday, February 07, 2000 6:48 AM
> To: John C. Strassner; Andrew Smith; 'Ken Roberts'
> Cc: [email-masked]; [email-masked]'; [email-masked]

---

From: Shai Herzog <[email-masked]>
Date: Mon, 07 Feb 2000 09:20:31 -0500

>policy set constructed by P1 & P2 policy rules, according to their built-in

But you must agree that the PEP won't be the one to merge them, but
that it is the job of the PDP, right?

>specific role combination.

Exactly. Imagine how complicated that is to the PDP, and therefore
quite impossible for the PEP. What I think the early policy systems
would do is define policy for a COMPLETE role combination in the
PDP as well such that the PDP won't have to do merging either (humans
would be doing the merging). Only more advanced, later policy systems
may start putting logic to merge policies from individual roles into
a role combination policy.

>Other than that I agree with all of Shai's observations.

Great.

---

From: "Yoram Snir" <[email-masked]>
Date: Mon, 7 Feb 2000 16:58:00 +0200

-----Original Message-----
  From: Shai Herzog [mailto:[email-masked]]
  Sent: Monday, February 07, 2000 4:21 PM
  To: [email-masked]; 'John C. Strassner'; 'Andrew Smith'; 'Ken Roberts'
  Cc: [email-masked]; [email-masked]; [email-masked]
  Subject: RE: Policy issues: definition of Roles

    Following this thread, I think that another problem is that there is a
    confusion between a group of policies and the definition of role which
is
    defined in the context of the PEP,  Shai's first observation.
    Policies, via policy groups, are associated to specific roles and role
    combination. For example, Policy Group P1 may be associated with Role
R1,
    policy group P2 may be associated with Role 2.
    If a device reports R1 he will be the subject of the rules contained in
P1,
    if he reports R1+R2 (combination), he may be the subject of the combined
    policy set constructed by P1 & P2 policy rules, according to their
built-in
    priorities.

  But you must agree that the PEP won't be the one to merge them, but
  that it is the job of the PDP, right?
  [Yoram Snir] Yes, I agree with all of your observations, as I wrote below,
with the addition of my comment.

    Mapping specific policy rules to specific roles, directly, is also
possible,
    and we may look at that as a policy group containing a single rule, but
it
    would create a problem when we look at the ability to conduct a
consistent
    decision process, i.e., synchronize the priorities of the policies for a
    specific role combination.

  Exactly. Imagine how complicated that is to the PDP, and therefore
  quite impossible for the PEP. What I think the early policy systems
  would do is define policy for a COMPLETE role combination in the
  PDP as well such that the PDP won't have to do merging either (humans
  would be doing the merging). Only more advanced, later policy systems
  may start putting logic to merge policies from individual roles into
  a role combination policy.
  [Yoram Snir] The QoS policy draft extending the core policy draft deals
with this problem, by defining the priorities between groups of policy rules
(we call them named policy containers, classes that extend PolicyGroup) and
defining the decision strategy to be used by PDPs. Explicitly defining these
2 attributes, creates a consistent and interoperable policy decision
process, i.e., different PDPs would reach the same decision for the same
role / role combination and policy DB.

  Great.

    Yoram Snir
    Cisco Systems
    Tel.   972-9-9700085
    Mobile 972-54-970085

---

From: "John C. Strassner" <[email-masked]>
Date: Tue, 08 Feb 2000 08:22:33 -0800

Hi Shai, comments inline.

regards,
John

>various levels of "roles". Let me try to make the following

<js>
Levels of roles? If a role is indeed an attribute used as a selector, this 
translates to levels of attributes. My head is hurting. ;-) More to the 
point, I don't know what you mean by "levels" of roles...

I humbly submit that you're making this too complicated. Instead, thinking 
of roles as a means to select from among a larger subset is appealing 
because it always means the same thing each time it is used.
</js>

>    definition sense) in the PEP.

<js>
I disagree. Granted that for the cases we've considered so far, it has been 
tied specifically to device interfaces. But a "role" is an age-old concept, 
and can be used equally in other contexts as well - roles as a selector to 
the type of job that a person is performing, for example. Which can be tied 
back to networking (Shai's CTO role gets him on the Engineering subnet, 
whereas Shai's marketing role gets him onto the Marketing subnet).

I suspect that as IPSP gets kicked off, they will want to use a more 
general definition of roles than just to describe the capabilities of a 
device interface.
</js>

>    My point is that we should stop thinking that the policy is bound

<js>
I certainly never said that. A policy can contain multiple roles, and a 
role can be used by multiple policies. In fact, if you think of a role as a 
selector, you couldn't draw that conclusion anyway. So at least we agree 
here. ;-)
</js>

>    implications and complications and needs to receive very specific

<jcs> Agreed </js>

>combination or a specific role which is only a part of a role

<js>
Seems to me that you want to differentiate between roles as used to 
influence device configuration on the PEP level vs. roles as used to build 
policy statements at the PDP level. Is this what you meant by "levels" of 
roles?

If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith 
suggested earlier) vs. roles as a selector (to make me happy ;-) )
</js>

---

From: Shai Herzog <[email-masked]>
Date: Tue, 08 Feb 2000 12:11:24 -0500

>point, I don't know what you mean by "levels" of roles...

Sorry, didn't mean to hurt anyone ;-)
I meant: Roles at PEP, Roles at PDP, Roles in the Schema, Roles in our
head, etc....

>because it always means the same thing each time it is used.

I think the two of us have been discussing this for perhaps years ;-)
I believe that the input to the PDP (schema, GUI, whatever) isn't
necessarily mapped 1:1 with PEP configuration (In fact, it better
not be). This means that the PDP may have as input an E-2-E definition
w/o roles ( this user gets gold service (low delay, drop) ) The PDP
gets this non-role info and converts it into COPS commands to
configure the PEP based on roles:

Role=Edge, DS GOLD Service -> Mark DSCP AF11

So, the schema didn't have roles, but roles were used in configuring the
edge router.

So, the role isn't a selector in the schema (although simple schema may
use it) it is also not a selector at the PDP, but only a selector
for the PEP to advertise the kind of roles it has, and receive policy
for each one of its roles.
...

>suggested earlier) vs. roles as a selector (to make me happy ;-) )

YES YES YES, you hit it bulls eye! I was talking about PEP roles only
and was trying (clumsily) to express myself, thanks!

So, lets call it "PEP ROLES"

As for the other one, I believe PDP is merely an interpreter (in comes
abstract policy, out goes device policy) so it doesn't really have
roles. So, we should find another name for the second type that you
described, perhaps "Profile" (as in "user profile, application
profile,...)? or "Usage Roles".

Shai

---

From: "John C. Strassner" <[email-masked]>
Date: Wed, 09 Feb 2000 08:18:14 -0800

Comments inline.

regards,
John

At 12:11 PM 2/8/00 -0500, Shai Herzog wrote:
>>Levels of roles? If a role is indeed an attribute used as a selector, 
>>this translates to levels of attributes. My head is hurting. ;-) More to 
>>the point, I don't know what you mean by "levels" of roles...
>

<js> OK, fine. You're talking about different uses of the term "role". </js>

>>I humbly submit that you're making this too complicated. Instead, 
>>thinking of roles as a means to select from among a larger subset is 
>>appealing because it always means the same thing each time it is used.
>></js>
>

<js> seems longer ;-) </js>

>So, the schema didn't have roles, but roles were used in configuring the

<js>
The schema may have just had policy configuration information and no roles 
as you suggest, but in this case I wonder how we achieve consistent device 
configuration? It is the role that is used to define how the edge is to be 
configured. Therefore, if each PDP defines its own role, you have chaos. On 
the other hand, if the PDP knows about a certain set of roles, then it can 
distribute these to other PDPs so that each may consistently configure the 
set of devices that it controls.
</js>

>for each one of its roles.

<js>
I have no problem with your above example, and is certainly a valid use of 
roles. However, it is not the only use of roles, right? Equally correct 
would be to describe the provisioning of the system using roles. There are 
two obvious examples of using roles as selectors:

   1) as a way to select the subset of policies from a large
      set of policies that are stored in the repository.
   2) as a way to retrieve the subset of policies that pertain
      to a specific set of devices or interfaces

The first way assumes that the provisioning of the system is described in 
terms of roles. This is in contrast to your example, where roles can be 
used to provision the system. The second uses roles as a selector to 
retrieve policies for specific devices or device interfaces. This is 
slightly different than the first. The first describes the behavior of the 
system. The second describes the capabilities of a device in the form of 
roles (note that this is NOT the only way, but rather ONE way, that the PEP 
can do this) so that the PDP can retrieve the policies that affect that device.
</js>

>>influence device configuration on the PEP level vs. roles as used to 
>>build policy statements at the PDP level. Is this what you meant by 
>>"levels" of roles?
>>
>>If so, then I suggest that we talk about PEP roles vs. PDP roles (as 
>>Keith suggested earlier) vs. roles as a selector (to make me happy ;-) )
>></js>
>

<js>
Well, we're getting very close here. Let me propose a summary to see if we 
can agree. Roles have three fundamentally different uses:

   1) to directly influence device configuration - let's
      call this PEP ROLES for now
   2) to translate from a high-level description of policy
      into one that configures the device either directly
      or indirectly - let's call this PDP ROLES for now
   3) to be used as a selector to retrieve a subset of
      applicable policies from a larger set of available
      policies - let's call this SELECTOR ROLES for now

Note that the second use is subtlely different than the third. The second 
uses roles as a means to translate between expressing policy in general 
terms and in configuring the device to implement or support that policy. So 
in Shai's example, the PDP has two inputs. One input is the definition of 
the policy from the administrator's point-of-view, which probably can not 
be used in its current form to configure devices. The other is from the 
devices that it controls. They announce their capabilities in terms of 
roles. The PDP then uses roles to translate policy from a business 
expression (Gold service, or don't allow more than 30% of my core bandwidth 
to be devoted to a certain type of traffic, or...) to a form that is used 
to ultimately configure the devices that it controls.

The third use is not focused on translation. Rather, it is a way of 
selecting policies and/or policy information to be retrieved for further 
processing.
</js>

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 9 Feb 2000 14:45:23 -0500

I like Bert's suggestion...I don't know how others feel, but my laptop only has 6 gig...can we confine this (and other) discussion(s) to one list, say policy.  Cheers, Lee

---

From: Shai Herzog <[email-masked]>
Date: Fri, 11 Feb 2000 09:05:23 -0500

At 08:18 AM 02/09/2000, John C. Strassner wrote:

>terms and in configuring the device to implement or support that policy. 
>So in Shai's example, the PDP has two inputs. One input is the definition 
>of the policy from the administrator's point-of-view, which probably can 
>not be used in its current form to configure devices. The other is from 
>the devices that it controls. They announce their capabilities in terms of 
>expression (Gold service, or don't allow more than 30% of my core 
>bandwidth to be devoted to a certain type of traffic, or...) to a form 
>that is used to ultimately configure the devices that it controls.
>

The #1 is agreed upon, but I fail to see the #2 & #3 being separate
and I have a hard time with "PDP" roles given that PDP is a translation
machine and doe not have its own definition or determination of policy
(or roles for that matter). It takes two types of input, one from above
(schema) and one from bellow (device). Those inputs may have roles in
them, but those are different "role types".

PEP Roles <-----------> PDP <---------------> Schema Roles

The job of the PDP is to bridge between PEPs and Schema, but it doesn't
have roles or policy per se.

Shai

---

From: "John C. Strassner" <[email-masked]>
Date: Fri, 11 Feb 2000 21:00:25 -0800

OK, #1 is agreed on, that's progress at least. ;-)

>them, but those are different "role types".

But if the PDP is using roles (which you did in your earlier posting) to 
achieve the translation, then it's a role. Furthermore, if it taking input 
from above and below which both have roles, I fail to see how it can not 
therefore understand what a role is.

#2 and #3 happen to be the EXACT case where a role is most closely used as 
a selector. You have role definitions in the schema and in the device, and 
the PDP will retrieve the subset of policies that are applicable to these 
role definitions from the much larger set of available policies that are in 
the repository. So I still see nothing wrong with calling these translation 
roles and selector roles.

regards,
John

At 09:05 AM 2/11/00 -0500, Shai Herzog wrote:
>>Well, we're getting very close here. Let me propose a summary to see if 
>>we can agree. Roles have three fundamentally different uses:
>>
>>the devices that it controls. They announce their capabilities in terms 
>>of roles. The PDP then uses roles to translate policy from a business