Subject: Packet Filtering (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)

From: "Robert Moore" <[email-masked]>
Date: Tue, 6 Feb 2001 14:13:19 -0500

John,

Here are your comments on the "Packet Filtering" section
of my PCIMe note.  My responses are below your comments.

>  2.2.5. Packet Filtering
>
>    For packet filtering done in the context of a
> PolicyCondition, a set of PolicyVariables and
> PolicyValues were defined, corresponding to the
> fields in an IP packet header plus the most common
> Layer 2 frame header fields.  It is expected that policy
> conditions that filter on these header fields will be
> expressed in terms of CompoundPolicyConditions built up
> from SimplePolicyConditions that use these variables and
> values.
> An additional PolicyVariable, PacketDirection, was also
> defined, to indicate whether a packet being filtered is
> traveling inbound or outbound on an interface.
>
>    For packet filtering in other contexts (specifically,
> for the packet classifier filters modeled in QDDIM),
> these variables and values need not be used.  Filter
> classes derived from the CIM FilterEntryBase class
> hierarchy may still be used in these contexts.

<js>
This last sentence is misleading. One can easily define
equivalences between the FilterEntry.MatchConditionType and
the PolicyVariable classes and also between the
FilterEntry.MatchConditionValue and the PolicyValue classes.
The perception that PolicyVariables and PolicyValues somehow
break FilterEntries is just plain wrong.

Perhaps some additional wording to this effect should be
included in PCIMe. The designer can specify a filter using
either FilterEntries and/or {variable, operator, value}
triplets.
</js>

I'm not sure I understand your basic point here, since
I think it's been a given all along that one can construct
equivalent filters using the two technologies.  I thought
that what people were asking us to do was simply to pick
one or the other mechanism as *the* way to represent
packet filtering for all IP-related policy models.

So, people asked us to pick one method or the other, and we
didn't quite do that.  We picked Variables&Values for
filters in Policy Conditions, but left FilterEntries as an
option for non-policy contexts like QDDIM.  This is what
we've proposed for PCIMe to say.

There's also the reality of staging, stability, and
schedules.  Even if PCIMe is going to end up saying that
Policy Conditions SHALL use Variables&Values to represent
packet filters, Lee and Jamie have elected to say that
for March, at least, ICIM is too far down the FilterEntry
path to change at this point.  So we'll have the anomaly
in ICIM of Policy Conditions that do packet filtering
using FilterEntries rather than Variables&Values.

Bottom line:  I think that your last sentence ("The
designer can specify a filter using either FilterEntries
and/or {variable, operator, value} triplets.") is
precisely what people *don't* want PCIMe to say.  Even if
we have to hedge it a little, I think they would rather
have us make a choice one way or the other.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: John Strassner <[email-masked]>
Date: Wed, 07 Feb 2001 11:19:37 -0800

Bob,

first, I didn't think that people were asking us to pick one method. This 
is dictatorial without due cause. If one can map between the two, which you 
agreed could be done in your note, why not let people choose what method is 
most appropriate for their application? I don't think we'll ever be able to 
say that one method is better than the other, because applications will use 
these tools differently.

Furthermore, I don't understand your reasoning. First, you say that people 
want us to pick one method. Then, you say that it is perfectly acceptable 
for us to have one method in PCIMe and another method in ICIM. This 
contradicts your goal of having us pick one.

In addition, I don't understand the point of your message, unless it was to 
underscore that PCIMe didn't do what people wanted. My point was simply 
that the two mechanisms are equivalent and either could be used in a given 
application. Since that is what is happening, why can't we just document that?

John

p.s.: still waiting for responses on my other points...

---

From: "Lee Rafalow" <[email-masked]>
Date: Thu, 8 Feb 2001 09:00:51 -0500

If I remember correctly, the charter on  filters was to either pick one or
explain why there are two (or more) ways to do filters.  When we got
together to discuss this topic, our collective judgment was that there are
reasons for both but that for policy conditions the VOV syntax was
preferable.  (I, personally, have some hesitations that I've outlined in
another posting, but that was the consensus.)  So, the "why" ends up being
guidance about when to use each...which is different from pick as you will.
What gets tagged as MAY, SHOULD or MUST is TBD.

As for IPCM (aka ICIM), Jamie & I discussed whether we should make the
changes and concluded that we'll postpone changes for now.  We're racing to
get it updated to so we can have a technically stable model without the
representation issues clouding the picture and we want to get input from the
IPSP WG on the representation issues as well.  The ultimate consensus needs
to be broader than just the Policy Framework WG.

IHTH.  Cheers.

----- Original Message -----
From: "John Strassner" <[email-masked]>
To: "Robert Moore" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 07, 2001 2:19 PM
Subject: Re: Packet Filtering (Re: Preliminary results from PCIMe technical
meeting, 1/24/01 - 1/26/01)

> p.s.: still waiting for responses on my other points...
snip...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Feb 2001 13:35:41 -0500

Actually, we need to be careful about the phrase "map between the two".
1) One can create variable condition expressions to represent (with 
suitable variables) filters
2) For variable expressions that correspond to filters, one can (usually) 
create the filter.

However, it is certainly not the case that all variable conditions can be 
reasonably expressed in the filter mechanisms that we are looking at.  One 
of the nice things about filters and filter classes is that you can 
describe what set of filters the underlying system can support.  Simply 
describing what set of variables can be tested in expressions does not give 
one the same level of clarity.  Hence, we will probably find ourselves 
needing to write somewhere textual restrictions on the variable expressions 
if we want them to be "mappable" to useable filters.

Yours,
Joel M. Halpern

At 11:19 AM 2/7/01 -0800, John Strassner wrote:

>is dictatorial without due cause. If one can map between the two, which 
>you agreed could be done in your note, why not let people choose what 
>method is most appropriate for their application? I don't think we'll ever 
>be able to say that one method is better than the other, because 
>applications will use these tools differently.
>
>In addition, I don't understand the point of your message, unless it was 
>to underscore that PCIMe didn't do what people wanted. My point was simply

---

From: John Strassner <[email-masked]>
Date: Tue, 13 Feb 2001 11:50:44 -0800

Hi Joel,

Let me see if I understand your point. Looking at the current version of 
QDDIM, I see the following class inheritance:

...
   FilterEntryBase
     FilterEntry
       IP6TupleFilter
       8021Filter
         8021PQFilter

This is relevant because every property in these classes EXCEPT ONE 
(OtherMatchCondition) is defined. There is NO flexibility in this model, 
beyond the simple ability to aggregate different instances of the classes 
together to form a new filter.

In that respect, the QPIM model of using expressions with constraints is a 
LOT more flexible.

I think what you're asking for is limitations on QPIM such that we can be 
assured of a bi-directional mapping. The problem is that QDDIM defines some 
attributes that aren't explicitly defined in QPIM, and vice-versa. I would 
argue that this in and of itself isn't the problem, as such attributes can 
be easily added. What the real problem is that QPIM has introduced several 
notions that are completely lacking in QDDIM:

   - constraining the values of a variable or constant
   - constraining the data types of a variable or constant
   - binding a variable to a value

Is it these things that you are worried about, or something else?

regards,
John

At 01:35 PM 2/9/2001 -0500, Joel M. Halpern wrote:
>describing what set of variables can be tested in expressions does not 
>give one the same level of clarity.  Hence, we will probably find 
>ourselves needing to write somewhere textual restrictions on the variable 
>expressions if we want them to be "mappable" to useable filters.
>
>Yours,
>Joel M. Halpern
>
>>method is most appropriate for their application? I don't think we'll 
>>ever be able to say that one method is better than the other, because 
>>Furthermore, I don't understand your reasoning. First, you say that 
>>people want us to pick one method. Then, you say that it is perfectly 
>>acceptable for us to have one method in PCIMe and another method in ICIM. 
>>This contradicts your goal of having us pick one.
>>
>>to underscore that PCIMe didn't do what people wanted. My point was 
>>simply that the two mechanisms are equivalent and either could be used in 
>>a given application. Since that is what is happening, why can't we just 
>>document that?
>>
>>John
>>