From cfcecfaf@cardsetc.com.au Wed Nov 01 19:31:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfQUd-0003IS-Mx for ipfix-archive@lists.ietf.org; Wed, 01 Nov 2006 19:31:39 -0500 Received: from [201.244.41.75] (helo=pablo) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfQUT-0004lv-Ts for ipfix-archive@lists.ietf.org; Wed, 01 Nov 2006 19:31:39 -0500 Message-ID: <662161c806044njns4sivpsel2jhh21sxz2elz22zb2u5i@mail2.cardaccess.com.au> Date: Thu, 2 Dec 2006 00:38:21 +0300 From: "Stephan Wong" To: ipfix-archive@lists.ietf.org Subject: urgently to you 112.5% increase all-important MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 1.4 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da financially--what a State bank was and what a national one; what brokerssee clearly what was meant by money as a medium of exchange, and how allplace for a boy to live. It contained mostly small two and three-storywas quite often allowed to come to the bank on Saturdays, when he wouldred brick houses, with small white marble steps leading up to the front BMSN.OB could prove to be one of the LARGEST stem cell stock acting for the month of this month! Why? Bio-Matrix Scientific Group Inc. BMSN.OB No argument with stem cells from fat or cord blood. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Company name: Bio-Matrix Scientific Group Inc. Stock symbol: BMSN.OB Typical amount: 14,492.4 Present cost: 1.50 Future price: 2.22 (+48% Income) Expectations: MAX ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Purchase that stock symbol and you can double or triple your funds. Buy it because the price is still little. Don't waste, throw that ideal chance. You can see the monthly price of that stock symbol on Nasdaq and the price was 2.10-2.05 last month. After the publishing of the news the price will significally boost and it can be up to 2.22$. Please examine this news attentively and make a right choice: ???????????????????????????????????????????????????????? Mature stem cell biotechs: better prospects, less controversy Any minute BMSN's facility will get clearance to open! This will be an incredible moment. This information was released Bio-Matrix Scientific Group Inc. Processing Laboratory Nearing Completion (Go to yahoo or any economic site to read this information now) We could be looking at something completely incredible about to happen. The CEO has stated that as far as he knows this will be the first Stem Cell from fat storage facility. They will also store cord blood. This will be a main moment for BMSN. Everyone will have the opportunity to store Adult Stem Cells from heavy and cord blood. Go to MSNBC and put in Adult Stem Cells from Fat. Watch the miracles happen. No controversy. No destroying embryos. This is incredible. look this Company like a hawk. Low drift Corporation. Could be a big mover. |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| Go BMSN.OB! Take that nice stock to your portfolio. This stock is just perfect as a middle term savings. dis.claimer All material herein was prepared based upon information believed to be reliable. The information contained herein is not guaranteed to be accurate, and should not be considered to be all-inclusive. The company that is discussed in this opinion have not approved the statements made in this opinion. This opinion contains forward- looking statements that involve risks and uncertainties. This material is for informational purposes only and should not be construed as an offer or solicitation of an offer to buy or sell securities. We are not a licensed broker, broker dealer, market maker, investment banker, investment advisor, analyst or underwriter. Please consult a broker before purchasing or selling any securities viewed or mentioned herein. We are expecting to receive cash no amount has been decided on..We will report on compensation as soon as we finalize the price. These stocks are highly violatile, and you can lose all your money. They can trade very high and very low in minutes; we suggest if you are not a savvy investor you sit back and watch. financially--what a State bank was and what a national one; what brokersdoor, and thin, white marble trimmings outlining the front door andresponsible, and gradually he was becoming quite a personage. He already From ipfix-bounces@ietf.org Thu Nov 02 17:52:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GflNx-0001Ki-Ki; Thu, 02 Nov 2006 17:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GflNx-0001Kd-6f for ipfix@ietf.org; Thu, 02 Nov 2006 17:50:09 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GflNv-0003Ac-Hw for ipfix@ietf.org; Thu, 02 Nov 2006 17:50:09 -0500 Received: from [192.168.1.129] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EC74513CF82; Thu, 2 Nov 2006 23:52:06 +0100 (CET) Date: Thu, 02 Nov 2006 23:50:04 +0100 From: Juergen Quittek To: Hitoshi Irino Subject: Re: [IPFIX] Question about data types of some IEs Message-ID: <193F108D2BE1B43AB572F0F5@juergen-quitteks-computer.local> In-Reply-To: <4545BC7C.60308@lab.ntt.co.jp> References: <4532D411.9090006@lab.ntt.co.jp> <4545BC7C.60308@lab.ntt.co.jp> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Irino-san, --On 30.10.06 17:49 +0900 Hitoshi Irino wrote: > Dear Juregen, > > Juergen Quittek wrote: >> Dear Irino-san, >> >> Thanks for carefully checking the data types used in the >> info model. Please find replies to your comments inline. >> For three IEs I followed your suggestion and replaced the >> data type for the next version of the draft. > > Thank you. > I confirmed these changes in IPFIX-INFO-14 > >>> 4. >>> 5.7.12. mplsVpnRouteDistinguisher >>> Abstract Data Type: octetArray >>> >>> According to section 4.2 in rfc4364, >>> a VPN-IPv4 address consists of an 8-byte Route Distinguisher >>> followed by a 4-byte IPv4 address. >>> >>> Is unsigned64 sufficient for this IE? >>> >>> According to page 7 of rfc4382, >>> MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION >>> SYNTAX OCTET STRING(SIZE (0..256)) >>> >>> I think that Abstract Data Type of this IE should be "string", >>> if this IE is in conformity to rfc4382. >> >> RFC 4364 defines the size of a route distinguisher as 64 bits >> (8 octets) which exactly matches the current data type in the >> info model. > > I am confused by this sentence. Current abstract data type is defined as > octetArray in IPFIX-INFO-14, RD is a 64 bit value, so I supposed it is > better to change unsigned64. Otherwise, I supposed to use 8 octets > octetArray, a description of this IE should specify that a size of this > IE is 8 octets. Sorry. This statement is wrong. As last minute change I used octetArray instead of unsigned64. This is still fine for the current definition in RFC 4364 but also matches the specification in RFC 4382 that is cited above. The octetArray in our info model corresponds to the SMIv2 OCTET STRING. >> However, you are right that the MIB module in RFC 4382 chooses >> the SMI type for a route distinguisher to be an octet string >> with up to 256 octets. I do not understand why the in the MIB >> module in RFC 4382 does not use a shorter array. > > I have same question. I checked with the authors. They just did not see a reason to limit the size to 8 octets and rather preferred to be open to extensions or future formats of route distinguishers. I followed their recommendation for the info model. > When RD is described by string, I guess that the maximum string length of RD is 23 characters. > ----- > 0:2ByteASN:4Byte -> 0:65536:4294967296 -> 18 characters > maximum value of 2ByteASN is 65536, > maximum value of 4Byte is 4294967296 > 1:4ByteIPv4Address:2Byte-> 1:255.255.255.255:65536 -> 23 characters > maximum value of 4ByteIPv4Address is 255.255.255.255, > maximum value of 2Byte is 65536 > 2:4ByteASN:2Byte -> 2:4294967296:65536 -> 18 characters > maximum value of 4ByteASN is 4294967296, > maximum value of 2Byte is 65536 > ----- I did not yet consider encoding as text string. In the MIB module it's an octet string that matches our octetArray. >> >> I sent this question to the editors of RFC 4382. >> Let's hope they can help us. Or can somebody on the list >> answer this question? >>> 5. >>> Can Exporter implementation be chosen which use fixed or variable >>> length for IEs that have octetArray or string data type? >>> Is it correct? Should Information model draft define which use >>> fixed or variable for these IEs? >> >> I think exporters should be free to choose between fixed or >> variable length encoding of a particular IE. I do not see a >> good reason to restrict the use. But I am open to discuss it >> if you bring up a good reason. > > I reconsidered my opinion, I agree that exporters should be free to > choose between fixed or variable length encoding of a particular IE. > On the other hand, I am afraid that collectors increase load by decoding > variable length IEs. Indeed, "The IPFIX Template mechanism is optimized > for fixed length Information Elements" is written in IPFIX-PROTO. > When a exporter treats a IE whose data type is octetArray but the data > size is steady, exporter will use fixed length encoding (for example > above mplsVpnRouteDistinguisher is octetArray IE, but the data size is 8 > octets, the size is fixed (if this IE is in conformity to rfc4364)). > > I think that the use should not be restricted, but I think definition of > IE should provide information about which prefer fixed or variable, and > provide minimum / maximum size length octetArray and string type IEs to > prevent confusion for implementation. (Similarly, I think definition of > IE should provide information whether the IE may be apply reduced size > encoding for integer and float type IEs.) So far, the mplsVpnRouteDistinguisher is the only info element of type octetArray (except for the padding IE). In RFC 4382 no recommendation about the 8 octet encoding was given. Would it really be necessary to state "please encode an 8 octet identifier in an octetArray of size 8? Thanks, Juergen > -- > Hitoshi Irino > NTT Network Service Systems Laboratories > 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan > Tel: +81-422-59-4403 Fax: +81-422-59-4549 > > > > > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 02 17:52:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GflNx-0001Ki-Ki; Thu, 02 Nov 2006 17:50:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GflNx-0001Kd-6f for ipfix@ietf.org; Thu, 02 Nov 2006 17:50:09 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GflNv-0003Ac-Hw for ipfix@ietf.org; Thu, 02 Nov 2006 17:50:09 -0500 Received: from [192.168.1.129] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EC74513CF82; Thu, 2 Nov 2006 23:52:06 +0100 (CET) Date: Thu, 02 Nov 2006 23:50:04 +0100 From: Juergen Quittek To: Hitoshi Irino Subject: Re: [IPFIX] Question about data types of some IEs Message-ID: <193F108D2BE1B43AB572F0F5@juergen-quitteks-computer.local> In-Reply-To: <4545BC7C.60308@lab.ntt.co.jp> References: <4532D411.9090006@lab.ntt.co.jp> <4545BC7C.60308@lab.ntt.co.jp> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Irino-san, --On 30.10.06 17:49 +0900 Hitoshi Irino wrote: > Dear Juregen, > > Juergen Quittek wrote: >> Dear Irino-san, >> >> Thanks for carefully checking the data types used in the >> info model. Please find replies to your comments inline. >> For three IEs I followed your suggestion and replaced the >> data type for the next version of the draft. > > Thank you. > I confirmed these changes in IPFIX-INFO-14 > >>> 4. >>> 5.7.12. mplsVpnRouteDistinguisher >>> Abstract Data Type: octetArray >>> >>> According to section 4.2 in rfc4364, >>> a VPN-IPv4 address consists of an 8-byte Route Distinguisher >>> followed by a 4-byte IPv4 address. >>> >>> Is unsigned64 sufficient for this IE? >>> >>> According to page 7 of rfc4382, >>> MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION >>> SYNTAX OCTET STRING(SIZE (0..256)) >>> >>> I think that Abstract Data Type of this IE should be "string", >>> if this IE is in conformity to rfc4382. >> >> RFC 4364 defines the size of a route distinguisher as 64 bits >> (8 octets) which exactly matches the current data type in the >> info model. > > I am confused by this sentence. Current abstract data type is defined as > octetArray in IPFIX-INFO-14, RD is a 64 bit value, so I supposed it is > better to change unsigned64. Otherwise, I supposed to use 8 octets > octetArray, a description of this IE should specify that a size of this > IE is 8 octets. Sorry. This statement is wrong. As last minute change I used octetArray instead of unsigned64. This is still fine for the current definition in RFC 4364 but also matches the specification in RFC 4382 that is cited above. The octetArray in our info model corresponds to the SMIv2 OCTET STRING. >> However, you are right that the MIB module in RFC 4382 chooses >> the SMI type for a route distinguisher to be an octet string >> with up to 256 octets. I do not understand why the in the MIB >> module in RFC 4382 does not use a shorter array. > > I have same question. I checked with the authors. They just did not see a reason to limit the size to 8 octets and rather preferred to be open to extensions or future formats of route distinguishers. I followed their recommendation for the info model. > When RD is described by string, I guess that the maximum string length of RD is 23 characters. > ----- > 0:2ByteASN:4Byte -> 0:65536:4294967296 -> 18 characters > maximum value of 2ByteASN is 65536, > maximum value of 4Byte is 4294967296 > 1:4ByteIPv4Address:2Byte-> 1:255.255.255.255:65536 -> 23 characters > maximum value of 4ByteIPv4Address is 255.255.255.255, > maximum value of 2Byte is 65536 > 2:4ByteASN:2Byte -> 2:4294967296:65536 -> 18 characters > maximum value of 4ByteASN is 4294967296, > maximum value of 2Byte is 65536 > ----- I did not yet consider encoding as text string. In the MIB module it's an octet string that matches our octetArray. >> >> I sent this question to the editors of RFC 4382. >> Let's hope they can help us. Or can somebody on the list >> answer this question? >>> 5. >>> Can Exporter implementation be chosen which use fixed or variable >>> length for IEs that have octetArray or string data type? >>> Is it correct? Should Information model draft define which use >>> fixed or variable for these IEs? >> >> I think exporters should be free to choose between fixed or >> variable length encoding of a particular IE. I do not see a >> good reason to restrict the use. But I am open to discuss it >> if you bring up a good reason. > > I reconsidered my opinion, I agree that exporters should be free to > choose between fixed or variable length encoding of a particular IE. > On the other hand, I am afraid that collectors increase load by decoding > variable length IEs. Indeed, "The IPFIX Template mechanism is optimized > for fixed length Information Elements" is written in IPFIX-PROTO. > When a exporter treats a IE whose data type is octetArray but the data > size is steady, exporter will use fixed length encoding (for example > above mplsVpnRouteDistinguisher is octetArray IE, but the data size is 8 > octets, the size is fixed (if this IE is in conformity to rfc4364)). > > I think that the use should not be restricted, but I think definition of > IE should provide information about which prefer fixed or variable, and > provide minimum / maximum size length octetArray and string type IEs to > prevent confusion for implementation. (Similarly, I think definition of > IE should provide information whether the IE may be apply reduced size > encoding for integer and float type IEs.) So far, the mplsVpnRouteDistinguisher is the only info element of type octetArray (except for the padding IE). In RFC 4382 no recommendation about the 8 octet encoding was given. Would it really be necessary to state "please encode an 8 octet identifier in an octetArray of size 8? Thanks, Juergen > -- > Hitoshi Irino > NTT Network Service Systems Laboratories > 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan > Tel: +81-422-59-4403 Fax: +81-422-59-4549 > > > > > > _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Nov 03 00:02:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfrAY-0001TK-J8; Fri, 03 Nov 2006 00:00:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfrAW-0001TF-U3 for ipfix@ietf.org; Fri, 03 Nov 2006 00:00:40 -0500 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfrAQ-0004f3-2y for ipfix@ietf.org; Fri, 03 Nov 2006 00:00:40 -0500 Received: from [192.168.3.3] (softbank219039065064.bbtec.net [219.39.65.64]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 994CF4D96E; Fri, 3 Nov 2006 14:00:07 +0900 (JST) Message-ID: <454ACCD7.1040306@sfc.wide.ad.jp> Date: Fri, 03 Nov 2006 14:00:07 +0900 From: Hitoshi Irino Organization: WIDE User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] Question about data types of some IEs References: <4532D411.9090006@lab.ntt.co.jp> <4545BC7C.60308@lab.ntt.co.jp> <193F108D2BE1B43AB572F0F5@juergen-quitteks-computer.local> In-Reply-To: <193F108D2BE1B43AB572F0F5@juergen-quitteks-computer.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Juergen, Juergen Quittek wrote: > Dear Irino-san, > > --On 30.10.06 17:49 +0900 Hitoshi Irino wrote: > >> Dear Juregen, >> >> Juergen Quittek wrote: >>> Dear Irino-san, >>> >>> Thanks for carefully checking the data types used in the >>> info model. Please find replies to your comments inline. >>> For three IEs I followed your suggestion and replaced the >>> data type for the next version of the draft. >> >> Thank you. >> I confirmed these changes in IPFIX-INFO-14 >> >>>> 4. >>>> 5.7.12. mplsVpnRouteDistinguisher >>>> Abstract Data Type: octetArray >>>> >>>> According to section 4.2 in rfc4364, >>>> a VPN-IPv4 address consists of an 8-byte Route Distinguisher >>>> followed by a 4-byte IPv4 address. >>>> >>>> Is unsigned64 sufficient for this IE? >>>> >>>> According to page 7 of rfc4382, >>>> MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION >>>> SYNTAX OCTET STRING(SIZE (0..256)) >>>> >>>> I think that Abstract Data Type of this IE should be "string", >>>> if this IE is in conformity to rfc4382. >>> >>> RFC 4364 defines the size of a route distinguisher as 64 bits >>> (8 octets) which exactly matches the current data type in the >>> info model. >> >> I am confused by this sentence. Current abstract data type is defined as >> octetArray in IPFIX-INFO-14, RD is a 64 bit value, so I supposed it is >> better to change unsigned64. Otherwise, I supposed to use 8 octets >> octetArray, a description of this IE should specify that a size of this >> IE is 8 octets. > > Sorry. This statement is wrong. > As last minute change I used octetArray instead of unsigned64. > This is still fine for the current definition in RFC 4364 but also > matches the specification in RFC 4382 that is cited above. > The octetArray in our info model corresponds to the SMIv2 OCTET STRING. I understand the reason of using octetArray by your explanation. >>> However, you are right that the MIB module in RFC 4382 chooses >>> the SMI type for a route distinguisher to be an octet string >>> with up to 256 octets. I do not understand why the in the MIB >>> module in RFC 4382 does not use a shorter array. >> >> I have same question. > > I checked with the authors. They just did not see a reason to limit > the size to 8 octets and rather preferred to be open to extensions > or future formats of route distinguishers. I followed their > recommendation for the info model. > >> When RD is described by string, I guess that the maximum string length >> of RD is 23 characters. >> ----- >> 0:2ByteASN:4Byte -> 0:65536:4294967296 -> 18 characters >> maximum value of 2ByteASN is 65536, >> maximum value of 4Byte is 4294967296 >> 1:4ByteIPv4Address:2Byte-> 1:255.255.255.255:65536 -> 23 characters >> maximum value of 4ByteIPv4Address is 255.255.255.255, >> maximum value of 2Byte is 65536 >> 2:4ByteASN:2Byte -> 2:4294967296:65536 -> 18 characters >> maximum value of 4ByteASN is 4294967296, >> maximum value of 2Byte is 65536 >> ----- > > I did not yet consider encoding as text string. > In the MIB module it's an octet string that matches our > octetArray. > >>> >>> I sent this question to the editors of RFC 4382. >>> Let's hope they can help us. Or can somebody on the list >>> answer this question? >>>> 5. >>>> Can Exporter implementation be chosen which use fixed or variable >>>> length for IEs that have octetArray or string data type? >>>> Is it correct? Should Information model draft define which use >>>> fixed or variable for these IEs? >>> >>> I think exporters should be free to choose between fixed or >>> variable length encoding of a particular IE. I do not see a >>> good reason to restrict the use. But I am open to discuss it >>> if you bring up a good reason. >> >> I reconsidered my opinion, I agree that exporters should be free to >> choose between fixed or variable length encoding of a particular IE. >> On the other hand, I am afraid that collectors increase load by decoding >> variable length IEs. Indeed, "The IPFIX Template mechanism is optimized >> for fixed length Information Elements" is written in IPFIX-PROTO. >> When a exporter treats a IE whose data type is octetArray but the data >> size is steady, exporter will use fixed length encoding (for example >> above mplsVpnRouteDistinguisher is octetArray IE, but the data size is 8 >> octets, the size is fixed (if this IE is in conformity to rfc4364)). >> >> I think that the use should not be restricted, but I think definition of >> IE should provide information about which prefer fixed or variable, and >> provide minimum / maximum size length octetArray and string type IEs to >> prevent confusion for implementation. (Similarly, I think definition of >> IE should provide information whether the IE may be apply reduced size >> encoding for integer and float type IEs.) > > So far, the mplsVpnRouteDistinguisher is the only info element of type > octetArray (except for the padding IE). In RFC 4382 no recommendation > about the 8 octet encoding was given. Would it really be necessary to > state "please encode an 8 octet identifier in an octetArray of size 8? It is not necessary to describe "please encode an 8 octet identifier in an octetArray of size 8". But I want the description of this IE to explains "The size of mplsVpnRouteDistinguisher is 8 octets accroding to RFC4364. The octetArray is adopted to correspond to the SMIv2 OCTET STRING which is a data type of MplsL3VpnRouteDistinguisher in RFC4382, and to be open to future extensions." Regards, Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Nov 03 00:02:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfrAY-0001TK-J8; Fri, 03 Nov 2006 00:00:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfrAW-0001TF-U3 for ipfix@ietf.org; Fri, 03 Nov 2006 00:00:40 -0500 Received: from shonan.sfc.wide.ad.jp ([2001:200:0:8803::53] helo=mail.sfc.wide.ad.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfrAQ-0004f3-2y for ipfix@ietf.org; Fri, 03 Nov 2006 00:00:40 -0500 Received: from [192.168.3.3] (softbank219039065064.bbtec.net [219.39.65.64]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 994CF4D96E; Fri, 3 Nov 2006 14:00:07 +0900 (JST) Message-ID: <454ACCD7.1040306@sfc.wide.ad.jp> Date: Fri, 03 Nov 2006 14:00:07 +0900 From: Hitoshi Irino Organization: WIDE User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] Question about data types of some IEs References: <4532D411.9090006@lab.ntt.co.jp> <4545BC7C.60308@lab.ntt.co.jp> <193F108D2BE1B43AB572F0F5@juergen-quitteks-computer.local> In-Reply-To: <193F108D2BE1B43AB572F0F5@juergen-quitteks-computer.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Juergen, Juergen Quittek wrote: > Dear Irino-san, > > --On 30.10.06 17:49 +0900 Hitoshi Irino wrote: > >> Dear Juregen, >> >> Juergen Quittek wrote: >>> Dear Irino-san, >>> >>> Thanks for carefully checking the data types used in the >>> info model. Please find replies to your comments inline. >>> For three IEs I followed your suggestion and replaced the >>> data type for the next version of the draft. >> >> Thank you. >> I confirmed these changes in IPFIX-INFO-14 >> >>>> 4. >>>> 5.7.12. mplsVpnRouteDistinguisher >>>> Abstract Data Type: octetArray >>>> >>>> According to section 4.2 in rfc4364, >>>> a VPN-IPv4 address consists of an 8-byte Route Distinguisher >>>> followed by a 4-byte IPv4 address. >>>> >>>> Is unsigned64 sufficient for this IE? >>>> >>>> According to page 7 of rfc4382, >>>> MplsL3VpnRouteDistinguisher ::= TEXTUAL-CONVENTION >>>> SYNTAX OCTET STRING(SIZE (0..256)) >>>> >>>> I think that Abstract Data Type of this IE should be "string", >>>> if this IE is in conformity to rfc4382. >>> >>> RFC 4364 defines the size of a route distinguisher as 64 bits >>> (8 octets) which exactly matches the current data type in the >>> info model. >> >> I am confused by this sentence. Current abstract data type is defined as >> octetArray in IPFIX-INFO-14, RD is a 64 bit value, so I supposed it is >> better to change unsigned64. Otherwise, I supposed to use 8 octets >> octetArray, a description of this IE should specify that a size of this >> IE is 8 octets. > > Sorry. This statement is wrong. > As last minute change I used octetArray instead of unsigned64. > This is still fine for the current definition in RFC 4364 but also > matches the specification in RFC 4382 that is cited above. > The octetArray in our info model corresponds to the SMIv2 OCTET STRING. I understand the reason of using octetArray by your explanation. >>> However, you are right that the MIB module in RFC 4382 chooses >>> the SMI type for a route distinguisher to be an octet string >>> with up to 256 octets. I do not understand why the in the MIB >>> module in RFC 4382 does not use a shorter array. >> >> I have same question. > > I checked with the authors. They just did not see a reason to limit > the size to 8 octets and rather preferred to be open to extensions > or future formats of route distinguishers. I followed their > recommendation for the info model. > >> When RD is described by string, I guess that the maximum string length >> of RD is 23 characters. >> ----- >> 0:2ByteASN:4Byte -> 0:65536:4294967296 -> 18 characters >> maximum value of 2ByteASN is 65536, >> maximum value of 4Byte is 4294967296 >> 1:4ByteIPv4Address:2Byte-> 1:255.255.255.255:65536 -> 23 characters >> maximum value of 4ByteIPv4Address is 255.255.255.255, >> maximum value of 2Byte is 65536 >> 2:4ByteASN:2Byte -> 2:4294967296:65536 -> 18 characters >> maximum value of 4ByteASN is 4294967296, >> maximum value of 2Byte is 65536 >> ----- > > I did not yet consider encoding as text string. > In the MIB module it's an octet string that matches our > octetArray. > >>> >>> I sent this question to the editors of RFC 4382. >>> Let's hope they can help us. Or can somebody on the list >>> answer this question? >>>> 5. >>>> Can Exporter implementation be chosen which use fixed or variable >>>> length for IEs that have octetArray or string data type? >>>> Is it correct? Should Information model draft define which use >>>> fixed or variable for these IEs? >>> >>> I think exporters should be free to choose between fixed or >>> variable length encoding of a particular IE. I do not see a >>> good reason to restrict the use. But I am open to discuss it >>> if you bring up a good reason. >> >> I reconsidered my opinion, I agree that exporters should be free to >> choose between fixed or variable length encoding of a particular IE. >> On the other hand, I am afraid that collectors increase load by decoding >> variable length IEs. Indeed, "The IPFIX Template mechanism is optimized >> for fixed length Information Elements" is written in IPFIX-PROTO. >> When a exporter treats a IE whose data type is octetArray but the data >> size is steady, exporter will use fixed length encoding (for example >> above mplsVpnRouteDistinguisher is octetArray IE, but the data size is 8 >> octets, the size is fixed (if this IE is in conformity to rfc4364)). >> >> I think that the use should not be restricted, but I think definition of >> IE should provide information about which prefer fixed or variable, and >> provide minimum / maximum size length octetArray and string type IEs to >> prevent confusion for implementation. (Similarly, I think definition of >> IE should provide information whether the IE may be apply reduced size >> encoding for integer and float type IEs.) > > So far, the mplsVpnRouteDistinguisher is the only info element of type > octetArray (except for the padding IE). In RFC 4382 no recommendation > about the 8 octet encoding was given. Would it really be necessary to > state "please encode an 8 octet identifier in an octetArray of size 8? It is not necessary to describe "please encode an 8 octet identifier in an octetArray of size 8". But I want the description of this IE to explains "The size of mplsVpnRouteDistinguisher is 8 octets accroding to RFC4364. The octetArray is adopted to correspond to the SMIv2 OCTET STRING which is a data type of MplsL3VpnRouteDistinguisher in RFC4382, and to be open to future extensions." Regards, Hitoshi Irino _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Nov 03 10:01:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0WK-0004bx-90; Fri, 03 Nov 2006 09:59:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0WJ-0004br-Oo for ipfix@ietf.org; Fri, 03 Nov 2006 09:59:47 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg0WF-0007Xb-DZ for ipfix@ietf.org; Fri, 03 Nov 2006 09:59:47 -0500 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E5F4213CF82; Fri, 3 Nov 2006 16:01:45 +0100 (CET) Date: Fri, 03 Nov 2006 15:59:41 +0100 From: Juergen Quittek To: Hitoshi Irino Subject: Re: [IPFIX] Question about data types of some IEs Message-ID: In-Reply-To: <454ACCD7.1040306@sfc.wide.ad.jp> References: <4532D411.9090006@lab.ntt.co.jp> <4545BC7C.60308@lab.ntt.co.jp> <193F108D2BE1B43AB572F0F5@juergen-quitteks-computer.local> <454ACCD7.1040306@sfc.wide.ad.jp> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Irino-san, --On 03.11.06 14:00 +0900 Hitoshi Irino wrote: > Dear Juergen, > >>> I reconsidered my opinion, I agree that exporters should be free to >>> choose between fixed or variable length encoding of a particular IE. >>> On the other hand, I am afraid that collectors increase load by decoding >>> variable length IEs. Indeed, "The IPFIX Template mechanism is optimized >>> for fixed length Information Elements" is written in IPFIX-PROTO. >>> When a exporter treats a IE whose data type is octetArray but the data >>> size is steady, exporter will use fixed length encoding (for example >>> above mplsVpnRouteDistinguisher is octetArray IE, but the data size is 8 >>> octets, the size is fixed (if this IE is in conformity to rfc4364)). >>> >>> I think that the use should not be restricted, but I think definition of >>> IE should provide information about which prefer fixed or variable, and >>> provide minimum / maximum size length octetArray and string type IEs to >>> prevent confusion for implementation. (Similarly, I think definition of >>> IE should provide information whether the IE may be apply reduced size >>> encoding for integer and float type IEs.) >> >> So far, the mplsVpnRouteDistinguisher is the only info element of type >> octetArray (except for the padding IE). In RFC 4382 no recommendation >> about the 8 octet encoding was given. Would it really be necessary to >> state "please encode an 8 octet identifier in an octetArray of size 8? > > It is not necessary to describe "please encode an 8 octet identifier in > an octetArray of size 8". But I want the description of this IE to explains > "The size of mplsVpnRouteDistinguisher is 8 octets accroding to RFC4364. > The octetArray is adopted to correspond to the SMIv2 OCTET STRING which > is a data type of MplsL3VpnRouteDistinguisher in RFC4382, and to be open > to future extensions." I see. I think this is a good idea. I will add it to the list of issues for the next revision of the draft. Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Nov 03 10:01:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0WK-0004bx-90; Fri, 03 Nov 2006 09:59:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0WJ-0004br-Oo for ipfix@ietf.org; Fri, 03 Nov 2006 09:59:47 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg0WF-0007Xb-DZ for ipfix@ietf.org; Fri, 03 Nov 2006 09:59:47 -0500 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E5F4213CF82; Fri, 3 Nov 2006 16:01:45 +0100 (CET) Date: Fri, 03 Nov 2006 15:59:41 +0100 From: Juergen Quittek To: Hitoshi Irino Subject: Re: [IPFIX] Question about data types of some IEs Message-ID: In-Reply-To: <454ACCD7.1040306@sfc.wide.ad.jp> References: <4532D411.9090006@lab.ntt.co.jp> <4545BC7C.60308@lab.ntt.co.jp> <193F108D2BE1B43AB572F0F5@juergen-quitteks-computer.local> <454ACCD7.1040306@sfc.wide.ad.jp> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Irino-san, --On 03.11.06 14:00 +0900 Hitoshi Irino wrote: > Dear Juergen, > >>> I reconsidered my opinion, I agree that exporters should be free to >>> choose between fixed or variable length encoding of a particular IE. >>> On the other hand, I am afraid that collectors increase load by decoding >>> variable length IEs. Indeed, "The IPFIX Template mechanism is optimized >>> for fixed length Information Elements" is written in IPFIX-PROTO. >>> When a exporter treats a IE whose data type is octetArray but the data >>> size is steady, exporter will use fixed length encoding (for example >>> above mplsVpnRouteDistinguisher is octetArray IE, but the data size is 8 >>> octets, the size is fixed (if this IE is in conformity to rfc4364)). >>> >>> I think that the use should not be restricted, but I think definition of >>> IE should provide information about which prefer fixed or variable, and >>> provide minimum / maximum size length octetArray and string type IEs to >>> prevent confusion for implementation. (Similarly, I think definition of >>> IE should provide information whether the IE may be apply reduced size >>> encoding for integer and float type IEs.) >> >> So far, the mplsVpnRouteDistinguisher is the only info element of type >> octetArray (except for the padding IE). In RFC 4382 no recommendation >> about the 8 octet encoding was given. Would it really be necessary to >> state "please encode an 8 octet identifier in an octetArray of size 8? > > It is not necessary to describe "please encode an 8 octet identifier in > an octetArray of size 8". But I want the description of this IE to explains > "The size of mplsVpnRouteDistinguisher is 8 octets accroding to RFC4364. > The octetArray is adopted to correspond to the SMIv2 OCTET STRING which > is a data type of MplsL3VpnRouteDistinguisher in RFC4382, and to be open > to future extensions." I see. I think this is a good idea. I will add it to the list of issues for the next revision of the draft. Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Nov 05 05:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggex2-0002vH-1R; Sun, 05 Nov 2006 05:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggex0-0002sn-TP for ipfix@ietf.org; Sun, 05 Nov 2006 05:10:02 -0500 Received: from [2001:fa8::25] (helo=mail.nttv6.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggewy-0005Su-N7 for ipfix@ietf.org; Sun, 05 Nov 2006 05:10:02 -0500 Received: from [127.0.0.1] (mail.nttv6.net [192.68.245.115]) by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id kA5A9WiO048462 for ; Sun, 5 Nov 2006 19:09:33 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sun, 05 Nov 2006 02:09:35 -0800 From: kobayashi atsushi To: ipfix@ietf.org Message-Id: <20061105005836.54B0.AKOBA@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: -2.8 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [IPFIX] Metering Process in IPFIX concentrators X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, I'm being confused about Metering Process in IPFIX concentrators. Please comments about this case. IPFIX-Arch draft described about Metering Process as follows. Metering Process The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example the selected output interface). It seems to be that Metering process generates flow records from only packets, not from flows. However, IPFIX-Arch does not cover or mention intermediate nodes such as concentrators such as concentrator or mediator. On the other hand, RFC 3917 (Section 9) mention concentrator, and it describes that a concentrator can have (partial) metering process. In the concentrator case, inputs to this process are Received Flow Records, and characteristics are based on the flow content and final Flow records are created by this process. It generates final flow records from fine granular flows. I think that it is better for IPFIX-Arch to mention such case. If it is not, the partial Metering Process in concentrator seem not to be true Metering Process. Is it correct? Best Regards, Atsushi Kobayashi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Nov 05 05:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggex2-0002vH-1R; Sun, 05 Nov 2006 05:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggex0-0002sn-TP for ipfix@ietf.org; Sun, 05 Nov 2006 05:10:02 -0500 Received: from [2001:fa8::25] (helo=mail.nttv6.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggewy-0005Su-N7 for ipfix@ietf.org; Sun, 05 Nov 2006 05:10:02 -0500 Received: from [127.0.0.1] (mail.nttv6.net [192.68.245.115]) by mail.nttv6.net (8.13.8/8.13.5) with ESMTP id kA5A9WiO048462 for ; Sun, 5 Nov 2006 19:09:33 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Sun, 05 Nov 2006 02:09:35 -0800 From: kobayashi atsushi To: ipfix@ietf.org Message-Id: <20061105005836.54B0.AKOBA@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.25.02 [ja] X-Spam-Score: -2.8 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [IPFIX] Metering Process in IPFIX concentrators X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, I'm being confused about Metering Process in IPFIX concentrators. Please comments about this case. IPFIX-Arch draft described about Metering Process as follows. Metering Process The Metering Process generates Flow Records. Inputs to the process are packet headers and characteristics observed at an Observation Point, and packet treatment at the Observation Point (for example the selected output interface). It seems to be that Metering process generates flow records from only packets, not from flows. However, IPFIX-Arch does not cover or mention intermediate nodes such as concentrators such as concentrator or mediator. On the other hand, RFC 3917 (Section 9) mention concentrator, and it describes that a concentrator can have (partial) metering process. In the concentrator case, inputs to this process are Received Flow Records, and characteristics are based on the flow content and final Flow records are created by this process. It generates final flow records from fine granular flows. I think that it is better for IPFIX-Arch to mention such case. If it is not, the partial Metering Process in concentrator seem not to be true Metering Process. Is it correct? Best Regards, Atsushi Kobayashi --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Nov 05 11:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglFE-0000Ka-4Q; Sun, 05 Nov 2006 11:53:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglFC-0000BA-PS for ipfix@ietf.org; Sun, 05 Nov 2006 11:53:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GglF8-0001Gf-M6 for ipfix@ietf.org; Sun, 05 Nov 2006 11:53:14 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2006 17:53:11 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKCjTUWQ/uCLY2dsb2JhbACMQRQPKg X-IronPort-AV: i="4.09,388,1157320800"; d="scan'208"; a="117362633:sNHT27454104" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA5Gr9XO024258; Sun, 5 Nov 2006 17:53:09 +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 kA5Gr84Z025188; Sun, 5 Nov 2006 17:53:08 +0100 (MET) Received: from [10.21.120.102] (sjc-vpn6-102.cisco.com [10.21.120.102]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA19295; Sun, 5 Nov 2006 16:53:04 GMT Message-ID: <454E16D0.3020004@cisco.com> Date: Sun, 05 Nov 2006 16:52:32 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hitoshi Irino Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> <4524FD68.8010008@cisco.com> <45251A10.9060300@sfc.wide.ad.jp> <3698BB5BA217DA9BAB358D82@[61.213.6.135]> <45324C91.5090507@cisco.com> <73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]> <45327BD3.6090901@cisco.com> <940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org> <4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com> <4534C8C8.1080209@lab.ntt.co.jp> <13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org> <4534FCEF.2020807@cisco.com> <4545E16D.1030809@lab.ntt.co.jp> <4545E6DC.8090807@cisco.com> <45470CA2.9090406@lab.ntt.co.jp> In-Reply-To: <45470CA2.9090406@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=3026; t=1162745589; x=1163609589; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; X=v=3Dcisco.com=3B=20h=3D/xbIbcX/tcIcjgpOSe6OytYXQxU=3D; b=woG+j1lnoVPtM0OY0OwDqkV3xVESbO6bCSIUrHGJkFYyaj7yCaMPw1xHwV0WuW3dKKOyeXKW INh+zfaPlYxPLv0uZTWmHRFVSI87hqBWc0Xhhfokvyy/yc0BJ6Uq7BvQ; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hello all Hitoshi Irino wrote: > Paul Aitken wrote: >>> sysUpBaseTimeMilliseconds >>> >>> Description: >>> The absolute timestamp of the base time for flowStartSysUpTime >>> and flowEndSysUpTime. The initial value is equal to >>> systemInitTimeMilliseconds, and the value is updated every 49 >>> days to prevent overflow of flowStartSysUpTime and flowEndSysUpTime. Like Template IDs and Common Property IDs, this should be bound to the transport session. Something like: "The absolute timestamp of the base time for any System Uptime based value sent within this Transport Session." [SNIP] >> We should say that where it's present it's to be used in preference to >> the systemInitTimeMilliseconds, where "present" means there's a value >> for this IE in the flow, or in an option that's in scope. >> >> But you want to export the sysUpBaseTimeMilliseconds value in an >> option because you certainly you don't want to have to export the >> value in every flow, right? > > I want to export in option. > >> That raises an interesting question concerning the change of value. If >> you're exporting some flows based on a certain value of >> sysUpBaseTimeMilliseconds, and you export an option containing an >> updated value, you must ensure that all the old flows have reached and >> been processed by the collector before the updated >> sysUpBaseTimeMilliseconds, and that the updated >> sysUpBaseTimeMilliseconds reaches the collector and is processed >> before any of the new flows. Else you risk interpreting some of the >> flows with the wrong value of sysUpBaseTimeMilliseconds. >> >> Unless we can show how that can be done, it'd be necessary to export >> systemInitTimeMilliseconds in every flow which, as previously >> discussed at some length, is incredibly inefficient and should not be >> done. > > I have not considered about this problem. > I think that if the option template which includes > sysUpBaseTimeMilliseconds can notify the sequence number of header of > corresponding data record which contains flowStartSysUpTime and > flowEndSysUpTime relating new updated sysUpBaseTimeMilliseconds to > collector (but suitable IE does not exist in nowadays IPFIX-INFO), this > problem can be solved. The main problem here is one of re-ordering, and it is not unique to this IE, for example also applies to Template IDs. One reasonable approach for dealing with the re-ordering problem is to only use the option with data that has was received with a later sequence ID than the one the update was received in. Hitoshi-san, what scope were you thinking of using when updating the base time? I can't think of any obvious one. Template IDs would be one possibility as you could change the templates every 47 days and therefore there would be no confusion about where the base time applied to. However I suspect you want any base time updates to apply to all templates. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sun Nov 05 11:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglFE-0000Ka-4Q; Sun, 05 Nov 2006 11:53:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GglFC-0000BA-PS for ipfix@ietf.org; Sun, 05 Nov 2006 11:53:14 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GglF8-0001Gf-M6 for ipfix@ietf.org; Sun, 05 Nov 2006 11:53:14 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2006 17:53:11 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAKCjTUWQ/uCLY2dsb2JhbACMQRQPKg X-IronPort-AV: i="4.09,388,1157320800"; d="scan'208"; a="117362633:sNHT27454104" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA5Gr9XO024258; Sun, 5 Nov 2006 17:53:09 +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 kA5Gr84Z025188; Sun, 5 Nov 2006 17:53:08 +0100 (MET) Received: from [10.21.120.102] (sjc-vpn6-102.cisco.com [10.21.120.102]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA19295; Sun, 5 Nov 2006 16:53:04 GMT Message-ID: <454E16D0.3020004@cisco.com> Date: Sun, 05 Nov 2006 16:52:32 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Hitoshi Irino Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> <4524FD68.8010008@cisco.com> <45251A10.9060300@sfc.wide.ad.jp> <3698BB5BA217DA9BAB358D82@[61.213.6.135]> <45324C91.5090507@cisco.com> <73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]> <45327BD3.6090901@cisco.com> <940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org> <4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com> <4534C8C8.1080209@lab.ntt.co.jp> <13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org> <4534FCEF.2020807@cisco.com> <4545E16D.1030809@lab.ntt.co.jp> <4545E6DC.8090807@cisco.com> <45470CA2.9090406@lab.ntt.co.jp> In-Reply-To: <45470CA2.9090406@lab.ntt.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=3026; t=1162745589; x=1163609589; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20when=20flow{Start,End}SysUpTime=20overflow; X=v=3Dcisco.com=3B=20h=3D/xbIbcX/tcIcjgpOSe6OytYXQxU=3D; b=woG+j1lnoVPtM0OY0OwDqkV3xVESbO6bCSIUrHGJkFYyaj7yCaMPw1xHwV0WuW3dKKOyeXKW INh+zfaPlYxPLv0uZTWmHRFVSI87hqBWc0Xhhfokvyy/yc0BJ6Uq7BvQ; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hello all Hitoshi Irino wrote: > Paul Aitken wrote: >>> sysUpBaseTimeMilliseconds >>> >>> Description: >>> The absolute timestamp of the base time for flowStartSysUpTime >>> and flowEndSysUpTime. The initial value is equal to >>> systemInitTimeMilliseconds, and the value is updated every 49 >>> days to prevent overflow of flowStartSysUpTime and flowEndSysUpTime. Like Template IDs and Common Property IDs, this should be bound to the transport session. Something like: "The absolute timestamp of the base time for any System Uptime based value sent within this Transport Session." [SNIP] >> We should say that where it's present it's to be used in preference to >> the systemInitTimeMilliseconds, where "present" means there's a value >> for this IE in the flow, or in an option that's in scope. >> >> But you want to export the sysUpBaseTimeMilliseconds value in an >> option because you certainly you don't want to have to export the >> value in every flow, right? > > I want to export in option. > >> That raises an interesting question concerning the change of value. If >> you're exporting some flows based on a certain value of >> sysUpBaseTimeMilliseconds, and you export an option containing an >> updated value, you must ensure that all the old flows have reached and >> been processed by the collector before the updated >> sysUpBaseTimeMilliseconds, and that the updated >> sysUpBaseTimeMilliseconds reaches the collector and is processed >> before any of the new flows. Else you risk interpreting some of the >> flows with the wrong value of sysUpBaseTimeMilliseconds. >> >> Unless we can show how that can be done, it'd be necessary to export >> systemInitTimeMilliseconds in every flow which, as previously >> discussed at some length, is incredibly inefficient and should not be >> done. > > I have not considered about this problem. > I think that if the option template which includes > sysUpBaseTimeMilliseconds can notify the sequence number of header of > corresponding data record which contains flowStartSysUpTime and > flowEndSysUpTime relating new updated sysUpBaseTimeMilliseconds to > collector (but suitable IE does not exist in nowadays IPFIX-INFO), this > problem can be solved. The main problem here is one of re-ordering, and it is not unique to this IE, for example also applies to Template IDs. One reasonable approach for dealing with the re-ordering problem is to only use the option with data that has was received with a later sequence ID than the one the update was received in. Hitoshi-san, what scope were you thinking of using when updating the base time? I can't think of any obvious one. Template IDs would be one possibility as you could change the templates every 47 days and therefore there would be no confusion about where the base time applied to. However I suspect you want any base time updates to apply to all templates. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 06 19:25:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhElQ-0003d2-Mu; Mon, 06 Nov 2006 19:24:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhElO-0003cZ-WE for ipfix@ietf.org; Mon, 06 Nov 2006 19:24:27 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhElI-00017I-8a for ipfix@ietf.org; Mon, 06 Nov 2006 19:24:26 -0500 X-ASG-Debug-ID: 1162859048-28f600490000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1162859048 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id C362EB16 for ; Tue, 7 Nov 2006 00:24:08 +0000 (GMT) Received: from mhdexc01.adhel.hitachi-eu.com ([IP=193.39.227.50]) by eSafe SMTP Relay 1162838877; Tue Nov 7 00:24:08 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by mhdexc01.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 00:24:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: commonPropertiesId Date: Tue, 7 Nov 2006 00:24:05 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F8F@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: commonPropertiesId Thread-Index: AccCAwixsMskRWgbSJ6AfCCe/RCVMw== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 07 Nov 2006 00:24:07.0402 (UTC) FILETIME=[09AFC4A0:01C70203] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [IPFIX] commonPropertiesId X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0963149619==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0963149619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70203.08CE7D2D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70203.08CE7D2D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, the commonPropertiesId definition in IPFIX-INFO is currently different from the one we propose in the Reducing Redundancy draft. In IPFIX-INFO we have: "An identifier of a set of common properties that is unique per Observation Domain. Typically, this Information Element is used to link to information reported in separate records." While in the Reducing Redundancy draft we agreed on a definition in line = with templateId: "The commonPropertiesId is an identifier of a set of common properties that is locally unique per Observation Domain and Transport Session." I think that IPFIX-INFO should be updated (basically by adding the words = "and Transport session"). Comments? Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C70203.08CE7D2D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable commonPropertiesId

Dear all,

the commonPropertiesId definition in IPFIX-INFO is currently
different from the one we propose in the Reducing Redundancy draft.

In IPFIX-INFO we have:
"An identifier of a set of common properties that is unique per
Observation Domain. Typically, this Information Element is used
to link to information reported in separate records."

While in the Reducing Redundancy draft we agreed on a definition in line = with templateId:
"The commonPropertiesId is an identifier of a set of common properti= es
that is locally unique per Observation Domain and Transport Session."= ;

I think that IPFIX-INFO should be updated (basically by adding the words = "and Transport session").

Comments?

Regards,
Elisa
 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C70203.08CE7D2D-- --===============0963149619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0963149619==-- From ipfix-bounces@ietf.org Mon Nov 06 19:25:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhElQ-0003d2-Mu; Mon, 06 Nov 2006 19:24:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhElO-0003cZ-WE for ipfix@ietf.org; Mon, 06 Nov 2006 19:24:27 -0500 Received: from gatekeeper.hitachi-eu.com ([194.36.128.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhElI-00017I-8a for ipfix@ietf.org; Mon, 06 Nov 2006 19:24:26 -0500 X-ASG-Debug-ID: 1162859048-28f600490000-urGyNO X-Barracuda-URL: http://mhd-bar.hitachi-eu.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: primary.hitachi-eu.net[193.39.225.234] X-Barracuda-Start-Time: 1162859048 X-ASG-Whitelist: Client Received: from mhd-esafe-int.hitachi-eu.com (primary.hitachi-eu.net [193.39.225.234]) by gatekeeper.hitachi-eu.com (Spam Firewall) with SMTP id C362EB16 for ; Tue, 7 Nov 2006 00:24:08 +0000 (GMT) Received: from mhdexc01.adhel.hitachi-eu.com ([IP=193.39.227.50]) by eSafe SMTP Relay 1162838877; Tue Nov 7 00:24:08 2006 Received: from mhdexc02.adhel.hitachi-eu.com ([193.39.227.51]) by mhdexc01.adhel.hitachi-eu.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 00:24:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 X-ASG-Orig-Subj: commonPropertiesId Date: Tue, 7 Nov 2006 00:24:05 -0000 Message-ID: <3167F18F59B81B4888A4D4C0A1717DD6670F8F@mhdexc02.adhel.hitachi-eu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: commonPropertiesId Thread-Index: AccCAwixsMskRWgbSJ6AfCCe/RCVMw== From: "Boschi, Elisa" To: X-OriginalArrivalTime: 07 Nov 2006 00:24:07.0402 (UTC) FILETIME=[09AFC4A0:01C70203] X-ESAFE-STATUS: Mail clean X-ESAFE-DETAILS: Clean X-Barracuda-Virus-Scanned: by HEU SPAM Firewall - MHD at hitachi-eu.com X-Spam-Score: 0.6 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Subject: [IPFIX] commonPropertiesId X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0963149619==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0963149619== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70203.08CE7D2D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70203.08CE7D2D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, the commonPropertiesId definition in IPFIX-INFO is currently different from the one we propose in the Reducing Redundancy draft. In IPFIX-INFO we have: "An identifier of a set of common properties that is unique per Observation Domain. Typically, this Information Element is used to link to information reported in separate records." While in the Reducing Redundancy draft we agreed on a definition in line = with templateId: "The commonPropertiesId is an identifier of a set of common properties that is locally unique per Observation Domain and Transport Session." I think that IPFIX-INFO should be updated (basically by adding the words = "and Transport session"). Comments? Regards, Elisa *************************************************************************= ************************* =20 E-mail Confidentiality Notice and Disclaimer. =20 This email and any files transmitted with it are confidential and are i= ntended solely for=20 the use of the individual or entity to which they are addressed. Access t= o this e-mail by=20 anyone else is unauthorised. If you are not the intended recipient, any d= isclosure,=20 copying, distribution or any action taken or omitted to be taken in relia= nce on it, is=20 prohibited.=20 E-mail messages are not necessarily secure. Hitachi does not accept re= sponsibility=20 for any changes made to this message after it was sent.=20 Please note that Hitachi checks outgoing e-mail messages for the presen= ce of=20 computer viruses. *************************************************************************= ************************* ------_=_NextPart_001_01C70203.08CE7D2D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable commonPropertiesId

Dear all,

the commonPropertiesId definition in IPFIX-INFO is currently
different from the one we propose in the Reducing Redundancy draft.

In IPFIX-INFO we have:
"An identifier of a set of common properties that is unique per
Observation Domain. Typically, this Information Element is used
to link to information reported in separate records."

While in the Reducing Redundancy draft we agreed on a definition in line = with templateId:
"The commonPropertiesId is an identifier of a set of common properti= es
that is locally unique per Observation Domain and Transport Session."= ;

I think that IPFIX-INFO should be updated (basically by adding the words = "and Transport session").

Comments?

Regards,
Elisa
 

*************************************************************************=
*************************
=20
 E-mail Confidentiality Notice and Disclaimer.
=20
  This email and any files transmitted with it are confidential and are i=
ntended solely for=20
the use of the individual or entity to which they are addressed. Access t=
o this e-mail by=20
anyone else is unauthorised. If you are not the intended recipient, any d=
isclosure,=20
copying, distribution or any action taken or omitted to be taken in relia=
nce on it, is=20
prohibited.=20
  E-mail messages are not necessarily secure.  Hitachi does not accept re=
sponsibility=20
for any changes made to this message after it was sent.=20
  Please note that Hitachi checks outgoing e-mail messages for the presen=
ce of=20
computer viruses.

*************************************************************************=
*************************
------_=_NextPart_001_01C70203.08CE7D2D-- --===============0963149619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0963149619==-- From ipfix-bounces@ietf.org Mon Nov 06 19:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhExA-0008CB-Qz; Mon, 06 Nov 2006 19:36:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEx9-0008Bc-Fq for ipfix@ietf.org; Mon, 06 Nov 2006 19:36:35 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEx8-0003R1-1Y for ipfix@ietf.org; Mon, 06 Nov 2006 19:36:35 -0500 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4A46220031DE; Tue, 7 Nov 2006 01:37:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CDF8XeORG1q; Tue, 7 Nov 2006 01:37:03 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 291D72000168; Tue, 7 Nov 2006 01:37:03 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Nov 2006 01:36:31 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD696645CE0@mx1.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPFIX MIB writeability proposal Thread-Index: AccCBMTl12EwhW/ITNSPRj5d+xu5kA== From: "Thomas Dietz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Juergen Quittek Subject: [IPFIX] IPFIX MIB writeability proposal X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0493997268==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0493997268== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0044_01C701C1.B6C49180" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C701C1.B6C49180 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear IPFIX people, I recently sent a mail about the writeability of the IPFIX MIB. We (the MIB authors) would like to propose a compromise at the IPFIX session at IETF 67 on Thursday. Before presenting this solution we want to post it here that you can make up your mind and think about it. First of all I would like to divide the MIB in logical parts: - Collector MIB - Exporter MIB o Reporting with Session and Collector Group o Templates o Methods The Collector MIB could be entirely read only because it basically only collects traffic and doesn't need configuration. The Exporter MIB needs some more detailed discussion: - Reporting with Session (which is new and substitutes the collectors and the instances) and Collector Group should be Read Write - Templates should be read only - Methods should be read only We think this is a reasonable compromise between configurabilty and complexity. Please think about it and be prepared for the session. Best Regards, Thomas -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany ------=_NextPart_000_0044_01C701C1.B6C49180 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3 MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4 vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/ jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u 9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTA3MDAz NjMxWjAjBgkqhkiG9w0BCQQxFgQU7esHpdwvakzlBP0uMI/u8S70iEYwZwYJKoZIhvcNAQkPMVow WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAIQFCJyPQRkD5j5929qeZz5S tzczy1c8EDojiDHi7ttlEkkkPobwtbdNs7tKZOMFBzo5hwahi6qm97DSYK0hqBmx3u6TNEJCnU4T 0w9LVO9ULDZFgn/YyAGm7HIXdQvvNaxU4IKYBctO6Dt4GP+RRv3kRybCe71IW0IcbuOl/BKdSTgn s5x9Qp+W9t6PMk9PK/e/XBeHEKUxvKJA4brx2PH2qdpGcdFlT2CIzq+yVcn0A9EUNaarEhkN5Oc5 /vxu2kkWrudvHdT3V7/yiBU9z1TfrFREjue/K+jeL3TVSi/065sAld4GnYkpo3SCh17zHl0MYIIw K8tH8z3ck9v+A1oAAAAAAAA= ------=_NextPart_000_0044_01C701C1.B6C49180-- --===============0493997268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0493997268==-- From ipfix-bounces@ietf.org Mon Nov 06 19:37:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhExA-0008CB-Qz; Mon, 06 Nov 2006 19:36:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEx9-0008Bc-Fq for ipfix@ietf.org; Mon, 06 Nov 2006 19:36:35 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEx8-0003R1-1Y for ipfix@ietf.org; Mon, 06 Nov 2006 19:36:35 -0500 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 4A46220031DE; Tue, 7 Nov 2006 01:37:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CDF8XeORG1q; Tue, 7 Nov 2006 01:37:03 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 291D72000168; Tue, 7 Nov 2006 01:37:03 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Nov 2006 01:36:31 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD696645CE0@mx1.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPFIX MIB writeability proposal Thread-Index: AccCBMTl12EwhW/ITNSPRj5d+xu5kA== From: "Thomas Dietz" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Juergen Quittek Subject: [IPFIX] IPFIX MIB writeability proposal X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0493997268==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0493997268== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0044_01C701C1.B6C49180" This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C701C1.B6C49180 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear IPFIX people, I recently sent a mail about the writeability of the IPFIX MIB. We (the MIB authors) would like to propose a compromise at the IPFIX session at IETF 67 on Thursday. Before presenting this solution we want to post it here that you can make up your mind and think about it. First of all I would like to divide the MIB in logical parts: - Collector MIB - Exporter MIB o Reporting with Session and Collector Group o Templates o Methods The Collector MIB could be entirely read only because it basically only collects traffic and doesn't need configuration. The Exporter MIB needs some more detailed discussion: - Reporting with Session (which is new and substitutes the collectors and the instances) and Collector Group should be Read Write - Templates should be read only - Methods should be read only We think this is a reasonable compromise between configurabilty and complexity. Please think about it and be prepared for the session. Best Regards, Thomas -- Thomas Dietz Network Laboratories, NEC Europe Ltd., 69115 Heidelberg, Germany ------=_NextPart_000_0044_01C701C1.B6C49180 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3 MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4 vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/ jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u 9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTA3MDAz NjMxWjAjBgkqhkiG9w0BCQQxFgQU7esHpdwvakzlBP0uMI/u8S70iEYwZwYJKoZIhvcNAQkPMVow WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAIQFCJyPQRkD5j5929qeZz5S tzczy1c8EDojiDHi7ttlEkkkPobwtbdNs7tKZOMFBzo5hwahi6qm97DSYK0hqBmx3u6TNEJCnU4T 0w9LVO9ULDZFgn/YyAGm7HIXdQvvNaxU4IKYBctO6Dt4GP+RRv3kRybCe71IW0IcbuOl/BKdSTgn s5x9Qp+W9t6PMk9PK/e/XBeHEKUxvKJA4brx2PH2qdpGcdFlT2CIzq+yVcn0A9EUNaarEhkN5Oc5 /vxu2kkWrudvHdT3V7/yiBU9z1TfrFREjue/K+jeL3TVSi/065sAld4GnYkpo3SCh17zHl0MYIIw K8tH8z3ck9v+A1oAAAAAAAA= ------=_NextPart_000_0044_01C701C1.B6C49180-- --===============0493997268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0493997268==-- From ipfix-bounces@ietf.org Tue Nov 07 12:18:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUZv-0007ay-FP; Tue, 07 Nov 2006 12:17:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUZu-0007al-C6 for ipfix@ietf.org; Tue, 07 Nov 2006 12:17:38 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhUZt-0006Bv-06 for ipfix@ietf.org; Tue, 07 Nov 2006 12:17:38 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kA7HG7G06250 for ; Tue, 7 Nov 2006 18:16:07 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 18:17:35 +0100 Message-ID: <70524A4436C03E43A293958B505008B65685B5@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 care-of and home address Thread-Index: AccCkJ45R0ppqpFPQ6yzkPEdDkrRNA== From: "Schmoll, Carsten" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [IPFIX] IPv6 care-of and home address X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Dear gentle people, =20 how would I export an IPv6 care-of address and IPv6 home address? Are there any specific IEs for that? I did not find any in the info model. =20 If both are to be exported in one record I imagine using two sourceIPv6Addresses in one template. Or should we define a separate IEs to distinguish the two? =20 Best regards, Carsten. =20 -- "The difference between theory and practice is that in theory theory and practice are the same but in practice they are not." Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. ANTS for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 07 12:18:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUZv-0007ay-FP; Tue, 07 Nov 2006 12:17:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhUZu-0007al-C6 for ipfix@ietf.org; Tue, 07 Nov 2006 12:17:38 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhUZt-0006Bv-06 for ipfix@ietf.org; Tue, 07 Nov 2006 12:17:38 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kA7HG7G06250 for ; Tue, 7 Nov 2006 18:16:07 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 18:17:35 +0100 Message-ID: <70524A4436C03E43A293958B505008B65685B5@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 care-of and home address Thread-Index: AccCkJ45R0ppqpFPQ6yzkPEdDkrRNA== From: "Schmoll, Carsten" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [IPFIX] IPv6 care-of and home address X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Dear gentle people, =20 how would I export an IPv6 care-of address and IPv6 home address? Are there any specific IEs for that? I did not find any in the info model. =20 If both are to be exported in one record I imagine using two sourceIPv6Addresses in one template. Or should we define a separate IEs to distinguish the two? =20 Best regards, Carsten. =20 -- "The difference between theory and practice is that in theory theory and practice are the same but in practice they are not." Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. ANTS for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 07 13:57:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW7f-0004YC-25; Tue, 07 Nov 2006 13:56:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW7d-0004XX-3J for ipfix@ietf.org; Tue, 07 Nov 2006 13:56:33 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhW7b-0006uu-PR for ipfix@ietf.org; Tue, 07 Nov 2006 13:56:33 -0500 Received: from dhcp69-133.ietf67.org (dhcp69-133.ietf67.org [130.129.69.133]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 189AF13CF82; Tue, 7 Nov 2006 19:58:50 +0100 (CET) Date: Tue, 07 Nov 2006 19:56:28 +0100 From: Juergen Quittek To: "Schmoll, Carsten" , ipfix@ietf.org Subject: Re: [IPFIX] IPv6 care-of and home address Message-ID: <9A34571448C6735701ADE247@dhcp69-133.ietf67.org> In-Reply-To: <70524A4436C03E43A293958B505008B65685B5@EXCHSRV.fokus.fraunhofer.de> References: <70524A4436C03E43A293958B505008B65685B5@EXCHSRV.fokus.fraunhofer.de> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Carsten, I do understand how these addresses are associated with an interface. But how do you think are they associated with a certain flow? Thanks, Juergen --On 07.11.06 18:17 +0100 Schmoll, Carsten wrote: > > Dear gentle people, > > how would I export an IPv6 care-of address and IPv6 home address? > > Are there any specific IEs for that? > I did not find any in the info model. > > If both are to be exported in one record I imagine using two > sourceIPv6Addresses in one template. Or should we define a > separate IEs to distinguish the two? > > Best regards, > Carsten. > > -- > "The difference between theory and practice is that in theory > theory and practice are the same but in practice they are not." > > Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS > schmoll@fokus.fraunhofer.de National Research Institute > Fraunhofer FOKUS / dept. ANTS for Open Communication Systems > Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 > Fax: +49-30-3463-8000 D-10589 Berlin, Germany > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 07 13:57:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW7f-0004YC-25; Tue, 07 Nov 2006 13:56:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhW7d-0004XX-3J for ipfix@ietf.org; Tue, 07 Nov 2006 13:56:33 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhW7b-0006uu-PR for ipfix@ietf.org; Tue, 07 Nov 2006 13:56:33 -0500 Received: from dhcp69-133.ietf67.org (dhcp69-133.ietf67.org [130.129.69.133]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 189AF13CF82; Tue, 7 Nov 2006 19:58:50 +0100 (CET) Date: Tue, 07 Nov 2006 19:56:28 +0100 From: Juergen Quittek To: "Schmoll, Carsten" , ipfix@ietf.org Subject: Re: [IPFIX] IPv6 care-of and home address Message-ID: <9A34571448C6735701ADE247@dhcp69-133.ietf67.org> In-Reply-To: <70524A4436C03E43A293958B505008B65685B5@EXCHSRV.fokus.fraunhofer.de> References: <70524A4436C03E43A293958B505008B65685B5@EXCHSRV.fokus.fraunhofer.de> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Carsten, I do understand how these addresses are associated with an interface. But how do you think are they associated with a certain flow? Thanks, Juergen --On 07.11.06 18:17 +0100 Schmoll, Carsten wrote: > > Dear gentle people, > > how would I export an IPv6 care-of address and IPv6 home address? > > Are there any specific IEs for that? > I did not find any in the info model. > > If both are to be exported in one record I imagine using two > sourceIPv6Addresses in one template. Or should we define a > separate IEs to distinguish the two? > > Best regards, > Carsten. > > -- > "The difference between theory and practice is that in theory > theory and practice are the same but in practice they are not." > > Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS > schmoll@fokus.fraunhofer.de National Research Institute > Fraunhofer FOKUS / dept. ANTS for Open Communication Systems > Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 > Fax: +49-30-3463-8000 D-10589 Berlin, Germany > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 07 17:29:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZQ6-0003zK-Hc; Tue, 07 Nov 2006 17:27:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZQ5-0003yj-8m for ipfix@ietf.org; Tue, 07 Nov 2006 17:27:49 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZQ3-0007XF-W4 for ipfix@ietf.org; Tue, 07 Nov 2006 17:27:49 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2006 23:27:48 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEuWUEWQ/uCLcmdsb2JhbACMSgEJDyo X-IronPort-AV: i="4.09,398,1157320800"; d="scan'208"; a="117888463:sNHT24844384" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA7MRl3f031192; Tue, 7 Nov 2006 23:27:47 +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 kA7MRk4Z006361; Tue, 7 Nov 2006 23:27:46 +0100 (MET) Received: from [10.21.89.127] (sjc-vpn5-383.cisco.com [10.21.89.127]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA29907; Tue, 7 Nov 2006 22:27:45 GMT Message-ID: <45510842.6060808@cisco.com> Date: Tue, 07 Nov 2006 22:27:14 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] IPv6 care-of and home address References: <70524A4436C03E43A293958B505008B65685B5@EXCHSRV.fokus.fraunhofer.de> <9A34571448C6735701ADE247@dhcp69-133.ietf67.org> In-Reply-To: <9A34571448C6735701ADE247@dhcp69-133.ietf67.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=585; t=1162938467; x=1163802467; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20IPv6=20care-of=20and=20home=20address |Sender:; X=v=3Dcisco.com=3B=20h=3D4qFJ82WKJsq+2/q8g7Zzpv0d2PI=3D; b=iX6UblHSYsSIP/eOYGHt11W9BdeRaXwAV+GDgWHyRmBqDTNTG4adEIaFLR4shSQRjJnIkZZw xiViixqzw/CxIw3cl7JW1rH8ABQMgoXjKCIIwvsEBs7w+B86ryIt/+tj; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Schmoll, Carsten" , ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Juergen Quittek wrote: > Carsten, > > I do understand how these addresses are associated with > an interface. But how do you think are they associated > with a certain flow? That really depends on the common properties that define Carsten's flow. Perhaps these different properties could part of an Option Template Record that provides information on an interface. However, it seems that "The IPv6 source address in the IP packet header" is the wrong element to use these and new ones should be requested if there is an application in mind. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 07 17:29:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZQ6-0003zK-Hc; Tue, 07 Nov 2006 17:27:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZQ5-0003yj-8m for ipfix@ietf.org; Tue, 07 Nov 2006 17:27:49 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZQ3-0007XF-W4 for ipfix@ietf.org; Tue, 07 Nov 2006 17:27:49 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Nov 2006 23:27:48 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEuWUEWQ/uCLcmdsb2JhbACMSgEJDyo X-IronPort-AV: i="4.09,398,1157320800"; d="scan'208"; a="117888463:sNHT24844384" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA7MRl3f031192; Tue, 7 Nov 2006 23:27:47 +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 kA7MRk4Z006361; Tue, 7 Nov 2006 23:27:46 +0100 (MET) Received: from [10.21.89.127] (sjc-vpn5-383.cisco.com [10.21.89.127]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id WAA29907; Tue, 7 Nov 2006 22:27:45 GMT Message-ID: <45510842.6060808@cisco.com> Date: Tue, 07 Nov 2006 22:27:14 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] IPv6 care-of and home address References: <70524A4436C03E43A293958B505008B65685B5@EXCHSRV.fokus.fraunhofer.de> <9A34571448C6735701ADE247@dhcp69-133.ietf67.org> In-Reply-To: <9A34571448C6735701ADE247@dhcp69-133.ietf67.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=585; t=1162938467; x=1163802467; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20IPv6=20care-of=20and=20home=20address |Sender:; X=v=3Dcisco.com=3B=20h=3D4qFJ82WKJsq+2/q8g7Zzpv0d2PI=3D; b=iX6UblHSYsSIP/eOYGHt11W9BdeRaXwAV+GDgWHyRmBqDTNTG4adEIaFLR4shSQRjJnIkZZw xiViixqzw/CxIw3cl7JW1rH8ABQMgoXjKCIIwvsEBs7w+B86ryIt/+tj; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Schmoll, Carsten" , ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Juergen Quittek wrote: > Carsten, > > I do understand how these addresses are associated with > an interface. But how do you think are they associated > with a certain flow? That really depends on the common properties that define Carsten's flow. Perhaps these different properties could part of an Option Template Record that provides information on an interface. However, it seems that "The IPv6 source address in the IP packet header" is the wrong element to use these and new ones should be requested if there is an application in mind. regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 07 18:09:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gha4U-0002aR-QR; Tue, 07 Nov 2006 18:09:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gha4T-0002aE-KF for ipfix@ietf.org; Tue, 07 Nov 2006 18:09:33 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gha4S-00050l-Ay for ipfix@ietf.org; Tue, 07 Nov 2006 18:09:33 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kA7N9SOi014647 for ; Tue, 7 Nov 2006 18:09:28 -0500 Received: from [130.129.69.164] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id kA7N9RfZ026554 for ; Tue, 7 Nov 2006 18:09:27 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Date: Tue, 7 Nov 2006 15:06:42 -0800 To: ipfix@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [IPFIX] Fwd: Template Set padding issue X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org All, In ensuring last week that our own IPFIX implementation handles all the vagaries of set padding properly, I found what I think is an inconsistency in the protocol's handling of Template Set padding. The issue is best illustrated by the question, "what does a Collecting Process do with the following Template Set example?": +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 (Template Set) | Set Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 0xB701 | IE Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set padding to 8-byte boundary = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is at first glance a valid template set, aligned to an 8-byte boundary as suggested in "Padding" in sec. 3.3.1 of proto-23. However: 1. The padding length MUST be shorter than any allowable Record in this Set. ("Padding", sec. 3.3.1 of proto-23); and 2. Template Withdrawal messages (sec 8 of proto-23) set the minimum allowable Template Record length to 4 bytes (a Template ID followed by an IE Count of 0). So, if a Collecting Process were to follow the protocol (as I read it presently) and note that the remainder of the set after the first template was equal to the minimum Template Record length, it would interpret it as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 (Template Set) | Set Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 0xB701 | IE Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 0x0000 | IE Count = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which would be an illegal Template Withdraw record (as such records can only appear in a message with other Template Withdraw records: "The Template Withdraw Message MUST NOT contain new Template or Options Template Records.", sec. 8 of proto-23) for an illegal Template ID (Set ID 0x0000 is reserved from V9, sec. 12 para 2 of proto-23; also RFC3954). So, any Template Set padded to an 8-byte boundary would appear to be an illegal Set. One solution would be to explicitly point out that any Template Record which is a four-byte sequence of zeroes be interpreted as padding, as a special case. In other words, a Collecting Process would accept and ignore any Template Withdraw record for Template 0. This solution would also imply that we would want to state that any Options Template Record which is four-byte sequence of zeroes (a Template Withdraw record as above) or a six-byte sequence of zeroes (which would be patently illegal as an Options Template Record) be interpreted as padding as well. This does allow us to pad any type of set to 8-byte boundaries, but has the disadvantage of mandating two extra special-case codepaths at the CP side. Therefore, I'm a little conflicted about it as a proposal. Thoughts? Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Tue Nov 07 18:09:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gha4U-0002aR-QR; Tue, 07 Nov 2006 18:09:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gha4T-0002aE-KF for ipfix@ietf.org; Tue, 07 Nov 2006 18:09:33 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gha4S-00050l-Ay for ipfix@ietf.org; Tue, 07 Nov 2006 18:09:33 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kA7N9SOi014647 for ; Tue, 7 Nov 2006 18:09:28 -0500 Received: from [130.129.69.164] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id kA7N9RfZ026554 for ; Tue, 7 Nov 2006 18:09:27 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Date: Tue, 7 Nov 2006 15:06:42 -0800 To: ipfix@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [IPFIX] Fwd: Template Set padding issue X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org All, In ensuring last week that our own IPFIX implementation handles all the vagaries of set padding properly, I found what I think is an inconsistency in the protocol's handling of Template Set padding. The issue is best illustrated by the question, "what does a Collecting Process do with the following Template Set example?": +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 (Template Set) | Set Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 0xB701 | IE Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set padding to 8-byte boundary = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is at first glance a valid template set, aligned to an 8-byte boundary as suggested in "Padding" in sec. 3.3.1 of proto-23. However: 1. The padding length MUST be shorter than any allowable Record in this Set. ("Padding", sec. 3.3.1 of proto-23); and 2. Template Withdrawal messages (sec 8 of proto-23) set the minimum allowable Template Record length to 4 bytes (a Template ID followed by an IE Count of 0). So, if a Collecting Process were to follow the protocol (as I read it presently) and note that the remainder of the set after the first template was equal to the minimum Template Record length, it would interpret it as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 (Template Set) | Set Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 0xB701 | IE Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 0x0000 | IE Count = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ which would be an illegal Template Withdraw record (as such records can only appear in a message with other Template Withdraw records: "The Template Withdraw Message MUST NOT contain new Template or Options Template Records.", sec. 8 of proto-23) for an illegal Template ID (Set ID 0x0000 is reserved from V9, sec. 12 para 2 of proto-23; also RFC3954). So, any Template Set padded to an 8-byte boundary would appear to be an illegal Set. One solution would be to explicitly point out that any Template Record which is a four-byte sequence of zeroes be interpreted as padding, as a special case. In other words, a Collecting Process would accept and ignore any Template Withdraw record for Template 0. This solution would also imply that we would want to state that any Options Template Record which is four-byte sequence of zeroes (a Template Withdraw record as above) or a six-byte sequence of zeroes (which would be patently illegal as an Options Template Record) be interpreted as padding as well. This does allow us to pad any type of set to 8-byte boundaries, but has the disadvantage of mandating two extra special-case codepaths at the CP side. Therefore, I'm a little conflicted about it as a proposal. Thoughts? Regards, Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From akstcgdarmmnsdgs@gdarm.com Wed Nov 08 02:11:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghhay-0004XO-HU; Wed, 08 Nov 2006 02:11:36 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghhay-0005gK-Fk; Wed, 08 Nov 2006 02:11:36 -0500 Received: from [12.42.193.114] (helo=mail.eohrealty.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ghhav-0007IZ-20; Wed, 08 Nov 2006 02:11:34 -0500 Received: from 217.160.226.100 (HELO mx00.1and1.com) by lists.ietf.org with esmtp (G,+3S40G2.B Q67X) id 2U0:+8-=WH;N@-,0 for ipcdn-archive@lists.ietf.org; Wed, 8 Nov 2006 07:11:32 +0420 Message-ID: <01c70305$1e4cd4e0$6c822ecf@akstcgdarmmnsdgs> From: "Brandy Rosales" To: Subject: Fw: Date: Wed, 8 Nov 2006 07:11:32 +0420 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Spam-Score: 3.9 (+++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 "THESUBWAY.COM" PUT MPRG ON THIER “HOT STOCKS” LIST AFTER WILLIAM MORRIS AGENCY ANNOUNCED IT WILL BE SELLING RIGHTS TO NEW SUTHERLAND MOVIE! Company: The Motion Picture Group Inc. STOCK: MP RG Price: $0.32 UP Today Vol um e Ex pe ct ations: Huge Time to move fast. HUGE announcements on MPRG today. MPRG announced that William Morris Agency, the worlds largest and most diverse talent agency will be selling the rights to the new Keifer Sutherland movie at the 2006 American Film Market. That market closes on the 8th so this deal will be done by end of tomorrow. This is so hot, everyone os getting in while they can and the market watchers are labeling this as the next winner. Watch the trailer at "www.itrustyoutokillmethemovie.com" and get in on MPRG first thing Wed, November 08, 2006. I hope it was a helper news. I'll email or fax you later next week. Brandy Rosales. day, in such dirty weather, and by herself, was almost incredible to mrs. hurst and miss bingley; and "my dear brother, elizabeth's astonishment was beyond expression. she stared, coloured, doubted, and was silent. conjectures, on this interesting subject, by its repeated discussion, no other could detain them from it be justified in devoting too much of our time to music, for there are certainly other things to be "my father is gone to london, and jane has written to beg my uncle's immediate assistance; and "i have often observed how little young ladies are interested by books of a serious stamp, though before, and a positive engagement made of his meeting some of the gentlemen at pemberley before "i can easily believe it. you thought me then devoid of every proper feeling, i am sure you did. and publicly canvassed; and everybody was pleased to know how much they had always disliked mr. From ipfix-bounces@ietf.org Wed Nov 08 03:45:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghj1p-0006T6-PH; Wed, 08 Nov 2006 03:43:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghj1o-0006T1-TI for ipfix@ietf.org; Wed, 08 Nov 2006 03:43:24 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghj1n-000451-9l for ipfix@ietf.org; Wed, 08 Nov 2006 03:43:24 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 09:43:21 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAK4mUUWQ/uCKemdsb2JhbACMSgEBCA8q X-IronPort-AV: i="4.09,400,1157320800"; d="scan'208"; a="118000177:sNHT30574776" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kA88hKO9009490; Wed, 8 Nov 2006 09:43:20 +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 kA88hJ4Z006564; Wed, 8 Nov 2006 09:43:19 +0100 (MET) Received: from [10.89.20.35] (rcdn-vpn-cluster-2-35.cisco.com [10.89.20.35]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA10534; Wed, 8 Nov 2006 08:43:04 GMT Message-ID: <45519870.5010404@cisco.com> Date: Wed, 08 Nov 2006 08:42:24 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> In-Reply-To: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=5852; t=1162975400; x=1163839400; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:; X=v=3Dcisco.com=3B=20h=3Dx9Fd5u0YJ7kArbQ3LVlXr5yVAhw=3D; b=F8Ai/JsFBgd4RAQH35Q2Ht54k0W9Z0e4Trv3EoLIdD0cOmZ3OpuUMQ1fwO1mQFdjGCSFU6Qo f+mGv9x9zozJxTp1HBgFCJ3O2oNK6doDq1tYyIfQouc0a1X/xmIkPzoE; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Brain It seems to me that the either the withdrawal message is either "allowable Record in this set" or it isn't. So does the fact that Template Withdrawal records can only appear in a set of other Withdrawal messages mean that it isn't an "allowable record"? 1. It is allowed: As you quote below "The padding length MUST be shorter than any allowable Record in this Set." If this is an allowable record then you can only pad 3 or less bytes, therefore your below message is illegal as it wants to pad 4 bytes. 2. It is not allowed: If it's a message that is not "allowable" then the padding is valid and the record should be correctly decoded by the collector. I think the spirit of the text is option 2. The collector should not be looking for withdrawal messages here. I agree that you've found a potentially sticky area, but I hope we can clarify the case one way or the other. Brian Trammell wrote: > All, > > In ensuring last week that our own IPFIX implementation handles all the > vagaries of set padding properly, I found what I think is an > inconsistency in the protocol's handling of Template Set padding. The > issue is best illustrated by the question, "what does a Collecting > Process do with the following Template Set example?": > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 (Template Set) | Set Length = 32 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 0xB701 | IE Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set padding to 8-byte boundary = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This is at first glance a valid template set, aligned to an 8-byte > boundary as suggested in "Padding" in sec. 3.3.1 of proto-23. However: > > 1. The padding length MUST be shorter than any allowable Record in this > Set. ("Padding", sec. 3.3.1 of proto-23); and > > 2. Template Withdrawal messages (sec 8 of proto-23) set the minimum > allowable Template Record length to 4 bytes (a Template ID followed by > an IE Count of 0). > > So, if a Collecting Process were to follow the protocol (as I read it > presently) and note that the remainder of the set after the first > template was equal to the minimum Template Record length, it would > interpret it as follows: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 (Template Set) | Set Length = 32 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 0xB701 | IE Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 0x0000 | IE Count = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > which would be an illegal Template Withdraw record (as such records can > only appear in a message with other Template Withdraw records: "The > Template Withdraw Message MUST NOT contain new Template or Options > Template Records.", sec. 8 of proto-23) for an illegal Template ID (Set > ID 0x0000 is reserved from V9, sec. 12 para 2 of proto-23; also > RFC3954). So, any Template Set padded to an 8-byte boundary would appear > to be an illegal Set. > > One solution would be to explicitly point out that any Template Record > which is a four-byte sequence of zeroes be interpreted as padding, as a > special case. In other words, a Collecting Process would accept and > ignore any Template Withdraw record for Template 0. > > This solution would also imply that we would want to state that any > Options Template Record which is four-byte sequence of zeroes (a > Template Withdraw record as above) or a six-byte sequence of zeroes > (which would be patently illegal as an Options Template Record) be > interpreted as padding as well. > > This does allow us to pad any type of set to 8-byte boundaries, but has > the disadvantage of mandating two extra special-case codepaths at the CP > side. Therefore, I'm a little conflicted about it as a proposal. Thoughts? > > Regards, > > Brian > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 08 03:45:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghj1p-0006T6-PH; Wed, 08 Nov 2006 03:43:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghj1o-0006T1-TI for ipfix@ietf.org; Wed, 08 Nov 2006 03:43:24 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghj1n-000451-9l for ipfix@ietf.org; Wed, 08 Nov 2006 03:43:24 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 09:43:21 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAK4mUUWQ/uCKemdsb2JhbACMSgEBCA8q X-IronPort-AV: i="4.09,400,1157320800"; d="scan'208"; a="118000177:sNHT30574776" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kA88hKO9009490; Wed, 8 Nov 2006 09:43:20 +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 kA88hJ4Z006564; Wed, 8 Nov 2006 09:43:19 +0100 (MET) Received: from [10.89.20.35] (rcdn-vpn-cluster-2-35.cisco.com [10.89.20.35]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA10534; Wed, 8 Nov 2006 08:43:04 GMT Message-ID: <45519870.5010404@cisco.com> Date: Wed, 08 Nov 2006 08:42:24 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> In-Reply-To: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=5852; t=1162975400; x=1163839400; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:; X=v=3Dcisco.com=3B=20h=3Dx9Fd5u0YJ7kArbQ3LVlXr5yVAhw=3D; b=F8Ai/JsFBgd4RAQH35Q2Ht54k0W9Z0e4Trv3EoLIdD0cOmZ3OpuUMQ1fwO1mQFdjGCSFU6Qo f+mGv9x9zozJxTp1HBgFCJ3O2oNK6doDq1tYyIfQouc0a1X/xmIkPzoE; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Brain It seems to me that the either the withdrawal message is either "allowable Record in this set" or it isn't. So does the fact that Template Withdrawal records can only appear in a set of other Withdrawal messages mean that it isn't an "allowable record"? 1. It is allowed: As you quote below "The padding length MUST be shorter than any allowable Record in this Set." If this is an allowable record then you can only pad 3 or less bytes, therefore your below message is illegal as it wants to pad 4 bytes. 2. It is not allowed: If it's a message that is not "allowable" then the padding is valid and the record should be correctly decoded by the collector. I think the spirit of the text is option 2. The collector should not be looking for withdrawal messages here. I agree that you've found a potentially sticky area, but I hope we can clarify the case one way or the other. Brian Trammell wrote: > All, > > In ensuring last week that our own IPFIX implementation handles all the > vagaries of set padding properly, I found what I think is an > inconsistency in the protocol's handling of Template Set padding. The > issue is best illustrated by the question, "what does a Collecting > Process do with the following Template Set example?": > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 (Template Set) | Set Length = 32 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 0xB701 | IE Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set padding to 8-byte boundary = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This is at first glance a valid template set, aligned to an 8-byte > boundary as suggested in "Padding" in sec. 3.3.1 of proto-23. However: > > 1. The padding length MUST be shorter than any allowable Record in this > Set. ("Padding", sec. 3.3.1 of proto-23); and > > 2. Template Withdrawal messages (sec 8 of proto-23) set the minimum > allowable Template Record length to 4 bytes (a Template ID followed by > an IE Count of 0). > > So, if a Collecting Process were to follow the protocol (as I read it > presently) and note that the remainder of the set after the first > template was equal to the minimum Template Record length, it would > interpret it as follows: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Set ID = 2 (Template Set) | Set Length = 32 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 0xB701 | IE Count = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID = 0x0000 | IE Count = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > which would be an illegal Template Withdraw record (as such records can > only appear in a message with other Template Withdraw records: "The > Template Withdraw Message MUST NOT contain new Template or Options > Template Records.", sec. 8 of proto-23) for an illegal Template ID (Set > ID 0x0000 is reserved from V9, sec. 12 para 2 of proto-23; also > RFC3954). So, any Template Set padded to an 8-byte boundary would appear > to be an illegal Set. > > One solution would be to explicitly point out that any Template Record > which is a four-byte sequence of zeroes be interpreted as padding, as a > special case. In other words, a Collecting Process would accept and > ignore any Template Withdraw record for Template 0. > > This solution would also imply that we would want to state that any > Options Template Record which is four-byte sequence of zeroes (a > Template Withdraw record as above) or a six-byte sequence of zeroes > (which would be patently illegal as an Options Template Record) be > interpreted as padding as well. > > This does allow us to pad any type of set to 8-byte boundaries, but has > the disadvantage of mandating two extra special-case codepaths at the CP > side. Therefore, I'm a little conflicted about it as a proposal. Thoughts? > > Regards, > > Brian > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 08 11:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghq2y-0003XZ-H0; Wed, 08 Nov 2006 11:13:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghq2x-0003Vt-Of for ipfix@ietf.org; Wed, 08 Nov 2006 11:13:03 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghq2w-0002Lz-20 for ipfix@ietf.org; Wed, 08 Nov 2006 11:13:03 -0500 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id AB45E20031DE; Wed, 8 Nov 2006 17:13:24 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mANGSYmt7kCV; Wed, 8 Nov 2006 17:13:24 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8727D20031DA; Wed, 8 Nov 2006 17:13:24 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [IPFIX] Fwd: Template Set padding issue Date: Wed, 8 Nov 2006 17:12:49 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD696645FCC@mx1.office> In-Reply-To: <45519870.5010404@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Fwd: Template Set padding issue Thread-Index: AccDEkL7worX9lyQR8qXD0AYUegM7wAPkhQA From: "Thomas Dietz" To: "Andrew Johnson" , "Brian Trammell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0661624208==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0661624208== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0006_01C7030D.AB4EB9F0" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C7030D.AB4EB9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Brian, Andrew, If I am not mistaken here, you cannot mix templates with withdraw templates. So (if this is the case) this is a non issue. Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@netlab.nec.de Network Laboratories Phone: +49 6221 4342-128 NEC Europe Ltd. Fax: +49 6221 4342-155 Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.netlab.nec.de > -----Original Message----- > From: Andrew Johnson [mailto:andrjohn@cisco.com] > Sent: Wednesday, November 08, 2006 12:42 AM > To: Brian Trammell > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] Fwd: Template Set padding issue > > Hi Brain > > It seems to me that the either the withdrawal message is either > "allowable Record in this set" or it isn't. So does the fact > that Template Withdrawal records can only appear in a set of > other Withdrawal messages mean that it isn't an "allowable > record"? > > 1. It is allowed: > As you quote below "The padding length MUST be shorter than > any allowable Record in this Set." If this is an allowable > record then you can only pad 3 or less bytes, therefore your > below message is illegal as it wants to pad 4 bytes. > > 2. It is not allowed: > If it's a message that is not "allowable" then the padding > is valid and the record should be correctly decoded by the > collector. > > I think the spirit of the text is option 2. The collector > should not be looking for withdrawal messages here. I agree > that you've found a potentially sticky area, but I hope we > can clarify the case one way or the other. > > > > Brian Trammell wrote: > > All, > > > > In ensuring last week that our own IPFIX implementation > handles all the > > vagaries of set padding properly, I found what I think is an > > inconsistency in the protocol's handling of Template Set > padding. The > > issue is best illustrated by the question, "what does a Collecting > > Process do with the following Template Set example?": > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Set ID = 2 (Template Set) | Set Length = 32 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Template ID = 0xB701 | IE Count = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Set padding to 8-byte boundary = 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > This is at first glance a valid template set, aligned to an 8-byte > > boundary as suggested in "Padding" in sec. 3.3.1 of > proto-23. However: > > > > 1. The padding length MUST be shorter than any allowable > Record in this > > Set. ("Padding", sec. 3.3.1 of proto-23); and > > > > 2. Template Withdrawal messages (sec 8 of proto-23) set the minimum > > allowable Template Record length to 4 bytes (a Template ID > followed by > > an IE Count of 0). > > > > So, if a Collecting Process were to follow the protocol (as > I read it > > presently) and note that the remainder of the set after the first > > template was equal to the minimum Template Record length, it would > > interpret it as follows: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Set ID = 2 (Template Set) | Set Length = 32 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Template ID = 0xB701 | IE Count = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Template ID = 0x0000 | IE Count = 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > which would be an illegal Template Withdraw record (as such > records can > > only appear in a message with other Template Withdraw records: "The > > Template Withdraw Message MUST NOT contain new Template or Options > > Template Records.", sec. 8 of proto-23) for an illegal > Template ID (Set > > ID 0x0000 is reserved from V9, sec. 12 para 2 of proto-23; also > > RFC3954). So, any Template Set padded to an 8-byte boundary > would appear > > to be an illegal Set. > > > > One solution would be to explicitly point out that any > Template Record > > which is a four-byte sequence of zeroes be interpreted as > padding, as a > > special case. In other words, a Collecting Process would accept and > > ignore any Template Withdraw record for Template 0. > > > > This solution would also imply that we would want to state that any > > Options Template Record which is four-byte sequence of zeroes (a > > Template Withdraw record as above) or a six-byte sequence of zeroes > > (which would be patently illegal as an Options Template Record) be > > interpreted as padding as well. > > > > This does allow us to pad any type of set to 8-byte > boundaries, but has > > the disadvantage of mandating two extra special-case > codepaths at the CP > > side. Therefore, I'm a little conflicted about it as a > proposal. Thoughts? > > > > Regards, > > > > Brian > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > ------=_NextPart_000_0006_01C7030D.AB4EB9F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3 MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4 vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/ jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u 9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTA4MTYx MjQ0WjAjBgkqhkiG9w0BCQQxFgQUwwvQgqzzBh5NdzWxdnocaErhLZ0wZwYJKoZIhvcNAQkPMVow WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAB44PWz56AODanOmLR/VLgFR 8SgjxmVRtQ6m+yoofmuENp3VqzVr9y5J8FE2zZa+u/HeZ4mWt/hsdmihAScqaTcxwb5VlqancBS8 p1Cf3Gt82HvXue6tRjTejn/VxsxlaVhjWFGODedqsjsp44i7jRXHq8LLp4CoQm+GzqYoxsCDi5jn lQMfpsMZe+iAWVaHSr4NW97raySE0s3KqLIGEtmrj2dwmZC+NT303GbS1cGFEEkSpwUINdBCIoEw Opws6QKCh9FKvS3nl3s4HEUX6WgxbhIhIieyWeYexE+j3b/7US+V+7k0mQmaoyK50bunNUURpQCi xfblPwx8rWXGGOgAAAAAAAA= ------=_NextPart_000_0006_01C7030D.AB4EB9F0-- --===============0661624208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0661624208==-- From ipfix-bounces@ietf.org Wed Nov 08 11:14:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghq2y-0003XZ-H0; Wed, 08 Nov 2006 11:13:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghq2x-0003Vt-Of for ipfix@ietf.org; Wed, 08 Nov 2006 11:13:03 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghq2w-0002Lz-20 for ipfix@ietf.org; Wed, 08 Nov 2006 11:13:03 -0500 Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id AB45E20031DE; Wed, 8 Nov 2006 17:13:24 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mANGSYmt7kCV; Wed, 8 Nov 2006 17:13:24 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8727D20031DA; Wed, 8 Nov 2006 17:13:24 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [IPFIX] Fwd: Template Set padding issue Date: Wed, 8 Nov 2006 17:12:49 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD696645FCC@mx1.office> In-Reply-To: <45519870.5010404@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] Fwd: Template Set padding issue Thread-Index: AccDEkL7worX9lyQR8qXD0AYUegM7wAPkhQA From: "Thomas Dietz" To: "Andrew Johnson" , "Brian Trammell" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0661624208==" Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --===============0661624208== Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0006_01C7030D.AB4EB9F0" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C7030D.AB4EB9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Brian, Andrew, If I am not mistaken here, you cannot mix templates with withdraw templates. So (if this is the case) this is a non issue. Regards, Thomas -- Thomas Dietz E-mail: Thomas.Dietz@netlab.nec.de Network Laboratories Phone: +49 6221 4342-128 NEC Europe Ltd. Fax: +49 6221 4342-155 Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.netlab.nec.de > -----Original Message----- > From: Andrew Johnson [mailto:andrjohn@cisco.com] > Sent: Wednesday, November 08, 2006 12:42 AM > To: Brian Trammell > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] Fwd: Template Set padding issue > > Hi Brain > > It seems to me that the either the withdrawal message is either > "allowable Record in this set" or it isn't. So does the fact > that Template Withdrawal records can only appear in a set of > other Withdrawal messages mean that it isn't an "allowable > record"? > > 1. It is allowed: > As you quote below "The padding length MUST be shorter than > any allowable Record in this Set." If this is an allowable > record then you can only pad 3 or less bytes, therefore your > below message is illegal as it wants to pad 4 bytes. > > 2. It is not allowed: > If it's a message that is not "allowable" then the padding > is valid and the record should be correctly decoded by the > collector. > > I think the spirit of the text is option 2. The collector > should not be looking for withdrawal messages here. I agree > that you've found a potentially sticky area, but I hope we > can clarify the case one way or the other. > > > > Brian Trammell wrote: > > All, > > > > In ensuring last week that our own IPFIX implementation > handles all the > > vagaries of set padding properly, I found what I think is an > > inconsistency in the protocol's handling of Template Set > padding. The > > issue is best illustrated by the question, "what does a Collecting > > Process do with the following Template Set example?": > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Set ID = 2 (Template Set) | Set Length = 32 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Template ID = 0xB701 | IE Count = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Set padding to 8-byte boundary = 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > This is at first glance a valid template set, aligned to an 8-byte > > boundary as suggested in "Padding" in sec. 3.3.1 of > proto-23. However: > > > > 1. The padding length MUST be shorter than any allowable > Record in this > > Set. ("Padding", sec. 3.3.1 of proto-23); and > > > > 2. Template Withdrawal messages (sec 8 of proto-23) set the minimum > > allowable Template Record length to 4 bytes (a Template ID > followed by > > an IE Count of 0). > > > > So, if a Collecting Process were to follow the protocol (as > I read it > > presently) and note that the remainder of the set after the first > > template was equal to the minimum Template Record length, it would > > interpret it as follows: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Set ID = 2 (Template Set) | Set Length = 32 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Template ID = 0xB701 | IE Count = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Template ID = 0x0000 | IE Count = 0 | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > which would be an illegal Template Withdraw record (as such > records can > > only appear in a message with other Template Withdraw records: "The > > Template Withdraw Message MUST NOT contain new Template or Options > > Template Records.", sec. 8 of proto-23) for an illegal > Template ID (Set > > ID 0x0000 is reserved from V9, sec. 12 para 2 of proto-23; also > > RFC3954). So, any Template Set padded to an 8-byte boundary > would appear > > to be an illegal Set. > > > > One solution would be to explicitly point out that any > Template Record > > which is a four-byte sequence of zeroes be interpreted as > padding, as a > > special case. In other words, a Collecting Process would accept and > > ignore any Template Withdraw record for Template 0. > > > > This solution would also imply that we would want to state that any > > Options Template Record which is four-byte sequence of zeroes (a > > Template Withdraw record as above) or a six-byte sequence of zeroes > > (which would be patently illegal as an Options Template Record) be > > interpreted as padding as well. > > > > This does allow us to pad any type of set to 8-byte > boundaries, but has > > the disadvantage of mandating two extra special-case > codepaths at the CP > > side. Therefore, I'm a little conflicted about it as a > proposal. Thoughts? > > > > Regards, > > > > Brian > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipfix > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix > ------=_NextPart_000_0006_01C7030D.AB4EB9F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJfTCCAwUw ggJuoAMCAQICEDNPKBqVVn29xxL8Ep6jwQAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDgwMzE0NTMyNVoXDTA3MDgwMzE0NTMy NVowYzEOMAwGA1UEBBMFRGlldHoxDzANBgNVBCoTBlRob21hczEVMBMGA1UEAxMMVGhvbWFzIERp ZXR6MSkwJwYJKoZIhvcNAQkBFhpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAJ7o/CiPtV5IVpryvix3S941FioZKoy4XRu+e3IQgIEMOE1b fKwAiusFHiFcd38WbWg5y683xjELLPvmPmjtz/GtQXcv6I60KTi8p8LKM7XgNKDT4imzXXiwCURn OFiU11mX3foGg1z35+gRnLwnwy9aoCtsmoj3o1R6uJ2maQzV3+rqkGx8TtQZKKV5ODd+rg+XkQbB OJKjAeiaRUjpABysi5hsnzxlRwd5ZkmPww4QopXwYSWlazKOypVL0o9S0+ZIFQn8R+mhpX6v4vJw vYED7Dci1FNyxu9T7ylO327AyoMUFXI655BN4A9TzB8TV/gnK3qXVTX0IG1ZFoDwtncCAwEAAaM3 MDUwJQYDVR0RBB4wHIEaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQUFAAOBgQCTQ8yxs18IN1J739z9tXApNAvhgq/w60BXhNub1tgyhmdAq2D9bEe4 vfF7WYNQ/xk+Zt2cphWV5lRFBreqbK9Yv3teegZ9+gGakiwxpC5GUkXctPvUNrebOQPLozgTk7g/ jZNKdRs0X3ykHyCk+mhVrWjwXPHMjFDIpwh6JzD81jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u 9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDeTCCA3UCAQEwdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEDNPKBqVVn29xxL8Ep6jwQAwCQYFKw4DAhoF AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTA4MTYx MjQ0WjAjBgkqhkiG9w0BCQQxFgQUwwvQgqzzBh5NdzWxdnocaErhLZ0wZwYJKoZIhvcNAQkPMVow WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAzTygalVZ9vccS/BKeo8EAMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAhAzTygalVZ9vccS/BKeo8EAMA0GCSqGSIb3DQEBAQUABIIBAB44PWz56AODanOmLR/VLgFR 8SgjxmVRtQ6m+yoofmuENp3VqzVr9y5J8FE2zZa+u/HeZ4mWt/hsdmihAScqaTcxwb5VlqancBS8 p1Cf3Gt82HvXue6tRjTejn/VxsxlaVhjWFGODedqsjsp44i7jRXHq8LLp4CoQm+GzqYoxsCDi5jn lQMfpsMZe+iAWVaHSr4NW97raySE0s3KqLIGEtmrj2dwmZC+NT303GbS1cGFEEkSpwUINdBCIoEw Opws6QKCh9FKvS3nl3s4HEUX6WgxbhIhIieyWeYexE+j3b/7US+V+7k0mQmaoyK50bunNUURpQCi xfblPwx8rWXGGOgAAAAAAAA= ------=_NextPart_000_0006_01C7030D.AB4EB9F0-- --===============0661624208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --===============0661624208==-- From ipfix-bounces@ietf.org Wed Nov 08 11:26:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqFi-0001iP-Hx; Wed, 08 Nov 2006 11:26:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqFh-0001iK-OO for ipfix@ietf.org; Wed, 08 Nov 2006 11:26:13 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhqFf-0004QS-6S for ipfix@ietf.org; Wed, 08 Nov 2006 11:26:13 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 17:21:42 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIOTUUWQ/uCLcmdsb2JhbACMSwEJDyo X-IronPort-AV: i="4.09,401,1157320800"; d="scan'208"; a="118147187:sNHT3350693826" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA8GLgfu025066; Wed, 8 Nov 2006 17:21:42 +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 kA8GLT4Z020133; Wed, 8 Nov 2006 17:21:30 +0100 (MET) Received: from [10.21.97.73] (sjc-vpn1-329.cisco.com [10.21.97.73]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA25548; Wed, 8 Nov 2006 16:21:24 GMT Message-ID: <455203F2.704@cisco.com> Date: Wed, 08 Nov 2006 16:21:06 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Thomas Dietz Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <113091BD57179D4491C19DA7E10CD696645FCC@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD696645FCC@mx1.office> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=344; t=1163002902; x=1163866902; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:; X=v=3Dcisco.com=3B=20h=3DjPI6TgyVNupOWxLD1vgI/WuphZc=3D; b=A2yo0JviQpi3l1QSlSstLUF5SIMdbtRBPbdH53RuwpO+yeA4f4piFssdoo6RSCDloZYvZODJ XmYzi+OR6P9CZUa9Kkwj+nwc3TKCJxlxUzxfLwRiAEPZw/QC16SZlBFH; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Thomas Dietz wrote: > If I am not mistaken here, you cannot mix templates with withdraw > templates. Thomas is right: the fourth paragrah under Figure T in IPFIX-PROTO says: The Template Withdraw Message MUST NOT contain new Template or Options Template Records. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 08 11:26:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqFi-0001iP-Hx; Wed, 08 Nov 2006 11:26:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhqFh-0001iK-OO for ipfix@ietf.org; Wed, 08 Nov 2006 11:26:13 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhqFf-0004QS-6S for ipfix@ietf.org; Wed, 08 Nov 2006 11:26:13 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 17:21:42 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIOTUUWQ/uCLcmdsb2JhbACMSwEJDyo X-IronPort-AV: i="4.09,401,1157320800"; d="scan'208"; a="118147187:sNHT3350693826" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA8GLgfu025066; Wed, 8 Nov 2006 17:21:42 +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 kA8GLT4Z020133; Wed, 8 Nov 2006 17:21:30 +0100 (MET) Received: from [10.21.97.73] (sjc-vpn1-329.cisco.com [10.21.97.73]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id QAA25548; Wed, 8 Nov 2006 16:21:24 GMT Message-ID: <455203F2.704@cisco.com> Date: Wed, 08 Nov 2006 16:21:06 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Thomas Dietz Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <113091BD57179D4491C19DA7E10CD696645FCC@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD696645FCC@mx1.office> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=344; t=1163002902; x=1163866902; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:; X=v=3Dcisco.com=3B=20h=3DjPI6TgyVNupOWxLD1vgI/WuphZc=3D; b=A2yo0JviQpi3l1QSlSstLUF5SIMdbtRBPbdH53RuwpO+yeA4f4piFssdoo6RSCDloZYvZODJ XmYzi+OR6P9CZUa9Kkwj+nwc3TKCJxlxUzxfLwRiAEPZw/QC16SZlBFH; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Thomas Dietz wrote: > If I am not mistaken here, you cannot mix templates with withdraw > templates. Thomas is right: the fourth paragrah under Figure T in IPFIX-PROTO says: The Template Withdraw Message MUST NOT contain new Template or Options Template Records. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 08 12:02:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghqok-0002f6-6j; Wed, 08 Nov 2006 12:02:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghqoj-0002f1-9o for ipfix@ietf.org; Wed, 08 Nov 2006 12:02:25 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghqog-00019B-R7 for ipfix@ietf.org; Wed, 08 Nov 2006 12:02:25 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kA8H2F7n005315 for ; Wed, 8 Nov 2006 12:02:15 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kA8H267n005293 for ; Wed, 8 Nov 2006 12:02:06 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kA8H26EX005291; Wed, 08 Nov 2006 12:02:06 -0500 (EST) Received: from [130.129.69.164] (vpn-10-25-4-19.remote.cert.org [10.25.4.19]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id kA8H25Cq020810; Wed, 8 Nov 2006 12:02:05 -0500 In-Reply-To: <45519870.5010404@cisco.com> References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue Date: Wed, 8 Nov 2006 09:01:25 -0800 To: Andrew Johnson X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Indeed, the protocol does not allow Template Withdrawals other than in their own Set (and these in their own Message). So, the minimum allowable record length in a Set is then as follows: Template Set: IF Template Withdrawal, then 4 (TID + 0x0000); otherwise 8 (TID + IE Count + IE 0 + Len 0) Options Template Set: IF Template Withdrawal, then 4 (TID + 0x0000); otherwise 10 (TID + IE Count + Scope Count + IE 0 + Len 0) So the question now becomes "how does the Collecting Process determine that a Template Set contains Template Withdrawals". Since the protocol doesn't define a Set ID for template withdrawals (the Set ID MUST be 2 to withdraw Templates or 3 to withdraw Options Templates), when reading the first {Options} Template Set in a Message it must be assumed to possibly contain a Template Withdrawal until the first Template Record is read. This is actually not all that bad WRT requiring special case treatment at the CP (and is certainly much more acceptable than my earlier proposal). Padding will also work in this case (as padding is read at the _end_ of the Template Set, after the first record is read). However, as an implementor, I would still suggest that we note this is a bit tricky in the implementation guidelines... Thanks! - Brian On Nov 8, 2006, at 12:42 AM, Andrew Johnson wrote: > Hi Brain > > It seems to me that the either the withdrawal message is either > "allowable Record in this set" or it isn't. So does the fact > that Template Withdrawal records can only appear in a set of > other Withdrawal messages mean that it isn't an "allowable > record"? > > 1. It is allowed: > As you quote below "The padding length MUST be shorter than > any allowable Record in this Set." If this is an allowable > record then you can only pad 3 or less bytes, therefore your > below message is illegal as it wants to pad 4 bytes. > > 2. It is not allowed: > If it's a message that is not "allowable" then the padding > is valid and the record should be correctly decoded by the > collector. > > I think the spirit of the text is option 2. The collector > should not be looking for withdrawal messages here. I agree > that you've found a potentially sticky area, but I hope we > can clarify the case one way or the other. > > > Brian Trammell wrote: >> All, >> In ensuring last week that our own IPFIX implementation handles >> all the vagaries of set padding properly, I found what I think is >> an inconsistency in the protocol's handling of Template Set >> padding. The issue is best illustrated by the question, "what does >> a Collecting Process do with the following Template Set example?": >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 (Template Set) | Set Length = 32 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 0xB701 | IE Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set padding to 8-byte boundary = 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> This is at first glance a valid template set, aligned to an 8-byte >> boundary as suggested in "Padding" in sec. 3.3.1 of proto-23. >> However: >> 1. The padding length MUST be shorter than any allowable Record in >> this Set. ("Padding", sec. 3.3.1 of proto-23); and >> 2. Template Withdrawal messages (sec 8 of proto-23) set the >> minimum allowable Template Record length to 4 bytes (a Template ID >> followed by an IE Count of 0). >> So, if a Collecting Process were to follow the protocol (as I read >> it presently) and note that the remainder of the set after the >> first template was equal to the minimum Template Record length, it >> would interpret it as follows: >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 (Template Set) | Set Length = 32 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 0xB701 | IE Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 0x0000 | IE Count = 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> which would be an illegal Template Withdraw record (as such >> records can only appear in a message with other Template Withdraw >> records: "The Template Withdraw Message MUST NOT contain new >> Template or Options Template Records.", sec. 8 of proto-23) for an >> illegal Template ID (Set ID 0x0000 is reserved from V9, sec. 12 >> para 2 of proto-23; also RFC3954). So, any Template Set padded to >> an 8-byte boundary would appear to be an illegal Set. >> One solution would be to explicitly point out that any Template >> Record which is a four-byte sequence of zeroes be interpreted as >> padding, as a special case. In other words, a Collecting Process >> would accept and ignore any Template Withdraw record for Template 0. >> This solution would also imply that we would want to state that >> any Options Template Record which is four-byte sequence of zeroes >> (a Template Withdraw record as above) or a six-byte sequence of >> zeroes (which would be patently illegal as an Options Template >> Record) be interpreted as padding as well. >> This does allow us to pad any type of set to 8-byte boundaries, >> but has the disadvantage of mandating two extra special-case >> codepaths at the CP side. Therefore, I'm a little conflicted about >> it as a proposal. Thoughts? >> Regards, >> Brian >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 08 12:02:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghqok-0002f6-6j; Wed, 08 Nov 2006 12:02:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghqoj-0002f1-9o for ipfix@ietf.org; Wed, 08 Nov 2006 12:02:25 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghqog-00019B-R7 for ipfix@ietf.org; Wed, 08 Nov 2006 12:02:25 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kA8H2F7n005315 for ; Wed, 8 Nov 2006 12:02:15 -0500 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kA8H267n005293 for ; Wed, 8 Nov 2006 12:02:06 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kA8H26EX005291; Wed, 08 Nov 2006 12:02:06 -0500 (EST) Received: from [130.129.69.164] (vpn-10-25-4-19.remote.cert.org [10.25.4.19]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id kA8H25Cq020810; Wed, 8 Nov 2006 12:02:05 -0500 In-Reply-To: <45519870.5010404@cisco.com> References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue Date: Wed, 8 Nov 2006 09:01:25 -0800 To: Andrew Johnson X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Indeed, the protocol does not allow Template Withdrawals other than in their own Set (and these in their own Message). So, the minimum allowable record length in a Set is then as follows: Template Set: IF Template Withdrawal, then 4 (TID + 0x0000); otherwise 8 (TID + IE Count + IE 0 + Len 0) Options Template Set: IF Template Withdrawal, then 4 (TID + 0x0000); otherwise 10 (TID + IE Count + Scope Count + IE 0 + Len 0) So the question now becomes "how does the Collecting Process determine that a Template Set contains Template Withdrawals". Since the protocol doesn't define a Set ID for template withdrawals (the Set ID MUST be 2 to withdraw Templates or 3 to withdraw Options Templates), when reading the first {Options} Template Set in a Message it must be assumed to possibly contain a Template Withdrawal until the first Template Record is read. This is actually not all that bad WRT requiring special case treatment at the CP (and is certainly much more acceptable than my earlier proposal). Padding will also work in this case (as padding is read at the _end_ of the Template Set, after the first record is read). However, as an implementor, I would still suggest that we note this is a bit tricky in the implementation guidelines... Thanks! - Brian On Nov 8, 2006, at 12:42 AM, Andrew Johnson wrote: > Hi Brain > > It seems to me that the either the withdrawal message is either > "allowable Record in this set" or it isn't. So does the fact > that Template Withdrawal records can only appear in a set of > other Withdrawal messages mean that it isn't an "allowable > record"? > > 1. It is allowed: > As you quote below "The padding length MUST be shorter than > any allowable Record in this Set." If this is an allowable > record then you can only pad 3 or less bytes, therefore your > below message is illegal as it wants to pad 4 bytes. > > 2. It is not allowed: > If it's a message that is not "allowable" then the padding > is valid and the record should be correctly decoded by the > collector. > > I think the spirit of the text is option 2. The collector > should not be looking for withdrawal messages here. I agree > that you've found a potentially sticky area, but I hope we > can clarify the case one way or the other. > > > Brian Trammell wrote: >> All, >> In ensuring last week that our own IPFIX implementation handles >> all the vagaries of set padding properly, I found what I think is >> an inconsistency in the protocol's handling of Template Set >> padding. The issue is best illustrated by the question, "what does >> a Collecting Process do with the following Template Set example?": >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 (Template Set) | Set Length = 32 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 0xB701 | IE Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set padding to 8-byte boundary = 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> This is at first glance a valid template set, aligned to an 8-byte >> boundary as suggested in "Padding" in sec. 3.3.1 of proto-23. >> However: >> 1. The padding length MUST be shorter than any allowable Record in >> this Set. ("Padding", sec. 3.3.1 of proto-23); and >> 2. Template Withdrawal messages (sec 8 of proto-23) set the >> minimum allowable Template Record length to 4 bytes (a Template ID >> followed by an IE Count of 0). >> So, if a Collecting Process were to follow the protocol (as I read >> it presently) and note that the remainder of the set after the >> first template was equal to the minimum Template Record length, it >> would interpret it as follows: >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID = 2 (Template Set) | Set Length = 32 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 0xB701 | IE Count = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID = 0x0000 | IE Count = 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> which would be an illegal Template Withdraw record (as such >> records can only appear in a message with other Template Withdraw >> records: "The Template Withdraw Message MUST NOT contain new >> Template or Options Template Records.", sec. 8 of proto-23) for an >> illegal Template ID (Set ID 0x0000 is reserved from V9, sec. 12 >> para 2 of proto-23; also RFC3954). So, any Template Set padded to >> an 8-byte boundary would appear to be an illegal Set. >> One solution would be to explicitly point out that any Template >> Record which is a four-byte sequence of zeroes be interpreted as >> padding, as a special case. In other words, a Collecting Process >> would accept and ignore any Template Withdraw record for Template 0. >> This solution would also imply that we would want to state that >> any Options Template Record which is four-byte sequence of zeroes >> (a Template Withdraw record as above) or a six-byte sequence of >> zeroes (which would be patently illegal as an Options Template >> Record) be interpreted as padding as well. >> This does allow us to pad any type of set to 8-byte boundaries, >> but has the disadvantage of mandating two extra special-case >> codepaths at the CP side. Therefore, I'm a little conflicted about >> it as a proposal. Thoughts? >> Regards, >> Brian >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 08 13:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghryx-0006gM-7U; Wed, 08 Nov 2006 13:17:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghryv-0006gE-S9 for ipfix@ietf.org; Wed, 08 Nov 2006 13:17:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghryu-0004aJ-5v for ipfix@ietf.org; Wed, 08 Nov 2006 13:17:01 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 19:16:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADStUUWQ/uCKcmdsb2JhbACMSwEJDyo X-IronPort-AV: i="4.09,401,1157320800"; d="scan'208"; a="118182231:sNHT33111816" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kA8IGtH3013703; Wed, 8 Nov 2006 19:16:55 +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 kA8IGt4Z017995; Wed, 8 Nov 2006 19:16:55 +0100 (MET) Received: from [10.82.216.87] (rtp-vpn3-87.cisco.com [10.82.216.87]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA08922; Wed, 8 Nov 2006 18:16:52 GMT Message-ID: <45521EF5.2020304@cisco.com> Date: Wed, 08 Nov 2006 18:16:21 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> In-Reply-To: <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=7885; t=1163009815; x=1163873815; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:; X=v=3Dcisco.com=3B=20h=3Dx9Fd5u0YJ7kArbQ3LVlXr5yVAhw=3D; b=GUqGdF60u+tdo6qK0EDOSSBAKiGMolCrB4YzOHVrdjgdIxZ3MoslavPaEgHqrfmazsMibCKz qSfGGIEE3CF76WTDH155OHyaC/v9lpu1oHKOKOGzi3IEPjhrcNZ8W/F5; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian Trammell wrote: > Indeed, the protocol does not allow Template Withdrawals other than in > their own Set (and these in their own Message). So, the minimum > allowable record length in a Set is then as follows: > > Template Set: IF Template Withdrawal, then 4 (TID + 0x0000); > otherwise 8 (TID + IE Count + IE 0 + Len 0) > > Options Template Set: IF Template Withdrawal, then 4 (TID + 0x0000); > otherwise 10 (TID + IE Count + Scope Count + IE 0 + Len 0) > > So the question now becomes "how does the Collecting Process determine > that a Template Set contains Template Withdrawals". Since the protocol > doesn't define a Set ID for template withdrawals (the Set ID MUST be 2 > to withdraw Templates or 3 to withdraw Options Templates), when reading > the first {Options} Template Set in a Message it must be assumed to > possibly contain a Template Withdrawal until the first Template Record > is read. If the protocol says that the withdrawals must be in their own message, them the decision can be made on the very first Set. I would recommend that on receiving a message, determining if it is a withdrawal message is one of the first actions to be taken. Can we have a message with both Template withdrawals and Option Template withdrawals or do they have to be sent separately? > This is actually not all that bad WRT requiring special case treatment > at the CP (and is certainly much more acceptable than my earlier > proposal). Padding will also work in this case (as padding is read at > the _end_ of the Template Set, after the first record is read). However, > as an implementor, I would still suggest that we note this is a bit > tricky in the implementation guidelines... I agree. regards Andrew > On Nov 8, 2006, at 12:42 AM, Andrew Johnson wrote: > >> Hi Brain >> >> It seems to me that the either the withdrawal message is either >> "allowable Record in this set" or it isn't. So does the fact >> that Template Withdrawal records can only appear in a set of >> other Withdrawal messages mean that it isn't an "allowable >> record"? >> >> 1. It is allowed: >> As you quote below "The padding length MUST be shorter than >> any allowable Record in this Set." If this is an allowable >> record then you can only pad 3 or less bytes, therefore your >> below message is illegal as it wants to pad 4 bytes. >> >> 2. It is not allowed: >> If it's a message that is not "allowable" then the padding >> is valid and the record should be correctly decoded by the >> collector. >> >> I think the spirit of the text is option 2. The collector >> should not be looking for withdrawal messages here. I agree >> that you've found a potentially sticky area, but I hope we >> can clarify the case one way or the other. >> >> >> Brian Trammell wrote: >>> All, >>> In ensuring last week that our own IPFIX implementation handles all >>> the vagaries of set padding properly, I found what I think is an >>> inconsistency in the protocol's handling of Template Set padding. The >>> issue is best illustrated by the question, "what does a Collecting >>> Process do with the following Template Set example?": >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 2 (Template Set) | Set Length = 32 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Template ID = 0xB701 | IE Count = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set padding to 8-byte boundary = 0 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> This is at first glance a valid template set, aligned to an 8-byte >>> boundary as suggested in "Padding" in sec. 3.3.1 of proto-23. However: >>> 1. The padding length MUST be shorter than any allowable Record in >>> this Set. ("Padding", sec. 3.3.1 of proto-23); and >>> 2. Template Withdrawal messages (sec 8 of proto-23) set the minimum >>> allowable Template Record length to 4 bytes (a Template ID followed >>> by an IE Count of 0). >>> So, if a Collecting Process were to follow the protocol (as I read it >>> presently) and note that the remainder of the set after the first >>> template was equal to the minimum Template Record length, it would >>> interpret it as follows: >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 2 (Template Set) | Set Length = 32 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Template ID = 0xB701 | IE Count = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Template ID = 0x0000 | IE Count = 0 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> which would be an illegal Template Withdraw record (as such records >>> can only appear in a message with other Template Withdraw records: >>> "The Template Withdraw Message MUST NOT contain new Template or >>> Options Template Records.", sec. 8 of proto-23) for an illegal >>> Template ID (Set ID 0x0000 is reserved from V9, sec. 12 para 2 of >>> proto-23; also RFC3954). So, any Template Set padded to an 8-byte >>> boundary would appear to be an illegal Set. >>> One solution would be to explicitly point out that any Template >>> Record which is a four-byte sequence of zeroes be interpreted as >>> padding, as a special case. In other words, a Collecting Process >>> would accept and ignore any Template Withdraw record for Template 0. >>> This solution would also imply that we would want to state that any >>> Options Template Record which is four-byte sequence of zeroes (a >>> Template Withdraw record as above) or a six-byte sequence of zeroes >>> (which would be patently illegal as an Options Template Record) be >>> interpreted as padding as well. >>> This does allow us to pad any type of set to 8-byte boundaries, but >>> has the disadvantage of mandating two extra special-case codepaths at >>> the CP side. Therefore, I'm a little conflicted about it as a >>> proposal. Thoughts? >>> Regards, >>> Brian >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 08 13:18:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghryx-0006gM-7U; Wed, 08 Nov 2006 13:17:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghryv-0006gE-S9 for ipfix@ietf.org; Wed, 08 Nov 2006 13:17:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghryu-0004aJ-5v for ipfix@ietf.org; Wed, 08 Nov 2006 13:17:01 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 19:16:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADStUUWQ/uCKcmdsb2JhbACMSwEJDyo X-IronPort-AV: i="4.09,401,1157320800"; d="scan'208"; a="118182231:sNHT33111816" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kA8IGtH3013703; Wed, 8 Nov 2006 19:16:55 +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 kA8IGt4Z017995; Wed, 8 Nov 2006 19:16:55 +0100 (MET) Received: from [10.82.216.87] (rtp-vpn3-87.cisco.com [10.82.216.87]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA08922; Wed, 8 Nov 2006 18:16:52 GMT Message-ID: <45521EF5.2020304@cisco.com> Date: Wed, 08 Nov 2006 18:16:21 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> In-Reply-To: <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=7885; t=1163009815; x=1163873815; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:; X=v=3Dcisco.com=3B=20h=3Dx9Fd5u0YJ7kArbQ3LVlXr5yVAhw=3D; b=GUqGdF60u+tdo6qK0EDOSSBAKiGMolCrB4YzOHVrdjgdIxZ3MoslavPaEgHqrfmazsMibCKz qSfGGIEE3CF76WTDH155OHyaC/v9lpu1oHKOKOGzi3IEPjhrcNZ8W/F5; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Brian Trammell wrote: > Indeed, the protocol does not allow Template Withdrawals other than in > their own Set (and these in their own Message). So, the minimum > allowable record length in a Set is then as follows: > > Template Set: IF Template Withdrawal, then 4 (TID + 0x0000); > otherwise 8 (TID + IE Count + IE 0 + Len 0) > > Options Template Set: IF Template Withdrawal, then 4 (TID + 0x0000); > otherwise 10 (TID + IE Count + Scope Count + IE 0 + Len 0) > > So the question now becomes "how does the Collecting Process determine > that a Template Set contains Template Withdrawals". Since the protocol > doesn't define a Set ID for template withdrawals (the Set ID MUST be 2 > to withdraw Templates or 3 to withdraw Options Templates), when reading > the first {Options} Template Set in a Message it must be assumed to > possibly contain a Template Withdrawal until the first Template Record > is read. If the protocol says that the withdrawals must be in their own message, them the decision can be made on the very first Set. I would recommend that on receiving a message, determining if it is a withdrawal message is one of the first actions to be taken. Can we have a message with both Template withdrawals and Option Template withdrawals or do they have to be sent separately? > This is actually not all that bad WRT requiring special case treatment > at the CP (and is certainly much more acceptable than my earlier > proposal). Padding will also work in this case (as padding is read at > the _end_ of the Template Set, after the first record is read). However, > as an implementor, I would still suggest that we note this is a bit > tricky in the implementation guidelines... I agree. regards Andrew > On Nov 8, 2006, at 12:42 AM, Andrew Johnson wrote: > >> Hi Brain >> >> It seems to me that the either the withdrawal message is either >> "allowable Record in this set" or it isn't. So does the fact >> that Template Withdrawal records can only appear in a set of >> other Withdrawal messages mean that it isn't an "allowable >> record"? >> >> 1. It is allowed: >> As you quote below "The padding length MUST be shorter than >> any allowable Record in this Set." If this is an allowable >> record then you can only pad 3 or less bytes, therefore your >> below message is illegal as it wants to pad 4 bytes. >> >> 2. It is not allowed: >> If it's a message that is not "allowable" then the padding >> is valid and the record should be correctly decoded by the >> collector. >> >> I think the spirit of the text is option 2. The collector >> should not be looking for withdrawal messages here. I agree >> that you've found a potentially sticky area, but I hope we >> can clarify the case one way or the other. >> >> >> Brian Trammell wrote: >>> All, >>> In ensuring last week that our own IPFIX implementation handles all >>> the vagaries of set padding properly, I found what I think is an >>> inconsistency in the protocol's handling of Template Set padding. The >>> issue is best illustrated by the question, "what does a Collecting >>> Process do with the following Template Set example?": >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 2 (Template Set) | Set Length = 32 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Template ID = 0xB701 | IE Count = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set padding to 8-byte boundary = 0 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> This is at first glance a valid template set, aligned to an 8-byte >>> boundary as suggested in "Padding" in sec. 3.3.1 of proto-23. However: >>> 1. The padding length MUST be shorter than any allowable Record in >>> this Set. ("Padding", sec. 3.3.1 of proto-23); and >>> 2. Template Withdrawal messages (sec 8 of proto-23) set the minimum >>> allowable Template Record length to 4 bytes (a Template ID followed >>> by an IE Count of 0). >>> So, if a Collecting Process were to follow the protocol (as I read it >>> presently) and note that the remainder of the set after the first >>> template was equal to the minimum Template Record length, it would >>> interpret it as follows: >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Set ID = 2 (Template Set) | Set Length = 32 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Template ID = 0xB701 | IE Count = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |1| IE 1 = 9 s.ActiveHostCount | IE 1 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | IE 1 PEN = 6871 (CERT Network Situational Awareness Group) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 2 = 44 s.IPv4Prefix | IE 2 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 3 = 9 s.IPv4PrefixLen. | IE 3 Length = 1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |0| IE 4 = 12 d.IPv4Address | IE 4 Length = 4 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Template ID = 0x0000 | IE Count = 0 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> which would be an illegal Template Withdraw record (as such records >>> can only appear in a message with other Template Withdraw records: >>> "The Template Withdraw Message MUST NOT contain new Template or >>> Options Template Records.", sec. 8 of proto-23) for an illegal >>> Template ID (Set ID 0x0000 is reserved from V9, sec. 12 para 2 of >>> proto-23; also RFC3954). So, any Template Set padded to an 8-byte >>> boundary would appear to be an illegal Set. >>> One solution would be to explicitly point out that any Template >>> Record which is a four-byte sequence of zeroes be interpreted as >>> padding, as a special case. In other words, a Collecting Process >>> would accept and ignore any Template Withdraw record for Template 0. >>> This solution would also imply that we would want to state that any >>> Options Template Record which is four-byte sequence of zeroes (a >>> Template Withdraw record as above) or a six-byte sequence of zeroes >>> (which would be patently illegal as an Options Template Record) be >>> interpreted as padding as well. >>> This does allow us to pad any type of set to 8-byte boundaries, but >>> has the disadvantage of mandating two extra special-case codepaths at >>> the CP side. Therefore, I'm a little conflicted about it as a >>> proposal. Thoughts? >>> Regards, >>> Brian >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 08 13:39:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsJy-0001hu-E4; Wed, 08 Nov 2006 13:38:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsJx-0001hX-43 for ipfix@ietf.org; Wed, 08 Nov 2006 13:38:45 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhsJv-00074W-Q1 for ipfix@ietf.org; Wed, 08 Nov 2006 13:38:45 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 19:38:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPuxUUWQ/uCLcmdsb2JhbACMSwEJDyo X-IronPort-AV: i="4.09,401,1157320800"; d="scan'208"; a="118193132:sNHT26151596" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA8Icgj3026408; Wed, 8 Nov 2006 19:38:42 +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 kA8Icg4Z015214; Wed, 8 Nov 2006 19:38:42 +0100 (MET) Received: from [10.21.97.73] (sjc-vpn1-329.cisco.com [10.21.97.73]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA11663; Wed, 8 Nov 2006 18:38:40 GMT Message-ID: <4552241E.8010100@cisco.com> Date: Wed, 08 Nov 2006 18:38:22 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> In-Reply-To: <45521EF5.2020304@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1163011123; x=1163875123; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:; X=v=3Dcisco.com=3B=20h=3DjPI6TgyVNupOWxLD1vgI/WuphZc=3D; b=DimGSgXSQ4MG4eObhmyLt8FEM8EJiRVF4fcJDOnAzww7p+X21Trv52xjY9CSEVvOjbvOssB/ bOq1WO8Bc1ovJGgdObp1O6MnaCBZK+UzOYkvSavPGlyZ7Z5TG9KFKnQV; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, > If the protocol says that the withdrawals must be in their own message, > them the decision can be made on the very first Set. I would recommend > that on receiving a message, determining if it is a withdrawal message is > one of the first actions to be taken. I agree. > Can we have a message with both Template withdrawals and Option Template > withdrawals I don't see why not. > or do they have to be sent separately? Is there any need for that? Actually, it seems to me that "Template Withdrawal Message" is a misnomer: it's really a Template Withdrawal *Set*, and what's important is that you don't try to define new templates in the same set - else you might end up in the situation Brian described earlier. I don't see a problem with sending both Template withdrawals and Option Template withdrawals as two sets in the same IPFIX message, nor with sending a mixture of templates and withdrawals in different sets in the same message. I think it'd be a lot clearer if the "Template Withdrawal Message" was renamed to "Template Withdrawal Set" and this text: The Template Withdraw Message MUST NOT contain new Template or Options Template Records. was changed to: The Template Withdraw Set MUST NOT contain new Template or Options Template Records. >> However, as an implementor, I would still suggest that we note this is >> a bit tricky in the implementation guidelines... > > I agree. Seconded. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Wed Nov 08 13:39:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsJy-0001hu-E4; Wed, 08 Nov 2006 13:38:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsJx-0001hX-43 for ipfix@ietf.org; Wed, 08 Nov 2006 13:38:45 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhsJv-00074W-Q1 for ipfix@ietf.org; Wed, 08 Nov 2006 13:38:45 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 19:38:44 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPuxUUWQ/uCLcmdsb2JhbACMSwEJDyo X-IronPort-AV: i="4.09,401,1157320800"; d="scan'208"; a="118193132:sNHT26151596" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA8Icgj3026408; Wed, 8 Nov 2006 19:38:42 +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 kA8Icg4Z015214; Wed, 8 Nov 2006 19:38:42 +0100 (MET) Received: from [10.21.97.73] (sjc-vpn1-329.cisco.com [10.21.97.73]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA11663; Wed, 8 Nov 2006 18:38:40 GMT Message-ID: <4552241E.8010100@cisco.com> Date: Wed, 08 Nov 2006 18:38:22 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> In-Reply-To: <45521EF5.2020304@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1561; t=1163011123; x=1163875123; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:Paul=20Aitken=20 |Subject:Re=3A=20[IPFIX]=20Fwd=3A=20Template=20Set=20padding=20issue |Sender:; X=v=3Dcisco.com=3B=20h=3DjPI6TgyVNupOWxLD1vgI/WuphZc=3D; b=DimGSgXSQ4MG4eObhmyLt8FEM8EJiRVF4fcJDOnAzww7p+X21Trv52xjY9CSEVvOjbvOssB/ bOq1WO8Bc1ovJGgdObp1O6MnaCBZK+UzOYkvSavPGlyZ7Z5TG9KFKnQV; Authentication-Results: ams-dkim-2; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, > If the protocol says that the withdrawals must be in their own message, > them the decision can be made on the very first Set. I would recommend > that on receiving a message, determining if it is a withdrawal message is > one of the first actions to be taken. I agree. > Can we have a message with both Template withdrawals and Option Template > withdrawals I don't see why not. > or do they have to be sent separately? Is there any need for that? Actually, it seems to me that "Template Withdrawal Message" is a misnomer: it's really a Template Withdrawal *Set*, and what's important is that you don't try to define new templates in the same set - else you might end up in the situation Brian described earlier. I don't see a problem with sending both Template withdrawals and Option Template withdrawals as two sets in the same IPFIX message, nor with sending a mixture of templates and withdrawals in different sets in the same message. I think it'd be a lot clearer if the "Template Withdrawal Message" was renamed to "Template Withdrawal Set" and this text: The Template Withdraw Message MUST NOT contain new Template or Options Template Records. was changed to: The Template Withdraw Set MUST NOT contain new Template or Options Template Records. >> However, as an implementor, I would still suggest that we note this is >> a bit tricky in the implementation guidelines... > > I agree. Seconded. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 09 00:24:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2NC-00070f-ST; Thu, 09 Nov 2006 00:22:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2NC-00070a-4d for ipfix@ietf.org; Thu, 09 Nov 2006 00:22:46 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi2NA-0000XG-OO for ipfix@ietf.org; Thu, 09 Nov 2006 00:22:46 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kA95Mhh27654; Thu, 9 Nov 2006 06:22:43 +0100 (CET) Received: from [10.21.82.22] (sjc-vpn4-534.cisco.com [10.21.82.22]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kA95MYP11656; Thu, 9 Nov 2006 06:22:35 +0100 (CET) Message-ID: <4552BB1A.30108@cisco.com> Date: Wed, 08 Nov 2006 21:22:34 -0800 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <113091BD57179D4491C19DA7E10CD696645FCC@mx1.office> <455203F2.704@cisco.com> In-Reply-To: <455203F2.704@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi, > Thomas Dietz wrote: > >> If I am not mistaken here, you cannot mix templates with withdraw >> templates. > > Thomas is right: the fourth paragrah under Figure T in IPFIX-PROTO says: > > The Template Withdraw Message MUST NOT contain new Template or > Options Template Records. On the top of that, the Template Id must >255. So not zero. Regards, Benoit. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 09 00:24:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2NC-00070f-ST; Thu, 09 Nov 2006 00:22:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2NC-00070a-4d for ipfix@ietf.org; Thu, 09 Nov 2006 00:22:46 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi2NA-0000XG-OO for ipfix@ietf.org; Thu, 09 Nov 2006 00:22:46 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kA95Mhh27654; Thu, 9 Nov 2006 06:22:43 +0100 (CET) Received: from [10.21.82.22] (sjc-vpn4-534.cisco.com [10.21.82.22]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id kA95MYP11656; Thu, 9 Nov 2006 06:22:35 +0100 (CET) Message-ID: <4552BB1A.30108@cisco.com> Date: Wed, 08 Nov 2006 21:22:34 -0800 From: Benoit Claise User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Paul Aitken Subject: Re: [IPFIX] Fwd: Template Set padding issue References: <113091BD57179D4491C19DA7E10CD696645FCC@mx1.office> <455203F2.704@cisco.com> In-Reply-To: <455203F2.704@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi, > Thomas Dietz wrote: > >> If I am not mistaken here, you cannot mix templates with withdraw >> templates. > > Thomas is right: the fourth paragrah under Figure T in IPFIX-PROTO says: > > The Template Withdraw Message MUST NOT contain new Template or > Options Template Records. On the top of that, the Template Id must >255. So not zero. Regards, Benoit. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 09 00:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2i4-0008Ny-6a; Thu, 09 Nov 2006 00:44:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2i2-0008Nl-On for ipfix@ietf.org; Thu, 09 Nov 2006 00:44:18 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi2hz-00043v-HC for ipfix@ietf.org; Thu, 09 Nov 2006 00:44:18 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kA95i9re027417 for ; Thu, 9 Nov 2006 00:44:09 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kA95h4NM027379 for ; Thu, 9 Nov 2006 00:43:04 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kA95h4E3027377; Thu, 09 Nov 2006 00:43:04 -0500 (EST) Received: from [12.105.247.21] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id kA95gv4f032198; Thu, 9 Nov 2006 00:43:01 -0500 In-Reply-To: <4552241E.8010100@cisco.com> References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue Date: Wed, 8 Nov 2006 21:42:18 -0800 To: Paul Aitken , Benoit Claise X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Nov 8, 2006, at 10:38 AM, Paul Aitken wrote: > Actually, it seems to me that "Template Withdrawal Message" is a > misnomer: it's really a Template Withdrawal *Set*, and what's > important is that you don't try to define new templates in the same > set - else you might end up in the situation Brian described earlier. > > I don't see a problem with sending both Template withdrawals and > Option Template withdrawals as two sets in the same IPFIX message, > nor with sending a mixture of templates and withdrawals in > different sets in the same message. > > I think it'd be a lot clearer if the "Template Withdrawal Message" > was renamed to "Template Withdrawal Set" and this text: > > The Template Withdraw Message MUST NOT contain new Template or > Options Template Records. > > was changed to: > > The Template Withdraw Set MUST NOT contain new Template or > Options Template Records. Absolutely. Benoit: are we at a state with the protocol now (sorry!) that we could make this change? - Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 09 00:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2i4-0008Ny-6a; Thu, 09 Nov 2006 00:44:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi2i2-0008Nl-On for ipfix@ietf.org; Thu, 09 Nov 2006 00:44:18 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gi2hz-00043v-HC for ipfix@ietf.org; Thu, 09 Nov 2006 00:44:18 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kA95i9re027417 for ; Thu, 9 Nov 2006 00:44:09 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kA95h4NM027379 for ; Thu, 9 Nov 2006 00:43:04 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kA95h4E3027377; Thu, 09 Nov 2006 00:43:04 -0500 (EST) Received: from [12.105.247.21] (vpn-10-25-4-11.remote.cert.org [10.25.4.11]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id kA95gv4f032198; Thu, 9 Nov 2006 00:43:01 -0500 In-Reply-To: <4552241E.8010100@cisco.com> References: <04451D7C-DB5E-416A-9254-A01891D69C14@cert.org> <45519870.5010404@cisco.com> <67A49DC0-8809-4A58-B86E-A4F2373E4C12@cert.org> <45521EF5.2020304@cisco.com> <4552241E.8010100@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] Fwd: Template Set padding issue Date: Wed, 8 Nov 2006 21:42:18 -0800 To: Paul Aitken , Benoit Claise X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org On Nov 8, 2006, at 10:38 AM, Paul Aitken wrote: > Actually, it seems to me that "Template Withdrawal Message" is a > misnomer: it's really a Template Withdrawal *Set*, and what's > important is that you don't try to define new templates in the same > set - else you might end up in the situation Brian described earlier. > > I don't see a problem with sending both Template withdrawals and > Option Template withdrawals as two sets in the same IPFIX message, > nor with sending a mixture of templates and withdrawals in > different sets in the same message. > > I think it'd be a lot clearer if the "Template Withdrawal Message" > was renamed to "Template Withdrawal Set" and this text: > > The Template Withdraw Message MUST NOT contain new Template or > Options Template Records. > > was changed to: > > The Template Withdraw Set MUST NOT contain new Template or > Options Template Records. Absolutely. Benoit: are we at a state with the protocol now (sorry!) that we could make this change? - Brian _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From yumi_pohhonda@yahoo.co.jp Thu Nov 09 11:36:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCtE-0001JZ-H8 for ipfix-archive@megatron.ietf.org; Thu, 09 Nov 2006 11:36:32 -0500 Received: from [58.61.153.66] (helo=pc45) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiCtC-0004iM-Nj for ipfix-archive@megatron.ietf.org; Thu, 09 Nov 2006 11:36:32 -0500 To: From: =?iso-2022-jp?B?GyRCSC85VDxUISFDZkI8ISFNM0h+O1IbKEI=?= Subject: =?iso-2022-jp?B?GyRCJD0kJiQkJCgkUBsoQig7GyRCIS0iJiEuGyhCQWBg?= MIME-Version: 1.0 Reply-To: Date: Thu, 09 Nov 2006 22:05:13 +0900 Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 $B$=$&$$$($P!"?&6H!'2qA0$G=P$F$-$^$9$h!*(B From ipfix-bounces@ietf.org Thu Nov 09 18:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJ3O-0003aN-3N; Thu, 09 Nov 2006 18:11:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJ3N-0003aC-7S for ipfix@ietf.org; Thu, 09 Nov 2006 18:11:25 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJ3M-000338-23 for ipfix@ietf.org; Thu, 09 Nov 2006 18:11:25 -0500 Received: from harrington73653 (dhcp71-105.ietf67.org[130.129.71.105]) by comcast.net (sccrmhc11) with SMTP id <2006110923112301100brk7ee>; Thu, 9 Nov 2006 23:11:23 +0000 From: "David Harrington" To: Date: Thu, 9 Nov 2006 15:08:50 -0800 Message-ID: <088901c70454$054b3f90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccETYGa5880ZmXWQ1ekVgJd9GncEwABiFhA X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [IPFIX] MIB work X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi, A have seen a numer of comments made in the WG that make me believe the ipfix WG could use a MIB advisor, to help design the MIB. A MIB Doctor can help you understand the pros and cons of different types of indexing strategies, when RowStatus and StorageType objects are useful, and strategies for defining different compliance levels. Contact Dan Romascanu, who can seek a volunteer to perform this service for the WG. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 09 18:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJ3O-0003aN-3N; Thu, 09 Nov 2006 18:11:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJ3N-0003aC-7S for ipfix@ietf.org; Thu, 09 Nov 2006 18:11:25 -0500 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJ3M-000338-23 for ipfix@ietf.org; Thu, 09 Nov 2006 18:11:25 -0500 Received: from harrington73653 (dhcp71-105.ietf67.org[130.129.71.105]) by comcast.net (sccrmhc11) with SMTP id <2006110923112301100brk7ee>; Thu, 9 Nov 2006 23:11:23 +0000 From: "David Harrington" To: Date: Thu, 9 Nov 2006 15:08:50 -0800 Message-ID: <088901c70454$054b3f90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccETYGa5880ZmXWQ1ekVgJd9GncEwABiFhA X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [IPFIX] MIB work X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi, A have seen a numer of comments made in the WG that make me believe the ipfix WG could use a MIB advisor, to help design the MIB. A MIB Doctor can help you understand the pros and cons of different types of indexing strategies, when RowStatus and StorageType objects are useful, and strategies for defining different compliance levels. Contact Dan Romascanu, who can seek a volunteer to perform this service for the WG. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 09 18:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJfZ-0003c5-SC; Thu, 09 Nov 2006 18:50:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJfG-0003NU-9a; Thu, 09 Nov 2006 18:50:34 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJfG-0007Zj-7C; Thu, 09 Nov 2006 18:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GiJfE-0004fG-Ua; Thu, 09 Nov 2006 18:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9CC5B175B4; Thu, 9 Nov 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GiJek-0004MO-7O; Thu, 09 Nov 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Nov 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-protocol-24.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Specification of the IPFIX Protocol for the Exchange Author(s) : B. Claise Filename : draft-ietf-ipfix-protocol-24.txt Pages : 64 Date : 2006-11-9 This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a number of transport protocols from an IPFIX exporting process to an IPFIX collecting process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-24.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-ipfix-protocol-24.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-ipfix-protocol-24.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: <2006-11-9162003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-protocol-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-protocol-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-9162003.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Thu Nov 09 18:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJfZ-0003c5-SC; Thu, 09 Nov 2006 18:50:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJfG-0003NU-9a; Thu, 09 Nov 2006 18:50:34 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJfG-0007Zj-7C; Thu, 09 Nov 2006 18:50:34 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GiJfE-0004fG-Ua; Thu, 09 Nov 2006 18:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9CC5B175B4; Thu, 9 Nov 2006 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GiJek-0004MO-7O; Thu, 09 Nov 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 09 Nov 2006 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-protocol-24.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Specification of the IPFIX Protocol for the Exchange Author(s) : B. Claise Filename : draft-ietf-ipfix-protocol-24.txt Pages : 64 Date : 2006-11-9 This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a number of transport protocols from an IPFIX exporting process to an IPFIX collecting process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-24.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-ipfix-protocol-24.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-ipfix-protocol-24.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: <2006-11-9162003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-protocol-24.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-protocol-24.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-11-9162003.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --NextPart-- From ipfix-bounces@ietf.org Thu Nov 09 21:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiM6W-0005zs-94; Thu, 09 Nov 2006 21:26:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiM6V-0005zn-Q3 for ipfix@ietf.org; Thu, 09 Nov 2006 21:26:51 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiM6U-0002oB-H5 for ipfix@ietf.org; Thu, 09 Nov 2006 21:26:51 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3FCA320031E4; Fri, 10 Nov 2006 03:27:22 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n3-BKD-AwuO; Fri, 10 Nov 2006 03:27:22 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2AF2F20031DA; Fri, 10 Nov 2006 03:27:22 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Nov 2006 03:26:51 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD69610ADBB@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFIX IETF67 session summary Thread-Index: AccEb6367cWWusIfQ4GKVoX9KfnO5w== From: "Juergen Quittek" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [IPFIX] IPFIX IETF67 session summary X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org IPFIX IETF67 session summary All documents from the old charter have passed IETF last call and the IPFIX protocol already passed IESG evaluation. The IPFIX architecture still needs to resolve one DISCUSS issue from IESG evaluation. The information model and the applicability statement will enter IESG evaluation soon. For the five documents from the new charter, all have initial versions as planned except for the MIB module that is still and individual draft. Progress of these documents is slightly slower than planned. Only the redundancy draft is on schedule and will enter WGLC next week. The implementation guidelines and the IPFIX testing drafts are delayed, because they should also cover IPFIX protocol security for which the final solution was fixed just this week. For this and the draft on bidirectional flow reporting WGLC is no planned for January 2007. The MIB module needs further work. Particularly the writeability of objects needs further discussion. WGLC is expected after the Prague meeting. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 09 21:28:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiM6W-0005zs-94; Thu, 09 Nov 2006 21:26:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiM6V-0005zn-Q3 for ipfix@ietf.org; Thu, 09 Nov 2006 21:26:51 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiM6U-0002oB-H5 for ipfix@ietf.org; Thu, 09 Nov 2006 21:26:51 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3FCA320031E4; Fri, 10 Nov 2006 03:27:22 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n3-BKD-AwuO; Fri, 10 Nov 2006 03:27:22 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2AF2F20031DA; Fri, 10 Nov 2006 03:27:22 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Nov 2006 03:26:51 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD69610ADBB@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFIX IETF67 session summary Thread-Index: AccEb6367cWWusIfQ4GKVoX9KfnO5w== From: "Juergen Quittek" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [IPFIX] IPFIX IETF67 session summary X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org IPFIX IETF67 session summary All documents from the old charter have passed IETF last call and the IPFIX protocol already passed IESG evaluation. The IPFIX architecture still needs to resolve one DISCUSS issue from IESG evaluation. The information model and the applicability statement will enter IESG evaluation soon. For the five documents from the new charter, all have initial versions as planned except for the MIB module that is still and individual draft. Progress of these documents is slightly slower than planned. Only the redundancy draft is on schedule and will enter WGLC next week. The implementation guidelines and the IPFIX testing drafts are delayed, because they should also cover IPFIX protocol security for which the final solution was fixed just this week. For this and the draft on bidirectional flow reporting WGLC is no planned for January 2007. The MIB module needs further work. Particularly the writeability of objects needs further discussion. WGLC is expected after the Prague meeting. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From usagi_kirin@ocn.ne.jp Sat Nov 11 17:33:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj1Q9-0006Ba-3s for IPFIX-ARCHIVE@MEGATRON.IETF.ORG; Sat, 11 Nov 2006 17:33:53 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj1Q9-0005Ee-1g for IPFIX-ARCHIVE@MEGATRON.IETF.ORG; Sat, 11 Nov 2006 17:33:53 -0500 Received: from [221.203.85.179] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gj1Q4-0006cS-Sc for IPFIX-ARCHIVE@MEGATRON.IETF.ORG; Sat, 11 Nov 2006 17:33:52 -0500 Received: from herlkexzb4 (unknown [218.159.30.123]) by smtp67 (Coremail) with SMTP id 3mhT2AowMryi2U4x.1 for ; Sun, 12 Nov 2006 06:33:51 +0800 (CST) X-Originating-IP: [218.159.30.123] Subject: =?iso-2022-jp?B?GyRCTyJNbUBoOHgzKyJ2GyhC?= From: =?shift-jis?B?k0mP6oFAl0yXog==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0192_01C6F135.436D38F0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f This is a multi-part message in MIME format. ------=_NextPart_000_0192_01C6F135.436D38F0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit SEX$B$7$F$/$l$k=w@-$r3N
SEX=1B$B$7$F$/$l$k=3Dw@-$r3Nhttp://vqlh.com/?fs28
=1B$BA4$FL5NA$G;H$($k$N$G$*;n$72<$5$$=1B(B
=
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
/_/_/_/_/_/_/_/_/_/_/_/_/_/
=1B$B%a!<%kITMW=1B(B
ever_green_1313@yahoo.fr
/_/_/_/_/_/_/_/_/_/_/_/_/_/
 
 
------=_NextPart_000_0192_01C6F135.436D38F0-- From ipfix-bounces@ietf.org Mon Nov 13 14:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjhOd-0001gE-Ql; Mon, 13 Nov 2006 14:23:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjhOc-0001Wd-Cv for ipfix@ietf.org; Mon, 13 Nov 2006 14:23:06 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjhIk-0000Ga-0q for ipfix@ietf.org; Mon, 13 Nov 2006 14:17:04 -0500 Received: from [192.168.1.137] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3446713CF82 for ; Mon, 13 Nov 2006 20:19:47 +0100 (CET) Date: Mon, 13 Nov 2006 20:17:02 +0100 From: Juergen Quittek To: ipfix@ietf.org Message-ID: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, As agreed at the IPFIX session in San Diego last week this is the WG last call on the Internet draft on Reducing redundancy in IPFIX and PSAMP reports, draft-ietf-ipfix-reducing-redundancy-01.txt. The WG last call starts today and will be closed on December 1st. Please review the draft and send your comments! Please also send a message to the mailing list if you reviewed it and have no comment to make! Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 13 14:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjhOd-0001gE-Ql; Mon, 13 Nov 2006 14:23:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjhOc-0001Wd-Cv for ipfix@ietf.org; Mon, 13 Nov 2006 14:23:06 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjhIk-0000Ga-0q for ipfix@ietf.org; Mon, 13 Nov 2006 14:17:04 -0500 Received: from [192.168.1.137] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3446713CF82 for ; Mon, 13 Nov 2006 20:19:47 +0100 (CET) Date: Mon, 13 Nov 2006 20:17:02 +0100 From: Juergen Quittek To: ipfix@ietf.org Message-ID: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, As agreed at the IPFIX session in San Diego last week this is the WG last call on the Internet draft on Reducing redundancy in IPFIX and PSAMP reports, draft-ietf-ipfix-reducing-redundancy-01.txt. The WG last call starts today and will be closed on December 1st. Please review the draft and send your comments! Please also send a message to the mailing list if you reviewed it and have no comment to make! Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 16 11:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkTC-0007rY-3f; Thu, 16 Nov 2006 11:52:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkT9-0007rR-Ut for ipfix@ietf.org; Thu, 16 Nov 2006 11:52:07 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkkT7-0005Wh-LE for ipfix@ietf.org; Thu, 16 Nov 2006 11:52:07 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kAGGpxrQ017359 for ; Thu, 16 Nov 2006 11:52:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Nov 2006 18:51:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipfix-info-14 not approved by the IESG Thread-Index: AccJn4dUx1WG3ljCRUqIhsbOM1LyWg== From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [IPFIX] draft-ietf-ipfix-info-14 not approved by the IESG X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org As expected draft-ietf-ipfix-info-14.txt was not approved at its first pass in the IESG. There are five open DISCUSSes from the various ADs that need to be answered by the editors of the document and WG chairs. For the moment it goes into AD Follow-up state. The editors and the WG chairs need to work hard in the next few weeks to resolve the DISCUSSes. Dan _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 16 11:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkTC-0007rY-3f; Thu, 16 Nov 2006 11:52:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkT9-0007rR-Ut for ipfix@ietf.org; Thu, 16 Nov 2006 11:52:07 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkkT7-0005Wh-LE for ipfix@ietf.org; Thu, 16 Nov 2006 11:52:07 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kAGGpxrQ017359 for ; Thu, 16 Nov 2006 11:52:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Nov 2006 18:51:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipfix-info-14 not approved by the IESG Thread-Index: AccJn4dUx1WG3ljCRUqIhsbOM1LyWg== From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [IPFIX] draft-ietf-ipfix-info-14 not approved by the IESG X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org As expected draft-ietf-ipfix-info-14.txt was not approved at its first pass in the IESG. There are five open DISCUSSes from the various ADs that need to be answered by the editors of the document and WG chairs. For the moment it goes into AD Follow-up state. The editors and the WG chairs need to work hard in the next few weeks to resolve the DISCUSSes. Dan _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From afdecababffagb@castleduncan.com Thu Nov 16 12:32:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkl3n-00016C-GL for ipfix-archive@lists.ietf.org; Thu, 16 Nov 2006 12:29:59 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkkpl-0000cf-2w; Thu, 16 Nov 2006 12:15:29 -0500 Received: from [85.101.118.44] (helo=dsl.static8510111844.ttnet.net.tr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gkkpe-0001EJ-T6; Thu, 16 Nov 2006 12:15:26 -0500 Date: Thu, 16 Dec 2006 17:15:27 -0120 From: Bestwatches store X-Mailer: The Bat! (v2.11.02) CD5BF9353B3B7091 Reply-To: afdecababffagb X-Priority: 3 (Normal) Message-ID: <86433778.20061116171527@castleduncan.com> To: ipo-archive@lists.ietf.org Subject: Nice replica watches MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 4.4 (++++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
=20=

LUXURY CHRISTMAS GIFTS


Replica Watches, Handbags, Jewelry and More

We have everything you need to make someone's day complete, or=20= indulge yourself:

=95 Beautiful Handbags, Wallets and Accessories in Summer=20= Colors
=95 Sterling Silver Tiffany Bracelets let you Show off=20= Delicately
=95 Stylish Ink Pens for any Desk or Office
=95 Designer Neckties, made from the Finest Silks
=95 Rolex Watches will Last a Lifetime

Enjoy the best at a fraction of the cost.

Order Now=20= and SAVE 25% or Get Free Shipping!

fifteen--the boy gained=20= a wide knowledge of the condition of the countrycrowding close to the=20= pavement in front, left a comfortable space in themight be called a=20= comfortable and happy family existence. Buttonwoodpavement was of big,=20= round cobblestones, made bright and clean by theand because as a clerk=20= his duties necessitated his calling at otherwere not worth the paper=20= they were written on, and that others weredoor, and thin, white marble=20= trimmings outlining the front door and
From ipfix-bounces@ietf.org Fri Nov 17 00:53:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkwe8-0007tz-Il; Fri, 17 Nov 2006 00:52:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkwe7-0007tr-Ko for ipfix@ietf.org; Fri, 17 Nov 2006 00:52:15 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkwe5-0005wh-1h for ipfix@ietf.org; Fri, 17 Nov 2006 00:52:15 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kAH5pwW6017797 for ; Fri, 17 Nov 2006 00:52:06 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kAH5oA9p017751 for ; Fri, 17 Nov 2006 00:50:10 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kAH5o9iG017749; Fri, 17 Nov 2006 00:50:10 -0500 (EST) Received: from [10.117.0.35] (vpn-10-25-4-7.remote.cert.org [10.25.4.7]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id kAH5o8WE030101; Fri, 17 Nov 2006 00:50:08 -0500 In-Reply-To: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Fri, 17 Nov 2006 00:49:27 -0500 To: Juergen Quittek , Elisa Boschi , Lutz Mark , Benoit Claise X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org All, I reviewed the reducing redundancy draft. Looks good, other than a couple of minor general comments. First, we should keep this text parallel with some SCTP-related changes in the IPFIX protocol. Reliability in SCTP is selected per- message, not per-stream, as Randall Stewart pointed out in San Diego. So: 4.1.1 OLD: Common Properties MUST be exported via Data Records defined by an Option Template Record and MUST be sent only once with the reliable stream of PR-SCTP association or within the TCP connection. 4.1.1 NEW: Common Properties MUST be exported via Data Records defined by an Option Template Record. Like Template Records, they MUST be sent only once per SCTP association or TCP connection, and MUST be sent reliably via SCTP if SCTP is the transport protocol. 5.1 OLD: The Common Properties Flow Records MUST be sent on a reliable SCTP stream. 5.1 NEW: The Common Properties Flow Records MUST be sent reliably. Second, there appears to be some spurious mention of templates in section 7, presumably as the cpId management text evolved from template management text: 7 para 5 OLD: (i.e. a commonPropertiesID from the same Exporter Observation Domain with the same Template ID received on the SCTP association) 7 para 5 NEW: (i.e. a commonPropertiesID from the same Exporter Observation Domain received on the SCTP association) 7 para 7 OLD: If a Collecting Process receives a Common Properties Withdrawal message, the Collecting Process MUST delete the corresponding Common Properties associated with the specific SCTP association and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates. 7 para 7 NEW: If a Collecting Process receives a Common Properties Withdrawal message, the Collecting Process MUST delete the corresponding Common Properties associated with the specific SCTP association and specific Observation Domain. 7.1 para 3 OLD: The Collecting Process MUST NOT decode any further Data Records which are associated with the expired Common Properties. If a Common Property is refreshed with a Template Record that differs from the previous received Template Record, the Collecting Process SHOULD log a warning and replace the previous received Common Property with the new one. The Template lifetime at the Collecting Process MUST be at least 3 times higher than the Template refresh timeout configured on the Exporting Process. 7.1 para 3 NEW: The Collecting Process MUST NOT decode any further Data Records which are associated with the expired Common Properties. If a Common Property is refreshed with a definition that differs from the previous definition, the Collecting Process SHOULD log a warning and replace the previous received Common Property with the new one. The Common Property lifetime at the Collecting Process MUST be at least 3 times higher than the Common Property timeout configured on the Exporting Process. 7.1 para 4 OLD: The Collecting Process SHOULD accept Data Records without the associated Common Property(ies) required to decode the Data Record. If the Common Property(ies) have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Template Records (or other definitions) are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session. 7.1 para 4 NEW: The Collecting Process SHOULD accept Data Records without the associated Common Properties required to decode the Data Record. If the Common Properties have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Common Properties definitions are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session. Regards, Brian On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote: > Dear all, > > As agreed at the IPFIX session in San Diego last week > this is the WG last call on the Internet draft on > Reducing redundancy in IPFIX and PSAMP reports, > draft-ietf-ipfix-reducing-redundancy-01.txt. > > The WG last call starts today and will be closed on > December 1st. > > Please review the draft and send your comments! Please also > send a message to the mailing list if you reviewed it and > have no comment to make! > > Thanks, > > Juergen > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Nov 17 00:53:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkwe8-0007tz-Il; Fri, 17 Nov 2006 00:52:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkwe7-0007tr-Ko for ipfix@ietf.org; Fri, 17 Nov 2006 00:52:15 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkwe5-0005wh-1h for ipfix@ietf.org; Fri, 17 Nov 2006 00:52:15 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id kAH5pwW6017797 for ; Fri, 17 Nov 2006 00:52:06 -0500 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id kAH5oA9p017751 for ; Fri, 17 Nov 2006 00:50:10 -0500 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id kAH5o9iG017749; Fri, 17 Nov 2006 00:50:10 -0500 (EST) Received: from [10.117.0.35] (vpn-10-25-4-7.remote.cert.org [10.25.4.7]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.65) with ESMTP id kAH5o8WE030101; Fri, 17 Nov 2006 00:50:08 -0500 In-Reply-To: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Date: Fri, 17 Nov 2006 00:49:27 -0500 To: Juergen Quittek , Elisa Boschi , Lutz Mark , Benoit Claise X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org All, I reviewed the reducing redundancy draft. Looks good, other than a couple of minor general comments. First, we should keep this text parallel with some SCTP-related changes in the IPFIX protocol. Reliability in SCTP is selected per- message, not per-stream, as Randall Stewart pointed out in San Diego. So: 4.1.1 OLD: Common Properties MUST be exported via Data Records defined by an Option Template Record and MUST be sent only once with the reliable stream of PR-SCTP association or within the TCP connection. 4.1.1 NEW: Common Properties MUST be exported via Data Records defined by an Option Template Record. Like Template Records, they MUST be sent only once per SCTP association or TCP connection, and MUST be sent reliably via SCTP if SCTP is the transport protocol. 5.1 OLD: The Common Properties Flow Records MUST be sent on a reliable SCTP stream. 5.1 NEW: The Common Properties Flow Records MUST be sent reliably. Second, there appears to be some spurious mention of templates in section 7, presumably as the cpId management text evolved from template management text: 7 para 5 OLD: (i.e. a commonPropertiesID from the same Exporter Observation Domain with the same Template ID received on the SCTP association) 7 para 5 NEW: (i.e. a commonPropertiesID from the same Exporter Observation Domain received on the SCTP association) 7 para 7 OLD: If a Collecting Process receives a Common Properties Withdrawal message, the Collecting Process MUST delete the corresponding Common Properties associated with the specific SCTP association and specific Observation Domain, and stop decoding IPFIX Messages that use the withdrawn Templates. 7 para 7 NEW: If a Collecting Process receives a Common Properties Withdrawal message, the Collecting Process MUST delete the corresponding Common Properties associated with the specific SCTP association and specific Observation Domain. 7.1 para 3 OLD: The Collecting Process MUST NOT decode any further Data Records which are associated with the expired Common Properties. If a Common Property is refreshed with a Template Record that differs from the previous received Template Record, the Collecting Process SHOULD log a warning and replace the previous received Common Property with the new one. The Template lifetime at the Collecting Process MUST be at least 3 times higher than the Template refresh timeout configured on the Exporting Process. 7.1 para 3 NEW: The Collecting Process MUST NOT decode any further Data Records which are associated with the expired Common Properties. If a Common Property is refreshed with a definition that differs from the previous definition, the Collecting Process SHOULD log a warning and replace the previous received Common Property with the new one. The Common Property lifetime at the Collecting Process MUST be at least 3 times higher than the Common Property timeout configured on the Exporting Process. 7.1 para 4 OLD: The Collecting Process SHOULD accept Data Records without the associated Common Property(ies) required to decode the Data Record. If the Common Property(ies) have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Template Records (or other definitions) are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session. 7.1 para 4 NEW: The Collecting Process SHOULD accept Data Records without the associated Common Properties required to decode the Data Record. If the Common Properties have not been received at the time Data Records are received, the Collecting Process SHOULD store the Data Records for a short period of time and decode them after the Common Properties definitions are received. The short period of time MUST be lower than the lifetime of definitions associated with identifiers considered unique within the UDP session. Regards, Brian On Nov 13, 2006, at 2:17 PM, Juergen Quittek wrote: > Dear all, > > As agreed at the IPFIX session in San Diego last week > this is the WG last call on the Internet draft on > Reducing redundancy in IPFIX and PSAMP reports, > draft-ietf-ipfix-reducing-redundancy-01.txt. > > The WG last call starts today and will be closed on > December 1st. > > Please review the draft and send your comments! Please also > send a message to the mailing list if you reviewed it and > have no comment to make! > > Thanks, > > Juergen > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Nov 17 05:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl17s-0000gL-HS; Fri, 17 Nov 2006 05:39:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl17r-0000g9-Gd for ipfix@ietf.org; Fri, 17 Nov 2006 05:39:15 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl17o-0001Df-Q6 for ipfix@ietf.org; Fri, 17 Nov 2006 05:39:15 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 2D61A125 for ; Fri, 17 Nov 2006 11:39:05 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33826-03 for ; Fri, 17 Nov 2006 11:39:02 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3FD5511C for ; Fri, 17 Nov 2006 11:39:02 +0100 (MET) Message-ID: <455D917A.7020003@informatik.uni-tuebingen.de> Date: Fri, 17 Nov 2006 11:39:54 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> In-Reply-To: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------080102020100040902020907" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --------------080102020100040902020907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, Some meccorrections for draft-ietf-ipfix-reducing-redundancy-01: fig. 7: Shouldn't "index of properties A" be in front of "scrAddrA"? p. 18: it's =3D> it is etc... =3D> etc. p. 21: "In that case, for a flow of 1000 packets the amount of data can be decreased _by_ more than 33 percent" can't =3D> cannot p. 22: Somehow mark the notion of time in the table, e.g. with horizontal lines between distinct export instances? Or add timestamp fields. p. 23: Field Count =3D 3 ? Some comments on Section 8: The main advantage of the method specified in this document is the reduction in the amount of measurement data that has to be transferred from the Exporter to the Collector. I would like to add here "under some conditions" (or something similar) since the proposed method does not necessarily lead to a reduction of the amount of data. The transfer of the commonPropertiesIDs originates some overhead. Note that IPFIX allows reduced-size encoding of Information Elements. In cases where the range of the commonPropertiesID can be restricted, reduced-size encoding can be applied also to the commonPropertiesID, and would result in a further bandwidth efficiency gain. I would say: the overhead of the commonPropertiesID IE is very significant if 64 bit are used. The length of the commonPropertiesID field also gives you a necessary condition if you ever want to reach a reduced amount of data: The length must be shorter than the length of the replaced IEs, otherwise you even increase the amount monitoring data! As a consequence, reduced-size encoding should be used whenever possible. The example in section 11.2 below uses IPFIX to export measurement data for each received packet. In that case, for a flow of 1000 packets the amount of data can be decreased more than 33 percent. The example in 11.2 refers to OWD measurements, which is a very special application where the proposed method is very beneficial. Maybe you should mention "OWD measurements" here, since 33 percent may not be the general case. While the goal of this specification is to reduce the bandwidth, the efficiency might be limited. As I said before, you can even increase the amount of data with the proposed method. So I suggest to explain under which conditions the approach achieves its goal. How many times do I need to refer to the common properties until the amount of data is reduced for the first time? This should be a simple calculation. Even if this number cannot be predicted in advance in pratice, it might be useful to estimate when I should use the approach. Regards, Gerhard Juergen Quittek wrote: > Dear all, >=20 > As agreed at the IPFIX session in San Diego last week > this is the WG last call on the Internet draft on > Reducing redundancy in IPFIX and PSAMP reports, > draft-ietf-ipfix-reducing-redundancy-01.txt. >=20 > The WG last call starts today and will be closed on > December 1st. >=20 > Please review the draft and send your comments! Please also > send a message to the mailing list if you reviewed it and > have no comment to make! >=20 > Thanks, >=20 > Juergen >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------080102020100040902020907 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --------------080102020100040902020907-- From ipfix-bounces@ietf.org Fri Nov 17 05:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl17s-0000gL-HS; Fri, 17 Nov 2006 05:39:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl17r-0000g9-Gd for ipfix@ietf.org; Fri, 17 Nov 2006 05:39:15 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl17o-0001Df-Q6 for ipfix@ietf.org; Fri, 17 Nov 2006 05:39:15 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 2D61A125 for ; Fri, 17 Nov 2006 11:39:05 +0100 (MET) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33826-03 for ; Fri, 17 Nov 2006 11:39:02 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3FD5511C for ; Fri, 17 Nov 2006 11:39:02 +0100 (MET) Message-ID: <455D917A.7020003@informatik.uni-tuebingen.de> Date: Fri, 17 Nov 2006 11:39:54 +0100 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ipfix@ietf.org Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> In-Reply-To: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------080102020100040902020907" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org This is a multi-part message in MIME format. --------------080102020100040902020907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, Some meccorrections for draft-ietf-ipfix-reducing-redundancy-01: fig. 7: Shouldn't "index of properties A" be in front of "scrAddrA"? p. 18: it's =3D> it is etc... =3D> etc. p. 21: "In that case, for a flow of 1000 packets the amount of data can be decreased _by_ more than 33 percent" can't =3D> cannot p. 22: Somehow mark the notion of time in the table, e.g. with horizontal lines between distinct export instances? Or add timestamp fields. p. 23: Field Count =3D 3 ? Some comments on Section 8: The main advantage of the method specified in this document is the reduction in the amount of measurement data that has to be transferred from the Exporter to the Collector. I would like to add here "under some conditions" (or something similar) since the proposed method does not necessarily lead to a reduction of the amount of data. The transfer of the commonPropertiesIDs originates some overhead. Note that IPFIX allows reduced-size encoding of Information Elements. In cases where the range of the commonPropertiesID can be restricted, reduced-size encoding can be applied also to the commonPropertiesID, and would result in a further bandwidth efficiency gain. I would say: the overhead of the commonPropertiesID IE is very significant if 64 bit are used. The length of the commonPropertiesID field also gives you a necessary condition if you ever want to reach a reduced amount of data: The length must be shorter than the length of the replaced IEs, otherwise you even increase the amount monitoring data! As a consequence, reduced-size encoding should be used whenever possible. The example in section 11.2 below uses IPFIX to export measurement data for each received packet. In that case, for a flow of 1000 packets the amount of data can be decreased more than 33 percent. The example in 11.2 refers to OWD measurements, which is a very special application where the proposed method is very beneficial. Maybe you should mention "OWD measurements" here, since 33 percent may not be the general case. While the goal of this specification is to reduce the bandwidth, the efficiency might be limited. As I said before, you can even increase the amount of data with the proposed method. So I suggest to explain under which conditions the approach achieves its goal. How many times do I need to refer to the common properties until the amount of data is reduced for the first time? This should be a simple calculation. Even if this number cannot be predicted in advance in pratice, it might be useful to estimate when I should use the approach. Regards, Gerhard Juergen Quittek wrote: > Dear all, >=20 > As agreed at the IPFIX session in San Diego last week > this is the WG last call on the Internet draft on > Reducing redundancy in IPFIX and PSAMP reports, > draft-ietf-ipfix-reducing-redundancy-01.txt. >=20 > The WG last call starts today and will be closed on > December 1st. >=20 > Please review the draft and send your comments! Please also > send a message to the mailing list if you reviewed it and > have no comment to make! >=20 > Thanks, >=20 > Juergen >=20 >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www1.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Sand 13 (Room B309), D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 E-mail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------080102020100040902020907 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix --------------080102020100040902020907-- From ipfix-bounces@ietf.org Fri Nov 17 21:06:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlFZO-0000hA-BU; Fri, 17 Nov 2006 21:04:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlFZM-0000h4-Md for ipfix@ietf.org; Fri, 17 Nov 2006 21:04:36 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlFZJ-0006Rn-W5 for ipfix@ietf.org; Fri, 17 Nov 2006 21:04:36 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2006 03:04:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAI24Xcf006330; Sat, 18 Nov 2006 03:04:33 +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 kAI24Wwv016824; Sat, 18 Nov 2006 03:04:32 +0100 (MET) Received: from [10.61.81.190] (ams3-vpn-dhcp4543.cisco.com [10.61.81.190]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id CAA07153; Sat, 18 Nov 2006 02:04:32 GMT Message-ID: <455E6A11.2080209@cisco.com> Date: Sat, 18 Nov 2006 02:04:01 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> In-Reply-To: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9225; t=1163815473; x=1164679473; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=tRpOceFmafMhHQMWFuJUsV3uYKEeaKY1R1ie+WqyjhU=; b=pF61K4yMJgJrGA8rQxC571Fe/ijocec8WR6qN14LzSjOudUPBVe0+cvEf4osDYLekQ9OgaPx kcbH2PDqT8twUy3tcOhm+SxufoCvL6PRix2xBM/hyrnMMAJRD4AeFb+Z; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all I have reviewed the reducing redundancy document and I have the following comments and questions. I'm afraid I've got quite a lot to say so please ask about anything that isn't clear or you disagree with. regards Andrew Questions ========= a) As there are no enhancements or additions (after all, their just options) is this a proposed Informational RFC? b) If so, can MUST, SHOULD etc, be used outside of directly (or perhaps indirectly) quoting the standard? If there are references to PSAMP drafts, doesn't that block this from becoming an RFC until the PSAMP ones are RFCs? Do we have to mention PSAMP so much anyway, as it's just a specialised use case of IPFIX? Since a flow is defined as a group of packets that share a set of common properties, i.e. key fields, is there any danger that the commonPropertiesID will be wrongly assumed to refer to only the complete set of key fields? Is there any need to define a new term for "Specific Properties"? These are just part of a normal Data Record. For example: "... The rows are then referenced by the Specific Properties by using the appropriate value for the Common Properties identifier." could simply be: "... The rows are then referenced by Data Records by using the appropriate value for the Common Properties identifier." Are option withdrawal messages part of IPFIX? Are they meaningful in IPFIX? i.e. per the PROTO will an option with scope but no data be deemed invalidated by the Collector. Scope without data is the same as never having recieved the mapping in the first place. I think that it would be up to the implementation but it seems like a good idea so if we can't add it to the PROTO can we put it in the implementation guidelines? How do you propose to withdraw common properties when they are associated with a template rather than the Common Properties index? General Comments ================ I think, sections 3.1.2, 8.2 and 8.3 would be better grouped into a 3.2 Advanced Techniques section. I think 3.2 Per Packet Data Reduction, should be removed and any information that is not in section 3.1 should be added to to the PSAMP example. I think the the per-packet example is a good example of per flow reducing redundancy and section 11.1.1 can be removed. Labels for the figures would be better if they were centred. There is all sorts of extra spacing at the end of the lines. Specific Comments ================= 2. Terminology Tabbing is inconsistent in definition of "Selector": (i) the Packet Content; (ii) information derived from the packet's treatment at the Observation Point; (iii) any selection state that may be maintained by the Selection Process. 3.1.2 Multiple Data Reduction I don't think this section is explained very well. From my original email to Elisa and Lutz (18th Nov 2005): Andrew Johnson wrote: > Flows > ===== > Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes > Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes > Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes > Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes > > Options > ======= > flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 > flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 > > flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 > flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 This shows how 4 (2+2) options can be expanded to 4 combinations of Data Record to reduce redundancy without the need to define 4 complete sets of Common Properties and therefore not save any bandwidth. The more options you have the better this works. 20 options (10+10) would give you up to 100 possible pairs common properties. This isn't really made clear in the draft text, with only "flow1" having two indices. The example in 11.1.2 doesn't even have any! While I agree that using a template that doesn't include the cpID is a good idea to efficiently communicate flows with not so common properties, however I would call this an "Advanced Technique" to be listed in the section I proposed earlier. 3.2 Per Packet Data Reduction The text reads: If filtering is applied to select a series of packets, using the PSAMP specifications to export per-packet information might be relatively inefficient if the filtered fields (the common attributes) are exported in every single record. However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO it is explained how the filter information MUST be sent. This is designed so that the selector ID will match the one from the Data Record (via the selectionSequenceId) and perform exactly the function that is being proposed here for the commonPropertiesId. 4. Specifications for bandwidth saving information export What is being specified here that isn't true for ALL options as described in IPFIX-PROTO? I think section 3 does a better job of explaining how all this works. I'm really not sure what section 4 adds. (Aside: figure 9 refers to Common Sroperties). 6. commonPropertiesID Management The text reads: The commonPropertiesID values MAY be assigned sequentially, but it�s It seems the "it's" is using an invalid character rather than an apostrophe. 7. The Collecting Process Side The text reads: Like TemplateIDs the commonPropertiesIDs are generated dynamically by the Exporting Process. Hence a restart of the Exporting Process may imply a renumbering of commonProperiesIDs. The collector can't know if the Exporter Process restarted, this is why we rescoped the commonPropertiesID to the Transport Session, so the above text is now redundant. The text reads: Common Properties IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a common Properties ID which has already been received but which has not previously been withdrawn (i.e. a commonPropertiesID from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shutdown the association. and: If the Collecting Process receives a Common Properties Withdrawal message for a Common Properties that it has not received before on this SCTP assocation, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages. I think this might go against IPFIX-PROTO. The text reads: If the Common Properties are not refreshed before that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In which case, an alarm MUST be logged. What happened to storing it until the option turned up. Furthermore you shouldn't dictate the the record is discarded, just because you can't tell a piece of potentially trivial information about a flow doesn't mean it's meaningless. The Common Properties in question could be anything. Besides, we're not changing the protocol here, right? 8.1 Transport Protocol Choice The text reads: The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore the use of SCTP or TCP is recommended. Note that SCTP isn't necessarily reliable. 8.3 commonPropertiesID vs. TemplateID scope Additional flow properties can be tied to almost any I.E. For example a particular interface could be associated with the one IP address it serves. 8.4 Efficiency Gain The text reads: "...it can�t predict whether future..." Weird apostrophe character again. Examples: 1. There is no padding between records, it's against IPFIX-PROTO, unless you use the special padding I.E. 2. The templates define the counts as 4 octets but the records show them as 2. 3. Since 11.1.1 and 11.2 don't demonstrate anything different, can we have just one example? 4. The tabbing is sometimes a little of on the run though of the I.E.s, and I think we can loose the commas. e.g. OLD - the source IPv4 Address, sourceIPv4Address [IPFIX-INFO], with a type of 8 and a length of 4 octets NEW - the source IPv4 Address: sourceIPv4Address [IPFIX-INFO] with a type of 8 and a length of 4 octets 5. What is a packet ID anyway? In general PSAMP uses sampling to gather detailed information about a small proportion of the network traffic. In most cases there won't be many common factors between the reports. The real exception is hash-based filtering, which is what I think the example uses. 6. Do we have to use enterprise specific things here? What about: observationTimeMilliseconds (323), digestHashValue (326), ipTotalLength (224) _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Fri Nov 17 21:06:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlFZO-0000hA-BU; Fri, 17 Nov 2006 21:04:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlFZM-0000h4-Md for ipfix@ietf.org; Fri, 17 Nov 2006 21:04:36 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlFZJ-0006Rn-W5 for ipfix@ietf.org; Fri, 17 Nov 2006 21:04:36 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2006 03:04:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAI24Xcf006330; Sat, 18 Nov 2006 03:04:33 +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 kAI24Wwv016824; Sat, 18 Nov 2006 03:04:32 +0100 (MET) Received: from [10.61.81.190] (ams3-vpn-dhcp4543.cisco.com [10.61.81.190]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id CAA07153; Sat, 18 Nov 2006 02:04:32 GMT Message-ID: <455E6A11.2080209@cisco.com> Date: Sat, 18 Nov 2006 02:04:01 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> In-Reply-To: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9225; t=1163815473; x=1164679473; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=tRpOceFmafMhHQMWFuJUsV3uYKEeaKY1R1ie+WqyjhU=; b=pF61K4yMJgJrGA8rQxC571Fe/ijocec8WR6qN14LzSjOudUPBVe0+cvEf4osDYLekQ9OgaPx kcbH2PDqT8twUy3tcOhm+SxufoCvL6PRix2xBM/hyrnMMAJRD4AeFb+Z; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi all I have reviewed the reducing redundancy document and I have the following comments and questions. I'm afraid I've got quite a lot to say so please ask about anything that isn't clear or you disagree with. regards Andrew Questions ========= a) As there are no enhancements or additions (after all, their just options) is this a proposed Informational RFC? b) If so, can MUST, SHOULD etc, be used outside of directly (or perhaps indirectly) quoting the standard? If there are references to PSAMP drafts, doesn't that block this from becoming an RFC until the PSAMP ones are RFCs? Do we have to mention PSAMP so much anyway, as it's just a specialised use case of IPFIX? Since a flow is defined as a group of packets that share a set of common properties, i.e. key fields, is there any danger that the commonPropertiesID will be wrongly assumed to refer to only the complete set of key fields? Is there any need to define a new term for "Specific Properties"? These are just part of a normal Data Record. For example: "... The rows are then referenced by the Specific Properties by using the appropriate value for the Common Properties identifier." could simply be: "... The rows are then referenced by Data Records by using the appropriate value for the Common Properties identifier." Are option withdrawal messages part of IPFIX? Are they meaningful in IPFIX? i.e. per the PROTO will an option with scope but no data be deemed invalidated by the Collector. Scope without data is the same as never having recieved the mapping in the first place. I think that it would be up to the implementation but it seems like a good idea so if we can't add it to the PROTO can we put it in the implementation guidelines? How do you propose to withdraw common properties when they are associated with a template rather than the Common Properties index? General Comments ================ I think, sections 3.1.2, 8.2 and 8.3 would be better grouped into a 3.2 Advanced Techniques section. I think 3.2 Per Packet Data Reduction, should be removed and any information that is not in section 3.1 should be added to to the PSAMP example. I think the the per-packet example is a good example of per flow reducing redundancy and section 11.1.1 can be removed. Labels for the figures would be better if they were centred. There is all sorts of extra spacing at the end of the lines. Specific Comments ================= 2. Terminology Tabbing is inconsistent in definition of "Selector": (i) the Packet Content; (ii) information derived from the packet's treatment at the Observation Point; (iii) any selection state that may be maintained by the Selection Process. 3.1.2 Multiple Data Reduction I don't think this section is explained very well. From my original email to Elisa and Lutz (18th Nov 2005): Andrew Johnson wrote: > Flows > ===== > Flow A: flowId 1, flowId 11, 30 packets, 6000 bytes > Flow B: flowID 1, flowId 12, 50 packets, 9500 bytes > Flow C: flowId 2, flowId 11, 60 packets, 8000 bytes > Flow D: flowID 2, flowId 12, 10 packets, 1500 bytes > > Options > ======= > flowId 1 - destinationIpv4address 10.0.0.1, destinationTcpPort 80 > flowId 1 - destinationIpv4address 10.0.0.5, destinationTcpPort 80 > > flowId 11 - sourceIpv4address 10.0.1.10, sourceTcpPort 1932 > flowId 12 - sourceIpv4address 10.0.1.15, sourceTcpPort 1842 This shows how 4 (2+2) options can be expanded to 4 combinations of Data Record to reduce redundancy without the need to define 4 complete sets of Common Properties and therefore not save any bandwidth. The more options you have the better this works. 20 options (10+10) would give you up to 100 possible pairs common properties. This isn't really made clear in the draft text, with only "flow1" having two indices. The example in 11.1.2 doesn't even have any! While I agree that using a template that doesn't include the cpID is a good idea to efficiently communicate flows with not so common properties, however I would call this an "Advanced Technique" to be listed in the section I proposed earlier. 3.2 Per Packet Data Reduction The text reads: If filtering is applied to select a series of packets, using the PSAMP specifications to export per-packet information might be relatively inefficient if the filtered fields (the common attributes) are exported in every single record. However in section 6.5.2.5 (Property Match Filtering) of PSAMP-PROTO it is explained how the filter information MUST be sent. This is designed so that the selector ID will match the one from the Data Record (via the selectionSequenceId) and perform exactly the function that is being proposed here for the commonPropertiesId. 4. Specifications for bandwidth saving information export What is being specified here that isn't true for ALL options as described in IPFIX-PROTO? I think section 3 does a better job of explaining how all this works. I'm really not sure what section 4 adds. (Aside: figure 9 refers to Common Sroperties). 6. commonPropertiesID Management The text reads: The commonPropertiesID values MAY be assigned sequentially, but it�s It seems the "it's" is using an invalid character rather than an apostrophe. 7. The Collecting Process Side The text reads: Like TemplateIDs the commonPropertiesIDs are generated dynamically by the Exporting Process. Hence a restart of the Exporting Process may imply a renumbering of commonProperiesIDs. The collector can't know if the Exporter Process restarted, this is why we rescoped the commonPropertiesID to the Transport Session, so the above text is now redundant. The text reads: Common Properties IDs are unique per SCTP association and per Observation Domain. If the Collecting Process receives a common Properties ID which has already been received but which has not previously been withdrawn (i.e. a commonPropertiesID from the same Exporter Observation Domain with the same Template ID received on the SCTP association), then the Collecting Process MUST shutdown the association. and: If the Collecting Process receives a Common Properties Withdrawal message for a Common Properties that it has not received before on this SCTP assocation, it MUST reset the SCTP association, discard the IPFIX Message, and SHOULD log the error as it does for malformed IPFIX Messages. I think this might go against IPFIX-PROTO. The text reads: If the Common Properties are not refreshed before that lifetime has expired, the Collecting Process MUST discard the corresponding definition of the commonPropertiesID and any current and future associated Data Records. In which case, an alarm MUST be logged. What happened to storing it until the option turned up. Furthermore you shouldn't dictate the the record is discarded, just because you can't tell a piece of potentially trivial information about a flow doesn't mean it's meaningless. The Common Properties in question could be anything. Besides, we're not changing the protocol here, right? 8.1 Transport Protocol Choice The text reads: The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties. Therefore the use of SCTP or TCP is recommended. Note that SCTP isn't necessarily reliable. 8.3 commonPropertiesID vs. TemplateID scope Additional flow properties can be tied to almost any I.E. For example a particular interface could be associated with the one IP address it serves. 8.4 Efficiency Gain The text reads: "...it can�t predict whether future..." Weird apostrophe character again. Examples: 1. There is no padding between records, it's against IPFIX-PROTO, unless you use the special padding I.E. 2. The templates define the counts as 4 octets but the records show them as 2. 3. Since 11.1.1 and 11.2 don't demonstrate anything different, can we have just one example? 4. The tabbing is sometimes a little of on the run though of the I.E.s, and I think we can loose the commas. e.g. OLD - the source IPv4 Address, sourceIPv4Address [IPFIX-INFO], with a type of 8 and a length of 4 octets NEW - the source IPv4 Address: sourceIPv4Address [IPFIX-INFO] with a type of 8 and a length of 4 octets 5. What is a packet ID anyway? In general PSAMP uses sampling to gather detailed information about a small proportion of the network traffic. In most cases there won't be many common factors between the reports. The real exception is hash-based filtering, which is what I think the example uses. 6. Do we have to use enterprise specific things here? What about: observationTimeMilliseconds (323), digestHashValue (326), ipTotalLength (224) _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Nov 18 06:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlOfw-0000Pc-DY; Sat, 18 Nov 2006 06:48:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlOft-0000PV-IZ for ipfix@ietf.org; Sat, 18 Nov 2006 06:47:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlOfs-0004a2-8S for ipfix@ietf.org; Sat, 18 Nov 2006 06:47:57 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2006 12:47:49 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAIBlnbw010426; Sat, 18 Nov 2006 12:47:49 +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 kAIBlmwv024106; Sat, 18 Nov 2006 12:47:48 +0100 (MET) Received: from [10.61.81.190] (ams3-vpn-dhcp4543.cisco.com [10.61.81.190]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA05167; Sat, 18 Nov 2006 11:47:47 GMT Message-ID: <455EF2C5.9040101@cisco.com> Date: Sat, 18 Nov 2006 11:47:17 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Elisa Boschi , Lutz Mark , Benoit Claise Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=999; t=1163850469; x=1164714469; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=S+eCg2XuLaut6MB5hNtT/dMRA2LH6Lt0vjCkw+dFz5M=; b=L58RRd62erLXUNSx8HJOieei2lSMgQEagvQhAmSLa4Dg3oHifoujDDlWc4Q5xiJLN1Xnjjde dz+hrZPvkw7fTDAi3vURl66e0DiSbBmX4+5YZFZKyiNbZ0r6xnSWQHaO; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipfix@ietf.org Subject: [IPFIX] An advanced for Reducing Redundancy X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hello Elisa, Lutz and Benoit While reviewing the Reducing Redundancy draft I had a thought about an "Advanced Technique" that may be worth mentioning in your draft. If one were to define several templates, with different lengths of cpId in each, then for cpIds 0 to 255 you could save a byte or two over templates with a larger cpID. I would expect in many cases certain Common Properties will be more common than others, so an intelligent Exporting Process may be able to ensure the more common of the Common Property sets are had lower indices to save the most bytes. One more that might be a bit obtuse. The technique for defining separate cpIds for source and destination Common Properties is mentioned in the draft. For common combinations a third category of cpId could be used which maps to two other cpIds. i.e.: cpID C -> cpID A + cpID B cpID A -> source address A, source port A cpID B -> destination address B, source port B regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Nov 18 06:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlOfw-0000Pc-DY; Sat, 18 Nov 2006 06:48:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlOft-0000PV-IZ for ipfix@ietf.org; Sat, 18 Nov 2006 06:47:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlOfs-0004a2-8S for ipfix@ietf.org; Sat, 18 Nov 2006 06:47:57 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2006 12:47:49 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAIBlnbw010426; Sat, 18 Nov 2006 12:47:49 +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 kAIBlmwv024106; Sat, 18 Nov 2006 12:47:48 +0100 (MET) Received: from [10.61.81.190] (ams3-vpn-dhcp4543.cisco.com [10.61.81.190]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA05167; Sat, 18 Nov 2006 11:47:47 GMT Message-ID: <455EF2C5.9040101@cisco.com> Date: Sat, 18 Nov 2006 11:47:17 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Elisa Boschi , Lutz Mark , Benoit Claise Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=999; t=1163850469; x=1164714469; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=S+eCg2XuLaut6MB5hNtT/dMRA2LH6Lt0vjCkw+dFz5M=; b=L58RRd62erLXUNSx8HJOieei2lSMgQEagvQhAmSLa4Dg3oHifoujDDlWc4Q5xiJLN1Xnjjde dz+hrZPvkw7fTDAi3vURl66e0DiSbBmX4+5YZFZKyiNbZ0r6xnSWQHaO; Authentication-Results: ams-dkim-1; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipfix@ietf.org Subject: [IPFIX] An advanced for Reducing Redundancy X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hello Elisa, Lutz and Benoit While reviewing the Reducing Redundancy draft I had a thought about an "Advanced Technique" that may be worth mentioning in your draft. If one were to define several templates, with different lengths of cpId in each, then for cpIds 0 to 255 you could save a byte or two over templates with a larger cpID. I would expect in many cases certain Common Properties will be more common than others, so an intelligent Exporting Process may be able to ensure the more common of the Common Property sets are had lower indices to save the most bytes. One more that might be a bit obtuse. The technique for defining separate cpIds for source and destination Common Properties is mentioned in the draft. For common combinations a third category of cpId could be used which maps to two other cpIds. i.e.: cpID C -> cpID A + cpID B cpID A -> source address A, source port A cpID B -> destination address B, source port B regards Andrew _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Nov 18 07:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlPPJ-0003JB-5V; Sat, 18 Nov 2006 07:34:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlPPI-0003J6-JF for ipfix@ietf.org; Sat, 18 Nov 2006 07:34:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlPPG-0001Fg-9W for ipfix@ietf.org; Sat, 18 Nov 2006 07:34:52 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2006 13:34:49 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAICYniH023610; Sat, 18 Nov 2006 13:34:49 +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 kAICYnwv009205; Sat, 18 Nov 2006 13:34:49 +0100 (MET) Received: from [10.61.64.34] (ams3-vpn-dhcp34.cisco.com [10.61.64.34]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA06884; Sat, 18 Nov 2006 12:34:48 GMT Message-ID: <455EFDD4.9000800@cisco.com> Date: Sat, 18 Nov 2006 12:34:28 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <455EF2C5.9040101@cisco.com> In-Reply-To: <455EF2C5.9040101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=817; t=1163853289; x=1164717289; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=3sEAQgfkqYhJeejtQeKV2evK2GWUfixHOe8Mm4eRsok=; b=qUfTSS2EtQCYH8GUDc1G3J2fE6WZuArsDt48ZcsboUFwkNAjVdYzWoqlIw2i4srWNF+TvOY4 PlBAGGbOYGT/nzqdo4cmqInyLW02LDIT55dBRl07s66jZWznUM8XyKZD; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, > One more that might be a bit obtuse. The technique for > defining separate cpIds for source and destination Common > Properties is mentioned in the draft. For common combinations > a third category of cpId could be used which maps to two other > cpIds. > > i.e.: > cpID C -> cpID A + cpID B > cpID A -> source address A, source port A > cpID B -> destination address B, source port B Which raises the question of what duplicate cpID means, eg: cpID D -> cpID C + cpID A Also, we need to be careful to avoid circular definitions, eg: cpID E -> cpID F [ + cpID ... ] cpID F -> cpID E [ + cpID ... ] Probably an exporter SHOULD NOT send these, and a collector MUST detect and discard them, and log. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Nov 18 07:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlPPJ-0003JB-5V; Sat, 18 Nov 2006 07:34:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlPPI-0003J6-JF for ipfix@ietf.org; Sat, 18 Nov 2006 07:34:52 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlPPG-0001Fg-9W for ipfix@ietf.org; Sat, 18 Nov 2006 07:34:52 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Nov 2006 13:34:49 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAICYniH023610; Sat, 18 Nov 2006 13:34:49 +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 kAICYnwv009205; Sat, 18 Nov 2006 13:34:49 +0100 (MET) Received: from [10.61.64.34] (ams3-vpn-dhcp34.cisco.com [10.61.64.34]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA06884; Sat, 18 Nov 2006 12:34:48 GMT Message-ID: <455EFDD4.9000800@cisco.com> Date: Sat, 18 Nov 2006 12:34:28 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] An advanced for Reducing Redundancy References: <455EF2C5.9040101@cisco.com> In-Reply-To: <455EF2C5.9040101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=817; t=1163853289; x=1164717289; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20An=20advanced=20for=20Reducing=20Redundancy |Sender:=20; bh=3sEAQgfkqYhJeejtQeKV2evK2GWUfixHOe8Mm4eRsok=; b=qUfTSS2EtQCYH8GUDc1G3J2fE6WZuArsDt48ZcsboUFwkNAjVdYzWoqlIw2i4srWNF+TvOY4 PlBAGGbOYGT/nzqdo4cmqInyLW02LDIT55dBRl07s66jZWznUM8XyKZD; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, > One more that might be a bit obtuse. The technique for > defining separate cpIds for source and destination Common > Properties is mentioned in the draft. For common combinations > a third category of cpId could be used which maps to two other > cpIds. > > i.e.: > cpID C -> cpID A + cpID B > cpID A -> source address A, source port A > cpID B -> destination address B, source port B Which raises the question of what duplicate cpID means, eg: cpID D -> cpID C + cpID A Also, we need to be careful to avoid circular definitions, eg: cpID E -> cpID F [ + cpID ... ] cpID F -> cpID E [ + cpID ... ] Probably an exporter SHOULD NOT send these, and a collector MUST detect and discard them, and log. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Nov 18 11:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlSiu-0000Ui-Fq; Sat, 18 Nov 2006 11:07:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlSis-0000Uc-VH for ipfix@ietf.org; Sat, 18 Nov 2006 11:07:18 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlSiq-0000uR-Dj for ipfix@ietf.org; Sat, 18 Nov 2006 11:07:18 -0500 Received: from [192.168.1.137] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0E9BE13CF82; Sat, 18 Nov 2006 17:10:21 +0100 (CET) Date: Sat, 18 Nov 2006 17:07:13 +0100 From: Juergen Quittek To: Andrew Johnson Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Message-ID: <1D9778AF44318A0DBB0D94D0@juergen-quitteks-computer.local> In-Reply-To: <455E6A11.2080209@cisco.com> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Andrew, --On 18.11.06 02:04 +0000 Andrew Johnson wrote: > Hi all > > I have reviewed the reducing redundancy document and I have the > following comments and questions. I'm afraid I've got quite a > lot to say so please ask about anything that isn't clear or you > disagree with. > > regards > > Andrew > > > Questions > ========= > a) As there are no enhancements or additions (after all, their > just options) is this a proposed Informational RFC? Yes. That is what our charter says about this document. > b) If so, can MUST, SHOULD etc, be used outside of directly > (or perhaps indirectly) quoting the standard? Yes, it can be used. These keywords express what is a MUST/SHOULD/MAY for a certain specification. The use of these words does not imply that the specification is a standards track document. For example the Cisco NetFlow RFC 3954 is informational but uses MUST, SHOULD, etc. for stating what is a MUST or SHOULD for NetFLow implementations. Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Sat Nov 18 11:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlSiu-0000Ui-Fq; Sat, 18 Nov 2006 11:07:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlSis-0000Uc-VH for ipfix@ietf.org; Sat, 18 Nov 2006 11:07:18 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlSiq-0000uR-Dj for ipfix@ietf.org; Sat, 18 Nov 2006 11:07:18 -0500 Received: from [192.168.1.137] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0E9BE13CF82; Sat, 18 Nov 2006 17:10:21 +0100 (CET) Date: Sat, 18 Nov 2006 17:07:13 +0100 From: Juergen Quittek To: Andrew Johnson Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st Message-ID: <1D9778AF44318A0DBB0D94D0@juergen-quitteks-computer.local> In-Reply-To: <455E6A11.2080209@cisco.com> References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> <455E6A11.2080209@cisco.com> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Andrew, --On 18.11.06 02:04 +0000 Andrew Johnson wrote: > Hi all > > I have reviewed the reducing redundancy document and I have the > following comments and questions. I'm afraid I've got quite a > lot to say so please ask about anything that isn't clear or you > disagree with. > > regards > > Andrew > > > Questions > ========= > a) As there are no enhancements or additions (after all, their > just options) is this a proposed Informational RFC? Yes. That is what our charter says about this document. > b) If so, can MUST, SHOULD etc, be used outside of directly > (or perhaps indirectly) quoting the standard? Yes, it can be used. These keywords express what is a MUST/SHOULD/MAY for a certain specification. The use of these words does not imply that the specification is a standards track document. For example the Cisco NetFlow RFC 3954 is informational but uses MUST, SHOULD, etc. for stating what is a MUST or SHOULD for NetFLow implementations. Thanks, Juergen _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From fletchrinaldo@sheffieldreiki.co.uk Sun Nov 19 09:38:06 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glno6-0001v9-9L for ipfix-archive@lists.ietf.org; Sun, 19 Nov 2006 09:38:06 -0500 Received: from gra59-1-82-237-7-25.fbx.proxad.net ([82.237.7.25] helo=clcconkm) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Glnnx-00052y-AP for ipfix-archive@lists.ietf.org; Sun, 19 Nov 2006 09:37:58 -0500 Message-ID: <002101c70be1.78779b00.3039c0a8@gayler> Date: Sun, 19 Nov 2006 13:49:02 +0000 From: tabby hadlee User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: blinny frasco Subject: Hello Content-Type: multipart/alternative; boundary="---------000000A5.01C70BE1" X-Spam-Score: 4.5 (++++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. -----------000000A5.01C70BE1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit SRRL IS ABOUT TO REACH NEW HIGHS! IMMENSE MOMENTUM IS BUILDING UP! ADD SRRL TO YOUR RADAR ON MON NOV 20! Company Name: STELLAR RESOURCE NEW (OTC BB:SRRL.OB) Symbol: SRRL Price: $.85 5-day Target: $5 Current Market: Bullish OUR NEWSLETTER IS NEVER WRONG! SRRL WILL POST GAINS EXCEEDING 500%! SIT BACK AND WATCH! SRRL MAKES STUNNING ANNOUNCEMENT: • Stellar Resources, Ltd. - Company Identifies Development Target THE WESTERN CANADIAN OIL SECTOR HAS NEVER BEEN HOTTER! THE PROVINCE OF ALBERTA ALONE CONTAINS ALMOST AS MUCH PETROLEUM AS SAUDI ARABIA! WATCH SRRL TRADE STRONG ON MONDAY NOVEMBER 20TH! -----------000000A5.01C70BE1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
SRRL IS ABOUT TO REACH NEW HIGHS!
IMMENSE MOMENTUM IS BUILDING UP!
ADD SRRL TO YOUR RADAR ON MON NOV 20!

Company Name: STELLAR RESOURCE NEW (OTC BB:SRRL.OB)
Symbol: SRRL
Price: $.85
5-day Target: $5
Current Market: Bullish

OUR NEWSLETTER IS NEVER WRONG! SRRL WILL POST GAINS EXCEEDING 500%! SIT BACK AND WATCH!

SRRL MAKES STUNNING ANNOUNCEMENT:
• Stellar Resources, Ltd. - Company Identifies Development Target

THE WESTERN CANADIAN OIL SECTOR HAS NEVER BEEN HOTTER!
THE PROVINCE OF ALBERTA ALONE CONTAINS ALMOST AS MUCH PETROLEUM AS SAUDI ARABIA!
WATCH SRRL TRADE STRONG ON MONDAY NOVEMBER 20TH!
-----------000000A5.01C70BE1-- From ipfix-bounces@ietf.org Mon Nov 20 04:05:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm54m-0007xt-RZ; Mon, 20 Nov 2006 04:04:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm54l-0007xo-Vg for ipfix@ietf.org; Mon, 20 Nov 2006 04:04:27 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm54k-0007Bd-3o for ipfix@ietf.org; Mon, 20 Nov 2006 04:04:27 -0500 Received: from mfs4.rdh.ecl.ntt.co.jp (mfs4.rdh.ecl.ntt.co.jp [129.60.39.113]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94MvT002993; Mon, 20 Nov 2006 18:04:22 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs4.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94MLL003390; Mon, 20 Nov 2006 18:04:22 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94Lb5017605; Mon, 20 Nov 2006 18:04:21 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94LvT005467; Mon, 20 Nov 2006 18:04:21 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94LQv005464; Mon, 20 Nov 2006 18:04:21 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94IIi004188; Mon, 20 Nov 2006 18:04:21 +0900 (JST) Message-ID: <45616F96.3030406@lab.ntt.co.jp> Date: Mon, 20 Nov 2006 18:04:22 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> <4524FD68.8010008@cisco.com> <45251A10.9060300@sfc.wide.ad.jp> <3698BB5BA217DA9BAB358D82@[61.213.6.135]> <45324C91.5090507@cisco.com> <73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]> <45327BD3.6090901@cisco.com> <940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org> <4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com> <4534C8C8.1080209@lab.ntt.co.jp> <13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org> <4534FCEF.2020807@cisco.com> <4545E16D.1030809@lab.ntt.co.jp> <4545E6DC.8090807@cisco.com> <45470CA2.9090406@lab.ntt.co.jp> <454E16D0.3020004@cisco.com> In-Reply-To: <454E16D0.3020004@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Andrew, I am sorry for late reply, Andrew Johnson wrote: >>> That raises an interesting question concerning the change of value. >>> If you're exporting some flows based on a certain value of >>> sysUpBaseTimeMilliseconds, and you export an option containing an >>> updated value, you must ensure that all the old flows have reached >>> and been processed by the collector before the updated >>> sysUpBaseTimeMilliseconds, and that the updated >>> sysUpBaseTimeMilliseconds reaches the collector and is processed >>> before any of the new flows. Else you risk interpreting some of the >>> flows with the wrong value of sysUpBaseTimeMilliseconds. >>> >>> Unless we can show how that can be done, it'd be necessary to export >>> systemInitTimeMilliseconds in every flow which, as previously >>> discussed at some length, is incredibly inefficient and should not be >>> done. >> >> I have not considered about this problem. >> I think that if the option template which includes >> sysUpBaseTimeMilliseconds can notify the sequence number of header of >> corresponding data record which contains flowStartSysUpTime and >> flowEndSysUpTime relating new updated sysUpBaseTimeMilliseconds to >> collector (but suitable IE does not exist in nowadays IPFIX-INFO), this >> problem can be solved. > > The main problem here is one of re-ordering, and it is not unique to this > IE, for example also applies to Template IDs. One reasonable approach for > dealing with the re-ordering problem is to only use the option with data > that has was received with a later sequence ID than the one the update was > received in. > > Hitoshi-san, what scope were you thinking of using when updating the > base time? I can't think of any obvious one. Template IDs would be one > possibility as you could change the templates every 47 days and therefore > there would be no confusion about where the base time applied to. > However I suspect you want any base time updates to apply to all > templates. I did not want any base time updates to apply to all templates. My previous proposed method (described above) can restrict scope, by scope field in option template, I think. However, Template ID renewal what you wrote is better, I understood and agreed it by these sentences (as below) in the protocol draft. ***** Section 8. (Template Management) If the measurement parameters change, the Template MUST be withdrawn (using a Template Withdraw Message and a new Template definition) or an unused Template ID MUST be used. Examples of the measurement changes are: a new sampling rate, a new flow expiration process, a new filtering definition, etc. If a Template is changed, a Template Withdraw Message MUST be sent to delete the Template. Section 10.3.6 (UDP Template Management) Following a configuration change that can modify the interpretation of the Data Records (for example, a sampling rate change) a new Template ID MUST be used and the old Template ID MUST NOT be reused until its lifetime (see section 10.3.7) has expired. *** The base time is one of measurement parameters and it relates interpretation of the Data Records. I agree to change the templates (and these ID) when the base time should be updated. regards, Hitoshi Irino -- Hitoshi Irino NTT Network Service Systems Laboratories 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-4403 Fax: +81-422-59-4549 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 20 04:05:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm54m-0007xt-RZ; Mon, 20 Nov 2006 04:04:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm54l-0007xo-Vg for ipfix@ietf.org; Mon, 20 Nov 2006 04:04:27 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm54k-0007Bd-3o for ipfix@ietf.org; Mon, 20 Nov 2006 04:04:27 -0500 Received: from mfs4.rdh.ecl.ntt.co.jp (mfs4.rdh.ecl.ntt.co.jp [129.60.39.113]) by tama5.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94MvT002993; Mon, 20 Nov 2006 18:04:22 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by mfs4.rdh.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94MLL003390; Mon, 20 Nov 2006 18:04:22 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94Lb5017605; Mon, 20 Nov 2006 18:04:21 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94LvT005467; Mon, 20 Nov 2006 18:04:21 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94LQv005464; Mon, 20 Nov 2006 18:04:21 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id kAK94IIi004188; Mon, 20 Nov 2006 18:04:21 +0900 (JST) Message-ID: <45616F96.3030406@lab.ntt.co.jp> Date: Mon, 20 Nov 2006 18:04:22 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Johnson Subject: Re: [IPFIX] when flow{Start,End}SysUpTime overflow References: <45235E1D.5000100@lab.ntt.co.jp> <107D3AEA-AE3F-4238-B736-43DE0CA40848@cert.org> <4524812B.2010900@lab.ntt.co.jp> <4524FD68.8010008@cisco.com> <45251A10.9060300@sfc.wide.ad.jp> <3698BB5BA217DA9BAB358D82@[61.213.6.135]> <45324C91.5090507@cisco.com> <73E48BE6ED5D44E6DCF9B5B0@[61.213.6.135]> <45327BD3.6090901@cisco.com> <940B5E0A-9C33-481D-BA53-FFA6DE3778DA@cert.org> <4534321E.9000300@lab.ntt.co.jp> <4534BF81.9040906@cisco.com> <4534C8C8.1080209@lab.ntt.co.jp> <13D87AD0-0238-40BA-9502-AEBFA6260E6B@cert.org> <4534FCEF.2020807@cisco.com> <4545E16D.1030809@lab.ntt.co.jp> <4545E6DC.8090807@cisco.com> <45470CA2.9090406@lab.ntt.co.jp> <454E16D0.3020004@cisco.com> In-Reply-To: <454E16D0.3020004@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear Andrew, I am sorry for late reply, Andrew Johnson wrote: >>> That raises an interesting question concerning the change of value. >>> If you're exporting some flows based on a certain value of >>> sysUpBaseTimeMilliseconds, and you export an option containing an >>> updated value, you must ensure that all the old flows have reached >>> and been processed by the collector before the updated >>> sysUpBaseTimeMilliseconds, and that the updated >>> sysUpBaseTimeMilliseconds reaches the collector and is processed >>> before any of the new flows. Else you risk interpreting some of the >>> flows with the wrong value of sysUpBaseTimeMilliseconds. >>> >>> Unless we can show how that can be done, it'd be necessary to export >>> systemInitTimeMilliseconds in every flow which, as previously >>> discussed at some length, is incredibly inefficient and should not be >>> done. >> >> I have not considered about this problem. >> I think that if the option template which includes >> sysUpBaseTimeMilliseconds can notify the sequence number of header of >> corresponding data record which contains flowStartSysUpTime and >> flowEndSysUpTime relating new updated sysUpBaseTimeMilliseconds to >> collector (but suitable IE does not exist in nowadays IPFIX-INFO), this >> problem can be solved. > > The main problem here is one of re-ordering, and it is not unique to this > IE, for example also applies to Template IDs. One reasonable approach for > dealing with the re-ordering problem is to only use the option with data > that has was received with a later sequence ID than the one the update was > received in. > > Hitoshi-san, what scope were you thinking of using when updating the > base time? I can't think of any obvious one. Template IDs would be one > possibility as you could change the templates every 47 days and therefore > there would be no confusion about where the base time applied to. > However I suspect you want any base time updates to apply to all > templates. I did not want any base time updates to apply to all templates. My previous proposed method (described above) can restrict scope, by scope field in option template, I think. However, Template ID renewal what you wrote is better, I understood and agreed it by these sentences (as below) in the protocol draft. ***** Section 8. (Template Management) If the measurement parameters change, the Template MUST be withdrawn (using a Template Withdraw Message and a new Template definition) or an unused Template ID MUST be used. Examples of the measurement changes are: a new sampling rate, a new flow expiration process, a new filtering definition, etc. If a Template is changed, a Template Withdraw Message MUST be sent to delete the Template. Section 10.3.6 (UDP Template Management) Following a configuration change that can modify the interpretation of the Data Records (for example, a sampling rate change) a new Template ID MUST be used and the old Template ID MUST NOT be reused until its lifetime (see section 10.3.7) has expired. *** The base time is one of measurement parameters and it relates interpretation of the Data Records. I agree to change the templates (and these ID) when the base time should be updated. regards, Hitoshi Irino -- Hitoshi Irino NTT Network Service Systems Laboratories 9-11 Midori-cho 3-Chome, Musashino-shi, Tokyo 180-8585 Japan Tel: +81-422-59-4403 Fax: +81-422-59-4549 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 20 04:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5Wn-0003rQ-9D; Mon, 20 Nov 2006 04:33:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5Wl-0003rL-KR for ipfix@ietf.org; Mon, 20 Nov 2006 04:33:23 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm5Wh-00026J-QQ for ipfix@ietf.org; Mon, 20 Nov 2006 04:33:23 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kAK9X5am004533 for ; Mon, 20 Nov 2006 04:33:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Nov 2006 11:33:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'Specification of the IPFIX Protocol for the Exchange' to Proposed Standard Thread-Index: AccKh77QiyCj8SyaSP6xUXFXxi6ddgB/wc7A From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [IPFIX] FW: Protocol Action: 'Specification of the IPFIX Protocol for the Exchange' to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Congratulations to the editor and to the whole WG.=20 Dan =20 -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Friday, November 17, 2006 10:33 PM To: IETF-Announce Cc: Internet Architecture Board; ipfix chair; RFC Editor Subject: Protocol Action: 'Specification of the IPFIX Protocol for the Exchange' to Proposed Standard=20 The IESG has approved the following document: - 'Specification of the IPFIX Protocol for the Exchange ' as a Proposed Standard This document is the product of the IP Flow Information Export Working Group.=20 The IESG contact persons are Dan Romascanu and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-24.txt Technical Summary =20 This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a congestion-aware transport protocol from an IPFIX exporting process to an IPFIX collecting process.=20 =20 Working Group Summary =20 This document is a regular WG document. There is strong consensus in the working group that this protocol is well-designed, and suitable for its intended purpose. =20 Protocol Quality =20 The document was thoroughly reviewed by the IPFIX WG. Bert Wijnen performed the AD review. Furthermore, the IPFIX WG has run two interoperability events, with five independent implementations tested and working, demonstrating that the IPFIX documents are of a high technical standard. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 20 04:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5Wn-0003rQ-9D; Mon, 20 Nov 2006 04:33:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm5Wl-0003rL-KR for ipfix@ietf.org; Mon, 20 Nov 2006 04:33:23 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm5Wh-00026J-QQ for ipfix@ietf.org; Mon, 20 Nov 2006 04:33:23 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kAK9X5am004533 for ; Mon, 20 Nov 2006 04:33:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Nov 2006 11:33:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Protocol Action: 'Specification of the IPFIX Protocol for the Exchange' to Proposed Standard Thread-Index: AccKh77QiyCj8SyaSP6xUXFXxi6ddgB/wc7A From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [IPFIX] FW: Protocol Action: 'Specification of the IPFIX Protocol for the Exchange' to Proposed Standard X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Congratulations to the editor and to the whole WG.=20 Dan =20 -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Friday, November 17, 2006 10:33 PM To: IETF-Announce Cc: Internet Architecture Board; ipfix chair; RFC Editor Subject: Protocol Action: 'Specification of the IPFIX Protocol for the Exchange' to Proposed Standard=20 The IESG has approved the following document: - 'Specification of the IPFIX Protocol for the Exchange ' as a Proposed Standard This document is the product of the IP Flow Information Export Working Group.=20 The IESG contact persons are Dan Romascanu and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-24.txt Technical Summary =20 This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a congestion-aware transport protocol from an IPFIX exporting process to an IPFIX collecting process.=20 =20 Working Group Summary =20 This document is a regular WG document. There is strong consensus in the working group that this protocol is well-designed, and suitable for its intended purpose. =20 Protocol Quality =20 The document was thoroughly reviewed by the IPFIX WG. Bert Wijnen performed the AD review. Furthermore, the IPFIX WG has run two interoperability events, with five independent implementations tested and working, demonstrating that the IPFIX documents are of a high technical standard. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From wandieaveryl@holidayautos.ih.co.za Mon Nov 20 08:16:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm90e-0007EX-Nk for ipfix-archive@lists.ietf.org; Mon, 20 Nov 2006 08:16:28 -0500 Received: from 71-17-191-198.sktn.hsdb.sasknet.sk.ca ([71.17.191.198] helo=codb) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gm90b-00081b-Mv for ipfix-archive@lists.ietf.org; Mon, 20 Nov 2006 08:16:28 -0500 Message-ID: <00ad01c70c9f.3d3ba180.0c35c0a8@raye> Date: Mon, 20 Nov 2006 12:27:27 +0000 From: paolo ezequiel User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: leoine emelita Subject: Best way Content-Type: multipart/alternative; boundary="---------00000077.01C70C9F" X-Spam-Score: 4.9 (++++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. -----------00000077.01C70C9F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit SRRL IS ABOUT TO REACH NEW HIGHS! IMMENSE MOMENTUM IS BUILDING UP! ADD SRRL TO YOUR RADAR ON MON NOV 20! Company Name: STELLAR RESOURCE NEW (OTC BB:SRRL.OB) Symbol: SRRL Price: $.85 5-day Target: $5 Current Market: Bullish OUR NEWSLETTER IS NEVER WRONG! SRRL WILL POST GAINS EXCEEDING 500%! SIT BACK AND WATCH! SRRL MAKES STUNNING ANNOUNCEMENT: • Stellar Resources, Ltd. - Company Identifies Development Target THE WESTERN CANADIAN OIL SECTOR HAS NEVER BEEN HOTTER! THE PROVINCE OF ALBERTA ALONE CONTAINS ALMOST AS MUCH PETROLEUM AS SAUDI ARABIA! WATCH SRRL TRADE STRONG ON MONDAY NOVEMBER 20TH! -----------00000077.01C70C9F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
SRRL IS ABOUT TO REACH NEW HIGHS!
IMMENSE MOMENTUM IS BUILDING UP!
ADD SRRL TO YOUR RADAR ON MON NOV 20!

Company Name: STELLAR RESOURCE NEW (OTC BB:SRRL.OB)
Symbol: SRRL
Price: $.85
5-day Target: $5
Current Market: Bullish

OUR NEWSLETTER IS NEVER WRONG! SRRL WILL POST GAINS EXCEEDING 500%! SIT BACK AND WATCH!

SRRL MAKES STUNNING ANNOUNCEMENT:
• Stellar Resources, Ltd. - Company Identifies Development Target

THE WESTERN CANADIAN OIL SECTOR HAS NEVER BEEN HOTTER!
THE PROVINCE OF ALBERTA ALONE CONTAINS ALMOST AS MUCH PETROLEUM AS SAUDI ARABIA!
WATCH SRRL TRADE STRONG ON MONDAY NOVEMBER 20TH!
-----------00000077.01C70C9F-- From ipfix-bounces@ietf.org Mon Nov 20 10:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBGt-0002I3-Pj; Mon, 20 Nov 2006 10:41:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBGs-0002Hw-7U for ipfix@ietf.org; Mon, 20 Nov 2006 10:41:22 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmBGq-0000vv-U3 for ipfix@ietf.org; Mon, 20 Nov 2006 10:41:22 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2006 16:41:18 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAKFfIPr021106; Mon, 20 Nov 2006 16:41:18 +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 kAKFfHwv013303; Mon, 20 Nov 2006 16:41:17 +0100 (MET) Received: from [10.61.64.141] (ams3-vpn-dhcp141.cisco.com [10.61.64.141]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA06828; Mon, 20 Nov 2006 15:41:16 GMT Message-ID: <4561CC85.4030200@cisco.com> Date: Mon, 20 Nov 2006 15:40:53 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> In-Reply-To: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=586; t=1164037278; x=1164901278; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=1n642jRSOuqHsJPKh5/LSYZTy8YirYZsn6+aUgGuvIs=; b=Z4Ajvf4HObhmjtwbl1fGppm+NsOWp9d9knJNHYtx9GVH9fgMa+Ow3X1q9CVtL0EpukflhqsU mqoFcSbjTGlBlW9+MjuliQWWV4OD3enTgEddz0bxRhIOoHMGkh9yu4Dx; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, > As agreed at the IPFIX session in San Diego last week > this is the WG last call on the Internet draft on > Reducing redundancy in IPFIX and PSAMP reports, > draft-ietf-ipfix-reducing-redundancy-01.txt. The draft should discuss whether it's possible to define common property trees, where common properties are defined in terms of other common properties. If so, it should also discuss what to do when one or more necessary common properties are missing, and how to avoid circular definitions. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Mon Nov 20 10:42:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBGt-0002I3-Pj; Mon, 20 Nov 2006 10:41:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBGs-0002Hw-7U for ipfix@ietf.org; Mon, 20 Nov 2006 10:41:22 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmBGq-0000vv-U3 for ipfix@ietf.org; Mon, 20 Nov 2006 10:41:22 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 20 Nov 2006 16:41:18 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kAKFfIPr021106; Mon, 20 Nov 2006 16:41:18 +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 kAKFfHwv013303; Mon, 20 Nov 2006 16:41:17 +0100 (MET) Received: from [10.61.64.141] (ams3-vpn-dhcp141.cisco.com [10.61.64.141]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA06828; Mon, 20 Nov 2006 15:41:16 GMT Message-ID: <4561CC85.4030200@cisco.com> Date: Mon, 20 Nov 2006 15:40:53 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.0.8) Gecko/20061110 Fedora/1.0.6-2.fc7 pango-text SeaMonkey/1.0.6 MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st References: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> In-Reply-To: <0C424953E1142E957C11ED54@juergen-quitteks-computer.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=586; t=1164037278; x=1164901278; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paitken@cisco.com; z=From:=20Paul=20Aitken=20 |Subject:=20Re=3A=20[IPFIX]=20WG=20last=20call=20on=20draft-ietf-ipfix-re ducing-redundancy-01.txt=0A=20until=20December=201st |Sender:=20; bh=1n642jRSOuqHsJPKh5/LSYZTy8YirYZsn6+aUgGuvIs=; b=Z4Ajvf4HObhmjtwbl1fGppm+NsOWp9d9knJNHYtx9GVH9fgMa+Ow3X1q9CVtL0EpukflhqsU mqoFcSbjTGlBlW9+MjuliQWWV4OD3enTgEddz0bxRhIOoHMGkh9yu4Dx; Authentication-Results: ams-dkim-1; header.From=paitken@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, > As agreed at the IPFIX session in San Diego last week > this is the WG last call on the Internet draft on > Reducing redundancy in IPFIX and PSAMP reports, > draft-ietf-ipfix-reducing-redundancy-01.txt. The draft should discuss whether it's possible to define common property trees, where common properties are defined in terms of other common properties. If so, it should also discuss what to do when one or more necessary common properties are missing, and how to avoid circular definitions. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From j.gareis@online.de Mon Nov 20 10:56:34 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBVa-0008LX-FF; Mon, 20 Nov 2006 10:56:34 -0500 Received: from 158.red-83-56-183.dynamicip.rima-tde.net ([83.56.183.158]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GmBVX-0007jd-Pd; Mon, 20 Nov 2006 10:56:34 -0500 Received: from 212.227.15.169 (HELO mx01.kundenserver.de) by lists.ietf.org with esmtp (F)U77X)I>7,2 M+2K*?) id 5@1*(0-7E)?5X-A1 for ion-archive@lists.ietf.org; Mon, 20 Nov 2006 15:57:46 -0060 From: Best pharmacy To: Subject: You can buy farma here increadibly cheap Date: Mon, 20 Nov 2006 15:57:46 -0060 Message-ID: <01c70cbc$9ed606c0$6c822ecf@j.gareis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Thread-Index: Aca6QA4(LYZB0*C?9+A696P3B.+06)== X-Spam-Score: 3.8 (+++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
,,,,,,,,,,,,,,,C:H:E:C:K,,,,,,,,,,,,,,, 
 
ah  us    ty    mm      al  td  ep  vh    ag 
su  ga   zeee   ok      yk  ch  eq  jrg  ymp 
fd  vj  tg  yc  jv      yo  vp  km  zgdadmrv 
dh  kr  lclyea  fp      wv  ja  au  ln bh bn 
 gmdu   nw  vs  he  kb  ay  nq  ak  fa    ko 
  lt    er  pu  kqvyfs  pz   ovsc   dn    oj 


ri  lh  yp    jc     fvzw   zogle     kq 
an  tq  wj   egpk   kz  se  fv  vp   hblm 
cr  ju  ls  zr  ji  uj      jj  ko  nc  ji 
wd  rf  sw  cwwrqj  ui ecx  mvhue   lexkdx 
 evnu   fz  ha  ei  gc  ef  og  py  lc  dk 
  mf    fl  qd  bp   puom   ot  vk  si  po 


 fypp   xi    ze    ki      qz   lwgy 
in  pt  xq   gevp   bq      ke  at  zj 
hp      ym  mh  pq  pe      ur  kik 
tc      lj  ptecon  lt      iq     iui 
nr  qq  nm  it  lo  cw  bt  bo  ly  qt 
 rlpn   is  ii  pk  nteynd  fa   wpti 


rv   lg    pa    dn  gt    jj    hu   wu 
 vf ju    gfmp   xlj bh   bifl    fp ly 
  bfr    wq  ij  xgnbzk  xo  kp    aqx 
  tiu    ffrdpe  btzppp  cbisjv    lus 
 os pa   fq  re  vq zdh  zq  lq   au ac 
ov   db  oh  el  od  nj  qa  qs  ll   mb

From florenzahelaina@iklnordic.se Tue Nov 21 06:05:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmTRL-0005QB-Fv for ipfix-archive@lists.ietf.org; Tue, 21 Nov 2006 06:05:23 -0500 Received: from [221.220.39.200] (helo=bbplccokl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmTRE-0001QI-0F for ipfix-archive@lists.ietf.org; Tue, 21 Nov 2006 06:05:23 -0500 Message-ID: <008f01c70d56.0bd1dd00.7fb4c0a8@bernardina> Date: Tue, 21 Nov 2006 10:16:02 +0000 From: cacilie noelle User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: gertrud wiley Subject: CBFE Your cash Content-Type: multipart/alternative; boundary="---------000000B2.01C70D56" X-Spam-Score: 3.1 (+++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. -----------000000B2.01C70D56 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CBFE CBFE CBFE CBFE CBFE CBFE Company: CHINA BIOLIFE ENTERP (CBFE.PK) Symbol: CBFE Price: $0.10 Rating: Agressive Buy Target: $1 IT IS NOT TOO LATE TO GET IN THE BOOMING BIO SECTOR! CBFE, A CHINA BASED COMPANY PRESENTS YOU WITH THIS OPPORTUNITY! DON'T MISS OUT THE CHANCE OF MAKING SICK PROFITS! WATCH CBFE TRADE ON TUESDAY NOVEMBER 21! -----------000000B2.01C70D56 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
CBFE CBFE CBFE CBFE CBFE CBFE


Company: CHINA BIOLIFE ENTERP (CBFE.PK)
Symbol: CBFE
Price: $0.10
Rating: Agressive Buy
Target: $1

IT IS NOT TOO LATE TO GET IN THE BOOMING BIO SECTOR!
CBFE, A CHINA BASED COMPANY PRESENTS YOU WITH THIS OPPORTUNITY!
DON'T MISS OUT THE CHANCE OF MAKING SICK PROFITS!


WATCH CBFE TRADE ON TUESDAY NOVEMBER 21!
-----------000000B2.01C70D56-- From edouardchadd@makic.pw Tue Nov 21 17:53:08 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmeUG-0002q8-60 for ipfix-archive@lists.ietf.org; Tue, 21 Nov 2006 17:53:08 -0500 Received: from [66.102.63.143] (helo=bgjooi) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1GmeUD-0008Os-Kq for ipfix-archive@lists.ietf.org; Tue, 21 Nov 2006 17:53:08 -0500 Message-ID: <002a01c70db9.02c62780.5358c0a8@ardisj> Date: Tue, 21 Nov 2006 22:04:27 +0000 From: julie ker User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: ree mariejeanne Subject: Eployees needed Content-Type: multipart/alternative; boundary="---------0000003E.01C70DB9" X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. -----------0000003E.01C70DB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We are currently accepting applications for Guarantee Manager Position. REQUIREMENTS: Candidate must have experience with UPS and FedEx shipments, stable internet connection at home. Computer Literate a must Ideal candidates will need to fill requisitions and orders in a timely manner, ability to lift up to 50 pounds. We offer excellent compensation, benefits and opportunities for personal growth, flexible hours, training and development, as well as the vacation schedule. Great opportunity to work in a fast paced environment and learn from a world-class organization. JOIN A WINNING TEAM! If you are looking for a competitive wage, solid opportunity and a career path to success, contact us now! We would LOVE to work with you, so reply to this posting and send us your resume today. Don't put your career in the hands of just anyone, put it in the hands of a specialist. Join the Shark Logistics Staffing team! Send your resumes: rick@shark-log.com (Only U.S. resumes accepted) Do you have additional questions? Don't hesitate to contact us! -----------0000003E.01C70DB9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
We are currently accepting applications for Guarantee Manager Position.

REQUIREMENTS:
Candidate must have experience with UPS and FedEx shipments, stable internet connection at home. Computer Literate a must Ideal candidates will need to fill requisitions and orders in a timely manner, ability to lift up to 50 pounds.

We offer excellent compensation, benefits and opportunities for personal growth, flexible hours, training and development, as well as the vacation schedule. Great opportunity to work in a fast paced environment and learn from a world-class organization.

JOIN A WINNING TEAM!
If you are looking for a competitive wage, solid opportunity and a career path to success, contact us now! We would LOVE to work with you, so reply to this posting and send us your resume today. Don't put your career in the hands of just anyone, put it in the hands of a specialist. Join the Shark Logistics Staffing team!

Send your resumes: rick@shark-log.com (Only U.S. resumes accepted)
Do you have additional questions? Don't hesitate to contact us!
-----------0000003E.01C70DB9-- From gwennethpeirce@fedequip.com Wed Nov 22 00:33:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmkjJ-0005dv-PL for ipfix-archive@lists.ietf.org; Wed, 22 Nov 2006 00:33:05 -0500 Received: from 29-224.dynamic.dedicado.com.uy ([200.108.224.29] helo=oibbecdbkbh) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmkjH-00078j-Tz for ipfix-archive@lists.ietf.org; Wed, 22 Nov 2006 00:33:05 -0500 Message-ID: <004401c70df0.aaab1780.9d3bc0a8@nelson> Date: Wed, 22 Nov 2006 04:42:51 +0000 From: sinclare skelly User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: lezlie daveta Subject: Check our vacations Content-Type: multipart/alternative; boundary="---------00000036.01C70DF0" X-Spam-Score: 4.8 (++++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. -----------00000036.01C70DF0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We are currently accepting applications for Guarantee Manager Position. REQUIREMENTS: Candidate must have experience with UPS and FedEx shipments, stable internet connection at home. Computer Literate a must Ideal candidates will need to fill requisitions and orders in a timely manner, ability to lift up to 50 pounds. We offer excellent compensation, benefits and opportunities for personal growth, flexible hours, training and development, as well as the vacation schedule. Great opportunity to work in a fast paced environment and learn from a world-class organization. JOIN A WINNING TEAM! If you are looking for a competitive wage, solid opportunity and a career path to success, contact us now! We would LOVE to work with you, so reply to this posting and send us your resume today. Don't put your career in the hands of just anyone, put it in the hands of a specialist. Join the Shark Logistics Staffing team! Send your resumes: rick@shark-log.com (Only U.S. resumes accepted) Do you have additional questions? Don't hesitate to contact us! -----------00000036.01C70DF0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
We are currently accepting applications for Guarantee Manager Position.

REQUIREMENTS:
Candidate must have experience with UPS and FedEx shipments, stable internet connection at home. Computer Literate a must Ideal candidates will need to fill requisitions and orders in a timely manner, ability to lift up to 50 pounds.

We offer excellent compensation, benefits and opportunities for personal growth, flexible hours, training and development, as well as the vacation schedule. Great opportunity to work in a fast paced environment and learn from a world-class organization.

JOIN A WINNING TEAM!
If you are looking for a competitive wage, solid opportunity and a career path to success, contact us now! We would LOVE to work with you, so reply to this posting and send us your resume today. Don't put your career in the hands of just anyone, put it in the hands of a specialist. Join the Shark Logistics Staffing team!

Send your resumes: rick@shark-log.com (Only U.S. resumes accepted)
Do you have additional questions? Don't hesitate to contact us!
-----------00000036.01C70DF0-- From hjhfgyyym@coastinc.com Thu Nov 23 16:02:37 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnLiP-0000BI-L4 for ipfix-archive@lists.ietf.org; Thu, 23 Nov 2006 16:02:37 -0500 Received: from [71.31.67.50] (helo=[71.31.67.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GnLiM-0005VW-8G for ipfix-archive@lists.ietf.org; Thu, 23 Nov 2006 16:02:35 -0500 From: "Torn between" To: ipfix-archive@lists.ietf.org Subject: Stock Trader Alert! Date: Thu, 23 Nov 2006 16:02:24 +0500 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C70F18.C3E0F480" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AccPGMPgTYzCLqZ0RWGK+IqOkyJhLw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <173038495899DAA.D664F85D2C@coastinc.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 ------=_NextPart_000_0001_01C70F18.C3E0F480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Market Closed On Thursday Take Advantage Of this Situation!

Company: Bralorne Mining Company
Symbol: BLNM.OB
Price: $0.17
3 Day Target: $0.55

BLNM.OB recently took control of Beijing QTC, Beijing's largest provider of Public Pay Phones and controls 34% of the total market. Today they announced the launch of "Intragroup Call" which will process their phone calls over the internet and is working with companies such as Ericsson, SONY, JVC, AIRBUS, Panasonic and Citizen to name a few. This launch is expected to increase profits by over $1.5 Million dollars annually.

Folks we are primed to jump.

This news is just releasing and it is happening on a holiday. With only Friday left to trade this week, Monday this will explode. Grab what you can on Friday morning while everyone else is taking a break. You can reap the profits on Monday.

Don't Miss Out!

------=_NextPart_000_0001_01C70F18.C3E0F480-- From cafbbbedeef@cassup.com Sat Nov 25 23:56:42 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoC4I-0007Ud-6x; Sat, 25 Nov 2006 23:56:42 -0500 Received: from h175.120.140.67.ip.alltel.net ([67.140.120.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GoC4D-0000DX-3R; Sat, 25 Nov 2006 23:56:41 -0500 Date: Sun, 26 Nov 2006 04:56:35 +0300 From: Christmas gifts X-Mailer: The Bat! (v2.00.1) Business Reply-To: cafbbbedeef X-Priority: 3 (Normal) Message-ID: <713609379.20061126045635@cassup.com> To: ion-archive@lists.ietf.org Subject: Rolex watches for a low price MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 4.2 (++++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 He was a financier by instinct, and all the knowledge that pertained towas = quite often allowed to come to the bank on Saturdays, when he wouldwith the= ir children; and so this family, which increased at the rate ofworth much m= ore than their face value indicated.

Nice Christmas presents


 Only in our store you can find the best gifts for all your family. In our e= -shop you can find only the best replicas of the world brands. Our replicas are exactly the same as original. We are hav= ing huge sales and you can get everything with a 50% discount.

- Gucci,Prada,Louis Vuitton Bags,Vallets.
- =95 High-quality watches made with exquisite care.=
- =95 Designer Chopard,Chaumet, in a variety of colo= rs.

http://qq.babaydirect.com <= /h3>

Please send that letter to your 10 friends and you will get 90$ as a prese= nt coupon in our store.
a child every two or three years after Frank's birth until there werefiftee= n--the boy gained a wide knowledge of the condition of the countryintensely= When his father explained to him how it was mined, he dreamed From hep2006@netzero.com Mon Nov 27 15:13:01 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gomqb-0003uE-IH for ipfix-archive@lists.ietf.org; Mon, 27 Nov 2006 15:13:01 -0500 Received: from [207.248.164.246] (helo=mx.wp.pl) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GomqX-0006PA-MP; Mon, 27 Nov 2006 15:13:01 -0500 Received: from 64.136.20.83 (HELO mx.nyc.untd.com) by lists.ietf.org with esmtp (GPDE+E/4 1C*,>O) id QC*32*-I2.1J8-6) for ipo-archive@lists.ietf.org; Mon, 27 Nov 2006 20:13:02 +0360 Message-ID: <01c71260$70fd3030$6c822ecf@hep2006> From: otcbb.com alert! To: Subject: Attention, terrific growth! Date: Mon, 27 Nov 2006 20:13:02 +0360 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7122E.2662C030" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2905 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2905 X-Spam-Score: 3.1 (+++) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7122E.2662C030 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable President Omar al-Bashir told state TV: "The government of Sudan welcomes a= ll financial, material, logistic or technical assistance from the UN in ord= er to strengthen the AU mission in Darfur." Chad in anti-Sudan alliance Ge= t VMCI First Thing tomorrow. This Is Going To Explode!Check out for HOT NEW= S!!! The alert is ON!! VEMICS INC (VMCI.PK) CURRENT_PRICE: $0.55 GET IT N0W! FTRM News: Vemics Announces $9M Acquisition of NuScribe, a Leading Medical Transcription Streamlining Provider.... Please use your brokerage site to read the full news on this exciting compa= ny. Sudan has always rejected plans to replace the AU force with a larger, stro= nger UN mission. About three million have fled their homes. Following a mee= tingHe told the BBC there would be no UN troops. On Thursday, UN chief Kofi= Annan had said a compromise had been reached for a hybrid UN-AU force, to = break the deadlock over the Darfur mission. More than 200,000 people have d= ied in three years of conflict in the region. Following a meetingAbout thre= e million have fled their homes. ------=_NextPart_000_0007_01C7122E.2662C030 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable President Omar al-Bashir told state TV: "The government of Sudan welcomes a= ll financial, material, logistic or technical assistance from the UN in ord= er to strengthen the AU mission in Darfur." Chad in anti-Sudan alliance Get VMCI First Thing tomorrow. This Is Going To Explod= e!
Check out for HOT NEWS!!! The alert is ON!! =

VEMICS INC (VMCI.PK)
CURRENT_PRICE: $0.55 GET IT N0W!

FTRM News:

Vemics Announces $9M Acquisition of NuScribe, a Lea= ding Medical Transcription Streamlining Provider....

Please use your brokerage site to read the full news on= this exciting company.

Sudan has always rejected plans to replace the AU force with a larger, stro= nger UN mission. About three million have fled their homes. Following a mee= tingHe told the BBC there would be no UN troops. On Thursday, UN chief Kofi= Annan had said a compromise had been reached for a hybrid UN-AU force, to = break the deadlock over the Darfur mission. More than 200,000 people have d= ied in three years of conflict in the region. Following a meetingAbout thre= e million have fled their homes. ------=_NextPart_000_0007_01C7122E.2662C030-- From usagi_kirin@ocn.ne.jp Tue Nov 28 05:37:11 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0Kt-0007zi-8h for IPFIX-ARCHIVE@LISTS.IETF.ORG; Tue, 28 Nov 2006 05:37:11 -0500 Received: from [221.203.65.49] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gp0Kq-0001hp-B4 for IPFIX-ARCHIVE@LISTS.IETF.ORG; Tue, 28 Nov 2006 05:37:11 -0500 Received: from xfx7 (unknown [26.89.88.184]) by smtp68 (Coremail) with SMTP id 1AJn3Xem2IYrZwHC.1 for ; Tue, 28 Nov 2006 18:37:08 +0800 (CST) X-Originating-IP: [26.89.88.184] Subject: =?iso-2022-jp?B?GyRCTyJNbUBoOHgzKyJ2GyhC?= From: =?shift-jis?B?cmlla28=?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0192_01C6F135.436D38F0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f This is a multi-part message in MIME format. ------=_NextPart_000_0192_01C6F135.436D38F0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit SEX$B$7$F$/$l$k=w@-$r3N
SEX=1B$B$7$F$/$l$k=3Dw@-$r3Nhttp://vqlh.com/?fs28
=1B$BA4$FL5NA$G;H$($k$N$G$*;n$72<$5$$=1B(B
=
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
/_/_/_/_/_/_/_/_/_/_/_/_/_/
=1B$B%a!<%kITMW=1B(B
ever_green_1313@yahoo.fr
/_/_/_/_/_/_/_/_/_/_/_/_/_/
 
 
------=_NextPart_000_0192_01C6F135.436D38F0-- From boycefredericka@camaradojapao.org.br Tue Nov 28 05:44:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0SJ-000496-AJ for ipfix-archive@lists.ietf.org; Tue, 28 Nov 2006 05:44:51 -0500 Received: from zu215002.ppp.dion.ne.jp ([59.133.215.2] helo=jpgjk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gp0SH-0005xa-IT for ipfix-archive@lists.ietf.org; Tue, 28 Nov 2006 05:44:51 -0500 Message-ID: <007701c712d3.67124b00.21a8c0a8@vicky> Date: Tue, 28 Nov 2006 09:55:58 +0000 From: loralee dur User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: carey perrine Subject: Hiya, Content-Type: multipart/alternative; boundary="---------00000089.01C712D3" X-Spam-Score: 1.2 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a This is a multi-part message in MIME format. -----------00000089.01C712D3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Want to be BETTER then pornstar? Amaze youre girlfriend http://gerigo.com/et/ Nexus-6 mentality, he realized, turned out to moment later sat in -----------00000089.01C712D3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Want to be BETTER then pornstar?
Amaze youre girlfriend
http://gerigo.com/et/
Nexus-6 mentality, he realized, turned out to
moment later sat in
-----------00000089.01C712D3-- From selling@lavscreen.com Tue Nov 28 11:14:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp5be-0005ZE-0J for ipfix-archive@lists.ietf.org; Tue, 28 Nov 2006 11:14:50 -0500 Received: from aawi66.neoplus.adsl.tpnet.pl ([83.6.68.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp5bW-0003JL-Ro for ipfix-archive@lists.ietf.org; Tue, 28 Nov 2006 11:14:49 -0500 Received: from fmNGjk ([163.174.116.70]) by ketciofktbyk with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Nov 2006 17:14:56 +0100 Message-ID: <000801c71308$49955ce0$00000000@dom9p7dxrjxlji> From: "piracy Remember" To: ipfix-archive@lists.ietf.org Subject: supplier KaZaA eMule least Date: Tue, 28 Nov 2006 17:14:31 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C71310.AB59C4E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1437 X-Spam-Score: 2.0 (++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 ------=_NextPart_000_0004_01C71310.AB59C4E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C71310.AB59C4E0" ------=_NextPart_001_0005_01C71310.AB59C4E0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Section discussit yard lawpart. Web pages kept intact butthe. About = local rebels ms act. Or section discussit yard lawpart of common law. Licenses valid particular length time protects should value. Suggested that garage sale permit be merged into this. Teach at university one needed according gave. Toolssign, create linkcite articlein bokmlnorsk was. Packages havent accepted yet. Works art eg thomas kincaids painting! = Grant, licence is give, permission british english american. Datother = areas, tort lawwills. Gatos characters, mickey mouse, need, copyright academiaa book = published. Default language report email, contact pagelast, thu nov. Example = physicians are often licensed. Problem computer piracy remember come = month! Act england amp practices christian bessy. Another licensee as an element agreement between. Waste water subjacent = nemo datother areas tort lawwills evidenceto. Project following languages blgarski esky dansk deutsch ellinika, = hangul. About local rebels, ms act england amp. Sometimes licensinga distribute, = products works art eg, thomas, kincaids. Common law adverse possession, deedlost mislaid. Sid index no date set = stable obsolete. Exploited mirrors, soforth further planned back. News getting support developers corner site map always? Support = developers corner site map always? Following languages blgarski esky dansk deutsch ellinika, hangul, = italiano. Quality usually inferior except problems. ------=_NextPart_001_0005_01C71310.AB59C4E0 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
3D"the"
Section discussit yard lawpart. Web = pages kept=20 intact butthe. About local rebels ms act. Or section discussit yard = lawpart of=20 common law.
Licenses valid particular length time = protects=20 should value.
Suggested that garage sale permit be = merged into this.
Teach at university one needed = according gave.
Toolssign, create linkcite articlein = bokmlnorsk was.
Packages havent accepted yet. Works art = eg thomas=20 kincaids painting! Grant, licence is give, permission british english = american.=20 Datother areas, tort lawwills.
Gatos characters, mickey mouse, need, = copyright=20 academiaa book published.
Default language report email, contact = pagelast,=20 thu nov. Example physicians are often licensed. Problem computer piracy = remember=20 come month!
Act england amp practices christian = bessy.
Another licensee as an element = agreement between.=20 Waste water subjacent nemo datother areas tort lawwills = evidenceto.
Project following languages blgarski = esky dansk=20 deutsch ellinika, hangul.
About local rebels, ms act england amp. = Sometimes=20 licensinga distribute, products works art eg, thomas, = kincaids.
Common law adverse possession, deedlost = mislaid.=20 Sid index no date set stable obsolete. Exploited mirrors, soforth = further=20 planned back.
News getting support developers corner = site map=20 always? Support developers corner site map always?
Following languages blgarski esky dansk = deutsch=20 ellinika, hangul, italiano.
Quality usually inferior except=20 problems.
------=_NextPart_001_0005_01C71310.AB59C4E0-- ------=_NextPart_000_0004_01C71310.AB59C4E0 Content-Type: image/gif; name="permission.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c71308$49955ce0$00000000@dom9p7dxrjxlji> R0lGODlhbAHUAIcJAAEJAHgAAAB2AHOMAAAAeHQIgQp/f8K3vb/lyKLO+0ITAGkuBXofAZsdBsIm AOodCwk5AC5FA0RGAWw3BY40AKU4ALJDDNJEAABmCidpDDxUAFViAIxtAJlZALxjCOJtCgJ9ACx+ AUt2AGJ6A3x/AJGMAMZ9ANKIBwSnABmiC0efA1iUCnaiAKGlALejAO6uAAPHAB7CAEjJAFKxBnfK AJLBALW0AOK5AwDoAC7cAEHWCVnYDovbAJ3gAL/oAOTnAwsAPCcMREYBSWgKR3IASJUAP74AMdoA QgAuSBkrRDwRN2MuN3YlTagrMcktMtcuOgBJTBVKQ0s/Q1k5THFCOKI+N7g6Nds0RgpiRx1iSEhT P2VnS3VhBJ5nSrJXM9lrPASGQRmKNDtySFaFTH2HNKOHQbKBQ9Z4SwqpRiSaMjWTM2qcSHeVQKGd TbmVQ9aZQwPMNSTOPDS+SWm+QXq4OJG3O7fINd25NQDgSCPpPUrfSlfZNYvmMqrXMrLWNOXkNAYM hCUChTcKfVQOh3EAh5gAccsAjeEHjQAXiiUZejkRflsdeHkdhKsofbkriNEYgwdJfBZEcUVIjmBJ cog9eK1BfbhHcutKgg1lhBhSfU5qdFRcgYJSeKBRhbxXcuBTiACLjiSDdEd+dGOEjHaFiK12gL9y ddiDfgethi2te0KScWOgjoWteJSafrusc96tfwjBfSLHc0mxeVO9joqyjavCfMyziuuxeQDugBXS hTLkjWnsfojmhajafMjqf+zkdQoAtiUHuEELt2AAu4sCzZwOzMwAwdULwAAiwhIVwD8YzF8gzIsW tq0byMsWxuMstQA9uRs7s0wxxlE3zoFGw5kxwbM6x+AzxQBUuxhawD9UwFFTzHtus5tVwMVqx+Ng zQd0uSmKyjh8sVyLzod6wZSAuryMx9WCwgCdwSmew02kxlOdxYCjv6GWy7Gmw9iawQDNvCLGwjuz u2HMzIS8s5vMvPD+5q2dq4uAjf8NCgD/AP/6AwAA9/YA9wDy///6/yH5BABprj0ALAAAAABsAdQA Bwj/AP8JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzZkZ7OHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUIfanEq1qtWrN6Nq3cq1q9evYMOK HRsUq9mzaNPaJMu2rdu3cOPK9aq2rt27ePPq3cu3b8i5gAMLHky48FK/iBMrtmq4sePHkCNLnky5 suXLmDNr3szZ8eLPoEOLHk26tOnTqFOrXs26tevXsGPL7Ey7tu3buHPr3s27t+/fwIMLH04cruzj yJMrX878Y4AABZ//e06d+vTq0AdKj579IHaB2L+H//deneB2892vlyf/HXx699cNnm9OPz56+9y1 p58/Pz/8+wDip55+2VkHoIH/+fdff/bx9159pyH1XE4T2lPhThdeiFOFGmIYQFAdZvghhSOSuCF1 OnFYIogrqsiTiCcWJ+NTEp23HYP49Xfjg/otpGN3NvIo3ZBAQocjQg4m2OOCPEJYmoQlqhiehVGu eGKHL1rp4ZYxdrnlhDBi+VN4VWaZIoozpnlYjUYWSZ6SASq0noJMxtnjjvAFiWCceNIpoJOpJQVm mVmi2ZOYY2oZYnVcflnmoGZGaiKWi6ppKVmQenmmppsaVWmnGoqZ6ZUfUqollY5KyumlrAJF0Z44 Bv/5JkQ/KpjkgfsZWKt87xHJq5+A1gerkLn+Kqebft46oHsF9rpjscYmqOySdE4brF1KGUrllJ+a yKK23oarKXadlrstuCSSeyajqoob6qmtxivvvPTWa++9+Op07b78WpTvvwDP1e/ABDcU8MEIJ6zw wr8JIIBODkP8sMMUU2xPxBJfXLHFPGGc8cYPC+UxyCNzjJPHJ4fM8MpLlVyyxj69DLPIKucUscxA obwTxjyHrPPMLAeNVM89pxyzykXT3PHENf9ss8k7I+3z1EsLHbREDgtUsdYCcJ1Q1ll7zVDYBIHd 9UBkI5R22Wf/E7bZB61dMKBDT500yU2jjHdPP9//nHdQTutNdeA1W214zkwbnfTRfysdNdBOP161 xH5rjPPhCU+0tdsUo9123GnLDbpBZm++kNyis/322anPTV9SFad8+eOzH1115D/1XTjtVAON+e9L Ey217Ub7nvvulRulM+4zLw68wpqHTnbq07P+uULSi/3Q2q1zLvbqru+rlOCUb2y83yAfH3vxQ6Vv vOSyD//8/PTXb//9+GcW/v4F5+///wAMYGT4R0B+CfCACEygAr9SwAbSbYEQ3I0DJ0jBClrwghjM oAY3WMEIevCDIPwgB0dIwhKa8IQoTKEKV/iRELpQMyyMIbZeSMMa2vCGOMyhUmTIwx76MHw6DKIQ /4dIxCIa8YhI7MkPbfKBDzykiciBIk0AQEUq0kSKWHRiE7foxH9wUYtfLMgXwSgQKXqRi2dEoxnL qMYtDgSNbHSjQcaYRjamUY4EWSMcz/jGLlZkj3SM4xrtyEc+0jGLdxxkIgmJSJlYcSqNhOIgFVlI MfqRkV2c5CUryUlCFjKSm+ykHM1IyUqCso8WaaQnO2lJTIoyk2RMCCIl6cdSquSRBakiAASiyyry UpcDAeY/evnLYg5zl6j8ZCyT2co5hhKOitRkHp8Jy2kq05mWpCUzrblKWnqTlKPEYzdrSc6DnNKQ 1FSlOau5x1W2BJfBRKYV57lLehoznscs5iP3if/MPgYyjILkZjb1WM6BVnOa4BznNQ0a0IRiU6EO 1SY6qSlQhzYzkeEUJzjFmUxvPvQl8DSmPUcqz5L6kp+/DKlBwynLgl60ohQVaDPV+c1QvvKO22Qm QU3JzjBScqeetKU/AfpTl64zox91iUpRStJ85pOpJU1pP49KVJsG1abRZOlLWelKTmqzqK0EJFaN KtFrSjOpFhWqIKGZzoMiRJNnhUlIofrUekaVrk7Nq167ytWrrnOmbnVnKVV5zqwC1qjbPKdZe/rW wAJVpoTd5CxjKs3HylWYmLVrXX0pVc3mFZ4qjWwbNTrWNl7VjYccbRY36lK4ohaWiE0saWO52sD/ DnSrVeUmayVa04OeVZ0dcQsVlTJcBTbRcMelC0pU6hDmalCt9IHuEqdL3eryry3FBUp2k4hAiRAT Is4lSHgXko98CKS85zVvederXvP+A73sRa91YXOU7dYXAEKxb1HKixP+2oO//s2JfwGcD+4mzL7F HW4vE6zLnDTYHgw2yoAL/N8CB1jA6+0vhQ2cJu9ylq5Nras+owqR+K43vSceiHzfy975xmYpDI6w gvErY/xCmMY2ToqJJ9yTAF+YwweLsY1nfOMiF7nGS9kxhX9cYR4D+cA5zi6RiXzkIeMYJ/oVipMr vBMeM/nJ9eqlTqR85RlX0cFnNnKWg7JlE3OZ/8tuBnNwMjJeF9u5I3U2iZL3zOf43vnPgA60oAeN l0McYiSGJkmiCX2S+6Z5J2tmi6F1YuhJ96TSh8gJpi+daaFY2h6YtnSlcfJpUndazoOJsGFCDepO l9rUsBb1qTU961bvZNQ8mbSuM/3qV6N6LjWm8oMfbGSobBrWtr61q2vd61onm9LOlnWrff3sX28l IlC961RRuteLYHogi150Qb5NEHGD+9DjRne51X3ucx/a3O1mNEkcreoqj1nMXjm2tJWN7GrTmtah PnWzOT1taFs7MAiO8pXRTJZN79vgyaa2vyc+8FyP+tMSPzhbEs7w7ao60ktx+LKRLe2M+/rks/+m 9q6fnXGN7xC8U/2sSWeOz42E2t3qFje5A24QePu80vFOt0CAPnR2yxtQ8O5I0kGy9KPTp+k2N/pH oO70qlv96lgvTZ5rEvOsf4beIAf5TxYcFbHn2MEu1w22u46Qrbed7RYZrzC77fXT1Pm7mb2neLf9 4b77neafHaZ4BV93v4C9J/XG8sKzzHgcW1nxal445LEMYbRXPu24qQg97elUvHPWIKAFJi6zfVK4 p7Szhe8LjM8+eWFbec1khnzs7X3voNB4zJhXU+Jbv3iFj933tI+88D3O+ttbPve18bBzPf/58Ia+ 9Hv/ezxJfMy5pl71cBE7cVlvFO4j/zYscXv/cz8/EdNf//zor8v3057+rK///fCPv/znT/8Etv/+ +P9z/cGc/6rv/8n9F4ACOIAE2ED/d4AICEEFOGgJ2IAO+D8LKGgPOIEU+DwRGGgVSEQXCGgZ2IEe uDAbqH9GwQ8kSII4UYImeIIoyA85UYItyIL2YIIoGIMpmII06II6gYMyuII0qII+eIM2qII4CIQ7 mIM8KIRG6IIryIJH+IMUWINMCINQ2BNDWIQ/qINSCINUOIVB2INeaIVbeIVa6IReuBNVOIZlKIYv mIFcmIVk6INQGIRxGIVpyBMzCIZq2INdaIR5uIZ+yIdTyIeC+IVomHsRsYICQYKJyA+LWIID/6GI ivgPjkgQkYiCksiIkYgQlgiJltiIiOiJBlGJjHiJk5iJpJiJnPiIpdiJqDiKpnh9R9GGZ2iHdHiD ZuiGdxiFXbiDeCiETfiHvqiFuziGe9iLeoiGNhiIT4iLtViHS6iLxMiMYDiMQFiHRDiEwHiM2SiH yLiEt+iMwuiG73eIroiJ5biIBdGKl7iO6MiOq9iOqtiI7JiO5xiKoxiP7niP8DiP8PiKqUiJ9Zh/ sTiDZciLShiOhFiNcfiC2EiI0JiM4kiEtLiG3siDFYmQR3iR2LiHmBeCd/aBIBmSIjmSgOGRdjaQ fXiGBCmREPmNCXmRcJiRhUiSmBGIENmNg87ohNT4kjipjS5Jk5thk8w4iMWIkILYhrSojNkIlCVJ jksYj6aojvT4iQD5lKeoj604ifxokleBFM+IkdG4lC15i95ojQVZiBzJlJXxlcE4ltbolgwpk0kZ kUuplpahjG7JjT/JkXjZk8Zol4QxEaKIj/Poj5t4j6/YjlnpiINplYnJlZAZmQkBmJRZmZYJlJKZ mZq5HJe5QJv5maAZmqIJEp1Zmqb5GKOZmqq5mqzZmjx0mrAZm03pmrRZm1ghm7iZm2RhmySkm775 m1sREAA7 ------=_NextPart_000_0004_01C71310.AB59C4E0-- From helderlinsbambam@ig.com.br Tue Nov 28 12:12:10 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6V8-0001HL-HQ; Tue, 28 Nov 2006 12:12:10 -0500 Received: from clw215.neoplus.adsl.tpnet.pl ([83.31.124.215]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gp6V4-0007D7-5U; Tue, 28 Nov 2006 12:12:10 -0500 Received: from 200.226.132.20 (HELO mx.ig.com.br) by lists.ietf.org with esmtp (DH0056@B?D3 6S>R4S) id J,9IQ1-NP5;,M-P7 for iporpr-archive@lists.ietf.org; Tue, 28 Nov 2006 17:12:06 -0060 Date: Tue, 28 Nov 2006 17:12:06 -0060 From: Christmas gifts X-Mailer: The Bat! (v3.80.03) UNREG / CD5BF9353B3B7091 X-Priority: 3 (Normal) Message-ID: <598159942.21044485224255@thebat.net> To: iporpr-archive@lists.ietf.org Subject: Nice replica for xmas MIME-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Spam-Score: 4.1 (++++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Christmas gifts! President Omar al-Bashir told state TV: "The government of Sudan welcomes all financial, material, logistic or technical assistance from the UN in order to strengthen the AU mission in Darfur." Sudan has always rejected plans to replace the AU force with a larger, stronger UN mission. He told the BBC there would be no UN troops. His Foreign Minister Lam Akol specified that "there should be no talk about a mixed force".

Louis Vuitton, Chanel, Hermes, Tiffany & Co. and More

Handbags, Wallets, Bracelets, Tons of Accessories

HURRY! Special Ends Soon!


Buy nice replica for Christmas


President Omar al-Bashir told state TV: "The government of Sudan welcomes all financial, material, logistic or technical assistance from the UN in order to strengthen the AU mission in Darfur." From mauritsniven@dpbonline.com Wed Nov 29 16:05:08 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWc8-0005E1-2j for ipfix-archive@lists.ietf.org; Wed, 29 Nov 2006 16:05:08 -0500 Received: from p508b766c.dip.t-dialin.net ([80.139.118.108] helo=fnfmffgbc) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpWc5-0005aN-Bt for ipfix-archive@lists.ietf.org; Wed, 29 Nov 2006 16:05:08 -0500 Message-ID: <00ad01c713f3.4a6d3480.3378c0a8@hasty> Date: Wed, 29 Nov 2006 20:16:45 +0000 From: bruno klarrisa User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: lisette jecho Subject: elset Content-Type: multipart/alternative; boundary="---------000000B9.01C713F3" X-Spam-Score: 2.4 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 This is a multi-part message in MIME format. -----------000000B9.01C713F3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Become a SUPERLOVER tonight! http://negys.com/et/ was ready. An their legs and controlled their mounts -----------000000B9.01C713F3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Become a SUPERLOVER tonight!
http://negys.com/et/
was ready. An
their legs and controlled their mounts
-----------000000B9.01C713F3-- From ipfix-bounces@ietf.org Thu Nov 30 09:44:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn7Q-0007mu-RQ; Thu, 30 Nov 2006 09:42:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn7Q-0007mC-5E for ipfix@ietf.org; Thu, 30 Nov 2006 09:42:32 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpn7O-0007Lm-Og for ipfix@ietf.org; Thu, 30 Nov 2006 09:42:32 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kAUEgJt13629; Thu, 30 Nov 2006 15:42:19 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [IPFIX] IPv6 care-of and home address Date: Thu, 30 Nov 2006 15:41:48 +0100 Message-ID: <70524A4436C03E43A293958B505008B6568E8C@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPv6 care-of and home address Thread-Index: AccCu/1P19w9K/rxTUWXj+wwrASSKQRzuf+Q From: "Schmoll, Carsten" To: "Andrew Johnson" , "Juergen Quittek" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, we are currently investigating on a prototype to send accounted IP flow information in a mobile IPv6 environment. For reasons of simplicity and speed we usually export the care-of address (CoA) and the correspondent node's IP address as sourceIPv6Address and destinationIPv6Address.=20 In case of multiple users on one terminal however (or one user making use of multiple of his identities) we'll have to capture and export the home address (HoA) too. The HoA is embedded in an IPv6 extension header of either type Routing EH (43) or the Destination Options EH (60). This would result then in a flow record with two IPv6 source addresses. Even though repetition of the sourceIPv6 address is legal I would like to propose additional IEs to avoid ambiguity. These could be: sourceIPv6CareOfAddress =20 sourceIPv6HomeAddress destinationIPv6CareOfAddress =20 destinationIPv6HomeAddress This would also cover the case where both endpoints of a=20 communication are mobile nodes. What do you think? Best regards, Carsten. =20 > -----Original Message----- > From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > Sent: Tuesday, November 07, 2006 11:27 PM > To: Juergen Quittek > Cc: Schmoll, Carsten; ipfix@ietf.org > Subject: Re: [IPFIX] IPv6 care-of and home address >=20 > Juergen Quittek wrote: > > Carsten, > >=20 > > I do understand how these addresses are associated with > > an interface. But how do you think are they associated > > with a certain flow? >=20 > That really depends on the common properties that define > Carsten's flow. Perhaps these different properties could > part of an Option Template Record that provides information > on an interface. >=20 > However, it seems that "The IPv6 source address in the IP > packet header" is the wrong element to use these and new > ones should be requested if there is an application in > mind. >=20 >=20 > regards >=20 > Andrew >=20 >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 09:44:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn7Q-0007mu-RQ; Thu, 30 Nov 2006 09:42:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpn7Q-0007mC-5E for ipfix@ietf.org; Thu, 30 Nov 2006 09:42:32 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpn7O-0007Lm-Og for ipfix@ietf.org; Thu, 30 Nov 2006 09:42:32 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kAUEgJt13629; Thu, 30 Nov 2006 15:42:19 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [IPFIX] IPv6 care-of and home address Date: Thu, 30 Nov 2006 15:41:48 +0100 Message-ID: <70524A4436C03E43A293958B505008B6568E8C@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPv6 care-of and home address Thread-Index: AccCu/1P19w9K/rxTUWXj+wwrASSKQRzuf+Q From: "Schmoll, Carsten" To: "Andrew Johnson" , "Juergen Quittek" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Dear all, we are currently investigating on a prototype to send accounted IP flow information in a mobile IPv6 environment. For reasons of simplicity and speed we usually export the care-of address (CoA) and the correspondent node's IP address as sourceIPv6Address and destinationIPv6Address.=20 In case of multiple users on one terminal however (or one user making use of multiple of his identities) we'll have to capture and export the home address (HoA) too. The HoA is embedded in an IPv6 extension header of either type Routing EH (43) or the Destination Options EH (60). This would result then in a flow record with two IPv6 source addresses. Even though repetition of the sourceIPv6 address is legal I would like to propose additional IEs to avoid ambiguity. These could be: sourceIPv6CareOfAddress =20 sourceIPv6HomeAddress destinationIPv6CareOfAddress =20 destinationIPv6HomeAddress This would also cover the case where both endpoints of a=20 communication are mobile nodes. What do you think? Best regards, Carsten. =20 > -----Original Message----- > From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > Sent: Tuesday, November 07, 2006 11:27 PM > To: Juergen Quittek > Cc: Schmoll, Carsten; ipfix@ietf.org > Subject: Re: [IPFIX] IPv6 care-of and home address >=20 > Juergen Quittek wrote: > > Carsten, > >=20 > > I do understand how these addresses are associated with > > an interface. But how do you think are they associated > > with a certain flow? >=20 > That really depends on the common properties that define > Carsten's flow. Perhaps these different properties could > part of an Option Template Record that provides information > on an interface. >=20 > However, it seems that "The IPv6 source address in the IP > packet header" is the wrong element to use these and new > ones should be requested if there is an application in > mind. >=20 >=20 > regards >=20 > Andrew >=20 >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 10:08:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpnW4-0000eq-5k; Thu, 30 Nov 2006 10:08:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpnW2-0000ej-Ur for ipfix@ietf.org; Thu, 30 Nov 2006 10:07:58 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpnW1-00024e-K3 for ipfix@ietf.org; Thu, 30 Nov 2006 10:07:58 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2006 16:07:57 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAUF7uwr030634; Thu, 30 Nov 2006 16:07: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 kAUF7uAJ008180; Thu, 30 Nov 2006 16:07:56 +0100 (MET) Received: from [144.254.153.26] (dhcp-144-254-153-26.cisco.com [144.254.153.26]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA01382; Thu, 30 Nov 2006 15:07:55 GMT Message-ID: <456EF3CB.2060803@cisco.com> Date: Thu, 30 Nov 2006 15:07:55 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Schmoll, Carsten" Subject: Re: [IPFIX] IPv6 care-of and home address References: <70524A4436C03E43A293958B505008B6568E8C@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B6568E8C@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2319; t=1164899276; x=1165763276; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20IPv6=20care-of=20and=20home=20address |Sender:=20; bh=N1wXylMRYP/p59DccwxYa00Oe9WZp4Jw7VUWdWvCRnI=; b=RGC3qWITHSXNhBp7207snPjHDXpCJ3MJcfTDWYjbh3urMcb50+RyZ6mIUsinCid3c2BLH6eE Tc/SBGYuKDzlPgRQu/w4XUKKT/NDgwOP4HrfRCx9R33/TA6+Q7GZo1n7; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Carsten The Routing EH and Destination EH have the source and destination Home Addresses in them, so new new fields for them make sense. The Care of Addresses are just from the IPv6 header, so why do you need new types for them? regards Andrew Schmoll, Carsten wrote: > Dear all, > > we are currently investigating on a prototype to send > accounted IP flow information in a mobile IPv6 environment. > > For reasons of simplicity and speed we usually export the > care-of address (CoA) and the correspondent node's IP > address as sourceIPv6Address and destinationIPv6Address. > > In case of multiple users on one terminal however (or one > user making use of multiple of his identities) we'll have > to capture and export the home address (HoA) too. The HoA > is embedded in an IPv6 extension header of either type > Routing EH (43) or the Destination Options EH (60). > > This would result then in a flow record with two IPv6 source > addresses. Even though repetition of the sourceIPv6 address > is legal I would like to propose additional IEs to avoid > ambiguity. These could be: > > sourceIPv6CareOfAddress > sourceIPv6HomeAddress > destinationIPv6CareOfAddress > destinationIPv6HomeAddress > > This would also cover the case where both endpoints of a > communication are mobile nodes. > > What do you think? > > Best regards, > Carsten. > > >> -----Original Message----- >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> Sent: Tuesday, November 07, 2006 11:27 PM >> To: Juergen Quittek >> Cc: Schmoll, Carsten; ipfix@ietf.org >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> Juergen Quittek wrote: >>> Carsten, >>> >>> I do understand how these addresses are associated with >>> an interface. But how do you think are they associated >>> with a certain flow? >> That really depends on the common properties that define >> Carsten's flow. Perhaps these different properties could >> part of an Option Template Record that provides information >> on an interface. >> >> However, it seems that "The IPv6 source address in the IP >> packet header" is the wrong element to use these and new >> ones should be requested if there is an application in >> mind. >> >> >> regards >> >> Andrew >> >> _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 10:08:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpnW4-0000eq-5k; Thu, 30 Nov 2006 10:08:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpnW2-0000ej-Ur for ipfix@ietf.org; Thu, 30 Nov 2006 10:07:58 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpnW1-00024e-K3 for ipfix@ietf.org; Thu, 30 Nov 2006 10:07:58 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2006 16:07:57 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAUF7uwr030634; Thu, 30 Nov 2006 16:07: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 kAUF7uAJ008180; Thu, 30 Nov 2006 16:07:56 +0100 (MET) Received: from [144.254.153.26] (dhcp-144-254-153-26.cisco.com [144.254.153.26]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA01382; Thu, 30 Nov 2006 15:07:55 GMT Message-ID: <456EF3CB.2060803@cisco.com> Date: Thu, 30 Nov 2006 15:07:55 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Schmoll, Carsten" Subject: Re: [IPFIX] IPv6 care-of and home address References: <70524A4436C03E43A293958B505008B6568E8C@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B6568E8C@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2319; t=1164899276; x=1165763276; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20IPv6=20care-of=20and=20home=20address |Sender:=20; bh=N1wXylMRYP/p59DccwxYa00Oe9WZp4Jw7VUWdWvCRnI=; b=RGC3qWITHSXNhBp7207snPjHDXpCJ3MJcfTDWYjbh3urMcb50+RyZ6mIUsinCid3c2BLH6eE Tc/SBGYuKDzlPgRQu/w4XUKKT/NDgwOP4HrfRCx9R33/TA6+Q7GZo1n7; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Hi Carsten The Routing EH and Destination EH have the source and destination Home Addresses in them, so new new fields for them make sense. The Care of Addresses are just from the IPv6 header, so why do you need new types for them? regards Andrew Schmoll, Carsten wrote: > Dear all, > > we are currently investigating on a prototype to send > accounted IP flow information in a mobile IPv6 environment. > > For reasons of simplicity and speed we usually export the > care-of address (CoA) and the correspondent node's IP > address as sourceIPv6Address and destinationIPv6Address. > > In case of multiple users on one terminal however (or one > user making use of multiple of his identities) we'll have > to capture and export the home address (HoA) too. The HoA > is embedded in an IPv6 extension header of either type > Routing EH (43) or the Destination Options EH (60). > > This would result then in a flow record with two IPv6 source > addresses. Even though repetition of the sourceIPv6 address > is legal I would like to propose additional IEs to avoid > ambiguity. These could be: > > sourceIPv6CareOfAddress > sourceIPv6HomeAddress > destinationIPv6CareOfAddress > destinationIPv6HomeAddress > > This would also cover the case where both endpoints of a > communication are mobile nodes. > > What do you think? > > Best regards, > Carsten. > > >> -----Original Message----- >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> Sent: Tuesday, November 07, 2006 11:27 PM >> To: Juergen Quittek >> Cc: Schmoll, Carsten; ipfix@ietf.org >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> Juergen Quittek wrote: >>> Carsten, >>> >>> I do understand how these addresses are associated with >>> an interface. But how do you think are they associated >>> with a certain flow? >> That really depends on the common properties that define >> Carsten's flow. Perhaps these different properties could >> part of an Option Template Record that provides information >> on an interface. >> >> However, it seems that "The IPv6 source address in the IP >> packet header" is the wrong element to use these and new >> ones should be requested if there is an application in >> mind. >> >> >> regards >> >> Andrew >> >> _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From fbffgbdg@carlosokellys.com Thu Nov 30 10:29:34 2006 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpnqw-0000SI-3M for ipfix-archive@lists.ietf.org; Thu, 30 Nov 2006 10:29:34 -0500 Received: from 53533a9e.cable.casema.nl ([83.83.58.158] helo=SNNECCI) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gpnqs-0000Vj-Fy for ipfix-archive@lists.ietf.org; Thu, 30 Nov 2006 10:29:33 -0500 Date: Thu, 30 Nov 2006 15:29:29 -0060 From: Christmas gifts X-Mailer: The Bat! (v3.0) Home Reply-To: fbffgbdg X-Priority: 3 (Normal) Message-ID: <866702407.20061130152929@carlosokellys.com> To: ipfix-archive@lists.ietf.org Subject: Nice replica for xmas MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.3 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f A bipartisan panel on Iraq is finalizing recommedations on Iraq. The group = led by former Secretary of State James Baker III and former Rep. Lee Hamilt= on, D-Ind., plan to present ideas to Bush next month.A bipartisan panel on = Iraq is finalizing recommedations on Iraq. The group led by former Secretar= y of State James Baker III and former Rep. Lee Hamilton, D-Ind., plan to pr= esent ideas to Bush next month.A bipartisan panel on Iraq is finalizing rec= ommedations on Iraq. The group led by former Secretary of State James Baker= III and former Rep. Lee Hamilton, D-Ind., plan to present ideas to Bush ne= xt month.Bush pushed back against skeptics of his goal of spreading freedom= across the Middle East. "I understand these doubts but I do not share them= ," the president said."Defeating them will require the full commitment of o= ur alliance," Bush said.

LUXURY REPLICAS with warranty
25% off or Free Shipping

WATCHES =95 TIES =95 JEWELRY =95 HANDBAGS =95 AND MORE
~-~-~-~-~-~-~-~-~-~-~-~-
Rolex =95 Cartier =95 Bvlgari
Versace =95 Fendi =95 Armani
Chanel =95 Louis Vuitton =95 Hermes

Best gifts for Christ= mas!

A bipartisan panel on Iraq is finalizing recommedations on Iraq. The group = led by former Secretary of State James Baker III and former Rep. Lee Hamilt= on, D-Ind., plan to present ideas to Bush next month. From ipfix-bounces@ietf.org Thu Nov 30 10:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpnzn-0001G6-BW; Thu, 30 Nov 2006 10:38:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpnzl-0001DE-QO for ipfix@ietf.org; Thu, 30 Nov 2006 10:38:41 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpnzj-0005to-Bf for ipfix@ietf.org; Thu, 30 Nov 2006 10:38:41 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kAUFcat20797; Thu, 30 Nov 2006 16:38:36 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [IPFIX] IPv6 care-of and home address Date: Thu, 30 Nov 2006 16:38:06 +0100 Message-ID: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPv6 care-of and home address Thread-Index: AccUkVoMspyD9x7JSA+zUFYZOr/OzwAAhwxw From: "Schmoll, Carsten" To: "Andrew Johnson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, I was wondering what "kind of" IP address my collector will receive when there is only=20 sourceIPv6Address in the accounting flow record. But I agree now that we should say that=20 in a mobile environment an sourceIPv6Address will always denote the care-of address from the usual place in the IPv6 header. We probably want to note this in the info model. So I change my proposal to just request: sourceIPv6HomeAddress destinationIPv6HomeAddress J=FCrgen: do you agree too? May a write some short text for the info model on that? Best regards, Carsten. =20 > -----Original Message----- > From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > Sent: Thursday, November 30, 2006 4:08 PM > To: Schmoll, Carsten > Cc: Juergen Quittek; ipfix@ietf.org > Subject: Re: [IPFIX] IPv6 care-of and home address >=20 > Hi Carsten >=20 > The Routing EH and Destination EH have the source and > destination Home Addresses in them, so new new fields > for them make sense. >=20 > The Care of Addresses are just from the IPv6 header, so > why do you need new types for them? >=20 > regards >=20 > Andrew >=20 >=20 > Schmoll, Carsten wrote: > > Dear all, > >=20 > > we are currently investigating on a prototype to send > > accounted IP flow information in a mobile IPv6 environment. > >=20 > > For reasons of simplicity and speed we usually export the > > care-of address (CoA) and the correspondent node's IP > > address as sourceIPv6Address and destinationIPv6Address.=20 > >=20 > > In case of multiple users on one terminal however (or one > > user making use of multiple of his identities) we'll have > > to capture and export the home address (HoA) too. The HoA > > is embedded in an IPv6 extension header of either type > > Routing EH (43) or the Destination Options EH (60). > >=20 > > This would result then in a flow record with two IPv6 source > > addresses. Even though repetition of the sourceIPv6 address > > is legal I would like to propose additional IEs to avoid > > ambiguity. These could be: > >=20 > > sourceIPv6CareOfAddress =20 > > sourceIPv6HomeAddress > > destinationIPv6CareOfAddress =20 > > destinationIPv6HomeAddress > >=20 > > This would also cover the case where both endpoints of a=20 > > communication are mobile nodes. > >=20 > > What do you think? > >=20 > > Best regards, > > Carsten. > >=20 > > =20 > >> -----Original Message----- > >> From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > >> Sent: Tuesday, November 07, 2006 11:27 PM > >> To: Juergen Quittek > >> Cc: Schmoll, Carsten; ipfix@ietf.org > >> Subject: Re: [IPFIX] IPv6 care-of and home address > >> > >> Juergen Quittek wrote: > >>> Carsten, > >>> > >>> I do understand how these addresses are associated with > >>> an interface. But how do you think are they associated > >>> with a certain flow? > >> That really depends on the common properties that define > >> Carsten's flow. Perhaps these different properties could > >> part of an Option Template Record that provides information > >> on an interface. > >> > >> However, it seems that "The IPv6 source address in the IP > >> packet header" is the wrong element to use these and new > >> ones should be requested if there is an application in > >> mind. > >> > >> > >> regards > >> > >> Andrew > >> > >> >=20 >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 10:39:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpnzn-0001G6-BW; Thu, 30 Nov 2006 10:38:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpnzl-0001DE-QO for ipfix@ietf.org; Thu, 30 Nov 2006 10:38:41 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpnzj-0005to-Bf for ipfix@ietf.org; Thu, 30 Nov 2006 10:38:41 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kAUFcat20797; Thu, 30 Nov 2006 16:38:36 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [IPFIX] IPv6 care-of and home address Date: Thu, 30 Nov 2006 16:38:06 +0100 Message-ID: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] IPv6 care-of and home address Thread-Index: AccUkVoMspyD9x7JSA+zUFYZOr/OzwAAhwxw From: "Schmoll, Carsten" To: "Andrew Johnson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Andrew, I was wondering what "kind of" IP address my collector will receive when there is only=20 sourceIPv6Address in the accounting flow record. But I agree now that we should say that=20 in a mobile environment an sourceIPv6Address will always denote the care-of address from the usual place in the IPv6 header. We probably want to note this in the info model. So I change my proposal to just request: sourceIPv6HomeAddress destinationIPv6HomeAddress J=FCrgen: do you agree too? May a write some short text for the info model on that? Best regards, Carsten. =20 > -----Original Message----- > From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > Sent: Thursday, November 30, 2006 4:08 PM > To: Schmoll, Carsten > Cc: Juergen Quittek; ipfix@ietf.org > Subject: Re: [IPFIX] IPv6 care-of and home address >=20 > Hi Carsten >=20 > The Routing EH and Destination EH have the source and > destination Home Addresses in them, so new new fields > for them make sense. >=20 > The Care of Addresses are just from the IPv6 header, so > why do you need new types for them? >=20 > regards >=20 > Andrew >=20 >=20 > Schmoll, Carsten wrote: > > Dear all, > >=20 > > we are currently investigating on a prototype to send > > accounted IP flow information in a mobile IPv6 environment. > >=20 > > For reasons of simplicity and speed we usually export the > > care-of address (CoA) and the correspondent node's IP > > address as sourceIPv6Address and destinationIPv6Address.=20 > >=20 > > In case of multiple users on one terminal however (or one > > user making use of multiple of his identities) we'll have > > to capture and export the home address (HoA) too. The HoA > > is embedded in an IPv6 extension header of either type > > Routing EH (43) or the Destination Options EH (60). > >=20 > > This would result then in a flow record with two IPv6 source > > addresses. Even though repetition of the sourceIPv6 address > > is legal I would like to propose additional IEs to avoid > > ambiguity. These could be: > >=20 > > sourceIPv6CareOfAddress =20 > > sourceIPv6HomeAddress > > destinationIPv6CareOfAddress =20 > > destinationIPv6HomeAddress > >=20 > > This would also cover the case where both endpoints of a=20 > > communication are mobile nodes. > >=20 > > What do you think? > >=20 > > Best regards, > > Carsten. > >=20 > > =20 > >> -----Original Message----- > >> From: Andrew Johnson [mailto:andrjohn@cisco.com]=20 > >> Sent: Tuesday, November 07, 2006 11:27 PM > >> To: Juergen Quittek > >> Cc: Schmoll, Carsten; ipfix@ietf.org > >> Subject: Re: [IPFIX] IPv6 care-of and home address > >> > >> Juergen Quittek wrote: > >>> Carsten, > >>> > >>> I do understand how these addresses are associated with > >>> an interface. But how do you think are they associated > >>> with a certain flow? > >> That really depends on the common properties that define > >> Carsten's flow. Perhaps these different properties could > >> part of an Option Template Record that provides information > >> on an interface. > >> > >> However, it seems that "The IPv6 source address in the IP > >> packet header" is the wrong element to use these and new > >> ones should be requested if there is an application in > >> mind. > >> > >> > >> regards > >> > >> Andrew > >> > >> >=20 >=20 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 11:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoOS-0003Ej-IB; Thu, 30 Nov 2006 11:04:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoOQ-0003Ec-Uy for ipfix@ietf.org; Thu, 30 Nov 2006 11:04:10 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpoOP-0000Nl-IL for ipfix@ietf.org; Thu, 30 Nov 2006 11:04:10 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kAUG48t25139 for ; Thu, 30 Nov 2006 17:04:08 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 17:03:38 +0100 Message-ID: <70524A4436C03E43A293958B505008B6568EA3@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notes on IPFIX testing draft from Interop event Thread-Index: AccUmRjCf2uFGk4NRBGOc6aEu2k+/A== From: "Schmoll, Carsten" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [IPFIX] notes on IPFIX testing draft from Interop event X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Dear all, =20 at the IPFIX Interop event in Berlin which was held yesterday and today we briefly scanned (among other work) the IPFIX testing draft. We propose to extend the draft with a few more example test packets in ASCII art style to clarify the tests. The test packets should also be made available online (e.g. as a tarball of binary data, 1 file per packet). Of course such tarball may contain more packets then=20 we have space for in the testing draft. The suggested sections for an ASCII art-style example=20 packet are: * 3.2.2 * 3.3.x * 3.4.3/4/5/6 * 3.6.4/5/8/11 We're open to discuss this list and are looking for people who would volunteer to 'paint' one or the other test packet for the draft. Best regards, Carsten. =20 =20 -- "The difference between theory and practice is that in theory theory and practice are the same but in practice they are not." Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. ANTS for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 11:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoOS-0003Ej-IB; Thu, 30 Nov 2006 11:04:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoOQ-0003Ec-Uy for ipfix@ietf.org; Thu, 30 Nov 2006 11:04:10 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpoOP-0000Nl-IL for ipfix@ietf.org; Thu, 30 Nov 2006 11:04:10 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id kAUG48t25139 for ; Thu, 30 Nov 2006 17:04:08 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Nov 2006 17:03:38 +0100 Message-ID: <70524A4436C03E43A293958B505008B6568EA3@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: notes on IPFIX testing draft from Interop event Thread-Index: AccUmRjCf2uFGk4NRBGOc6aEu2k+/A== From: "Schmoll, Carsten" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [IPFIX] notes on IPFIX testing draft from Interop event X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org =20 Dear all, =20 at the IPFIX Interop event in Berlin which was held yesterday and today we briefly scanned (among other work) the IPFIX testing draft. We propose to extend the draft with a few more example test packets in ASCII art style to clarify the tests. The test packets should also be made available online (e.g. as a tarball of binary data, 1 file per packet). Of course such tarball may contain more packets then=20 we have space for in the testing draft. The suggested sections for an ASCII art-style example=20 packet are: * 3.2.2 * 3.3.x * 3.4.3/4/5/6 * 3.6.4/5/8/11 We're open to discuss this list and are looking for people who would volunteer to 'paint' one or the other test packet for the draft. Best regards, Carsten. =20 =20 -- "The difference between theory and practice is that in theory theory and practice are the same but in practice they are not." Dipl.Ing. Carsten Schmoll Fraunhofer Institute FOKUS schmoll@fokus.fraunhofer.de National Research Institute Fraunhofer FOKUS / dept. ANTS for Open Communication Systems Tel: +49-30-3463-7136 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8000 D-10589 Berlin, Germany _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 13:50:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqyX-0000GV-E0; Thu, 30 Nov 2006 13:49:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqyV-0000Cw-Bv for ipfix@ietf.org; Thu, 30 Nov 2006 13:49:35 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqyT-0004d7-W1 for ipfix@ietf.org; Thu, 30 Nov 2006 13:49:35 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2006 19:49:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAUInWPd032299; Thu, 30 Nov 2006 19:49:33 +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 kAUInWAJ026458; Thu, 30 Nov 2006 19:49:32 +0100 (MET) Received: from [144.254.153.59] (dhcp-144-254-153-59.cisco.com [144.254.153.59]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA24923; Thu, 30 Nov 2006 18:49:31 GMT Message-ID: <456F27B9.5010809@cisco.com> Date: Thu, 30 Nov 2006 18:49:29 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Schmoll, Carsten" Subject: Re: [IPFIX] IPv6 care-of and home address References: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3752; t=1164912573; x=1165776573; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20IPv6=20care-of=20and=20home=20address |Sender:=20; bh=LkSnhIAsph3rrE+6C3TkUNUpKfJZCw94yGI3kzSclEQ=; b=ZH7FVAYZlFmPUTzIYekKxa2REtpRJ5SAO4BB/Ydd5yjqYKAekLkoV95jq8Y9G3otWUWp72PU IA08wxZewzrfyA4N62uhHjeA527577tk5gcDNq+M/jJ8DxY0laGBAmH7; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Schmoll, Carsten wrote: > Andrew, > > I was wondering what "kind of" IP address my > collector will receive when there is only > sourceIPv6Address in the accounting flow record. > > But I agree now that we should say that > in a mobile environment an sourceIPv6Address > will always denote the care-of address from > the usual place in the IPv6 header. > > We probably want to note this in the info model. > > So I change my proposal to just request: > > sourceIPv6HomeAddress > destinationIPv6HomeAddress The address from the IPv6 routing header is not specifically a "Home Address" is it? While the Mobile IPv6 environment conceptualises it this way, you really are collecting is an Ipv6RoutingHeaderIpv6Address. Similarly for the Destination Extension header. I'm not sure about the names there, but you get the idea. Cheers Andrew > Jürgen: do you agree too? > May a write some short text for the info model on that? > > Best regards, > Carsten. > > >> -----Original Message----- >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> Sent: Thursday, November 30, 2006 4:08 PM >> To: Schmoll, Carsten >> Cc: Juergen Quittek; ipfix@ietf.org >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> Hi Carsten >> >> The Routing EH and Destination EH have the source and >> destination Home Addresses in them, so new new fields >> for them make sense. >> >> The Care of Addresses are just from the IPv6 header, so >> why do you need new types for them? >> >> regards >> >> Andrew >> >> >> Schmoll, Carsten wrote: >>> Dear all, >>> >>> we are currently investigating on a prototype to send >>> accounted IP flow information in a mobile IPv6 environment. >>> >>> For reasons of simplicity and speed we usually export the >>> care-of address (CoA) and the correspondent node's IP >>> address as sourceIPv6Address and destinationIPv6Address. >>> >>> In case of multiple users on one terminal however (or one >>> user making use of multiple of his identities) we'll have >>> to capture and export the home address (HoA) too. The HoA >>> is embedded in an IPv6 extension header of either type >>> Routing EH (43) or the Destination Options EH (60). >>> >>> This would result then in a flow record with two IPv6 source >>> addresses. Even though repetition of the sourceIPv6 address >>> is legal I would like to propose additional IEs to avoid >>> ambiguity. These could be: >>> >>> sourceIPv6CareOfAddress >>> sourceIPv6HomeAddress >>> destinationIPv6CareOfAddress >>> destinationIPv6HomeAddress >>> >>> This would also cover the case where both endpoints of a >>> communication are mobile nodes. >>> >>> What do you think? >>> >>> Best regards, >>> Carsten. >>> >>> >>>> -----Original Message----- >>>> From: Andrew Johnson [mailto:andrjohn@cisco.com] >>>> Sent: Tuesday, November 07, 2006 11:27 PM >>>> To: Juergen Quittek >>>> Cc: Schmoll, Carsten; ipfix@ietf.org >>>> Subject: Re: [IPFIX] IPv6 care-of and home address >>>> >>>> Juergen Quittek wrote: >>>>> Carsten, >>>>> >>>>> I do understand how these addresses are associated with >>>>> an interface. But how do you think are they associated >>>>> with a certain flow? >>>> That really depends on the common properties that define >>>> Carsten's flow. Perhaps these different properties could >>>> part of an Option Template Record that provides information >>>> on an interface. >>>> >>>> However, it seems that "The IPv6 source address in the IP >>>> packet header" is the wrong element to use these and new >>>> ones should be requested if there is an application in >>>> mind. >>>> >>>> >>>> regards >>>> >>>> Andrew >>>> >>>> >> _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 13:50:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqyX-0000GV-E0; Thu, 30 Nov 2006 13:49:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpqyV-0000Cw-Bv for ipfix@ietf.org; Thu, 30 Nov 2006 13:49:35 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpqyT-0004d7-W1 for ipfix@ietf.org; Thu, 30 Nov 2006 13:49:35 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2006 19:49:34 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAUInWPd032299; Thu, 30 Nov 2006 19:49:33 +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 kAUInWAJ026458; Thu, 30 Nov 2006 19:49:32 +0100 (MET) Received: from [144.254.153.59] (dhcp-144-254-153-59.cisco.com [144.254.153.59]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA24923; Thu, 30 Nov 2006 18:49:31 GMT Message-ID: <456F27B9.5010809@cisco.com> Date: Thu, 30 Nov 2006 18:49:29 +0000 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Schmoll, Carsten" Subject: Re: [IPFIX] IPv6 care-of and home address References: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> In-Reply-To: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3752; t=1164912573; x=1165776573; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:=20Andrew=20Johnson=20 |Subject:=20Re=3A=20[IPFIX]=20IPv6=20care-of=20and=20home=20address |Sender:=20; bh=LkSnhIAsph3rrE+6C3TkUNUpKfJZCw94yGI3kzSclEQ=; b=ZH7FVAYZlFmPUTzIYekKxa2REtpRJ5SAO4BB/Ydd5yjqYKAekLkoV95jq8Y9G3otWUWp72PU IA08wxZewzrfyA4N62uhHjeA527577tk5gcDNq+M/jJ8DxY0laGBAmH7; Authentication-Results: ams-dkim-2; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Schmoll, Carsten wrote: > Andrew, > > I was wondering what "kind of" IP address my > collector will receive when there is only > sourceIPv6Address in the accounting flow record. > > But I agree now that we should say that > in a mobile environment an sourceIPv6Address > will always denote the care-of address from > the usual place in the IPv6 header. > > We probably want to note this in the info model. > > So I change my proposal to just request: > > sourceIPv6HomeAddress > destinationIPv6HomeAddress The address from the IPv6 routing header is not specifically a "Home Address" is it? While the Mobile IPv6 environment conceptualises it this way, you really are collecting is an Ipv6RoutingHeaderIpv6Address. Similarly for the Destination Extension header. I'm not sure about the names there, but you get the idea. Cheers Andrew > Jürgen: do you agree too? > May a write some short text for the info model on that? > > Best regards, > Carsten. > > >> -----Original Message----- >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> Sent: Thursday, November 30, 2006 4:08 PM >> To: Schmoll, Carsten >> Cc: Juergen Quittek; ipfix@ietf.org >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> Hi Carsten >> >> The Routing EH and Destination EH have the source and >> destination Home Addresses in them, so new new fields >> for them make sense. >> >> The Care of Addresses are just from the IPv6 header, so >> why do you need new types for them? >> >> regards >> >> Andrew >> >> >> Schmoll, Carsten wrote: >>> Dear all, >>> >>> we are currently investigating on a prototype to send >>> accounted IP flow information in a mobile IPv6 environment. >>> >>> For reasons of simplicity and speed we usually export the >>> care-of address (CoA) and the correspondent node's IP >>> address as sourceIPv6Address and destinationIPv6Address. >>> >>> In case of multiple users on one terminal however (or one >>> user making use of multiple of his identities) we'll have >>> to capture and export the home address (HoA) too. The HoA >>> is embedded in an IPv6 extension header of either type >>> Routing EH (43) or the Destination Options EH (60). >>> >>> This would result then in a flow record with two IPv6 source >>> addresses. Even though repetition of the sourceIPv6 address >>> is legal I would like to propose additional IEs to avoid >>> ambiguity. These could be: >>> >>> sourceIPv6CareOfAddress >>> sourceIPv6HomeAddress >>> destinationIPv6CareOfAddress >>> destinationIPv6HomeAddress >>> >>> This would also cover the case where both endpoints of a >>> communication are mobile nodes. >>> >>> What do you think? >>> >>> Best regards, >>> Carsten. >>> >>> >>>> -----Original Message----- >>>> From: Andrew Johnson [mailto:andrjohn@cisco.com] >>>> Sent: Tuesday, November 07, 2006 11:27 PM >>>> To: Juergen Quittek >>>> Cc: Schmoll, Carsten; ipfix@ietf.org >>>> Subject: Re: [IPFIX] IPv6 care-of and home address >>>> >>>> Juergen Quittek wrote: >>>>> Carsten, >>>>> >>>>> I do understand how these addresses are associated with >>>>> an interface. But how do you think are they associated >>>>> with a certain flow? >>>> That really depends on the common properties that define >>>> Carsten's flow. Perhaps these different properties could >>>> part of an Option Template Record that provides information >>>> on an interface. >>>> >>>> However, it seems that "The IPv6 source address in the IP >>>> packet header" is the wrong element to use these and new >>>> ones should be requested if there is an application in >>>> mind. >>>> >>>> >>>> regards >>>> >>>> Andrew >>>> >>>> >> _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 17:23:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuIH-00053I-Ud; Thu, 30 Nov 2006 17:22:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuIG-000532-Lp for ipfix@ietf.org; Thu, 30 Nov 2006 17:22:12 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpuIE-0002h2-2A for ipfix@ietf.org; Thu, 30 Nov 2006 17:22:12 -0500 Received: from [192.168.1.128] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8B96513CF82; Thu, 30 Nov 2006 23:26:02 +0100 (CET) Date: Thu, 30 Nov 2006 23:22:01 +0100 From: Juergen Quittek To: "Schmoll, Carsten" , Andrew Johnson Subject: RE: [IPFIX] IPv6 care-of and home address Message-ID: <8CE1C74CB824CD9425EA37A8@juergen-quitteks-computer.local> In-Reply-To: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> References: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Carsten, --On 30.11.06 16:38 +0100 Schmoll, Carsten wrote: > > Andrew, > > I was wondering what "kind of" IP address my > collector will receive when there is only > sourceIPv6Address in the accounting flow record. > > But I agree now that we should say that > in a mobile environment an sourceIPv6Address > will always denote the care-of address from > the usual place in the IPv6 header. > > We probably want to note this in the info model. Yes, please send a proposal with full specification. I am not sure we should add it to the draft, but we can add it to the list of IEs at the Info Element Browser which are candidates to be added as soon as the maintenance of IE identifiers has been handed over to IANA. Thanks, Juergen > So I change my proposal to just request: > > sourceIPv6HomeAddress > destinationIPv6HomeAddress > > J=C3=BCrgen: do you agree too? > May a write some short text for the info model on that? > > Best regards, > Carsten. > > >> -----Original Message----- >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> Sent: Thursday, November 30, 2006 4:08 PM >> To: Schmoll, Carsten >> Cc: Juergen Quittek; ipfix@ietf.org >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> Hi Carsten >> >> The Routing EH and Destination EH have the source and >> destination Home Addresses in them, so new new fields >> for them make sense. >> >> The Care of Addresses are just from the IPv6 header, so >> why do you need new types for them? >> >> regards >> >> Andrew >> >> >> Schmoll, Carsten wrote: >> > Dear all, >> > >> > we are currently investigating on a prototype to send >> > accounted IP flow information in a mobile IPv6 environment. >> > >> > For reasons of simplicity and speed we usually export the >> > care-of address (CoA) and the correspondent node's IP >> > address as sourceIPv6Address and destinationIPv6Address. >> > >> > In case of multiple users on one terminal however (or one >> > user making use of multiple of his identities) we'll have >> > to capture and export the home address (HoA) too. The HoA >> > is embedded in an IPv6 extension header of either type >> > Routing EH (43) or the Destination Options EH (60). >> > >> > This would result then in a flow record with two IPv6 source >> > addresses. Even though repetition of the sourceIPv6 address >> > is legal I would like to propose additional IEs to avoid >> > ambiguity. These could be: >> > >> > sourceIPv6CareOfAddress >> > sourceIPv6HomeAddress >> > destinationIPv6CareOfAddress >> > destinationIPv6HomeAddress >> > >> > This would also cover the case where both endpoints of a >> > communication are mobile nodes. >> > >> > What do you think? >> > >> > Best regards, >> > Carsten. >> > >> > >> >> -----Original Message----- >> >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> >> Sent: Tuesday, November 07, 2006 11:27 PM >> >> To: Juergen Quittek >> >> Cc: Schmoll, Carsten; ipfix@ietf.org >> >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> >> >> Juergen Quittek wrote: >> >>> Carsten, >> >>> >> >>> I do understand how these addresses are associated with >> >>> an interface. But how do you think are they associated >> >>> with a certain flow? >> >> That really depends on the common properties that define >> >> Carsten's flow. Perhaps these different properties could >> >> part of an Option Template Record that provides information >> >> on an interface. >> >> >> >> However, it seems that "The IPv6 source address in the IP >> >> packet header" is the wrong element to use these and new >> >> ones should be requested if there is an application in >> >> mind. >> >> >> >> >> >> regards >> >> >> >> Andrew >> >> >> >> >> >> --=20 Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix From ipfix-bounces@ietf.org Thu Nov 30 17:23:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuIH-00053I-Ud; Thu, 30 Nov 2006 17:22:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpuIG-000532-Lp for ipfix@ietf.org; Thu, 30 Nov 2006 17:22:12 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpuIE-0002h2-2A for ipfix@ietf.org; Thu, 30 Nov 2006 17:22:12 -0500 Received: from [192.168.1.128] (unknown [91.89.53.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8B96513CF82; Thu, 30 Nov 2006 23:26:02 +0100 (CET) Date: Thu, 30 Nov 2006 23:22:01 +0100 From: Juergen Quittek To: "Schmoll, Carsten" , Andrew Johnson Subject: RE: [IPFIX] IPv6 care-of and home address Message-ID: <8CE1C74CB824CD9425EA37A8@juergen-quitteks-computer.local> In-Reply-To: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> References: <70524A4436C03E43A293958B505008B6568E9A@EXCHSRV.fokus.fraunhofer.de> X-Mailer: Mulberry/4.0.5 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: ipfix@ietf.org X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ipfix-bounces@ietf.org Carsten, --On 30.11.06 16:38 +0100 Schmoll, Carsten wrote: > > Andrew, > > I was wondering what "kind of" IP address my > collector will receive when there is only > sourceIPv6Address in the accounting flow record. > > But I agree now that we should say that > in a mobile environment an sourceIPv6Address > will always denote the care-of address from > the usual place in the IPv6 header. > > We probably want to note this in the info model. Yes, please send a proposal with full specification. I am not sure we should add it to the draft, but we can add it to the list of IEs at the Info Element Browser which are candidates to be added as soon as the maintenance of IE identifiers has been handed over to IANA. Thanks, Juergen > So I change my proposal to just request: > > sourceIPv6HomeAddress > destinationIPv6HomeAddress > > J=C3=BCrgen: do you agree too? > May a write some short text for the info model on that? > > Best regards, > Carsten. > > >> -----Original Message----- >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> Sent: Thursday, November 30, 2006 4:08 PM >> To: Schmoll, Carsten >> Cc: Juergen Quittek; ipfix@ietf.org >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> Hi Carsten >> >> The Routing EH and Destination EH have the source and >> destination Home Addresses in them, so new new fields >> for them make sense. >> >> The Care of Addresses are just from the IPv6 header, so >> why do you need new types for them? >> >> regards >> >> Andrew >> >> >> Schmoll, Carsten wrote: >> > Dear all, >> > >> > we are currently investigating on a prototype to send >> > accounted IP flow information in a mobile IPv6 environment. >> > >> > For reasons of simplicity and speed we usually export the >> > care-of address (CoA) and the correspondent node's IP >> > address as sourceIPv6Address and destinationIPv6Address. >> > >> > In case of multiple users on one terminal however (or one >> > user making use of multiple of his identities) we'll have >> > to capture and export the home address (HoA) too. The HoA >> > is embedded in an IPv6 extension header of either type >> > Routing EH (43) or the Destination Options EH (60). >> > >> > This would result then in a flow record with two IPv6 source >> > addresses. Even though repetition of the sourceIPv6 address >> > is legal I would like to propose additional IEs to avoid >> > ambiguity. These could be: >> > >> > sourceIPv6CareOfAddress >> > sourceIPv6HomeAddress >> > destinationIPv6CareOfAddress >> > destinationIPv6HomeAddress >> > >> > This would also cover the case where both endpoints of a >> > communication are mobile nodes. >> > >> > What do you think? >> > >> > Best regards, >> > Carsten. >> > >> > >> >> -----Original Message----- >> >> From: Andrew Johnson [mailto:andrjohn@cisco.com] >> >> Sent: Tuesday, November 07, 2006 11:27 PM >> >> To: Juergen Quittek >> >> Cc: Schmoll, Carsten; ipfix@ietf.org >> >> Subject: Re: [IPFIX] IPv6 care-of and home address >> >> >> >> Juergen Quittek wrote: >> >>> Carsten, >> >>> >> >>> I do understand how these addresses are associated with >> >>> an interface. But how do you think are they associated >> >>> with a certain flow? >> >> That really depends on the common properties that define >> >> Carsten's flow. Perhaps these different properties could >> >> part of an Option Template Record that provides information >> >> on an interface. >> >> >> >> However, it seems that "The IPv6 source address in the IP >> >> packet header" is the wrong element to use these and new >> >> ones should be requested if there is an application in >> >> mind. >> >> >> >> >> >> regards >> >> >> >> Andrew >> >> >> >> >> >> --=20 Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www1.ietf.org/mailman/listinfo/ipfix