Subject: QoS/IPSEC alignment questions

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 6 Dec 2000 13:00:47 -0500

Jean,

1. I think the difference between the condition representations can be
justified.

The IETF QDDIM and IPSP models (and their corresponding DMTF QoS and IPsec
models)are device-level models, i.e., in the PEP.  In these device-level
models, the intent is to create an object model that is reasonably close to
implementation structures and yet independent of any specific
implementation.  Filters are commonly used to determine packet handling and,
therefore, are used in these device-level models.

The QPIM model, on the other hand, is a domain-level model (i.e., in the
PMT, repository and/or PDP).  The approach taken in the current draft is
very general in its capability.  Without discussing the merits of the
"atoms" approach in the QPIM, for a domain-level policy specification this
generality might be seen as very beneficial.  But it's not likely that a
Diffserv PEP or an IKE service are going to have data structures that are
going to sacrifice the efficiency of filters in favor of that generality.

The question, then, comes down to how closely do we want the model and the
application of the model to be to one another.  So, this is not to say that
we shouldn't explore convergence here, it's just that we haven't to date
because of the perceived affinity to implementations at the two different
levels.

I hope this helps.

2. There's another divergence that you didn't mention that I've noticed and
that I'm less comfortable with.  It's in the handling of the rule priorities
as they're aggregated in policy groups.

Specifically, in the soon to be released DMTF IPsec model (and presumably in
Jamie's revision of the IPsec Configuration Policy Model when it's posted)
the IPsecPolicyGroupInPolicyGroup aggregation of groups has a GroupPriority
property that is used to assign absolute priorities to rules within groups
of groups.  The model uses the PolicyRule.RulePriority for the rule and, for
simplicity, we limit a rule to be in a single group.  But since groups can
be in multiple groups, it is the relationship between the groups that assign
the relative priorities of the contained rules to those contained in other
groups.

In QPIM, however, PolicyGroup subclasses are limited to a single parent in
the aggregation hierarchy.  With that limitation in mind, the gpPriority
property has been placed in the gpsPolicyGroup class instead of in the
aggregating relationship.

I believe that we should settle on a single way of prioritizing groups
within groups and that generality would lead to putting that priority into
the PolicyGroupInPolicyGroup subclasses.

There may be other alignment concerns but this is what I've spotted so far.

Lee

----- Original Message -----
From: "Jean Christophe Martin" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 21, 2000 4:57 PM
Subject: QoS/IPSEC alignement questions

>
>
> I'm trying to understand how the QoS drafts are relating to the
> IPSEC drafts , and so far, I have little succes. For example :
>
>
> The IPSEC Policy Model is defining :
>
>  PolicyCondition
>         |
>    SACondition <----FilterofSACondition--->FilterList
>
>
>
> That should map, for the QoS, into :
>
>  PolicyCondition
>         |
>    QoSCondition <---FilterofQosCondition-->FilterList
>
>
> The FilterList is a list of FilterEntryBase that can either be
> QoS specific Filter Entries or plain FilterEntry as defined in
> CIM network model.
>
> However, in draft-ietf-policy-qos-info-model-01.txt, the Condition
> is using a complete different model.
>
> Is there any plan to update the documents : Policy Framework QoS
> Information Model and QoS Policy Schema to use a model like the
> IPSEC model that seems closer to the DMTF model ?
>
> Thanks
>
> JC.

---

From: Ron Cohen <[email-masked]>
Date: Wed, 06 Dec 2000 12:39:00 -0800

Lee,

I fully agree with point 1.

For the second point, in the QPIM 02 draft we explain the reuse of policy 
groups, i.e. we allow having more than one parent for each policy group. We 
have a section that discuss how to use priority in this case. The 
PolicyGroupInPolicyGroup aggregation is defined in PCIM, not in QPIM, 
without the additional priority property. I think that your proposal to 
include the priority in the aggregation is much more elegant. We might 
still do it by defining a new aggregation, or a derived one. Lets talk 
about this in the IETF and find the right solution.

Thanks
Ron