Subject: Final Minutes of Policy Framework WG, San Diego

From: "Ed Ellesson" <[email-masked]>
Date: Sun, 7 Jan 2001 23:33:55 -0500

Summary and Minutes
Policy Framework Working Group Meeting
49th IETF, San Diego
Submitted by Ed Ellesson,  January 7, 2001

Charts submitted separately to [email-masked]

1.   Summary and Action Items, combined from both wg sessions:

1.1   QDDIM: (QOS DiffServ Device Info Model, or QOS Datapath
        Device Info Model)

       -Differences with DiffServ are now resolved

       -Expect name change to the QDDIM draft to reflect generic qos
datapath
        focus for traffic handling and conditioning (ie. not just diffserv),
but qos
       signaling (control plane) will continue to be out of scope for this
       document.

        *  Action:  Bob Moore

       -Schedulers/Queues relationship: Expect co-author consensus to be
        posted on the policy mailing list, in approximately two weeks.

        *  Action:  Walter Weiss

1.2   QPIM:  (QOS Policy Information Model)

        *  Action:  QPIM Authors:

       -Overlap and linkage with QDDIM: Need added text/terminology to
         describe how/why policy objects are approached differently in QPIM,
         than from device level view in QDDIM.

       -Further clarification may be added to describe distinctions among
the
        following functions:  Configuration, policy (operational behavior),
        and state.

       -QPIM continues to be device independent, and mechanism independent.
         Examples are needed that show the abstraction level for
         QPIM, including policy vs. mechanism.

       -A new PCIM extensions draft will be written, which describes generic
         PCIM functions that can be broken out separately from the current
        QPIM draft  (ie. those that are not QOS-specific.  The first phase
of this
        was agreed to be done by the current QPIM authors, themselves.

       -RSVP with diffserv in the same network. Positioning statement needed
         for this situation.

 1.3   ICIM (IPSP Configuration Information Model):

       -The content of this document is owned by the IPSP working group.

       -Our liaison with IPSP (Lee Rafalow) will take a look at similarities
         with QPIM, to determine if there is any reason to recommend further
         harmonizing any of the functionality there with QDDIM or QPIM
        approaches, such as in the area of sequenced actions.

1.4   Packet classification work effort proposed:

       -Small design team will be formed to clearly document the motivations
         for the differing approaches to packet classification across QDDIM,
         QPIM and ICIM. This team will clearly express the design goals of
         each approach.

        *Action:  Volunteers to contact WG chairs

       -Consideration will be given, to converge or not, the four approaches
         to packet classification presented by Bob Moore:

        a) single field generic (filter entry)
        b) variables/operators/values (qpim)
        c) single field specific (ipsp's icim)
        d) multi-field specific (6-tuple)

       -Consideration will be given to documenting this in the separate,
         common document, (see above) which defines general purpose
         mechanisms, or to document why general purpose approaches are
         not appropriate.  These guidelines will be intended to guide
further
         application of our models to other domains.

       -If multiple approaches continue to exist after this design team
         effort, mapping the methods, one to the other, will need to be
        documented.

1.5   Terminology Draft:

       -Expect document rev in a few weeks, then working group Last Call.

        *  Action:  Andrea

1.6   PCLS (Policy Core LDAP Schema):

       -Expect another rev with recent input from mailing list, and a new
        security considerations section.

       *Action:  Ryan Moats, Bob Moore and Ed Ellesson.

       -Expect this document to be ready for last call next month.

1.7   MPLS Policy:

       -Authors will discuss potential homes for this work with wg chairs,
         and the appropriate AD's . The Policy Framework wg charter does
         not cover this.  As a general rule, it is expected that further
application
         of the policy model, beyond qos, will be accomplished within
         technologly-specific working groups, which is where the subject
         matter experts are for those technical domains. This is similar to
         the way mibs/pibs are developed.

        *  Action:  Joel will help by discussing this with the chairs and/or
            AD's for MPLS.

1.8   Charter Milestones:

       The co-chairs will work with Bert on a new set of wg
       charter-milestones, now that our first document (PCIM) has been
       approved for advancement to Proposed Standard.

       *   Action:  Joel and Ed

2.   Detailed Minutes from the Monday, December 11 Session:

       -The order of the minutes is in the order of the agenda topics.

2.1   Intro/Objectives/Milestones:  Joel Halpern:

       -Welcome.  Thanks to the many authors who have worked to get drafts
         for this meeting.

       -However, we are WAY behind schedule.

       -Particular items of note that need to be worked on include:

        a) Framework
        b) Requirements
        c) Use Cases
        d) Terminology

         -The QPIM and QDIM work has made some significant progress.
           Remember:  "A key part of demonstrating that this model can
provide
           end-to-end translation of high-level policy specifications to
device
           configurations is to ensure that the information model and
schemata are
           compatible with and can use the information contained in the
PIB(s)
           and MIB(s) being developed in the Differentiated Services WG. To
           this end, the Policy Framework WG will supply input to the
           development of the PIBs, and include all applicable PIBs and MIBs
           in its development considerations for the framework, information
           model, and schemata." So we need to get QPIM and QDIM aligned
           with each other and with the diffserv work.   QDIM is now much
more
           closely aligned with diffserv than in the past.  Cooperation with
           DiffServ here is a key goal.

          -Similarly, we need to work with the IPSP folks to align the usage
of
           the model there.  We will work to put together a new schedule.
We
           will be reluctant to take on any new work items until the backlog
has
           cleared.  And even then we would like to get this working group
           wrapped up rather than perpetually adding work items.

2.2   Agenda Bash.  No changes for now.  (see later changes to second day's
        agenda)

2.3   QDDIM Issues Presentation:  Bob Moore

       -Bob's charts were also presented in the DiffServ working group, just
         prior to this Policy Framework meeting.  Some of the decisions on
these
         issues are DiffServ's to make, since they are the owners of the
diffserv
         conceptual model, mib, and pib, with which we want to be
consistent.

       -The word "device" was added to the title, to reflect the fact that
         rsvp is no longer  included in the initial focus of this document.
(It
         proved to be too hard to reach closure on both diffserv and rsvp at
the
         same time.)

       -See the charts that Bob presented, for the details of each specific
         issue.

        *   Issue 1: On whether the QDDIM Scheduler class is to be a
subclass
             of Condition:

            -It was decided that Scheduler is, indeed, to be a subclass of
             Condition.

        *   Issue 2: should scheduling disciplines be modeled as
associations
            or as classes?

            -Walter:  It turns out that the DiffServ MIB will not allow one
              approach, but the conceptual model will support it.  The
question  is:
              should we align with the mib or the informal conceptual model?

            -Andrea, Walter, John Strassner and Dave Durham all had opinions
             on which was a better representation, and the vote among them
was
             split.  The decision was to revisit this...see the summary for
the
             resolution.

        *   Issue 3:  How should the tail drop and head drop dropping
             algorithms be represented?

            -The resolution is that the the DiffServ working group will
              loosen the language in the conceptual model to allow for the
dropper
              to be represented either before or after the queue, and the
MIB will
              be tightly defined, as it is now, to include a property to
describe a
              dropper as tail drop or head drop.  This leaves the policy
working
              group clear to document the model as we are doing it now.

        *   Issue 4:  Bob described a taxonomy for the four ways to
represent
             filters, used across multiple documents in our working group.

            -We will take up this topic for discussion in the Wednesday
               session, after the ICIM presentation.

2.4   QPIM Issues Presentation:  Ron Cohen

       -QPIM includes PCIM extensions, including those that are QOS-specific
         (both diffserv and intserv), as well as those that are useful
beyond just
         the QOS discipline.

       -See Ron's charts for a complete list of the changes from the last
        draft of the QPIM document and for the generic and qos-specific
        extensions included there.

       -Generic Extensions to PCIM include the modeling of variables and
         values, which allows for the reuse of values, and for specifying
value
         constraints, and for adding new variables and values without
changing
         the syntax.  See the charts for other extensions.

       -Mapping to the DiffServ MIB is supported.

       -Reuse and "domain-wide" application of QPIM, are the primary drivers
         for organizing the model the way it is currently.

       -Missing Pieces:

        *  a model of the "capabilities" functionality in the PIB

        *  an approach for binding roles to entities

       -Status of QPIM:  The last call on this document forced discussion,
         and the feedback was valuable and incorporated into the current
draft.

2.5   QPIM and QDDIM Compatibility with DiffServ Discussion
         Moderators:  Joel and Ed

       -On QPIM relationship to QDDIM:  This relationship is not formally
         documented in the QPIM document.  John Strassner commented that
          this is a "works with" relationship, rather than a "mapping"
relationship,
          between QPIM and QDDIM.

       -Bob Moore questioned the issue about DSCP markers not having two
         values.  This may need to be clarified.  Also, Bob suggested not
reusing
         the class names from the QDDIM model, in the QPIM model, since that
         could cause confusion.

        Ron accepted this last comment as a valid point.

       -Andrea expressed the opinion that a mapping from QPIM to QDDIM
         is, indeed, required.  We also need to work on clarifying the
         "configuration" vs. "state" issue.

       -It was agreed that a new PCIM extensions document would be created,
        and the relevant parts of QPIM that are generically applicable,
would be
        pulled out and documented separately.  The QPIM authors will
        articipate, as well as volunteers, as they come forward.

       -Lee Rafalow:  Not convinced that the following aspects of QPIM are
         justified: complexity of "atoms" approach, compound conditions, and
         Rules within Rules.

        -Yoram Bernet requested that more attention be given to admission
          control, and to those conditioning services that are in common to
both
          intserv and rsvp.

        -Shai Herzog questioned the level of the policy documented here...is
          it "mechanism" or is it "policy"?

2.6   Monday's Session Wrap-up:

       -See Section 1, above, for the combined summary of both Monday and
        Wednesday sessions

3.  Detailed Minutes from the Wednesday, December 13 Session:

3.1    Intro and News:  Changed the agenda to continue the discussion of
         Queues and Schedulers.  See the sixth item on the agenda (item 3.6,
          below).

3.2   ICIM:  IPSP Policy Model Presentation, Lee Rafalow:

       -Lee suggests that we harmonize among the various document authors on
         appropriate re-usable components for packet classification, across
the
         several documents which address this.

       -See Lee's charts for his review of the IPSP (ICIM) Model.

        *  Basic model structure

        *  Filter-based conditions

        *  Actions, Proposals, and Transforms

       -Discussion Points:

       -Differences between the multiple models that do packet
classification
         were reviewed.  Lee noted the different objectives for each model,
         which motivated the different approaches.  See the charts.

       -Semantics of subclassed condition class, as used in the ipsp's icim
         model, are specific to the ipsec negotiation, which can change from
true
         to false, as more info is received about the security association.
This is a
         different semantic than in the case of QOS.

       -Grouping differences were also discussed.

       -Evaluation order is always determined ahead of time, in IPsec
policy.
         This is always mandatory, but the semantic is different from the
         mandatory semantic in the rest of the policy model. The semantic
is:
         "Try this first, and if it does not work try the next one."

       -Roles: As used in the policy model, roles represent a binding of
         policy to interfaces.  This is not the appropriate semantic for
IPsec, so
         the PolicyRole object was not used.  Instead, the ipsp icim model
uses
         IdentityContexts.

       -The IPSP model is more oriented toward individual device policy,
like
        QDDIM, rather than the domain level, like QPIM, but the IPSP model
        derives from the policy classes, like QPIM does.

       -Discussion:

        *  Strassner:  QPIM differences have to do with the reusability of
            the classes, without binding to specific devices.

        *  Ron Cohen:  Sequenced actions:  There is a similar function in
           QPIM, with a selector, for path messages.  Suggests we take a
look at
           whether we should have the same basic approach in both QPIM and
           IPSP's ICIM

        *  ICIM is a model for the PDP to PEP configuration function; it is
            not a domain level model

        *  Rules are "leaf" objects in the IPSP's ICIM model

3.3  Applying and Linking Policy Discussion  (including the discussion about
       packet classification)

      -Proposed objective:  Harmonize the reusable components across the
       documents which describe how to represent policy for packet
       classification, or clearly document why there are differences, due to
       different design points, different disciplines, etc.  Are the
semantics really
       different?

      -Walter Weiss:  Questions whether the IPSP's ICIM model should be
         handling both levels in one model.  Conditions and Actions, can one
         thing be both?

      -A work effort is proposed:  mapping the different approaches, one to
        the other.

      -Reuse of instances vs. reuse of classes:  this motivates some of the
        differences in QPIM.

      -The usefulness of the QPIM "atoms" approach might drive the QPIM
        method of representing filters, as being different from other
models.  On
        the other hand, maybe convergence of documentation is called for:
        perhaps a single document which describes the generic approaches,
and
        when each is called for:  single field generic (filter entry),
        variables/operators/values (QPIM), single field specific (ICIM),
        multi-field specific (6-tuple).

      -A separate document is proposed to split out the portion of QPIM that
       documents functions, such as packet classification, that can be
re-used
       across multiple disciplines, with an explanation of the different
approaches
       that remain, if they do indeed remain after the attempt to harmonize
them.
       The current authors of the QPIM document will take the lead with this
       effort, but volunteers are encouraged, as well.  We may do this in a
two-       step process, with the current authors taking the first shot at
the generic
       document.

      -The MPLS needs for packet classification should also be taken into
        account, since this is also valuable experience that we can learn
from for
        the purpose of coming up with a generic approach.

       -Example:  "Source Port = 80" appears to be in all the models.

       -There is controversy about this point:  The distinctions between
QPIM
         and QDDIM may be defensible, given the difference in their scope
         (network domain-wide scope, vs. device level scope), but what about
         ICIM (the IPSP's model), which appears to be device-level?   But we
         should be able to articulate the reason that any differences
remain, if we
         can.

       -The topic of policy languages came up.   This is not in our charter,
         but Andrea suggested we might want to look at the language
constructs
         developed by Morris Sloman at Imperial College in London.

       -There was also a question about how SNMP handles differences in
         mibs. Does the SNMP area directorate push back on working groups
         that taken different approaches to the same problem?

        Bert:  Yes, the Ops and Management area pushes back on working
        groups that want to go a different way, but the AD's are not always
        successful in pushing for common approaches.  Despite the best of
        intentions,  there are mibs that provide duplicate function in
different
        ways.

        (BTW:  Wasn't Policy supposed to solve this?)

3.4   PCLS Update: (Ryan Moats and Ed Ellesson)

       -Changes for the -08 version:   Please see Ryan's charts for details.

       -Ryan reviewed the syntax changes from the previous version, as well
        as other changes, including an issue associated with matching rules,
and
        the fact that there will be a -09 version shortly, with new aux
classes,
        and a new security considerations section.

       -Security Considerations section:  Please see Ed's charts for
details.

       -Ed reviewed the security considerations which will be re-written for
         the next version.  The challenge is to make sure that all the
necessary
         security considerations are covered, across the multiple documents
         which complete the standardized "policy package" of documents for
any
         specific discipline.

       -For example, the QOS group of policy documents will include the core
         policy documents, PCIM and PCLS, as well as the QOS-specific
         policy info model (QPIM), and the device level info model for QOS
         (QDDIM), plus whatever the appropriate mapping of these QOS-
         specific models turn out to be,  to an LDAP-accessible directory.

       -The security considerations sections of all these documents taken
         together, have to cover all the appropriate issues for applying QOS
         policy in a real world environment.  The security considerations
section
        of PCLS is part of this total coverage.

       -Please contact Ed if you want to contribute to this section.

3.5   Polterm Harmonization:  Andrea Westerinen

       -See Andrea's charts.

       -The team which created this draft was successful in achieving its
         goal:  to finalize common policy terminology across multiple
working
         groups, without creating new terms.

       -The team resolved the conflicting use of the term Policy Rule in
         different wg's

       -Polterm draft will be revised with changes discussed in presentation
         and sent to last call.

       -References to I-D's will be removed and maintained separately in a
         cross-reference table linked from the policy framework working
group's
         home page.

3.6   Queues and Schedulers:  Walter Weiss

       -See Walter's charts.  This is meant to provide a context for
         continuing the discussion from Monday on this topic.

       -In the current QDDIM model, we have greater flexibility in
         representing queues and schedulers than is currently available in
the
         DiffServ mib with SMIv2.  This was
        accepted as not being a problem, since individual vendors may extend
        the DiffServ mib in proprietary ways, and we want the QDDIM model to
        be able to map to these extensions, if possible, to the extent that
we can
        anticipate them.

       -Brian Carpenter stated that the DiffServ working group's criteria
for
        including something in the DiffServ mib is that it be expressible,
and that
        vendors want it there.  Further, it should be clear that QDDIM does
not
        drive the content of the DiffServ mib.

       -There was considerable discussion of the six charts which Walter
         presented, which described the pro's and con's of different ways of
         representing queues, schedulers, and their relationships to each
other.
         This presentation and discussion further clarified the issues, and
will be
         used to help the QDDIM authors come to an agreement for finalizing
         how that model will represent queues and schedulers and their
         relationships.

3.7   Use of Policy in AAA Architecture:  Cees de Laat

       -See charts from Cees de Laat, at:

        http://www.phys.uu.nl/~wwwfi/aaaarch/sandiego/delaat.htm

       -Cees presented the policy work that is going on in the IRTF, under
         the AAA Architecture working group.

       -This working group has an inter-domain focus and an architectural
         focus, which differentiates it from the work in the policy
framework
        working group, in addition to the fact that they are working on AAA.

3.8   Use of Policy in MPLS:  Ritu Chadha and Marcus Brunner

      -Ritu presented the changes and convergence from the first drafts
which
       dealt with MPLS policy.  The authors re-used a number of the ideas
for
       packet filtering, roles and other functions, from the QDDIM and QPIM
       drafts.

      -Marcus presented the open issues, including the fact that MPLS policy
        has not been accepted as a charter item by any IETF working group,
        including policy framework, mpls, and traffic engineering.

      -Joel committed to talking to the chairs of the mpls and tewg to help
       determine the appropriate home for this work.  It seems appropriate
to
        host this work where the subject matter experts are (mpls or tewg),
with
        help provided from policy liaison people who have experience in
       applying the policy information model.

3.9   Wrap-up:  See Section 1 of these minutes for the combined summary for
         both sessions.

Ed