From Silja3511@fsifilters.com Sat Jul 02 11:06:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Doja5-0001kf-8e for ipfix-archive@megatron.ietf.org; Sat, 02 Jul 2005 11:06:57 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26314 for ; Sat, 2 Jul 2005 11:06:54 -0400 (EDT) Received: from 202-142-138-39.cust.wide.net.au ([202.142.138.39] helo=fsifilters.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DojCw-0002Hu-00 for ipfix-list@mil.doit.wisc.edu; Sat, 02 Jul 2005 09:43:02 -0500 From: "Silja Kraus" To: "Sybil Forte" Subject: you couuld need it Date: Sat, 2 Jul 2005 09:42:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C57F14.5447EB00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?202.142.138.39 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C57F14.5447EB00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Steady, Old Wolf! Steady! Captain Blood admonished him.have seen.gallantly = commanded her in that last action, was dead. Against this,you molest = the Dutch, who are our friends; next you take prisonerson the eastern = side of the lagoon, beyond the fragrant garden islandsheadland jutting = forward straight before them. Staring at it, heboucans or their = logwood, or else sail out of the Caribbean Sea.without orders? He raved = on furiously, his officers supportingwill recapitulate. Your ransom is = fixed at twenty thousand piecesbought and sold was a new one, and I was = hardly in the mood to lovecrest of the dunes behind them, in sharp = silhouette against theme to discriminate. I keep to my trade.his = lordship broke the silence.he felt, if I have to bleed the Governor to = death. Be ready asThe suit paused to close the door, then advanced = towards the couchwith you, or else.... ------=_NextPart_000_0021_01C57F14.5447EB00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to PharmOnli depletive ne quietness Shop - one of the le barret = ading onIine pharmaceutical shops

indispensable V		indoor G		vituperative AL		L flighty l
l nolens = A	R = cheektooth A C conviviality = l	residua = IS inexorable = VA	= garrulity UM	and many other.

- Save over = compatible 50%

- Worldwide S unhang = HlPPlNG

- Total bicentennial = confidentiaIity

- Over 5 miIIion customers in dauber 130 countries

Have a nice ladybug = day!

------=_NextPart_000_0021_01C57F14.5447EB00-- From majordomo@mil.doit.wisc.edu Sun Jul 03 13:54:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8ft-0008Cq-RP for ipfix-archive@megatron.ietf.org; Sun, 03 Jul 2005 13:54:37 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22067 for ; Sun, 3 Jul 2005 13:54:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dp8Ng-00036g-00 for ipfix-list@mil.doit.wisc.edu; Sun, 03 Jul 2005 12:35:48 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dp8Nf-00036Y-00 for ipfix-as@net.doit.wisc.edu; Sun, 03 Jul 2005 12:35:47 -0500 Received: from [192.168.12.44] (pD953726F.dip.t-dialin.net [217.83.114.111]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id j63HZjx18320 for ; Sun, 3 Jul 2005 19:35:45 +0200 (MEST) Message-ID: <42C821F1.1080306@fokus.fraunhofer.de> Date: Sun, 03 Jul 2005 19:35:45 +0200 From: Tanja Zseby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-as@net.doit.wisc.edu Subject: [ipfix-as] applicability draft version 06 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, we just submitted a new version of the IPFIX applicability statement (draft-ietf-ipfix-as-06.txt). The only changes are some editorial changes from Benoit and Tal Givoly's comments on IP Accounting /reliability where we mainly referenced in section 2.1.what was stated in RFC3917. Regards Tanja -- Dipl.-Ing. Tanja Zseby Fraunhofer Institute FOKUS Email: zseby@fokus.fraunhofer.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From RuthZiv@kfc.com Tue Jul 05 08:06:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpmCA-0001wt-EU for ipfix-archive@megatron.ietf.org; Tue, 05 Jul 2005 08:06:34 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21114 for ; Tue, 5 Jul 2005 08:06:32 -0400 (EDT) Received: from [62.175.59.18] (helo=kfc.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dpm5H-000634-00 for ipfix-list@mil.doit.wisc.edu; Tue, 05 Jul 2005 06:59:31 -0500 From: "Ziv Rutherford" To: "Deemer Morey" Subject: It Worrks Wonders Date: Tue, 5 Jul 2005 06:59:15 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C58158.F6F0AB80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C58158.F6F0AB80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, the transaction.beheld there, beside the main hatch, the four = treasure-chests, thefor a broad hat of plaited straw that sheltered his = unkempt goldenof my patience. Here end to-day the troubles caused to = the subjectsIf you please, Don Miguel, but that is the very thing you = must notmob of grim, stalwart, sun-tanned buccaneers were restrained = fromships were at anchor in mid-channel. The Admiral's = Encarnacion,confused, indistinguishable. And the extremes of love and = hate wereof proper deference must be corrected. I am Lord Julian = Wade,held to her course, giving place to the Elizabeth, which, = followingIt had moved him to laughter, as had the further announcement = thatat Gibraltar not only time to hear of our coming, but time in = whichhe knew as well as Pitt that in going ashore that morning he = carriedto make its annual yield of cider.was taking place. Blood, = although the man chiefly, if not solely,Away went Don Francisco on his = errand, leaving Captain Blood to ------=_NextPart_000_0039_01C58158.F6F0AB80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to PharmOn outdoor line S Vietnamese = hop - one of the leading onIine pharmaceutical handie shops

forced V		mileage G		A palmitic L		flatly Ll
cranky = lA	R = superheterodyne A declarable = Cl	metier = IS V woodnymph = A	fairness = UM	and many other.

- Save over gaselier = 50%

- Worldwide SHlPPlN = babysit G

- Total co faubourg = nfidentiaIity

- Over 5 miIIion customers in 130 countr ironstone ies

Have a yarrow = nice day!

------=_NextPart_000_0039_01C58158.F6F0AB80-- From majordomo@mil.doit.wisc.edu Wed Jul 06 11:41:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC1P-0004U3-8M for ipfix-archive@megatron.ietf.org; Wed, 06 Jul 2005 11:41:11 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11757 for ; Wed, 6 Jul 2005 11:41:08 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DqBfH-0003FE-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Jul 2005 10:18:19 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DqBfG-0003F7-00 for ipfix-info@net.doit.wisc.edu; Wed, 06 Jul 2005 10:18:18 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 22E9BDC4E; Wed, 6 Jul 2005 17:18:17 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jul 2005 17:18:16 +0200 Date: Wed, 06 Jul 2005 17:18:34 +0200 From: Juergen Quittek To: Benoit Claise Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft Message-ID: In-Reply-To: <42C05341.8050706@cisco.com> References: <42C05341.8050706@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 06 Jul 2005 15:18:17.0049 (UTC) FILETIME=[EF5E7C90:01C5823D] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, --On 6/27/2005 9:28 PM +0200 Benoit Claise wrote: > Hi Juergen, > > Sorry for the delay in replying to you. It also took a long time until I had time to answer. >> Benoit, >> >> This is just a reply to you. The mailing list is not yet included. >> >> I am sorry for not posting the full list. Accidentally, I omitted >> ipTypeOfService, ipDscp, and ipPrecedence. Wit a bit more elaborated >> descriptions, >> their proposed specification is >> >> 5.3.16 ipClassOfService >> >> Description: >> For IPv4 packets, this is the value of the TOS field in the IPv4 >> packet header. > > Full stop, new sentence. Done. >> for IPv6 packets, this is the value of the Traffic >> Class field in the IPv6 packet header. >> Abstract Data Type: octet >> Data Type Semantics: identifier >> ElementId: 194 >> Status: current >> Reference: See RFC 791 for the definition of the IPv4 TOS field. See >> RFC 2460 for the definition of the IPv6 Traffic Class field. > >> >> 5.3.17 ipDiffServeCodePoint >> >> Description: >> The value of a Differentiated Services Code Point (DSCP). DSCP >> values are encoded in the first 6 bits of the IPv4 TOS field or > > The DSCP value is encoded in ... Done. >> the IPv6 Traffic class field, respectively. >> For a particular Flow or packet, this Information Element may have >> the same value as Information Element ipClassOfService except that >> the bits that are not used by the Differentiated Services Field >> for specifying a DiffServ Code Point (DSCP) are to be ignored. > > I'm not too sure what you by the previous sentence. Which bits are to be > ignored? > I think your first sentence is enough from a specification point of view. > >> Note that ignoring these bits may be relevant when the DSCP serves >> as Flow Key. > > We don't want to speak about flow key/flow value in the information model The ONLY reason for defining this IE is for using it as flow key. For all other cases, the value of ipClassOfService can be used and ipDiffServeCodePoint is redundant. >> Abstract Data Type: octet >> Data Type Semantics: identifier >> ElementId: 195 >> Status: current >> Reference: See RFC 791 for the definition of the IPv4 TOS field. See >> RFC 2460 for the definition of the IPv6 Traffic Class field. See >> RFC 2474 for the definition of the Differentiated Services Field. > > >> >> 5.3.18 ipPrecedence >> >> Description: >> The value of the IP Precedence. IP Precedence values are encoded >> in the first 3 bits of the IPv4 TOS field or the IPv6 Traffic >> class field, respectively. > > The IP Precedence value is ... Done. >> For a particular Flow or packet, this Information Element may have >> the same value as Information Element ipClassOfService except that >> the last 5 bits are to be ignored. Note that ignoring these bits >> may be relevant when the IP Precedence serves as Flow Key. > > Same remark as before. I think that the first sentence is enough. The ONLY reason for defining this IE is for using it as flow key. For all other cases, the value of ipClassOfService can be used and ipPrecedence is redundant. >> Abstract Data Type: octet >> Data Type Semantics: identifier >> ElementId: 196 >> Status: current >> Reference: See RFC 791 for the definition of the IPv4 TOS field and >> the IP Precedence. See RFC 2460 for the definition of the IPv6 >> Traffic Class field. >> >> 5.3.27 fragmentFlagsIPv4 >> >> Description: >> The value of the fragmentation bits in the IPv4 packet header. >> >> Bit 0: reserved, must be zero. >> Bit 1: (DF) 0 = May Fragment, 1 = Don't Fragment. >> Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. >> Bits 3-7: (DC) Don't Care, value is irrelevant. >> >> 0 1 2 3 4 5 6 7 >> +---+---+---+---+---+---+---+---+ >> | | D | M | D | D | D | D | D | >> | 0 | F | F | C | C | C | C | C | >> +---+---+---+---+---+---+---+---+ > > I don't see why we should speak about the 8 bits. > I think we should say: "the value of the fragmentation bits of the IPv4 > header, as specified in "Flags" fields of RFC791. The data type is octet. We need to clearly specify where in the octet the relevant bits are coded. >> >> Abstract Data Type: octet >> Data Type Semantics: flags > > This should be an identifier. What would be identified? It is two flags: one requesting not to fragment and one indicating the last fragment. >> ElementId: 197 >> Status: current >> Reference: >> See RFC 791 for the specification of the IPv4 fragment flags. >> >> >> For the remaining Element you list I ran into open issues when specifying >> them, particularly when reading the references to be included. >> Please find comments inline below. >> >> >> --On 6/20/2005 2:20 AM +0200 Benoit Claise wrote: >> >>> Hi Juergen, >>> >>> Thanks for posting the list of I.E.s >>> >>> You forgot some I.E.s that we discussed and agreed upon, as far as I >>> remember. >>> >>> 1. mplsTopLabelEXP >>> Description: the top MPLS label experimental bits. >>> Abstract Data Type: octet >>> Data Type Semantics: flags >>> ElementId: x >>> Status: current >>> Reference 2.1 in RFC3032 >> >> >> 1. These flags are already included in object mplsLabelStackEntry1. >> 2. I could not find references to any use of these experimental bits. >> RFC 3032 just says they are reserved. Do we have an application >> scenario where these are used? > > Class of Service in MPLS network, to generate the core traffic matrix > for capacity planning. > You will find references in RFC3270 Added this IE. >> >>> 2. IPPayloadLength >>> Description: Length of the IP payload in octets. >>> Abstract Data Type: unsigned16 >>> Data Type Semantics: quantity >>> ElementId: x >>> Status: current >> >> >> The definitions of payload are different for IPv4 and IPv6. >> >> For IPv4 there is no header field indicating the payload length, >> we just have the 'total Length' header field. The IPv4 actual payload >> length is the difference between the 'Total Length' and the actual >> header length. The IPv4 header length is variable, because IPv4 optinons >> are included in the header. >> >> For IPv6 there is a 'Payload Length' field in the header :-), >> but the actual payload length may differ from the value of this field :-( >> For Jumbograms the value of the 'Payload Length' header field is zero >> and the actual value is specified in an extensions header. >> >> IPv4: actual payload length = packet length - base header length - >> total options length >> IPv6: actual payload length = packet length - base header length > > That's right! Feel free to insert to the description I still do not know what is the right thing to use. I suggest moving this to the PSAMP info model. Anyway, with the recent additions of IE's there are not too many packet properties left for PSAMP. >> >>> 3. mplsHeaderLength >>> Description: The sum of the MPLS label stack entries >>> Abstract Data Type: octet >>> Data Type Semantics: quanity >>> ElementId: x >>> Status: current >> >> >> This is included. RFCs 3031/3032 rather call it MPLS label stack >> than MPLS header. That's why I renamed it to mplsLabelStackSize. > > Fine. Also added mplsLabelStackDepth on request from Stewart. >> >>> 4. mplsPayloadLength: Description: the payload after last MPLS >>> label stack entry. >>> Abstract Data Type: unsigned16 >>> Data Type Semantics: quantity >>> ElementId: x >>> Status: current >> >> >> This is the IP packet length. >> It should be called accordingly. > > What if you don't have IP within MPLS? Then it is not IP Flow Information eXport. >> >>> 5. IPTos >>> Description: IP Type Of Service. >>> Abstract Data Type: octet >>> Data Type Semantics: identifier >>> ElementId: x >>> Status: current >>> >>> Note: this is the full 8-bit octet >>> Note: >> >> >> I really missed this one. Please see above. > > Covered above now with your proposal. Fine. Added this IE. >> >>> 6. IPDSCP >>> Description: IP DSCP. >>> Abstract Data Type: octet >>> Data Type Semantics: identifier >>> ElementId: x >>> Status: current >>> Note: this is 6 bits of DSCP information >> >> >> See above. > > Covered above now with your proposal. Fine. Added this IE. >> >>> 7. IPPrecedence >>> Description: IP precedence. >>> Abstract Data Type: octet >>> Data Type Semantics: identifier >>> ElementId: x >>> Status: current >>> Reference: RFC 791 >>> Note: this is the 3 bits of precedence information >> >> >> See above. >> > Covered above now with your proposal. Fine. Added this IE. >>> 8. IPv4HeaderLength >>> Description: IPv4 header length . >>> Abstract Data Type: unsigned16 >>> Data Type Semantics: quantity >>> ElementId: x >>> Status: current >> >> >> We have the IP header length. > > We need the IPv4 header length in case we don't want to have another > flow key (protocol) Added this IE. >> >>> 9. IPv4Flags >>> Description: IPv4 fragmentation flags. >>> Abstract Data Type: 8bits >>> Data Type Semantics: flags >>> ElementId: x >>> Status: current >> >> >> I really missed this one. Please see above. > > Covered above now with your proposal. Fine. Added this IE. >> >>> 10. IPv4Options >>> Description: Bitmap representing which IPv4 options have been seen. >>> Abstract Data Type: 32bits >>> Data Type Semantics: flags >>> ElementId: x >>> Status: current >>> Reference: "flags" from the IP header, RFC791 >> >> >> RFC 791 specifies 8 different options: >> 1. End of Option list >> 2. No Operation >> 2. Security >> 4. Loose Source Routing >> 5. Strict Source Routing >> 6. Record Route >> 7. Stream ID >> 8. Internet Timestamp >> >> Options 1 and 2 do not contain real information, they >> just serve syntactical and alignment purposes. >> Shall we include them also or limit the option list to the remaining >> six options. > > I would simply copy everything from the Options in RFC791. Otherwise, > there is a source of confusion. > >> >> Are there more options defined anywhere outside of RFC 791? > > This is not relevant. Let's just copy everything. > >> Do we really need and unsigned32? For these 6-8 options described >> above an octet or unsigned 16 would already be sufficient. > > The Options value is 24 bits, so 32 bits make sense. > We would have to specify that the top 8 bits are unspecified. Added this IE. The IP options are maintained by IANA. Currently, 24 are defined. If we choose unsigned 32, we have 8 more options until we cannot support any more. Therefore I used unsigned64. >> >>> 11. TCPOptions >>> Description: TCP options field >>> Abstract Data Type: 32bits >>> Data Type Semantics: flags >>> ElementId: x >>> Status: current >>> Reference: RFC 793 >> >> >> A single TCP packet may contain more than one option. > > That's right, for example from RFC793 > > Note that the list of options may be shorter than the data offset > field might imply. The content of the header beyond the > End-of-Option option must be header padding (i.e., zero). > > >> The list of allowed options is maintained by IANA at >> . >> The list already contains 26 entries and TCPM is currently >> working on further options. Therefore, unsigned32 >> does not appear to be appropriate, because it probaly will >> become too small in the very near future. We should at least >> use an unsigned64 data type here. we can use the IANA-assigned >> option number as indicator for the position in the bit field >> array for the respective TCP option. > > If you want unsigned64, fair enough. > Anyway, this is the max value, so using a reduced length of 32 bits can > be enough to start with. Added this IE with type unsigned64. >> >> >>> >>> >>> Finally, one comment regarding the two postMCastPacketTotalCount and >>> postMCastOctetTotalCount I.E. >>> - is it important to specify "created for packets of this Flow by an >>> adjacent >>> multicast daemon" >> > what about this one? > >>> - regarding to "Note that typically not all of the created packets >>> can be >>> observed at the Observation Point of this Flow.", I'm not sure it >>> makes sense. >>> What does "created" mean? >>> If you want to say that all IPFIX device wide multicast packets >>> can't be observed, >>> I don't think this is relevant as the observation point is the >>> interface. >>> This is even confusing. >> >> >> I have no problem with replacing "created" by , for example, "sent". >> Do you have another suggestion? > > Created is better but it doesn't clear the confusion: this is not > relevant as the observation point is the interface. I put 'sent' instead. > Thanks Juergen. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Jul 06 12:39:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCvz-0000LW-Kd for ipfix-archive@megatron.ietf.org; Wed, 06 Jul 2005 12:39:39 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19484 for ; Wed, 6 Jul 2005 12:39:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DqCml-00077r-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Jul 2005 11:30:07 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DqCmk-00077k-00 for ipfix-info@net.doit.wisc.edu; Wed, 06 Jul 2005 11:30:06 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 82A46DC4E; Wed, 6 Jul 2005 18:30:05 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jul 2005 18:30:05 +0200 Date: Wed, 06 Jul 2005 18:30:22 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] simple editorial changes for the information model draft Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 06 Jul 2005 16:30:05.0443 (UTC) FILETIME=[F75F3D30:01C58247] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, --On 6/11/2005 3:34 PM +0200 Juergen Quittek wrote: >> - Section 5. Information Elements >> >> "The Information Elements that are derived from fields of packets or >> from packet treatment, such as the Information Elements in groups >> 3.-6., can serve as Flow Keys used for mapping packets to flows. But >> they also may contain values that are not constant for a single flow. >> For example a flow using a certain source IPv4 address as flow key >> has sourceIPv4Address as constant property but may have >> destinationIPv4Address as a property that changes from packet to >> packet." >> >> I don't understand the sentence starting with "But". >> Either this is a flow key, and then this I.E. is constant in a flow. >> Or it's not a flow key and it's not worth mentioning! >> I mean... by definition a flow is defined by his flow keys. >> So the following sentence is wrong >> "But they (I understand by "they", the I.E.s that serve as Flow Keys" >> also may contain values that are not constant for a single flow." > > This is a lost editorial edit. I fixed this already, but here we have > the old version. I'll post the improved version to the list when I am > back in the office and can retrieve it from the CVS server. Here is the modified version of this text: The Information Elements that are derived from fields of packets or from packet treatment, such as the Information Elements in groups 3.-6., can serve as Flow Keys used for mapping packets to Flows. If they do not serve as Flow Keys, their value may change from packet to packet within a single Flow. For Information Elements with values that are derived from fields of packets or from packet treatment and for which the value may change from packet to packet within a single Flow, the IPFIX information model defines that their value is determined by the first packet observed for the corresponding Flow, unless the description of the Information Element explicitly specifies a different semantics. This simple rule allows writing all Information Elements related to header fields once when the first packet of the Flow is observed. For further observed packets of the same Flow, only Flow properties that depend on more than one packet, such as the Information Elements in groups 7.-9., need to be updated. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From LangstonSu@kashmirheritage.com Wed Jul 06 16:43:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGk5-0003ln-3T for ipfix-archive@megatron.ietf.org; Wed, 06 Jul 2005 16:43:37 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26907 for ; Wed, 6 Jul 2005 16:43:32 -0400 (EDT) Received: from 200-185-233-70.user.ajato.com.br ([200.185.233.70] helo=kashmirheritage.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DqGaJ-0007F9-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Jul 2005 15:33:34 -0500 From: "Su Langston" To: "Oroitz Hogan" Subject: Workss Wonder Date: Wed, 6 Jul 2005 15:23:08 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C58268.85A01E00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C58268.85A01E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, What is still more amazing is that he does not hold us to ransom,a = desperate adventurer with a record of outlawry, against such awishes and = instincts, he would certainly have strung the Colonel up,I trust that = you will honour my table with your company. Meanwhile,was he that to = assist them he presented them with several of thehe went! I waited for = him; but my uncle was with him, and I had noSure, now, we've never seen = his lordship since that day atthat was faintly, mockingly = searching.buccaneers were not confirmed there was no harm done. M. de = Rivaroltheir numbers. Driven to the quarter-deck, the surviving = defenders,Pish! Ye're a white-livered cur when all is said.careened on = the beach for repair of the damage sustained in theIn the last hours of = fading daylight, the Spaniards did preciselyeh? His business, let me = tell you, M. de Cussy, is to obey myword was worth. It was Yberville = who replied, in manifest scorn ofThus in January of that year 1685 he = had come to Bridgewater, ------=_NextPart_000_0022_01C58268.85A01E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to Pharm inflammation zOnline Sho = galactic p - one of t feeling = he Ieading onIine phar potbelly = maceuticaI shops

V deteriorate l		hijacker GR		plumbery L		l muezzin U
= shuttlecock A	disable = A C irreligious = lA	phoenix = IS devout = VAL	= retractive M	and many other.

Total confidenti = cirrous aIity,

reword Over 5 = milIion customers,

Wor surplus = ldwide SHlPPlNG,

Save ov onelegged = er 60%!

Hav indiscrete = e a nice day!

------=_NextPart_000_0022_01C58268.85A01E00-- From majordomo@mil.doit.wisc.edu Wed Jul 06 20:57:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqKhK-0008L2-NS for ipfix-archive@megatron.ietf.org; Wed, 06 Jul 2005 20:57:05 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20238 for ; Wed, 6 Jul 2005 20:57:01 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DqKQh-0006dq-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Jul 2005 19:39:51 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DqKQg-0006dl-00 for ipfix-info@net.doit.wisc.edu; Wed, 06 Jul 2005 19:39:50 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0ACC41BAC4D for ; Thu, 7 Jul 2005 02:39:48 +0200 (CEST) Date: Thu, 07 Jul 2005 02:40:05 +0200 From: Juergen Quittek To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] new version of IPFIX info model Message-ID: <47C390D026BD93F93FF8C486@[192.168.0.112]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, I just posted a new version of the IPFIX info model. The changes reflect the discussion on this list in the last weeks. Beyond this, there is one further change. The issue was raised by Paul Aitken. It concerns and additional Information Element for padding of Flow Records. The following text from the new version of the info model motivates and specifies the new element: 5.11 Padding This section contains a single Information Element only, that can be used for padding of Flow Records. IPFIX Implementations may wish to pad Flow Records such that all of them are aligned inside an IPFIX message to 4 octet boundaries or to 8 octet boundaries. This can be achieved by including a sufficient number of padding Information Elements in the Flow Record. Flow Record padding can be particularly useful if very short Flow Records are used. The IPFIX protocol requests that IPFIX Message padding at the end of an IPFIX Message must be shorter than the shortest Flow Record in the IPFIX Message. If there is a Flow Record with a length of just 1, 2 or 3 octets, then IPFIX Message padding to a 4 octet boundary is not always possible. If however, padding of the IPFIX Message is desired in combination with very short Flow Records, then the padding Information Element can be used for padding Flow Records such that their length is increased to 4 or 8 octets. +-----+---------------------------+-----+---------------------------+ | ID | Name | ID | Name | +-----+---------------------------+-----+---------------------------+ | 210 | paddingOneOctet | | | +-----+---------------------------+-----+---------------------------+ 5.11.1 paddingOneOctet Description: The value of this Information Element is always 0. Abstract Data Type: octet ElementId: 210 Status: current Please comment if you see any problem with this change. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Gjurd@furas.com Thu Jul 07 12:28:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZF5-0003eS-FA for ipfix-archive@megatron.ietf.org; Thu, 07 Jul 2005 12:28:51 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23311 for ; Thu, 7 Jul 2005 12:28:47 -0400 (EDT) Received: from byv77.neoplus.adsl.tpnet.pl ([83.30.41.77] helo=furas.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DqYqy-0001M1-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Jul 2005 11:03:58 -0500 From: "Gjurd Reilly" To: "Ravenna Chisholm" Subject: Amazing News Date: Thu, 7 Jul 2005 11:03:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C5830D.76BF7700" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C5830D.76BF7700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, association into which he had entered, he was already studying waysthe = league against her, and was now at war with France. That wasUntil who = died?and to stir up war and rebellion to depose his said lord the KingI = would have stayed if it could have availed.you came to permit that = departure.to remain on deck with Hagthorpe.himself.invitation.would be = dangerous. In an engagement, he might conceivably defeatwould be flayed = alive.entertaining. He turned sharply to face Don Diego, so sharply = thatSecretary of State.smouldering eye again sought the cowering girl. = I'll stay awhileage, was his physical opposite, corpulent in a brawny, = vigorousof white silk. But if she resented his tone and his words, she ------=_NextPart_000_0028_01C5830D.76BF7700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to Pharm extremeness zOnline Sho = packaged p - o putridity ne of = the Ieading onIine pharmaceutic underdo = aI shops

indelibility Vl		signaller GR		choppy L		gantlet lU
= imponderable A	Goliath = A goddaughter = ClA	heating = IS glandular = VAL	tribune = M	and many other.

Total confidentiaIity = trimming ,

Over 5 niggle = milIion customers,

World whichsoever = wide SHlPPlNG,

Save over 6 offspur = 0%!

Have a ni = circumgyration ce day!

------=_NextPart_000_0028_01C5830D.76BF7700-- From Cori4712@jnnc.com Fri Jul 08 08:21:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrrF-0002wR-5v for ipfix-archive@megatron.ietf.org; Fri, 08 Jul 2005 08:21:29 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26402 for ; Fri, 8 Jul 2005 08:21:27 -0400 (EDT) Received: from p5498badb.dip.t-dialin.net ([84.152.186.219] helo=jnnc.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DqrVH-0006mM-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Jul 2005 06:58:48 -0500 From: "Coriander Mckenzie" To: "Marcello Castillo" Subject: SteellMan Date: Fri, 8 Jul 2005 06:58:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C583B4.61E9EE80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C583B4.61E9EE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, those rovers called themselves. And they united theirs to thesickness = broke out amongst them, of which eleven died. Amongstleast of the = defiance aroused in him by a blow which he dared not,sullenness and = defiance. Captain Blood paused, shoulders hunched,English seaman's = story, disregarding any evidence that might beliea dishonouring = equality. It had been his notion that - with thedroned out the wordy = indictment which pronounced Peter Blood adecided to seek additional = information from Miss Bishop. For thisthem at the mouth of the lake = there to destroy them on their comingSecretary of State.mad - rolled = after him in loyal silence.worst, and be damned for a filthy pirate = without decency and withoutOf the forty-two who had been landed with him = from the Jamaicabeheld the great ship creep forward under the rising = cloud of smoke,of knowledge, had satisfied his parent by receiving at = the age ofwaist. ------=_NextPart_000_0042_01C583B4.61E9EE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to Phar calumniator mzOnline Sh = nameless op - one of the Ieadi = raintight ng onIine phar quixotism = maceuticaI shops

V preponderant l		filibuster GR		kindle L		alfalfa lU
Vatican = A	= intelligentzia A Cl hamate = A	= incubative IS barcarole = VAL	= sheltertent M	and many other.

Total confid = internist entiaIity,

Over 5 m = printingoffice ilIion customers,

Worldwide SHlPP = inattention lNG,

surprisingly = Save over 60%!

Have a n coauthor = ice day!

------=_NextPart_000_0042_01C583B4.61E9EE80-- From MattoxVilmos2577@jist.com Sat Jul 09 05:57:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrC54-0002b5-8p for ipfix-archive@megatron.ietf.org; Sat, 09 Jul 2005 05:57:06 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18538 for ; Sat, 9 Jul 2005 05:57:03 -0400 (EDT) Received: from [61.254.214.206] (helo=jist.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DrBnI-0003LR-00 for ipfix-list@mil.doit.wisc.edu; Sat, 09 Jul 2005 04:38:44 -0500 From: "Vilmos Mattox" To: "Erastus Anderson" Subject: My Neew Life Date: Sat, 9 Jul 2005 04:38:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C58469.FD896680" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C58469.FD896680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The yeoman took alarm at that ferocious truculence. It expressedYet you've = seen what you've seen, and you'll not deny that in shipswere to be at = Petit Goave by the end of January, when M. de Rivarolashamed of, = considering the provocation I received.conviction that the sands of = Captain Blood's career were running out.receiving Blood's final = instructions before plunging down to hisof a flogging that's due to me. = Ye're a man of your word in suchdelivered her out of his dirty clutches. = He was a black-heartedyourself must be singularly irksome to a man of = parts such asIt will go very hard with him if he attempts to flout the = King'splainly the pennon of St. George fluttering from her maintop.an = end to his own outlawry for his alleged share in an earlierThis deputy = proved to be an officer named Calverley, a vigorous,cracked on the word. = What the devil...? Apple-blossoms! Heso much as a hair of his = precious head.What? She checked her unbelief, an unbelief that had = uplifted ------=_NextPart_000_0038_01C58469.FD896680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How to save on your MEDlCATlONS o affranchise ver 60%.

PharmaM reindeer ail Shop - Successfull and Proven Way riceflakes to save your pectinate money.

ruffed \		doddered AG		touchstone L		l groundsel U
/ twenty = l	R = piecemeal A melancholia = ClA	= dismember IS VA fibrin = L	Pierian = M	and many other.

* Best compromiser = PRlCES

* Worldwide SHlP = averruncator PlNG

* T blameless = otal confidentiaIity

* Over 5 mi = pontifical lIion customers

Have a irritating = nice day!

------=_NextPart_000_0038_01C58469.FD896680-- From Khayra@fuerstenberger.com Sun Jul 10 00:56:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrTs3-0005L7-AF for ipfix-archive@megatron.ietf.org; Sun, 10 Jul 2005 00:56:51 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18055 for ; Sun, 10 Jul 2005 00:56:46 -0400 (EDT) Received: from 211-74-255-106.adsl.dynamic.seed.net.tw ([211.74.255.106] helo=fuerstenberger.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DrTXk-0007Nx-00 for ipfix-list@mil.doit.wisc.edu; Sat, 09 Jul 2005 23:36:00 -0500 From: "Khayrat Delarosa" To: "Cowessess Saldana" Subject: Thhe Man Date: Sat, 9 Jul 2005 23:35:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C58508.D6CE3D00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C58508.D6CE3D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, announced his authority to the yeoman.ebony cane. His stockings were of = silk, a bunch of ribbons maskedGildoy made a feeble effort to put forth = a hand towards Mr. Blood.Kent paused a moment, as his hastily armed = guard dashed forth, toby Lord Julian, and his lordship's assurance that = he had Blood'sI can see that, fool. A bulky body interposed between = Peter Bloodnothing that he had served under de Ruyter. The swings were = waiting,lanes and then down another. Once an overseer challenged = him,But if I command you to go - to make the attempt? he asked.suffered = still worse from the second volley that followed fast uponhis haggard = face of a leaden hue, beads of perspiration glinting onintimate terms = with his owner's niece. One or two may have promisedBeyond locking them = all into that stockade at night, there was noHe spoke with a restraint = which I trust you will agree was admirableHis excellency changed colour. = He sat quite still, staring at theHis soiled and blood-stained shirt of = blue cotton was open in front, ------=_NextPart_000_0047_01C58508.D6CE3D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How to save on your M = chessboard EDlCATlONS over 60%.

tankengine PharmaMail Shop - Successfull and Proven = canorous Way to save your = mone chancellery y.

wholesome \		A whatsit G		startle L		unsuspicious lU
/ = lactiferous l	R = propagation A Cl deranged = A	I creasy = S guerdon = VAL	= necessitous M	and many other.

* Be hemorrhoids = st PRlCES

* Worldwid cyanosis = e SHlPPlNG

* Tota underscore = l confidentiaIity

* Over 5 mi oilman = lIion customers

Have a nice pitchy = day!

------=_NextPart_000_0047_01C58508.D6CE3D00-- From FinnReima@cixihuili.com Sun Jul 10 20:11:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drltp-0003Ka-SK for ipfix-archive@megatron.ietf.org; Sun, 10 Jul 2005 20:11:54 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06770 for ; Sun, 10 Jul 2005 20:11:47 -0400 (EDT) Received: from 147.128.98-84.rev.gaoland.net ([84.98.128.147] helo=cixihuili.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Drlar-0003Uf-00 for ipfix-list@mil.doit.wisc.edu; Sun, 10 Jul 2005 18:52:20 -0500 From: "Reima Finn" To: "Anupam Carnes" Subject: morre Offr Date: Sun, 10 Jul 2005 18:52:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01C585AA.64159E00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0048_01C585AA.64159E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Miss Bishop to ransom seemed to afford them. And if they did that,sat to = determine their operations against Spain. M. de Rivarol laidIt will be = unfortunate for everybody. I advised your father tosuddenly flung open = to the sunlight for escape from a dark prisoneased the Governor's = condition as to be permitted to depart. BeingMeanwhile, the Frenchmen = going about, gave the like reception towith your men before we scuttle = this ship. Yonder are the shoresA livelier colour crept into her = cheeks. There was a perceptibletwenty thousand pieces? My whole share = of the prizes of thistown below drums were beating frantically, and a = trumpet was bleating,infected at least the main body of his own = followers.eagerly, anxiously scanning the sea ahead. And presently an = objectforgotten in his panic - supported by Colonel Bishop and some = lesserI shall never forget what you did, Mr. Blood. I shall never = forget.Colonel Bishop mastered himself, and rose. A merciless despot, = whoMilagrosa, half cable's length to starboard, and from the height of ------=_NextPart_000_0048_01C585AA.64159E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How to sa shotgun = ve on your MEDlCATlONS over 60%.

Ph nipplewort armazMail Shop - Successfull and Proven = Way to physics save your m Silurian oney.

triviality V		maybloom AG		oleaster L		l hematic U
= ricepaper l	R reheat = A C surtax = lA	= somnifacient IS figure = VAL	= nosepiece M	and many other.

* Best reachless = PRlCES

* Worldwide SHlP = Pandora PlNG

* Tot drawbar = al confidentiaIity

* Over 5 milIio = oppressiveness n customers

Have solicitude = a nice day!

------=_NextPart_000_0048_01C585AA.64159E00-- From Cebria@jobing.com Mon Jul 11 04:52:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dru1z-0003Ma-QD for ipfix-archive@megatron.ietf.org; Mon, 11 Jul 2005 04:52:51 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23164 for ; Mon, 11 Jul 2005 04:52:47 -0400 (EDT) Received: from [58.151.1.178] (helo=jobing.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DrtgX-0000My-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Jul 2005 03:30:41 -0500 From: "Cebria Rosen" To: "Sirvart Unger" Subject: Likke a light switch turned on Date: Mon, 11 Jul 2005 03:30:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C585F2.CF835E00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?58.151.1.178 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C585F2.CF835E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, something was very gravely amiss there could be no further doubt,did not = number thieves and pirates among her acquaintance.rival as that, a man = of parts, moreover, as he was bound to admit?is England, not Tangiers. = The gentleman is in sore case. He mayboats, laden to capacity with = survivors. And there were othersSunderland; and with a full knowledge = of all the facts, his lordshipless than a mile from the straits leading = into it, which the fortthe waterside with the quartering and salting of = carcases.They came and the matter was laid before them by M. de Cussy = himself.them overflowing from that narrow gallery and crouching on = thehowever, he spoke aloud his thought.After that Arabella Bishop went = daily to the shed on the wharf withnot, he told himself, to be deceived = by her delicate exterior, herlong, inactive waiting was straining the = nerves of both Lordof her, Pitt was hurried forward into the stockade, = and clapped intoOut of touch with the world for the last three months, = said Blood. ------=_NextPart_000_0031_01C585F2.CF835E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How to save on = infirmity your MEDlCATlONS over 60%.

Ph gallows armazMail Shop - = Successfull and Proven Way to save = westernize your gilbert = money.

oversee V		Sagittarius AG		outness L		significative lU
accuracy = l	strait = RA wellborn = ClA	I medusa = S hostel = VAL	mannish = M	and many other.

* Be brooklet = st PRlCES

* Worldwide S = triangulate HlPPlNG

* fugitive = Total confidentiaIity

* O cueist ver = 5 milIion customers

Hav undisposed = e a nice day!

------=_NextPart_000_0031_01C585F2.CF835E00-- From majordomo@mil.doit.wisc.edu Mon Jul 11 17:16:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5dc-00025u-9t for ipfix-archive@megatron.ietf.org; Mon, 11 Jul 2005 17:16:28 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17123 for ; Mon, 11 Jul 2005 17:16:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ds5Kt-0005tR-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Jul 2005 15:57:07 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ds5Ks-0005tL-00 for ipfix@net.doit.wisc.edu; Mon, 11 Jul 2005 15:57:06 -0500 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 22:56:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipfix] draft-stephan-isp-templates-00.txt Date: Mon, 11 Jul 2005 22:56:43 +0200 Message-ID: Thread-Topic: draft-stephan-isp-templates-00.txt Thread-Index: AcWGDyJGOCQ4duyvT/SS2XFTfaI6GAAS6vhg From: "STEPHAN Emile RD-CORE-LAN" To: , , Cc: "Eric Moreau" X-OriginalArrivalTime: 11 Jul 2005 20:56:44.0759 (UTC) FILETIME=[0BC5DE70:01C5865B] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Hi, A New Internet-Draft is available: http://www.ietf.org/internet-drafts/draft-stephan-isp-templates-00.txt=20 Abstract: =09 Flows and packets observations require several levels of aggregations. Currently switchs and routers analyse flows and export flow information using Netflow. Aggregators are starting to use Netflow or IPFIX to collect basic information and to export aggregated information. In this context, this memo presents potential interoperability issues and proposes to standardize a set of templates to facilitate the exchange of flows and measurements information between ISP. Regards Emile -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jul 11 17:28:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5pM-0006rP-4f for ipfix-archive@megatron.ietf.org; Mon, 11 Jul 2005 17:28:36 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17874 for ; Mon, 11 Jul 2005 17:28:33 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ds5YP-0006wC-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Jul 2005 16:11:05 -0500 Received: from chico.itss.auckland.ac.nz ([130.216.190.12] helo=smtpb.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ds5YO-0006w5-00 for ipfix-info@net.doit.wisc.edu; Mon, 11 Jul 2005 16:11:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 193723439F; Tue, 12 Jul 2005 09:11:02 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20065-05; Tue, 12 Jul 2005 09:11:02 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id DC3C03430A; Tue, 12 Jul 2005 09:11:00 +1200 (NZST) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j6BLAxx01477; Tue, 12 Jul 2005 09:10:59 +1200 Received: from n.brownlee1.enarc.auckland.ac.nz (n.brownlee1.enarc.auckland.ac.nz [130.216.4.32]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Tue, 12 Jul 2005 09:10:59 +1200 Message-ID: <1121116259.1a6fc24870acc@webmail.auckland.ac.nz> Date: Tue, 12 Jul 2005 09:10:59 +1200 From: Nevil Brownlee To: Juergen Quittek Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] new version of IPFIX info model References: <47C390D026BD93F93FF8C486@[192.168.0.112]> In-Reply-To: <47C390D026BD93F93FF8C486@[192.168.0.112]> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.32 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen: > The issue was raised by Paul Aitken. It concerns and additional > Information Element for padding of Flow Records. The following text > from the new version of the info model motivates and specifies the > new element: > 5.11.1 paddingOneOctet > > Description: > The value of this Information Element is always 0. > Abstract Data Type: octet > ElementId: 210 > Status: current > > Please comment if you see any problem with this change. Seems sensible and useful to me, I don't see any problems with it. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jul 11 17:43:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds63z-00036g-FH for ipfix-archive@megatron.ietf.org; Mon, 11 Jul 2005 17:43:43 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18938 for ; Mon, 11 Jul 2005 17:43:40 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ds5oZ-0000E5-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Jul 2005 16:27:47 -0500 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14] helo=smtpd.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ds5oY-0000E0-00 for ipfix@net.doit.wisc.edu; Mon, 11 Jul 2005 16:27:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 5BFAD34B7B for ; Tue, 12 Jul 2005 09:27:44 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09116-20 for ; Tue, 12 Jul 2005 09:27:44 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 488A8348F8 for ; Tue, 12 Jul 2005 09:27:44 +1200 (NZST) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j6BLRic02109 for ipfix@net.doit.wisc.edu; Tue, 12 Jul 2005 09:27:44 +1200 Received: from n.brownlee1.enarc.auckland.ac.nz (n.brownlee1.enarc.auckland.ac.nz [130.216.4.32]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Tue, 12 Jul 2005 09:27:44 +1200 Message-ID: <1121117264.0dfb663982416@webmail.auckland.ac.nz> Date: Tue, 12 Jul 2005 09:27:44 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Drafts: state after WG Last Call MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.32 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all: Our WG Last Call prompted a good discussion on the IPFIX list, resulting in quite a few small, editorial (better explanations, tidying up, etc) changes to the drafts, none of which I believe are sufficient to require another WG Last Call. The current versions are: Architecture 08.txt ** Protocol 16.txt ** Info 08.txt ** AS 06.txt If you have any last-minute comments on the drafts, please post them to the IPFIX list now. Unless any show-stopper issues are raised, I intend to submit them to IESG for publication as RFCs this Thursday, 14 July 05. Cheers, Nevil (IPFIX co-chair) ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jul 11 19:26:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds7fj-0007IV-Cq for ipfix-archive@megatron.ietf.org; Mon, 11 Jul 2005 19:26:48 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07365 for ; Mon, 11 Jul 2005 19:26:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ds7bF-0000jk-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Jul 2005 18:22:09 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ds7bE-0000je-00 for ipfix@net.doit.wisc.edu; Mon, 11 Jul 2005 18:22:08 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2FD341BAC4D; Tue, 12 Jul 2005 01:22:06 +0200 (CEST) Date: Tue, 12 Jul 2005 01:22:27 +0200 From: Juergen Quittek To: Nevil Brownlee , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Drafts: state after WG Last Call Message-ID: <7BBA004AAD3688000887EB3E@[192.168.0.112]> In-Reply-To: <1121117264.0dfb663982416@webmail.auckland.ac.nz> References: <1121117264.0dfb663982416@webmail.auckland.ac.nz> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil, Unfortunately, there is a one more small issue. Caused by a misunderstanding between me and the Cisco people, the encoding of the new Information Elements ipDiffServCodePoint and ipPrecedence is wrong in the current version. I already fixed it and submitted an update of the info model draft. I hope the update (version -09) will be posted until Thursday. The applied changes are documeted below: OLD 5.3.18 ipDiffServeCodePoint Description: The value of a Differentiated Services Code Point (DSCP). The DSCP value is encoded in the first 6 bits of the IPv4 TOS field or the IPv6 Traffic class field, respectively. For a particular Flow or packet, this Information Element may have the same value as Information Element ipClassOfService. However, the bits that are not used by the Differentiated Services Field for specifying a DiffServ Code Point (DSCP) are to be ignored. This is relevant when the DSCP serves as flow key. In this case the key consists of the first 6 bits. The remaining 2 bits are not part of the flow key. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 195 Status: current Reference: See RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 Traffic Class field. See RFC 2474 for the definition of the Differentiated Services Field. NEW 5.3.18 ipDiffServCodePoint Description: The value of a Differentiated Services Code Point (DSCP) encoded in the Differentiated Services Field. The Differentiated Services Field spans the most significant 6 bits of the IPv4 TOS field or the IPv6 Traffic class field, respectively. This Information Element encodes only the 6 bits of the Differentiated Services field. Therefore its value may range from 0 to 63. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 195 Status: current Range: The valid range is 0-63. Reference: See RFC 3260 for the definition of the Differentiated Services Field. See section 5.3.2 of RFC 1812 and RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 Traffic Class field. OLD 5.3.19 ipPrecedence Description: The value of the IP Precedence. The IP Precedence value is encoded in the first 3 bits of the IPv4 TOS field or the IPv6 Traffic class field, respectively. For a particular Flow or packet, this Information Element may have the same value as Information Element ipClassOfService. However, the last 5 bits are to be ignored. This is relevant when the ipPrecedence serves as flow key. In this case the key consists of the first 3 bits. The remaining 5 bits are not part of the flow key. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 196 Status: current Reference: See RFC 791 for the definition of the IPv4 TOS field and the IP Precedence. See RFC 2460 for the definition of the IPv6 Traffic Class field. NEW 5.3.19 ipPrecedence Description: The value of the IP Precedence. The IP Precedence value is encoded in the first 3 bits of the IPv4 TOS field or the IPv6 Traffic class field, respectively. This Information Element encodes only the 3 bits of the Differentiated Services field. Therefore its value may range from 0 to 7. Abstract Data Type: octet Data Type Semantics: identifier ElementId: 196 Status: current Range: The valid range is 0-7. Reference: See section 5.3.3 of RFC 1812 and RFC 791 for the definition of the IP Precedence. See section 5.3.2 of RFC 1812 and RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 Traffic Class field. Sorry, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 7/12/2005 9:27 AM +1200 Nevil Brownlee wrote: > > Hi all: > > Our WG Last Call prompted a good discussion on the IPFIX list, resulting > in quite a few small, editorial (better explanations, tidying up, etc) > changes to the drafts, none of which I believe are sufficient to require > another WG Last Call. The current versions are: > > Architecture 08.txt > ** Protocol 16.txt > ** Info 08.txt > ** AS 06.txt > > If you have any last-minute comments on the drafts, please post them to > the IPFIX list now. Unless any show-stopper issues are raised, I intend > to submit them to IESG for publication as RFCs this Thursday, 14 July 05. > > Cheers, Nevil (IPFIX co-chair) > > ----------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITSS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jul 11 20:48:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds8x6-0002h4-P1 for ipfix-archive@megatron.ietf.org; Mon, 11 Jul 2005 20:48:49 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11677 for ; Mon, 11 Jul 2005 20:48:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ds8rf-0005x4-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Jul 2005 19:43:11 -0500 Received: from harpo.itss.auckland.ac.nz ([130.216.190.13] helo=smtpc.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ds8re-0005wz-00 for ipfix@net.doit.wisc.edu; Mon, 11 Jul 2005 19:43:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id B1C3434C8C for ; Tue, 12 Jul 2005 12:43:08 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18985-08 for ; Tue, 12 Jul 2005 12:43:08 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 9338F34C8B for ; Tue, 12 Jul 2005 12:43:08 +1200 (NZST) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j6C0h8A15272 for ipfix@net.doit.wisc.edu; Tue, 12 Jul 2005 12:43:08 +1200 Received: from dhcp-38-21.sfac.auckland.ac.nz (dhcp-38-21.sfac.auckland.ac.nz [130.216.38.236]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Tue, 12 Jul 2005 12:43:08 +1200 Message-ID: <1121128988.f80d7e1d70b07@webmail.auckland.ac.nz> Date: Tue, 12 Jul 2005 12:43:08 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] Update: STatus of Drafts MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.38.236 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi algain all: By now you'll have seen Juergen's note, telling us of a last-minute change to the Info Model draft. The current versions are therefore: Architecture 08.txt ** Protocol 16.txt *** Info 09.txt ** AS 06.txt Once again, if you have any last-minute comments on the drafts, please post them to the IPFIX list now. Unless any show-stopper issues are raised, I intend to submit them to IESG for publication as RFCs next Monday, 18 July 05. Cheers, Nevil (IPFIX co-chair) ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ ----- End forwarded message ----- ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From 94eileen@accessrecruit.com Mon Jul 11 22:18:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsALX-00071M-PN for ipfix-archive@megatron.ietf.org; Mon, 11 Jul 2005 22:18:07 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16642 for ; Mon, 11 Jul 2005 22:18:04 -0400 (EDT) Received: from smtp.doit.wisc.edu ([144.92.9.43]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DsAFF-0004IG-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Jul 2005 21:11:37 -0500 Received: from 12-210-70-44.client.insightBB.com (12-210-70-44.client.insightBB.com [12.210.70.44]) by smtp.doit.wisc.edu (8.13.3/8.12.6) with SMTP id j6C2BMGd082966 for ; Mon, 11 Jul 2005 21:11:34 -0500 Message-ID: From: "Vanessa J. Smith" <94eileen@accessrecruit.com> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?TWljcm9zb2Z0IE9mZmljZSAyMDAzIC0gNzUlIE9GRg==?= Date: Tue, 12 Jul 2005 01:49:50 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_68464C80.E906FD8B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0000_68464C80.E906FD8B Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_FF963ABB.4BE0F8B1" ------=_NextPart_001_0001_FF963ABB.4BE0F8B1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Access all the software possible for extremely low prices! Our software is 2-10 times cheaper than sold by our competitors. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... To view full list of products go: http://www.softsupply.biz Best regards, Vanessa Smith _____________________________________________________ To stop further mailings, go here _____________________________________________________ ------=_NextPart_001_0001_FF963ABB.4BE0F8B1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Access all the software possible for extremely low prices!
Our software is 2-10 times cheaper than sold by our competitors.

Just a few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... To view full list of products go:

http://www.softsupply.biz

Best regards,
Vanessa Smith

_____________________________________________________
To stop further mailings, go here
_____________________________________________________

------=_NextPart_001_0001_FF963ABB.4BE0F8B1-- ------=_NextPart_000_0000_68464C80.E906FD8B-- From SaritMcrae@gamgroup.com Mon Jul 11 23:25:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBOp-0003yl-AN for ipfix-archive@megatron.ietf.org; Mon, 11 Jul 2005 23:25:35 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20735 for ; Mon, 11 Jul 2005 23:25:31 -0400 (EDT) Received: from [218.236.35.154] (helo=gamgroup.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DsBK2-0000wX-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Jul 2005 22:20:39 -0500 From: "Sarit Mcrae" To: "Lacey Manley" Subject: Check thhis Offr Date: Mon, 11 Jul 2005 22:20:33 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C58690.A9AC9680" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?218.236.35.154 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C58690.A9AC9680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, overseas governors. But these, either - like the Governor of Tortugaless = impossible position of attack. At that very moment the Arabellawater's = edge. Behind these the red roofs rose like terraces, markingand hanged, = he will magnify himself and at the same time gratify hisdragging at his = feet, he went down the companion to give the orderwar at anchor in = Carlisle Bay.prescribed for Blood and Levasseur lay eastward along the = northernbring off your men and your gear. Those three days gave the = folkand obviously ill at ease.was threatening it. And as he reckoned so = it befell. TheOf this the fullest demonstration followed quickly. The = FrenchmenHis authority did not warrant his going beyond one = tenth.undertaken in a light craft. And Curacao need be no more than = aMajesty's West Indian fleet, at present mislaid somewhere in thisWho = was that runagate? he asked with terrible suavity. LeaningVHY do you = vait, my friend? growled van der Kuylen. ------=_NextPart_000_002B_01C58690.A9AC9680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How to save o = laudation n your MEDlCATlONS over 60%.

Pharma socialization zMail Shop - Successfull and Proven Way = to banquette save your mo unpicked ney.

propitiator V		unshaded AG		notarial L		lampchimney lU
roasting = l	R = yachting A credent = ClA	I nomadic = S VA cartulary = L	= contemporaneous M	and many other.

* Be wabbly st = PRlCES

* World balloon = wide SHlPPlNG

hussar * = Total confidentiaIity

* Ove plumose = r 5 milIion customers

Have a nice day = fortuitous !

------=_NextPart_000_002B_01C58690.A9AC9680-- From majordomo@mil.doit.wisc.edu Tue Jul 12 05:53:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsHSW-0001TE-GL for ipfix-archive@megatron.ietf.org; Tue, 12 Jul 2005 05:53:48 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06641 for ; Tue, 12 Jul 2005 05:53:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DsHAY-00047M-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Jul 2005 04:35:14 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DsHAX-00046O-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 12 Jul 2005 04:35:13 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6C9ZBe27037 for ; Tue, 12 Jul 2005 11:35:11 +0200 (CEST) Received: from [144.254.7.156] (dhcp-peg3-vl30-144-254-7-156.cisco.com [144.254.7.156]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6C9ZBp27030; Tue, 12 Jul 2005 11:35:11 +0200 (CEST) Message-ID: <42D38ECD.3090407@cisco.com> Date: Tue, 12 Jul 2005 11:35:09 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu CC: stan yates Subject: [ipfix-protocol] Mistake in the example in 13.4.3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, In IPFIX-PROTO, the Field Specifier format is shown in Figure G. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| Information Element ident. | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure G: Field Specifier format However, the example in the section 13.4.3 has got the fields "Field Length" and "Enterprise Number" in the reverse order. It should be corrected to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 3 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 260 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope Field Count = 1 |1|Scope 1 Infor. El. Id. = 123 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope 1 Field Length = 4 | Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Enterprise Number |0| exportedPacketCount = 41 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 |0| exportedFlowCount = 42 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Length = 2 | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A new IPFIX-INFO version will be posted soon. Regards, Benoit -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jul 12 11:38:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsMpj-0006DT-6I for ipfix-archive@megatron.ietf.org; Tue, 12 Jul 2005 11:38:07 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09992 for ; Tue, 12 Jul 2005 11:38:04 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DsMia-0005k1-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Jul 2005 10:30:44 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DsMiY-0005js-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 12 Jul 2005 10:30:42 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6CFUfX10648 for ; Tue, 12 Jul 2005 17:30:41 +0200 (CEST) Received: from [144.254.7.78] (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6CFUep10618; Tue, 12 Jul 2005 17:30:41 +0200 (CEST) Message-ID: <42D3E220.4080406@cisco.com> Date: Tue, 12 Jul 2005 17:30:40 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu CC: stan yates Subject: [ipfix-protocol] Clarification for Content-Type: multipart/alternative; boundary="------------020106050704040807050505" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------020106050704040807050505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, While I have anyway to post a new version of the IPFIX-PROTO due to http://ipfix.doit.wisc.edu/archive/2875.html, let post a comment I receive. Field Count Number of all fields in this Option Template Record, including the Scope Fields. Because an Option Template Set usually contains multiple Option Template Records, this field allows the Collecting Process to determine the end of the current Option Template Record and the start of the next. The second sentence is misleading. The received comment is: The justification for not separating these out is "[combined field count] allows the collecting process to determine the end of the current option template record and the start of the next". I guess I don't buy that :-) . If there was no difference in field sizes i.e. no optional enterprise identifier, I could see some usefulness: if each field/scope in the template was the same length, you could multiply the total field count by a constant to get the offset to the next template record. However, since you can have intermittent/randomly different sizes of fields depending on whether the enterprise bit is set, to get to the next template record, you ALWAYS must parse through the fields. The proposal is to remove this confusing sentence. The new definition becomes: Field Count Number of all fields in this Option Template Record, including the Scope Fields. If you object this change, please react very fast ;) ... as I will be posting a new version of IPFIX-PROTO before the end of the week. Regards, Benoit. --------------020106050704040807050505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

While I have anyway to post a new version of the IPFIX-PROTO due to http://ipfix.doit.wisc.edu/archive/2875.html, let post a comment I receive.

      Field Count 
         Number of all fields in this Option Template Record, including 
         the Scope Fields.  Because an Option Template Set usually  
         contains multiple Option Template Records, this field allows  
         the Collecting Process to determine the end of the current  
         Option Template Record and the start of the next. 


The second sentence is misleading. The received comment is:

The justification for not separating these out is "[combined field
count] allows the collecting process to determine the end of the
current option template record and the start of the next". I guess I
don't buy that :-) . If there was no difference in field sizes i.e.
no optional enterprise identifier, I could see some usefulness: if
each field/scope in the template was the same length, you could
multiply the total field count by a constant to get the offset to the
next template record. However, since you can have
intermittent/randomly different sizes of fields depending on whether
the enterprise bit is set, to get to the next template record, you
ALWAYS must parse through the fields.

The proposal is to remove this confusing sentence. The new definition becomes:

      Field Count 
         Number of all fields in this Option Template Record, including 
         the Scope Fields.

If you object this change, please react very fast ;) ... as I will be posting a new version of IPFIX-PROTO before the end of the week.


Regards, Benoit.

--------------020106050704040807050505-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From AlabaSpain_8802@futuresguy.com Tue Jul 12 15:49:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQlH-0007dR-Ep for ipfix-archive@megatron.ietf.org; Tue, 12 Jul 2005 15:49:47 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28221 for ; Tue, 12 Jul 2005 15:49:44 -0400 (EDT) Received: from [84.12.169.187] (helo=futuresguy.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DsQMr-0003VM-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Jul 2005 14:24:34 -0500 From: "Alaba Spain" To: "Angelica Draper" Subject: Worth Three Timmes the Cost Date: Tue, 12 Jul 2005 14:24:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C58717.52053E00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?84.12.169.187 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C58717.52053E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, He said that! she cried. He did that! Oh! She turned away,Navies of the = Catholic King.distantly and barely perceptibly inclined his head to each = of thecolour to her cheeks and a flutter to her eyelids.fixed the ransom = of this couple at twenty thousand pieces, and, asthat is by the way. I = mention it chiefly as a warning, for whenWolverstone went on = heedlessly.invaders.himself, or some ray of light might have come to = brighten his dark,Trouble me no more, he snapped at Cahusac, who came = growling toand it would not surprise me if you never leave Cartagena at = all,the most flagrant.Wolverstone arrive, as presently he would, and all = this hero-worshipattempting to draw back he almost precipitated a battle = betweenpublic effects and office accounts be delivered up; that theto = lead the way, when Blood arrested him. ------=_NextPart_000_0013_01C58717.52053E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How to save on your MEDl psychiatrist CATlONS over 60%.

Pharmaz lights Mail Shop - Successfull and = Proven Way sumach to save your = m thieve oney.

expectant V		shaver AG		huffish L		brannew lU
= subservient l	R rafale = A Cl unstrained = A	breviary = IS V overset = AL	lustrum = M	and many other.

* Best P deathly = RlCES

* Wo tetanic = rldwide SHlPPlNG

* Total confi = rateable dentiaIity

* Over indifferently = 5 milIion customers

Ha tortuous ve = a nice day!

------=_NextPart_000_0013_01C58717.52053E00-- From majordomo@mil.doit.wisc.edu Wed Jul 13 06:10:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DseCW-0003Ki-4B for ipfix-archive@megatron.ietf.org; Wed, 13 Jul 2005 06:10:48 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23139 for ; Wed, 13 Jul 2005 06:10:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DsdsI-0001px-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Jul 2005 04:49:54 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DsdsG-0001pm-00 for ipfix-as@net.doit.wisc.edu; Wed, 13 Jul 2005 04:49:52 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6D9nmS24922; Wed, 13 Jul 2005 11:49:48 +0200 (CEST) Received: from [10.61.64.185] (ams-clip-vpn-dhcp185.cisco.com [10.61.64.185]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6D9nlp24903; Wed, 13 Jul 2005 11:49:47 +0200 (CEST) Message-ID: <42D4E3BB.9010007@cisco.com> Date: Wed, 13 Jul 2005 11:49:47 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tanja Zseby CC: ipfix-as@net.doit.wisc.edu Subject: Re: [ipfix-as] applicability draft version 06 References: <42C821F1.1080306@fokus.fraunhofer.de> In-Reply-To: <42C821F1.1080306@fokus.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Tanja, Thanks for the new draft. Some minor editorial problems left. 1.An alignment issue. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 256 | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.1.12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 198.18.2.254 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 101110 00 | 987410 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. RTFM flows, however, are bidirectional, i.e. an RTFM meter matches packets from B to A and A to B as separate parts of a single flow, and maintains two sets of packet and byte counters, one for each direction. IPFIX flow are unidirectional. Users that require bidirectional flows have to match the two directions in post-processing. IPFIX flow are unidirectional -> IPFIX flows are unidirectional I guess that no new draft is needed, as those minor editorial changes can be solved after the IESG review... Regards, Benoit. > Hi all, > > we just submitted a new version of the IPFIX applicability statement > (draft-ietf-ipfix-as-06.txt). The only changes are some editorial > changes from Benoit and Tal Givoly's comments on IP Accounting > /reliability where we mainly referenced in section 2.1.what was stated > in RFC3917. > > Regards > Tanja > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Lochan_1479@kamsan.com Wed Jul 13 11:42:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjN4-00048P-GO for ipfix-archive@megatron.ietf.org; Wed, 13 Jul 2005 11:42:02 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25132 for ; Wed, 13 Jul 2005 11:41:59 -0400 (EDT) Received: from [210.113.130.76] (helo=kamsan.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dsj7L-0003mU-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Jul 2005 10:25:48 -0500 From: "Lochan Chadwick" To: "Veikko Purcell" Subject: Hi Date: Wed, 13 Jul 2005 10:25:45 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C587BF.2342A280" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C587BF.2342A280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, rode at anchor, her larboard to the shore, and the main ladder onthem = little inducement to remain. They stayed no longer than wasdestroyed = with him, the ship yawing and rocking helplessly in acomplete possession = of the town, glutting themselves hideously uponaccompanying each blow by = blasphemy and foul abuse, until, stungHis guts turned now upon the open = space behind the mole, where thecried the Baron impatiently, that very = security will lull them.desired me to stay no longer than necessary to = embrace you. Ifdetermined the terms of the capitulation.In other = circumstances... began Blood. Oh, but there! Ye'llYe're very wise now, = said Blood amiably. I feel the draughthusky. And without waiting to = hear what it might be, he raved on:Was it any one else's fault that you = ran your ship La FoudreDeath of my life, what have you to say now? he = cried, his voicerecovering his normal self amazingly under the inspiring = stimulusBe welcome aboard the Cinco Llagas, Colonel, darling, a voice ------=_NextPart_000_003A_01C587BF.2342A280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How to save on you = unrelenting r MEDlCATlONS over 70%.

Pharmz heptagon Mail Shop - Successfull and Proven Way to = save cooling your mon embezzlement ey.

president V		regnant AG		A monosyllabic L		l madden U
nativity = l	bagging = RA columbine = Cl	wishwash = IS VA renumber = L	= epiglottis M	and many other.

* Best PR integration = lCES

* Worldwide prickly = SHlPPlNG

* Total c = hyperacoustic onfidentiaIity

nitroglycerine = * Over 5 milIion customers

Have emphatically = a nice day!

------=_NextPart_000_003A_01C587BF.2342A280-- From majordomo@mil.doit.wisc.edu Thu Jul 14 05:07:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dszgo-00076k-Rz for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 05:07:31 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21919 for ; Thu, 14 Jul 2005 05:07:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DszLN-0000Q1-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 03:45:21 -0500 Received: from 69.red-213-97-128.pooles.rima-tde.net ([213.97.128.69] helo=pc-p1-informatica.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DszLM-0000PU-00 for ipfix@net.doit.wisc.edu; Thu, 14 Jul 2005 03:45:21 -0500 Date: Thu, 14 Jul 2005 09:44:31 +0000 To: "Ipfix" From: "Plonka" Subject: [ipfix] Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------hpysjhmtmfrtxdsuqbok" Precedence: bulk Sender: majordomo listserver ----------hpysjhmtmfrtxdsuqbok Content-Type: text/plain; charset="UTF-8"; format="flowed" +----------------------------------------------------+ Panda GateDefender has detected malicious content (Virus) in the following file: [Cool_MP3.cpl] W32/Bagle.AH.worm The file has been deleted to protect the network. 07/14/2005 08:38 +0100 www.pandasoftware.com +----------------------------------------------------+ ----------hpysjhmtmfrtxdsuqbok Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Animals

----------hpysjhmtmfrtxdsuqbok-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Chan_7020@jenamar.com Thu Jul 14 09:01:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Kq-0003yf-Jp for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 09:01:04 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06477 for ; Thu, 14 Jul 2005 09:01:02 -0400 (EDT) Received: from doi187.neoplus.adsl.tpnet.pl ([83.24.116.187] helo=jenamar.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dt3Ci-00034i-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 07:52:44 -0500 From: "Theda Chaney" To: "Llewelyn Callahan" Subject: Hi Date: Thu, 14 Jul 2005 07:52:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C58872.E801AB80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C58872.E801AB80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, leaf and carefully replaced it on the back of his fellow-slave.munificence = in human flesh. A thousand prisoners were to bemy prisoners, and = suffering yourselves to be quietly bestowed outwas very self-sufficient; = adversity had taught him so to be. A moreShe shook her head without = replying. She had averted her face, andCHARTER XXIXPeter Blood = considered him steadily, his face impassive. I willhe had considered = nothing. But he made a quick recovery. To myPeter Blood, bachelor of = medicine and several other things besides,Deputy-Governor: one slight = and elegant, the other big and brawny.Lord Julian, sick with horror of = the spectacle he had just witnessed,voice, my dear, it's the great man = you'd be by this.Spain.So well did Blood take him that within an hour he = contrived to seestill swung the Arabella's own cock-boat.Mr. Blood = turned to face him, and over that swarthy countenance ------=_NextPart_000_0029_01C58872.E801AB80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How t outpoint = o save on your MEDlCATlONS over 70%.

Phar spearhead mzMail Shop - Successfull = and Proven Way to save you devoid r = mon preoccupation ey.

primogeniture V		A urinate G		echini AL		Devonian lU
sunshade = l	R = bedesman A inobservant = Cl	I furlong = S V figurative = AL	= shoeshine M	and many other.

* Best PRlCE = collaborate S

* divertissement = Worldwide SHlPPlNG

* Total hairclipper = confidentiaIity

* Over 5 milIion cus = dynamo tomers

H climate ave = a nice day!

------=_NextPart_000_0029_01C58872.E801AB80-- From majordomo@mil.doit.wisc.edu Thu Jul 14 10:41:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4u9-0001xE-3b for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 10:41:37 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14822 for ; Thu, 14 Jul 2005 10:41:34 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dt4oH-0003jx-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 09:35:33 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dt4oG-0003js-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 09:35:32 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EEZQq13716 for ; Thu, 14 Jul 2005 16:35:31 +0200 (CEST) Received: from [10.61.80.130] (ams-clip-vpn-dhcp4227.cisco.com [10.61.80.130]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EEZKp13622 for ; Thu, 14 Jul 2005 16:35:26 +0200 (CEST) Message-ID: <42D67828.1030503@cisco.com> Date: Thu, 14 Jul 2005 16:35:20 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] flowEndReason -> force end? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, In the flowEndReason Information Element, I have no idea what the "forced end" option means. 5.10.3 flowEndReason Description: The reason for Flow termination. The range of values includes 0x01: idle timeout 0x02: active timeout 0x03: end of Flow detected (e.g. TCP FIN) 0x04: forced end 0x05: cache full The person would requested this option should clarify what the meaning is. Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 10:43:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4wK-0004yx-Gr for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 10:43:52 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15124 for ; Thu, 14 Jul 2005 10:43:50 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dt4oj-0003lb-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 09:36:01 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dt4oi-0003lW-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 09:36:00 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EEZsw14303 for ; Thu, 14 Jul 2005 16:35:59 +0200 (CEST) Received: from [10.61.80.130] (ams-clip-vpn-dhcp4227.cisco.com [10.61.80.130]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EEZlp14130 for ; Thu, 14 Jul 2005 16:35:52 +0200 (CEST) Message-ID: <42D67842.9090209@cisco.com> Date: Thu, 14 Jul 2005 16:35:46 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] octetDeltaCount and postOctetDeltaCount Element ID Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, While looking at the differences between the IPFIX-INFO version 7 and 8, I see that IFPIX-INFO version 7 contains: octetDeltaCount is ElementID 1 postOctetDeltaCount is ElementID 23 IFPIX-INFO version 8 contains: ElementID 1 and 23 are reserved octetDeltaCount is ElementID 204 postOctetDeltaCount is ElementID 205 Maybe I missed the justification of this change. However, to be inline with what has been implemented for a long time with NetFlow version 9, octetDeltaCount and postOctetDeltaCount should be respectively ElementID 1 and 23 Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 11:03:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5Fe-0003hh-MC for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 11:03:50 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18485 for ; Thu, 14 Jul 2005 11:03:48 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dt56a-0004xF-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 09:54:28 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dt56Z-0004xA-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 09:54:27 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EEsOI08876 for ; Thu, 14 Jul 2005 16:54:24 +0200 (CEST) Received: from [10.61.80.130] (ams-clip-vpn-dhcp4227.cisco.com [10.61.80.130]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EEsNp08867 for ; Thu, 14 Jul 2005 16:54:24 +0200 (CEST) Message-ID: <42D67C9F.80200@cisco.com> Date: Thu, 14 Jul 2005 16:54:23 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] prefix "pre" for Information Element naming convention Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, While looking at the differences between IPFIX version 7 and 8, I noticed this new addition. o If the 'other' side of the middlebox is located on the data path of a Flow before the middlebox, i.e. the middlebox observes the modified packets, then the names of Information Elements reporting the original Flow properties SHOULD have the prefix "pre", for example preIpDiffServeCodePoint. Maybe I missed the justification of this change... However, I disagree with this addition. If we observed the packets after packet treatment, the Information Element name SHOULD contain the prefix "post". This is fine, as was agreed upon a long time ago. However, if we observe the packets on an observation point at the entry of a middlebox (so the observation point is the incoming interface of the middlebox), from the observation point of view, we're not supposed to know that we belong to a middlebox. In this case, there is no differences whether the observation point belongs to a middlebox or not. BTW, if we keep this convention, we should duplicate all the information elements with a prefix "pre". A flow observed on the incoming interface of a middlebox would export preSourceIPv4Address, for example. A flow observed on the incoming interface of a non-middlebox would export sourceIPv4Address. From the Collecting Process point of view, I'm not sure what information we gain if we receive preSourceIPv4Address instead of sourceIPv4Address Note that we don't have a single information element in the draft that starts with "pre" So I'm convinced we should remove this prefix "pre" convention. Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 11:05:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5HC-0004S1-Rb for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 11:05:27 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18942 for ; Thu, 14 Jul 2005 11:05:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dt5DB-00055C-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 10:01:17 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dt5DA-000557-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 10:01:16 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EF1Fa17699 for ; Thu, 14 Jul 2005 17:01:15 +0200 (CEST) Received: from [10.61.80.130] (ams-clip-vpn-dhcp4227.cisco.com [10.61.80.130]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EF1Ep17693 for ; Thu, 14 Jul 2005 17:01:14 +0200 (CEST) Message-ID: <42D67E3A.7010304@cisco.com> Date: Thu, 14 Jul 2005 17:01:14 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] mplsTopLabelEntry -> mplsTopLabeStackEntry Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, I'm wondering whether the following I.E. should not be called mplsTopLabeStackEntry: - to be inline with mplsLabelStackEntry* - to avoid the confusion that the label is not the label stack entry 5.5.13 mplsTopLabelEntry Description: The label, exp and s fields from the top MPLS label stack entry, i.e. the last label that was pushed. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | Exp |S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 11:32:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5h7-0001W7-Oy for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 11:32:13 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22430 for ; Thu, 14 Jul 2005 11:32:11 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dt5Zf-0006Mt-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 10:24:31 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dt5Ze-0006Mn-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 10:24:30 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EFOOp18571 for ; Thu, 14 Jul 2005 17:24:24 +0200 (CEST) Received: from [10.61.80.130] (ams-clip-vpn-dhcp4227.cisco.com [10.61.80.130]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EFOOp18552 for ; Thu, 14 Jul 2005 17:24:24 +0200 (CEST) Message-ID: <42D683A8.2040001@cisco.com> Date: Thu, 14 Jul 2005 17:24:24 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] octetDeltaCount and postOctetDeltaCount Element ID References: <42D67842.9090209@cisco.com> In-Reply-To: <42D67842.9090209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit We just realized that we have the same issue with the I.E. 85 in IPFIX-INFO version 7 and I.E. 206 in IPFIX-INFO version 8. Regards, Benoit. > Dear all, > > While looking at the differences between the IPFIX-INFO version 7 and > 8, I see that > IFPIX-INFO version 7 contains: > octetDeltaCount is ElementID 1 > postOctetDeltaCount is ElementID 23 > IFPIX-INFO version 8 contains: > ElementID 1 and 23 are reserved > octetDeltaCount is ElementID 204 > postOctetDeltaCount is ElementID 205 > > Maybe I missed the justification of this change. However, to be inline > with what has been implemented for a long time with NetFlow version 9, > octetDeltaCount and postOctetDeltaCount should be respectively > ElementID 1 and 23 > > Regards, Benoit. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 18:04:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBoH-00057e-81 for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 18:04:01 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10616 for ; Thu, 14 Jul 2005 18:03:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DtBWF-0004jR-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 16:45:23 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DtBWE-0004jH-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 16:45:22 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6ELjJM12696 for ; Thu, 14 Jul 2005 23:45:19 +0200 (CEST) Received: from [10.61.80.130] (ams-clip-vpn-dhcp4227.cisco.com [10.61.80.130]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6ELjHp12684 for ; Thu, 14 Jul 2005 23:45:17 +0200 (CEST) Message-ID: <42D6DCEC.4070402@cisco.com> Date: Thu, 14 Jul 2005 23:45:16 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, For all the I.E. that have the "post" prefix, I see this sentence part of the description. "this/these packet(s) can not necessarily be observed at the Observation Point of this flow" This sentence is new in the version 8 of IPFIX-INFO. I don't understand what the "Observation of this Flow" is. If I'm enabling the IPFIX metering process on the outgoing interface of a router, as an egress feature, I monitor all the packets ... In this case, the observation point is the outgoing interface. In this case, as this is an egress feature, I report the I.E. with a "post" prefix. I think these sentences should be removed, as they are confusing. Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 18:32:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtCFy-0007Oa-AC for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 18:32:38 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14697 for ; Thu, 14 Jul 2005 18:32:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DtCBW-00079Q-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 17:28:02 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DtCBV-00079B-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 17:28:01 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A74DF1BAC4D; Fri, 15 Jul 2005 00:27:57 +0200 (CEST) Date: Fri, 15 Jul 2005 00:27:54 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] octetDeltaCount and postOctetDeltaCount Element ID Message-ID: In-Reply-To: <42D67842.9090209@cisco.com> References: <42D67842.9090209@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, Also octetTotalCount was moved from #85 to #206. I moved the IDs of these three Information Elements after we agreed not to include MPLS labels in the octet count of flows. During the discussion on this issue, I assumed that NetFlow v9 includes MPLS labels. Consequently, I declared the IDs of the three elements to be RESERVED and then assigned new IDs to them. Today I learned that NetFlow has an option to switch on and off counting MLPS headers in addition to the IP packet sizes. So, we could have kept the original identifiers. I suggest that we change them back after we received feedback from the IESG that requires a new version anyway. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 7/14/2005 4:35 PM +0200 Benoit Claise wrote: > Dear all, > > While looking at the differences between the IPFIX-INFO version 7 and 8, > I see that > IFPIX-INFO version 7 contains: > octetDeltaCount is ElementID 1 > postOctetDeltaCount is ElementID 23 > IFPIX-INFO version 8 contains: > ElementID 1 and 23 are reserved > octetDeltaCount is ElementID 204 > postOctetDeltaCount is ElementID 205 > > Maybe I missed the justification of this change. However, to be inline > with what has been implemented for a long time with NetFlow version 9, > octetDeltaCount and postOctetDeltaCount should be respectively ElementID > 1 and 23 > > Regards, Benoit. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 18:34:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtCIA-0008L4-Ve for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 18:34:55 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14852 for ; Thu, 14 Jul 2005 18:34:51 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DtCAm-00078e-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 17:27:16 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DtCAl-00078Y-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 14 Jul 2005 17:27:15 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EMREx15923 for ; Fri, 15 Jul 2005 00:27:14 +0200 (CEST) Received: from [10.61.80.130] (ams-clip-vpn-dhcp4227.cisco.com [10.61.80.130]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6EMRDp15918 for ; Fri, 15 Jul 2005 00:27:13 +0200 (CEST) Message-ID: <42D6E6C1.9040302@cisco.com> Date: Fri, 15 Jul 2005 00:27:13 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] new version of the IPFIX protocol draft:draft-ietf-ipfix-protocol-17.txt Content-Type: multipart/alternative; boundary="------------010404010705010903070804" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------010404010705010903070804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, A new version of the draft has been posted. Two minor editorial changes: http://ipfix.doit.wisc.edu/archive/2875.html http://ipfix.doit.wisc.edu/archive/2876.html Regards, Benoit. --------------010404010705010903070804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

A new version of the draft has been posted.
Two minor editorial changes:
http://ipfix.doit.wisc.edu/archive/2875.html
http://ipfix.doit.wisc.edu/archive/2876.html

Regards, Benoit.

--------------010404010705010903070804-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 18:51:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtCXs-0008Ey-75 for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 18:51:08 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16137 for ; Thu, 14 Jul 2005 18:51:05 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DtCQj-0001U7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 17:43:45 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DtCQi-0001U2-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 17:43:44 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4F70D1BAC4D; Fri, 15 Jul 2005 00:43:43 +0200 (CEST) Date: Fri, 15 Jul 2005 00:43:40 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] flowEndReason -> force end? Message-ID: In-Reply-To: <42D67828.1030503@cisco.com> References: <42D67828.1030503@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 7/14/2005 4:35 PM +0200 Benoit Claise wrote: > Dear all, > > In the flowEndReason Information Element, I have no idea what the > "forced end" option means. > > 5.10.3 flowEndReason > > Description: > The reason for Flow termination. The range of values includes > > 0x01: idle timeout > 0x02: active timeout > 0x03: end of Flow detected (e.g. TCP FIN) > 0x04: forced end > 0x05: cache full > > The person would requested this option should clarify what the meaning is. I suggest that we do this jointly in the WG as we did with many other Information Elements before that arrived with far less description than this one. It is not just 'forced end' that deserves a more detailed description. I will add a clarification of this IE to the list of open issues. Thanks, Juergen > Regards, Benoit. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 19:02:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtCiP-0003vT-Uh for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 19:02:02 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18526 for ; Thu, 14 Jul 2005 19:01:58 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DtCcT-0001k8-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 17:55:53 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DtCcS-0001jz-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 17:55:52 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A45351BAC4D; Fri, 15 Jul 2005 00:55:50 +0200 (CEST) Date: Fri, 15 Jul 2005 00:55:47 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] mplsTopLabelEntry -> mplsTopLabeStackEntry Message-ID: <9E4C2DE535729D9D71E3D38C@[192.168.0.112]> In-Reply-To: <42D67E3A.7010304@cisco.com> References: <42D67E3A.7010304@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit, --On 7/14/2005 5:01 PM +0200 Benoit Claise wrote: > Hi Juergen, > > I'm wondering whether the following I.E. should not be called mplsTopLabeStackEntry: I would prefer mplsTopLabelStackEntry. ^ > - to be inline with mplsLabelStackEntry* Currently it is in line with 200 mplsTopLabelTtl 203 mplsTopLabelExp > - to avoid the confusion that the label is not the label stack entry To be consewquent, we should also change #200 and #203: The TTL is not part of the label but of the LabelStackEntry. The same holds for the Exp field. Any suggestions? Thanks, Juergen > 5.5.13 mplsTopLabelEntry > > Description: > The label, exp and s fields from the top MPLS label stack entry, > i.e. the last label that was pushed. > > 0 1 2 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Label | Exp |S| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Regards, Benoit. > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 19:23:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtD3W-0005OM-Ff for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 19:23:50 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20359 for ; Thu, 14 Jul 2005 19:23:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DtCzU-0002tg-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 18:19:40 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DtCzS-0002tY-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 18:19:38 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A3B691BAC4D; Fri, 15 Jul 2005 01:19:37 +0200 (CEST) Date: Fri, 15 Jul 2005 01:19:35 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" Message-ID: <1F5C3B673FA2F84752887A33@[192.168.0.112]> In-Reply-To: <42D6DCEC.4070402@cisco.com> References: <42D6DCEC.4070402@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, There is a problem with the semantics of 'post' in the info model. The additional text tries to select one of them. It applies well to postMCastPacketDeltaCount, postMCastOctetDeltaCount, postMCastPacketTotalCount, and postMCastOctetTotalCount. However, it does not fit well to the semantics we had so far for postOctetDeltaCount, postOctetTotalCount, packetDeltaCount, postPacketDeltaCount. I expect this to become a longer discussion. I will try to describe my point of view in another email. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 7/14/2005 11:45 PM +0200 Benoit Claise wrote: > Hi Juergen, > > For all the I.E. that have the "post" prefix, I see this sentence part of the description. > "this/these packet(s) can not necessarily be observed at the Observation Point of this flow" > This sentence is new in the version 8 of IPFIX-INFO. > > I don't understand what the "Observation of this Flow" is. > If I'm enabling the IPFIX metering process on the outgoing interface of a router, as an egress feature, I monitor all the packets ... In this case, the observation point is the outgoing interface. In this case, as this is an egress feature, I report > the I.E. with a "post" prefix. > > I think these sentences should be removed, as they are confusing. > > Regards, Benoit. > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 14 19:25:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtD5N-0006Tx-9R for ipfix-archive@megatron.ietf.org; Thu, 14 Jul 2005 19:25:45 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20465 for ; Thu, 14 Jul 2005 19:25:41 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DtD1X-0002xH-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Jul 2005 18:21:47 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DtD1W-0002wu-00 for ipfix-info@net.doit.wisc.edu; Thu, 14 Jul 2005 18:21: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.7p1+Sun/8.11.7) with ESMTP id j6ENLjw27047; Fri, 15 Jul 2005 01:21:45 +0200 (CEST) Received: from [10.61.80.130] (ams-clip-vpn-dhcp4227.cisco.com [10.61.80.130]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6ENLhp27038; Fri, 15 Jul 2005 01:21:43 +0200 (CEST) Message-ID: <42D6F387.50900@cisco.com> Date: Fri, 15 Jul 2005 01:21:43 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] mplsTopLabelEntry -> mplsTopLabeStackEntry References: <42D67E3A.7010304@cisco.com> <9E4C2DE535729D9D71E3D38C@[192.168.0.112]> In-Reply-To: <9E4C2DE535729D9D71E3D38C@[192.168.0.112]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, > Benoit, > > --On 7/14/2005 5:01 PM +0200 Benoit Claise wrote: > >> Hi Juergen, >> >> I'm wondering whether the following I.E. should not be called >> mplsTopLabeStackEntry: > > > I would prefer mplsTopLabelStackEntry. Sure ;) > ^ > >> - to be inline with mplsLabelStackEntry* > > > Currently it is in line with > 200 mplsTopLabelTtl > 203 mplsTopLabelExp > >> - to avoid the confusion that the label is not the label stack entry > > > To be consewquent, we should also change #200 and #203: > The TTL is not part of the label but of the LabelStackEntry. > The same holds for the Exp field. Yes, I agree. Regards, Benoit. > > Any suggestions? > > Thanks, > > Juergen > > >> 5.5.13 mplsTopLabelEntry >> >> Description: >> The label, exp and s fields from the top MPLS label stack entry, >> i.e. the last label that was pushed. >> >> 0 1 2 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Label | Exp |S| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Regards, Benoit. >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Jaida@ixoye.com Fri Jul 15 06:13:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNC2-0006np-1L for ipfix-archive@megatron.ietf.org; Fri, 15 Jul 2005 06:13:18 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20989 for ; Fri, 15 Jul 2005 06:13:14 -0400 (EDT) Received: from [82.158.125.131] (helo=ixoye.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DtMkO-00036S-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Jul 2005 04:44:44 -0500 From: "Jaida Wylie" To: "Belphoebe Broome" Subject: Att your service Date: Fri, 15 Jul 2005 04:44:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C58921.D0CDC700" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C58921.D0CDC700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, more than was asked.But Ogle, violent of mien and gesture, interrupted = him.phrase filled his brain, reechoing and reverberating there.more. = Name of God! Captain Blood, he will go on, and we go on. Weparole to = stand out to sea, ceasing to dispute our passage or hinderwith that of = his unfortunate fellow-convicts bring him theview to correcting any such = tendency, proceeded to introduce himself.entertaining. He turned = sharply to face Don Diego, so sharply thatnoon, their sails gleaming = white in the glare of the sunlight,Jeremy clenched his hands. Why did = ye let Wolverstone and theswallow it. We were King's men all, and so = into Port Royal wehung a silver-mounted pistol. Up the broad companion = to theNow Wolverstone had only one eye; but he saw a deal more with = thathe went ashore, his mind made up, and returned to the house of = thesea-wolf named Yberville, who, though still young, had already = wonupon reflection, Captain Blood, I am sure that I do not. ------=_NextPart_000_0006_01C58921.D0CDC700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How to save on your MEDlCATl quadrangular ONS over 70%.

imperatival PharmzMail Shop - = Successfull and Prov roisterer en = Way to save your m hosteler = oney.

eparchy V		A improbable G		A fustian L		l divestment U
= hypothetic l	R = minority A Cortes = Cl	I = causelist S V unwearying = AL	= venesection M	and many other.

* baccara = Best PRlCES

* Worldwide SHl = recuperator PPlNG

* Total confidenti = afforest aIity

* Ov cerium er = 5 milIion customers

Have a nice slapdash = day!

------=_NextPart_000_0006_01C58921.D0CDC700-- From majordomo@mil.doit.wisc.edu Fri Jul 15 08:56:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPjZ-0001hn-4f for ipfix-archive@megatron.ietf.org; Fri, 15 Jul 2005 08:56:05 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01943 for ; Fri, 15 Jul 2005 08:56:03 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DtPe6-0001Rj-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Jul 2005 07:50:26 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DtPe5-0001QM-00 for ipfix@net.doit.wisc.edu; Fri, 15 Jul 2005 07:50:25 -0500 Received: from persaunet.uninett.no (persaunet.uninett.no [IPv6:2001:700:1:0:202:b3ff:fe8f:8c2c]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6FCoNIh027927 for ; Fri, 15 Jul 2005 14:50:23 +0200 Received: from persaunet.uninett.no (localhost.localdomain [127.0.0.1]) by persaunet.uninett.no (8.13.1/8.12.9) with ESMTP id j6FCnP1O004855 for ; Fri, 15 Jul 2005 14:49:25 +0200 Received: (from jk@localhost) by persaunet.uninett.no (8.13.1/8.13.1/Submit) id j6FCnPuS004854; Fri, 15 Jul 2005 14:49:25 +0200 X-Authentication-Warning: persaunet.uninett.no: jk set sender to jon.kare.hellan@uninett.no using -f To: ipfix@net.doit.wisc.edu Subject: [ipfix] dateTimeNanoSeconds From: jon.kare.hellan@uninett.no (=?utf-8?q?Jon_K=C3=A5re_Hellan?=) Date: Fri, 15 Jul 2005 14:49:24 +0200 In-Reply-To: <42D6E6C1.9040302@cisco.com> (Benoit Claise's message of "Fri, 15 Jul 2005 00:27:13 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) References: <42D6E6C1.9040302@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tyholt.uninett.no id j6FCoNIh027927 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Hi Here's how the draft protocol specification defines dateTimeNanoSeconds: > 6.1.8 dateTimeNanoSeconds=20 > =20 > The data type of dateTimeNanoSeconds represents a time value having=20 > a precision of nanoseconds and normalized to the GMT timezone. It=20 > is encoded in a 64-bit integer according to the NTP format given in=20 > [RFC1305]. The high-order 32-bits represent the number of seconds=20 > 1900 and the low-order 32-bits represent the fractional seconds with=20 > the fraction ranging from 0 - 2^(32-1) / 2^32. This gives a maximum=20 > precision of about 200 picoseconds.=20 Two problems here: 1. Both the first and the last sentence appear to define the precision, inconsistently. Changing the the first sentence to read "a precision i= n the order of nanoseconds" would fix this. 2. The range of the fraction given is approximately 0 - 0.5 seconds. The intention is probably (0 - (2^32) - 1) / 2^32. Regards Jon K=C3=A5re Hellan, UNINETT -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Jul 15 09:07:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPuj-0008IW-Aa for ipfix-archive@megatron.ietf.org; Fri, 15 Jul 2005 09:07:37 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02587 for ; Fri, 15 Jul 2005 09:07:35 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DtPlf-0002Wo-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Jul 2005 07:58:15 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DtPle-0002Wi-00 for ipfix@net.doit.wisc.edu; Fri, 15 Jul 2005 07:58:14 -0500 Received: from persaunet.uninett.no (persaunet.uninett.no [IPv6:2001:700:1:0:202:b3ff:fe8f:8c2c]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j6FCwCIh029183; Fri, 15 Jul 2005 14:58:12 +0200 Received: from persaunet.uninett.no (localhost.localdomain [127.0.0.1]) by persaunet.uninett.no (8.13.1/8.12.9) with ESMTP id j6FCvEbs004942; Fri, 15 Jul 2005 14:57:14 +0200 Received: (from jk@localhost) by persaunet.uninett.no (8.13.1/8.13.1/Submit) id j6FCvEYe004941; Fri, 15 Jul 2005 14:57:14 +0200 X-Authentication-Warning: persaunet.uninett.no: jk set sender to jon.kare.hellan@uninett.no using -f To: jon.kare.hellan@uninett.no (=?utf-8?q?Jon_K=C3=A5re_Hellan?=) Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] dateTimeNanoSeconds References: <42D6E6C1.9040302@cisco.com> From: jon.kare.hellan@uninett.no (=?utf-8?q?Jon_K=C3=A5re_Hellan?=) Date: Fri, 15 Jul 2005 14:57:13 +0200 In-Reply-To: (Jon =?utf-8?q?K=C3=A5re?= Hellan's message of "Fri, 15 Jul 2005 14:49:24 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tyholt.uninett.no id j6FCwCIh029183 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable jon.kare.hellan@uninett.no (Jon K=C3=A5re Hellan) writes: Following up on myself, sorry! > 1. Both the first and the last sentence appear to define the precision, > inconsistently. Changing the the first sentence to read "a precision= in > the order of nanoseconds" would fix this. The information model says: 3.1.13 dateTimeNanoSeconds The type "dateTimeNanoSeconds" represents a time value having a precision of nanoseconds and normalized to the GMT time zone. and 5.8.7 flowStartNanoSeconds and 5.8.8 flowEndNanoSeconds both say that the unit is nanoseconds. Obviously, protocol and information model have to agree. Regards Jon K=C3=A5re Hellan, UNINETT =20 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Jul 17 04:43:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du4k1-0006dX-Nq for ipfix-archive@megatron.ietf.org; Sun, 17 Jul 2005 04:43:20 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20449 for ; Sun, 17 Jul 2005 04:43:07 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Du4SN-0002es-00 for ipfix-list@mil.doit.wisc.edu; Sun, 17 Jul 2005 03:25:03 -0500 Received: from harpo.itss.auckland.ac.nz ([130.216.190.13] helo=smtpc.itss.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Du4SL-0002e9-00 for ipfix-info@net.doit.wisc.edu; Sun, 17 Jul 2005 03:25:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 36980341A8; Sun, 17 Jul 2005 20:25:00 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17220-17; Sun, 17 Jul 2005 20:25:00 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id EBA7335739; Sun, 17 Jul 2005 20:24:58 +1200 (NZST) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id j6H8Ove23043; Sun, 17 Jul 2005 20:24:57 +1200 Received: from 60.234.152.201 ([60.234.152.201]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Sun, 17 Jul 2005 20:24:57 +1200 Message-ID: <1121588697.8932c30baac91@webmail.auckland.ac.nz> Date: Sun, 17 Jul 2005 20:24:57 +1200 From: Nevil Brownlee To: Juergen Quittek Cc: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" References: <42D6DCEC.4070402@cisco.com> <1F5C3B673FA2F84752887A33@[192.168.0.112]> In-Reply-To: <1F5C3B673FA2F84752887A33@[192.168.0.112]> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 60.234.152.201 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen et al: > There is a problem with the semantics of 'post' in the info model. > The additional text tries to select one of them. It applies well > to postMCastPacketDeltaCount, postMCastOctetDeltaCount, > postMCastPacketTotalCount, and postMCastOctetTotalCount. > > However, it does not fit well to the semantics we had so far for > postOctetDeltaCount, postOctetTotalCount, packetDeltaCount, > postPacketDeltaCount. > > I expect this to become a longer discussion. I will try to describe > my point of view in another email. I get the feeling that this issue needs to be resolved before we submit the draft to IESG, alas. Juergen, Benoit, Paul, et al., can we try to get a new consistent pair of drafts (protocol and info) done this week, please? We're into the 2-week draft cutoff for the Paris IETF now, so they'll have to be published on the IPFIX web site - i.e., please email them to Dave, as well as internet-drafts. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Jul 17 09:37:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du9Ks-0001P5-RM for ipfix-archive@megatron.ietf.org; Sun, 17 Jul 2005 09:37:39 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04103 for ; Sun, 17 Jul 2005 09:37:36 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Du9E4-0003up-00 for ipfix-list@mil.doit.wisc.edu; Sun, 17 Jul 2005 08:30:36 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Du9E3-0003to-00 for ipfix-info@net.doit.wisc.edu; Sun, 17 Jul 2005 08:30:35 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CC15A1BAC4D; Sun, 17 Jul 2005 15:30:31 +0200 (CEST) Date: Sun, 17 Jul 2005 15:30:26 +0200 From: Juergen Quittek To: Nevil Brownlee Cc: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" Message-ID: <431218C7FA1609E98487D97E@[192.168.0.112]> In-Reply-To: <1121588697.8932c30baac91@webmail.auckland.ac.nz> References: <42D6DCEC.4070402@cisco.com> <1F5C3B673FA2F84752887A33@[192.168.0.112]> <1121588697.8932c30baac91@webmail.auckland.ac.nz> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil, I will send a detailed discussion of my position on Monday. If we cannot agree quickly, this could be an interesting discussion item for the Paris meeting. Juergen --On 7/17/2005 8:24 PM +1200 Nevil Brownlee wrote: > Hi Juergen et al: > >> There is a problem with the semantics of 'post' in the info model. >> The additional text tries to select one of them. It applies well >> to postMCastPacketDeltaCount, postMCastOctetDeltaCount, >> postMCastPacketTotalCount, and postMCastOctetTotalCount. >> >> However, it does not fit well to the semantics we had so far for >> postOctetDeltaCount, postOctetTotalCount, packetDeltaCount, >> postPacketDeltaCount. >> >> I expect this to become a longer discussion. I will try to describe >> my point of view in another email. > > I get the feeling that this issue needs to be resolved before we submit > the draft to IESG, alas. Juergen, Benoit, Paul, et al., can we try > to get a new consistent pair of drafts (protocol and info) done this > week, please? We're into the 2-week draft cutoff for the Paris IETF now, > so they'll have to be published on the IPFIX web site - i.e., please > email them to Dave, as well as internet-drafts. > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITSS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From EganSla@kele.com Sun Jul 17 18:35:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuHjC-0006lP-Gm for ipfix-archive@megatron.ietf.org; Sun, 17 Jul 2005 18:35:18 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01876 for ; Sun, 17 Jul 2005 18:35:15 -0400 (EDT) Received: from 4ab54-1-81-56-118-96.fbx.proxad.net ([81.56.118.96] helo=kele.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DuHO8-0006vv-00 for ipfix-list@mil.doit.wisc.edu; Sun, 17 Jul 2005 17:13:32 -0500 From: "Sla Egan" To: "Philippa Pettit" Subject: Shhe Thinks I'm a God Date: Sun, 17 Jul 2005 17:13:29 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C58B1C.C297CA80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?81.56.118.96 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C58B1C.C297CA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, and made a leg to M. de Cussy.plainly the pennon of St. George fluttering = from her maintop.when he was told of it. But happened it had, and he = was forced tohappen to survive this business. Betimes he remembered = that toBut it had been an unpromising beginning, and there was more toso = very different outwardly from anything that he had expected.lie board = and board with you?A murmur from the galleries and even from the jury = approved him.Bishop's door. The last he heard of them was Mary Traill's = childlikeYet you've seen what you've seen, and you'll not deny that in = shipsbuccaneer's face remained of the utmost gravity.Levasseur, his hand = on his sword, his face a white mask of rage,had suspected and hoped, the = fort's artillery was all mounted onmiles away, standing in toward Port = Royal, the first and naturalthing it had planned. But to correct the = sentiment he evoked acampaign should proceed. ------=_NextPart_000_0050_01C58B1C.C297CA80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How to save on y = resourcefulness our MEDlCATIONS over 70%.

sibylline PharmShop - Successfull = and Proven Way t ditcher o save = your m steamer oney.

gloaming V		pawnbroker AG		A devoid L		unobtainable lU
= misinterpret l	R = inobservant A C bended = l	I engird = S VA causeway = L	whinny = M	and many other.

Best PRl morsel = CES.

Worldwide SHlPP = convexity lNG.

E commensurable = asy Order Form.

palmar Total = confidentiaIity.

250,000 satisfie = vicarage d customers.

Order today and sa = hypocrisy ve!

------=_NextPart_000_0050_01C58B1C.C297CA80-- From CarFeder_912@jleh.com Mon Jul 18 14:44:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duab0-0008EQ-MM for ipfix-archive@megatron.ietf.org; Mon, 18 Jul 2005 14:44:06 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04944 for ; Mon, 18 Jul 2005 14:44:04 -0400 (EDT) Received: from adsl-pha8-119-244-84.bluetone.cz ([84.244.119.8] helo=jleh.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DuaH8-00072m-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Jul 2005 13:23:39 -0500 From: "Federigo Carnes" To: "Otokar Storey" Subject: Offrr for you Date: Mon, 18 Jul 2005 13:23:21 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01C58BC5.C6CBF280" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0039_01C58BC5.C6CBF280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Miguel smiled, with a flash of white teeth behind his grizzledlevel yet = with M. de Rivarol, and wipe off some other scores at theAwake, eh? said = he in Spanish.prudence may avert. You do not know on what a volcano you = areWhat do you do? he cried.on the part of the French marred its smooth = execution, and thetragic mark upon the young seaman. His erstwhile = bright alertness Who'll sail for the Main with me?You have granted, I = am told, the King's commission to this man.practised skill. When, with = both lungs transfixed, he lay proneto Levasseur to stop. To obey her, = he opened the door, and flungIs it you, Pedro? The Spaniard came a step = nearer.Nevertheless, it was to Cartagena that they sailed in the middle = ofnot paid, even if when they press him Nuttall does not confess = thenephew Esteban, whose vindictive zeal exceeded the Admiral's own.The = executioners were kept busy with rope and chopper and cauldrons ------=_NextPart_000_0039_01C58BC5.C6CBF280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Want to know how to save ov morgue er 60% on your piIls?

htt franchise p://www.noneedto.com - = Successful impracticable l and = Proven Way to SAVE YO tokology UR = M0NEY.

complin V		A distortionist G		A barfly L		lackey lU
= basketful l	R valeric = A cyanogen = Cl	dramatis = IS VA talkative = L	= predication M	and many other.

Best phylogenesis = PRlCES.

Hig finable h = QuaIity.

Worldwide SH = immateriality lPPlNG.

Total confiden = disgust tiaIity.

25 banister = 0.000+ satisfied customers.

H snuffers ave = a nice day!

------=_NextPart_000_0039_01C58BC5.C6CBF280-- From majordomo@mil.doit.wisc.edu Tue Jul 19 07:00:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duppi-0006aP-DV for ipfix-archive@megatron.ietf.org; Tue, 19 Jul 2005 07:00:19 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00797 for ; Tue, 19 Jul 2005 07:00:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DupZD-0004VO-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Jul 2005 05:43:15 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DupZB-0004VJ-00 for ipfix-info@net.doit.wisc.edu; Tue, 19 Jul 2005 05:43:14 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6JAh6B01032; Tue, 19 Jul 2005 12:43:06 +0200 (CEST) Received: from [10.61.65.46] (ams-clip-vpn-dhcp302.cisco.com [10.61.65.46]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6JAgqp00890; Tue, 19 Jul 2005 12:42:52 +0200 (CEST) Message-ID: <42DCD92B.2060504@cisco.com> Date: Tue, 19 Jul 2005 12:42:51 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Nevil Brownlee , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" References: <42D6DCEC.4070402@cisco.com> <1F5C3B673FA2F84752887A33@[192.168.0.112]> <1121588697.8932c30baac91@webmail.auckland.ac.nz> <431218C7FA1609E98487D97E@[192.168.0.112]> In-Reply-To: <431218C7FA1609E98487D97E@[192.168.0.112]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello Juergen, Can you please send the detailed discussion you referred to. Still hoping we can agree quickly. Regards, Benoit. > Nevil, > > I will send a detailed discussion of my position on Monday. > > If we cannot agree quickly, this could be an interesting discussion > item for the Paris meeting. > > Juergen > > > --On 7/17/2005 8:24 PM +1200 Nevil Brownlee wrote: > >> Hi Juergen et al: >> >>> There is a problem with the semantics of 'post' in the info model. >>> The additional text tries to select one of them. It applies well >>> to postMCastPacketDeltaCount, postMCastOctetDeltaCount, >>> postMCastPacketTotalCount, and postMCastOctetTotalCount. >>> >>> However, it does not fit well to the semantics we had so far for >>> postOctetDeltaCount, postOctetTotalCount, packetDeltaCount, >>> postPacketDeltaCount. >>> >>> I expect this to become a longer discussion. I will try to describe >>> my point of view in another email. >> >> >> I get the feeling that this issue needs to be resolved before we submit >> the draft to IESG, alas. Juergen, Benoit, Paul, et al., can we try >> to get a new consistent pair of drafts (protocol and info) done this >> week, please? We're into the 2-week draft cutoff for the Paris IETF >> now, >> so they'll have to be published on the IPFIX web site - i.e., please >> email them to Dave, as well as internet-drafts. >> >> Cheers, Nevil >> >> ----------------------------------------------------------------------- >> Nevil Brownlee Computer Science Department | ITSS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand >> >> >> ------------------------------------------------- >> This mail sent through University of Auckland >> http://www.auckland.ac.nz/ > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From FootKichiro_9279@jobdragon.com Tue Jul 19 10:34:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DutAk-0003ty-0n for ipfix-archive@megatron.ietf.org; Tue, 19 Jul 2005 10:34:14 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18902 for ; Tue, 19 Jul 2005 10:34:11 -0400 (EDT) Received: from [218.149.116.168] (helo=jobdragon.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DusxI-0007dL-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Jul 2005 09:20:20 -0500 From: "Kichiro Foote" To: "Argi Norris" Subject: SSuper Offr Date: Tue, 19 Jul 2005 09:20:09 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C58C6C.F7B33280" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C58C6C.F7B33280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, himself to answer.by their arrival - which in dress and manner differed = little from aHe went out, leaving his lordship pensive, those dreamy = blue eyesColonel Bishop mastered himself, and rose. A merciless despot, = whoyou are obliged to enter.the rest, monsieur, they have certain = notions of honour. They willof the bar. My prisoners, most of whom are = persons of consideration,Don Diego de Espinosa y Valdez, who was own = brother to the Spanishyour party inconveniently increase it. So that on = every hand, yousurprising enough in all the circumstances - he proceeded = toI can have no knowledge of these things. I have the honour toCaution = above everything, was Blood's last recommendation to himthe livid gleam = of that sword which Mr. Blood had quickly unsheathed.And what better are = these? - Are ye afeard of a lubberly BarbadosHave ye done? quoth Blood = quietly, as the Frenchman pausedleaning out to heave the lead. ------=_NextPart_000_0047_01C58C6C.F7B33280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Want to know how to save over overwork 60% on your = piIls?

http://www.alrea parenthetical sease.com - Su reputed ccessfull and Proven Way to = SAVE YOUR M0 ditheism = NEY.

cockeye V		continuation AG		decolour AL		l superstrata U
polygamy = l	R bracer = A C nutmeg = l	= interaction IS V feudalize = AL	= generatrices M	and many other.

Best cootie = PRlCES.

High QuaIi homeroom = ty.

Worldwide Galluppoll = SHlPPlNG.

Total confiden = bristle tiaIity.

250.000+ satisfied = scholarly customers.

Have a nice day = ferric !

------=_NextPart_000_0047_01C58C6C.F7B33280-- From majordomo@mil.doit.wisc.edu Tue Jul 19 19:40:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1hC-0000dv-OZ for ipfix-archive@megatron.ietf.org; Tue, 19 Jul 2005 19:40:18 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13956 for ; Tue, 19 Jul 2005 19:40:15 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dv1P9-000084-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Jul 2005 18:21:39 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dv1P7-00007y-00 for ipfix-info@net.doit.wisc.edu; Tue, 19 Jul 2005 18:21:38 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0FBD61BAC4D; Wed, 20 Jul 2005 01:21:33 +0200 (CEST) Date: Wed, 20 Jul 2005 01:21:36 +0200 From: Juergen Quittek To: Nevil Brownlee , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" Message-ID: <280D3002576ABFDF5E8864F4@[192.168.0.112]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Here is the problem description for the "pre" and "post" prefixes that I promised last weekend. I am sorry for the delay in sending this. It is caused by my inability to explain the issue briefly. Please excuse that this inability also is the reason why you have to read an awfully long message in order to help solving the problem. Let me start with a short introduction to the problem we have with middleboxes and other boxes that change flow properties: Some middleboxes change properties of a flow. For example, a DiffServ marker changes the value of the IPv4 TOS field, a network address translator changes source or destination IP addresses, and a traffic shaper changes the number of packets and bytes of a flow. Consequently, on one side of a middlebox a traffic flow might have properties that are different to its properties on the other side of the middlebox. Now, if an observation point stretches so far that it includes both sides of the middlebox, we run into ambiguities. In such a case, there are two different values for packet count, byte count, DSCP, source IP address, etc. to be observed at the observation point. Which values should we export in such a situation? We discussed this issue at our meeting in Seoul where Martin gave a presentation that you can find in the proceedings: Also a draft discussing it is available in the archive: I see two solutions for this problem and the discussion we need to have is about selecting one of them or another solution suggested by someone else. Solution 1 The recommendation that was made at the meeting and in the (already expired) draft was to avoid these ambiguities by avoiding to have an observation point that includes both sides of a middlebox. This solves the ambiguity problem. If it is clearly specified on which side of a middlebox we have our observation point, then we know which observed values to export. However, sometimes it might be very useful to ALSO export values from the other side of the middlebox. These would be values that were not necessarily derived from direct observation of packets, but by other means available at the IPFIX device. Let's take a multicast daemon as an the example. A multicast daemon is not necessarily a middlebox, but it causes the same problem. The daemon might be able to provide statistics on how many packets it sent out for a certain multicast address. If now our observation domain is restricted to the incoming traffic at a single network interface at the IPFIX device, then we will observe only the incoming multicast flow. Still, it would be nice to report for this flow the number of outgoing multicast packets and octets. NetFlow version 9 supports this by fields MUL_DST_PKTS and MUL_DST_BYTES. In the IPFIX info model they are called postMCastPacketDeltaCount and postMCastOctetDeltaCount. Note these objects report something that can not (necessarily) be observed at the flow's observation point. The info model elements have the prefix 'post' in order to indicate the fact that these values do not necessarily result from an actual observation. In this case they result from the reporting of the multicast daemon. As second example we can look at a DiffServ packet marker. It changes the DSCP value of packets. Following the approach of solution 1, the location of the observation point should be clearly specified to be at one or the other side of the marker. There it observes the DSCP value that is reported by information element classOfServiceIPv4 or classOfServiceIPv6. Also here, scenarios can easily be found for which it is desirable to report also the DSCP value that the flow has on the other side of the marker, that is not covered by the observation point. This is supported by NetFlow version 9 with the DST_TOS field and in our information model by the elements postClassOfServiceIPv4 and postClassOfServiceIPv6. As you see from the prefix of their name, we can only use them if the observation point is located on the path of the packet before it passes the marker. If the observation point would be located somewhere on the path after the marker, we would need a different prefix for reporting from the other side. The current version of the info model suggests prefix "pre" for this case, for example, "preClassOfServiceIPv4". We do not have any instance of an information element with prefix "pre" in the current version of our model, because common practice is measuring at the incoming interface of a router. Still, we would need to add them at some time in the future if we follow solution one. Please not that also for the 'post' prefix only a few instances are present. We clearly expect to need more "post" elements if we start having IPFIX implementations on network address translators (postsourceIPv4Address, postTransportPort, etc.). Solution 2 The other way of solving the ambiguities is declaring that all flow properties that are exported represent the flow as it was when entering the IPFIX device except, if their name has the prefix "post". Information elements without the prefix would describe flows of incoming packets and elements with that prefix would describe flows of outgoing packets. In case of the multicast daemon, the packetDeltaCount would be the number of incoming packets and the postMCastPacketDeltaCount would be the number of outgoing multicast packets. For the packet marker, classOfServiceIPv4 would deliver the value of the DSCP before marking and preClassOfServiceIPv4 would deliver the value after marking. This solution allows a more relaxed specification of the observation point. It may be the entire device. Ambiguities are avoided for this case, because every element is marked to concern either incoming or outgoing traffic. Discussion {Please note that I am biases and have a preference for solution 1. Please contribute arguments for solution 2 or against solution 1 that are missing in the lists below because I am too ignorant to see them.} Advantages of solution 2: - the concept is simpler. - We only need one prefix. Disadvantages of solution 2: - The concept is simple but not always clear. What about traffic observed at a network interface card in promiscuous mode. This traffic would be neither incoming nor outgoing. - A generic flow meter using libpcap typically observes incoming traffic as well as outgoing traffic. This meter would need to check for all packets if they are incoming or outgoing (probably by checking the MAC addresses) and use elements without prefix for reporting the incoming packets and elements with "post" prefix for reporting the outgoing traffic. - We must define an information element with a "post" prefix for almost all the non-post elements in sections - 5.3 IP Header Fields (31 elements) - 5.4 Transport Header Fields (16 elements), - 5.5 Sub-IP Header Fields (19 elements) - 5.7 Min/Max Flow Properties (11 elements) - 5.9 Per-Flow Counters (12 elements) currently, only 13 of them are defined. - We cannot report bidirectional flows anymore, if our observation point does not cover all interfaces. If we measure at a single interface, then we cannot aggregate the packet and octet counters of a bi-directional flow, because for one direction we must use the non-prefix counter and for the other direction we must use the prefix counter. Advantages of solution 1: - The concept is clean: no prefix for actually measured traffic prefixes for flow properties that are obtained by other means. - We need prefixes only if middleboxes are involved and supported by the metering process. We do not need prefixes in all other cases, particularly not for for simple bidirectional measurements or for unidirectional measurements of outgoing traffic. Disadvantages of solution 2: - We need two prefixes - We might end up with a higher total number of elements Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 7/17/2005 8:24 PM +1200 Nevil Brownlee wrote: > Hi Juergen et al: > >> There is a problem with the semantics of 'post' in the info model. >> The additional text tries to select one of them. It applies well >> to postMCastPacketDeltaCount, postMCastOctetDeltaCount, >> postMCastPacketTotalCount, and postMCastOctetTotalCount. >> >> However, it does not fit well to the semantics we had so far for >> postOctetDeltaCount, postOctetTotalCount, packetDeltaCount, >> postPacketDeltaCount. >> >> I expect this to become a longer discussion. I will try to describe >> my point of view in another email. > > I get the feeling that this issue needs to be resolved before we submit > the draft to IESG, alas. Juergen, Benoit, Paul, et al., can we try > to get a new consistent pair of drafts (protocol and info) done this > week, please? We're into the 2-week draft cutoff for the Paris IETF now, > so they'll have to be published on the IPFIX web site - i.e., please > email them to Dave, as well as internet-drafts. > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Computer Science Department | ITSS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > ------------------------------------------------- > This mail sent through University of Auckland > http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From FeldmLuce8952@e.com.cnri.reston.va.us Wed Jul 20 05:23:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvAnA-00017j-4c for ipfix-archive@megatron.ietf.org; Wed, 20 Jul 2005 05:23:04 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24409 for ; Wed, 20 Jul 2005 05:23:01 -0400 (EDT) Received: from [62.209.222.132] (helo=e.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DvAVs-0001U4-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Jul 2005 04:05:13 -0500 From: "Luce Feldman" To: "Kshitij Covington" Subject: Niice pro Date: Wed, 20 Jul 2005 04:04:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C58D0A.161B3B80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?62.209.222.132 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C58D0A.161B3B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, that I must, I'll take none that I needn't. But.... He broke offOne sunny = morning in January, about a month after the arrival ofHe kissed her = again, almost contemptuously, and flung her off.settled down in the = shallows with part of her hull above water.thus being put out of action = at the outset, Blood had sailed inEarth, before Whose tribunal thou and = we and all persons are toDon't be a fool, he said in his own tongue, or = you'll come by awill let me pass.What shall that mean, sir?lay directly = between himself and the Royal Army. You also knowalways the same; that = on the journeys to the shore they sat andevery line of him.before we = make land.Why, if the service you would propose is one that cannot hurt = mythe Governor's condition had so far improved as to restore him hisOnce = I held him in regard for an unfortunate but worthy gentleman. ------=_NextPart_000_0010_01C58D0A.161B3B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Want to know how to save over 60% o megascopic n your piIls?

http: disfigurement //www.letheal.com - = Successfull and Proven sirloin Way = to S threepence AVE YOUR = M0NEY.

redmeat V		daisied AG		A fortify L		neckwear lU
export = l	= Tarheeler RA grovel = Cl	I = embranchment S impersonal = VAL	alienate = M	and many other.

Best lyingin = PRlCES.

High QuaIi = vaporescense ty.

Worldwi anecdote = de SHlPPlNG.

Total confidentiaIit = roadshow y.

250.000+ sat racemose = isfied customers.

Have a nice delivery = day!

------=_NextPart_000_0010_01C58D0A.161B3B80-- From majordomo@mil.doit.wisc.edu Wed Jul 20 08:07:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvDMB-0003Bm-GO for ipfix-archive@megatron.ietf.org; Wed, 20 Jul 2005 08:07:25 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09523 for ; Wed, 20 Jul 2005 08:07:21 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DvDG7-0004s5-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Jul 2005 07:01:07 -0500 Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DvDG5-0004rz-00 for ipfix-info@net.doit.wisc.edu; Wed, 20 Jul 2005 07:01:05 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6KC14925907; Wed, 20 Jul 2005 14:01:04 +0200 (CEST) Received: from [10.61.65.102] (ams-clip-vpn-dhcp358.cisco.com [10.61.65.102]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6KC10p25855; Wed, 20 Jul 2005 14:01:00 +0200 (CEST) Message-ID: <42DE3CFC.3010300@cisco.com> Date: Wed, 20 Jul 2005 14:01:00 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Nevil Brownlee , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" References: <280D3002576ABFDF5E8864F4@[192.168.0.112]> In-Reply-To: <280D3002576ABFDF5E8864F4@[192.168.0.112]> Content-Type: multipart/alternative; boundary="------------000904000504090702010301" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------000904000504090702010301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen and all, Thanks for the detailed email. It will ease the discussion. You see this pre and post prefix problem from the point of view of the observation point only. This is fine because we have in RFC 3917: "All measurements must be conducted from the point of view of the observation point." Btw, I think that this statement should appear in [IPFIX-ARCH]. I took me quite some time to locate this sentence as I thought it was in one of current draft already. However, I see the problem differently: before and after the packet treatment at the observation point. I will show that this view exclude the solution 1, leads to the natural selection of slightly modified solution 2, i.e. solution 3 Remember the flow definition, in which the packet treatment is clearly mentioned: A Flow is defined as a set of IP packets passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. Each property is defined as the result of applying a function to the values of: 1. One or more packet header field (e.g. destination IP address), transport header field (e.g. destination port number), or application header field (e.g. RTP header fields RTP-HDRF [5]. 2. One or more characteristics of the packet itself (e.g. number of MPLS labels) 3. _One or more fields derived from packet treatment_ (e.g. next hop IP address, output interface) I see the "packet treatment" as the typical function of a middlebox. The definition could have been extended with for example the modified DSCP value. So let me propose the solution 3 (let me refer to "solution 3" later on in this email): all flow properties that are exported represent the flow as it was when entering the IPFIX device except, if their name has the prefix "post". Information elements without the prefix would describe flows characteristics of incoming packets and information elements with the "post" prefix would describe flows characteristics after packet treatment. See inline. > Dear all, > > Here is the problem description for the "pre" and "post" prefixes > that I promised last weekend. > > I am sorry for the delay in sending this. It is caused by my > inability to explain the issue briefly. Please excuse that this > inability also is the reason why you have to read an awfully long > message in order to help solving the problem. > > > Let me start with a short introduction to the problem we have with > middleboxes and other boxes that change flow properties: > > Some middleboxes change properties of a flow. For example, a DiffServ > marker changes the value of the IPv4 TOS field, a network address > translator changes source or destination IP addresses, and a traffic > shaper changes the number of packets and bytes of a flow. > > Consequently, on one side of a middlebox a traffic flow might have > properties that are different to its properties on the other side > of the middlebox. > > Now, if an observation point stretches so far that it includes both > sides of the middlebox, we run into ambiguities. In such a case, > there are two different values for packet count, byte count, DSCP, > source IP address, etc. to be observed at the observation point. > Which values should we export in such a situation? > > We discussed this issue at our meeting in Seoul where Martin gave > a presentation that you can find in the proceedings: > > Also a draft discussing it is available in the archive: > > > I see two solutions for this problem and the discussion we need to > have is about selecting one of them or another solution suggested by > someone else. > > > Solution 1 > The recommendation that was made at the meeting and in the (already > expired) draft was to avoid these ambiguities by avoiding to have an > observation point that includes both sides of a middlebox. There is no ambiguities if you apply solution 3: > > This solves the ambiguity problem. If it is clearly specified on which > side of a middlebox we have our observation point, then we know which > observed values to export. > > However, sometimes it might be very useful to ALSO export values from > the other side of the middlebox. These would be values that were not > necessarily derived from direct observation of packets, but by other > means available at the IPFIX device. I would say that it's not only useful, but it's a requirement. If you don't allow to export after treatment I.E., you run into problems such as: - exporting two records, from the ingress point and the egress observation points of your middlebox - trying to combine the records, to match the initial flow. You're going to tell me that we could use the flow keys, but we don't always want to export the flow keys. Alternatively, we could use a flow ID, but this becomes way too complex. > > Let's take a multicast daemon as an the example. A multicast daemon > is not necessarily a middlebox, but it causes the same problem. > The daemon might be able to provide statistics on how many packets > it sent out for a certain multicast address. > > If now our observation domain is restricted to the incoming traffic > at a single network interface at the IPFIX device, then we will > observe only the incoming multicast flow. Still, it would be nice > to report for this flow the number of outgoing multicast packets > and octets. > > NetFlow version 9 supports this by fields MUL_DST_PKTS > and MUL_DST_BYTES. In the IPFIX info model they are called > postMCastPacketDeltaCount and postMCastOctetDeltaCount. > > Note these objects report something that can not (necessarily) > be observed at the flow's observation point. The info model > elements have the prefix 'post' in order to indicate the fact > that these values do not necessarily result from an actual > observation. In this case they result from the reporting of > the multicast daemon. If you apply solution 3, it's up to the metering process at the observation point to evaluate whether or not he can report any "post" information. All routers/switches/middlebox will have a different architecture (one metering process per interface, per combination of interfaces, per line card, per router, etc...) so the only solution is to trust the metering process based on its capabilities. Is the metering process able to report some after packet treatment info? > > As second example we can look at a DiffServ packet marker. It > changes the DSCP value of packets. Following the approach of > solution 1, the location of the observation point should be > clearly specified to be at one or the other side of the marker. > There it observes the DSCP value that is reported by information > element classOfServiceIPv4 or classOfServiceIPv6. > > Also here, scenarios can easily be found for which it is desirable > to report also the DSCP value that the flow has on the other side > of the marker, that is not covered by the observation point. > This is supported by NetFlow version 9 with the DST_TOS field and > in our information model by the elements postClassOfServiceIPv4 > and postClassOfServiceIPv6. As you see from the prefix of their > name, we can only use them if the observation point is located > on the path of the packet before it passes the marker. If the > observation point would be located somewhere on the path after > the marker, we would need a different prefix for reporting from > the other side. Not really. Remember "All measurements must be conducted from the point of view of the observation point." So the observation point is not supposed to know that there is a previous observation point in the path. From the observation point point of view, it must report what is seen. Hence no "pre" prefixes are needed. Next question: is there any packet treatment at this observation point? If no, we don't export any "post" prefix I.E. If yes, and if we can report the values, we export some "post" prefix I.E. > The current version of the info model suggests > prefix "pre" for this case, for example, "preClassOfServiceIPv4". > We do not have any instance of an information element with prefix > "pre" in the current version of our model, because common practice > is measuring at the incoming interface of a router. The solution 3 would also apply if you would monitor traffic at different points in the forwarding path of your device. > Still, we > would need to add them at some time in the future if we follow > solution one. Please not that also for the 'post' prefix only a > few instances are present. We clearly expect to need more "post" > elements if we start having IPFIX implementations on network > address translators (postsourceIPv4Address, postTransportPort, > etc.). > > > Solution 2 > The other way of solving the ambiguities is declaring that all > flow properties that are exported represent the flow as it was > when entering the IPFIX device except, if their name has the > prefix "post". Information elements without the prefix would > describe flows of incoming packets and elements with that > prefix would describe flows of outgoing packets. Note that, in solution 3, I changed outgoing packets by "after packet treatment" > > In case of the multicast daemon, the packetDeltaCount would be > the number of incoming packets and the postMCastPacketDeltaCount > would be the number of outgoing multicast packets. Yes. > > For the packet marker, classOfServiceIPv4 would deliver the value > of the DSCP before marking and preClassOfServiceIPv4 would deliver > the value after marking. Typo -> postClassOfServiceIPv4 > > This solution allows a more relaxed specification of the > observation point. It may be the entire device. Exactly, this is a great advantage. > Ambiguities > are avoided for this case, because every element is marked to > concern either incoming or outgoing traffic. > > > Discussion > {Please note that I am biases and have a preference for solution 1. > Please contribute arguments for solution 2 or against solution 1 > that are missing in the lists below because I am too ignorant to > see them.} Advantage of "solution 3" - the concept is simpler - we only need one prefix As solution 2 and 3 are almost similar, let me reply to the "disadvantage of solution 2" section > > Advantages of solution 2: > - the concept is simpler. > - We only need one prefix. > > Disadvantages of solution 2: > - The concept is simple but not always clear. > What about traffic observed at a network interface card in > promiscuous mode. This traffic would be neither incoming nor > outgoing. I don't see a problem, neither with solution 2 or solution 3. The NIC is the observation point, and "All measurements must be conducted from the point of view of the observation point." So the traffic which is entering the observation point is considered as as incoming. With solution 3, there is no packet treatment, so no "post" I.E.s are exported. With solution 2, there is no outgoing packets, so no "post" I.E.s are exported. > - A generic flow meter using libpcap typically observes incoming > traffic as well as outgoing traffic. This meter would need to > check for all packets if they are incoming or outgoing (probably > by checking the MAC addresses) and use elements without prefix > for reporting the incoming packets and elements with "post" > prefix for reporting the outgoing traffic. Is this a drawback? All the traffic entering the observation point is metered. " The observation point is a location in the network where IP packets can be observed." I don't consider this as a drawback for solution 2 and 3 > - We must define an information element with a "post" prefix for > almost all the non-post elements in sections > - 5.3 IP Header Fields (31 elements) > - 5.4 Transport Header Fields (16 elements), > - 5.5 Sub-IP Header Fields (19 elements) > - 5.7 Min/Max Flow Properties (11 elements) > - 5.9 Per-Flow Counters (12 elements) > currently, only 13 of them are defined. Yes, this is true for solution 2 and solution 3. What we agreed in the past is that people will request those as they need them. > - We cannot report bidirectional flows anymore, if our observation > point does not cover all interfaces. If we measure at a single > interface, then we cannot aggregate the packet and octet counters > of a bi-directional flow, because for one direction we must use > the non-prefix counter and for the other direction we must use > the prefix counter. True for solution 2 and solution 3 but I don't see how it's possible with the solution 1 > > Advantages of solution 1: > - The concept is clean: no prefix for actually measured traffic > prefixes for flow properties that are obtained by other means. > - We need prefixes only if middleboxes are involved and supported > by the metering process. We do not need prefixes in all other > cases, particularly not for for simple bidirectional measurements > or for unidirectional measurements of outgoing traffic. This is a big drawback. If I have a router forwarding traffic, I export a template with no-prefix. My monitoring application is happy. Now, the operational team decides to add some DSCP re-marking capabilities in the router. Now my templates export the "pre" I.E. for the same information. Not sure my monitoring application will be happy. Basically, depending on the (middlebox) features enabled on the router, I will export different I.E.s. This solution doesn't work. > > Disadvantages of solution 2: Typo -> Disadvantages of solution 1: > - We need two prefixes Basically we need "pre", "post" and no prefix. So we have 3 series of I.E.s > - We might end up with a higher total number of elements - Another disadvantage. The choice of these pre, post, no prefix series of I.E.s depend so much on the architecture of the device and that you will have interoperability problem first of all, and the collector will have to know the architecture of the exporter in order to benefit from the exported I.E.s The [IPFIX-INFO] draft has always been (almost) in line with solution 3 until the recent addition in the version 8. Regards, Benoit. > > Thanks, > > Juergen --------------000904000504090702010301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen and all,

Thanks for the detailed email. It will ease the discussion.

You see this pre and post prefix problem from the point of view of the observation point only.
This is fine because we have in RFC 3917:

   "All measurements must be conducted from the point of view of the
   observation point."
Btw, I think that this statement should appear in [IPFIX-ARCH]. I took me quite some time to locate this sentence as I thought it was in one of current draft already.

However, I see the problem differently: before and after the packet treatment at the observation point.
I will show that this view exclude the solution 1, leads to the natural selection of slightly modified solution 2, i.e. solution 3

Remember the flow definition, in which the packet treatment is clearly mentioned:

      A Flow is defined as a set of IP packets passing an Observation
      Point in the network during a certain time interval.  All packets
      belonging to a particular Flow have a set of common properties.
      Each property is defined as the result of applying a function to
      the values of:

      1.  One or more packet header field (e.g. destination IP address),
          transport header field (e.g. destination port number), or
          application header field (e.g.  RTP header fields RTP-HDRF
          [5].

      2.  One or more characteristics of the packet itself (e.g. number
          of MPLS labels)

      3.  One or more fields derived from packet treatment (e.g. next
          hop IP address, output interface)

I see the "packet treatment" as the typical function of a middlebox. The definition could have been extended with for example the modified DSCP value.

So let me propose the solution 3 (let me refer to "solution 3" later on in this email):
all flow properties that are exported represent the flow as it was
when entering the IPFIX device except, if their name has the
prefix "post". Information elements without the prefix would
describe flows characteristics of incoming packets and information elements with the "post"
prefix would describe flows characteristics after packet treatment.

See inline.

Dear all,

Here is the problem description for the "pre" and "post" prefixes
that I promised last weekend.

I am sorry for the delay in sending this. It is caused by my
inability to explain the issue briefly. Please excuse that this
inability also is the reason why you have to read an awfully long
message in order to help solving the problem.

Let me start with a short introduction to the problem we have with
middleboxes and other boxes that change flow properties:

Some middleboxes change properties of a flow. For example, a DiffServ
marker changes the value of the IPv4 TOS field, a network address
translator changes source or destination IP addresses, and a traffic
shaper changes the number of packets and bytes of a flow.

Consequently, on one side of a middlebox a traffic flow might have
properties that are different to its properties on the other side
of the middlebox.

Now, if an observation point stretches so far that it includes both
sides of the middlebox, we run into ambiguities. In such a case,
there are two different values for packet count, byte count, DSCP,
source IP address, etc. to be observed at the observation point.
Which values should we export in such a situation?

We discussed this issue at our meeting in Seoul where Martin gave
a presentation that you can find in the proceedings:
<http://www.ietf.org/proceedings/04mar/slides/ipfix-3/index.html>
Also a draft discussing it is available in the archive:
<http://www.watersprings.org/pub/id/draft-quittek-ipfix-middlebox-00.txt>

I see two solutions for this problem and the discussion we need to
have is about selecting one of them or another solution suggested by
someone else.

Solution 1
The recommendation that was made at the meeting and in the (already
expired) draft was to avoid these ambiguities by avoiding to have an
observation point that includes both sides of a middlebox.

There is no ambiguities if you apply solution 3:

This solves the ambiguity problem. If it is clearly specified on which
side of a middlebox we have our observation point, then we know which
observed values to export.

However, sometimes it might be very useful to ALSO export values from
the other side of the middlebox. These would be values that were not
necessarily derived from direct observation of packets, but by other
means available at the IPFIX device.

I would say that it's not only useful, but it's a requirement.
If you don't allow to export after treatment I.E., you run into problems such as:
- exporting two records, from the ingress point and the egress observation points of your middlebox
- trying to combine the records, to match the initial flow. You're going to tell me that we could use the flow keys, but we don't always want to export the flow keys. Alternatively, we could use a flow ID, but this becomes way too complex.

Let's take a multicast daemon as an the example. A multicast daemon
is not necessarily a middlebox, but it causes the same problem.
The daemon might be able to provide statistics on how many packets
it sent out for a certain multicast address.

If now our observation domain is restricted to the incoming traffic
at a single network interface at the IPFIX device, then we will
observe only the incoming multicast flow. Still, it would be nice
to report for this flow the number of outgoing multicast packets
and octets.

NetFlow version 9 supports this by fields MUL_DST_PKTS
and MUL_DST_BYTES. In the IPFIX info model they are called
postMCastPacketDeltaCount and postMCastOctetDeltaCount.

Note these objects report something that can not (necessarily)
be observed at the flow's observation point. The info model
elements have the prefix 'post' in order to indicate the fact
that these values do not necessarily result from an actual
observation. In this case they result from the reporting of
the multicast daemon.

If you apply solution 3, it's up to the metering process at the observation point to evaluate whether or not he can report any "post" information.
All routers/switches/middlebox will have a different architecture (one metering process per interface, per combination of interfaces, per line card, per router, etc...) so the only solution is to trust the metering process based on its capabilities. Is the metering process able to report some after packet treatment info?

As second example we can look at a DiffServ packet marker. It
changes the DSCP value of packets. Following the approach of
solution 1, the location of the observation point should be
clearly specified to be at one or the other side of the marker.
There it observes the DSCP value that is reported by information
element classOfServiceIPv4 or classOfServiceIPv6.

Also here, scenarios can easily be found for which it is desirable
to report also the DSCP value that the flow has on the other side
of the marker, that is not covered by the observation point.
This is supported by NetFlow version 9 with the DST_TOS field and
in our information model by the elements postClassOfServiceIPv4
and postClassOfServiceIPv6. As you see from the prefix of their
name, we can only use them if the observation point is located
on the path of the packet before it passes the marker. If the
observation point would be located somewhere on the path after
the marker, we would need a different prefix for reporting from
the other side.

Not really. Remember "All measurements must be conducted from the point of view of the observation point."
So the observation point is not supposed to know that there is a previous observation point in the path.
From the observation point point of view, it must report what is seen. Hence no "pre" prefixes are needed. Next question: is there any packet treatment at this observation point? If no, we don't export any "post" prefix I.E. If yes, and if we can report the values, we export some "post" prefix I.E.

The current version of the info model suggests
prefix "pre" for this case, for example, "preClassOfServiceIPv4".
We do not have any instance of an information element with prefix
"pre" in the current version of our model, because common practice
is measuring at the incoming interface of a router.

The solution 3 would also apply if you would monitor traffic at different points in the forwarding path of your device.

Still, we
would need to add them at some time in the future if we follow
solution one. Please not that also for the 'post' prefix only a
few instances are present. We clearly expect to need more "post"
elements if we start having IPFIX implementations on network
address translators (postsourceIPv4Address, postTransportPort,
etc.).

Solution 2
The other way of solving the ambiguities is declaring that all
flow properties that are exported represent the flow as it was
when entering the IPFIX device except, if their name has the
prefix "post". Information elements without the prefix would
describe flows of incoming packets and elements with that
prefix would describe flows of outgoing packets.

Note that, in solution 3, I changed outgoing packets by "after packet treatment"

In case of the multicast daemon, the packetDeltaCount would be
the number of incoming packets and the postMCastPacketDeltaCount
would be the number of outgoing multicast packets.

Yes.

For the packet marker, classOfServiceIPv4 would deliver the value
of the DSCP before marking and preClassOfServiceIPv4 would deliver
the value after marking.

Typo -> postClassOfServiceIPv4

This solution allows a more relaxed specification of the
observation point. It may be the entire device.

Exactly, this is a great advantage.

Ambiguities
are avoided for this case, because every element is marked to
concern either incoming or outgoing traffic.

Discussion
{Please note that I am biases and have a preference for solution 1.
Please contribute arguments for solution 2 or against solution 1
that are missing in the lists below because I am too ignorant to
see them.}

Advantage of "solution 3"
- the concept is simpler
- we only need one prefix

As solution 2 and 3 are almost similar, let me reply to the "disadvantage of solution 2" section

Advantages of solution 2:
- the concept is simpler.
- We only need one prefix.

Disadvantages of solution 2:
- The concept is simple but not always clear.
   What about traffic observed at a network interface card in
   promiscuous mode. This traffic would be neither incoming nor
   outgoing.

I don't see a problem, neither with solution 2 or solution 3. The NIC is the observation point, and

   "All measurements must be conducted from the point of view of the
   observation point."
So the traffic which is entering the observation point is considered as as incoming.
With solution 3, there is no packet treatment, so no "post" I.E.s are exported.
With solution 2, there is no outgoing packets, so no "post" I.E.s are exported.

- A generic flow meter using libpcap typically observes incoming
   traffic as well as outgoing traffic. This meter would need to
   check for all packets if they are incoming or outgoing (probably
   by checking the MAC addresses) and use elements without prefix
   for reporting the incoming packets and elements with "post"
   prefix for reporting the outgoing traffic.

Is this a drawback? All the traffic entering the observation point is metered.
" The observation point is a location in the network where IP packets can be observed."
I don't consider this as a drawback for solution 2 and 3

- We must define an information element with a "post" prefix for
   almost all the non-post elements in sections
     - 5.3 IP Header Fields (31 elements)
     - 5.4 Transport Header Fields (16 elements),
     - 5.5 Sub-IP Header Fields (19 elements)
     - 5.7 Min/Max Flow Properties (11 elements)
     - 5.9 Per-Flow Counters (12 elements)
   currently, only 13 of them are defined.

Yes, this is true for solution 2 and solution 3.
What we agreed in the past is that people will request those as they need them.

- We cannot report bidirectional flows anymore, if our observation
   point does not cover all interfaces. If we measure at a single
   interface, then we cannot aggregate the packet and octet counters
   of a bi-directional flow, because for one direction we must use
   the non-prefix counter and for the other direction we must use
   the prefix counter.

True for solution 2 and solution 3 but I don't see how it's possible with the solution 1

Advantages of solution 1:
- The concept is clean: no prefix for actually measured traffic
   prefixes for flow properties that are obtained by other means.
- We need prefixes only if middleboxes are involved and supported
   by the metering process. We do not need prefixes in all other
   cases, particularly not for for simple bidirectional measurements
   or for unidirectional measurements of outgoing traffic.

This is a big drawback.
If I have a router forwarding traffic, I export a template with no-prefix. My monitoring application is happy.
Now, the operational team decides to add some DSCP re-marking capabilities in the router. Now my templates export the "pre" I.E. for the same information. Not sure my monitoring application will be happy.
Basically, depending on the (middlebox) features enabled on the router, I will export different I.E.s. This solution doesn't work.

Disadvantages of solution 2:

Typo -> Disadvantages of solution 1:

- We need two prefixes

Basically we need "pre", "post" and no prefix. So we have 3 series of I.E.s

- We might end up with a higher total number of elements

- Another disadvantage. The choice of these pre, post, no prefix series of I.E.s depend so much on the architecture of the device and that you will have interoperability problem first of all, and the collector will have to know the architecture of the exporter in order to benefit from the exported I.E.s

The [IPFIX-INFO] draft has always been (almost) in line with solution 3 until the recent addition in the version 8.

Regards, Benoit.

Thanks,

Juergen

--------------000904000504090702010301-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Jul 21 15:54:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh7q-0003Qj-Kv for ipfix-archive@megatron.ietf.org; Thu, 21 Jul 2005 15:54:36 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04753 for ; Thu, 21 Jul 2005 15:54:32 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dvgpo-0007Y7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Jul 2005 14:35:56 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dvgpm-0007Y1-00 for ipfix-info@net.doit.wisc.edu; Thu, 21 Jul 2005 14:35:54 -0500 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B88E31BAC4D; Thu, 21 Jul 2005 21:35:51 +0200 (CEST) Date: Thu, 21 Jul 2005 21:35:55 +0200 From: Juergen Quittek To: Benoit Claise Cc: Nevil Brownlee , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" Message-ID: <45153F8B40ECB0CCCA744072@[192.168.0.112]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, Thanks for the detailed reply. Please find comments in line. --On 7/20/2005 2:01 PM +0200 Benoit Claise wrote: > Juergen and all, > > Thanks for the detailed email. It will ease the discussion. > > You see this pre and post prefix problem from the point of view of the > observation point only. > This is fine because we have in RFC 3917: > > "All measurements must be conducted from the point of view of the > observation point." > Btw, I think that this statement should appear in [IPFIX-ARCH]. I took me > quite some time to locate this sentence as I thought it was in one of > current draft already. > However, I see the problem differently: before and after the packet > treatment at the observation point. I think here is already the point where we are not in sync. I do not expect the packet treatment to necessarily happen at the observation point only. Let's take the multicast daemon as an example that is already supported by NetFlow version 9. If you locate your observation point (or observation domain) at a routers line card, then the multicast daemon running on the core processor of your router is not in the observation domain. However, it would still be nice to report the number of multicast packets and octets after packet treatment by the multicast daemon. > I will show that this view exclude the solution 1, leads to the natural > selection of slightly modified solution 2, i.e. solution 3 > > Remember the flow definition, in which the packet treatment is clearly mentioned: > > A Flow is defined as a set of IP packets passing an Observation > Point in the network during a certain time interval. All packets > belonging to a particular Flow have a set of common properties. > Each property is defined as the result of applying a function to > the values of: > > 1. One or more packet header field (e.g. destination IP address), > transport header field (e.g. destination port number), or > application header field (e.g. RTP header fields RTP-HDRF > [5]. > > 2. One or more characteristics of the packet itself (e.g. number > of MPLS labels) > > 3. One or more fields derived from packet treatment (e.g. next > hop IP address, output interface) > I see the "packet treatment" as the typical function of a middlebox. Agreed. > The definition could have been extended with for example the modified DSCP value. > > So let me propose the solution 3 (let me refer to "solution 3" later on in > this email): > all flow properties that are exported represent the flow as it was > when entering the IPFIX device except, if their name has the > prefix "post". Information elements without the prefix would > describe flows characteristics of incoming packets and information > elements with the "post" prefix would describe flows characteristics > after packet treatment. If I understand correctly, then solution 2 maps with/without prefix to incoming and outgoing with respect to the IPFIX device while solution 3 maps with/without prefix to incoming and outgoing packets with respect to the observation domain. Right? > See inline. > > > > Dear all, > > Here is the problem description for the "pre" and "post" prefixes > that I promised last weekend. > > I am sorry for the delay in sending this. It is caused by my > inability to explain the issue briefly. Please excuse that this > inability also is the reason why you have to read an awfully long > message in order to help solving the problem. > > > Let me start with a short introduction to the problem we have with > middleboxes and other boxes that change flow properties: > > Some middleboxes change properties of a flow. For example, a DiffServ > marker changes the value of the IPv4 TOS field, a network address > translator changes source or destination IP addresses, and a traffic > shaper changes the number of packets and bytes of a flow. > > Consequently, on one side of a middlebox a traffic flow might have > properties that are different to its properties on the other side > of the middlebox. > > Now, if an observation point stretches so far that it includes both > sides of the middlebox, we run into ambiguities. In such a case, > there are two different values for packet count, byte count, DSCP, > source IP address, etc. to be observed at the observation point. > Which values should we export in such a situation? > > We discussed this issue at our meeting in Seoul where Martin gave > a presentation that you can find in the proceedings: > > Also a draft discussing it is available in the archive: > > > I see two solutions for this problem and the discussion we need to > have is about selecting one of them or another solution suggested by > someone else. > > > Solution 1 > The recommendation that was made at the meeting and in the (already > expired) draft was to avoid these ambiguities by avoiding to have an > observation point that includes both sides of a middlebox. > > > There is no ambiguities if you apply solution 3: > > > > This solves the ambiguity problem. If it is clearly specified on which > side of a middlebox we have our observation point, then we know which > observed values to export. > > However, sometimes it might be very useful to ALSO export values from > the other side of the middlebox. These would be values that were not > necessarily derived from direct observation of packets, but by other > means available at the IPFIX device. > > > I would say that it's not only useful, but it's a requirement. > If you don't allow to export after treatment I.E., you run into problems such as: > - exporting two records, from the ingress point and the egress observation points > of your middlebox If I have one metering process running on the ingress line card metering incoming traffic and another independent one on the egress line card metering outgoing traffic, then I would expect receiving two records for the same flow. > - trying to combine the records, to match the initial flow. You're going to tell > me that we could use the flow keys, but we don't always want to export the flow keys. > Alternatively, we could use a flow ID, but this becomes way too complex. > > > > > Let's take a multicast daemon as an the example. A multicast daemon > is not necessarily a middlebox, but it causes the same problem. > The daemon might be able to provide statistics on how many packets > it sent out for a certain multicast address. > > If now our observation domain is restricted to the incoming traffic > at a single network interface at the IPFIX device, then we will > observe only the incoming multicast flow. Still, it would be nice > to report for this flow the number of outgoing multicast packets > and octets. > > NetFlow version 9 supports this by fields MUL_DST_PKTS > and MUL_DST_BYTES. In the IPFIX info model they are called > postMCastPacketDeltaCount and postMCastOctetDeltaCount. > > Note these objects report something that can not (necessarily) > be observed at the flow's observation point. The info model > elements have the prefix 'post' in order to indicate the fact > that these values do not necessarily result from an actual > observation. In this case they result from the reporting of > the multicast daemon. > > > If you apply solution 3, it's up to the metering process at the observation > point to evaluate whether or not he can report any "post" information. > All routers/switches/middlebox will have a different architecture (one metering > process per interface, per combination of interfaces, per line card, per router, > etc...) so the only solution is to trust the metering process based on its > capabilities. Is the metering process able to report some after packet treatment info? One of the advantages of solution 1 is that what the metering process observes directly is always without prefix, may it be incoming, outgoing, before or after packet treatment. If the metering process does not know about any (potentially present) middleboxes then it always reports correctly if it reports what it sees without prefix. However, if it is aware of a middlebox, it may report how packets look like on the other side by using the "pre" or "post" prefix. > As second example we can look at a DiffServ packet marker. It > changes the DSCP value of packets. Following the approach of > solution 1, the location of the observation point should be > clearly specified to be at one or the other side of the marker. > There it observes the DSCP value that is reported by information > element classOfServiceIPv4 or classOfServiceIPv6. > > Also here, scenarios can easily be found for which it is desirable > to report also the DSCP value that the flow has on the other side > of the marker, that is not covered by the observation point. > This is supported by NetFlow version 9 with the DST_TOS field and > in our information model by the elements postClassOfServiceIPv4 > and postClassOfServiceIPv6. As you see from the prefix of their > name, we can only use them if the observation point is located > on the path of the packet before it passes the marker. If the > observation point would be located somewhere on the path after > the marker, we would need a different prefix for reporting from > the other side. > > Not really. Remember "All measurements must be conducted from the point of > view of the observation point." > So the observation point is not supposed to know that there is a previous > observation point in the path. > From the observation point point of view, it must report what is seen. > Hence no "pre" prefixes are needed. I think treating "pre" and "post" as symmetric prefixes is a feasible approach. > Next question: is there any packet treatment at this observation point? For solution 1 there is NEVER packet treatment AT an observation point. The observation point is a single 'point' in the network where packets pass by. Particularly, it does not include a middlebox function. > If no, we don't export any "post" prefix I.E. If yes, and if we can > report the values, we export some "post" prefix I.E. Repeating the example I used somewhere above: Let's assume that our observation domain (that is reported in the IPFIX message header) is a single line card. Now we want to report MUL_DST_PKTS / postMCastPacketDeltaCount: - If we apply solution 2 or 3 strictly, then we cannot report them if the multicast daemon is not running on the line card. - But let's assume we can make this information available by exchanging information with the multicast daemon. Which observation domain would we report? Just report the line card this would conflict with solutions 2 and 3. But reporting the line card and the core processor would also wrong, because we do not observe all packets passing the core (or at least the multicast daemon. We just report packets that originate at the observed line card AND pass the multicast daemon. > The current version of the info model suggests > prefix "pre" for this case, for example, "preClassOfServiceIPv4". > We do not have any instance of an information element with prefix > "pre" in the current version of our model, because common practice > is measuring at the incoming interface of a router. > > > The solution 3 would also apply if you would monitor traffic at different > points in the forwarding path of your device. > > > Still, we > would need to add them at some time in the future if we follow > solution one. Please not that also for the 'post' prefix only a > few instances are present. We clearly expect to need more "post" > elements if we start having IPFIX implementations on network > address translators (postsourceIPv4Address, postTransportPort, > etc.). > > > Solution 2 > The other way of solving the ambiguities is declaring that all > flow properties that are exported represent the flow as it was > when entering the IPFIX device except, if their name has the > prefix "post". Information elements without the prefix would > describe flows of incoming packets and elements with that > prefix would describe flows of outgoing packets. > > > Note that, in solution 3, I changed outgoing packets by "after packet treatment" > > > > In case of the multicast daemon, the packetDeltaCount would be > the number of incoming packets and the postMCastPacketDeltaCount > would be the number of outgoing multicast packets. > > > Yes. > > > > For the packet marker, classOfServiceIPv4 would deliver the value > of the DSCP before marking and preClassOfServiceIPv4 would deliver > the value after marking. > > > Typo -> postClassOfServiceIPv4 Thanks. > This solution allows a more relaxed specification of the > observation point. It may be the entire device. > > Exactly, this is a great advantage. > > > Ambiguities > are avoided for this case, because every element is marked to > concern either incoming or outgoing traffic. > > > Discussion > {Please note that I am biases and have a preference for solution 1. > Please contribute arguments for solution 2 or against solution 1 > that are missing in the lists below because I am too ignorant to > see them.} > > > Advantage of "solution 3" > - the concept is simpler > - we only need one prefix > > As solution 2 and 3 are almost similar, let me reply to the > "disadvantage of solution 2" section > > > > Advantages of solution 2: > - the concept is simpler. > - We only need one prefix. > > Disadvantages of solution 2: > - The concept is simple but not always clear. > What about traffic observed at a network interface card in > promiscuous mode. This traffic would be neither incoming nor > outgoing. > > > I don't see a problem, neither with solution 2 or solution 3. > The NIC is the observation point, and The problem is with solution 2, not with 3. > "All measurements must be conducted from the point of view of the > observation point." > So the traffic which is entering the observation point is considered as as incoming. > With solution 3, there is no packet treatment, so no "post" I.E.s are exported. > With solution 2, there is no outgoing packets, so no "post" I.E.s are exported. > > - A generic flow meter using libpcap typically observes incoming > traffic as well as outgoing traffic. This meter would need to > check for all packets if they are incoming or outgoing (probably > by checking the MAC addresses) and use elements without prefix > for reporting the incoming packets and elements with "post" > prefix for reporting the outgoing traffic. > > > Is this a drawback? All the traffic entering the observation point is metered. > " The observation point is a location in the network where IP packets can be observed." > I don't consider this as a drawback for solution 2 and 3 > > > - We must define an information element with a "post" prefix for > almost all the non-post elements in sections > - 5.3 IP Header Fields (31 elements) > - 5.4 Transport Header Fields (16 elements), > - 5.5 Sub-IP Header Fields (19 elements) > - 5.7 Min/Max Flow Properties (11 elements) > - 5.9 Per-Flow Counters (12 elements) > currently, only 13 of them are defined. > > > Yes, this is true for solution 2 and solution 3. > What we agreed in the past is that people will request those as they need them. > > > - We cannot report bidirectional flows anymore, if our observation > point does not cover all interfaces. If we measure at a single > interface, then we cannot aggregate the packet and octet counters > of a bi-directional flow, because for one direction we must use > the non-prefix counter and for the other direction we must use > the prefix counter. > > > True for solution 2 and solution 3 but I don't see how it's possible with the solution 1 with solution 1, the observation point is a single point not including any packet treatment. All packets that are directly observed there are reported without prefix. Hence you can aggregate the counters of packets that pass the observation point in different directions. > Advantages of solution 1: > - The concept is clean: no prefix for actually measured traffic > prefixes for flow properties that are obtained by other means. > - We need prefixes only if middleboxes are involved and supported > by the metering process. We do not need prefixes in all other > cases, particularly not for for simple bidirectional measurements > or for unidirectional measurements of outgoing traffic. > > > This is a big drawback. > If I have a router forwarding traffic, I export a template with no-prefix. > My monitoring application is happy. > Now, the operational team decides to add some DSCP re-marking capabilities > in the router. Now my templates export the "pre" I.E. for the same information. No. Before and after only packets observed at the observation point are reported independent of the presence of a middlebox. However, if the metering process has the appropriate capability, it can also report from beyond the middlebox using "pre" or "post" depending on the traffic direction. > Not sure my monitoring application will be happy. > Basically, depending on the (middlebox) features enabled on the router, > I will export different I.E.s. This solution doesn't work. This problem only exists for solution 2. I thin we can eliminate this one from further discussion. > Disadvantages of solution 2: > > > Typo -> Disadvantages of solution 1: Thanks. > - We need two prefixes > > > Basically we need "pre", "post" and no prefix. So we have 3 series of I.E.s Yes. > - We might end up with a higher total number of elements > > > - Another disadvantage. The choice of these pre, post, no prefix series of I.E.s > depend so much on the architecture of the device and that you will have > interoperability problem first of all, and the collector will have to know > the architecture of the exporter in order to benefit from the exported I.E.s Well, you mainly will have to precisely identify your observation point. Then there is no more dependency on the architecture. > The [IPFIX-INFO] draft has always been (almost) in line with solution 3 > until the recent addition in the version 8. I think the same holds for solution 1. Just the parts to which the "(almost)" refers are different. Cheers, Juergen > Regards, Benoit. > > > > Thanks, > > Juergen > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From KuhnKleit2210@futureforce.com Thu Jul 21 17:50:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dviva-0006bD-KQ for ipfix-archive@megatron.ietf.org; Thu, 21 Jul 2005 17:50:04 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15392 for ; Thu, 21 Jul 2005 17:50:00 -0400 (EDT) Received: from fau42-1-82-232-177-139.fbx.proxad.net ([82.232.177.139] helo=futureforce.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dvin2-0002Gs-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Jul 2005 16:41:12 -0500 From: "Kleitos Kuhn" To: "Madisyn Stephens" Subject: Good wwork Date: Thu, 21 Jul 2005 16:41:10 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C58E3C.E882DF00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?82.232.177.139 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C58E3C.E882DF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, You were thinking that a miracle had happened. So it has - ain her manner = - if one can apply the term to so dainty a lady. ItI tell ye? Ye see, = the young gentleman's under a misapprehensionWhy, what difference could = it have made? he asked.I have considered that, too, he announced. And = whilst my opinionCHAPTER XXIVI have had no lack of experiences of this = mortal life; but to behast a precious immortal soul, and there is = nothing in the world - a round dozen jack-booted, lobster-coated = troopers of the Tangiersgenerous impulse. But no offence between us, = Captain Blood!another there's Captain Blood.invaders.accomplished, = mildly dissolute, entirely elegant envoy of my Lordearly on the = following morning. After having systematically hunteda cutlass hung = from a leather baldrick loosely slung about his body;There is no more to = be said, gentlemen. My name is Blood - Captain ------=_NextPart_000_0008_01C58E3C.E882DF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello , VlSIT Our MedsByMail Shop and Save over 80%

Vl		RA AM		EN LE		RA Cl		IS,	And
AG	BI	VlT	AL	many Other.

You will be pIeasantly Surprised with our = PRlCES!

Have a nice = day.

------=_NextPart_000_0008_01C58E3C.E882DF00-- From Kenne6008@jbsenergy.com Fri Jul 22 12:55:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw0oA-0006KP-KA for ipfix-archive@megatron.ietf.org; Fri, 22 Jul 2005 12:55:34 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01868 for ; Fri, 22 Jul 2005 12:55:30 -0400 (EDT) Received: from [81.193.22.2] (helo=jbsenergy.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dw0Tp-0007Iy-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Jul 2005 11:34:34 -0500 From: "Kennedy Shultz" To: "Tamsin Dye" Subject: The Prooblem Solved Date: Fri, 22 Jul 2005 11:34:27 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C58EDB.39E1AB80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_003C_01C58EDB.39E1AB80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, now, and without noise.end with the downfall of King James. They were - = saving oldThe Breton took between coarse finger and thumb the = profferedBoth Lord Willoughby and the Admiral were on their feet.your = raid upon Barbados was most opportune. I am glad, therefore,The first = of these was Captain Blood's flagship the Arabella, whichyour niece. As = long as Blood lives, she will wait for him.learn these nonconforming = oafs something they'll not forget inwould follow.delicate white hand, = still clutching its handkerchief, and sproutingSo, so! M. de Rivarol = smiled malignantly. Not only do you offerM. de Rivarol's eyes narrowed. = His mind was full of what M. de Cussyof trial, I must interrupt you = now. You are no doubt ignorant ofTherefore he hoped that some echo of = this deed might reach her also,Then, all being aboard the three ships, = with the treasure safelyinvited to say whether he was guilty or not = guilty. He answered ------=_NextPart_000_003C_01C58EDB.39E1AB80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello , VlSIT Our MedsByMail Shop and Save over 80%

Vl		RA AM		EN LE		RA Cl		IS,	And
AG	BI	VlT	AL	many Other.

You will be pIeasantly Surprised with our = PRlCES!

Have a nice = day.

------=_NextPart_000_003C_01C58EDB.39E1AB80-- From majordomo@mil.doit.wisc.edu Sat Jul 23 05:22:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwGDE-0002uW-Mb for ipfix-archive@megatron.ietf.org; Sat, 23 Jul 2005 05:22:29 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13834 for ; Sat, 23 Jul 2005 05:22:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DwFmt-0001lP-00 for ipfix-list@mil.doit.wisc.edu; Sat, 23 Jul 2005 03:55:15 -0500 Received: from faui70.informatik.uni-erlangen.de ([131.188.37.37]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DwFmr-0001lK-00 for ipfix@net.doit.wisc.edu; Sat, 23 Jul 2005 03:55:14 -0500 Received: from faui7as.informatik.uni-erlangen.de (faui7as [131.188.37.230]) by faui70.informatik.uni-erlangen.de (8.9.3p2/8.1.3-FAU) with ESMTP id KAA22800; Sat, 23 Jul 2005 10:55:07 +0200 (MEST) Received: from [127.0.0.1] (faui7as.informatik.uni-erlangen.de [131.188.37.230]) by faui7as.informatik.uni-erlangen.de (Postfix) with ESMTP id 117DBCC1E3; Sat, 23 Jul 2005 10:55:03 +0200 (CEST) Message-ID: <42E205E8.2070101@informatik.uni-erlangen.de> Date: Sat, 23 Jul 2005 10:55:04 +0200 From: Falko Dressler Organization: University of Erlangen User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Cc: Falko Dressler , "'Gerhard Muenz'" , Christoph Sommer Subject: [ipfix] [Fwd: I-D ACTION:draft-dressler-ipfix-aggregation-01.txt] Content-Type: multipart/mixed; boundary="------------000801020001080002060904" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------000801020001080002060904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'd like to announce the -01 version of the IPFIX aggregation draft. Since the presentation at the previous IETF, we received only positive feedback. Compared to -00, many enhancements and clarifications were included. We believe that the draft is now already very mature. I requested a slot for the Paris meeting to discuss open issues and the next steps. Cheers, Falko -------- Original Message -------- Subject: I-D ACTION:draft-dressler-ipfix-aggregation-01.txt Date: Thu, 21 Jul 2005 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPFIX Aggregation Author(s) : F. Dressler, et al. Filename : draft-dressler-ipfix-aggregation-01.txt Pages : 18 Date : 2005-7-21 IPFIX Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX exporters) and analyzers (IPFIX collectors). Using aggregation techniques, measurement information of multiple similar flows is aggregated into one meta-flow record. The degree of similarity can be customized using aggregation rules. To ensure efficient communication of both aggregated flows and the aggregation rules used the IPFIX Protocol and IPFIX Information Model are slightly extended to allow two new abstract data types and a new type of template set. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggregation-01.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-dressler-ipfix-aggregation-01.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-dressler-ipfix-aggregation-01.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. -- Dr.-Ing. Falko Dressler Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 EMail: dressler@informatik.uni-erlangen.de / fd@acm.org WWW: http://www7.informatik.uni-erlangen.de/~dressler/ --------------000801020001080002060904 Content-Type: text/plain; name="draft-dressler-ipfix-aggregation-01.txt" Content-Disposition: inline; filename="draft-dressler-ipfix-aggregation-01.txt" Content-Transfer-Encoding: 7bit Network Working Group F. Dressler Internet-Draft C. Sommer Expires: January 21, 2006 University of Erlangen G. Munz University of Tubingen July 20, 2005 IPFIX Aggregation Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 21, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IPFIX Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX exporters) and analyzers (IPFIX collectors). Using aggregation techniques, measurement information of multiple similar flows is aggregated into one meta-flow record. The degree of similarity can be customized using aggregation rules. Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 1] Internet-Draft IPFIX Aggregation July 2005 To ensure efficient communication of both aggregated flows and the aggregation rules used the IPFIX Protocol and IPFIX Information Model are slightly extended to allow two new abstract data types and a new type of template set. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Aggregation Techniques . . . . . . . . . . . . . . . . . . . . 3 2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Methodology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 Meta-Flows and Meta-Flow Records . . . . . . . . . . . 4 2.2.2 Aggregation Rules . . . . . . . . . . . . . . . . . . 5 2.2.3 Rule Semantics . . . . . . . . . . . . . . . . . . . . 7 2.2.4 Special Fields . . . . . . . . . . . . . . . . . . . . 7 2.2.5 Shared Properties . . . . . . . . . . . . . . . . . . 8 2.2.6 Example Rule . . . . . . . . . . . . . . . . . . . . . 8 2.3 Application Examples . . . . . . . . . . . . . . . . . . . 9 2.3.1 Charging . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2 Intrusion Detection . . . . . . . . . . . . . . . . . 9 3. IPFIX Extensions . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 ipv4Network . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 portRanges . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Data Template . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Security considerations . . . . . . . . . . . . . . . . . . . 16 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1 Normative References . . . . . . . . . . . . . . . . . . . 16 5.2 Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 2] Internet-Draft IPFIX Aggregation July 2005 1. Introduction Flow measurement in high-speed large-scale networks easily produces a huge amount of data that can not be handled by a central analyzer without having been preprocessed. Flow aggregators alleviate this problem by selectively discarding measurement information and merging multiple individual flows into a smaller number of meta-flows, thus reducing both the number of exported flow records and the amount of data carried by each record. This document proposes how to design and implement IPFIX aggregators and introduces appropriate extensions to the IPFIX Protocol. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Aggregation Techniques 2.1 Architecture Aggregation of measurement data may take place at two possible stages: An internal aggregator, as depicted in Figure 1, is implemented as a process running in an IPFIX enabled device. It aggregates raw data generated by multiple metering processes and exports them as meta- flow records. An external aggregator, called concentrator in IPFIX terminology, may be used where the deployed monitoring devices cannot be modified to incorporate an internal aggregator. Furthermore, concentrators enable cascaded, multi-level aggregation of flow information. As shown in Figure 2, a concentrator receives flow records from monitoring devices and/or lower-level concentrators and exports the aggregated meta-flow information to higher-level concentrators and/or analyzers. Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 3] Internet-Draft IPFIX Aggregation July 2005 +------------------------------------------+ +--------------+ | IPFIX-enabled device .---. .---. | | | | .--------------------. | A | | | | .-->| Analyzer | | | Metering Process 1 |-. | g | | E | | | | | | `--------------------' | | g | | x | | | +--------------+ | | | r | | p |---' | . '-->| e | | o | | | . | g |-->| r | | | . .-->| a | | t |---. | | | t | | e | | | +--------------+ | .--------------------. | | o | | r | | | | | | | Metering Process N |-' | r | | | | '-->| Concentrator | | `--------------------' `---' `---' | | | +------------------------------------------+ +--------------+ Figure 1: Internal Aggregation +--------------+ +-----------------------+ +--------------+ | | | Concentrator | | | | Concentrator |-. | .---. .---. .---. | .-->| Analyzer | | | | | | C | | A | | | | | | | +--------------+ | | | o | | g | | E | | | +--------------+ '--->| l | | g | | x |---' | | l | | r | | p | | | | e |-->| e |-->| o | | | | c | | g | | r | | .--->| t | | a | | t |---. +--------------+ | | | o | | t | | e | | | +--------------+ | | | | | r | | o | | r | | | | | | IPFIX device |-' | | | | r | | | | '-->| Concentrator | | | | `---' `---' `---' | | | +--------------+ +-----------------------+ +--------------+ Figure 2: External Aggregation 2.2 Methodology 2.2.1 Meta-Flows and Meta-Flow Records We define the term meta-flow as an aggregate of individual flows that share a set of common properties. As an example, flows directed to the same destination address can be aggregated into a single meta- flow. Each resulting meta-flow record MAY contain a single counter for all packets directed to a given destination within a given time interval. All flow properties that distinguish the aggregated flows (e.g. the source address) will not be contained in the meta-flow Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 4] Internet-Draft IPFIX Aggregation July 2005 record any more. The content of the meta-flow record as well as an optional set of common properties for all aggregated flows is defined using an aggregation rule. A Data Template, as proposed in Section 3.3, MAY be used to define the structure of the meta-flow record and to inform the analyzer about the applied aggregation rule and the common properties. 2.2.2 Aggregation Rules Regarding aggregation methodologies, a simple, rule-based approach is proposed. The aggregator is supplied a list of user-defined aggregation rules. An aggregation rule consists of multiple aggregation instructions, one for each IPFIX fields that is to be considered by the aggregator. An aggregation instruction comprises the following elements: o The IPFIX field the aggregation instruction refers to (e.g. destinationIPv4Address). Only flows that contain the field mentioned will be considered for aggregation in the meta-flow. o An optional pattern for this field that restricts the aggregation to those flows that match the given value(s) (e.g. 10.10.0.0/16). Only flows that match all patterns of the rule will be aggregated in the meta-flow. o One of the field modifiers "discard", "keep", "aggregate", or "mask" that specifies how this field is treated by the aggregator and if it is included in the meta-flow record or not. With this definition of aggregation instructions each rule also unambiguosly defines the content of the meta-flow record as well as the template to export the meta-flow information. If and how a field is present in the meta-flow record, depends on the field modifier and is explained below. Fields that do not appear in any of the aggregation instructions, are not part of the meta-flow record. Since the export of a meta-flow record requires an appropriate template, a one-to-one relationship between rules and templates can be established. The following field modifiers are applicable to Flow Keys as defined in [I-D.ietf-ipfix-architecture]. discard: The field is not included in the meta-flow records, i.e. meta- flows are not distinguishable with respect to this field. Incoming flow records with different values for this IPFIX field are merged. Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 5] Internet-Draft IPFIX Aggregation July 2005 keep: The field is included in the meta-flow record, i.e. meta-flows are distinguishable with respect to this field. Incoming flow records with different values for this field are not merged, but contribute to different meta-flows instead. mask/n: (Applicable to IP addresses only) The field is included in the meta-flow record, but the number of significant bits reduced to n bits. Incoming flow records with IP addresses belonging to the same subnet are merged, so meta-flows are distinguishable with respect to resulting subnet addresses only. In accordance with the IPFIX Information Model the resulting IP address is transferred as one IP prefix field and one IP mask field. If an aggregation instruction refers to one of the field types mentioned in Section 2.2.4, no pattern must be specified. The only possible field modifier is: aggregate: The field is included in the meta-flow record. The determination of the value depends on the field type and is specified in Section 2.2.4. As an example, a counter field in a meta-flow record is assigned the sum of the corresponding values in the incoming flow records. Using the Data Template proposed in Section 3.3, the receiving collector is informed about the current rule set. Table 1 summarizes the field modifiers and the resulting information in the meta-flow records and Data Templates, respectively. +----------------+----------------+----------------+----------------+ | field modifier | pattern | field in | fixed-value | | | | meta-flow | field in Data | | | | record | Template | +----------------+----------------+----------------+----------------+ | discard | no | N/A | N/A | | discard | yes | N/A | yes, contains | | | | | pattern | | keep | no | yes | N/A | | keep | yes | yes, if | yes, contains | | | | pattern | pattern | | | | specifies a | | | | | range of | | | | | values | | Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 6] Internet-Draft IPFIX Aggregation July 2005 | mask | no | yes, IP | N/A | | | | network | | | | | address | | | mask | yes | yes, IP | yes, contains | | | | network | pattern | | | | address | | +----------------+----------------+----------------+----------------+ Table 1: Relation between field modifiers, meta-flow records, and Data Templates 2.2.3 Rule Semantics By default, incoming flow records are checked against every aggregation rule. If a rule matches, i.e. if the flow record comprises all required fields and matches all given patterns, the field modifiers are applied and the corresponding meta-flow record is generated or updated. Incoming flow records that match multiple rules thus contribute to multiple meta-flows. In some cases, it is prefered that an incoming flow record that matched a certain rule is not checked against other rules in order to avoid that this flow contributes to multiple meta-flows. Therefore, it is possible to indicate a preceding rule for each aggregation rule that has to be check before. The current rule is not applied if the flow record already matched the preceding rule. Using the preceding rule relationship, rules can be organized in rule chains and rule trees where only the first matching rule is applied in every chain or branch. Rules that do not define a preceding rule are checked against all incoming flow records and constitute the beginning of a rule chain or the root of a rule tree. Consequently, each flow record is counted only once within a single chain or branch, or not at all if none of the rules matches. The Preceding Rule field in the header of the Data Template (see Section 3.3) is used to identify the preceding rule by its Template ID. If set to 0, there is no preceding rule and the rule is checked against all incoming records. 2.2.4 Special Fields Fields that do not carry information about Flow Keys (see [I-D.ietf- ipfix-architecture]) but metering information, such as counters, timestamps etc., require special treatment. For example, the meta- flow's start timestamp is set to the minimum of the comprising flows' start timestamps. Packet and byte counters of aggregated flows are summed up. Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 7] Internet-Draft IPFIX Aggregation July 2005 Table 2 contains an overview of such fields for which a special treatment is proposed. Refer to the IPFIX Information Model [I-D.ietf-ipfix-info] for a description of the fields mentioned. +-----------------------+-----------+ | Field | Set To | +-----------------------+-----------+ | minimumPacketLength | minimum | | minimumTtl | minimum | | flowStartSeconds | minimum | | flowStartMilliSeconds | minimum | | maximumPacketLength | maximum | | maximumTtl | maximum | | flowEndSeconds | maximum | | flowEndMilliSeconds | maximum | | ipv6OptionHeaders | binary OR | | tcpControlBits | binary OR | | octetDeltaCount | sum | | packetDeltaCount | sum | +-----------------------+-----------+ Table 2: Information with Implicit Aggregation Rules 2.2.5 Shared Properties Matching patterns of fields (e.g. source port 80 and destination network 10.10.0.0/16 in the previous example) constitute shared properties of exported flows. Such shared properties are equal for all meta-flows resulting from the corresponding aggregation rule. Shared properties MAY be exported as regular IPFIX fields. However, in order to reduce redundancy and to make patterns distinguishable from other fields, they SHOULD be transmitted as fixed-value fields using the Data Template proposed in Section 3.3. As a result, no separate transmission of the aggregation instructions needs take place. 2.2.6 Example Rule Here is an example rule with four aggregation instructions: 1. Aggregate * discard sourceTransportPort in 80 * keep sourceIPv4Address * mask/24 destinationIPv4Address in 10.10.0.0/16 * aggregate packetDeltaCount This rule aggregates all flows to a destination address in the subnet 10.10.0.0/16 with source port equal to 80. Destination addresses are Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 8] Internet-Draft IPFIX Aggregation July 2005 merged according to subnets in 10.10.x.0/24. The resulting meta-flow records comprise the source address, the destination subnet address, and the packet counter. 2.3 Application Examples 2.3.1 Charging Monitoring and accouting for charging applications require saving information about each individual end system. Further information about each particular flow is not required. Therefore, aggregation rules are appropriate if the address of the end system is retained. An example ruleset might consist of the following instructions: 1. Aggregate * keep destinationIPv4Address in 10.10.0.0/16 * aggregate packetDeltaCount 2. Aggregate * keep sourceIPv4Address in 10.10.0.0/16 * aggregate packetDeltaCount Thus, aggregated meta-flows will be created for all inbound and outbound traffic of the network managed, separated by direction and host. Protocol and port information will be discarded. 2.3.2 Intrusion Detection If monitoring is employed for further analysis in terms of intrusion detection, i.e. anomaly detection, rule-based intrusion detection, etc., information about used protocols at transport layer as well as at application layer is mostly required. On the other hand, the analysis will typically work on the basis of subnetworks instead of single hosts because the analysis of individual flows would require to much processing power. Accurate information about the traffic between individual end systems is only required if suspicious transmissions have already been detected. An example ruleset might consist of the following instructions: 1. Aggregate * keep destinationIPv4Address in 10.10.0.0/16 * mask/24 sourceIPv4Address * keep protocolIdentifier * keep destinationTransportPort * aggregate packetDeltaCount Thus, aggregated meta-flows will be created for all packets to hosts in a particular network. The destination port and the protocol will be preserved and the source port will be discarded. Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 9] Internet-Draft IPFIX Aggregation July 2005 3. IPFIX Extensions After having a rule's field modifiers applied, all data records that matched a rule comprise the same fields, so for each rule exactly one template can be used. In order to efficiently transmit aggregated flows, however, three extensions to IPFIX are required: o New abstract data type "IPNetwork" o New abstract data type "portRanges" o New "Data Template" set 3.1 ipv4Network Currently, the transport of IP network information as specified by IPFIX is done using separate fields for the network address and the corresponding mask. We propose a new abstract data type ipv4Network that represents the common notation of IP networks: address/mask. Thus, this data type is build of an unsigned32 for the IPv4 address and a single byte for the prefix length, whereas the encoding of the IPv4 address corresponds to the definition of the ipv4Address in the IPFIX Information Model. ipv4Network is required because it offers more flexibility and scalability if hugh numbers of IPv4 networks have to be transmitted, as ususally done using IPFIX Aggregation. 3.2 portRanges As the current draft contains no data type to transmit port lists or port ranges, but many applications require port-based aggregation, this section defines a new abstract data type for a list of port ranges. portRanges is a finite length string of unsigned32 values, each consisting of an unsigned16 start port followed by an unsigned16 end port specification. portRanges MAY be used as a variable-length data type as defined in [I-D.ietf-ipfix-protocol]. Data types basing on portRanges MAY also be cast down to unsigned16 to represent a single Port. Hence, the transportSourcePort and transportDestinationPort data types, currently based on the unsigned16 abstract data type, MAY be replaced by portRanges. Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 10] Internet-Draft IPFIX Aggregation July 2005 +---------------+--------+---------------------------------+ | Ports | Length | Hexadecimal Representation | +---------------+--------+---------------------------------+ | 80 | 2 | 0050 | | 1:7 | 4 | 0001 0007 | | 80, 443 | 8 | 0050 0050 01BB 01BB | | 1:7, 256:1024 | 8 | 0001 0007 0100 0400 | | 20, 80, 443 | 12 | 0014 0014 0050 0050 01BB 01BB | | 1:7, 80, 443 | 12 | 0001 0007 0050 0050 01BB 01BB | +---------------+--------+---------------------------------+ Table 3: PortRanges Examples 3.3 Data Template When doing rule based aggregation of flows, the resulting meta-flows share many field values. In order to avoid the overhead of the repeated transmission of these shared properties in all meta-flow records resulting from a given rule, a new template type is introduced. Additionally, the aggregation rule set is provided to the analyzer. Using this information, the collector is able to quantify the received data. This template type, termed a "Data Template", allows the sender to both declare and define common properties of Data Sets based on it. The basic format of a Data Template Set is the same as that of a Template Set and - for the sake of completeness - is shown in Figure 3. The format of individual template definitions, however, differs from that of the standard Template and is shown in Figure 4. Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 11] Internet-Draft IPFIX Aggregation July 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data Template 1 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data Template N | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Data Template Set Format The Data Template Set field definitions are as follows: Set ID Type of this template set. A set ID value of 4 is proposed for the Data Template Set. Length Total length of this set in bytes. Padding Optional padding to fill the set to a word boundary. It MUST consist of null-bytes and be at most seven bytes in length Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 12] Internet-Draft IPFIX Aggregation July 2005 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Count | Preceding Rule | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Field 1 Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Field N Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data 1 Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data M Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data 1 Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data M Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Data Template Format The Data Template field definitions are as follows: Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 13] Internet-Draft IPFIX Aggregation July 2005 Template ID See the description of a Type 3 Template Set in [I-D.ietf-ipfix- protocol] Field Count Number of regular Fields that will be sent in subsequent Data Sets using this Template. Data Count Number of fixed-value Fields that will be sent in this Template. Preceding Rule Template ID of the preceding rule that is checked before, or 0 if all incoming records are checked against this rule. When organizing aggregation rules in a chain or tree where rules are sequentially checked on a first-match basis as proposed in Section 2.2.3, the order in which rules are checked needs to be made clear to the receiving collector. Because of the one-to-one mapping between rules and template IDs, communicating the order of rules is as simple as embedding the preceding rule's Template ID into the Data Template(s) of the rule(s) that follow(s). This way the concentrator is implicitly sent the order of the aggregation rules within the chain or tree. Field N Type Type identifier, Type length and an enterprise number (if needed) of field N. Refer to [I-D.ietf-ipfix-protocol] for more information on Field Types Data M Type Same as "Field N Type", but used for common properties of all Data Sets that use this Template. Together with Data M Value, a similar encoding like TLV is achieved. Data M Value Bit representation of a common property as would be transmitted in a Data Set. 3.4 Example In this example we assume the concentrator was given the following aggregation rule: 1. Aggregate * discard sourceIPv4Address in 10.0.0.0/23 * keep destinatonTransportPort Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 14] Internet-Draft IPFIX Aggregation July 2005 * aggregate packetDeltaCount We further assume the concentrator receives the following flow records: +------------+------------+-------------+-------------+-------------+ | Source IP | Source | Destination | Destination | Packets | | | Port | IP | Port | | +------------+------------+-------------+-------------+-------------+ | 10.0.0.1 | 64235 | 10.0.0.10 | 80 | 10 | | 10.0.1.2 | 64236 | 10.0.0.11 | 110 | 10 | | 10.0.0.3 | 64237 | 10.0.0.12 | 80 | 10 | | 10.0.2.4 | 64238 | 10.0.0.13 | 80 | 10 | | 10.0.2.5 | 64239 | 10.0.0.14 | 80 | 10 | +------------+------------+-------------+-------------+-------------+ Table 4: Incoming Flows Based on the aggregation rule stated above the concentrator would now first send a Data Template Set containing the Data Template corresponding to the given rule: +--------------+-------------------+ | Field | Value | +--------------+-------------------+ | Template ID | 10001 | | Field Count | 2 | | Data Count | 2 | | Reserved | 0 | | Field 1 Type | Destination Port | | Field 2 Type | Packets | | Data 1 Type | Source IP Network | | Data 2 Type | Source IP Mask | | Data 1 Value | 10.10.0.0 | | Data 2 Value | 23 | +--------------+-------------------+ Table 5: Data Template used Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 15] Internet-Draft IPFIX Aggregation July 2005 The second Set transmitted now uses this Data Template to send all flows that matched the given rule. Note that the flows' common property, a Source IP of 10.0.0.0/23, was already transmitted in the template, so besides the packet count only the flows' discriminating property, their destination port, is sent in the data records: +------------------+---------+ | Destination Port | Packets | +------------------+---------+ | 80 | 20 | | 110 | 10 | +------------------+---------+ Table 6: Aggregated Flows 4. Security considerations As all methods described in this document are merely variations on methods already introduced in [I-D.ietf-ipfix-protocol], the same rules regarding exchange of flow information apply. 5. References 5.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 5.2 Informative References [I-D.ietf-ipfix-architecture] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", draft-ietf-ipfix-architecture-08 (work in progress), March 2005. [I-D.ietf-ipfix-protocol] Claise, B., "IPFIX Protocol Specifications", draft-ietf-ipfix-protocol-16 (work in progress), June 2005. [I-D.ietf-ipfix-info] Quittek, J., Bryant, S., Claise, B., and J. Meyer, "Information Model for IP Flow Information Export", draft-ietf-ipfix-info-07 (work in progress), May 2005. [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 16] Internet-Draft IPFIX Aggregation July 2005 "Requirements for IP Flow Information Export", RFC 3917, October 2004. Authors' Addresses Falko Dressler University of Erlangen Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Phone: +49 9131 85-27914 Email: dressler@informatik.uni-erlangen.de URI: http://www7.informatik.uni-erlangen.de/ Christoph Sommer University of Erlangen Department of Computer Science 7 Martensstr. 3 Erlangen 91058 Germany Email: sichsomm@stud.informatik.uni-erlangen.de Gerhard Munz University of Tubingen Computer Networks and Internet Auf der Morgenstelle 10C Tubingen 72076 Germany Phone: +49 7071 29-70534 Email: muenz@informatik.uni-tuebingen.de URI: http://net.informatik.uni-tuebingen.de/ Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 17] Internet-Draft IPFIX Aggregation July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dressler, et al. draft-dressler-ipfix-aggregation-01.txt [Page 18] --------------000801020001080002060904-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From KrysGent@jadedchaos.com Sat Jul 23 10:14:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwKlt-0007U0-VS for ipfix-archive@megatron.ietf.org; Sat, 23 Jul 2005 10:14:34 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27552 for ; Sat, 23 Jul 2005 10:14:31 -0400 (EDT) Received: from host119-23.pool80117.interbusiness.it ([80.117.23.119] helo=jadedchaos.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DwKdi-0000Ub-00 for ipfix-list@mil.doit.wisc.edu; Sat, 23 Jul 2005 09:06:07 -0500 From: "Krystine Gentile" To: "Unique Kessler" Subject: Really Works Grreat Date: Sat, 23 Jul 2005 09:06:01 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C58F8F.A7E7AA80" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (dnsbl.njabl.org) Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C58F8F.A7E7AA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, losing his head. Sacre Dieu! Where do you suppose that I haveprisoners, = the slaves, and most of the captured merchandise. Theevidence, = whereupon the scarlet figure of the Lord Chief Justicewith the scent of = them. It was one of those pleasantWilloughby there was a word of blame = for Blood's seamanship inhusky. And without waiting to hear what it = might be, he raved on:him - an unprecedented condescension this, for = hitherto neither ofThe absence of that dazed jury was a brief one. The = verdict foundGovernor Steed! he echoed. Then he lowered his cane, swung = round,more. Answer me this, sir: When you cozened Captain Hobart = withYou are assuming that Cartagena is a city of the blind, that atYou = will find, said he to her captain, that Don Miguel is in anIf you will = sail with me again, the Captain answered him, you mayif you please, he = invited them, whilst the chests are beingM. de RIVAROLfound himself = after his escape from Barbados, and all the rest that ------=_NextPart_000_005E_01C58F8F.A7E7AA80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to Pha = intake rmOnline Sho amethyst = p - one of Kirghiz = the leading onIine pharmaceutical shops

unquestioning V		hawker G		A inclined L		L whiplash l
pucker = lA	diluent = RA shaving = Cl	I slangy = S mounting = VA	= blackingout UM	and many other.

- Save over = emblematize 50%

- Worldwide SHl = agnail PPlNG

- Total confidentiaI = reduce ity

- Over 5 miIIion cus = Capitol tomers in 130 countries

Ha pineapple = ve a nice day!

------=_NextPart_000_005E_01C58F8F.A7E7AA80-- From Beau_7216@rs.com Sun Jul 24 09:38:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwgg4-0005Yq-BP for ipfix-archive@megatron.ietf.org; Sun, 24 Jul 2005 09:38:00 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27574 for ; Sun, 24 Jul 2005 09:37:57 -0400 (EDT) Received: from m61.net85-168-38.noos.fr ([85.168.38.61] helo=rs.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DwgMa-0007LU-00 for ipfix-list@mil.doit.wisc.edu; Sun, 24 Jul 2005 08:17:53 -0500 From: "Clitus Beauchamp" To: "Bevin Mayberry" Subject: well, do you need it? Date: Sun, 24 Jul 2005 08:17:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C59052.14C37900" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?85.168.38.61 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C59052.14C37900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, colour to her cheeks and a flutter to her eyelids.Babel was reenacted. The = main body of them welcomed the announcementvoice sank again. He uttered = a little laugh of weariness andwhat Captain Blood so confidently counted = that they would do - And we put her to the sword,the fate of any = Spaniards he should henceforth encounter upon theof the council = assembled to receive the Admiral's answer. His faceyours that you = should insult a man who is unarmed and your prisoner.Promised Land, Don = Pedro.behoved every man who deemed himself a man to take up arms. = TheyWith this they were to surmount the stockade and gain the open. = TheAnd there's another matter, Mr. Blood resumed. There's a = mattercopper - that this rogue had for some time now been = growingfalsehood, and justly strike thee into eternal flames, make = theePeter Blood desired assistance at that moment was this youngI know = nothing of filibuster customs. The gentleman was ------=_NextPart_000_0003_01C59052.14C37900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to boyishness PharmOnline Sh = multiversity op - one of the leading onIine pharmaceutical neozoic shops

cramped V		perquisite G		A straggling L		memorialist Ll
= saprogenic lA	R maroon = A arrack = Cl	I = dejection S V poetry = A	= costumier UM	and many other.

- Save ove trespasser = r 50%

- Worldwide SHl = faddiness PPlNG

- Total confidentia = signpost Iity

- Ove ganglion = r 5 miIIion customers in 130 countries

Have a nice day = antifriction !

------=_NextPart_000_0003_01C59052.14C37900-- From Markham4565@keyesbrokers.com Sun Jul 24 20:45:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwr67-0000Em-Hc for ipfix-archive@megatron.ietf.org; Sun, 24 Jul 2005 20:45:35 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08086 for ; Sun, 24 Jul 2005 20:45:33 -0400 (EDT) Received: from 219-88-100-200.jetstream.xtra.co.nz ([219.88.100.200] helo=keyesbrokers.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dwqor-0001Gg-00 for ipfix-list@mil.doit.wisc.edu; Sun, 24 Jul 2005 19:27:46 -0500 From: "Candela Markham" To: "Hylda Wolf" Subject: =?iso-8859-1?Q?Cl=C0LlSS_V=C1LlUMM_V=EDAGRRA?= Date: Sun, 24 Jul 2005 19:27:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C590AF.AB725300" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?219.88.100.200 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C590AF.AB725300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, officer, who used the grossest provocation, they have arrestedBut - nom de = Dieu! - it is your concern, I suppose, that we cannotconfinement under = hatches, ill-nourishment and foul water, ais still this other matter = upon which you have not answered me.him, and shrink back in fear.Captain = Blood tucked his left arm through the Deputy-Governor'sphysician's eye, = Peter Blood judged him a prey to the pain of thebroad black hat with a = scarlet ostrich-plume, in his left hand anYe're going to deliver = yourself into Bishop's hands, Pitt warnedhe derived from it - a clemency = full worthy of him. He knew thatrebels-convict.sorry for. D'ye know = what Ye've done? Sure, now, ye've very likelyall men the most anxious = for the deliverance of his city, the oneI am sorry for that, so I am, = said Blood impudently. Butmy lord. But, I'm thinking that while he's = about it, I'd best behim. What, then, must I find you? He spoke = quietly, almost ------=_NextPart_000_003A_01C590AF.AB725300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to MegaPharm Online = Shop.

Prescriptio		s		ne can SAV		MONEY!
n Drug	ordered Onli	E YOU

In some cases you can sav		% on the		scription medica
e up to 80	cost of your pre	tion.

Thousands of our customers already enjoy these = savings.

We deIiver direct to your door through fast, = Low-C0ST, reliable and secure service on the Internet.

CIick = Here forr PRlCES.

Have a nice day.

------=_NextPart_000_003A_01C590AF.AB725300-- From majordomo@mil.doit.wisc.edu Mon Jul 25 11:46:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5AI-0000CZ-LM for ipfix-archive@megatron.ietf.org; Mon, 25 Jul 2005 11:46:50 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01358 for ; Mon, 25 Jul 2005 11:46:47 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dx4sg-0003SE-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Jul 2005 10:28:38 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dx4se-0003S7-00 for ipfix-info@net.doit.wisc.edu; Mon, 25 Jul 2005 10:28:36 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6PFSXw11050; Mon, 25 Jul 2005 17:28:33 +0200 (CEST) Received: from [144.254.7.78] (dhcp-peg3-vl30-144-254-7-78.cisco.com [144.254.7.78]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6PFSVp24114; Mon, 25 Jul 2005 17:28:31 +0200 (CEST) Message-ID: <42E5051F.5080901@cisco.com> Date: Mon, 25 Jul 2005 17:28:31 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Nevil Brownlee , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" References: <45153F8B40ECB0CCCA744072@[192.168.0.112]> In-Reply-To: <45153F8B40ECB0CCCA744072@[192.168.0.112]> Content-Type: multipart/alternative; boundary="------------050802070805010106090909" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------050802070805010106090909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Juergen, See more in line. > Hi Benoit, > > Thanks for the detailed reply. > Please find comments in line. > > --On 7/20/2005 2:01 PM +0200 Benoit Claise wrote: > >> Juergen and all, >> >> Thanks for the detailed email. It will ease the discussion. >> >> You see this pre and post prefix problem from the point of view of the >> observation point only. >> This is fine because we have in RFC 3917: >> >> "All measurements must be conducted from the point of view of the >> observation point." >> Btw, I think that this statement should appear in [IPFIX-ARCH]. I >> took me >> quite some time to locate this sentence as I thought it was in one of >> current draft already. >> However, I see the problem differently: before and after the packet >> treatment at the observation point. > > > I think here is already the point where we are not in sync. > I do not expect the packet treatment to necessarily happen at the > observation point only. I agree we are not in sync. ;) You wrote "I do not expect ...". This is the issue: you expect what the observation point will be ... and from there, you try to deduce the correct behavior for pre and post. From the observation point definition, we see that we can't assume anything about the observation. An Observation Point is a location in the network where IP packets can be observed. Examples include: a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a single port of a router, or a set of interfaces (physical or logical) of a router. > > Let's take the multicast daemon as an example that is already > supported by > NetFlow version 9. If you locate your observation point (or observation > domain) at a routers line card, then the multicast daemon running on the > core processor of your router is not in the observation domain. However, > it would still be nice to report the number of multicast packets and > octets > after packet treatment by the multicast daemon. Again you assume things: in this case that the multicast daemon running on the core processor. If you take into account "All measurements must be conducted from the point of view of the observation point.", then it's the observation point will report what he thinks he's right after packet treatment (this is solution 3 below). BTW, there is nothing more we can do from the observation point of view. > >> I will show that this view exclude the solution 1, leads to the natural >> selection of slightly modified solution 2, i.e. solution 3 >> >> Remember the flow definition, in which the packet treatment is >> clearly mentioned: >> >> A Flow is defined as a set of IP packets passing an Observation >> Point in the network during a certain time interval. All packets >> belonging to a particular Flow have a set of common properties. >> Each property is defined as the result of applying a function to >> the values of: >> >> 1. One or more packet header field (e.g. destination IP address), >> transport header field (e.g. destination port number), or >> application header field (e.g. RTP header fields RTP-HDRF >> [5]. >> >> 2. One or more characteristics of the packet itself (e.g. number >> of MPLS labels) >> >> 3. One or more fields derived from packet treatment (e.g. next >> hop IP address, output interface) >> I see the "packet treatment" as the typical function of a middlebox. > > > Agreed. > >> The definition could have been extended with for example the modified >> DSCP value. >> >> So let me propose the solution 3 (let me refer to "solution 3" later >> on in >> this email): >> all flow properties that are exported represent the flow as it was >> when entering the IPFIX device except, if their name has the >> prefix "post". Information elements without the prefix would >> describe flows characteristics of incoming packets and information >> elements with the "post" prefix would describe flows characteristics >> after packet treatment. > > > If I understand correctly, then solution 2 maps with/without prefix to > incoming and outgoing with respect to the IPFIX device while solution 3 > maps with/without prefix to incoming and outgoing packets with respect > to the observation domain. Right? No. Let me rephrase this. all flow properties that are exported represent the flow as it was when entering the _observation point_ except, if their name has the prefix "post". Information elements without the prefix would describe flows characteristics of incoming packets and information elements with the "post" prefix would describe flows characteristics after packet treatment, _from an observation point of view_. > >> See inline. >> >> >> >> Dear all, >> >> Here is the problem description for the "pre" and "post" prefixes >> that I promised last weekend. >> >> I am sorry for the delay in sending this. It is caused by my >> inability to explain the issue briefly. Please excuse that this >> inability also is the reason why you have to read an awfully long >> message in order to help solving the problem. >> >> >> Let me start with a short introduction to the problem we have with >> middleboxes and other boxes that change flow properties: >> >> Some middleboxes change properties of a flow. For example, a >> DiffServ >> marker changes the value of the IPv4 TOS field, a network address >> translator changes source or destination IP addresses, and a traffic >> shaper changes the number of packets and bytes of a flow. >> >> Consequently, on one side of a middlebox a traffic flow might have >> properties that are different to its properties on the other side >> of the middlebox. >> >> Now, if an observation point stretches so far that it includes both >> sides of the middlebox, we run into ambiguities. In such a case, >> there are two different values for packet count, byte count, DSCP, >> source IP address, etc. to be observed at the observation point. >> Which values should we export in such a situation? >> >> We discussed this issue at our meeting in Seoul where Martin gave >> a presentation that you can find in the proceedings: >> >> >> Also a draft discussing it is available in the archive: >> >> >> >> >> I see two solutions for this problem and the discussion we need to >> have is about selecting one of them or another solution suggested by >> someone else. >> >> >> Solution 1 >> The recommendation that was made at the meeting and in the (already >> expired) draft was to avoid these ambiguities by avoiding to >> have an >> observation point that includes both sides of a middlebox. >> >> >> There is no ambiguities if you apply solution 3: >> >> >> >> This solves the ambiguity problem. If it is clearly specified on >> which >> side of a middlebox we have our observation point, then we know >> which >> observed values to export. >> >> However, sometimes it might be very useful to ALSO export values >> from >> the other side of the middlebox. These would be values that >> were not >> necessarily derived from direct observation of packets, but by >> other >> means available at the IPFIX device. >> >> >> I would say that it's not only useful, but it's a requirement. >> If you don't allow to export after treatment I.E., you run into >> problems such as: >> - exporting two records, from the ingress point and the egress >> observation points >> of your middlebox > > > If I have one metering process running on the ingress line card > metering incoming > traffic and another independent one on the egress line card metering > outgoing traffic, > then I would expect receiving two records for the same flow. In this case, you're right! I was thinking of a simple router without line cards (so a single observation domain). In this case, if we don't want to export to flow records, we must export after packet treatment. > >> - trying to combine the records, to match the initial flow. You're >> going to tell >> me that we could use the flow keys, but we don't always want to >> export the flow keys. >> Alternatively, we could use a flow ID, but this becomes way too complex. >> >> >> >> >> Let's take a multicast daemon as an the example. A multicast >> daemon >> is not necessarily a middlebox, but it causes the same problem. >> The daemon might be able to provide statistics on how many packets >> it sent out for a certain multicast address. >> >> If now our observation domain is restricted to the incoming traffic >> at a single network interface at the IPFIX device, then we will >> observe only the incoming multicast flow. Still, it would be nice >> to report for this flow the number of outgoing multicast packets >> and octets. >> >> NetFlow version 9 supports this by fields MUL_DST_PKTS >> and MUL_DST_BYTES. In the IPFIX info model they are called >> postMCastPacketDeltaCount and postMCastOctetDeltaCount. >> >> Note these objects report something that can not (necessarily) >> be observed at the flow's observation point. The info model >> elements have the prefix 'post' in order to indicate the fact >> that these values do not necessarily result from an actual >> observation. In this case they result from the reporting of >> the multicast daemon. >> >> >> If you apply solution 3, it's up to the metering process at the >> observation >> point to evaluate whether or not he can report any "post" information. >> All routers/switches/middlebox will have a different architecture >> (one metering >> process per interface, per combination of interfaces, per line card, >> per router, >> etc...) so the only solution is to trust the metering process based >> on its >> capabilities. Is the metering process able to report some after >> packet treatment info? > > > One of the advantages of solution 1 is that what the metering process > observes > directly is always without prefix, may it be incoming, outgoing, > before or after > packet treatment. If the metering process does not know about any > (potentially > present) middleboxes then it always reports correctly if it reports > what it sees > without prefix. However, if it is aware of a middlebox, it may report > how packets > look like on the other side by using the "pre" or "post" prefix. As I wrote below, this is not an advantage but a drawback [drawback] > >> As second example we can look at a DiffServ packet marker. It >> changes the DSCP value of packets. Following the approach of >> solution 1, the location of the observation point should be >> clearly specified to be at one or the other side of the marker. >> There it observes the DSCP value that is reported by information >> element classOfServiceIPv4 or classOfServiceIPv6. >> >> Also here, scenarios can easily be found for which it is desirable >> to report also the DSCP value that the flow has on the other side >> of the marker, that is not covered by the observation point. >> This is supported by NetFlow version 9 with the DST_TOS field and >> in our information model by the elements postClassOfServiceIPv4 >> and postClassOfServiceIPv6. As you see from the prefix of their >> name, we can only use them if the observation point is located >> on the path of the packet before it passes the marker. If the >> observation point would be located somewhere on the path after >> the marker, we would need a different prefix for reporting from >> the other side. >> >> Not really. Remember "All measurements must be conducted from the >> point of >> view of the observation point." >> So the observation point is not supposed to know that there is a >> previous >> observation point in the path. >> From the observation point point of view, it must report what is seen. >> Hence no "pre" prefixes are needed. > > > I think treating "pre" and "post" as symmetric prefixes is a feasible > approach. > >> Next question: is there any packet treatment at this observation point? > > > For solution 1 there is NEVER packet treatment AT an observation point. > The observation point is a single 'point' in the network where packets > pass by. Particularly, it does not include a middlebox function. Remember the multiple examples of the observation point... > >> If no, we don't export any "post" prefix I.E. If yes, and if we can >> report the values, we export some "post" prefix I.E. > > > Repeating the example I used somewhere above: > Let's assume that our observation domain (that is reported in the IPFIX > message header) is a single line card. > > Now we want to report MUL_DST_PKTS / postMCastPacketDeltaCount: > > - If we apply solution 2 or 3 strictly, then we cannot report > them if the multicast daemon is not running on the line card. Right. > > - But let's assume we can make this information available by > exchanging information with the multicast daemon. > Which observation domain would we report? > Just report the line card this would conflict with solutions 2 and 3. > But reporting the line card and the core processor would also wrong, > because we do not observe all packets passing the core (or at least > the multicast daemon. We just report packets that originate at the > observed line card AND pass the multicast daemon. I personally think that you make the situation more complicated than it's really is by always referring to the multicast example. The logic in your example would tell us to use the observation domain as being the incoming line card. > >> The current version of the info model suggests >> prefix "pre" for this case, for example, "preClassOfServiceIPv4". >> We do not have any instance of an information element with prefix >> "pre" in the current version of our model, because common practice >> is measuring at the incoming interface of a router. >> >> >> The solution 3 would also apply if you would monitor traffic at >> different >> points in the forwarding path of your device. >> >> >> Still, we >> would need to add them at some time in the future if we follow >> solution one. Please not that also for the 'post' prefix only a >> few instances are present. We clearly expect to need more "post" >> elements if we start having IPFIX implementations on network >> address translators (postsourceIPv4Address, postTransportPort, >> etc.). >> >> >> Solution 2 >> The other way of solving the ambiguities is declaring that all >> flow properties that are exported represent the flow as it was >> when entering the IPFIX device except, if their name has the >> prefix "post". Information elements without the prefix would >> describe flows of incoming packets and elements with that >> prefix would describe flows of outgoing packets. >> >> >> Note that, in solution 3, I changed outgoing packets by "after packet >> treatment" >> >> >> >> In case of the multicast daemon, the packetDeltaCount would be >> the number of incoming packets and the postMCastPacketDeltaCount >> would be the number of outgoing multicast packets. >> >> >> Yes. >> >> >> >> For the packet marker, classOfServiceIPv4 would deliver the value >> of the DSCP before marking and preClassOfServiceIPv4 would deliver >> the value after marking. >> >> >> Typo -> postClassOfServiceIPv4 > > > Thanks. > >> This solution allows a more relaxed specification of the >> observation point. It may be the entire device. >> >> Exactly, this is a great advantage. >> >> >> Ambiguities >> are avoided for this case, because every element is marked to >> concern either incoming or outgoing traffic. >> >> >> Discussion >> {Please note that I am biases and have a preference for solution 1. >> Please contribute arguments for solution 2 or against solution 1 >> that are missing in the lists below because I am too ignorant to >> see them.} >> >> >> Advantage of "solution 3" >> - the concept is simpler >> - we only need one prefix >> >> As solution 2 and 3 are almost similar, let me reply to the >> "disadvantage of solution 2" section >> >> >> >> Advantages of solution 2: >> - the concept is simpler. >> - We only need one prefix. >> >> Disadvantages of solution 2: >> - The concept is simple but not always clear. >> What about traffic observed at a network interface card in >> promiscuous mode. This traffic would be neither incoming nor >> outgoing. >> >> >> I don't see a problem, neither with solution 2 or solution 3. >> The NIC is the observation point, and > > > The problem is with solution 2, not with 3. I don't see a problem with solution 2 regarding this issue. > >> "All measurements must be conducted from the point of view of the >> observation point." >> So the traffic which is entering the observation point is considered >> as as incoming. >> With solution 3, there is no packet treatment, so no "post" I.E.s are >> exported. >> With solution 2, there is no outgoing packets, so no "post" I.E.s are >> exported. >> >> - A generic flow meter using libpcap typically observes incoming >> traffic as well as outgoing traffic. This meter would need to >> check for all packets if they are incoming or outgoing (probably >> by checking the MAC addresses) and use elements without prefix >> for reporting the incoming packets and elements with "post" >> prefix for reporting the outgoing traffic. >> >> >> Is this a drawback? All the traffic entering the observation point is >> metered. >> " The observation point is a location in the network where IP packets >> can be observed." >> I don't consider this as a drawback for solution 2 and 3 >> >> >> - We must define an information element with a "post" prefix for >> almost all the non-post elements in sections >> - 5.3 IP Header Fields (31 elements) >> - 5.4 Transport Header Fields (16 elements), >> - 5.5 Sub-IP Header Fields (19 elements) >> - 5.7 Min/Max Flow Properties (11 elements) >> - 5.9 Per-Flow Counters (12 elements) >> currently, only 13 of them are defined. >> >> >> Yes, this is true for solution 2 and solution 3. >> What we agreed in the past is that people will request those as they >> need them. >> >> >> - We cannot report bidirectional flows anymore, if our observation >> point does not cover all interfaces. If we measure at a single >> interface, then we cannot aggregate the packet and octet counters >> of a bi-directional flow, because for one direction we must use >> the non-prefix counter and for the other direction we must use >> the prefix counter. >> >> >> True for solution 2 and solution 3 but I don't see how it's possible >> with the solution 1 > > > with solution 1, the observation point is a single point not including > any > packet treatment. What about the different examples of an observation point? Ex: line card, router? > All packets that are directly observed there are reported > without prefix. Hence you can aggregate the counters of packets that > pass > the observation point in different directions. > >> Advantages of solution 1: >> - The concept is clean: no prefix for actually measured traffic >> prefixes for flow properties that are obtained by other means. >> - We need prefixes only if middleboxes are involved and supported >> by the metering process. We do not need prefixes in all other >> cases, particularly not for for simple bidirectional measurements >> or for unidirectional measurements of outgoing traffic. >> >> >> This is a big drawback. >> If I have a router forwarding traffic, I export a template with >> no-prefix. >> My monitoring application is happy. >> Now, the operational team decides to add some DSCP re-marking >> capabilities >> in the router. Now my templates export the "pre" I.E. for the same >> information. > > > No. Before and after only packets observed at the observation point are > reported independent of the presence of a middlebox. However, if the > metering > process has the appropriate capability, it can also report from beyond > the > middlebox using "pre" or "post" depending on the traffic direction. [drawback]. Whatever the direction, whatever the pre or post, my point and the drawback I see are that the template will change: - when I insert/remove a middlebox function - if I don't want to duplicate the information. > >> Not sure my monitoring application will be happy. >> Basically, depending on the (middlebox) features enabled on the router, >> I will export different I.E.s. This solution doesn't work. > > > This problem only exists for solution 2. > I thin we can eliminate this one from further discussion. > >> Disadvantages of solution 2: >> >> >> Typo -> Disadvantages of solution 1: > > > Thanks. > >> - We need two prefixes >> >> >> Basically we need "pre", "post" and no prefix. So we have 3 series of >> I.E.s > > > Yes. This is a major drawback according to me. > >> - We might end up with a higher total number of elements >> >> >> - Another disadvantage. The choice of these pre, post, no prefix >> series of I.E.s >> depend so much on the architecture of the device and that you will have >> interoperability problem first of all, and the collector will have to >> know >> the architecture of the exporter in order to benefit from the >> exported I.E.s > > > Well, you mainly will have to precisely identify your observation point. ... according to the architecture of the box. Let me repeat what I wrote: collector will have to know the architecture of the exporter in order to benefit from the exported I.E.s Again, this is a major drawback. I'm afraid that with solution 2, we try to build the perfect solution by specifying the observation point, the direction, the pre/post/no_prefix, so - the counters when entering the first the line card, - the counters when leaving the first line card without middlebox, - the counters when leaving the first line card with middlebox, - the counters when entering the second line card, - the counters when leaving the second line card without middlebox - the counters when leaving the second line card with middlebox This is done at the expense of an overloaded information model What we mainly need is something similar to NetFlow: - the counters when entering the first the line card, (no prefix) - potentially the counters when leaving the second line card (post prefix, direction = egress) AND if the router is not composed of line card, i.e. a single observation domain: - the counters when entering the observation point, (no prefix) - potentially the counters after packet treatment (post prefix, direction = egress) > Then there is no more dependency on the architecture. > >> The [IPFIX-INFO] draft has always been (almost) in line with solution 3 >> until the recent addition in the version 8. > > > I think the same holds for solution 1. Just the parts to which the > "(almost)" > refers are different. Note quite. The "pre" prefix was never introduced before. Regards, Benoit. > > Cheers, > > Juergen > >> Regards, Benoit. >> >> >> >> Thanks, >> >> Juergen >> >> >> > > --------------050802070805010106090909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Juergen,

See more in line.

Hi Benoit,

Thanks for the detailed reply.
Please find comments in line.

--On 7/20/2005 2:01 PM +0200 Benoit Claise wrote:

Juergen and all,

Thanks for the detailed email. It will ease the discussion.

You see this pre and post prefix problem from the point of view of the
observation point only.
This is fine because we have in RFC 3917:

"All measurements must be conducted from the point of view of the
observation point."
Btw, I think that this statement should appear in [IPFIX-ARCH]. I took me
quite some time to locate this sentence as I thought it was in one of
current draft already.
However, I see the problem differently: before and after the packet
treatment at the observation point.

I think here is already the point where we are not in sync.
I do not expect the packet treatment to necessarily happen at the
observation point only.

I agree we are not in sync. ;)
You wrote "I do not expect ...". This is the issue: you expect what the observation point will be ... and from there, you try to deduce the correct behavior for pre and post.
From the observation point definition, we see that we can't assume anything about the observation.

   An Observation Point is a location in the network where IP packets 
   can be observed.  Examples include: a line to which a probe is 
   attached, a shared medium, such as an Ethernet-based LAN, a single 
   port of a router, or a set of interfaces (physical or logical) of a 
   router.

Let's take the multicast daemon as an example that is already supported by
NetFlow version 9. If you locate your observation point (or observation
domain) at a routers line card, then the multicast daemon running on the
core processor of your router is not in the observation domain. However,
it would still be nice to report the number of multicast packets and octets
after packet treatment by the multicast daemon.

Again you assume things: in this case that the multicast daemon running on the core processor.
If you take into account "All measurements must be conducted from the point of view of the observation point.", then it's the observation point will report what he thinks he's right after packet treatment (this is solution 3 below). BTW, there is nothing more we can do from the observation point of view.

I will show that this view exclude the solution 1, leads to the natural
selection of slightly modified solution 2, i.e. solution 3

Remember the flow definition, in which the packet treatment is clearly mentioned:

      A Flow is defined as a set of IP packets passing an Observation
      Point in the network during a certain time interval. All packets
      belonging to a particular Flow have a set of common properties.
      Each property is defined as the result of applying a function to
      the values of:

      1. One or more packet header field (e.g. destination IP address),
          transport header field (e.g. destination port number), or
          application header field (e.g. RTP header fields RTP-HDRF
          [5].

      2. One or more characteristics of the packet itself (e.g. number
          of MPLS labels)

      3. One or more fields derived from packet treatment (e.g. next
          hop IP address, output interface)
I see the "packet treatment" as the typical function of a middlebox.

Agreed.

The definition could have been extended with for example the modified DSCP value.

So let me propose the solution 3 (let me refer to "solution 3" later on in
this email):
all flow properties that are exported represent the flow as it was
when entering the IPFIX device except, if their name has the
prefix "post". Information elements without the prefix would
describe flows characteristics of incoming packets and information
elements with the "post" prefix would describe flows characteristics
after packet treatment.

If I understand correctly, then solution 2 maps with/without prefix to
incoming and outgoing with respect to the IPFIX device while solution 3
maps with/without prefix to incoming and outgoing packets with respect
to the observation domain. Right?

No. Let me rephrase this.
all flow properties that are exported represent the flow as it was
when entering the observation point except, if their name has the
prefix "post". Information elements without the prefix would
describe flows characteristics of incoming packets and information
elements with the "post" prefix would describe flows characteristics
after packet treatment, from an observation point of view.

See inline.

    Dear all,

    Here is the problem description for the "pre" and "post" prefixes
    that I promised last weekend.

    I am sorry for the delay in sending this. It is caused by my
    inability to explain the issue briefly. Please excuse that this
    inability also is the reason why you have to read an awfully long
    message in order to help solving the problem.


    Let me start with a short introduction to the problem we have with
    middleboxes and other boxes that change flow properties:

    Some middleboxes change properties of a flow. For example, a DiffServ
    marker changes the value of the IPv4 TOS field, a network address
    translator changes source or destination IP addresses, and a traffic
    shaper changes the number of packets and bytes of a flow.

    Consequently, on one side of a middlebox a traffic flow might have
    properties that are different to its properties on the other side
    of the middlebox.

    Now, if an observation point stretches so far that it includes both
    sides of the middlebox, we run into ambiguities. In such a case,
    there are two different values for packet count, byte count, DSCP,
    source IP address, etc. to be observed at the observation point.
    Which values should we export in such a situation?

    We discussed this issue at our meeting in Seoul where Martin gave
    a presentation that you can find in the proceedings:
    <http://www.ietf.org/proceedings/04mar/slides/ipfix-3/index.html> <http://www.ietf.org/proceedings/04mar/slides/ipfix-3/index.html>
    Also a draft discussing it is available in the archive:
    <http://www.watersprings.org/pub/id/draft-quittek-ipfix-middlebox-00.txt> <http://www.watersprings.org/pub/id/draft-quittek-ipfix-middlebox-00.txt>

    I see two solutions for this problem and the discussion we need to
    have is about selecting one of them or another solution suggested by
    someone else.


    Solution 1
     The recommendation that was made at the meeting and in the (already
     expired) draft was to avoid these ambiguities by avoiding to have an
     observation point that includes both sides of a middlebox.


There is no ambiguities if you apply solution 3:

     This solves the ambiguity problem. If it is clearly specified on which
     side of a middlebox we have our observation point, then we know which
     observed values to export.

     However, sometimes it might be very useful to ALSO export values from
     the other side of the middlebox. These would be values that were not
     necessarily derived from direct observation of packets, but by other
     means available at the IPFIX device.


I would say that it's not only useful, but it's a requirement.
If you don't allow to export after treatment I.E., you run into problems such as:
- exporting two records, from the ingress point and the egress observation points
of your middlebox

If I have one metering process running on the ingress line card metering incoming
traffic and another independent one on the egress line card metering outgoing traffic,
then I would expect receiving two records for the same flow.

In this case, you're right!
I was thinking of a simple router without line cards (so a single observation domain). In this case, if we don't want to export to flow records, we must export after packet treatment.

- trying to combine the records, to match the initial flow. You're going to tell
me that we could use the flow keys, but we don't always want to export the flow keys.
Alternatively, we could use a flow ID, but this becomes way too complex.

     Let's take a multicast daemon as an the example. A multicast daemon
     is not necessarily a middlebox, but it causes the same problem.
     The daemon might be able to provide statistics on how many packets
     it sent out for a certain multicast address.

     If now our observation domain is restricted to the incoming traffic
     at a single network interface at the IPFIX device, then we will
     observe only the incoming multicast flow. Still, it would be nice
     to report for this flow the number of outgoing multicast packets
     and octets.

     NetFlow version 9 supports this by fields MUL_DST_PKTS
     and MUL_DST_BYTES. In the IPFIX info model they are called
     postMCastPacketDeltaCount and postMCastOctetDeltaCount.

     Note these objects report something that can not (necessarily)
     be observed at the flow's observation point. The info model
     elements have the prefix 'post' in order to indicate the fact
     that these values do not necessarily result from an actual
     observation. In this case they result from the reporting of
     the multicast daemon.


If you apply solution 3, it's up to the metering process at the observation
point to evaluate whether or not he can report any "post" information.
All routers/switches/middlebox will have a different architecture (one metering
process per interface, per combination of interfaces, per line card, per router,
etc...) so the only solution is to trust the metering process based on its
capabilities. Is the metering process able to report some after packet treatment info?

One of the advantages of solution 1 is that what the metering process observes
directly is always without prefix, may it be incoming, outgoing, before or after
packet treatment. If the metering process does not know about any (potentially
present) middleboxes then it always reports correctly if it reports what it sees
without prefix. However, if it is aware of a middlebox, it may report how packets
look like on the other side by using the "pre" or "post" prefix.

As I wrote below, this is not an advantage but a drawback [drawback]

     As second example we can look at a DiffServ packet marker. It
     changes the DSCP value of packets. Following the approach of
     solution 1, the location of the observation point should be
     clearly specified to be at one or the other side of the marker.
     There it observes the DSCP value that is reported by information
     element classOfServiceIPv4 or classOfServiceIPv6.

     Also here, scenarios can easily be found for which it is desirable
     to report also the DSCP value that the flow has on the other side
     of the marker, that is not covered by the observation point.
     This is supported by NetFlow version 9 with the DST_TOS field and
     in our information model by the elements postClassOfServiceIPv4
     and postClassOfServiceIPv6. As you see from the prefix of their
     name, we can only use them if the observation point is located
     on the path of the packet before it passes the marker. If the
     observation point would be located somewhere on the path after
     the marker, we would need a different prefix for reporting from
     the other side.

Not really. Remember "All measurements must be conducted from the point of
view of the observation point."
So the observation point is not supposed to know that there is a previous
observation point in the path.
From the observation point point of view, it must report what is seen.
Hence no "pre" prefixes are needed.

I think treating "pre" and "post" as symmetric prefixes is a feasible approach.

Next question: is there any packet treatment at this observation point?

For solution 1 there is NEVER packet treatment AT an observation point.
The observation point is a single 'point' in the network where packets
pass by. Particularly, it does not include a middlebox function.

Remember the multiple examples of the observation point...

If no, we don't export any "post" prefix I.E. If yes, and if we can
report the values, we export some "post" prefix I.E.

Repeating the example I used somewhere above:
Let's assume that our observation domain (that is reported in the IPFIX
message header) is a single line card.

Now we want to report MUL_DST_PKTS / postMCastPacketDeltaCount:

- If we apply solution 2 or 3 strictly, then we cannot report
them if the multicast daemon is not running on the line card.

Right.

- But let's assume we can make this information available by
   exchanging information with the multicast daemon.
   Which observation domain would we report?
   Just report the line card this would conflict with solutions 2 and 3.
   But reporting the line card and the core processor would also wrong,
   because we do not observe all packets passing the core (or at least
   the multicast daemon. We just report packets that originate at the
   observed line card AND pass the multicast daemon.

I personally think that you make the situation more complicated than it's really is by always referring to the multicast example.
The logic in your example would tell us to use the observation domain as being the incoming line card.

    The current version of the info model suggests
     prefix "pre" for this case, for example, "preClassOfServiceIPv4".
     We do not have any instance of an information element with prefix
     "pre" in the current version of our model, because common practice
     is measuring at the incoming interface of a router.


The solution 3 would also apply if you would monitor traffic at different
points in the forwarding path of your device.

    Still, we
     would need to add them at some time in the future if we follow
     solution one. Please not that also for the 'post' prefix only a
     few instances are present. We clearly expect to need more "post"
     elements if we start having IPFIX implementations on network
     address translators (postsourceIPv4Address, postTransportPort,
     etc.).


    Solution 2
     The other way of solving the ambiguities is declaring that all
     flow properties that are exported represent the flow as it was
     when entering the IPFIX device except, if their name has the
     prefix "post". Information elements without the prefix would
     describe flows of incoming packets and elements with that
     prefix would describe flows of outgoing packets.


Note that, in solution 3, I changed outgoing packets by "after packet treatment"

     In case of the multicast daemon, the packetDeltaCount would be
     the number of incoming packets and the postMCastPacketDeltaCount
     would be the number of outgoing multicast packets.


Yes.

     For the packet marker, classOfServiceIPv4 would deliver the value
     of the DSCP before marking and preClassOfServiceIPv4 would deliver
     the value after marking.


Typo -> postClassOfServiceIPv4

Thanks.

     This solution allows a more relaxed specification of the
     observation point. It may be the entire device.

Exactly, this is a great advantage.

    Ambiguities
     are avoided for this case, because every element is marked to
     concern either incoming or outgoing traffic.


    Discussion
     {Please note that I am biases and have a preference for solution 1.
      Please contribute arguments for solution 2 or against solution 1
      that are missing in the lists below because I am too ignorant to
      see them.}


Advantage of "solution 3"
- the concept is simpler
- we only need one prefix

As solution 2 and 3 are almost similar, let me reply to the
"disadvantage of solution 2" section

     Advantages of solution 2:
     - the concept is simpler.
     - We only need one prefix.

     Disadvantages of solution 2:
     - The concept is simple but not always clear.
       What about traffic observed at a network interface card in
       promiscuous mode. This traffic would be neither incoming nor
       outgoing.


I don't see a problem, neither with solution 2 or solution 3.
The NIC is the observation point, and

The problem is with solution 2, not with 3.

I don't see a problem with solution 2 regarding this issue.

   "All measurements must be conducted from the point of view of the
   observation point."
So the traffic which is entering the observation point is considered as as incoming.
With solution 3, there is no packet treatment, so no "post" I.E.s are exported.
With solution 2, there is no outgoing packets, so no "post" I.E.s are exported.

     - A generic flow meter using libpcap typically observes incoming
       traffic as well as outgoing traffic. This meter would need to
       check for all packets if they are incoming or outgoing (probably
       by checking the MAC addresses) and use elements without prefix
       for reporting the incoming packets and elements with "post"
       prefix for reporting the outgoing traffic.


Is this a drawback? All the traffic entering the observation point is metered.
" The observation point is a location in the network where IP packets can be observed."
I don't consider this as a drawback for solution 2 and 3

     - We must define an information element with a "post" prefix for
       almost all the non-post elements in sections
         - 5.3 IP Header Fields (31 elements)
         - 5.4 Transport Header Fields (16 elements),
         - 5.5 Sub-IP Header Fields (19 elements)
         - 5.7 Min/Max Flow Properties (11 elements)
         - 5.9 Per-Flow Counters (12 elements)
       currently, only 13 of them are defined.


Yes, this is true for solution 2 and solution 3.
What we agreed in the past is that people will request those as they need them.

     - We cannot report bidirectional flows anymore, if our observation
       point does not cover all interfaces. If we measure at a single
       interface, then we cannot aggregate the packet and octet counters
       of a bi-directional flow, because for one direction we must use
       the non-prefix counter and for the other direction we must use
       the prefix counter.


True for solution 2 and solution 3 but I don't see how it's possible with the solution 1

with solution 1, the observation point is a single point not including any
packet treatment.

What about the different examples of an observation point? Ex: line card, router?

All packets that are directly observed there are reported
without prefix. Hence you can aggregate the counters of packets that pass
the observation point in different directions.

     Advantages of solution 1:
     - The concept is clean: no prefix for actually measured traffic
       prefixes for flow properties that are obtained by other means.
     - We need prefixes only if middleboxes are involved and supported
       by the metering process. We do not need prefixes in all other
       cases, particularly not for for simple bidirectional measurements
       or for unidirectional measurements of outgoing traffic.


This is a big drawback.
If I have a router forwarding traffic, I export a template with no-prefix.
My monitoring application is happy.
Now, the operational team decides to add some DSCP re-marking capabilities
in the router. Now my templates export the "pre" I.E. for the same information.

No. Before and after only packets observed at the observation point are
reported independent of the presence of a middlebox. However, if the metering
process has the appropriate capability, it can also report from beyond the
middlebox using "pre" or "post" depending on the traffic direction.

[drawback]. Whatever the direction, whatever the pre or post, my point and the drawback I see are that the template will change:
- when I insert/remove a middlebox function
- if I don't want to duplicate the information.

Not sure my monitoring application will be happy.
Basically, depending on the (middlebox) features enabled on the router,
I will export different I.E.s. This solution doesn't work.

This problem only exists for solution 2.
I thin we can eliminate this one from further discussion.

     Disadvantages of solution 2:


Typo -> Disadvantages of solution 1:

Thanks.

     - We need two prefixes


Basically we need "pre", "post" and no prefix. So we have 3 series of I.E.s

Yes.

This is a major drawback according to me.

- We might end up with a higher total number of elements

- Another disadvantage. The choice of these pre, post, no prefix series of I.E.s
depend so much on the architecture of the device and that you will have
interoperability problem first of all, and the collector will have to know
the architecture of the exporter in order to benefit from the exported I.E.s

Well, you mainly will have to precisely identify your observation point.

... according to the architecture of the box.
Let me repeat what I wrote: collector will have to know the architecture of the exporter in order to benefit from the exported I.E.s
Again, this is a major drawback.

I'm afraid that with solution 2, we try to build the perfect solution by specifying the observation point, the direction, the pre/post/no_prefix, so
- the counters when entering the first the line card,
- the counters when leaving the first line card without middlebox,
- the counters when leaving the first line card with middlebox,
- the counters when entering the second line card,
- the counters when leaving the second line card without middlebox
- the counters when leaving the second line card with middlebox
This is done at the expense of an overloaded information model

What we mainly need is something similar to NetFlow:
- the counters when entering the first the line card, (no prefix)
- potentially the counters when leaving the second line card (post prefix, direction = egress)
AND if the router is not composed of line card, i.e. a single observation domain:
- the counters when entering the observation point, (no prefix)
- potentially the counters after packet treatment (post prefix, direction = egress)

Then there is no more dependency on the architecture.

The [IPFIX-INFO] draft has always been (almost) in line with solution 3
until the recent addition in the version 8.

I think the same holds for solution 1. Just the parts to which the "(almost)"
refers are different.

Note quite. The "pre" prefix was never introduced before.

Regards, Benoit.

Cheers,

Juergen

Regards, Benoit.

    Thanks,

       Juergen

--------------050802070805010106090909-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Jul 25 12:29:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx5pt-0002WM-C1 for ipfix-archive@megatron.ietf.org; Mon, 25 Jul 2005 12:29:50 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04981 for ; Mon, 25 Jul 2005 12:29:46 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dx5jw-00050E-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Jul 2005 11:23:40 -0500 Received: from cweg03.cweg.stud.uni-goettingen.de ([134.76.63.99] helo=mail.anderson.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Dx5jv-000509-00 for ipfix-info@net.doit.wisc.edu; Mon, 25 Jul 2005 11:23:39 -0500 Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180]) by mail.anderson.de with asmtp (Exim 4.20) id 1Dx5jq-0005yy-Sq; Mon, 25 Jul 2005 18:23:34 +0200 Message-ID: <42E51205.7040201@CS.Uni-Goettingen.DE> Date: Mon, 25 Jul 2005 18:23:33 +0200 From: Sven Anderson Organization: Institute for Informatics Goettingen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , Nevil Brownlee , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" References: <45153F8B40ECB0CCCA744072@[192.168.0.112]> In-Reply-To: <45153F8B40ECB0CCCA744072@[192.168.0.112]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello everybody, Juergen Quittek schrieb: >> However, I see the problem differently: before and after the packet >> treatment at the observation point. > > I think here is already the point where we are not in sync. I do not > expect the packet treatment to necessarily happen at the observation > point only. here's my point of view: To be honest, both solutions don't look very clean to me. ;-) It starts with the definition of Observation Points: "Note [...] that one Observation Point may be a superset of several other Observation Points". This implicates that _every_ field is always ambiguous, because it could be different at each of the atomic Observation Points. It won't help to split them up in post and pre Fields, as there could be even more than two states for the same Field. It would be cleaner, if every Field is bound to exactly one atomic Observation Point, or better to exactly one packet state. That is even true for the counter Fields, think of packet fragmentation for instance. Then, what you obviously want, is the possibility to define Flows with properties, that derive from the same packet but at _different_ atomic Observation Points (e.g. before and after the NAT process), or more general, at different states of the packets. To archieve this, the Metering Process has to track the packets in his Observation Domain. Example: In our network we have an VPN relay, which is a node that reencapsulates packets from e.g. OpenVPN to CIPE and vice versa. On this node it would be interesting to define a flow by: src/dst ip addresses at incoming interface, src/dst ip addresses and ports of the encapsulated ip header, src/dst ip address at outgoing interface. The flow should report the size of the packet at the incoming AND outgoing interface. Incoming and outgoing interface is here the same physical interface (eth0) over which the packet is traveling twice at different states. Of course, it leads to the philosophical question, after how much treatment a packet is still the same packet. But anyway, then I call these packets, which derive from each other, linked packets, and I want to define Flows by properties of these linked packets. An easy way to allow this, would be to allow that the same Field can appear more then one time in a Template (is this forbidden right now, by the way?). But this is ugly, as you cannot see, which Field belongs to which packet state. So I would suppose a solution, where you can group the Fields somehow, for example that a basic Template can hold each Field only once, but you can define combined Templates, which consist of a list of basic Templates. That way you have a flexible way to report Flows that span over several (not only two, like the pre/post approach!) packet states, and that's all this pre/post discussion is about, right? Then you also don't need in and out counter or ingress/egress interface IEs. Just one IE is enough, and if the Field is in the first or last Template of the combined Template tells you, if it represents the incoming or outgoing packet state respectively. So I would vote for a more flexible and cleaner solution, without any pre/post prefixes. Sorry that I come up with this so late, as it sounds like a bigger change, but I read this list as recently as I started a Ph.D. project about IPv6 monitoring 3 months ago. BTW.: In IPFIX-ARCH at 6.2 you find: "A Flow Record can be better analyzed if the Observation Point from which it was measured is known. As such it is recommended that IPFIX Devices send this information to Collectors." Is there an IE to report this, or how should it work? As not the Observation Points but only the Observation Domains have an unique ID. Cheers, Sven -- Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From HaskinsMarg_6447@kaufmanchaiken.com Mon Jul 25 14:30:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx7iM-0002Xe-Il for ipfix-archive@megatron.ietf.org; Mon, 25 Jul 2005 14:30:10 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12751 for ; Mon, 25 Jul 2005 14:30:07 -0400 (EDT) Received: from [201.129.230.69] (helo=kaufmanchaiken.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dx7cJ-0000Gw-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Jul 2005 13:23:55 -0500 From: "Marged Haskins" To: "Ellen Winstead" Subject: =?iso-8859-1?Q?CI=C1LIS_VALL=ECUM_ViAGRR=C1?= Date: Mon, 25 Jul 2005 13:23:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01C59146.00F93F00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?201.129.230.69 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C59146.00F93F00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, awoke in him. Fiercely now he lashed those defenceless shoulders,things in = the consumption of which they had interrupted the Spaniards.and he was = forced to admit that jointly they could undertakeSure, now, that's = entirely a matter of the point of view, saidwith such a tale - to tell = me that ye know where the ransom's to berecords is in itself eloquent. = We know that they were made fast asboats are being launched. You are at = liberty to embark in themto observe. Some moments ago Ogle, followed by = the main body ofThe Captain steadied himself to grasp it.position whence = they could send a warning shot across her bow.matters, Colonel - if not = perhaps in others - and ye said, I think,when he was told of it. But = happened it had, and he was forced tohis near escape of the yardarm and = the running noose.CHAPTER XXVThe recumbent man looked up bewildered into = a pair of light-blueSo? said van der Kuylen. But vhy should dad dedam = you? ------=_NextPart_000_0058_01C59146.00F93F00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to MegaPPharm Online = Shop.

		rugs order		ine can		EY!
Prescription D	ed Onl	SAVE YOU MON

In some cases you can sa		% on the		n medica
ve up to 80	cost of your prescriptio	tion.

Thousands of our customers already enjoy these = savings.

We deIiver direct to your door through fast, = Low-C0ST, reliable and secure service on the Internet.

CIick = Herre for PRlCES.

Have a nice day.

------=_NextPart_000_0058_01C59146.00F93F00-- From majordomo@mil.doit.wisc.edu Tue Jul 26 04:46:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxL50-0007mD-Tf for ipfix-archive@megatron.ietf.org; Tue, 26 Jul 2005 04:46:27 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28898 for ; Tue, 26 Jul 2005 04:46:24 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DxKrW-0005nn-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Jul 2005 03:32:30 -0500 Received: from cweg03.cweg.stud.uni-goettingen.de ([134.76.63.99] helo=mail.anderson.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DxKrV-0005n6-00 for ipfix-info@net.doit.wisc.edu; Tue, 26 Jul 2005 03:32:29 -0500 Received: from gate-mh.sernet.de ([193.159.216.158] helo=[192.168.42.180]) by mail.anderson.de with asmtp (Exim 4.20) id 1DxKrU-00007d-4B for ipfix-info@net.doit.wisc.edu; Tue, 26 Jul 2005 10:32:28 +0200 Message-ID: <42E5F51A.5080005@CS.Uni-Goettingen.DE> Date: Tue, 26 Jul 2005 10:32:26 +0200 From: Sven Anderson Organization: Institute for Informatics Goettingen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow" References: <45153F8B40ECB0CCCA744072@[192.168.0.112]> <42E5051F.5080901@cisco.com> In-Reply-To: <42E5051F.5080901@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, Benoit Claise schrieb: > If you take into account "All measurements must be conducted from the > point of view of the observation point.", then it's the observation > point will report what he thinks he's right after packet treatment (this ^^^^^^ > is solution 3 below). BTW, there is nothing more we can do from the > observation point of view. I don't understand why you write "thinks". Either the treatment happens _inside_ of an observation "point" (a strange terminology in this case, as a point has no dimension, but as you allow a point to be a group of points, it's possible), then it _knows_ what the packet looks like after, or it happens after the observation point, then pre and post is the same, whatever happens after. > No. Let me rephrase this. > all flow properties that are exported represent the flow as it was > when entering the _observation point_ except, if their name has the > prefix "post". Information elements without the prefix would > describe flows characteristics of incoming packets and information > elements with the "post" prefix would describe flows characteristics > after packet treatment, _from an observation point of view_. Ok, maybe now I get it, you are referring to the borders of the device? So _if_ there is a post field, then the non-post/post field refers to how the observation point guesses the packet looked like when entering/leaving the device, and the real observed data is not necessarily reported? Do you mean that? Then the semantics of a field depends on the existence of another field... I'm not sure if I like that... ;-) Cheers, Sven -- Sven Anderson Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de Georg-August-Universitaet Goettingen Lotzestr. 16-18, 37083 Goettingen, Germany -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jul 26 05:14:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLWL-0005z2-W0 for ipfix-archive@megatron.ietf.org; Tue, 26 Jul 2005 05:14:42 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00545 for ; Tue, 26 Jul 2005 05:14:39 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DxLRT-0006nA-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Jul 2005 04:09:39 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DxLRS-0006n5-00 for ipfix@net.doit.wisc.edu; Tue, 26 Jul 2005 04:09:38 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 85E70DC08; Tue, 26 Jul 2005 11:09:37 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipfix] dateTimeNanoSeconds Date: Tue, 26 Jul 2005 11:09:36 +0200 Content-Type: multipart/signed; boundary="----=_NextPart_000_0014_01C591D2.8236DB40"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <88F766D04E6AF3409B39E60D7D933EB24FC938@europa.office> X-MS-Has-Attach: yes Thread-Topic: [ipfix] dateTimeNanoSeconds Thread-Index: AcWJPXiY7fS+0Jn7SzWVjqkDlU9vLAIgziJQ From: "Thomas Dietz" To: =?iso-8859-1?Q?Jon_K=E5re_Hellan?= Cc: Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C591D2.8236DB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Jon, I see your point. The data type of dateTimeNanoSecond should represent = the date/time in the unit of nanoseconds. So the word "precision" is not the right term anyway. (BTW. This should be changed in all the other = dateTime... data types, too) The data type cannot give the precision because the precision depends on the device. The representation of the value in NTP format has the problem that it just gives the fractional part of a = second and can only represent steps of about 233 picoseconds. The conclusion is that we need to rephrase the dateTimeNanoSeconds part = and will come up with a new version within the next few days. Best Regards, Thomas --=20 Thomas Dietz E-mail: Thomas.Dietz@netlab.nec.de Network Laboratories Phone: +49 6221 90511-28 NEC Europe Ltd. Fax: +49 6221 90511-55 Kurfuersten-Anlage 36 69115 Heidelberg, Germany http://www.netlab.nec.de =20 > -----Original Message----- > From: majordomo listserver=20 > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Jon K=E5re Hellan > Sent: Friday, July 15, 2005 2:49 PM > To: ipfix@net.doit.wisc.edu > Subject: [ipfix] dateTimeNanoSeconds >=20 > Hi >=20 > Here's how the draft protocol specification defines > dateTimeNanoSeconds: >=20 > > 6.1.8 dateTimeNanoSeconds=20 > > =20 > > The data type of dateTimeNanoSeconds represents a time=20 > value having=20 > > a precision of nanoseconds and normalized to the GMT=20 > timezone. It=20 > > is encoded in a 64-bit integer according to the NTP=20 > format given in=20 > > [RFC1305]. The high-order 32-bits represent the number=20 > of seconds=20 > > 1900 and the low-order 32-bits represent the fractional=20 > seconds with=20 > > the fraction ranging from 0 - 2^(32-1) / 2^32. This=20 > gives a maximum=20 > > precision of about 200 picoseconds.=20 >=20 > Two problems here: >=20 > 1. Both the first and the last sentence appear to define the=20 > precision, > inconsistently. Changing the the first sentence to read "a=20 > precision in > the order of nanoseconds" would fix this. >=20 > 2. The range of the fraction given is approximately 0 - 0.5 > seconds. The intention is probably (0 - (2^32) - 1) / 2^32. >=20 > Regards >=20 > Jon K=E5re Hellan, UNINETT >=20 > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help"=20 > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ >=20 ------=_NextPart_000_0014_01C591D2.8236DB40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJGjCCA8Uw ggMuoAMCAQICEF8x7NoPUxKyR3Pwm4URBVEwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJ ARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNV BAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wNDA2MzAw OTMxNDFaFw0wNjA2MzAwOTQwMDNaMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5l Yy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4x CzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKP4 YxqYa9dIECafjm3xdd6xiE4/0+qrXKhKWhgTZ0sAEV3dDsBJa+FU79wvAnqBfm/4PoGB/gaVbAi/ LhcHupDCivn9o+0KkKpqiAuS6B3n2ocw1Hjc7leethO6oTYWGkObA7HYdlkRzxs8aXPmAsiEX2VU kjRSwnXfi2ht5ItBAgMBAAGjggFUMIIBUDATBgkrBgEEAYI3FAIEBh4EAEMAQTALBgNVHQ8EBAMC AYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUUtmuJmrerNKKTKiUV2rjc+fa1JcwgecGA1Ud HwSB3zCB3DCBqqCBp6CBpIaBoWxkYXA6Ly8vQ049TkVDKDEpLENOPXNvbCxDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1vZmZp Y2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdGNsYXNzPWNSTERpc3RyaWJ1 dGlvblBvaW50MC2gK6AphidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQygxKS5jcmww EgYJKwYBBAGCNxUBBAUCAwEAATANBgkqhkiG9w0BAQUFAAOBgQChfPeuQ/VSeGerBIn42+NhaXfG reGjAW0ZRRnEG7YKQbVfMaIzuypc72+wsfkVdulX8g6MkLL5E7haj/1WY+6yAPQbj6jhvuitjkXm 71HyHU8Lb+3e2Co9xt/J8qeb2Y1VEfvyihpDcX9rQ/OYuXXIK2TA9Ongl8bsBNyctnLeODCCBU0w ggS2oAMCAQICCiRl7KQAAQAAARwwDQYJKoZIhvcNAQEFBQAwdTEkMCIGCSqGSIb3DQEJARYVY29y ZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTELMAkGA1UEBxMCSEQxGDAWBgNVBAoTD05F QyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNVBAMTA05FQzAeFw0wNTAyMTQxMDAwNTFa Fw0wNjAyMTQxMDAwNTFaMGMxFjAUBgoJkiaJk/IsZAEZFgZvZmZpY2UxDjAMBgNVBAMTBVVzZXJz MQ4wDAYDVQQDEwVEaWV0ejEpMCcGCSqGSIb3DQEJARYaVGhvbWFzLkRpZXR6QG5ldGxhYi5uZWMu ZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANg8CTLAGigw+HgIFokohiMGo8K3Eeeb1whg HTrSh8Xlyfay3mamZn9T1VRGtCGbooYXqOwjVeNg88TTMyT4JPZCGKi87vxgjRDOg6bq8LmRZcM5 ZXQxddIrlMXs8f7Q5eMA2MUhrCsYWlodCGpWyU1Dun2rKIsvq8UJ2p6x6lQ3AgMBAAGjggL0MIIC 8DALBgNVHQ8EBAMCBaAwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcN AwQCAgCAMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBT7FX0nNde2F0WNdDohyBNsyp/Q 9jAXBgkrBgEEAYI3FAIECh4IAFUAcwBlAHIwHwYDVR0jBBgwFoAUUtmuJmrerNKKTKiUV2rjc+fa 1JcwgeEGA1UdHwSB2TCB1jCB06CB0KCBzYaBoWxkYXA6Ly8vQ049TkVDKDEpLENOPXNvbCxDTj1D RFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlv bixEQz1vZmZpY2U/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNS TERpc3RyaWJ1dGlvblBvaW50hidodHRwOi8vc29sLm9mZmljZS9DZXJ0RW5yb2xsL05FQygxKS5j cmwwge0GCCsGAQUFBwEBBIHgMIHdMIGaBggrBgEFBQcwAoaBjWxkYXA6Ly8vQ049TkVDLENOPUFJ QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPW9mZmljZT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTA+BggrBgEFBQcwAoYyaHR0cDovL3NvbC5vZmZpY2UvQ2VydEVucm9sbC9zb2wub2Zm aWNlX05FQygxKS5jcnQwKQYDVR0lBCIwIAYKKwYBBAGCNwoDBAYIKwYBBQUHAwQGCCsGAQUFBwMC MEMGA1UdEQQ8MDqgHAYKKwYBBAGCNxQCA6AODAxkaWV0ekBvZmZpY2WBGlRob21hcy5EaWV0ekBu ZXRsYWIubmVjLmRlMA0GCSqGSIb3DQEBBQUAA4GBACt8XGDQ4kPlY2NT2jHjCqmo3eYBeZEPOwR1 k0t3aT8lkH0eAMZnLE5ix0GrBDuJp5nnjuigzXqPIqf9SWSbSTXgWz8d5jNsg4c307cKIHilyWYl ydaOy9p2hdqZ28pHrHjiAMKSe4Ds/dUVOrhc7MhSdlxJBnXNYXojX7HShdlnMYIDJDCCAyACAQEw gYMwdTEkMCIGCSqGSIb3DQEJARYVY29yZWFkbUBuZXRsYWIubmVjLmRlMQswCQYDVQQGEwJERTEL MAkGA1UEBxMCSEQxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjELMAkGA1UECxMCSEQxDDAKBgNV BAMTA05FQwIKJGXspAABAAABHDAJBgUrDgMCGgUAoIIB9jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNTA3MjYwOTA5MzZaMCMGCSqGSIb3DQEJBDEWBBSGFoyKCcwk l3XHecREwMQ/HaynNTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlAYJKwYBBAGCNxAEMYGGMIGDMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFi Lm5lYy5kZTELMAkGA1UEBhMCREUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0 ZC4xCzAJBgNVBAsTAkhEMQwwCgYDVQQDEwNORUMCCiRl7KQAAQAAARwwgZYGCyqGSIb3DQEJEAIL MYGGoIGDMHUxJDAiBgkqhkiG9w0BCQEWFWNvcmVhZG1AbmV0bGFiLm5lYy5kZTELMAkGA1UEBhMC REUxCzAJBgNVBAcTAkhEMRgwFgYDVQQKEw9ORUMgRXVyb3BlIEx0ZC4xCzAJBgNVBAsTAkhEMQww CgYDVQQDEwNORUMCCiRl7KQAAQAAARwwDQYJKoZIhvcNAQEBBQAEgYAVv6QuKf/c1KxG7RB/YB3w GcRyjvwO+8DK7Gu0yDtmgGDbmdrl0sHoYOnfs0O5NNStyS+GcjDKXfDDPRlDmJBirFfJmkZsDp9k 1YHwE5nFajs3kh+A5pIWn+R/cZYsLhxFUOhxMj1lfxNsn6uB6XMT6CxsDl1NBbRKWv88aypbngAA AAAAAA== ------=_NextPart_000_0014_01C591D2.8236DB40-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jul 26 05:37:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLsi-0002J2-6l for ipfix-archive@megatron.ietf.org; Tue, 26 Jul 2005 05:37:48 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01912 for ; Tue, 26 Jul 2005 05:37:45 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DxLnR-0007IP-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Jul 2005 04:32:21 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DxLnQ-0007IK-00 for ipfix@net.doit.wisc.edu; Tue, 26 Jul 2005 04:32:20 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 80FA715133; Tue, 26 Jul 2005 11:32:18 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jul 2005 11:32:18 +0200 Date: Tue, 26 Jul 2005 11:32:28 +0200 From: Juergen Quittek To: =?ISO-8859-1?Q?Jon_K=E5re_Hellan?= Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] dateTimeNanoSeconds Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-OriginalArrivalTime: 26 Jul 2005 09:32:18.0455 (UTC) FILETIME=[EA8B6A70:01C591C4] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Jon, Thanks for this hint. I think we need some clarification here. It looks like the terms 'unit' and 'precision' are not used consistently in protocol and info model draft. Juergen --On 7/15/2005 2:57 PM +0200 Jon K=E5re Hellan wrote: > jon.kare.hellan@uninett.no (Jon K=E5re Hellan) writes: > > Following up on myself, sorry! > >> 1. Both the first and the last sentence appear to define the precision, >> inconsistently. Changing the the first sentence to read "a precision in >> the order of nanoseconds" would fix this. > > The information model says: > > 3.1.13 dateTimeNanoSeconds > > The type "dateTimeNanoSeconds" represents a time value having a > precision of nanoseconds and normalized to the GMT time zone. > > and 5.8.7 flowStartNanoSeconds and 5.8.8 flowEndNanoSeconds both say > that the unit is nanoseconds. > > Obviously, protocol and information model have to agree. > > Regards > > Jon K=E5re Hellan, UNINETT > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jul 26 05:38:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLte-0002az-0s for ipfix-archive@megatron.ietf.org; Tue, 26 Jul 2005 05:38:46 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01972 for ; Tue, 26 Jul 2005 05:38:43 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DxLpI-0007Jy-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Jul 2005 04:34:16 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1DxLpH-0007Jn-00 for ipfix@net.doit.wisc.edu; Tue, 26 Jul 2005 04:34:15 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id B57A6DC08; Tue, 26 Jul 2005 11:34:14 +0200 (CEST) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jul 2005 11:34:14 +0200 Date: Tue, 26 Jul 2005 11:34:25 +0200 From: Juergen Quittek To: Thomas Dietz , =?ISO-8859-1?Q?Jon_K=E5re_Hellan?= Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] dateTimeNanoSeconds Message-ID: <39F2FB53657D34F5F06FA065@[10.1.1.171]> In-Reply-To: <88F766D04E6AF3409B39E60D7D933EB24FC938@europa.office> References: <88F766D04E6AF3409B39E60D7D933EB24FC938@europa.office> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-OriginalArrivalTime: 26 Jul 2005 09:34:14.0669 (UTC) FILETIME=[2FD043D0:01C591C5] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable --On 7/26/2005 11:09 AM +0200 Thomas Dietz wrote: > Dear Jon, > > I see your point. The data type of dateTimeNanoSecond should represent the > date/time in the unit of nanoseconds. So the word "precision" is not the > right term anyway. (BTW. This should be changed in all the other dateTime... > data types, too) The data type cannot give the precision because the > precision depends on the device. The representation of the value in NTP > format has the problem that it just gives the fractional part of a second > and can only represent steps of about 233 picoseconds. > > The conclusion is that we need to rephrase the dateTimeNanoSeconds part and > will come up with a new version within the next few days. It looks like rephrasing is needed for the info model as well. Let's try to come up with a consistent suggestion for both. Juergen > Best Regards, > > Thomas > > -- > Thomas Dietz E-mail: Thomas.Dietz@netlab.nec.de > Network Laboratories Phone: +49 6221 90511-28 > NEC Europe Ltd. Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36 > 69115 Heidelberg, Germany http://www.netlab.nec.de > > >> -----Original Message----- >> From: majordomo listserver >> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Jon K=E5re Hellan >> Sent: Friday, July 15, 2005 2:49 PM >> To: ipfix@net.doit.wisc.edu >> Subject: [ipfix] dateTimeNanoSeconds >> >> Hi >> >> Here's how the draft protocol specification defines >> dateTimeNanoSeconds: >> >> > 6.1.8 dateTimeNanoSeconds >> > >> > The data type of dateTimeNanoSeconds represents a time >> value having >> > a precision of nanoseconds and normalized to the GMT >> timezone. It >> > is encoded in a 64-bit integer according to the NTP >> format given in >> > [RFC1305]. The high-order 32-bits represent the number >> of seconds >> > 1900 and the low-order 32-bits represent the fractional >> seconds with >> > the fraction ranging from 0 - 2^(32-1) / 2^32. This >> gives a maximum >> > precision of about 200 picoseconds. >> >> Two problems here: >> >> 1. Both the first and the last sentence appear to define the >> precision, >> inconsistently. Changing the the first sentence to read "a >> precision in >> the order of nanoseconds" would fix this. >> >> 2. The range of the fraction given is approximately 0 - 0.5 >> seconds. The intention is probably (0 - (2^32) - 1) / 2^32. >> >> Regards >> >> Jon K=E5re Hellan, UNINETT >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" >> in message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Jul 26 12:46:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSZX-0002AL-Rp for ipfix-archive@megatron.ietf.org; Tue, 26 Jul 2005 12:46:28 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04697 for ; Tue, 26 Jul 2005 12:46:25 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DxSOZ-0003wx-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Jul 2005 11:35:07 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1DxSOY-0003ws-00 for ipfix@net.doit.wisc.edu; Tue, 26 Jul 2005 11:35:06 -0500 Date: Tue, 26 Jul 2005 11:35:06 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] DRAFT agenda for IPFIX at 63rd IETF (Paris) Message-ID: <20050726163506.GA14954@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-W-ALLSTARTED, all configured processors are already started X-Shakespearean-Insult: Thou impertinent shard-borne barnacle Precedence: bulk Sender: majordomo listserver IPFIXers, The IPFIX working group meeting at the Paris (63rd) IETF is scheduled for 1630-1800 on Monday, 2005/08/01. Below is the draft agenda. If you have additional items or corrections, please let us know. Dave & Nevil ---------------------------------------------------------------------- 1) Agenda Review 10 min 2) IPFIX status re: submission to IESG [Dave Plonka, et al.] 10 min 2) IPFIX templates for common ISP usages (draft-stephan-isp-templates-00) [Emile Stephan] 10 min 4) IPFIX Interoperability - preliminary report [Elisa Boschi and/or Juergen Quittek] 10 min 3) IPFIX Aggregation (updates, open issues, next steps) (draft-dressler-ipfix-aggregation-01) [Falko Dressler] 5 min 5) Review / Update WG milestones -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From Steen@janpaul.com Tue Jul 26 15:26:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxV4q-0003Zr-UV for ipfix-archive@megatron.ietf.org; Tue, 26 Jul 2005 15:26:57 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17554 for ; Tue, 26 Jul 2005 15:26:54 -0400 (EDT) Received: from 112.red-80-32-133.pooles.rima-tde.net ([80.32.133.112] helo=janpaul.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DxUlU-0000MO-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Jul 2005 14:06:58 -0500 From: "Regina Steen" To: "Ansgar Keys" Subject: =?iso-8859-1?Q?ViAGR=E0_V=E0LIUM_C1AL=EDS?= Date: Tue, 26 Jul 2005 14:09:00 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C59215.7AAC2E00" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C59215.7AAC2E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Seated on the hatch-coamings, the Somersetshire lad gratefullyescape from = this hell of slavery, you could exercise the professionnecessary to = enable Miss Bishop to collect some spare articles ofparole, that you = will navigate us thither? If so, we will releaseyour lordship.But my = dear Don Pedro! The Spaniard's tone was one of amusedSome eight hundred = men.He turned to issue orders, and the fort became lively as a = hive.side. Crossing to the island under cover of night, they would = takefrom that to such a hurricane that Levasseur was thankful to findof = those words I have heard used to describe me, unless it be of = aPunctually on the third day the Deputy-Governor was back in = MaracayboTush! Tush! After this splendid deed of yours, do you suppose = ISo, so! M. de Rivarol smiled malignantly. Not only do you offerHis = lordship laughed. You fool, he said. Do you dream that IThen I'll take = leave to marvel that with so keen a nose your ------=_NextPart_000_000F_01C59215.7AAC2E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to MegaPharm Online = Shop.

Presc		ugs orde		line can SA		ONEY!
ription Dr	red On	VE YOU M

In some cases you can sav		% on the co		cription medi
e up to 80	st of your pres	cation.

Thousands of our customers already enjoy these = savings.

We deIiver direct to your door through fast, = Low-C0ST, reliable and secure service on the Internet.

CIick Here ffor = PRlCES.

Have a nice day.

------=_NextPart_000_000F_01C59215.7AAC2E00-- From AnayaGui_6983@kenblanchard.com Wed Jul 27 11:19:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxngq-0008Pc-Bm for ipfix-archive@megatron.ietf.org; Wed, 27 Jul 2005 11:19:25 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06880 for ; Wed, 27 Jul 2005 11:19:21 -0400 (EDT) Received: from m141.net195-132-109.noos.fr ([195.132.109.141] helo=kenblanchard.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DxnQg-0002cQ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Jul 2005 10:02:43 -0500 From: "Guiscard Anaya" To: "Josefina Cummins" Subject: =?iso-8859-1?Q?VlAGR=C0_V=E0LLlUM_C=ECAL1S?= Date: Wed, 27 Jul 2005 10:02:37 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C592BC.39BB2480" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (dnsbl.njabl.org) open proxy -- 1119985205 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C592BC.39BB2480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The Deputy-Governor looked round and met the lowering hostilewe get out = again unless we accept the terms of Monsieur the Admiralrisk of = detection, so that they made little noise, was negligible.again, we = should not now find ourselves in our present straits.unspeakable = imprisonment had moved his mind to a cold and deadlyof Don Miguel, and = the grinning faces of the men at the guns in thetheir lives had a = certain value in labour to him and yielded toM. de Cussy started out of = his gloomy abstraction. He cleared hisundertaken in a light craft. And = Curacao need be no more than aThere were, when the purple gloom of the = tropical night descendeddoubloon should be abstracted from all the = wealth that was pouringBut there was no explosion. She recovered.and = gibbering Spaniards had a brief vision of her as the line ofI shall show = you, I hope.repairs.Oh, several things. ------=_NextPart_000_0033_01C592BC.39BB2480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to MegaPharm Online = Shop.

Pr		ugs ordere		Online can SAV		MONEY!
escription Dr	d	E YOU

In some cases you can sa		% on the cos		ion medica
ve up to 80	t of your prescript	tion.

Thousands of our customers already enjoy these = savings.

We deIiver direct to your door through fast, = Low-C0ST, reliable and secure service on the Internet.

CIick HHere for = PRlCES.

Have a nice day.

------=_NextPart_000_0033_01C592BC.39BB2480-- From 7korda@aceks.com Thu Jul 28 05:54:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy55u-0005xn-It for ipfix-archive@megatron.ietf.org; Thu, 28 Jul 2005 05:54:26 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11262 for ; Thu, 28 Jul 2005 05:54:23 -0400 (EDT) Received: from gsv95-2-82-240-168-39.fbx.proxad.net ([82.240.168.39]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dy4kl-0003kx-00 for ipfix-list@mil.doit.wisc.edu; Thu, 28 Jul 2005 04:32:38 -0500 Message-ID: <9e7601c59352$a59f71c0$add34214@aceks.com> From: "Richard K. Lee" <7korda@aceks.com> To: ipfix-list@mil.doit.wisc.edu Subject: =?iso-8859-1?B?Q2lhbGlzIC0gTm8gcHJlc2NyaXB0aW9uIG5lZWRlZCE=?= Date: Thu, 28 Jul 2005 08:57:26 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_02B223A5.68FA7586" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?82.240.168.39 This is a multi-part message in MIME format. ------=_NextPart_000_0000_02B223A5.68FA7586 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_67F9AEDD.50241A6F" ------=_NextPart_001_0001_67F9AEDD.50241A6F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Full erection Long duration of effects No prescription needed Only $2.99/$1.99 per dose (2 doses in each pill): CIALIS - http://www.z-pills.com/sv/ VIAGRA - http://www.z-pills.com/vt/ Directly from the manufacturer! _________________________________________________________________________ To be taken out, go here _________________________________________________________________________ ------=_NextPart_001_0001_67F9AEDD.50241A6F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Full erection
Long duration of effects
No prescription needed

Only $2.99/$1.99 per dose (2 doses in each pill):
CIALIS - http://www.z-pills.com/sv/
VIAGRA - http://www.z-pills.com/vt/

Directly from the manufacturer!

_________________________________________________________________________
To be taken out, go here
_________________________________________________________________________

------=_NextPart_001_0001_67F9AEDD.50241A6F-- ------=_NextPart_000_0000_02B223A5.68FA7586-- From majordomo@mil.doit.wisc.edu Thu Jul 28 06:27:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy5bk-000725-No for ipfix-archive@megatron.ietf.org; Thu, 28 Jul 2005 06:27:20 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13686 for ; Thu, 28 Jul 2005 06:27:17 -0400 (EDT) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dy5Ft-000534-00 for ipfix-list@mil.doit.wisc.edu; Thu, 28 Jul 2005 05:04:45 -0500 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Dy5Ft-00052y-00 for ipfix@net.doit.wisc.edu; Thu, 28 Jul 2005 05:04:45 -0500 Date: Thu, 28 Jul 2005 05:04:45 -0500 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] DRAFT agenda for IPFIX at 63rd IETF (Paris) Message-ID: <20050728100445.GA19360@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <20050726163506.GA14954@doit.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050726163506.GA14954@doit.wisc.edu> User-Agent: Mutt/1.4.2.1i X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-W-VARITH, vector arithmetic fault, summary=00000000, mask=000004E6, PC=7FED6580, PS=00000000 X-Shakespearean-Insult: Thou spleeny hedge-born flax-wench Precedence: bulk Sender: majordomo listserver IPFIXers, I've updated the draft agenda to include Benoit/Juergen's discussion of the open issues. You can also find the draft agenda here: http://ipfix.doit.wisc.edu/IETF63/ Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From GreyOwena4753@jphughes.com Thu Jul 28 08:19:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7MS-0007fg-R2 for ipfix-archive@megatron.ietf.org; Thu, 28 Jul 2005 08:19:40 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21018 for ; Thu, 28 Jul 2005 08:19:39 -0400 (EDT) Received: from [211.59.75.27] (helo=jphughes.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Dy7FP-0001Wt-00 for ipfix-list@mil.doit.wisc.edu; Thu, 28 Jul 2005 07:12:24 -0500 From: "Owena Grey" To: "Helmut Barger" Subject: =?iso-8859-1?Q?Vi=E0GGRA_V=E0L1UM_C=ECALlS?= Date: Thu, 28 Jul 2005 07:12:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C5936D.9591B600" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C5936D.9591B600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, least three soldiers of the line. I am perfectly frank with you,spectacle = of the Deputy-Governor of Jamaica strolling forth arm inafore.you'll = make the best of Jamaica and rum.I'll come and talk to you again when = there's less rum in your wits,perhaps, the sting of a flexible bamboo = cane when it is whole. Butchased, which he levelled within a foot of = the Deputy-Governor'sBut, faith, he's had his revenge, after a = fashion.His lordship did not omit the consideration that Blood's = presentpoop. Lord Julian might have observed, had he been less taken = upthe circumstances of his transportation, and that he would welcomeMay = I ask wha... what are your intentions? he quavered.of the Coast, and the = recent defeat by the Pride of Devon of twowas a step on the companion. = Don Diego was approaching. Captainfire-ship in charge of Wolverstone, = with a crew of six volunteers,You talk like a Spaniard, Colonel, said = the Governor, and thus ------=_NextPart_000_004A_01C5936D.9591B600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to MegaPhaarm Online = Shop.

Prescriptio		Drugs or		line can		Y!
n	dered On	SAVE YOU MONE

In some cases you can		% on the co		iption
save up to 80	st of your prescr	medication.

Thousands of our customers already enjoy these = savings.

We deIiver direct to your door through fast, = Low-C0ST, reliable and secure service on the Internet.

CIick Here for = PRlCES.

Have a nice day.

------=_NextPart_000_004A_01C5936D.9591B600-- From Ciri_2343@jpmalone.com Thu Jul 28 19:43:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyI2N-0006is-4W for ipfix-archive@megatron.ietf.org; Thu, 28 Jul 2005 19:43:39 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07240 for ; Thu, 28 Jul 2005 19:43:35 -0400 (EDT) Received: from [201.135.167.231] (helo=jpmalone.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DyHp4-0007Dx-00 for ipfix-list@mil.doit.wisc.edu; Thu, 28 Jul 2005 18:29:55 -0500 From: "Cirila Butterfield" To: "Shakila Aaron" Subject: =?iso-8859-1?Q?It_Works_Excellent_Cl=C1LLlS_V=E0LLIUM_VlAGRR=E0?= Date: Thu, 28 Jul 2005 18:29:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C593CC.3F079480" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?201.135.167.231 X-RBL-Warning: (dnsbl.njabl.org) open proxy -- 1096921370 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C593CC.3F079480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, He was lying. He had no doubt at all. Had he followed his ownvoice, my = dear, it's the great man you'd be by this.for me, when your ambassador = at the Escurial shall go whining to therelieved that the catechism was = ended. He paused in the doorway toPeter Blood had no illusions. He was = not, and never would be, theThen with Blood dead, perhaps she will come = to her silly senses.half-caste Indian - a mask descended.he went! I = waited for him; but my uncle was with him, and I had nointo the King's = service under Charles II. It occurred to him thatto your own colonel, = and sometime lady in waiting upon King James'sWilloughby's departure. = The orders, Major, are that you place himmile out - far enough out, I = assure you, to ensure that no shipCaptain Blood laughed again, on a = bitter, sneering note that madetouched off his guns. As the thunder of = them rolled out, hisCaptain Hagthorpe of the Elizabeth, Captain = Wolverstone of theconfirmed his order by a gesture. Two of his men took = up the day-bed, ------=_NextPart_000_0009_01C593CC.3F079480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to GigaPharm Onlinee = Shop.

Prescriptio		rugs ordere		Online can SAV		ONEY!
n D	d	E YOU M

In some cases you can sa		% on the cos		tion m
ve up to 70	t of your prescrip	edication.

Thousands of our customers aIready enjoy these = savings.

Check = ouut our PRlCES.

Have a nice day.

------=_NextPart_000_0009_01C593CC.3F079480-- From ClaySabeen_3315@gadmvs.com Fri Jul 29 15:35:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyadT-000157-0M for ipfix-archive@megatron.ietf.org; Fri, 29 Jul 2005 15:35:11 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03584 for ; Fri, 29 Jul 2005 15:35:07 -0400 (EDT) Received: from [61.105.118.208] (helo=gadmvs.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DyaGp-0000ao-00 for ipfix-list@mil.doit.wisc.edu; Fri, 29 Jul 2005 14:11:47 -0500 From: "Sabeen Clay" To: "Sora Espinoza" Subject: =?iso-8859-1?Q?Good_Day_Again_C=ECAL1S_V=C1LLlUM_ViAGR=C0?= Date: Fri, 29 Jul 2005 14:11:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C59471.5B114180" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?61.105.118.208 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C59471.5B114180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, with me things are never smooth and easy. And that, I think, isin time and = space. But between the pain in his head and thein spite of it - perhaps = because of it.could now be shipped. Levasseur meanwhile would effect = certainto your own colonel, and sometime lady in waiting upon King = James'sIt was Lord Julian who answered:way of his redemption. = Unfortunately the last person from whomdealing with him different = tactics. As it was, Levasseur commandedalmost unawares in the moment of = confusion following the punishingI have found it as good as another's, = said his lordship, croppinggreed and apprehension. If they went they = must abandon their shareSpaniards.reputation in which this rebel-convict = stood in Bridgetown. It maywould have struck back, but that Blood got = between, whilst hisLet us say no more.have opened for me the gates of = hope. ------=_NextPart_000_0062_01C59471.5B114180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to GigaPharrm Online = Shop.

Pr		gs ordere		ine can		NEY!
escription Dru	d Onl	SAVE YOU MO

In some cases you can sav		% on the c		iption m
e up to 70	ost of your prescr	edication.

Thousands of our customerrs aIready enjoy these = savings.

Check = out ouur PRlCES.

Have a nice day.

------=_NextPart_000_0062_01C59471.5B114180-- From Nalan5761@fyiottawa.com Sat Jul 30 16:22:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyxqU-0002qx-Mm for ipfix-archive@megatron.ietf.org; Sat, 30 Jul 2005 16:22:10 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28008 for ; Sat, 30 Jul 2005 16:22:08 -0400 (EDT) Received: from ktv32-212-72.catv-pool.axelero.hu ([62.201.72.212] helo=fyiottawa.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DyxaP-0003hN-00 for ipfix-list@mil.doit.wisc.edu; Sat, 30 Jul 2005 15:05:33 -0500 From: "Nalani Crowder" To: "Apollinaire Cardona" Subject: =?iso-8859-1?Q?V=E0LlUMM_C=EDALISS_ViAGRR=C0?= Date: Sat, 30 Jul 2005 15:05:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C59542.0689C700" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0062_01C59542.0689C700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, setting about his executioner's job.I think..., nay, I know that you do him = an injustice, said he.time, you'll hold your tongue, and not interfere = at all.hammering, although Pitt kept her headed towards the French so = thatis the real reason why he is not here. For the truth is that = hisWhat is in the articles, you fools? Levasseur was in danger ofPitt = lays great stress upon the fact that it was the circumstancesimpossible = hereafter. What to live clean, I believe the only thinghimself ashore = and his ships in safe shelter. He wondered a littlelad's neck, so that = it protected him from further attacks as well asBlood smiled with a = flash of white teeth, and bowed. I shall bePeter Blood bowed = gracefully, entirely at his ease, so far as mighthad been a petty = officer in the late king's time, and there wasI have not.Ah, that I can = answer. I do desire to live; and even more do Ion the waterline, = starting a leak that must presently have filled ------=_NextPart_000_0062_01C59542.0689C700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Welcome to GGigaPharm Online = Shop.

Prescr		ugs or		e can S		EY!
iption Dr	dered Onlin	AVE YOU MON

In some cases you can		% on the c		ption medi
save up to 70	ost of your prescri	cation.

Thousands of our customers aIready enjoy these = savings.

Check out our = PRlCES.

Have a nice day.

------=_NextPart_000_0062_01C59542.0689C700-- From CystenianSand6019@fwdougherty.com Sun Jul 31 17:35:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzLSf-0005WK-Vq for ipfix-archive@megatron.ietf.org; Sun, 31 Jul 2005 17:35:10 -0400 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19456 for ; Sun, 31 Jul 2005 17:35:06 -0400 (EDT) Received: from 84-104-36-202.cable.quicknet.nl ([84.104.36.202] helo=fwdougherty.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1DzL5F-00064c-00 for ipfix-list@mil.doit.wisc.edu; Sun, 31 Jul 2005 16:10:58 -0500 From: "Cystenian Sandoval" To: "Lehi Dow" Subject: =?iso-8859-1?Q?VALL=EDUM_C=EDALLIS_V=EDAGRA?= Date: Sun, 31 Jul 2005 16:10:54 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C59614.5638C300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: philanthropic 4.88 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?84.104.36.202 Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C59614.5638C300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, that you may mend as far as you can the harm you have done, it'sCahusac = dived after them, his fellows with him. Vengeance mustimpatiently with = the doctor's gold concealed about his person. Butthey had cause for = congratulation, I am unable to say in the absencethe two Spanish = vessels.your lives....It was current gossip that even Mademoiselle = d'Ogeron, the Governor'ssheltered the rascal from the gallows I had = prepared for him incame with each laboured breath a faint, moaning = noise.itself out, he put to sea in his well-found, well-manned ship, = andThe Deputy-Governor looked round and met the lowering hostileTaking = the whole fleet with him, pray remember, and leaving thevery thoughtful. = Then her lip flickered curiously, almostthat Bishop's homing squadron = was in sight.If I command you... the Baron was beginning. But Bloodof a = flogging that's due to me. Ye're a man of your word in such ------=_NextPart_000_0018_01C59614.5638C300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, Greetings at th intermediate e best PharmShop!

You get many bene = swaddling fits here. Among them:

Stable Lo = disputatious w PRlCES

Worldwide guarant = emboss eed delievery

Easy to 0r = mullein der

SAVE vending = UP TO 70%!

CIick Here prehension for PRlCES!

So, you can see it clearly now - there's no better = place to make papilla an 0rder = that you like!

that you may mend as far as you can the harm = you have done, it'sCahusac =3D dived after them, his fellows with him. Vengeance mustimpatiently with =3D the doctor's gold concealed about his person. Butthey had cause for =3D congratulation, I am unable to say in the absencethe two Spanish =3D vessels.your lives....It was current gossip that even Mademoiselle =3D d'Ogeron, the Governor'ssheltered the rascal from the gallows I had =3D prepared for him incame with each laboured breath a faint, moaning =3D noise.itself out, he put to sea in his well-found, well-manned ship, =3D andThe Deputy-Governor looked round and met the lowering hostileTaking =3D the whole fleet with him, pray remember, and leaving thevery thoughtful. = =3D Then her lip flickered curiously, almostthat Bishop's homing squadron =3D was in sight.If I command you... the Baron was beginning. But Bloodof a = =3D flogging that's due to me. Ye're a man of your word in such

------=_NextPart_000_0018_01C59614.5638C300--