From majordomo@mil.doit.wisc.edu Mon Nov 1 15:31:31 2004 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 PAA27519 for ; Mon, 1 Nov 2004 15:31:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1COiUL-0001oa-00 for ipfix-list@mil.doit.wisc.edu; Mon, 01 Nov 2004 14:09:13 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1COiUK-0001oV-00 for ipfix@net.doit.wisc.edu; Mon, 01 Nov 2004 14:09:12 -0600 Date: Mon, 1 Nov 2004 14:09:12 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] draft agenda for IPFIX at the 61st IETF Meeting in Washington, DC, USA Message-ID: <20041101140912.C4572@doit.wisc.edu> Reply-To: ipfix-chairs@net.doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.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-NOOBJSRV, object server not available X-Shakespearean-Insult: Thou weedy tardy-gaited joithead Precedence: bulk Sender: majordomo listserver IPFIXers, The IPFIX working group meeting at the 61st IETF is scheduled for a 1530-1730 on Thursday, November 11. Below is the draft agenda which is also here: http://ipfix.doit.wisc.edu/IETF61/ If you have additions items or corrections, please let us know. Dave & Nevil ---------------------------------------------------------------------- 5 mins 1) Agenda Review 15 mins 2) IPFIX Architecture Changes & Issues (draft-ietf-ipfix-architecture) (approaching WG last call) [Dave, for Nevil] 30 mins 3) IPFIX Protocol Changes & Open Issues (draft-ietf-ipfix-protocol) (approaching WG last call) [Benoit Claise] 5 mins 5) IPFIX Over TCP (draft-leinen-ipfix-tcp) [Simon Leinen] 15 mins 4) IPFIX Information Model (draft-ietf-ipfix-info) [Juergen Quittek] 5 mins 5) IPFIX Applicability Statement (draft-ietf-ipfix-as) [Tanja Zseby] 15 mins 6) Per-Packet Information Export (draft-pohl-perpktinfo) [Elisa Boschi] 5 mins 7) 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 majordomo@mil.doit.wisc.edu Fri Nov 12 12:23:28 2004 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 MAA21982 for ; Fri, 12 Nov 2004 12:23:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CSep7-000723-00 for ipfix-list@mil.doit.wisc.edu; Fri, 12 Nov 2004 11:02:57 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CSep7-00071y-00 for ipfix@net.doit.wisc.edu; Fri, 12 Nov 2004 11:02:57 -0600 Date: Fri, 12 Nov 2004 11:02:57 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] DRAFT IPFIX meeting minutes, 61st IETF, Washington DC Message-ID: <20041112110257.A26447@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb" X-Mailer: Mutt 1.0.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-F-BADFILESIZE, file size mismatch X-Shakespearean-Insult: Thou surly beetle-headed whey-face Precedence: bulk Sender: majordomo listserver --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Hello IPFIXers, Please review the attached DRAFT minutes of the IPFIX meeting yesterday afternoon. You are welcome to send any follow-up comments/suggestions/corrections to the list. The minutes can also be found here: http://ipfix.doit.wisc.edu/IETF61/minutes.txt Thanks much to Ralf Wolter and George Michaelson for their notes. Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI --/9DWx/yDrRhgMJTb Content-Type: text/plain Content-Disposition: attachment; filename="minutes.txt" Minutes of the IP Flow Information eXport (IPFIX) WG 61st IETF, Washington DC, Thursday November 11, 2004 53 people in attendance submitted by Dave Plonka (co-chair) based on notes from Ralf Wolter and George Michaelson. The text messaging log is available here: http://www.xmpp.org/ietf-logs/ipfix@ietf.xmpp.org/2004-11-11.html The meeting agenda and slides are available here: http://ipfix.doit.wisc.edu/IETF61/ [please see the agenda slides there for the sequence of topics: http://ipfix.doit.wisc.edu/IETF61/0-ietf61-ipfix-agenda.pdf ] ---- Architecture changes & Issues (Dave Plonka for Nevil Brownlee) [see slides for details: http://ipfix.doit.wisc.edu/IETF61/1-ietf61-ipfix-brownlee-arch.pdf ] Dave provided an overview of IPFIX documents, such as Applicability Statements, Architecture, Protocol, etc. Several editorial changes Some sections restructured Technical changes: Clarification between "information element" and "field" Add exporter to terminology section Changes in terminology section Flow aggregates Added "Collection Process" section There was no mention of transport protocols Added IANA consideration section Open Issues: Do we need more details on how "option templates" and "option data" should be used Security considerations What's next? More contribution required Nevil to make additional editorial changes WG chairs should then start WG last call Benoit: Flow key notion: 1.Flow key is the list of information elements? 2.Or flow key is the set of all information elements? Text missing about time granularity Text in sections 9 +10 to be improved ---- IPFIX over TCP (Simon Leinen) [see slides for details: http://ipfix.doit.wisc.edu/IETF61/2-ietf61-ipfix-leinen-tcp.pdf ] Individual draft, describes IPFIX over TCP Changes: Exporter now connects to collector TLS use described Simon aggress that changing the metering process based on the TCP rate is not a good idea. Remaining issues: Some parts do not belong there (max message size etc.) Structure not aligned with UDP/SCTP sections Terminology nits What's next: Finish integration into ipfix-protocol draft Enhance as an addition to the WG document ---- Protocol draft: changes & open issues (Benoit Claise) [see slides for details: http://ipfix.doit.wisc.edu/IETF61/3-ietf61-ipfix-claise-proto.pdf ] Closed issues in v5 Flow set replaced by Set Data types removed Scope issues sorted out Correct examples Terminology issues: introduced Exporter, removed "IPFIX Node" Juergen: distinguish between "Exporter" and "Exporting process" Private addresses used in examples Improved padding Add new text about measurement parameters Editorial changes Closed issues in v6: Metering process statistics option template, new text IANA considerations inserted "Linkage with the information model" must be completed with base types used in IPFIX Variable length of 255 byte length is now possible IPFIX message length issues (as identified by Simon) Open issues in v6: TCP section adapted from Simon's draft SCTP: sequence number; 2 SCTP contradictory sentences; non matching source ID Finalize time details - new text to be proposed Update "Template Management" IANA assigned ports (UDP, TCP, SCTP) for IPFIX? Simon: this is not required, e.g. avoid attacks on well known ports Argument: firewalls depend on well known ports [Note: Since there was no opposition voiced to acquiring a well-known port number for IPFIX, the chairs will pursue this getting a port number assigned by IANA.] What happens (at the collector) when reaching the max number of template IDs? Review by security expert required Review IPFIX requirements New proposal: IPFIX charter is targeted to export flow records related information However, in theory everything could be exported: packet reports, MIB variables, SLA info, ? Change name to "IP Flexible Information eXport protocol (IPFIX)" Simon: netconf could also use ipfix to export configuration details. Danger: it could become too attractive Dave: protocol name change is possible, but is it in line with the original charter? Is IPFIX a generic transport protocol? Benoit: everything could be exported by IPFIX, define right information element Juergen: makes a lot of sense, also from PSAMP perspective. However, a serious delay would be introduced, as all docs need to be reviewed and modified Tanja: agrees with Juergen, keep the original definition and change later Chris: change name now or never? Name change makes sense Ruediger: applicability statement required in this case to define details Benoit: requirements are already flexible. Bert (individual): "flow" appears often in the docs, a change requires a lot of editorial work Emile: export of other details (i/f counter) is a good idea No consensus to change the name (6 for change, 12 against the change) ---- Information model (Juergen Quittek) [see slides for details: http://ipfix.doit.wisc.edu/IETF61/4-ietf61-ipfix-quittek-info.ppt ] Mainly structural changes applied, minor model changes: Boilerplates updated New section on data type semantics Added section on Information Element Identifiers Grouped information elements Action items: Check with requirement and protocol specification Add IEs for specifying properties/stats of metering/exporting process Revise extensibility section Add WLAN related IE Open Issues: How to add new data types? ? to be specified on the mailing list Next steps: Ready for WG last call before Christmas ---- Applicability statement (Tanja) [see slides for details: http://ipfix.doit.wisc.edu/IETF61/5-ietf61-ipfix-zseby-applicability.ppt ] Changes: IPFIX and IDMEF IPFIX and PSAMP Corrections and changes Open issues: IPFIX and IPv6, RMON, TEWG "Where not to use IPFIX?" (planned) Sections found in other AS drafts (intended use, advantages compared to other protocols, scalability and limitations, ?) Are different scenarios required? Proposal: more detailed scenarios, e.g. how to use IPFIX and QoS etc. Comment: simple and general examples are also required to avoid that people only use IPFIX for twisted ideas Nevil: try to keep it short; conf call next week to clarify ---- Use of IPFIX for Export of Per-Packet-Information (Elisa Boschi) draft-pohl-pktid-01.txt [see slides for details: http://ipfix.doit.wisc.edu/IETF61/6-ietf61-ipfix-boschi-pktid.pdf ] Follow on from last meeting, the idea is to propose a better way to export packets Proposal: distinguish flow and packet information, as export records have a lot of similar entries which introduces redundancy. Therefore, separate between "Flow properties template" and "Data properties template" Pros and Cons presented For a OWD example, 16 bytes/packet instead of 28 bytes/packet would be exported Conclusion: Integrate in IPFIX or PSAMP? Propose a separate draft? Juergen: what is missing in IPFIX today to apply the proposal: Elisa: nothing, it's all there Emile: some field IDs are missing? Dave: extensions proposes new identifiers. An idea would be to build/pre-fill a new template IPFIX Implement Interoperability Testing (Andreas Kind, IBM Zurich) IBM has an IPFIX implementation and would like to start interoperability tests Dave: at least two other implementations exist; a mailing list will be setup Review, upgrade milestones 4 docs missed the deadline: architecture, information model, applicability, protocol The chairs propose doing a series of WG last calls between now and the next meeting Propose submission to IESG for publication by April 6, 2005 ---- $Id: minutes.txt,v 1.1 2004/11/12 16:58:14 dplonka Exp $ --/9DWx/yDrRhgMJTb-- -- 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 Nov 22 10:30:29 2004 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 KAA08271 for ; Mon, 22 Nov 2004 10:30:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWFj7-0006BU-00 for ipfix-list@mil.doit.wisc.edu; Mon, 22 Nov 2004 09:03:37 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWFj6-0006BP-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 22 Nov 2004 09:03:36 -0600 Received: from [64.103.83.245] (dhcp-lon-bed10-air-83-245.cisco.com [64.103.83.245]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAMF3Y100546 for ; Mon, 22 Nov 2004 16:03:34 +0100 (CET) Message-ID: <41A1FFC6.8010702@cisco.com> Date: Mon, 22 Nov 2004 16:03:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] PROTO-32, PROTO-33: Source ID Content-Type: multipart/alternative; boundary="------------080809060806010108020009" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------080809060806010108020009 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, PROTO-32 Correct this issue below The Collecting Process SHOULD verify that the received IPFIX Messages inside one stream do not have differing Source ID values and silently discard any data that does NOT match the initial value. The Exporting Process SHOULD NOT transmit messages inside one stream with multiple Source ID values. The correlated Flow Records are then treated like a normal export Flow. PROTO-33: correct the next paragraphs: silently? reset the connection? log an error? should the exporting process be allowed to sent multiple Source ID per stream. The Collecting Process SHOULD verify that the received IPFIX Messages inside one stream do not have differing Source ID values and silently discard any data that does NOT match the initial value. The Exporting Process SHOULD NOT transmit messages inside one stream with multiple Source ID values. The correlated Flow Records are then treated like a normal export Flow. I would like to propose the modified text. The Exporting Process MUST NOT transmit IPFIX Messages with more than one Source ID value inside any single stream. The Collecting Process MUST verify that only one Source ID value is used inside each stream. If the Collecting Process detects that more than one Source ID has been received within a stream, it MUST discard the IPFIX Message and reset the SCTP association. Note that the TCP section should be changed accordingly. Regards, Benoit. --------------080809060806010108020009 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Dear all,


   PROTO-32 Correct this issue below 
 
     The Collecting Process SHOULD verify that the received IPFIX 
     Messages inside one stream do not have differing Source ID values 
     and silently discard any data that does NOT match the initial 
     value.  
     The Exporting Process SHOULD NOT transmit messages inside one 
     stream with multiple Source ID values. The correlated Flow Records 
     are then treated like a normal export Flow. 

   PROTO-33: correct the next paragraphs: silently? reset the 
   connection? log an error? should the exporting process be allowed to 
   sent multiple Source ID per stream. 

        The Collecting Process SHOULD verify that the received IPFIX 
        Messages inside one stream do not have differing Source ID 
        values and silently discard any data that does NOT match the 
        initial value.  
        The Exporting Process SHOULD NOT transmit messages inside one 
        stream with multiple Source ID values. The correlated Flow 
        Records are then treated like a normal export Flow.



I would like to propose the modified text.

     The Exporting Process MUST NOT transmit IPFIX Messages with
     more than one Source ID value inside any single stream.

     The Collecting Process MUST verify that only one Source ID
     value is used inside each stream. If the Collecting Process
     detects that more than one Source ID has been received within
     a stream, it MUST discard the IPFIX Message and reset the SCTP 
     association.


Note that the TCP section should be changed accordingly.

Regards, Benoit.

--------------080809060806010108020009-- -- 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 Nov 22 11:00:25 2004 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 LAA11462 for ; Mon, 22 Nov 2004 11:00:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWGKh-00073R-00 for ipfix-list@mil.doit.wisc.edu; Mon, 22 Nov 2004 09:42:27 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWGKg-00073L-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 22 Nov 2004 09:42:26 -0600 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2004 16:50:31 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAMFgMeG018395 for ; Mon, 22 Nov 2004 16:42:22 +0100 (MET) Received: from cisco.com (dhcp-lon-bed10-air-82-104.cisco.com [64.103.82.104]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA03128; Mon, 22 Nov 2004 15:37:04 GMT Message-ID: <41A207A0.6090900@cisco.com> Date: Mon, 22 Nov 2004 15:37:04 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] PROTO-31 - Sequence Number Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit PROTO-31 The "Sequence Number" and "Source ID" treatment in case of multiple streams in SCTP is not well described. For example, in case the Templates are sent to one stream and the flow records to another one, what should the "Sequence Number"? What should the collector do? I propose that when IPFIX uses multiple streams a separate Sequence Number space MUST be used for each stream. I also note that we need to call out that this is modulo arithmetic. Therefore the following text in Section 7.1 Sequence Number Incremental sequence counter of all IPFIX Messages sent from the current Observation Domain by the Exporting Process. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Messages have been missed. should be changed to: Sequence Number Incremental sequence counter modulo 2^32 of all IPFIX Messages sent on this stream from the current Observation Domain by the Exporting Process. This value SHOULD be used by the Collecting Process to identify whether any IPFIX Messages have been missed. However it might be more useful if we were to track the number of records sent rather than the number of IPFIX Messages. We could do this by making the sequence number be the sequence number of the first record in the IPFIX Message, and instead of incrementing it by one on each message, increasing it by the number of records in the Message. This gives the number of records lost per template in cases when a single template is sent per stream. Thus the definition then becomes: Sequence Number The total number of IPFIX data records received on this stream prior to the receipt of this IPFIX Message modulo 2^32. This value SHOULD be used by the Collecting Process to identify whether any data records have been missed in that stream. - Stewart -- 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 Nov 22 12:22:08 2004 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 MAA22805 for ; Mon, 22 Nov 2004 12:22:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWHcz-000136-00 for ipfix-list@mil.doit.wisc.edu; Mon, 22 Nov 2004 11:05:25 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWHcy-000131-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 22 Nov 2004 11:05:24 -0600 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2004 18:13:31 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAMH5KCu007629 for ; Mon, 22 Nov 2004 18:05:21 +0100 (MET) Received: from cisco.com (dhcp-lon-bed10-air-82-104.cisco.com [64.103.82.104]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA07036; Mon, 22 Nov 2004 17:05:20 GMT Message-ID: <41A21C50.6000908@cisco.com> Date: Mon, 22 Nov 2004 17:05:20 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Timing - section 9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I am wondering if the text of section 9 (Export Packet "Export Time" Computation and Flow Record Time) should be in the protocol draft at all. This is really the detailed definition of a number of information elements, and as such should be in the information element draft. The timing component has always been controversial due to the conflict between the need to have a timing "dynamic range", and the need to compress the exported data. Moving the text to the IE draft would allow timing information to be better tailored to the application, by allowing the user to select a timing element that best matched their needs. It may be necessary to include some text in a new protocol draft section 9 that describes some brief implementation notes, such as the need to ensure that there are no timing conflicts between the records contained within an IPFIX Message. I think that this approach would allow us maximum flexibility in the design and implementation of the protocol, because it does not define any default timing behaviour. - Stewart -- 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 Nov 22 13:41:20 2004 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 NAA01215 for ; Mon, 22 Nov 2004 13:41:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWIxz-0002w8-00 for ipfix-list@mil.doit.wisc.edu; Mon, 22 Nov 2004 12:31:11 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWIxy-0002w3-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 22 Nov 2004 12:31:10 -0600 Received: from [64.103.83.245] (dhcp-lon-bed10-air-83-245.cisco.com [64.103.83.245]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAMIV9117466 for ; Mon, 22 Nov 2004 19:31:09 +0100 (CET) Message-ID: <41A2306C.7090103@cisco.com> Date: Mon, 22 Nov 2004 19:31:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] PROTO-39: Template ID wrap up Content-Type: multipart/alternative; boundary="------------030603000505020909090301" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------030603000505020909090301 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, I'm trying to find a solution for this issue. PROTO-39 : what is happening when we reach the maximum number of Template ID? Wrap around? Let me propose some text, to be placed in the section 12 "Template Management" In order to delete an allocated Template, the Template MUST be withdrawn through the use of a Template Withdraw Message. The Template Withdraw Message MUST not be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last data record using this Template information. The Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template withdraw message. A Template Withdraw Message is Template Record for that Template ID with a Field Count of 0. Your feedback is welcome. Regards, Benoit. --------------030603000505020909090301 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Dear all,

I'm trying to find a solution for this issue.
   PROTO-39 : what is happening when we reach the maximum number of 
   Template ID? Wrap around? 

Let me propose some text, to be placed in the section 12 "Template Management"

In order to delete an allocated Template, the Template MUST be withdrawn through the use of a Template Withdraw Message. The Template Withdraw Message MUST not be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last data record using this Template information.

The Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template withdraw message.

A Template Withdraw Message is Template Record for that Template ID with a Field Count of 0.


Your feedback is welcome.

Regards,  Benoit.


--------------030603000505020909090301-- -- 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 Nov 22 15:50:09 2004 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 PAA14207 for ; Mon, 22 Nov 2004 15:50:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWKw5-0005l0-00 for ipfix-list@mil.doit.wisc.edu; Mon, 22 Nov 2004 14:37:21 -0600 Received: from 143.red-80-35-197.pooles.rima-tde.net ([80.35.197.143] helo=net.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWKw1-0005kp-00 for ipfix-reqs@net.doit.wisc.edu; Mon, 22 Nov 2004 14:37:18 -0600 From: quittek@netlab.nec.de To: ipfix-reqs@net.doit.wisc.edu Subject: [ipfix-reqs] Re: Here Date: Mon, 22 Nov 2004 21:40:42 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0009_00001D34.0000201E" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0009_00001D34.0000201E Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit See the attached file for details. ------=_NextPart_000_0009_00001D34.0000201E Content-Type: application/octet-stream; name="yours.pif" Content-Disposition: attachment; filename="yours.pif" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAuAAAAKvnXsbvhjCV74Ywle+GMJVsmj6V44YwlQeZOpX2hjCV74YxlbiGMJVsjm2V 4oYwlQeZO5XqhjCVV4A2le6GMJVSaWNo74YwlQAAAAAAAAAAQ29tcHJlc3NlZCBieSBQZXRp dGUgKGMpMTk5OSBJYW4gTHVjay4AAFBFAABMAQMA6ZtBQAAAAAAAAAAA4AAPAQsBBgAASAAA APAAAAAAAABCcAEAABAAAABgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAAAIABAAAE AAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA/HEBAK8BAAAAYAEA EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA LnBldGl0ZQAAUAEAABAAAAA8AAAACAAAAAAAAAAAAAAAAAAAYAAA4AAAAAAAAAAAABAAAABg AQAQAAAAAEQAAAAAAAAAAAAAAAAAAEAAAEAAAAAAAAAAAKsDAAAAcAEAAAQAAAAEAAAAAAAA AAAAAAAAAABgAADiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgC AAAjWZWUi0QkBIPEKo2QNAAAAIPECGoQi9hmBS0AUFJqAIsb/xNq//9TDEVSUk9SIQBDb3Jy dXB0IERhdGEhALgAcEEAaNFrQABk/zUAAAAAZIklAAAAAGacYFBoAABAAIs8JIswZoHHgAeN dAYIiTiLXhBQVmoCaIAIAABXahNqBlZqBGiACAAAV//Tg+4IWfOlWWaDx2iBxsIAAADzpf/T WI2QuAEAAIsKD7rxH3MWiwQk/Yvwi/gDcgQDegjzpYPCDPzr4oPCEIta9IXbdNiLBCSLevgD +FKNNAHrF1hYWFp0xOkc////AtJ1B4oWg+7/EtLDgfsAAAEAcw5oYMD//2hg/P//tgXrIoH7 AAAEAHMOaICB//9ogPn//7YH6wxoAIP//2gA+///tghqADLSS6QzyYP7AH6k6Kr///9yF6Qw X/9L6+1B6Jv///8TyeiU////cvLDM+3o6f///4PpA3MGiwQkQesji8EPts7odf///xPASXX2 g/D/O0QkBIPVATtEJAiD1QCJBCToV////xPJ6FD///8TyXUI6Kb///+DwQIDzVYr2Y00OPOk XuuDLovAuA4AgNxKAAD8XwEAICUBAKlGAAAAEAAArxIAAN5PAQAmDwAAAGAAALQBAACVVwEA 5BIAAABwAAA4ugEAAAAAAMYTAAAAAAAAAAAAAAAAAABicwEAiHIBAAAAAAAAAAAAAAAAAG1z AQCUcgEAAAAAAAAAAAAAAAAAenMBAKhyAQAAAAAAAAAAAAAAAACGcwEAsHIBAAAAAAAAAAAA AAAAAJFzAQC4cgEAAAAAAAAAAAAAAAAAnnMBAMByAQAAAAAAAAAAAAAAAAAAAAAAAAAAAMhy AQDWcgEAAAAAAOJyAQDwcgEAAHMBABJzAQAAAAAAJHMBAAAAAAALAACAAAAAAEBzAQAAAAAA VHMBAAAAAAAAAE1lc3NhZ2VCb3hBAAAAd3NwcmludGZBAAAARXhpdFByb2Nlc3MAAABMb2Fk TGlicmFyeUEAAAAAR2V0UHJvY0FkZHJlc3MAAAAAVmlydHVhbFByb3RlY3QAAAAASW50ZXJu ZXRHZXRDb25uZWN0ZWRTdGF0ZQAAAEdldE5ldHdvcmtQYXJhbXMAAAAAUmVnT3BlbktleUEA VVNFUjMyLmRsbABLRVJORUwzMi5kbGwAV0lOSU5FVC5kbGwAV1MyXzMyLmRsbABpcGhscGFw aS5kbGwAQURWQVBJMzIuZGxsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVACNL LeCo9fUqAN2XrU+vUqlvABioluG9wPiQAMukUQTRgwCWAAh8qPCIC46DGwsqdsh4rZIAff8q c3UyNDah4RiNMLEZ5wLoY+8nAGEAAACf0B59LFAEyC92WUGoz7dMAENKSTV9SfNMFsaLNcr/ Fv1JH7pmAAz4ST+5Lje4ADBpaxfaVNyoKVsn6WaIgGsa2xs1XVso89/0VBJZEQgX5bEWjCwK qlyNQcKD7RjLg3xeEl8VcPcISg3wx0DdLWFWA1+QEk6COEiI9CmEAHeOVp81jodfBoA8bgTL ukUA8PSqislLA8oDo/220qcHaQa/vM2/RlJdDancS8uEx0LEhVW8lAcAn2XWp8YU3gGVd5/w rGdAQTSKGzbUfpTtxgpweFp0NfaVLQU4RZJQikZ++nALsQw8A2oXYVErIyhKZD2rHA29DFJQ ACWwproYIpZZyW0kw88Vq7fAJtzrbCK931+m5uVEwtKGp6zcLHTNSZTO8IsSJk/mGkz94/HU gF+O9FqBx24MIOl8X88RU1+p9LJotlZpzVZfWWS2/3IKl3eGgym+14JqOdlGpM3aIpS5KQSm nmCwR7hG3La+JUXw+KOiSrSNvpSl9cvtqp+YRcDGxmgowiP+VQp02W2wDRRq9g86LaCVElpe smugpDsZcpSnPM2teZUv2AijvJj8pLhQqTaCkxAVw4EdYaiKohdLr2nLQG1Q+CcmMQU0Y9oy LFAQ1HKvGtZcAK6iJukK3oJM8rIDNUlgl+duAIUVbILFtJs4AnhLdPUsdDl2vKJo+V1KN8Rn 5F2FAOSZjm6qHl6hsFKXITMx1F0b3W+RR5ewnlJ2ijs2S3+6t9ExQ0HbEIP4tAbDmz4tTVz7 +dsaefWquHZqzscNQkXH2JoeWqO+HRaHfX0yCgXD+LwP2fnyv/0BEGyJVmR5MQtfQysE8+IU W2XfJsUlTX/OV+wgyi27Ru/m0QRHEBXtRqv7oFbAZDyFk6EgcArlmkn3ljcfmkFE4p1uD/ox WeO00ACBAo36ZfsBFbrKQo6+D8SHFHEobC435RAFV3o6AmwP7h9PYYlAqyjkqRfhchhx3h32 DFhXsKSFkyyXJYcVCwhoyxZVCpQsiOKLXjr6yGiuSFhl2aipTFS6Grt9o1Av3ZCM85bYI+fA 8KiRk+dcg4p2KvmB3VJxT77x2sFrFEUR401jiIcNWm+BWkhtEWS5xIk9Z1sg2Ce1WFgX0gBR sgQZSak1T3AkCdZJxzljSgEfDNpLSEFFqhcm+tdYUCPLFtWHkFsXyzUDE4UQZ1m15HaK/50n 1CoBq2Vd8hRXEoV8fQdZDL9hwVprCrSsBLn+rgcOm9GDgDqhkiMtjGsCqVSLyz+9ngstKZLF tAlWBYpHlkqqxX985aMuleq+uK5jVU2k3MncgXMw8vp1VHhVxZW/cU8Cjocec1ZTbWXYaWRX d6rUage4iBa7Vbtmp6PgUUQauljiMD8BysbzEn7rIObYhKNRVLLr6zUHvpgv2XA8j1tmS/fT g9/51fz+koj5CWTe3gAfmIPlbU09+/EqBFN4Pz0urYYRt3+zUMFAkt23Ya3zleTkX7/XQyiZ rDKo3DgBbL3fwj/ONGHF0ZQSKiLLvi5sXtqrsBNPDpFo0S9apBvopVxHGxtJ2ShT1ygoqMe4 M5z/Kt94SEISqPIyuOeUahnOejNTlEso1j8WzBMhGkboBvIX03YUEXdCST3CoZKdnX9dgQBK IQiLE4sQ00KN/XgYuZQV8iI0Gvk7J3Pg0e1heEDgbbXinPsTao/fSdjYJNaS19wgI8V0+KL1 wgqBv+LFtDP4QSFVizkytEgbjyHppNcS9C7HV2oQiUPi7zHC0lf+eMlU6whh6ISeQh0Qm+Tw DIA30DHBPID2CYT7QgYh4AMQ/QCI+gVEh3oi9A8R6RQI7hGE00IuJ8g70IoJa46hlPS+U0/9 TUyNcnWBdyifheqKg0zoIh4x/jkDFZrgFj656KQo3T6s3+IcZdOZCD3OuAQ6xibNyGM/Mo5+ D50GDMy1FopoIW8Pwps/+sNx0vLIKMOOZcrIshqwl8RZqdRqiaBzIHYDc38L+90eZo9pgI+k B5Lp+rgH11918NtvrhrsqdQXQfIrqrt5NVNh73UedLnMws8uNX2SSjxqOBUqz/d5KN5ZKbqH boRPpgOjUKHeI2NRxSoiRWwjCNHPfGKC8eHjhg9VEYAw9FaNu8sRsFeq/jwmDs80hqP5pJmh Aq1pF+ybAsVXG5aA8LXaRIUsI2XgpavSjIsipFg3RDPfnw6txK280umBEKEUpw3qoVWjLvb+ bWqv/PeAHVUAY3BsOGjc15UE/VNv0pNHi04SsrMq8EVrtK8ofwCW/cDRC6TIbG+7kpVuWRAV SzW8zvtjfQwBLl0rXHxjeH3GIUzGs0lVNzLEC5Fq00kw0wNzGPGknSNWCAQTjrxMpPQ9JXOm gB6BDEpOOwwDcQ6OBjY9jMGJInlc6kh/ZcGR0mBhlf0og2/1YxjBsxxE1a4M2ZgzJuzirUjC 9LMKxsV3Gm06RYVxAIMQVFk9hZbPF7BTNQ+psFa/SMJtrwHHYAASxQWfwB6ho1BQ2N2+0F5c OvkHpAW4nMKGmSw5qECCBRaKnGRqbF9zZTSHfqxLlTqh31bqSktIZEOnKapSDbkRwrBhCng5 UiEBxcN4xeqjPTMr7dqPaOGKeh/wFezpNjKsTR1Ee6r79p0UHqn/1SfpWbEN7kKu8P3wOojn ba4huqWVO3+YFYTXeV1XkorMlnnvKGLr64BURLpNMiyJ2sxvpVrvLEX0UatcQ+QUiXKyhtK6 3CWN8ylugubFaopS2mb4HPyEALSScfn3JB4uuvAtgAr9lF+Z9SDWWM6qavPuoKb1JSimf/Mu j0YSA3mCGTCyyImKBKj4dDu+yu5hdMw8QB2TWmXahdMCa5aSZZu1qa9AmqglbXQI1v95Ssbc Qp/l3MvXi6KMTER/Nyzj+qKEQKZBB2TgOqoOtI8NNcTwtYfxqQWQEV1ESjqWPkOikCfhYSsg Vp1+dG2dLhft6Xwf3OzN9Whf7UoZBy3Mjuk/BTjyXhbpvGjMFihaccBcQJjtRg8hMNUyubjk FQqOAoVRH+Py+B1YEjtZaT3HDuMPi82wfFG0BP5nusv+yVOqpUb6HDuTBiAooQ5s3sd/TAMK roRKpChG69cOBEOGOqMOoX8UVlLevoCyvR4nbHjmhoG0mY2HElSO0ZUoOZaoJu3h5B8gPrZe wcwWqIMQ21F1DvGUQROTF69wkEAoBLQCF6gYSdrNDiV8kVok20BYckan3kE6vET7qEDsQVF9 ZIUGbyEp1T6hkbnc8W3VZaSl4K64VzU+d/OLyhg5AqykIWLqoQGbrCIMiFN4+LEI2TZ/FEKl GHx5vIFVfs+Pi9m5xdMUc8ig8TOqljK9E3jEr+uK04Oq/WdL/qQL73RDT4gxEd2sgwBMDoeT BUALehFBdg5lvyBWNPWKcrjIEoUx0Nj6rzNk2ee0gAl92qlUo+NCswUMDX3ipRsYitqIti8K /s9RIgLOE0c+CHv+nUI6or0ljMzIJYEHW1klZTbUxzORtMEKZhFTVFnkoq/glKRAqdD7pKZO XftGIhTcuvg1x7FayLmqu3teiVsn368OqDRz/PrKUuwOt4n1M1I73n/2oehFjkecmwLrL2yu kp2Jx99E8kAH/65NmTzc3hQEiAanzQX0koFreHV/oEjylVs93Sv1nkdRugr9wb9zSNEKrq8t JPdBzywrspUPFnOSSmfJgYBN27A5TCsOvTmBn699vMQVFnY6gms+Yc0FU9XqYJtA5fdQFacc fi/qIKAA5sZULkiLKB5siiPBnIXw0IOL6Mlj28jKgPhtkRTrnOun0+IbebC+RzMy0CMSlmED k0w15bLDS9rAQT/DsDsj8WPfGfXy2buuik5i9P5hO9Rm+QrfgPO0XZ7Zk7vlVFudLwVkBW13 M3W+jYf37AMrrTTzDgxEuzLjSB98BQI8mVDcRo4KVHVTxlRWWsV/bPKASKNgi280HsaS800i /iQiTRBzkZAijmoUBAu1BhrpsO22pkYSiFsQ+Yajm6pF+UiJ0Ff/YpeUt6fQGZvzYyne3/Uq qECfj+4kpw46tcjxsYr9wEPPKpOvqFkfeTEkdlSUdJH6WlR6fW23VpFXXOyYn98gvDJHWvzZ PDulzAsDdP6D/l1EZYtWe5stM99zPXQQV94mXbQJ9fE9XMqpkxC8gR0OXN3WKosbMyIxIiN+ Ter1r8tzfo+DF5nDAHBqqVMzQ9ghnxqCiNVGvb69zgLjVJ7RiNYXiMy/LyGlsNXW91hCBoH6 xeRvpGxPinSYNkVFkQ87kEeIWKD1r6ZYrVYHaMUmKmydtEjILihVY0v4F+C3BsKCzG51o5r/ x7tscbmaToDQATpSxaLRwOmfVxJh+79fv5J0Sd2pgs4iyWCrwzmEp19DW0Xy8cPif+0Ih0pu +SsghezWhw0MZhBphY02c6q7hLqEXIMUM0w5dxC5RUranc9b5nNAmYdoLvVcU0hMsv8onuaZ 1eXqHYcE9RvshDM+q24OPdA8DrflTv+n3eFCnLvVtASq/IWEAvhUNIeomzpOkev3o8tfLU7R 2Jje0Cyt4r7dsxTN6ueT9okxtwEgfwmT7wB9jry7NaCe2IfpJm7fsfyGXJ2+mSdEi15LR1w+ yAQz32aMRxA7+TqQ7tW6qRT60pB0EvsuT03t4Q3J7wvImVmmXPEGfUD+IWSqvgFr4BdMin2o 6QiwQ6m0SZ50A8GVoyHrxdnsDilfWYkfjJ+cJJgtXQSchpbRp/h+aAITeSQeUYq/o7V8bYKa CORrQlXb6L9rQq3Y6lGydhhgGy1UNarlimuVVTqKQv1VrRUkRdYiHphy0WWijssLCEbBuKZe mWJ4WeI2mcUZqWdbyoQrqghR5pYo4qSFGuriiN4pTyixpofU9kQ5nwILLES76SGywpIZQvxY yNKuX9I0ru3HJk4hr/PQxDNFa8aI2SmiFaeI1PclM1QVoOQdbhfG0RNAFRcFeSt2CCA2Mq3A YEExT/1c2spTstpx1L7BCUCxjo3LI/bCuMzRX9P24BxJrexz0yuAEbqxIWg3Y1/4SF+TpVWO cpjQc2vYVblcDCcAWKPUcR8gbR5/2x8xEbDnnBiXbgXAdblgfY9YhSdabYbaqTLwnqpg6aEH pY3zWinaYAPLUza6RVJ9UGO5iQ9JaN86OtaTKyicytspTFwJhN94K+tCKajsrOEy+xng4ChM SnFnGVQqMqx4tw1YBtHIuOfn8apRS+n7zpKHcn/gp66kDZCJ8vGUq+upYKwd7eUj0r6f0Qdl G+fk/IEQKr3pIEWAS7MNiC5ba3pt3mbsnqAzU8xCaUNLkHiQT9lXDZAf2QcNkC/BSUh8fVl2 ouYL+/QvYciYyQKXfoL6u70U9nQXIpupdoNLKuDjUBxnGeYOk80oB6vRQK7R8wZe0gCTmqcr WwcPLZ421ZoL76agVVQ1v+yWmpS1HOWdPSv361MGYcuhYOpicyv6vLKnVx53WVDR0w9y9mnN b1foK/AhAKl0sE6KBXpKBYhg7N9x+TGvZFZedrbTFMGBQdijUSp+EPCrd8c7OX2kU4vxcwHF rCzNTsKgEz31XRK/uRTGTb5K6b6PE9YFYrVMnTn9MTrJne5AmVQQmEhiD6sJWQiqo0EHrcWV x24CNhx9UaZnUKoqSd4k3tuAcocoWjJQhSkq3LOpNvFm8jTlw5PhTZ2pNLXTsU6N9hAFbgDM MQhi4Wox4RSW2ZbymmyCeZ40ntOSTZqmNKbLqtjxllIETRe9T7OSMr3kNr0ctZqVfVeoonDl Pei63yxa5ktESoOvNHMVUfhjDnyE3h0fkNIWPiLGRBR+ENoruDUvy8TP4Qr1X4WJdO0fTfae Ykzo1/P0hQKhhhUZmQ6Fc6EOT/WNXYw08emJx2wlouitoDa1l2+NVBgTIsVhsSmzUTLaCyja cUqdqosCQpNl3zMa1Hd2Kv2dtjyh5+atHMmaxWnRpt0Zmg5/Dybu8seT8k3+9jTK08pNxt40 wtPCTc7GN7rrj175MblmvRyJmqF/lmVLtSt+OKZ4fhj2mLVS459PHIbqo2BNrynPOeVkm4+q puFiw/L4+Foipj5WSu11HZxAau+WHaEA5efmaRXFl+MA7SLSjM8JpQsACwiJc+4rZf+hoNx6 GYho4bVGtML6xrHQmu8HJgZnkBcM6yIdiulII6TfJeAl2b4i1CTai1EaDqJN04QIQFVRvDF9 oHKvDhxzxIgucbVmKHv4ohHuvXRmUuJBmI/xQEemGujgZBEStuTWbWGZC+kcTnpBUpFaSk2l 1QdvDDv5zuDHYjNCAiloMyIDCiNEaujU/jq6ZASYDYcgGtdYCt8oGx+AKJh19fF9At+ug6o8 VVaKLWiaZjewuB3YRuImLGJiKC5DKoVF3pnMMNlwnsLHdMXLVdYdeZDgAvZeh3zNNgp3atFC fT9ApypgiZ967DlaYEASkzs/PBpRoaMYqy+yAtUpqd81UbHmZ4NfooBxqDKCzwVApGQnS1vD j3QgQurfgqPaUgen7sL7C7kZYtuXTKzZXJolF7OWVaSFbB96C/6G+IJ1QcF18GSF/sTzC7d2 FPeBM9WP6rLr2USbtoxKBFdFH80vERvU7rt/yhaDKl+nLOfZuvTjypjFm5DlUO0a7qhSgfsq S6TSqEAW7LQc0exrVIQ8yMyWu2QrwWmsjAY6MaLixlOYWEjnA9io5ZNFNcwV2uHBq/a2iVQM RV+BBk3hFzQpGSMEKV3hlM87OqPDqhLJkxdCFRYLPd+YdFNqrAlEifi38o8BpCKAcaDGufRk qh8YvSZuiFBjuD96YXlrCe51/otcwiNYoNEBS8r9hmTIav/Zy+ZIg8VCpXX9xGloGUu38Ago qB6pYFdaDJWrXHvoahFgVG/+RCK5T0WJBGVYGApiWMbIDKQAcwR47oixZepbr4yrPp2E6iKj R4UobWHDuG6J6ea5+KiPC6UgEJKjAZilJkboKNCs1qRIc87JcbTUEd4Cqt8kEupcQH42ggpx PWkqCWGjJsWfIUbexFbqujB/rta69tSS+rzV9vYtULbSqB4OUCVURgPOFAIykROubT8Oysci xoHEhVaVkyC0WtS1AhrX2Gk229N6QG5NVlrUBHxVGnJo+G74fzfxcerJI+IktzTQTPdYfPub dS5wiPsUmBtXVIWvx6i6g7LscUcurudXlkO1TQFbdZsDkLFHTYcpQFYMrTCEWngNyw9q0x0W +gvp1FssOscE2t+g9LpZXQlyUvvNhbgCSA6M/l849LIQZEPE9iNxFEICZyZUWisXd7xc9iIU mBgDxtGEr3UeTjbk3H6/Ue3E3rY30YJSokrvkZMN/7JV0AeyZRVRPQo1+FC4VLE+Afst5OJa 2Zf2uVY6pw49PUw8iL+ZXJWVeOiSfqZmpbXZm+AiVuCfZ6QR/qj6hB0UOiiOt1YFlKlgPB4G 19nChcc/DoqgSBw4GrRVd0LHJhZQ8V86pgSbERHCVO1X9EYoASf5CWkOegfSCWc+tEAdhQmL /ruoZ+zk+HV9bdai8eFSDqJckhiaupUqCcRpFM/l+CB9hijcsojL25/NHHJNFXAz4eotFyHj q3WU3NzUV65uB2MkndlVxGS2cqTO30376D5WcAXB0oIC331GIBiCe/I0BYT/M4ge0It4NUmT Lh9JDD/rKG5XgXBXDPVJ+Wi9d2iqqL64eEiAfovUThlgB00JnylW5aaiQ8oL5FsiQbcmJSTB K2YAqhLJjHce4bqppdFn97ciBr1oIWgOCPw8uM9Ds9LXvfOjkPXjOttTIa92Ty7kYsPO76Jg 3UH6lqChStyMRGOHG6nDJZDHrKOY/ScA2FScVte3KKT1yBh07rVaCwfhfM7nlqmhnZ2MmhZd GmQKD+i3MOcea3jtwVzxPwcslWoVFj5BuYiEn6vSLApq/56JnRtXfla3yIWsfi2Q5RCf4B8F bBSUdh3FQ0n5qUAbCCqRdRy4WBupp6n0tftlf4B7p+qvp6Nsb3QGymCgKshM8NsGAIDuHq7H XOSGMeUcEX9xSHmT4gkCB8z1y0o3g0mMjJSJPZpw4lNqqTMkJKZIGtKcMEKIFQjSoByyBQI2 KOks64BeiuoLINkictuCyM4IUqDTIDaJv7zOgFVBKoz7fq+g6hUu9RVraEnX7Uuyg//qJlUB 9OYCSGCloF0/7uX7xR0KyOVf2Yy9Ul2Rcb3F2XhaGNsA7ROn1+vBpToMQ8GFlTVFq5r4A1/k v2/VWCrkSbKS3O3uIq+SgCmknYLqu7qw1tw71SO7g5dfT08l4Lf1YIBixWkUYgBBCnHHQHNE VwBzMsxFUQeVKNETbT4VjKuMbaAzbIVkQbayAQHbEtpusOJ7uIdIfoCiUwIKSjx7bb7MALlH NDAC28cpA5Ev+2K7NV8BdqYlXu5N1C4dDX4a+hQ68dU2g4M+GnA6V/uOBHBC8Zd3yclK0adQ L/5GUe7HK4rqDSCCx4KI0zKXQ7kClzbECu9YDDShvD6oP+rqHVS1Tde7KvLy9fJOnxQu013+ w0HK0O/YJ99E9QSmM/gXjElo146rlK+YquTjMDHfScl0571APdz6261Bqu9FrWagZEoSjxqH aEmoFXoqMt+HSzRXaU8w3Ey1PWqvsULMWxGIElZSKIAjR/inq+ObtRqVDUfpN/mH+XXcVemt bkRk2/21pF1eApwqWyCeVf58OvaqeQUCOUwMgo6XzbxOq8S9hMdKBq82q/r7WCFgGURggKyr vnlY4h7idmjfg5N4MRXOiKJRCoObKmIoZvCyUyl4smQRYxykIRBnK9TbZQE9pX4CMixOVear vKR3YpWI1X+yYn9a5lTgsKxzMRXbIeWg1r/4rQSAS2MRVFD55vSxIP3JVcm1fWRfGoENf4b8 3nYc97wENx9S8Or48yLfOb2E8OgYcidtqDALVB4Nllma13mbGBXUjVSWi3VmK0DrDimPR/bt VbXlaYWZwo/quiXEgREusghRmXvle2Sd7AFGha2ChcCW/FZAPSA2eplnP22V1ORB/Ol2X3Lt zaUBmNkp+Tf3ONd+VItALu69irAeohY0IuuvOa8t7Jb5tFV5ghfGBF8QpUl2Ohhe2bptSzNs kxcz+Degj/MLBjKNJiuw5Qw+VDkClcvveyni06yrIRjwkh/ELT71G49cDqQHXy2csJKbt1w1 Ql1wrXVtpizj8vL6SO1Eo8Zukif7/VTajaFqBfqJWa6TjOhxGcgrGg6rsZRawg1Gb9C7+Qky UK+LVImHG1LwCOCtHRZiJ17imMTDqHabG4pF/UKr3/lVVnVUU3NookMSKhET+pMlMddPKY39 fAiFcHdXtx7LYkvQ6kn0eryRPhX6SkEUO9VJBlVewgBJrtwydXGJwskBg/X41egqlkEhoODu QkHhXRvU3rf1dqNwNX0MT6+8lYd8rGpJ7jasrv4lyxCAIgXGqRSropWDKLiN3qOWTqeoDwvl xSmRMvPOu8COuwF8g/J99PCeBLNRaE0OYiQngO9s4WdX3nOfgLzrVrJIMvYZp03BIVzbfVZ6 eYo+u/moDr0FezXC8jPzziIlKlkgFk+fg05VPstAltPa4hybdvaqEFaWfoMCCcSAAYAAj4CM SwZGRXwCPfnHBYZD7QbjCMw3ABFg2DOfpG08vATgYr7qISMphuQgGZEvD80LFVcTJ2JPcv6k sbHTlMMYtV+dUHqMrQyrLH/lFKpDbQxfltaoqZYWmCwY+umEl+8qCW5gKWVJOqJ6p1U71fvJ EXp1Ste2pWP8sq7g5caqCsf7bkQrtYa6sfIjWr+MEfw++SaqzWq5rrhVbl1rQl61C7/pjMay UWrKdNxDfa7Bfv6XAV0fHO5OrqpXDh+E017rBgYYjgS9B4TDp6V3WvidCJ1YfBOUhHVl6v+q WzL/rshHUKrVX+49trro2Iu75t9BvUHFe07XZqZKirrDOg25/0277f6NXAHqlkieVP7IQ0xl wSv/2vqAvMrhYfEfnp+OD/SII3fyloDVjwnTjEYvqj17fmHlIyLJNf8N+PcgQ+8ugVgrSR5Y EDFVAQxwlOifngcBE31+FQ97en95WkzmsMO1YDDql0vPd4QBPrXVz8uiqqZ8Vd/XsNPNAqRo Y41g4XOcHHlSKoNAfU1RU4gqbxMhy0ujowZV8oSKxY3IFgqjB43Ck9vss7IxQkRS09fGtbyg XJdkK0VVU8tyy5C2oDePNVIrGQ9vK1mtJAtAv3Mpz1vzGsfB+oNU49NwDK8OGMWf0mpnNCGX AzrQvHq/fSsdZZCCTuBf9f6OQVwpejKlT11elvFdK2SrEu44mryjO2OvAB+XifV9oR2ScT0H HjRXKVJIF18gH/QVaEqg5kCe5dIN9BIrma+hkrM1XGDD839vNuQk/htAjmQeV8torFRdVYt3 hxXW0N1IHUhN0XEKIt2u9sZp9hD/9ytjGPV2/ttww6ir4LzZL/uNJn9pIgMbAuF/eIIR7MGf I/0D/XQ+CVqXshwdoEwDxToONy8yQ0MVw41mp2sWiQVCOQgmDjJSEZZXbOA+Tvspg+6gGkA6 vmZ5N4CiyIqdAq2g/nZNTLbXbCSIrifSfZl8a3UhP9aT/5qLoonIu+jByqjlaDDFrm0uMol/ LjUxgHy6RTE+TOFfkl6LO4JCsBYtx3S6BTElX8H1dyyubfwoXyNFfooaEioZbZdBc42NE5B3 3MFVpt/0Q9xtdGv0or0zZTwQELXLhQC6EoWtTcp1gAtEwVXy+7LhfbxJ3Hq9PTFrmKJ3dd1V sIuuKDC9FyEF5Wlk2+BMoylcSy0FHSvAeA5XuwZEFAI+G/zSSGl0oH8C2orke0hQcyEeAH2j 7+kbPMuVA1ijGOyRyJWA/uc2+FgbbzkJRtQIiHu0AaoSQLgtwLwbrTXOaqwmoEytracz/lpX l5kAEGFYZ5PZFjlrrLfGVNF7U6to15dp4qRHtYZVKICNUCD6CCeJOTWqpxoXH23uJyypF21Y pRU9gW2vIlHZq1PpOiZHIrLCGaeVFE6KIYMh2SL/f4KIMVvCVOjI2aCd9ZjaQVPqu6eWpVkk 7O2Wi+i9V85Dr9DhpN7yUo7nW6o9qSUzRI2X0NIzj7OcVbo2lXLeCMkj5KDceoMDKuyvYV8V LgXqvRfrmoyenCpGBxxEWWK0jGadmPdUPYp/FG2fWiB3PJskiiFCkQdZn37oytWXAUJywtqQ ALTKA1jIHCzCwuqOSVEOL5SW//Iidh1mKupsqS8ciNqA3foVGlAbtJeUexf5b39oqFq33sqS C9wQ/6Vn/AbJAWOn9mZAa8Z0IWfDK5yQKJGEI0qwenBHo8ZoP4A4wrEOR8La5vQiwbzadIMl VbZe6OdygBl3hCQHjwrpNWWqTSAPVLbSQGqWKPU/Yur+PS9pMPxPukkol2r8WWSgu6VQ2bE8 llNbWdhd9magfUlZVtbIVHVn93umOCVhT6PeIgp3kiKfMu9vL10DllLhX/4VLkOUgHsLh839 0hXufLN3baGPDRPndDX17CDDGT0FqTtHHrBXRxOOajjk/qPgqcBTnK4FKO/wtPMxCMUCucCL Ctz89p2IsyfHgMnCMWODb6G0px5MoUt52UrpwhIH5IcW75t/iOnUTGJSZfqlGHfbCjwTgQdl gh5RZzcT5rkDKkkPs3Jj6paAH0PbUNsMqIR0tOvvZ1A3cchdef6ks9ZVz479lNGopaG8qlv/ ATy1YIGNLJEiaGOpRVxj19TVechBD9VliaCK6XZtf9y675p3K8RqfUQT0uEHPpwOq2jzaCjS H67cCu2BEZwtRIJ4BLxwxcIcqp8k5AA/cMSyZ1TzWChFOgj5VbDSo4O+fVdVzaJhYZq67LWl GrmFy11WwhVWtMf0IT7kgI78q/RFO75lIkl0vbk0h0kMNeAj7zicbncVFTZUkLV5XL13ZK4t RYeq9QIUkhtRICi/+hAoRTnBPxW6CsqqsBJlGkjj1+rcq5irGfQfEUA7qJh/87CV80K0E1WE fIOS4kkfg9ah8iQY/ZXdFlyNXNpxqQBEBinMZf8Z58i+1HJYUZ0Cgqso6qpYQZLhnVI6KKND WkI1RWu0qq94/hEOd/Jw8PDXin3wX+iinm69glpoWlY/vxTUUArWZyOgaSNPb07uSyw7X7ly VQnXjPfFloy+Dj64djfyA7wiJyru1fQ0JQ7caSuXzV9HyU9D9BTM31vrjJufV1Nv5D37gfWB 06JlZ4wn1PzW+xakCFnnUlNqPxBAjtcHsu+ux6pdNz7VpKbvyimDAaHZv1XfuKDVzh3UanP+ cRXbnGyKgxnxinKJggsFaAciCkYg66WL634dJPkAZCAvZV+w712pnxOFJ12jLvd9FAUN21LN +EALuKQLQsJ/bReFTAm9PMRU/dwLNTpBO/p7xFKv8sS+vPqrRR/3AycpCY8XZgEo6GYsgknL oEPy9ouPfep1MwyMiANoPLonBQjYVnNd3GJlA6PuLmgPN/k3U1ra39GIKOwcKqMTu34PgMLI NBq66FaGikuASTL0sR89SPnRKlj3SQwxXB4gCu/rLW7y0idivmkAFtPf7pmQ4JO/hsMaW1xk vnlf2gquRKUEv705HgdkehC18avyW9V/uOVv1dRdzaEUHyD3ScsViFDMj049rnFtKPsNf3vV X23NtpDuMSRJIXALG0C0Zg7r96cqpqwXmAKnaIlfdc6112iXRaqlTIcHt9D9BFTO2TaCxlJ6 Roq+YfNVgRhWCunu8/AjyoGQzlSlui6e+lS1kMXTJvPoNpdPIm/eRaaAX9V7nWBAA6kS4krv uffr/HEKYYL7ImwPINuXS4j+6nHqERaLA19Kk1sk5bjaplpWjE6tdqArjS/uEh/HLITzb0Mo Tx2QFeK31bBEUhIQKJDvrbSobdFKmpWvj49tC+pFRBtlHr78tEmpvuEWJPIMsruhZ/19lCfI FxMKAq7W/psC1EjmfQexlu2N+FMjJUD9Fxp/Pl0dC/G0zYhEjPmHS8rK/gn8BFn4VDwqJJdg EouJjvXeDR7CJVkUFgvpe4VXQAB4ISMBmkLvEhSNB5YU/BYGlHmymkhI/zwGn+V/6b5hVgoi YZ2gjWWfU9xnukrWxw+7ZVqjR1kP+mts5GD73zydDrurPLFdd7AY3waCXwajeSa+o8PFT6jn 9RVt3YSF6p+G40lFB56NtEnQcPBFQi+COGF1KsyjeTrw3UMJ8IEzqPgp6FVQ9kEVtEAZjzZM 4mIpbiu4bGLPgmtolWim8WMukWBHuUBdmL2P67CqgSr01JFpyNVXU/MhRhWocWSIc05fWE2a DCsElnEZQmcNV+2lm7YhHYaAv4qojGWptq2g+6hI2n2gftWXrkA2Wj+DD7xnwYoGxqDyqBLa Liulw2TrJAYiqg5KfgMri++gtxMRRLXztjqJ/60UQPNQ8hFK44oE7+IG9F63+MWEvPxginmU EvXBZVi9bgVhzub/AAmmtH/dGatWhwryhQq919TeLD4FLgiOr86/CQBC8XYLxY24+M3XWNco gkMgJfwl+ATbZsJBqVOmEXhd7SrdKAYa4nkF93vwCGLjq3n+qgoC4gUEzwa8lEM172Fm+/gp 1HX83AbzfmiaeFUzOnf6XEoMEu7dJlzxilZQhRGoswYiEwqKtP6aqHFPt5eW+FNLksCnS65I f70rz6yaIKM4JbXhMSM6aTNOuGlFo48EQLi26/uRWy2d+C3TjeBCPms29UToVDQGYmouKqKb LGCt5KJCLOnokGxFIzYkRhEWKCZecNuorMBoWaODWVCIa/2//FGAOEPVz4gZvnKucSAXT9ff l5BpXYVIYfz08/vKejX/KEGec8KKlweaGexudPPffvJLonWXzSo4HtCMsRx8cK7UsxNvSxpl ZvQ7c0lBbV/c/rk0FzUIq/7R6/LWvRjX+Y2b1d4oFWR23c+eyC48moPIAjjwgohpImMMeIB1 mnFoTS4gzqyhh8goKyCf8jcLU+TyxpjlcuFpnaaptZqxaI3Xdz48Bob8FIWLFb1u3c+paqBm 68gbbJqCiJBqIPuI9QnPpsvHhogXPCOCsqgLyBk7If6iZApbZKHn5q0cyZrFadGm3RmaDjXd z4rs+oWLFb3w3c+p9KDIrtX0YBBOKHZBKQGDbhYWjvx0Uz9jc6stK3tM6J6+C11CewrIF19D KhoPJOkjrev7S9vQgIPhaTGuq6SkQhjnoBXIpcr0OAo7ppf7gYFFjt5obF9mk91ZV6FRlX2O dZBFTkaLdc12d2Iqt/sYZ60m0cVayqa+xjlWBH3kegiPUbbxS/qWilpG+yhYq0eKCTX0lK1X Vthkoxp4sUcgv6YWCEpaIkt/X3D1JUC2uZcpOVmHaKoUryt/iiKAiyXHDI7LDgWy+/GAszy5 7IWBcJLStVKZ+7aKkjboGE6mfY9mwkmmCr/FHhd19EzxdUmonzwDRLjFd4SDgwXbzbNdSQc7 IqLPcCyTkoc8PBD/+qTTKFgNPLJewqITJ271KtUEkep9qceiiLzw+RCr/3Kq4aCt9XCoO27c 63kdJx5pvI6R6FG7nFnnkE56C28mXhrFC8X6IacFSAxMJCMYOTY0ANNOwMx4ajWMNJbTmE1a QDQw0yBNMgI0HsnoiSbE9JqUaZymqKSasGlEpigcmerSIgDaSQymOiKa2GnwpsbcmqZpqKac jJl86ySO05hNolo0qNPcTcLoMhA6SRqSFD9MDowmkTIgJMrT3E2OhDT60+pNytIyKk9JUOBq OH5hANgZymWOTHUkgxTDk+5N6fk0/tPnTd3iNNbTyU3PwjTD06FNyc07H1lG4hi2tEjz8/MA 6+vr6+Pj4+MA6+vr6/Pz8/MAy8vLy8PDw/kA9fXx8fX1+fkA5eXh4eXl+fkA9fXx8fX1+fkA BU5MTkhOTE4FQE5MX1yNsJEhgV0ojuHAEBQOKzcAMDl7PysqOCRtdaAGHR8cHc0iSkyLgxEI Dng4UDN2Gn59bk6JwHAXEC0myEs2Oh3wFXmOgWZ+MGZgZGkha2VhfZqFbGZjcQvQ5MGB7Kqb dcRVnxCCx5WVhYCDXIa8sBS0rbDAo6wZKaWnc5CIfrgVxkuaiLMC8fUNi0gKEt5bQLSbUKoS g8xMCMUEutDiLWrx8RtFJSQ4uK0ShxutxuC7fMIWH+XHvklbcBUimXxh9+U8mmWixToMSxmh HwUviIhkO1xag9Dh2KuwOai3VKjNopfYQMXb3B5teuP1KCLhpdXjHWE1BLUUVRrgSwMBChcd DwABZw89LPR48WdvZ4+aD2DUUljHVEZ1RegSPwVxfWl4Ebt7fG+AaL2fWC8dHp2VEoDFVJjQ aN0MuYXydJdrwD0ytbVRhqa9VFaKC+Ps5pf3BAvx1dnIWVDO+riNtYZe43aA0VXOqEattvy8 wEuPsoUa4BoWoxcVGIYMFEd4AYmRnUslzaxDOCUECBQTPy6rGtaFITMFWEknIb6ZCSjiKhIl UyZPtoBYT0hbXl11A1lNdTNHQqZQHR8CT7p5schHdJN3DsvJD0MwD+ECbAwSEml48yIOS5YB IZn4+uxn7yl3fwMZb0lyR7mkc0y7BbpJBbmPn562Emyh7wF3gRKGpq27uGnFk71cS5vfhruT g5WZ+Aj20NuqnKqi7YtntJup93vPyv/zuLsklPfjfvuSFfmVGiIyJBkJRh8/ERo77z7xQQDc ihuJFx+WZtI0ywpdzXzVJTcMc1IFzRMvC3RcQEMLZ3OJhvdvOgNwuV1q9IRANGpiAV9TtX4W U9VYb0mJhUGQtoGB1FueQlL5p4ziNiDb9/HkvFuKbd4DS775HpPTisyb+hipN3G/zmwzqrBK rzPfOMf86pJ9sbopOBgRprpVqjT7txu8pTNBPu/b6jr+YywdOQq4E1KLmGVLX45FTnRCfDJs oE+RXnRt4AxPZnvSK7+fFbTVo1Koh5Sx0SWmUBb0o98WzzuwKjAHhrqAPi5VpkftxUe/gnVL X3Cq4ejvs8StFO7voKcyaz8CMiXjFQPY4ltP67fTKgLrcc2dEvnt82Nl9+qMFu6IJV8UdVki mocPT3dwMBZ2s6K6fYvq17tqo/svd79gmVDve/GNmj2R0Zk68pOsoundlheN3iz5WcNvMlRx 9rjtY3fk/QpVz5nRIA/ULPEqKupoLmxPzHvSjCYx0S7PKidVYNihe0ILelNKlElUS1Rv3B38 CFCndmDWGFWi5w1ZplbDcEN6Y1Sn4uiO6Jsg6sX25FueWTPoHVEG0NvQWZ+hhc7q6f5RIj/I 4F/pwrVAODB5P43OtfvrDTzbg8y9G0hpcSJtXhsAQP8mY/VVg2j+HQopTB5b2ZUZEuQrVplV X94qQPSeBRVMB1F+4gLseBRQAF1COltdN19bEVJWUTJVS9zkSylEXlRQAFciAjLAoZp2AORw 4XSbIat4HHpO8AJmB6XpiGL3PYFu2MdjJtmRALbVgyp8KOUDg4NeZaDRXgAC4AU6YqegWSjL eRTI2QIj5ubfNbyQyuzZtBCDdMaQUK9xpIO6hUej0Le6m6uBVmJhiPGXpl2wq4Drv1W4lZlG AEWazf5ZDMhIBk9kTSJ+En+QeCpDDC1hbv4DdiuLLICAM9qjoCwj8CH/pRvKpaYvaMBMTeSP iUgfkNTPVc6vgPQISjWDR34X+nA7MoFMx9r+M6qNJ9ejMODh+GCuEPTkIbUWsmjUclRS2PpY dYaAM82i++oxMpDhjewNy8lHb0n7kqK1OEwbd1UztrATtCTCQGsirCpuowFNYKdm8vH3zagJ QOPpati3ALrsjwTaqahNAIhgo0UFbYEKGMCAC+q/WnD0lHLGlFnS6WVRr6ONQKeUy5mUs3wu QgFZoZCwLajARQrQlkggWU2YwQhLCYlAxn5DNlN7FSW9JeosMErHQDDyOjLbxjvpK6L7DEKr 0J3J6ucaT/36SrPbFW4XoswtUbPU80pzC4SVcWO7MR3ykSasugWKag3pGExJYNEIzlYLC1AZ MEIGX4HZg117d1UcMIecnr5tYZClnLQAaMsr0cb3FvL8/oJ6DfGCHyTougVBf6j4qlslCH9C IHudmf8NqfSN5AAgYb2SOxt9ZFYYcppSYCis9QQX37pZjNAqRSiZrg9VAKVLf5k4qMJDAHx5 rDdMfalLFzQBM4y1e5U3zSEaZgsx2dZaL4j1rWKQH6JTBsYjkWr+vBqSE0gUhdVWUPConbNf QcDtnnBlzADAFAivh5bVfhRoyhp8w5MQTQQ4NCzT4Gf0iMyawGm0pqicmnBkhA+YmHKsaaCm 1Mia/GjQMihgCxwlNAIALj5nKz0bFj0IMDYkLZhzSKhCOUzbmERyWGlMpnB0mmxpWKYkIJo8 aSimFBCaDGn4kgSATQAcNAjTNE0wLDQY02BNWFA0tNO4TaykNODT6E388DSY04RNgIA0hNOU TJBk+ZJsaVimQDCa6Gn4pgQYmjBpKKZQRJpMaViSoCZNtJg0jNP0TeCsNETTWE1oaDQYGQA2 EFiF7Gc/YcncssjETaxcNGjTdE2csDSg0NBk/NPITNQ8vJMQDk0AcDRY0zhN2IA0pMlQ2SZQ UJpQaXCmcHCacGlQplBQmlBpsKawsJqwadCm0NCa0GnwpvDwmvBp0IgyfUamPTiaS2lOpkFE ml9pWqZVUJpzaXameXyaZ2lipm1omptpnqaRlJqPYLGIk5fEBIWLjYX/QK78uq6tuQa0vrCw /bqA0U2sv0W7iq+iWdJ2jKLDfOHBydG3AoPOzs/0gqiRcwEj1+ayfYi5AoQODNFy1RcLDyg6 LAgofpgb2wAjKSYxDy4nLzR80Um3AHNcT0tbTlKi0VNLR8P6YGcCZHpwZnFlD1nNMNvukGeB koBipYaYLj325UoNng+tEWegi1RQ2kSx9Ybw2sZWwMhpillJ8vVOCOWNMjwZtVUqDjaJacAT Eg0JPK3ENTRpNAA5I2EaPCU8L74sM+DNgxsdGB3fFulAzy30YWIccWhrwOXtlaaxjJWQYZ4e hZerTZo6oA05uf4zTzxasQ2X8moqvaPD9MTStM79MTTHP0yzzv0xKDHP0/PFv0/PFrgBKTGN UWITs/db7VdmBviPudb0BM/UqGCZeaGvUJc8ub3xwbilrxewsLShxb9kM8upPo8bDG6kxzbE odqWWe9jKB7znyEWVtnfviWmN3pi1pCjNYcdn0jmoXdzZDdvmZ5suLDNM8WCk7Sns/Oa58wX vbGtruG3FvmbouXXwWUryvdcvZrQ9jzRR9zdaUqb+ppKxMQfoNL3+AVzz+M6K+ARUfn9hPCu QuE4CQ427UUUdPhQ0wRVYm3VyLefXKtpPxXt6jroZ+SzcW/vAUIlMGVpUWx+fkZBc1taU2om FXfyRmkMIC0cGhgaAhwSEBIcGpdCDnt2adzo9HF8sfM+fDxBanViCt8TX8cBi4yVCZMUhyK+ ugnadjh4jriVKuOAytfThXjr0xwd2QFj9nLIY8iJngbn+hz6pMj/8uLJ5kEGOiAgJ1QyNPAw QzFDmlqw1EtAV0xQVm9wbWXjaW5jMWFriZbnpHJ30nsZDBAOrR+1Be00BxvGqPDPt+USiRQu K316Djom01oiqTo9vjI3j1Y0+slCzm/C299NLOzx5O42Q/9rO7PLDySalpup8mSTrJPZq865 48q+PFrhPQt93WzlS0FFXVrHjVLuElLeasy48cd9PjwMuO7fC9v02gtnHIpwaSsrvjw7rRk+ nSAxdnTKp+OWlrga7DWHft65AK+66c2UysXBYZYsk1Ch063tEM1LG8PotqmNl4c6/JeB+tzE sf91nJX/zsMl6dLbyO7WzsOR8BnR+uPve849ho3W6uw16iTbaHTC8Ufr/LbEVSvbyCwCE99a HPUfFmFhejkYMi8x/hpwxvh1eoznlguW46xq4sfPflOlbCQbYVpG6UJWWAgAaUUXSUZM6yFC HgNA/5aUKCkRx1Z4Uq/aS2W7Rn89SpVcRMCgVfHc9XiY0szttoRb5QYVoqp6rfyk/esVW64N HdMNZjbatqNW6Hve0s0dypWGs3mG8aL2zDbQVP9y75TVU130whDz0lQIzkoBVPhC11EEAiUu KyBEBbpmPCpz8YEMfh8CHX+ynWEbMOy2Yj201Q8DqFABN92Dmhs3nVYZpxYcViaJbn7yrWRn nZHIrZ8VgVkvr2AizbCg4eW6BSu5gFHQxJDqBOGA+Q+f/Zznn7uEexA+wVyO2Cr8Hbfsdqn0 zMevKWXedwaxzIK4ePX0yfyx6qt04VQVGrDrogcHAD+C+p/kCWvjHgocgMAKFAYBdAdSHctz LWhyQAUGDwlkIgUQDdEMBHByOHp6zHVnxyZ0Hgk2DAv6oIQ6NUffuRVrkJxDZVOvddgAokS+ iYj1r3eohZxCJZmwEDC/tYqN5Sqp4ttFfYvJEYyCf6oimtYSnxr0hBXz69Wu/iOYg/r17e3k vLrVuvNQ19vTlVrnxI0f7f6kBuMgheCw5vQ68BtiziuLVDYiJK5V7ecuv95FFhIRfFgADxQc DQ8WBHMQZ/JgrLamxvqbq3wHMB1XfqCEUmRAU0NdREhXAHFMPkFEMEExOTIsNM3I6m0Ay7q+ 2s+2zMQG38HArq8a3usxAN+iopi4qoyx49W9o7y8rrZG9PWcppWuqVHoifzvd5357UGO9T8e qKrd1Mr1ZejKCyG11hDTeMJ/ya4FGVEXaCQaA2QJr3Cn0zZaAAD9ZRJRUk+Q7jUKwwsWwTxD GJAGVZFKQxB5ZgVqBHlBgii1gu1PizACRRB2Xamxqn3AP/5hQcwScRIxNfE7xGU1yCAyigsm nQSDIIqydwsgfLJxCyBGslsLML/kv9O+TTxTgWZutKBxmg2EUmbJjois48bT+XgcjqZ1tJ0/ sdjqX2MUyXWmLE6acGlHkqwtTVSMO2Nj3MkmplwvmhxpMKYsXJnUfiRl0/xNbsQ08MlwfSz7 fz49BPhyFfXx9qQMSPiIZRqfZ8XE3TF6BMh1doIETVQqNQGEvUIJFEfBeRRsFn547B1OZY/x xFE54uglgybqlwj1svdOgrfzuO0VD956k8kDfS4OFv14//p9CPtKxSwqAtjS1+j+RTV9MoAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_0009_00001D34.0000201E-- -- 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 Nov 23 01:51:00 2004 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 BAA21920 for ; Tue, 23 Nov 2004 01:51:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWUGF-0006OT-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Nov 2004 00:34:47 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWUGE-0006OO-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 23 Nov 2004 00:34:46 -0600 Received: from [192.168.8.4] (ams-clip-vpn-dhcp125.cisco.com [10.61.64.125]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAN6YY107609; Tue, 23 Nov 2004 07:34:34 +0100 (CET) Message-ID: <41A2D9F5.5090706@cisco.com> Date: Tue, 23 Nov 2004 07:34:29 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lutz Mark CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] PROTO-39: Template ID wrap up References: <41A2306C.7090103@cisco.com> <41A2581B.6000800@fokus.fraunhofer.de> In-Reply-To: <41A2581B.6000800@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 Mark, You forgot that - with SCTP-PR, we send the templates on the reliable stream and the flow data records potentially on a different stream Hence some potential re-ordering - with UDP, some potential re-ordering. If you simply change the Template definition, you could confuse the Collecting Process. Example: you change the Template definition from bytes count to packets count, and the new Template definition arrives after just after the first associated flow data record... what will the Collecting Process do with the first flow data record??? It will conclude that this is a bytes count, and it's not! Regards, Benoit. > > >> I'm trying to find a solution for this issue. >> PROTO-39 : what is happening when we reach the maximum number of >> Template ID? Wrap around? >> Let me propose some text, to be placed in the section 12 "Template >> Management" >> >> In order to delete an allocated Template, the Template MUST be >> withdrawn through the use of a Template Withdraw Message. The >> Template Withdraw Message MUST not be sent until sufficient time has >> elapsed to allow the Collecting Process to receive and process the >> last data record using this Template information. >> >> The Template ID from a withdrawn Template MUST NOT be reused until >> sufficient time has elapsed to allow for the Collecting Process to >> receive and process the Template withdraw message. >> >> A Template Withdraw Message is Template Record for that Template ID >> with a Field Count of 0. >> >> >> Your feedback is welcome. > > > Hi Benoit, > > I think we do not need a withdraw message in this case. Just sending a > new template with the former used ID should be enough. > The collector can delete the old template after receiving a new > template with the same ID. > > A withdraw message might help the exporter to signal that a specific > template will not be used anymore. Then the collector would be able to > free allocated resources. > > Regards, > Lutz -- 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 Nov 23 04:52:17 2004 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 EAA21531 for ; Tue, 23 Nov 2004 04:52:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWXCy-0003oY-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Nov 2004 03:43:36 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWXCx-0003oS-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 23 Nov 2004 03:43:35 -0600 Received: from [193.175.133.240] (kaitos [193.175.133.240]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id iAN9hVe13277; Tue, 23 Nov 2004 10:43:31 +0100 (MET) Message-ID: <41A30643.1020906@fokus.fraunhofer.de> Date: Tue, 23 Nov 2004 10:43:31 +0100 From: Lutz Mark User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] PROTO-39: Template ID wrap up References: <41A2306C.7090103@cisco.com> <41A2581B.6000800@fokus.fraunhofer.de> <41A2D9F5.5090706@cisco.com> In-Reply-To: <41A2D9F5.5090706@cisco.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > You forgot that > - with SCTP-PR, we send the templates on the reliable stream and the > flow data records potentially on a different stream > Hence some potential re-ordering > - with UDP, some potential re-ordering. ok, but we talk in the context of the wrap around of a 16 bit template id. There will be no re-ordering. > If you simply change the Template definition, you could confuse the > Collecting Process. > Example: you change the Template definition from bytes count to packets > count, and the new Template definition arrives after just after the > first associated flow data record... what will the Collecting Process do > with the first flow data record??? It will conclude that this is a bytes > count, and it's not! This is a little bit constructed. ok, the transmission of the withdraw message makes it waterproof. what about: Disused Templates SHOULD be deleted. Prior to reuse a Template ID the disused Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdraw Message. The Template Withdraw Message MUST not be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last data record using this Template information. The Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template withdraw message. A Template Withdraw Message is Template Record for that Template ID with a Field Count of 0. Regards, Lutz -- 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 Nov 23 07:55:46 2004 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 HAA05844 for ; Tue, 23 Nov 2004 07:55:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWa4T-0001rH-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Nov 2004 06:47:01 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWa4S-0001qt-00 for ipfix-info@net.doit.wisc.edu; Tue, 23 Nov 2004 06:47:00 -0600 Received: from [64.103.83.245] (dhcp-lon-bed10-air-83-245.cisco.com [64.103.83.245]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iANCkw116690 for ; Tue, 23 Nov 2004 13:46:59 +0100 (CET) Message-ID: <41A33143.6050405@cisco.com> Date: Tue, 23 Nov 2004 13:46:59 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] 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, We know that information elements can come from the packet header, the characteristics of the packet itself, or the fields derived from packet treatment, as defined in the "IP flow" terminology section. IP Traffic Flow or Flow There are several definitions of the term 'flow' being used by the Internet community. Within the context of IPFIX we use the following definition: 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 [RFC1889]) 2. one or more characteristics of the packet itself (e.g. number of MPLS labels, etc...) 3. one or more of fields derived from packet treatment (e.g. next hop IP address, the output interface, etc...) I would like to propose the following convention in [IPFIX-INFO]. The information elements exported after packet treatment would start with "post" Example: classOfServiceIPv4 Description: The value of the IPv4 TOS field observed for packets of this flow. postClassOfServiceIPv4 Description: The value of the IPv4 TOS field for packets of this flow, after packet treatment. Feedback? 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 Nov 23 09:36:04 2004 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 JAA14367 for ; Tue, 23 Nov 2004 09:36:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWbPH-0004Qm-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Nov 2004 08:12:35 -0600 Received: from diotima.switch.ch ([130.59.4.87]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWbPF-0004Qd-00 for ipfix-info@net.doit.wisc.edu; Tue, 23 Nov 2004 08:12:34 -0600 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.12.11/8.12.11) with ESMTP id iANEBGDC026984 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Tue, 23 Nov 2004 15:11:20 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.12.11/8.12.11/Submit) id iANEBFku026981; Tue, 23 Nov 2004 15:11:15 +0100 (CET) To: Benoit Claise Cc: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] Information Element naming convention X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <41A33143.6050405@cisco.com> (Benoit Claise's message of "Tue, 23 Nov 2004 13:46:59 +0100") References: <41A33143.6050405@cisco.com> Date: Tue, 23 Nov 2004 15:11:15 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Benoit Claise writes: > I would like to propose the following convention in [IPFIX-INFO]. > The information elements exported after packet treatment would start > with "post" > Example: > classOfServiceIPv4 > Description: > The value of the IPv4 TOS field observed for packets of this flow. > postClassOfServiceIPv4 > Description: > The value of the IPv4 TOS field for packets of this flow, > after packet treatment. > Feedback? I think "post" is somewhat unspecific, unless it is clear what exactly the "packet treatment" consists of. It assumes that an observation point has access to these values in exactly two points: "" (meaning "pre"), and "post". Looking at your example, it seems clear that your observation point must be "inside" the packet treatment (integrated somewhere into the forwarding/filtering/classification/marking decision logic). Note that this doesn't fit nicely into the (idealized) IPFIX architecture as it currently stands. In any case it would make sense to talk about "pre" and "post", not just "post" for all properties that can be changed in the course of packet treatment. But the real question is, shouldn't we specify (pre- or) "post-WHAT"? For some treatments this immediately seems to make sense, e.g. deltaOctetCountBeforeIngressACL deltaOctetCountAfterIngressACL deltaOctetCountAfterIngressPolicing deltaOctetCountAfterEgressACL deltaOctetCountAfterEgressShaping - where the actual order or presence of different steps will be highly implementation-dependent. The clean/naive solution would be to have multiple observation points, which could contribute different values for observed properties of the same identical flows. But the current IPFIX architecture doesn't support this. Now... if templates could somehow specify a "scope" (or "observation-sub-point" :-) for each field (in addition to enterprise/type and field length), then multiple instances of fields such as "classOfServiceIPv4" or "deltaOctetCount" could peacefully coexist in a single Data Set, without any explosion of field types. What about aligning the Template Set Format with the Options Template Set Format, so that (data) Templates could have sections for different Scopes, just like Option Templates? (At least that's what I understand the current Option Template should support.) Then enterprises (or maybe even the IETF) could define Scope Field Types corresponding to different well-defined points in packet treatment. Regards, -- Simon. -- 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 Nov 23 11:11:27 2004 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 LAA25885 for ; Tue, 23 Nov 2004 11:11:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWctN-00078A-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Nov 2004 09:47:45 -0600 Received: from diotima.switch.ch ([130.59.4.87]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWctM-000780-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 23 Nov 2004 09:47:44 -0600 Received: from diotima.switch.ch (localhost [127.0.0.1]) by diotima.switch.ch (8.12.11/8.12.11) with ESMTP id iANFleqI029319 (version=TLSv1/SSLv3 cipher=EDH-DSS-DES-CBC3-SHA bits=168 verify=NO); Tue, 23 Nov 2004 16:47:43 +0100 (CET) Received: (from leinen@localhost) by diotima.switch.ch (8.12.11/8.12.11/Submit) id iANFleZ9029318; Tue, 23 Nov 2004 16:47:40 +0100 (CET) To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Re: Proposed fixes to "Template Set Format" table X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: <16803.23127.380315.836409@diotima.switch.ch> (Simon Leinen's message of "Tue, 23 Nov 2004 16:42:15 +0100") References: <16803.23127.380315.836409@diotima.switch.ch> Date: Tue, 23 Nov 2004 16:47:40 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Sorry for following up on my own message. This should be just as long and even less confusing (only the ellipses are different): 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 = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | Field Count 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1.1 | Field Length 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1.2 | Field Length 1.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1.N | Field Length 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 257 | Field Count 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2.1 | Field Length 2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2.2 | Field Length 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2.M | Field Length 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure H: Template Set Format -- Simon. -- 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 Nov 23 11:14:20 2004 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 LAA26348 for ; Tue, 23 Nov 2004 11:14:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWco6-00070O-00 for ipfix-list@mil.doit.wisc.edu; Tue, 23 Nov 2004 09:42:18 -0600 Received: from diotima.switch.ch ([130.59.4.87]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWco5-00070D-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 23 Nov 2004 09:42:17 -0600 Received: from diotima.switch.ch (localhost [IPv6:::1]) by diotima.switch.ch (8.12.11/8.12.11) with ESMTP id iANFgGxp029162; Tue, 23 Nov 2004 16:42:16 +0100 (CET) From: Simon Leinen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16803.23127.380315.836409@diotima.switch.ch> Date: Tue, 23 Nov 2004 16:42:15 +0100 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Proposed fixes to "Template Set Format" table X-Mailer: VM 7.18 under Emacs 21.3.1 X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit The template example in Figure H of draft-ietf-ipfix-protocol-06 could be improved. The current version reads like this: 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 = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1 | Field Length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2 | Field Length 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type N | Field Length N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 257 | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1 | Field Length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2 | Field Length 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type M | Field Length M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure H: Template Set Format First, "Enterprise Number 2.1" is missing between the second occurrence of "Field Length 1" and the subsequent "Field Type 2". Second, it might be better to use the "I.K" syntax for Field Types and Field Lengths, not just for Enterprise Numbers. The "I" Index could also be used in the "Field Count" inscriptions. Third, the ellipsis between "Field Type 2/Field Length 2" (the first) and "Field Type N/Field Length N" suggests that just Field Type/Field Length pairs should go between those, but every type/length pair should be followed by an Enterprise Number. So here's my suggested replacement text: 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 = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | Field Count 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1.1 | Field Length 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1.2 | Field Length 1.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1.N | Field Length 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 257 | Field Count 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2.1 | Field Length 2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2.2 | Field Length 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2.M | Field Length 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure H: Template Set Format Slightly longer but hopefully clearer. -- Simon. -- 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 Nov 24 08:41:04 2004 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 IAA23473 for ; Wed, 24 Nov 2004 08:41:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWxA8-0001qb-00 for ipfix-list@mil.doit.wisc.edu; Wed, 24 Nov 2004 07:26:24 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWxA7-0001qW-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 24 Nov 2004 07:26:23 -0600 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2004 14:35:04 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAODQJCu023088; Wed, 24 Nov 2004 14:26:20 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4528.cisco.com [10.61.81.175]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA29073; Wed, 24 Nov 2004 13:26:18 GMT Message-ID: <41A48BFA.4030309@cisco.com> Date: Wed, 24 Nov 2004 13:26:18 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Leinen CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Re: Proposed fixes to "Template Set Format" table References: <16803.23127.380315.836409@diotima.switch.ch> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit See my earlier post - Stewart Simon Leinen wrote: > Sorry for following up on my own message. This should be just as long > and even less confusing (only the ellipses are different): > > 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 = 2 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 256 | Field Count 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1.1 | Field Length 1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1.2 | Field Length 1.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1.N | Field Length 1.N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 257 | Field Count 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2.1 | Field Length 2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2.2 | Field Length 2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2.M | Field Length 2.M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure H: Template Set Format -- 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 Nov 24 08:45:18 2004 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 IAA23786 for ; Wed, 24 Nov 2004 08:45:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CWx9W-0001q9-00 for ipfix-list@mil.doit.wisc.edu; Wed, 24 Nov 2004 07:25:46 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CWx9U-0001q3-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 24 Nov 2004 07:25:44 -0600 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Nov 2004 14:34:25 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAODPeCu022870; Wed, 24 Nov 2004 14:25:41 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4528.cisco.com [10.61.81.175]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA29040; Wed, 24 Nov 2004 13:25:39 GMT Message-ID: <41A48BD2.1070600@cisco.com> Date: Wed, 24 Nov 2004 13:25:38 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Leinen CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Proposed fixes to "Template Set Format" table References: <16803.23127.380315.836409@diotima.switch.ch> In-Reply-To: <16803.23127.380315.836409@diotima.switch.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Simon Leinen wrote: > The template example in Figure H of draft-ietf-ipfix-protocol-06 could > be improved. The current version reads like this: > > 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 = 2 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 256 | Field Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1 | Field Length 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2 | Field Length 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type N | Field Length N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 257 | Field Count | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1 | Field Length 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2 | Field Length 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type M | Field Length M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure H: Template Set Format > > First, "Enterprise Number 2.1" is missing between the second > occurrence of "Field Length 1" and the subsequent "Field Type 2". Yes and No. It's not there because in the above example Field Type 1 is an IETF defined field (top bit clear). Need to check if we say that in the text, clearly we should. The idea was to give an example with both types included. > > Second, it might be better to use the "I.K" syntax for Field Types and > Field Lengths, not just for Enterprise Numbers. The "I" Index could > also be used in the "Field Count" inscriptions. Sure, that improves the understandability. > > Third, the ellipsis between "Field Type 2/Field Length 2" (the first) > and "Field Type N/Field Length N" suggests that just Field Type/Field > Length pairs should go between those, but every type/length pair > should be followed by an Enterprise Number. Not true. The design of record is that we don't sent ENs for IETF defined IEs. What you are proposing is a change to the design. > > So here's my suggested replacement text: > > > 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 = 2 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 256 | Field Count 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1.1 | Field Length 1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1.2 | Field Length 1.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1.N | Field Length 1.N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 257 | Field Count 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2.1 | Field Length 2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2.2 | Field Length 2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2.M | Field Length 2.M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure H: Template Set Format > > Slightly longer but hopefully clearer. Is incorrect and should be: 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 = 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 256 | Field Count 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1.1 | Field Length 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1.2 | Field Length 1.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1.N | Field Length 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 1.N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 257 | Field Count 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2.1 | Field Length 2.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2.2 | Field Length 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2.M | Field Length 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number 2.M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Field Types 1.2 and 2.1 are defined by the IETF (bit 0 = 0) and therefore do not need and Enterprise Number to identify them. - Stewart -- 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 Nov 29 06:07:32 2004 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 GAA06664 for ; Mon, 29 Nov 2004 06:07:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CYj27-00048K-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Nov 2004 04:45:27 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CYj26-00048F-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 29 Nov 2004 04:45:26 -0600 Received: from [192.168.0.1] (ams-clip-vpn-dhcp25.cisco.com [10.61.64.25]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iATAjF104423; Mon, 29 Nov 2004 11:45:15 +0100 (CET) Message-ID: <41AAFDB8.2060405@cisco.com> Date: Mon, 29 Nov 2004 11:45:12 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lutz Mark CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] PROTO-39: Template ID wrap up References: <41A2306C.7090103@cisco.com> <41A2581B.6000800@fokus.fraunhofer.de> <41A2D9F5.5090706@cisco.com> <41A30643.1020906@fokus.fraunhofer.de> In-Reply-To: <41A30643.1020906@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 Mark, > >> You forgot that >> - with SCTP-PR, we send the templates on the reliable stream and the >> flow data records potentially on a different stream >> Hence some potential re-ordering >> - with UDP, some potential re-ordering. > > > ok, but we talk in the context of the wrap around of > a 16 bit template id. There will be no re-ordering. I expressed myself badly. I wanted to say: packet arrival order issue, so the new template definition arriving after the first flow record. And this influences the fact that we can't just redefine a template definition. > >> If you simply change the Template definition, you could confuse the >> Collecting Process. >> Example: you change the Template definition from bytes count to >> packets count, and the new Template definition arrives after just >> after the first associated flow data record... what will the >> Collecting Process do with the first flow data record??? It will >> conclude that this is a bytes count, and it's not! > > > This is a little bit constructed. > > ok, the transmission of the withdraw message makes it waterproof. > > what about: > > Disused Templates SHOULD be deleted. Prior to reuse a Template ID > the disused Template MUST be deleted. > In order to delete an allocated Template, the Template is withdrawn > through the use of a Template Withdraw Message. > > The Template Withdraw Message MUST not be sent until sufficient > time has > elapsed to allow the Collecting Process to receive and process the > last data record using this Template information. > > The Template ID from a withdrawn Template MUST NOT be reused until > sufficient time has elapsed to allow for the Collecting Process to > receive and process the Template withdraw message. > > A Template Withdraw Message is Template Record for that Template ID > with a Field Count of 0. I like your proposal. Augmenting the text with some extra information, I propose: Disused Templates SHOULD be deleted. Prior to reuse a Template ID the disused Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdraw Message. The Template Withdraw Message MUST not be sent until sufficient time has elapsed to allow the Collecting Process to receive and process the last data record using this Template information. The Template ID from a withdrawn Template MUST NOT be reused until sufficient time has elapsed to allow for the Collecting Process to receive and process the Template withdraw message. A Template Withdraw Message is Template Record for that Template ID with a Field Count of 0. The format of the Template Withdrawal Message is shown in figure X. 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 = (2 or 3) | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | Field Count = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure X: Template Withdrawal Message format The Set ID field MUST contain the value 2 for Template Set withdrawal, and the value 3 for Options Template Set. Multiple Template ID MAY be withdrawn with a single Template Withdrawal Message: in that case, padding MAY be used. 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 Mon Nov 29 08:16:12 2004 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 IAA17415 for ; Mon, 29 Nov 2004 08:16:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CYlIM-0001fP-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Nov 2004 07:10:22 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CYlIL-0001fG-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 29 Nov 2004 07:10:21 -0600 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 29 Nov 2004 14:20:34 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iATDAGCu025658; Mon, 29 Nov 2004 14:10:17 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp4357.cisco.com [10.61.81.4]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA05825; Mon, 29 Nov 2004 13:10:15 GMT Message-ID: <41AB1FB6.40903@cisco.com> Date: Mon, 29 Nov 2004 13:10:14 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: Lutz Mark , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] PROTO-39: Template ID wrap up References: <41A2306C.7090103@cisco.com> <41A2581B.6000800@fokus.fraunhofer.de> <41A2D9F5.5090706@cisco.com> <41A30643.1020906@fokus.fraunhofer.de> <41AAFDB8.2060405@cisco.com> In-Reply-To: <41AAFDB8.2060405@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > Mark, > >> >>> You forgot that >>> - with SCTP-PR, we send the templates on the reliable stream and the >>> flow data records potentially on a different stream >>> Hence some potential re-ordering >>> - with UDP, some potential re-ordering. >> >> >> >> ok, but we talk in the context of the wrap around of >> a 16 bit template id. There will be no re-ordering. > > > I expressed myself badly. I wanted to say: packet arrival order issue, > so the new template definition arriving after the first flow record. > And this influences the fact that we can't just redefine a template > definition. BTW I don't like the use of the term "wrap of the 16 bit template id" that we (the group, including me) have used from time to time. They are template identifiers, not template sequence numbers and may be allocated in any order. The issue is not id wrap, it is id reuse. Perhaps we need a couple of lines in the spec to say that they can be allocated in any order? Stewart > >> >>> If you simply change the Template definition, you could confuse the >>> Collecting Process. >>> Example: you change the Template definition from bytes count to >>> packets count, and the new Template definition arrives after just >>> after the first associated flow data record... what will the >>> Collecting Process do with the first flow data record??? It will >>> conclude that this is a bytes count, and it's not! >> >> >> >> This is a little bit constructed. >> >> ok, the transmission of the withdraw message makes it waterproof. >> >> what about: >> >> Disused Templates SHOULD be deleted. Prior to reuse a Template ID >> the disused Template MUST be deleted. >> In order to delete an allocated Template, the Template is withdrawn >> through the use of a Template Withdraw Message. >> >> The Template Withdraw Message MUST not be sent until sufficient >> time has >> elapsed to allow the Collecting Process to receive and process the >> last data record using this Template information. >> >> The Template ID from a withdrawn Template MUST NOT be reused until >> sufficient time has elapsed to allow for the Collecting Process to >> receive and process the Template withdraw message. >> >> A Template Withdraw Message is Template Record for that Template ID >> with a Field Count of 0. > > > I like your proposal. Augmenting the text with some extra information, I > propose: > > Disused Templates SHOULD be deleted. Prior to reuse a Template ID > the disused Template MUST be deleted. > In order to delete an allocated Template, the Template is withdrawn > through the use of a Template Withdraw Message. > > The Template Withdraw Message MUST not be sent until sufficient time has > elapsed to allow the Collecting Process to receive and process the > last data record using this Template information. > > The Template ID from a withdrawn Template MUST NOT be reused until > sufficient time has elapsed to allow for the Collecting Process to > receive and process the Template withdraw message. > > A Template Withdraw Message is Template Record for that Template ID > with a Field Count of 0. The format of the Template Withdrawal Message > is shown in figure X. > > 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 = (2 or 3) | Length = 8 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID | Field Count = 0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure X: Template Withdrawal Message format > > The Set ID field MUST contain the value 2 for Template Set withdrawal, > and the value 3 for Options Template Set. > Multiple Template ID MAY be withdrawn with a single Template Withdrawal > Message: in that case, padding MAY be used. > > > 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 Mon Nov 29 10:34:25 2004 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 KAA01897 for ; Mon, 29 Nov 2004 10:34:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CYnNe-00062u-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Nov 2004 09:23:58 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CYnNd-00062p-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 29 Nov 2004 09:23:57 -0600 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4217.cisco.com [10.61.80.120]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iATFNs111916; Mon, 29 Nov 2004 16:23:54 +0100 (CET) Message-ID: <41AB3F0A.2080504@cisco.com> Date: Mon, 29 Nov 2004 16:23:54 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] PROTO-25, 31, 32, and 33: template management, collecting process and transport Content-Type: multipart/mixed; boundary="------------080608060408070102020507" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------080608060408070102020507 Content-Type: multipart/alternative; boundary="------------040207090107070000090707" --------------040207090107070000090707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, Stewart Bryant, Paul Aitken, and I have been trying to address the protocol issues # 25, 31, 32, and 33. PROTO-25: The section "Template Management" and "The Collecting Process's Side" will have to updated according to the transport protocol. - For example, the point 2 of the section "Template Management". Remark: the template management will vary with TCP, SCTP, etc... Must have both sections updated: transport updated and template management sections (BTW, this is the same for the failover section). - From Deri's draft: On the other hand as a probe can send flows to several collectors (e.g. in round-robin or as a reflector) it must keep track of per-collector templates transmission. This means that if collector X reconnects, the probe must send the template only to this collector and not to all collectors. PROPOSAL, after IETF60: treat UDP as the exception, in the template subsection of the UDP transport protocol. PROTO-31 The "Sequence Number" and "Source ID" treatment in case of multiple streams in SCTP is not well described. For example, in case the Templates are sent to one stream and the flow records to another one, what should the "Sequence Number"? What should the collector do? See David Moore's post PROTO-32 Correct this issue below The Collecting Process SHOULD verify that the received IPFIX Messages inside one stream do not have differing Source ID values and silently discard any data that does NOT match the initial value. The Exporting Process SHOULD NOT transmit messages inside one stream with multiple Source ID values. The correlated Flow Records are then treated like a normal export Flow. PROTO-33: correct the next paragraphs: silently? reset the connection? log an error? should the exporting process be allowed to sent multiple Source ID per stream. The Collecting Process SHOULD verify that the received IPFIX Messages inside one stream do not have differing Source ID values and silently discard any data that does NOT match the initial value. The Exporting Process SHOULD NOT transmit messages inside one stream with multiple Source ID values. The correlated Flow Records are then treated like a normal export Flow. Here is some text, to start the discussion Only the relevant sections have been introduced: - transport sections (section 5) BTW, the TCP sections has been changed much as Simon will do it - template managment (section 12) - Collecting process's side (section 13) BTW, I think we should move the transport protocols mappings section after section 13, because section 12/13 are dedicated to SCTP. The transport mappings for TCP and UDP are the exceptions, and as a consequence should be handled afterwards. Feedback? Regards, Benoit. --------------040207090107070000090707 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Dear all,


Stewart Bryant, Paul Aitken, and I have been trying to address the
protocol issues # 25, 31, 32, and 33.
 PROTO-25: The section "Template Management" and "The Collecting
Process's Side" will have to updated according to the transport
protocol.
- For example, the point 2 of the section "Template Management".
Remark: the template management will vary with TCP, SCTP,
etc...
Must have both sections updated: transport updated and
template management sections (BTW, this is the same for the
failover section).
- From Deri's draft: On the other hand as a probe can send flows
to several collectors (e.g. in round-robin or as a reflector) it
must keep track of per-collector templates transmission. This
means that if collector X reconnects, the probe must send the
template only to this collector and not to all collectors.

PROPOSAL, after IETF60: treat UDP as the exception, in the template
subsection of the UDP transport protocol.

PROTO-31 The "Sequence Number" and "Source ID" treatment in case of
multiple streams in SCTP is not well described. For example, in case
the Templates are sent to one stream and the flow records to another
one, what should the "Sequence Number"? What should the collector
do? See David Moore's post

PROTO-32 Correct this issue below
The Collecting Process SHOULD verify that the received IPFIX
Messages inside one stream do not have differing Source ID values
and silently discard any data that does NOT match the initial
value.

The Exporting Process SHOULD NOT transmit messages inside one
stream with multiple Source ID values. The correlated Flow Records
are then treated like a normal export Flow.

PROTO-33: correct the next paragraphs: silently? reset the
connection? log an error? should the exporting process be allowed to
sent multiple Source ID per stream.

The Collecting Process SHOULD verify that the received IPFIX
Messages inside one stream do not have differing Source ID
values and silently discard any data that does NOT match the
initial value.

The Exporting Process SHOULD NOT transmit messages inside one
stream with multiple Source ID values. The correlated Flow
Records are then treated like a normal export Flow. 
Here is some text, to start the discussion
Only the relevant sections have been introduced:
- transport sections (section 5)
  BTW, the TCP sections has been changed much as Simon will do it
- template managment (section 12)
- Collecting process's side (section 13)

BTW, I think we should move the transport protocols mappings section after section 13, because section 12/13 are dedicated to SCTP.
The transport mappings for TCP and UDP are the exceptions, and as a consequence should be handled afterwards.

Feedback?

Regards, Benoit.
--------------040207090107070000090707-- --------------080608060408070102020507 Content-Type: text/plain; name="tmp_section12_13.txt" Content-Disposition: inline; filename="tmp_section12_13.txt" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id iATFNs111916 Content-Transfer-Encoding: quoted-printable =20 5. Transport Protocol=20 =20 =20 5.2 TCP=20 =20 This section describes how IPFIX can be transported over=20 TCP [TCP]. =20 5.2.4.4 Template Management=20 =20 New Template Records SHOULD be transmitted as soon as=20 they are created on the Metering Process, and preferably=20 before any associated Flow or Options Data Record is=20 transmitted. The Collecting Process SHOULD accept Flow=20 and Options Data Records without the associated Template=20 Record. =20 =20 A Collecting Process MUST record all Template and Option=20 Template Records for the duration of the connection, as=20 an Exporting Process is not required to re-export=20 Template Records. =20 =20 5.3 SCTP=20 =20 This section describes how IPFIX can be transported over=20 SCTP [RFC2960] using the PR-SCTP [RFC3758] extension. =20 5.3.4.5 Template Management=20 =20 When the transport protocol is SCTP the default Template=20 Management described in Section 12 is used.=20 =20 5.3.5 Collecting Process=20 =20 When the transport protocol is SCTP, the default=20 Collector processing described in Section 13 is used. =20 =20 5.4 UDP=20 =20 =0C This section describes how IPFIX can be transported ov= er=20 UDP [RFC768].=20 =20 5.4.5.1 Template Management=20 =20 When IPFIX uses UDP as the transport protocol, Template=20 Sets and Option Template Sets MUST be re-sent at regular=20 intervals. The frequency of (Options) Template=20 transmission MUST be configurable. New Template Records=20 SHOULD be transmitted as soon as they are created, and=20 SHOULD be transmitted before any associated Data Record=20 is transmitted.=20 =20 In the event of configuration changes, the Exporting=20 Process SHOULD send the new template definitions at an=20 accelerated rate. In such a case, it MAY transmit the=20 changed Template Record(s) and Options Template=20 Record(s), without any data, in advance to help ensure=20 that the Collector will have the correct template=20 information before receiving the first data.=20 =20 If the Option Template scope is defined in another=20 Template, then both Templates SHOULD be sent in the same=20 IPFIX Message. For example: if a Flow Key Option=20 Template (see section 8.3) is sent in an Option=20 Template, then the associated Template SHOULD be sent in=20 the same IPFIX Message.=20 =20 Note that following a configuration change a new=20 Template ID should be used and the old Template ID=20 SHOULD NOT be reused until its lifetime has expired.=20 =20 Template Withdraw Messages SHOULD NOT be sent over UDP.=20 =20 5.4.6 Collecting Process=20 =20 The Collecting Process SHOULD accept Flow and Options=20 Data Records without the associated Template Record. If=20 the Template Records have not been received at the time=20 Flow Data Records (or Options Data Records) are=20 received, the Collecting Process SHOULD store the Flow=20 Data Records (or Options Data Records) for a short=20 period of time and decode them after the (Options)=20 Template Records are received. The short period of time=20 MUST be lower than the Template lifetime.=20 =20 The lifetime of a template at the Collecting Process is=20 limited to a fixed refresh timeout. The Collecting=20 Process MUST associate a lifetime with each Template=20 received via UDP. Templates not refreshed by the=20 Exporting Process within the timeout are expired at the=20 Collecting Process. If the template is not refreshed by=20 the Exporting Process before that lifetime has expired,=20 the Collecting Process MUST discard the Template, and=20 any current and future associated Flow or Option Data=20 Records. The Collecting Process MUST NOT decode any=20 further Flow or Option Data Records which are associated=20 with an that expired Template. =20 =20 At any given time the Collecting Process SHOULD maintain=20 the following for all the current Template Records and=20 Options Template Records: . =20 =20 12 Template Management=20 =20 This section describes Template management when using=20 SCTP and SCTP-PR as the transport protocol. Any=20 necessary changes to Template management specifically=20 related to TCP or UDP transport protocols are specified=20 in section 5.=20 =20 The Exporting Process assigns and maintains the=20 Template IDs for the Exporter=92s Observations Domains. A= =20 newly created Template Record is assigned an unused=20 Template ID by the Exporting Process. =20 =20 Templates Sets and Option Template Sets MUST be only=20 sent once on SCTP stream zero with full reliability. As=20 such, the Collecting Process MUST store the Template=20 Record information for the duration of the association=20 so that it can interpret the corresponding Flow Data=20 Records that are received in subsequent Data Sets.=20 =20 New Template Records SHOULD be transmitted as soon as=20 they are created. The Exporting Process MAY transmit=20 the Template Set and Options Template in advance of any=20 Data Sets that use that (Options) Template ID, to=20 ensure that the Collector has the Template Record=20 before receiving the first Flow or Options Data Record. =20 Flow and Options Data Records that correspond to a=20 Template Record MAY appear in the same and/or=20 subsequent IPFIX Message(s). =20 =20 A Template ID MUST be unique per Observation Domain.=20 Different Observation Domains from the same Exporter may=20 use the same Template ID value to refer to different=20 Templates.=20 =20 If the measurement parameters change, the Template MUST=20 be withdrawn using a Template Withdraw Message or an=20 unused Template ID MUST be used. Examples of the=20 measurement changes are: a new sampling rate, a new=20 flow expiration process, a new filtering definition,=20 etc. If a Template is changed, a Template Withdraw=20 Message MUST be sent to delete the Template. =20 =20 If the Exporting Process restarts, the SCTP association=20 MUST be shutdown and restarted. When the Exporting=20 Process restarts, all Template assignments are lost and=20 Template IDs MUST be re-assigned. If the Metering=20 Process restarts, the Exporting Process MUST either=20 reuse the previously assigned Template ID for each=20 Template, or it MUST withdraw the previously issued=20 Template IDs by sending Template Withdraw Message(s)=20 before reusing them. EDITOR=92S NOTE: A TEMPLATE WITHDRAW= =20 MESSAGE THAT WITHDRAW ALL THE TEMPLATE FOR A SPECIFIC=20 SOURCE ID MIGHT BE USEFUL.=20 =20 When the SCTP association restarts, the Exporting=20 Process MUST resend all the Template Records.=20 =20 The Exporting Process MUST NOT transmit IPFIX Messages=20 with more than one Source ID value inside any single=20 stream.=20 =20 More that one (Option) Template Set MAY be sent in an=20 IPFIX Message. =20 =20 13. The Collecting Process's Side=20 =20 This section describes the Collecting Process when using=20 SCTP and SCTP-PR as the transport protocol. Any=20 necessary changes to the Collecting Process specifically=20 related to TCP or UDP transport protocols are specified=20 in section 5.=20 =20 The Collecting Process SHOULD listen for a new=20 association request from the Exporting Process. The=20 Exporting Process will request a number of streams to=20 use for export. A Collecting Process MUST support at=20 least two inbound streams per association. An Exporting=20 Process MAY ask for and support more than two streams.=20 =20 The Collecting Process MUST verify that only one Source=20 ID value is used inside each stream. If the Collecting=20 Process detects that more than one Source ID has been=20 received within a stream, it MUST discard the IPFIX=20 Message, reset the SCTP association, and SHOULD log the=20 error=20 =20 If the Collecting Process receives a malformed IPFIX=20 Message, it MUST reset the SCTP association, discard the=20 message, and SHOULD log the error. =20 =20 Templates Sets and Option Template Sets are only sent=20 once. The Collecting Process MUST store the Template=20 Record information for the duration of the association=20 so that it can interpret the corresponding Flow Data=20 Records that are received in subsequent Data Sets.=20 =20 Template IDs are unique per Exporting Process and per=20 Observation Domain. If the Collecting Process receives=20 a Template which has already been received but which has=20 not previously been withdrawn (i.e. a Template Record=20 from the same Exporter Observation Domain with the same=20 Template ID), then the Collecting Process MUST shutdown=20 the association.=20 =20 When an SCTP association is closed, the Collecting=20 Process MUST discard all templates received over that=20 association and stop decoding IPFIX Messages that use=20 those templates.=20 =20 The Collecting Process normally receives Template=20 Records from the Exporting Process, before receiving=20 Flow or Options Data Records. The Flow Data Records (or=20 Options Data Records) are then decoded and stored by the=20 Collector. If the Template Records have not been=20 received at the time Flow Data Records (or Options Data=20 Records) are received, the Collecting Process MAY store=20 the Flow Data Records (or Options Data Records) for a=20 short period of time and decode them after the Template=20 Records are received. A Collecting Process MUST NOT=20 assume that the Data Set and the associated Template Set=20 (or Options Template Set) are exported in the same IPFIX=20 Message.=20 =20 The Collecting Process MUST note the Field ID of any=20 Information Element that it does not understand and MAY=20 discard that Information Element from the Flow Record. =20 The Collecting Process MUST note the size and position=20 of any Vendor Specified Information Element that it does=20 not understand and discard that Information Element from=20 the Flow Record.=20 =20 More that one (Options) Template Set MAY be received in=20 an IPFIX Message.=20 =20 =20 The Collector MUST accept padding in Flow Data Records,=20 Options Data Records and Template Records.=20 =20 The IPFIX protocol has a Sequence Number field in the=20 Export header which increases with each IPFIX Message. =20 A Collector may detect out of sequence, dropped, or=20 duplicate IPFIX Messages by tracking the Sequence=20 Number. EDITOR=92S NOTE: THIS MIGHT CHANGE IF THE=20 SEQUENCE NUMBER IS PER STREAM AND IF THIS IS THE NUMBER=20 OF FLOW RECORDS. A collector SHOULD provide a logging=20 mechanism for tracking out of sequence IPFIX Messages. =20 Such out of sequence IPFIX Messages may be due to=20 Exporter resource exhaustion where it can not transmit=20 messages at their creation rate, an Exporting Process=20 reset, congestion on the network link between the=20 Exporter and Collector, Collector resource exhaustion=20 where it can not process the IPFIX Messages at their=20 arrival rate, out of order packet reception, duplicate=20 packet reception, or an attacker injecting false=20 messages.=20 =20 If a Collecting Process receives a Template Withdraw=20 Message, the Collecting Process MUST delete the=20 corresponding Template Record associated with the=20 specific Exporter and specific Observation Domain, and=20 stop decoding IPFIX Messages that use those Templates. =20 =20 A Collecting Process that receives IPFIX Messages from=20 several Observation Domains from the same Exporter MUST=20 be aware that the uniqueness of the Template ID is not=20 guaranteed across Observation Domains.=20 --------------080608060408070102020507-- -- 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 Nov 29 10:35:58 2004 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 KAA02066 for ; Mon, 29 Nov 2004 10:35:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CYnOQ-00063H-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Nov 2004 09:24:46 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CYnOP-00063C-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 29 Nov 2004 09:24:45 -0600 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4217.cisco.com [10.61.80.120]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iATFOY113091; Mon, 29 Nov 2004 16:24:34 +0100 (CET) Message-ID: <41AB3F32.1020001@cisco.com> Date: Mon, 29 Nov 2004 16:24:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stewart Bryant CC: Lutz Mark , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] PROTO-39: Template ID wrap up References: <41A2306C.7090103@cisco.com> <41A2581B.6000800@fokus.fraunhofer.de> <41A2D9F5.5090706@cisco.com> <41A30643.1020906@fokus.fraunhofer.de> <41AAFDB8.2060405@cisco.com> <41AB1FB6.40903@cisco.com> In-Reply-To: <41AB1FB6.40903@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id iATFOY113091 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Stewart Bryant wrote: > > > Benoit Claise wrote: > >> Mark, >> >>> >>>> You forgot that >>>> - with SCTP-PR, we send the templates on the reliable stream and=20 >>>> the flow data records potentially on a different stream >>>> Hence some potential re-ordering >>>> - with UDP, some potential re-ordering. >>> >>> >>> >>> >>> ok, but we talk in the context of the wrap around of >>> a 16 bit template id. There will be no re-ordering. >> >> >> >> I expressed myself badly. I wanted to say: packet arrival order=20 >> issue, so the new template definition arriving after the first flow=20 >> record. >> And this influences the fact that we can't just redefine a template=20 >> definition. > > > BTW I don't like the use of the term "wrap of the 16 bit template id" > that we (the group, including me) have used from time to time. > > They are template identifiers, not template sequence numbers and > may be allocated in any order. The issue is not id wrap, it > is id reuse. Perhaps we need a couple of lines in the spec to > say that they can be allocated in any order? You're right. Actually the protocol issue should have been "Template ID=20 reuse... potentially due Template ID running out of values" The new I just posted in the email "PROTO-25, 31, 32, and 33: template=20 management, collecting process and transport" contains: The Exporting Process assigns and maintains the Template IDs for the Exporter=92s Observations Domains. A newly created Template Record is assigned an unused Template ID by the Exporting Process. Do we need something else? Regards, Benoit. > > Stewart > > >> >>> >>>> If you simply change the Template definition, you could confuse the=20 >>>> Collecting Process. >>>> Example: you change the Template definition from bytes count to=20 >>>> packets count, and the new Template definition arrives after just=20 >>>> after the first associated flow data record... what will the=20 >>>> Collecting Process do with the first flow data record??? It will=20 >>>> conclude that this is a bytes count, and it's not! >>> >>> >>> >>> >>> This is a little bit constructed. >>> >>> ok, the transmission of the withdraw message makes it waterproof. >>> >>> what about: >>> >>> Disused Templates SHOULD be deleted. Prior to reuse a Template ID >>> the disused Template MUST be deleted. >>> In order to delete an allocated Template, the Template is withdrawn >>> through the use of a Template Withdraw Message. >>> >>> The Template Withdraw Message MUST not be sent until sufficient time=20 >>> has >>> elapsed to allow the Collecting Process to receive and process the >>> last data record using this Template information. >>> >>> The Template ID from a withdrawn Template MUST NOT be reused until >>> sufficient time has elapsed to allow for the Collecting Process to >>> receive and process the Template withdraw message. >>> >>> A Template Withdraw Message is Template Record for that Template ID >>> with a Field Count of 0. >> >> >> >> I like your proposal. Augmenting the text with some extra=20 >> information, I propose: >> >> Disused Templates SHOULD be deleted. Prior to reuse a Template ID >> the disused Template MUST be deleted. >> In order to delete an allocated Template, the Template is withdrawn >> through the use of a Template Withdraw Message. >> >> The Template Withdraw Message MUST not be sent until sufficient time h= as >> elapsed to allow the Collecting Process to receive and process the >> last data record using this Template information. >> >> The Template ID from a withdrawn Template MUST NOT be reused until >> sufficient time has elapsed to allow for the Collecting Process to >> receive and process the Template withdraw message. >> >> A Template Withdraw Message is Template Record for that Template ID >> with a Field Count of 0. The format of the Template Withdrawal Message >> is shown in figure X. >> >> 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=20 >> 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID =3D (2 or 3) | Length =3D 8 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID | Field Count =3D 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure X: Template Withdrawal Message format >> >> The Set ID field MUST contain the value 2 for Template Set=20 >> withdrawal, and the value 3 for Options Template Set. >> Multiple Template ID MAY be withdrawn with a single Template Withdrawa= l >> Message: in that case, padding MAY be used. >> >> >> Regards, Benoit. >> >> >> --=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/ >> >> -- 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 Nov 29 10:39:21 2004 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 KAA02326 for ; Mon, 29 Nov 2004 10:39:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CYnWd-0006R3-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Nov 2004 09:33:15 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CYnWb-0006Qt-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 29 Nov 2004 09:33:13 -0600 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8ED471BACA1; Mon, 29 Nov 2004 16:33:11 +0100 (CET) Date: Mon, 29 Nov 2004 16:33:10 +0100 From: Juergen Quittek To: Stewart Bryant , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Timing - section 9 Message-ID: <2147483647.1101745990@[10.1.1.171]> In-Reply-To: <41A21C50.6000908@cisco.com> References: <41A21C50.6000908@cisco.com> X-Mailer: Mulberry/3.0.3 (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 Stewart, I agree that the definition of timer semantics should be moved to the info model document. There we should distinguish timer elements by - their precision - seconds - milliseconds - microseconds - nanaseconds Currently, we have just two precisions supported: dateTimeSeconds and dateTimeMicroSeconds. And currently both use GMT/UTC as time base. Reading section 9 of the protocol spec, we need also data types for time offset values. This would end up to eight data types: GMT/UTC-based time values in four precisions: dateTimeSeconds dateTimeMilliSeconds dateTimeMicroSeconds dateTimeNanoSeconds Time offset values in four precisions: timeIntervalSeconds timeIntervalMilliSeconds timeIntervalMicroSeconds timeIntervalNanoSeconds For the offset values we need to specify if they are always signed or unsigned. All in all we would extend the two data types for times we have already to a set of eight. Are all eight required? 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 22.11.2004 17:05 h +0000 Stewart Bryant wrote: > I am wondering if the text of section 9 (Export Packet > "Export Time" Computation and Flow Record Time) should > be in the protocol draft at all. This is really the detailed > definition of a number of information elements, and > as such should be in the information element draft. > > The timing component has always been controversial due > to the conflict between the need to have a timing > "dynamic range", and the need to compress the exported > data. Moving the text to the IE draft would allow > timing information to be better tailored to the > application, by allowing the user to select a timing > element that best matched their needs. > > It may be necessary to include some text in a new > protocol draft section 9 that describes some brief > implementation notes, such as the need to ensure that > there are no timing conflicts between the records > contained within an IPFIX Message. > > I think that this approach would allow us maximum > flexibility in the design and implementation of the > protocol, because it does not define any default > timing behaviour. > > - Stewart > > > > > -- > 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 Nov 29 10:49:18 2004 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 KAA03200 for ; Mon, 29 Nov 2004 10:49:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CYnfq-0006eu-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Nov 2004 09:42:46 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CYnfp-0006ef-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 29 Nov 2004 09:42:45 -0600 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 647511BACA1; Mon, 29 Nov 2004 16:42:43 +0100 (CET) Date: Mon, 29 Nov 2004 16:42:39 +0100 From: Juergen Quittek To: Stewart Bryant , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Timing - section 9 Message-ID: <2147483647.1101746559@[10.1.1.171]> In-Reply-To: <41A21C50.6000908@cisco.com> References: <41A21C50.6000908@cisco.com> X-Mailer: Mulberry/3.0.3 (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 Stewart, --On 22.11.2004 17:05 h +0000 Stewart Bryant wrote: > I am wondering if the text of section 9 (Export Packet > "Export Time" Computation and Flow Record Time) should > be in the protocol draft at all. This is really the detailed > definition of a number of information elements, and > as such should be in the information element draft. > > The timing component has always been controversial due > to the conflict between the need to have a timing > "dynamic range", and the need to compress the exported > data. Moving the text to the IE draft would allow > timing information to be better tailored to the > application, by allowing the user to select a timing > element that best matched their needs. > > It may be necessary to include some text in a new > protocol draft section 9 that describes some brief > implementation notes, such as the need to ensure that > there are no timing conflicts between the records > contained within an IPFIX Message. I am not sure these implementation notes belong into a protocol specification document. I would see them rather as part of a (future) implementation guideline document. Rather than giving code on how a time base for time offset values is computed, the protocol draft should specify how time bases are set (header of the IPFIX message) and what is their scope (offset time values in the records). 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 > I think that this approach would allow us maximum > flexibility in the design and implementation of the > protocol, because it does not define any default > timing behaviour. > > - Stewart > > > > > -- > 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 Nov 29 11:09:17 2004 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 LAA05022 for ; Mon, 29 Nov 2004 11:09:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CYnve-0007IM-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Nov 2004 09:59:06 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CYnvd-0007IF-00 for ipfix-info@net.doit.wisc.edu; Mon, 29 Nov 2004 09:59:05 -0600 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4217.cisco.com [10.61.80.120]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iATFww123148; Mon, 29 Nov 2004 16:59:02 +0100 (CET) Message-ID: <41AB4742.5090909@cisco.com> Date: Mon, 29 Nov 2004 16:58:58 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Leinen CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] Information Element naming convention References: <41A33143.6050405@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060607020607020506060007" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------060607020607020506060007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Simon Leinen wrote: >Benoit Claise writes: > > >>I would like to propose the following convention in [IPFIX-INFO]. >>The information elements exported after packet treatment would start >>with "post" >> >> > > > >>Example: >> >> > > > >>classOfServiceIPv4 >> Description: >> The value of the IPv4 TOS field observed for packets of this flow. >> >> > > > >>postClassOfServiceIPv4 >> Description: >> The value of the IPv4 TOS field for packets of this flow, >>after packet treatment. >> >> > > > >>Feedback? >> >> > >I think "post" is somewhat unspecific, unless it is clear what exactly >the "packet treatment" consists of. It assumes that an observation >point has access to these values in exactly two points: "" (meaning >"pre"), and "post". > >Looking at your example, it seems clear that your observation point >must be "inside" the packet treatment (integrated somewhere into the >forwarding/filtering/classification/marking decision logic). > I'm not sure why? The observation point is something abstract. Let's take a simple router, composed of 2 interfaces. You would like to account for flows as packets enter the router, so observed packets with the observation point = the incoming interface You would potentially like to account for flows as packets leave the router, so the packets transmitted (*) by the observation point = the outgoing interface (*) to say transmitted, we can say "after packet treatment" However, you could also see the router as one big observation point (I guess this is what you are referring to in your previous sentence): this doesn't change the logic. We want the packets observed as they enter, and transmitted as they leave. > <> Note > that this doesn't fit nicely into the (idealized) IPFIX architecture > as it currently stands. > <>In any case it would make sense to talk about "pre" and "post", not > just "post" for all properties that can be changed in the course of > packet treatment. I used "post" as opposed to observed. Observed is the default behaviour of IPFIX; "An Observation Point is a location in the network where IP packets can be observed.". So implicetely, you observe the packet(s) before you change anything on it/them. As a default behaviour, I don't think we need to specify "pre" for all the information elements. >But the real question is, shouldn't we specify (pre- or) "post-WHAT"? > > >For some treatments this immediately seems to make sense, e.g. > >deltaOctetCountBeforeIngressACL >deltaOctetCountAfterIngressACL >deltaOctetCountAfterIngressPolicing >deltaOctetCountAfterEgressACL >deltaOctetCountAfterEgressShaping > > Let's ask an easier question first: how to report egress NetFlow (http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00802d41ea.html)? >- where the actual order or presence of different steps will be highly >implementation-dependent. > > Exactly. And we standardize the export, not the metering process >The clean/naive solution would be to have multiple observation points, >which could contribute different values for observed properties of the >same identical flows. But the current IPFIX architecture doesn't >support this. > > Potentially. Again, that would be exporter architecture-dependent. And we standardize the export, not the metering process >Now... if templates could somehow specify a "scope" (or >"observation-sub-point" :-) for each field (in addition to >enterprise/type and field length), then multiple instances of fields >such as "classOfServiceIPv4" or "deltaOctetCount" could peacefully >coexist in a single Data Set, without any explosion of field types. > >What about aligning the Template Set Format with the Options Template >Set Format, so that (data) Templates could have sections for different >Scopes, just like Option Templates? (At least that's what I understand >the current Option Template should support.) > >Then enterprises (or maybe even the IETF) could define Scope Field >Types corresponding to different well-defined points in packet >treatment. > > I'm afraid that all the different vendors will have different exporter architecture, different "internal" scope or "observation-sub-point". And that at the end, it will be difficult for the collectors to conclude anything common about the flows from different vendors This is the reason why I was proposing something simple, for a simple problem first Observerd = pre = default Transmitted = post = after all packet treatments => use post in information element naming convention Regards, Benoit --------------060607020607020506060007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Simon Leinen wrote:
Benoit Claise writes:
  
I would like to propose the following convention in [IPFIX-INFO].
The information elements exported after packet treatment would start
with "post"
    

  
Example:
    

  
classOfServiceIPv4
   Description:
      The value of the IPv4 TOS field observed for packets of this flow.
    

  
postClassOfServiceIPv4
   Description:
      The value of the IPv4 TOS field for packets of this flow,
after packet treatment.
    

  
Feedback?
    

I think "post" is somewhat unspecific, unless it is clear what exactly
the "packet treatment" consists of.  It assumes that an observation
point has access to these values in exactly two points: "" (meaning
"pre"), and "post".

Looking at your example, it seems clear that your observation point
must be "inside" the packet treatment (integrated somewhere into the
forwarding/filtering/classification/marking decision logic).
I'm not sure why? The observation point is something abstract.
Let's take a simple router, composed of 2 interfaces.
You would like to account for flows as packets enter the router, so observed packets with the observation point = the incoming interface
You would potentially like to account for flows as packets leave the router, so the packets transmitted (*) by the observation point = the outgoing interface
(*) to say transmitted, we can say "after packet treatment"
However, you could also see the router as one big observation point (I guess this is what you are referring to in your previous sentence): this doesn't change the logic. We want the packets observed as they enter, and transmitted as they leave.
<> Note
that this doesn't fit nicely into the (idealized) IPFIX architecture
as it currently stands.

<>In any case it would make sense to talk about "pre" and "post", not
just "post" for all properties that can be changed in the course of
packet treatment.
I used "post" as opposed to observed. Observed is the default behaviour of IPFIX; "An Observation Point is a location in the network where IP packets can be observed.". So implicetely, you observe the packet(s) before you change anything on it/them.
As a default behaviour, I don't think we need to specify "pre" for all the information elements.

But the real question is, shouldn't we specify (pre- or) "post-WHAT"?
  
For some treatments this immediately seems to make sense, e.g.

deltaOctetCountBeforeIngressACL
deltaOctetCountAfterIngressACL
deltaOctetCountAfterIngressPolicing
deltaOctetCountAfterEgressACL
deltaOctetCountAfterEgressShaping
Let's ask an easier question first: how to report egress NetFlow
(http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00802d41ea.html)?
- where the actual order or presence of different steps will be highly
implementation-dependent.
Exactly. And we standardize the export, not the metering process
The clean/naive solution would be to have multiple observation points,
which could contribute different values for observed properties of the
same identical flows.  But the current IPFIX architecture doesn't
support this.
Potentially. Again, that would be exporter architecture-dependent. And we standardize the export, not the metering process 
Now... if templates could somehow specify a "scope" (or
"observation-sub-point" :-) for each field (in addition to
enterprise/type and field length), then multiple instances of fields
such as "classOfServiceIPv4" or "deltaOctetCount" could peacefully
coexist in a single Data Set, without any explosion of field types.

What about aligning the Template Set Format with the Options Template
Set Format, so that (data) Templates could have sections for different
Scopes, just like Option Templates? (At least that's what I understand
the current Option Template should support.)

Then enterprises (or maybe even the IETF) could define Scope Field
Types corresponding to different well-defined points in packet
treatment.
I'm afraid that all the different vendors will have different exporter architecture, different "internal" scope or "observation-sub-point".
And that at the end, it will be difficult for the collectors to conclude anything common about the flows from different vendors
This is the reason why I was proposing something simple, for a simple problem first
    Observerd = pre = default
    Transmitted = post = after all packet treatments => use post in information element naming convention

Regards, Benoit

--------------060607020607020506060007-- -- 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 Nov 29 11:35:11 2004 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 LAA06999 for ; Mon, 29 Nov 2004 11:35:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CYoKI-0000VA-00 for ipfix-list@mil.doit.wisc.edu; Mon, 29 Nov 2004 10:24:34 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CYoKH-0000V5-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 29 Nov 2004 10:24:33 -0600 Received: from [192.168.0.1] (ams-clip-vpn-dhcp4217.cisco.com [10.61.80.120]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iATGOP122701; Mon, 29 Nov 2004 17:24:25 +0100 (CET) Message-ID: <41AB4D38.3030609@cisco.com> Date: Mon, 29 Nov 2004 17:24:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stewart Bryant CC: Lutz Mark , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] PROTO-39: Template ID wrap up References: <41A2306C.7090103@cisco.com> <41A2581B.6000800@fokus.fraunhofer.de> <41A2D9F5.5090706@cisco.com> <41A30643.1020906@fokus.fraunhofer.de> <41AAFDB8.2060405@cisco.com> <41AB1FB6.40903@cisco.com> In-Reply-To: <41AB1FB6.40903@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by strange-brew.cisco.com id iATGOP122701 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Stewart Bryant wrote: > > > Benoit Claise wrote: > >> Mark, >> >>> >>>> You forgot that >>>> - with SCTP-PR, we send the templates on the reliable stream and=20 >>>> the flow data records potentially on a different stream >>>> Hence some potential re-ordering >>>> - with UDP, some potential re-ordering. >>> >>> >>> >>> >>> ok, but we talk in the context of the wrap around of >>> a 16 bit template id. There will be no re-ordering. >> >> >> >> I expressed myself badly. I wanted to say: packet arrival order=20 >> issue, so the new template definition arriving after the first flow=20 >> record. >> And this influences the fact that we can't just redefine a template=20 >> definition. > > > BTW I don't like the use of the term "wrap of the 16 bit template id" > that we (the group, including me) have used from time to time. > > They are template identifiers, not template sequence numbers and > may be allocated in any order. The issue is not id wrap, it > is id reuse. Perhaps we need a couple of lines in the spec to > say that they can be allocated in any order? > > Stewart > > >> >>> >>>> If you simply change the Template definition, you could confuse the=20 >>>> Collecting Process. >>>> Example: you change the Template definition from bytes count to=20 >>>> packets count, and the new Template definition arrives after just=20 >>>> after the first associated flow data record... what will the=20 >>>> Collecting Process do with the first flow data record??? It will=20 >>>> conclude that this is a bytes count, and it's not! >>> >>> >>> >>> >>> This is a little bit constructed. >>> >>> ok, the transmission of the withdraw message makes it waterproof. >>> >>> what about: >>> >>> Disused Templates SHOULD be deleted. Prior to reuse a Template ID >>> the disused Template MUST be deleted. >>> In order to delete an allocated Template, the Template is withdrawn >>> through the use of a Template Withdraw Message. >>> >>> The Template Withdraw Message MUST not be sent until sufficient time=20 >>> has >>> elapsed to allow the Collecting Process to receive and process the >>> last data record using this Template information. >>> >>> The Template ID from a withdrawn Template MUST NOT be reused until >>> sufficient time has elapsed to allow for the Collecting Process to >>> receive and process the Template withdraw message. >>> >>> A Template Withdraw Message is Template Record for that Template ID >>> with a Field Count of 0. >> >> >> >> I like your proposal. Augmenting the text with some extra=20 >> information, I propose: >> >> Disused Templates SHOULD be deleted. Prior to reuse a Template ID >> the disused Template MUST be deleted. >> In order to delete an allocated Template, the Template is withdrawn >> through the use of a Template Withdraw Message. >> >> The Template Withdraw Message MUST not be sent until sufficient time h= as >> elapsed to allow the Collecting Process to receive and process the >> last data record using this Template information. >> >> The Template ID from a withdrawn Template MUST NOT be reused until >> sufficient time has elapsed to allow for the Collecting Process to >> receive and process the Template withdraw message. >> >> A Template Withdraw Message is Template Record for that Template ID >> with a Field Count of 0. The format of the Template Withdrawal Message >> is shown in figure X. >> >> 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=20 >> 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Set ID =3D (2 or 3) | Length =3D 8 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID | Field Count =3D 0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure X: Template Withdrawal Message format >> >> The Set ID field MUST contain the value 2 for Template Set=20 >> withdrawal, and the value 3 for Options Template Set. >> Multiple Template ID MAY be withdrawn with a single Template Withdrawa= l >> Message: in that case, padding MAY be used. > One more precision. "The Template Withdraw Message withdraws the Template ID for the Source=20 ID specified in the IPFIX Message header." One more comment. From the previous posted called " [ipfix-protocol] PROTO-25, 31, 32,=20 and 33: template management, collecting process and transport" If the Exporting Process restarts, the SCTP association=20 MUST be shutdown and restarted. When the Exporting=20 Process restarts, all Template assignments are lost and=20 Template IDs MUST be re-assigned. If the Metering=20 Process restarts, the Exporting Process MUST either=20 reuse the previously assigned Template ID for each=20 Template, or it MUST withdraw the previously issued=20 Template IDs by sending Template Withdraw Message(s)=20 before reusing them. EDITOR=92S NOTE: A TEMPLATE WITHDRAW= =20 MESSAGE THAT WITHDRAW ALL THE TEMPLATE FOR A SPECIFIC=20 SOURCE ID MIGHT BE USEFUL.=20 We could use the following to withdraw all Templates for the Source ID=20 specified in the IPFIX message header 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 =3D 2 | Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID =3D 2 | Field Count =3D 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We could use the following to withdraw all Options Templates for the=20 Source ID specified in the IPFIX message header 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 =3D 3 | Length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID =3D 3 | Field Count =3D 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Feedback? Regards, Benoit. >> >> >> Regards, Benoit. >> >> >> --=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/ >> >> -- 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 Nov 30 05:43:23 2004 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 FAA03604 for ; Tue, 30 Nov 2004 05:43:23 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CZ5Dt-0003Ff-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Nov 2004 04:27:05 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CZ5Ds-0003Fa-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 30 Nov 2004 04:27:04 -0600 Received: from [64.103.30.144] (dhcp-par-ilm-vl30-30-144.cisco.com [64.103.30.144]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAUAR3126595; Tue, 30 Nov 2004 11:27:03 +0100 (CET) Message-ID: <41AC4AF7.9020601@cisco.com> Date: Tue, 30 Nov 2004 11:27:03 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Stewart Bryant , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Timing - section 9 References: <41A21C50.6000908@cisco.com> <2147483647.1101745990@[10.1.1.171]> In-Reply-To: <2147483647.1101745990@[10.1.1.171]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > Hi Stewart, > > I agree that the definition of timer semantics should be > moved to the info model document. > > There we should distinguish timer elements by > > - their precision > - seconds > - milliseconds > - microseconds > - nanaseconds > > Currently, we have just two precisions supported: > dateTimeSeconds and dateTimeMicroSeconds. And currently > both use GMT/UTC as time base. > > Reading section 9 of the protocol spec, we need also data > types for time offset values. > > This would end up to eight data types: > > GMT/UTC-based time values in four precisions: > dateTimeSeconds > dateTimeMilliSeconds > dateTimeMicroSeconds > dateTimeNanoSeconds > > Time offset values in four precisions: > timeIntervalSeconds > timeIntervalMilliSeconds > timeIntervalMicroSeconds > timeIntervalNanoSeconds > > For the offset values we need to specify if they are > always signed or unsigned. > > All in all we would extend the two data types for times we have > already to a set of eight. Are all eight required? I'm not sure. The section 9 doesn't require: - timeIntervalSeconds, - timeIntervalNanoSeconds (because dateTimeNanoSeconds would use anyway a 64 bits counter. So we don't gain anything) 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 majordomo@mil.doit.wisc.edu Tue Nov 30 05:53:20 2004 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 FAA04303 for ; Tue, 30 Nov 2004 05:53:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CZ5AT-0003Ao-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Nov 2004 04:23:33 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CZ5AS-0003Aj-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 30 Nov 2004 04:23:32 -0600 Received: from [64.103.30.144] (dhcp-par-ilm-vl30-30-144.cisco.com [64.103.30.144]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAUANU123043; Tue, 30 Nov 2004 11:23:30 +0100 (CET) Message-ID: <41AC4A22.7080708@cisco.com> Date: Tue, 30 Nov 2004 11:23:30 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stewart Bryant CC: Simon Leinen , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Proposed fixes to "Template Set Format" table References: <16803.23127.380315.836409@diotima.switch.ch> <41A48BD2.1070600@cisco.com> In-Reply-To: <41A48BD2.1070600@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 Dear all, I added Stewart's proposed text below for the next version of the protocol draft. Regards, Benoit. > > > Simon Leinen wrote: > >> The template example in Figure H of draft-ietf-ipfix-protocol-06 could >> be improved. The current version reads like this: >> >> 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 = 2 | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID 256 | Field Count | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 1 | Field Length 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 1.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 2 | Field Length 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type N | Field Length N | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 1.N | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID 257 | Field Count | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 1 | Field Length 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 2 | Field Length 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 2.2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type M | Field Length M | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 2.M | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Padding (opt) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure H: Template Set Format >> >> First, "Enterprise Number 2.1" is missing between the second >> occurrence of "Field Length 1" and the subsequent "Field Type 2". > > > Yes and No. It's not there because in the above example Field Type 1 > is an IETF defined field (top bit clear). Need to check if we say that > in the text, clearly we should. The idea was to give an example > with both types included. > >> >> Second, it might be better to use the "I.K" syntax for Field Types and >> Field Lengths, not just for Enterprise Numbers. The "I" Index could >> also be used in the "Field Count" inscriptions. > > > Sure, that improves the understandability. > >> >> Third, the ellipsis between "Field Type 2/Field Length 2" (the first) >> and "Field Type N/Field Length N" suggests that just Field Type/Field >> Length pairs should go between those, but every type/length pair >> should be followed by an Enterprise Number. > > > Not true. The design of record is that we don't sent ENs for IETF > defined IEs. What you are proposing is a change to the design. > >> >> So here's my suggested replacement text: >> >> >> 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 = 2 | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID 256 | Field Count 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 1.1 | Field Length 1.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 1.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 1.2 | Field Length 1.2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 1.2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 1.N | Field Length 1.N | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 1.N | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Template ID 257 | Field Count 2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 2.1 | Field Length 2.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 2.1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 2.2 | Field Length 2.2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 2.2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... | ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Field Type 2.M | Field Length 2.M | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Enterprise Number 2.M | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Padding (opt) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure H: Template Set Format >> >> Slightly longer but hopefully clearer. > > > Is incorrect and should be: > > 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 = 2 | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 256 | Field Count 1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1.1 | Field Length 1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1.2 | Field Length 1.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 1.N | Field Length 1.N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 1.N | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Template ID 257 | Field Count 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2.1 | Field Length 2.1 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2.2 | Field Length 2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Field Type 2.M | Field Length 2.M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Enterprise Number 2.M | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Padding (opt) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Field Types 1.2 and 2.1 are defined by the IETF (bit 0 = 0) and > therefore do not need and Enterprise Number to identify them. > > - Stewart > > > -- > 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 Nov 30 06:23:17 2004 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 GAA07308 for ; Tue, 30 Nov 2004 06:23:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CZ5i0-0004Al-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Nov 2004 04:58:12 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CZ5hy-0004Ag-00; Tue, 30 Nov 2004 04:58:10 -0600 Received: from [64.103.30.144] (dhcp-par-ilm-vl30-30-144.cisco.com [64.103.30.144]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAUAw9125063; Tue, 30 Nov 2004 11:58:09 +0100 (CET) Message-ID: <41AC5241.5010100@cisco.com> Date: Tue, 30 Nov 2004 11:58:09 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-chairs@net.doit.wisc.edu CC: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] IANA: IPFIX ports request Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dave, Nevil, As we start to close the final issues w.r.t. the IPFIX protocol draft, we should not forget about the IANA ports registration. From the last meeting minutes; [Note: Since there was no opposition voiced to acquiring a well-known port number for IPFIX, the chairs will pursue this getting a port number assigned by IANA.] Note: this email as a gentle reminder, as I have personally no clue how long it might take for the registration process. 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 Nov 30 06:49:17 2004 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 GAA09025 for ; Tue, 30 Nov 2004 06:49:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CZ6P9-0006Yi-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Nov 2004 05:42:47 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CZ6P8-0006Yd-00 for ipfix-arch@net.doit.wisc.edu; Tue, 30 Nov 2004 05:42:46 -0600 Received: from [64.103.30.144] (dhcp-par-ilm-vl30-30-144.cisco.com [64.103.30.144]) by strange-brew.cisco.com (8.11.7p1+Sun/8.8.8) with ESMTP id iAUBgj102919 for ; Tue, 30 Nov 2004 12:42:45 +0100 (CET) Message-ID: <41AC5CB5.7050103@cisco.com> Date: Tue, 30 Nov 2004 12:42:45 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Flow Keys versus Flow key 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, There is a problem with use of the term "flow keys" versus "flow key" in the architecture draft. The definition in both [IPFIX-ARCH] and [IPFIX-PROTO] is * Flow Key Each of the fields which 1. Belong to the packet header (e.g. destination IP address) 2. Are a property of the packet itself (e.g. packet length) 3. Are derived from packet treatment (e.g. AS number) and which are used to define a Flow are termed Flow Keys. The question boils down to: what is the flow key notion? 1. The flow key is the list of information elements? Example: The flow keys are: source IP address, destination IP address, and DSCP 2. Or the flow key is the set of all information elements? Example: The flow key is: {source IP address, destination IP address, DSCP} Personally, I prefer the option 2. - as this is the way it has been known in NetFlow - as this corresponds to the definition. Note that [IPFIX-PROTO] is consistent with the option 2 However, [IPFIX-ARCH] use the term "flow key" (option 1) - "If the Flow Key is defined as {source IP address, destination IP address, DSCP}, ..." - "This could be done by defining the Flow Key as {source IP address, destination IP address, DSCP}" I would propose to change those the sentences to: - "If the Flow Keys are defined as {source IP address, destination IP address, DSCP}, ..." - "This could be done by defining the Flow Keys as {source IP address, destination IP address, DSCP}" Feedback? 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 Nov 30 07:57:09 2004 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 HAA14249 for ; Tue, 30 Nov 2004 07:57:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CZ7Ux-00015J-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Nov 2004 06:52:51 -0600 Received: from faui70.informatik.uni-erlangen.de ([131.188.37.37]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CZ7Uw-000157-00 for ipfix@net.doit.wisc.edu; Tue, 30 Nov 2004 06:52:50 -0600 Received: from faui7pc4.informatik.uni-erlangen.de (faui7pc4 [131.188.37.69]) by faui70.informatik.uni-erlangen.de (8.9.3p2/8.1.3-FAU) with ESMTP id NAA09002; Tue, 30 Nov 2004 13:52:45 +0100 (MET) Received: from [127.0.0.1] (faui7pc4.informatik.uni-erlangen.de [192.168.37.42]) by faui7pc4.informatik.uni-erlangen.de (Postfix) with ESMTP id 63F789BD1; Tue, 30 Nov 2004 13:52:45 +0100 (CET) Message-ID: <41AC6D1E.2050605@informatik.uni-erlangen.de> Date: Tue, 30 Nov 2004 13:52:46 +0100 From: Falko Dressler Organization: University of Erlangen-Nuremberg User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Cc: Falko Dressler , Christoph Sommer Subject: [ipfix] Link between Data/Template and Options Data/Template X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime 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, for a couple of reasons, there should be the possibility to define a link between a data record or a template set and an options data record / options template. Currently, this link is only available in the opposite direction, i.e. from options to data. What is our intention? One thing is a planned IPFIX aggregation (see next mail) and there are other scenarios in which a collector requires an options data record in order to decode a received data record. Nevertheless, such a thing currently does not exist, that is, a data record might be wrong decoded just because the corresponding options record hasn't arrived yet. Cheers, Falko. -- 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/ -- 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 Nov 30 08:00:38 2004 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 IAA14425 for ; Tue, 30 Nov 2004 08:00:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CZ7WN-00016s-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Nov 2004 06:54:19 -0600 Received: from faui70.informatik.uni-erlangen.de ([131.188.37.37]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CZ7WL-00016i-00 for ipfix@net.doit.wisc.edu; Tue, 30 Nov 2004 06:54:17 -0600 Received: from faui7pc4.informatik.uni-erlangen.de (faui7pc4 [131.188.37.69]) by faui70.informatik.uni-erlangen.de (8.9.3p2/8.1.3-FAU) with ESMTP id NAA09046; Tue, 30 Nov 2004 13:54:12 +0100 (MET) Received: from [127.0.0.1] (faui7pc4.informatik.uni-erlangen.de [192.168.37.42]) by faui7pc4.informatik.uni-erlangen.de (Postfix) with ESMTP id 6ACE29BD1; Tue, 30 Nov 2004 13:54:12 +0100 (CET) Message-ID: <41AC6D75.2080807@informatik.uni-erlangen.de> Date: Tue, 30 Nov 2004 13:54:13 +0100 From: Falko Dressler Organization: University of Erlangen-Nuremberg User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Cc: Falko Dressler , Christoph Sommer Subject: [ipfix] IPFIX Concentrator X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------040502030003010505060305" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------040502030003010505060305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, currently, we are implementing an IPFIX aggregation tool, in IPFIX terminology a concentrator. Regarding the export of aggregated data, there are a couple of possible solutions, which (all) require the modification of IPFIX or the addition of some new propoerties. Before we come in with a new draft describing the aggragation mechanisms and (our) final solution, we want to ask this list for suggestions/remarks. Cheers, Falko -- 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/ --------------040502030003010505060305 Content-Type: text/plain; name="sa-concentrator.txt" Content-Disposition: inline; filename="sa-concentrator.txt" Content-Transfer-Encoding: 7bit 0 Abstract Due to the possibly high amount of measurement data exported using IPFIX we started a flow aggregation project. Aggregation should take place at a measurement point or on a separate flow concentrator (as mentioned in the IPFIX documents). Aggregation rules include the merging of flows with similar properties such as a common source network. Planning on implementing an IPFIX concentrator we were soon faced with the question of how to transmit the aggregated flows' shared properties (e.g. a Source IP in 192.168.0.0/23) via IPFIX. As all solutions we could find have their pros and cons and some need additions to IPFIX, we decided to post the ones we considered most fit to this mailing list for review and discussion. Different ways of sending these common properties will be presented in Section 1, while Section 2 deals with Data Types necessary or useful for doing so. Section 3 contains some thoughts on pros and cons of the different approaches presented. 1 Communicating common properties This section presents different ways of communicating field values that are constant for all records in a Data Set. In the examples used we assume our concentrator was given the following aggregation rules: - aggregate all flows with a source IP in 192.168.0.0/23 separating them only by their destination port - pass through all other flows These rules could be expressed as the following table: Protocol Src_Net Dst_Net Src_Ports Dst_Ports ------------------------------------------------------------------------------- any 192.168.0.0/23 any any each each each each each each We further assume our concentrator receives the following flow records: Src_IP Dst_IP Src_Port Dst_Port Pckts ------------------------------------------------------------------------------- 192.168.0.201 194.95.211.10 64235 80 10 192.168.1.202 194.95.211.11 64236 80 10 192.168.0.203 194.95.211.12 64237 110 10 192.168.2.204 194.95.211.13 64238 80 10 192.168.2.205 194.95.211.14 64239 80 10 1.1 Complete Data Set The most straightforward approach to communicating common properties is to simply transmit them with every flow record. Given the example rules and flows from above our concentrator would then output the following Data Set (provided a new portlist field): Src_IP Dst_IP Src_Port Dest_Port Pckts ------------------------------------------------------------------------------- 192.168.0.0/23 * * 80,110 20 192.168.2.204 194.95.211.13 64238 80 10 192.168.2.205 194.95.211.14 64239 80 10 1.2 Association of Data Sets with Option Data Sets This approach transmits all common properties in one option data record rather than in each data record. Now two ways of maintaining an association between transmitted data records and their option data records can be thought of: Only having the option data record refer to the data records (1.2.1) or having both refer to each other (1.2.2). 1.2.1 Implicit forward association This approach uses (1) one template for all non-aggregatable flows, (2) one template each for all flows matching a given aggregation rule, containing only discriminating properties of these flows, along with (3) one (option) template each describing common properties of these flows (1) will be directly passed through by the concentrator paying attention to reserve template IDs for (2) and (3). The association between (2) and (3) will be maintained by using (2)'s template ID as a scope value in (3). Given the example rules and flows from above our concentrator would now first transmit to the collector one Data Set that contains information about all flows that matched no given rule and were thus not aggregatable: Src_IP Dst_IP Src_Port Dest_Port Pckts -----------------------------------------------------------------(Set ID 257)-- 192.168.2.204 194.95.211.13 64238 80 10 192.168.2.205 194.95.211.14 64239 80 10 The second Data Set contains all flows that matched our aggregation rule. Note that besides the packet count only the flows' discriminating property, their destination port, is sent: Dest_Port Pckts -----------------------------------------------------------------(Set ID 258)-- 80 20 110 10 The final set, an option data set, refers to the Template used to transmit the aggregated flows and defines the property shared by all flows that use it - a source IP in 192.168.0.0/23: Template Src_IP -----------------------------------------------------------------(Set ID 259)-- 258 192.168.0.0/23 1.2.2 Explicit association This approach differs from (1.2.1) only in that now aggregated flow records will each contain a pointer to the option data set defining their common properties. Again the first Data Set our concentrator would now transmit to the collector contains information about all flows that matched no given rule and were thus not aggregatable: Src_IP Dst_IP Src_Port Dest_Port Pckts -----------------------------------------------------------------(Set ID 257)-- 192.168.2.204 194.95.211.13 64238 80 10 192.168.2.205 194.95.211.14 64239 80 10 The second Data Set contains all flows that matched our aggregation rule. This time each flow record explicitly points to the Option Template used to transmit common properties. See_also Dest_Port Pckts -----------------------------------------------------------------(Set ID 258)-- 259 80 20 259 110 10 Like in 1.2.1 the final set, an option data set, defines the property shared by all flows that use Template 258: A source IP in 192.168.0.0/23: Template Src_IP -----------------------------------------------------------------(Set ID 259)-- 258 192.168.0.0/23 1.3 Introduction of a new type of Template Set This approach uses a new type of Template, termed a Data Template. The 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 A. The format of individual Template definitions, however, differs from that of the standard Template and is shown in Figure B. 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 A: Template Set Format The Data Template Set field definitions are as follows: Set ID A Set ID value of 4 might be used for the Data Template Set. Length Total length of this Set in bytes. Padding See the description of a Type 3 Template Set in [PROTO] 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Field 1 Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Field N Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data 1 Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data 1 Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data M Type | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Data M Value | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure B: Data Template Format The Data Template field definitions are as follows: Template ID See the description of a Type 3 Template Set in [PROTO] 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. Field N Type Defined according to Section 7.2 in [PROTO]: Type identifier, Type length and an enterprise number, if needed. Data M Type Same as "Field N Type", but used for common properties of all Data Sets that use this Template. Data M Value Bit representation of a common property as would be transmitted in a Data Set. Given the example rules and flows from above our concentrator would now use one Template, say 257, to send all flows that matched no given rule and were thus not aggregatable: Src_IP Dst_IP Src_Port Dest_Port Pckts -----------------------------------------------------------------(Set ID 257)-- 192.168.2.204 194.95.211.13 64238 80 10 192.168.2.205 194.95.211.14 64239 80 10 The second Data Set uses a Data Template, say 258, to send all flows that matched our aggregation rule. Dest_Port Pckts (Src_IP=192.168.0.0/23) -----------------------------------------------------------------(Set ID 258)-- 80 20 110 10 2 Data Types 2.1 Networks 2.1.1 Different Data Types for IP and Netmask This is the traditional way of representing a network: IP address and netmask are transmitted as two fields: Src_IP Src_Mask Dst_IP Dst_Mask Pckts ------------------------------------------------------------------------------- 192.168.0.0 23 0.0.0.0 0 10 2.1.2 IP Networks Data Type This is an alternative way of representing networks: Both IP address and netmask are transmitted in one field with a Networks Data Type. Networks may be casted down to part of an IP address. It might also be used as a variable-length data type as defined in Chapter 11 of [PROTO], thus representing a list of networks. Examples for Networks: Network Length Binary_Representation ------------------------------------------------------------------------------- 192.168.0.0/24 3 0xC0A000 192.168.0.1 4 0xC0A00001 192.168.0.0/23 5 0xC0A00000 0x17 192.168.0.{1|3} 10 0xC0A00001 0x20 0xC0A00003 0x20 2.2 Port Ranges As the current draft contains no data type to transmit portlists or portranges, this section contains two alternatives for a new data type. 2.2.1 PortRanges Data Type This Data Type represents a list of port ranges. Its binary representation will be an arbitrary number of 4-byte sequences, each consisting of a 2-byte start port and a 2-byte end port specification. PortRanges may be casted down to a single Port or might also be used as a variable-length data type as defined in Chapter 11 of [PROTO]. Examples for PortRanges: Ports Length Binary_Representation ------------------------------------------------------------------------------- 80 2 0x0050 1:7 4 0x0001 0x0007 80, 443 8 0x0050 0x0050 0x01BB 0x01BB 1:7, 256:1024 8 0x0001 0x0007 0x0100 0x0400 20, 80, 443 12 0x0014 0x0014 0x0050 0x0050 0x01BB 0x01BB 1:7, 80, 443 12 0x0001 0x0007 0x0050 0x0050 0x01BB 0x01BB 2.2.2 Ports Data Type The interpretation of this Data Type will depend on its length. It can either represent a list of 2-byte port numbers or a list of 4-byte port ranges. In order to tell one representation from the other the plain port list will have an additional zero byte appended. Ports Length Binary_Representation ------------------------------------------------------------------------------- 80 2 0x0050 0x00 80,443 4 0x0050 0x01BB 0x00 1:7 5 0x0001 0x0007 20,80,443 6 0x0014 0x0050 0x01BB 0x00 1:7, 256:1024 9 0x0001 0x0007 0x0100 0x0400 1:7, 80, 443 12 0x0001 0x0007 0x0050 0x0050 0x01BB 0x01BB 3 Thoughts about the different approaches 3.1 Communicating common properties Approach 1.1 (Complete Data Set) seems least suitable for transmitting common properties, both because of the enormous overhead of sending the same constant values over and over again and because of the need for a dedicated "any" value for fields like Protocol or Flags. Aproach 1.2.1 (Implicit Forward Association) appears more promising but leaves the receiver in doubt as to whether a Template has any fixed values associated with it, long as the Options Data Record was not received yet and - in case of packet loss over SCTP or UDP - might even leave the receiver assuming that there just aren't any fixed values when in fact only the Options Data Set got lost. Approach 1.2.2 (Explicit Association) tries to fill this hole by embedding a pointer to the Options Data Set in each Data Record, but thus creates probably unnecessary overhead. Approach 1.3 (Introduction of a new Template Set) arguably uses the least overhead to transmit constant values, but at a price: Data Sets basing on a Data Template Set are illegible for clients implementing older versions of the IPFIX draft. One, however, has to keep in mind that all other approaches will also be at most partly understood by clients unaware of the possibility of aggregated flows. 3.2 Data Types Approach 2.1.1 (Different Data Types for IP and Netmask) represents the traditional way of transmitting networks. It can, however, only represent one single network. Approach 2.1.2 (IP Networks Data Type) bundles IP and Netmask into one field and may represent lists of Networks as well as single IPs. A con of this Data Type is that it is illegible for older clients. These clients are, however, unaware of concentrated flows and might such even produce wrong statistics when fed seperate data fields for IP and Netmask. For Ports, other that for networks, a new data type seems to be definitely needed. Approaches 2.2.1 and 2.2.2 differ only in that the latter may also represent a port list rather than a list of port ranges, making better use of space - be it in a Flow Record, in an Option Data Record or in a Template. Approach 2.2.2 is, however, somewhat more complex to interpret and might internally be treated like a list of port ranges anyway. --------------040502030003010505060305-- -- 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 Nov 30 10:07:54 2004 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 KAA25701 for ; Tue, 30 Nov 2004 10:07:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CZ9Q2-0004ga-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Nov 2004 08:55:54 -0600 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CZ9Q1-0004gV-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 30 Nov 2004 08:55:53 -0600 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2004 16:06:27 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAUEtnCu025162 for ; Tue, 30 Nov 2004 15:55:49 +0100 (MET) Received: from cisco.com (dhcp-rea-gp250-64-103-65-235.cisco.com [64.103.65.235]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA27859; Tue, 30 Nov 2004 14:55:48 GMT Message-ID: <41AC89F4.70208@cisco.com> Date: Tue, 30 Nov 2004 14:55:48 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Source ID = 0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit It might be useful if we were to reserve Source ID = 0 for use by the IPFIX protocol. This gives a means of extending the IPFIX header if we need to do so in the future. I therefore propose that the following text now reads. Source ID A 32-bit value that identifies the Exporter Process Observation Domain. Collecting Process SHOULD use the combination of the source IP address and the Source ID field to separate different export streams originating from the same Exporting Process. The Source ID value zero is reserved for future use. IPFIX Messages with a Source ID of zero MUST be discarded by the Collecting Process. - Stewart -- 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 Nov 30 10:13:28 2004 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 KAA26498 for ; Tue, 30 Nov 2004 10:13:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CZ9a2-000540-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Nov 2004 09:06:14 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CZ9a0-00053q-00 for ipfix-arch@net.doit.wisc.edu; Tue, 30 Nov 2004 09:06:12 -0600 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id F08961BAC99; Tue, 30 Nov 2004 16:06:10 +0100 (CET) Date: Tue, 30 Nov 2004 16:06:11 +0100 From: Juergen Quittek To: Benoit Claise , ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Flow Keys versus Flow key Message-ID: <2147483647.1101830771@[10.1.1.171]> In-Reply-To: <41AC5CB5.7050103@cisco.com> References: <41AC5CB5.7050103@cisco.com> X-Mailer: Mulberry/3.0.3 (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, The difference in usage is that option 2 uses the term 'flow key' for the entire set of flow properties that determine whether or not a packet is mapped to a flow. In contrast, option 1 uses the term 'flow key for each individual member of this set. In previous (ancient?) discussions we used option 2, for example Also RFC 2722 (and 2063) use option 2 and so does the NetFlow terminology. We might confuse people if we now choose the other option. 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 30.11.2004 12:42 h +0100 Benoit Claise wrote: > Dear all, > > There is a problem with use of the term "flow keys" versus "flow key" in the architecture draft. > > The definition in both [IPFIX-ARCH] and [IPFIX-PROTO] is > * Flow Key > Each of the fields which > 1. Belong to the packet header (e.g. destination IP address) > 2. Are a property of the packet itself (e.g. packet length) > 3. Are derived from packet treatment (e.g. AS number) > and which are used to define a Flow are termed Flow Keys. > > The question boils down to: what is the flow key notion? > 1. The flow key is the list of information elements? > Example: The flow keys are: source IP address, destination IP address, and DSCP > 2. Or the flow key is the set of all information elements? > Example: The flow key is: {source IP address, destination IP address, DSCP} > > > Personally, I prefer the option 2. - as this is the way it has been known in NetFlow > - as this corresponds to the definition. > Note that [IPFIX-PROTO] is consistent with the option 2 > > However, [IPFIX-ARCH] use the term "flow key" (option 1) > - "If the Flow Key is defined as {source IP address, destination IP address, DSCP}, ..." > - "This could be done by defining the Flow Key as {source IP address, destination IP address, DSCP}" > > I would propose to change those the sentences to: > - "If the Flow Keys are defined as {source IP address, destination IP address, DSCP}, ..." > - "This could be done by defining the Flow Keys as {source IP address, destination IP address, DSCP}" > > Feedback? > > 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 Tue Nov 30 10:33:20 2004 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 KAA28728 for ; Tue, 30 Nov 2004 10:33:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1CZ9uM-0005ZS-00 for ipfix-list@mil.doit.wisc.edu; Tue, 30 Nov 2004 09:27:14 -0600 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1CZ9uK-0005ZM-00; Tue, 30 Nov 2004 09:27:12 -0600 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 60BF11BAC99; Tue, 30 Nov 2004 16:27:11 +0100 (CET) Date: Tue, 30 Nov 2004 16:27:12 +0100 From: Juergen Quittek To: Benoit Claise , ipfix-chairs@net.doit.wisc.edu Cc: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] IANA: IPFIX ports request Message-ID: <2147483647.1101832032@[10.1.1.171]> In-Reply-To: <41AC5241.5010100@cisco.com> References: <41AC5241.5010100@cisco.com> X-Mailer: Mulberry/3.0.3 (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 When registering a port number, IANA wants to have a contact person idenitfied by name and email address. Who would this be? I want to make a suggestion for a port number: 4739 The number has not been assigned yet and it matches 'IPFX' on a telephone key pad. Usually IANA accepts suggested numbers and 'IPFX' would be a nice memory hook. 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 30.11.2004 11:58 h +0100 Benoit Claise wrote: > Dave, Nevil, > > As we start to close the final issues w.r.t. the IPFIX protocol draft, we should not forget about the IANA ports registration. > From the last meeting minutes; > [Note: Since there was no opposition voiced to acquiring a well-known port > number for IPFIX, the chairs will pursue this getting a port number > assigned by IANA.] > > Note: this email as a gentle reminder, as I have personally no clue how long it might take for the registration process. > > 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/