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

snmpconf RE: Policy issues: definition of Roles

Hi Shai, comments inline.


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

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.

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

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.

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

   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.

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

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

<jcs> Agreed </js>

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

   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

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


At 05:49 PM 02/06/2000, John C. Strassner wrote:
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.


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


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:kjr@nortelnetworks.com]
Sent: Monday, January 31, 2000 4:42 PM
To: Andrew Smith; 'Bob Natale'
Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com'
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.
Ken Roberts
INM Product Architecture
Nortel Networks
?ESN   :        655-7844                        ?Direct  : 408-565-7844
?  Fax    :        408-565-8226
? email :      kjr@nortelnetworks.com

This message may contain information proprietary to Nortel Networks
Corporation so any
unauthorised disclosure, copying or distribution of its contents is strictly
 -----Original Message-----
From:   Andrew Smith [mailto:andrew@extremenetworks.com]
Sent:   Monday, January 31, 2000 3:36 PM
To:     'Bob Natale'
Cc:     policy@raleigh.ibm.com; 'snmpconf@snmp.com'
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
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
(Apologies if I'm repeating stuff here).

> -----Original Message-----
> From: Bob Natale [mailto:bnatale@acecomm.com]
> Sent: Monday, January 31, 2000 3:27 PM
> To: Andrew Smith
> Cc: policy@raleigh.ibm.com
> 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).

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