From trammell@tik.ee.ethz.ch Mon Apr 2 04:37:59 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B107421F8963 for ; Mon, 2 Apr 2012 04:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nug-c-JPjwe3 for ; Mon, 2 Apr 2012 04:37:59 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 497AD21F895F for ; Mon, 2 Apr 2012 04:37:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 00955D930B for ; Mon, 2 Apr 2012 13:37:56 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0Y-G+TCiXS2d for ; Mon, 2 Apr 2012 13:37:56 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A83DFD9304 for ; Mon, 2 Apr 2012 13:37:56 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 13:37:19 +0200 Message-Id: <0F5DB589-A334-4598-817C-D68DC2CA1724@tik.ee.ethz.ch> To: IETF IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [IPFIX] RFC 5101bis: Changes to MTI transport protocol and security X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:37:59 -0000 Greetings, all, Following up on the discussion at the WG meeting in Paris on Thursday, I = wanted to outline in more detail a proposal to slightly modify the = mandatory-to-implement transports for IPFIX. We have a problem in interoperability testing (our big open issue for = 5101bis): section 11.1 states that DTLS over SCTP MUST be implemented. = DTLS over SCTP was finally published on the standards track as RFC 6083 = in January 2011, but to my knowledge there still exist no = implementations of this on which an IPFIX implementation could be built = for interop testing. On the other hand, TLS over TCP was successfully = interop'd as far back as 2006. I would propose the following as a fix for this situation: 1. SCTP [RFC4960] with partial reliability [RFC3578] is the mandatory = transport protocol for IPFIX. This protocol is intended for use in = typical "walled garden" flow collection infrastructures within a single = administrative domain on closed/dedicated networks. These = infrastructures are often built with legacy flow collection applications = in mind (i.e. NetFlow over UDP), and provide security either through = physical or virtual separation at layer 2, or via tunneling when = necessary.=20 2. TLS over TCP is the mandatory transport protocol for IPFIX where = transport security is required. This protocol is intended for "open = Internet" usage of IPFIX, across administrative domains or from remote = sites to which a tunneled or physically secured network cannot be = extended. Note that the most serious drawback for IPFIX over TCP -- full = reliability leading to head-of-line blocking when transmitting at = capacity -- is generally less of an issue in such circumstances, as = these would usually be "post-mediator" applications, filtering or = aggregating the data to be sent remotely. 3. All other transport and transport security combinations are optional. This would require new text in 5101bis to explain the differences in = deployment requirements between "walled garden" and "open Internet" = deployments. I spoke informally to one of the security ADs, and he = indicated that personally did not consider defining SCTP and TCP/TLS as = the mandatories to be untenable, given the DTLS/SCTP situation. We do have a problem in that a 5101bis implementation is now = _technically_ not interoperable with an older 5101 implementation = (5101bis uses TLS over TCP, 5101 DTLS over SCTP), but since DTLS over = SCTP never worked this should not present a problem in practice. =01Recent developments in TSVWG include the definition of UDP = encapsulation of SCTP (WG item, to allow userspace implementation and = transit of SCTP-unaware or SCTP-hostile middleboxes) and DTLS over UDP = encapsulation of SCTP (individual draft = http://tools.ietf.org/id/draft-tuexen-tsvwg-sctp-dtls-encaps-00.txt -- = which appears to be targeted at solving a problem RTCWEB has). I believe = this second draft may lead to easier implementation than the present = DTLS over SCTP, as there already exist working DTLS over UDP = implementations. We could then define bindings for IPFIX over SCTP over DTLS over UDP in = a separate, later draft for open-internet deployments which require the = features of SCTP. But I don't think this belongs in 5101bis (especially as it's still = covered by a TSVWG individual draft). Thoughts? Best regards, Brian= From trammell@tik.ee.ethz.ch Mon Apr 2 04:38:38 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C66221F895F for ; Mon, 2 Apr 2012 04:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54D1JcQt2K2d for ; Mon, 2 Apr 2012 04:38:37 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 97D6121F895C for ; Mon, 2 Apr 2012 04:38:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E2775D930B for ; Mon, 2 Apr 2012 13:38:36 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3QTv6hzahRnm for ; Mon, 2 Apr 2012 13:38:36 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D8E12D9304 for ; Mon, 2 Apr 2012 13:38:35 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 13:33:53 +0200 Message-Id: To: IETF IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [IPFIX] RFC 5101bis: CP MUST Close and Simplified Template Management X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:38:38 -0000 Greetings, all, Following up on the discussion at the WG meeting in Paris on Thursday, = I'd like to clarify the issues with CP must close and proposed = simplified template management in RFC5101bis, and start the discussion = thereon. The _main_ problem IMO with RFC5101 template management is the language = stating the Collecting Process MUST close the session on the following = conditions: 1. Receiving a malformed message. (What a "malformed message" is is not = defined, though it is explicitly noted that non-zero Set padding does = not constitute a malformed message.) 2. Receiving a Template for a given Template ID which has been = previously defined without having been withdrawn (on SCTP and TCP). 3. Receiving a Template Withdrawal for a Template ID which is not = presently defined (on SCTP and TCP). The problems with this arrangement are as follows: 1. There is no way for a UDP collector to effectively terminate a = session, as over UDP, IPFIX is completely unidirectional. A CP can = certainly shutdown whenever it wants, but aside from ICMP Port = Unreachable or Host Unreachable messages, the EP cannot detect this. 2. The "error" signal is useless to the EP, because the EP cannot = distinguish CP close due to error versus CP close due to CP shutdown. 3. After having the session terminated by the CP, there is no effective = remedy at the EP to restart, as all the conditions leading to a CP close = are effectively "badly implemented EP which doesn't follow the protocol = on three specific points enumerated above. So, I propose removing the "CP MUST close" language, and replacing it = with "CP MUST ignore / SHOULD log" for malformed messages or other = anomalies.=20 The other issue with template management in RFC5101 is that it is = unnecessarily complex, especially on UDP, and that template management = operates completely differently over UDP than over TCP/SCTP, and SCTP = has some timing issues related to templates on multiple streams. UDP = template management, in particular, requires hand tuning of timeouts to = requirements, and will generally either "just work" (on properly = provisioned links) or not work at _all_ due to packet loss in transit or = insufficiently sized buffers at the endpoints. I'd like to fix this as well in 5101bis, especially as any template = management scheme other than "define templates at session start and = export them" has never been successfully interop'd.=20 The changes are defined in Section 8 of RFC5101bis, and were presented = at the WG meeting. Essentially, this is taken from RFC 5655 (IPFIX = files), and states that on all transports: 1. Templates MAY be resent at any time on any transport; they MUST be = sent on UDP. 2. UDP Collecting Processes MAY expire Templates not resent within a = configurable delay to save resources. 3. Template IDs SHOULD be withdrawn using a Template ID when they will = no longer be used.=20 4. Template Withdrawals MAY be sent on UDP. 5. Template IDs MAY be reused without withdrawal or expiration by simply = sending a new Template. 6. Template management actions MUST be sequenced in IPFIX Message Header = Export Time order. This sixth point is (perhaps poorly) addressed in Section 8.3 of = 5101bis. To clarify: A. an EP MUST ensure when defining a Template that it exports no = messages containing data sets described by the new Template with export = times _earlier_ than the message containing the template set. B. an EP MUST ensure when withdrawing a Template ID that it exports no = messages containing data sets described by the withdrawn template with = export times _later_ than the message containing the withdrawal. C. an EP MUST ensure when reusing a Template ID that the following = actions are uniquely sequenceable in the following order by the Export = Time of the containing messages: i. last export of a data set described by the old template ii. withdrawal (if present) iii. definition of new template for reused template ID iv. first export of a data set described by the new template D. Sequencing actions within a Message counts (i.e., a message could = contain a template followed by data sets described thereby); it is not = yet clear to me how to account for (UDP) reordering of Messages with the = same Export Time. The intent in the new section 8 is that the SHOULD language is = compatible with the old, complex template management in 5101, while = 5101bis EPs MAY use the simplifications to ease multi-transport = implementation. Note that points 1 (on SCTP, TCP), 4, and 5 would cause = 5101 CPs which actually implement MUST close to do so. There is a pending question before our new AD as to whether this is = acceptably interoperable with respect to 5101bis advancing IPFIX to full = standard. Other questions, comments, concerns, flames, please, the floor is open. = :) Best regards, Brian From trammell@tik.ee.ethz.ch Mon Apr 2 04:45:16 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9469521F891C for ; Mon, 2 Apr 2012 04:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.267 X-Spam-Level: X-Spam-Status: No, score=-5.267 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jP3fphUH+um for ; Mon, 2 Apr 2012 04:45:16 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD8B21F889D for ; Mon, 2 Apr 2012 04:45:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 114EBD930C for ; Mon, 2 Apr 2012 13:38:37 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Uv40RlIt5dsw for ; Mon, 2 Apr 2012 13:38:36 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1DC34D9308 for ; Mon, 2 Apr 2012 13:38:36 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/html; charset=us-ascii X-Apple-Base-Url: x-msg://296/ X-Apple-Mail-Remote-Attachments: YES From: Brian Trammell X-Apple-Mail-Plain-Text-Draft: yes X-Apple-Windows-Friendly: 1 Date: Mon, 2 Apr 2012 13:37:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: X-Uniform-Type-Identifier: com.apple.mail-draft To: IETF IPFIX Working Group X-Mailer: Apple Mail (2.1257) Subject: [IPFIX] RFC 5101bis: On Interoperability Testing X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:45:16 -0000 Greetings, all,

The largest remaining open = issue in RFC5101bis is that of interoperability. As per the presentation = in Paris, the following things have never been successfully interop = tested:

1. Template withdrawal and ID reuse (section 8.1)
2. = Template stream separation in SCTP (section 8.3)
3. Template = expiration in UDP (section 8.4)
4. Multiple-stream export in SCTP = (section 10.2.6)
5. DTLS over SCTP and UDP (section 11.1)

Of = these, 1 requires a resolution to the discussion on simplified template = management, and 5 requires a resolution to the discussion on MTI = transport protocols. 2-4 are stable features with no change or = clarification in 5101bis, and could be in theory tested immediately by = any compliant implementation.

As I expect the limiting factor on = the publication of 5101bis and the advancement of the protocol is the = successful interoperability testing of these features (along with the = basic operation of the protocol), IMO it makes sense to begin planning = interop testing ASAP. We need to discuss location and timeframe, but = more important is:

1. who has an implementation of an IPFIX EP = and/or CP ready for test, and is willing to participate in = interoperability testing?

2. of the five missing features listed = above, who has a working implementation of them (subject, of course, to = the other noted discussions...)?

Once we have an idea of who and = what, we can start talking when and where, I think.

Best = regards,

Brian


= From muenz@net.in.tum.de Mon Apr 2 13:13:22 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263FB21F86C7 for ; Mon, 2 Apr 2012 13:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+tfIUc9sCtp for ; Mon, 2 Apr 2012 13:13:21 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2B15A21F86BA for ; Mon, 2 Apr 2012 13:13:20 -0700 (PDT) Received: from [192.168.2.26] (e181138227.adsl.alicedsl.de [85.181.138.227]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 55B26204BE34; Mon, 2 Apr 2012 22:13:19 +0200 (CEST) Message-ID: <4F7A0853.3090600@net.in.tum.de> Date: Mon, 02 Apr 2012 22:13:07 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian Trammell References: <0F5DB589-A334-4598-817C-D68DC2CA1724@tik.ee.ethz.ch> In-Reply-To: <0F5DB589-A334-4598-817C-D68DC2CA1724@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis: Changes to MTI transport protocol and security X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:13:22 -0000 Brian, I think that it is reasonable to relax the MTI transports for IPFIX. Looking at your e-mail, I would not call the MTI transports "mandatory transport protocols" because this sounds as if their usage is mandatory in the given context - which is not. The "optional transports" can be used as well. If I understand correctly, you want to make TLS/TCP mandatory to implement, while the implementation of DTLS/SCTP shall become optional in RFC5101. What about implementations which already support DTLS/SCTP but not TLS/TCP? Will they become non-compliant? What about implementations which will only be used in a "walled garden"? Do they need to implement TLS/TCP although it will never be used? Is it actually necessary to specify any MTI transports, apart from SCTP-PR? Isn't it sufficient to specify that TLS should or must be supported when TCP is implemented? It makes much sense to strongly recommend (or mandate) the usage of encryption for any IPFIX transport over untrusted networks. Whether this is realized using TLS, DTLS, IPSEC or whatever is not important. Thanks, Gerhard On 02.04.2012 13:37, Brian Trammell wrote: > Greetings, all, > > Following up on the discussion at the WG meeting in Paris on Thursday, I wanted to outline in more detail a proposal to slightly modify the mandatory-to-implement transports for IPFIX. > > We have a problem in interoperability testing (our big open issue for 5101bis): section 11.1 states that DTLS over SCTP MUST be implemented. DTLS over SCTP was finally published on the standards track as RFC 6083 in January 2011, but to my knowledge there still exist no implementations of this on which an IPFIX implementation could be built for interop testing. On the other hand, TLS over TCP was successfully interop'd as far back as 2006. > > I would propose the following as a fix for this situation: > > 1. SCTP [RFC4960] with partial reliability [RFC3578] is the mandatory transport protocol for IPFIX. This protocol is intended for use in typical "walled garden" flow collection infrastructures within a single administrative domain on closed/dedicated networks. These infrastructures are often built with legacy flow collection applications in mind (i.e. NetFlow over UDP), and provide security either through physical or virtual separation at layer 2, or via tunneling when necessary. > > 2. TLS over TCP is the mandatory transport protocol for IPFIX where transport security is required. This protocol is intended for "open Internet" usage of IPFIX, across administrative domains or from remote sites to which a tunneled or physically secured network cannot be extended. Note that the most serious drawback for IPFIX over TCP -- full reliability leading to head-of-line blocking when transmitting at capacity -- is generally less of an issue in such circumstances, as these would usually be "post-mediator" applications, filtering or aggregating the data to be sent remotely. > > 3. All other transport and transport security combinations are optional. > > This would require new text in 5101bis to explain the differences in deployment requirements between "walled garden" and "open Internet" deployments. I spoke informally to one of the security ADs, and he indicated that personally did not consider defining SCTP and TCP/TLS as the mandatories to be untenable, given the DTLS/SCTP situation. > > We do have a problem in that a 5101bis implementation is now _technically_ not interoperable with an older 5101 implementation (5101bis uses TLS over TCP, 5101 DTLS over SCTP), but since DTLS over SCTP never worked this should not present a problem in practice. > > Recent developments in TSVWG include the definition of UDP encapsulation of SCTP (WG item, to allow userspace implementation and transit of SCTP-unaware or SCTP-hostile middleboxes) and DTLS over UDP encapsulation of SCTP (individual draft http://tools.ietf.org/id/draft-tuexen-tsvwg-sctp-dtls-encaps-00.txt -- which appears to be targeted at solving a problem RTCWEB has). I believe this second draft may lead to easier implementation than the present DTLS over SCTP, as there already exist working DTLS over UDP implementations. > > We could then define bindings for IPFIX over SCTP over DTLS over UDP in a separate, later draft for open-internet deployments which require the features of SCTP. > But I don't think this belongs in 5101bis (especially as it's still covered by a TSVWG individual draft). > > Thoughts? > > Best regards, > > Brian > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Mon Apr 2 13:44:24 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF37121F86A3 for ; Mon, 2 Apr 2012 13:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.954 X-Spam-Level: X-Spam-Status: No, score=-5.954 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbUpk0S+3Ovi for ; Mon, 2 Apr 2012 13:44:24 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id CB48421F86A1 for ; Mon, 2 Apr 2012 13:44:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 68D43D9305; Mon, 2 Apr 2012 22:44:22 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6srMY2kTc0JF; Mon, 2 Apr 2012 22:44:22 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 014F2D9304; Mon, 2 Apr 2012 22:44:21 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F7A0853.3090600@net.in.tum.de> Date: Mon, 2 Apr 2012 22:44:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F5DB589-A334-4598-817C-D68DC2CA1724@tik.ee.ethz.ch> <4F7A0853.3090600@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1257) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis: Changes to MTI transport protocol and security X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:44:25 -0000 Hi, Gerhard, Thanks for your reply; replies thereon inline... On Apr 2, 2012, at 10:13 PM, Gerhard Muenz wrote: >=20 > Brian, >=20 > I think that it is reasonable to relax the MTI transports for IPFIX. >=20 > Looking at your e-mail, I would not call the MTI transports "mandatory = transport protocols" because this sounds as if their usage is mandatory = in the given context - which is not. The "optional transports" can be = used as well. Good point; will tighten up the language that goes into the document, = should we make this change. > If I understand correctly, you want to make TLS/TCP mandatory to = implement, while the implementation of DTLS/SCTP shall become optional = in RFC5101. Yes -> the MTI protocols would be SCTP and TLS/TCP. > What about implementations which already support DTLS/SCTP but not = TLS/TCP? Will they become non-compliant? Essentially, yes. (Are there currently working DTLS/SCTP implementations = which don't support TLS/TCP?) > What about implementations which will only be used in a "walled = garden"? Do they need to implement TLS/TCP although it will never be = used? I would intend not; this depends on how/whether we can specify a = deployment-scenario-dependent MTI. > Is it actually necessary to specify any MTI transports, apart from = SCTP-PR? >=20 > Isn't it sufficient to specify that TLS should or must be supported = when TCP is implemented? >=20 > It makes much sense to strongly recommend (or mandate) the usage of = encryption for any IPFIX transport over untrusted networks. Whether this = is realized using TLS, DTLS, IPSEC or whatever is not important. As I recall from the discussions of this issue in 5101 back in = 2006-2007, the security area would not have been (and likely would still = not be) happy with us defining a single MTI which did not provide any = security; defining "security by tunnel" in the general case was not = acceptable. Therefore the proposal to separate the transport out by deployment = requirements. Thanks, and best regards, Brian > On 02.04.2012 13:37, Brian Trammell wrote: >> Greetings, all, >>=20 >> Following up on the discussion at the WG meeting in Paris on = Thursday, I wanted to outline in more detail a proposal to slightly = modify the mandatory-to-implement transports for IPFIX. >>=20 >> We have a problem in interoperability testing (our big open issue for = 5101bis): section 11.1 states that DTLS over SCTP MUST be implemented. = DTLS over SCTP was finally published on the standards track as RFC 6083 = in January 2011, but to my knowledge there still exist no = implementations of this on which an IPFIX implementation could be built = for interop testing. On the other hand, TLS over TCP was successfully = interop'd as far back as 2006. >>=20 >> I would propose the following as a fix for this situation: >>=20 >> 1. SCTP [RFC4960] with partial reliability [RFC3578] is the mandatory = transport protocol for IPFIX. This protocol is intended for use in = typical "walled garden" flow collection infrastructures within a single = administrative domain on closed/dedicated networks. These = infrastructures are often built with legacy flow collection applications = in mind (i.e. NetFlow over UDP), and provide security either through = physical or virtual separation at layer 2, or via tunneling when = necessary. >>=20 >> 2. TLS over TCP is the mandatory transport protocol for IPFIX where = transport security is required. This protocol is intended for "open = Internet" usage of IPFIX, across administrative domains or from remote = sites to which a tunneled or physically secured network cannot be = extended. Note that the most serious drawback for IPFIX over TCP -- full = reliability leading to head-of-line blocking when transmitting at = capacity -- is generally less of an issue in such circumstances, as = these would usually be "post-mediator" applications, filtering or = aggregating the data to be sent remotely. >>=20 >> 3. All other transport and transport security combinations are = optional. >>=20 >> This would require new text in 5101bis to explain the differences in = deployment requirements between "walled garden" and "open Internet" = deployments. I spoke informally to one of the security ADs, and he = indicated that personally did not consider defining SCTP and TCP/TLS as = the mandatories to be untenable, given the DTLS/SCTP situation. >>=20 >> We do have a problem in that a 5101bis implementation is now = _technically_ not interoperable with an older 5101 implementation = (5101bis uses TLS over TCP, 5101 DTLS over SCTP), but since DTLS over = SCTP never worked this should not present a problem in practice. >>=20 >> =01Recent developments in TSVWG include the definition of UDP = encapsulation of SCTP (WG item, to allow userspace implementation and = transit of SCTP-unaware or SCTP-hostile middleboxes) and DTLS over UDP = encapsulation of SCTP (individual draft = http://tools.ietf.org/id/draft-tuexen-tsvwg-sctp-dtls-encaps-00.txt -- = which appears to be targeted at solving a problem RTCWEB has). I believe = this second draft may lead to easier implementation than the present = DTLS over SCTP, as there already exist working DTLS over UDP = implementations. >>=20 >> We could then define bindings for IPFIX over SCTP over DTLS over UDP = in a separate, later draft for open-internet deployments which require = the features of SCTP. >> But I don't think this belongs in 5101bis (especially as it's still = covered by a TSVWG individual draft). >>=20 >> Thoughts? >>=20 >> Best regards, >>=20 >> Brian >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Mon Apr 2 13:58:30 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FCF21F85F8 for ; Mon, 2 Apr 2012 13:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXbPtcMsYqXZ for ; Mon, 2 Apr 2012 13:58:30 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF6321F85EE for ; Mon, 2 Apr 2012 13:58:26 -0700 (PDT) Received: from [192.168.2.26] (e181138227.adsl.alicedsl.de [85.181.138.227]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 47656204BE34; Mon, 2 Apr 2012 22:58:25 +0200 (CEST) Message-ID: <4F7A12E1.6080608@net.in.tum.de> Date: Mon, 02 Apr 2012 22:58:09 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian Trammell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis: CP MUST Close and Simplified Template Management X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:58:31 -0000 Brian, See inline. On 02.04.2012 13:33, Brian Trammell wrote: > Greetings, all, > > Following up on the discussion at the WG meeting in Paris on Thursday, I'd like to clarify the issues with CP must close and proposed simplified template management in RFC5101bis, and start the discussion thereon. > > The _main_ problem IMO with RFC5101 template management is the language stating the Collecting Process MUST close the session on the following conditions: > > 1. Receiving a malformed message. (What a "malformed message" is is not defined, though it is explicitly noted that non-zero Set padding does not constitute a malformed message.) > > 2. Receiving a Template for a given Template ID which has been previously defined without having been withdrawn (on SCTP and TCP). > > 3. Receiving a Template Withdrawal for a Template ID which is not presently defined (on SCTP and TCP). > > The problems with this arrangement are as follows: > > 1. There is no way for a UDP collector to effectively terminate a session, as over UDP, IPFIX is completely unidirectional. A CP can certainly shutdown whenever it wants, but aside from ICMP Port Unreachable or Host Unreachable messages, the EP cannot detect this. > > 2. The "error" signal is useless to the EP, because the EP cannot distinguish CP close due to error versus CP close due to CP shutdown. > > 3. After having the session terminated by the CP, there is no effective remedy at the EP to restart, as all the conditions leading to a CP close are effectively "badly implemented EP which doesn't follow the protocol on three specific points enumerated above. I do not see the link to conditions 1 to 3. The three problems concern UDP. Conditions 2 and 3 do not affect UDP. Regarding condition 1, I would assume that a message containing Data Sets for a Template which is unknown to the CP is not "malformed" in the sense of RFC5101. This is the only problem which can happen if UDP collector crashes. Due to the retransmission, it is not a problem. > So, I propose removing the "CP MUST close" language, and replacing it with "CP MUST ignore / SHOULD log" for malformed messages or other anomalies. This is ok. Collectors should be tolerant in what they receive. > The other issue with template management in RFC5101 is that it is unnecessarily complex, especially on UDP, and that template management operates completely differently over UDP than over TCP/SCTP, and SCTP has some timing issues related to templates on multiple streams. UDP template management, in particular, requires hand tuning of timeouts to requirements, and will generally either "just work" (on properly provisioned links) or not work at _all_ due to packet loss in transit or insufficiently sized buffers at the endpoints. > > I'd like to fix this as well in 5101bis, especially as any template management scheme other than "define templates at session start and export them" has never been successfully interop'd. I do not see that the changes proposed below solve any of the UDP issues. IPFIX over UDP will still depend on proper timeout configuration and good luck. Therefore, UDP exporters and collectors will still differ from TCP and SCTP exporters and collectors. I think that it is a good idea to relax the UDP transport specification and to remove restrictions which require a distinct behavior from TCP and SCTP. However, I do not see any advantage in changing the current TCP and SCTP transport specifications for IPFIX. I would prefer keeping changes small (e.g. restrict changes to UDP transport) in order to increase interoperability between RFC5101 and ~bis. Changing the protocol just to make it easier for a few people to implement all transports is not a good argument because most transports are optional anyway. > The changes are defined in Section 8 of RFC5101bis, and were presented at the WG meeting. Essentially, this is taken from RFC 5655 (IPFIX files), and states that on all transports: > > 1. Templates MAY be resent at any time on any transport; they MUST be sent on UDP. I do not see how this helps UDP. I do not see any advantages for TCP and SCTP. I would keep the original spec and allow resending for UDP only. > 2. UDP Collecting Processes MAY expire Templates not resent within a configurable delay to save resources. Ok. This clarifies that infinite expiration timeouts are allowed. > 3. Template IDs SHOULD be withdrawn using a Template ID when they will no longer be used. I would keep the MUST for TCP and SCTP. I do not see any advantage in removing this rule. > 4. Template Withdrawals MAY be sent on UDP. Ok. Template Withdrawal does not hurt in case of UDP. Also, it can be used by the exporter to "close" the session. > 5. Template IDs MAY be reused without withdrawal or expiration by simply sending a new Template. This causes incompatibility with RFC5101 without offering any advantages. I would keep the mandatory withdrawal for TCP and SCTP. > 6. Template management actions MUST be sequenced in IPFIX Message Header Export Time order. This is a reasonable clarification. > This sixth point is (perhaps poorly) addressed in Section 8.3 of 5101bis. To clarify: > > A. an EP MUST ensure when defining a Template that it exports no messages containing data sets described by the new Template with export times _earlier_ than the message containing the template set. How can the EP ensure this in case of SCTP with multiple streams? It is difficult for an application to obtain information from the SCTP socket when a message has left the interface card. It's a question of when the exporter can assume that a message is exported. > B. an EP MUST ensure when withdrawing a Template ID that it exports no messages containing data sets described by the withdrawn template with export times _later_ than the message containing the withdrawal. Same as above. > C. an EP MUST ensure when reusing a Template ID that the following actions are uniquely sequenceable in the following order by the Export Time of the containing messages: > > i. last export of a data set described by the old template > ii. withdrawal (if present) > iii. definition of new template for reused template ID > iv. first export of a data set described by the new template Good idea. Thanks, Gerhard > D. Sequencing actions within a Message counts (i.e., a message could contain a template followed by data sets described thereby); it is not yet clear to me how to account for (UDP) reordering of Messages with the same Export Time. > > The intent in the new section 8 is that the SHOULD language is compatible with the old, complex template management in 5101, while 5101bis EPs MAY use the simplifications to ease multi-transport implementation. Note that points 1 (on SCTP, TCP), 4, and 5 would cause 5101 CPs which actually implement MUST close to do so. > > There is a pending question before our new AD as to whether this is acceptably interoperable with respect to 5101bis advancing IPFIX to full standard. > > Other questions, comments, concerns, flames, please, the floor is open. :) > > Best regards, > > Brian > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Mon Apr 2 14:00:59 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7C521F8600 for ; Mon, 2 Apr 2012 14:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY+co1TTIx2L for ; Mon, 2 Apr 2012 14:00:58 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5A17221F85F8 for ; Mon, 2 Apr 2012 14:00:58 -0700 (PDT) Received: from [192.168.2.26] (e181138227.adsl.alicedsl.de [85.181.138.227]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 59E89204BE34; Mon, 2 Apr 2012 23:00:57 +0200 (CEST) Message-ID: <4F7A1379.4090906@net.in.tum.de> Date: Mon, 02 Apr 2012 23:00:41 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian Trammell References: <0F5DB589-A334-4598-817C-D68DC2CA1724@tik.ee.ethz.ch> <4F7A0853.3090600@net.in.tum.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis: Changes to MTI transport protocol and security X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 21:00:59 -0000 Brian, >> What about implementations which already support DTLS/SCTP but not TLS/TCP? Will they become non-compliant? > > Essentially, yes. (Are there currently working DTLS/SCTP implementations which don't support TLS/TCP?) Vermont does not support TCP at all, but DTLS/SCTP on FreeBSD. Gerhard From trammell@tik.ee.ethz.ch Mon Apr 2 23:23:51 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E9321F8625 for ; Mon, 2 Apr 2012 23:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAcm4xONBLH9 for ; Mon, 2 Apr 2012 23:23:51 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C26BD21F85B6 for ; Mon, 2 Apr 2012 23:23:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6C5F2D9307; Tue, 3 Apr 2012 08:23:41 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3HBqw3YgYxEn; Tue, 3 Apr 2012 08:23:41 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 324D8D9305; Tue, 3 Apr 2012 08:23:41 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F7A1379.4090906@net.in.tum.de> Date: Tue, 3 Apr 2012 08:23:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F5DB589-A334-4598-817C-D68DC2CA1724@tik.ee.ethz.ch> <4F7A0853.3090600@net.in.tum.de> <4F7A1379.4090906@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1257) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis: Changes to MTI transport protocol and security X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 06:23:51 -0000 Hi, Gerhard, Ah. I should have known that, sorry. Part of the argument for changing = MTIs is the unimplementability of DTLS/SCTP, which Vermont would clearly = seem to have disproven. So if we do this, we will have to find a way to do so that does not make = existing implementations non-compliant. Thanks, cheers, Brian On Apr 2, 2012, at 11:00 PM, Gerhard Muenz wrote: >=20 > Brian, >=20 >>> What about implementations which already support DTLS/SCTP but not = TLS/TCP? Will they become non-compliant? >>=20 >> Essentially, yes. (Are there currently working DTLS/SCTP = implementations which don't support TLS/TCP?) >=20 > Vermont does not support TCP at all, but DTLS/SCTP on FreeBSD. >=20 > Gerhard From trammell@tik.ee.ethz.ch Tue Apr 3 06:35:15 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F15D11E8096 for ; Tue, 3 Apr 2012 06:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFTYeC-vjWwc for ; Tue, 3 Apr 2012 06:35:14 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 53AC011E808E for ; Tue, 3 Apr 2012 06:35:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7FBF1D9307; Tue, 3 Apr 2012 15:35:12 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vKQ7EWKACKAc; Tue, 3 Apr 2012 15:35:12 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3D981D9305; Tue, 3 Apr 2012 15:35:12 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F7A12E1.6080608@net.in.tum.de> Date: Tue, 3 Apr 2012 15:35:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F7A12E1.6080608@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1257) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis: CP MUST Close and Simplified Template Management X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:35:15 -0000 Hi, Gerhard, Thanks for the comments; replies inline as per tradition... On Apr 2, 2012, at 10:58 PM, Gerhard Muenz wrote: >=20 > Brian, >=20 > See inline. >=20 > On 02.04.2012 13:33, Brian Trammell wrote: >> Greetings, all, >>=20 >> Following up on the discussion at the WG meeting in Paris on = Thursday, I'd like to clarify the issues with CP must close and proposed = simplified template management in RFC5101bis, and start the discussion = thereon. >>=20 >> The _main_ problem IMO with RFC5101 template management is the = language stating the Collecting Process MUST close the session on the = following conditions: >>=20 >> 1. Receiving a malformed message. (What a "malformed message" is is = not defined, though it is explicitly noted that non-zero Set padding = does not constitute a malformed message.) >>=20 >> 2. Receiving a Template for a given Template ID which has been = previously defined without having been withdrawn (on SCTP and TCP). >>=20 >> 3. Receiving a Template Withdrawal for a Template ID which is not = presently defined (on SCTP and TCP). >>=20 >> The problems with this arrangement are as follows: >>=20 >> 1. There is no way for a UDP collector to effectively terminate a = session, as over UDP, IPFIX is completely unidirectional. A CP can = certainly shutdown whenever it wants, but aside from ICMP Port = Unreachable or Host Unreachable messages, the EP cannot detect this. >>=20 >> 2. The "error" signal is useless to the EP, because the EP cannot = distinguish CP close due to error versus CP close due to CP shutdown. >>=20 >> 3. After having the session terminated by the CP, there is no = effective remedy at the EP to restart, as all the conditions leading to = a CP close are effectively "badly implemented EP which doesn't follow = the protocol on three specific points enumerated above. >=20 > I do not see the link to conditions 1 to 3. >=20 > The three problems concern UDP. Conditions 2 and 3 do not affect UDP. Indeed, it's unclear what CP must close means on UDP. > Regarding condition 1, I would assume that a message containing Data = Sets for a Template which is unknown to the CP is not "malformed" in the = sense of RFC5101. This is the only problem which can happen if UDP = collector crashes. Due to the retransmission, it is not a problem. Correct. (Indeed, this is IMO further evidence that "malformed message" = doesn't mean anything either. Of course, a CP has to protect itself from = a malicious or clearly broken EP, but we do this in section 11.4, more = or less.) >> So, I propose removing the "CP MUST close" language, and replacing it = with "CP MUST ignore / SHOULD log" for malformed messages or other = anomalies. >=20 > This is ok. Collectors should be tolerant in what they receive. >=20 >> The other issue with template management in RFC5101 is that it is = unnecessarily complex, especially on UDP, and that template management = operates completely differently over UDP than over TCP/SCTP, and SCTP = has some timing issues related to templates on multiple streams. UDP = template management, in particular, requires hand tuning of timeouts to = requirements, and will generally either "just work" (on properly = provisioned links) or not work at _all_ due to packet loss in transit or = insufficiently sized buffers at the endpoints. >>=20 >> I'd like to fix this as well in 5101bis, especially as any template = management scheme other than "define templates at session start and = export them" has never been successfully interop'd. >=20 > I do not see that the changes proposed below solve any of the UDP = issues. IPFIX over UDP will still depend on proper timeout configuration = and good luck. Therefore, UDP exporters and collectors will still differ = from TCP and SCTP exporters and collectors. Indeed. However, it would be nice if the documents acknowledged this; = the current 5101 template management seems based on rules of thumb and = give the impression that UDP template management can be made to work if = these are followed; in reality it's up to the provisioning of the = network (and good luck). If your pipes and buffers are big enough it = works, otherwise no amount of timeout and retransmit will give you = acceptable performance. (If you're willing to lose more than, say, 10% = of your flows, I'd submit you don't actually want to be collecting = unsampled flows in the first place.) > I think that it is a good idea to relax the UDP transport = specification and to remove restrictions which require a distinct = behavior from TCP and SCTP. However, I do not see any advantage in = changing the current TCP and SCTP transport specifications for IPFIX. >=20 > I would prefer keeping changes small (e.g. restrict changes to UDP = transport) in order to increase interoperability between RFC5101 and = ~bis. Changing the protocol just to make it easier for a few people to = implement all transports is not a good argument because most transports = are optional anyway. This is a very good point. I'll work up an alternate proposal based on = these comments to minimize changes. (These should also have the effect = of minimizing the possible incompatibility with 5101...) >> The changes are defined in Section 8 of RFC5101bis, and were = presented at the WG meeting. Essentially, this is taken from RFC 5655 = (IPFIX files), and states that on all transports: >>=20 >> 1. Templates MAY be resent at any time on any transport; they MUST be = sent on UDP. >=20 > I do not see how this helps UDP. I do not see any advantages for TCP = and SCTP. I would keep the original spec and allow resending for UDP = only. Good point, noted. >> 2. UDP Collecting Processes MAY expire Templates not resent within a = configurable delay to save resources. >=20 > Ok. This clarifies that infinite expiration timeouts are allowed. Another key here is that the protocol shouldn't prevent the CP from = keeping state that it might have another reason to. >> 3. Template IDs SHOULD be withdrawn using a Template ID when they = will no longer be used. >=20 > I would keep the MUST for TCP and SCTP. I do not see any advantage in = removing this rule. Other than using nc or some other "dumb" EP to send a file via TCP that = was itself received via UDP. But yes, that looks pretty much like the = definition of "corner case". :) >> 4. Template Withdrawals MAY be sent on UDP. >=20 > Ok. Template Withdrawal does not hurt in case of UDP. Also, it can be = used by the exporter to "close" the session. It also wouldn't lead to a UDP session reset, because there is no such = thing. >> 5. Template IDs MAY be reused without withdrawal or expiration by = simply sending a new Template. >=20 > This causes incompatibility with RFC5101 without offering any = advantages. I would keep the mandatory withdrawal for TCP and SCTP. As above, good point... However, this does basically mean we're not = simplifying template management (we still have "reliable" and = "unreliable" template management protocols)... though there may still be = some benefit in simplifying the specification of them. >> 6. Template management actions MUST be sequenced in IPFIX Message = Header Export Time order. >=20 > This is a reasonable clarification. >=20 >> This sixth point is (perhaps poorly) addressed in Section 8.3 of = 5101bis. To clarify: >>=20 >> A. an EP MUST ensure when defining a Template that it exports no = messages containing data sets described by the new Template with export = times _earlier_ than the message containing the template set. >=20 > How can the EP ensure this in case of SCTP with multiple streams? > It is difficult for an application to obtain information from the SCTP = socket when a message has left the interface card. > It's a question of when the exporter can assume that a message is = exported. The EP can ensure this by setting the Export Time in the header; all = sequencing is done via this header (as opposed to actual time the packet = leaves the EP or arrives at the CP). Cheers, Brian From paitken@cisco.com Tue Apr 3 08:03:01 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5DD21F84E2 for ; Tue, 3 Apr 2012 08:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE7l-SV2L1yO for ; Tue, 3 Apr 2012 08:03:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4321F84E1 for ; Tue, 3 Apr 2012 08:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1049; q=dns/txt; s=iport; t=1333465380; x=1334674980; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=tStoktGLb2GJBHZ89in3lxeakwAuFQGEdpzRVU3xLwc=; b=m0URAlRxv2ymxoCmmSb/IZCHorJQtnEAW6sKTOB4iKrorks1IA+2CPBE 1fE0kRFvFyWdLqJNe9LJbScPiRnqykDY4EYp+0pDCGxzCm0oQqcCGC+sC tT7x4A9QqfV0tRjQTZclmrRsWHvsiWTmoxUenwPHpRBFKGIufiRpknn5Q c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0GAJIQe0+Q/khL/2dsb2JhbABCgx60YoEHggkBAQEDARIBHwEFQAEQCyEWDwkDAgECAUUGAQwBBwEBHodiBaAGlyGQZgSVY4VwiFeBaYJo X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="70026683" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 Apr 2012 15:02:59 +0000 Received: from [10.55.91.3] (dhcp-10-55-91-3.cisco.com [10.55.91.3]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q33F2xJT008164; Tue, 3 Apr 2012 15:02:59 GMT Message-ID: <4F7B1124.5060606@cisco.com> Date: Tue, 03 Apr 2012 16:03:00 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: Gerhard Muenz , Brian Trammell References: <4F7A12E1.6080608@net.in.tum.de> In-Reply-To: <4F7A12E1.6080608@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis: CP MUST Close and Simplified Template Management X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:03:01 -0000 Brian, Gerhard, >> 4. Template Withdrawals MAY be sent on UDP. > > Ok. Template Withdrawal does not hurt in case of UDP. UDP doesn't guarantee in-order delivery. Therefore not waiting long enough after sending a TWM before sending a new template definition using the same template ID, could result in the new template definition arriving first, then being withdrawn. ie, "Template N¹, TWM N, Template N²" becomes, "Template N¹, Template N², TWM N". Of course, this can be avoided by checking the header timestamps, and ignoring the TWM if it originated prior to the current template. Brian's reply later in this thread: The EP can ensure this by setting the Export Time in the header; all sequencing is done via this header (as opposed to actual time the packet leaves the EP or arrives at the CP). I wonder how many collectors process data in time order versus order of receipt? Since 5101 has nothing to say on the matter, some interesting interop test cases could be devised around this question. P. From trammell@tik.ee.ethz.ch Tue Apr 3 08:31:38 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F25111E80F4 for ; Tue, 3 Apr 2012 08:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvtau9c2qXBv for ; Tue, 3 Apr 2012 08:31:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A264C11E80F6 for ; Tue, 3 Apr 2012 08:31:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 001EDD9307; Tue, 3 Apr 2012 17:31:36 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sr9usyB2ms5O; Tue, 3 Apr 2012 17:31:36 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B7416D9305; Tue, 3 Apr 2012 17:31:36 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F7B1124.5060606@cisco.com> Date: Tue, 3 Apr 2012 17:31:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4579C9B2-A2F6-4000-B913-7F04CA4FFEFA@tik.ee.ethz.ch> References: <4F7A12E1.6080608@net.in.tum.de> <4F7B1124.5060606@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1257) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis: CP MUST Close and Simplified Template Management X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:31:38 -0000 Hi, Paul, Inline... On Apr 3, 2012, at 5:03 PM, Paul Aitken wrote: > Brian, Gerhard, >=20 >>> 4. Template Withdrawals MAY be sent on UDP. >>=20 >> Ok. Template Withdrawal does not hurt in case of UDP. >=20 > UDP doesn't guarantee in-order delivery. Therefore not waiting long = enough after sending a TWM before sending a new template definition = using the same template ID, could result in the new template definition = arriving first, then being withdrawn. >=20 > ie, "Template N=B9, TWM N, Template N=B2" becomes, "Template N=B9, = Template N=B2, TWM N". >=20 > Of course, this can be avoided by checking the header timestamps, and = ignoring the TWM if it originated prior to the current template. You can also stick them all in the same message, no? > Brian's reply later in this thread: >=20 > The EP can ensure this by setting the Export Time in the header; = all sequencing is done via this header (as opposed to actual time the = packet leaves the EP or arrives at the CP). >=20 >=20 > I wonder how many collectors process data in time order versus order = of receipt? Since 5101 has nothing to say on the matter, some = interesting interop test cases could be devised around this question. I presume most CPs process data in order of receipt, and for the most = part things should run as such. However, if a collector detects that = something is not right (in circumstances in which it can do so, which we = addressed in the hallway once but which are now less clear to me than = they were then) then it can use the export time ordering to try and = recover. (Or it can scream at the admin and have the admin go tweak some timeouts = and/or fetch a bigger pipe. Again, IPFIX over UDP is a game for people = with very-well-provisioned measurement networks and/or a penchant for = gambling.) Cheers, Brian From paitken@cisco.com Tue Apr 3 08:56:10 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2BD11E80FF for ; Tue, 3 Apr 2012 08:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d84irkZ9TkEi for ; Tue, 3 Apr 2012 08:56:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7C86D11E80F5 for ; Tue, 3 Apr 2012 08:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2466; q=dns/txt; s=iport; t=1333468559; x=1334678159; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zoCt7trHBZf2B6fEBp9ApPgn3Z8jhxUIqoBrdcbPWCg=; b=PeDL7cdw0ORaS7jarUh0sAE0NQBf+PnJmcAf6vZt3amqZSheBvR/iTwU LoE/d3oEmEScEhIS36DmqYOexGZQ8o4ogbPC4C/bFkhKmavbmho9GkOKM 2rbGonh/7pjAuoHMTXzvoR0AQzs0EAQ+VchQewJWoLIjz6//d/wJqE5/p 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8HAPYce0+Q/khL/2dsb2JhbABFgxG0cIEHggkBAQEDARIBHwEFQAEFCwshFg8JAwIBAgFFBg0BBwEBHodiBZt3nwCQZgSVY4VwiFeBaYJo X-IronPort-AV: E=Sophos;i="4.75,364,1330905600"; d="scan'208";a="134173962" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2012 15:55:58 +0000 Received: from [10.55.91.3] (dhcp-10-55-91-3.cisco.com [10.55.91.3]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q33FtvTT019420; Tue, 3 Apr 2012 15:55:58 GMT Message-ID: <4F7B1D8F.4080908@cisco.com> Date: Tue, 03 Apr 2012 16:55:59 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: Brian Trammell References: <4F7A12E1.6080608@net.in.tum.de> <4F7B1124.5060606@cisco.com> <4579C9B2-A2F6-4000-B913-7F04CA4FFEFA@tik.ee.ethz.ch> In-Reply-To: <4579C9B2-A2F6-4000-B913-7F04CA4FFEFA@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis: CP MUST Close and Simplified Template Management X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:56:10 -0000 Brian, >>>> 4. Template Withdrawals MAY be sent on UDP. >>> Ok. Template Withdrawal does not hurt in case of UDP. >> UDP doesn't guarantee in-order delivery. Therefore not waiting long enough after sending a TWM before sending a new template definition using the same template ID, could result in the new template definition arriving first, then being withdrawn. >> >> ie, "Template N¹, TWM N, Template N²" becomes, "Template N¹, Template N², TWM N". >> >> Of course, this can be avoided by checking the header timestamps, and ignoring the TWM if it originated prior to the current template. > You can also stick them all in the same message, no? That violates 5101, which specifically excludes TWM over UDP. However, if the restriction is removed, then inter-message timestamps and intra-message order must both be honoured. eg, if your collector sub-divides messages and processes them in multiple threads. >> Brian's reply later in this thread: >> >> The EP can ensure this by setting the Export Time in the header; all sequencing is done via this header (as opposed to actual time the packet leaves the EP or arrives at the CP). >> >> >> I wonder how many collectors process data in time order versus order of receipt? Since 5101 has nothing to say on the matter, some interesting interop test cases could be devised around this question. > I presume most CPs process data in order of receipt, +1 However, they should then reject out-of-order messages according to the header timestamp. - except that this introduces a potential DoS vector, where I can send my ISP a (possibly null) message with a header timestamp of "7th Jan 2106" and block all future messages... - except that collectors should also reject messages which are far in the future (while allowing for collectors in remote timezones and DST changes). > and for the most part things should run as such. However, if a collector detects that something is not right (in circumstances in which it can do so, which we addressed in the hallway once but which are now less clear to me than they were then) +1 P. > then it can use the export time ordering to try and recover. > > (Or it can scream at the admin and have the admin go tweak some timeouts and/or fetch a bigger pipe. Again, IPFIX over UDP is a game for people with very-well-provisioned measurement networks and/or a penchant for gambling.) > > Cheers, > > Brian From trammell@tik.ee.ethz.ch Mon Apr 9 12:07:43 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB6B21F87C6 for ; Mon, 9 Apr 2012 12:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.855 X-Spam-Level: X-Spam-Status: No, score=-3.855 tagged_above=-999 required=5 tests=[AWL=-1.970, BAYES_40=-0.185, MANGLED_SEX=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLtXZPiGw+vB for ; Mon, 9 Apr 2012 12:07:42 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6919921F8782 for ; Mon, 9 Apr 2012 12:07:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0A980D9307 for ; Mon, 9 Apr 2012 21:07:41 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fqdKjzgQp0BQ for ; Mon, 9 Apr 2012 21:07:40 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AE1E6D9300 for ; Mon, 9 Apr 2012 21:07:40 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Apr 2012 21:07:39 +0200 Message-Id: To: IETF IPFIX Working Group Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [IPFIX] draft-johnson-ipfix-mib-variable-export and template extension X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:07:44 -0000 Greetings, all, I've had a look at draft-johnson-ipfix-mib-variable-export, and as I = noted at the meeting in Paris, have a concern about the mechanism = presented in section 5.3.x for adding extended field specifiers to = IPFIX. I'd like to suggest a generalization of this approach. Supporting the description of fields in an IPFIX Record as MIB Objects = is a special case of extending the Information Element space in general. = I see two other _particular_ applications for this: the ability to flag = or index IEs within a template (to note reverse counters, indexes, = pre/post or other packet handling notation, and so on), and the ability = to add type restrictions to Structured Data containers (in order to = maintain template-level type information for templates containing = structured data). However, completely defining these mechanisms is clearly out of scope = for the mibvar draft (and would delay it unnecessarily), so I'd like to = tweak the mechanism presented there such that it could be extended in = the future. The basic mechanism I'm proposing is: 1. the creation of an general Extended Template Set (Set ID 4) and an = Extended Options Template Set (Set ID 5). 2. Extended Template Sets contain Templates with a Template Record = Header identical to those in Template Sets (Set ID 2); Extended Options = Template Sets contain Templates with a Template Record Header identical = to those in Options Template Sets (Set ID 3). 3. Both contain Extended Field Specifiers, which for IANA Information = Elements appear as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Information Element ident. | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| IE Ext. ID | IE Ext. Len. | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Extension Content (defined by ID/Length) | ... ... ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 and for enterprise-specific Information Elements appear as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Information Element ident. | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| IE Ext. ID | IE Ext. Len. | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Extension Content (defined by ID/Length) | ... ... ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The two-byte field after the Field Length or the Enterprise Number is an = extension specifier: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M| IE Ext. ID | IE Ext. Len. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ ^ | | Extension length (2-255 bytes, including = specifier) | Extension type (as per new Template Extension Registry, see = below) More Bit (1 =3D more extensions after this; 0 =3D this is the last = extension) 4. The creation of a Template Extension Registry, to be managed by IANA = and modified by Standards Action, initially having the following two = entries: IE Extension ID 0 =3D Null Extension: allows the specification of a = standard IPFIX Information Element not having any extension information = within an Extended Template Record. Null Extensions MAY have any length = (greater than the minimum 2). Their content SHOULD be zero and MUST be = ignored by the CP. This allows the maintenance of 32-bit alignment = within templates if desired by the EP; a non-extended IE could then look = either like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Information Element ident. | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ext ID =3D 0 | ext len =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Information Element ident. | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| ext ID =3D 0 | ext len =3D 4 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IE Extension ID 1 =3D MIB Variable Extension: allows the specification = of an Information Element as a MIB Object, as follows. The Information = Element Identifier is in this case _ignored_, but SHOULD be the MIB OID = IE. An EP MUST NOT export a Template with a MIB OID IE field without a = MIB Variable Extension attached. 5. The definition of the MIB Variable Extension format, which as far as = I am concerned remains an open question. It's pretty clear that for = non-indexed MIB objects it looks very much like just sticking the = content in section 5.3.2 into the extension content: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| MIB OID IE | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 1 (mibvar) | IE Ext. Len. | Index Count 0 | MIB OID Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIB Object Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'm not sure if I like the indexing mechanism specified in sections = 5.3.3 through 5.3.5 yet (I'm not an SNMP guy), so I might suggest = something. The question I _think_ I have an answer for but am not = convinced of: is there _ever_ a case where a MIB Object element will be = indexed by something _NOT_ in the enclosing template? If not, why not = just have a list of template field indices as MIB object indices? seems = like it would take a lot less effort at both the EP and the CP, and = would lead to a lot less possibility of exporting a bad extension. i.e.: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| MIB OID IE | Field Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| 1 (mibvar) | IE Ext. Len. | Index Count 2 | MIB OID Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MIB Object Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | field spec pos of 1st index | field spec pos of 2nd index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thoughts? Best regards, Brian From bclaise@cisco.com Tue Apr 10 04:07:57 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8CC21F872F for ; Tue, 10 Apr 2012 04:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DdAUpTmnvkw for ; Tue, 10 Apr 2012 04:07:56 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 34B9421F8721 for ; Tue, 10 Apr 2012 04:07:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3AB7q4E025061; Tue, 10 Apr 2012 13:07:52 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3AB7pmA021070; Tue, 10 Apr 2012 13:07:52 +0200 (CEST) Message-ID: <4F841487.8090604@cisco.com> Date: Tue, 10 Apr 2012 13:07:51 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------080108090002050701050704" Cc: Al Morton , Ron Bonica Subject: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:07:57 -0000 This is a multi-part message in MIME format. --------------080108090002050701050704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft defines two new terms: Active Timeout and Inactive Timeout. I was thinking: surely, we have defined those terms already in some IPFIX RFCs. Actually, I was unable to find any references.... Have I overlooked something? The only pointers I could find are in RFC5102 5.11.1. flowActiveTimeout Description: The number of seconds after which an active Flow is timed out anyway, even if there is still a continuous flow of packets. Abstract Data Type: unsigned16 ElementId: 36 Status: current Units: seconds 5.11.2. flowIdleTimeout Description: A Flow is considered to be timed out if no packets belonging to the Flow have been observed for the number of seconds specified by this field. Abstract Data Type: unsigned16 ElementId: 37 Status: current Units: seconds 5.11.3. flowEndReason Description: The reason for Flow termination. The range of values includes the following: 0x01: idle timeout The Flow was terminated because it was considered to be idle. 0x02: active timeout The Flow was terminated for reporting purposes while it was still active, for example, after the maximum lifetime of unreported Flows was reached. ... Here is one issue. Some documents refer to inactive timeout RFC5472, ipfixMeteringProcessCacheInactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03 inactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 While some others refer to idle timeout RFC 5102, draft-ietf-bmwg-ipflow-meth-09 Any proposal to fix this problem? Regards, Benoit (OPS A.D.) --------------080108090002050701050704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft defines two new terms: Active Timeout and Inactive Timeout.
I was thinking: surely, we have defined those terms already in some IPFIX RFCs.
Actually, I was unable to find any references.... Have I overlooked something?

The only pointers I could find are in RFC5102

5.11.1.  flowActiveTimeout

   Description:
      The number of seconds after which an active Flow is timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned16
   ElementId: 36
   Status: current
   Units: seconds

5.11.2.  flowIdleTimeout


   Description:
      A Flow is considered to be timed out if no packets belonging to
      the Flow have been observed for the number of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.11.3.  flowEndReason
Description:
      The reason for Flow termination.  The range of values includes the
      following:

      0x01: idle timeout
            The Flow was terminated because it was considered to be
            idle.

      0x02: active timeout
            The Flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported Flows was reached.

      ...
Here is one issue.
Some documents refer to inactive timeout
    RFC5472,
    ipfixMeteringProcessCacheInactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03
    inactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10
While some others refer to idle timeout
    RFC 5102,
    draft-ietf-bmwg-ipflow-meth-09

Any proposal to fix this problem?

Regards, Benoit (OPS A.D.)

--------------080108090002050701050704-- From janovak@cisco.com Tue Apr 10 04:17:49 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0621F85F6 for ; Tue, 10 Apr 2012 04:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHW0jcVduDBe for ; Tue, 10 Apr 2012 04:17:49 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id BC1A921F85F2 for ; Tue, 10 Apr 2012 04:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=janovak@cisco.com; l=2690; q=dns/txt; s=iport; t=1334056668; x=1335266268; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jKtWqVQxA/FhjesZr7qixhUdkioC0mxIjs6oJBdEyH4=; b=RJkiPp3znRoSkv8bt0WEhaGj/nGYu8EaS0zfqFCoQOP9Ws+4eLxedtvp Av1mA4fVepl8VK3PPUQzwcpj0McOZ5MxOLlfpKWJ/UsUiFSgz9nxmSu5Z UqeZm7OdL0k4Eirxb7hTGtCp92NKXOIO330yKZJTm7TkQQSvow55mPEe8 4=; X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="70466540" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 10 Apr 2012 11:17:47 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3ABHlxE030492; Tue, 10 Apr 2012 11:17:47 GMT Received: from xmb-ams-212.cisco.com ([144.254.75.23]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 13:17:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Apr 2012 13:17:45 +0200 Message-ID: In-Reply-To: <4F841487.8090604@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) Thread-Index: Ac0XCi4AJ/m2p5GYTh+nYoKKfQEYjQAAOt3A References: <4F841487.8090604@cisco.com> From: "Jan Novak (janovak)" To: "Benoit Claise (bclaise)" , X-OriginalArrivalTime: 10 Apr 2012 11:17:47.0894 (UTC) FILETIME=[8F3EA960:01CD170B] Cc: Ron Bonica , Al Morton Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:17:49 -0000 Hi, I have checked the IPFIX documents at the time and couldn't find any definitions while there was a need for them for the BMWG document - so that's why it is there. The definitions are quite cumbersome to develop (as you as well might remember :-)) and still are to some extent controversial (or every reviewer so far picked at them). Jan The climate of Edinburgh is such that the weak succumb young ....=20 and the strong envy them. Dr. Johnson From: Benoit Claise (bclaise)=20 Sent: 10 April 2012 12:08 To: ipfix@ietf.org Cc: Jan Novak (janovak); Ron Bonica; Al Morton Subject: No active/inactive timeout definitions in any IPFIX RFCs? Idle = versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 = review) Dear all, Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft = defines two new terms: Active Timeout and Inactive Timeout. I was thinking: surely, we have defined those terms already in some = IPFIX RFCs. Actually, I was unable to find any references.... Have I overlooked = something? The only pointers I could find are in RFC5102 5.11.1. flowActiveTimeout Description: The number of seconds after which an active Flow is timed out anyway, even if there is still a continuous flow of packets. Abstract Data Type: unsigned16 ElementId: 36 Status: current Units: seconds 5.11.2. flowIdleTimeout Description: A Flow is considered to be timed out if no packets belonging to the Flow have been observed for the number of seconds specified by this field. Abstract Data Type: unsigned16 ElementId: 37 Status: current Units: seconds 5.11.3. flowEndReason Description: The reason for Flow termination. The range of values includes the following: 0x01: idle timeout The Flow was terminated because it was considered to be idle. 0x02: active timeout The Flow was terminated for reporting purposes while it was still active, for example, after the maximum lifetime of unreported Flows was reached. ... Here is one issue. Some documents refer to inactive timeout =A0=A0=A0 RFC5472,=20 =A0=A0=A0 ipfixMeteringProcessCacheInactiveTimeout in = http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03 =A0=A0=A0 inactiveTimeout in = http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 While some others refer to idle timeout =A0=A0=A0 RFC 5102,=20 =A0=A0=A0 draft-ietf-bmwg-ipflow-meth-09 Any proposal to fix this problem? Regards, Benoit (OPS A.D.) From trammell@tik.ee.ethz.ch Tue Apr 10 04:19:42 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947A421F8601 for ; Tue, 10 Apr 2012 04:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8MeyKUtTC97 for ; Tue, 10 Apr 2012 04:19:42 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A623221F85F6 for ; Tue, 10 Apr 2012 04:19:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 547C4D9308; Tue, 10 Apr 2012 13:19:40 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7Kh+AOf0e2fI; Tue, 10 Apr 2012 13:19:40 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id F02F5D9300; Tue, 10 Apr 2012 13:19:39 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F841487.8090604@cisco.com> Date: Tue, 10 Apr 2012 13:19:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F841487.8090604@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1257) Cc: Ron Bonica , Al Morton , "ipfix@ietf.org" Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 11:19:42 -0000 Hi, Benoit, all, Active and idle timeout are essentially Metering Process = implementation-specific parameters. I suspect most MPs dealing with = flows will have _something_ that looks like an active timeout, and = something that looks like an idle or inactive timeout, regardless of = what they call them. Exactly how active and idle timeouts are = implemented, and the effect they have on the duration and export order = of exported flows, probably isn't a protocol matter. So I'm not sure how = specifically defined they need to be. "Active" seems to be "active" everywhere. The choice of picking idle or = inactive would seem then to be arbitrary. Given that 5102 predates all = other (directly-IPFIX-related) references, and there's an IE in the IANA = registry called flowIdleTimeout, I'd tend to go with "idle" for this = one. As to _where_ and _how_ to define these, I don't know, and as little as = possible. Cheers, Brian On Apr 10, 2012, at 1:07 PM, Benoit Claise wrote: > Dear all, >=20 > Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft = defines two new terms: Active Timeout and Inactive Timeout. > I was thinking: surely, we have defined those terms already in some = IPFIX RFCs. > Actually, I was unable to find any references.... Have I overlooked = something? >=20 > The only pointers I could find are in RFC5102 >=20 > 5.11.1. flowActiveTimeout >=20 >=20 > Description: > The number of seconds after which an active Flow is timed out > anyway, even if there is still a continuous flow of packets. > Abstract Data Type: unsigned16 > ElementId: 36 > Status: current > Units: seconds >=20 >=20 > 5.11.2. flowIdleTimeout >=20 >=20 >=20 > Description: > A Flow is considered to be timed out if no packets belonging to > the Flow have been observed for the number of seconds specified = by > this field. > Abstract Data Type: unsigned16 > ElementId: 37 > Status: current > Units: seconds >=20 >=20 > 5.11.3. flowEndReason >=20 > Description: > The reason for Flow termination. The range of values includes = the > following: >=20 > 0x01: idle timeout > The Flow was terminated because it was considered to be > idle. >=20 > 0x02: active timeout > The Flow was terminated for reporting purposes while it = was > still active, for example, after the maximum lifetime of > unreported Flows was reached. >=20 > ... >=20 >=20 >=20 >=20 >=20 > Here is one issue. > Some documents refer to inactive timeout > RFC5472,=20 > ipfixMeteringProcessCacheInactiveTimeout in = http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03 > inactiveTimeout in = http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 > While some others refer to idle timeout > RFC 5102,=20 > draft-ietf-bmwg-ipflow-meth-09 >=20 > Any proposal to fix this problem? >=20 > Regards, Benoit (OPS A.D.) >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Tue Apr 10 09:34:23 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75EE921F8572 for ; Tue, 10 Apr 2012 09:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ftloq9qVISSp for ; Tue, 10 Apr 2012 09:34:22 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4E44A21F856F for ; Tue, 10 Apr 2012 09:34:22 -0700 (PDT) Received: from [192.168.2.26] (g231051210.adsl.alicedsl.de [92.231.51.210]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 7781A201ED24; Tue, 10 Apr 2012 18:34:19 +0200 (CEST) Message-ID: <4F846107.7040907@net.in.tum.de> Date: Tue, 10 Apr 2012 18:34:15 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Benoit Claise References: <4F841487.8090604@cisco.com> In-Reply-To: <4F841487.8090604@cisco.com> Content-Type: multipart/alternative; boundary="------------050707080602030509020903" Cc: Ron Bonica , Al Morton , "ipfix@ietf.org" Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:34:23 -0000 This is a multi-part message in MIME format. --------------050707080602030509020903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Benoit, The parameter was always called inactive timeout in IPFIX MIB. ipfix-config changed from idleTimeout to inactiveTimeout in draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB. We could change the name in the MIB and in ipfix-config if consistency is important. Gerhard On 10.04.2012 13:07, Benoit Claise wrote: > Dear all, > > Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft > defines two new terms: Active Timeout and Inactive Timeout. > I was thinking: surely, we have defined those terms already in some > IPFIX RFCs. > Actually, I was unable to find any references.... Have I overlooked > something? > > The only pointers I could find are in RFC5102 > > > 5.11.1. flowActiveTimeout > > > Description: > The number of seconds after which an active Flow is timed out > anyway, even if there is still a continuous flow of packets. > Abstract Data Type: unsigned16 > ElementId: 36 > Status: current > Units: seconds > > > 5.11.2. flowIdleTimeout > > > > Description: > A Flow is considered to be timed out if no packets belonging to > the Flow have been observed for the number of seconds specified by > this field. > Abstract Data Type: unsigned16 > ElementId: 37 > Status: current > Units: seconds > > > 5.11.3. flowEndReason > > Description: > The reason for Flow termination. The range of values includes the > following: > > 0x01: idle timeout > The Flow was terminated because it was considered to be > idle. > > 0x02: active timeout > The Flow was terminated for reporting purposes while it was > still active, for example, after the maximum lifetime of > unreported Flows was reached. > > ... > > Here is one issue. > Some documents refer to inactive timeout > RFC5472, > ipfixMeteringProcessCacheInactiveTimeout in > http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03 > inactiveTimeout in > http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 > While some others refer to idle timeout > RFC 5102, > draft-ietf-bmwg-ipflow-meth-09 > > Any proposal to fix this problem? > > Regards, Benoit (OPS A.D.) > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------050707080602030509020903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Benoit,

The parameter was always called inactive timeout in IPFIX MIB. ipfix-config changed from idleTimeout to inactiveTimeout in draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB.

We could change the name in the MIB and in ipfix-config if consistency is important.

Gerhard


On 10.04.2012 13:07, Benoit Claise wrote:
Dear all,

Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft defines two new terms: Active Timeout and Inactive Timeout.
I was thinking: surely, we have defined those terms already in some IPFIX RFCs.
Actually, I was unable to find any references.... Have I overlooked something?

The only pointers I could find are in RFC5102

5.11.1.  flowActiveTimeout

   Description:
      The number of seconds after which an active Flow is timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned16
   ElementId: 36
   Status: current
   Units: seconds

5.11.2.  flowIdleTimeout


   Description:
      A Flow is considered to be timed out if no packets belonging to
      the Flow have been observed for the number of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.11.3.  flowEndReason
Description:
      The reason for Flow termination.  The range of values includes the
      following:

      0x01: idle timeout
            The Flow was terminated because it was considered to be
            idle.

      0x02: active timeout
            The Flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported Flows was reached.

      ...
Here is one issue.
Some documents refer to inactive timeout
    RFC5472,
    ipfixMeteringProcessCacheInactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03
    inactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10
While some others refer to idle timeout
    RFC 5102,
    draft-ietf-bmwg-ipflow-meth-09

Any proposal to fix this problem?

Regards, Benoit (OPS A.D.)



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
--------------050707080602030509020903-- From andrewf@plixer.com Tue Apr 10 13:12:36 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F59621F8516 for ; Tue, 10 Apr 2012 13:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1mbaefZcS9s for ; Tue, 10 Apr 2012 13:12:35 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 913F321F8501 for ; Tue, 10 Apr 2012 13:12:33 -0700 (PDT) Received: from [10.100.1.132] ([66.186.184.193]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 16:12:32 -0400 Message-ID: <4F849430.7020306@plixer.com> Date: Tue, 10 Apr 2012 16:12:32 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120404 Thunderbird/14.0a1 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------080601020501080606060405" X-OriginalArrivalTime: 10 Apr 2012 20:12:32.0637 (UTC) FILETIME=[433DEAD0:01CD1756] Subject: [IPFIX] RFC 5101bis X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:12:36 -0000 This is a multi-part message in MIME format. --------------080601020501080606060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I noticed today that section 6.2 is named "Reduced Size Encoding of Integer and Float Types", but then in the first sentence also lists "string" and "octetArray" types. "Information Elements containing integer, string, float, and octetArray types in the information model MAY be encoded using fewer octets than those implied by their type in the information model" I'm not sure how a type of string or octetArray implies a length. It seems that the section should be renamed to be more generic (remove "Integer and Float Types") In which case I assume rather than a size "implied by their type" the first paragraph should read something like. "Information Elements containing integer, string, float, and octetArray types in the information model MAY be encoded using fewer octets than the specified maximum encoding size" Or is reduced encoding intended only for integer types? -Andrew --------------080601020501080606060405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I noticed today that section 6.2 is named "Reduced Size Encoding of Integer and Float Types", but then in the first sentence  also lists "string" and "octetArray" types.

"Information Elements containing integer, string, float, and
   octetArray types in the information model MAY be encoded using fewer
   octets than those implied by their type in the information model"

I'm not sure how a type of string or octetArray implies a length.

It seems that the section should be renamed to be more generic (remove "Integer and Float Types")

In which case I assume rather than a size "implied by their type" the first paragraph should read something like.

"Information Elements containing integer, string, float, and
   octetArray types in the information model MAY be encoded using fewer
   octets than the specified maximum encoding size"

Or is reduced encoding intended only for integer types?

-Andrew
--------------080601020501080606060405-- From prvs=0447e42482=simon.leinen@switch.ch Tue Apr 10 13:42:06 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4933E21F8599 for ; Tue, 10 Apr 2012 13:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg4z2VOuVw7O for ; Tue, 10 Apr 2012 13:42:05 -0700 (PDT) Received: from bernina.switch.ch (bernina.switch.ch [IPv6:2001:620:0:14::22]) by ietfa.amsl.com (Postfix) with ESMTP id B2ACF21F8598 for ; Tue, 10 Apr 2012 13:42:05 -0700 (PDT) Received: from macsl.switch.ch ([2001:620:0:4:226:8ff:fe05:cfee]) by bernina.switch.ch with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SHht3-0002IO-Ud; Tue, 10 Apr 2012 22:42:02 +0200 From: Simon Leinen To: Brian Trammell In-Reply-To: (Brian Trammell's message of "Tue, 10 Apr 2012 13:19:38 +0200") References: <4F841487.8090604@cisco.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (darwin) 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` Date: Tue, 10 Apr 2012 22:42:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: Ron Bonica , Al Morton , "ipfix@ietf.org" Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:42:06 -0000 Brian Trammell writes: > Active and idle timeout are essentially Metering Process > implementation-specific parameters. I suspect most MPs dealing with > flows will have _something_ that looks like an active timeout, and > something that looks like an idle or inactive timeout, regardless of > what they call them. Yes, probably, but some Metering Process implementations have more involved heuristics than these two timeouts. For example, the ones we use have something called "fast aging", where flows that have accumulated less than (or equal, depending on the hardware version :-) a configurable threshold of packets can be timed out more aggressively, i.e. after a shorter idle period than the default (which is used for longer flows). This is a popular platform with an installed base worth multiple 10s of billions of dollars. I don't claim that they are all exporting flows. This feature is quite useful for us, because we have many very short flows in our network, such as those from DNS and NTP "conversations", we collect flows without sampling, and the routers have fixed-size hardware flow tables. Fast aging allows us to get rid of the tinyflows quickly. > Exactly how active and idle timeouts are implemented, and the effect > they have on the duration and export order of exported flows, probably > isn't a protocol matter. So I'm not sure how specifically defined they > need to be. I agree. Implementors of Metering Processes should be allowed to differentiate themselves using more effective heuristics. It is problematic when we start to encode assumptions about these heuristics in standards. If we assume that there's just an active timeout and an idle (or inactive, I don't care) timeout, then we already cannot capture (Netflow) implementations that are quite widely used. -- Simon. From andrewf@plixer.com Tue Apr 10 14:06:19 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B18111E8149 for ; Tue, 10 Apr 2012 14:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6xbpwICnxsL for ; Tue, 10 Apr 2012 14:06:18 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 9A59D11E814B for ; Tue, 10 Apr 2012 14:06:18 -0700 (PDT) Received: from [10.100.1.132] ([66.186.184.193]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 17:06:16 -0400 Message-ID: <4F84A0C8.80802@plixer.com> Date: Tue, 10 Apr 2012 17:06:16 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120404 Thunderbird/14.0a1 MIME-Version: 1.0 To: ipfix@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2012 21:06:16.0856 (UTC) FILETIME=[C506B180:01CD175D] Subject: Re: [IPFIX] draft-claise-export-application-info-in-ipfix-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:06:19 -0000 On 03/28/2012 06:48 AM, Chris Inacio wrote: > http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-05 > > ClassEngineID + SelectorID - shouldn't this be 32-bits and possible to be shortened using reduced size encoding? I'm not sure there is any advantage to saying you won't know until you see the Engine ID; and seriously, from an implementation point of view; building the decoder, I'm not going to care while parsing the information. I will only care when doing the human display level - when I have to do the lookups. For the protocol, (on the wire,) I prefer a 32-bit field. Hi Chris, I don't see how it can be just 32-bits since according to section 4.2 classificationEngineId=12(PANA-L2) + selectorId = 6 bytes. I'm also not sure I agree on using reduced size encoding. If NetFlow v9 is being exported and you are trying to minimize your encoding size you don't have much choice. The problem I have with the reduced size encoding described for legacy protocols is that an applicationId that should be common to anyone implementing this draft (1..1 for example) can actually be encoded encoded 5 different ways. Gross. I'd prefer to burn some extra bytes for v9 rather than try and deal with the normalizing different encodings, but I think that genie is already out of the bottle. I definitely wouldn't want to see that continue in IPFIX since we have a perfectly nice variable length octetArray. With a variable length octetArray at least equivalent applicationIds can be matched without having to decompose them. -Andrew From pashley@au1.ibm.com Tue Apr 10 17:08:05 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9087D11E80F8 for ; Tue, 10 Apr 2012 17:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-36GsxE9q2O for ; Tue, 10 Apr 2012 17:08:04 -0700 (PDT) Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5A61511E8081 for ; Tue, 10 Apr 2012 17:08:02 -0700 (PDT) Received: from /spool/local by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 11 Apr 2012 00:57:22 +1000 Received: from d23relay05.au.ibm.com (202.81.31.247) by e23smtp09.au.ibm.com (202.81.31.206) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 11 Apr 2012 00:57:21 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q3B01MsL3620940 for ; Wed, 11 Apr 2012 10:01:22 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q3B07nal030793 for ; Wed, 11 Apr 2012 10:07:49 +1000 Received: from d23ml004.au.ibm.com (d23ml004.au.ibm.com [9.190.250.23]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q3B07ncQ030789 for ; Wed, 11 Apr 2012 10:07:49 +1000 Auto-Submitted: auto-generated From: Paul Ashley To: ipfix@ietf.org Message-ID: Date: Wed, 11 Apr 2012 10:12:02 +1000 X-MIMETrack: Serialize by Router on d23ml004/23/M/IBM(Release 8.5.2FP1HF437 | June 7, 2011) at 11/04/2012 10:12:03 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII x-cbid: 12041014-3568-0000-0000-00000183D69A Subject: [IPFIX] AUTO: Paul Ashley is out of the office (returning 16/04/2012) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 00:08:05 -0000 I am out of the office until 16/04/2012. I am out of the office. I will have no access to my email. For ISS client issues, please email Andrew Sallaway (andrewms@au1.ibm.com) For ISS product development issues, please email John Court (johnwcrt@au1.ibm.com). For urgent issues, please send me a text message to 0421 611 853. Note: This is an automated response to your message "IPFIX Digest, Vol 64, Issue 3" sent on 11/4/2012 5:00:08. This is the only notification you will receive while this person is away. From trammell@tik.ee.ethz.ch Wed Apr 11 08:24:32 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA1C21F84EF for ; Wed, 11 Apr 2012 08:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQIcFPqJknrc for ; Wed, 11 Apr 2012 08:24:26 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD3E21F84D8 for ; Wed, 11 Apr 2012 08:24:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 25EFED9312; Wed, 11 Apr 2012 17:24:23 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CT5lcBmhaa2Z; Wed, 11 Apr 2012 17:24:22 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D9A49D930B; Wed, 11 Apr 2012 17:24:22 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F849430.7020306@plixer.com> Date: Wed, 11 Apr 2012 17:24:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A58FD92-2432-4E6E-9726-29D55C60C229@tik.ee.ethz.ch> References: <4F849430.7020306@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1257) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:24:32 -0000 Hi, Andrew, Good points... On Apr 10, 2012, at 10:12 PM, Andrew Feren wrote: > I noticed today that section 6.2 is named "Reduced Size Encoding of = Integer and Float Types", but then in the first sentence also lists = "string" and "octetArray" types. >=20 > "Information Elements containing integer, string, float, and > octetArray types in the information model MAY be encoded using = fewer > octets than those implied by their type in the information model" >=20 > I'm not sure how a type of string or octetArray implies a length. This is a terminology question, I think; strings and octetArrays can be = any length, so it's not really "reduced length encoding". > It seems that the section should be renamed to be more generic (remove = "Integer and Float Types")=20 Agreed. > In which case I assume rather than a size "implied by their type" the = first paragraph should read something like. >=20 > "Information Elements containing integer, string, float, and > octetArray types in the information model MAY be encoded using = fewer > octets than the specified maximum encoding size" This would be one good way to handle it. > Or is reduced encoding intended only for integer types? The fact that an Information Element inherently has a type which = inherently has a length (except for strings and octetArrays), which may = be different than the length for the IE specifier in a given template = record (subject to certain restrictions: you can have a 3-byte = unsigned64 but not a 3-byte float64, for instance) means no; however, = there is a question as to what of this is reduced-length encoding and = what is just "using templates". Cheers, Brian= From trammell@tik.ee.ethz.ch Wed Apr 11 08:25:39 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EF821F8565 for ; Wed, 11 Apr 2012 08:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OstheMjg8ocV for ; Wed, 11 Apr 2012 08:25:38 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 69C6021F84D8 for ; Wed, 11 Apr 2012 08:25:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C50D2D9314; Wed, 11 Apr 2012 17:25:31 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7SLpBxbKwD8p; Wed, 11 Apr 2012 17:25:31 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 878DDD930B; Wed, 11 Apr 2012 17:25:31 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Wed, 11 Apr 2012 17:25:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F841487.8090604@cisco.com> To: Simon Leinen X-Mailer: Apple Mail (2.1257) Cc: Ron Bonica , Al Morton , "ipfix@ietf.org" Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:25:39 -0000 Hi, Simon, all, Agreed. The question of what should the protocol assume about the capabilities = of _all_ Metering Processes attached to compliant Exporting Processes = is, I think, separate from what we want to be able to represent using = the protocol. We already have the idle and active timeout IEs, which can = at least be used by fast aging implementations to report an _incomplete_ = picture of their configuration. (Indeed, a fast aging implementation = _could_ export a per-flow flowEndReason "idle" and flowIdleTimeout "4 = sec" to report which flows were fast aged if it wanted to. Each flow = could even have its own active and idle timeouts. But the efficiency of = this approach is questionable.) The question of what we want to be able to report about _specific_ = metering processes is an interesting one which we have left to metering = process vendors, to date. We actually had a side discussion on this a = while ago, I think in Maastricht: knowing specific information about the = metering and exporting processes and their configuration helps in = interpreting the data they produce. Each exporter would have an exporter = profile, which could be sent inline with options, and kept with the data = at the collector side. As to how to actually do this, you'd have to get very specific about the = capabilities and configurations represented. However, an exercise using = something like the configuration data model as a basis, and allowing for = vendor-specific extensions, might be worth the effort. Cheers, Brian On Apr 10, 2012, at 10:42 PM, Simon Leinen wrote: > Brian Trammell writes: >> Active and idle timeout are essentially Metering Process >> implementation-specific parameters. I suspect most MPs dealing with >> flows will have _something_ that looks like an active timeout, and >> something that looks like an idle or inactive timeout, regardless of >> what they call them. >=20 > Yes, probably, but some Metering Process implementations have more > involved heuristics than these two timeouts. >=20 > For example, the ones we use have something called "fast aging", where > flows that have accumulated less than (or equal, depending on the > hardware version :-) a configurable threshold of packets can be timed > out more aggressively, i.e. after a shorter idle period than the = default > (which is used for longer flows). >=20 > This is a popular platform with an installed base worth multiple 10s = of > billions of dollars. I don't claim that they are all exporting flows. >=20 > This feature is quite useful for us, because we have many very short > flows in our network, such as those from DNS and NTP "conversations", > we collect flows without sampling, and the routers have fixed-size > hardware flow tables. Fast aging allows us to get rid of the = tinyflows > quickly. >=20 >> Exactly how active and idle timeouts are implemented, and the effect >> they have on the duration and export order of exported flows, = probably >> isn't a protocol matter. So I'm not sure how specifically defined = they >> need to be. >=20 > I agree. Implementors of Metering Processes should be allowed to > differentiate themselves using more effective heuristics. >=20 > It is problematic when we start to encode assumptions about these > heuristics in standards. If we assume that there's just an active > timeout and an idle (or inactive, I don't care) timeout, then we = already > cannot capture (Netflow) implementations that are quite widely used. > --=20 > Simon. From andrewf@plixer.com Wed Apr 11 08:30:54 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83F11E8099 for ; Wed, 11 Apr 2012 08:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MrkbVBIsdah for ; Wed, 11 Apr 2012 08:30:52 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 71B7611E8088 for ; Wed, 11 Apr 2012 08:30:52 -0700 (PDT) Received: from [10.100.1.132] ([66.186.184.193]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Apr 2012 11:30:51 -0400 Message-ID: <4F85A3AB.9050409@plixer.com> Date: Wed, 11 Apr 2012 11:30:51 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120404 Thunderbird/14.0a1 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------070603060706030506090203" X-OriginalArrivalTime: 11 Apr 2012 15:30:51.0558 (UTC) FILETIME=[13D3AC60:01CD17F8] Subject: [IPFIX] draft-claise-export-application-info-in-ipfix-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:30:54 -0000 This is a multi-part message in MIME format. --------------070603060706030506090203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit First a few editorial notes. Page 6 [top paragraph] "available at [CISCO], only the layer 7 ones cannot compiled" should be "available at [CISCO], only the layer 7 ones cannot be compiled " Page 12 "protocol encoding may encoded with 3 bytes. In such a case, " should be "protocol encoding may be encoded with 3 bytes. In such a case," Page 27 section 6.6 the reporting application wants to determine whether or the default HTTP port 80 or 8080 was used, it must export the destination port (destinationTransportPort at [IANA-IPFIX]) in the corresponding IPFIX record. should be something like the reporting application wants to determine whether or not the default HTTP port 80 or 8080 was used, the destination port (destinationTransportPort at [IANA-IPFIX]) must also be exported in the corresponding IPFIX record. Now a few other notes. Maybe it is just me, but on page 8 I have no idea what is meant by The Selector ID term is in sync with the selectorId Information Element, specified in the PSAMP Protocol [RFC5476]. 7.1.8. p2pTechnology 7.1.9. tunnelTechnology 7.1.10. encryptedTechnology specify y, 2, n, 2, u, and 0 in addition to the "yes", "no", and "unassigned" values found at http://www.iana.org/assignments/ipfix/ipfix.xml Are all of these valid values? If yes should the IANA entries be updated? -Andrew --------------070603060706030506090203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit First a few editorial notes.

Page 6 [top paragraph]

"available at [CISCO], only the layer 7 ones cannot compiled"
should be
"available at [CISCO], only the layer 7 ones cannot be compiled "

Page 12
"protocol encoding may encoded with 3 bytes. In such a case, "
should be
"protocol encoding may be encoded with 3 bytes. In such a case,"

Page 27 section 6.6

        the reporting application wants to determine whether or the
        default HTTP port 80 or 8080 was used, it must export the
        destination port (destinationTransportPort at [IANA-IPFIX])
        in the corresponding IPFIX record. 

should be something like

        the reporting application wants to determine whether or not the
        default HTTP port 80 or 8080 was used, the
        destination port (destinationTransportPort at [IANA-IPFIX])
        must also be exported in the corresponding IPFIX record. 


Now a few other notes.

Maybe it is just me, but on page 8 I have no idea what is meant by

        The Selector ID term is in sync with the selectorId
        Information Element, specified in the PSAMP Protocol
        [RFC5476]. 


     7.1.8. p2pTechnology
     7.1.9. tunnelTechnology
     7.1.10. encryptedTechnology

specify y, 2, n, 2, u, and 0 in addition to the "yes", "no", and "unassigned" values found at http://www.iana.org/assignments/ipfix/ipfix.xml

Are all of these valid values?  If yes should the IANA entries be updated?

-Andrew
--------------070603060706030506090203-- From paitken@cisco.com Wed Apr 11 09:50:23 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313DD11E80BB for ; Wed, 11 Apr 2012 09:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMw8hnLdTwf5 for ; Wed, 11 Apr 2012 09:50:22 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 127CD11E80B2 for ; Wed, 11 Apr 2012 09:50:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=458; q=dns/txt; s=iport; t=1334163022; x=1335372622; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=N+efKzCSE6bQ6QgB02pgCNvKg0HHz1zSmKmw7H+j1Ok=; b=dfgwdii8V1jlgabnnrR8d1+VunWokNF0b9swXFNg8NMIvFdL3EL7Wjif VugIntlRh5yP1f5efIJ6k626HYAskGXd9uy/Pb28bls/VCsBjRZJrpR9u lbYi55pUTaQYDuEbkUqLtyFysN+M/VdYJfKU9+Rpk9g0JaYRzqIfcjsxI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGAEW1hU+Q/khL/2dsb2JhbABEgxy2MoEHggkBAQEDARIBJUABBQsLIRYPCQMCAQIBRQYNAQcBAR6HZwWbC6AokUYElWyFcohbgWmCaA X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="scan'208";a="70605191" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 11 Apr 2012 16:50:21 +0000 Received: from [10.55.88.31] (dhcp-10-55-88-31.cisco.com [10.55.88.31]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3BGoKRI001929; Wed, 11 Apr 2012 16:50:20 GMT Message-ID: <4F85B64D.9030900@cisco.com> Date: Wed, 11 Apr 2012 17:50:21 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Brian Trammell References: <4F849430.7020306@plixer.com> <7A58FD92-2432-4E6E-9726-29D55C60C229@tik.ee.ethz.ch> In-Reply-To: <7A58FD92-2432-4E6E-9726-29D55C60C229@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:50:23 -0000 Brian, > there is a question as to what of this is reduced-length encoding and what is just "using templates". If 5102 and IANA's IPFIX registry didn't list field sizes, then this would just be "using templates". However, since they do specify sizes, this is reduced-length encoding in most cases (ie, excepting strings / arrays). There's at least one tool which expects the 5102/IANA sizes, regardless of what the template says :-( P. From janovak@cisco.com Sat Apr 14 13:58:06 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F38B21F857A for ; Sat, 14 Apr 2012 13:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA89lo7m7xrj for ; Sat, 14 Apr 2012 13:58:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5A521F8576 for ; Sat, 14 Apr 2012 13:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=janovak@cisco.com; l=345; q=dns/txt; s=iport; t=1334437085; x=1335646685; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=oE0dKera1oZiklg08XKgpRIZEvV386rLhCHy9LyK/UU=; b=iefGzUL764J5tVY+9IaKujwq/Qvw1/634JUTTPIJFVHUSusHrSI34nXL kYmn6w2S7Qgeu/ufny+diDn75w2kgKts8pvVFl8+r5CEW8pY6GGpp3m0W Q36vP730Fuk4Gf1ivTWn3dQmKz6FepfofOPMJ7ndWqk4kcf17LLDWMf0R k=; X-IronPort-AV: E=Sophos;i="4.75,423,1330905600"; d="scan'208";a="135169103" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2012 20:58:04 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3EKw4NJ010414; Sat, 14 Apr 2012 20:58:04 GMT Received: from xmb-ams-212.cisco.com ([144.254.75.23]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Apr 2012 22:58:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Apr 2012 22:58:03 +0200 Message-ID: In-Reply-To: <4F841487.8090604@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) Thread-Index: Ac0XCi4AJ/m2p5GYTh+nYoKKfQEYjQDdrrYg References: <4F841487.8090604@cisco.com> From: "Jan Novak (janovak)" To: "Benoit Claise (bclaise)" , X-OriginalArrivalTime: 14 Apr 2012 20:58:04.0764 (UTC) FILETIME=[495E69C0:01CD1A81] Cc: Ron Bonica , Al Morton Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 20:58:06 -0000 >While some others refer to idle timeout >RFC 5102,=20 >draft-ietf-bmwg-ipflow-meth-09 I have checked (word searched) and there is no single occurrence of word "idle" in draft-ietf-bmwg-ipflow-meth-09. The terminology active/inactive seemed to be at least historically most justified or we simply never used anything else ... Jan From trammell@tik.ee.ethz.ch Tue Apr 17 05:07:42 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2600221F85A1 for ; Tue, 17 Apr 2012 05:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.686 X-Spam-Level: X-Spam-Status: No, score=-5.686 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMQyEfUlFIdp for ; Tue, 17 Apr 2012 05:07:41 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 80EBD21F859A for ; Tue, 17 Apr 2012 05:07:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0F310D930C; Tue, 17 Apr 2012 14:07:40 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LI5PdD2RnfYr; Tue, 17 Apr 2012 14:07:39 +0200 (MEST) Received: from [10.0.1.13] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BA5D7D930B; Tue, 17 Apr 2012 14:07:39 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F85B64D.9030900@cisco.com> Date: Tue, 17 Apr 2012 14:07:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F849430.7020306@plixer.com> <7A58FD92-2432-4E6E-9726-29D55C60C229@tik.ee.ethz.ch> <4F85B64D.9030900@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1257) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 12:07:42 -0000 Hi, Paul, Andrew, Well, that's unfortunate. One open question that came up as I was clarifying this section... We = definitely support reduced length encoding for the following types: unsigned16, unsigned32, unsigned64 signed16, signed32, signed64 float64 (reduce only to 4-byte float32) The following types have no length inherent to the type (though may = represent IEs with their own length restrictions, a note that should be = added to section 6.2): octetArray, string The following types have internal structure and therefore cannot be = reduced: ipv4Address, ipv6Address, macAddress dateTimeMicroseconds, dateTimeNanoseconds Which leaves us with dateTimeSeconds, dateTimeMilliseconds, and = dateTimeMicroseconds. 5101 is silent on whether these can be reduced or = not, which implies that they MUST NOT be exported with reduced length = encoding; I think we want to clarify that directly in 5101bis, though I = don't have a good justification therefor. Certainly there are range = limitations (dateTimeMicroseconds can cover a 2300 year span with 7 = bytes, and dateTimeMilliseconds can cover a 9000 year span with 6, = though these seem like a whole lot of work for very little = optimization), which are probably good enough... Thoughts? Thanks, Brian On Apr 11, 2012, at 6:50 PM, Paul Aitken wrote: > Brian, >=20 >> there is a question as to what of this is reduced-length encoding and = what is just "using templates". >=20 > If 5102 and IANA's IPFIX registry didn't list field sizes, then this = would just be "using templates". >=20 > However, since they do specify sizes, this is reduced-length encoding = in most cases (ie, excepting strings / arrays). >=20 > There's at least one tool which expects the 5102/IANA sizes, = regardless of what the template says :-( >=20 > P. From andrewf@plixer.com Tue Apr 17 07:00:04 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D71921F8568 for ; Tue, 17 Apr 2012 07:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA5iXj+QAMMy for ; Tue, 17 Apr 2012 07:00:03 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4A321F853C for ; Tue, 17 Apr 2012 07:00:03 -0700 (PDT) Received: from [10.100.1.132] ([66.186.184.193]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 10:00:01 -0400 Message-ID: <4F8D7760.2070009@plixer.com> Date: Tue, 17 Apr 2012 10:00:00 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120411 Thunderbird/14.0a1 MIME-Version: 1.0 To: Brian Trammell References: <4F849430.7020306@plixer.com> <7A58FD92-2432-4E6E-9726-29D55C60C229@tik.ee.ethz.ch> <4F85B64D.9030900@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Apr 2012 14:00:01.0023 (UTC) FILETIME=[618888F0:01CD1CA2] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC 5101bis X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 14:00:04 -0000 Hi Brian, I don't see much point in a reduced encoding for dateTimeSeconds since we clarified it in 5101bis to be an unsigned 32 bit integer having a start epoch of 1 January 1970. 3 bytes only allows dates into July of 1970 which doesn't seem particularly useful. As for dateTimeMilliseconds and dateTimeMicroseconds I am currently ambivalent on whether these MUST NOT be exported with reduced length encoding. I haven't tried, but I believe that if I was sent a reduced encoding of one of these that everything would just work. Different implementations may be less forgiving. -Andrew On 04/17/2012 08:07 AM, Brian Trammell wrote: > Hi, Paul, Andrew, > > Well, that's unfortunate. > > One open question that came up as I was clarifying this section... We definitely support reduced length encoding for the following types: > > unsigned16, unsigned32, unsigned64 > signed16, signed32, signed64 > float64 (reduce only to 4-byte float32) > > The following types have no length inherent to the type (though may represent IEs with their own length restrictions, a note that should be added to section 6.2): > > octetArray, string > > The following types have internal structure and therefore cannot be reduced: > > ipv4Address, ipv6Address, macAddress > dateTimeMicroseconds, dateTimeNanoseconds > > Which leaves us with dateTimeSeconds, dateTimeMilliseconds, and dateTimeMicroseconds. 5101 is silent on whether these can be reduced or not, which implies that they MUST NOT be exported with reduced length encoding; I think we want to clarify that directly in 5101bis, though I don't have a good justification therefor. Certainly there are range limitations (dateTimeMicroseconds can cover a 2300 year span with 7 bytes, and dateTimeMilliseconds can cover a 9000 year span with 6, though these seem like a whole lot of work for very little optimization), which are probably good enough... > > Thoughts? > > Thanks, > > Brian > > On Apr 11, 2012, at 6:50 PM, Paul Aitken wrote: > >> Brian, >> >>> there is a question as to what of this is reduced-length encoding and what is just "using templates". >> If 5102 and IANA's IPFIX registry didn't list field sizes, then this would just be "using templates". >> >> However, since they do specify sizes, this is reduced-length encoding in most cases (ie, excepting strings / arrays). >> >> There's at least one tool which expects the 5102/IANA sizes, regardless of what the template says :-( >> >> P. From bclaise@cisco.com Wed Apr 18 03:51:24 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8521F8554 for ; Wed, 18 Apr 2012 03:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF8oG7OoNkp5 for ; Wed, 18 Apr 2012 03:51:19 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2AB21F85C3 for ; Wed, 18 Apr 2012 03:51:18 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3IApB9U007599; Wed, 18 Apr 2012 12:51:11 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3IApA11024537; Wed, 18 Apr 2012 12:51:10 +0200 (CEST) Message-ID: <4F8E9C9E.4080404@cisco.com> Date: Wed, 18 Apr 2012 12:51:10 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Gerhard Muenz References: <4F841487.8090604@cisco.com> <4F846107.7040907@net.in.tum.de> In-Reply-To: <4F846107.7040907@net.in.tum.de> Content-Type: multipart/alternative; boundary="------------060401040308010109050608" Cc: Ron Bonica , Al Morton , "ipfix@ietf.org" Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 10:51:24 -0000 This is a multi-part message in MIME format. --------------060401040308010109050608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I believe that consistency is important amongst all the IPFIX documents. What Brian expressed "Given that 5102 predates all other (directly-IPFIX-related) references, and there's an IE in the IANA registry called flowIdleTimeout, I'd tend to go with "idle" for this one." is I believe the right way forward. And Gerhard mentioned " We could change the name in the MIB and in ipfix-config if consistency is important." So let me propose the following: - http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, in the RFC-editor queue: we could still change inactive to idle - http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, in the RFC-editor queue we could still change inactive to idle - Editorial errata on RFC5472: "inactive" -> "idle" Potentially, an extra sentence such as: "note that the idle timeout is sometimes called the inactive timeout in the industry" - http://www.ietf.org/id/draft-ietf-bmwg-ipflow-meth-09.txt replace inactive by idle. Any objections? Regards, Benoit. > Hi Benoit, > > The parameter was always called inactive timeout in IPFIX MIB. > ipfix-config changed from idleTimeout to inactiveTimeout in > draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB. > > We could change the name in the MIB and in ipfix-config if consistency > is important. > > Gerhard > > > On 10.04.2012 13:07, Benoit Claise wrote: >> Dear all, >> >> Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this >> draft defines two new terms: Active Timeout and Inactive Timeout. >> I was thinking: surely, we have defined those terms already in some >> IPFIX RFCs. >> Actually, I was unable to find any references.... Have I overlooked >> something? >> >> The only pointers I could find are in RFC5102 >> >> >> 5.11.1. flowActiveTimeout >> >> >> Description: >> The number of seconds after which an active Flow is timed out >> anyway, even if there is still a continuous flow of packets. >> Abstract Data Type: unsigned16 >> ElementId: 36 >> Status: current >> Units: seconds >> >> >> 5.11.2. flowIdleTimeout >> >> >> >> Description: >> A Flow is considered to be timed out if no packets belonging to >> the Flow have been observed for the number of seconds specified by >> this field. >> Abstract Data Type: unsigned16 >> ElementId: 37 >> Status: current >> Units: seconds >> >> >> 5.11.3. flowEndReason >> >> Description: >> The reason for Flow termination. The range of values includes the >> following: >> >> 0x01: idle timeout >> The Flow was terminated because it was considered to be >> idle. >> >> 0x02: active timeout >> The Flow was terminated for reporting purposes while it was >> still active, for example, after the maximum lifetime of >> unreported Flows was reached. >> >> ... >> >> Here is one issue. >> Some documents refer to inactive timeout >> RFC5472, >> ipfixMeteringProcessCacheInactiveTimeout in >> http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03 >> inactiveTimeout in >> http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 >> While some others refer to idle timeout >> RFC 5102, >> draft-ietf-bmwg-ipflow-meth-09 >> >> Any proposal to fix this problem? >> >> Regards, Benoit (OPS A.D.) >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix --------------060401040308010109050608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

I believe that consistency is important amongst all the IPFIX documents.
What Brian expressed "Given that 5102 predates all other (directly-IPFIX-related) references, and there's an IE in the IANA registry called flowIdleTimeout, I'd tend to go with "idle" for this one." is I believe the right way forward.
And Gerhard mentioned " We could change the name in the MIB and in ipfix-config if consistency is important."

So let me propose the following:
- http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, in the RFC-editor queue:
    we could still change inactive to idle
- http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, in the RFC-editor queue
    we could still change inactive to idle
- Editorial errata on RFC5472:
    "inactive" -> "idle"
    Potentially, an extra sentence such as: "note that the idle timeout is sometimes called the inactive timeout in the industry"
- http://www.ietf.org/id/draft-ietf-bmwg-ipflow-meth-09.txt
    replace inactive by idle.

Any objections?

Regards, Benoit.
Hi Benoit,

The parameter was always called inactive timeout in IPFIX MIB. ipfix-config changed from idleTimeout to inactiveTimeout in draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB.

We could change the name in the MIB and in ipfix-config if consistency is important.

Gerhard


On 10.04.2012 13:07, Benoit Claise wrote:
Dear all,

Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft defines two new terms: Active Timeout and Inactive Timeout.
I was thinking: surely, we have defined those terms already in some IPFIX RFCs.
Actually, I was unable to find any references.... Have I overlooked something?

The only pointers I could find are in RFC5102

5.11.1.  flowActiveTimeout

   Description:
      The number of seconds after which an active Flow is timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned16
   ElementId: 36
   Status: current
   Units: seconds

5.11.2.  flowIdleTimeout


   Description:
      A Flow is considered to be timed out if no packets belonging to
      the Flow have been observed for the number of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.11.3.  flowEndReason
Description:
      The reason for Flow termination.  The range of values includes the
      following:

      0x01: idle timeout
            The Flow was terminated because it was considered to be
            idle.

      0x02: active timeout
            The Flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported Flows was reached.

      ...
Here is one issue.
Some documents refer to inactive timeout
    RFC5472,
    ipfixMeteringProcessCacheInactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03
    inactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10
While some others refer to idle timeout
    RFC 5102,
    draft-ietf-bmwg-ipflow-meth-09

Any proposal to fix this problem?

Regards, Benoit (OPS A.D.)



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------060401040308010109050608-- From bclaise@cisco.com Wed Apr 18 07:03:03 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9407021F84B8 for ; Wed, 18 Apr 2012 07:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia1o31yqAPbY for ; Wed, 18 Apr 2012 07:02:58 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD1A21F84BF for ; Wed, 18 Apr 2012 07:02:58 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3IE2uRt000048; Wed, 18 Apr 2012 16:02:56 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3IE2tWG009028; Wed, 18 Apr 2012 16:02:56 +0200 (CEST) Message-ID: <4F8EC98F.90408@cisco.com> Date: Wed, 18 Apr 2012 16:02:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Andrew Feren References: <4F85A3AB.9050409@plixer.com> In-Reply-To: <4F85A3AB.9050409@plixer.com> Content-Type: multipart/alternative; boundary="------------010903010203040707010406" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] draft-claise-export-application-info-in-ipfix-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:03:03 -0000 This is a multi-part message in MIME format. --------------010903010203040707010406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, Many thanks for your review. See in line. > First a few editorial notes. > > Page 6 [top paragraph] > > "available at [CISCO], only the layer 7 ones cannot compiled" > should be > "available at [CISCO], only the layer 7 ones cannot be compiled " This following text has been removed in the current temp version. This feedback comes from the AD review (Dan Romascanu) Note that, while the Application Ids for all applications are available at [CISCO ], only the layer 7 ones cannot compiled from existing well known registries. > > Page 12 > "protocol encoding may encoded with 3 bytes. In such a case, " > should be > "protocol encoding may be encoded with 3 bytes. In such a case," Done. > > Page 27 section 6.6 > > the reporting application wants to determine whether or the > default HTTP port 80 or 8080 was used, it must export the > destination port (destinationTransportPort at [IANA-IPFIX]) > in the corresponding IPFIX record. > > should be something like > > the reporting application wants to determine whether or not the > default HTTP port 80 or 8080 was used, the > destination port (destinationTransportPort at [IANA-IPFIX]) > must also be exported in the corresponding IPFIX record. > That's better. Thanks. > > Now a few other notes. > > Maybe it is just me, but on page 8 I have no idea what is meant by > > The Selector ID term is in sync with the selectorId > Information Element, specified in the PSAMP Protocol > [RFC5476]. NEW: The Selector ID term is similar to the selectorId Information Element, specified in the PSAMP Protocol [RFC5476]. > > > 7.1.8. p2pTechnology > 7.1.9. tunnelTechnology > 7.1.10. encryptedTechnology > > specify y, 2, n, 2, u, and 0 in addition to the "yes", "no", and > "unassigned" values found at > http://www.iana.org/assignments/ipfix/ipfix.xml > > Are all of these valid values? If yes should the IANA entries be updated? Yes, IANA should be updated. I put this note in the draft, to make sure it's not forgotten. RFC-EDITOR/IANA-EDITOR: some entries are already present in IPFIX-IANA. However, those must be updated with the current content. Regards, Benoit. > > -Andrew --------------010903010203040707010406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Andrew,

Many thanks for your review. See in line.

First a few editorial notes.

Page 6 [top paragraph]

"available at [CISCO], only the layer 7 ones cannot compiled"
should be
"available at [CISCO], only the layer 7 ones cannot be compiled "
This following text has been removed in the current temp version. This feedback comes from the AD review (Dan Romascanu)
      Note that, while the Application Ids for all applications are
      available at [CISCO], only the layer 7 ones cannot compiled
      from existing well known registries.


Page 12
"protocol encoding may encoded with 3 bytes. In such a case, "
should be
"protocol encoding may be encoded with 3 bytes. In such a case,"
Done.

Page 27 section 6.6

        the reporting application wants to determine whether or the
        default HTTP port 80 or 8080 was used, it must export the
        destination port (destinationTransportPort at [IANA-IPFIX])
        in the corresponding IPFIX record. 

should be something like

        the reporting application wants to determine whether or not the
        default HTTP port 80 or 8080 was used, the
        destination port (destinationTransportPort at [IANA-IPFIX])
        must also be exported in the corresponding IPFIX record. 

That's better. Thanks.

Now a few other notes.

Maybe it is just me, but on page 8 I have no idea what is meant by

        The Selector ID term is in sync with the selectorId
        Information Element, specified in the PSAMP Protocol
        [RFC5476]. 
NEW:
         The Selector ID term is similar to the selectorId
        Information Element, specified in the PSAMP Protocol
        [RFC5476]. 


     7.1.8. p2pTechnology
     7.1.9. tunnelTechnology
     7.1.10. encryptedTechnology

specify y, 2, n, 2, u, and 0 in addition to the "yes", "no", and "unassigned" values found at http://www.iana.org/assignments/ipfix/ipfix.xml

Are all of these valid values?  If yes should the IANA entries be updated?
Yes, IANA should be updated.
I put this note in the draft, to make sure it's not forgotten.

RFC-EDITOR/IANA-EDITOR: some entries are already present in IPFIX-IANA. However, those must be updated with the current content.


Regards, Benoit.

-Andrew

--------------010903010203040707010406-- From bclaise@cisco.com Wed Apr 18 07:03:14 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6D21F84B8 for ; Wed, 18 Apr 2012 07:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzKBG7LQiSYT for ; Wed, 18 Apr 2012 07:03:10 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9F44021F8549 for ; Wed, 18 Apr 2012 07:03:09 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3IE38TJ000112; Wed, 18 Apr 2012 16:03:08 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3IE38Hp009284; Wed, 18 Apr 2012 16:03:08 +0200 (CEST) Message-ID: <4F8EC99C.80607@cisco.com> Date: Wed, 18 Apr 2012 16:03:08 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Andrew Feren References: <4F84A0C8.80802@plixer.com> In-Reply-To: <4F84A0C8.80802@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Nir Ben-Dvora \(nirbd\)" , ipfix@ietf.org Subject: Re: [IPFIX] draft-claise-export-application-info-in-ipfix-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:03:14 -0000 Andrew, Chris, > On 03/28/2012 06:48 AM, Chris Inacio wrote: >> http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-05 >> >> >> ClassEngineID + SelectorID - shouldn't this be 32-bits and possible >> to be shortened using reduced size encoding? I'm not sure there is >> any advantage to saying you won't know until you see the Engine ID; >> and seriously, from an implementation point of view; building the >> decoder, I'm not going to care while parsing the information. I will >> only care when doing the human display level - when I have to do the >> lookups. For the protocol, (on the wire,) I prefer a 32-bit field. > Hi Chris, > > I don't see how it can be just 32-bits since according to section 4.2 > classificationEngineId=12(PANA-L2) + selectorId = 6 bytes. > > I'm also not sure I agree on using reduced size encoding. If NetFlow > v9 is being exported and you are trying to minimize your encoding size > you don't have much choice. The problem I have with the reduced size > encoding described for legacy protocols is that an applicationId that > should be common to anyone implementing this draft (1..1 for example) > can actually be encoded encoded 5 different ways. Gross. I'd prefer > to burn some extra bytes for v9 rather than try and deal with the > normalizing different encodings, but I think that genie is already out > of the bottle. > > I definitely wouldn't want to see that continue in IPFIX since we have > a perfectly nice variable length octetArray. With a variable length > octetArray at least equivalent applicationIds can be matched without > having to decompose them. Exactly. And what if, in the future, we have a registry, which is even bigger than the ones we have today? With variable length, we're ready. Regards, Benoit. > > -Andrew > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > From bclaise@cisco.com Wed Apr 18 07:19:57 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343D521F85B4 for ; Wed, 18 Apr 2012 07:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbZulUpaLH0k for ; Wed, 18 Apr 2012 07:19:53 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 2517921F85AE for ; Wed, 18 Apr 2012 07:19:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3IEJk1o001849; Wed, 18 Apr 2012 16:19:46 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3IEJjgx026167; Wed, 18 Apr 2012 16:19:46 +0200 (CEST) Message-ID: <4F8ECD81.3050303@cisco.com> Date: Wed, 18 Apr 2012 16:19:45 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Chris Inacio References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Ron Bonica , "ipfix@ietf.org" Subject: Re: [IPFIX] draft-claise-export-application-info-in-ipfix-05 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:19:57 -0000 Hi Chris, Thanks for your review. > http://tools.ietf.org/html/draft-claise-export-application-info-in-ipfix-05 > > ClassEngineID + SelectorID - shouldn't this be 32-bits and possible to be shortened using reduced size encoding? I'm not sure there is any advantage to saying you won't know until you see the Engine ID; and seriously, from an implementation point of view; building the decoder, I'm not going to care while parsing the information. I will only care when doing the human display level - when I have to do the lookups. For the protocol, (on the wire,) I prefer a 32-bit field. See the answer I just sent to the IPFIX mailing list. > > I think the reference to the Cisco L7 registry should be removed from the main body text; and if possible added to some type of appendix. This issue is that this is a list that keeps updating all the time. So a reference is actually required. > > Is defaulting to TCP for protocol conflicts the best answer? Why not just make it relevant to the transport contained in another IE? Because we would break the following rule: the semantic of one IE would depend on the value of a different one. > > Aren't the IEEE standards you reference, well standards: e.g. normative, not informative? Good catch. Corrected. > > Can we add the definition of how to get an online registry into the document, and the XML definition of the registry? We have all those possible registry entries - why not define the interchange (lightweight) to get registry of app labels, and an options record to to be to specify its address. That makes a lot of sense, and we should/will do it. This will take a little bit of time to make it right. However, the proposal for this draft is to put on paper the specifications of what has been implemented. Copying Ron Bonica, the new AD sponsored for this draft (transferred from Dan Romascanu) > > e.g. > > Name: applicationRegistry > Description: > Specifies a URN where section 8.x well formed application registry information may be retrieved. > Abstract Data Type: string > Data Type Semantics: URN > ElementId: > Status: > > > > > > > Cisco > _date_ > VER > VER > > > > > . > . > . > > > > > > Then the Cisco specific references within the document above can be moved into the section related to how to get specific registries. > > > What missing: > > I need data extracted from fields as well; with a big question on how to efficiently index into it. I see two possibilities: Sure ;-) Many of us need this. This would be a second building block... > > (1) We have a general registry of useful fields (I have no idea how to build this even close to comprehensively): > 1 - user > 2 - organization > 3 - command > 4- command path > 5 - … > > and then using structured data, under an application level, you can have something like application id: > +--------------+---------------------------------------+ > | 1 | (string) inacio | > +--------------+---------------------------------------+ > | 2 | (string) CERT | > +--------------+---------------------------------------+ > > for something like an X.509 certificate. > > (2) define the fields specifically to the application protocols, which means extending the registry type information from above: > > X.509.user = inacio > X.509.org = CERT > > for example. But that leads to IE explosion. > > > Lastly, also, why all the reserved registry numbers? We're inventing something new, aren't we? ;) We started this project years ago, so let's say a few beginner mistakes. On top of that, we might need some more registries for custom protocols ... Regards, Benoit (as a contributor) > > Chris > > > From paitken@cisco.com Wed Apr 18 09:02:23 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948CE21F8459 for ; Wed, 18 Apr 2012 09:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWXNr00ySHpQ for ; Wed, 18 Apr 2012 09:02:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AEE8521F84EA for ; Wed, 18 Apr 2012 09:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=11517; q=dns/txt; s=iport; t=1334764937; x=1335974537; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=XsqdMxNReM2PmgC9tzMnyFEeLZuTsIiO0YHqeu7vMEI=; b=Y6QKtj9eAMHhNP1bZVhOpiqviWfxN+kvDO2RGb+lHqPkjK/hAtt90Odl ZQwcgewRdrZkyLzuGsUZm6mf4o5tAzEizK5R6YnJ0JIbUgIvgL7vpj4oy w71mnZ+9F9/ka3l3gZTrgEfaS5VVa+f4K5cryz3mOGZDEVV5rl7UHlptn g=; X-IronPort-AV: E=Sophos;i="4.75,442,1330905600"; d="scan'208,217";a="135560243" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 18 Apr 2012 16:02:16 +0000 Received: from [144.254.153.63] (dhcp-144-254-153-63.cisco.com [144.254.153.63]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3IG2GVh013128; Wed, 18 Apr 2012 16:02:16 GMT Message-ID: <4F8EE58A.3000007@cisco.com> Date: Wed, 18 Apr 2012 17:02:18 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Benoit Claise References: <4F841487.8090604@cisco.com> <4F846107.7040907@net.in.tum.de> <4F8E9C9E.4080404@cisco.com> In-Reply-To: <4F8E9C9E.4080404@cisco.com> Content-Type: multipart/alternative; boundary="------------000005080107000605010200" Cc: Ron Bonica , Al Morton , "ipfix@ietf.org" Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:02:23 -0000 This is a multi-part message in MIME format. --------------000005080107000605010200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benoit, Good plan; no objection. P. On 18/04/12 11:51, Benoit Claise wrote: > Dear all, > > I believe that consistency is important amongst all the IPFIX documents. > What Brian expressed "Given that 5102 predates all other > (directly-IPFIX-related) references, and there's an IE in the IANA > registry called flowIdleTimeout, I'd tend to go with "idle" for this > one." is I believe the right way forward. > And Gerhard mentioned " We could change the name in the MIB and in > ipfix-config if consistency is important." > > So let me propose the following: > - http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, > in the RFC-editor queue: > we could still change inactive to idle > - http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, in the > RFC-editor queue > we could still change inactive to idle > - Editorial errata on RFC5472: > "inactive" -> "idle" > Potentially, an extra sentence such as: "note that the idle > timeout is sometimes called the inactive timeout in the industry" > - http://www.ietf.org/id/draft-ietf-bmwg-ipflow-meth-09.txt > replace inactive by idle. > > Any objections? > > Regards, Benoit. >> Hi Benoit, >> >> The parameter was always called inactive timeout in IPFIX MIB. >> ipfix-config changed from idleTimeout to inactiveTimeout in >> draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB. >> >> We could change the name in the MIB and in ipfix-config if >> consistency is important. >> >> Gerhard >> >> >> On 10.04.2012 13:07, Benoit Claise wrote: >>> Dear all, >>> >>> Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this >>> draft defines two new terms: Active Timeout and Inactive Timeout. >>> I was thinking: surely, we have defined those terms already in some >>> IPFIX RFCs. >>> Actually, I was unable to find any references.... Have I overlooked >>> something? >>> >>> The only pointers I could find are in RFC5102 >>> >>> >>> 5.11.1. flowActiveTimeout >>> >>> >>> Description: >>> The number of seconds after which an active Flow is timed out >>> anyway, even if there is still a continuous flow of packets. >>> Abstract Data Type: unsigned16 >>> ElementId: 36 >>> Status: current >>> Units: seconds >>> >>> >>> 5.11.2. flowIdleTimeout >>> >>> >>> >>> Description: >>> A Flow is considered to be timed out if no packets belonging to >>> the Flow have been observed for the number of seconds specified by >>> this field. >>> Abstract Data Type: unsigned16 >>> ElementId: 37 >>> Status: current >>> Units: seconds >>> >>> >>> 5.11.3. flowEndReason >>> >>> Description: >>> The reason for Flow termination. The range of values includes the >>> following: >>> >>> 0x01: idle timeout >>> The Flow was terminated because it was considered to be >>> idle. >>> >>> 0x02: active timeout >>> The Flow was terminated for reporting purposes while it was >>> still active, for example, after the maximum lifetime of >>> unreported Flows was reached. >>> >>> ... >>> >>> Here is one issue. >>> Some documents refer to inactive timeout >>> RFC5472, >>> ipfixMeteringProcessCacheInactiveTimeout in >>> http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03 >>> inactiveTimeout in >>> http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 >>> While some others refer to idle timeout >>> RFC 5102, >>> draft-ietf-bmwg-ipflow-meth-09 >>> >>> Any proposal to fix this problem? >>> >>> Regards, Benoit (OPS A.D.) >>> >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------000005080107000605010200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Benoit,

Good plan; no objection.

P.


On 18/04/12 11:51, Benoit Claise wrote:
Dear all,

I believe that consistency is important amongst all the IPFIX documents.
What Brian expressed "Given that 5102 predates all other (directly-IPFIX-related) references, and there's an IE in the IANA registry called flowIdleTimeout, I'd tend to go with "idle" for this one." is I believe the right way forward.
And Gerhard mentioned " We could change the name in the MIB and in ipfix-config if consistency is important."

So let me propose the following:
- http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, in the RFC-editor queue:
    we could still change inactive to idle
- http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, in the RFC-editor queue
    we could still change inactive to idle
- Editorial errata on RFC5472:
    "inactive" -> "idle"
    Potentially, an extra sentence such as: "note that the idle timeout is sometimes called the inactive timeout in the industry"
- http://www.ietf.org/id/draft-ietf-bmwg-ipflow-meth-09.txt
    replace inactive by idle.

Any objections?

Regards, Benoit.
Hi Benoit,

The parameter was always called inactive timeout in IPFIX MIB. ipfix-config changed from idleTimeout to inactiveTimeout in draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB.

We could change the name in the MIB and in ipfix-config if consistency is important.

Gerhard


On 10.04.2012 13:07, Benoit Claise wrote:
Dear all,

Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft defines two new terms: Active Timeout and Inactive Timeout.
I was thinking: surely, we have defined those terms already in some IPFIX RFCs.
Actually, I was unable to find any references.... Have I overlooked something?

The only pointers I could find are in RFC5102

5.11.1.  flowActiveTimeout

   Description:
      The number of seconds after which an active Flow is timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned16
   ElementId: 36
   Status: current
   Units: seconds

5.11.2.  flowIdleTimeout


   Description:
      A Flow is considered to be timed out if no packets belonging to
      the Flow have been observed for the number of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.11.3.  flowEndReason
Description:
      The reason for Flow termination.  The range of values includes the
      following:

      0x01: idle timeout
            The Flow was terminated because it was considered to be
            idle.

      0x02: active timeout
            The Flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported Flows was reached.

      ...
Here is one issue.
Some documents refer to inactive timeout
    RFC5472,
    ipfixMeteringProcessCacheInactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03
    inactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10
While some others refer to idle timeout
    RFC 5102,
    draft-ietf-bmwg-ipflow-meth-09

Any proposal to fix this problem?

Regards, Benoit (OPS A.D.)



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------000005080107000605010200-- From trammell@tik.ee.ethz.ch Wed Apr 18 09:11:34 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099F321F85E3 for ; Wed, 18 Apr 2012 09:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.025 X-Spam-Level: X-Spam-Status: No, score=-6.025 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmOohdWPoxFn for ; Wed, 18 Apr 2012 09:11:30 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DBA7C21F85CC for ; Wed, 18 Apr 2012 09:11:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2CC76D9305; Wed, 18 Apr 2012 18:11:29 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TvLg5Z7I4B+g; Wed, 18 Apr 2012 18:11:28 +0200 (MEST) Received: from [10.0.1.2] (cust-integra-121-161.antanet.ch [80.75.121.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id B29B0D9304; Wed, 18 Apr 2012 18:11:28 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F8E9C9E.4080404@cisco.com> Date: Wed, 18 Apr 2012 18:11:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F841487.8090604@cisco.com> <4F846107.7040907@net.in.tum.de> <4F8E9C9E.4080404@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1257) Cc: Ron Bonica , Al Morton , "ipfix@ietf.org" Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:11:34 -0000 Hi, Benoit, Sounds good to me. Cheers, Brian On Apr 18, 2012, at 12:51 PM, Benoit Claise wrote: > Dear all, >=20 > I believe that consistency is important amongst all the IPFIX = documents. > What Brian expressed "Given that 5102 predates all other = (directly-IPFIX-related) references, and there's an IE in the IANA = registry called flowIdleTimeout, I'd tend to go with "idle" for this = one." is I believe the right way forward. > And Gerhard mentioned " We could change the name in the MIB and in = ipfix-config if consistency is important." >=20 > So let me propose the following: > - http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, = in the RFC-editor queue: > we could still change inactive to idle > - http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, in the = RFC-editor queue > we could still change inactive to idle > - Editorial errata on RFC5472:=20 > "inactive" -> "idle" > Potentially, an extra sentence such as: "note that the idle = timeout is sometimes called the inactive timeout in the industry" > - http://www.ietf.org/id/draft-ietf-bmwg-ipflow-meth-09.txt > replace inactive by idle. >=20 > Any objections? >=20 > Regards, Benoit. >> Hi Benoit, >>=20 >> The parameter was always called inactive timeout in IPFIX MIB. = ipfix-config changed from idleTimeout to inactiveTimeout in = draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB. >>=20 >> We could change the name in the MIB and in ipfix-config if = consistency is important. >>=20 >> Gerhard >>=20 >>=20 >> On 10.04.2012 13:07, Benoit Claise wrote: >>> Dear all, >>>=20 >>> Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this = draft defines two new terms: Active Timeout and Inactive Timeout. >>> I was thinking: surely, we have defined those terms already in some = IPFIX RFCs. >>> Actually, I was unable to find any references.... Have I overlooked = something? >>>=20 >>> The only pointers I could find are in RFC5102 >>>=20 >>> 5.11.1. flowActiveTimeout >>>=20 >>>=20 >>> Description: >>> The number of seconds after which an active Flow is timed out >>> anyway, even if there is still a continuous flow of packets. >>> Abstract Data Type: unsigned16 >>> ElementId: 36 >>> Status: current >>> Units: seconds >>>=20 >>>=20 >>> 5.11.2. flowIdleTimeout >>>=20 >>>=20 >>>=20 >>> Description: >>> A Flow is considered to be timed out if no packets belonging = to >>> the Flow have been observed for the number of seconds = specified by >>> this field. >>> Abstract Data Type: unsigned16 >>> ElementId: 37 >>> Status: current >>> Units: seconds >>>=20 >>>=20 >>> 5.11.3. flowEndReason >>>=20 >>> Description: >>> The reason for Flow termination. The range of values includes = the >>> following: >>>=20 >>> 0x01: idle timeout >>> The Flow was terminated because it was considered to be >>> idle. >>>=20 >>> 0x02: active timeout >>> The Flow was terminated for reporting purposes while it = was >>> still active, for example, after the maximum lifetime of >>> unreported Flows was reached. >>>=20 >>> ... >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Here is one issue. >>> Some documents refer to inactive timeout >>> RFC5472,=20 >>> ipfixMeteringProcessCacheInactiveTimeout in = http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03 >>> inactiveTimeout in = http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 >>> While some others refer to idle timeout >>> RFC 5102,=20 >>> draft-ietf-bmwg-ipflow-meth-09 >>>=20 >>> Any proposal to fix this problem? >>>=20 >>> Regards, Benoit (OPS A.D.) >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPFIX mailing list >>>=20 >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Thu Apr 19 06:14:49 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E9921F85E3 for ; Thu, 19 Apr 2012 06:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Scgvx5n5VBZO for ; Thu, 19 Apr 2012 06:14:45 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 0646621F8615 for ; Thu, 19 Apr 2012 06:14:42 -0700 (PDT) Received: from [10.100.1.132] ([66.186.184.193]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Apr 2012 09:14:41 -0400 Message-ID: <4F900FC1.3050602@plixer.com> Date: Thu, 19 Apr 2012 09:14:41 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120411 Thunderbird/14.0a1 MIME-Version: 1.0 To: ipfix@ietf.org References: <4F841487.8090604@cisco.com> <4F846107.7040907@net.in.tum.de> <4F8E9C9E.4080404@cisco.com> In-Reply-To: <4F8E9C9E.4080404@cisco.com> Content-Type: multipart/alternative; boundary="------------000305070804090504000200" X-OriginalArrivalTime: 19 Apr 2012 13:14:41.0864 (UTC) FILETIME=[619D4C80:01CD1E2E] Subject: Re: [IPFIX] No active/inactive timeout definitions in any IPFIX RFCs? Idle versus inactive terminology? (part of draft-ietf-bmwg-ipflow-meth-09 review) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 13:14:49 -0000 This is a multi-part message in MIME format. --------------000305070804090504000200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Benoit, all, No objection, however, given how common the term "inactive timeout" is in the industry that including a note like you suggested is probably worth doing. -Andrew On 04/18/2012 06:51 AM, Benoit Claise wrote: > Dear all, > > I believe that consistency is important amongst all the IPFIX documents. > What Brian expressed "Given that 5102 predates all other > (directly-IPFIX-related) references, and there's an IE in the IANA > registry called flowIdleTimeout, I'd tend to go with "idle" for this > one." is I believe the right way forward. > And Gerhard mentioned " We could change the name in the MIB and in > ipfix-config if consistency is important." > > So let me propose the following: > - http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, > in the RFC-editor queue: > we could still change inactive to idle > - http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, in the > RFC-editor queue > we could still change inactive to idle > - Editorial errata on RFC5472: > "inactive" -> "idle" > Potentially, an extra sentence such as: "note that the idle > timeout is sometimes called the inactive timeout in the industry" > - http://www.ietf.org/id/draft-ietf-bmwg-ipflow-meth-09.txt > replace inactive by idle. > > Any objections? > > Regards, Benoit. >> Hi Benoit, >> >> The parameter was always called inactive timeout in IPFIX MIB. >> ipfix-config changed from idleTimeout to inactiveTimeout in >> draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB. >> >> We could change the name in the MIB and in ipfix-config if >> consistency is important. >> >> Gerhard >> >> >> On 10.04.2012 13:07, Benoit Claise wrote: >>> Dear all, >>> >>> Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this >>> draft defines two new terms: Active Timeout and Inactive Timeout. >>> I was thinking: surely, we have defined those terms already in some >>> IPFIX RFCs. >>> Actually, I was unable to find any references.... Have I overlooked >>> something? >>> >>> The only pointers I could find are in RFC5102 >>> >>> >>> 5.11.1. flowActiveTimeout >>> >>> >>> Description: >>> The number of seconds after which an active Flow is timed out >>> anyway, even if there is still a continuous flow of packets. >>> Abstract Data Type: unsigned16 >>> ElementId: 36 >>> Status: current >>> Units: seconds >>> >>> >>> 5.11.2. flowIdleTimeout >>> >>> >>> >>> Description: >>> A Flow is considered to be timed out if no packets belonging to >>> the Flow have been observed for the number of seconds specified by >>> this field. >>> Abstract Data Type: unsigned16 >>> ElementId: 37 >>> Status: current >>> Units: seconds >>> >>> >>> 5.11.3. flowEndReason >>> >>> Description: >>> The reason for Flow termination. The range of values includes the >>> following: >>> >>> 0x01: idle timeout >>> The Flow was terminated because it was considered to be >>> idle. >>> >>> 0x02: active timeout >>> The Flow was terminated for reporting purposes while it was >>> still active, for example, after the maximum lifetime of >>> unreported Flows was reached. >>> >>> ... >>> >>> Here is one issue. >>> Some documents refer to inactive timeout >>> RFC5472, >>> ipfixMeteringProcessCacheInactiveTimeout in >>> http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03 >>> inactiveTimeout in >>> http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10 >>> While some others refer to idle timeout >>> RFC 5102, >>> draft-ietf-bmwg-ipflow-meth-09 >>> >>> Any proposal to fix this problem? >>> >>> Regards, Benoit (OPS A.D.) >>> >>> >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------000305070804090504000200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Benoit, all,

No objection, however, given how common the term "inactive timeout" is in the industry that including a note like you suggested is probably worth doing.

-Andrew

On 04/18/2012 06:51 AM, Benoit Claise wrote:
Dear all,

I believe that consistency is important amongst all the IPFIX documents.
What Brian expressed "Given that 5102 predates all other (directly-IPFIX-related) references, and there's an IE in the IANA registry called flowIdleTimeout, I'd tend to go with "idle" for this one." is I believe the right way forward.
And Gerhard mentioned " We could change the name in the MIB and in ipfix-config if consistency is important."

So let me propose the following:
- http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10, in the RFC-editor queue:
    we could still change inactive to idle
- http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03, in the RFC-editor queue
    we could still change inactive to idle
- Editorial errata on RFC5472:
    "inactive" -> "idle"
    Potentially, an extra sentence such as: "note that the idle timeout is sometimes called the inactive timeout in the industry"
- http://www.ietf.org/id/draft-ietf-bmwg-ipflow-meth-09.txt
    replace inactive by idle.

Any objections?

Regards, Benoit.
Hi Benoit,

The parameter was always called inactive timeout in IPFIX MIB. ipfix-config changed from idleTimeout to inactiveTimeout in draft-ietf-ipfix-configuration-model-02 to be consistent with the MIB.

We could change the name in the MIB and in ipfix-config if consistency is important.

Gerhard


On 10.04.2012 13:07, Benoit Claise wrote:
Dear all,

Reading draft-ietf-bmwg-ipflow-meth-09.txt, I realized that this draft defines two new terms: Active Timeout and Inactive Timeout.
I was thinking: surely, we have defined those terms already in some IPFIX RFCs.
Actually, I was unable to find any references.... Have I overlooked something?

The only pointers I could find are in RFC5102

5.11.1.  flowActiveTimeout

   Description:
      The number of seconds after which an active Flow is timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned16
   ElementId: 36
   Status: current
   Units: seconds

5.11.2.  flowIdleTimeout


   Description:
      A Flow is considered to be timed out if no packets belonging to
      the Flow have been observed for the number of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.11.3.  flowEndReason
Description:
      The reason for Flow termination.  The range of values includes the
      following:

      0x01: idle timeout
            The Flow was terminated because it was considered to be
            idle.

      0x02: active timeout
            The Flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported Flows was reached.

      ...
Here is one issue.
Some documents refer to inactive timeout
    RFC5472,
    ipfixMeteringProcessCacheInactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-rfc5815bis-03
    inactiveTimeout in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-10
While some others refer to idle timeout
    RFC 5102,
    draft-ietf-bmwg-ipflow-meth-09

Any proposal to fix this problem?

Regards, Benoit (OPS A.D.)



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix


--------------000305070804090504000200-- From internet-drafts@ietf.org Mon Apr 23 07:38:36 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC4721F8700; Mon, 23 Apr 2012 07:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbgBXVe3MiXM; Mon, 23 Apr 2012 07:38:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1873521F86AF; Mon, 23 Apr 2012 07:38:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120423143835.24238.53213.idtracker@ietfa.amsl.com> Date: Mon, 23 Apr 2012 07:38:35 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-11.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:38:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Gr= oup 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-11.txt Pages : 36 Date : 2012-04-23 Flow selection is the process of selecting a subset of flows from all observed flows. The Flow Selection Process may be located at an observation point, or on an IPFIX Mediator. Flow selection reduces the effort of post-processing flow data and transferring Flow Records. This document describes motivations for flow selection and presents flow selection techniques. It provides an information model for configuring flow selection techniques and discusses what information about a flow selection process should be exported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-11= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-11.= txt From salvatore.dantonio@uniparthenope.it Mon Apr 23 08:17:28 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B93221F86D4 for ; Mon, 23 Apr 2012 08:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.73 X-Spam-Level: X-Spam-Status: No, score=0.73 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUPmEMVxOWIi for ; Mon, 23 Apr 2012 08:17:27 -0700 (PDT) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id 72F5D21F86AA for ; Mon, 23 Apr 2012 08:17:27 -0700 (PDT) Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id ECC51B5B1; Mon, 23 Apr 2012 15:17:25 +0000 (UTC) Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1dfc_6ebffd20_8d57_11e1_a0f7_001372515a5c; Mon, 23 Apr 2012 17:17:25 +0200 Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id D61C3C42EF; Mon, 23 Apr 2012 18:14:54 +0200 (CEST) Received: by spamk.uniparthenope.it (Postfix, from userid 500) id D142DC432D; Mon, 23 Apr 2012 18:14:54 +0200 (CEST) Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by spamk.uniparthenope.it (Postfix) with ESMTP id 9CED1C42EF; Mon, 23 Apr 2012 18:14:42 +0200 (CEST) Received: from saldantoPC (unknown [192.168.162.11]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 8EAD2B7D4; Mon, 23 Apr 2012 17:17:12 +0200 (CEST) From: "Salvatore D'Antonio" To: "'Romascanu, Dan \(Dan\)'" , "'IETF IPFIX Working Group'" References: In-Reply-To: Date: Mon, 23 Apr 2012 17:17:13 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0HgYT2PNNa/4XrS9iDIJxRD2mpEwZ4Hx+g Content-Language: it Message-ID: <000e01cd2164$293ef350$7bbcd9f0$@dantonio@uniparthenope.it> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20120423 #7799414, check: 20120423 clean Subject: [IPFIX] R: AD review of draft-ietf-ipfix-flow-selection-tech-10.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:17:28 -0000 Dear Dan, The new version of the Internet Draft on Flow Selection Techniques has = been published. Answers to yours comments inline. -----Messaggio originale----- Da: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Per conto di Romascanu, Dan (Dan) Inviato: mercoled=EC 21 marzo 2012 17:42 A: IETF IPFIX Working Group Oggetto: [IPFIX] AD review of = draft-ietf-ipfix-flow-selection-tech-10.txt Please find below the AD review of draft-ietf-ipfix-flow-selection-tech-10.txt.=20 The document is in a good enough shape to be sent to IETF LC. Please consider my comments together with the other IETF LC comments.=20 The comments are divided into T (Technical) and E (Editorial).=20 T1. In section 5.1.2:=20 Nevertheless there MAY be the incentive to apply Hash- based Flow Filtering not on the packet level during the Metering Process, for example when the size of the selection range and therefore the sampling probability is dependent on the number of observed flows. I think that the usage of a capitalized RFC 2119 MAY is not justified here.=20 Agreed. MAY has been replaced by may. T2. In section 6.1 please provide references for the hash functions mentioned as possible functions. Done. References for the mentioned hash functions have been added. T3. In section 7:=20 In this section we describe Information Elements (IEs) that SHOULD be exported by a flow selection process in order to support the interpretation of measurement results from flow measurements where only some flows are selected. =20 Why is this a SHOULD and not a MUST? What are the exception cases?=20 Fixed. SHOULD has been replaced with MUST. T4. Also in section 7:=20 All counters SHOULD be exported and reset when a new measurement interval starts. Why is this a SHOULD and not a MUST? What are the exception cases? Are exporting counters and reset of counters independent, in other words can some counters be exported but not reset when a new measurement interval starts?=20 Fixed. SHOULD has been replaced with MUST. T5. Where are allocated all the IDs marked as TBD in the table in Section 7? I do not see a request for allocation in the IANA considerations section. What am I missing? The IDs that were marked as TBD in the table and not mentioned in the = IANA Considerations section have been removed from the table. =20 T6. Even if configuration methods and protocols are out of the scope of this document I believe that this statement in the Security Considerations section is not sufficient:=20 Nevertheless, a full analysis and assessment of threats for configuration and reporting has to be done if configuration or reporting methods are proposed. I think that this document needs at least make a complete assessment of the threats and place requirements in the configuration and reporting methods to be later defined.=20 A new Security Considerations section has been added to the document. E1. Three of the missing references prompted up by idnits seem to be indeed missing references:=20 =3D=3D Missing Reference: 'RFC5226' is mentioned on line 868, but not defined 'administered by IANA and are subject to Expert Review [RFC5226...' Reference to RFC5226 has been added. =3D=3D Missing Reference: 'I-D.dkcm-ipfix-rfc5815bis' is mentioned on = line 1330, but not defined 'according to the procedures set forth in [I-D.dkcm-ipfix-rfc5815b...' Reference to RFC5815 has been added. =3D=3D Missing Reference: 'GoRe07' is mentioned on line 1372, but not defined '[GoRe07]....' Reference [GoRe07] has been updated.=20 E2. Drop the comma from 'The reason is, that flow-state dependent ...' Fixed E3. Section 5.2.1: Systematic sampling MAY BE applied during the Metering Process. BE needs not be capitalized.=20 Fixed. E4. It would be useful to nuumber the Tables in the document like the one in Section 6, for later references in other documents.=20 Done. Best regards, Salvatore Regards, Dan _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix ----- Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 2012.0.1913 / Database dei virus: 2114/4884 - Data di = rilascio: 21/03/2012 From dromasca@avaya.com Tue Apr 24 02:48:12 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1CD21F8773 for ; Tue, 24 Apr 2012 02:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.107 X-Spam-Level: X-Spam-Status: No, score=-102.107 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_00=-2.599, MANGLED_ONLINE=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9z38VWqM2lw for ; Tue, 24 Apr 2012 02:48:11 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id BAA8C21F876F for ; Tue, 24 Apr 2012 02:48:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEF2lk+HCzI1/2dsb2JhbABEsWmBB4IJAQEBAQMBAQEPHhkiAxcEAgEIDQQEAQELBgwLAQYBJh8JCAEBBAESCBqHbQudHZ1SiWeHBGMEiC+DF5BKSolegms X-IronPort-AV: E=Sophos;i="4.75,473,1330923600"; d="scan'208";a="343972183" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Apr 2012 05:47:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Apr 2012 05:31:25 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Apr 2012 11:48:08 +0200 Message-ID: In-Reply-To: <000e01cd2164$293ef350$7bbcd9f0$@dantonio@uniparthenope.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech-10.txt Thread-Index: Ac0HgYT2PNNa/4XrS9iDIJxRD2mpEwZ4Hx+gACdPtTA= References: <000e01cd2164$293ef350$7bbcd9f0$@dantonio@uniparthenope.it> From: "Romascanu, Dan (Dan)" To: "Salvatore D'Antonio" , "IETF IPFIX Working Group" Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech-10.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 09:48:13 -0000 Hi Salvatore, Thank you for addressing the issues raised in my review.=20 Regards, Dan > -----Original Message----- > From: Salvatore D'Antonio [mailto:salvatore.dantonio@uniparthenope.it] > Sent: Monday, April 23, 2012 6:17 PM > To: Romascanu, Dan (Dan); 'IETF IPFIX Working Group' > Subject: R: [IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech- > 10.txt >=20 > Dear Dan, >=20 > The new version of the Internet Draft on Flow Selection Techniques has > been > published. >=20 > Answers to yours comments inline. >=20 > -----Messaggio originale----- > Da: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Per conto = di > Romascanu, Dan (Dan) > Inviato: mercoled=EC 21 marzo 2012 17:42 > A: IETF IPFIX Working Group > Oggetto: [IPFIX] AD review of draft-ietf-ipfix-flow-selection-tech- > 10.txt >=20 > Please find below the AD review of > draft-ietf-ipfix-flow-selection-tech-10.txt. >=20 > The document is in a good enough shape to be sent to IETF LC. Please > consider my comments together with the other IETF LC comments. >=20 > The comments are divided into T (Technical) and E (Editorial). >=20 > T1. In section 5.1.2: >=20 > Nevertheless there MAY be the incentive to apply Hash- > based Flow Filtering not on the packet level during the Metering > Process, for example when the size of the selection range and > therefore the sampling probability is dependent on the number of > observed flows. >=20 > I think that the usage of a capitalized RFC 2119 MAY is not justified > here. >=20 > Agreed. MAY has been replaced by may. >=20 > T2. In section 6.1 please provide references for the hash functions > mentioned as possible functions. >=20 > Done. References for the mentioned hash functions have been added. >=20 > T3. In section 7: >=20 > In this section we describe Information Elements (IEs) that SHOULD > be > exported by a flow selection process in order to support the > interpretation of measurement results from flow measurements where > only some flows are selected. >=20 > Why is this a SHOULD and not a MUST? What are the exception cases? >=20 > Fixed. SHOULD has been replaced with MUST. >=20 > T4. Also in section 7: >=20 > All counters SHOULD be exported and reset when a new > measurement interval starts. >=20 > Why is this a SHOULD and not a MUST? What are the exception cases? Are > exporting counters and reset of counters independent, in other words > can > some counters be exported but not reset when a new measurement = interval > starts? >=20 > Fixed. SHOULD has been replaced with MUST. >=20 > T5. Where are allocated all the IDs marked as TBD in the table in > Section 7? I do not see a request for allocation in the IANA > considerations section. What am I missing? >=20 > The IDs that were marked as TBD in the table and not mentioned in the > IANA > Considerations section have been removed from the table. >=20 > T6. Even if configuration methods and protocols are out of the scope = of > this document I believe that this statement in the Security > Considerations section is not sufficient: >=20 > Nevertheless, a full analysis and assessment of threats for > configuration and reporting has to be done if configuration or > reporting methods are proposed. >=20 > I think that this document needs at least make a complete assessment = of > the threats and place requirements in the configuration and reporting > methods to be later defined. >=20 > A new Security Considerations section has been added to the document. >=20 > E1. Three of the missing references prompted up by idnits seem to be > indeed missing references: >=20 > =3D=3D Missing Reference: 'RFC5226' is mentioned on line 868, but = not > defined > 'administered by IANA and are subject to Expert Review > [RFC5226...' >=20 > Reference to RFC5226 has been added. >=20 > =3D=3D Missing Reference: 'I-D.dkcm-ipfix-rfc5815bis' is mentioned = on > line > 1330, but not defined > 'according to the procedures set forth in > [I-D.dkcm-ipfix-rfc5815b...' >=20 > Reference to RFC5815 has been added. >=20 > =3D=3D Missing Reference: 'GoRe07' is mentioned on line 1372, but = not > defined > '[GoRe07]....' >=20 > Reference [GoRe07] has been updated. >=20 > E2. Drop the comma from 'The reason is, that flow-state dependent ...' >=20 > Fixed >=20 > E3. Section 5.2.1: >=20 > Systematic sampling MAY BE applied during the Metering > Process. >=20 > BE needs not be capitalized. >=20 > Fixed. >=20 > E4. It would be useful to nuumber the Tables in the document like the > one in Section 6, for later references in other documents. >=20 > Done. >=20 > Best regards, >=20 > Salvatore >=20 >=20 >=20 >=20 >=20 > Regards, >=20 > Dan >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > ----- > Nessun virus nel messaggio. > Controllato da AVG - www.avg.com > Versione: 2012.0.1913 / Database dei virus: 2114/4884 - Data di > rilascio: > 21/03/2012 From n.brownlee@auckland.ac.nz Wed Apr 25 09:07:37 2012 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC6321F86D9 for ; Wed, 25 Apr 2012 09:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r52EaqQFhjWO for ; Wed, 25 Apr 2012 09:07:36 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.12.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA6E21F87D2 for ; Wed, 25 Apr 2012 09:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1335370056; x=1366906056; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=IdlLhH6Eg1rJ1hWgEv4+ICEv0C4ThcXOKviL7t2WFIg=; b=Eok8urT9Af8pDcQ6oQQJT7qXy5GUnOqfvLf1XSooULwZzsKtxDqxxoGK BglqRJXTeNTD35wMxwSwjefSdujZgJnS4NsMSnXzEL+mvGU9PG2RD64FD g8Iq94SaN9o2euzL8xMGXEApEMljQlsdqwaLei7hDoAG2g/Cyc/DUlKtn U=; X-IronPort-AV: E=Sophos;i="4.75,481,1330858800"; d="scan'208";a="147849669" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 193.0.10.159 - Outgoing - Outgoing-SSL Received: from guest128.guestnet.ripe.net (HELO [193.0.10.159]) ([193.0.10.159]) by mx1-int.auckland.ac.nz with ESMTP; 26 Apr 2012 04:07:31 +1200 Message-ID: <4F98213F.50607@auckland.ac.nz> Date: Wed, 25 Apr 2012 09:07:27 -0700 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IPFIX list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] WG Last calls for Aggregation and MIB-Doctors drafts X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:07:37 -0000 Hi all: At the IPFIX meeting during IETF-83, we said that two drafts need WGLCs: draft-ietf-ipfix-a9n-03 This is the aggregation draft; it now has two IPR disclosures, so it needs a new WGLC. draft-ietf-ipfix-ie-doctors-02 This is now ready for its WGLC. Please read these drafts, and send reviews and/or comments to the list. If you suggest improvements, please send text! Reviews are, of course, most appreciated - but simple posts saying "I support this" are fine too. These WGLCs start today, and will end on 27 May 2012. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand