Subject: Draft Minutes of Policy Framework WG, Pittsburgh IETF

From: [email-masked]
Date: Wed, 16 Aug 2000 14:18:09 -0400

Dear Policy Enthusiasts:

The following minutes were jointly contributed by Andrea Westerinen and John
Strassner.  Thanks to both of them for taking such comprehensive notes!  Please
send your comments/corrections to us by Friday, 8/18, so these minutes can be
submitted for inclusion in the proceedings.  Keep in mind that these are
***draft*** minutes until then.

I would just like to pull out a few highlights for those of you who want the
short version: (any inaccuracies or misrepresentations in this summary are my
fault.  I would be happy to entertain changes/additions. Ed E.)

<begin summary version>

Summary/highlights:

(Note:  This is a reformat of the Wrap-up charts I put up at the end of the
meetings in Pittsburgh.)

1.  Except for a few editorial changes, there was consensus that the -07 PCIM
draft is ready to go forward to proposed standard.  Bob Moore is editing a -08
version as we speak, which will be out shortly.

[Note: at an authors meeting later in the week, we also got some additional
comments from the Security Area for the Security Considerations section, which
we will also include in the draft that we send forward. We are considering this
input as if it was received during the IETF last call period, since we believe
it is important to the IESG's approval of the document.]

2.  The PCLS draft will be revised again to address versioning questions, and
input from the LDAP community regarding security aspects, so that conflict is
avoided with the ldap standards direction.

3.  The polterm draft will continue forward with the intention of becoming an
fyi rfc.  Expect further discussion on all the working group mailing lists
whicha are dealing with policy.

4.  The QOS Policy Info Model will be revised as a result of implementation
experience.  Now is the time to get your comments in. The comment period will
extend through the end of August, after which a new revision is expected.  The
authors will be looking to advance the document at that time, so don't wait
until then to influence the content!

5.  There are questions about the QOS Device Info Model draft: (need discussion
on the mailing list)

    -best way to do filter characterization
    -how to position relative to pib, mib and diffserv conceptual model
    -relationship to service elements, capabilities, and to qos policy draft and
other documents

    need discussion on the list

6.  MPLS, VPN and SLS:  There is definite interest in the MPLS policy and
related work being done in the policy framework working group.  Questions remain
(need discussion and proposals on the mailing list:

    -reusability of the classification mechanisms in the qos model
    -how to structure the work into the various working groups, and to order the
work
    -levels of abstraction, instance level control, roles, trunk types, and
signaling:
     how to model, and what is in the realm of policy

<End Summary Version>

<Begin Detailed Version>

Policy Framework WG, Day One
Monday, July 31
Minutes recorded by Andrea Westerinen and John Strassner

Agenda Bash
-----------

Proposed agenda passed without comment.

Bob Moore, Policy Core Information Model
draft-ietf-policy-core-info-model-07.txt
----------------------------------------

The previous version (-06) was published in May 2000. It
passed both working group and IETF last calls, and was
submitted to the IESG for review. Harald Alvestrand did an
extensive review and had comments. The current version (-07)
is a response to many of Harald's issues.

The most significant change was naming, especially CIM's
naming conventions. The previous version made CIM naming a
central part of the draft. However, the policy classes
really was independent of these issues. The document now
covers all of the naming required for the structure of
policies, and a new appendix was introduced to contain
naming rules specifically for use by a CIM object manager.
This strengthens the draft, in that now we have naming
rules for a truly independent policy structure, plus
additional naming rules for interoperability with a CIM
model. It simplifies naming, and also discusses how
naming is used when communicating with a native CIM
implementation.

Other changes:

  1. 2 associations removed - PolicyConditionSubject and
     PolicyConditionTarget. This is because they are Not
     needed for the current wave of PCIM applications and
     extensions, and because there is not yet a clear
     understanding of "subjects" and "targets". Thus,
     they were removed pending further clarification.

  2.  Abstract class ManagedElement was introduced at the
      top of the object hierarchy. If policies are indeed
      applicable to anything, we likely need associations
      that plug into the highest level of the hierarchy
      (e.g., subject and target). This also had the effect
      of raising some properties higher in the inheritance
      hierarchy, but no content was changed

  3.  Associations in model - Semantic overlaps existed
      between associations in the model and with some
      existing associations in CIM. Thus, the existing
      associations in policy were recast either as
      subclasses of existing CIM associations, or as
      subclasses of new abstract associations defined in
      PCIM. Again, none of the policy classes changed
      their semantics, but this enables us to exploit
      inheritance in the associations that we defined.

Bert suggested and Bob agreed ...  These changes are
editorial in nature. Bert continued: Do people agree? If
not just editorial comments, then we need another last call

Ed:  Is another last call needed?
Silence is taken as acceptance

Yoram Ramberg suggested that we relax the text in PCIM that
restricted grouping policyGroups and policyRules in
policyGroups, based on implementation experience. We agreed
that we would do this as an editorial change.
Bert:  Can be removed in editing for final submission

From the wrapup on the first day:  The working group is
satisfied that the -07 PCIM draft is ready to go forward to
proposed standard, including the feedback from the IESG
review and editorial changes.

Bob Moore, Status of Policy Core LDAP Schema
draft-ietf-policy-core-schema-07.txt
--------------------------------------------

The current version has also moved to an -07 revision, but
it got there by a different path. The -06 was published in
November 1999 and then work was held pending PCIM
finalization. This is because it is a mapping of the Core
Info Model, and we needed stability in PCIM before we
continued to edit PCLS. The new -07 version was published
7/14/2000.

The main change was that in parallel with the IETF work, the
DMTF was also performing active work on mapping CIM to an
LDAP implementation. Recall that CIM consists of a layered
set of models. The DMTF published both a generic mapping
guidelines document as well as 2 mapping documents for the
Core and Physical models. All of these documents are still
evolving and the mapping continues. The DMTF documents
available on the DMTF site at:

  http://www.dmtf.org/spec/denh.html

Our mapping was revised slightly to include this work.
Specifically, there are now a set of real LDAP classes from
which to subclass the Policy classes. The high-level CIM
classes are registered with OIDs from the DMTF Enterprise
subtree. PCLS pre-dates this DMTF mapping, and uses IETF
OIDs for its specific classes.

Mapping of associations. The DMTF recommends three ways for
mapping CIM associations:

  - DN pointers in aux classes (attach a reference to a
    structural class)
  - Separate classes representing the associations
  - Implicit via DIT containment

PCLS uses DN pointers in a structural class and DIT
containment to map associations.

CIM naming is mentioned in PCIM - In appendix in PCIM.
However, there are the same set of issues in PCLS as there
were in PCIM. These will be fixed in a similar manner.

There are two different ways to produce an LDAP
implementation. If you go from PCIM to PCLS directly, then
you can take the policy content and map to a naming scheme
that makes sense for a directory. On the other hand, if you
have an actual CIM implementation, you do NOT want to use
any arbitrary naming scheme, you NEED to use CIM naming.
This is described in Appendix A of the PCIM. Furthermore, if
you want interoperability between native CIM and native
LDAP, then you need to map CIM names into the directory.
So, each LDAP class has an attribute called orderedCimKeys,
which represents CIM naming flattened into a directory
string. Note that this can be left out if the implementation
is not in a CIM environment.

With respect to the directory naming that is defined in
PCLS, we use cn (common name) for x.500 style naming, along
with class-specific naming attributes (e.g., policyGroupName
to name a policyGroup entry). We don't mandate the use of
one or the other, as there is no consensus as to which
attribute to use in directory implementations. All we can do
is provide the tools. ;-)

We also define DIT structure and content rules for naming
via any of these approaches.

John Strassner:  Another addition is needed, which is to
prefix each of the classes and attributes with a string to
protect the schema against version changes

Mark Wahl:  Noticed that the DMTF mapping prefix used is
"cim23" - Does this go through a last call similar to the
IETF?  Should it before we use it?

John:  Work in the IETF mapping was taken up by a dedicated
sub-team in the DMTF, and expanded and clarified.  Close to
being finished in the DMTF and then will be brought back to
the IETF for further discussion. This is an official
document and can be properly referenced.

Ed:  We could have a single ID in the IETF with pointers.
Or, just have normative references in the pertinent IDs.

Mark Wahl:  We are reviewing a mapping based on the DMTF
guidelines.  What if IETF comments indicate that a change is
needed to the mappings or guidelines?

Ed:  Number of team members overlap groups.  Expect these
same folks to take this feedback back to the DMTF and affect
change.

Bob:  Guidelines document is categorized as "living" and
subject to evolution.  The mappings that already exist,
those are done.  If we determine that they could have been
done in a better way, then they would need a different
label. Can we rely on them as unchanging, but can not rely
on them always being the best thinking.

Keith McCloghrie:  Do we really want the cim23 numbering in
the class names?   What happens when you get to cim24?

Bob:  The answer is that we want "a" version in the name so
that we can indicate different versions.  Should the
labeling be "23", "24" or some other labeling?

Ed:  Nothing to prevent us from changing the name of a class
and creating the right LDAP basis for the policy classes.

John: The current view of the subteam is to in fact change
the prefix from "cimXY" to something else, because "cimXY"
has semantics that tie us to a specific CIM version, which
is undesirable.

Mark Wahl:  Mapping document includes text on discovering
the schema and authenticating it. Should this be in one
document?  Or separate out applicability? Example - Kerberos
but not digest. However, LDAP says that can use digest.
Maybe an applicability document on how policy uses the
directory may be valuable.

Bob:  Ed and Russ worked on security considerations.
Ed:  Tried to capture the best knowledge on how to use the
directory.
John:  LDAP's Mandatory To Implement is digest.  This
conflicts.  Need to separate guidelines from security.

Mark agreed to help get this corrected.

Bob:  Next draft should not be too far in the future.

From the wrapup on the first day: PCLS will be revised once
more to address versioning and the authors will work with
Mark Wahl on applicability of current ldap direction on
security, to avoid conflict.

Andrea Westerinen, Policy Terminology Status
--------------------------------------------
draft-ietf-policy-terminology-00.txt

There have been several versions of policy terms that have
been floating in the IETF. At the last IETF, it was decided
that the Policy Framework working group would own this
draft.

Our goal was to document the terms that exist and to point
out conflicts, as opposed to create new terms or creatively
re-arranging terms. One example is the term "roles". It is
currently defined differently in SNMPConf than it is in
Policy, DiffServ, and RAP. Our job is to identify such
conflicts and help bring the dissenting working groups to a
consensus if possible.

In building this new draft, our approach was to start with
all existing terms that we could find from applicable
drafts. We organized the document based on RFC 2828 (the
Internet Security Glossary). All terms and their acronyms
listed in alphabetical order. Each term is characterized as
P (policy related), M (mechanism related, as in COPS, PIB,
or DEN), or A (area of use for policy (for example,
DiffServ).

Further work will consist of minor updates and clarification
to existing terms. We want to add a table to cross-reference
the terms with the drafts that use those terms. We also need
to resolve two conflicting terms: "role" (SNMPConf
definition conflicts with the definition used in Policy,
RAP, and DiffServ) and "role-combination" (slight confusion
between how the PIB uses role-combination and how it is used
in Policy) - the problem is that the PIB uses
role-combinations in a more specific manner than Policy
does.

How does this affect existing documents? All affected
documents are either drafts or at Proposed Standard, so both
have to be revised in any case before they proceed. So
hopefully the use of terms defined in this document will
spread over more and more RFCs.

We want to have a master table that cross-references the
terms and where they are used in which drafts. However,
there is a problem with having the cross-referencing table
in an RFC. So one solution is to include it while it is
progressing towards RFC status, and then remove the table
when it reaches standards process. This is the approach that
we will use.

Andrea needs to send the info on the glossary to all
pertinent mail lists.

From the wrapup on the first day: direction is as an fyi
rfc, that is referenced by stds track docs.  Will put email
on the other affected mailing lists for expanded discussion.

Yoram Snir, Status of QoS Policy Information Model & Schema
draft-ietf-policy-qos-info-model-01.txt
-----------------------------------------------------------

This version is the same as the version posted before
Adelaide, and was previously revised under individual
submissions before it became a working group draft. There
have been no major comments received since Adelaide.

The major changes in this version from the previous version
inclue:

  - Extensions of variables and values
  - Rule decision strategy
  - Extended actions
  - PolicyRule associations (SDNs to association classes)
  - Object repository
  - Other cosmetic changes

Everything that was done in the QoSPIM was as an extension
to the PCIM. We identified many concepts, such as reusable
objects and policy repositories, that eventually moved into
the PCIM. These remain as general concepts to PCIM and are
refined in the QoSPIM to reflect the particular semantics of
QoS, as opposed to generic, policies.

The QoSPIM also explicitly defined policy scope for applying
policies.

Specific policy conditions and actions for Diffserv and
Intserv were developed in this draft. Conditions are defined
as a {variable - operator - value} triplet. Predefined
variables and their binding to acceptable values (e.g., you
can't have an IPAddress value of -3) was defined, as well as
a generic extension mechanism.

A simple QoS policy condition was defined whose variable
specifies the attribute of the flow that should be matched
when evaluating the condition. Predefined variables and
values were included as a class hierarchy, with
corresponding values. This enables a binding to be
established, and also simplifies its representation for many
different types of data models. The binding also includes a
generic mechanism for specifying some simple constraints.

Two simple match strategies were defined - match-first and
match-all. Examples of their use and their differences were
included in the draft. It was noted that the match
strategies should have their semantics defined and
documented in Polterm.

Two different types of QoS actions were specified -
signaling and provisioning. The draft describes how meters,
markers, shapers, and droppers could be implemented. It also
uses the concept of traffic profiles to control the
provisioning of these elements.

The decision strategy is defined per qosPolicyDomain. The
basic difference is that match-first evaluates all
attributes according to priority until it finds one that
matches and then exits. Match-all finds all that match, and
then executes the actions of each matching condition. Note
that these two strategies can be mixed as appropriate.

The QoS Policy Schema also has not received any comments,
but it needs to be held up so as to realign with the new
PCLS that will be issued.

Ed:  Do we have any other implementations that could be
brought to bear?
Yoram Ramberg: We have an implementation.
Dave Durham:  Specifically when mapping to DiffServ
conceptual model or QoS Device Model, that describe meters,
markers, etc. - how are these combined? And used?  What if I
wanted to meter together FTP and xyz?
Yoram:  You would have two rules with the same action.
Meters are actions.

Bob:  Do you need more synchronization changes given the
new PCIM?
Yoram:  Some minor naming changes.
John: Agreed, but these are really editorial in nature.
Marcus Brunner:  We have done similar things in MPLS for
signaling.  You now have RSVP signaling.  Should we bring
these together into a higher level signaling action?
Yoram:  You can certainly share actions but it is hard to
combine things from different policy domains.

Marcus Brunner:  You reuse RSVP signaling in MPLS.  Is this
ok in the model?
Yoram:  Yes
Walter:  A meter has two or three different outputs.  How do
you do this as an action?
Yoram:  A meter is not an action.  A meter is used with an
action.  It is used in association with a traffic profile -
it can be discarded, reshaped, etc.

Yoram: It's frustrating that this draft hasn't progressed in
the absence of comments.
Ed:  Not clear that the group indicates that this is ready
for last call. What are the issues? This is a model that
applies Policy to QoS.   This ties the DiffServ QoS to
policy.
Shai:  Informational or proposed standard?
Ed:  Proposed standard.

Ed: Let's take a straw poll.
(Results of the straw poll indicate that the vast majority
have no opinion.)

Ed:  People who voted to not go to last call - could you put
your issues on the list? People who didn't vote - you might
want to indicate why you didn't vote.

Kathy Dally:  Variables should be part of the Core Schema.
Question in Adelaide as to how this would be done and put
into CIM. What is the status?
John:  In Adelaide, it was suggested that variables, values
and binding be moved to Core or to a separate document. This
was because it was suggested that there was more
applicability of these concepts than just to QoS.  Reason
that this was not done was because there was no clear
consensus on either doing this, or which option to choose.
So, we decided to keep these concepts in the QoSPIM for now
in order to encourage specific implementation experience in
a specific domain before we try to generalize these
concepts.

Ed:  You often classify a packet based on the same criteria
independent of QoS or IPsec. Do we want this generalization?
Feedback indicates that we can't generalize.  What do
any implementation experience indicate?
Lee Rafalow:  I did not raise my hand - pro or con - since I
think that we need more time to think about this.
Joel Halpern:  We are having this discussion in various
other WGs. DiffSErv MIB vs MPLS MIB have different
classifiers. Putting up as a proposed standard - one
particular piece of this problem seems the wrong thing.  We
need to wait on the other WGs.
Bob:  I think that the Core policy is too high conceptually
to target these structures. There might be an intermediate
document if you think about everything that policy can apply
to.

Ed:  Question is really "do we need to wait on this
document?"   Not whether we want to move things to Core.
Keith McCloghrie:  Can we apply this work to what is
happening in MPLS?
Ed:   More discussion on MPLS tomorrow.  We can revisit it
then.
Ron Cohen:  Frustration about this draft.  It has been out
there for more than 6 months.  I think that the right thing
should be to put this on the mail list.
Ed:  We are not making the call here, but it will go to the
mail list.
John:  Authors are requesting specific reasons on the mail
list.
Bert:  Everyone who raised his/her hand that this should not
go to last call - post to the list.

From the wrapup on the first day: it was noted that any
objections over taking this document to working group last
call should be posted to the list in the next 3 weeks.

Policy Framework WG, Day Two
Tuesday, August 1
Minutes recorded by Andrea Westerinen and John Strassner

Agenda Bashing - No change

Andrea Westerinen, QoS Device Info Model
draft-ietf-policy-qos-device-info-model-01.txt
----------------------------------------------

There are a long list of changes from the -00 to the -01
draft. Here are the major ones.

<start changes>

There were no associations in the 00 draft - So much of
the context for using the model was missing.
Associations completely specified in the -01 version
(13 associations not counting superclasses :-).

QoSService capabilities properties removed pending further
discussion. Statistics classes removed pending further
discussion and more stability in the MIBs.
PrecedenceService changed from subclass of DiffServ to peer

ServiceTime class removed since its semantics are in PCIM
(PolicyTimePeriodCondition and the PolicyRuleValidityPeriod
association).

The TCB class and its semantics were removed and replaced
with ConditioningService and its semantics (e.g., the
NextService association, tracking of the TrafficClass
property across all of the conditioning elements, etc.).

Added property (CanRemark boolean) to MarkerService

Removed HeadTailDropper class since it provided no
additional detail beyond the Dropper superclass.
Removed PercentageDropper and moved its functionality to
REDDropperService. Moved the semantics of the FailAction
and SucceedAction properties in MeterService, to a
property on the NextServiceAfterMeter association
(MeterResult).  This conveys individual traffic flows for
(up to) a 3 level meter. Also corrected EWMAMeter to
better align with the conceptual model.

Moved IsIngress from ClassifierService to a property on
the ConditioningServiceOnEndpoint association. This
enables us to identify the first and last conditioining
services for a flow. Removed Status on ClassifierService
and replaced with the HasClassifiedPackets property. This
clarifies semantics for when packets have been classified.
Moved TrafficClass from ClassifierService to a property
on the NextService association to better describe the
flow of traffic through any of the ConditioningServices.
In the model, we make a specific association between this
property and similar properties in each conditioning
service, so one can easily track what is happening on a
flow-by-flow basis.

Documented FilterList and FilterEntry (they were referenced
but not defined in the -00 version). Also, in response to
feedback from IPSP, we defined a new superclass for
FilterEntry, called FilterEntryBase. This enables
technology-specific mechanisms (e.g., DiffServ vs. IPSec)
to define their own filters but use other parts of this
model (e.g., the classifier). Added TrafficClass property
on FilterEntry and tied it to NextService's TrafficClass
property. Removed FilterType property of FilterList since
it did not align with IPsec usage. Finally, added implied
associations of FilterList and FilterEntry to the
ComputerSystem class.

Removed PrecedenceValue property in EFService, as this
needs more clarification. Moved Enabled property on
ForwardingService to ConditioningService. Removed ID
property on ForwardingService - Was "Yet Another Name".
We changed the name of BufferManagerService to BufferPool
since the semantics of this class describe the pool of
buffers and not the service. This meant that the class
inheritance changed and properties were added.

We added FIFO queuing to QueuingService enumeration. We
removed the GiveExcessCapacity property from the
PacketSchedulingService. Finally, we updated the
QueuingService class hierarchy names for consistency.

<end changes>

The salient features of the information model was then
reviewed. Filters were discussed, and the properties of
each class were explained.

Question: Why are filters defined in this model and not
in the other models?
John: They're not in PCIM because not all policies need
the concept of filters. The QoSPIM use of filters is at
a much higher level. The next revision of this draft
will bind the use of filters and other conditioning
elements more tightly to the QoSPIM.

QoSService is used to conceptualize a service as a set
of coordinated sub-services that each need QoS. It
serves as a common base class for defining sub-services
needed to build higher-level QoS (e.g., the infamous
"Gold Service" can be described as a set of sub-services
that each have their own requirements. It therefore
serves to consolidate relationships between different
types of QoS services and the different types of
"ConditioningServices" that each requires.

The subclasses of QoSService enable the administrator's
approach to defining QoS to be maintained. These three
classes enable QoS to be expressed in terms appropriate
to the technology being used - ToS, DiffServ, or 802.1P.

ConditioningService defines how traffic is conditioned
in the data forwarding path of a device. Subclasses of
ConditioningService define the particular type of
traffic conditioning being provided. Five fundamental
types are defined: classification, metering, marking,
dropping, and queuing.

There are two important associations that are defined
that provide additional semantics for these five types
of conditioining services. These are the NextService
and ConditioningServiceOnEndpoint associations. The
NextService association indicates the specific sequence
of ConditioningServices that are used to condition a
specific flow or aggregate. Both one-to-one and
different fan in/fan out relationships are described
through the use of appropriate cardinalities on the
association. It is a special type of Dependency
association, but has an additional key property
required (TrafficClass). This enables a
ConditioningService to forward multiple traffic
flows to the same 'next' Service while maintaining
their traffic 'identity'.

The ConditioningServiceOnEndpoint association
decribes the Ingress/Egress points to a set of
ConditioningServices.

The PacketScheduling class hierarchy is a direct
subclass of ForwardingService, and describes different
scheduling algorithms that are used to service queues.
This is defined in the SchedulerUsed association.

Question: Why is a scheduler not a conditioning
service, because it can also contain a shaper?
Walter: Because we have defined a scheduler strictly
as a dequeuing mechanism. In addition, there are
relationships between each of the conditioning
services, and the conditioning services represent the
ability to condition traffic between each instance
between ingress and egress.

An example of using QoSService and its subclasses and
associations was provided. Basically, higher-level
concepts are represented through instances of the
QoSService class. This can be used to define different
technology-based QoS mechanisms (e.g., DiffServ vs.
802.1P) that will be used to implement the traffic
conditioning required. These relationships are bound
by the QoSSubService aggregation. We then use the
QoSConditioningSubService aggregation to define the
specific conditioning that will be used to implement
that service. In other words, this aggregation
specifies the particular ConditioningService
instances that are required to implement a given
QoSService.

Question - how does this relate to the PIB and MIB,
as well as PCIM and QoSPIM? Are these classes
supposed to go in the policy repository?
Andrea: No, this is an information model and is
independent of the specific type of repository and
access protocol that is being used.

Walter: The policy "I want to limit traffic to 30%"
may be a valid policy, but it doesn't describe how
a policy server is going to use this policy, and it
doesn't guarantee interoperability between policy
servers. You have a policy that is mechanism-
independent, but non-interoperable. Therefore, we
tried to describe mechanism-dependent policies.

John: Does this draft really depend on the MIB and
the PIB? The authors think no, because this is an
information model, and is by definition more
generic than either the MIB or the PIB. Those are
two implementations of a specific type of data
model, and there may be others. The point is that
not all information needs to go into all mappings.
This is why the MIB and the PIB are not strictly
dependent on this model, and do not need to be held up.

Further work to do for the next revision of this draft:

  - Need to add IntServ and signaled QoS
  - Need to add statistics information back in
  - Discussion on the list as to whether we need more
    specific subclassing to indicate common scenarios,
    versus the flexibility of NextService and
    ConditioningServiceOnEndpoint
  - More information on cross dependencies of
    NextServices (for example, a meter dependent on
    queue depth)
  - Tighter alignment with PCIM and QoSPIM
  - Tie classifiers to physical ports
  - Updates based on recent discussions on Diffserv
    related to token bucket meters and other classes
  - Additions to enumerations (e.g., vlan id in Marker)

Ritu Chadha, Policy Info Model for MPLS traffic engineering
draft-chadha-policy-mpls-te-00.txt
-----------------------------------------------------------

Info model based on PCIM
Actions defined to manipulate trunks, LSPs, resource
profiles and the associations between them. This is related
to work from isoyama (lower level of abstractions). Where
they are focused on LSP setup, and mapping to LSPs, this
draft emphasizes CR-LDP. It is also related to the Wright
draft, in that both define Load balancing.

This is an info model for adaptive feedback control.
Performance feedback to PDP - which gets its policies from
repositories and communicates with PEPs. It defines the
concept of traffic trunks, which are aggregations of
traffic flows, placed in LSPs.

The model manipulates abstractions associated with trunks
such as affinity, preemption, priority, etc. Trunks are
associated with the LSPs to which they are mapped, with
backups.

Network resources are attributes associated with a trunk.
Route specification is also associated with a trunk.
LSP "MPLSrealizes" association to the Route that it
implements. Other associations also defined.

No new policy conditions defined over what is in the QoS
Policy Info Model. Reused QosPolicySimpleCondition, but
defined a set of new Policy Actions - MPLSActivateTT,
ModifyTT, DestroyTT, CreateLSP, etc.

Next steps
  - Merge work with other drafts
  - Address naming issues
  - Info on how to fit in with a global policy object
    model, including domains, policy groups, and
    policy repositories
  - LDAP mapping
  - Find a home ;-)

Marcus Brunner, QoS Info Model for MPLS
draft-isoyama-policy-mpls-info-model-00.txt
-------------------------------------------

Motiviation is to provide policy based management of MPLS
networks. High level support and automation of traffic
engineering. Followed Wright. Requirements similar to
other authors.

Objects and associations are labels which pass through the
network. Traffic profiles, resource classes, explicit
routes. Also defined label lifecycle - setup, update, and
release LSPs.

Associate traffic with LSP. There is signaling control of
CR-LDP. This draft models the modification of the
signaling parameter, and issues notification and release.
It contains fewer actions than other drafts.

Summary - The draft covers:

  - Lifecycle of LSPs
  - Mapping of traffic to LSP
  - Signaling control
  - QoS and MPLS
  - Fulfills requirements of Wright
  - Is simple and extensible
  - No backup LSP, no bidirectional trunk, no trunk
    signaling
  - Concept of FEC vs traffic trunk (from Ritu's draft)
  - 4 actions vs 7 actions (in Ritu's draft)

Joel Halpern:  I understand the space that we are working
in and understand some of this as policy.  The question is
how you map traffic (TT, ATM VCs, etc.).  This is a policy
level question much as we talk about giving service to
customers.  We put in indirection.  We talk about
assigning roles to represent properties - and assign
policy based on roles.  Is there an assumption about trunks
with roles or something equivalent?  It seems that there is
no decomposition or indirection but explicitly routed
trunks.
This is at an instance level and not an abstracted level.
Are we distorting our tools to work at the instance level
versus the abstracted one?
Marcus:  We are trying to model the network.  It would be
easy to have policies "all LSPs which belong to ResClass 1"
then do some action.

Joel Halpern:  Should this be where we start versus talking
at the low level right away?
Marcus:  We have this problem now.  Why should we talk about
high or low level?
Shai Herzog:  I agree with Joel.  We are jumping the gun
into the specifics of the mechanics of how to implement
policy inside an MPLS network.  What we haven't done is stay
at the policy level - what are the requirements of policy in
an MPLS network? What do you apply policy to?  I agree that
it is premature to build the low level building blocks.

Ritu:  We need to do more work with roles.  This is missing
in the drafts.  We have the concept of resource classes,
affinities, etc. This needs more work.
Joel Halpern:  Some of this belongs in policy and some in a
network information model.

Steven Wright - 3 drafts
draft -wright-mpls-*
------------------------

Started discussion of MPLS policy mgmt to gauge WG interest
Goal was to match controls, concepts in MPLS with policy.
Focus of work transferred to wright-mpls-te-policy and
cops-mpls.

Te-policy - Followup on previous, traffic engineering in
policy context
draft-wright-mpls-te-policy-00.txt

Example of policy-based management approach to TE using MPLS
Range of potential polices related to load balancing
Guide for producing a PIB

Assumes existing LSPs (no setup, LSPs must exist already)
Load-balancing - From traffic engineering WG
Influence TE guys to use policy for optimization
Time or network state dependent, offline or online,
centralized or distributed, prescriptive or descriptive

Load-distribution - Address comments from TE WG for
broader discussion

draft-wright-load-distribution-00.txt
Presented in TE WG. This contains mechanisms that affect
load distribution.

3 drafts targeted at te wg and for PIB guidance

COPS draft is draft-franr-mpls-cops-00.txt
Policy WG - Should be aware of the policy application to
MPLS/TE and possibly coordinate policy efforts in other
functional areas. TE focused on operations, not developing
PIBs. Would expect MPLS guys to define a PIB

IP VPN PIM - Mahadevan Iyer
draft-iyer-policy-ipvpn-info-model-00.txt
-----------------------------------------

Would like to understand how to move forward and overlap
with work in other groups

Motivation - Working with carriers who turn in requests
for IP VPNs, Secure LANs, flexible address spaces, better
mgmt of pipes, Security for traffic on the pipe, etc.
This in turn provides requirements map to firewalls, QoS,
NAT, IPsec. The mapping is one of how to enforce policy.

Found that when we create multi-functional box - need to
consolidate info models from various domains. This was
driven externally, through finding vendors with policy
enforcers and servers. This in turn requires us to have
a common understanding of info model to integrate.

Key aspects - Policy model/tags to mask the types and
specifics of conditions. Example:  Network condition that
deals with layer2 tag. IP VPN policy sets in a domain
translates as a set of policies that should be applied to
a specific class of traffic. For enforcement, signaling
and admin (in IPVPMPolicyDomain).

IPVPN Condition types (common blocks) - reused policy
conditions, but applied to network, users, application,
enforcer, time

IP VPN Action types include FW, NAT, QoS, Security.
Each implementation/domain brings in its own action types
Draft does not redefine attributes of action class for
these attributes

Goal of this draft is to be a policy umbrella

Issues

  - Outside the current scope of the group
  - Individual action models are not ready
  - Going forward, need to decide on whether a
    consolidated policy model belongs here
  - What do we need to add/drop? Are the levels of
    definition in action models correct?

Want to work on refining the draft, and request specific
comments on structure and deficiencies. This could be an
individual draft, but brings to my mind the purpose of
the Policy Framework WG. It is not so much an exact
implementation, but rather provides a policy umbrella
to plug into

Ed:  Would like to come back to question of what this
group should be concentrating on now and in the future.

SLS - Yves T'joens
Draft-tequila-diffserv-sls-00.txt
---------------------------------

Submitted to diffserv and redirected to operational area.
ADs thought that it fit better in Policy FW.

Template for SLS suitable for negotiation at two levels:
customer-provider and provider-provider boundary. Early
idea on requirements on the negotiation protocol.

Is there a home for this at the IETF?  If not, need BOF
in San Diego

Assume a Customer Premise Network and two ISPs. SLSes are
fed to the system and then translated to specific
policies and fed to PEPs.

So why is this needed?  In order to allow automated and
dynamic negotiation of SLSes. At customer premise/ISP
boundary and IPS/ISP boundary, this enables the design
of bandwidth broker functionality (regardless of whether
centralized or distributed, and is applicable to both
multivendor and multidomain problems.

SLS - Scope (ingress/egress), flow, traffic conformance
testing, and excess treatment. At network level -
performance guarantees, quantitative and qualitative
service schedule

Virutal leased line, minimum rate guarantee with allowed
excess, qualitative Olympic, funnel service (Services as
examples).

Interest in BOF?  Objectives to specify info and semantics
List requirements on negotiation protocol
EC IST projects - TEQUILA, Internet 2 Qbone, DMTF SLA WG
[email-masked]
www.ist-tequila.org

General wrapup on the MPLS and SLS drafts.

Ed:  Where do we go from here? Are there guidelines that we
should be using? We need a common principle.

John:  Ed and I reviewed the drafts and believe that MPLS is
very important. However, in the info model that we have,
MPLS would be defined as a Service.  But, this basic concept
has not yet been modeled in any of the drafts.  In other
words, we are trying to control MPLS without defining the
underlying application.  We need policy and infrastructure
that controls the application of the MPLS service and the
implementation of MPLS mechanisms.

With respect to the SLS draft, I am puzzled why this is
not in DiffServ. The SLS draft very quickly needs policy to
determine how bandwidths are distributed - but need
infrastructure on the things being controlled before we
have policy.

Brian Carpenter:  Why these drafts fit in operations and
management seems clear.  But why in policy is unclear.

Bert:  When this got referred to us, we agreed that it was
an operation issue.  I did not have time to read the draft,
but SLS seemed to be based on policy. So, the discussion
was to see if there is a fit, not to mandate one.

The WG needs to consider whether it wants to take on this
work after it finishes the current milestones.  These need
to
be met first.

Mahadevan:  Do you agree or disagree?  I would like to know
where to go with this.  Does this work fit within the scope
of this WG?

Ed:  Not today.  I am not sure if we can decide this today.
There is the concern that John expressed with respect to the
modeling of Services.  We manage devices so that they can
provide services.  I do not think that we should define the
services in this WG.

Lee Rafalow:  There is clear overlap with Iyer's work and
what is going on in IP Security Policy.  But, although we
don't have Services defined, we seem to be continuing work
on MPLS without it.  Now, we may need it.

There are parallels in IPSP and both IPVPN and SLS.  This
group may play a role if we want to wear an architecture
hat.  This is hard but there may be value in it.

Steven Wright: A lot of what we talked about is nice and
useful.  But the part that is absent is how to tie this to
actual users, customers, and business process.  I need to
tie this to business processes or it does not buy me
anything.

Iyer:  This has come from work on a policy enforcer and
policy server. I have avoided implementation details -
down to individual queues - but I could do this.

(From the floor) Is it fair game for the MPLS authors to
merge their documents and submit it to this WG?

Ed:  This is a question to Bert.  Is this allowed given our
scope?

Bert:  I don't hear consensus that this is in our scope in
the future. I hope by that time that we have moved on our
other milestones. Ask the work group about fitting this
into the charter.

Ed:  Who thinks that MPLS work fits in the Policy Framework
charter? Majority agreed.
Bert:  Seems that that authors should get together and
resubmit.

(From the floor):  We need a common document that identifies
policy elements and problems.  What needs to be enforced and
handled in policy infrastructure?  Policy oriented versus
application oriented.

Ed:  There are elements in the current drafts that apply and
should be amplified.  If you look at MPLS, we can identify
something that is policy itself but is really something to
set up traffic. We need to identify what policy should be
enforced and handled.

(From the floor):  Need to set up boundaries between this
work group and others dealing with the protocols.  There are
lots of details and implementation experience.  For example,
MIBs are defined in the individual groups and not in an
overall "SNMP" group.

MPLS Discussion Wrap-up by Ed Ellesson
Are any of the classification mechanisms reusable from QoS?
Which WGs should be involved in this work?
What are the relationships to services and infrastructure
models?
How do roles fit into MPLS?
Where is signaling?
Need to reconcile the drafts
What is the right policy level and what level is linked to
individual instance control?
What is the correct level of abstraction?
What are the requirements?
What are the Policy Framework WG charter updates?

Ed Ellesson
Tivoli Systems
Research Triangle Park, NC
[email-masked]
919-224-2111