http://permalink.gmane.org/gmane.ietf.ipfix hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.ipfix/4963 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Flow Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-17.txt Pages : 33 Date : 2013-05-24 Abstract: Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring </pre> internet-drafts< at >ietf.org 2013-05-24T10:18:03 http://permalink.gmane.org/gmane.ietf.ipfix/4962 <pre>Greetings, all, This revision contains edits in response to a Security Directorate review from IETF LC, as well as adding a new section on privacy considerations for collected data, requested as part of a DISCUSS on the flow selection techniques draft. Best regards, Brian Begin forwarded message: _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Brian Trammell 2013-05-23T09:55:08 http://permalink.gmane.org/gmane.ietf.ipfix/4961 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-protocol-rfc5101bis-07.txt Pages : 69 Date : 2013-05-23 Abstract: This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Proces</pre> internet-drafts< at >ietf.org 2013-05-23T09:52:19 http://permalink.gmane.org/gmane.ietf.ipfix/4960 <pre>Hi, Paul, all, On 23 May 2013, at 11:40, Paul Aitken &lt;paitken&lt; at &gt;cisco.com&gt; wrote: Point. What's layer 6 in the IETF IP stack, though? Let's back off from layering for a moment. How about "transportedOctetDeltaCount"? The packet IE naming is harder though. "nonemptyPacketDeltaCount"? All the time. TCP handshakes and pure ACKs, for one (these are the ones I care about). SCTP control chunks. That'd be great. However, I'd like to implement these counters well before the complete revision of the Information Model implied by Extended Field Specifiers is complete. Cheers, Brian _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Brian Trammell 2013-05-23T09:47:22 http://permalink.gmane.org/gmane.ietf.ipfix/4959 <pre>Brian, Using "layer 7" in the name and "layer 4" in the definition leaves it unclear whether layer 6 should be included. Yesterday I got to wondering what exactly a layer 4 packet is. Put another way, how often do we send packets which don't have any layer 4 content? Now I'm wondering the same about layer 7 - ie, what sort of packets would - and more importantly _would not_ - be counted by layer7PacketDeltaCount ? BTW, recall the Extended Field Specifier Format? How useful if all these IEs could be grouped under a single pair of "packetCount" and "octetCount" IEs with multiple extensions, eg packetCount.{layerN}.{delta|total}. P. _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Paul Aitken 2013-05-23T09:40:35 http://permalink.gmane.org/gmane.ietf.ipfix/4958 <pre>hi, Paul, all, On 22 May 2013, at 13:57, Paul Aitken &lt;paitken&lt; at &gt;cisco.com&gt; wrote: I have the same problem with naming them layer7, actually. They're _not_ "layer4", though, since they count octets above the layer 4 headers. I suppose we could call them layer5, but that would almost certainly confuse everyone. Whether it would be more or less confusing than the _current_ names, though, I'm not sure. As specified, these four IEs that can never be unambiguously implemented by an RFC 5103 EP, since the presence of these IEs may or may not reverse the sense of forward and reverse direction. (There is a separate issue here, that 298 and 299 are presently so unclearly specified in my opinion as to be completely unimplementable. This will need to be fixed, but we can set that aside for the moment.) We certainly don't want to break existing implementations (any revision, per ie-doctors, must be interoperable; breaking existing implementations would not be). I'd thought that the intent of these IEs was to implemen</pre> Brian Trammell 2013-05-23T09:25:42 http://permalink.gmane.org/gmane.ietf.ipfix/4957 <pre>Brian, The existing IANA definitions and cisco definitions of these fields are in terms of "layer 4". I believe it's wrong to rename them to "layer7". There would be a difference between the "layer 4" and "layer 7" definitions if there's layer 6 encryption or EBCDIC/ASCII conversion. These fields were requested by cisco; they're documented in Appendix A here: http://www.cisco.com/en/US/docs/ios/solutions_docs/avc/ios_xe3_8/avc_soln_guide_iosxe3_8_full.pdf Although that doesn't give us ownership of these fields, if you change them then we'll no longer be compliant with the fields we requested :-( P. On 17/05/13 15:33, Brian Trammell wrote: _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Paul Aitken 2013-05-22T11:57:33 http://permalink.gmane.org/gmane.ietf.ipfix/4956 <pre>Benoit, Nevil, All, Option 3, "yes and no". A clear specification of the compliance criteria is a must. However, with the current compliance statement an implementation of all the specified Flow Sampling techniques without Property Match Filtering, is not compliant. Similarly, a device which implements Hash-based Flow Filtering rather than Property Match Filtering is not compliant. We can't predict what future device requirements will be or how the draft will be used. Therefore the choice of Property Match Filtering as the compliance criteria seems somewhat arbitrary. It may seem like an obvious choice today, but in future might turn out like the 640KB limit. We don't want this to be a decision we regret with hindsight as we struggle with an awkward implementation of Property Match Filteringsimply to claim compliance. So I'd prefer the compliance statement to say, "In order to be compliant with this document, at least one of the Filtering or Sampling techniques MUST be implemented." Or, "... </pre> Paul Aitken 2013-05-22T07:58:04 http://permalink.gmane.org/gmane.ietf.ipfix/4955 <pre>Hi Nevil, "yes, keep the compliance statement in section 6.1". I want to keep the consistency to makes it clear to implementors what's needed for a minimal conforming implementation, and to be similar to RFC 5475 Regards, Benoit (as a contributor) _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Benoit Claise 2013-05-22T06:35:04 http://permalink.gmane.org/gmane.ietf.ipfix/4954 <pre>Hi all: draft-ietf-ipfix-flow-selection-tech-16 is now in IESG Evaluation; it currently has a blocking DISCUSS Section 6.1 contains a compliance statement, which says "In order to be compliant with this document, at least the Property Match Filtering MUST be implemented." The AD concerned asks whether we could remove this requirement. This was triggered by a remark in my Shepherd statement for this draft, which said "This draft raised IPR concerns, in the same manner as the PSAMP selection draft had done. Nick Duffield (AT&amp;T) commented that the AT&amp;T IPR claim relates only to statistical sampling, and PSAMP handled this by saying "at least on of the sampling techniques must be implemented." In this draft, we have tightened that up a little by saying "a conforming implementation MUST implement at least the Property Match Filtering." I realise now that the IPR in question was that relating to draft-krishnan-opsawg-large-flow-load-balancing, which was discussed on the IPFIX lis</pre> Nevil Brownlee 2013-05-22T02:13:18 http://permalink.gmane.org/gmane.ietf.ipfix/4953 <pre>Hi, Andrew. Hm... Good point. Thanks. (Pedantically: "everything under Layer 4" might also include layer 5 -- if you're of the opinion that HTTP is really a session layer nowadays -- but I think most everyone will understand what is meant.) So I amend my proposal to: Element ID: 231 Name: layer7OctetDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for this Flow at the Observation Point since the previous report (if any). Element ID: 232 Name: reverseLayer7OctetDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of octets, excluding IP header(s) and Layer 4 transport protocol header(s), observed for the reverse direction of this Flow, as defined in RFC 5103, at the Observation Point since the previous report (if any). If present in a Flow Record along with layer7OctetDeltaCount, causes layer7OctetDeltaCount to refer to the forward direction o</pre> Brian Trammell 2013-05-17T14:33:52 http://permalink.gmane.org/gmane.ietf.ipfix/4952 <pre>Hi Brian, If you are looking for consistency I'd go with "layer7". There are already 3 "layer2" IEs including 2 octet counts (layer2OctetDeltaCount and layer2OctetTotalCount). Also the the table of values for classificationEngineId (101) all use L# or layer # in their descriptions. -Andrew On 05/17/2013 03:45 AM, Brian Trammell wrote: _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Andrew Feren 2013-05-17T14:10:49 http://permalink.gmane.org/gmane.ietf.ipfix/4951 <pre>Oops, hit reply instead of reply all... Begin forwarded message: _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Brian Trammell 2013-05-17T07:45:31 http://permalink.gmane.org/gmane.ietf.ipfix/4950 <pre>Brian, 1. Some mistake in the numbering in your new definitions: you've written 232 and 233 instead of 231 and 232. 2. What's the significance of "app" in these names? "Applicable"? "Application"? "Appearing"? "Appended"? "Approved"? "Appropriate"? "Approximate"? ... P. On 16/05/13 16:45, Brian Trammell wrote: _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Paul Aitken 2013-05-16T16:10:00 http://permalink.gmane.org/gmane.ietf.ipfix/4949 <pre>Greetings, all, Following a previous suggestion to update propose we modify the names and definitions of the initiatorOctets(231), responderOctets(232), initiatorPackets(298), and responderPackets(299) as follows, (1) to bring them in line with the naming of other IPFIX Information Elements, (2) to allow them to be used by RFC 5103-compliant biflow Exporting Processes, and (3) to ensure (especially in the case of 298 and 299) that the descriptions are interoperably implemented. I think the proposed descriptions reflect the intent of the present descriptions, within the context of RFC 5103 terminology, and should therefore not have any impact on interoperability; I note that the description of IEs 298 and 299 are, however, not decipherable as written, so I may be taking some necessary liberty with my interpretation. Element ID: 232 Name: appOctetDeltaCount Data Type: unsigned64 Semantics: deltaCounter Description: The number of octets, excluding IP header(s) and Layer 4 transport protocol header</pre> Brian Trammell 2013-05-16T15:45:05 http://permalink.gmane.org/gmane.ietf.ipfix/4948 <pre>This was discussed recently on the IPFIX mailing list, and the conclusion was to add the section 4 "Difference between Intermediate Flow Selection Process and Intermediate Selection Process" While the situation is not ideal, my advice would be to leave the situation as it is. I figured it was something like that, but I felt I had to ask. :) _______________________________________________ IPFIX mailing list IPFIX&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ipfix </pre> Ted Lemon 2013-05-12T21:41:42 http://permalink.gmane.org/gmane.ietf.ipfix/4947 <pre>Hi Ted, Just replying to this COMMENT above. Here is a little bit of history. RFC 6183, IP Flow Information Export (IPFIX) Mediation: Framework, specified a couple of terms. Those terms (and "Intermediate Selection Process" was one of them) were generic terms to be used by the different RFCs: RFC 6235, draft-ietf-ipfix-a9n-08, &lt;http://datatracker.ietf.org/doc/draft-ietf-ipfix-a9n/&gt;draft-ietf-ipfix-flow-selection-tech-16 &lt;http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/&gt;, draft-ietf-ipfix-mediation-protocol-04 &lt;http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol/&gt; However, when developing draft-ietf-ipfix-flow-selection-tech-16, &lt;http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/&gt;the authors realized that the "Intermediate Selection Process" definition [RFC6183] was not suitable. Hence the redefinition into "Intermediate Flow Selection Process". This was discussed recently on the IPFIX mailing list, and the conclusion was to add the sectio</pre> Benoit Claise 2013-05-12T21:08:33 http://permalink.gmane.org/gmane.ietf.ipfix/4946 <pre>Hi Nevil, Thanks for the response, I will follow up separately on this item. After further discussions in OPSAWG, all IPR related material has been removed from "draft-krishnan-opsawg-large-flow-load-balancing". The latest draft, version 8, reflects this. The IPR update, which will happen in the next couple of days, will reflect this. I have also made sure that all IPR related material has been removed from draft-krishnan-ipfix-flow-aware-packet-sampling. Thanks, Ramki -----Original Message----- From: Nevil Brownlee [mailto:n.brownlee&lt; at &gt;auckland.ac.nz] Sent: Sunday, April 28, 2013 7:10 PM To: ramki Krishnan Cc: Salvatore D'Antonio; tanja&lt; at &gt;caida.org; lorenzo.peluso&lt; at &gt;unina.it; IPFIX Working Group Subject: Re: [IPFIX] R: R: Last Call Expired: &lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt; Hi Ramki et al: The IETF Last Call for this draft finished on 8 April 13, it's been revised following feedback since then. It already has short sections about flow-dependent packet selection, including a reference to [EsVa</pre> ramki Krishnan 2013-04-29T04:15:11 http://permalink.gmane.org/gmane.ietf.ipfix/4945 <pre> Hi Ramki et al: The IETF Last Call for this draft finished on 8 April 13, it's been revised following feedback since then. It already has short sections about flow-dependent packet selection, including a reference to [EsVa01] Estan, C. and G,. Varghese, "New Directions in Traffic Measurement and Accounting: Focusing on the Elephants, Ignoring the Mice", ACM SIGCOMM Internet Measurement Workshop 2001, San Francisco (CA), November 2001 I regard that as the seminal paper for this particular topic; it was followed in 2004 by a SIGCOMM paper, "Building a better NetFlow" by Estan, Keys, Moore and Varghese. At this point I'd like to see this draft carried through its IESG consideration without the distraction (and delay) brought on by attempting to define parameters for flow-dependent selection in the draft at this very late stage. Better to continue discussion on the list so as to reach a firm consensus on them. When we have that, they could be easily added as r</pre> Nevil Brownlee 2013-04-29T02:10:02 http://permalink.gmane.org/gmane.ietf.ipfix/4944 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2< at >hushmail.com 2013-04-27T16:49:12 http://permalink.gmane.org/gmane.ietf.ipfix/4943 <pre>Dear Authors, The technique I am suggesting is “Multistage Filters” in [EsVa01] and not “Sample and Hold”. Apologies for the error. I have fixed the text – my suggested changes will be in an addition to what is there currently. I had a good discussion with Juergen on this topic. He suggested that I reach out to you folks at the earliest. Probably a separate sub-section in section 6 ??? An example is “Multistage Filters” [EsVa01], or similar techniques, that try to prefer long-lived large volume flows in the selection. When a packet arrives, these packet selection techniques are applied only if a flow record for the packet does not exist. These packet selection techniques could have false positives but no false negatives; i.e. flows which are not long-lived large flows may be selected and learnt in the flow cache. The flows which are not long-lived large flows are later purged from the flow cache. Suggested changes to Section 7 For techniques similar to “Multistage Filters”, th</pre> ramki Krishnan 2013-04-25T02:02:35 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ipfix