Subject: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01

From: "Robert Moore" <[email-masked]>
Date: Tue, 30 Jan 2001 11:01:37 -0500

A subset of the PCIM, QPIM, ICIM, and MQPIM (Policy Framework MPLS
Information Model for QoS and TE) authors met last week, to begin
work on the PCIM Extensions (PCIMe) draft.  The goal was to take the
"implementation" experience from the three submodels of PCIM, and
determine what changes and extensions they suggested for the
proposed-standard PCIM document (currently sitting in the RFC
Editor's queue as draft-ietf-policy-core-info-model-08.txt).

The following is the list of changes that we agreed to pursue
documenting in the -00 version of the PCIMe draft.  Rather than
springing these changes cold on the WG at the I-D cutoff date, we'll
provide a brief summary of them here.  This is still work in progress
for the people who attended last week's meeting, so these formulations
of the issues may change.  But here's a snapshot of where we stand
right now.

   The following subsections provide a very brief overview of the changes
to
   PCIM being proposed in PCIMe.

 2.2.1. Changes to PolicyRepository

   Because of the potential for confusion with the Policy Framework
   component Policy Repository (from the four-box picture: Policy
Management
   Tool, Policy Repository, PDP, PEP), it was determined that
   "PolicyRepository" is a bad name for the PCIM class representing a
   container of reusable policy elements.  Thus the class PolicyRepository
   has been replaced with the class ReusablePolicyContainer.  To accomplish
   this change, it was necessary to deprecate the PCIM class
   PolicyRepository and its three associations, and replace them with a new
   class ReusablePolicyContainer and new associations.

   As a separate change, the definition of a ReusablePolicyContainer was
   broadened, to allow it to contain any reusable policy elements.  In
PCIM,
   a PolicyRepository was allowed to contain only policy conditions and
   policy actions.

 2.2.2. Additional Associations and Additional Reusable Elements

   The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule associations were
   imported from QPIM.  These associations make it possible to define
larger
   "chunks" of reusable policy to place in a ReusablePolicyContainer.  The
   PolicyRuleInPolicyRule association also introduces new semantics
   representing the contextual implications of having one PolicyRule
   executing within the scope of another PolicyRule.

 2.2.3. CompoundPolicyConditions and CompoundPolicyActions

   The concept of a CompoundPolicyCondition was imported into PCIMe from
   QPIM, and broadened to include a parallel CompoundPolicyAction.  In both
   cases the idea is to create reusable "chunks" of policy that can exist
as
   named elements in a ReusablePolicyContainer.  The "Compound" classes and
   their associations incorporate the condition and action semantics that
   PCIM defines at the PolicyRule level: DNF/CNF for conditions, and
   ordering for actions.

   Compound conditions and actions were defined to work with any component
   conditions and actions.  In other words, while the components may be
   instances, respectively, of SimplePolicyCondition and SimplePolicyAction
   (discussed immediately below), they need not be.

 2.2.4. Variables and Values

   The SimplePolicyCondition / PolicyVariable / PolicyValue structure was
   imported into PCIMe from QPIM.  A list of PCIMe-level variables was
   defined, as was a list of PCIMe-level values.  Other variables and
values
   may, if necessary, be defined in submodels of PCIMe.

   A corresponding SimplePolicyAction / PolicyVariable / PolicyValue
   structure was also defined.  While the semantics of a
   SimplePolicyCondition are "variable matches value", a SimplePolicyAction
   has the semantics "set variable to value".

 2.2.5. Packet Filtering

   For packet filtering done in the context of a PolicyCondition, a set of
   PolicyVariables and PolicyValues were defined, corresponding to the
   fields in an IP packet header plus the most common Layer 2 frame header
   fields.  It is expected that policy conditions that filter on these
   header fields will be expressed in terms of CompoundPolicyConditions
   built up from SimplePolicyConditions that use these variables and
values.
   An additional PolicyVariable, PacketDirection, was also defined, to
   indicate whether a packet being filtered is traveling inbound or
outbound
   on an interface.

   For packet filtering in other contexts (specifically, for the packet
   classifier filters modeled in QDDIM), these variables and values need
not
   be used.  Filter classes derived from the CIM FilterEntryBase class
   hierarchy may still be used in these contexts.

 2.2.6. Priorities and Decision Strategies

   Drawing from both QPIM and ICIM, the priority property has been
   deprecated in PolicyRule, and placed instead on the associations
   PolicyRuleInPolicyGroup, PolicyGroupInPolicyGroup,
   PolicyGroupInPolicyRule, and PolicyRuleInPolicyRule.  (Obvious question:
   would it be better to introduce a superclass PrioritizedPolicyComponent
   for these four associations, just to contain the priority property?  The
   answer is probably "yes".)  The QPIM rules for resolving relative
   priorities across nested PolicyGroups and PolicyRules have been
   incorporated into PCIMe as well.  With the removal of the priority
   property from PolicyRule, a new modeling dependency has been introduced:
   in order to prioritize a PolicyRule relative to other PolicyRules, the
   rules must be placed in a PolicyGroup.

   In the absence of any clear, general criterion for detecting policy
   conflicts, the PCIM restriction stating that priorities are relevant
only
   in the case of conflicts has been removed.  In its place, a
   DecisionStrategy property has been added to PolicyGroup class, to allow
   the policy administrator to select one of two behaviors with respect to
   rule evaluation: either perform the actions for all PolicyRules whose
   conditions evaluate to TRUE, or perform the actions only for the
highest-
   priority PolicyRule whose conditions evaluate to TRUE.  The QPIM rules
   for applying decision strategies to a nested set of PolicyGroups and
   PolicyRules were also imported.

   The question of whether to require unique priority values for the
   PolicyRules in a PolicyGroup was raised and discussed, but the decision
   was to allow these values to collide within a PolicyGroup, to indicate
   "don't care".  Submodels of PCIMe are free to add the restriction that
   priority values not collide within a PolicyGroup.

 2.2.7. Policy Roles

   Policy roles were removed from PolicyRules (that is, the PolicyRoles
   property was deprecated there), and placed instead on PolicyGroups.  For
   nested PolicyGroups, any roles associated with the outer PolicyGroup are
   automatically "inherited" by the nested PolicyGroup.  Additional roles
   may be added at the level of the nested group, but inherited roles
cannot
   be canceled or overridden there.

   It was also observed that there was no mechanism at all in PCIM for
   assigning roles to resources.  For example, while it was possible to
   associate a PolicyRule with the role combination "FrameRelay&&WAN",
there
   was no way to indicate which interfaces had this role combination.  A
new
   PolicyRole class was defined, representing the collection of resources
   associated with a particular role combination.  The linkage between a
   PolicyGroup and a set of resources is then represented by having an
   instance of PolicyRole that shares its name with a role combination
value
   for the PolicyGroup, and is associated with the set of resources having
   that role combination.

If you have any comments on these proposed updates to PCIM, please post
them
to the mailing list.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]