From owner-psamp@ops.ietf.org Thu Dec 01 10:58:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhqpF-00071s-Nr for psamp-archive@megatron.ietf.org; Thu, 01 Dec 2005 10:58:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08727 for ; Thu, 1 Dec 2005 10:57:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhqiT-000Kcr-Ok for psamp-data@psg.com; Thu, 01 Dec 2005 15:51:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EhqiQ-000KcX-Jl for psamp@ops.ietf.org; Thu, 01 Dec 2005 15:51:22 +0000 Received: from [192.168.1.129] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0D2B41BAC9E for ; Thu, 1 Dec 2005 16:51:20 +0100 (CET) Date: Thu, 01 Dec 2005 16:51:03 +0100 From: Juergen Quittek To: psamp@ops.ietf.org Subject: draft minutes of PSAMP session at IETF #64 Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-psamp@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, Draft minutes of our session in Vancouver are available at . Please check them and send your comments to this list. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Dec 07 12:39:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3GV-0005Rv-5M for psamp-archive@megatron.ietf.org; Wed, 07 Dec 2005 12:39:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03719 for ; Wed, 7 Dec 2005 12:38:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek372-000Ba4-DC for psamp-data@psg.com; Wed, 07 Dec 2005 17:29:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, HTML_10_20,HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek371-000BZq-Dx for psamp@ops.ietf.org; Wed, 07 Dec 2005 17:29:51 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB7HToS18483 for ; Wed, 7 Dec 2005 12:29:50 -0500 (EST) Received: from [10.61.65.69] (ams-clip-vpn-dhcp325.cisco.com [10.61.65.69]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB7HTnC29918 for ; Wed, 7 Dec 2005 18:29:49 +0100 (CET) Message-ID: <43971C0C.7080101@cisco.com> Date: Wed, 07 Dec 2005 18:29:48 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: psamp Subject: Uniform Probabilistic Sampling in PSAMP-PROTO Content-Type: multipart/alternative; boundary="------------000907020703050709030704" Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------000907020703050709030704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, We're trying to model "Uniform Probabilistic Sampling" in [PSAMP-PROTO]. [PSAMP-MIB] specifies: 5.2.5. Uniform Probabilistic Sampling Capability objects are not specified for the uniform probabilistic sampling method. It has only one parameter in the psampSampUniProbParamSetTable, the psampSampUniProbProbability. This object gives the probability that a packet is sampled. The probability is equal for every packet. The given value must be divided by 4294967295 (=2^32-1), so a value of 0 means no packet is sampled (probability is 0) and a value of 4294967295 means every packet is sampled (probability is 1). psampSampUniProbProbability OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) MAX-ACCESS read-create STATUS current DESCRIPTION "This object gives the probability that a packet is sampled. The probability is equal for every packet. The given value must be divided by 4294967295 (=2^32-1), so a value of 0 means no packet is sampled (probability is 0) and a value of 4294967295 means every packet is sampled (probability is 1)." First of all, I've got an issue with the psampSampUniProbProbability MIB. How do we represent a probability of 1/2 as this number not even? Should we use a different number (1000000000), specifying a range in the SYNTAX. I think so! Initially we wanted to model the probability in [PSAMP-PROTO] with a float, which is allowed by [IPFIX-PROTO]. However, we've got the issue that SMIv2 doesn't support floats. What to do now? _Solution 1: _ We export the probability with a float, and we approximate this value with the MIB variable. _Solution 2: _ We export the probability with an unsigned32, exactly the same content as the MIB variable psampSampUniProbProbability _Solution 3: _ We export the probability with two values N, M. This means 2 inter-dependent I.E.s and 2 MIB variables instead of one. I don't like it too much I'm clearly in favor of solution 1. It's not right that we would limit IPFIX because of the limitations of SMIv2 Feedback? Side question: if we go for the float solution, should we have a float64? This would give us more precision Note: not yet defined in [IPFIX-PROTO]. Regards, Benoit. --------------000907020703050709030704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Dear all,

We're trying to model "Uniform Probabilistic Sampling" in [PSAMP-PROTO].

[PSAMP-MIB] specifies:
5.2.5. Uniform Probabilistic Sampling

Capability objects are not specified for the uniform probabilistic
sampling method. It has only one parameter in the
psampSampUniProbParamSetTable, the psampSampUniProbProbability. This
object gives the probability that a packet is sampled. The
probability is equal for every packet. The given value must be
divided by 4294967295 (=2^32-1), so a value of 0 means no packet is
sampled (probability is 0) and a value of 4294967295 means every
packet is sampled (probability is 1).

psampSampUniProbProbability OBJECT-TYPE
SYNTAX Unsigned32 (0..4294967295)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object gives the probability that a packet is sampled.
The probability is equal for every packet. The given value
must be divided by 4294967295 (=2^32-1), so a value of 0
means no packet is sampled (probability is 0) and a value of
4294967295 means every packet is sampled (probability is
1)."

First of all, I've got an issue with the psampSampUniProbProbability MIB. How do we represent a probability of 1/2 as this number not even?
Should we use a different number (1000000000), specifying a range in the SYNTAX. I think so!

Initially we wanted to model the probability in [PSAMP-PROTO] with a float, which is allowed by [IPFIX-PROTO].
However, we've got the issue that SMIv2 doesn't support floats.

What to do now?

Solution 1:
We export the probability with a float, and we approximate this value with the MIB variable.

Solution 2:
We export the probability with an unsigned32, exactly the same content as the MIB variable psampSampUniProbProbability

Solution 3:
We export the probability with two values N, M.
    This means 2 inter-dependent I.E.s and 2 MIB variables instead of one.
    I don't like it too much

I'm clearly in favor of solution 1. It's not right that we would limit IPFIX because of the limitations of SMIv2
Feedback?

Side question: if we go for the float solution, should we have a float64? This would give us more precision
Note: not yet defined in [IPFIX-PROTO].

Regards, Benoit.
--------------000907020703050709030704-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Wed Dec 07 12:45:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek3MF-0006qy-99 for psamp-archive@megatron.ietf.org; Wed, 07 Dec 2005 12:45:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04311 for ; Wed, 7 Dec 2005 12:44:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek3H0-000Cem-L2 for psamp-data@psg.com; Wed, 07 Dec 2005 17:40:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_10_20,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ek3H0-000Cea-0Z for psamp@ops.ietf.org; Wed, 07 Dec 2005 17:40:10 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB7He8r19132; Wed, 7 Dec 2005 12:40:08 -0500 (EST) Received: from [10.61.65.69] (ams-clip-vpn-dhcp325.cisco.com [10.61.65.69]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB7He7C06976; Wed, 7 Dec 2005 18:40:07 +0100 (CET) Message-ID: <43971E77.1010806@cisco.com> Date: Wed, 07 Dec 2005 18:40:07 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu, psamp Subject: Multiple identical Information Elements in a template Content-Type: multipart/alternative; boundary="------------030608010306040701060908" Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------030608010306040701060908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, During the last PSAMP IETF meeting in Vancouver, we discussed the issue of multiple identical Information Elements in a template. First of all, [IPFIX-PROTO] doesn't address the issue. However, we do realize that multiple similar I.E.s are possible in PSAMP Example 1: in a composite selector, we must export all selector IDs [PSAMP-PROTO] specifies: If the packets are selected by a Composite Selector, the Associations ID field is composed of several Primitive Selectors. In such a case, the Associations Report Interpretation MUST contain the list of all the Primitive Selector IDs in the Associations ID. Example 2: a composite selector composed of two hash functions, we might want to export both hash values in the same record. Example 3: a composite selector, we must export the input sequence number of the primitive selector. [PSAMP-PROTO] specifies: For each selected packet, the Packet Report MUST contain the following information: ... - the input sequence number(s) of any Selectors that acted on the packet There are actually 3 solutions to the problem. I classified them in order of my preference _Solution 1:_ We try to fix [IPFIX-PROTO]. I think that this is the only right solution. If IPFIX is used to export other information (IPPM? NSIS?), there is a big chance that we will face this issue again. Let me try to propose some text for this in a next email. _Solution 2:_ We overload the I.E.s like we did with the MPLS label: mplsLabelStackEntry2, mplsLabelStackEntry3, mplsLabelStackEntry4, etc... So we would have selectorId1, selectorId2, selectorId3, selectorId4, etc... The advantage is that we don't modify [IPFIX-PROTO]. The disadvantage is that we overload the information model. How many do we need? Which do we need now, as opposed to the future? _Solution 3:_ For each occurrence of a PSAMP I.E. that might be duplicated in a PSAMP record, we specify the rule in the [PSAMP-PROTO]. For example, [PSAMP-PROTO] specifies: If the packets are selected by a Composite Selector, the Associations ID field is composed of several Primitive Selectors. In such a case, the Associations Report Interpretation MUST contain the list of all the Primitive Selector IDs in the Associations ID. If multiple Selectors are contained in the Associations Report Interpretation, the Selectors ID MUST be identified in the order they are used. The advantage is that we don't have to change [IPFIX-PROTO]. The disadvantage is that we put some more PSAMP rules on the top of IPFIX. What now if IPFIX is used by another protocol (example: NSIS) that requires the extra set of PSAMP rules? Shall we say that the we use the PSAMP protocol and not the IPFIX protocol? This doesn't work too well. I think that we should keep the IPFIX rules in [IPFIX-PROTO] Feedback? Regards, Benoit. --------------030608010306040701060908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

During the last PSAMP IETF meeting in Vancouver, we discussed the issue of multiple identical Information Elements in a template.

First of all, [IPFIX-PROTO] doesn't address the issue.
However, we do realize that multiple similar I.E.s are possible in PSAMP
Example 1: in a composite selector, we must export all selector IDs
    [PSAMP-PROTO] specifies:
   If the packets are selected by a Composite Selector, the Associations 
   ID field is composed of several Primitive Selectors. In such a case, 
   the Associations Report Interpretation MUST contain the list of all 
   the Primitive Selector IDs in the Associations ID.

Example 2: a composite selector composed of two hash functions, we might want to export both hash values in the same record.
Example 3: a composite selector, we must export the input sequence number of the primitive selector.
    [PSAMP-PROTO] specifies:
   For each selected packet, the Packet Report MUST contain the 
   following information: 
   ...
   - the input sequence number(s) of any Selectors that acted on the 
   packet   

There are actually 3 solutions to the problem. I classified them in order of my preference
Solution 1:
We try to fix [IPFIX-PROTO]. I think that this is the only right solution. If IPFIX is used to export other information (IPPM? NSIS?), there is a big chance that we will face this issue again.
Let me try to propose some text for this in a next email.

Solution 2:
We overload the I.E.s like we did with the MPLS label: mplsLabelStackEntry2, mplsLabelStackEntry3, mplsLabelStackEntry4, etc...
So we would have selectorId1, selectorId2, selectorId3, selectorId4, etc...
The advantage is that we don't modify [IPFIX-PROTO]. The disadvantage is that we overload the information model.
How many do we need? Which do we need now, as opposed to the future?

Solution 3:
For each occurrence of a PSAMP I.E. that might be duplicated in a PSAMP record, we specify the rule in the [PSAMP-PROTO].
For example, [PSAMP-PROTO] specifies:
   If the packets are selected by a Composite Selector, the Associations 
   ID field is composed of several Primitive Selectors. In such a case, 
   the Associations Report Interpretation MUST contain the list of all 
   the Primitive Selector IDs in the Associations ID.  If multiple 
   Selectors are contained in the Associations Report Interpretation, 
   the Selectors ID MUST be identified in the order they are used.
The advantage is that we don't have to change [IPFIX-PROTO].
The disadvantage is that we put some more PSAMP rules on the top of IPFIX.
What now if IPFIX is used by another protocol (example: NSIS) that requires the extra set of PSAMP rules? Shall we say that the we use the PSAMP protocol and not the IPFIX protocol? This doesn't work too well. I think that we should keep the IPFIX rules in [IPFIX-PROTO]

Feedback?

Regards, Benoit.


--------------030608010306040701060908-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Dec 08 06:19:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkJoA-0007iL-Oo for psamp-archive@megatron.ietf.org; Thu, 08 Dec 2005 06:19:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01328 for ; Thu, 8 Dec 2005 06:18:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkJhi-0007DY-GH for psamp-data@psg.com; Thu, 08 Dec 2005 11:12:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkJhh-0007DK-PE for psamp@ops.ietf.org; Thu, 08 Dec 2005 11:12:50 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB8BCmQ21698 for ; Thu, 8 Dec 2005 06:12:48 -0500 (EST) Received: from [10.61.65.148] (ams-clip-vpn-dhcp404.cisco.com [10.61.65.148]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB8BCeC00554 for ; Thu, 8 Dec 2005 12:12:40 +0100 (CET) Message-ID: <43981527.1080302@cisco.com> Date: Thu, 08 Dec 2005 12:12:39 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: psamp Subject: Open Issue 2: Field Match and Router State Filtering Content-Type: multipart/alternative; boundary="------------050305050106020500060502" Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------050305050106020500060502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, From the PSAMP meeting minutes: Open Issue #2 - Field Match and Router State Filtering From the protocol's perspective, there are no differences between the field match and router state fields. Proposal: merge both fields to simplify the protocol. Tanja: Currently, the packet selection draft separates them. Merging them is OK. It will simplify the protocol. I'm now merging "Field Match and Router State Filtering" in [PSAMP-PROTO] under "Property Match Filtering", as agreed. [PSAMP-TECH] should do the same. In [PSAMP-INFO], the selectorAlgorithm has got the following values * 1 Systematic count-based sampling * 2 Systematic time-based sampling * 3 Random n-out-of-N sampling * 4 Uniform probabilistic sampling * 5 Non-uniform probabilistic sampling * 6 Non-uniform flow state sampling * 7 Property Match filtering * 8 Hash based filtering Regards, Benoit. --------------050305050106020500060502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

From the PSAMP meeting minutes:
Open Issue #2 - Field Match and Router State Filtering
From the protocol's perspective, there are no differences between the field
match and router state fields. Proposal: merge both fields to simplify the
protocol.
Tanja: Currently, the packet selection draft separates them. Merging them
is OK. It will simplify the protocol.
I'm now merging "Field Match and Router State Filtering" in [PSAMP-PROTO] under "Property Match
Filtering", as agreed. [PSAMP-TECH] should do the same.

In [PSAMP-INFO], the selectorAlgorithm has got the following values

      *  1 Systematic count-based sampling
      *  2 Systematic time-based sampling
      *  3 Random n-out-of-N sampling
      *  4 Uniform probabilistic sampling
      *  5 Non-uniform probabilistic sampling
      *  6 Non-uniform flow state sampling
      *  7 Property Match filtering
      *  8 Hash based filtering
Regards, Benoit.
--------------050305050106020500060502-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Dec 08 07:00:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkKRz-0007Jg-3T for psamp-archive@megatron.ietf.org; Thu, 08 Dec 2005 07:00:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05708 for ; Thu, 8 Dec 2005 06:59:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkKK3-000BRa-B9 for psamp-data@psg.com; Thu, 08 Dec 2005 11:52:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkKK2-000BRK-Jg for psamp@ops.ietf.org; Thu, 08 Dec 2005 11:52:26 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB8BqPu23956 for ; Thu, 8 Dec 2005 06:52:25 -0500 (EST) Received: from [10.61.65.148] (ams-clip-vpn-dhcp404.cisco.com [10.61.65.148]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB8BqMC01290; Thu, 8 Dec 2005 12:52:22 +0100 (CET) Message-ID: <43981E76.5080709@cisco.com> Date: Thu, 08 Dec 2005 12:52:22 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: Benoit Claise CC: psamp Subject: Re: Measurement Process -> Metering Process References: <4377DDCF.4040103@cisco.com> In-Reply-To: <4377DDCF.4040103@cisco.com> Content-Type: multipart/alternative; boundary="------------070509040008060704060805" Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------070509040008060704060805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Do I understand correctly from the meeting minutes (below) that we get rid of the Reporting Process. Open Issue (not numbered): Terminology Metering Process (IPFIX) vs. Measurement Process(PSAMP) Terminology problem: When psamp started it wasn't clear that ipfix would be chosen for export, the architecture is similar but still different. What IPFIX calls "metering" is defined as "measurement" in PSAMP terminology. Juergen: Let's use term "metering" for both. Shall we also drop terms "selection process" and "reporting process"? Tanja: Keep selection process as part of metering process (is in line with IPFIX, because metering process can contain sampling/filtering). But selection process should be kept. Nick: I agree. Juergen: The changes need to be applied also to the framework draft and the packet selection draft that are currently in AD review. Without objections, I will be removing the concept of Reporting Process in [PSAMP-PROTO]. Anyway, we don't need it in the protocol. Regards, Benoit. > Tanja, Nick, and al. > > Regarding the "Measurement Process -> Metering Process" issue > discussed during the IETF meeting, I understand that: > - the Measurement Process definition disappears > - we replace all instances of Measurement Process by (IPFIX) Metering > Process > - we keep the Selection Process > > I was not too clear about the following point: > - do we keep the Reporting Process? > There is actually no information about it (no such thing such as > Reporting Process ID) > This is just a concept, right? > > Regards, Benoit. > > > -- > to unsubscribe send a message to psamp-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --------------070509040008060704060805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Do I understand correctly from the meeting minutes (below) that we get rid of the Reporting Process.
Open Issue (not numbered): Terminology Metering Process (IPFIX) vs. 
  Measurement Process(PSAMP)
Terminology problem: When psamp started it wasn't clear that ipfix would be 
chosen for export, the architecture is similar but still different. What IPFIX 
calls "metering" is defined as "measurement" in PSAMP terminology. 
Juergen: Let's use term "metering" for both.  Shall we also drop terms 
  "selection process" and "reporting process"?
Tanja: Keep selection process as part of metering process (is in line with 
  IPFIX, because metering process can contain sampling/filtering).  But 
  selection process should be kept. 
Nick: I agree.
Juergen: The changes need to be applied also to the framework draft and the
  packet selection draft that are currently in AD review.
Without objections, I will be removing the concept of Reporting Process in [PSAMP-PROTO].
Anyway, we don't need it in the protocol.

Regards, Benoit.



Tanja, Nick, and al.

Regarding the "Measurement Process -> Metering Process" issue discussed during the IETF meeting, I understand that:
- the Measurement Process definition disappears
- we replace all instances of Measurement Process by (IPFIX) Metering Process
- we keep the Selection Process

I was not too clear about the following point:
- do we keep the Reporting Process?
   There is actually no information about it (no such thing such as Reporting Process ID)
   This is just a concept, right?

Regards, Benoit.
 

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/psamp/>

--------------070509040008060704060805-- -- to unsubscribe send a message to psamp-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-psamp@ops.ietf.org Thu Dec 08 08:50:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkMAS-0008Lv-8F for psamp-archive@megatron.ietf.org; Thu, 08 Dec 2005 08:50:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16583 for ; Thu, 8 Dec 2005 08:49:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkM7M-000MOE-CS for psamp-data@psg.com; Thu, 08 Dec 2005 13:47:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0 Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkM7L-000MNp-64 for psamp@ops.ietf.org; Thu, 08 Dec 2005 13:47:27 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB8DlQO01208 for ; Thu, 8 Dec 2005 08:47:26 -0500 (EST) Received: from [10.61.65.148] (ams-clip-vpn-dhcp404.cisco.com [10.61.65.148]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB8DlPC11282 for ; Thu, 8 Dec 2005 14:47:25 +0100 (CET) Message-ID: <4398396C.8060809@cisco.com> Date: Thu, 08 Dec 2005 14:47:24 +0100 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: psamp Subject: Open Issue #7: Metering Process ID in Association ID Content-Type: multipart/alternative; boundary="------------080408060409060208020103" Sender: owner-psamp@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------080408060409060208020103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, From the meeting minutes in Vancouver: Open Issue #7: Metering Process ID in Association ID This concerns the IPFIX processes in the associations ID (section 7.1 and 7.2 of psamp-tech). The proposal is to remove "metering process ID" to avoid confusion, as no one could think of a possible scenario. Tanja: It was introduced to support multiple IPFIX proecesses sharing a selector. But since no example was found swo far where this is demanded and since it it can be done (but less efficient) without the associations by having 2 selectors, it is OK to drop it. Discussion to be concluded on the mailing list. I have remove the following sentence from the section 7.2 of [PSAMP-PROTO]: Optionally, the IPFIX processes to which the packets MAY be added to the Associations ID. Example of IPFIX processes are IPFIX Metering Process ID and IPFIX Exporting Process ID. To be consistent, [PSAMP-TECH] must also remove the notion of optional IPFIX processes from the association. Regards, Benoit. --------------080408060409060208020103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Dear all,

From the meeting minutes in Vancouver:

Open Issue #7: Metering Process ID in Association ID
This concerns the IPFIX processes in the associations ID (section 7.1 and 7.2 
of psamp-tech).  The proposal is to remove "metering process ID" to avoid 
confusion, as no one could think of a possible scenario. 
Tanja: It was introduced to support multiple IPFIX proecesses sharing a 
  selector.  But since no example was found swo far where this is  demanded 
  and since it it can be done (but less efficient) without the associations 
  by having 2 selectors, it is OK to drop it.
Discussion to be concluded on the mailing list.
I have remove the following sentence from the section 7.2 of [PSAMP-PROTO]:

Optionally, the IPFIX processes to which the packets MAY be added to the Associations ID. Example of IPFIX processes are IPFIX Metering Process ID and IPFIX Exporting Process ID.

To be consistent, [PSAMP-TECH] must also remove the notion of optional IPFIX processes from the association.
Regards, Benoit.






--------------080408060409060208020103--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Thu Dec 08 09:40:39 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkMwp-0003Kg-PR
	for psamp-archive@megatron.ietf.org; Thu, 08 Dec 2005 09:40:39 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22043
	for ; Thu, 8 Dec 2005 09:39:46 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EkMqV-0001Ur-0h
	for psamp-data@psg.com; Thu, 08 Dec 2005 14:34:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_10_20,HTML_MESSAGE,SPF_PASS autolearn=no 
	version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EkMqU-0001Ue-79
	for psamp@ops.ietf.org; Thu, 08 Dec 2005 14:34:06 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB8EY4Q04481;
	Thu, 8 Dec 2005 09:34:05 -0500 (EST)
Received: from [10.61.65.148] (ams-clip-vpn-dhcp404.cisco.com [10.61.65.148])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jB8EY1C01653;
	Thu, 8 Dec 2005 15:34:01 +0100 (CET)
Message-ID: <43984458.8070008@cisco.com>
Date: Thu, 08 Dec 2005 15:34:00 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Benoit Claise 
CC: ipfix-protocol@net.doit.wisc.edu, psamp 
Subject: Re: Multiple identical Information Elements in a template -> proposed
 IPFIX text
References: <43971E77.1010806@cisco.com>
In-Reply-To: <43971E77.1010806@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------060906040605020509060006"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------060906040605020509060006
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Replying to myself with some proposed text for the solution 1...
> Dear all,
>
> During the last PSAMP IETF meeting in Vancouver, we discussed the 
> issue of multiple identical Information Elements in a template.
>
> First of all, [IPFIX-PROTO] doesn't address the issue.
> However, we do realize that multiple similar I.E.s are possible in PSAMP
> Example 1: in a composite selector, we must export all selector IDs
>     [PSAMP-PROTO] specifies:
>    If the packets are selected by a Composite Selector, the Associations 
>    ID field is composed of several Primitive Selectors. In such a case, 
>    the Associations Report Interpretation MUST contain the list of all 
>    the Primitive Selector IDs in the Associations ID.
>
> Example 2: a composite selector composed of two hash functions, we might want to export both hash values in the same record.
> Example 3: a composite selector, we must export the input sequence number of the primitive selector.
>     [PSAMP-PROTO] specifies:
>    For each selected packet, the Packet Report MUST contain the 
>    following information: 
>    ...
>    - the input sequence number(s) of any Selectors that acted on the 
>    packet   
>
> There are actually 3 solutions to the problem. I classified them in 
> order of my preference
> _Solution 1:_
> We try to fix [IPFIX-PROTO]. I think that this is the only right 
> solution. If IPFIX is used to export other information (IPPM? NSIS?), 
> there is a big chance that we will face this issue again.
> Let me try to propose some text for this in a next email.
In section 8 "Template Management", after the following paragraph...

   If a specific Information Element is required by a Template but is 
   not available in observed packets, the Exporting Process MAY choose 
   to export Flow Records without this Information Element in a Data 
   Record defined by a new Template. 

I would add:

   If an Information Element is required more than once in Template,
   the different occurrences of this Information Element SHOULD follow
   the logical order of their treatments by the Metering Process.
   For example, if a selected packet goes through two hash functions,
   and if the two hash values are sent within a single template, the 
   first occurrence of the hash value should belong to the first hash
   function in the Metering Process. For example, when exporting the 
   two source IP addresses of an IPv4 in IPv4 packets, the first 
   sourceIPv4Address Information Element occurrence should be the IPv4
   address of the outer header, while the second occurrence should be 
   the inner header one.

In section 9 "The Collecting Process's Side", at the very end, I would add:

     The Collector MUST support the use of Templates containing multiple 
occurrences of
     the similar Information Elements.

Note: this text should solve the section 3.1.2.1 
"Multiple IE of same field type" open issue in draft-boschi-ipfix-implementation-guidelines-00.txt 

Regards, Benoit.
>
> _Solution 2:_
> We overload the I.E.s like we did with the MPLS label: 
> mplsLabelStackEntry2, mplsLabelStackEntry3, mplsLabelStackEntry4, etc...
> So we would have selectorId1, selectorId2, selectorId3, selectorId4, 
> etc...
> The advantage is that we don't modify [IPFIX-PROTO]. The disadvantage 
> is that we overload the information model.
> How many do we need? Which do we need now, as opposed to the future?
>
> _Solution 3:_
> For each occurrence of a PSAMP I.E. that might be duplicated in a 
> PSAMP record, we specify the rule in the [PSAMP-PROTO].
> For example, [PSAMP-PROTO] specifies:
>    If the packets are selected by a Composite Selector, the Associations 
>    ID field is composed of several Primitive Selectors. In such a case, 
>    the Associations Report Interpretation MUST contain the list of all 
>    the Primitive Selector IDs in the Associations ID.  If multiple 
>    Selectors are contained in the Associations Report Interpretation, 
>    the Selectors ID MUST be identified in the order they are used. 
> The advantage is that we don't have to change [IPFIX-PROTO].
> The disadvantage is that we put some more PSAMP rules on the top of 
> IPFIX.
> What now if IPFIX is used by another protocol (example: NSIS) that 
> requires the extra set of PSAMP rules? Shall we say that the we use 
> the PSAMP protocol and not the IPFIX protocol? This doesn't work too 
> well. I think that we should keep the IPFIX rules in [IPFIX-PROTO]
>
> Feedback?
>
> Regards, Benoit.
>
>


--------------060906040605020509060006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Replying to myself with some proposed text for the solution 1...



  
Dear all,

  

During the last PSAMP IETF meeting in Vancouver, we discussed the issue
of multiple identical Information Elements in a template.

  

First of all, [IPFIX-PROTO] doesn't address the issue.

However, we do realize that multiple similar I.E.s are possible in PSAMP

Example 1: in a composite selector, we must export all selector IDs

    [PSAMP-PROTO] specifies:

  
   If the packets are selected by a Composite Selector, the Associations 
   ID field is composed of several Primitive Selectors. In such a case, 
   the Associations Report Interpretation MUST contain the list of all 
   the Primitive Selector IDs in the Associations ID.

Example 2: a composite selector composed of two hash functions, we might want to export both hash values in the same record.
Example 3: a composite selector, we must export the input sequence number of the primitive selector.
    [PSAMP-PROTO] specifies:
   For each selected packet, the Packet Report MUST contain the 
   following information: 
   ...
   - the input sequence number(s) of any Selectors that acted on the 
   packet   

  

There are actually 3 solutions to the problem. I classified them in
order of my preference

  Solution 1:

We try to fix [IPFIX-PROTO]. I think that this is the only right
solution. If IPFIX is used to export other information (IPPM? NSIS?),
there is a big chance that we will face this issue again.

Let me try to propose some text for this in a next email.



In section 8 "Template Management", after the following paragraph...


   If a specific Information Element is required by a Template but is 
   not available in observed packets, the Exporting Process MAY choose 
   to export Flow Records without this Information Element in a Data 
   Record defined by a new Template. 

I would add:


   If an Information Element is required more than once in Template,
   the different occurrences of this Information Element SHOULD follow
   the logical order of their treatments by the Metering Process.
   For example, if a selected packet goes through two hash functions,
   and if the two hash values are sent within a single template, the 
   first occurrence of the hash value should belong to the first hash
   function in the Metering Process. For example, when exporting the 
   two source IP addresses of an IPv4 in IPv4 packets, the first 
   sourceIPv4Address Information Element occurrence should be the IPv4
   address of the outer header, while the second occurrence should be 
   the inner header one.

In section 9 "The Collecting Process's Side", at the very end, I would add:


     The Collector MUST support the use of Templates
containing
multiple occurrences of 

     the similar Information Elements. 




Note: this text should solve the section 3.1.2.1 
"Multiple IE of same field type" open issue in draft-boschi-ipfix-implementation-guidelines-00.txt 

Regards, Benoit.




  Solution 2:

We overload the I.E.s like we did with the MPLS label:
mplsLabelStackEntry2, mplsLabelStackEntry3, mplsLabelStackEntry4, etc...

So we would have selectorId1, selectorId2, selectorId3, selectorId4,
etc...

The advantage is that we don't modify [IPFIX-PROTO]. The disadvantage
is that we overload the information model.

How many do we need? Which do we need now, as opposed to the future?

  

  Solution 3:

For each occurrence of a PSAMP I.E. that might be duplicated in a PSAMP
record, we specify the rule in the [PSAMP-PROTO].

For example, [PSAMP-PROTO] specifies:

  
   If the packets are selected by a Composite Selector, the Associations 
   ID field is composed of several Primitive Selectors. In such a case, 
   the Associations Report Interpretation MUST contain the list of all 
   the Primitive Selector IDs in the Associations ID.  If multiple 
   Selectors are contained in the Associations Report Interpretation, 
   the Selectors ID MUST be identified in the order they are used. 

The advantage is that we don't have to change [IPFIX-PROTO]. 

The disadvantage is that we put some more PSAMP rules on the top of
IPFIX. 

What now if IPFIX is used by another protocol (example: NSIS) that
requires the extra set of PSAMP rules? Shall we say that the we use the
PSAMP protocol and not the IPFIX protocol? This doesn't work too well.
I think that we should keep the IPFIX rules in [IPFIX-PROTO]

  

Feedback?

  

Regards, Benoit.

  

  








--------------060906040605020509060006--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Thu Dec 08 11:58:23 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EkP67-0005v9-3O
	for psamp-archive@megatron.ietf.org; Thu, 08 Dec 2005 11:58:23 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10030
	for ; Thu, 8 Dec 2005 11:57:21 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EkP1t-000GqK-45
	for psamp-data@psg.com; Thu, 08 Dec 2005 16:54:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	SPF_PASS autolearn=no version=3.1.0
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EkP1s-000Gpu-EB
	for psamp@ops.ietf.org; Thu, 08 Dec 2005 16:54:00 +0000
Received: from ams-core-1.cisco.com ([144.254.224.150])
  by ams-iport-1.cisco.com with ESMTP; 08 Dec 2005 17:53:59 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB8GruFZ029676;
	Thu, 8 Dec 2005 17:53:57 +0100 (MET)
Received: from [144.254.153.68] (dhcp-144-254-153-68.cisco.com [144.254.153.68])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA14103;
	Thu, 8 Dec 2005 16:53:56 GMT
Message-ID: <43986523.7040803@cisco.com>
Date: Thu, 08 Dec 2005 16:53:55 +0000
From: Andrew Johnson 
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Benoit Claise 
CC: psamp 
Subject: Re: Uniform Probabilistic Sampling in PSAMP-PROTO
References: <43971C0C.7080101@cisco.com>
In-Reply-To: <43971C0C.7080101@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Benoit Claise wrote:
[SNIP]
> Initially we wanted to model the probability in [PSAMP-PROTO] with a 
> float, which is allowed by [IPFIX-PROTO].
> However, we've got the issue that SMIv2 doesn't support floats.

Although the floating point type is not a base type in SMI there are
a couple of proposals about how to send them.  This extract is from
the comp.protocols.snmp SNMP FAQ:

  http://www.faqs.org/faqs/snmp-faq/part2/
  ===============================================================
  2.40.04
  SUBJECT: Floating Point Numbers in SMI?

  You cannot add new base types to the SMI.

  For now, the easiest way to have floating point numbers
  in SNMP MIBs is to use the base type OCTET STRING and
  encode the value in ASCII.

  This is not the most elegant approach. However, it will work
  between your agent and your management application and it will
  be compliant to the SNMP SMI and protocol specifications.

  David Perkins
  ===============================================================

Apparently this method is implemented in the NET-SNMP agent and
manager.
  (http://ops.ietf.org/lists/mreview/mreview.2004/msg00083.html)

Whether we use the above suggested method or define a new way of
using unsigned32 the application will have to have some way of
converting that number before it can be used.


> What to do now?
> 
> _Solution 1: _
> We export the probability with a float, and we approximate this value 
> with the MIB variable.
> 
> _Solution 2: _
> We export the probability with an unsigned32, exactly the same content 
> as the MIB variable psampSampUniProbProbability
> 
> _Solution 3: _
> We export the probability with two values N, M.
>     This means 2 inter-dependent I.E.s and 2 MIB variables instead of one.
>     I don't like it too much
> 
> I'm clearly in favor of solution 1. It's not right that we would limit 
> IPFIX because of the limitations of SMIv2
> Feedback?
> 
> Side question: if we go for the float solution, should we have a 
> float64? This would give us more precision
> Note: not yet defined in [IPFIX-PROTO].

FYI:
The 32-bit float has 24 bits of precision, i.e. roughly +/-0.000006%.
The 64-bit float has 53 bits of precision, i.e. roughly +/-0.00000000000001%

regards

Andrew

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Sat Dec 10 10:37:05 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1El6mT-00025n-6p
	for psamp-archive@megatron.ietf.org; Sat, 10 Dec 2005 10:37:05 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06537
	for ; Sat, 10 Dec 2005 10:35:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1El6c3-000NRR-WC
	for psamp-data@psg.com; Sat, 10 Dec 2005 15:26:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_NJABL_PROXY 
	autolearn=no version=3.1.0
Received: from [193.175.80.156] (helo=mail.anderson.de)
	by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EklNS-0009us-83
	for psamp@ops.ietf.org; Fri, 09 Dec 2005 16:45:46 +0000
Received: from dslc-082-082-067-242.pools.arcor-ip.net ([82.82.67.242] helo=[192.168.0.3])
	by mail.anderson.de with esmtpa (Exim 4.51)
	id 1EklNF-00050P-7K; Fri, 09 Dec 2005 17:45:34 +0100
Message-ID: <4399B4B2.5060204@CS.Uni-Goettingen.DE>
Date: Fri, 09 Dec 2005 17:45:38 +0100
From: Sven Anderson 
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: Benoit Claise 
CC: ipfix-protocol@net.doit.wisc.edu, psamp 
Subject: Re: [ipfix-protocol] Re: Multiple identical Information Elements
 in a template -> proposed IPFIX text
References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com>
In-Reply-To: <43984458.8070008@cisco.com>
Content-Type: multipart/mixed;
 boundary="------------070807030508010407080203"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------070807030508010407080203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Dear Benoit and all,

Benoit Claise wrote:
> I would add:
> 
>    If an Information Element is required more than once in Template,
>    the different occurrences of this Information Element SHOULD follow
>    the logical order of their treatments by the Metering Process.
>    For example, if a selected packet goes through two hash functions,
>    and if the two hash values are sent within a single template, the 
>    first occurrence of the hash value should belong to the first hash
>    function in the Metering Process. For example, when exporting the 
>    two source IP addresses of an IPv4 in IPv4 packets, the first 
>    sourceIPv4Address Information Element occurrence should be the IPv4
>    address of the outer header, while the second occurrence should be 
>    the inner header one.
> 
> In section 9 "The Collecting Process's Side", at the very end, I would add:
> 
>      The Collector MUST support the use of Templates containing multiple 
> occurrences of
>      the similar Information Elements.

Isn't that quite exactly what I proposed in my mail of 2005/08/04? It 
was a long mail I admit, so maybe nobody read it. ;-) That mail is 
attached, if somebody now is interested to read it.

But doesn't make this all the post-/pre- I.E. discussion obsolete? 
Wouldn't it be enough just to export two I.E. of the same type? Of 
course, with the post-I.E. you have more semantics. But wouldn't it be 
better to give this semantics by other means?

But there are certain amiguities. For instance in your example (IP in 
IP), if you also export the packet size (for single packet reports) or 
in octet counters in general, is it corresponding to the outer or the 
inner packet? That's why I also proposed a kind of separator I.E. with 
length 0, which separates different groups of I.E. in the template.  And 
in each group, every I.E. MUST appear only one time. That way you always 
know which I.E. belong together.

Template example:


** (pseudo I.E. with length 0)


That way it's clear, that the counter corresponds to the first packet 
state size, which in the IP in IP scenario is the outer packet size.

Jurgen stated to my proposal, that you try to avoid more complex 
concepts if possible. But as it seems, it's getting more complex anyway.


Cheers,

Sven

-- 
Sven Anderson
Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de
Georg-August-Universitaet Goettingen
Lotzestr. 16-18, 37083 Goettingen, Germany

--------------070807030508010407080203
Content-Type: message/rfc822;
 name="Nachricht als Anhang"
Content-Disposition: inline;
 filename="Nachricht als Anhang"

Return-path: 
Envelope-to: sven@anderson.de
Delivery-date: Thu, 04 Aug 2005 19:42:15 +0200
Received: from s2.ifi.informatik.uni-goettingen.de ([134.76.81.12])
	by mail.anderson.de with esmtp (Exim 4.20)
	id 1E0jjT-0004iP-8X
	for sven@anderson.de; Thu, 04 Aug 2005 19:42:15 +0200
Received: from localhost (localhost [127.0.0.1])
  (forwarded by sanderso@s2.ifi.informatik.uni-goettingen.de)
  by s2.ifi.informatik.uni-goettingen.de with local; Thu, 04 Aug 2005 19:42:06 +0200
  id 000AB372.42F2536E.000071E2
Delivered-To: sanderso@s2.ifi.informatik.uni-goettingen.de
Received: from mailer.gwdg.de (mailer.gwdg.de [::ffff:134.76.10.26])
  (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA)
  by s2.ifi.informatik.uni-goettingen.de with esmtp; Thu, 04 Aug 2005 19:42:06 +0200
  id 000AB337.42F2536E.000071DB
Received: from mil.doit.wisc.edu ([128.104.31.31])
	by mailer.gwdg.de with esmtp (Exim 4.42)
	id 1E0jjJ-00003S-By
	for Sven.Anderson@cs.uni-goettingen.de; Thu, 04 Aug 2005 19:42:06 +0200
Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1)
	id 1E0jAR-0000kb-00
	for ipfix-list@mil.doit.wisc.edu; Thu, 04 Aug 2005 12:06:03 -0500
Received: from cweg03.cweg.stud.uni-goettingen.de ([134.76.63.99] helo=mail.anderson.de)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1E0jAP-0000kW-00
	for ipfix-info@net.doit.wisc.edu; Thu, 04 Aug 2005 12:06:02 -0500
Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180])
	by mail.anderson.de with asmtp (Exim 4.20)
	id 1E0jAJ-0004cv-0g
	for ipfix-info@net.doit.wisc.edu; Thu, 04 Aug 2005 19:05:55 +0200
Message-ID: <42F24AE6.9060900@CS.Uni-Goettingen.DE>
Date: Thu, 04 Aug 2005 19:05:42 +0200
From: Sven Anderson 
Organization: Institute for Informatics Goettingen
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322)
X-Accept-Language: de-DE, de, en-us, en
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15; format=flowed
To: ipfix-info@net.doit.wisc.edu
Subject: [ipfix-info] Proposal for IFPIX observations at middleboxes
Precedence: bulk
Sender: majordomo listserver 
X-Callback-Status: (ok)
X-Spam-Level: /
X-Spam-Report: Content analysis: 0.0 points, 6.0 required
X-Virus-Scanned: (clean) by exiscan+sophie
X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.47
X-Warning: 134.76.81.12 is listed at bl.spamcops.net
X-Bogosity: No, tests=bogofilter, spamicity=0.500001, version=0.92.8
Content-Transfer-Encoding: quoted-printable

Hi all,

I will try to explain again my idea for reporting flows from middleboxes
as clear and short(?) as possible:

When IP packets travel through a middlebox, their properties may change.
Examples would be TTL, IP adresses (NAT), DSCP or even fragmentation or
replication (multicasting). That means, that if an Observation Domain
includes several Observation Points, and the same packet passes more tha=
n
one of these Observation Points, some properties can be ambiguous in thi=
s
Observation Domain.

You could solve this by saying, that every propery of a flow-report
has to derive from the same observation point. But this would be
restrictive. Sometimes it is desirable, that you can classify a single
Flow by properties, that derive from _different_ Observation Points. For
example a flow-definition that includes the source IP address before and
after a NAT, or the DSCP at three different Observation Points (before
ingress linecard, after ingress linecard, after egress linecard).

To realise this, you need a way to use certain properties more than one
time in a flow-template, to correspond to the different states at the
different Observation Points. One way to do this, is the introduction of
additional post- I.E.s, which then correspond to the first and the last
Observation Point in the Observation Domain. But this is a restriction t=
o
two special Observation Points, and the second example from above is not
solvable with this approach.

A more general solution would be to allow the use of the same I.E. more
than one time in the same template. The order of the multiple I.E.s
corresponds to the different observations as the packet travels through
the middlebox. The problem here is, that you cannot tell then, to which =
of
the different observations the _singular_ I.E.s belong to.

To solve this, you need a possibility to build goups of I.E.s in the
Template: The I.E. values in one "Observation Group" always derive from
the same Observation Point (for each packet!). The Observation Groups ar=
e
ordered accordingly to the sequence of Observation Points the packet is
passing. Of course there are also fields which don't depend on the
Observation Point and can be reported in any Observation Group, like
ingressInterface (not egress!), as it is always the same, no matter wher=
e
in the middlebox the packet is observed. (You may say, that these fields
_have_ to be reported in the first group then, if this is an advantage.)

Important to note is, that packets of a Flow defined by (for example) tw=
o
Observation Groups don't necessarily pass the same sequence of two
Observation Points. They just share the same Flow poperties at the their
first and second Observation Points respectively. To make sure, that all
packets passed the same sequence of Observation Points you have to inclu=
de
an (yet to be defined) I.E. "observationPointID" as a Flow Key in each
Observation Group.

BTW.: It's possible that a Flow has the same observationPointID in
different Observation Groups. For example if your Flow contains two
Observation Groups, corresponding to Observation Points at the ingress a=
nd
egress interface, you could have Flows where ingress and egress interfac=
e
and therefore the observationPointID is the same (e.g. after some NAT).

The next question is: what is a good way to define these groups? Here ar=
e
just two ideas:

- my first idea, which I descibed in an former mail, was to define
"Combined Templates", which are a ordered list of other Templates. Each
Template in the Combined Template represents an Observation Group. The
reports for Combined Templates are just normal reports with all the Fiel=
ds
of all the listed Templates concatenated. The disadvantage is, that a
change of IPFIX-PROTO is necessary.

- another idea is to define a special separator I.E. with length 0, like
"newObservationGroup". This pseudo-field separates the Fields in the
Template into different Observation Groups. In the reports they don't
appear, but the collector has the template and knows where to split. Her=
e
no change in IPFIX-PROTO is necessary. (Jeroen Massar had a very similar=
 idea)

I think this concept is a superset of the proposals of J=FCrgen and Beno=
it.
Instead of using post-I.E.s Benoit could use Templates like this (using
the second grouping-mechanism):


[...different Fields...]


**


The DSCP field in the second ObservationGroup is the same as his postDSC=
P
field.

J=FCrgen would do it maybe like this:


**


[...different Fields...]


instead of using an preDestinationIPv4Address Field.

Why do I like this concept:

- it includes all the possibilities of the other solutions.

- you can have as many Observation Groups as you want. (I have an
VPN-Relay here, where I will need 3 Observation Groups, which is not
possible with the pre-/post- solutions.)

- it is always clear, which fields derive from the same Observation Poin=
ts
(same packet state). This is especially true for the counter Fields! You
can have even the same counter in different Observation Groups, if you
expect the packet size to be changed.

- you don't need any post-/pre- variants of the I.E.s You just need the
newObservationGroup I.E.. The observationPointID is a good idea anyway, =
I
think.

- you don't need complicated semantics, you just report an ordered
sequence of packet states. (And that's all you know, in fact.)

I'm not really sure, but I think, that the in- and out- counters also ge=
t
obsolete then. Wouldn't it be the same as having a counter in the first
and last Observation Group?

A side note: I think a packet-altering instance - like a NAT process -
which is reporting information to the metering process, should always be
seen as _two_ observation points, one before and one after the change.

Anyway, this is my "work in progress" idea. I hope I could present this
quite complex object in an understandable manner. Now tell me, why it is=
 a
bad idea. :-)


Cheers,

Sven

-- 
Sven Anderson
Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de
Georg-August-Universitaet Goettingen
Lotzestr. 16-18, 37083 Goettingen, Germany


--
Help        mailto:majordomo@net.doit.wisc.edu and say "help" in message=
 body
Unsubscribe mailto:majordomo@net.doit.wisc.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

--------------070807030508010407080203--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 16 11:14:00 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EnIDY-0004na-8G
	for psamp-archive@megatron.ietf.org; Fri, 16 Dec 2005 11:14:00 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09968
	for ; Fri, 16 Dec 2005 11:12:57 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EnI7q-000Jtu-8M
	for psamp-data@psg.com; Fri, 16 Dec 2005 16:08:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	SPF_PASS autolearn=no version=3.1.0
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EnI7o-000Jtb-RR
	for psamp@ops.ietf.org; Fri, 16 Dec 2005 16:08:05 +0000
Received: from ams-core-1.cisco.com ([144.254.224.150])
  by ams-iport-1.cisco.com with ESMTP; 16 Dec 2005 17:08:04 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBGG80FZ012576;
	Fri, 16 Dec 2005 17:08:01 +0100 (MET)
Received: from [10.61.65.73] (ams-clip-vpn-dhcp329.cisco.com [10.61.65.73])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA15854;
	Fri, 16 Dec 2005 16:07:59 GMT
Message-ID: <43A2E65E.5020800@cisco.com>
Date: Fri, 16 Dec 2005 16:07:58 +0000
From: Andrew Johnson 
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Sven Anderson 
CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu,
        psamp 
Subject: Re: [ipfix-protocol] Re: Multiple identical Information Elements
 in a template -> proposed IPFIX text
References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <4399B4B2.5060204@CS.Uni-Goettingen.DE>
In-Reply-To: <4399B4B2.5060204@CS.Uni-Goettingen.DE>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA09968

Hello Sven

Sven Anderson wrote:
> Dear Benoit and all,
>=20
> Benoit Claise wrote:
>=20
>> I would add:
>>
>>    If an Information Element is required more than once in Template,
>>    the different occurrences of this Information Element SHOULD follow
>>    the logical order of their treatments by the Metering Process.
>>    For example, if a selected packet goes through two hash functions,
>>    and if the two hash values are sent within a single template, the=20
>>    first occurrence of the hash value should belong to the first hash
>>    function in the Metering Process. For example, when exporting the=20
>>    two source IP addresses of an IPv4 in IPv4 packets, the first   =20
>> sourceIPv4Address Information Element occurrence should be the IPv4
>>    address of the outer header, while the second occurrence should be=20
>>    the inner header one.
>>
>> In section 9 "The Collecting Process's Side", at the very end, I would=
=20
>> add:
>>
>>      The Collector MUST support the use of Templates containing multip=
le occurrences of
>>      the similar Information Elements.
>=20
>=20
> Isn't that quite exactly what I proposed in my mail of 2005/08/04? It=20
> was a long mail I admit, so maybe nobody read it. ;-) That mail is=20
> attached, if somebody now is interested to read it.

I would say that the problem your proposal is trying to solve and the pro=
blem
that this proposal is trying to solve are subtely different.

You are trying to solve the issue of building a flow record with element
captured from different observation points.  The problem with using the
same I.E.s for the same field but seen in different places is that you
can't tell which entry in the record applies to which field.  Even adding
an order dependence doesn't solve this issue because there is no
requirement to put all versions of the element in the record.  This is
detailed in your proposal but your solution is quite a complex addition
to the protocol.

There is a seperate problem when it comes to having the same element
be applicable more than once at a single observation point.  Actually
there are two similar problems:

1. The same element applies more than once but you want to be able to
   selectively report only some of them.  i.e. MPLS labels.  In this
   case we have to use seperate I.E.s

2. The same element applies more than once but you need to report them
   all.

This is the issue Benoit's proposal is an attempt to solve.  For example
a classification routines may classify a packet as classes 1, 10 and 15
similtaneously because these classes have independent properties.  In
this example order may not seem important, but if you want to match the
classes with some statistics about each class then making it order
dependent allows the order of each to be alligned.


Andrew


> But doesn't make this all the post-/pre- I.E. discussion obsolete?=20
> Wouldn't it be enough just to export two I.E. of the same type? Of=20
> course, with the post-I.E. you have more semantics. But wouldn't it be=20
> better to give this semantics by other means?
>=20
> But there are certain amiguities. For instance in your example (IP in=20
> IP), if you also export the packet size (for single packet reports) or=20
> in octet counters in general, is it corresponding to the outer or the=20
> inner packet? That's why I also proposed a kind of separator I.E. with=20
> length 0, which separates different groups of I.E. in the template.  An=
d=20
> in each group, every I.E. MUST appear only one time. That way you alway=
s=20
> know which I.E. belong together.
>=20
> Template example:
> 
> 
> ** (pseudo I.E. with length 0)
> 
>=20
> That way it's clear, that the counter corresponds to the first packet=20
> state size, which in the IP in IP scenario is the outer packet size.
>=20
> J=FCrgen stated to my proposal, that you try to avoid more complex=20
> concepts if possible. But as it seems, it's getting more complex anyway.
>=20
>=20
> Cheers,
>=20
> Sven
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> Subject:
> [ipfix-info] Proposal for IFPIX observations at middleboxes
> From:
> Sven Anderson 
> Date:
> Thu, 04 Aug 2005 19:05:42 +0200
> To:
> ipfix-info@net.doit.wisc.edu
>=20
> To:
> ipfix-info@net.doit.wisc.edu
>=20
>=20
> Hi all,
>=20
> I will try to explain again my idea for reporting flows from middleboxe=
s
> as clear and short(?) as possible:
>=20
> When IP packets travel through a middlebox, their properties may change.
> Examples would be TTL, IP adresses (NAT), DSCP or even fragmentation or
> replication (multicasting). That means, that if an Observation Domain
> includes several Observation Points, and the same packet passes more th=
an
> one of these Observation Points, some properties can be ambiguous in th=
is
> Observation Domain.
>=20
> You could solve this by saying, that every propery of a flow-report
> has to derive from the same observation point. But this would be
> restrictive. Sometimes it is desirable, that you can classify a single
> Flow by properties, that derive from _different_ Observation Points. Fo=
r
> example a flow-definition that includes the source IP address before an=
d
> after a NAT, or the DSCP at three different Observation Points (before
> ingress linecard, after ingress linecard, after egress linecard).
>=20
> To realise this, you need a way to use certain properties more than one
> time in a flow-template, to correspond to the different states at the
> different Observation Points. One way to do this, is the introduction o=
f
> additional post- I.E.s, which then correspond to the first and the last
> Observation Point in the Observation Domain. But this is a restriction =
to
> two special Observation Points, and the second example from above is no=
t
> solvable with this approach.
>=20
> A more general solution would be to allow the use of the same I.E. more
> than one time in the same template. The order of the multiple I.E.s
> corresponds to the different observations as the packet travels through
> the middlebox. The problem here is, that you cannot tell then, to which=
 of
> the different observations the _singular_ I.E.s belong to.
>=20
> To solve this, you need a possibility to build goups of I.E.s in the
> Template: The I.E. values in one "Observation Group" always derive from
> the same Observation Point (for each packet!). The Observation Groups a=
re
> ordered accordingly to the sequence of Observation Points the packet is
> passing. Of course there are also fields which don't depend on the
> Observation Point and can be reported in any Observation Group, like
> ingressInterface (not egress!), as it is always the same, no matter whe=
re
> in the middlebox the packet is observed. (You may say, that these field=
s
> _have_ to be reported in the first group then, if this is an advantage.=
)
>=20
> Important to note is, that packets of a Flow defined by (for example) t=
wo
> Observation Groups don't necessarily pass the same sequence of two
> Observation Points. They just share the same Flow poperties at the thei=
r
> first and second Observation Points respectively. To make sure, that al=
l
> packets passed the same sequence of Observation Points you have to incl=
ude
> an (yet to be defined) I.E. "observationPointID" as a Flow Key in each
> Observation Group.
>=20
> BTW.: It's possible that a Flow has the same observationPointID in
> different Observation Groups. For example if your Flow contains two
> Observation Groups, corresponding to Observation Points at the ingress =
and
> egress interface, you could have Flows where ingress and egress interfa=
ce
> and therefore the observationPointID is the same (e.g. after some NAT).
>=20
> The next question is: what is a good way to define these groups? Here a=
re
> just two ideas:
>=20
> - my first idea, which I descibed in an former mail, was to define
> "Combined Templates", which are a ordered list of other Templates. Each
> Template in the Combined Template represents an Observation Group. The
> reports for Combined Templates are just normal reports with all the Fie=
lds
> of all the listed Templates concatenated. The disadvantage is, that a
> change of IPFIX-PROTO is necessary.
>=20
> - another idea is to define a special separator I.E. with length 0, lik=
e
> "newObservationGroup". This pseudo-field separates the Fields in the
> Template into different Observation Groups. In the reports they don't
> appear, but the collector has the template and knows where to split. He=
re
> no change in IPFIX-PROTO is necessary. (Jeroen Massar had a very simila=
r=20
> idea)
>=20
> I think this concept is a superset of the proposals of J=FCrgen and Ben=
oit.
> Instead of using post-I.E.s Benoit could use Templates like this (using
> the second grouping-mechanism):
>=20
> 
> [...different Fields...]
> 
> 
> **
> 
>=20
> The DSCP field in the second ObservationGroup is the same as his postDS=
CP
> field.
>=20
> J=FCrgen would do it maybe like this:
>=20
> 
> **
> 
> 
> [...different Fields...]
> 
>=20
> instead of using an preDestinationIPv4Address Field.
>=20
> Why do I like this concept:
>=20
> - it includes all the possibilities of the other solutions.
>=20
> - you can have as many Observation Groups as you want. (I have an
> VPN-Relay here, where I will need 3 Observation Groups, which is not
> possible with the pre-/post- solutions.)
>=20
> - it is always clear, which fields derive from the same Observation Poi=
nts
> (same packet state). This is especially true for the counter Fields! Yo=
u
> can have even the same counter in different Observation Groups, if you
> expect the packet size to be changed.
>=20
> - you don't need any post-/pre- variants of the I.E.s You just need the
> newObservationGroup I.E.. The observationPointID is a good idea anyway,=
 I
> think.
>=20
> - you don't need complicated semantics, you just report an ordered
> sequence of packet states. (And that's all you know, in fact.)
>=20
> I'm not really sure, but I think, that the in- and out- counters also g=
et
> obsolete then. Wouldn't it be the same as having a counter in the first
> and last Observation Group?
>=20
> A side note: I think a packet-altering instance - like a NAT process -
> which is reporting information to the metering process, should always b=
e
> seen as _two_ observation points, one before and one after the change.
>=20
> Anyway, this is my "work in progress" idea. I hope I could present this
> quite complex object in an understandable manner. Now tell me, why it i=
s a
> bad idea. :-)
>=20
>=20
> Cheers,
>=20
> Sven
>=20

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Mon Dec 19 10:04:13 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoMYe-0002h8-V7
	for psamp-archive@megatron.ietf.org; Mon, 19 Dec 2005 10:04:13 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27288
	for ; Mon, 19 Dec 2005 10:03:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EoMSm-0008Nk-Cf
	for psamp-data@psg.com; Mon, 19 Dec 2005 14:58:08 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EoMSi-0008HQ-F1
	for psamp@ops.ietf.org; Mon, 19 Dec 2005 14:58:04 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJEw3E11509;
	Mon, 19 Dec 2005 09:58:03 -0500 (EST)
Received: from [10.61.64.51] (ams-clip-vpn-dhcp51.cisco.com [10.61.64.51])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJEw0C23565;
	Mon, 19 Dec 2005 15:58:00 +0100 (CET)
Message-ID: <43A6CA78.9080506@cisco.com>
Date: Mon, 19 Dec 2005 15:58:00 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Sven Anderson 
CC: ipfix-protocol@net.doit.wisc.edu, psamp 
Subject: Re: [ipfix-protocol] Re: Multiple identical Information Elements
 in a template -> proposed IPFIX text
References: <43971E77.1010806@cisco.com> <43984458.8070008@cisco.com> <4399B4B2.5060204@CS.Uni-Goettingen.DE>
In-Reply-To: <4399B4B2.5060204@CS.Uni-Goettingen.DE>
Content-Type: multipart/alternative;
 boundary="------------030406000303010603060408"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------030406000303010603060408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA27288

Sven,

[sorry for the delay in replying to you]

Even if I agree that we will certainly have to solve the issue of=20
exporting structured records in clean way in a future IPFIX version,=20
even if I agree that your proposal is powerful, I was aiming for a quick=20
editorial change in [IPFIX-PROTO]. Let's not forget that the IPFIX=20
drafts are right now under IESG review.

Regards, Benoit.

>
> Benoit Claise wrote:
>> I would add:
>>
>>    If an Information Element is required more than once in Template,
>>    the different occurrences of this Information Element SHOULD follow
>>    the logical order of their treatments by the Metering Process.
>>    For example, if a selected packet goes through two hash functions,
>>    and if the two hash values are sent within a single template, the=20
>>    first occurrence of the hash value should belong to the first hash
>>    function in the Metering Process. For example, when exporting the=20
>>    two source IP addresses of an IPv4 in IPv4 packets, the first   =20
>> sourceIPv4Address Information Element occurrence should be the IPv4
>>    address of the outer header, while the second occurrence should be=20
>>    the inner header one.
>>
>> In section 9 "The Collecting Process's Side", at the very end, I=20
>> would add:
>>
>>      The Collector MUST support the use of Templates containing=20
>> multiple occurrences of
>>      the similar Information Elements.
>
> Isn't that quite exactly what I proposed in my mail of 2005/08/04? It=20
> was a long mail I admit, so maybe nobody read it. ;-) That mail is=20
> attached, if somebody now is interested to read it.
>
> But doesn't make this all the post-/pre- I.E. discussion obsolete?=20
> Wouldn't it be enough just to export two I.E. of the same type? Of=20
> course, with the post-I.E. you have more semantics. But wouldn't it be=20
> better to give this semantics by other means?
>
> But there are certain amiguities. For instance in your example (IP in=20
> IP), if you also export the packet size (for single packet reports) or=20
> in octet counters in general, is it corresponding to the outer or the=20
> inner packet? That's why I also proposed a kind of separator I.E. with=20
> length 0, which separates different groups of I.E. in the template. =20
> And in each group, every I.E. MUST appear only one time. That way you=20
> always know which I.E. belong together.
>
> Template example:
> 
> 
> ** (pseudo I.E. with length 0)
> 
>
> That way it's clear, that the counter corresponds to the first packet=20
> state size, which in the IP in IP scenario is the outer packet size.
>
> J=FCrgen stated to my proposal, that you try to avoid more complex=20
> concepts if possible. But as it seems, it's getting more complex anyway.
>
>
> Cheers,
>
> Sven
>
>
> -----------------------------------------------------------------------=
-
>
> Subject:
> [ipfix-info] Proposal for IFPIX observations at middleboxes
> From:
> Sven Anderson 
> Date:
> Thu, 04 Aug 2005 19:05:42 +0200
> To:
> ipfix-info@net.doit.wisc.edu
>
> To:
> ipfix-info@net.doit.wisc.edu
>
>
> Hi all,
>
> I will try to explain again my idea for reporting flows from middleboxe=
s
> as clear and short(?) as possible:
>
> When IP packets travel through a middlebox, their properties may change.
> Examples would be TTL, IP adresses (NAT), DSCP or even fragmentation or
> replication (multicasting). That means, that if an Observation Domain
> includes several Observation Points, and the same packet passes more th=
an
> one of these Observation Points, some properties can be ambiguous in th=
is
> Observation Domain.
>
> You could solve this by saying, that every propery of a flow-report
> has to derive from the same observation point. But this would be
> restrictive. Sometimes it is desirable, that you can classify a single
> Flow by properties, that derive from _different_ Observation Points. Fo=
r
> example a flow-definition that includes the source IP address before an=
d
> after a NAT, or the DSCP at three different Observation Points (before
> ingress linecard, after ingress linecard, after egress linecard).
>
> To realise this, you need a way to use certain properties more than one
> time in a flow-template, to correspond to the different states at the
> different Observation Points. One way to do this, is the introduction o=
f
> additional post- I.E.s, which then correspond to the first and the last
> Observation Point in the Observation Domain. But this is a restriction =
to
> two special Observation Points, and the second example from above is no=
t
> solvable with this approach.
>
> A more general solution would be to allow the use of the same I.E. more
> than one time in the same template. The order of the multiple I.E.s
> corresponds to the different observations as the packet travels through
> the middlebox. The problem here is, that you cannot tell then, to=20
> which of
> the different observations the _singular_ I.E.s belong to.
>
> To solve this, you need a possibility to build goups of I.E.s in the
> Template: The I.E. values in one "Observation Group" always derive from
> the same Observation Point (for each packet!). The Observation Groups a=
re
> ordered accordingly to the sequence of Observation Points the packet is
> passing. Of course there are also fields which don't depend on the
> Observation Point and can be reported in any Observation Group, like
> ingressInterface (not egress!), as it is always the same, no matter whe=
re
> in the middlebox the packet is observed. (You may say, that these field=
s
> _have_ to be reported in the first group then, if this is an advantage.=
)
>
> Important to note is, that packets of a Flow defined by (for example) t=
wo
> Observation Groups don't necessarily pass the same sequence of two
> Observation Points. They just share the same Flow poperties at the thei=
r
> first and second Observation Points respectively. To make sure, that al=
l
> packets passed the same sequence of Observation Points you have to=20
> include
> an (yet to be defined) I.E. "observationPointID" as a Flow Key in each
> Observation Group.
>
> BTW.: It's possible that a Flow has the same observationPointID in
> different Observation Groups. For example if your Flow contains two
> Observation Groups, corresponding to Observation Points at the ingress=20
> and
> egress interface, you could have Flows where ingress and egress interfa=
ce
> and therefore the observationPointID is the same (e.g. after some NAT).
>
> The next question is: what is a good way to define these groups? Here a=
re
> just two ideas:
>
> - my first idea, which I descibed in an former mail, was to define
> "Combined Templates", which are a ordered list of other Templates. Each
> Template in the Combined Template represents an Observation Group. The
> reports for Combined Templates are just normal reports with all the=20
> Fields
> of all the listed Templates concatenated. The disadvantage is, that a
> change of IPFIX-PROTO is necessary.
>
> - another idea is to define a special separator I.E. with length 0, lik=
e
> "newObservationGroup". This pseudo-field separates the Fields in the
> Template into different Observation Groups. In the reports they don't
> appear, but the collector has the template and knows where to split. He=
re
> no change in IPFIX-PROTO is necessary. (Jeroen Massar had a very=20
> similar idea)
>
> I think this concept is a superset of the proposals of J=FCrgen and Ben=
oit.
> Instead of using post-I.E.s Benoit could use Templates like this (using
> the second grouping-mechanism):
>
> 
> [...different Fields...]
> 
> 
> **
> 
>
> The DSCP field in the second ObservationGroup is the same as his postDS=
CP
> field.
>
> J=FCrgen would do it maybe like this:
>
> 
> **
> 
> 
> [...different Fields...]
> 
>
> instead of using an preDestinationIPv4Address Field.
>
> Why do I like this concept:
>
> - it includes all the possibilities of the other solutions.
>
> - you can have as many Observation Groups as you want. (I have an
> VPN-Relay here, where I will need 3 Observation Groups, which is not
> possible with the pre-/post- solutions.)
>
> - it is always clear, which fields derive from the same Observation=20
> Points
> (same packet state). This is especially true for the counter Fields! Yo=
u
> can have even the same counter in different Observation Groups, if you
> expect the packet size to be changed.
>
> - you don't need any post-/pre- variants of the I.E.s You just need the
> newObservationGroup I.E.. The observationPointID is a good idea anyway,=
 I
> think.
>
> - you don't need complicated semantics, you just report an ordered
> sequence of packet states. (And that's all you know, in fact.)
>
> I'm not really sure, but I think, that the in- and out- counters also g=
et
> obsolete then. Wouldn't it be the same as having a counter in the first
> and last Observation Group?
>
> A side note: I think a packet-altering instance - like a NAT process -
> which is reporting information to the metering process, should always b=
e
> seen as _two_ observation points, one before and one after the change.
>
> Anyway, this is my "work in progress" idea. I hope I could present this
> quite complex object in an understandable manner. Now tell me, why it=20
> is a
> bad idea. :-)
>
>
> Cheers,
>
> Sven
>


--------------030406000303010603060408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Sven,



[sorry for the delay in replying to you]



Even if I agree that we will certainly have to solve the issue of
exporting structured records in clean way in a future IPFIX version,
even if I agree that your proposal is powerful, I was aiming for a
quick editorial change in [IPFIX-PROTO]. Let's not forget that the
IPFIX drafts are right now under IESG review. 



Regards, Benoit.






Benoit Claise wrote:
  

  
I would add:
    

    

   If an Information Element is required more than once in Template,
    

   the different occurrences of this Information Element SHOULD follow
    

   the logical order of their treatments by the Metering Process.
    

   For example, if a selected packet goes through two hash functions,
    

   and if the two hash values are sent within a single template, the   
first occurrence of the hash value should belong to the first hash
    

   function in the Metering Process. For example, when exporting the   
two source IP addresses of an IPv4 in IPv4 packets, the first   
sourceIPv4Address Information Element occurrence should be the IPv4
    

   address of the outer header, while the second occurrence should be
   the inner header one.
    

    

In section 9 "The Collecting Process's Side", at the very end, I would
add:
    

    

     The Collector MUST support the use of Templates containing
multiple occurrences of
    

     the similar Information Elements.
    

  

  

Isn't that quite exactly what I proposed in my mail of 2005/08/04? It
was a long mail I admit, so maybe nobody read it. ;-) That mail is
attached, if somebody now is interested to read it.
  

  

But doesn't make this all the post-/pre- I.E. discussion obsolete?
Wouldn't it be enough just to export two I.E. of the same type? Of
course, with the post-I.E. you have more semantics. But wouldn't it be
better to give this semantics by other means?
  

  

But there are certain amiguities. For instance in your example (IP in
IP), if you also export the packet size (for single packet reports) or
in octet counters in general, is it corresponding to the outer or the
inner packet? That's why I also proposed a kind of separator I.E. with
length 0, which separates different groups of I.E. in the template. 
And in each group, every I.E. MUST appear only one time. That way you
always know which I.E. belong together.
  

  

Template example:
  

<sourceIPv4Address>
  

<octetDeltaCount>
  

*<newObservationGroup>* (pseudo I.E. with length 0)
  

<sourceIPv4Address>
  

  

That way it's clear, that the counter corresponds to the first packet
state size, which in the IP in IP scenario is the outer packet size.
  

  

Jürgen stated to my proposal, that you try to avoid more complex
concepts if possible. But as it seems, it's getting more complex
anyway.
  

  

  

Cheers,
  

  

Sven
  

  

  

  


  

    
      

        
        
Subject:
        

[ipfix-info] Proposal for IFPIX observations at middleboxes		
      

      

        
        
From: 

Sven Anderson <Sven.Anderson@CS.Uni-Goettingen.DE>		
      

      

        
        
Date: 

Thu, 04 Aug 2005 19:05:42 +0200		
      

      

        
        
To: 

ipfix-info@net.doit.wisc.edu		
      

    
  

  

    
      

        
        
To: 

ipfix-info@net.doit.wisc.edu		
      

    
  

  

Hi all,
  

  

I will try to explain again my idea for reporting flows from
middleboxes
  

as clear and short(?) as possible:
  

  

When IP packets travel through a middlebox, their properties may
change.
  

Examples would be TTL, IP adresses (NAT), DSCP or even fragmentation or
  

replication (multicasting). That means, that if an Observation Domain
  

includes several Observation Points, and the same packet passes more
than
  

one of these Observation Points, some properties can be ambiguous in
this
  

Observation Domain.
  

  

You could solve this by saying, that every propery of a flow-report
  

has to derive from the same observation point. But this would be
  

restrictive. Sometimes it is desirable, that you can classify a single
  

Flow by properties, that derive from _different_ Observation Points.
For
  

example a flow-definition that includes the source IP address before
and
  

after a NAT, or the DSCP at three different Observation Points (before
  

ingress linecard, after ingress linecard, after egress linecard).
  

  

To realise this, you need a way to use certain properties more than one
  

time in a flow-template, to correspond to the different states at the
  

different Observation Points. One way to do this, is the introduction
of
  

additional post- I.E.s, which then correspond to the first and the last
  

Observation Point in the Observation Domain. But this is a restriction
to
  

two special Observation Points, and the second example from above is
not
  

solvable with this approach.
  

  

A more general solution would be to allow the use of the same I.E. more
  

than one time in the same template. The order of the multiple I.E.s
  

corresponds to the different observations as the packet travels through
  

the middlebox. The problem here is, that you cannot tell then, to which
of
  

the different observations the _singular_ I.E.s belong to.
  

  

To solve this, you need a possibility to build goups of I.E.s in the
  

Template: The I.E. values in one "Observation Group" always derive from
  

the same Observation Point (for each packet!). The Observation Groups
are
  

ordered accordingly to the sequence of Observation Points the packet is
  

passing. Of course there are also fields which don't depend on the
  

Observation Point and can be reported in any Observation Group, like
  

ingressInterface (not egress!), as it is always the same, no matter
where
  

in the middlebox the packet is observed. (You may say, that these
fields
  

_have_ to be reported in the first group then, if this is an
advantage.)
  

  

Important to note is, that packets of a Flow defined by (for example)
two
  

Observation Groups don't necessarily pass the same sequence of two
  

Observation Points. They just share the same Flow poperties at the
their
  

first and second Observation Points respectively. To make sure, that
all
  

packets passed the same sequence of Observation Points you have to
include
  

an (yet to be defined) I.E. "observationPointID" as a Flow Key in each
  

Observation Group.
  

  

BTW.: It's possible that a Flow has the same observationPointID in
  

different Observation Groups. For example if your Flow contains two
  

Observation Groups, corresponding to Observation Points at the ingress
and
  

egress interface, you could have Flows where ingress and egress
interface
  

and therefore the observationPointID is the same (e.g. after some NAT).
  

  

The next question is: what is a good way to define these groups? Here
are
  

just two ideas:
  

  

- my first idea, which I descibed in an former mail, was to define
  

"Combined Templates", which are a ordered list of other Templates. Each
  

Template in the Combined Template represents an Observation Group. The
  

reports for Combined Templates are just normal reports with all the
Fields
  

of all the listed Templates concatenated. The disadvantage is, that a
  

change of IPFIX-PROTO is necessary.
  

  

- another idea is to define a special separator I.E. with length 0,
like
  

"newObservationGroup". This pseudo-field separates the Fields in the
  

Template into different Observation Groups. In the reports they don't
  

appear, but the collector has the template and knows where to split.
Here
  

no change in IPFIX-PROTO is necessary. (Jeroen Massar had a very
similar idea)
  

  

I think this concept is a superset of the proposals of Jürgen and
Benoit.
  

Instead of using post-I.E.s Benoit could use Templates like this (using
  

the second grouping-mechanism):
  

  

<sourceIPv4Address>
  

[...different Fields...]
  

<octetDeltaCount>
  

<DSCP>
  

*<newObservationGroup>*
  

<DSCP>
  

  

The DSCP field in the second ObservationGroup is the same as his
postDSCP
  

field.
  

  

Jürgen would do it maybe like this:
  

  

<destinationIPv4Address>
  

*<newObservationGroup>*
  

<sourceIPv4Address>
  

<destinationIPv4Address>
  

[...different Fields...]
  

<octetDeltaCount>
  

  

instead of using an preDestinationIPv4Address Field.
  

  

Why do I like this concept:
  

  

- it includes all the possibilities of the other solutions.
  

  

- you can have as many Observation Groups as you want. (I have an
  

VPN-Relay here, where I will need 3 Observation Groups, which is not
  

possible with the pre-/post- solutions.)
  

  

- it is always clear, which fields derive from the same Observation
Points
  

(same packet state). This is especially true for the counter Fields!
You
  

can have even the same counter in different Observation Groups, if you
  

expect the packet size to be changed.
  

  

- you don't need any post-/pre- variants of the I.E.s You just need the
  

newObservationGroup I.E.. The observationPointID is a good idea anyway,
I
  

think.
  

  

- you don't need complicated semantics, you just report an ordered
  

sequence of packet states. (And that's all you know, in fact.)
  

  

I'm not really sure, but I think, that the in- and out- counters also
get
  

obsolete then. Wouldn't it be the same as having a counter in the first
  

and last Observation Group?
  

  

A side note: I think a packet-altering instance - like a NAT process -
  

which is reporting information to the metering process, should always
be
  

seen as _two_ observation points, one before and one after the change.
  

  

Anyway, this is my "work in progress" idea. I hope I could present this
  

quite complex object in an understandable manner. Now tell me, why it
is a
  

bad idea. :-)
  

  

  

Cheers,
  

  

Sven
  

  








--------------030406000303010603060408--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Mon Dec 19 11:36:07 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoNzZ-0004dW-Pm
	for psamp-archive@megatron.ietf.org; Mon, 19 Dec 2005 11:36:07 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09614
	for ; Mon, 19 Dec 2005 11:35:02 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EoNrz-000A2v-DS
	for psamp-data@psg.com; Mon, 19 Dec 2005 16:28:15 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_30_40,HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_PASS 
	autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EoNry-0009z0-Lq
	for psamp@ops.ietf.org; Mon, 19 Dec 2005 16:28:14 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJGSDi18580
	for ; Mon, 19 Dec 2005 11:28:13 -0500 (EST)
Received: from [10.61.64.51] (ams-clip-vpn-dhcp51.cisco.com [10.61.64.51])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBJGSCC07924
	for ; Mon, 19 Dec 2005 17:28:12 +0100 (CET)
Message-ID: <43A6DF9B.40106@cisco.com>
Date: Mon, 19 Dec 2005 17:28:11 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: psamp 
Subject: Re: Measurement Process -> Metering Process
References: <4377DDCF.4040103@cisco.com> <43981E76.5080709@cisco.com>
In-Reply-To: <43981E76.5080709@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------000402060705060200000001"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------000402060705060200000001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

I applied the editorial changes.

1. I deleted the definition of "Reporting Process"
2. I removed/replaced all remaining occurrence of "Reporting Process"
    btw, as a consequence, I updated the definitions of "packet report", 
"report interpretation", "report stream"
3. I deleted the definition of "Measurement Process"
4. I modified all remaining occurrence of "Measurement Process" by 
"Selection Process"
   btw, as a consequence, I modified the definitions of "Exporting Process"
   I also modified the different requirements from [PSAMP-FMWK] that I 
was quoting in section 6.
   As a consequence, [PSAMP-FMWK] will have to be updated accordingly.

Then, the figure becomes.

               +---------+      +---------+ 
     Observed  |Selection|      |Exporting| 
     Packet--->|Process  |----->|Process  |--->Collector   
     Stream    +---------+      +---------+  
              \--Metering-/
               \-Process-/ 

     Figure B: PSAMP Processes


The same steps from 1 to 4 will have to be executed for [PSAMP-FMWK] and 
[PSAMP-TECH]. Alternatively, you might copy the new definitions from the 
next [PSAMP-PROTO] version.

Regards, Benoit.

> Dear all,
>
> Do I understand correctly from the meeting minutes (below) that we get 
> rid of the Reporting Process.
>
>     Open Issue (not numbered): Terminology Metering Process (IPFIX) vs. 
>       Measurement Process(PSAMP)
>     Terminology problem: When psamp started it wasn't clear that ipfix would be 
>     chosen for export, the architecture is similar but still different. What IPFIX 
>     calls "metering" is defined as "measurement" in PSAMP terminology. 
>     Juergen: Let's use term "metering" for both.  Shall we also drop terms 
>       "selection process" and "reporting process"?
>     Tanja: Keep selection process as part of metering process (is in line with 
>       IPFIX, because metering process can contain sampling/filtering).  But 
>       selection process should be kept. 
>     Nick: I agree.
>     Juergen: The changes need to be applied also to the framework draft and the
>       packet selection draft that are currently in AD review.
>
> Without objections, I will be removing the concept of Reporting 
> Process in [PSAMP-PROTO].
> Anyway, we don't need it in the protocol.
>
> Regards, Benoit.
>
>
>
>> Tanja, Nick, and al.
>>
>> Regarding the "Measurement Process -> Metering Process" issue 
>> discussed during the IETF meeting, I understand that:
>> - the Measurement Process definition disappears
>> - we replace all instances of Measurement Process by (IPFIX) Metering 
>> Process
>> - we keep the Selection Process
>>
>> I was not too clear about the following point:
>> - do we keep the Reporting Process?
>>    There is actually no information about it (no such thing such as 
>> Reporting Process ID)
>>    This is just a concept, right?
>>
>> Regards, Benoit.
>>  
>>
>> -- 
>> to unsubscribe send a message to psamp-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: 
>


--------------000402060705060200000001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  


Dear all,



I applied the editorial changes.



1. I deleted the definition of "Reporting Process"

2. I removed/replaced all remaining occurrence of "Reporting Process"

    btw, as a consequence, I updated the definitions of "packet
report", "report interpretation", "report stream"

3. I deleted the definition of "Measurement Process"

4. I modified all remaining occurrence of "Measurement Process" by
"Selection Process"

   btw, as a consequence, I modified the definitions of "Exporting
Process"

   I also modified the different requirements from [PSAMP-FMWK] that I
was quoting in section 6. 

   As a consequence, [PSAMP-FMWK] will have to be updated accordingly.



Then, the figure becomes.




               +---------+      +---------+ 
     Observed  |Selection|      |Exporting| 
     Packet--->|Process  |----->|Process  |--->Collector   
     Stream    +---------+      +---------+  
              \--Metering-/
               \-Process-/ 

     Figure B: PSAMP Processes



The same steps from 1 to 4 will have to be executed for [PSAMP-FMWK]
and
[PSAMP-TECH]. Alternatively, you might copy the new definitions from
the next [PSAMP-PROTO] version.



Regards, Benoit.





  
Dear all,

  

Do I understand correctly from the meeting minutes (below) that we get
rid of the Reporting Process.

  

    
Open Issue (not numbered): Terminology Metering Process (IPFIX) vs. 
  Measurement Process(PSAMP)
Terminology problem: When psamp started it wasn't clear that ipfix would be 
chosen for export, the architecture is similar but still different. What IPFIX 
calls "metering" is defined as "measurement" in PSAMP terminology. 
Juergen: Let's use term "metering" for both.  Shall we also drop terms 
  "selection process" and "reporting process"?
Tanja: Keep selection process as part of metering process (is in line with 
  IPFIX, because metering process can contain sampling/filtering).  But 
  selection process should be kept. 
Nick: I agree.
Juergen: The changes need to be applied also to the framework draft and the
  packet selection draft that are currently in AD review.

  

Without objections, I will be removing the concept of Reporting Process
in [PSAMP-PROTO].

Anyway, we don't need it in the protocol.

  

Regards, Benoit.

  

  

  

  
Tanja,
Nick, and al. 

    

Regarding the "Measurement Process -> Metering Process" issue
discussed during the IETF meeting, I understand that: 

- the Measurement Process definition disappears 

- we replace all instances of Measurement Process by (IPFIX) Metering
Process 

- we keep the Selection Process 

    

I was not too clear about the following point: 

- do we keep the Reporting Process? 

   There is actually no information about it (no such thing such as
Reporting Process ID) 

   This is just a concept, right? 

    

Regards, Benoit. 

  

    

-- 

to unsubscribe send a message to psamp-request@ops.ietf.org
with 

the word 'unsubscribe' in a single line as the message text body. 

archive: <http://ops.ietf.org/lists/psamp/>
    

  

  








--------------000402060705060200000001--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Tue Dec 20 08:37:23 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EohgB-0008GA-Ci
	for psamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 08:37:23 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26769
	for ; Tue, 20 Dec 2005 08:36:19 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EohaK-000MlB-HB
	for psamp-data@psg.com; Tue, 20 Dec 2005 13:31:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	HTML_40_50,HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_PASS autolearn=no 
	version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EohaI-000Mej-Vx
	for psamp@ops.ietf.org; Tue, 20 Dec 2005 13:31:19 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBKDVHt05760
	for ; Tue, 20 Dec 2005 08:31:17 -0500 (EST)
Received: from [64.103.12.93] (dhcp-64-103-12-93.cisco.com [64.103.12.93])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBKDVGC02513
	for ; Tue, 20 Dec 2005 14:31:16 +0100 (CET)
Message-ID: <43A80797.4040304@cisco.com>
Date: Tue, 20 Dec 2005 14:31:03 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: psamp 
Subject: Open Issue 1: optional compression
Content-Type: multipart/alternative;
 boundary="------------010109090301040004060902"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------010109090301040004060902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,


[PSAMP-FMWK] mentions the optional Export Packets compression (see 
section 8.5)
Should we mention it in [PSAMP-PROTO]?

This requirement comes from a time at which we didn't know that IPFIX 
would be selected.
As [IPFIX-PROTO] doesn't mention compression, I'm in favor not to add 
anything about compression in [PSAMP-PROTO].
I don't think that this is appropriate to differentiate the IPFIX and 
PSAMP protocols; the PSAMP protocol must use the IPFIX specifications as 
defined in [IPFIX-PROTO]

Feedback?

Regards, Benoit.


--------------010109090301040004060902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  



Dear all,






[PSAMP-FMWK] mentions the optional Export Packets
compression (see section 8.5) 

Should we mention it in [PSAMP-PROTO]?


This requirement comes from a time at which we
didn't know that IPFIX would be selected.

As [IPFIX-PROTO] doesn't mention compression, I'm in favor not to add
anything about compression in [PSAMP-PROTO]. 

I don't think that this is appropriate to differentiate the IPFIX and
PSAMP protocols; the PSAMP protocol must use the IPFIX specifications
as defined in [IPFIX-PROTO]




Feedback?




Regards, Benoit.






--------------010109090301040004060902--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Tue Dec 20 08:54:17 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EohwX-0003iY-NN
	for psamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 08:54:17 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28691
	for ; Tue, 20 Dec 2005 08:53:13 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Eohso-00068d-V6
	for psamp-data@psg.com; Tue, 20 Dec 2005 13:50:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Eohso-00065M-Dc
	for psamp@ops.ietf.org; Tue, 20 Dec 2005 13:50:26 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBKDoP907089
	for ; Tue, 20 Dec 2005 08:50:25 -0500 (EST)
Received: from [64.103.12.93] (dhcp-64-103-12-93.cisco.com [64.103.12.93])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBKDoOC23565
	for ; Tue, 20 Dec 2005 14:50:24 +0100 (CET)
Message-ID: <43A80C11.1040309@cisco.com>
Date: Tue, 20 Dec 2005 14:50:09 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: psamp 
Subject: Open Issue 5: PSAMP transport protocol 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear all,

The PSAMP open issue 5 is the following:
Transport protocol: SCTP and/or UDP and/or TCP. Nothing is mentioned at 
this stage. [PSAMP-FMWK] and PSAMP charter specifically mention UDP.

Currently, we don't mention anything regarding the transport protocol 
selection in [PSAMP-PROTO].
However, I think that we don't need to specify anything as we have this 
sentence in the draft:
    "The entire IPFIX protocol specifications [IPFIX-PROTO] MUST be 
implemented for the PSAMP export."
This allows the same transport  protocol choices as specified in 
[IPFIX-PROTO].

Please let me know if you disagree.

Regards, Benoit.

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Tue Dec 20 09:42:37 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EoihJ-0008Bo-Dc
	for psamp-archive@megatron.ietf.org; Tue, 20 Dec 2005 09:42:37 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06167
	for ; Tue, 20 Dec 2005 09:41:32 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Eoiaq-000BgS-Q9
	for psamp-data@psg.com; Tue, 20 Dec 2005 14:35:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Eoiaq-000Bbx-2P
	for psamp@ops.ietf.org; Tue, 20 Dec 2005 14:35:56 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBKEZsv10399
	for ; Tue, 20 Dec 2005 09:35:54 -0500 (EST)
Received: from [64.103.12.93] (dhcp-64-103-12-93.cisco.com [64.103.12.93])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBKEZrC21949
	for ; Tue, 20 Dec 2005 15:35:53 +0100 (CET)
Message-ID: <43A816BC.2030604@cisco.com>
Date: Tue, 20 Dec 2005 15:35:40 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: psamp 
Subject: Open Issue 6: Associations ID -> Selection Path
Content-Type: multipart/alternative;
 boundary="------------090200080400090707070105"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------090200080400090707070105
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

The PSAMP open issue 6 is the following:

    Even if the notion of Associations ID is mentioned in [PSAMP-TECH],
    maybe a term such as SelectionPath or PathID would be more appropriate.

The background of this issue is the following.
[PSAMP-TECH] specifies the Associations ID like this:

    ASSOCIATIONS 
     
    Values:  
    With STREAM ID: Observation point ID AND List of SELECTOR_IDs 

However, we concluded during the last IETF meeting that we don't need 
the IPFIX Metering and Exporting Process ID.
So we're left with:

    Values: 

Since we don't associate anymore the observation point with processes, it was proposed to change the name:
from "Associations ID" to "Selection Path" or "Path ID".

Personally, I prefer the Selection Path term, along with the selectionPath I.E.
For the simple reason that we speak of selection methods all over in the PSAMP drafts.

Feedback?

Regards, Benoit.



--------------090200080400090707070105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  



Dear all,






The PSAMP open issue 6 is the following:




Even if the notion of Associations ID is mentioned in
[PSAMP-TECH], maybe a term such as SelectionPath or PathID would be
more
appropriate.




The background of this issue is the following.

[PSAMP-TECH] specifies the Associations ID like this:




    ASSOCIATIONS 
     
    Values: <STREAM ID, IPFIX Metering process ID, IPFIX Exporting 
    process ID, IDs of other associated processes> 
    With STREAM ID: Observation point ID AND List of SELECTOR_IDs 


However, we concluded during the last IETF meeting
that we don't need the IPFIX Metering and Exporting Process ID.

So we're left with: 




    Values: <Observation point ID, List of SELECTOR_IDs>

Since we don't associate anymore the observation point with processes, it was proposed to change the name:
from "Associations ID" to "Selection Path" or "Path ID".

Personally, I prefer the Selection Path term, along with the selectionPath I.E.
For the simple reason that we speak of selection methods all over in the PSAMP drafts.

Feedback?

Regards, Benoit.










--------------090200080400090707070105--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 03:41:02 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EozWw-0007EA-N0
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 03:41:02 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10343
	for ; Wed, 21 Dec 2005 03:39:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EozQE-0009X0-Tj
	for psamp-data@psg.com; Wed, 21 Dec 2005 08:34:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EozQD-0009Wf-JE
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 08:34:05 +0000
Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 0F0DC1BAC4D;
	Wed, 21 Dec 2005 09:34:01 +0100 (CET)
Date: Wed, 21 Dec 2005 09:34:00 +0100
From: Juergen Quittek 
To: Benoit Claise , psamp 
Subject: Re: Uniform Probabilistic Sampling in PSAMP-PROTO
Message-ID: 
In-Reply-To: <43971C0C.7080101@cisco.com>
References:  <43971C0C.7080101@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Benoit,

Sorry for the late reply.
Basically, I agree with your proposal.
Please find comments in line.

--On 07.12.2005 18:29 Uhr +0100 Benoit Claise wrote:

>
> Dear all,
>
> We're trying to model "Uniform Probabilistic Sampling" in [PSAMP-PROTO].
>
> [PSAMP-MIB] specifies:
>
> 5.2.5. Uniform Probabilistic Sampling
>
> Capability objects are not specified for the uniform probabilistic
> sampling method. It has only one parameter in the
> psampSampUniProbParamSetTable, the psampSampUniProbProbability. This
> object gives the probability that a packet is sampled. The
> probability is equal for every packet. The given value must be
> divided by 4294967295 (=2^32-1), so a value of 0 means no packet is
> sampled (probability is 0) and a value of 4294967295 means every
> packet is sampled (probability is 1).
>
> psampSampUniProbProbability OBJECT-TYPE
> SYNTAX Unsigned32 (0..4294967295)
> MAX-ACCESS read-create
> STATUS current
> DESCRIPTION
> "This object gives the probability that a packet is sampled.
> The probability is equal for every packet. The given value
> must be divided by 4294967295 (=2^32-1), so a value of 0
> means no packet is sampled (probability is 0) and a value of
> 4294967295 means every packet is sampled (probability is
> 1)."
>
>
> First of all, I've got an issue with the psampSampUniProbProbability MIB. How do we represent a probability of 1/2 as this number not even?
> Should we use a different number (1000000000), specifying a range in the SYNTAX. I think so!

I support this proposal.  If we follow it, setting and reading
the probability would become less error-prone.  From reading the
value you can much easier identify a probalility of 0.5: 500000000
or 0.01: 10000000.  Still the problem of counting the zeros
remains as problem.  The disadvantage is less precision.  But I
think the remaining precision of 1 of a billion is still sufficient.

> Initially we wanted to model the probability in [PSAMP-PROTO] with a float, which is allowed by [IPFIX-PROTO].
> However, we've got the issue that SMIv2 doesn't support floats.
>
> What to do now?
>
> Solution 1:
> We export the probability with a float, and we approximate this value with the MIB variable.

Approximation is not an issue, because the precision of the Integer
in the MIB would be greater than the precision of a float32 by several
orders of magnitude.  So, we do not loose information by converting a
float32 to a 32 bit integer (in this case).
Approximation would be an issue if we chose a float64.

> Solution 2:
> We export the probability with an unsigned32, exactly the same content as the MIB variable psampSampUniProbProbability
>
> Solution 3:
> We export the probability with two values N, M.
>     This means 2 inter-dependent I.E.s and 2 MIB variables instead of one.
>     I don't like it too much
>
> I'm clearly in favor of solution 1. It's not right that we would limit IPFIX because of the limitations of SMIv2
>
> Feedback?

I am fine with Solution 1 as well as with Solution 2.
Are there any other opinions?

> Side question: if we go for the float solution, should we have a float64? This would give us more precision
> Note: not yet defined in [IPFIX-PROTO].

The question is how much precision we need here.
In general, I think that single precision is sufficient.

Thanks,

    Juergen

> Regards, Benoit.



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 03:42:15 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EozY6-0007y4-VH
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 03:42:15 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10423
	for ; Wed, 21 Dec 2005 03:41:10 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EozT4-0009l6-5z
	for psamp-data@psg.com; Wed, 21 Dec 2005 08:37:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EozT3-0009kt-IG
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 08:37:01 +0000
Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 484011BAC4D;
	Wed, 21 Dec 2005 09:37:00 +0100 (CET)
Date: Wed, 21 Dec 2005 09:36:58 +0100
From: Juergen Quittek 
To: Tanja Zseby , psamp 
Subject: Re: Open Issue 2: Field Match and Router State Filtering
Message-ID: <232DD2525641ACCFEF70F721@[10.1.1.171]>
In-Reply-To: <43981527.1080302@cisco.com>
References:  <43981527.1080302@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Tanja,

Please add this issue to the list of required changes
for the packet selection document.

Thanks,

    Juergen

--On 08.12.2005 12:12 Uhr +0100 Benoit Claise wrote:

> Dear all,
>
>> From the PSAMP meeting minutes:
>
> Open Issue #2 - Field Match and Router State Filtering
>> From the protocol's perspective, there are no differences between the field
> match and router state fields. Proposal: merge both fields to simplify the
> protocol.
> Tanja: Currently, the packet selection draft separates them. Merging them
> is OK. It will simplify the protocol.
>
>
> I'm now merging "Field Match and Router State Filtering" in [PSAMP-PROTO] under "Property Match
> Filtering", as agreed. [PSAMP-TECH] should do the same.
>
> In [PSAMP-INFO], the selectorAlgorithm has got the following values
>
>       *  1 Systematic count-based sampling
>       *  2 Systematic time-based sampling
>       *  3 Random n-out-of-N sampling
>       *  4 Uniform probabilistic sampling
>       *  5 Non-uniform probabilistic sampling
>       *  6 Non-uniform flow state sampling
>       *  7 Property Match filtering
>       *  8 Hash based filtering
>
>
> Regards, Benoit.



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 04:01:27 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Eozqg-0007zO-Uk
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 04:01:27 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12072
	for ; Wed, 21 Dec 2005 04:00:22 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EoznB-000BFl-IF
	for psamp-data@psg.com; Wed, 21 Dec 2005 08:57:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EoznA-000BFZ-KZ
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 08:57:48 +0000
Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 483111BAC4D;
	Wed, 21 Dec 2005 09:57:47 +0100 (CET)
Date: Wed, 21 Dec 2005 09:57:45 +0100
From: Juergen Quittek 
To: Benoit Claise , psamp 
Subject: Re: Measurement Process -> Metering Process
Message-ID: 
In-Reply-To: <43A6DF9B.40106@cisco.com>
References: <4377DDCF.4040103@cisco.com> <43981E76.5080709@cisco.com> <43A6DF9B.40106@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Benoit,

Thanks for elaborating this change.
Please find a comment in line.

--On 19.12.2005 17:28 Uhr +0100 Benoit Claise wrote:

> Dear all,
>
> I applied the editorial changes.
>
> 1. I deleted the definition of "Reporting Process"
> 2. I removed/replaced all remaining occurrence of "Reporting Process"
>     btw, as a consequence, I updated the definitions of "packet report", "report interpretation", "report stream"
> 3. I deleted the definition of "Measurement Process"
> 4. I modified all remaining occurrence of "Measurement Process" by "Selection Process"
>    btw, as a consequence, I modified the definitions of "Exporting Process"
>    I also modified the different requirements from [PSAMP-FMWK] that I was quoting in section 6.
>    As a consequence, [PSAMP-FMWK] will have to be updated accordingly.
>
> Then, the figure becomes.
>
>
>                +---------+      +---------+
>      Observed  |Selection|      |Exporting|
>      Packet--->|Process  |----->|Process  |--->Collector
>      Stream    +---------+      +---------+
>               \--Metering-/
>                \-Process-/
>
>      Figure B: PSAMP Processes

Shouldn't it be just

               +---------+      +---------+
     Observed  |Metering |      |Exporting|
     Packet--->|Process  |----->|Process  |--->Collector
     Stream    +---------+      +---------+

?

    Juergen

> The same steps from 1 to 4 will have to be executed for [PSAMP-FMWK] and [PSAMP-TECH]. Alternatively, you might copy the new definitions from the next [PSAMP-PROTO] version.
>
> Regards, Benoit.
>
>
>  Dear all,
>
> Do I understand correctly from the meeting minutes (below) that we get rid of the Reporting Process.
>
>
>
> Open Issue (not numbered): Terminology Metering Process (IPFIX) vs.
>   Measurement Process(PSAMP)
> Terminology problem: When psamp started it wasn't clear that ipfix would be
> chosen for export, the architecture is similar but still different. What IPFIX
> calls "metering" is defined as "measurement" in PSAMP terminology.
> Juergen: Let's use term "metering" for both.  Shall we also drop terms
>   "selection process" and "reporting process"?
> Tanja: Keep selection process as part of metering process (is in line with
>   IPFIX, because metering process can contain sampling/filtering).  But
>   selection process should be kept.
> Nick: I agree.
> Juergen: The changes need to be applied also to the framework draft and the
>   packet selection draft that are currently in AD review.
>
>
> Without objections, I will be removing the concept of Reporting Process in [PSAMP-PROTO].
> Anyway, we don't need it in the protocol.
>
> Regards, Benoit.
>
>
>
>
> Tanja, Nick, and al.
>
> Regarding the "Measurement Process -> Metering Process" issue discussed during the IETF meeting, I understand that:
> - the Measurement Process definition disappears
> - we replace all instances of Measurement Process by (IPFIX) Metering Process
> - we keep the Selection Process
>
> I was not too clear about the following point:
> - do we keep the Reporting Process?
>    There is actually no information about it (no such thing such as Reporting Process ID)
>    This is just a concept, right?
>
> Regards, Benoit.
>
>
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
>
>
>
>



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 05:20:40 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep15M-00020n-OC
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:20:40 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20127
	for ; Wed, 21 Dec 2005 05:19:35 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep0zs-000Ghw-3f
	for psamp-data@psg.com; Wed, 21 Dec 2005 10:15:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_PASS 
	autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep0zr-000Ghk-DJ
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 10:14:59 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLAEwS23722
	for ; Wed, 21 Dec 2005 05:14:58 -0500 (EST)
Received: from [10.61.65.195] (ams-clip-vpn-dhcp451.cisco.com [10.61.65.195])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLAEvC28970
	for ; Wed, 21 Dec 2005 11:14:57 +0100 (CET)
Message-ID: <43A92B20.3020600@cisco.com>
Date: Wed, 21 Dec 2005 11:14:56 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: psamp 
Subject: PSAMP IANA considerations section
Content-Type: multipart/alternative;
 boundary="------------020408050407080606030403"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------020408050407080606030403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Here is a proposal for the IANA considerations section.

1. 9. IANA Considerations

The PSAMP Protocol, as set out in this document, has two sets of 
assigned numbers.  Considerations for assigning them are discussed in 
this section, using the example policies as set out in the "Guidelines 
for IANA Considerations" document IANA-RFC [RFC2434].

     9.1 IPFIX Related Considerations

As the PSAMP protocol uses the IPFIX protocol, refer to the IANA 
considerations section in [IPFIX-PROTO] for the assignments of numbers 
used in the protocol and for the numbers used in the information model.

      9.2 PSAMP Related Considerations

Each new selection method MUST be assigned a unique value for the 
selectorAlgorithm Information Element.  Its configuration parameter(s), 
along with the way to report it/them with an Options Template, MUST be 
clearly specified.

Each new selection method MUST be assigned a unique value for the 
selectorAlgorithm Information Element.  New assignments for the PSAMP 
selection method will be administered by IANA, on a First Come First 
Served basis [RFC 2434], subject to Expert Review [RFC 2434], i.e. 
review by one of a group of experts designated by an IETF Operations and 
Management Area Director.  The group of experts must double check the 
Information Elements definitions with already defined Information 
Elements for completeness, accuracy and redundancy.  Those experts will 
initially be drawn from the Working Group Chairs and document editors of 
the IPFIX and PSAMP Working Groups.



Now, two questions:
1. I'm not too sure whether we should mandate a new IETF RFC for the new 
selection method description?
2. I'm not too sure whether we should mandate new IANA-registered 
information elements for the new selection method?
    In other words, can we have proprietary selection method in the 
selectorAlgorithm Information Element?

Regards, Benoit.

--------------020408050407080606030403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  


Dear all,



Here is a proposal for the IANA considerations section.




1.
9. IANA Considerations


The PSAMP Protocol, as set out in this document, has
two sets
of assigned numbers.  Considerations for
assigning them are discussed in this section, using the example
policies as set
out in the "Guidelines for IANA Considerations" document IANA-RFC
[RFC2434].


    
9.1 IPFIX Related Considerations


As the PSAMP protocol uses the IPFIX protocol, refer
to the
IANA considerations section in [IPFIX-PROTO] for the assignments of
numbers
used in the protocol and for the numbers used in the information model.


     
9.2 PSAMP Related
Considerations


Each new selection method MUST be assigned a unique
value for
the selectorAlgorithm Information Element.  Its configuration
parameter(s), along with the way to report it/them with an Options
Template,
MUST be clearly specified.


Each new selection method MUST be assigned a unique
value for
the selectorAlgorithm Information Element.  New assignments for the
PSAMP selection
method will be administered by IANA, on a First Come First Served basis
[RFC
2434], subject to Expert Review [RFC 2434], i.e. review by one of a
group of
experts designated by an IETF Operations and Management Area Director.  The
group of experts must double check the
Information Elements definitions with already defined Information
Elements for completeness,
accuracy and redundancy.  Those experts
will initially be drawn from the Working Group Chairs and document
editors of
the IPFIX and PSAMP Working Groups.





Now, two questions:

1. I'm not too sure whether we should mandate a new IETF RFC for the
new selection method description?

2. I'm not too sure whether we should mandate new IANA-registered
information elements for the new selection method?

    In other words, can we have proprietary selection method in the
selectorAlgorithm Information Element?



Regards, Benoit.




--------------020408050407080606030403--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 05:41:37 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep1Pd-0002JJ-Ba
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 05:41:37 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22126
	for ; Wed, 21 Dec 2005 05:40:31 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep1Lq-000ISb-Ow
	for psamp-data@psg.com; Wed, 21 Dec 2005 10:37:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_30_40,HTML_MESSAGE,SPF_PASS autolearn=no 
	version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep1Lp-000ISN-Vy
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 10:37:42 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLAbeO25099;
	Wed, 21 Dec 2005 05:37:40 -0500 (EST)
Received: from [10.61.65.195] (ams-clip-vpn-dhcp451.cisco.com [10.61.65.195])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLAbdC18932;
	Wed, 21 Dec 2005 11:37:39 +0100 (CET)
Message-ID: <43A93072.1020304@cisco.com>
Date: Wed, 21 Dec 2005 11:37:38 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Juergen Quittek 
CC: psamp 
Subject: Re: Measurement Process -> Metering Process
References: <4377DDCF.4040103@cisco.com> <43981E76.5080709@cisco.com>	<43A6DF9B.40106@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative;
 boundary="------------000900060502030009050802"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------000900060502030009050802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Juergen Quittek wrote:
> Hi Benoit,
>
> Thanks for elaborating this change.
> Please find a comment in line.
>
> --On 19.12.2005 17:28 Uhr +0100 Benoit Claise wrote:
>
>> Dear all,
>>
>> I applied the editorial changes.
>>
>> 1. I deleted the definition of "Reporting Process"
>> 2. I removed/replaced all remaining occurrence of "Reporting Process"
>>     btw, as a consequence, I updated the definitions of "packet 
>> report", "report interpretation", "report stream"
>> 3. I deleted the definition of "Measurement Process"
>> 4. I modified all remaining occurrence of "Measurement Process" by 
>> "Selection Process"
>>    btw, as a consequence, I modified the definitions of "Exporting 
>> Process"
>>    I also modified the different requirements from [PSAMP-FMWK] that 
>> I was quoting in section 6.
>>    As a consequence, [PSAMP-FMWK] will have to be updated accordingly.
>>
>> Then, the figure becomes.
>>
>>
>>                +---------+      +---------+
>>      Observed  |Selection|      |Exporting|
>>      Packet--->|Process  |----->|Process  |--->Collector
>>      Stream    +---------+      +---------+
>>               \--Metering-/
>>                \-Process-/
>>
>>      Figure B: PSAMP Processes
>
> Shouldn't it be just
>
>               +---------+      +---------+
>     Observed  |Metering |      |Exporting|
>     Packet--->|Process  |----->|Process  |--->Collector
>     Stream    +---------+      +---------+
>
> ?
>
>  
Personally, this is what I would prefer. It makes more sense.
However, I was perfectly clear on the conclusions from the meeting in 
Vancouver (this is reason why I started this thread)
 From the meeting minutes at 
http://www3.ietf.org/proceedings/05nov/minutes/psamp.txt

    Open Issue (not numbered): Terminology Metering Process (IPFIX) vs.
    Measurement Process(PSAMP)
    Terminology problem: When psamp started it wasn't clear that ipfix
    would be
    chosen for export, the architecture is similar but still different.
    What IPFIX
    calls "metering" is defined as "measurement" in PSAMP terminology.
    Juergen: Let's use term "metering" for both. Shall we also drop terms
    "selection process" and "reporting process"?
    Tanja: Keep selection process as part of metering process (is in
    line with
    IPFIX, because metering process can contain sampling/filtering). But
    selection process should be kept.
    Nick: I agree.
    Juergen: The changes need to be applied also to the framework draft
    and the
    packet selection draft that are currently in AD review.

Juergen, I would be perfectly happy to edit the diagram as you draw it.

Regards, Benoit.


>
>> The same steps from 1 to 4 will have to be executed for [PSAMP-FMWK] 
>> and [PSAMP-TECH]. Alternatively, you might copy the new definitions 
>> from the next [PSAMP-PROTO] version.
>>
>> Regards, Benoit.
>>
>>
>>  Dear all,
>>
>> Do I understand correctly from the meeting minutes (below) that we 
>> get rid of the Reporting Process.
>>
>>
>>
>> Open Issue (not numbered): Terminology Metering Process (IPFIX) vs.
>>   Measurement Process(PSAMP)
>> Terminology problem: When psamp started it wasn't clear that ipfix 
>> would be
>> chosen for export, the architecture is similar but still different. 
>> What IPFIX
>> calls "metering" is defined as "measurement" in PSAMP terminology.
>> Juergen: Let's use term "metering" for both.  Shall we also drop terms
>>   "selection process" and "reporting process"?
>> Tanja: Keep selection process as part of metering process (is in line 
>> with
>>   IPFIX, because metering process can contain sampling/filtering).  But
>>   selection process should be kept.
>> Nick: I agree.
>> Juergen: The changes need to be applied also to the framework draft 
>> and the
>>   packet selection draft that are currently in AD review.
>>
>>
>> Without objections, I will be removing the concept of Reporting 
>> Process in [PSAMP-PROTO].
>> Anyway, we don't need it in the protocol.
>>
>> Regards, Benoit.
>>
>>
>>
>>
>> Tanja, Nick, and al.
>>
>> Regarding the "Measurement Process -> Metering Process" issue 
>> discussed during the IETF meeting, I understand that:
>> - the Measurement Process definition disappears
>> - we replace all instances of Measurement Process by (IPFIX) Metering 
>> Process
>> - we keep the Selection Process
>>
>> I was not too clear about the following point:
>> - do we keep the Reporting Process?
>>    There is actually no information about it (no such thing such as 
>> Reporting Process ID)
>>    This is just a concept, right?
>>
>> Regards, Benoit.
>>
>>
>> -- 
>> to unsubscribe send a message to psamp-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: 
>>
>>
>>
>>


--------------000900060502030009050802
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Juergen Quittek wrote:

Hi Benoit,
  

  

Thanks for elaborating this change.
  

Please find a comment in line.
  

  

--On 19.12.2005 17:28 Uhr +0100 Benoit Claise wrote:
  

  

  
Dear all,
    

    

I applied the editorial changes.
    

    

1. I deleted the definition of "Reporting Process"
    

2. I removed/replaced all remaining occurrence of "Reporting Process"
    

    btw, as a consequence, I updated the definitions of "packet
report", "report interpretation", "report stream"
    

3. I deleted the definition of "Measurement Process"
    

4. I modified all remaining occurrence of "Measurement Process" by
"Selection Process"
    

   btw, as a consequence, I modified the definitions of "Exporting
Process"
    

   I also modified the different requirements from [PSAMP-FMWK] that I
was quoting in section 6.
    

   As a consequence, [PSAMP-FMWK] will have to be updated accordingly.
    

    

Then, the figure becomes.
    

    

    

               +---------+      +---------+
    

     Observed  |Selection|      |Exporting|
    

     Packet--->|Process  |----->|Process  |--->Collector
    

     Stream    +---------+      +---------+
    

              \--Metering-/
    

               \-Process-/
    

    

     Figure B: PSAMP Processes
    

  

  

Shouldn't it be just
  

  

              +---------+      +---------+
  

    Observed  |Metering |      |Exporting|
  

    Packet--->|Process  |----->|Process  |--->Collector
  

    Stream    +---------+      +---------+
  

  

?
  

  

  



Personally, this is what I would prefer. It makes more sense.

However, I was perfectly clear on the conclusions from the meeting in
Vancouver (this is reason why I started this thread)

From the meeting minutes at
http://www3.ietf.org/proceedings/05nov/minutes/psamp.txt


Open Issue (not numbered): Terminology Metering Process
(IPFIX) vs. 

Measurement Process(PSAMP)

Terminology problem: When psamp started it wasn't clear that ipfix
would be 

chosen for export, the architecture is similar but still different.
What IPFIX 

calls "metering" is defined as "measurement" in PSAMP terminology. 

Juergen: Let's use term "metering" for both. Shall we also drop terms 

"selection process" and "reporting process"?

Tanja: Keep selection process as part of metering process (is in line
with 

IPFIX, because metering process can contain sampling/filtering). But 

selection process should be kept. 

Nick: I agree.

Juergen: The changes need to be applied also to the framework draft and
the

packet selection draft that are currently in AD review.




Juergen, I would be perfectly happy to edit the diagram as you draw it.

Regards, Benoit.







  
The same steps from 1 to 4 will have to be
executed for [PSAMP-FMWK] and [PSAMP-TECH]. Alternatively, you might
copy the new definitions from the next [PSAMP-PROTO] version.
    

    

Regards, Benoit.
    

    

    

 Dear all,
    

    

Do I understand correctly from the meeting minutes (below) that we get
rid of the Reporting Process.
    

    

    

    

Open Issue (not numbered): Terminology Metering Process (IPFIX) vs.
    

  Measurement Process(PSAMP)
    

Terminology problem: When psamp started it wasn't clear that ipfix
would be
    

chosen for export, the architecture is similar but still different.
What IPFIX
    

calls "metering" is defined as "measurement" in PSAMP terminology.
    

Juergen: Let's use term "metering" for both.  Shall we also drop terms
    

  "selection process" and "reporting process"?
    

Tanja: Keep selection process as part of metering process (is in line
with
    

  IPFIX, because metering process can contain sampling/filtering).  But
    

  selection process should be kept.
    

Nick: I agree.
    

Juergen: The changes need to be applied also to the framework draft and
the
    

  packet selection draft that are currently in AD review.
    

    

    

Without objections, I will be removing the concept of Reporting Process
in [PSAMP-PROTO].
    

Anyway, we don't need it in the protocol.
    

    

Regards, Benoit.
    

    

    

    

    

Tanja, Nick, and al.
    

    

Regarding the "Measurement Process -> Metering Process" issue
discussed during the IETF meeting, I understand that:
    

- the Measurement Process definition disappears
    

- we replace all instances of Measurement Process by (IPFIX) Metering
Process
    

- we keep the Selection Process
    

    

I was not too clear about the following point:
    

- do we keep the Reporting Process?
    

   There is actually no information about it (no such thing such as
Reporting Process ID)
    

   This is just a concept, right?
    

    

Regards, Benoit.
    

    

    

--
    

to unsubscribe send a message to psamp-request@ops.ietf.org with
    

the word 'unsubscribe' in a single line as the message text body.
    

archive: <http://ops.ietf.org/lists/psamp/>
    

    

    

    

    

  








--------------000900060502030009050802--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 06:19:10 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep1zy-0001Pl-M8
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 06:19:10 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25970
	for ; Wed, 21 Dec 2005 06:18:05 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep1wf-000LC2-5k
	for psamp-data@psg.com; Wed, 21 Dec 2005 11:15:45 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep1we-000LBe-25
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 11:15:44 +0000
Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 74A2F1BAC4D;
	Wed, 21 Dec 2005 12:15:42 +0100 (CET)
Date: Wed, 21 Dec 2005 12:15:39 +0100
From: Juergen Quittek 
To: Andrew Johnson , Benoit Claise 
Cc: psamp 
Subject: Re: Uniform Probabilistic Sampling in PSAMP-PROTO
Message-ID: 
In-Reply-To: <43986523.7040803@cisco.com>
References: <43971C0C.7080101@cisco.com> <43986523.7040803@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Andrew,

--On 08.12.2005 16:53 Uhr +0000 Andrew Johnson wrote:

> Benoit Claise wrote:
> [SNIP]
>> Initially we wanted to model the probability in [PSAMP-PROTO] with a
>> float, which is allowed by [IPFIX-PROTO].
>> However, we've got the issue that SMIv2 doesn't support floats.
>
> Although the floating point type is not a base type in SMI there are
> a couple of proposals about how to send them.  This extract is from
> the comp.protocols.snmp SNMP FAQ:
>
>   http://www.faqs.org/faqs/snmp-faq/part2/
>   ===============================================================
>   2.40.04
>   SUBJECT: Floating Point Numbers in SMI?
>
>   You cannot add new base types to the SMI.
>
>   For now, the easiest way to have floating point numbers
>   in SNMP MIBs is to use the base type OCTET STRING and
>   encode the value in ASCII.
>
>   This is not the most elegant approach. However, it will work
>   between your agent and your management application and it will
>   be compliant to the SNMP SMI and protocol specifications.
>
>   David Perkins
>   ===============================================================
>
> Apparently this method is implemented in the NET-SNMP agent and
> manager.
>   (http://ops.ietf.org/lists/mreview/mreview.2004/msg00083.html)
>
> Whether we use the above suggested method or define a new way of
> using unsigned32 the application will have to have some way of
> converting that number before it can be used.

This would be Solution 4.
I still prefer Solution 1 or Solution 2.

>> What to do now?
>>
>> _Solution 1: _
>> We export the probability with a float, and we approximate this value
>> with the MIB variable.
>>
>> _Solution 2: _
>> We export the probability with an unsigned32, exactly the same content
>> as the MIB variable psampSampUniProbProbability
>>
>> _Solution 3: _
>> We export the probability with two values N, M.
>>     This means 2 inter-dependent I.E.s and 2 MIB variables instead of one.
>>     I don't like it too much
>>
>> I'm clearly in favor of solution 1. It's not right that we would limit
>> IPFIX because of the limitations of SMIv2
>> Feedback?
>>
>> Side question: if we go for the float solution, should we have a
>> float64? This would give us more precision
>> Note: not yet defined in [IPFIX-PROTO].
>
> FYI:
> The 32-bit float has 24 bits of precision, i.e. roughly +/-0.000006%.

It is 23 bits we are using. Precision would be    roughly +/-0.00001%
The Unsigned as Benoit suggests it would have     roughly +/-0.0000001%

> The 64-bit float has 53 bits of precision, i.e. roughly +/-0.00000000000001%
> regards

Thanks,

    Juergen

> Andrew
>
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 06:21:05 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep21o-0001eE-TD
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 06:21:05 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26120
	for ; Wed, 21 Dec 2005 06:19:56 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep1zo-000LPD-W6
	for psamp-data@psg.com; Wed, 21 Dec 2005 11:19:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep1zo-000LP0-Cb
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 11:19:00 +0000
Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 193FC1BAC4D;
	Wed, 21 Dec 2005 12:18:58 +0100 (CET)
Date: Wed, 21 Dec 2005 12:18:55 +0100
From: Juergen Quittek 
To: Benoit Claise , psamp 
Subject: Re: Open Issue 1: optional compression
Message-ID: 
In-Reply-To: <43A80797.4040304@cisco.com>
References:  <43A80797.4040304@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Benoit,

I think the protocol document should state that with the choice of
IPFIX as protocol, the compression option mentioned in the framework
is not addressed.

Thanks,

    Juergen

--On 20.12.2005 14:31 Uhr +0100 Benoit Claise wrote:

>
> Dear all,
>
>
> [PSAMP-FMWK] mentions the optional Export Packets compression (see section 8.5)
> Should we mention it in [PSAMP-PROTO]?
>
> This requirement comes from a time at which we didn't know that IPFIX would be selected.
> As [IPFIX-PROTO] doesn't mention compression, I'm in favor not to add anything about compression in [PSAMP-PROTO].
> I don't think that this is appropriate to differentiate the IPFIX and PSAMP protocols; the PSAMP protocol must use the IPFIX specifications as defined in [IPFIX-PROTO]
>
> Feedback?
>
> Regards, Benoit.



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 06:26:06 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep26g-0004JH-SN
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 06:26:06 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26847
	for ; Wed, 21 Dec 2005 06:24:59 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep24M-000LoC-3x
	for psamp-data@psg.com; Wed, 21 Dec 2005 11:23:42 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep24K-000Lnv-Qv
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 11:23:41 +0000
Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 659B81BAC4D;
	Wed, 21 Dec 2005 12:23:39 +0100 (CET)
Date: Wed, 21 Dec 2005 12:23:36 +0100
From: Juergen Quittek 
To: Benoit Claise 
Cc: psamp 
Subject: Re: Measurement Process -> Metering Process
Message-ID: 
In-Reply-To: <43A93072.1020304@cisco.com>
References: <4377DDCF.4040103@cisco.com> <43981E76.5080709@cisco.com>	<43A6DF9B.40106@cisco.com>  <43A93072.1020304@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 21.12.2005 11:37 Uhr +0100 Benoit Claise wrote:

> Juergen Quittek wrote:
>
> Hi Benoit,
>
> Thanks for elaborating this change.
> Please find a comment in line.
>
> --On 19.12.2005 17:28 Uhr +0100 Benoit Claise wrote:
>
>
> Dear all,
>
> I applied the editorial changes.
>
> 1. I deleted the definition of "Reporting Process"
> 2. I removed/replaced all remaining occurrence of "Reporting Process"
>     btw, as a consequence, I updated the definitions of "packet report", "report interpretation", "report stream"
> 3. I deleted the definition of "Measurement Process"
> 4. I modified all remaining occurrence of "Measurement Process" by "Selection Process"
>    btw, as a consequence, I modified the definitions of "Exporting Process"
>    I also modified the different requirements from [PSAMP-FMWK] that I was quoting in section 6.
>    As a consequence, [PSAMP-FMWK] will have to be updated accordingly.
>
> Then, the figure becomes.
>
>
>                +---------+      +---------+
>      Observed  |Selection|      |Exporting|
>      Packet--->|Process  |----->|Process  |--->Collector
>      Stream    +---------+      +---------+
>               \--Metering-/
>                \-Process-/
>
>      Figure B: PSAMP Processes
>
>
> Shouldn't it be just
>
>               +---------+      +---------+
>     Observed  |Metering |      |Exporting|
>     Packet--->|Process  |----->|Process  |--->Collector
>     Stream    +---------+      +---------+
>
> ?

I would use this figure for showing consistency with IPFIX.
We can explain in the text that the metering process contains
a selection process (as it does in IPFIX).

Thanks,

    Juergen

> Personally, this is what I would prefer. It makes more sense.
> However, I was perfectly clear on the conclusions from the meeting in Vancouver (this is reason why I started this thread)
> From the meeting minutes at http://www3.ietf.org/proceedings/05nov/minutes/psamp.txt
>
> Open Issue (not numbered): Terminology Metering Process (IPFIX) vs.
> Measurement Process(PSAMP)
> Terminology problem: When psamp started it wasn't clear that ipfix would be
> chosen for export, the architecture is similar but still different. What IPFIX
> calls "metering" is defined as "measurement" in PSAMP terminology.
> Juergen: Let's use term "metering" for both. Shall we also drop terms
> "selection process" and "reporting process"?
> Tanja: Keep selection process as part of metering process (is in line with
> IPFIX, because metering process can contain sampling/filtering). But
> selection process should be kept.
> Nick: I agree.
> Juergen: The changes need to be applied also to the framework draft and the
> packet selection draft that are currently in AD review.
>
>
> Juergen, I would be perfectly happy to edit the diagram as you draw it.
>
> Regards, Benoit.
>
>
>
>
>
>
> The same steps from 1 to 4 will have to be executed for [PSAMP-FMWK] and [PSAMP-TECH]. Alternatively, you might copy the new definitions from the next [PSAMP-PROTO] version.
>
> Regards, Benoit.
>
>
>  Dear all,
>
> Do I understand correctly from the meeting minutes (below) that we get rid of the Reporting Process.
>
>
>
> Open Issue (not numbered): Terminology Metering Process (IPFIX) vs.
>   Measurement Process(PSAMP)
> Terminology problem: When psamp started it wasn't clear that ipfix would be
> chosen for export, the architecture is similar but still different. What IPFIX
> calls "metering" is defined as "measurement" in PSAMP terminology.
> Juergen: Let's use term "metering" for both.  Shall we also drop terms
>   "selection process" and "reporting process"?
> Tanja: Keep selection process as part of metering process (is in line with
>   IPFIX, because metering process can contain sampling/filtering).  But
>   selection process should be kept.
> Nick: I agree.
> Juergen: The changes need to be applied also to the framework draft and the
>   packet selection draft that are currently in AD review.
>
>
> Without objections, I will be removing the concept of Reporting Process in [PSAMP-PROTO].
> Anyway, we don't need it in the protocol.
>
> Regards, Benoit.
>
>
>
>
> Tanja, Nick, and al.
>
> Regarding the "Measurement Process -> Metering Process" issue discussed during the IETF meeting, I understand that:
> - the Measurement Process definition disappears
> - we replace all instances of Measurement Process by (IPFIX) Metering Process
> - we keep the Selection Process
>
> I was not too clear about the following point:
> - do we keep the Reporting Process?
>    There is actually no information about it (no such thing such as Reporting Process ID)
>    This is just a concept, right?
>
> Regards, Benoit.
>
>
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
>
>
>
>
>
>
>



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 08:49:51 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep4Ln-00086m-Fz
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 08:49:51 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14961
	for ; Wed, 21 Dec 2005 08:48:46 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep4GY-0006a5-8I
	for psamp-data@psg.com; Wed, 21 Dec 2005 13:44:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep4GX-0006Zt-NC
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 13:44:25 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLDiOt06818;
	Wed, 21 Dec 2005 08:44:24 -0500 (EST)
Received: from [10.61.65.159] (ams-clip-vpn-dhcp415.cisco.com [10.61.65.159])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLDiNC09417;
	Wed, 21 Dec 2005 14:44:23 +0100 (CET)
Message-ID: <43A95C36.6090407@cisco.com>
Date: Wed, 21 Dec 2005 14:44:22 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Juergen Quittek 
CC: psamp 
Subject: Re: Open Issue 1: optional compression
References: <43A80797.4040304@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Juergen,

Fine. I added a new entry in section 6.1 IPFIX Solution for the PSAMP 
requirement

* Compression: to conserve network bandwidth and resources at the 
Collector, the Export Packets may be compressed before export.

With the choice of IPFIX as PSAMP export protocol, the compression 
option mentioned in the framework is not addressed.

Regards, Benoit.
> Benoit,
>
> I think the protocol document should state that with the choice of
> IPFIX as protocol, the compression option mentioned in the framework
> is not addressed.
>
> Thanks,
>
>    Juergen
>
> --On 20.12.2005 14:31 Uhr +0100 Benoit Claise wrote:
>
>>
>> Dear all,
>>
>>
>> [PSAMP-FMWK] mentions the optional Export Packets compression (see 
>> section 8.5)
>> Should we mention it in [PSAMP-PROTO]?
>>
>> This requirement comes from a time at which we didn't know that IPFIX 
>> would be selected.
>> As [IPFIX-PROTO] doesn't mention compression, I'm in favor not to add 
>> anything about compression in [PSAMP-PROTO].
>> I don't think that this is appropriate to differentiate the IPFIX and 
>> PSAMP protocols; the PSAMP protocol must use the IPFIX specifications 
>> as defined in [IPFIX-PROTO]
>>
>> Feedback?
>>
>> Regards, Benoit.


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 10:18:41 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep5jl-0004i2-Sl
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 10:18:41 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28985
	for ; Wed, 21 Dec 2005 10:17:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep5fX-000Cwf-96
	for psamp-data@psg.com; Wed, 21 Dec 2005 15:14:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_PASS 
	autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep5fW-000CwT-K0
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 15:14:18 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLFEHF13292
	for ; Wed, 21 Dec 2005 10:14:17 -0500 (EST)
Received: from [10.61.65.159] (ams-clip-vpn-dhcp415.cisco.com [10.61.65.159])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLFE1C15221
	for ; Wed, 21 Dec 2005 16:14:01 +0100 (CET)
Message-ID: <43A97138.90704@cisco.com>
Date: Wed, 21 Dec 2005 16:14:00 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: psamp 
Subject: Open issue 15: chunk with a too short length
Content-Type: multipart/alternative;
 boundary="------------020104030000060409050300"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------020104030000060409050300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

 From the Vancouver meeting minutes:

    Open Issue (not numbered): Chunk with too short length
    How to encode "chunk" with a too short length? Padding wouldn't be
    recognized
    by the collector. One solution would be using a new template for
    each length.
    Proposal: The protocol draft should say that padding MUST NOT be
    used for
    variable length IEs.

Here is a new proposed text (actually, only the second paragraph is new)

Basic Packet Report

For each selected packet, the Packet Report MUST contain the following 
information:
- The associationsId Information Element
- Some number of contiguous bytes from the start of the packet, 
including the packet header (which includes link layer, network layer 
and other encapsulation headers) and some subsequent bytes of the packet 
payload.  Alternatively, the number of contiguous bytes may start at the 
beginning of the payload. The Layer2PacketSection, 
l2PayloadPacketSection, mplsLabelStackSection, mplsPayloadPacketSection, 
ipPacketSection, and ipPayloadPacketSection PSAMP Information Elements 
are available for this use. 
- The input sequence number(s) of any Selectors that acted on the 
packet, represented by the selectorInputSequenceNumber Information Element.
 
The contiguous Information Elements (Layer2PacketSection, 
l2PayloadPacketSection, mplsLabelStackSection, mplsPayloadPacketSection, 
ipPacketSection, and ipPayloadPacketSection) MAY be encoded with a fixed 
length field or with a variable sized field. If one of these Information 
Elements is encoded with a fixed length field whose length is too long 
for the number of contiguous bytes in the selected packet, padding MUST 
NOT be used. In this case, the Exporting Process MUST export the 
information either in a new Template Record with the correct fixed 
length field, or either in a new Template Record with a variable length 
field.  


Feedback?

Regards, Benoit.


--------------020104030000060409050300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  


Dear all,



From the Vancouver meeting minutes:


Open Issue (not numbered): Chunk with too short length

How to encode "chunk" with a too short length? Padding wouldn't be
recognized 

by the collector. One solution would be using a new template for each
length.

Proposal: The protocol draft should say that padding MUST NOT be used
for

variable length IEs.




Here is a new proposed text (actually, only the second paragraph is new)


Basic Packet Report



For each selected packet, the Packet Report MUST contain the
following information:


- The associationsId Information Element


- Some number of contiguous bytes from the start of the
packet, including the packet header (which includes link layer, network
layer
and other encapsulation headers) and some subsequent bytes of the
packet
payload.  Alternatively, the number of
contiguous bytes may start at the beginning of the payload. The
Layer2PacketSection, l2PayloadPacketSection, mplsLabelStackSection,
mplsPayloadPacketSection,
ipPacketSection, and ipPayloadPacketSection PSAMP Information Elements
are
available for this use.  


- The input sequence number(s) of any Selectors that acted on
the packet, represented by the selectorInputSequenceNumber Information
Element.


 


The contiguous Information Elements (Layer2PacketSection,
l2PayloadPacketSection,
mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection, and
ipPayloadPacketSection)
MAY be encoded with a fixed length field or with a variable sized
field. If one
of these Information Elements is encoded with a fixed length field
whose length
is too long for the number of contiguous bytes in the selected packet,
padding
MUST NOT be used. In this case, the Exporting Process MUST export the
information either in a new Template Record with the correct fixed
length field,
or either in a new Template Record with a variable length field.  





Feedback?



Regards, Benoit.






--------------020104030000060409050300--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 10:54:20 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep6IG-0005wB-P4
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 10:54:20 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05688
	for ; Wed, 21 Dec 2005 10:53:15 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep6DA-000FDe-8P
	for psamp-data@psg.com; Wed, 21 Dec 2005 15:49:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	SPF_HELO_PASS autolearn=ham version=3.1.0
Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep6D8-000FDP-D2
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 15:49:02 +0000
Received: from venus.office (europa.netlab.nec.de [10.1.1.25])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 87F60DB7A;
	Wed, 21 Dec 2005 16:49:01 +0100 (CET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Measurement Process -> Metering Process
Date: Wed, 21 Dec 2005 16:48:30 +0100
Content-Type: multipart/signed;
	micalg=SHA1;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_0057_01C6064E.5F80A540"
Message-ID: 
X-MS-Has-Attach: yes
Thread-Topic: Measurement Process -> Metering Process
thread-index: AcYGIU4t9/xCJVMeRpGXBOPQCrXHVwAJFykw
From: "Thomas Dietz" 
To: "Juergen Quittek" ,
        "Benoit Claise" 
Cc: "psamp" 
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0057_01C6064E.5F80A540
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Juergen and Benoit,

I support Juergens view. Its consistent with IPFIX and thus easier to
understand for those who already implemented IPFIX (which I guess will be
the majority).

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 90511-28
NEC Europe Ltd.                    Fax:    +49 6221 90511-55
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
  

> -----Original Message-----
> From: owner-psamp@ops.ietf.org 
> [mailto:owner-psamp@ops.ietf.org] On Behalf Of Juergen Quittek
> Sent: Wednesday, December 21, 2005 12:24 PM
> To: Benoit Claise
> Cc: psamp
> Subject: Re: Measurement Process -> Metering Process
> 
> --On 21.12.2005 11:37 Uhr +0100 Benoit Claise wrote:
> 
> > Juergen Quittek wrote:
> >
> > Hi Benoit,
> >
> > Thanks for elaborating this change.
> > Please find a comment in line.
> >
> > --On 19.12.2005 17:28 Uhr +0100 Benoit Claise wrote:
> >
> >
> > Dear all,
> >
> > I applied the editorial changes.
> >
> > 1. I deleted the definition of "Reporting Process"
> > 2. I removed/replaced all remaining occurrence of 
> "Reporting Process"
> >     btw, as a consequence, I updated the definitions of 
> "packet report", "report interpretation", "report stream"
> > 3. I deleted the definition of "Measurement Process"
> > 4. I modified all remaining occurrence of "Measurement 
> Process" by "Selection Process"
> >    btw, as a consequence, I modified the definitions of 
> "Exporting Process"
> >    I also modified the different requirements from 
> [PSAMP-FMWK] that I was quoting in section 6.
> >    As a consequence, [PSAMP-FMWK] will have to be updated 
> accordingly.
> >
> > Then, the figure becomes.
> >
> >
> >                +---------+      +---------+
> >      Observed  |Selection|      |Exporting|
> >      Packet--->|Process  |----->|Process  |--->Collector
> >      Stream    +---------+      +---------+
> >               \--Metering-/
> >                \-Process-/
> >
> >      Figure B: PSAMP Processes
> >
> >
> > Shouldn't it be just
> >
> >               +---------+      +---------+
> >     Observed  |Metering |      |Exporting|
> >     Packet--->|Process  |----->|Process  |--->Collector
> >     Stream    +---------+      +---------+
> >
> > ?
> 
> I would use this figure for showing consistency with IPFIX.
> We can explain in the text that the metering process contains
> a selection process (as it does in IPFIX).
> 
> Thanks,
> 
>     Juergen
> 
> > Personally, this is what I would prefer. It makes more sense.
> > However, I was perfectly clear on the conclusions from the 
> meeting in Vancouver (this is reason why I started this thread)
> > From the meeting minutes at 
> http://www3.ietf.org/proceedings/05nov/minutes/psamp.txt
> >
> > Open Issue (not numbered): Terminology Metering Process (IPFIX) vs.
> > Measurement Process(PSAMP)
> > Terminology problem: When psamp started it wasn't clear 
> that ipfix would be
> > chosen for export, the architecture is similar but still 
> different. What IPFIX
> > calls "metering" is defined as "measurement" in PSAMP terminology.
> > Juergen: Let's use term "metering" for both. Shall we also 
> drop terms
> > "selection process" and "reporting process"?
> > Tanja: Keep selection process as part of metering process 
> (is in line with
> > IPFIX, because metering process can contain sampling/filtering). But
> > selection process should be kept.
> > Nick: I agree.
> > Juergen: The changes need to be applied also to the 
> framework draft and the
> > packet selection draft that are currently in AD review.
> >
> >
> > Juergen, I would be perfectly happy to edit the diagram as 
> you draw it.
> >
> > Regards, Benoit.
> >
> >
> >
> >
> >
> >
> > The same steps from 1 to 4 will have to be executed for 
> [PSAMP-FMWK] and [PSAMP-TECH]. Alternatively, you might copy 
> the new definitions from the next [PSAMP-PROTO] version.
> >
> > Regards, Benoit.
> >
> >
> >  Dear all,
> >
> > Do I understand correctly from the meeting minutes (below) 
> that we get rid of the Reporting Process.
> >
> >
> >
> > Open Issue (not numbered): Terminology Metering Process (IPFIX) vs.
> >   Measurement Process(PSAMP)
> > Terminology problem: When psamp started it wasn't clear 
> that ipfix would be
> > chosen for export, the architecture is similar but still 
> different. What IPFIX
> > calls "metering" is defined as "measurement" in PSAMP terminology.
> > Juergen: Let's use term "metering" for both.  Shall we also 
> drop terms
> >   "selection process" and "reporting process"?
> > Tanja: Keep selection process as part of metering process 
> (is in line with
> >   IPFIX, because metering process can contain 
> sampling/filtering).  But
> >   selection process should be kept.
> > Nick: I agree.
> > Juergen: The changes need to be applied also to the 
> framework draft and the
> >   packet selection draft that are currently in AD review.
> >
> >
> > Without objections, I will be removing the concept of 
> Reporting Process in [PSAMP-PROTO].
> > Anyway, we don't need it in the protocol.
> >
> > Regards, Benoit.
> >
> >
> >
> >
> > Tanja, Nick, and al.
> >
> > Regarding the "Measurement Process -> Metering Process" 
> issue discussed during the IETF meeting, I understand that:
> > - the Measurement Process definition disappears
> > - we replace all instances of Measurement Process by 
> (IPFIX) Metering Process
> > - we keep the Selection Process
> >
> > I was not too clear about the following point:
> > - do we keep the Reporting Process?
> >    There is actually no information about it (no such thing 
> such as Reporting Process ID)
> >    This is just a concept, right?
> >
> > Regards, Benoit.
> >
> >
> > --
> > to unsubscribe send a message to psamp-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: 
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
> 

------=_NextPart_000_0057_01C6064E.5F80A540
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw
ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE
EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG
9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S
C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw
j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg
LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O
IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc
gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo
2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV
0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG
A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD
VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE
aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN
AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz
MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj
YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs
YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56
fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw
AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo
SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm
CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ
KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp
ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA
dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC
AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j
cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp
BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6
GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh
eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTIyMTE1NDgzMFowIwYJKoZIhvcNAQkEMRYEFF5xPvCx
TBMBfdyys5DWAhoxyL/AMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ
c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAB/Jb5wSbbKCEJTG+wSH
F4slhzAtno3vAmlcyfD7oDuAhpJ2aNv+gHwDM7tMAUG00vJyHpSOUUDamyDgv2ADleSXgkune9nw
FfVcNFaodnXiguCXw5HSpGmb5IXUHUTZIzoQKQnty8kfKduuqw3aW6/LfKBomIRV6+IOoQopqBfa
Mnnne7Z+aKOJHlwtnP1BKh7HfY288/3B9lGYjWtSAH5SNnNKCIqZfi34Vxj2qsYoLB8ILlSVW7JS
BikS6Bjscvmlvh+A8G9rsHogs8HHvyfIKd+xOyiBPkz3+aPw68jbImMd+BYKW2MLrwt0Y0zQ8+C6
qc88ufKtf84C55A2nnsAAAAAAAA=

------=_NextPart_000_0057_01C6064E.5F80A540--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 10:55:00 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep6Iu-0006B6-Mi
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 10:55:00 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05709
	for ; Wed, 21 Dec 2005 10:53:55 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep6GI-000FST-3l
	for psamp-data@psg.com; Wed, 21 Dec 2005 15:52:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep6GH-000FSF-Js
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 15:52:17 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLFqGr16198;
	Wed, 21 Dec 2005 10:52:16 -0500 (EST)
Received: from [10.61.65.159] (ams-clip-vpn-dhcp415.cisco.com [10.61.65.159])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLFqFC26795;
	Wed, 21 Dec 2005 16:52:15 +0100 (CET)
Message-ID: <43A97A2E.8060905@cisco.com>
Date: Wed, 21 Dec 2005 16:52:14 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Thomas Dietz 
CC: Juergen Quittek , psamp 
Subject: Re: Measurement Process -> Metering Process
References: 
In-Reply-To: 
Content-Type: multipart/alternative;
 boundary="------------040007080709060909060903"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------040007080709060909060903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Thomas,

Very good. Below is the new proposal.

Regards, Benoit.

    The figure B indicates the sequence of the processes (selection and
    exporting) within the PSAMP Device.
         
                          +----------+      +-----------+
         Observed  | Metering |         | Exporting |
         Packet--->| Process  |----->| Process   |--->Collector  
         Stream     +----------+       +-----------+ 
     
        Figure B: PSAMP Processes
                         
    The Selection Process, which takes an Observed Packet Stream as its
    input, and produces Packet Reports as its output, is an integral
    part of the Metering Process, which by its definition, produces Flow
    Records as its output.


> Hi Juergen and Benoit,
>
> I support Juergens view. Its consistent with IPFIX and thus easier to
> understand for those who already implemented IPFIX (which I guess will be
> the majority).
>
> Thomas
>
>   


--------------040007080709060909060903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Hi Thomas,



Very good. Below is the new proposal.



Regards, Benoit.




The figure B indicates the sequence of the processes
(selection and exporting) within the PSAMP Device.
  

        

                        +----------+      +-----------+
  

       Observed 
  | Metering |         |
Exporting | 

       Packet--->|
Process  |----->| Process   |--->Collector   

       Stream 
     +----------+       +-----------+  

   
  

      Figure
B: PSAMP Processes
  

                        

The Selection Process, which takes an Observed Packet Stream
as its input, and produces Packet Reports as its output, is an integral
part of
the Metering Process, which by its definition, produces Flow Records as
its
output.







  
Hi Juergen and Benoit,

I support Juergens view. Its consistent with IPFIX and thus easier to
understand for those who already implemented IPFIX (which I guess will be
the majority).

Thomas

  








--------------040007080709060909060903--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 11:01:13 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Ep6Ov-0000Ks-N4
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 11:01:13 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06589
	for ; Wed, 21 Dec 2005 11:00:08 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep6Ij-000Fff-Bk
	for psamp-data@psg.com; Wed, 21 Dec 2005 15:54:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO,
	SPF_HELO_PASS autolearn=ham version=3.1.0
Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Ep6Ih-000FfN-RG
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 15:54:48 +0000
Received: from venus.office (europa.netlab.nec.de [10.1.1.25])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 061C31F216;
	Wed, 21 Dec 2005 16:54:47 +0100 (CET)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Uniform Probabilistic Sampling in PSAMP-PROTO
Date: Wed, 21 Dec 2005 16:54:30 +0100
Content-Type: multipart/signed;
	micalg=SHA1;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_0061_01C6064F.36249CF0"
Message-ID: 
X-MS-Has-Attach: yes
Thread-Topic: Uniform Probabilistic Sampling in PSAMP-PROTO
thread-index: AcYGIEqJ1CkrX54ZQBWktsw9TDMpiAAJiv2w
From: "Thomas Dietz" 
To: "Juergen Quittek" ,
        "Andrew Johnson" ,
        "Benoit Claise" 
Cc: "psamp" 
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0061_01C6064F.36249CF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear all,

I would also vote for solution 1 or 2. If we choose solution 2 then we
should adjust the value as Benoit suggested.

Regards,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 90511-28
NEC Europe Ltd.                    Fax:    +49 6221 90511-55
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
  

> -----Original Message-----
> From: owner-psamp@ops.ietf.org 
> [mailto:owner-psamp@ops.ietf.org] On Behalf Of Juergen Quittek
> Sent: Wednesday, December 21, 2005 12:16 PM
> To: Andrew Johnson; Benoit Claise
> Cc: psamp
> Subject: Re: Uniform Probabilistic Sampling in PSAMP-PROTO
> 
> Hi Andrew,
> 
> --On 08.12.2005 16:53 Uhr +0000 Andrew Johnson wrote:
> 
> > Benoit Claise wrote:
> > [SNIP]
> >> Initially we wanted to model the probability in 
> [PSAMP-PROTO] with a
> >> float, which is allowed by [IPFIX-PROTO].
> >> However, we've got the issue that SMIv2 doesn't support floats.
> >
> > Although the floating point type is not a base type in SMI there are
> > a couple of proposals about how to send them.  This extract is from
> > the comp.protocols.snmp SNMP FAQ:
> >
> >   http://www.faqs.org/faqs/snmp-faq/part2/
> >   ===============================================================
> >   2.40.04
> >   SUBJECT: Floating Point Numbers in SMI?
> >
> >   You cannot add new base types to the SMI.
> >
> >   For now, the easiest way to have floating point numbers
> >   in SNMP MIBs is to use the base type OCTET STRING and
> >   encode the value in ASCII.
> >
> >   This is not the most elegant approach. However, it will work
> >   between your agent and your management application and it will
> >   be compliant to the SNMP SMI and protocol specifications.
> >
> >   David Perkins
> >   ===============================================================
> >
> > Apparently this method is implemented in the NET-SNMP agent and
> > manager.
> >   (http://ops.ietf.org/lists/mreview/mreview.2004/msg00083.html)
> >
> > Whether we use the above suggested method or define a new way of
> > using unsigned32 the application will have to have some way of
> > converting that number before it can be used.
> 
> This would be Solution 4.
> I still prefer Solution 1 or Solution 2.
> 
> >> What to do now?
> >>
> >> _Solution 1: _
> >> We export the probability with a float, and we approximate 
> this value
> >> with the MIB variable.
> >>
> >> _Solution 2: _
> >> We export the probability with an unsigned32, exactly the 
> same content
> >> as the MIB variable psampSampUniProbProbability
> >>
> >> _Solution 3: _
> >> We export the probability with two values N, M.
> >>     This means 2 inter-dependent I.E.s and 2 MIB variables 
> instead of one.
> >>     I don't like it too much
> >>
> >> I'm clearly in favor of solution 1. It's not right that we 
> would limit
> >> IPFIX because of the limitations of SMIv2
> >> Feedback?
> >>
> >> Side question: if we go for the float solution, should we have a
> >> float64? This would give us more precision
> >> Note: not yet defined in [IPFIX-PROTO].
> >
> > FYI:
> > The 32-bit float has 24 bits of precision, i.e. roughly 
> +/-0.000006%.
> 
> It is 23 bits we are using. Precision would be    roughly +/-0.00001%
> The Unsigned as Benoit suggests it would have     roughly 
> +/-0.0000001%
> 
> > The 64-bit float has 53 bits of precision, i.e. roughly 
> +/-0.00000000000001%
> > regards
> 
> Thanks,
> 
>     Juergen
> 
> > Andrew
> >
> > --
> > to unsubscribe send a message to psamp-request@ops.ietf.org with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: 
> 
> 
> 
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
> 

------=_NextPart_000_0061_01C6064F.36249CF0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw
ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE
EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG
9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S
C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw
j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg
LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O
IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc
gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo
2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV
0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG
A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD
VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE
aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN
AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz
MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj
YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs
YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56
fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw
AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo
SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm
CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ
KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp
ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA
dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC
AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j
cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp
BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6
GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh
eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTIyMTE1NTQzMFowIwYJKoZIhvcNAQkEMRYEFHYzZIgM
Xpll1g/VA8dHa311JLKnMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ
c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAI5avNWVb4y2YJDZ6lYb
vIKw82TMKvJFdVicpbqI2q0hMPgGUOQ8xHgeonSz87IdKh5WOupHPKIauSwrbI5cWkvtrSY3F0Oa
DYH7uAl8dVOfGMUVTxHAIDzsAan23LRaV6/O7aFa4NH1nmRxBcaG3tFYIokDR0FcZLTkO7NtjWfs
Nyu8fHZOr497cV4YTidZk9ZkLjyQIscWJc5LXLVuehEcrFlvjO8U11QI8iTFVCVQ0xUkmSX1Gjin
RAliX76PagkQMsHoZmLmw/F8/odIAgaTCLLicu7vb28JtiuUqXvx38AIuOFwnwuc+V8+Sa6QuuIy
4bGe7cBj0rXCfrhQoX4AAAAAAAA=

------=_NextPart_000_0061_01C6064F.36249CF0--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 17:58:56 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpCvA-00080U-PN
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 17:58:56 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24200
	for ; Wed, 21 Dec 2005 17:57:51 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpCrq-000LLK-H1
	for psamp-data@psg.com; Wed, 21 Dec 2005 22:55:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_PASS 
	autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpCrp-000LL4-R6
	for psamp@ops.ietf.org; Wed, 21 Dec 2005 22:55:29 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLMtSi14539
	for ; Wed, 21 Dec 2005 17:55:28 -0500 (EST)
Received: from [10.61.65.159] (ams-clip-vpn-dhcp415.cisco.com [10.61.65.159])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBLMtQC09887;
	Wed, 21 Dec 2005 23:55:26 +0100 (CET)
Message-ID: <43A9DD5D.80209@cisco.com>
Date: Wed, 21 Dec 2005 23:55:25 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: Benoit Claise 
CC: psamp 
Subject: Re: Open issue 15: chunk with a too short length
References: <43A97138.90704@cisco.com>
In-Reply-To: <43A97138.90704@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------010903010301040703060201"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------010903010301040703060201
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

BTW, regarding [PSAMP-INFO], the 2 ipHeaderPacketSection and 
ipPayloadPacketSection information element descriptions currently contain:

    "If insufficient octets are available,
    the remainder of the data should be zero-filled and an additional
    information element sent (e.g., ipPayloadLength) indicating how
    much of the data is valid."

Obviously these sentences will have to be removed.

Regards, Benoit.
> Dear all,
>
> >From the Vancouver meeting minutes:
>
>     Open Issue (not numbered): Chunk with too short length
>     How to encode "chunk" with a too short length? Padding wouldn't be
>     recognized
>     by the collector. One solution would be using a new template for
>     each length.
>     Proposal: The protocol draft should say that padding MUST NOT be
>     used for
>     variable length IEs.
>
> Here is a new proposed text (actually, only the second paragraph is new)
>   
> Basic Packet Report
>
> For each selected packet, the Packet Report MUST contain the following 
> information:
> - The associationsId Information Element
> - Some number of contiguous bytes from the start of the packet, 
> including the packet header (which includes link layer, network layer 
> and other encapsulation headers) and some subsequent bytes of the 
> packet payload.  Alternatively, the number of contiguous bytes may 
> start at the beginning of the payload. The Layer2PacketSection, 
> l2PayloadPacketSection, mplsLabelStackSection, 
> mplsPayloadPacketSection, ipPacketSection, and ipPayloadPacketSection 
> PSAMP Information Elements are available for this use. 
> - The input sequence number(s) of any Selectors that acted on the 
> packet, represented by the selectorInputSequenceNumber Information 
> Element.
>  
> The contiguous Information Elements (Layer2PacketSection, 
> l2PayloadPacketSection, mplsLabelStackSection, 
> mplsPayloadPacketSection, ipPacketSection, and ipPayloadPacketSection) 
> MAY be encoded with a fixed length field or with a variable sized 
> field. If one of these Information Elements is encoded with a fixed 
> length field whose length is too long for the number of contiguous 
> bytes in the selected packet, padding MUST NOT be used. In this case, 
> the Exporting Process MUST export the information either in a new 
> Template Record with the correct fixed length field, or either in a 
> new Template Record with a variable length field.  
>
>
> Feedback?
>
> Regards, Benoit.
>


--------------010903010301040703060201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  


BTW, regarding [PSAMP-INFO], the 2 ipHeaderPacketSection and
ipPayloadPacketSection information element descriptions currently
contain:


"If insufficient octets are available,

the remainder of the data should be zero-filled and an additional

information element sent (e.g., ipPayloadLength) indicating how

much of the data is valid."



Obviously these sentences will have to be removed.



Regards, Benoit.


 Dear all,

  

>From the Vancouver meeting minutes:

  
Open Issue (not numbered): Chunk with too short length

How to encode "chunk" with a too short length? Padding wouldn't be
recognized 

by the collector. One solution would be using a new template for each
length.

Proposal: The protocol draft should say that padding MUST NOT be used
for

variable length IEs.

  

  
Here is a new proposed text (actually, only the second paragraph is new)
  

Basic Packet Report

  

For each selected packet, the Packet Report MUST contain the
following information:
  

- The associationsId Information Element
  

- Some number of contiguous bytes from the start of the
packet, including the packet header (which includes link layer, network
layer
and other encapsulation headers) and some subsequent bytes of the
packet
payload.  Alternatively, the number of
contiguous bytes may start at the beginning of the payload. The
Layer2PacketSection, l2PayloadPacketSection, mplsLabelStackSection,
mplsPayloadPacketSection,
ipPacketSection, and ipPayloadPacketSection PSAMP Information Elements
are
available for this use.  
  

- The input sequence number(s) of any Selectors that acted on
the packet, represented by the selectorInputSequenceNumber Information
Element.
  

   
  

The contiguous Information Elements (Layer2PacketSection,
l2PayloadPacketSection,
mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection, and
ipPayloadPacketSection)
MAY be encoded with a fixed length field or with a variable sized
field. If one
of these Information Elements is encoded with a fixed length field
whose length
is too long for the number of contiguous bytes in the selected packet,
padding
MUST NOT be used. In this case, the Exporting Process MUST export the
information either in a new Template Record with the correct fixed
length field,
or either in a new Template Record with a variable length field.  

  

  

Feedback?

  

Regards, Benoit.

  








--------------010903010301040703060201--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 21 19:34:40 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpEPo-00028l-NJ
	for psamp-archive@megatron.ietf.org; Wed, 21 Dec 2005 19:34:40 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03600
	for ; Wed, 21 Dec 2005 19:33:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpEKi-0003Ey-Ek
	for psamp-data@psg.com; Thu, 22 Dec 2005 00:29:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpEKh-0003En-Ti
	for psamp@ops.ietf.org; Thu, 22 Dec 2005 00:29:24 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBM0TKp19869
	for ; Wed, 21 Dec 2005 19:29:21 -0500 (EST)
Received: from [10.61.65.159] (ams-clip-vpn-dhcp415.cisco.com [10.61.65.159])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBM0T4C27754
	for ; Thu, 22 Dec 2005 01:29:04 +0100 (CET)
Message-ID: <43A9F344.8010308@cisco.com>
Date: Thu, 22 Dec 2005 01:28:52 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051025)
MIME-Version: 1.0
To: psamp 
Subject: PSAMP open issue 18: export rate limit?
Content-Type: text/plain; charset=windows-1252; format=flowed
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA03600

Dear all,

In [PSAMP-FMWK], the following statement is still un-addressed in=20
[PSAMP-PROTO]
PROTO-18 =93The exporting process must have an export rate limit,=20
configurable per Exporting Process=94.
See section 8.3 for the details=20
http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-10.txt


First of all, I have a question regarding the requirement itself. Isn't=20
it supposed to mean: =93The exporting process must have an export rate=20
limit, configurable per Collecting Process=94? Otherwise, I don't=20
understand the exact requirement when we have a PSAMP device exporting=20
to multiple collectors!

Then, how to address the requirement?
Shall we simply update [PSAMP-PROTO] with a sentence such as: "The=20
exporting process MUST have an export rate limit, configurable per=20
Collecting Process"?
And that's it?

Do we keep the export rate limit as a generic term? Or do we define=20
precisely what it mean? Example: number of IPFIX Messages, number of=20
bytes/s, number of records/s?

As always, your views are appreciated.

Regards, Benoit.





--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Thu Dec 22 07:10:54 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpPHa-0004NM-5D
	for psamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 07:10:54 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01844
	for ; Thu, 22 Dec 2005 07:09:47 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpPBz-0006Zq-6x
	for psamp-data@psg.com; Thu, 22 Dec 2005 12:05:07 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [193.174.154.14] (helo=mailhub.fokus.fraunhofer.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpPBx-0006ZV-Uy
	for psamp@ops.ietf.org; Thu, 22 Dec 2005 12:05:06 +0000
Received: from [10.147.67.245] (i4dhcp245 [10.147.67.245])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id jBMC4vw08903;
	Thu, 22 Dec 2005 13:05:01 +0100 (MET)
Message-ID: <43AA9667.2070909@fokus.fraunhofer.de>
Date: Thu, 22 Dec 2005 13:04:55 +0100
From: Tanja Zseby 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Benoit Claise 
CC: psamp 
Subject: Re: Open Issue 6: Associations ID -> Selection Path
References: <43A816BC.2030604@cisco.com>
In-Reply-To: <43A816BC.2030604@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Benoit,

I also prefer Selection Path.

Kind regards,
Tanja

Benoit Claise wrote:

> Dear all,
>
> The PSAMP open issue 6 is the following:
>
>    Even if the notion of Associations ID is mentioned in [PSAMP-TECH],
>    maybe a term such as SelectionPath or PathID would be more 
> appropriate.
>
> The background of this issue is the following.
> [PSAMP-TECH] specifies the Associations ID like this:
>
>    ASSOCIATIONS        Values:  IPFIX Exporting    process ID, IDs of other associated processes>    
> With STREAM ID: Observation point ID AND List of SELECTOR_IDs
> However, we concluded during the last IETF meeting that we don't need 
> the IPFIX Metering and Exporting Process ID.
> So we're left with:
>
>    Values: 
>
> Since we don't associate anymore the observation point with processes, 
> it was proposed to change the name:
> from "Associations ID" to "Selection Path" or "Path ID".
>
> Personally, I prefer the Selection Path term, along with the 
> selectionPath I.E.
> For the simple reason that we speak of selection methods all over in 
> the PSAMP drafts.
>
> Feedback?
>
> Regards, Benoit.
>
>
>

-- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: zseby@fokus.fraunhofer.de	
Kaiserin-Augusta-Allee 31			Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Thu Dec 22 07:24:07 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpPUN-0000tX-CN
	for psamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 07:24:07 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03197
	for ; Thu, 22 Dec 2005 07:23:01 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpPQI-0007Zv-Kv
	for psamp-data@psg.com; Thu, 22 Dec 2005 12:19:54 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [193.174.154.14] (helo=mailhub.fokus.fraunhofer.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpPQH-0007Zj-SI
	for psamp@ops.ietf.org; Thu, 22 Dec 2005 12:19:54 +0000
Received: from [10.147.67.245] (i4dhcp245 [10.147.67.245])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id jBMCJow11921;
	Thu, 22 Dec 2005 13:19:50 +0100 (MET)
Message-ID: <43AA99E5.6040003@fokus.fraunhofer.de>
Date: Thu, 22 Dec 2005 13:19:49 +0100
From: Tanja Zseby 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thomas Dietz 
CC: Juergen Quittek , Benoit Claise ,
        psamp 
Subject: Re: Measurement Process -> Metering Process
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Benoit,

I also support this. If the metering process contains the selection 
process this is also fully in line with IPFIX.

Regards
Tanja

Thomas Dietz wrote:

>Hi Juergen and Benoit,
>
>I support Juergens view. Its consistent with IPFIX and thus easier to
>understand for those who already implemented IPFIX (which I guess will be
>the majority).
>
>Thomas
>
>  
>

-- 
Dipl.-Ing. Tanja Zseby			    	      	
Fraunhofer Institute FOKUS			Email: zseby@fokus.fraunhofer.de	
Kaiserin-Augusta-Allee 31			Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Thu Dec 22 09:28:55 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpRR8-0000bb-Sr
	for psamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 09:28:54 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18355
	for ; Thu, 22 Dec 2005 09:27:49 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpRMQ-000HJL-Nk
	for psamp-data@psg.com; Thu, 22 Dec 2005 14:24:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [193.174.154.14] (helo=mailhub.fokus.fraunhofer.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpRMO-000HJ3-H7
	for psamp@ops.ietf.org; Thu, 22 Dec 2005 14:24:00 +0000
Received: from [10.147.67.245] (i4dhcp245 [10.147.67.245])
	by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id jBMENTw04053;
	Thu, 22 Dec 2005 15:23:30 +0100 (MET)
Message-ID: <43AAB6E0.30900@fokus.fraunhofer.de>
Date: Thu, 22 Dec 2005 15:23:28 +0100
From: Tanja Zseby 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Benoit Claise 
CC: psamp 
Subject: Re: PSAMP open issue 18: export rate limit?
References: <43A9F344.8010308@cisco.com>
In-Reply-To: <43A9F344.8010308@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA18355

Hi Benoit,

I think originally this was about controlling the report rate.=20
Furthermore I think it could be difficult to control the number of bytes=20
(although it may be a useful feature) by the exporting process. So for=20
now I would only target the report export rate.

Regards
Tanja

Benoit Claise wrote:

> Dear all,
>
> In [PSAMP-FMWK], the following statement is still un-addressed in=20
> [PSAMP-PROTO]
> PROTO-18 =93The exporting process must have an export rate limit,=20
> configurable per Exporting Process=94.
> See section 8.3 for the details=20
> http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-10.txt
>
>
> First of all, I have a question regarding the requirement itself.=20
> Isn't it supposed to mean: =93The exporting process must have an export=
=20
> rate limit, configurable per Collecting Process=94? Otherwise, I don't=20
> understand the exact requirement when we have a PSAMP device exporting=20
> to multiple collectors!
>
> Then, how to address the requirement?
> Shall we simply update [PSAMP-PROTO] with a sentence such as: "The=20
> exporting process MUST have an export rate limit, configurable per=20
> Collecting Process"?
> And that's it?
>
> Do we keep the export rate limit as a generic term? Or do we define=20
> precisely what it mean? Example: number of IPFIX Messages, number of=20
> bytes/s, number of records/s?
>
> As always, your views are appreciated.
>
> Regards, Benoit.
>
>
>
>
>
> --=20
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 


--=20
Dipl.-Ing. Tanja Zseby			    	      =09
Fraunhofer Institute FOKUS			Email: zseby@fokus.fraunhofer.de=09
Kaiserin-Augusta-Allee 31			Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------=
-------------=20
"Living on earth is expensive but it includes a free trip around the sun.=
" (Anonymous)
-------------------------------------------------------------------------=
-------------


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Thu Dec 22 18:15:13 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpZeT-0000Or-MO
	for psamp-archive@megatron.ietf.org; Thu, 22 Dec 2005 18:15:13 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17054
	for ; Thu, 22 Dec 2005 18:14:07 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpZZJ-0009Df-Rq
	for psamp-data@psg.com; Thu, 22 Dec 2005 23:09:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpZZJ-0009DS-7F
	for psamp@ops.ietf.org; Thu, 22 Dec 2005 23:09:53 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBMN9qi15175;
	Thu, 22 Dec 2005 18:09:52 -0500 (EST)
Received: from [10.61.65.37] (ams-clip-vpn-dhcp293.cisco.com [10.61.65.37])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBMN9oC07005;
	Fri, 23 Dec 2005 00:09:50 +0100 (CET)
Message-ID: <43AB3234.9050709@cisco.com>
Date: Fri, 23 Dec 2005 00:09:40 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Tanja Zseby 
CC: psamp 
Subject: Re: Open Issue 6: Associations ID -> Selection Path
References: <43A816BC.2030604@cisco.com> <43AA9667.2070909@fokus.fraunhofer.de>
In-Reply-To: <43AA9667.2070909@fokus.fraunhofer.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ok, I made the modifications for the new draft that I will be posting soon.

Regards, Benoit.
> Hi Benoit,
>
> I also prefer Selection Path.
>
> Kind regards,
> Tanja
>
> Benoit Claise wrote:
>
>> Dear all,
>>
>> The PSAMP open issue 6 is the following:
>>
>>    Even if the notion of Associations ID is mentioned in [PSAMP-TECH],
>>    maybe a term such as SelectionPath or PathID would be more 
>> appropriate.
>>
>> The background of this issue is the following.
>> [PSAMP-TECH] specifies the Associations ID like this:
>>
>>    ASSOCIATIONS        Values: > IPFIX Exporting    process ID, IDs of other associated processes>    
>> With STREAM ID: Observation point ID AND List of SELECTOR_IDs
>> However, we concluded during the last IETF meeting that we don't need 
>> the IPFIX Metering and Exporting Process ID.
>> So we're left with:
>>
>>    Values: 
>>
>> Since we don't associate anymore the observation point with 
>> processes, it was proposed to change the name:
>> from "Associations ID" to "Selection Path" or "Path ID".
>>
>> Personally, I prefer the Selection Path term, along with the 
>> selectionPath I.E.
>> For the simple reason that we speak of selection methods all over in 
>> the PSAMP drafts.
>>
>> Feedback?
>>
>> Regards, Benoit.
>>
>>
>>
>


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 23 07:23:43 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EplxX-0004JQ-A2
	for psamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 07:23:43 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04205
	for ; Fri, 23 Dec 2005 07:22:36 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Eplq4-000250-8G
	for psamp-data@psg.com; Fri, 23 Dec 2005 12:16:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [195.37.70.21] (helo=kyoto.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Eplq2-00024j-VI
	for psamp@ops.ietf.org; Fri, 23 Dec 2005 12:15:59 +0000
Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39])
	by kyoto.netlab.nec.de (Postfix) with ESMTP id 38FC81BAC4D;
	Fri, 23 Dec 2005 13:15:57 +0100 (CET)
Date: Fri, 23 Dec 2005 13:15:58 +0100
From: Juergen Quittek 
To: Benoit Claise , psamp 
Subject: Re: PSAMP IANA considerations section
Message-ID: 
In-Reply-To: <43A92B20.3020600@cisco.com>
References:  <43A92B20.3020600@cisco.com>
X-Mailer: Mulberry/3.1.6 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 21.12.2005 11:14 Uhr +0100 Benoit Claise wrote:

> Dear all,
>
> Here is a proposal for the IANA considerations section.
>
>
> 1. 9. IANA Considerations
>
> The PSAMP Protocol, as set out in this document, has two sets of assigned numbers.  Considerations for assigning them are discussed in this section, using the example policies as set out in the "Guidelines for IANA Considerations" document IANA-RFC
> [RFC2434].
>
>      9.1 IPFIX Related Considerations
>
> As the PSAMP protocol uses the IPFIX protocol, refer to the IANA considerations section in [IPFIX-PROTO] for the assignments of numbers used in the protocol and for the numbers used in the information model.
>
>       9.2 PSAMP Related Considerations
>
> Each new selection method MUST be assigned a unique value for the selectorAlgorithm Information Element.  Its configuration parameter(s), along with the way to report it/them with an Options Template, MUST be clearly specified.
>
> Each new selection method MUST be assigned a unique value for the selectorAlgorithm Information Element.  New assignments for the PSAMP selection method will be administered by IANA, on a First Come First Served basis [RFC 2434], subject to Expert
> Review [RFC 2434], i.e. review by one of a group of experts designated by an IETF Operations and Management Area Director.  The group of experts must double check the Information Elements definitions with already defined Information Elements for
> completeness, accuracy and redundancy.  Those experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups.
>
> Now, two questions:
> 1. I'm not too sure whether we should mandate a new IETF RFC for the new selection method description?

This would be a tough requirement.  However, it would make sure that the
new methods is well documented.

> 2. I'm not too sure whether we should mandate new IANA-registered information elements for the new selection method?

Since we do not have vendor IDs in here, this is the only way of achieving
interoperability.

>     In other words, can we have proprietary selection method in the selectorAlgorithm Information Element?

Can't we assign an interval, say [1024 - ...] and declare selection methods
with identifiers in that interval as 'experimental' or even 'implementation specific'?

> Regards, Benoit.



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 23 07:44:11 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpmHL-0001Iw-8n
	for psamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 07:44:11 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05889
	for ; Fri, 23 Dec 2005 07:43:04 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpmDc-0004hO-71
	for psamp-data@psg.com; Fri, 23 Dec 2005 12:40:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_40_50,
	HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_HELO_PASS autolearn=ham 
	version=3.1.0
Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpmDa-0004gx-4k
	for psamp@ops.ietf.org; Fri, 23 Dec 2005 12:40:18 +0000
Received: from venus.office (venus.office [10.1.1.25])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 58F4415258;
	Fri, 23 Dec 2005 13:40:17 +0100 (CET)
Content-class: urn:content-classes:message
Subject: RE: Open issue 15: chunk with a too short length
MIME-Version: 1.0
Content-Type: multipart/signed;
	micalg=SHA1;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_0101_01C607C6.606022F0"
Date: Fri, 23 Dec 2005 13:40:02 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Message-ID: 
X-MS-Has-Attach: yes
Thread-Topic: Open issue 15: chunk with a too short length
Thread-Index: AcYGghZd9O1pG3dkTAePBAY5aefLfABO71hg
From: "Thomas Dietz" 
To: "Benoit Claise" 
Cc: "psamp" 
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0101_01C607C6.606022F0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0102_01C607C6.606022F0"


------=_NextPart_001_0102_01C607C6.606022F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Benoit, all,
 
Why don't we make the chunk elements by default variable length and just
don't allow them to be fixed length??
 
Regards,
 
Thomas

--
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 90511-28
NEC Europe Ltd.                    Fax:    +49 6221 90511-55
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
 
  

 


  _____  

From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On Behalf
Of Benoit Claise
Sent: Wednesday, December 21, 2005 11:55 PM
To: Benoit Claise
Cc: psamp
Subject: Re: Open issue 15: chunk with a too short length


BTW, regarding [PSAMP-INFO], the 2 ipHeaderPacketSection and
ipPayloadPacketSection information element descriptions currently contain:


"If insufficient octets are available,
the remainder of the data should be zero-filled and an additional
information element sent (e.g., ipPayloadLength) indicating how
much of the data is valid."


Obviously these sentences will have to be removed.

Regards, Benoit.


Dear all,

>From the Vancouver meeting minutes:


Open Issue (not numbered): Chunk with too short length
How to encode "chunk" with a too short length? Padding wouldn't be
recognized 
by the collector. One solution would be using a new template for each
length.
Proposal: The protocol draft should say that padding MUST NOT be used for
variable length IEs.


Here is a new proposed text (actually, only the second paragraph is new)

  
Basic Packet Report

For each selected packet, the Packet Report MUST contain the following
information: 
- The associationsId Information Element 
- Some number of contiguous bytes from the start of the packet, including
the packet header (which includes link layer, network layer and other
encapsulation headers) and some subsequent bytes of the packet payload.
Alternatively, the number of contiguous bytes may start at the beginning of
the payload. The Layer2PacketSection, l2PayloadPacketSection,
mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection, and
ipPayloadPacketSection PSAMP Information Elements are available for this
use.  
- The input sequence number(s) of any Selectors that acted on the packet,
represented by the selectorInputSequenceNumber Information Element. 
  
The contiguous Information Elements (Layer2PacketSection,
l2PayloadPacketSection, mplsLabelStackSection, mplsPayloadPacketSection,
ipPacketSection, and ipPayloadPacketSection) MAY be encoded with a fixed
length field or with a variable sized field. If one of these Information
Elements is encoded with a fixed length field whose length is too long for
the number of contiguous bytes in the selected packet, padding MUST NOT be
used. In this case, the Exporting Process MUST export the information either
in a new Template Record with the correct fixed length field, or either in a
new Template Record with a variable length field.  


Feedback?

Regards, Benoit.





------=_NextPart_001_0102_01C607C6.606022F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Dear Benoit, all,


 


Why don't we make the chunk elements by default =
variable=20
length and just don't allow them to be fixed =
length??


 


Regards,


 


Thomas


--
Thomas=20
Dietz           &n=
bsp;          =20
E-mail: Thomas.Dietz@netlab.nec.de
Network=20
Laboratories          &=
nbsp;   =20
Phone:  +49 6221 90511-28
NEC Europe=20
Ltd.           &nb=
sp;       =20
Fax:    +49 6221 90511-55
Kurfuersten-Anlage =
36
69115=20
Heidelberg, =
Germany          http://www.netlab.nec.de
 =
=20



 



  

  

  From: owner-psamp@ops.ietf.org=20
  [mailto:owner-psamp@ops.ietf.org] On Behalf Of Benoit=20
  Claise
Sent: Wednesday, December 21, 2005 11:55 =
PM
To:=20
  Benoit Claise
Cc: psamp
Subject: Re: Open issue =
15: chunk=20
  with a too short length


  
BTW, regarding [PSAMP-INFO], the 2 ipHeaderPacketSection =
and=20
  ipPayloadPacketSection information element descriptions currently =
contain:

  
"If insufficient octets are available,
the remainder of =
the=20
    data should be zero-filled and an additional
information element =
sent=20
    (e.g., ipPayloadLength) indicating how
much of the data is=20
  valid."
Obviously these sentences will have to be=20
  removed.

Regards, Benoit.

  
Dear=20
    all,

>From the Vancouver meeting minutes:

    
Open Issue (not numbered): Chunk with too short =
length
How=20
      to encode "chunk" with a too short length? Padding wouldn't be =
recognized=20
      
by the collector. One solution would be using a new template =
for each=20
      length.
Proposal: The protocol draft should say that padding =
MUST NOT=20
      be used for
variable length IEs.
Here is a =
new proposed text (actually, only the second paragraph is new)
  
Basic Packet Report

For each selected packet, the Packet=20
    Report MUST contain the following information: 
- The =
associationsId=20
    Information Element 
- Some number of contiguous bytes from the =
start of=20
    the packet, including the packet header (which includes link layer, =
network=20
    layer and other encapsulation headers) and some subsequent bytes of =
the=20
    packet payload.  Alternatively, the number of =
contiguous=20
    bytes may start at the beginning of the payload. The =
Layer2PacketSection,=20
    l2PayloadPacketSection, mplsLabelStackSection, =
mplsPayloadPacketSection,=20
    ipPacketSection, and ipPayloadPacketSection PSAMP Information =
Elements are=20
    available for this use.  
- The input sequence=20
    number(s) of any Selectors that acted on the packet, represented by =
the=20
    selectorInputSequenceNumber Information =
Element.=20
    
  
The contiguous Information Elements=20
    (Layer2PacketSection, l2PayloadPacketSection, mplsLabelStackSection, =

    mplsPayloadPacketSection, ipPacketSection, and =
ipPayloadPacketSection) MAY=20
    be encoded with a fixed length field or with a variable sized field. =
If one=20
    of these Information Elements is encoded with a fixed length field =
whose=20
    length is too long for the number of contiguous bytes in the =
selected=20
    packet, padding MUST NOT be used. In this case, the Exporting =
Process MUST=20
    export the information either in a new Template Record with the =
correct=20
    fixed length field, or either in a new Template Record with a =
variable=20
    length field. =
 


Feedback?

Regards,=20
    Benoit.




------=_NextPart_001_0102_01C607C6.606022F0--

------=_NextPart_000_0101_01C607C6.606022F0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw
ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE
EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG
9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S
C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw
j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg
LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O
IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc
gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo
2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV
0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG
A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD
VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE
aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN
AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz
MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj
YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs
YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56
fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw
AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo
SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm
CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ
KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp
ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA
dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC
AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j
cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp
BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6
GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh
eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTIyMzEyNDAwMlowIwYJKoZIhvcNAQkEMRYEFCsApDK7
blxdFD9uhIo+DGOhtBoeMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ
c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAH6Rai06Dxf5621W5afk
M5mJmI4W2reNtiHoeclkgbo0ssWiB7nxueEQIjMTZsTaaZhYheoecvpOlQblp+RwgBJBLs+4VuRH
iQC/96myvbtRlAPM3INVQXwasJjHQ/YO4nh0/m5QlTMQ9mFnjQlITwQJi6DfmepKh2EBTogBmmPd
uCfphL3+Md3ifjhLYX6dXLXWJiMUKEXZj2NKkCkObL/tEWkSFoWoP+yD/p5L0FADU+DTu+D6Dlx3
nlGrCbS2Gz/9X5vlJjojnTwqLSPUX+H6h/oDypSnDh04YApcOD/KzjQiUCRkd7ekhNzT03AOdgXe
X9mJi+WfQLp97hcXMVkAAAAAAAA=

------=_NextPart_000_0101_01C607C6.606022F0--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 23 07:47:12 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpmKF-0001li-6R
	for psamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 07:47:12 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06180
	for ; Fri, 23 Dec 2005 07:46:04 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpmHv-0005Dt-UP
	for psamp-data@psg.com; Fri, 23 Dec 2005 12:44:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,
	FORGED_RCVD_HELO,SPF_HELO_PASS autolearn=ham version=3.1.0
Received: from [195.37.70.40] (helo=smtp0.netlab.nec.de)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpmHu-0005DW-Qc
	for psamp@ops.ietf.org; Fri, 23 Dec 2005 12:44:47 +0000
Received: from venus.office (europa.netlab.nec.de [10.1.1.25])
	by smtp0.netlab.nec.de (Postfix) with ESMTP id 1F5A515258;
	Fri, 23 Dec 2005 13:44:46 +0100 (CET)
Content-class: urn:content-classes:message
Subject: RE: Open Issue 5: PSAMP transport protocol 
MIME-Version: 1.0
Content-Type: multipart/signed;
	micalg=SHA1;
	protocol="application/x-pkcs7-signature";
	boundary="----=_NextPart_000_010E_01C607C7.02ADF8C0"
Date: Fri, 23 Dec 2005 13:44:35 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Message-ID: 
X-MS-Has-Attach: yes
Thread-Topic: Open Issue 5: PSAMP transport protocol 
Thread-Index: AcYFbM80OtaWBxfHSaS+KuLw0aH4QgCUbcrA
From: "Thomas Dietz" 
To: "Benoit Claise" , "psamp" 
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_010E_01C607C7.02ADF8C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Benoit,

I think, with the mentioned sentence we cover everything because we have
IPFIX as basis...

Regards,

Thomas

-- 
Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
Network Laboratories               Phone:  +49 6221 90511-28
NEC Europe Ltd.                    Fax:    +49 6221 90511-55
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
  

> -----Original Message-----
> From: owner-psamp@ops.ietf.org 
> [mailto:owner-psamp@ops.ietf.org] On Behalf Of Benoit Claise
> Sent: Tuesday, December 20, 2005 2:50 PM
> To: psamp
> Subject: Open Issue 5: PSAMP transport protocol 
> 
> Dear all,
> 
> The PSAMP open issue 5 is the following:
> Transport protocol: SCTP and/or UDP and/or TCP. Nothing is 
> mentioned at 
> this stage. [PSAMP-FMWK] and PSAMP charter specifically mention UDP.
> 
> Currently, we don't mention anything regarding the transport protocol 
> selection in [PSAMP-PROTO].
> However, I think that we don't need to specify anything as we 
> have this 
> sentence in the draft:
>     "The entire IPFIX protocol specifications [IPFIX-PROTO] MUST be 
> implemented for the PSAMP export."
> This allows the same transport  protocol choices as specified in 
> [IPFIX-PROTO].
> 
> Please let me know if you disagree.
> 
> Regards, Benoit.
> 
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 
> 

------=_NextPart_000_010E_01C607C7.02ADF8C0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Disposition: attachment;
	filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw
ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE
EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG
9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S
C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw
j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg
LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O
IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc
gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA
A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo
2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV
0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG
A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD
VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE
aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN
AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz
MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj
YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs
YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56
fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw
AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo
SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm
CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ
KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV
BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp
ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w
MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA
dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC
AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j
cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp
BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6
GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh
eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU
aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MTIyMzEyNDQzNVowIwYJKoZIhvcNAQkEMRYEFFCp8geL
5tyn2y5ee77G2byc4vcRMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC
AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG
SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ
c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK
ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg
RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAGHi1NqbRPVph1G4+6Rl
Of10hAknICqzEKSLhjiAbEYBxlOTuToL9Z68o6JbYvjzhf+uzlYszony8j3B7ytqkNOyUGh2jot8
JtcWlGolDkiJT+Qy/LmsiUvjKKUH411mdSk41km89ILedcT7rzeL5F9d8lV5ilGV8ReHL49L7qah
l+bKU3d56hPTsCOSQXifpKPDplu+w1JjuZ5o3mKQk8IJO9fBC+Rh2exYhD1S35UJJxrGM4Amhntx
xiVyoQ4wRE8obx6Jmak4q0nYcxWuidD0ZKTeObfOlAFk75vEd44lpjHRM47X/W3COLRvz0meRWo6
Dw/g1FPxcjcq3hCaDfkAAAAAAAA=

------=_NextPart_000_010E_01C607C7.02ADF8C0--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 23 08:10:01 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpmgL-00019g-7d
	for psamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 08:10:01 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09037
	for ; Fri, 23 Dec 2005 08:08:54 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpmdR-0007mc-OE
	for psamp-data@psg.com; Fri, 23 Dec 2005 13:07:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,HTML_40_50,HTML_MESSAGE,HTML_TITLE_EMPTY,SPF_PASS 
	autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpmdP-0007mF-DQ
	for psamp@ops.ietf.org; Fri, 23 Dec 2005 13:06:59 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBND6vF03624;
	Fri, 23 Dec 2005 08:06:58 -0500 (EST)
Received: from [10.61.65.220] (ams-clip-vpn-dhcp476.cisco.com [10.61.65.220])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBND6pC27878;
	Fri, 23 Dec 2005 14:06:51 +0100 (CET)
Message-ID: <43ABF66A.8050206@cisco.com>
Date: Fri, 23 Dec 2005 14:06:50 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Thomas Dietz 
CC: psamp 
Subject: Re: Open issue 15: chunk with a too short length
References: 
In-Reply-To: 
Content-Type: multipart/alternative;
 boundary="------------050704030906040208000309"
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------050704030906040208000309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear Thomas,
> Dear Benoit, all,
>  
> Why don't we make the chunk elements by default variable length and 
> just don't allow them to be fixed length??
I see a drawback with this approach. I have to specify in [PSAMP-PROTO] 
that all chunk elements will be encoded with variable length I.E.. Fine, 
I can list all the ones that exist today. But what about the new ones, 
administered by IANA. How do we know that these are chunk elements or 
not? We could say: if it contains "Section" part of the name, this is a 
chunk, so encoded with a variable length -> this is a little bit light! 
Alternatively, we could specify in the I.E. description that it must be 
encoded with a variable length but it break the independence of the 
information model versus the protocol.

Regards, Benoit.
>  
> Regards,
>  
> Thomas
>
> --
> Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
> Network Laboratories               Phone:  +49 6221 90511-28
> NEC Europe Ltd.                    Fax:    +49 6221 90511-55
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany          http://www.netlab.nec.de 
> 
>  
>
>  
>
>     ------------------------------------------------------------------------
>     *From:* owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org]
>     *On Behalf Of *Benoit Claise
>     *Sent:* Wednesday, December 21, 2005 11:55 PM
>     *To:* Benoit Claise
>     *Cc:* psamp
>     *Subject:* Re: Open issue 15: chunk with a too short length
>
>     BTW, regarding [PSAMP-INFO], the 2 ipHeaderPacketSection and
>     ipPayloadPacketSection information element descriptions currently
>     contain:
>
>         "If insufficient octets are available,
>         the remainder of the data should be zero-filled and an additional
>         information element sent (e.g., ipPayloadLength) indicating how
>         much of the data is valid."
>
>     Obviously these sentences will have to be removed.
>
>     Regards, Benoit.
>>     Dear all,
>>
>>     >From the Vancouver meeting minutes:
>>
>>         Open Issue (not numbered): Chunk with too short length
>>         How to encode "chunk" with a too short length? Padding
>>         wouldn't be recognized
>>         by the collector. One solution would be using a new template
>>         for each length.
>>         Proposal: The protocol draft should say that padding MUST NOT
>>         be used for
>>         variable length IEs.
>>
>>     Here is a new proposed text (actually, only the second paragraph is new)
>>       
>>     Basic Packet Report
>>
>>     For each selected packet, the Packet Report MUST contain the
>>     following information:
>>     - The associationsId Information Element
>>     - Some number of contiguous bytes from the start of the packet,
>>     including the packet header (which includes link layer, network
>>     layer and other encapsulation headers) and some subsequent bytes
>>     of the packet payload.  Alternatively, the number of contiguous
>>     bytes may start at the beginning of the payload. The
>>     Layer2PacketSection, l2PayloadPacketSection,
>>     mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection,
>>     and ipPayloadPacketSection PSAMP Information Elements are
>>     available for this use. 
>>     - The input sequence number(s) of any Selectors that acted on the
>>     packet, represented by the selectorInputSequenceNumber
>>     Information Element.
>>      
>>     The contiguous Information Elements (Layer2PacketSection,
>>     l2PayloadPacketSection, mplsLabelStackSection,
>>     mplsPayloadPacketSection, ipPacketSection, and
>>     ipPayloadPacketSection) MAY be encoded with a fixed length field
>>     or with a variable sized field. If one of these Information
>>     Elements is encoded with a fixed length field whose length is too
>>     long for the number of contiguous bytes in the selected packet,
>>     padding MUST NOT be used. In this case, the Exporting Process
>>     MUST export the information either in a new Template Record with
>>     the correct fixed length field, or either in a new Template
>>     Record with a variable length field.  
>>
>>
>>     Feedback?
>>
>>     Regards, Benoit.
>>
>


--------------050704030906040208000309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  


Dear Thomas,



  
  
  
  
Dear Benoit, all,

  
 

  
Why don't we make the chunk
elements by default variable length and just don't allow them to be
fixed length??



I see a drawback with this approach. I have to specify in [PSAMP-PROTO]
that all chunk elements will be encoded with variable length I.E..
Fine, I can list all the ones that exist today. But what about the new
ones, administered by IANA. How do we know that these are chunk
elements or not? We could say: if it contains "Section" part of the
name, this is a chunk, so encoded with a variable length -> this is
a little bit light! Alternatively, we could specify in the I.E.
description that it must be encoded with a variable length but it break
the independence of the information model versus the protocol.



Regards, Benoit.



  
 

  
Regards,

  
 

  
Thomas


  
--

Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de

Network Laboratories               Phone:  +49 6221 90511-28

NEC Europe Ltd.                    Fax:    +49 6221 90511-55

Kurfuersten-Anlage 36

69115 Heidelberg, Germany          http://www.netlab.nec.de

  

  
 

  

  

    

    
 From:
owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On
Behalf Of Benoit Claise

    Sent: Wednesday, December 21, 2005 11:55 PM

    To: Benoit Claise

    Cc: psamp

    Subject: Re: Open issue 15: chunk with a too short length

    

    

BTW, regarding [PSAMP-INFO], the 2 ipHeaderPacketSection and
ipPayloadPacketSection information element descriptions currently
contain:

    
"If insufficient octets are available,

the remainder of the data should be zero-filled and an additional

information element sent (e.g., ipPayloadLength) indicating how

much of the data is valid."

    

Obviously these sentences will have to be removed.

    

Regards, Benoit.

    
Dear all,

      

>From the Vancouver meeting minutes:

      
Open Issue (not numbered): Chunk with too short length

How to encode "chunk" with a too short length? Padding wouldn't be
recognized 

by the collector. One solution would be using a new template for each
length.

Proposal: The protocol draft should say that padding MUST NOT be used
for

variable length IEs.

      

      
Here is a new proposed text (actually, only the second paragraph is new)
  

Basic Packet Report

      

For each selected packet, the Packet Report MUST contain the following
information: 

- The associationsId Information Element 

- Some number of contiguous bytes from the start of the packet,
including the packet header (which includes link layer, network layer
and other encapsulation headers) and some subsequent bytes of the
packet payload.  Alternatively, the number of contiguous
bytes may start at the beginning of the payload. The
Layer2PacketSection, l2PayloadPacketSection, mplsLabelStackSection,
mplsPayloadPacketSection, ipPacketSection, and ipPayloadPacketSection
PSAMP Information Elements are available for this use.  

- The input sequence number(s) of any Selectors that acted on the
packet, represented by the selectorInputSequenceNumber Information
Element. 

        

The contiguous Information Elements (Layer2PacketSection,
l2PayloadPacketSection, mplsLabelStackSection,
mplsPayloadPacketSection, ipPacketSection, and ipPayloadPacketSection)
MAY be encoded with a fixed length field or with a variable sized
field. If one of these Information Elements is encoded with a fixed
length field whose length is too long for the number of contiguous
bytes in the selected packet, padding MUST NOT be used. In this case,
the Exporting Process MUST export the information either in a new
Template Record with the correct fixed length field, or either in a new
Template Record with a variable length field.  

      

      

Feedback?

      

Regards, Benoit.

      

    

    

  








--------------050704030906040208000309--

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 23 08:42:38 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EpnBt-0002vL-UQ
	for psamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 08:42:38 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12832
	for ; Fri, 23 Dec 2005 08:41:30 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Epn5w-000B2l-KD
	for psamp-data@psg.com; Fri, 23 Dec 2005 13:36:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0
Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Epn5v-000B2U-7T
	for psamp@ops.ietf.org; Fri, 23 Dec 2005 13:36:27 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBNDaQh05635
	for ; Fri, 23 Dec 2005 08:36:26 -0500 (EST)
Received: from [10.61.65.220] (ams-clip-vpn-dhcp476.cisco.com [10.61.65.220])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id jBNDa9C25614;
	Fri, 23 Dec 2005 14:36:09 +0100 (CET)
Message-ID: <43ABFD49.7030004@cisco.com>
Date: Fri, 23 Dec 2005 14:36:09 +0100
From: Benoit Claise 
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: psamp 
Subject: New version of the protocol draft draft-ietf-psamp-protocol-03.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear all,

As promised during the last IETF meeting in Vancouver, a new version of the PSAMP protocol draft has just been posted.

Many issues have been closed:

   PROTO-01 [PSAMP-FMWK] mentions the optional Export Packets 
   compression (see section 8.5) Should we mention this in this 
   document? 
    
   PROTO-02 From a protocol point of view, there a no differences 
   between the Field Match Filtering and the Router State Filtering as 
   defined in [PSAMP-TECH]. The only difference concerns the I.E. on 
   which we do the filtering... part of the packet in one case, not part 
   of the packet in the other case. Proposal: merge the 2 methods in 
   [PSAMP-TECH] 

   PROTO-03 The second open issue is concerned with reporting the 
   sequential order of sampling and filtering. => order of the scope. 
   We spot a new problem: we could export twice the hash value. How to 
   distinguish them? How to know that the hash value 1 corresponds to a 
   specific definition specified in an Option Template. 

   PROTO-05 Transport protocol: SCTP and/or UDP and/or TCP. Nothing is 
   mentioned at this stage. [PSAMP-FMWK] and PSAMP charter specifically 
   mention UDP. 
    
   PROTO-06 Even if the notion of Associations ID is mentioned in 
   [PSAMP-TECH], maybe a term such as SelectionPath or PathID would be 
   more appropriate. 

   PROTO-07 Even if [PSAMP-TECH] section 7.1 and 7.2 describes that "The 
   ASSOCIATIONS field describes the Observation Point and optionally the 
   IPFIX processes to which the packet Selector is associated. Values: 
   ", we can't see an example where 
   the IPFIX process(es) ID would be required. Don't we have enough with 
   the list of Selector IDs?  

   PROTO-09 "The algorithm specific Information Elements, defining 
   configuration parameters for match-based and router state filtering, 
   are taken from the full range of available IPFIX Information Elements 
   [IPFIX-INFO]". What about the ones from [PSAMP-INFO]? In other words, 
   are they I.E.s in [PSAMP-INFO] that we could use for the match-based 
   and router state filtering? 

   PROTO-13 The solution in this document is based on the fact that 
   https://psg.com/lists/psamp/psamp.2005/msg00050.html is taken into 
   account. That means: no range for the filtering 


Note that some open issues have been listed in this version of the draft

   PROTO-16 IANA considerations section to be completed. 
   Two questions: 
   1. I'm not too sure whether we should mandate a new IETF RFC for the 
   new selection method description? 
   2. I'm not too sure whether we should mandate new IANA-registered 
   information elements for the new selection method? 
       In other words, can we have proprietary selection method in the 
   selectorAlgorithm Information Element?  
       
   PROTO-17 "Encrypted Packets: Selectors that interpret packet fields 
   must be configurable to ignore (i.e. not select) encrypted packets, 
   when they are detected". "Since packet encryption alters the meaning 
   of encrypted fields, field match filtering must be configurable to 
   ignore encrypted packets, when detected." I guess we will need extra 
   text for this. 
    
   PROTO-18 "The exporting process must have an export rate limit, 
   configurable per Exporting Process". I guess we need extra text for 
   this. 
    
   PROTO-19 "the timestamp of observation of the packet at the 
   Observation Point. The timestamp should be reported to microsecond 
   resolution." Nothing is mentioned in this draft regarding this issue. 
    
   PROTO-20 Hash based filtering to be completed.  


Regarding the action items, some have been closed:

   PROTO-102 insert double spaces after the end of each sentence. 

   PROTO-103 Should briefly discuss the fact that PSAMP is OK with IPFIX 
   requirements in terms of time (uSec precision) 

   PROTO-105 Section 6 about "PSAMP requirements": check if any changes 
   with the version 5 of [PSAMP-FMWK]. This draft is based on ietf-
   psamp-framework-04.txt. 

   PROTO-107 All the examples in section 7 should contain the 
   Information Element ID instead of the Information Element name. 
   Example: Option 3 =   samp.PacketSpace  
   Corrected Example: Option 3 = 305   

However, there are still a couple of action items:

   PROTO-101 See EDITOR'S NOTE 
    
   PROTO-104 Fix the terminology sections, as a last step before 
   publication 
 
   PROTO-106 Extend security considerations by a discussion on exported  
   Payload. Consider whether [PSAMP-INFO] or [PSAMP-PROTO] or both 
   is/are the place(s). 
    
   PROTO-107 Provide the equivalent for variable length I.E. 
   Here is an example of a basic Packet Report, with a SelectionPath 
   value of 9 (will be explained later on) and ipPacketSection 
   Information Element of 12 bytes, encoded with a fixed length. 
   To be put in section 7.3.1 
 
   PROTO-108 Have a statement that this protocol specification  
   meets all requirements for the PSAMP protocol stated in the framework  
   except ... An then have a list of bullets, where at minimum there is 
   stated "not yet covered" or a longer explanation why it is not 
   covered. This would be replacement for the long list of requirements 
   in section 6.1 


The goal is to post a final draft version, with all open issues solved, by the IETF deadline (should be around the beginning of March).

Regards, Benoit.




--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 23 10:15:46 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Epoe1-0004NF-Ry
	for psamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 10:15:46 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23104
	for ; Fri, 23 Dec 2005 10:14:40 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Epoam-000L3I-0I
	for psamp-data@psg.com; Fri, 23 Dec 2005 15:12:24 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	SPF_PASS autolearn=no version=3.1.0
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Epoak-000L36-Vz
	for psamp@ops.ietf.org; Fri, 23 Dec 2005 15:12:23 +0000
Received: from ams-core-1.cisco.com ([144.254.224.150])
  by ams-iport-1.cisco.com with ESMTP; 23 Dec 2005 16:12:22 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBNFCJFZ019299;
	Fri, 23 Dec 2005 16:12:19 +0100 (MET)
Received: from [10.61.80.190] (ams-clip-vpn-dhcp4287.cisco.com [10.61.80.190])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA19234;
	Fri, 23 Dec 2005 15:12:16 GMT
Message-ID: <43AC13D0.5000704@cisco.com>
Date: Fri, 23 Dec 2005 15:12:16 +0000
From: Andrew Johnson 
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Juergen Quittek 
CC: Benoit Claise , psamp 
Subject: Re: Uniform Probabilistic Sampling in PSAMP-PROTO
References: <43971C0C.7080101@cisco.com> <43986523.7040803@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Juergen Quittek wrote:
> Hi Andrew,
> 
> --On 08.12.2005 16:53 Uhr +0000 Andrew Johnson wrote:
> 
>> Benoit Claise wrote:
>> [SNIP]
>>
>>> Initially we wanted to model the probability in [PSAMP-PROTO] with a
>>> float, which is allowed by [IPFIX-PROTO].
>>> However, we've got the issue that SMIv2 doesn't support floats.
>>
>>
>> Although the floating point type is not a base type in SMI there are
>> a couple of proposals about how to send them.  This extract is from
>> the comp.protocols.snmp SNMP FAQ:
>>
>>   http://www.faqs.org/faqs/snmp-faq/part2/
>>   ===============================================================
>>   2.40.04
>>   SUBJECT: Floating Point Numbers in SMI?
>>
>>   You cannot add new base types to the SMI.
>>
>>   For now, the easiest way to have floating point numbers
>>   in SNMP MIBs is to use the base type OCTET STRING and
>>   encode the value in ASCII.
>>
>>   This is not the most elegant approach. However, it will work
>>   between your agent and your management application and it will
>>   be compliant to the SNMP SMI and protocol specifications.
>>
>>   David Perkins
>>   ===============================================================
>>
>> Apparently this method is implemented in the NET-SNMP agent and
>> manager.
>>   (http://ops.ietf.org/lists/mreview/mreview.2004/msg00083.html)
>>
>> Whether we use the above suggested method or define a new way of
>> using unsigned32 the application will have to have some way of
>> converting that number before it can be used.
> 
> 
> This would be Solution 4.
> I still prefer Solution 1 or Solution 2.
> 
>>> What to do now?
>>>
>>> _Solution 1: _
>>> We export the probability with a float, and we approximate this value
>>> with the MIB variable.
>>>
>>> _Solution 2: _
>>> We export the probability with an unsigned32, exactly the same content
>>> as the MIB variable psampSampUniProbProbability
>>>
>>> _Solution 3: _
>>> We export the probability with two values N, M.
>>>     This means 2 inter-dependent I.E.s and 2 MIB variables instead of 
>>> one.
>>>     I don't like it too much
>>>
>>> I'm clearly in favor of solution 1. It's not right that we would limit
>>> IPFIX because of the limitations of SMIv2
>>> Feedback?
>>>
>>> Side question: if we go for the float solution, should we have a
>>> float64? This would give us more precision
>>> Note: not yet defined in [IPFIX-PROTO].
>>
>>
>> FYI:
>> The 32-bit float has 24 bits of precision, i.e. roughly +/-0.000006%.
> 
> 
> It is 23 bits we are using. Precision would be    roughly +/-0.00001%

I think you are correct.  IEEE 764 assumes a top bit of 1 but although
this generates a 24-bit number we only have 23 bits of precission, as
you say.

This precision remains constant as the size of the number varies as the
exponent shifts the mantissa to where the bits have the most accuracy.
This is why I prefer using the float as a solution.


> The Unsigned as Benoit suggests it would have     roughly +/-0.0000001%

The precision scales according to the size of the fraction you are
representing, so for the common small numbers it is quite precise but for
the smaller the fraction the less accurate the method is. For example, for
a 1 in 3 billion sampler the closest we can represent is 1 in 2^32, which
is almost 50% off.


Regards,

Andrew


>> The 64-bit float has 53 bits of precision, i.e. roughly 
>> +/-0.00000000000001%
>> regards
> 
> 
> Thanks,
> 
>    Juergen
> 
>> Andrew
>>
>> -- 
>> to unsubscribe send a message to psamp-request@ops.ietf.org with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: 

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 23 10:29:15 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Epor5-0008Uk-60
	for psamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 10:29:15 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24424
	for ; Fri, 23 Dec 2005 10:28:09 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Epooi-000M1l-Bo
	for psamp-data@psg.com; Fri, 23 Dec 2005 15:26:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	SPF_PASS autolearn=no version=3.1.0
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Epooh-000M1W-M2
	for psamp@ops.ietf.org; Fri, 23 Dec 2005 15:26:47 +0000
Received: from ams-core-1.cisco.com ([144.254.224.150])
  by ams-iport-1.cisco.com with ESMTP; 23 Dec 2005 16:26:48 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBNFQiFZ022396;
	Fri, 23 Dec 2005 16:26:44 +0100 (MET)
Received: from [10.61.80.190] (ams-clip-vpn-dhcp4287.cisco.com [10.61.80.190])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA20314;
	Fri, 23 Dec 2005 15:26:43 GMT
Message-ID: <43AC1733.9040104@cisco.com>
Date: Fri, 23 Dec 2005 15:26:43 +0000
From: Andrew Johnson 
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thomas Dietz 
CC: Benoit Claise , psamp 
Subject: Re: Open issue 15: chunk with a too short length
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thomas Dietz wrote:
> Dear Benoit, all,
>  
> Why don't we make the chunk elements by default variable length and just 
> don't allow them to be fixed length??

I think in many cases the chunks will be sufficiently small to mean that
they are guaranteed to be complete.  i.e. a ipv4HeaderSection of 20 bytes.
Forcing a variable length field in this case will give more overhead than
necessary.

I think most sensible implementations will use a variable length for large
chunks in IPFIX, but specifying how to do it using templates gives a clear
direction to anyone implementing a dual IPFIX / NetFlow v9 exporter.


Andrew


> --
> Thomas Dietz                       E-mail: Thomas.Dietz@netlab.nec.de
> Network Laboratories               Phone:  +49 6221 90511-28
> NEC Europe Ltd.                    Fax:    +49 6221 90511-55
> Kurfuersten-Anlage 36
> 69115 Heidelberg, Germany          http://www.netlab.nec.de 
> 
>  
> 
>  
> 
>     ------------------------------------------------------------------------
>     *From:* owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org]
>     *On Behalf Of *Benoit Claise
>     *Sent:* Wednesday, December 21, 2005 11:55 PM
>     *To:* Benoit Claise
>     *Cc:* psamp
>     *Subject:* Re: Open issue 15: chunk with a too short length
> 
>     BTW, regarding [PSAMP-INFO], the 2 ipHeaderPacketSection and
>     ipPayloadPacketSection information element descriptions currently
>     contain:
> 
>         "If insufficient octets are available,
>         the remainder of the data should be zero-filled and an additional
>         information element sent (e.g., ipPayloadLength) indicating how
>         much of the data is valid."
> 
>     Obviously these sentences will have to be removed.
> 
>     Regards, Benoit.
> 
>>     Dear all,
>>
>>     >From the Vancouver meeting minutes:
>>
>>         Open Issue (not numbered): Chunk with too short length
>>         How to encode "chunk" with a too short length? Padding
>>         wouldn't be recognized
>>         by the collector. One solution would be using a new template
>>         for each length.
>>         Proposal: The protocol draft should say that padding MUST NOT
>>         be used for
>>         variable length IEs.
>>
>>Here is a new proposed text (actually, only the second paragraph is new)
>>  
>>
>>     Basic Packet Report
>>
>>     For each selected packet, the Packet Report MUST contain the
>>     following information:
>>     - The associationsId Information Element
>>     - Some number of contiguous bytes from the start of the packet,
>>     including the packet header (which includes link layer, network
>>     layer and other encapsulation headers) and some subsequent bytes
>>     of the packet payload.  Alternatively, the number of contiguous
>>     bytes may start at the beginning of the payload. The
>>     Layer2PacketSection, l2PayloadPacketSection,
>>     mplsLabelStackSection, mplsPayloadPacketSection, ipPacketSection,
>>     and ipPayloadPacketSection PSAMP Information Elements are
>>     available for this use. 
>>     - The input sequence number(s) of any Selectors that acted on the
>>     packet, represented by the selectorInputSequenceNumber Information
>>     Element.
>>      
>>     The contiguous Information Elements (Layer2PacketSection,
>>     l2PayloadPacketSection, mplsLabelStackSection,
>>     mplsPayloadPacketSection, ipPacketSection, and
>>     ipPayloadPacketSection) MAY be encoded with a fixed length field
>>     or with a variable sized field. If one of these Information
>>     Elements is encoded with a fixed length field whose length is too
>>     long for the number of contiguous bytes in the selected packet,
>>     padding MUST NOT be used. In this case, the Exporting Process MUST
>>     export the information either in a new Template Record with the
>>     correct fixed length field, or either in a new Template Record
>>     with a variable length field.  
>>
>>
>>     Feedback?
>>
>>     Regards, Benoit.
>>
> 

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 23 10:37:17 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Epoyr-000319-7j
	for psamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 10:37:17 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25882
	for ; Fri, 23 Dec 2005 10:36:11 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1Epowa-000McJ-FU
	for psamp-data@psg.com; Fri, 23 Dec 2005 15:34:56 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE,
	SPF_PASS autolearn=no version=3.1.0
Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EpowZ-000Mc6-T4
	for psamp@ops.ietf.org; Fri, 23 Dec 2005 15:34:56 +0000
Received: from ams-core-1.cisco.com ([144.254.224.150])
  by ams-iport-1.cisco.com with ESMTP; 23 Dec 2005 16:34:56 +0100
Received: from cisco.com (mrwint.cisco.com [64.103.71.48])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jBNFYqFZ024061;
	Fri, 23 Dec 2005 16:34:53 +0100 (MET)
Received: from [10.61.80.190] (ams-clip-vpn-dhcp4287.cisco.com [10.61.80.190])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA20803;
	Fri, 23 Dec 2005 15:34:52 GMT
Message-ID: <43AC191B.6080803@cisco.com>
Date: Fri, 23 Dec 2005 15:34:51 +0000
From: Andrew Johnson 
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Benoit Claise 
CC: psamp 
Subject: Re: PSAMP open issue 18: export rate limit?
References: <43A9F344.8010308@cisco.com>
In-Reply-To: <43A9F344.8010308@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA25882

Hello Benoit and all.

Benoit Claise wrote:
> Dear all,
>=20
> In [PSAMP-FMWK], the following statement is still un-addressed in=20
> [PSAMP-PROTO]
> PROTO-18 =93The exporting process must have an export rate limit,=20
> configurable per Exporting Process=94.
> See section 8.3 for the details=20
> http://www.ietf.org/internet-drafts/draft-ietf-psamp-framework-10.txt
>=20
>=20
> First of all, I have a question regarding the requirement itself. Isn't=
=20
> it supposed to mean: =93The exporting process must have an export rate=20
> limit, configurable per Collecting Process=94? Otherwise, I don't=20
> understand the exact requirement when we have a PSAMP device exporting=20
> to multiple collectors!

I would say that each Exporting Process exports to only one collector,
but can be fed by multiple Metering Processes.  Also, each Metering
Process may feed Multiple Exporting Processes.  With this concept we
can rate limit the Exporting Process and it will only affect one
collector.


> Then, how to address the requirement?
> Shall we simply update [PSAMP-PROTO] with a sentence such as: "The=20
> exporting process MUST have an export rate limit, configurable per=20
> Collecting Process"?
> And that's it?

If we agree that one Exporting Process deals with only one collector
then this simplifies matters.


> Do we keep the export rate limit as a generic term? Or do we define=20
> precisely what it mean? Example: number of IPFIX Messages, number of=20
> bytes/s, number of records/s?

I think we should pick a MUST, such as we MUST be able to rate limit
based on the number of data and option records per second, but you MAY
rate limit on other criteria also, such as bandwidth.  This will allow
some common ground between implementations, useful for people who buy
from multiple vendors.

Regards

Andrew

--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Fri Dec 23 13:20:13 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EprWX-0008R7-Ff
	for psamp-archive@megatron.ietf.org; Fri, 23 Dec 2005 13:20:13 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17419
	for ; Fri, 23 Dec 2005 13:19:06 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EprRA-0007ed-Sl
	for psamp-data@psg.com; Fri, 23 Dec 2005 18:14:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,
	DNS_FROM_RFC_WHOIS,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [192.20.225.110] (helo=mail-white.research.att.com)
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1EprRA-0007eP-89
	for psamp@ops.ietf.org; Fri, 23 Dec 2005 18:14:40 +0000
Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k1.research.att.com [135.207.26.243])
	by mail-green.research.att.com (Postfix) with ESMTP id 82E4D865F;
	Fri, 23 Dec 2005 13:14:39 -0500 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: Open Issue 5: PSAMP transport protocol 
Date: Fri, 23 Dec 2005 13:14:39 -0500
Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1915555@NJFPSRVEXG2KCL.research.att.com>
Thread-Topic: Open Issue 5: PSAMP transport protocol 
Thread-Index: AcYFbGJqyRWj1tTnRjezB523X1uyxwCfm0bg
From: 
To: , 
Sender: owner-psamp@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Benoit,

> -----Original Message-----
> From: owner-psamp@ops.ietf.org [mailto:owner-psamp@ops.ietf.org] On
Behalf
> Of Benoit Claise
> Sent: Tuesday, December 20, 2005 8:50 AM
> To: psamp
> Subject: Open Issue 5: PSAMP transport protocol
>=20
> Dear all,
>=20
> The PSAMP open issue 5 is the following:
> Transport protocol: SCTP and/or UDP and/or TCP. Nothing is mentioned
at
> this stage. [PSAMP-FMWK] and PSAMP charter specifically mention UDP.
>=20
> Currently, we don't mention anything regarding the transport protocol
> selection in [PSAMP-PROTO].
> However, I think that we don't need to specify anything as we have
this
> sentence in the draft:
>     "The entire IPFIX protocol specifications [IPFIX-PROTO] MUST be
> implemented for the PSAMP export."
> This allows the same transport  protocol choices as specified in
> [IPFIX-PROTO].
>=20

Requiring implementation of the entire IPFIX protocol is stronger than
requiring the same transport protocol choices.=20

According to [PSAMP-FMWK], not all of IPFIX need be implemented, see
Section 8.1:=20
	"On the other=20
      hand, not all features of the IPFIX protocol will need to be=20
      implemented by some PSAMP devices. For example, a device that=20
      offers only content-independent sampling and basic PSAMP=20
      reporting has no need to support IPFIX capabilities based on=20
      packet fields."

Nick



> Please let me know if you disagree.
>=20
> Regards, Benoit.
>=20
> --
> to unsubscribe send a message to psamp-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: 



--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: 



From owner-psamp@ops.ietf.org Wed Dec 28 10:57:08 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Erdfo-0004Al-PF
	for psamp-archive@megatron.ietf.org; Wed, 28 Dec 2005 10:57:08 -0500
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21758
	for ; Wed, 28 Dec 2005 10:55:58 -0500 (EST)
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1ErdYz-000E5h-G7
	for psamp-data@psg.com; Wed, 28 Dec 2005 15:50:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.60 (FreeBSD))
	(envelope-from )
	id 1ErdYw-000E4f-UE
	for psamp@ops.ietf.org; Wed, 28 Dec 2005 15:50:03 +0000
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ErdYv-0004K1-Tn; Wed, 28 Dec 2005 10:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: psamp@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-psamp-protocol-03.txt 
Message-Id: 
Date: Wed, 28 Dec 2005 10:50:01 -0500
Sender: owner-psamp@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Packet Sampling Working Group of the IETF.

	Title		: Packet Sampling (PSAMP) Protocol Specifications
	Author(s)	: B. Claise
	Filename	: draft-ietf-psamp-protocol-03.txt
	Pages		: 40
	Date		: 2005-12-28
	
This document specifies the export of packet information from a 
   PSAMP Exporting Process to a PSAMP Colleting Process.  For export of 
   packet information the IP Flow Information eXport (IPFIX) protocol 
   is used, as both the IPFIX and PSAMP architecture match very well 
   and the means provided by the IPFIX protocol are sufficient.  The 
   document specifies in detail how the IPFIX protocol is used for 
   PSAMP export of packet information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-psamp-protocol-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-psamp-protocol-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-psamp-protocol-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<2005-12-28095201.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-psamp-protocol-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-psamp-protocol-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<2005-12-28095201.I-D@ietf.org>

--OtherAccess--

--NextPart--


--
to unsubscribe send a message to psamp-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: