[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
various levels of "roles". Let me try to make the
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
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
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
2. PDPs and DEN Policy Schemas may or may not
take advantage of PEP
PEP Roles: Edge+Ethernet, Edge+T1
PDP Policy: If User=Joe, Mark (Traffic Desc)
Here the PDP may actually track down the ingress router
mark on ALL of its interfaces, regardless of Roles. It
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
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
Given the previous example, the PDP is not allowed to send
following to the PEP:
Role=Edge : Conf1
Since the PEP that has an interface with both roles in a
combination (Edge+Ethernet) is now required to merge
This merge is a big NO NO, since the whole point about
policy processing is that the PEP doesn't understand
implications and complications and needs to receive very
<jcs> Agreed </js>
4. PDPs may be smart enough to merge roles
(and therefore deal with
individual roles within a role combination). This is
an implication of observation (2) but I though it needs to
For example, in the PDP, lets assume Ethernets get
treatment (higher precedence rule).
Role=Edge : If Service=Gold then Mark
Role=Ethernet: If Service=Gold then Mark DSCP=yyy
This will produce the following configuration (using COPS,
Role=Edge+Ethernet: Mark (Traffic Desc) DSCP=yyy
Role=Edge+T1 : Mark (Traffic
So, going back to the definition I gave a while back, the reason
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
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"
interfaces". You wouldn't bother sending that rule to token-ring
(I guess I'm really an assembler programmer so I don't understand
"class" and "subclass" things you talk about).
P.S. Maybe we should drop the "policy framework" list from this
this appears to be purely a "device" thing. But I did think we
attempting the (maybe thankless) task of unifying the terminology
all the WGs.
From: Ken Roberts
Sent: Monday, January 31, 2000 4:42 PM
To: Andrew Smith; 'Bob Natale'
Cc: email@example.com; 'firstname.lastname@example.org'
Subject: RE: Policy issues: definition of Roles
Gents & others,
I'm a little confused by Andrew's statement of a policy that has
roles. I understood a policy had rules. Rules may be crafted to include
notion of roles but are they separate rules or sub classes of one
When the statement "A policy that references roles W and X" is
this imply there is a matrix relationship that can be established from
parent policy (/rule)? How is this managed? Why is this required?
policies have hierarchical structure can this not be done with
or another relationship?
I think I had better re-read the thread as maybe I've missed
INM Product Architecture
?Direct : 408-565-7844
? Fax :
? email : email@example.com
This message may contain information proprietary to Nortel Networks
Corporation so any
unauthorised disclosure, copying or distribution of its contents is
From: Andrew Smith
Sent: Monday, January 31, 2000 3:36 PM
To: 'Bob Natale'
Subject: RE: Policy issues:
definition of Roles
And, in particular, you only need to tell the device about those roles
are relevant to it - that is where the big savings are, I think.
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
4. A policy that references roles W and Y should be downloaded only
device A, not device B.
The role combination concept in the PIB was introduced specifically in
to do this: you have to be able to list only those roles that are
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
> Sent: Monday, January 31, 2000 3:27 PM
> To: Andrew Smith
> Cc: firstname.lastname@example.org
> Subject: RE: Policy issues: definition of Roles
> That works fine for me. All I care about on this thread is
> "role combination" DOES NOT HAVE to include ALL of the
> by a network entity/component (although there MAY well be a
> combination which does incorporate all roles supported by a
Shai Herzog, Founder & CTO IPHighway Inc. Tel
: (914) 654-4810
55 New York
Main: (508) 620-1141
Fax : (212) 656-1006