[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf RE: Policy issues: definition of Roles
In the worst case then, yes, you're right, the PDP has to multiply out the
role combinations and send them all to the PEP. But there will be many cases
where the PDP knows that a policy does not need to distinguish between "T1"
and "Ethernet": then, the PDP can download a policy for role-combination
"Edge". In that case, the ALL in your definition is not applicable. That is
what I was trying to explain in my response to Bob Natale last week (1/31).
> From: Shai Herzog [mailto:firstname.lastname@example.org]
> Sent: Sunday, February 06, 2000 8:48 PM
> To: John C. Strassner; Andrew Smith; 'Ken Roberts'
> Cc: email@example.com; 'firstname.lastname@example.org'; email@example.com
> Subject: RE: Policy issues: definition of Roles
> 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