Subject: RE: PQIM draft issues

From: "David Lowndes" <[email-masked]>
Date: Wed, 11 Oct 2000 09:23:30 +0100

Will someone unsubscribe me - please. The automatic system keeps refusing me
and emailing [email-masked]
<mailto:[email-masked]>  several times has resulted in no
action or reply.
 
Thanks
David Lowndes
--

>>>> unsubscribe policy

**** unsubscribe: '"David Lowndes" <[email-masked]>' matches
multiple list members.

**** FAILED.

------------------------------------------------------------------------------------
This message is for the named persons use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privileged is waived or lost by any miss transmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient.  PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all email communications through its network.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.

---

From: "Weiss, Walter" <[email-masked]>
Date: Wed, 18 Oct 2000 13:26:23 -0400

Yoram,
 
My comments follow.
 
regards,
 
-Walter

-----Original Message-----
From: Yoram Ramberg [mailto:[email-masked]]
Sent: Thursday, October 12, 2000 1:32 AM
To: Weiss, Walter; [email-masked]
Subject: Re: PQIM draft issues

Walter,

Thanx for your comments.
See inline for specifics.

Personal note: 
During (and before) the last IETF meeting in Pittsburgh I was quite dismayed
to see that [QPIM] received little attention from potential knowledgeable
reviewers. I had never thought that it had been a perfect or complete
document. I was quite concerned that because of the little review it had
received it would end up coming out as an RFC only to be proven useless for
its shortcomings. I was further dismayed by what appeared to be a
personal/political dispute around the structure and process of the WG, which
prevented (IMO) any constructive review of the WG documents. 
I'm so pleased to have received the enclosed review from Walter, which is
thorough, comprehensive and very constructive. To me this is a major
atmospheric change and it may be a start for a new era in this WG.
I welcome this change and hope that it is really a sign for things to come.
I'm convinced that this kind of cooperative work will result in a better
product and great benefit to the WG as a whole.

*Yoram
 
<walter>
I appreciate the constructive tone. It is certainly my goal that any
standard in the management space is a step forward.
</walter>
 
At 09:16 PM 10/10/00 -0400, Weiss, Walter wrote:

 [Snip] 

3.2.4 "In this approach, a different set of PHBs can be assigned to
different policy containers. This has the effect of modifying the
interpretation of the same PHBs by each policy container."

(3) I just don't understand what this means. If I understand the text, a PHB
can have multiple interpretations within a policy domain. Why would anyone
need this feature?

PHBs as described in the currently posted version of [QPIM] have been
completely removed. Modeling a PHB is now an example in the text. The new
revision contains the means to fully describe a PHB (or a set thereof)
without the need for a dedicated PHB model.

Now, the need to override a PHB specification is required for local (role
context) policy. It is conceivable that a domain wide "PHB" policy would be
inappropriate for a particular location. In fact, we've seen market
requirements: In order for one to allow some flexibility without having to
create a new domain for a very small subset of interfaces within one's
domain.
 
<walter>
Does your last comment imply that the a single policy can vary based on the
role? It seems to imply a proposed change to PCIM rather then QPIM.
</walter>

"The notion of ordering of rules is so essential to the concept of policy
that removing it from the rule also renders the rule less expressive, making
policy modeling a more difficult job."

and 

"These examples show that the modeling of shared rules is inappropriate for
the QPIM" 

(4*) It seems to me that making policy container manage the ordering of
rules is a more flexible solution as it allows policies to be more easily
reused across different policy containers. One could even argue that the
order of containment could be used to specify priorities. However, being
explicit is reasonable as well. In either case, the notion of priority is
not unique to PQIM or to QoS. If there are issues with the existing PCIM
model that are not adequately addressed (omissions or incomplete
explainations), I would think that fixing it there makes more sense then
allowing this variation from one derivation to the next. I did not find
anything in the draft that justified the second statement to my
satisfaction.

It appears to me that you're commenting on a "shortcoming" of [PCIM] here.
Tell me if this is so. As I understand what you're saying, the problem stems
from the lack of rule ordering mechanism in [PCIM]. I tend to agree. I'd
also state a very personal opinion here that ordering of contained object is
probably best done by the relationships between the container and the
contained objects. This is the most flexible way and it is also ubiquitous
in both [PCIM] and [QPIM]. We ([QPIM] and [PCIM] authors) should probably
discuss this.

<walter>
I would agree that this is a shortcoming of PCIM. From a pure modeling
perspective, I would concur with your assertion that the ordering should be
part of the association. However, priorities are represented using the same
strategy, I would suggest, as an implementor, that it is expensive to
traverse all associations looking for the highest priority. It is worth
considering this expense even though it is a mapping issue because it is
potentially expensive for all mappings.
</walter>
  
However, you may also claim that [QPIM] contains several general mechanisms
that are not very QoS related. For example, most of the conditions we
specified (now extended into compound conditions as well) are general policy
constructs. The fact that [PCIM] is post last call at this time prevents us
from proposing any changes to it. We decided to accommodate some general
concept in [QPIM] and use a naming convention that would enable an
implementer to distinguish between what's QoS and what's general. It is
deemed a necessary compromise. Again, I personally think this is a troubling
weakness but I learned to see the bright side -- at least we have this
standard mechanism nonetheless.

<walter>
While I can understand the compromise, I am concerned that other models are
more likely to use PCIM as the baseline rather than using QPIM as a
reference point for their model. As such the deficiencies in PCIM may be
addressed with radically different approaches in other models. If it is too
late for PCIM, then perhaps we should consider starting a PCIM extensions
draft.
</walter>

4.1 "If the rule is enabled and the boolean expression is evaluated to TRUE,
then use the Action list to extract the prescribed treatment for this flow."

(5*) This statement represents the most significant issue I have with this
draft. The notion that a policy describes the processing rules for a packet
is counter-intuitive to me. Here are some reasons why. 

Walter - I'll attempt to address some of your points but I don't want to
defend our proposed solution at all cost. You may have some very good
objections to our modeling of a policy rule. The basic model appears, on its
face, to be a reasonable, familiar concept. It is hard to object to a rule
of the form "If <condition(s)> then <action(s)>", being the computer
programmers that most of us are... The examples you stated below may be used
to substantiate such objections, but the model is still very attractive for
its "user friendly" form. We (WG members) must do an ego-free evaluation of
your objections and see if we want to extend )or replace) this primary
concept so that your points are fully addressed. I hereby request that other
WG members be good enough to contribute some input into these questions.
One thing, though: The form of policy rules is introduced and dictated by
[PCIM]. If this form is to be changed, then more than [QPIM] is at stake
here.
 
<walter>
Two good points. Let me address both. On your first point, I would certainly
not suggest that we should throw away the concept of the conditional
statement. I find "If <condition(s)> then <action(s)>" an extremely useful
concept. However, I would prefer to interpret the conditions and actions
explicitly and consistently using the same attribute semantics that are used
for managing the configuration of systems. So let me suggest the following.
If we consider a policy that wishes to change a bandwidth allocation up to a
certain limit based on current bandwidth comsumption, I would like to use
the conditional expression in the following way:
 
IF (ConsumedBandwidth > ,9*AssignedBandwidth) AND (AssignedBandwidth < 1000)
THEN
   AssignedBandwidth += 100
 
To your second point, in addition to using PCIM's conditional expression,
this uses three elements of the QPIM model that I find very compelling:
Attributes, Relational operators, and Constants. Therefore, I don't see this
approach affecting the PCIM model at all. In fact, I think it leverages the
Attribute/Operator/Constant approach advocated in QPIM far more strongly and
consistently.
</walter>

First, the policy will be translated into a set of configuration rules. For
example, a condition like "if source = 1.2.3.4 then set DSCP to EF" will, in
fact, configure the marker in a router to set the EF DSCP, configure the
classifier to look for packets with a source IP address of 1.2.3.4 and
configures the binding between the classifier and the remarker. What is the
difference between a policy that represents this example the way you propose
vs. a policy that represents this as:

if <TRUE> then 
 set classifier to 1.2.3.4 
 set DSCP to EF 
 bind classifier to DSCP 

I think I understand what you're saying but for this particular example I
see this as a matter of taste. A already stated above that the current form
is clearly attractive to computer programmers for its familiar look'n'feel.
Why. based on this example alone, should we opt for a different form at this
point?
 
<walter>
Hmm. I don't think this is a question of taste, but consistency. I actually
believe that this approach is more to a programmer's taste (at least it is
to me). Let's consider some of the practical conditions that I may now
employ to set up this classifier I described above using the full
conditional semantics:
  IF the address 1.2.3.4 is assigned to a new user THEN ...
  IF 1.2.3.4 is making a phone call THEN ...
  IF GS RSVP request from 1.2.3.4 THEN ...
  IF AF4 is oversubscribed THEN ...
 
Let's also consider the scenario using current QPIM semantics where the only
objective is to change a meter:
IF <TRUE> THEN qpTrfcProf = <new profile>
 
This strikes me as equally unnatural when compared to my original example.
</walter>

Second, what is being described by taking this approach is a script for
processing a packet. The notion of a script that describes packet processing
is certainly not universal to all components desiring to leverage the
benefits of policy. For example, A port failure does not generate a packet
at all. Further, there are many conditions that are caused by the arrival of
a packet but that cannot be explicitly determined as being caused by a
specific packet, for example a topology change (particularly with RIPv1/v2),
or the available capacity for bandwidth allocations RSVP/CR-LDP.

(please bear in mind that I'm threading the fin line at the edge of my
expertise) You may be criticizing the lack of expressive power of the model
here. Let me talk to that. I think that the info model itself does not
dictate a packet processing script approach, although it is certainly a
possible (and useful) interpretation. Suppose you wish to model a rule such
as this: "When AvailableBW becomes greater than 256 Kbps, then reevaluate
link constrains". What you'll have to do (and granted, it is not part of
[QPIM]) is to model the condition "AvailableBW <op> <BWValue>", binding
rules for 'AvailableBW' (possibly this has to do with summing up all the
microflows consumption and all the currently live trunks on a given link and
subtracting it fom the total link capacity ) and the actions required to
reevaluate a link constraints. If you're going to implement a policy based
TE system you'd also have to provide the particular device configuration
mechanisms to accomplish this reevaluation of link constraints (possibly
this has to do with evaluating various link attributes, if exist). Now, all
of this can be done by specifying policy rules in the form "If
<condition(s)> then <action(s)" as dictated by [PCIM]. The "When" condition
is a hint that this is a rule that needs to be applied as a result of an
event, i.e., a trigger, but a port failure, a routing change or a packet
arrival are all events. I hope I'm understanding your point here. Please
correct me if I didn't.
 
<walter>
I am inclined to agree with most of the above comment. Perhaps it may
clarify my comment if I point out that by deriving filters and only filters
from policyCondition, the conditional expression inherently takes the
viewpoint of the packet. The model is further restricted (as I pointed out
previously) by presuming that a single packet is sufficient for determining
all subsequent actions. The reality is that the characteristics of the flow
as well as the overall burden on the egress also greatly influences the
rules that determine the packet's ultimate fate.
 
Futher, what I am suggesting is that by taking the point of view of the
packet, there are many other conditions that are difficult to convey. I
think that policies can be more consistently expressed by using a taking a
different point of view. When I write any program I am immediately dependent
on pre-defined interfaces that allow me to interact with a variety of
sub-systems. These sub-systems can include I/O, memory management, resource
management (files, the volume on speakers, etc.), task/process management,
window manager, etc. There are predefined interfaces that I can use to
manipulate each of the subsystems. I believe we should follow the same model
for managing routers through policy.
 
Now, for a router, we could argue about the details of an interface, such as
what can and cannot be manipulated or whether the interfaces should be based
on attributes or on function calls. However, to argue that a classifier
belongs on one side of a conditional expression and everything else belongs
on the action side does not make any sense to me at all. Just about every
sub-system has things you can check and things you can change. The things
you check are typically used in conditions and the things you change
typically belong in the actions (assignment statements and function calls).
</walter>

Third, I have seen many applications that represent policies precisely as
you describe them, even though, as I mentioned earlier, the way routers are
configured is very different. Why choose a particular type of user interface
as the basis for interoperability.

I think I already addressed this. The fact that many apps represent policies
in this way is probably because this is very convenient and familiar. This
is a good reason, ain't it? The arguments about routers being of a different
species and that they have a different internal model provides a stronger
motivation for constructing such a model, no? 
 
<walter>
From my perspective it is neither convenient nor familiar. It is not
convenient for all the reasons I have mentioned above. It is familiar only
to the extent that it has been suggested in the early policy models. As no
policy models have actually been standardized we still have the freedom to
chose the best approach. I would also argue that the arguement has been made
that it is familiar because existing user interfaces work this way (ie. a
table with classification on one side and course QoS parameters on the
other). All this has done is allowed all existing user interfaces to claim
to be policy enabled. Again, I don't see why we would want to standardize a
user interface. Should we dictate that all user interfaces look the same. Do
existing network management tools that depend on SNMP present MIBs to mibs
to administrators, or do they display graphs, charts, drag & drops, and
pull-downs?
</walter> 

Fourth, the criteria for deriving from condition or action is arbitrary. The
examples associated with my second reason speak to this somewhat. However,
let's consider a packet processing scenario. If a switch is deployed with a
single queue but also supports profile based marking (think Frame Relay),
the environment is one where the first point where packets are distinguished
from one-another is the meter. Hence, for such a system, a reasonable
condition would be: If in-profile then mark Green;

If out-of-profile then mark Red. Now, you could argue that this can be done
simply by configuring the meter and marker. However, that strengthens the
arguement for my first point, suggesting that classification (filtering) can
be configured as well.

Yes, you're absolutely right. The DS MIB has a means of addressing that.
This weakness has been remedied in the upcoming version of [QPIM]. I still
don't see this as an argument against the general form of policy rules as
quoted above.

Fifth, creates ambiguity for the interpretation of the condition. A
condition such as: "If IP Source address = 1.2.3.4" can be interpreted two
different ways. One interpretation is "If the packet looks like this". The
other interpretation is, "If there is a classifer configured in the router
that is trapping IP Source Addresses of 1.2.3.4". Now, I admit that the
former interpretation is far more likely than the latter. However, it is not
unreasonable to assume that there could be policies that are conditioned
based on the local router configuration. A good example would be "If the
current bandwidth consumption on a queue is more than 80% of the same
queue's bandwidth allocation then...".

Well, I hope this is also addressed above. ...and again, how is this an
argument against the good, old "If <condition(s) then <action(s)" form?
 
<walter>
Relative to your last to comments, I can only re-iterate that I am not
opposed to conditions and actions. Merely your choices in what constitutes a
condition and an action.
</walter> 

4.2 "The qosPolicySimpleCondition class models individual conditions. This
class refines the basic structure of the basic structure of the
policyCondition class defined in [PCIM] by using the triplet <variable>,
<operator> and <value> to form a condition. ..."

(6*) The subsequent two paragraphs discuss this concept in more detail.
However, I don't see how any of this text belongs in this document. What you
are defining is extended syntax that has applicability beyond your QoS
model. It is not only applicable to the QoS device model but also to other
policy domains. It seems to me that extensions of this type should either go
into [PCIM] or a PCIM extensions draft.

Again, Walter, you're darn right. I did talk to this above when I agreed
that some constructs in [QPIM] are possibly beyond the chartered scope of
the draft... I also mentioned the fact that compromising was called for in
some areas to allow for [QPIM] to be sufficiently expressive. I'd have
little to mourn when several such construct make their way back to [PCIM]
where they belong. The flip side of this argument would be to say that
[PCIM] comes short of providing the expression power needed by many
particular policy info models. I'm sad to agree with you on this.
 
<walter>
So let's start work on a PCIM extensions draft and put all these compelling
concepts in there.
</walter>

4.3 "The QPIM defines a single operator, "match", that models the most
generic relation: that of being equal or belonging to."

(7*) Equal to and belonging to are two very different semantics. One is a
comparative relation while the other is a set relation. I don't think you
should overload these two distinct concepts with a single operator.

Hmmmm... You're disagreeing with a judgement call made here. I'm not too
sentimental about this. Some like it and some don't, but what's your
specific objection to the overloading? Do you think this may become
ambiguous under some circumstances? Can you think of an example? 
 
<walter>
I have no problem with overloading. However, what we are really doing here
(as you have suggested) is that we are constructing a language for
expressing policies. As such, an operator should be explicitly defined
relative to each data type. To say "here is an operator that can be
interpreted either this way or this way" is inherently dangerous. As to a
specific example, masked IP addresses come to mind. For the expression:
A = 1.2.3.128/30
 
If A contains the value 1.2.3.0/24, does = mean membership or comparison? If
it means equal, the result is FALSE. If it means membership, the result is
TRUE.
</walter> 
 
[snip] 
 
 (9) I like the concept of being able to specify constraints for various
data structures (variables). However, I don't like the idea of specifying
these constraints explicitly with attributes in the model. Rather, I believe
that the model should specify constraints as part of attribute definitions.
As an analogy, in the SNMP world, there is SMI that defines attributes
names, data types and constraints (like read-only) for MIBs and SNMP that
only passes the attributes, but implicitly enforces all the constraints for
the attributes by MIB convention.

Ok, good point. This issue has already been addressed. The new version of
[QPIM] defines an association between a variable and its constraints. I hope
this is good enough. 
 
<walter>
It is probably not good enough. The QDIM authors have been discussing this
same issue for some time. It is a fairly difficult concept to convey with
e-mail. So, let's try this by analogy. On issue 7 above, you suggested that
it was perfectly reasonable to use one operator to express two distinct
semantics. I agreed, provided that the semantics was well defined for each
data type. This semantic can be expressed one of two ways. Either it is
expressed implicitly as part of the standard or it is expressed explicitly
through code or attributes that describe the behavior in more detail. Again,
by analogy in object oriented programming languages, the distinction is
between base data types and programmer defined data types. There are no
extra attributes or functions to describe the semantics of relational
operators on Integers. In contrast, if I create a new data type like a
queue, there are no operator semantics defined for this new data type.
Therefore, I must define the operator semantics as part of defining the
operational characteristics of this new data type.
 
Now, on issue 7 above, you suggested (and I agree) that the semantics of
relational operators on standardized variables can be specified in the
standard rather than with additional attributes. I would argue that the
interpretation of an operator on an attribute is a form of a constraint.
Hence other constraints such as read-only can similarly be defined by
convention (like Integer), or with a set of expressive attributes. I would
suggest that for variables (data types) that are not standardized, we define
a set of attributes that allow operator semantics and constraints to be
described. For attributes that are standardized, we use the standard to
express the constraints and operator semantics rather than a bunch of
attributes.
</walter> 

4.4.2 "Following is a table that defines the predefined variable names and
their binding" 

(10) There are references to Application and User that were insufficiently
specified. Does this field refer to Ids in the RSVP header?

You're requesting a clarification and I agree that one is due. Will be
addressed.

(11) All these field definitions should be integrated with the QDIM model. 

Now, [QDIM] is at an earlier stage in its evolution than [QPIM]. The IESG is
not likely to allow [QPIM] to move forward when it contains references to
non-RFC-ed documents. It is necessary to make the two documents fully
compatible but [QPIM] must be self contained so it can be used by
implementers. Are you saying that [QPIM] should be frozen until such time
when [QDIM] is RFC-ed? 
 
<walter>
I am not convinced that QDIM or QPIM are in different stages of evolution. I
could even argue the opposite. However, that is not a debate worth my time
or the list's time. The question of integration depends entirely on the
purpose of QPIM. There have been numerous requests to integrate QDIM and
QPIM such that the operational relationships between the two are clearly
understood. I am currently opposed to multiple definitions of header fields
and qos parameters. I don't believe it buys us anything.
</walter> 
 
[snip]

---

From: Mahadevan Iyer <[email-masked]>
Date: Sun, 29 Oct 2000 22:29:36 -0800 (PST)

Hello Yoram,

> What you're saying is, in fact, the motivation
> behind drafting the core 
> policy information model (PCIM) in the first place 
> (draft-ietf-policy-core-info-model-08.txt, moving
> quickly toward an RFC status)

I think the (PCIM)is appropriately targeted as
providing the basic building blocks for creating
policy applications. The IPVPN policy information
model is one such application. I don't see any issues
here.

> Does this draft do the job of establishing a
> sufficient info model to 
> accomplish the goal set to it? You may argue that it
> doesn't and I grant 
> you this would start (continue?) a lively and heated
> discussion. However, I 
> suggest to you that this is the (large part of the)
> WG charter and this is 

As per discussions that I have had with Ed the charter
leans towards QoS, the exact boundary where it draws
the line w.r.t. the charters of other QoS groups is
unclear to me. But what is clear to me is that there
is a common policy information model problem to be
solved without any takers, whereas there are several
people targeting the QoS configuration issues where
there needs to be just one WG.

> For example, several abstract/base action classes
> that were defined in QPIM 
> can be used by policy systems in areas such as
> traffic engineering, 
> security and possibly ipvpn as well. Another, more
> general example is the 
> introduction of variables/values/constants
> mechanisms in QPIM that can 
> certainly be thought of as general (maybe even
> beyond Policy...).
> Surely your argument has merits and I believe Walter
> (whom you quote in 
> your letter) would agree with you.

I see these aspects in the QoS draft as well, but it
is  quite obviously not the main purpose of the draft.
I would also point out that the people most qualified
to comment on the QoS actions are probably not on this
mailing list. This gets back to my point about the
relationship of this WG to others, let the respective
WGs define the actions for their domains.

> 
> Now, I've taken a quick look at your ipvpn policy
> draft and experienced 
> very little difficulty in identifying duplication of
> efforts due to the 
> above shortcomings of the existing models. For
> example, you had to define 
> IP address type (v4, v6) and variables (although you
> don't call them 
> variables...).

The difference is that the focus of the IPVPN policy
draft is a side issue in the (QPIM). Yes there is some
duplication and the network tag is a good example.
Just to illustrate a point, the network tag mentioned
in the draft isn't necessary a layer 3 specification,
it can be used to represent any piece of  routing
(L3/L3) information available in the packet header.
This is precisely the kind of problem that gets 
solved over and over again in every configuration
model and a common general purpose scheme to represent
"networking information" in the packet(to be used for
policy decisions) has significant value.

> 
> I also must tell you that the use of qpPHBset in the
> ShapingAction class 
> must be revisited due to changes in the latest draft
> (-02) of QPIM. That's 
> unfortunate but unavoidable... There are other such
> examples. In fact, you 
> might wish to take a look at the new QPIM draft and
> see if your action 
> model can be better aligned with QPIM.

True, I have to revisit significant portions of the
IPVPN draft for other reasons as well.

> 
> Also - in the last IETF (Pittsburgh) two new drafts
> were presented to model 
> TE policy. Should you consider merging the efforts
> there? Should you absorb 
> TE policy into ipvpn policy? Note I'm not proposing,
> only asking. You're 
> the experts and I'd like to here your opinions.

I have tried to get in touch with one of them and
explained why, but there hasn't been a whole lot of
response.

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/