Subject: PQIM draft issues

From: "Weiss, Walter" <[email-masked]>
Date: Tue, 10 Oct 2000 21:16:56 -0400

I recently reread the PQIM draft and identified a number of serious
shortcoming (marked with *).

regards,

-Walter

3.1 "The basic mechanism used for expressing containment is placement of the
objects in a data tree."

(1) This strikes me as a very directory specific representation strategy.
This statement seems to contradict a subseqent reference to [PCIM]:

"an association class represents the act of containment itself."

(2) There are a number of references in this section and other sections to
the term repository:

"In general, containment may be direct or indirect. Direct containment means
that when the association or aggregation is instantiated in a repository,
the child will be directly scoped by the container object."

Does this imply that these policies can only be represented in repositories?
Can this model be mapped to a MIB for example?

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?

"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.

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. 

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

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.

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.

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.

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...".

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.

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.

4.4 "A variable may also limit, or constrain, the set of values within a
particular value type that can be matched against it in a condition."

(8*) This is another generalized concept that is not specific to QPIM and
should be moved to PCIM or a PCIM extension.

(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.

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?

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

4.7 "If two or more actions have the same non-zero sequence number, they may
be performed in any order, but they must all be performed at the appropriate
place in the overall action sequence."

(12) I did not understand what was meant in the text following "but".

4.7.1

(13) I found numerous references to qpOutOfProfileAction. However, there was
no mention of an in-profile action.

(14) Example 2 needs to be explained in more detail. I was not able to
figure out from this spec how you would explicitly model that example in an
actual policy.

(15*) How do I assign traffic to a particular queue or scheduling strategy?
If there is a proposed strategy, it needs to be discussed in detail so that
interoperable implementations of this model can be constructed by other
vendors.

(16) It is important to keep in mind that there will be more forwarding
actions beyond the QoS ones specified here. For example, NAT, Tunneling, and
stateful firewalling services are all functions that are in the packet
processing engine and that occur in the path between the ingress and egress
ports of a router. Therefore, it is important to be able to define a
sequence of actions with various decision points along the path. It may well
be that this model supports these more complex scenarios, but there was not
enough detail in the section for me to determine with any level of
confidence that this model could be sufficiently extended.

4.7.2 "The basic decision modeled by this class is whether to admit or
reject the RSVP request. The decision can be based on comparison of the
request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can be
used to track the temporal resources allocation of RSVP requests matching
the network condition."

(17) I could not gather from this text whether the semantics allowed me to
specify a policy that limited admission based on the current volume of RSVP
session traffic or the sum of the reservations. However, it is probably
reasonable to support both capabilities.

"Setting preemption priority [RSVP_PREEMP] allows the RSVP node to decide
which of its reservations should be admitted, and when to make room for a
new reservation by preempting an already installed one."

(18*) It would seem to me that preemption is a good example of something I
might want to construct a policy for. Note that this type of policy has
nothing to do with packet arrival (see issue 5 above). For example, I might
want to create a policy that preempts the reservation (flow) that is
consuming (or reserving) the most bandwidth.

"Rule S:
  If <condition> THEN, for all WF and SE style Resv messages, accept RSVP
request requesting less then <64kp/sec> AND make sure that the total number
of admitted active reservations is restricted to <5>."

(19*) This is another case where I consider the conditions and actions to be
arbitrarily mangled to fit it into the model. The way I would have expressed
this is:

  IF (style = WF OR style = SE) AND qpRSVPTrfcProf < 64Kb AND SessionCount <
6 THEN accept reservation

This is far more intuitive than what you have.

4.8.1 "qosPolicyPRTrfcProf class includes the follow properties:
  1. Rate measured in bits/sec.
  2. Normal burst measured in bytes.
  3. Excess burst measured in bytes."

(20*) This is not the only set of parameters for defining a metering
profile. Certainly this is not the one described in the DiffServ specs.

"Rate determines the long-term average transmission rate."

(21) If you can specify the rate and the burst, why don't you have
parameters quantifying "long-term", either as a weight or an interval or
both.

5.3 "This section demonstrates both decision strategies and rule
prioritization."

(22*) This is another section that needs to be considered within the larger
context of PCIM. If this prioritization strategy is only applicable to this
model, then it may be appropriate. However, I am strongly opposed to any
derivations that fundamentally change the operating semantics for policy
processing and that is unique to a particular derived model. This will not
scale. Either get it adopted by PCIM or remove it.

6.1
(23*) I did not understand what PHB sets are or how they are used. Please
clarify this section further.

8.1.3/8.2.2 qpPolicyRuleMatchMethod/qpNamedPolicyRuleMatchMethod
(24*) Notions like First Match and Match All really belong in PCIM. If PCIM
does not work this way, than argue for a change in the PCIM model to support
this. Don't go inventing your own processing rules that are unique to your
model.

---

From: Yoram Ramberg <[email-masked]>
Date: Thu, 12 Oct 2000 00:31:59 -0500

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

>I think you've hit most of the issues that require some work and I 
>appreciate your review as it confirms and strengthen some of our own 
>conclusions about what needs to better the [QPIM] doc.

>3.1 "The basic mechanism used for expressing containment is placement of 
>the objects in a data tree."
>

This has been pointed out by others along with other LDAPisms in the draft. 
Thanx for pointing out the [PCIM] quote. You're right and work is underway 
to correct this in particular and other LDAPisms in general.

>"In general, containment may be direct or indirect. Direct containment 
>means that when the association or aggregation is instantiated in a 
>repository, the child will be directly scoped by the container object."
>
>Does this imply that these policies can only be represented in 
>repositories? Can this model be mapped to a MIB for example?

Darn, I hope not. The quoted text is, indeed, too restrictive. I agree that 
it needs to be rephrased to relax and generalize containment 
conceptualization here and elsewhere in the draft. The intention is to 
allow this model to be mapp-able to MIBs, RDBMS, LDAP and many other 
popular storage models. Note, however, that the concept of repositories can 
be easily modeled in a MIB. The core info model of MIBs lends itself to 
RDBMS mapping in a very straight forward way (IMHO it is a nicer storage 
model than LDAP dirs... Sue me.)

>(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.

>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"
>
>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.

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.

>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."
>
>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.

>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

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?

>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.

>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?

>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.

>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?

>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 
>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.

>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?

>should be moved to PCIM or a PCIM extension.

Yes, it is. See above (you may notice by now that we have some strong 
agreements on some items...)

>(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.

>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?

>4.7 "If two or more actions have the same non-zero sequence number, they 
>may be performed in any order, but they must all be performed at the 
>appropriate place in the overall action sequence."
>

This is a bad sentence. We need to rephrase this.

>4.7.1
>
>(13) I found numerous references to qpOutOfProfileAction. However, there 
>was no mention of an in-profile action.

Correct. This has been addressed in the new version.

>figure out from this spec how you would explicitly model that example in 
>an actual policy.

While some re-editing has been done here, I still think that the example 
can be made more explicit by forming the rules that model the policy stated 
in the free text. I'll raise it with my co-authors.

>(15*) How do I assign traffic to a particular queue or scheduling 
>strategy? If there is a proposed strategy, it needs to be discussed in 
>detail so that interoperable implementations of this model can be 
>constructed by other vendors.

Again, this has been now addressed. In this case, a queue action has been 
added to facilitate such policy.

>actions beyond the QoS ones specified here. For example, NAT, Tunneling, 
>and stateful firewalling services are all functions that are in the packet 
>processing engine and that occur in the path between the ingress and 
>egress ports of a router. Therefore, it is important to be able to define 
>a sequence of actions with various decision points along the path. It may 
>well be that this model supports these more complex scenarios, but there 
>was not enough detail in the section for me to determine with any level of 

We've been looking into these issues. I'm deferring this to Ron as the 
primary action modeler, but I think your point is to be seriously 
considered here.

>specify a policy that limited admission based on the current volume of 
>RSVP session traffic or the sum of the reservations. However, it is 
>probably reasonable to support both capabilities.

Again, deferred to the expert. I tend to agree that one should be able to 
express both types of admission policies.

>nothing to do with packet arrival (see issue 5 above). For example, I 
>might want to create a policy that preempts the reservation (flow) that is 

I think you're requesting a clarification here. Will be addressed.

> request requesting less then <64kp/sec> AND make sure that the total 
> number of admitted active reservations is restricted to <5>."
>
>(19*) This is another case where I consider the conditions and actions to 
>be arbitrarily mangled to fit it into the model. The way I would have 
>expressed this is:
>
>   IF (style = WF OR style = SE) AND qpRSVPTrfcProf < 64Kb AND 
> SessionCount < 6 THEN accept reservation
>

I believe this has been addressed above. It ends up being a matter of taste 
but it is also a modeling decision to accommodate certain profiling and 
metering mechanisms in a uniform way. However, I think that this deserves 
some studying. Will do.

>parameters quantifying "long-term", either as a weight or an interval or both.

Again, (20) and (21) are deferred to Ron.

>(22*) This is another section that needs to be considered within the 
>larger context of PCIM. If this prioritization strategy is only applicable 
>to this model, then it may be appropriate. However, I am strongly opposed 
>to any derivations that fundamentally change the operating semantics for 
>policy processing and that is unique to a particular derived model. This 
>will not scale. Either get it adopted by PCIM or remove it.

I think the very same objection has been discussed above in a wide context.

>clarify this section further.

This section has been removed. The concepts are generalized now and PHBs 
are presented as examples.

>(24*) Notions like First Match and Match All really belong in PCIM. If 
>PCIM does not work this way, than argue for a change in the PCIM model to 
>support this. Don't go inventing your own processing rules that are unique 
>to your model.

See above (and above, and above...)

Thanx again,
*Yoram

---

From: Ron Cohen <[email-masked]>
Date: Sat, 14 Oct 2000 15:04:54 -0700

My remarks inline.

In order to save bandwidth, I've snipped sections I don't have anything to 
add on

[snip]

>ambiguous under some circumstances? Can you think of an example?

The wording should be fixed, but the intention is that the semantics of the 
match is determined by the form of the matched value. An IP address value 
can represent both a single IP address as well as a range of IP addresses. 
When an IP value is matched against a variable, the match is therefore 
either equal to a single IP address or reside within the IP address range.

[snip]

>>and stateful firewalling services are all functions that are in the 
>>packet processing engine and that occur in the path between the ingress 
>>and egress ports of a router. Therefore, it is important to be able to 
>>define a sequence of actions with various decision points along the path. 
>>It may well be that this model supports these more complex scenarios, but 
>>there was not enough detail in the section for me to determine with any 
>>level of confidence that this model could be sufficiently extended.
>

I think it is not a good idea to try to model everything at once within 
QPIM. People are looking at adding actions that cover other areas as MPLS, 
tunneling, etc.

>>request TSPEC or FLOWSPEC to a traffic profile and a meter. A meter can 
>>be used to track the temporal resources allocation of RSVP requests 
>>matching the network condition."
>>
>>(17) I could not gather from this text whether the semantics allowed me 
>>to specify a policy that limited admission based on the current volume of 
I'm not sure what "current volume of RSVP session traffic" means. "sum of 
reservations" as well as control on any single reservation request is 
supported. QPIM does not provide a way to make different decisions based on 
whether the actual rate of flows is smaller that the rate reserved for 
these flows. I don't see why it should.

>>(18*) It would seem to me that preemption is a good example of something 
>>I might want to construct a policy for. Note that this type of policy has 
>>might want to create a policy that preempts the reservation (flow) that 
>>is consuming (or reserving) the most bandwidth.
>

An RSVP PDP (LPDP) needs to arrive at decisions once an RSVP state changes, 
in most cases once a new/update RSVP message arrives. This policy allows 
you to specify the preemption priority that an RSVP state deserves. The 
standard RSVP preemption algorithm is assumed. See RFC 2751.

>>"Rule S:
>>   If <condition> THEN, for all WF and SE style Resv messages, accept 
>> RSVP request requesting less then <64kp/sec> AND make sure that the 
>> total number of admitted active reservations is restricted to <5>."
>>
>I believe this has been addressed above. It ends up being a matter of 
>taste but it is also a modeling decision to accommodate certain profiling 
>and metering mechanisms in a uniform way. However, I think that this 
>deserves some studying. Will do.

RSVP specific parameters were not included in the filter but rather as 
attributes within the action that limit its scope. This is similar to the 
direction (in/out) indication included in the action as well. The reason 
was to allow specifying all actions relevant to a traffic class in a single 
rule. For example, to be able to specify:

If (My ERP application) than
       Accept RSVP reservations requesting CL
       Deny RSVP reservations requesting GS

As well as being able to use share the same filters across provisioning and 
signaling actions.

>Again, (20) and (21) are deferred to Ron.

One can add other traffic-profile as extensions. We chose to include the 
basic traffic profile chosen by the diffserv-MIB (rate and burst), plus 
adding the excess burst that is commonly used in the industry (CIR 
specification for example).

No need to define both time-interval as well as burst and rate, as 
time-interval=burst/rate (up to a unit factor). This is explained in 
diffserv-MIB. We chose not to allow two different ways to represent the 
same traffic profile.

[snip]

Thanks
Ron

---

From: Marcus Brunner <[email-masked]>
Date: Mon, 16 Oct 2000 12:21:37 +0200

Ron, Yoram, Walter,

Do you see the qosPolicyPRTrfcProf as the base class to derive other
traffic profile classes from. Or how do you see the extension?

(Side remark: I'm looking for a base class in order to derive MPLS
(CR-LDP) traffic profiles)

Marcus

-- 

Dr. Marcus Brunner
C&C Research Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.tik.ee.ethz.ch/~brunner

Adenauerplatz 6
D-69115 Heidelberg
Germany

Phone: +49 (0)6221/ 9051129
Fax:   +49 (0)6221/ 9051155

---

From: "Yoram Snir" <[email-masked]>
Date: Mon, 16 Oct 2000 15:12:26 +0200

The qosPolicyTrfcProfile should be a base class if it covers some of the
attributes you are looking for in your target class and the target class
relations with actions and meters are similar.
The coming version of the QPIM, will be available very soon,  which would
include an updated action section should be the base of your decision.

------------------------------------------
Yoram Snir - Manager, Business Development
Cisco Systems
Tel.     1-408-853-4053 (US)
         +972-9-9700085 (Israel)
Mobile   +972-54-970085
------------------------------------------

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Marcus Brunner
> Sent: Monday, October 16, 2000 12:22 PM
> To: Ron Cohen; Yoram Ramberg; Weiss, Walter
> Cc: [email-masked]
> Subject: Re: PQIM draft issues
>
>
>
> Ron, Yoram, Walter,
>