Subject: RE: Policy issues: definition of Roles

From: "Weiss, Walter" <[email-masked]>
Date: Wed, 26 Jan 2000 11:12:14 -0500

Jon (Saperia),

Are you suggesting that a given policy should be restricted to a single
class (the policy equivalent of a PIB/MIB row) and that a
collection/hierarchy of policies be used to implement the example policies I
cited?

regards,

-Walter

> -----Original Message-----
> From: Jon Saperia [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2000 7:49 AM
> To: Weiss, Walter
> Cc: [email-masked]
> Subject: Re: Policy issues: definition of Roles
> 
> 
> Walter, I like your second role definition better as well. I 
> had always
> imagined, even before this work started, of a hierarchy of rules
> (policies) which would take precedence under some circumstances. One
> reasonable one you gave is over subscription. Another I 
> frequently worry
> about is failure (which can look like over subsciption).  In a sense I
> am suggesting a way of interrelating rules. 
> /jon
> "Weiss, Walter" wrote:
> > 
> 
> > The first issue is one I eluded to in my presentation. 
> There are apparently
> > two definitions for Role:
> > 
> > 1. A role is a list of targets for a policy to be applied 
> to. In other
> > words, if the policy conditions and actions describe some 
> interaction with
> > or within an interface, the role lists the interfaces that 
> the policy is
> > applicable to. If the policy describes some OSPF related 
> rules, then the
> > role is the list of OSPF instances. This definition is more 
> applicable to
> > how policies are distributed
> > 
> > 2. A role describes the binding between the set of 
> attributes used in a
> > policy and the actual attributes that exist in a device or 
> service. For
> > example, a policy that prevents new flows when total 
> bandwidth for that flow
> > type exceeds 30% of all traffic, may need an explicit binding of the
> > bandwidth counter attribute and the flow type definition to 
> a particular
> > instance of a queue. This definition speaks more to how a policy is
> > interpreted.
> > 
> > My take is that these two definitions are nearly the same. 
> However, if a
> > role is assumed to be associated with the rule, I would be 
> inclined to favor
> > definition 1. The reason is that I anticipate the 
> possibility of policy
> > rules that either interact with multiple instances of the 
> same time (If Gold
> > Traffic exceeds a threshold, lower bandwidth allocation for 
> Silver Service)
> > or transcend service domains (When a new DHCP accounting 
> user is validated
> > install a packet filter granting access to the accounting 
> network). In the
> > first example a role listing the queues/services to which 
> this policy is
> > applicable is reasonable. However, a role binding of the rule to a
> > particular set of queues/services is ambiguous because the 
> gold service
> > queue and the silver service queue would each interpret the 
> rule as "If MY
> > traffic exceeds this threshold reduce MY bandwidth." What 
> we really want is
> > "If MY  traffic exceeds this threshold reduce the OTHER 
> bandwidth." In the
> > second example, according to definition 1 of role, the 
> policy server would
> > determine that the role is applicable to the DHCP service 
> and the filters on
> > edge interfaces of the accounting network. Under definition 
> 2, the attribute
> > binding is confusing because the DHCP service has no packet 
> forwarding
> > service and the routers don't (usually) have a DHCP 
> service. Therefore a
> > subset of the attributes are ambiguous. The only way to 
> disambiguate this
> > type of rule is to qualify the attribute: 
> DHCPService.NewUserAddress and
> > AccountingEdgeInterfaces.SrcAddrFilter. With this level of attribute
> > qualification, the value of roles under definition 2 seems almost
> > irrelevant.
> > 
> > Comments?
> > 
> > regards,
> > 
> > -Walter
>

---

From: Jon Saperia <[email-masked]>
Date: Wed, 26 Jan 2000 13:14:23 -0500

> collection/hierarchy of policies be used to implement the example policies I

Actually no - I do not think that all policies must necessarily be
limited to a single class. I think there should be a class of policies
which can span what you would call single client types.  I had mentioned
this a while ago.  It seems logical to me that in some cases policies
are modified by others. It is possible that a collection of policies
could reasonably be implemented as a hierarchy or in other
relationships. It might be fun to use something like rational rose to
model real world policies and see the relationships and shared data elements.

/jon