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

snmpconf [Fwd: Policy issues: definition of Roles]

The other email.

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