IETF-47 Policy Framework WG Minutes
Day One, Policy Framework WG
Minutes recorded by John Strassner
The agenda was discussed. No changes were made. For your
reference, the agenda was:
1st Session, 1300-1500 Mon, 27 March
Agenda Bashing - Ed (5)
Status Update - Ed/John (15)
PCIM - WG Last Call Results - Bob (15)
PCIM - Final Draft Review - Bob (25)
file: draft-ietf-policy-core-info-model-04.txt
PCS (Policy Core Schema) Review - Bob (10)
file: draft-ietf-policy-core-schema-06.txt
Polterm Requirements Doc - Fran (15)
file: draft-reichmeyer-polterm-terminology-00.txt
Policy Framework Status - Mark (15)
file: draft-ietf-policy-framework-00.txt
Policy Monitoring - Bob/Ken (15)
(postponed to Wed.)
no draft, just general thoughts; draft is pending
Wrapup - Ed (5)
2nd Session, 1300-1500 Wed, 29 March
Policy Monitoring - Bob/Ken (10) (resched)
no draft, just thoughts
QoS Policy Extensions - John to give an intro (5)
QoS Policy Info Model (new draft) - John (22)
file: draft-ietf-policy-qos-info-model-00.txt
QoS Policy Schema (revision) - John (20)
file: draft-ietf-policy-qos-schema-00.txt
QoS PHB Specifications - John (5)
file: draft-ietf-policy-qos-schema-00.txt
QoS Device Info Model Update - Walter (22)
file: draft-ietf-policy-qos-device-info-model-00.txt
(will be available by 3/20/00, note name change)
Requirements and Use Case - Hugh (23)
file: draft-ietf-policy-req-02.txt
Policy Scalability - Hugh (08)
file: draft-owens-policy-scalability-00.txt
Wrapup - Ed (5)
(Note: due to a long discussion about whether and when a
second working group last call should start, the Policy
Monitoring draft was moved to the second session and the
draft discussion in that session were compressed to
accommodate the change)
Status - John Strassner
John gave a brief overview of the overall status. The bad news
is that we�re behind our charter goals. The good news is that
we�ve had a lot of activity this last round. Every draft listed
above in the agenda is either a new draft or an update to an
existing draft. The exceptions are the framework draft, which
has been waiting for consensus to build in other affected
working groups, and the core schema, which is waiting until
the core information model gets out of working group last call.
Q: Are we doing another call for the core information model?
A: This ended up being a somewhat lengthy discussion.
Here�s a summary.
There are two outstanding issues in the core model. The first is
representation of time, which Bob will talk about shortly. We
have an answer, so this will be resolved. The second was
clarification for roles, which we added. All other last call
comments have been addressed in the document.
Now, we want to strike a balance between doing the right
thing (having another formal working group last call) and
trying to get the document issues as soon as possible. The
argument against having another working group last call is it
will cause at least another week and a half delay (repository
doesn�t open till April 7) and there really isn�t anything more
to discuss. ;-) Argument for another working group last call is
that is how the procedure should take place, and since this is
for Proposed Standard, we shouldn�t take any short cuts. After
further discussion, we decided to go the formal route and have
a last call start as soon as the draft was placed in the
repository.
Q: And when is last call for core schema?
A: The core schema will go to last call when the IETF Last
call completes of the core information model.
Q: Can�t we move this up a bit?
A: Bert agreed. It was decided that we update and send into
last call another revision of the core schema, approximately 2
weeks (sooner if possible) after the core information model
completes its second last call. This would make it available
roughly in mid-May.
Core Info Model - Bob Moore
File: draft-ietf-policy-core-info-model-04.txt
Several editorial comments were raised, and addressed in the
04 version of this draft. One issue was raised, and resolution
will be discussed below. This is the time issue, and will cause
the version of the Policy Core Information Model (PCIM) to
be revised to 05, and will be the main focus of attention for
the second WG last call.
The main issues talked about during the change from 03 to
04 in the first working group last call were:
- declarative vs. procedural model (wording clarified)
- discussion of roles (wording clarified)
- new PolicyRoles property added to policyRule
- UCS-2 encoding for CIM strings explained more fully
- Changed encodings of PolicyTimePeriodCondition mask
properties from strings to octet strings
- Clarified encoding of OIDs for ConstraintEncoding and
ActionEncoding properties
- Expanded the names for several of the association
classes and their reference properties
- Updated Security Section
- Updated Acknowledgments and References sections,
along with minor editorial fixes
We then had a discussion about roles in the meeting. There
was concern voiced that the roles definition was still not as
clear as it could be. For example, what happens, specifically,
when it is desired to retrieve all policies that are defined for
the role-combination BGP+RIP? It is assumed that this will
cause all policies for BGP, all policies for RIP, and all policies
that deal with both BGP and RIP to be downloaded to the
PDP. However, this is not explicitly spelled out. There was a
request for additional clarification to state explicitly that all of
these policies get downloaded to the PDP. It is then up to the
PDP to either filter only the BGP+RIP policies and send those
policies to the PEP, or to ship additional policies to the PDP
and have the PDP decide what to act on. This text will be
added as part of the 05 draft. This action item is assigned to
John.
Time issue. The basic issue was that the semantics and syntax
for the time-range properties in the policyTimePeriodCondition
class should match those specified in RFC 2445 (iCalendar
document). This RFC already has a convention for representing
time intervals, and the suggestion was that we use that
convention instead of our own. Proposed resolution:
- when both ends of the time period are specified, use the
convention in RFC 2445
- when there is an open ended time period (from some
time before till or from now till forever),
RFC 2445 doesn�t have this capability. So we�ll solve
this by glueing together the specification of
each end according to RFC 2445.
- For timeOfDayMask property, change the representation
to conform to RFC2445 by starting the time with a T and
replacing our delimiter (a colon) with the RFC 2445
delimiter (a slash). As an example, we could have:
Thhmmss/Thhmmss.
So far, so good. However, once we started talking to the
iCalendar people, we realized that there was yet another
problem with the representation of time zones. This affects the
ApplicableTimeZone property . We use a static offset from
UTC time, as does almost everyone else. But this is wrong,
because for example, countries that have daylight time change
their offsets twice a year. We observe that we are just as good
(or bad) as SNMP, LDAP, and many other protocols in this
area, and therefore we should change when the other protocols
change. Bert and Patrik Falstrom are investigating and will get
back to us.
The action item for updating the first two items with respect to
time definition is assigned to Bob.
Next steps. We need another two-week last call. After some
discussion, we decided that we will wait to have a working
group last call start Monday 10 April, since that is the first
date that people may be able to get the document from the
repository. John or Ed will ensure that the document is
updated and posted to the repository as soon as it opens up (7
April).
Core LDAP Schema - Bob Moore
File: draft-ietf-policy-core-schema-06.txt
We need to incorporate recent work done in the DMTF plus
work that Ryan Moats has done in mapping information
models to the LDAP schema. Then, we will be ready to issue
another revision of this document.
Q: what about definitions such as port and protocol? These
objects have added semantics that should be captured in the
Core information model and schema, instead of remaining in
the QoS models.
A: There are some problems associated with this, such as
coordinating this work with other working groups that want to
use these.
Q: But there are a number of IETF-specific constants (for
example, protocol and port) that are IP-specific.
A: But moving this to the Core information model and schema
means that other working groups, such as IPSP, must use it.
Furthermore, it means that working groups that don�t need a
concept of port or protocol would be saddled with it.
A: IPSP wanted to differentiate between distribution and
configuration of policies. So the current IPSP draft isn�t really
tied into the Policy model; rather, it is trying to model lower-
level information that can be controlled by higher-level policy
(similar to the division in the QoS models in Policy).
Bert thinks that if it is indeed general, then we should consider
moving this information into the Core Info Model and
Schema. This then raised a discussion as to (1) its feasibility
and (2) its practicality. Feasibility is the actual mechanics of
moving the information; practicality is when, and how that
will affect the schedule.
One additional possibility is to have a third document -
information model proposed common concepts (and of course,
a companion LDAP mapping document). This is the subject
for further discussion on the list. The chairs recommend that
we wait until the Policy QoS and Device QoS models are re-
published, along with the IPSP model, to see if these are
indeed general concepts.
Action Item: Bob Moore to coordinate the updating of the
Policy Core Schema draft. This should wait until the working
group last call of the PCIM has finished, just to make sure that
nothing changes. The goal will be to issue a new revision as
close to two weeks from a successful working group last call
close of the PCIM.
Policy Terminology - Francis Reichmeyer
File: draft-reichmeyer-polterm-terminology-00.txt
Approach. Several working groups are working on policy
networking terminology. The list includes (at least) RAP,
Policy, DiffServ, and IPSP. Others are being added (e.g.,
MPLS). The result is a lot of policy terms and definitions, with
some conflicts occurring. The focus of this document is to
resolve those conflicts and to put these terms in one place.
Goal: identify relevant common terms that all working groups
can use.
Non-goal: common policy architecture
Q: Does this draft introduce new terms?
A: No
Approaches to Policy. This section talks about Policy,
management and administration of policy, the notion of policy
domains, and meta-policy. These latter two were new to some
people. A policy domain is a collection of objects that have
been explicitly grouped together so that they can share the
same policies. There is an implied common administration that
happens. Domains can be nested, in order to reflect
hierarchical semantics. A meta-policy is a policy that defines
how policies are constructed. Another way of thinking about
this is that it defines how to build other policies.
Policy Management Models. Three are defined: outsourcing,
provisioning, and interactive (though there is a question as to
whether this one is needed or not). An outsourced policy
model directs certain components of the policy framework to
rely upon other components of that same framework in order
to perform policy-related decisions. A provisioned policy
model implements policy by first configuring devices that will
execute policy decisions prior to the events that will prompt
those decisions. No real-time interaction is done here - this
model consists of configuring a device so that it will do the
right thing sometime later. An interactive policy model
implements policy by installing policy expressions within
appropriate components of the policy framework. This means
that policies are complete, self-contained expressions, and that
there are a set of rules that define the interaction between a
process that requires policy decisions to be made and the
constituent components of the policy framework that enforce
those decisions through executing a set of actions.
Q: Are these three terms reflective of work being done in an
architecture, or is it something that was invented as part of this
work? If it was invented, then we should not use it. (In other
words, the purpose of this draft is to document terms, not
invent new ones).
A: Good feedback, the authors will discuss this again.
A: The purpose of this document is to be a "living" document
that grows as the working groups that are using it gain more
experience and form tighter definitions of policy.
Q: Outsourcing and provisioning reflect a COPS legacy,
where interactive reflects a policy legacy. Policy is all about a
condition-action pair, and controlling the interaction between
a PDP and a PEP.
A: Provisioning is pure configuration. Outsourcing is asking
for help. Interactive is describing capabilities.
The chairs appealed for volunteers to write up and comment
on text. Shai to argue against interactive, and Walter to argue
for interactive. Everyone else is free to join in the discussion.
;-)
Abstraction and Scoping. Four key concepts are defined in this
section: Administrator-defined, device-independent, device-
dependent, and roles. Roles are used to help define scoping.
Q: what about network-wide policies?
A: not explicitly identified as such, but this term should be
added to the next revision of the document.
Q: Also, don�t like "administrator-defined". This should
instead be bound to a specific scope, such as administrator for
a network, etc.
A: Authors to discuss and either incorporate or add additional
clarifying text.
Q: Are there multiple definitions of roles? In other words, is
this definition synchronized with the definition in the PCIM?
A: The intent is most assuredly to NOT have multiple
definitions. Unfortunately, the definitions are not currently
synchronized with the PCIM, but they will be in the next
revision.
Q: Concern that by defining the functions of a policy system,
there is a strong chance of these terms conflicting with other
documents.
A: Good point. So if this document is a "passive" document
(i.e., no new terms are defined), then if there needs to be a new
term, the authors of this document should contact the
appropriate architecture or framework document and get them
updated.
This last question led to a general discussion of which
working group should own this document. It was offered that
Policy owns this, and RAP agreed. Need to check with IPSP
and DiffServ. (Editor�s note: subsequently, IPSP and DiffServ
responded, saying it was OK. Thus, this document needs to be
added to the Policy Framework working group charter. Action
item: John/Ed to do this).
Framework document - Mark Stevens
File: draft-ietf-policy-framework-00.txt
Document hasn�t received much attention, due to other
pressing matters that this draft depends on. The authors are
going to be revising this and hope to get a new revision out in
April (May at the latest). Feedback is encouraged.
Wrapup of First Day (Ed).
1. New version of PCIM (-05) will be completed by the end
of this week (pending discussion of moving constants
from QoS model to PCIM
2. Time period changes will also be incorporated by next
week.
3. John to update roles section by next week.
4. Bert to check with Marcus on time zone handling.
5. Monitoring to be moved onto Wednesday session.
6. Which working group should own policy terminology?
Tentatively Policy, but need to check with IPSP and
DiffServ, and also need to ensure that it is a working
document that incorporates needs of the other working
group
7. Shai and Walter to suggest text describing use of
interactive.
Policy, Day Two
Policy Monitoring - Bob Moore
(No draft yet)
Why monitoring (i.e., what are the requirements that we are
trying to address)?
Administrators need to know which policies (active and
inactive) are present at a PDP, and whether these policies are
meeting their objectives and being properly enforced. There
needs to be a "core" policy MIB to tie all of the individual
policy-related MIBs together.
It is proposed that a new draft be written that addresses these
issues. Note that the scope is monitoring only -- we have other
mechanisms for configuring policies.
The next question is what to monitor. There are two broad
categories of items that need monitoring - the policy
framework itself, and whether polices are acting correctly and
being enforced or not. This is more complicated that it initially
appears to be. There can be several protocols (e.g., a policy
repository protocol, like LDAP, as well as policy protocols
themselves (e.g., COPS and SNMP). In addition, there are
issues with respect to instrumenting different domains (e.g.,
QoS and IPSec will have different needs).
There are a set of nine possible instrumentation points
envisioned. These divide into the ingress, inside and egress of
the Policy repository and PDP (6), the ingress and inside of
the PEP (2), and the policy-managed resource itself (1). All
except this latter one use the policy framework. More
specifically, they are:
1 - PM tool to repository
2 - inside the repository
3 - repository to PDP
4 - PDP to repository
5 - Instrumented inside the PDP
6 - PDP looking at PEP
7 - implemented at a policy-aware PEP, policy flows
from the PEP to the PDP
8 - the MIB that instruments the function that is
policy-controlled
9 - the PEP itself
There are a set of MIBs that exist. The question is, how do we
proceed to harmonize/rationalize these MIBS and relate them
to the Policy Framework working group? This draft will help
define this relationship.
Policy QoS Information Model - John Strassner
File: draft-ietf-policy-qos-info-model-00.txt
This draft was built by abstracting the concepts in the QoS
Policy schema. It is acknowledged that not all of the
"LDAPisms" have been successfully purged from this
document, and that it should be further generalized. This will
happen in the next revision.
The purpose of this draft is to extend the generic concepts of
policies to a form that is more suitable for representing
policies that control DiffServ and IntServ. It fits as the middle
layer of policies, refining on generic concepts (for
interoperability) and using specific mechanisms as defined in
the QoS Device Information Model (to be discussed later). For
example, it defines the concept of a policer. This is not a
generic extension (e.g., DHCP doesn�t require one); it is a
concept that is needed by DiffServ and IntServ.
Status
This draft is actually the third major revision - it is a 00 draft
because it has just moved from the individual namespace to
the working group namespace. The following changes were
made during this revision:
- Added a lot of detail to QoS actions (both DiffServ and
IntServ)
- Added functionality, yet simplified, repository usage
- Added granularity to representing constants and
variables
- Added changes to match the latest version of the PCIM
- Added examples
- Minor editorial changes as suggested per working group
comments
There were also some extensions to the PCIM. The most
important of these were to extend the decision process to
allow rule nesting and rule-group interaction, and to support
the concept of nested rules and sub-rules.
Objectives of this draft.
The specific goals of this draft is to extend the generic notion
of policy, as expressed in the PCIM, to better represent the
needs of DiffServ and IntServ. This takes several forms:
- to refine the concepts of repositories, conditions and
actions for expressing QoS policy rules
- to ensure that a simple way is available to build
hierarchical namespaces for administration and scoping
of policy rules
- to build a framework of classes that help ensure that
devices of different capabilities interpret QoS
mechanisms the same way
- to provide for rule-specific as well as reusable policy
rules, conditions and actions; and to be able to define at a
high-, a device-independent, or a device-dependent level,
DiffServ and IntServ policies.
This draft can�t do the last two bullets by itself. But it can be
one of the tools that, combined with other work, can
accomplish these together.
Policy Layers.
As stated previously, this draft is one of several that work
together to define a continuum of policies. A chart was
displayed that provided three different abstractions. The
highest was administrator-defined. This level is device-,
technology- (e.g., DiffServ) and mechanism- (e.g., WFQ)
independent. An example is:
IF User is subscribed to Gold Service,
THEN
allow use of NetMeeting and
provide premium data services
The next lower layer is characterized by device- and
mechanism-independent, but technology-specific, policy rules.
These policies translate the higher-level administratively-
defined policy rules to a form that can be more easily
translated to a device. An example is:
IF sourceIPAddress == 172.3.128.0/15,
THEN
mark voice with EF and
mark data with AF
The third layer is characterized by a device-independent,
technology- and mechanism-dependent policy. This type of
policy is used to do the following three types of configuration:
- configure a component so it can be used to condition
forwarded traffic
- configure a component so that it can act on received
traffic directly
- trigger an action based on a network or a system event
(e.g., link failure)
These configuration actions take the form of performing a set
of device-independent actions (e.g., configure a classifier, then
configure a filter and bind it to the classifier, etc.). This draft
serves as the integration point for binding high-level QoS
policies to low-level QoS policies.
The concept of reusable repositories was discussed. This is an
extension of the repository concept that is present in the
PCIM. Repositories in the QoS Policy model serve the
following three purposes:
- containers for reusable objects
- maintenance mechanism for ensuring the integrity and
proper updating of reusable objects
- provide a hierarchical namespace and context for
reusable objects
The repository implementation has been simplified. The
policyRepository class of the PCIM is used, and additional
semantics are provided by subclassing the policyGroup class.
Basically, the policyRepository class is used to define the root
of the policy repository. The qosPolicyDomain class is used to
define the roots of various administrative domains that reside
in the policy repository. Within each qosPolicyDomain, one or
more qosNamedPolicyContainers can be used to define
policies that are specific to a particular group of objects.
Several examples were given. One illustrated the above
process, showing how policy rules could be grouped first by
container, then by domain. Another illustrated the more
granular decision-making process that the QoS Policy Schema
supports. Several examples were also provided of showing
how QoS policy rules could be constructed.
QoS action extensions were then covered. DiffServ actions
include classification, and then the ability to mark, police,
and/or shape to a specified traffic profile. IntServ actions
included controlling RSVP, as well as signaling and install
actions. Note that it is expected that the QoS Device
Information Model will supply the specific parameters that are
controlled and manipulated by these actions. A good analogy
is that the QoS Device Information Model represents the
DiffServ and IntServ mechanisms of the device, while the
QoS Policy Information Model shows how to configure and
manage these mechanisms.
There is one main open issue, which is whether to move the
variables and constants that are defined in this draft up to the
core information model or not. This will be taken to the list.
John will revise this draft within 2-3 weeks.
QoS Policy Schema - John Strassner
File: draft-ietf-policy-qos-schema-00.txt
This draft appears as a 00 draft because it has just moved
from the individual namespace to the working group
namespace. It has had 3 major iterations previously.
It is acknowledged that another revision needs to be made.
First, in separating out concepts that were generic that were
used to build the QoS Policy Information Model, not all of the
generic concepts have been extracted. Second, it needs to be
revised to include a formal ABNF, and to synchronize again
against the core information model (simple) and schema (a
little bit more work).
Status
This draft has received a lot of previous attention. It was the
original source for the concept of policy repositories, and
contributed this and other concepts to the PCIM and Core
Schema documents. This revision has had the following
changes:
- generalization and simplification of the containment
model
- generalization and simplification of the implementation
of reusable object repositories
- qosPolicyRule class removed, now using policyRule
- QoS domains and policyGroups can be arbitrarily nested
- Action classes for DiffServ and IntServ created
- PHB modeling added as separate drafts
- Variable binding definition and pre-defined constants
revised and made more granular
Discussion.
Containment is now based on association classes. This hides
the difference between attachment and reference. The reusable
objects were generalized so that they could reside in any
repository. The model was inverted, so that now multiple
domains can reside in a repository, with multiple containers in
each domain. This is a more flexible and efficient mapping.
The qosPolicyRule class was removed. Instead, the policyRule
class defined in the core model was used, and semantics were
moved into the condition and action subclasses defined in this
draft.
An example was provided that illustrates how a QoS Domain
could be instantiated. It stressed the use of DIT containment,
and the ability to treat policyRule and
qosNamedPolicyContainer objects as siblings. The policyRule
priority attribute, along with the qosPolicyRuleMatchMethod
attribute, were used to fine-tune the decision-making process
that is represented in the QoS domain. A similar example was
provided that illustrates the difference between using
attachment and reference to form a QoS policy rule.
The open action items are to incorporate some additional
minor editorial comments, to finish the ABNF, and to decide
on where variables and constants belong. John will revise this
draft within 2-3 weeks.
PHB Sets and Mapping - John Strassner
Files: draft-ronc-domain-phb-set-specification-00.txt and
draft-ronc-domain-phb-set-ldap-rep-00.txt
We don�t really have time to go into any real detail on these,
please read the drafts and comment. The purpose is to extend
the core and QoS policy information models and associated
schemata by representing a set of PHBs enforced on a QoS
domain. This manages the scheduling and resource allocation
that is shared between the set of PHBs that are enforced
together on a QoS domain.
Device QoS Information Model - Walter Weiss
File: draft-ietf-policy-qos-device-info-model-00.txt
This is a 00 draft, but represents a major restructuring and
refinement of the previous draft. It focuses on creating data
structures for configuring and managing QoS mechanisms that
are "in" a device.
The first slide talks about the same three levels of policy.
Again, there is a continuum of policies that start by being
defined administratively, then get translated to a device- and
mechanism-independent form, and then get translated again
into a device-independent but mechanism-dependent form.
Mechanism-independent policies talk about ports and DSCP
values. Mechanism-dependent policies talk about classifiers,
markers, and other elements that affect the forwarding of
traffic in the data path of a router.
There is an important implication here. One of the problems of
the mechanism-independent approach is that it can�t guarantee
interoperability between different devices. That is, consider a
single policy server. If it controls two different devices that
each have different implementations of the same QoS
mechanism (e.g., a dropper or queue), then these devices will
interpret the policy differently UNLESS there is a common
device information model.
Similarly, mechanism-independent policies do not guarantee
interoperability between policy servers. If you have multiple
policy servers from different vendors, then you have a
different set of problems: each policy server defines its own
mapping to control devices, but you have no assurance that the
policy servers are doing the same thing.
How do we support the different types of mechanisms? Our
approach is to use a class hierarchy. This provides a set of
abstractions that each can model one or more concepts in
detail. This makes the model inherently simpler, more
accurate, and more extensible than building a single
monolithic model that describes everything. The higher
portion of the hierarchy talks about common information, and
as you move down the hierarchy, you refine these higher
concepts to model mechanism-specific or even device-specific
policies. An example from the model that describes droppers
was given, where a superclass represents information that is
both device-independent and generic. Its immediate subclasses
refine this to contain more specific information (RED vs. tail-
drop characteristics). Note that this level is still device-
independent. A further level can be defined, which subclasses
the RED and tail-dropper classes to bind a specific vendor
implementation to them.
Class Associations are used to specify relationships between
QoS mechanisms and services. These take several forms. One
example is the construction of a generic QoS service from
specific technologies, such as DiffServ or 802.1Q. Note that
these technologies are modeled as sub-services that work
together to implement a service. Another example is the
definition of a TCB (traffic conditioning block) service. This
service is made up of various sub-services, such as marking,
classifying, metering, etc. A third example, nextTCBElement,
is used to control the sequencing of various TCB sub-services.
Note that associations are implementation-independent. They
can be mapped to a row pointer if using a MIB, or a DN if
using a directory.
Another idea in the draft is to specify at run-time (or when the
policy needs to be processed or interpreted) the characteristics
of the device that are applicable, so that the best possible
mapping can be done. Sometimes, you run into capacity
problems (e.g., device can only support 50 filters) or specific
technologies (does this device support DSCP marking?) or
specific implementation (does this filter support bit masks and
ranges?). These are called capabilities. Capabilities enable us
to bind policy to device-specific characteristics. Examples
were given that show how capabilities and constraints can be
used to achieve a closer model of how the device is operating
in the real world.
QoS Model.
The QoS Model has two parts - description of QoS services,
and description of mechanisms in the device. QoSService is an
instance of (for example) Gold Service, and its associations
enable specific sub-services (e.g., classifiers and markers) to
be used to provide this service.
Three examples of different types of services were provided.
A DiffServService binds DSCPs to TCBs in order to construct
the DiffServ service. An 802.1P service binds priority values
to TCBs in order to construct the service. Finally, Gold
Service can be conceptualized as an instance of QoSService
that could use services like the ones above to specify a
customized QoS definition. This definition consists in reality
of multiple services that are coordinated together (e.g., EF for
voice, and AF for data).
Q: Don�t see policies that govern admission control
A: This is governed by the TCB components.
Q: No, I mean explicit admission control (controlling
interaction of devices to limit the number of conversations that
can take place
A: Nothing in the model precludes modeling this, but we need
more work in this area
Q: What about modeling voice?
A: We support this, it�s actually similar to the Gold Service
example. You�d create an instance of QoSService
Q: how do we use this to configure devices, and how does it
relate to the core model?
A: the QoS Device info model defines attributes that you can
use to configure mechanisms (e.g., RED droppers). The QoS
Info model provides the structure that encapsulates this
information. It�s up to you if you want to use policies to
control this information or some other means. But the
information is defined in both cases by the Device QoS Info
Model.
Note: this is not a completed model. So, it�s not that we can�t
or don�t want to model certain policies, we just haven�t gotten
there yet.
Hugh - Policy Requirements Document (now 3 drafts)
www.users.uswest.net/~hmahon/ is the common prefix.
draft-ietf-policy-req-02.txt
draft-mahon-policy-mgmt-00.txt
draft-ietf-policy-use-00.txt
Changes in Requirements draft. This was split into 3 drafts in
response to feedback from the community. The first draft
(draft-ietf-policy-req-02.txt) is just the requirements. Draft-
mahon-policy-mgmt-00.txt and draft-mahon-policy-use-00.txt
talk about how policies are managed and use cases,
respectively. Also, tried to remove implementation
information and in general tried to cut down the draft size.
Content Changes.
Discuss situation in which policy would actually be used (e.g.,
why are people interested in policy management). Three
examples are VoIP, protect certain classes of traffic from other
classes of traffic, and to guarantee transfer time.
Usage cases. New usage cases are a variation of Olympic
service in an ISP environment (customers connecting to an
ISP, where the ISP is repsonsible for delivering different
classes of service based on who the customer is). Second
example is Olympic service in an intranet. This is similar to
the first usage case, and both concentrate on how traffic is to
be marked and how traffic is deployed.
Major issues.
Policy information is not the same as a description of service.
Need for rapid notification of changes to policy. Despite the
fact that policy is relatively static, it is a must that policy
information be delivered quickly (e.g., security, fix a broken
link, etc.). The point is that ven though policy doesn�t change
very much, when it does change, it usually needs to be
deployed quickly.
Methods for identifying traffic other than port numbers and IP
addresses is mandatory.
Better, more complete information about the managed
environment needs to be available in a standardized way.
Security section of the document is changed to include
authorization, as opposed to just authentication, as mandatory
requirements.
Next Steps
Can continue to add more information, but is there a specific
direction that people would like the drafts to go? One
suggestion is to describe what need to be done by the
administrator to manage QoS in the environment, and then
describe the requirements to support those activities.
Hugh thinks that the requirements and usage cases can help
guide the next revision of the Policy Framework document in
helping to continue to make the framework more robust and
complete. Yoram adds that one specific requirement that has
not been addressed in the framework are general signaling
requirements.
Topics in this draft are why we�re concerned about scalability,
what types of things we need to think about when build a
policy management system, and what are the implications in
managing the policy management database.
Objectives
Need to manage large numbers of nodes at which policy is
deployed. But the problem is that nodes exist at numerous
locations, across multiple domains (e.g., administrative
domains within a company, etc. as well as different types of
policies, and who can govern/use which policy). In addition,
there is lots of information that needs to be combined to form
a policy, as well as different types of information.
Organization
Need to conside type as well as locality of policies. Using a
hierarchy of policies can significantly simplify the
management domain.
Considerations
Topology can be used to restrict the number of resources,
entities and/or people that need specific entries in the policy
database by using hierarchies of policies and repositories to
distribute the information
Allocation
Need to understand the frequency of access of the repository
and its availability, and then design
Conclusion
Need to create a partitioning of data...
Q: You mentioned partitioning, rules, secondary servers, and
other similar things. This sounds like fundamental concerns
for modeling as well as schema design. Seems like this should
be folded back into the requirements draft (at least). Where do
you see the work going?
A: Good question. Problem is that there is a lot of things to
consider. The question is how much of the discussion as to
why these are requirements should go back into the
requirements draft vs. staying outside.
Comment: Seems like this crosses the info model draft as well
as the framework
Wrapup (Ed)
Two things need to be added. One, the operational aspects of
the device info model and the QoS info model need to be
documented - this seems to belong in the framework doc. The
other is how this info model interacts with CIM (for example).
