[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snmpconf RE: Policy issues: definition of Roles



Comments inline.

regards,
John

At 12:11 PM 2/8/00 -0500, Shai Herzog wrote:
At 08:22 AM 02/08/2000, John C. Strassner wrote:
Hi Shai, comments inline.

regards,
John

At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:
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:

<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...

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

<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>

I think the two of us have been discussing this for perhaps years ;-)

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

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.

<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>

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.
...

<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>


<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>

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".

<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>
 
Shai

__________________________________________________________________
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