From majordomo@raleigh.ibm.com Mon Oct 2 06:18:32 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04509 for ; Mon, 2 Oct 2000 06:18:31 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA17218; Mon, 2 Oct 2000 06:09:50 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA25916; Mon, 2 Oct 2000 06:09:47 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21402; Mon, 2 Oct 2000 05:32:48 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38034; Mon, 2 Oct 2000 05:32:44 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id FAA28506 for ; Mon, 2 Oct 2000 05:32:43 -0400 Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id FAA21442 for ; Mon, 2 Oct 2000 05:32:41 -0400 Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id e929FGn02391; Mon, 2 Oct 2000 11:15:16 +0200 (MET DST) Received: from alcatel.be ([138.203.253.249]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id C125696C.00327D79; Mon, 2 Oct 2000 11:11:29 +0200 Message-Id: <39D85101.BECAE6DC@alcatel.be> Date: Mon, 02 Oct 2000 11:10:25 +0200 From: "Yves T'Joens" Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en Mime-Version: 1.0 To: diffserv-interest , diffserv@ietf.org, rap@iphighway.com, policy@raleigh.ibm.com Cc: "Yves T'Joens" Subject: SLS interest list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yves T'Joens" Content-Transfer-Encoding: 7bit hi all, Following our presentation at the Pittsburgh IETF meeting of draft-tequila-diffserv-sls-00.txt, we would like to announce that the sls interest mailing list is operational as of now. To subscribe to the list send an email to majordomo@ist-tequila.org with the sentence subscribe sls@ist-tequila.org in the body and nothing in the subject line. This list provides the medium for discussion on Service Level Specification (SLS) template definition and Service Level Specification negotiation protocol requirements. In the coming weeks, an update to the former draft and a framework document will be distributed. Amongst the objectives of launching this list is to gauge interest for the creation of work effort within the IETF on these specific topics. Therefor, also a BoF description and agenda will be discussed on this mailing list to be proposed to the appropriate area directors. http://search.ietf.org/internet-drafts/draft-tequila-diffserv-sls-00.txt archives can be found at http://www.ist-tequila.org/sls.html but there's little there today off course ;-) regards, Yves T'Joens From majordomo@raleigh.ibm.com Tue Oct 10 21:56:20 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17636 for ; Tue, 10 Oct 2000 21:56:19 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA18560; Tue, 10 Oct 2000 21:47:33 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id VAA28636; Tue, 10 Oct 2000 21:47:20 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA30598; Tue, 10 Oct 2000 21:20:55 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48504; Tue, 10 Oct 2000 21:20:51 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id VAA31830 for ; Tue, 10 Oct 2000 21:20:49 -0400 Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id VAA25048 for ; Tue, 10 Oct 2000 21:20:42 -0400 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Oct 2000 21:16:58 -0400 Message-Id: From: "Weiss, Walter" To: policy@raleigh.ibm.com Subject: PQIM draft issues Date: Tue, 10 Oct 2000 21:16:56 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03320.F35D405E" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03320.F35D405E Content-Type: text/plain; charset="iso-8859-1" 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 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 , and 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 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. ------_=_NextPart_001_01C03320.F35D405E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable PQIM draft issues

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 =3D = 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 =3D = 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 =3D WF OR style =3D 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.


 

------_=_NextPart_001_01C03320.F35D405E-- From majordomo@raleigh.ibm.com Wed Oct 11 04:58:05 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04895 for ; Wed, 11 Oct 2000 04:58:04 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA29872; Wed, 11 Oct 2000 04:48:01 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA34894; Wed, 11 Oct 2000 04:47:54 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA48678; Wed, 11 Oct 2000 04:27:57 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42270; Wed, 11 Oct 2000 04:27:52 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA30320 for ; Wed, 11 Oct 2000 04:27:53 -0400 Received: from jupiter.bj.co.uk (jupiter.bj.co.uk [194.72.164.25]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id EAA23950 for ; Wed, 11 Oct 2000 04:27:44 -0400 Received: from 194.72.164.27 by jupiter.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 11 Oct 2000 09:30:37 +0100 X-Server-Uuid: 3da21eb0-4d9e-11d4-96af-00b0d018dd71 Received: by bjex1.bj.co.uk with Internet Mail Service (5.5.2448.0) id <4SSSR8TV>; Wed, 11 Oct 2000 09:23:31 +0100 Message-Id: <608D67882786D211B1070090271E4CB96ECC2F@bjex1.bj.co.uk> From: "David Lowndes" To: policy@raleigh.ibm.com Subject: RE: PQIM draft issues Date: Wed, 11 Oct 2000 09:23:30 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) X-Wss-Id: 15FAFAA711544-01-01 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0335C.8A0AC6C6" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "David Lowndes" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0335C.8A0AC6C6 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Will someone unsubscribe me - please. The automatic system keeps refusing me and emailing majordomo-owner@raleigh.ibm.com several times has resulted in no action or reply. Thanks David Lowndes -- >>>> unsubscribe policy **** unsubscribe: '"David Lowndes" ' 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. ------_=_NextPart_001_01C0335C.8A0AC6C6 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit PQIM draft issues
Will someone unsubscribe me - please. The automatic system keeps refusing me and emailing majordomo-owner@raleigh.ibm.com several times has resulted in no action or reply.
 
Thanks
David Lowndes

--

>>>> unsubscribe policy

**** unsubscribe: '"David Lowndes" <david.lowndes@bj.co.uk>' 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.


------_=_NextPart_001_01C0335C.8A0AC6C6-- From majordomo@raleigh.ibm.com Wed Oct 11 07:05:37 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06363 for ; Wed, 11 Oct 2000 07:05:36 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA26540; Wed, 11 Oct 2000 06:54:45 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA26734; Wed, 11 Oct 2000 06:54:43 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53318; Wed, 11 Oct 2000 06:35:34 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA25662; Wed, 11 Oct 2000 06:35:31 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA27082 for ; Wed, 11 Oct 2000 06:35:32 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA15030 for ; Wed, 11 Oct 2000 06:35:28 -0400 Received: from yramberg-hpxu.cisco.com (telaviv3-dhcp65.cisco.com [144.254.93.193]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id MAA22056; Wed, 11 Oct 2000 12:34:22 +0200 (IST) Message-Id: <4.3.2.7.2.20001011212859.00d95e70@csi-admin1.cisco.com> X-Sender: yramberg@csi-admin1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Oct 2000 00:31:59 -0500 To: "Weiss, Walter" , policy@raleigh.ibm.com From: Yoram Ramberg Subject: Re: PQIM draft issues In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1125257062==_.ALT" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg --=====================_1125257062==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 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 At 09:16 PM 10/10/00 -0400, Weiss, Walter wrote: >I recently reread the PQIM draft and identified a number of serious >shortcoming (marked with *). > >regards, > >-Walter >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." > >(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." 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. >(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? 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.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. >"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. 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." > >(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 then ", 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 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? >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 ", 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 then 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? >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 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 , > and 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. >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? >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. 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. >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? >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". 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. >(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. 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. >(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. 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. >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. Again, deferred to the expert. I tend to agree that one should be able to express both types of admission policies. >"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. I think you're requesting a clarification here. Will be addressed. >"Rule S: > If 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. 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. >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. Again, (20) and (21) are deferred to Ron. >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. I think the very same objection has been discussed above in a wide context. >6.1 >(23*) I did not understand what PHB sets are or how they are used. Please >clarify this section further. This section has been removed. The concepts are generalized now and PHBs are presented as examples. >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. See above (and above, and above...) > Thanx again, *Yoram --=====================_1125257062==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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

At 09:16 PM 10/10/00 -0400, Weiss, Walter wrote:

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

regards,

-Walter

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

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

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.


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

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


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

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

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


First, the policy will be translated into a set of configuration rules. For example, a condition like "if source =3D 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?


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.


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?


Fourth, the criteria for derivin= g 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 =3D 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?


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.


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?


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.

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.


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?


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

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.


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

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.


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

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.


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.

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


"Setting preemption priorit= y [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.

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


"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 =3D WF OR style =3D SE) AND qpRSVPTrfcProf &= lt; 64Kb AND SessionCount < 6 THEN accept reservation

This is far more intuitive than what you have.

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.


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.

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


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.

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


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

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


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.

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


 

Thanx again,
*Yoram --=====================_1125257062==_.ALT-- From majordomo@raleigh.ibm.com Fri Oct 13 17:15:52 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12019 for ; Fri, 13 Oct 2000 17:15:51 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA25936; Fri, 13 Oct 2000 17:06:49 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA29290; Fri, 13 Oct 2000 17:06:35 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54360; Fri, 13 Oct 2000 16:41:14 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54352; Fri, 13 Oct 2000 16:41:11 -0400 Received: from corp.tivoli.com (corp.tivoli.com [146.84.104.1]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA03406 for ; Fri, 13 Oct 2000 16:41:08 -0400 From: ellesson@tivoli.com Received: from schub.tivoli.com (schub.tivoli.com [146.84.104.17]) by corp.tivoli.com (8.9.3/8.9.0) with ESMTP id PAA15388; Fri, 13 Oct 2000 15:40:36 -0500 (CDT) Importance: Normal Subject: PCIM I-D Submitted To: policy@raleigh.ibm.com Cc: "Luis A. Sanchez" , "G R Mundy" , "Wijnen, Bert \(Bert\)" , "Joel M. Halpern" , remoore@us.ibm.com, Harald Alvestrand , John Strassner , "Andrea Westerinen" Date: Fri, 13 Oct 2000 16:42:03 -0400 Message-Id: X-Mimetrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at 10/13/2000 03:40:33 PM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: ellesson@tivoli.com A new version of the Policy Core Information Model -- Version 1 Specification , was submitted this morning, for posting to the I-D repository, and we have passed this version on to our Area Advisor, Bert Wijnen, for consideration by the IESG for advancement to Proposed Standard. It should show up in the repository very soon. Thanks to Bob Moore for editing and submitting this document, and to the authors of, and contributors to, this and earlier drafts. This version incorporates the editorial changes agreed upon in Pittsburgh, and also includes input from Luis Sanchez, and Russ Mundy, representing the Security Area, who helped us with the appropriate wording for Section 10, the Security Considerations section, as well as input from Harald Alvestrand, who reviewed our work on behalf of the IESG. Thank you, Luis, Russ and Harald. Follow-on derivative documents will extend and map PCIM into specific technical domains, and into specific representation technologies. These extensions and mappings will affect the nature of what needs to be documented, and where, with regard to security requirements. The authors discussed this with Bert, Luis and Russ, and we all agreed to the following text. This completes our effort to address the issues which came up as a result of last call on this document. 10. Security Considerations The Policy Core Information Model (PCIM) presented in this document provides an object-oriented model for describing policy information. It provides a basic framework for describing the structure of policy information, in a form independent of any specific repository or access protocol, for use by an operational system. PCIM is not intended to represent any particular system design or implementation, nor does it define a protocol, and as such it does not have any specific security requirements. However, it should also be noted that certain derivative documents, which use PCIM as a base, will need to convey more specific security considerations. In order to communicate the nature of what will be expected in these follow-on derivative documents, it is necessary to review the reasons that PCIM, as defined in this document, is neither implementable, nor representative of any real-world system, as well as the nature of the expected follow-on extensions and mappings. There are three independent reasons that PCIM, as defined here, is neither implementable nor representative of any real-world system: 1. Its classes are independent of any specific repository that uses any specific access protocol. Therefore, its classes are designed not to be implemented directly. PCIM should instead be viewed as a schematic that directs how information should be represented, independent of any specific model implementation constraints. 2. Its classes were designed to be independent of any specific policy domain. For example, DiffServ and IPSec represent two different policy domains. Each document which extends PCIM to one of these domains will derive subclasses from the classes and relationships defined in PCIM, in order to represent extensions of a generic model to cover specific technical domains. 3. It's an information model, which must be mapped to a specific data model (native CIM schema, LDAP schema, MIB, whatever) before it can be implemented. Derivative documents will map the extended information models noted in item 2, above, to specific types of data model implementations. Even though specific security requirements are not appropriate for PCIM, specific security requirements MUST be defined for each operational real- world application of PCIM. Just as there will be a wide range of operational, real-world systems using PCIM, there will also be a wide range of security requirements for these systems. Some operational, real-world systems that are deployed using PCIM may have extensive security requirements that impact nearly all classes and subclasses utilized by such a system, while other systems' security requirements might have very little impact. The derivative documents, discussed above, will create the context for applying operational, real-world, system-level security requirements against the various models which derive from PCIM. For example, in some real-world scenarios, the values associated with certain properties, within certain instantiated classes, may represent information associated with scarce, and/or costly (and therefore valuable) resources. It may be the case that these values must not be disclosed to, or manipulated by, unauthorized parties. As long as the derived model remains an information model (as opposed to a data model), it is not possible to discuss the data model-specific tools and mechanisms that are available for achieving the authentication and authorization implicit in a requirement that restricts read and/or read- write access to these values. Therefore, these mechanisms will need to be discussed in each of the data models to which the derived information models are mapped. If there are any general security requirements that can be identified and can be applied across multiple types of data models, it would be appropriate to discuss those at the information model level, rather than the data model level. In any case, any identified security requirements that are not dealt with in the information model document, MUST be dealt with in the derivative data model documents. We can illustrate these points by extending the example from Section 2. A real-world system that provides QoS Gold Service to John would likely need to provide at least the following security-related capabilities and mechanisms (see [12] for definitions of security related terms): o Data integrity for the information (e.g. property values and instantiated relationships) that specify that John gets QoS Gold Service, from the point(s) that the information is entered into the system to the point(s) where network components actually provide that Service. o Authentication and Authorization methods to ensure that only system administrators (and not John or other engineers) can remotely administer components of the system. o An Authentication method to insure that John receives Gold Service, and the other members of the engineering group receive Bronze Service. These are one possible set of requirements associated with an example real-world system which delivers Gold Service, and the appropriate place to document these would be in some combination of the information model and the derivative data models for QoS Policy. Each of the data models would also need to discuss how these requirements are satisfied, using the mechanisms typically available to such a data model, given the particular technology or set of technologies which it may employ. Ed and Joel From majordomo@raleigh.ibm.com Sat Oct 14 18:52:48 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05917 for ; Sat, 14 Oct 2000 18:52:47 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA28668; Sat, 14 Oct 2000 18:44:19 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA37952; Sat, 14 Oct 2000 18:44:15 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43774; Sat, 14 Oct 2000 18:05:28 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50158; Sat, 14 Oct 2000 18:05:22 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA12694 for ; Sat, 14 Oct 2000 18:05:21 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA28104 for ; Sat, 14 Oct 2000 18:05:18 -0400 Received: from user-53.cisco.com ([144.254.95.34]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id AAA15364; Sun, 15 Oct 2000 00:04:42 +0200 (IST) Message-Id: <4.3.2.7.2.20001011215319.00d7c870@csi-admin1> X-Sender: ronc@csi-admin1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 14 Oct 2000 15:04:54 -0700 To: Yoram Ramberg , "Weiss, Walter" , policy@raleigh.ibm.com From: Ron Cohen Subject: Re: PQIM draft issues In-Reply-To: <4.3.2.7.2.20001011212859.00d95e70@csi-admin1.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Ron Cohen My remarks inline. In order to save bandwidth, I've snipped sections I don't have anything to add on [snip] >>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? 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] >>(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. > >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. > 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. >>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. > >Again, deferred to the expert. I tend to agree that one should be able to >express both types of admission policies. 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. >>"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. > >I think you're requesting a clarification here. Will be addressed. 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 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. > >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. >>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. > >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 majordomo@raleigh.ibm.com Mon Oct 16 07:13:16 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02135 for ; Mon, 16 Oct 2000 07:13:15 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA21712; Mon, 16 Oct 2000 07:02:38 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA05726; Mon, 16 Oct 2000 07:02:25 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44866; Mon, 16 Oct 2000 06:16:26 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42554; Mon, 16 Oct 2000 06:16:22 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA27628 for ; Mon, 16 Oct 2000 06:16:22 -0400 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA16982 for ; Mon, 16 Oct 2000 06:16:17 -0400 Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e9GAGBF94038; Mon, 16 Oct 2000 12:16:11 +0200 (CEST) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA08983; Mon, 16 Oct 2000 12:16:13 +0200 Message-Id: <39EAD6B1.90034B1B@ccrle.nec.de> Date: Mon, 16 Oct 2000 12:21:37 +0200 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de Mime-Version: 1.0 To: Ron Cohen , Yoram Ramberg , "Weiss, Walter" Cc: policy@raleigh.ibm.com Subject: Re: PQIM draft issues References: <4.3.2.7.2.20001011215319.00d7c870@csi-admin1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit 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 > >>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. > > > >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 -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de 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 majordomo@raleigh.ibm.com Mon Oct 16 19:00:40 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17314 for ; Mon, 16 Oct 2000 19:00:39 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA26984; Mon, 16 Oct 2000 18:49:55 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA43574; Mon, 16 Oct 2000 18:49:42 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42212; Mon, 16 Oct 2000 18:18:47 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA42202; Mon, 16 Oct 2000 18:18:39 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA23810 for ; Mon, 16 Oct 2000 18:18:43 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA22388 for ; Mon, 16 Oct 2000 18:18:39 -0400 Received: from ysnirnt70 (dhcp-5sjc10-171-70-71-54.cisco.com [171.70.71.54]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with SMTP id AAA28320; Tue, 17 Oct 2000 00:14:41 +0200 (IST) From: "Yoram Snir" To: "'Marcus Brunner'" Cc: , "'Ron Cohen'" , "'Yoram Ramberg'" , "'Weiss, Walter'" Subject: RE: PQIM draft issues Date: Mon, 16 Oct 2000 15:12:26 +0200 Message-Id: <004401c03772$bb2334e0$364746ab@ysnirnt70> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <39EAD6B1.90034B1B@ccrle.nec.de> Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Yoram Snir" Content-Transfer-Encoding: 7bit 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: policy-owner@raleigh.ibm.com > [mailto:policy-owner@raleigh.ibm.com]On Behalf Of Marcus Brunner > Sent: Monday, October 16, 2000 12:22 PM > To: Ron Cohen; Yoram Ramberg; Weiss, Walter > Cc: policy@raleigh.ibm.com > Subject: Re: PQIM draft issues > > > > 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 > > > >>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. > > > > > >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 > > -- > > Dr. Marcus Brunner > C&C Research Laboratories > NEC Europe Ltd. > > E-Mail: brunner@ccrle.nec.de > 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 majordomo@raleigh.ibm.com Wed Oct 18 14:08:07 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09107 for ; Wed, 18 Oct 2000 14:08:04 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA15146; Wed, 18 Oct 2000 13:57:58 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA34910; Wed, 18 Oct 2000 13:57:44 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46268; Wed, 18 Oct 2000 13:30:39 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34996; Wed, 18 Oct 2000 13:30:35 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA30996 for ; Wed, 18 Oct 2000 13:30:38 -0400 Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA32492 for ; Wed, 18 Oct 2000 13:30:29 -0400 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <4XB5BF8L>; Wed, 18 Oct 2000 13:26:30 -0400 Message-Id: From: "Weiss, Walter" To: "'Yoram Ramberg'" , policy@raleigh.ibm.com Subject: RE: PQIM draft issues Date: Wed, 18 Oct 2000 13:26:23 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03928.8D855718" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03928.8D855718 Content-Type: text/plain; charset="iso-8859-1" Yoram, My comments follow. regards, -Walter -----Original Message----- From: Yoram Ramberg [mailto:yramberg@cisco.com] Sent: Thursday, October 12, 2000 1:32 AM To: Weiss, Walter; policy@raleigh.ibm.com 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 I appreciate the constructive tone. It is certainly my goal that any standard in the management space is a step forward. 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. 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. "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. 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. 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. 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. 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 then ", 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. 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 then " 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. 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 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? 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 THEN qpTrfcProf = This strikes me as equally unnatural when compared to my original example. 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 ", 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 then 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). 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? 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? 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 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. 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 , and 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. So let's start work on a PCIM extensions draft and put all these compelling concepts in there. 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? 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. [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. 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. 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? 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. [snip] ------_=_NextPart_001_01C03928.8D855718 Content-Type: text/html; charset="iso-8859-1"
Yoram,
 
My comments follow.
 
regards,
 
-Walter
-----Original Message-----
From: Yoram Ramberg [mailto:yramberg@cisco.com]
Sent: Thursday, October 12, 2000 1:32 AM
To: Weiss, Walter; policy@raleigh.ibm.com
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]

------_=_NextPart_001_01C03928.8D855718-- From majordomo@raleigh.ibm.com Wed Oct 18 18:43:43 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13363 for ; Wed, 18 Oct 2000 18:43:41 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA27566; Wed, 18 Oct 2000 18:35:12 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA34630; Wed, 18 Oct 2000 18:35:05 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41186; Wed, 18 Oct 2000 18:10:33 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA52416; Wed, 18 Oct 2000 18:10:25 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA12740 for ; Wed, 18 Oct 2000 18:10:28 -0400 Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA35566 for ; Wed, 18 Oct 2000 18:10:27 -0400 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id <4XB5BHAR>; Wed, 18 Oct 2000 18:06:24 -0400 Message-Id: From: "Weiss, Walter" To: "'Ron Cohen'" , Yoram Ramberg , policy@raleigh.ibm.com Subject: RE: PQIM draft issues Date: Wed, 18 Oct 2000 18:06:14 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0394F.A71B1646" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0394F.A71B1646 Content-Type: text/plain; charset="iso-8859-1" Hi Ron, > From: Ron Cohen [mailto:ronc@cisco.com] > Sent: Saturday, October 14, 2000 6:05 PM > > >>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? > > 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. > See comments to Yoram on this point. > [snip] > > > >>(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. > > > >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. > > > > 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. > My point was a little different. I was not suggesting that you should expand your model to consider these possible scenarios. Rather that it should be compartmentalized using class hierarchies, such that actions can reference class instances. I would strongly argue against a flat action space containing all possible attributes that can be assigned. While this may be tenable for QoS, it will not scale once other forwarding bahaviors are introduced into the policy infrastructure. > > >>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. > > > >Again, deferred to the expert. I tend to agree that one > should be able to > >express both types of admission policies. > 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. > I have heard from customers that want to use policies based on network consumption rather than reservations as a criteria for accepting or rejecting a reservation. While I would personally challenge this notion as counter to basic principles around reservations and IntServ in general, there seems to be a desire to have this feature non the less. However, as you can see, I did not flag this as a critical issue. > > >>"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. > > > >I think you're requesting a clarification here. Will be addressed. > > 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. > We are not not suggesting that the semantics of RSVP or COPS should change. Rather, I am pointing out that COPS has provisions for local policy enforcement and consequently using policies to determine preemption criteria rather than static priorities would certainly be useful. > > >>"Rule S: > >> If 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. > > > >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. > Hmm. Frankly, I don't understand this arguement. Making these expressions conditions instead of actions still keeps them in the same rule. Further, I don't think it prevents the sharing of filters across provisioning and signaling either. > > > >>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. > > > >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. > I went back to the MIB and found the text. It does not look quite right to me.I am going to have to get back to you on this one after I discuss it with the MIB co-authors. Thanks, -Walter ------_=_NextPart_001_01C0394F.A71B1646 Content-Type: text/html; charset="iso-8859-1" RE: PQIM draft issues

Hi Ron,

> From: Ron Cohen [mailto:ronc@cisco.com]
> Sent: Saturday, October 14, 2000 6:05 PM
>
> >>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?
>
> 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.
>
See comments to Yoram on this point.

> [snip]
>
>
> >>(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.
> >
> >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.
> >
>
> 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.
>
My point was a little different. I was not suggesting that you should expand your model to consider these possible scenarios. Rather that it should be compartmentalized using class hierarchies, such that actions can reference class instances. I would strongly argue against a flat action space containing all possible attributes that can be assigned. While this may be tenable for QoS, it will not scale once other forwarding bahaviors are introduced into the policy infrastructure.

>
> >>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.
> >
> >Again, deferred to the expert. I tend to agree that one
> should be able to
> >express both types of admission policies.
> 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.
>
I have heard from customers that want to use policies based on network consumption rather than reservations as a criteria for accepting or rejecting a reservation. While I would personally challenge this notion as counter to basic principles around reservations and IntServ in general, there seems to be a desire to have this feature non the less. However, as you can see, I did not flag this as a critical issue.

>
> >>"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.
> >
> >I think you're requesting a clarification here. Will be addressed.
>
> 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.
>
We are not not suggesting that the semantics of RSVP or COPS should change. Rather, I am pointing out that COPS has provisions for local policy enforcement and consequently using policies to determine preemption criteria rather than static priorities would certainly be useful.

>
> >>"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.
> >
> >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.
>
Hmm. Frankly, I don't understand this arguement. Making these expressions conditions instead of actions still keeps them in the same rule. Further, I don't think it prevents the sharing of filters across provisioning and signaling either.

>
>
> >>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.
> >
> >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.
>
I went back to the MIB and found the text.  It does not look quite right to me.I am going to have to get back to you on this one after I discuss it with the MIB co-authors.

Thanks,

-Walter

------_=_NextPart_001_01C0394F.A71B1646-- From majordomo@raleigh.ibm.com Thu Oct 19 07:59:24 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08994 for ; Thu, 19 Oct 2000 07:59:23 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA31396; Thu, 19 Oct 2000 07:44:02 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA26294; Thu, 19 Oct 2000 07:42:37 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA32020; Thu, 19 Oct 2000 07:12:51 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39180; Thu, 19 Oct 2000 07:12:48 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA25018 for ; Thu, 19 Oct 2000 07:12:49 -0400 Received: from csi-admin1.cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA29382 for ; Thu, 19 Oct 2000 07:12:45 -0400 Received: from yramberg-hpxu.cisco.com (telaviv3-dhcp65.cisco.com [144.254.93.193]) by csi-admin1.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id NAA13781; Thu, 19 Oct 2000 13:11:41 +0200 (IST) Message-Id: <4.3.2.7.2.20001019125927.03a604c0@csi-admin1.cisco.com> X-Sender: yramberg@csi-admin1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Oct 2000 13:08:55 -0500 To: "Weiss, Walter" , "'Ron Cohen'" , policy@raleigh.ibm.com From: Yoram Ramberg Subject: RE: PQIM draft issues In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_75516453==_.ALT" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg --=====================_75516453==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Just a tiny little note... Snipped the rest to save BW. *Yoram At 06:06 PM 10/18/00 -0400, Weiss, Walter wrote: >Hi Ron, > > > From: Ron Cohen [mailto:ronc@cisco.com] > > Sent: Saturday, October 14, 2000 6:05 PM >[...snip...] > > >>(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. > > > > > >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. > > > > > > > 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. > > >My point was a little different. I was not suggesting that you should >expand your model to consider these possible scenarios. Rather that it >should be compartmentalized using class hierarchies, such that actions can >reference class instances. I would strongly argue against a flat action >space containing all possible attributes that can be assigned. While this >may be tenable for QoS, it will not scale once other forwarding bahaviors >are introduced into the policy infrastructure. IMO, we should provide abstract classes that can be further refined to model various specific actions (which can be further refined). Why abstract actions? To allow interoperability so that people don't go defining their own actions that are outside the scope of [QPIM] and [PCIM]. So, for example, traffic profile can be a property-less abstract class from which one can derive PR profile, RSVP profile and also things like CR-LDP traffic profile. Alternately, an implementer may use RSVP traffic profile (or PR) already defined and derived from the abstract class to specify CR-LDP traffic profile. Comments to this effect were made in Pittsburgh and since by Marcus. We need to consider this seriously. [...snip...] --=====================_75516453==_.ALT Content-Type: text/html; charset="us-ascii" Just a tiny little note...
Snipped the rest to save BW.
*Yoram

At 06:06 PM 10/18/00 -0400, Weiss, Walter wrote:

Hi Ron,

> From: Ron Cohen [mailto:ronc@cisco.com]
> Sent: Saturday, October 14, 2000 6:05 PM
[...snip...]

> >>(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.
> >
> >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.
> >
>
> 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.
>
My point was a little different. I was not suggesting that you should expand your model to consider these possible scenarios. Rather that it should be compartmentalized using class hierarchies, such that actions can reference class instances. I would strongly argue against a flat action space containing all possible attributes that can be assigned. While this may be tenable for QoS, it will not scale once other forwarding bahaviors are introduced into the policy infrastructure.

IMO, we should provide abstract classes that can be further refined to model various specific actions (which can be further refined). Why abstract actions? To allow interoperability so that people don't go defining their own actions that are outside the scope of [QPIM] and [PCIM]. So, for example, traffic profile can be a property-less abstract class from which one can derive PR profile, RSVP profile and also things like CR-LDP traffic profile. Alternately, an implementer may use RSVP traffic profile (or PR) already defined and derived from the abstract class to specify CR-LDP traffic profile. Comments to this effect were made in Pittsburgh and since by Marcus. We need to consider this seriously.

[...snip...]
--=====================_75516453==_.ALT-- From majordomo@raleigh.ibm.com Fri Oct 20 17:29:39 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06629 for ; Fri, 20 Oct 2000 17:29:39 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA21156; Fri, 20 Oct 2000 17:19:28 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA33170; Fri, 20 Oct 2000 17:19:16 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA55476; Fri, 20 Oct 2000 16:48:25 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21676; Fri, 20 Oct 2000 16:48:22 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA30892 for ; Fri, 20 Oct 2000 16:48:25 -0400 Received: from ziggy.stardust.com (root@ns.stardust.com [205.184.205.34]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA33268 for ; Fri, 20 Oct 2000 16:48:23 -0400 Received: from pleiades (dhcp204-96.stardust.com [205.184.204.96]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA16900 for ; Fri, 20 Oct 2000 13:41:52 -0700 Message-Id: <3.0.5.32.20001020134151.014b7ba0@stardust.com> X-Sender: jasonu@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Oct 2000 13:41:51 -0700 To: policy@raleigh.ibm.com From: Jason Utz Subject: COPS/Policy Activities at upcoming iBANDatISPCON event Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Jason Utz I wanted to give you a heads-up on the sessions at the upcoming iBAND at ISPCON event that are most relevant to this list: "COPS Management for MPLS Traffic", Fran Reichmeyer, PfN Inc. "QoS and Policy-Based Routing", Bora Akyol, Pluris "Standard for Application Programming Interfaces", Pierre Lin, Verizon Communications & Satoshi Yoshizawa, Hitachi America These are just a few of the technical sessions at this year's 5th iBAND conference and showcase, co-located with ISPCON this year at the San Jose Convention Center, November 8-10. Internet Traffic Management, Service Provisioning and Performance Measurement are the themes of the event. For more event information, go to: http://events.stardust.com/iband Before October 25, 2000, you can sign up for the event, get all the sessions free in MP3 format and get a $100 discount by going to https://events.stardust.com/iband/special/register_offer.htm and using the following registration code: POLICY ---------------------- Other Event Highlights ---------------------- Keynotes -------- * Content Delivery: A New World ofTechnology, Business & Value-Added Services Z. Alan Fink, Sr. Vice President & General Manager, Adero & Jim Ricotta,Senior Director, Marketing Cisco Systems * Internet Infrastructure: Why We Can't Just Paint Over the Cracks Judy Estrin, Chief Executive Officer, Packet Design, Inc. * Creating, Provisioning and Managing IP Services Under Massive Commercial Pressures Charles Muirhead, Founder, Orchestream and iGabriel.net BOFs * What's new in network processing and the CPIX Forum's role in it Colin Mick, CPIX Forum Steve Jacobson, RealNetworks * The Technical Needs of Content Peering Mark Day, Cisco Systems & Brad Cain, Mirror Image Internet * Enabling QoS at the Network Edge Manickam "Sri" Sridhar, Sitara Networks * Policy-based Configuration Management Art Mellor, Gold Wire Technology * Riding the Wave of Streaming Video Bodhi Mukherjee, InfoValue Computing * Internet2 Russ Hobby, UC Davis iBAND Showcase The iBAND Showcase is the fourth in a series of networks engineered by members of the QoS Forum and exhibitors at the iBAND event -- It will feature: * Accelerated Application Services * Intelligent Network Infrastructure * Service Management * Network Performance Tools Relevant Sessions I4 - Standard for Application Programming Interfaces for QoS Aware IP Network Pierre Lin, Verizon Communications Satoshi Yoshizawa, Hitachi America Open programmable interfaces are required to control, manage and compose network resources across various QoS-ready network elements. Significant progress has been made on a reference model, working drafts and working prototypes via the IEEE P1520 Standard Working Group, culminating with a joint technology demonstration at Telecom 99. The first draft standard of the APIs for IP networks is to be published by October 2000. These efforts will benefit network service developers and application vendors who would like to implement and deploy novel traffic management schemes. I5 - COPS Management for MPLS Traffic Engineering Fran Reichmeyer, PfN Inc. MPLS provides a set of functionality that satisfies several requirements for performing traffic engineering in the network. The COPS protocol can be used to manage those MPLS features that are responsible for provisioning network resources for use by the MPLS traffic. Applying COPS in this way offers several advantages such as having a single management mechanism for provisioning, for the dynamic mapping of traffic onto MPLS tunnels, as well as for monitoring and maintaining tunnel performance. I6 - QoS and Policy-Based Routing at Wire Speed Bora Akyol, Pluris As Internet traffic demands accelerate, service providers cannot afford to have much-needed prioritization mechanisms slow throughput. Next-generation IP core equipment must offer extensive classification, policing, queuing, congestion management, and shaping capabilities while at the same time enabling service providers deliver scalable services at line-rate performance. This presentation will address the ASIC classification, policing, and shaping capabilities to create and provide such services as well as explain the software attributes necessary to meet the demands of providing quality of service at multi-gigabit interface speeds. From majordomo@raleigh.ibm.com Mon Oct 23 08:54:28 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21663 for ; Mon, 23 Oct 2000 08:54:27 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA12972; Mon, 23 Oct 2000 08:46:04 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA29230; Mon, 23 Oct 2000 08:45:59 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39182; Mon, 23 Oct 2000 08:16:22 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA37858; Mon, 23 Oct 2000 08:16:17 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id IAA26304 for ; Mon, 23 Oct 2000 08:16:17 -0400 Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA06650 for ; Mon, 23 Oct 2000 08:16:11 -0400 Received: from wallace.heidelberg.ccrle.nec.de (root@Wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by yamato.ccrle.nec.de (8.10.1/8.10.1) with ESMTP id e9NCFmT25946; Mon, 23 Oct 2000 14:15:48 +0200 (CEST) Received: from ccrle.nec.de (madrid.heidelberg.ccrle.nec.de [192.168.102.79]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA00353; Mon, 23 Oct 2000 14:15:57 +0200 Message-Id: <39F42D4C.D8B02924@ccrle.nec.de> Date: Mon, 23 Oct 2000 14:21:32 +0200 From: Marcus Brunner Organization: NEC Europe Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en,de Mime-Version: 1.0 To: Yoram Ramberg Cc: "Weiss, Walter" , "'Ron Cohen'" , policy@raleigh.ibm.com Subject: Re: PQIM draft issues References: <4.3.2.7.2.20001019125927.03a604c0@csi-admin1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Marcus Brunner Content-Transfer-Encoding: 7bit Yoram Ramberg wrote: > > Just a tiny little note... > Snipped the rest to save BW. > *Yoram > > At 06:06 PM 10/18/00 -0400, Weiss, Walter wrote: > > > Hi Ron, > > > > > From: Ron Cohen [mailto:ronc@cisco.com] > > > Sent: Saturday, October 14, 2000 6:05 PM > > [...snip...] > > > > >>(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. > > > > > > > >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. > > > > > > > > > > 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. > > > > > My point was a little different. I was not suggesting that you > > should expand your model to consider these possible scenarios. > > Rather that it should be compartmentalized using class hierarchies, > > such that actions can reference class instances. I would strongly > > argue against a flat action space containing all possible attributes > > that can be assigned. While this may be tenable for QoS, it will not > > scale once other forwarding bahaviors are introduced into the policy > > infrastructure. > > > > IMO, we should provide abstract classes that can be further refined to > model various specific actions (which can be further refined). Why > abstract actions? To allow interoperability so that people don't go > defining their own actions that are outside the scope of [QPIM] and > [PCIM]. So, for example, traffic profile can be a property-less > abstract class from which one can derive PR profile, RSVP profile and > also things like CR-LDP traffic profile. Alternately, an implementer > may use RSVP traffic profile (or PR) already defined and derived from > the abstract class to specify CR-LDP traffic profile. Comments to this > effect were made in Pittsburgh and since by Marcus. We need to > consider this seriously. > > [...snip...] Yoram, Yes, I am in favour of using inheritence for the purpose of extending the model. Some abstract actions and traffic profiles are what we would like to use and extend in the MPLS case. And I am sure, it will help defining other models by extending existing once instead of defining from scratch. Marcus -- Dr. Marcus Brunner C&C Research Laboratories NEC Europe Ltd. E-Mail: brunner@ccrle.nec.de 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 majordomo@raleigh.ibm.com Tue Oct 24 14:45:08 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12683 for ; Tue, 24 Oct 2000 14:45:08 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA07354; Tue, 24 Oct 2000 14:25:37 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA33306; Tue, 24 Oct 2000 14:25:32 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA53886; Tue, 24 Oct 2000 10:51:46 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34662; Tue, 24 Oct 2000 10:51:41 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA27392 for ; Tue, 24 Oct 2000 10:51:43 -0400 Received: from d04nms41.raleigh.ibm.com (d04nms41nms42.raleigh.ibm.com [9.67.228.19]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.94) with ESMTP id KAA30122 for ; Tue, 24 Oct 2000 10:51:42 -0400 Importance: Normal Subject: QDIM: Changing two QoS Model properties to uint64, units = nanoseconds To: policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore/Raleigh/IBM" Date: Tue, 24 Oct 2000 10:54:28 -0400 X-Mimetrack: Serialize by Router on D04NMS41/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 10/24/2000 10:51:43 AM Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore/Raleigh/IBM" In looking further at the QDIM draft, it appears that the DeltaInterval properties in AverageRateMeter and EWMAMeter don't have a fine enough granularity. These properties were defined in QDIM-01 to have units = microseconds. In fact, though, they need to have units = nanoseconds. Furthermore, if we change the units to nanoseconds, then the uint32 syntax doesn't have enough bits. So we (the authors of the draft) propose to change the units for these two properties to nanoseconds, and change their syntax from uint32 to uint64. Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com From majordomo@raleigh.ibm.com Tue Oct 24 14:47:46 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13023 for ; Tue, 24 Oct 2000 14:47:45 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA23150; Tue, 24 Oct 2000 14:25:41 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA32364; Tue, 24 Oct 2000 14:25:32 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34624; Tue, 24 Oct 2000 10:52:47 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA39986; Tue, 24 Oct 2000 10:52:34 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA36674 for ; Tue, 24 Oct 2000 10:52:36 -0400 Received: from mx-relay1.treas.gov (mx-relay1.treas.gov [199.196.144.5]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA22928 for ; Tue, 24 Oct 2000 10:52:33 -0400 Received: from tias4.treas.gov (tias-gw4.treas.gov [199.196.144.14]) by mx-relay1.treas.gov (8.9.1b+Sun/8.9.3) with SMTP id KAB00486 for ; Tue, 24 Oct 2000 10:52:34 -0400 (EDT) Received: from mailhub.net.treas.gov by tias4.treas.gov via smtpd (for mx-relay.treas.gov [199.196.144.5]) with SMTP; 24 Oct 2000 14:52:33 UT Received: from mears.indy.cr.irs.gov (mailhub-3.net.treas.gov [10.7.8.11]) by mailhub-3.net.treas.gov (8.9.3+Sun/8.9.3) with ESMTP id KAA03292 for ; Tue, 24 Oct 2000 10:51:07 -0400 (EDT) Received: from parnelli.indy.cr.irs.gov (IDENT:lsbart35@localhost [127.0.0.1]) by mears.indy.cr.irs.gov (8.9.3/8.9.3) with ESMTP id JAA01318 for ; Tue, 24 Oct 2000 09:52:20 -0500 Message-Id: <39F5A224.C58504DE@parnelli.indy.cr.irs.gov> Date: Tue, 24 Oct 2000 09:52:20 -0500 From: "Larry S. Bartz" X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en Mime-Version: 1.0 To: IETF Policy WG LIST Subject: looking for cim23AdminDomain OID and ABNF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Larry S. Bartz" Content-Transfer-Encoding: 7bit The draft-ietf-policy-core-schema-07.txt defines an objectclass policyRepository which inherits from cim23AdminDomain. cim23AdminDomain is absent from the DMTF's LDAP schema at: http://www.dmtf.org/spec/DEN/DSP0101.htm The schema described by draft-ietf-policy-core-schema-07 cannot be implemented without the OID of cim23AdminDomain. Where can I find the ABNF representation for cim23AdminDomain? What is its OID? -- #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| # Larry Bartz | | # lbartz@parnelli.indy.cr.irs.gov | Ooo, ooo, | # | Ooo, ooo, oooooo! | # | I've got a gnu attitude! | # voice (317) 226-7060 | | # FAX (317) 226-6378 | | #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::| From majordomo@raleigh.ibm.com Tue Oct 24 16:40:22 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06565 for ; Tue, 24 Oct 2000 16:40:22 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA31606; Tue, 24 Oct 2000 16:29:24 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA13602; Tue, 24 Oct 2000 16:29:22 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43096; Tue, 24 Oct 2000 15:24:00 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43076; Tue, 24 Oct 2000 15:23:55 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA26224 for ; Tue, 24 Oct 2000 15:23:58 -0400 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA27718 for ; Tue, 24 Oct 2000 15:23:54 -0400 Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA00799; Tue, 24 Oct 2000 12:22:11 -0700 (PDT) Message-Id: <4.1.20001024151732.00c4b3c0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 24 Oct 2000 15:19:29 -0400 To: "Robert Moore/Raleigh/IBM" , policy@raleigh.ibm.com From: John Schnizlein Subject: Re: QDIM: Changing two QoS Model properties to uint64, units = nanoseconds In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein At 10:54 AM 10/24/2000 -0400, Robert Moore/Raleigh/IBM wrote: >In looking further at the QDIM draft, it appears that the >DeltaInterval properties in AverageRateMeter and EWMAMeter >don't have a fine enough granularity. These properties >were defined in QDIM-01 to have units = microseconds. >In fact, though, they need to have units = nanoseconds. Could you say a little about why microseconds are insufficient, please? From majordomo@raleigh.ibm.com Wed Oct 25 11:30:38 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26345 for ; Wed, 25 Oct 2000 11:30:38 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA21478; Wed, 25 Oct 2000 11:21:56 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA22900; Wed, 25 Oct 2000 11:21:42 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49278; Wed, 25 Oct 2000 10:56:42 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA49268; Wed, 25 Oct 2000 10:56:38 -0400 Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA28674 for ; Wed, 25 Oct 2000 10:56:40 -0400 Received: from d04nms41.raleigh.ibm.com (d04nms41nms42.raleigh.ibm.com [9.67.228.19]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.94) with ESMTP id KAA45098; Wed, 25 Oct 2000 10:56:38 -0400 Importance: Normal Subject: Re: QDIM: Changing two QoS Model properties to uint64, units = nanoseconds To: John Schnizlein Cc: policy@raleigh.ibm.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-Id: From: "Robert Moore/Raleigh/IBM" Date: Wed, 25 Oct 2000 10:59:26 -0400 X-Mimetrack: Serialize by Router on D04NMS41/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 10/25/2000 10:56:40 AM Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Robert Moore/Raleigh/IBM" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA26345 John, This change comes from a comment that Walter made earlier on the mailing list: (This excerpt has my text quoted, and Walter's response unquoted) > 4. AverageRateMeter.DeltaInterval > 5. EWMAMeter.DeltaInterval >      The units for these properties are already >      specified as microseconds.  If 1 microsecond >      is sufficiently granular, then we have an >      interval a little over 1 hour as the maximum >      we can represent. > This deserves a warning. The minimum granularity for most intervals whether for a meters or average queue depth calculations should be 1 packet length time. Therefore, the lower bound is determined by the speed fo the link. At current link speed upper bounds (10Gb) and assuming a minimum packet size of 64 bytes (we way want to consider ATM cells, but let's ignore that for the moment), the current lower bound should be .000000067 of a second. (End excerpt) Regards, Bob Bob Moore IBM Networking Software +1-919-254-4436 remoore@us.ibm.com John Schnizlein on 10/24/2000 03:19:29 PM To: Robert Moore/Raleigh/IBM@IBMUS, policy@raleigh.ibm.com cc: Subject: Re: QDIM: Changing two QoS Model properties to uint64, units = nanoseconds At 10:54 AM 10/24/2000 -0400, Robert Moore/Raleigh/IBM wrote: >In looking further at the QDIM draft, it appears that the >DeltaInterval properties in AverageRateMeter and EWMAMeter >don't have a fine enough granularity. These properties >were defined in QDIM-01 to have units = microseconds. >In fact, though, they need to have units = nanoseconds. Could you say a little about why microseconds are insufficient, please? From majordomo@raleigh.ibm.com Wed Oct 25 12:46:33 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07918 for ; Wed, 25 Oct 2000 12:46:32 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA18598; Wed, 25 Oct 2000 12:36:56 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA35148; Wed, 25 Oct 2000 12:36:55 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47190; Wed, 25 Oct 2000 12:16:31 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38990; Wed, 25 Oct 2000 12:16:28 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA34684 for ; Wed, 25 Oct 2000 12:16:31 -0400 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA30368 for ; Wed, 25 Oct 2000 12:16:27 -0400 Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA12341; Wed, 25 Oct 2000 09:15:21 -0700 (PDT) Message-Id: <4.1.20001025115445.00a346d0@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 25 Oct 2000 12:14:27 -0400 To: "Robert Moore/Raleigh/IBM" From: John Schnizlein Subject: Re: QDIM: Changing two QoS Model properties to uint64, units = nanoseconds Cc: policy@raleigh.ibm.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein Some scrutiny should be given to the claim that "The minimum granularity for most intervals whether for a meters or average queue depth calculations should be 1 packet length time." Not only do averages need not be computed for every packet, but the parameters involved here are configured thresholds for compliance with a service-level-specification of rate. Microsecond level specification (32-bits) is already overkill, but not worth complaining about because justifying the economy of a 16-bit number is questionable. The more serious problem, which I thought someone else raised, is that a "real number" has limited practical value in a forwarding device. If real numbers were actually used, the exponent would presumably cover nanosecond scale of accuracy for this period. To help people evaluate the claimed need for this precision, included here is the relevant portion of draft-ietf-policy-qos-device-info-model-01.txt: "... 4.3.10.1. The Property AverageRate This is a 32-bit real number that defines the rate that is used to determine whether admitted packets are in conformance or not. The value is specified in kilobits per second. 4.3.10.2. The Property DeltaInterval This is a 32-bit real number that defines the time period over which the average measurement should be taken. The value is specified in microseconds. 4.3.11. The Class EWMAMeter This is a new concrete class, defined in this model. It is a subclass of the MeterService class, and represents an exponentially weighted moving average meter. This meter is a simple IIR low-pass filter that measures the rate of incoming packets over a small, fixed sampling interval. Any admitted packet that pushes the average rate over a pre-defined limit is defined to be non-conforming. Please see [DSMODEL] for more information. The class definition is as follows: NAME EWMAMeter DESCRIPTION A concrete class describing admitted traffic as either conforming or non- conforming, depending on whether the arrival of a packet in a small fixed sampling interval causes the average arrival rate to exceed a pre-determined value or not. DERIVED FROM MeterService TYPE Structural PROPERTIES AverageRate, DeltaInterval, Gain 4.3.11.1. The Property AverageRate This attribute is a 32-bit real number that defines the average rate against which the sampled arrival rate of packets should be measured. Any packet that causes the sampled rate to exceed this rate is deemed non-conforming. The value is specified in kilobits per second. 4.3.11.2. The Property DeltaInterval This attribute is a 32-bit real number that defines the sampling interval used to measure the arrival rate in bytes. The calculated rate is averaged over this interval and checked against the AverageRate attribute. All packets whose computed average arrival rate is less than the AverageRate are deemed conforming. The value is specified in microseconds. " At 10:59 AM 10/25/2000 -0400, Robert Moore/Raleigh/IBM wrote: > >This change comes from a comment that Walter made earlier on >the mailing list: > >(This excerpt has my text quoted, and Walter's response unquoted) >> 4. AverageRateMeter.DeltaInterval >> 5. EWMAMeter.DeltaInterval >> The units for these properties are already >> specified as microseconds. If 1 microsecond >> is sufficiently granular, then we have an >> interval a little over 1 hour as the maximum >> we can represent. >> >This deserves a warning. The minimum granularity for most intervals whether >for a meters or average queue depth calculations should be 1 packet length >time. Therefore, the lower bound is determined by the speed fo the link. At >current link speed upper bounds (10Gb) and assuming a minimum packet size >of 64 bytes (we way want to consider ATM cells, but let's ignore that for >the moment), the current lower bound should be .000000067 of a second. >(End excerpt) > >At 10:54 AM 10/24/2000 -0400, Robert Moore/Raleigh/IBM wrote: >>In looking further at the QDIM draft, it appears that the >>DeltaInterval properties in AverageRateMeter and EWMAMeter >>don't have a fine enough granularity. These properties >>were defined in QDIM-01 to have units = microseconds. >>In fact, though, they need to have units = nanoseconds. From majordomo@raleigh.ibm.com Wed Oct 25 18:40:58 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27083 for ; Wed, 25 Oct 2000 18:40:57 -0400 (EDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA25704; Wed, 25 Oct 2000 18:31:58 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id SAA19392; Wed, 25 Oct 2000 18:31:55 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54126; Wed, 25 Oct 2000 18:08:35 -0400 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34148; Wed, 25 Oct 2000 18:08:30 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id SAA25908 for ; Wed, 25 Oct 2000 18:08:33 -0400 Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id SAA28416 for ; Wed, 25 Oct 2000 18:08:29 -0400 Received: from andreawlap (sj-dial-4-81.cisco.com [171.68.181.210]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id PAA28517; Wed, 25 Oct 2000 15:07:16 -0700 (PDT) From: "Andrea Westerinen" To: "A S Arun" , "Policy@Raleigh. Ibm. Com" Subject: RE: Policy Language Date: Wed, 25 Oct 2000 15:11:25 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Andrea Westerinen" Content-Transfer-Encoding: 7bit Arun, The Policy Framework WG in the IETF may be a better home for this question. Andrea -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of A S Arun Sent: Wednesday, October 25, 2000 10:53 AM To: mpls@UU.NET; rsvp@isi.edu Subject: I am looking for a language by which policy can be entered There was one "policy Framework definition language" IETF Draft, Nov 1998, but is dormant now Are there any standard languages, Given a language I would write a compiler which would build the policy database, which would be searched as and when required. regards, **************************************************************************** *** A.S.ARUN (Arun A Somasundara) 3rd Sem M.E. Room No. D-3 Computer Science & Engineering IISc Hostels Dept. of Computer Science & Automation Indian Institute of Science Bangalore - 560012 INDIA **************************************************************************** *** From majordomo@raleigh.ibm.com Thu Oct 26 08:29:47 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19265 for ; Thu, 26 Oct 2000 08:29:47 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id IAA26070; Thu, 26 Oct 2000 08:04:10 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id IAA26566; Thu, 26 Oct 2000 08:03:57 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA41976; Thu, 26 Oct 2000 07:28:04 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA44528; Thu, 26 Oct 2000 07:28:01 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA31944 for ; Thu, 26 Oct 2000 07:28:02 -0400 Received: from itc-eml2.lannet.com (at.lannet.com [194.90.94.231]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA29574 for ; Thu, 26 Oct 2000 07:28:00 -0400 Received: by itc-eml2.lannet.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 13:27:55 +0200 Message-Id: <15F58915DF84D311AC7D0090279AA614233F49@itc-eml2.lannet.com> From: Dan Romascanu To: "'Andrea Westerinen'" , A S Arun , "Policy@Raleigh. Ibm. Com" Subject: RE: Policy Language Date: Thu, 26 Oct 2000 13:27:55 +0200 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Dan Romascanu Arun, You may also want to look at draft-ietf-snmpconf-pm-03.txt, which is worked in the snmpconf WG. Regards, Dan > -----Original Message----- > From: Andrea Westerinen [SMTP:andreaw@cisco.com] > Sent: Thu October 26 2000 0:11 > To: A S Arun; Policy@Raleigh. Ibm. Com > Subject: RE: Policy Language > > Arun, The Policy Framework WG in the IETF may be a better home for this > question. > > Andrea > > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of A S Arun > Sent: Wednesday, October 25, 2000 10:53 AM > To: mpls@UU.NET; rsvp@isi.edu > Subject: > > > I am looking for a language by which policy can be entered > > There was one "policy Framework definition language" IETF Draft, Nov 1998, > but is dormant now > > Are there any standard languages, > Given a language I would write a compiler which would build the policy > database, which would be searched as and when required. > > regards, > ************************************************************************** > ** > *** > A.S.ARUN > (Arun A Somasundara) > > 3rd Sem M.E. Room No. D-3 > Computer Science & Engineering IISc Hostels > Dept. of Computer Science & Automation > > Indian Institute of Science > Bangalore - 560012 > INDIA > ************************************************************************** > ** > *** > From majordomo@raleigh.ibm.com Thu Oct 26 12:26:40 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17457 for ; Thu, 26 Oct 2000 12:26:39 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA21854; Thu, 26 Oct 2000 12:16:26 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA29410; Thu, 26 Oct 2000 12:16:15 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA47392; Thu, 26 Oct 2000 11:49:57 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA35350; Thu, 26 Oct 2000 11:49:52 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA23294 for ; Thu, 26 Oct 2000 11:49:53 -0400 Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA24242 for ; Thu, 26 Oct 2000 11:49:50 -0400 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 11:45:27 -0400 Message-Id: From: "Weiss, Walter" To: "'John Schnizlein'" , Robert Moore/Raleigh/IBM Cc: policy@raleigh.ibm.com Subject: RE: QDIM: Changing two QoS Model properties to uint64, units = na noseconds Date: Thu, 26 Oct 2000 11:45:24 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03F63.C25AA42A" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03F63.C25AA42A Content-Type: text/plain; charset="iso-8859-1" John, Bob kicked me today to respond by pointing out that he was quoting me. My comments follow inline. regards, -Walter > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Wednesday, October 25, 2000 12:14 PM > To: Robert Moore/Raleigh/IBM > Cc: policy@raleigh.ibm.com > Subject: Re: QDIM: Changing two QoS Model properties to > uint64, units = > nanoseconds > > > Some scrutiny should be given to the claim that > "The minimum granularity for most intervals whether for a meters > or average queue depth calculations should be 1 packet > length time." > > Not only do averages need not be computed for every packet, but the > parameters involved here are configured thresholds for compliance with > a service-level-specification of rate. Microsecond level specification > (32-bits) is already overkill, but not worth complaining > about because > justifying the economy of a 16-bit number is questionable. The purpose of DeltaIntervals are to specify specific points in time at which an action should occur. In the case of the average queue depth measurement (TimeInterval), the value is already specified in nano-seconds for the reasons already cited. For DeltaInterval, the property describes the interval for sampling. My understanding is that the algorithm is identical to the algorithm used to calculate the averaged queue depth. If my understanding of the algorithm is flawed, then we will probably need to reconsider properties as well. There are two other issues. First, does line rate influence granularity. If the conclusion is that the line rate does not have an affect on sampling interval, then the question reduces to one of range of valid values. If the range is small, it can easily be represented in a 32 bit property with an appropriate units (10ns, 100ns, 1ms, etc.) For this first question, I can argue either side, so perhaps I am not the best person to advocate one over the other. I for one, would welcome some research or deployment experience here. The second issue relates to the mapping of the model to specific implementations. Your comment seems to imply that some implementations don't need this level of granularity because they don't perform the calculation on a per packet basis. This comment, to my mind, is inappropriate to determining the appropriate bounds of an Information Model. The purpose of a model is to stand the test of time. The purpose of data models and mappings of data models to specific products is to take advantage of more specific knowledge and work around specific limitations in the protocols, data stores, or specific implementations. > > The more serious problem, which I thought someone else raised, is that > a "real number" has limited practical value in a forwarding device. > If real numbers were actually used, the exponent would presumably > cover nanosecond scale of accuracy for this period. I keep flipping on this issue. On the one hand, REALs allow you to sacrifice precision in favor of greater flexibility in the ranges. On the other hand, REALs are painful to support in devices. I think my second comment above is the main arguement for using REALs: This is an information model. Specific mappings of this model to data models like MIBs inherently require a mapping of the data type because of limitations in the data type specifications, or limitations on the part of the applications using the protocol to support the data type. > > To help people evaluate the claimed need for this precision, > included here is the relevant portion of > draft-ietf-policy-qos-device-info-model-01.txt: > "... > 4.3.10.1. The Property AverageRate > > This is a 32-bit real number that defines the rate that is used > to determine whether admitted packets are in conformance or not. > The value is specified in kilobits per second. > > 4.3.10.2. The Property DeltaInterval > > This is a 32-bit real number that defines the time period over > which the average measurement should be taken. The value is > specified in microseconds. > > 4.3.11. The Class EWMAMeter > > This is a new concrete class, defined in this model. It is a > subclass of the MeterService class, and represents an > exponentially weighted moving average meter. This meter is a > simple IIR low-pass filter that measures the rate of incoming > packets over a small, fixed sampling interval. Any admitted > packet that pushes the average rate over a pre-defined limit is > defined to be non-conforming. Please see [DSMODEL] for more > information. > > The class definition is as follows: > > NAME EWMAMeter > DESCRIPTION A concrete class describing admitted > traffic as either conforming or non- > conforming, depending on whether the > arrival of a packet in a small fixed > sampling interval causes the average > arrival rate to exceed a > pre-determined value or not. > DERIVED FROM MeterService > TYPE Structural > PROPERTIES AverageRate, DeltaInterval, Gain > > 4.3.11.1. The Property AverageRate > > This attribute is a 32-bit real number that defines the average > rate against which the sampled arrival rate of packets should be > measured. Any packet that causes the sampled rate to exceed this > rate is deemed non-conforming. The value is specified in kilobits > per second. > > 4.3.11.2. The Property DeltaInterval > > This attribute is a 32-bit real number that defines the sampling > interval used to measure the arrival rate in bytes. The > calculated rate is averaged over this interval and checked > against the AverageRate attribute. All packets whose computed > average arrival rate is less than the AverageRate are deemed > conforming. > > The value is specified in microseconds. > " > > > At 10:59 AM 10/25/2000 -0400, Robert Moore/Raleigh/IBM wrote: > > > >This change comes from a comment that Walter made earlier on > >the mailing list: > > > >(This excerpt has my text quoted, and Walter's response unquoted) > >> 4. AverageRateMeter.DeltaInterval > >> 5. EWMAMeter.DeltaInterval > >> The units for these properties are already > >> specified as microseconds. If 1 microsecond > >> is sufficiently granular, then we have an > >> interval a little over 1 hour as the maximum > >> we can represent. > >> > >This deserves a warning. The minimum granularity for most > intervals whether > >for a meters or average queue depth calculations should be 1 > packet length > >time. Therefore, the lower bound is determined by the speed > fo the link. At > >current link speed upper bounds (10Gb) and assuming a > minimum packet size > >of 64 bytes (we way want to consider ATM cells, but let's > ignore that for > >the moment), the current lower bound should be .000000067 of > a second. > >(End excerpt) > > > >At 10:54 AM 10/24/2000 -0400, Robert Moore/Raleigh/IBM wrote: > >>In looking further at the QDIM draft, it appears that the > >>DeltaInterval properties in AverageRateMeter and EWMAMeter > >>don't have a fine enough granularity. These properties > >>were defined in QDIM-01 to have units = microseconds. > >>In fact, though, they need to have units = nanoseconds. > ------_=_NextPart_001_01C03F63.C25AA42A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: QDIM: Changing two QoS Model properties to uint64, units =3D = nanoseconds

John,

Bob kicked me today to respond by pointing out that = he was quoting me. My comments follow inline.

regards,

-Walter

> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]=
> Sent: Wednesday, October 25, 2000 12:14 = PM
> To: Robert Moore/Raleigh/IBM
> Cc: policy@raleigh.ibm.com
> Subject: Re: QDIM: Changing two QoS Model = properties to
> uint64, units =3D
> nanoseconds
>
>
> Some scrutiny should be given to the claim that =
>    "The minimum granularity = for most intervals whether for a meters
>     or average queue depth = calculations should be 1 packet
> length time."
>
> Not only do averages need not be computed for = every packet, but the
> parameters involved here are configured = thresholds for compliance with
> a service-level-specification of rate. = Microsecond level specification
> (32-bits) is already overkill, but not worth = complaining
> about because
> justifying the economy of a 16-bit number is = questionable.

The purpose of DeltaIntervals are to specify specific = points in time at which an action should occur. In the case of the = average queue depth measurement (TimeInterval), the value is already = specified in nano-seconds for the reasons already cited. For = DeltaInterval, the property describes the interval for sampling. My = understanding is that the algorithm is identical to the algorithm used = to calculate the averaged queue depth. If my understanding of the = algorithm is flawed, then we will probably need to reconsider = properties as well.

There are two other issues. First, does line rate = influence granularity. If the conclusion is that the line rate does not = have an affect on sampling interval, then the question reduces to one = of range of valid values. If the range is small, it can easily be = represented in a 32 bit property with an appropriate units (10ns, = 100ns, 1ms, etc.) For this first question, I can argue either side, so = perhaps I am not the best person to advocate one over the other. I for = one, would welcome some research or deployment experience = here.

The second issue relates to the mapping of the model = to specific implementations. Your comment seems to imply that some = implementations don't need this level of granularity because they don't = perform the calculation on a per packet basis. This comment, to my = mind, is inappropriate to determining the appropriate bounds of an = Information Model. The purpose of a model is to stand the test of time. = The purpose of data models and mappings of data models to specific = products is to take advantage of more specific knowledge and work = around specific limitations in the protocols, data stores, or specific = implementations. 

>
> The more serious problem, which I thought = someone else raised, is that
> a "real number" has limited practical = value in a forwarding device.
> If real numbers were actually used, the = exponent would presumably
> cover nanosecond scale of accuracy for this = period.

I keep flipping on this issue. On the one hand, REALs = allow you to sacrifice precision in favor of greater flexibility in the = ranges. On the other hand, REALs are painful to support in devices. I = think my second comment above is the main arguement for using REALs: = This is an information model. Specific mappings of this model to data = models like MIBs inherently require a mapping of the data type because = of limitations in the data type specifications, or limitations on the = part of the applications using the protocol to support the data = type.

>
> To help people evaluate the claimed need for = this precision,
> included here is the relevant portion of =
> = draft-ietf-policy-qos-device-info-model-01.txt: 
> "...
>  4.3.10.1. The Property AverageRate =
>
>    This is a 32-bit real number = that defines the rate that is used
>    to determine whether admitted = packets are in conformance or not.
>    The value is specified in = kilobits per second.
>
>  4.3.10.2. The Property DeltaInterval =
>
>    This is a 32-bit real number = that defines the time period over
>    which the average measurement = should be taken.  The value is
>    specified in microseconds. =
>
>  4.3.11. The Class EWMAMeter
>
>    This is a new concrete class, = defined in this model. It is a
>    subclass of the MeterService = class, and represents an
>    exponentially weighted moving = average meter. This meter is a
>    simple IIR low-pass filter = that measures the rate of incoming
>    packets over a small, fixed = sampling interval. Any admitted
>    packet that pushes the = average rate over a pre-defined limit is
>    defined to be non-conforming. = Please see [DSMODEL] for more
>    information.
>
>    The class definition is as = follows:
>
>        = NAME           &n= bsp;    EWMAMeter
>        = DESCRIPTION         A concrete = class describing admitted
>          = ;            = ;      traffic as either conforming or non- =
>          = ;            = ;      conforming, depending on whether = the 
>          = ;            = ;      arrival of a packet in a small = fixed 
>          = ;            = ;      sampling interval causes the = average 
>          = ;            = ;      arrival rate to exceed a 
>          = ;            = ;      pre-determined value or not.
>        = DERIVED FROM        MeterService =
>        = TYPE           &n= bsp;    Structural
>        = PROPERTIES          = AverageRate, DeltaInterval, Gain
>   
>  4.3.11.1. The Property AverageRate =
>
>    This attribute is a 32-bit = real number that defines the average
>    rate against which the = sampled arrival rate of packets should be
>    measured. Any packet that = causes the sampled rate to exceed this
>    rate is deemed = non-conforming. The value is specified in kilobits
>    per second.
>
>  4.3.11.2. The Property DeltaInterval =
>
>    This attribute is a 32-bit = real number that defines the sampling
>    interval used to measure the = arrival rate in bytes. The
>    calculated rate is averaged = over this interval and checked
>    against the AverageRate = attribute. All packets whose computed
>    average arrival rate is less = than the AverageRate are deemed
>    conforming. 
>
>    The value is specified in = microseconds.
> "
>
>
> At 10:59 AM 10/25/2000 -0400, Robert = Moore/Raleigh/IBM wrote:
> >
> >This change comes from a comment that = Walter made earlier on
> >the mailing list:
> >
> >(This excerpt has my text quoted, and = Walter's response unquoted)
> >> 4. = AverageRateMeter.DeltaInterval
> >> 5. EWMAMeter.DeltaInterval
> >>      The = units for these properties are already
> >>      = specified as microseconds.  If 1 microsecond
> >>      is = sufficiently granular, then we have an
> >>      interval = a little over 1 hour as the maximum
> >>      we can = represent.
> >>
> >This deserves a warning. The minimum = granularity for most
> intervals whether
> >for a meters or average queue depth = calculations should be 1
> packet length
> >time. Therefore, the lower bound is = determined by the speed
> fo the link. At
> >current link speed upper bounds (10Gb) and = assuming a
> minimum packet size
> >of 64 bytes (we way want to consider ATM = cells, but let's
> ignore that for
> >the moment), the current lower bound should = be .000000067 of
> a second.
> >(End excerpt)
> >
> >At 10:54 AM 10/24/2000 -0400, Robert = Moore/Raleigh/IBM wrote:
> >>In looking further at the QDIM draft, = it appears that the
> >>DeltaInterval properties in = AverageRateMeter and EWMAMeter
> >>don't have a fine enough = granularity.  These properties
> >>were defined in QDIM-01 to have units = =3D microseconds.
> >>In fact, though, they need to have = units =3D nanoseconds.
>

------_=_NextPart_001_01C03F63.C25AA42A-- From majordomo@raleigh.ibm.com Thu Oct 26 15:39:58 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12402 for ; Thu, 26 Oct 2000 15:39:58 -0400 (EDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA33506; Thu, 26 Oct 2000 15:31:11 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA30114; Thu, 26 Oct 2000 15:31:04 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29958; Thu, 26 Oct 2000 15:10:15 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46590; Thu, 26 Oct 2000 15:10:11 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA32132 for ; Thu, 26 Oct 2000 15:10:15 -0400 Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA16124 for ; Thu, 26 Oct 2000 15:10:12 -0400 Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA06062; Thu, 26 Oct 2000 12:06:59 -0700 (PDT) Message-Id: <4.1.20001026144232.009c9200@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 26 Oct 2000 15:06:08 -0400 To: "Weiss, Walter" , Robert Moore/Raleigh/IBM From: John Schnizlein Subject: RE: QDIM: Changing two QoS Model properties to uint64, units = nanoseconds Cc: policy@raleigh.ibm.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: John Schnizlein At 11:45 AM 10/26/2000 -0400, Weiss, Walter wrote: > >The purpose of DeltaIntervals are to specify specific points in time >at which an action should occur. Do you really think timing precision of nanoseconds is necessary, or even feasible for this specification? >For DeltaInterval, the property describes the interval for sampling. >My understanding is that the algorithm is identical to the algorithm >used to calculate the averaged queue depth. If my understanding of the >algorithm is flawed, then we will probably need to reconsider properties >as well. I suspect it is an error to imply a particular algorithm in the information model, even for the device model. Otherwise, an more-scalable algorithm than calculating the average at the maximimum arrival rate of the minimum packet should be considered. John From majordomo@raleigh.ibm.com Thu Oct 26 16:07:30 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15649 for ; Thu, 26 Oct 2000 16:07:30 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA31418; Thu, 26 Oct 2000 15:58:59 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA29562; Thu, 26 Oct 2000 15:58:43 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA51094; Thu, 26 Oct 2000 15:39:38 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21124; Thu, 26 Oct 2000 15:39:31 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA19792 for ; Thu, 26 Oct 2000 15:39:25 -0400 Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA07270 for ; Thu, 26 Oct 2000 15:39:00 -0400 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 15:34:14 -0400 Message-Id: From: "Weiss, Walter" To: "'John Schnizlein'" , Robert Moore/Raleigh/IBM Cc: policy@raleigh.ibm.com Subject: RE: QDIM: Changing two QoS Model properties to uint64, units = na noseconds Date: Thu, 26 Oct 2000 15:34:12 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03F83.B8DA0D1C" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03F83.B8DA0D1C Content-Type: text/plain; charset="iso-8859-1" > On Thursday, October 26, 2000 3:06 PM John Schnizlein wrote: > To: Weiss, Walter; Robert Moore/Raleigh/IBM > Cc: policy@raleigh.ibm.com > Subject: RE: QDIM: Changing two QoS Model properties to > uint64, units = > nanoseconds > > > At 11:45 AM 10/26/2000 -0400, Weiss, Walter wrote: > > > >The purpose of DeltaIntervals are to specify specific points in time > >at which an action should occur. > > Do you really think timing precision of nanoseconds is necessary, > or even feasible for this specification? > Do you think microseconds are enough for the queue depth averaging function? If the algorithm is different from that one, this aspect of the discussion is not relevant. > >For DeltaInterval, the property describes the interval for sampling. > >My understanding is that the algorithm is identical to the algorithm > >used to calculate the averaged queue depth. If my > understanding of the > >algorithm is flawed, then we will probably need to > reconsider properties > >as well. > > I suspect it is an error to imply a particular algorithm in > the information > model, even for the device model. Otherwise, an more-scalable > algorithm > than calculating the average at the maximimum arrival rate of > the minimum > packet should be considered. Algorithms always influence the management parameters. That is why there are different parameters for different classes of schedulers, meters, droppers, etc. Further, an algorithm does not necessarily translate to an implementation. If you want to propose a different set of parameters such that the semantics of the algorithm can be supported, I'm ok with that. regards, -Walter ------_=_NextPart_001_01C03F83.B8DA0D1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: QDIM: Changing two QoS Model properties to uint64, units =3D = nanoseconds

> On Thursday, October 26, 2000 3:06 PM John = Schnizlein wrote:
> To: Weiss, Walter; Robert = Moore/Raleigh/IBM
> Cc: policy@raleigh.ibm.com
> Subject: RE: QDIM: Changing two QoS Model = properties to
> uint64, units =3D
> nanoseconds
>
>
> At 11:45 AM 10/26/2000 -0400, Weiss, Walter = wrote:
> >
> >The purpose of DeltaIntervals are to = specify specific points in time
> >at which an action should occur.
>
> Do you really think timing precision of = nanoseconds is necessary,
> or even feasible for this specification?
>
Do you think microseconds are enough for the queue = depth averaging function? If the algorithm is different from that one, = this aspect of the discussion is not relevant.

 
> >For DeltaInterval, the property describes = the interval for sampling.
> >My understanding is that the algorithm is = identical to the algorithm
> >used to calculate the averaged queue depth. = If my
> understanding of the
> >algorithm is flawed, then we will probably = need to
> reconsider properties
> >as well.
>
> I suspect it is an error to imply a particular = algorithm in
> the information
> model, even for the device model. Otherwise, an = more-scalable
> algorithm
> than calculating the average at the maximimum = arrival rate of
> the minimum
> packet should be considered.

Algorithms always influence the management = parameters. That is why there are different parameters for different = classes of schedulers, meters, droppers, etc. Further, an = algorithm  does not necessarily translate to an implementation. If = you want to propose a different set of parameters such that the = semantics of the algorithm can be supported, I'm ok with = that.

regards,

-Walter

------_=_NextPart_001_01C03F83.B8DA0D1C-- From majordomo@raleigh.ibm.com Thu Oct 26 17:26:57 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00396 for ; Thu, 26 Oct 2000 17:26:56 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA18366; Thu, 26 Oct 2000 17:15:11 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id RAA29266; Thu, 26 Oct 2000 17:14:39 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15152; Thu, 26 Oct 2000 16:55:07 -0400 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA50464; Thu, 26 Oct 2000 16:55:03 -0400 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA14012 for ; Thu, 26 Oct 2000 16:55:08 -0400 Received: from bor.ellacoya.com (216-064-109-139.inaddr.vitts.com [216.64.109.139]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id QAA19092 for ; Thu, 26 Oct 2000 16:55:06 -0400 Received: by bor.ellacoya.com with Internet Mail Service (5.5.2650.21) id ; Thu, 26 Oct 2000 16:50:17 -0400 Message-Id: From: "Weiss, Walter" To: "'John Schnizlein'" , Robert Moore/Raleigh/IBM Cc: policy@raleigh.ibm.com Subject: RE: QDIM: Changing two QoS Model properties to uint64, units = na noseconds Date: Thu, 26 Oct 2000 16:50:15 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03F8E.5852AFB6" Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: "Weiss, Walter" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C03F8E.5852AFB6 Content-Type: text/plain; charset="iso-8859-1" John, > The point here was the timing precision of policy actions; the > averaging function is a different question (below). Is it reasonable > to attempt to specify the timing of a policy action to the precision > of nanoseconds? .. microseconds? > The precision of the policy has nothing to do with it. This describes the precision of the averaging function of a meter in one or more devices. If we want to change the averaging interval in a set of routers through a policy, you would use this property to make the change. > My opinion is that implying a particular algorithm for computing the > moving average queue depth in an information model that might become > standards-track is wrong. > Why. AF is described in terms of a very specific algorithm (probablistic droppers). The MIB specifies those attributes necessary to configure the majority of probablistic droppers. I believe the MIB is standards track. > The choice of algorithm is essentially an implementation decision. > My advice is that it is silly to recompute frequently the > average that > is intended to discriminate long-term congestion from expected bursts. > If you wanted the rapidly-changing queue depth, you wouldn't average. > Implying silly implementation in the information model is a good way > to get people to ignore it. > This is exactly the way that the majority of RED droppers work and how the DS MIB describes it. As a matter of fact, the interval attribute specified in the MIB is to allow algorithmic flexibility should implementations not wish to calculate the average every time a packet is sent. > John > ------_=_NextPart_001_01C03F8E.5852AFB6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: QDIM: Changing two QoS Model properties to uint64, units =3D = nanoseconds

John,

> The point here was the timing precision of = policy actions; the
> averaging function is a different question = (below). Is it reasonable
> to attempt to specify the timing of a policy = action to the precision
> of nanoseconds? .. microseconds?
>
The precision of the policy has nothing to do with = it. This describes the precision of the averaging function of a meter = in one or more devices. If we want to change the averaging interval in = a set of routers through a policy, you would use this property to make = the change.

> My opinion is that implying a particular = algorithm for computing the
> moving average queue depth in an information = model that might become
> standards-track is wrong.
>
Why. AF is described in terms of a very specific = algorithm (probablistic droppers). The MIB specifies those attributes = necessary to configure the majority of probablistic droppers. I believe = the MIB is standards track.

> The choice of algorithm is essentially an = implementation decision.
> My advice is that it is silly to recompute = frequently the
> average that
> is intended to discriminate long-term = congestion from expected bursts.
> If you wanted the rapidly-changing queue depth, = you wouldn't average.
> Implying silly implementation in the = information model is a good way
> to get people to ignore it.
>
This is exactly the way that the majority of RED = droppers work and how the DS MIB describes it. As a matter of fact, the = interval attribute specified in the MIB is to allow algorithmic = flexibility should implementations not wish to calculate the average = every time a packet is sent.

> John
>

------_=_NextPart_001_01C03F8E.5852AFB6-- From majordomo@raleigh.ibm.com Fri Oct 27 06:32:40 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03580 for ; Fri, 27 Oct 2000 06:32:40 -0400 (EDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id GAA24516; Fri, 27 Oct 2000 06:22:49 -0400 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id GAA32272; Fri, 27 Oct 2000 06:22:47 -0400 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA34310; Fri, 27 Oct 2000 06:02:12 -0400 Received: from rtpmail01.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA46330; Fri, 27 Oct 2000 06:02:09 -0400 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id GAA27464 for ; Fri, 27 Oct 2000 06:02:08 -0400 Received: from web1905.mail.yahoo.com (web1905.mail.yahoo.com [128.11.23.54]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id GAA31872 for ; Fri, 27 Oct 2000 06:02:05 -0400 Received: (qmail 3328 invoked by uid 60001); 27 Oct 2000 10:02:05 -0000 Message-Id: <20001027100205.3327.qmail@web1905.mail.yahoo.com> Received: from [198.206.187.100] by web1905.mail.yahoo.com; Fri, 27 Oct 2000 03:02:05 PDT Date: Fri, 27 Oct 2000 03:02:05 -0700 (PDT) From: Mahadevan Iyer Subject: Re: PQIM draft issues To: Ron Cohen , Yoram Ramberg , "Weiss, Walter" , policy@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer > >>(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. I had tried to raise a related issue at the last IETF meeting but am still looking for a home for an information model that cuts across these functions. Each of these functions (firewall, bandwidth management, NAT, IPSEC etc) tend to use the same building blocks and are often clubbed together by choice or by necessity. In such cases there is a need for an information model that had a common policy condition clause, with several action clauses related to each supported function. Further more instead of redefining the QoS actions here as well as the RAP WG, or IPSEC policies in the IPSEC WG, it would make more sense to ask them to plug in their actions into a common policy framework. > > > >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. > > I will stop here and point you to a draft sent out earlier for those interested in reading further. http://www.ietf.org/internet-drafts/draft-iyer-policy-ipvpn-info-model-00.txt I expect to put out a new revision soon, but I would like to draw your attention to the general purpose of the draft. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ From majordomo@raleigh.ibm.com Sun Oct 29 04:56:50 2000 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17557 for ; Sun, 29 Oct 2000 04:56:50 -0500 (EST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA20636; Sun, 29 Oct 2000 04:42:53 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id EAA13910; Sun, 29 Oct 2000 04:42:52 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA29392; Sun, 29 Oct 2000 04:13:40 -0500 Received: from rtpmail03.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA54090; Sun, 29 Oct 2000 04:13:30 -0500 Received: from fwns2.raleigh.ibm.com (fwns2.raleigh.ibm.com [9.37.0.4]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id EAA08094 for ; Sun, 29 Oct 2000 04:13:34 -0500 Received: from cisco.com (csi-admin1.cisco.com [144.254.91.12]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id EAA35806 for ; Sun, 29 Oct 2000 04:13:28 -0500 Received: from yramberg-hpxu.cisco.com (telaviv3-dhcp65.cisco.com [144.254.93.193]) by cisco.com (8.8.4-Cisco.1/8.8.8) with ESMTP id LAA29468; Sun, 29 Oct 2000 11:12:41 +0200 (IST) Message-Id: <4.3.2.7.2.20001029090823.00d94d10@csi-admin1.cisco.com> X-Sender: yramberg@csi-admin1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 Oct 2000 10:09:48 -0500 To: Mahadevan Iyer , Ron Cohen , "Weiss, Walter" , policy@raleigh.ibm.com From: Yoram Ramberg Subject: Re: PQIM draft issues In-Reply-To: <20001027100205.3327.qmail@web1905.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Yoram Ramberg 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) 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 the document that should be discussed. Some have opined that a certain portion of the QPIM specification (draft-ietf-policy-qos-info-model-01.txt, a -02 revision should be available very soon) actually belongs in PCIM due to its generic nature. 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. 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...). 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. 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. Thanx, *Yoram At 03:02 AM 10/27/00 -0700, Mahadevan Iyer wrote: > > >>(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. > >I had tried to raise a related issue at the last IETF >meeting but am still looking for a home for an >information model that cuts across these functions. >Each of these functions (firewall, bandwidth >management, NAT, IPSEC etc) tend to use the same >building blocks and are often clubbed together by >choice or by necessity. > >In such cases there is a need for an information model >that had a common policy condition clause, with >several action clauses related to each supported >function. > >Further more instead of redefining the QoS actions >here as well as the RAP WG, or IPSEC policies in the >IPSEC WG, it would make more sense to ask them to plug >in their actions into a common policy framework. > > > > > > >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. > > > > >I will stop here and point you to a draft sent out >earlier for those interested in reading further. > >http://www.ietf.org/internet-drafts/draft-iyer-policy-ipvpn-info-model-00.txt > >I expect to put out a new revision soon, but I would >like to draw your attention to the general purpose of >the draft. > >Thanks > > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Messenger - Talk while you surf! It's FREE. >http://im.yahoo.com/ From majordomo@raleigh.ibm.com Mon Oct 30 02:21:26 2000 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27326 for ; Mon, 30 Oct 2000 02:21:25 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id CAA24240; Mon, 30 Oct 2000 02:02:22 -0500 Received: from rtpaix11.raleigh.ibm.com (rtpaix11.raleigh.ibm.com [9.37.172.4]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id CAA23806; Mon, 30 Oct 2000 02:02:08 -0500 Received: by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA38024; Mon, 30 Oct 2000 01:29:50 -0500 Received: from rtpmail02.raleigh.ibm.com by rtpaix11.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA43644; Mon, 30 Oct 2000 01:29:35 -0500 Received: from fwns1.raleigh.ibm.com (fwns1.raleigh.ibm.com [9.37.0.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id BAA34788 for ; Mon, 30 Oct 2000 01:29:39 -0500 Received: from web1906.mail.yahoo.com (web1906.mail.yahoo.com [128.11.23.67]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with SMTP id BAA33986 for ; Mon, 30 Oct 2000 01:29:37 -0500 Received: (qmail 7049 invoked by uid 60001); 30 Oct 2000 06:29:36 -0000 Message-Id: <20001030062936.7048.qmail@web1906.mail.yahoo.com> Received: from [198.206.187.100] by web1906.mail.yahoo.com; Sun, 29 Oct 2000 22:29:36 PST Date: Sun, 29 Oct 2000 22:29:36 -0800 (PST) From: Mahadevan Iyer Subject: Re: PQIM draft issues To: Yoram Ramberg , Ron Cohen , "Weiss, Walter" , policy@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: policy-owner@raleigh.ibm.com Precedence: bulk Reply-To: Mahadevan Iyer 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/