Subject: Draft Policy minutes

From: "John Strassner" <[email-masked]>
Date: Fri, 30 Jul 1999 14:38:34 -0700

Policy Enthusiasts,

attached please find the draft minutes for the Policy Framework WG
meetings at Oslo. Please send comments back asap.

regards,
John and Ed

=============

Minutes, day 1, recorded by John Strassner

Charter Changes and Update - John Strassner
----------------------------------------------

John described the changes to the charter. They are summarized below:
  - Information model and LDAP schema were separated into 2 drafts:
      - draft-ietf-policy-core-info-model-00.txt
      - draft-ietf-policy-core-schema-04.txt
  - Both were explicitly linked to the CIM and DEN models
  - The charter was updated to call for explicit coordination between
    the core and QoS policy information model and schemata and:
        - PIB(s) and MIB(s) developed in DiffServ
        - COPS-PR developed in RAP
        - working with IPSP
  - A document combining requirements and use cases will be added
  - A new set of milestones were added

Core Information Model and LDAP Schema Drafts - Bob Moore
------------------------------------------------------------------

The Core Information Model  and Core LDAP Schema were presented by Bob
Moore. Bob first presented the design for splitting the classes that
were in the ...-core-schema-03 document into classes that are in
...-core-info-model-00 and classes that are in ...-core-schema-04.
This also gave insight into why certain new classes that appeared in
the LDAP core schema only were necessary.There are no fewer and no
more classes than there were before, they are just organized better
and have had more detail added.

The information model specifies the semantics of policy independently
of any implementation (including directories that use LDAP as their
access protocol). It does this by using generalized object classes,
and associations and aggregations to relate the different object
classes to each other. It is an enhancement of DEN. Its purpose is to
enable other organizations to map a single model to multiple storage
technologies, making cross-technology interoperability possible.

The purpose of the LDAP core schema is to map the data and
relationships represented in the core information model to a form that
is implementable in a directory that uses LDAP as its access protocol.
Therefore, the basic semantics of these classes are referenced, not
repeated. Modeling constructs, such as associations and aggregations,
are usually represented as DN pointers and "structured DN pointers"
(this latter is a DN pointer that has semantic meaning represented as
attributes). Sometimes, auxiliary classes are also used. Specific
optimizations to simplify identification of classes in the DIT that
should be under policy control, DIT navigation and bulk retrieval of
policy-related information were introduced. These are all required to
help mitigate performance problems when using LDAP, and therefore have
no corresponding classes in the Core Information Model.

Ryan Moats offered to help describe the format of both the core
information model and core LDAP schema classes in formal ASN1. In
addition, would like to examine the concept of versioning.

Going to last call was discussed. The basic problem is that the core
information model (and to a lesser extent, the core LDAP schema
mapping) is needed by other working groups. This argues for moving
these documents to last call, once changes have been incorporated (see
end of the minutes for more info on this). On the other hand, some
people expressed concern that related work, such as the architecture
document and the PIB(s), should be progressed first, and then have the
core documents moved to last call.

One possibility is to move the document through working group Last
Call to ensure that there is consensus, but then wait to submit it to
the IESG until the architecture document (and maybe others) have had a
round of comments. The chairs and the ADs will work out a strategy and
propose this to the working group.

Raju Rajan - QoS Schema
---------------------------

Raju gave an overview of the draft that he has co-authored. It
describes a schema for modeling provisioned and signaled QoS. The
goals of the provisioned QoS section are:

  -  Identify flow aggregates
  -  Ensure resource allocation for flow aggregates using PHBs
  -  Ensure support for AF and EF
  -  Support packet (re)marking

The goals of the Signaled QoS section are:
  -  Accept or reject reservation requests
  -  Per-flow, per-user, per-domain, per-application
  -  Assign pre-emption priorities
  -  Support RSVP policy objects

The draft attempts to support range of client types, including end
hosts/servers as well as networking devices such as routers and
firewalls. For each device category, there are different actions that
are applicable. These include the following:

  Applications and Hosts
    -  User and application needs
    -  Packet marking

Edge routers and firewalls
    -  Traffic verification
    -  Shaping
    -  Aggregation
    -  Resource allocation

Backbone routers
    -  Aggregation
    -  Resource allocation

The DiffServ actions are provided through three classes -
diffServAction (subclass of policyAction), and diffServResourceGroup
and RSVPResourceGroup, the latter two of which are both subclasses of
Top. Traffic profile descriptors and packet marking descriptors are
embedded in the diffServAction class. The traffic profile descriptor
is used to classify traffic as being in- or out-of-profile. The packet
marking descriptor provides the ability to mark the DS byte for
enabling simpler QoS classification at downstream network devices.
The resource group descriptor describes the treatment expected by
packets within a common service group. The descriptor does NOT aim to
describe how the service is to be provided, as this is
device-specific. Instead, it describes the semantics of the traffic
conditioning that is to be performed.

The class RSVPAction, which is a subclass of policyAction, contains
policies to be applied to RSVP PATH messages and RESV messages. The
draft supports simple forms of policy based control, enabling
administrative restrictions to be placed on the amount of resources
that a single RSVP flow, or group of flows, may consume. Support is
also provided for an RSVP reservation to be mapped into a DiffServ
service category.

Raju presented three approaches to the following problem: if 3
descriptors are dumped into a single action class, then if there are
two domains that require separate policing that share a common
resource, this can't be accommodated. His recommended solution was to
combine traffic descriptor and marking in two different diffserv
action classes, and use a pointer to a resource descriptor. You can
further expand on this by cascading diffserv action classes, that each
have their own mark and resource descriptor objects. Problem is that
there are too many objects (Ed note: if the objects are reusable, then
their quantity doesn't matter).

There were a number of questions on the draft.

Shai: No higher-level above RSVP or DS
Raju: take rate. It's defined differently in ATM, DS, etc.

Raj: we need a separate conceptual model

Shai: Why is there no such thing as Gold Service. How do I map between
AF11 and AF31?
Raju: embedded in the condition, and the PDP does this.

Shai: See a higher-level being mapped into RSVP and DS. This is too
low-level.

Raju: What about concurrent work going on in the DMTF? Those of us
that aren't members can't see this.
John: The latest version of CIM is publically accessible

Andrew: needs alignment with terminology draft
John: agreed, but we need to reconcile this draft with other QoS
drafts to be presented
and then align the terminology

David: conditions draft enables you to build an mf classifier; what is
lacking is network state
Tos marking needs alignment with DiffServ. AutoStart should be
optional

Yoram Bernet/Andrew: is this draft at the right level? Similar to the
conceptual model
in diffserv, but why is the draft so close to the device

QoS Device Information Model - Walter Weiss/John Strassner
----------------------------------------------------------------

Best Effort was a Good Thing. Everything was straightforward and easy.
You pushed out the bandwidth, and whatever happened happened.
Congestion wasn't bad - it told you how much you had to cut back, and
how much you had to add.

Then came QoS. Things got a LOT more complicated, especially
management. This took the form of increasing complexity required to
manage individual devices to support network services.

What is a QoS Service? There are two different elements of this
service configuration and management. Policy comes more into play in
the maintenance of a service. Policies apply to services, and also
help implement services.

Need for low-level policies. Device has a set of capabilities, and we
can talk about sets of devices that share sets of capabilities. This
is especially true of DS, when we are talking about behaviors and how
services like AF and EF are managed and maintained. We're advocating
support attributes and classes in the schema that enable us to manage
such services, and to facilitate the mapping of information in
schemata to MIBs, PIBs, etc.

Slide # 6 shows the inherent sub-ordinate relationship of policies.
This is why examples such as "Gold Service" are fraught with trouble,
since "Gold Service" consists of a set of sub-services that, together,
provide the higher-level service referred to as "Gold".

There are 2 components of a policy: grammatical semantics and
attributes. Is User = George, or is this IP Address part of the Sales
Force.  Variables and constants represent the things that you want to
manipulate and check (e.g., device and service state). When you
combine these 2 concepts, you can construct policies to manage
services and business objectives. This is why low-level policies are
so important - Gold Service is meaningless unless it can be related to
what the device is capable of providing.

Shai: 2 statements in fitrst group - is this procedural.
John: No, this defines the enabling of a new class. The point is that
some policies may need to be executed in a device, whereas others
should be executed in a PDP. It depends on the component of the policy
(e.g., are you testing a group of counters)

Attributes are stored in classes, and the policy core model defines
the class structure and grammatical semantics to do this. However, we
worry about attributes being subclassed out of the policy core schema.
Problem is that if all policy attributes are subclassed from the core
schema, this leads to massive duplication of attributes, not just
between different ietf wgs, but also between dmtf models and ietf wgs.
This draft makes a clear differentiation between state and
configuration attributes, something that has been heretofore lacking.
There are really two different types of attributes - state vs.
configuration attributes. State attributes are attributes that
represent the currently active state of the device or service, eg.,
counters. Config attributes specify what the desired value that you
want the device or service to have. E.g., if average queue depth was
10K bytes, and if we want to change that for a certain set of devices,
then we can decouple state from configuration. The point is that we
shouldn't be shackled by the protocol. You can also represent a group
of devices, or interfaces, or services, or other objects.

Contexts and roles. Roles need to be formally added to the grammatical
syntax of policies. These are used to define what policies are applied
to what devices.

Raju: Why can't we use the policyGroup container for roles?
John: Because a role is simply a string attribute that defines the
name of the
object in question. It is not a container. Furthermore, a container
has the
limited semantics of being able to hold objects. A role points to an
object
that has much more powerful semantics, describing how it is used in
the system.

Question: Where does this fit in w.r.t. the bigger picture?
Walter: We want people to think about policies in respect to low-level
and
high-level function. We also want to differentiate between
configuration
and state.

Question: how does this scale? Suppose you had a relatively large
network.
How many objects would be required?
John: Impossible to answer, since policies are inherently different in
nature,
and it depends on what it is that you are trying to do. For example,
controlling a single device will generally take less objects than
controlling a
set of devices. But, as we'll see in the next presentation, being able
to reuse
objects mitigates their sheer number.
Question: But isn't this a lot of objects?
John: Again, impossible to define in the general sense. But it is
generally
greater that 1 and less than 50.

===========
Day 2, minutes recorded by John Strassner
===========

Yoram Snir - QoS Information Model
---------------------------------------

This draft is complementary to the previous draft presented. This
draft subclasses the policy core information model, whereas the
previous draft subclasses the network model of CIM.

This draft is an extension to the core shcema draft, in spirit and
structure. Aimed to help interoperability. Schema is made up of 3
parts: Scoping, Repository, and Definitions.

Reusable-objects. This is a notion currently missing from the core
schema. We feel that it is essential to building highly scalable and
reusable schemata. The repository classes are subclassed from the core
schema. This enables us to add semantics to the container classes
defined in the core schema.

The repository structure is described. Note that it is extensible by
nature, what is presented in the draft is meant to be a foundation.

Reusable objects are placed in the repository. This lets you abstract
key concepts (e.g., an HTTP port can be referred to by HTTP, and you
don't care what the exact port number is). It also helps protect
against some of the deficiencies of LDAP - if classes reference
reusable objects from one repository class, then changes can be
simplified - always get them from one place.

An extensible containment hierarchy is defined in the draft. This
divides objects into multiple domains, each of which can have a set of
named containers that contain groups of policyRules to be applied for
a common set of applications, or to a subnet, or to the employees of
an organizationalUnit, etc.

Why qosPolicyRule? Because the policyRule class is generic and nature,
and certain key attributes needed for QoS are missing. One example is
priority, which is essential if multiple PDPs need to get to the same
target object.

Simple conditions are built out of variables and constants. Variables
have a name and a type, and represent constraints. Constants have a
name and a type, and represent values. We've defined some simple value
classes; more can be added as required.

With this structure, we are able to model provisioned and signaled QoS
conditions and actions in an extensible way. We also have the ability
to model simple and complex conditions, as defined in the core schema
draft.

Something that we're working on is how to abstract the PHB. We're also
working on general definition for PATH and RESV admission control.

Simple condition example - attachment
This shows a simple condition built out of the attachment of a
variable and a constant class. Note that the constant class has a
qosPolicyNumberValue class attached to it. This is in the spirit of
the core schema, and enables you to retrieve this in a single access

Simple condition example - reference.
Gives you more flexibility at the expense of more accesses. But more
accesses aren't bad if the objects that they are referring to are
reusable.

Complex condition
This is also accommodated by our approach. Consists of a set of
references to separate objects

Simple QoS Policy Rule
Example consists of a SimpleCondition and a single action. Each of
these can be attached directly to the qosPolicyRule, which is a
structural class.

QoS Policy Rule example
Now we have a qosPolicyRule with a condition List and an actionList.
Each of the lists point to other objects. The objects themselves can
be simple objects or objects that have other objects attached to them.

Namespace example
This reflects the translation of different administrative domains.
Within a given domain you have a set of policy rules that can be
simple or complex.

David Black: good that someone tried to put this together, likes it in
general

Glenn Waters - Status of the Policy Framework draft
------------------------------------------------------

There is a new set of authors (Hugh Mahon, Mark Stevens, John
Strassner, Lee Rafalow, and Glenn Waters). Next revision to be
submitted to the draft editor by 31 August, will have an interim copy
available for wg review by 15 August.

The general architecture was described. Focus was on the partitioning
of the framework into four components (Policy Management Tool, Policy
Repository, PDP, and PEP), and their interconnection.

The purpose of the policy management tool is to serve as an interface
between policy definition, editing, and management functions external
to the Policy Server (e.g., the repository, PDP, and PEP) and the
components of the Policy Server. It consists at least of an editor, a
means to translate policy rules entered in human-readable form to a
format compatible with the type of the repository being used, and the
ability to validate policy rules. This includes syntax and semantics
(to as much an extent as possible) checking, as well as simple static
conflict detection.

The repository is used to store policy information and rules. Note
that any technology can be used, but particular attention is paid to a
directory that uses LDAP as its access protocol.

The PDP performs three main functions. First, it responds to policy
events and locates the appropriate rules that are of interest to this
event. Second, it performs state and resource validation (for example,
bandwidth broker using policies to control bandwidth allocation).
Finally, it converts the policy rules as stored in the repository to
device-specific mechanisms.

The PEP is responsible for executing the appropriate actions. Note
that the PEP may in fact evaluate the policy instead of the PDP, if
the conditions of the policy are (for example) traffic conditions that
PDP doesn't understand.

Other important parts of the document discuss conflict detection and
interoperability (e.g., how the data in the repository is used and
accessed).
Talk more about Cisco additions, but note that there is no existing
standard to pass notifications. Note also that we don't talk about
protocols in this wg, and so we can specify its functional
requirements in the architecture, and we can specify what happens, but
we can't specify the protocol itself.

Document sections left to write:
  - Roles: John
  - PIBs:  Hugh/Mark
  - Conflict detection additions:  John
  - Relationship to other WGs:  Hugh
  - Procedural vs. declarative:  Glenn

Keith: clarify that you will have multiple of each component (e.g.,
the PDP)
Glenn: OK

Fran: the device adaptor never disappears
Glenn meant a translation of format.
Fran: Doesn't this change how things are stored in the repository?
Glenn: No, it just means that the PEP is very smart and knows how to
deal with information in a raw format

Yoram Bernet: Need to beef up sections on RSVP (e.g., COPS for RSVP)
and generalize things like filters for both DiffServ and RSVP usage

Keith/Nitsan: worried about distribution of policy information

Raj: not trying to solve LDAP problems, right?
Glenn: right

Yoram: use of directory - just for static info, right?
Glenn: right

Walter: variable manipulation can be part of the info model, but do
NOT have to be pushed up all the way to the directory

John Strassner - Update on the Terminology draft
--------------------------------------------------

The purpose of this draft is to define a standard set of terms that
describe policy. It should be compatible with formal modeling
terminology.

Motivation was to reconcile differences in terminology between the
DiffServ, RAP, and Policy groups. Intent is not to redefine
terminology of other groups (e.g., what is a PDP) but rather to help
drive a common agreement between the working groups.

This was recently reissued as a working group draft. Final edits are
being incorporated, and then the next step is to do a thorough review
of it with the updated DiffServ and RAP documents. Will then reissue
by end of August.

Hugh Mahon - Policy Usage and Requirements

This will turn into a working group draft.

The focus in on how one will use a policy system. It emphasizes the
separation of policy delivery from the definition, editing, and
management of policies.
It covers issues such as:
  - accommodating those particular policies that need to be
    delivered in a timely manner. Note that this is separate
    from how often the policy changes, or who changes it.
  - providing feedback to the administrator describing what
    happened to the policy (e.g., was it delivered? were
    there any installation problems? etc.)
  - how does the admnistrator know that the authored
    policy is what was received?
  - how to deal with the lack of transactional and
    referential integrity in LDAP
  - role management

Nitsan: reporting policy server errors. This has a usability problem -
we need to be able to tell the user that a particular policy was
successfully downloaded, installed, and deployed.

Scott Hahn - Description of the PIB
------------------------------------

Important point is that PIB lives not in the schema but is passed down
to the device. Scott views schema as high-level and abstract, not at
the level that the device needs to implement policy. PIB is
responsible for configuration. It enables the same configuration to be
pushed down to a set of devices.

So, the PIB is not a protocol, nor is it a schema. It is a data
definition that exposes the capabilities of a PEP to the PDP. The PEP
uses the PIB to report device capabilities to its PDP. The PDP uses
the PIB to provide configuration information and updates to the PEP.

Policy server and PDP developers need to be aware of both the PIB and
the schema, because they need to map information contained in one to
the other, and vice-versa. Referring to slide #3, PIB information is
carried on the wire between the PDP and a PEP.

The flow of data is simple - the device expresses its capabilities to
the PDP, and then the PDP matches policy rules to those capabilities
and sends down configuration information. The PEP can then report
status and/or errors to the PDP. Note that the PDP can asynchronously
update policies as required.

The PIB is protocol-agnostic, but one specific implementation was
written with COPS-PR in mind as the transport protocol. The PIB could
easily be carried over SNMP, for example.

The initial draft focuses on a QoS PIB, though the concept is
extensible to other policy domains. Now part of the DiffServ WG.
Focused on DiffServ policies. QoS PIB consists of 3 modules: general
info, IP module, and 802.1p module.

The PIB uses the concept of roles and role-combinations.

More integration needed with DiffServ conceptual model and the
DiffServ MIB. Metering currently is not addressed.

Kathy Dally - How is violation of Policy handled?
(we need to take this to the working group)

Walter - we need a practical example of how to use a PIB. In
particular, we need to substantiate the claim that it contains
lower-level information than the schema contains.
(again, we need to take this to the working group)

Policy Conditions (Raju)

PolicyGroup groups policyRules. PolicyRules talks about
policyConditions and policyActions.

What shoul be the content of policyConditions, and how should it be
structured. PolicyConditions need packet header and PEP information,
administrative categories, and network state/event categories. This
should be represented in the schema, but we must consider data and
query costs, extensibility, structural vs. aux classes. These
considerations affect the overall object model.

Administrative categories - user, user groups; hosts and host groups;
apps; roles

Network state/event information. Wide range of events that are
relevant to QoS. But you get into trouble when you try to put this
into the directory. Examples of this are network congestion, routing
information, or RSVP path message arrival. How will we achieve
interoperability, and how can we ensure that multiple devices from
multiple vendors will use the same definitions.

Policy condition - if you embed an expression directly as an attribute
in the condition object, then it isn't extensible and you need another
schema to interpret it.

One way to do this is with one structural class with all may
attributes. Not extensible, and doesn't allow one user to extend
attributes of the class of one type without affecting the entire
class. Preferred way is to use multiple aux classes.

Jamie Jason - Working with IPSP
---------------------------------

There are currently 3 drafts in IPSP - ASN1 draft for VPNs, another,
plus UML draft. We've unified the 3 drafts in order to design policy
to control IPSEC in the abstract. After we get agreement from the
IPSEC wg, we want to get agreement with the PFWG. This will enable us
to ensure that their draft is properly derived from PF core classes,
as well as enable them to provide direct feedback to this wg. Want to
be able to represent the 5-tuple somewhere, maybe not in core, but
certainly not repeatedly in IPSP and DiffServ.

Final Action Items (Ed Ellesson)
--------------------------------

General consensus that some concepts in the Snir-Ramberg-Strassner QoS
draft (e.g., repositories) need to be moved into the core policy
document. Authors of both documents to get together and plan this out.
Then, both documents will be re-issued.

Policy terminology draft to be updated, and a new revision sent to the
list. It is hoped that the next revision of this (and the policy core
information model draft) will be ready for working group last call.

Core LDAP draft proceeding well, but needs another revision before we
can start considering Last Call.

The authors of the framework draft will produce an updated draft on or
before 31 August. Hugh will try to produce his new draft by 31 August
too.

It seems like we should have an interim meeting, possibly one day of
design team from Policy, DiffServ and RAP, and another day of the
Policy Framework working group. Target date will be early September.