Subject: Re: group in group in MIB

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 1 May 2001 14:55:56 -0400

Wes, A few comments interspersed below...cheers.

Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Home email: [email-masked]
----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, April 25, 2001 7:16 PM
Subject: group in group in MIB

> Currently the IPSEC-POLICY-MIB doesn't support group-in-group.  The
> original definitions of the tables that Mike Baer and I came up with
> (sitting in a coffee shop) had more tables than the current MIB has
> and implemented group-in-group semantics.  We then dropped the support
> for it when writing the draft as it was decided it was too complex.
> Then, in the Minneapolis meeting it was discussed again (in a wider
> audience) and decided that it should be supported.  So, now I'm
> bringing it to the widest of the audiences (the mailing list) and we
> need to decide what to do and whether or not to support group-in-group
> semantics.
>
> Choices:
>
> 1) Leave it as is, where only rules can be inside groups.  This would
>    deviate from the data model.

The ICPM info model makes this optional.  That is, a rule MUST be aggregated
into one and only one group but a group MAY be aggregated into a 'parent'
group.

>
> 2) Add a new table defining what a group is supposed to contain
>    (1=groups, 2=rules).  And another table containing the groups in a
>    group if the type = 1.
>
> 3) merge the rules-in-groups/groups-in-groups table to be all one
>    table containing merely a list of "names" in side a group, and then
>    add one table like the first in #2 above that defined what a group
>    was supposed to contain.
>
> I'm not really happy with how the data model currently works, and it
> makes this whole decision hard.  As defined a group can contain *only*
> a set of groups *or* a set of rules.  This makes it impossible to
> define a groupA that contains groupB, ruleC, groupD.  ruleC, in this
> case, would have to be put into a group of its own (which is just
> silly).

True (...not the silly part, but the restriction in the ICPM info model).  I
don't
remember exactly where this restriction came from, but it was intended to
simplify. It was done at the time when priority for a rule was expressed in
the rule rather than in the aggregation and we defined our own way to do
priority for groups since there wasn't one in PCIM.  Our methodology has
been adopted in PCIM extensions for both groups and rules.  I suspect that
was part of the complexity, but I also think it had something to do with the
natural groupings, e.g., a group is made up of the phase 1 and phase 2 rules
that are used together. But if, in fact, it doesn't simplify things, then
I'm sure people will be open to changing it.

>
> Also, what is the difference between GroupComponent and PartComponent
> in the current IPsecPolicyGroupInPolicyGroup object?

The GroupComponent and PartComponent are simply the references to the
aggregation pair:  GroupComponent is the parent or containing instance and
PartComponent is the child or contained instance.

> It also makes no sense to me that the data model is defined such that
> groups and rules can even exist with the same priority level.  I don't
> think "two ContainedGroups with the same precedence is undefined" is
> correct.  I think it should be simply illegal.

They haven't been permitted to do so in the IPSP model for some time now and
the PCIM extensions draft currently states that unique priority values are
required in all models.  The case for the non-unique priority values is that
there are things that are simply independent of one another and therefore
need no prioritization, but the requirement for deterministic behavior won
in the end.

>
> To do this properly though, the priority shouldn't be associated with
> the group itself, but with whatever contains it.  IE, I'd like groupA
> (above) to contain 1=groupB, 5=ruleC, 1000=groupD and still have a
> second group optionally reorder them such that groupX contained
> 1=groupB, 20=groupD, 800=ruleC (last two swapped in precedence).

The way PCIM extensions discusses this topic is that the contents of a group
assumes the relative priority of the group in its context.  See section 4.5
of the PCIMe draft,
http://www.ietf.org/internet-drafts/draft-ietf-policy-pcim-ext-01.txt,
which largely reflects the way we've been handling priority in the ICPM
draft for some time now.  We only use the FirstMatching decision strategy.
In the example below, A contains A1 and A2 with the context-specific
priority 1 and 2, respectively, and so on. Priority is high-to-low.

groupA
  |
  +--1--groupA1
  |      |
  |      +----10-----ruleA1a
  |      |
  |      +----15-----ruleA1b
  |      |
  |      +----20-----ruleA1c
  |
  +--2--groupA2
         |
         +-----6-----ruleA2a
         |
         +-----5-----ruleA2b
         |
         +-----4-----ruleA1c

Note that ruleA1c appears in both groups with a different priority assigned
in each context.  The order of evaluation of the above set is: A2a, A2b, A1c
(in its A2 context), A1c (in its A1 context), A1b and then A1a.

IHTH.  Lee

---

From: Wes Hardaker <[email-masked]>
Date: 01 May 2001 13:55:23 -0700

>>>>> On Tue, 1 May 2001 14:55:56 -0400, "Lee Rafalow" <[email-masked]> said:

Lee> Wes, A few comments interspersed below...cheers.

Thanks for responding.

>> deviate from the data model.

Lee> The ICPM info model makes this optional.  That is, a rule MUST be
Lee> aggregated into one and only one group but a group MAY be
Lee> aggregated into a 'parent' group.

Right, but we decided at the Minneapolis meeting that it should be
done anyway as it really isn't that hard to do, its just hard to do
"nicely" and have it align with the data-model.

>> I'm not really happy with how the data model currently works, and
>> it makes this whole decision hard.  As defined a group can contain
>> *only* a set of groups *or* a set of rules.  This makes it
>> impossible to define a groupA that contains groupB, ruleC, groupD.
>> ruleC, in this case, would have to be put into a group of its own
>> (which is just silly).

Lee> True (...not the silly part, but the restriction in the ICPM info
Lee> model).

It seems that every time I find something I don't like, its always our
parent's fault...

Lee> I don't remember exactly where this restriction came from, but it
Lee> was intended to simplify.

IMHO, it failed to do so and made it more complex (implementation and
usage, not necessarily the definition itself). 

Lee> It was done at the time when priority for a rule was expressed in
Lee> the rule rather than in the aggregation and we defined our own
Lee> way to do priority for groups since there wasn't one in PCIM.
Lee> Our methodology has been adopted in PCIM extensions for both
Lee> groups and rules.  I suspect that was part of the complexity, but
Lee> I also think it had something to do with the natural groupings,
Lee> e.g., a group is made up of the phase 1 and phase 2 rules that
Lee> are used together. But if, in fact, it doesn't simplify things,
Lee> then I'm sure people will be open to changing it.

IMHO, I think it would be more simplistic to have a group contain
both, with a (unique) priority assigned to each "member", be it a rule
or a group.

>> in the current IPsecPolicyGroupInPolicyGroup object?

Lee> The GroupComponent and PartComponent are simply the references to
Lee> the aggregation pair: GroupComponent is the parent or containing
Lee> instance and PartComponent is the child or contained instance.

Ahh.  The description clauses are a bit vague in this regard.

>> It also makes no sense to me that the data model is defined such
>> that groups and rules can even exist with the same priority level.
>> I don't think "two ContainedGroups with the same precedence is
>> undefined" is correct.  I think it should be simply illegal.

Lee> They haven't been permitted to do so in the IPSP model for some
Lee> time now and the PCIM extensions draft currently states that
Lee> unique priority values are required in all models.

To quote section 4.5.3 of the -02 data model draft:

   NAME         GroupPriority
   DESCRIPTION  Specifies the rule priority to be set to all nested
                rules.
   SYNTAX       unsigned 16-bit integer
   VALUE        Any value between 1 and 2^16-1 inclusive.  Lower values
                have higher precedence (i.e., 1 is the highest
-------- see here --------------
                precedence).  The merging order of two ContainedGroups
                with the same precedence is undefined.
-------- see here --------------

That text is the reason for my comment.  I guess that text was missed
in the last update?

>> To do this properly though, the priority shouldn't be associated
>> with the group itself, but with whatever contains it.

Lee> The way PCIM extensions discusses this topic is that the contents
Lee> of a group assumes the relative priority of the group in its
Lee> context.

Ahh...  A hierarchical priority scheme, which works as well.  Thanks
for the description.

-- 
Wes Hardaker
NAI Labs
Network Associates