From paitken@cisco.com Mon Jul 1 03:03:24 2013 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 520A821F9ED7 for ; Mon, 1 Jul 2013 03:03:24 -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 udXVIay1rNMy for ; Mon, 1 Jul 2013 03:03:18 -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 206FD21F9EE3 for ; Mon, 1 Jul 2013 03:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10951; q=dns/txt; s=iport; t=1372672995; x=1373882595; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0gTgKikNE2HDGSm73/kKD8BEv0NAgpN3x8PHtoVq5MI=; b=f6uVrmbWcUKnfE68CjfjlCvVobHNc2ksJk4vc4DRykOJTTBaHTtt39YB EhEbHE3uJO/Pi39O//GO9M2yH6bvoFI5mODnhFuFQVUdMdFtq3Ko1qAVB hlzm9RlmQE7qhcQHUYoCTueJJj8GocGvR1K8gLDyw/iIC8OI4uiFvd+xc g=; X-IronPort-AV: E=Sophos;i="4.87,973,1363132800"; d="scan'208";a="83820769" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Jul 2013 10:03:10 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r61A38Tg007171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 10:03:08 GMT Received: from [10.61.208.129] ([10.61.208.129]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r61A36bj003091; Mon, 1 Jul 2013 11:03:07 +0100 (BST) Message-ID: <51D153DD.5000606@cisco.com> Date: Mon, 01 Jul 2013 11:03:09 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Trammell References: <51425F53.10203@cisco.com> <51CCAC2B.3060300@cisco.com> <51CCB67D.9070204@cisco.com> <3328C6B8-4BD6-4565-A379-1E2DC2A88455@tik.ee.ethz.ch> In-Reply-To: <3328C6B8-4BD6-4565-A379-1E2DC2A88455@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ipfix-mediation-protocol@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-04 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, 01 Jul 2013 10:03:24 -0000 Brian, replies inline: >>>>> Original Exporter: An Original Exporter is an IPFIX Device that >>>>> hosts the Observation Points where the metered IP packets are >>>>> observed. >>>>> >>>>> Original Observation Point: An Observation Point of the Original >>>>> Exporter. In the case of the Intermediate Aggregation Process on >>>>> >>>> These definitions imply that OPs belong to the exporter, which is not the case; they belong to the MP or to the IPFIX device. >>> Changed to >>> Original Observation Point: An Observation Point on >>> the Original >>> Exporter. In the case of the Intermediate Aggregation Process on >>> >> Looking at the OP and OD definitions in 5101 and 5101bis, I see nothing to suggest that OPs are in any way related to Exporters. > Yes, but from the point of view of a Mediator, the Original Observation Point is defined in terms of its relationship to the Original Exporter, no? So this seems fine. Disagree. If multiple Metering Processes export through a single Exporting Process, a Mediator will only know a single Original Exporter. However, it's important to distinguish that the OPs belong to different original MPs. It's incorrect for a mediator to assume that they're all in a single space simply because they're reported by the same OE. If that wasn't true, we wouldn't have any need for Observation Domain. >>>> So are we saying that OD zero has a special meaning? Should existing exporters avoid using OD zero in order to avoid confusing Collectors? >>> It's already taken care of by RFC5101bis and RFC5101 btw. >>> Observation Domain ID >>> >>> A 32-bit identifier of the Observation Domain that is locally >>> unique to the Exporting Process. The Exporting Process uses the >>> Observation Domain ID to uniquely identify to the Collecting >>> Process the Observation Domain that metered the Flows. It is >>> RECOMMENDED that this identifier also be unique per IPFIX Device. >>> Collecting Processes SHOULD use the Transport Session and the >>> Observation Domain ID field to separate different export streams >>> originating from the same Exporter. >>> The Observation Domain ID >>> SHOULD be 0 when no specific Observation Domain ID is relevant for >>> the entire IPFIX Message, for example, when exporting the >>> Exporting Process Statistics, or in case of a hierarchy of >>> Collectors when aggregated Data Records are exported. >>> >>> Now, the only change is SHOULD -> MUST >> You avoided the second part of the question: Should existing exporters avoid using OD zero in order to avoid confusing Collectors? >> >> I could also ask, "MUST existing exporters avoid using OD zero ..." ? >> >> It's possibly not directly relevant for this draft, but definitely for 5101bis. > What's the suggested change to 5101bis? There's no particular guidance to avoid OD zero in cases where the Message doesn't contain data for multiple source ODs, but IIRC we left this (and indeed, everything we could possibly could about ODs) open, because an OD is kind of an opaque thing up to the implementor, and only touches the protocol in that it scopes templates and options. It's opaque apart from the recently introduced special value, zero. When a mediator or collector sees OD zero, it can't tell whether the export came from a simple device with only one OD, or from a complex device with multiple ODs using the "no specific Observation Domain ID is relevant" rule. >>>>> Claise, et al. Expires August 29, 2013 [Page 22] >>>>> Internet-Draft IPFIX MED-PROTO February 2013 >>>>> >>>>> >>>>> | ignoredRecordTotalCount | The total number of Data Records | >>>>> | | received but not processed by the | >>>>> | | Intermediate Process. | >>>>> | time first record | The timestamp of the first record that | >>>>> | ignored | was ignored by the Intermediate | >>>>> | | Process. For Data Records containing | >>>>> | | timestamp ranges, this SHOULD be taken | >>>>> | | from the start timestamp of the range; | >>>>> | | for data records containing no timing | >>>>> | | information, this SHOULD be taken from | >>>>> | | the Export Time in the message header | >>>>> | | of >>>>> the containing IPFIX Message. For | >>>> Is this the incoming IPFIX Message? So the Intermediate Process has to examine each incoming Message in some detail, even though it's ignoring them? >>> Yes. >> Well that's just daft. So this is a new definition of "ignoring" which actually means "examining them in detail"? Have you considered a career in politics? > Yes, but they won't let me run for anything here until I get my passport. ;) > > And this depends completely on where the bottleneck is. Consider the case where per-record processing is far more expensive than message deframing, in that case, it knows exactly where in the record stream it starts having problems, and can count dropped records because it's operating on a record stream instead of a message stream. It can even keep deframing messages when it knows that it'll have to drop records, because the marginal cost of deframing a message is zero. > > If the problem is keeping up with messages, though, yes, you're right, this doesn't work. See below on the tradition of wild guessing in metameasurement. A wild guess might be the only possibility. My concern is that although an implementation may not wish to export this option because it cannot be accurately or meaningfully measured, it may be obliged to export it for RFC compliance. >>>>> | | this timestamp, any of the following | >>>>> | | timestamp can be used: | >>>>> | | observationTimeSeconds, | >>>>> | | observationTimeMilliseconds, | >>>>> | | observationTimeMicroseconds, or | >>>>> | | observationTimeNanoseconds. | >>>>> | time last record | The timestamp of the last record that | >>>>> | ignored | was ignored by the Intermediate | >>>>> | | Process. For Data Records containing | >>>>> | | timestamp ranges, this SHOULD be taken | >>>>> | | from the end timestamp of the range; | >>>>> | | for data records containing no timing | >>>>> | | information, this SHOULD be taken from | >>>>> | | the Export Time in the message header | >>>>> | | of the containing IPFIX Message. For | >>>>> | | this timestamp, any of the following | >>>>> | | timestamp can be used: | >>>>> | | observationTimeSeconds, | >>>>> | | observationTimeMilliseconds, | >>>>> | | observationTimeMicroseconds, or | >>>>> | | observationTimeNanoseconds. | >>>>> +-------------------------+-----------------------------------------+ >>>>> >>>> Pleaseaddsomewhitespacetomakethetablereadable. >>> I could not find a way to do it... >> Add some blank lines to vertically separate each definition in the table. Else all the definitions run together. >> >> ie, make each definition a visually separate chunk. See http://syque.com/cstyle/ch2.8.htm > cf. previous discussions on xml2rfc hacking -- as you've made this comment before on stock xml2rfc tables I've put into IPFIX documents, it may be more productive if you raise this issue with the xml2rfc people instead. I'd need the source XML. > In the meantime we can certainly crudely hack a dividing line in there. Thanks. >>>>> 10.4. ignoredRecordTotalCount Information Element >>>>> >>>>> Description: The total number of received Data Records that the >>>>> Intermediate Process did not process since the (re-)initialization >>>>> of the Intermediate Process; includes only Data Records not >>>>> examined or otherwise handled by the Intermediate Process due to >>>>> resource constraints, not Data Records which were examined or >>>>> otherwise handled by the Intermediate Process but which merely do >>>>> not contribute to any exported Data Record due to the operations >>>>> performed by the Intermediate Process. >>>>> >>>> If a mediator is resource constrained, how can it accurately report this figure? >>> Like in RFC 5101, section 4.2. The Metering Process Reliability Statistics Option Template >>> >>> ignoredPacketTotalCount >>> The total number of IP packets that the >>> Metering Process did not process. >>> >>> ignoredOctetTotalCount >>> The total number of octets in observed IP >>> packets that the Metering Process did not >>> process. >>> >> Sorry, I asked the wrong question. If a mediator is resource constrained, how can it accurately measure this figure? >> >> It's a similar point to "time first record ignored" above. > It can't accurately measure it at all. But that's not the point. > > This is simply an instance of the apparent custom in measurement equipment, all the way up and down the stack, to try to estimate dropped/missing packets/messages/events. Some of the estimates (dropped packet counting in hardware capture) are close enough to accurate that you can use them for debug purposes, if not accounting purposes. Some of them are utter garbage. The quality of the guess is implementation and situation dependent. These counters are provided for consistency in line with this tradition: it's the same situation as with reliability statistics reported by MPs and EPs in 5101(bis), of which I'm also (as a user of data) deeply, deeply skeptical. But one can argue that a low-quality, well-intentioned guess is better than nothing. That's exactly what I'm arguing. Provide an opt-out for the case that an implementer knows that this metric will be poor to meaningless, or impossible to implement. P. From paitken@cisco.com Mon Jul 1 03:34:00 2013 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 BFAC321F941D for ; Mon, 1 Jul 2013 03:34:00 -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 nJ2-zWfW1UIZ for ; Mon, 1 Jul 2013 03:33:54 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id CA81621F91B4 for ; Mon, 1 Jul 2013 03:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11097; q=dns/txt; s=iport; t=1372674834; x=1373884434; h=message-id:date:from:mime-version:to:cc:subject; bh=n+VI0mV+QcxVgK56c2J1MDQyAP1NbYgqxb6lLUN78CM=; b=e7nWOEAw1SNYEwHXThY8vE/y67iXmdffI8HDfvrOatUW0jQhhdj/SJEz tiFkSZy3MgWP01hE3iLt7wO0JVMs0xQya/MYLLj3m4268wC2ky9iJ8jza mgSQGp0Agx7a+lrqfQ9e6zA9ar3bOZazXbvrJlRoq5OhnZZyKOPEj95Ft 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAFS6zFGQ/khR/2dsb2JhbABbgwkyiSy2KIECFnSCIwEBAQN5AQUJLhYYAwIBAgEJTwEFAgEBiAQGu0oEjg+BFiyDbAOTc4NShiGLJIMSgXA X-IronPort-AV: E=Sophos;i="4.87,973,1363132800"; d="scan'208,217";a="14700362" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 01 Jul 2013 10:33:51 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r61AXnWC010590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 10:33:49 GMT Received: from [10.61.208.129] ([10.61.208.129]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r61AXmp6005319; Mon, 1 Jul 2013 11:33:48 +0100 (BST) Message-ID: <51D15B0E.1080701@cisco.com> Date: Mon, 01 Jul 2013 11:33:50 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: draft-ietf-ipfix-mediation-protocol@tools.ietf.org Content-Type: multipart/alternative; boundary="------------090204020009090608040004" Cc: IETF IPFIX Working Group Subject: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-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: Mon, 01 Jul 2013 10:34:00 -0000 This is a multi-part message in MIME format. --------------090204020009090608040004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here's a review of draft-ietf-ipfix-mediation-protocol-05. The comments are all editorial. > However, thanks to its Template mechanism, the IPFIX protocol can > export any type of information, as long as the relevant Information > Element is specified in the IPFIX Information Model > [I-D.ietf-ipfix-information-model-rfc5102bis], registered with IANA, > or specified as an enterprise-specific Information Element. The > specifications in the IPFIX protocol > [I-D.ietf-ipfix-protocol-rfc5101bis] have not been defined in the > context of an IPFIX Mediator receiving, aggregating, correlating, > anonymizing, etc... Flow Records fromthe one or multiple Exporters. Say, "from one or more Exporters". > IPFIX has a formal description of IPFIX Information Elements, their > name, type and additional semantic information, as specified in the > IPFIX Information Model > [I-D.ietf-ipfix-information-model-rfc5102bis]. The IPFIX Information > Element registry [iana-ipfix-assignments]registry is maintained by Remove the second "registry". > Figure 3: Template Mapping example: templates > > The Template Mapping corresponding tofigure 3 is displayed infigure > 4: Capitalise "Figure 3" and "Figure 4" for consistency. Can you prevent the line break in "Figure 4" ? > Figure 4: Template Mapping example: mappings > > Alternatively, the Template Mapping may be optimized as infigure 5: Capitalise "Figure 5" for consistency. > 4.1.1. Template Mapping and Information Element Ordering > > In the situation where Original Exporters each export an (Options) > Template to a single IPFIX Mediator, and the (Options) Template > Record contains the same Information Elements but in different order, > should the IPFIX Mediator maintain a Template Mapping with a single > Export Template Record (seefigure 6) or should the IPFIX Mediator > maintain multiple independent Template Records (seefigure 7) before > re-exporting to the Collector? Capitalise "Figure 6" and "Figure 7" for consistency. > o Any combination or list of Information Elements representing > Observation Points. For example: > o Remove the additional bullet point. > Any combination of the above representations is possible. An example > of an Original Observation Point for an Intermediate Aggregation > Process is displayed infigure 8. Capitalise "Figure 8" for consistency. > The most generic way to export the Original Observation Point is to > use a subTemplateMultiList, with the semantic "exactlyOneOf". Taking > the previous example, the encoding infigure 9 can be used. Capitalise "Figure 9" for consistency. > Analogous to the Metering Process Reliability Statistics Options > Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis], > Mediators SHOULD implement the Intermediate Process Reliability > Statistics Options Template, specified inthe Section 10.1. Remove "the". > 10.1. Intermediate Process Reliability Statistics Template Name this "... Option Template" since it contains scope IEs, and for consistency with 10.2. > 13. IANA Considerations > > This document specifies new IPFIX Information Elements, > originalExporterIPv4Address in Section 5.1, > originalExporterIPv6Address in Section 5.2, > originalObservationDomainId in Section 6.1, intermediateProcessId in > Section 10.3, and ignoredFlowRecordTotalCount in Section 10.4, to be > added to the IPFIX Information Element registry > [iana-ipfix-assignments]. [IANA NOTE: please add the five > Information Elements as specified in the references subsections, > change TBD1, TBD2, TBD3, TBD4, and TBD5 in this document to reflect > the assigned identifiers, put the Status as current, insert THISRFC > into theReuquester entry, insert 0 for the Revision, and use the > current date for Date.] Typo, "Requester". > Atsushi Kobayashi > NTT Information Sharing Platform Laboratories > 3-9-11 Midori-cho > Musashino-shi, Tokyo 180-8585 > Japan > > Phone: +81 422 59 3978 > Email: akoba@nttv6.net Check whether this is still correct. P. --------------090204020009090608040004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here's a review of draft-ietf-ipfix-mediation-protocol-05.

The comments are all editorial.



   However, thanks to its Template mechanism, the IPFIX protocol can
   export any type of information, as long as the relevant Information
   Element is specified in the IPFIX Information Model
   [I-D.ietf-ipfix-information-model-rfc5102bis], registered with IANA,
   or specified as an enterprise-specific Information Element.  The
   specifications in the IPFIX protocol
   [I-D.ietf-ipfix-protocol-rfc5101bis] have not been defined in the
   context of an IPFIX Mediator receiving, aggregating, correlating,
   anonymizing, etc... Flow Records from the one or multiple Exporters.

Say, "from one or more Exporters".


   IPFIX has a formal description of IPFIX Information Elements, their
   name, type and additional semantic information, as specified in the
   IPFIX Information Model
   [I-D.ietf-ipfix-information-model-rfc5102bis].  The IPFIX Information
   Element registry [iana-ipfix-assignments] registry is maintained by

Remove the second "registry".


               Figure 3: Template Mapping example: templates

   The Template Mapping corresponding to figure 3 is displayed in figure
   4:

Capitalise "Figure 3" and "Figure 4" for consistency.

Can you prevent the line break in "Figure 4" ?


               Figure 4: Template Mapping example: mappings

   Alternatively, the Template Mapping may be optimized as in figure 5:

Capitalise "Figure 5" for consistency.


4.1.1.  Template Mapping and Information Element Ordering

   In the situation where Original Exporters each export an (Options)
   Template to a single IPFIX Mediator, and the (Options) Template
   Record contains the same Information Elements but in different order,
   should the IPFIX Mediator maintain a Template Mapping with a single
   Export Template Record (see figure 6) or should the IPFIX Mediator
   maintain multiple independent Template Records (see figure 7) before
   re-exporting to the Collector?

Capitalise "Figure 6" and "Figure 7" for consistency.


   o  Any combination or list of Information Elements representing
      Observation Points.  For example:
   o

Remove the additional bullet point.


   Any combination of the above representations is possible.  An example
   of an Original Observation Point for an Intermediate Aggregation
   Process is displayed in figure 8.

Capitalise "Figure 8" for consistency.


   The most generic way to export the Original Observation Point is to
   use a subTemplateMultiList, with the semantic "exactlyOneOf".  Taking
   the previous example, the encoding in figure 9 can be used.

Capitalise "Figure 9" for consistency.


   Analogous to the Metering Process Reliability Statistics Options
   Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis],
   Mediators SHOULD implement the Intermediate Process Reliability
   Statistics Options Template, specified in the Section 10.1.

Remove "the".


10.1.  Intermediate Process Reliability Statistics Template

Name this "... Option Template" since it contains scope IEs, and for consistency with 10.2.



13.  IANA Considerations

   This document specifies new IPFIX Information Elements,
   originalExporterIPv4Address in Section 5.1,
   originalExporterIPv6Address in Section 5.2,
   originalObservationDomainId in Section 6.1, intermediateProcessId in
   Section 10.3, and ignoredFlowRecordTotalCount in Section 10.4, to be
   added to the IPFIX Information Element registry
   [iana-ipfix-assignments].  [IANA NOTE: please add the five
   Information Elements as specified in the references subsections,
   change TBD1, TBD2, TBD3, TBD4, and TBD5 in this document to reflect
   the assigned identifiers, put the Status as current, insert THISRFC
   into the Reuquester entry, insert 0 for the Revision, and use the
   current date for Date.]

Typo, "Requester".


   Atsushi Kobayashi
   NTT Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585
   Japan

   Phone: +81 422 59 3978
   Email: akoba@nttv6.net

Check whether this is still correct.


P.
--------------090204020009090608040004-- From trammell@tik.ee.ethz.ch Mon Jul 1 03:51:17 2013 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 2829821F9CE2 for ; Mon, 1 Jul 2013 03:51:17 -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 Bf3Su4vh2xng for ; Mon, 1 Jul 2013 03:51:05 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6A921F9C17 for ; Mon, 1 Jul 2013 03:51:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8E4C4D9307; Mon, 1 Jul 2013 12:51:04 +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 DroqwbqOUuxx; Mon, 1 Jul 2013 12:51:04 +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 52FD5D9305; Mon, 1 Jul 2013 12:51:04 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <51D153DD.5000606@cisco.com> Date: Mon, 1 Jul 2013 12:51:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7121793B-432D-4551-A87E-32DBD60465BB@tik.ee.ethz.ch> References: <51425F53.10203@cisco.com> <51CCAC2B.3060300@cisco.com> <51CCB67D.9070204@cisco.com> <3328C6B8-4BD6-4565-A379-1E2DC2A88455@tik.ee.ethz.ch> <51D153DD.5000606@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-ipfix-mediation-protocol@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-04 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, 01 Jul 2013 10:51:17 -0000 On 1 Jul 2013, at 12:03 , Paul Aitken wrote: > Brian, replies inline: >=20 >>>>>> Original Exporter: An Original Exporter is an IPFIX Device = that >>>>>> hosts the Observation Points where the metered IP packets = are >>>>>> observed. >>>>>>=20 >>>>>> Original Observation Point: An Observation Point of the = Original >>>>>> Exporter. In the case of the Intermediate Aggregation = Process on >>>>>>=20 >>>>> These definitions imply that OPs belong to the exporter, which is = not the case; they belong to the MP or to the IPFIX device. >>>> Changed to >>>> Original Observation Point: An Observation Point on >>>> the Original >>>> Exporter. In the case of the Intermediate Aggregation = Process on >>>>=20 >>> Looking at the OP and OD definitions in 5101 and 5101bis, I see = nothing to suggest that OPs are in any way related to Exporters. >> Yes, but from the point of view of a Mediator, the Original = Observation Point is defined in terms of its relationship to the = Original Exporter, no? So this seems fine. >=20 > Disagree. If multiple Metering Processes export through a single = Exporting Process, a Mediator will only know a single Original Exporter. = However, it's important to distinguish that the OPs belong to different = original MPs. It's incorrect for a mediator to assume that they're all = in a single space simply because they're reported by the same OE. If = that wasn't true, we wouldn't have any need for Observation Domain. Okay, so the concrete terminological suggestion you're making is... NEW: Original Observation Point: An Observation Point on a Metering=20 Process associated with the Original Exporter... correct? >>>>> So are we saying that OD zero has a special meaning? Should = existing exporters avoid using OD zero in order to avoid confusing = Collectors? >>>> It's already taken care of by RFC5101bis and RFC5101 btw. >>>> Observation Domain ID >>>>=20 >>>> A 32-bit identifier of the Observation Domain that is locally >>>> unique to the Exporting Process. The Exporting Process uses = the >>>> Observation Domain ID to uniquely identify to the Collecting >>>> Process the Observation Domain that metered the Flows. It is >>>> RECOMMENDED that this identifier also be unique per IPFIX = Device. >>>> Collecting Processes SHOULD use the Transport Session and the >>>> Observation Domain ID field to separate different export = streams >>>> originating from the same Exporter. >>>> The Observation Domain ID >>>> SHOULD be 0 when no specific Observation Domain ID is = relevant for >>>> the entire IPFIX Message, for example, when exporting the >>>> Exporting Process Statistics, or in case of a hierarchy of >>>> Collectors when aggregated Data Records are exported. >>>>=20 >>>> Now, the only change is SHOULD -> MUST >>> You avoided the second part of the question: Should existing = exporters avoid using OD zero in order to avoid confusing Collectors? >>>=20 >>> I could also ask, "MUST existing exporters avoid using OD zero ..." = ? >>>=20 >>> It's possibly not directly relevant for this draft, but definitely = for 5101bis. >> What's the suggested change to 5101bis? There's no particular = guidance to avoid OD zero in cases where the Message doesn't contain = data for multiple source ODs, but IIRC we left this (and indeed, = everything we could possibly could about ODs) open, because an OD is = kind of an opaque thing up to the implementor, and only touches the = protocol in that it scopes templates and options. >=20 > It's opaque apart from the recently introduced special value, zero. (Where "recent" is "January 2008", with the publication of RFC 5101 = (Section 3.1 "Message Header Format", description "Observation Domain = ID", bottom of page 12).) > When a mediator or collector sees OD zero, it can't tell whether the = export came from a simple device with only one OD, or from a complex = device with multiple ODs using the "no specific Observation Domain ID is = relevant" rule. I don't see the problem here. Why would a CP/mediator need to know = something about the OD that the EP didn't export? =46rom the standpoint = of the protocol, OD 0 isn't really special -- it's a template and = options scope as any other OD, with an added note that the CP should = make no assumptions about the uniqueness of flows across records. Any = other OD specific behavior is (1) interoperability-irrelevant and (2) = implementation-specific. >>>>>> Claise, et al. Expires August 29, 2013 = [Page 22] >>>>>> Internet-Draft IPFIX MED-PROTO = February 2013 >>>>>>=20 >>>>>>=20 >>>>>> | ignoredRecordTotalCount | The total number of Data Records = | >>>>>> | | received but not processed by the = | >>>>>> | | Intermediate Process. = | >>>>>> | time first record | The timestamp of the first record = that | >>>>>> | ignored | was ignored by the Intermediate = | >>>>>> | | Process. For Data Records = containing | >>>>>> | | timestamp ranges, this SHOULD be = taken | >>>>>> | | from the start timestamp of the = range; | >>>>>> | | for data records containing no = timing | >>>>>> | | information, this SHOULD be taken = from | >>>>>> | | the Export Time in the message = header | >>>>>> | | of >>>>>> the containing IPFIX Message. For | >>>>> Is this the incoming IPFIX Message? So the Intermediate Process = has to examine each incoming Message in some detail, even though it's = ignoring them? >>>> Yes. >>> Well that's just daft. So this is a new definition of "ignoring" = which actually means "examining them in detail"? Have you considered a = career in politics? >> Yes, but they won't let me run for anything here until I get my = passport. ;) >>=20 >> And this depends completely on where the bottleneck is. Consider the = case where per-record processing is far more expensive than message = deframing, in that case, it knows exactly where in the record stream it = starts having problems, and can count dropped records because it's = operating on a record stream instead of a message stream. It can even = keep deframing messages when it knows that it'll have to drop records, = because the marginal cost of deframing a message is zero. >>=20 >> If the problem is keeping up with messages, though, yes, you're = right, this doesn't work. See below on the tradition of wild guessing in = metameasurement. >=20 > A wild guess might be the only possibility. >=20 > My concern is that although an implementation may not wish to export = this option because it cannot be accurately or meaningfully measured, it = may be obliged to export it for RFC compliance. Good point. There's 2119 creep here: the reliability records specified = in RFC5101 and 5101bis are a MAY, in medproto they're a SHOULD. I = suggest the fix here is to downgrade the requirement in section 10 of = medproto to MAY: NEW: IPFIX provides Options Templates for the reporting the reliability of processes within the IPFIX Architecture. As each Mediator includes at least one IPFIX Exporting Process, they MAY use the Exporting Process Reliability Statistics Options Template, as specified in [I-D.ietf-ipfix-protocol-rfc5101bis]. Analogous to the Metering Process Reliability Statistics Options Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis], Mediators MAY implement the Intermediate Process Reliability Statistics Options Template, specified in the Section 10.1. The Flow Keys Options Template, as specified in [I-D.ietf-ipfix-protocol-rfc5101bis], may require special handling at an IPFIX Mediator as described in Section 10.2. >>>>>> 10.4. ignoredRecordTotalCount Information Element >>>>>>=20 >>>>>> Description: The total number of received Data Records that = the >>>>>> Intermediate Process did not process since the = (re-)initialization >>>>>> of the Intermediate Process; includes only Data Records not >>>>>> examined or otherwise handled by the Intermediate Process = due to >>>>>> resource constraints, not Data Records which were examined = or >>>>>> otherwise handled by the Intermediate Process but which = merely do >>>>>> not contribute to any exported Data Record due to the = operations >>>>>> performed by the Intermediate Process. >>>>>>=20 >>>>> If a mediator is resource constrained, how can it accurately = report this figure? >>>> Like in RFC 5101, section 4.2. The Metering Process Reliability = Statistics Option Template >>>>=20 >>>> ignoredPacketTotalCount >>>> The total number of IP packets that the >>>> Metering Process did not process. >>>>=20 >>>> ignoredOctetTotalCount >>>> The total number of octets in observed = IP >>>> packets that the Metering Process did = not >>>> process. >>>>=20 >>> Sorry, I asked the wrong question. If a mediator is resource = constrained, how can it accurately measure this figure? >>>=20 >>> It's a similar point to "time first record ignored" above. >> It can't accurately measure it at all. But that's not the point. >>=20 >> This is simply an instance of the apparent custom in measurement = equipment, all the way up and down the stack, to try to estimate = dropped/missing packets/messages/events. Some of the estimates (dropped = packet counting in hardware capture) are close enough to accurate that = you can use them for debug purposes, if not accounting purposes. Some of = them are utter garbage. The quality of the guess is implementation and = situation dependent. These counters are provided for consistency in line = with this tradition: it's the same situation as with reliability = statistics reported by MPs and EPs in 5101(bis), of which I'm also (as a = user of data) deeply, deeply skeptical. But one can argue that a = low-quality, well-intentioned guess is better than nothing. >=20 > That's exactly what I'm arguing. Provide an opt-out for the case that = an implementer knows that this metric will be poor to meaningless, or = impossible to implement. Okay, got it, and I agree. As above, MAY language would provide this = opt-out. Cheers, Brian= From paitken@cisco.com Mon Jul 1 06:16:19 2013 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 45E5711E83B8 for ; Mon, 1 Jul 2013 06:16:19 -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 vRVv8Fi-ZGn4 for ; Mon, 1 Jul 2013 06:16:13 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id BD5F211E8426 for ; Mon, 1 Jul 2013 06:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3471; q=dns/txt; s=iport; t=1372684139; x=1373893739; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zkrhWcQXF55PEHxuIbiUQlXCjDUx1l9lQyPkfb8WKQ8=; b=KpqvP43FKY0Eg6Yox9ZtljN7ga22+U8J2KNCgHv3MvSiTumR9BLqqFh2 0SUzB4c/XlwVsFoJyVc+UJ49wVVb4CQk8NAgCkOHdu9eFiD2rZsqG23WE JtvYGNpK6wHOSmaw5QF0KpHjwKI8/v4UFmxiCZcsvlzmRHqNgT/Dnjvii c=; X-IronPort-AV: E=Sophos;i="4.87,974,1363132800"; d="scan'208";a="14705518" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 01 Jul 2013 13:08:40 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r61D8c8E027915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Jul 2013 13:08:38 GMT Received: from [10.61.210.76] ([10.61.210.76]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r61D8aiO014122; Mon, 1 Jul 2013 14:08:37 +0100 (BST) Message-ID: <51D17F54.9020807@cisco.com> Date: Mon, 01 Jul 2013 14:08:36 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Trammell References: <51425F53.10203@cisco.com> <51CCAC2B.3060300@cisco.com> <51CCB67D.9070204@cisco.com> <3328C6B8-4BD6-4565-A379-1E2DC2A88455@tik.ee.ethz.ch> <51D153DD.5000606@cisco.com> <7121793B-432D-4551-A87E-32DBD60465BB@tik.ee.ethz.ch> In-Reply-To: <7121793B-432D-4551-A87E-32DBD60465BB@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ipfix-mediation-protocol@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-04 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, 01 Jul 2013 13:16:19 -0000 Brian, > Okay, so the concrete terminological suggestion you're making is... > > NEW: > Original Observation Point: An Observation Point on a Metering > Process associated with the Original Exporter... > > correct? That helps. >> >> It's opaque apart from the recently introduced special value, zero. > (Where "recent" is "January 2008", with the publication of RFC 5101 (Section 3.1 "Message Header Format", description "Observation Domain ID", bottom of page 12).) 2008 wasn't so long ago? The problem with these RFCs is that they make statements without making any implication about the opposite. eg, the text in question says: The Observation Domain ID SHOULD be 0 when no specific Observation Domain ID is relevant for the entire IPFIX Message, for example, when exporting the Exporting Process Statistics, or in case of a hierarchy of Collectors when aggregated Data Records are exported. Normally this would imply that an OD of zero indicates that no specific Observation Domain ID is relevant. However I've come to realise that it's incorrect to draw this conclusion because the text doesn't explicitly say that. >> When a mediator or collector sees OD zero, it can't tell whether the export came from a simple device with only one OD, or from a complex device with multiple ODs using the "no specific Observation Domain ID is relevant" rule. > I don't see the problem here. Why would a CP/mediator need to know something about the OD that the EP didn't export? From the standpoint of the protocol, OD 0 isn't really special -- it's a template and options scope as any other OD, with an added note that the CP should make no assumptions about the uniqueness of flows across records. Any other OD specific behavior is (1) interoperability-irrelevant and (2) implementation-specific. You're not concerned about it. I'll let it go. >> My concern is that although an implementation may not wish to export this option because it cannot be accurately or meaningfully measured, it may be obliged to export it for RFC compliance. > Good point. There's 2119 creep here: the reliability records specified in RFC5101 and 5101bis are a MAY, in medproto they're a SHOULD. I suggest the fix here is to downgrade the requirement in section 10 of medproto to MAY: > > NEW: > > IPFIX provides Options Templates for the reporting the reliability of > processes within the IPFIX Architecture. As each Mediator includes > at least one IPFIX Exporting Process, they MAY use the Exporting > Process Reliability Statistics Options Template, as specified in > [I-D.ietf-ipfix-protocol-rfc5101bis]. > > Analogous to the Metering Process Reliability Statistics Options > Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis], > Mediators MAY implement the Intermediate Process Reliability > Statistics Options Template, specified in the Section 10.1. > > The Flow Keys Options Template, as specified in > [I-D.ietf-ipfix-protocol-rfc5101bis], may require special handling at > an IPFIX Mediator as described in Section 10.2. Great. >> That's exactly what I'm arguing. Provide an opt-out for the case that an implementer knows that this metric will be poor to meaningless, or impossible to implement. > Okay, got it, and I agree. As above, MAY language would provide this opt-out. Thanks, P. From internet-drafts@ietf.org Tue Jul 2 15:44:59 2013 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 71DCF21F955A; Tue, 2 Jul 2013 15:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 SNIcGU1lI0mZ; Tue, 2 Jul 2013 15:44:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E540521F92E3; Tue, 2 Jul 2013 15:44:58 -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.51.p2 Message-ID: <20130702224458.19565.45122.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 15:44:58 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-03.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, 02 Jul 2013 22:45:00 -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 Group = of the IETF. Title : Information Elements for Data Link Layer Traffic Measure= ment Author(s) : Shingo Kashima Atsushi Kobayashi Paul Aitken Filename : draft-ietf-ipfix-data-link-layer-monitoring-03.txt Pages : 30 Date : 2013-07-02 Abstract: This document describes Information Elements related to data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-data-link-layer-monitor= ing-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From akoba@orange.plala.or.jp Tue Jul 2 16:18:34 2013 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 B8EE511E80E4 for ; Tue, 2 Jul 2013 16:18:34 -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=[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 eyyNrFZ8MF+w for ; Tue, 2 Jul 2013 16:18:28 -0700 (PDT) Received: from msa02b.plala.or.jp (msa02.plala.or.jp [IPv6:2400:7800:0:5010::2]) by ietfa.amsl.com (Postfix) with ESMTP id E7C8321F9A5F for ; Tue, 2 Jul 2013 16:18:26 -0700 (PDT) Received: from [192.168.1.12] (really [114.181.166.44]) by msa02b.plala.or.jp with SMTP id <20130702231819.PYSZ27867.msa02b.plala.or.jp@[192.168.1.12]> for ; Wed, 3 Jul 2013 08:18:19 +0900 Date: Wed, 03 Jul 2013 08:18:19 +0900 From: ATSUSHI KOBAYASHI To: ipfix@ietf.org In-Reply-To: <20130702224458.19565.45122.idtracker@ietfa.amsl.com> References: <20130702224458.19565.45122.idtracker@ietfa.amsl.com> Message-Id: <20130703081819.4F5D.C996B02F@orange.plala.or.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.65.02 [ja] X-VirusScan: Outbound; msa02b; Wed, 3 Jul 2013 08:18:19 +0900 Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-03.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, 02 Jul 2013 23:18:34 -0000 Hi all, I submitted the newest version of IEs of link layer. I improved it based on the following comments. http://www.ietf.org/mail-archive/web/ipfix/current/msg06799.html http://www.ietf.org/mail-archive/web/ipfix/current/msg06800.html http://www.ietf.org/mail-archive/web/ipfix/current/msg06801.html Could you please review it, and then let me know your comments. Regards, Atsushi On Tue, 02 Jul 2013 15:44:58 -0700 internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > Title : Information Elements for Data Link Layer Traffic Measurement > Author(s) : Shingo Kashima > Atsushi Kobayashi > Paul Aitken > Filename : draft-ietf-ipfix-data-link-layer-monitoring-03.txt > Pages : 30 > Date : 2013-07-02 > > Abstract: > This document describes Information Elements related to data link > layer. They are used by the IP Flow Information Export (IPFIX) > protocol for encoding measured data link layer traffic information. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-data-link-layer-monitoring-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- KOBAYASHI ATSUSHI From Quittek@neclab.eu Thu Jul 4 01:17:12 2013 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 CA64721F9F67 for ; Thu, 4 Jul 2013 01:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 uMoq3mnC0ArE for ; Thu, 4 Jul 2013 01:17:06 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4540421F9F5F for ; Thu, 4 Jul 2013 01:16:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 89FD7104959 for ; Thu, 4 Jul 2013 10:16:10 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKZbONth7dGQ for ; Thu, 4 Jul 2013 10:16:10 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 6A9A5104958 for ; Thu, 4 Jul 2013 10:16:05 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.234]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 4 Jul 2013 10:15:59 +0200 From: Juergen Quittek To: 'IETF IPFIX Working Group' Thread-Topic: WG last call on draft-ietf-ipfix-mediation-protocol-05 Thread-Index: Ac54jpPdnIzVTfRPTC6oPk4pJPnPbw== Date: Thu, 4 Jul 2013 08:15:01 +0000 Message-ID: <9AB93E4127C26F4BA7829DEFDCE5A6E85A34BF8B@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPFIX] WG last call on draft-ietf-ipfix-mediation-protocol-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: Thu, 04 Jul 2013 08:17:12 -0000 Dear all, This is the working group last call on draft-ietf-ipfix-mediation-protocol-05. The call starts today and will last until Sunday July 21. A URL for this Internet-Draft is: http://www.ietf.org/id/draft-ietf-ipfix-mediation-protocol-05.txt We already received (mainly editorial) comments=20 on this version of the draft on the IPFIX mailing list.=20 Thanks to the reviewers! We will consider your=20 comments as input to this WG last call. =20 Please read the draft. Please send your comments to this mailing list. Please also send a message if you are fine with the draft as it is. Thank you, Juergen From trammell@tik.ee.ethz.ch Thu Jul 4 08:48:16 2013 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 A6C0621F9958 for ; Thu, 4 Jul 2013 08:48:16 -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 JoUD2nkbib5e for ; Thu, 4 Jul 2013 08:48:10 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4511E812E for ; Thu, 4 Jul 2013 08:48:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 313CAD94B9; Thu, 4 Jul 2013 17:48:07 +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 SQI+kwoTV7jq; Thu, 4 Jul 2013 17:48:06 +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 DFC25D94B5; Thu, 4 Jul 2013 17:48:06 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <51D15B0E.1080701@cisco.com> Date: Thu, 4 Jul 2013 17:48:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <34E01E68-6B48-48B5-9F93-AEB893F7D2E8@tik.ee.ethz.ch> References: <51D15B0E.1080701@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-ipfix-mediation-protocol@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-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: Thu, 04 Jul 2013 15:48:16 -0000 hi Paul, Many thanks for the review; these have all been applied to the working = copy of revision -06, which will be published post-WGLC. Cheers, Brian On 1 Jul 2013, at 12:33 , Paul Aitken wrote: > Here's a review of draft-ietf-ipfix-mediation-protocol-05. >=20 > The comments are all editorial. >=20 >=20 >=20 >> However, thanks to its Template mechanism, the IPFIX protocol can >> export any type of information, as long as the relevant = Information >> Element is specified in the IPFIX Information Model >> [I-D.ietf-ipfix-information-model-rfc5102bis], registered with = IANA, >> or specified as an enterprise-specific Information Element. The >> specifications in the IPFIX protocol >> [I-D.ietf-ipfix-protocol-rfc5101bis] have not been defined in the >> context of an IPFIX Mediator receiving, aggregating, correlating, >> anonymizing, etc... Flow Records from=20 >> the one or multiple Exporters. >=20 > Say, "from one or more Exporters". >=20 >=20 >> IPFIX has a formal description of IPFIX Information Elements, = their >> name, type and additional semantic information, as specified in = the >> IPFIX Information Model >> [I-D.ietf-ipfix-information-model-rfc5102bis]. The IPFIX = Information >> Element registry [iana-ipfix-assignments]=20 >> registry is maintained by >=20 > Remove the second "registry". >=20 >=20 >> Figure 3: Template Mapping example: templates >>=20 >> The Template Mapping corresponding to=20 >> figure 3 is displayed in=20 >> figure >> 4 >> : >=20 > Capitalise "Figure 3" and "Figure 4" for consistency. >=20 > Can you prevent the line break in "Figure 4" ? >=20 >=20 >> Figure 4: Template Mapping example: mappings >>=20 >> Alternatively, the Template Mapping may be optimized as in=20 >> figure 5: >=20 > Capitalise "Figure 5" for consistency. >=20 >=20 >> 4.1.1. Template Mapping and Information Element Ordering >>=20 >> In the situation where Original Exporters each export an (Options) >> Template to a single IPFIX Mediator, and the (Options) Template >> Record contains the same Information Elements but in different = order, >> should the IPFIX Mediator maintain a Template Mapping with a = single >> Export Template Record (see=20 >> figure 6 >> ) or should the IPFIX Mediator >> maintain multiple independent Template Records (see=20 >> figure 7 >> ) before >> re-exporting to the Collector? >>=20 >=20 > Capitalise "Figure 6" and "Figure 7" for consistency. >=20 >=20 >> o Any combination or list of Information Elements representing >> Observation Points. For example: >> o >>=20 >=20 > Remove the additional bullet point. >=20 >=20 >> Any combination of the above representations is possible. An = example >> of an Original Observation Point for an Intermediate Aggregation >> Process is displayed in=20 >> figure 8. >=20 > Capitalise "Figure 8" for consistency. >=20 >=20 >> The most generic way to export the Original Observation Point is = to >> use a subTemplateMultiList, with the semantic "exactlyOneOf". = Taking >> the previous example, the encoding in=20 >> figure 9 can be used. >=20 > Capitalise "Figure 9" for consistency. >=20 >=20 >> Analogous to the Metering Process Reliability Statistics Options >> Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis], >> Mediators SHOULD implement the Intermediate Process Reliability >> Statistics Options Template, specified in=20 >> the Section 10.1. >=20 > Remove "the". >=20 >=20 >> 10.1. Intermediate Process Reliability Statistics Template >=20 > Name this "... Option Template" since it contains scope IEs, and for = consistency with 10.2. >=20 >=20 >=20 >> 13. IANA Considerations >>=20 >> This document specifies new IPFIX Information Elements, >> originalExporterIPv4Address in Section 5.1, >> originalExporterIPv6Address in Section 5.2, >> originalObservationDomainId in Section 6.1, intermediateProcessId = in >> Section 10.3, and ignoredFlowRecordTotalCount in Section 10.4, to = be >> added to the IPFIX Information Element registry >> [iana-ipfix-assignments]. [IANA NOTE: please add the five >> Information Elements as specified in the references subsections, >> change TBD1, TBD2, TBD3, TBD4, and TBD5 in this document to = reflect >> the assigned identifiers, put the Status as current, insert = THISRFC >> into the=20 >> Reuquester >> entry, insert 0 for the Revision, and use the >> current date for Date.] >>=20 >=20 > Typo, "Requester". >=20 >=20 >> Atsushi Kobayashi >>=20 >> NTT Information Sharing Platform Laboratories >> 3-9-11 Midori-cho >> Musashino-shi, Tokyo 180-8585 >> Japan >>=20 >> Phone: +81 422 59 3978 >>=20 >> Email:=20 >> akoba@nttv6.net >=20 > Check whether this is still correct. >=20 >=20 > P. From trammell@tik.ee.ethz.ch Thu Jul 4 08:49:57 2013 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 92A5721F9644 for ; Thu, 4 Jul 2013 08:49:55 -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 bw9XnfP7mXM6 for ; Thu, 4 Jul 2013 08:49:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AF80A21F9CD7 for ; Thu, 4 Jul 2013 08:49:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 18C43D94BC; Thu, 4 Jul 2013 17:49:46 +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 VCbGXb8OY+3z; Thu, 4 Jul 2013 17:49:45 +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 E0309D94B9; Thu, 4 Jul 2013 17:49:45 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <51D17F54.9020807@cisco.com> Date: Thu, 4 Jul 2013 17:49:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <385BBA28-470B-4D53-9760-6B534AEC5D27@tik.ee.ethz.ch> References: <51425F53.10203@cisco.com> <51CCAC2B.3060300@cisco.com> <51CCB67D.9070204@cisco.com> <3328C6B8-4BD6-4565-A379-1E2DC2A88455@tik.ee.ethz.ch> <51D153DD.5000606@cisco.com> <7121793B-432D-4551-A87E-32DBD60465BB@tik.ee.ethz.ch> <51D17F54.9020807@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1508) Cc: draft-ietf-ipfix-mediation-protocol@tools.ietf.org, IETF IPFIX Working Group Subject: Re: [IPFIX] review of draft-ietf-ipfix-mediation-protocol-04 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, 04 Jul 2013 15:49:57 -0000 hi Paul, all, I've made the following changes to the -06 working copy as well Cheers, Brian On 1 Jul 2013, at 15:08 , Paul Aitken wrote: > Brian, >=20 >> Okay, so the concrete terminological suggestion you're making is... >>=20 >> NEW: >> Original Observation Point: An Observation Point on a Metering >> Process associated with the Original Exporter... >>=20 >> correct? >=20 > That helps. >=20 >>> My concern is that although an implementation may not wish to export = this option because it cannot be accurately or meaningfully measured, it = may be obliged to export it for RFC compliance. >> Good point. There's 2119 creep here: the reliability records = specified in RFC5101 and 5101bis are a MAY, in medproto they're a = SHOULD. I suggest the fix here is to downgrade the requirement in = section 10 of medproto to MAY: >>=20 >> NEW: >>=20 >> IPFIX provides Options Templates for the reporting the reliability = of >> processes within the IPFIX Architecture. As each Mediator = includes >> at least one IPFIX Exporting Process, they MAY use the Exporting >> Process Reliability Statistics Options Template, as specified in >> [I-D.ietf-ipfix-protocol-rfc5101bis]. >>=20 >> Analogous to the Metering Process Reliability Statistics Options >> Template, also specified in [I-D.ietf-ipfix-protocol-rfc5101bis], >> Mediators MAY implement the Intermediate Process Reliability >> Statistics Options Template, specified in the Section 10.1. >>=20 >> The Flow Keys Options Template, as specified in >> [I-D.ietf-ipfix-protocol-rfc5101bis], may require special handling = at >> an IPFIX Mediator as described in Section 10.2. >=20 > Great. >=20 >>> That's exactly what I'm arguing. Provide an opt-out for the case = that an implementer knows that this metric will be poor to meaningless, = or impossible to implement. >> Okay, got it, and I agree. As above, MAY language would provide this = opt-out. >=20 > Thanks, > P. From n.brownlee@auckland.ac.nz Sun Jul 7 14:31:56 2013 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 AF1BC11E8122 for ; Sun, 7 Jul 2013 14:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Aj7oD0IrBZiP for ; Sun, 7 Jul 2013 14:31:52 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 284DB21F9C88 for ; Sun, 7 Jul 2013 14:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1373232712; x=1404768712; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=nAvguV8vsTSjIPGvXuv3DvdGj2jujca1bZtPPRra4jg=; b=kgf7Jj6uu8inCBnkjI0YAzmBpI7SywDrfYV2DM3mncGNOo7VvKRgtkAy G4dPsSoxSMfKQRnUTuZVTaH/K+sV3idCY5O2AUkFTjrdh7NVf77uL2fBo R7GjcvDweWPp+fMyJ9tlRX8kuQQ0B70+tIFOF3yRpUAS+Ftdqb6Ketyz+ c=; X-IronPort-AV: E=Sophos;i="4.87,1015,1363086000"; d="scan'208";a="197584436" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 08 Jul 2013 09:31:51 +1200 Message-ID: <51D9DE46.6060605@auckland.ac.nz> Date: Mon, 08 Jul 2013 09:31:50 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] First Draft agenda for IPFIX at IETF 87, Berlin 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: Sun, 07 Jul 2013 21:31:56 -0000 Hi all: Here's the first draft of our agenda for Berlin. Please send any suggestions for changes to it to Nevil; if you want to present something, particularly if its relevant to item 4 (Next steps for IPFIX), please let me know as soon as possible. Cheers, Nevil ================================================== IP Flow Information Export WG (ipfix) Agenda for IETF 87, Berlin (agenda-00) Thursday, 1 August 2013, 1000-1130, Schoenberg 1/2 ================================================== >>> Note that EMAN and IPFIX are sharing this 2.5 hour meeting time on MOnday morning <<< Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 10 min Flow Selection Techniques In RFC Ed queue since 30 May, MISSREF on 5101bis IE Doctors In RFC Ed queue since Oct 2012, MISSREF on 5101bis Current ie-doctors team is Brian Trammell, Paul Aitken, Juergen Quittek and Nevil Brownlee 5102bis In RFC Ed queue since 12 Feb, MISSREF on 5101bis 5101bis draft-ietf-ipfix-protocol-rfc5101bis-08, 13 Jun 13 On agenda for IESG Telechat 11 July 13 3. Current charter work items = 10 min a) IEs for Data Link Layer Traffic Measurement (Atsushi Kobayashi) draft-ipfix-data-link-layer-monitoring-03, 2 Jul 13 Waiting for feedback from Pat Thaler b) Protocol for PFIX Mediation (Benoit Claise) draft-ietf-ipfix-mediation-protocol-05, 27 Jun 13 c) Exporting MIB objects (Paul Aitken) draft-ipfix-mib-variable-export-02, 25 Feb 13 No change since last meeting 4. Next steps for IPFIX = 50 min a) IPFIXv2 discussion In Atlanta, when discussing MIB Variable Export we said ... . EFSF is a new direction for IPFIX - it's really IPFIXv2. . We need to finish the MIB Variable Export draft as soon as possible. . Paul will remove it from this draft, making sure the draft will still work in IPFIXv2. . The WG should adopt this as a work item. That will require a new charter; meanwhile work on it can proceed on the IPFIX list. b) What drafts should we consider next for the WG? 5. Other drafts (if time permits) = 15 min a) IEs for Metering Process Location (Abdelkader Lahmadi), 30 Jun 13 draft-festor-ipfix-metering-process-location-00 a) Framework for Signaling Flow Characteristics between Applications and the Network (Toreless Eckert), 4 Jul 13 draft-eckert-intarea-flow-metadata-framework-00 6. Any Other Business Drafts presnted at IETF 86 (Orlando) a) Flow Aware Packet Sampling Techniques (Ramki Krishnan) draft-krishnan-ipfix-flow-aware-packet-sampling-05.txt 16 Jun 13 b) Textual Representation of IPFIX Abstract Data Types (Brian Trammell) draft-trammell-ipfix-text-adt-00.txt, 5 Nov 12 c) Private Enterprise Information Elements Registry Exchange (Chris Inacio) draft-inacio-ipfix-penie-00.txt, 9 Nov 12 d) Reporting Equivalent IPFIX Information Elements (Paul Aitken) draft-aitken-ipfix-equivalent-ies-00.txt, 15 Feb 13 Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=87 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org and via Meetecho, http://ietf87.conf.meetecho.com/index.php/Web_Client -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From internet-drafts@ietf.org Wed Jul 10 06:55:51 2013 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 CBC6221F9BD5; Wed, 10 Jul 2013 06:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 FAl7S4ADT7Pi; Wed, 10 Jul 2013 06:55:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C42021F866E; Wed, 10 Jul 2013 06:55:51 -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.51.p2 Message-ID: <20130710135551.21232.20647.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 06:55:51 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-09.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: Wed, 10 Jul 2013 13:55:51 -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 Group = of the IETF. Title : Specification of the IP Flow Information eXport (IPFIX) = Protocol for the Exchange of Flow Information Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-protocol-rfc5101bis-09.txt Pages : 72 Date : 2013-07-10 Abstract: This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Wed Jul 10 07:01:46 2013 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 8C0DD11E812C for ; Wed, 10 Jul 2013 07:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 idrZj3srRaVV for ; Wed, 10 Jul 2013 07:01: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 AD91311E8123 for ; Wed, 10 Jul 2013 07:01:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E62A8D94A1 for ; Wed, 10 Jul 2013 16:01: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 ntaaDwcdYaPC for ; Wed, 10 Jul 2013 16:01:40 +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 BAAF8D949E for ; Wed, 10 Jul 2013 16:01:40 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jul 2013 16:01:40 +0200 References: <20130710135551.21232.96540.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-protocol-rfc5101bis-09.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: Wed, 10 Jul 2013 14:01:46 -0000 Greetings, all, We've submitted a new version of rfc5101bis, addressing IESG and ops-dir = review comments.=20 Best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-ipfix-protocol-rfc5101bis-09.txt > Date: 10 July 2013 15:55:51 GMT+02:00 > To: Benoit Claise , Brian Trammell = >=20 >=20 > A new version of I-D, draft-ietf-ipfix-protocol-rfc5101bis-09.txt > has been successfully submitted by Benoit Claise and posted to the > IETF repository. >=20 > Filename: draft-ietf-ipfix-protocol-rfc5101bis > Revision: 09 > Title: Specification of the IP Flow Information eXport = (IPFIX) Protocol for the Exchange of Flow Information > Creation date: 2013-07-10 > Group: ipfix > Number of pages: 72 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-rfc5101bis-0= 9.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis > Htmlized: = http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-09 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-09= >=20 > Abstract: > This document specifies the IP Flow Information Export (IPFIX) > protocol that serves for transmitting Traffic Flow information over > the network. In order to transmit Traffic Flow information from an > Exporting Process to a Collecting Process, a common representation = of > flow data and a standard means of communicating them is required. > This document describes how the IPFIX Data and Template Records are > carried over a number of transport protocols from an IPFIX Exporting > Process to an IPFIX Collecting Process. This document obsoletes RFC > 5101. >=20 >=20 >=20 >=20 > The IETF Secretariat From internet-drafts@ietf.org Thu Jul 11 14:44:25 2013 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 6165811E81AD; Thu, 11 Jul 2013 14:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 B+zI51JtJ2Eo; Thu, 11 Jul 2013 14:44:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C65B311E8129; Thu, 11 Jul 2013 14:44:24 -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.51.p2 Message-ID: <20130711214424.17469.65072.idtracker@ietfa.amsl.com> Date: Thu, 11 Jul 2013 14:44:24 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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: Thu, 11 Jul 2013 21:44:25 -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 Group = of the IETF. Title : Specification of the IP Flow Information eXport (IPFIX) = Protocol for the Exchange of Flow Information Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-protocol-rfc5101bis-10.txt Pages : 73 Date : 2013-07-11 Abstract: This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Fri Jul 12 05:12:23 2013 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 D5C2811E8103 for ; Fri, 12 Jul 2013 05:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 Ev2mcgJKIIzL for ; Fri, 12 Jul 2013 05:12:19 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9DADD11E80E1 for ; Fri, 12 Jul 2013 05:12:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0A25FD9305 for ; Fri, 12 Jul 2013 14:12:15 +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 2qWHHlxiLbSw for ; Fri, 12 Jul 2013 14:12:15 +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 C37ABD9304 for ; Fri, 12 Jul 2013 14:12:15 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 12 Jul 2013 14:12:15 +0200 To: IETF IPFIX Working Group Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [IPFIX] announcement: ipfix for python 3 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: Fri, 12 Jul 2013 12:12:23 -0000 Greetings, all, Those of you who need to read or write IPFIX messages from programs = written in Python 3 can now do so by installing the 'ipfix' package from = the Python Package Index (http://pypi.python.org/pypi/ipfix; pip install = ipfix or easy_install ipfix should work too, depending on how your = Python environment is set up). The module provides a bridge between Messages and streams of Messages, = and Python dicts and tuples. It supports Templates and Options = Templates, with built-in support for IANA and RFC5103 IEs, as well as = the definition of enterprise-specific IEs in IEspec format (section 10 = of draft-ietf-ipfix-ie-doctors). The module is not a complete implementation of an Exporting and/or = Collecting Process, though the ipfix.reader.MessageStreamReader and = ipfix.writer.MessageStreamWriter objects can be fairly easily bound to = TCP sockets and/or used with the socketserver framework. SCTP support is = forthcoming. It should be fairly easy to implement UDP support as well, = though it's a low priority. Documentation is at britram.github.io/python-ipfix. Be advised that the = module is alpha quality: there's some lightweight testing based on = doctest, but testing hasn't been at all rigorous to date. The module is = under active development but the API should remain reasonably stable. = Bug reports are welcome. I'm using it in some light day-to-day analysis = tasks and it seems to work reasonably well with the data I have; your = mileage may vary. Enjoy, Brian= From n.brownlee@auckland.ac.nz Sun Jul 14 15:48:22 2013 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 C621A21F9C19 for ; Sun, 14 Jul 2013 15:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 10DijEPBpe3s for ; Sun, 14 Jul 2013 15:48:18 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3D421F9C3D for ; Sun, 14 Jul 2013 15:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1373842097; x=1405378097; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=L7kGiD6Fr+Obv1wBfWmxk44rVmcO3ATT02wE397LPEA=; b=hJgwHMIHEzB/6En+zu0uaaFsoe5I9sIvilJYp+nmWOFMPzj/08cdUghf /0YXn1ds3Orvhm2t9C/mIDI7U3DqF7TnGmviL3xRYIqnjEdRT8187QZEE 4f8TBdekiCZ+fXHODbmTo/vhB3W/reCX6WVvrQdgiyM2eeHTzw+I75lSZ 4=; X-IronPort-AV: E=Sophos;i="4.89,665,1367928000"; d="scan'208";a="198926482" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 15 Jul 2013 10:48:16 +1200 Message-ID: <51E32AB0.30803@auckland.ac.nz> Date: Mon, 15 Jul 2013 10:48:16 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Agenda for Berlin meeting on Monday morning 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: Sun, 14 Jul 2013 22:48:22 -0000 Hi all: The current agenda for the IPFIX meeting in Berlin is now available at http://www.ietf.org/proceedings/87/agenda/agenda-87-ipfix Note that the meeting time is now 1000-1130 on Monday, 29 July Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From n.brownlee@auckland.ac.nz Mon Jul 15 18:16:55 2013 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 26D4521E80CD for ; Mon, 15 Jul 2013 18:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 pHKEDdZDpHvO for ; Mon, 15 Jul 2013 18:16:50 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0E821E8055 for ; Mon, 15 Jul 2013 18:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1373937410; x=1405473410; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=dSPPPtjI0HciM3D2n/zoOSah1gYjAfJktxXAgMWIdd8=; b=GQNupp2ltuj75OBnVXlI/XCGWoVNoRV3pk8RJZTn7R2lzdFKc59H3AsH 2UuMniI3+aWWsfjmP+VAQYdXNj1DKe1Q4MAn71/oqRzBTDPDc8AqccLvk QPGzvUi54RjF1+604wSMGpF0n2ud9heStrD/LnFRSIt3kAm4Q09BH23Ye 0=; X-IronPort-AV: E=Sophos;i="4.89,673,1367928000"; d="scan'208";a="199228325" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 16 Jul 2013 13:16:49 +1200 Message-ID: <51E49F01.4010707@auckland.ac.nz> Date: Tue, 16 Jul 2013 13:16:49 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] [ipfix] Updated Agenda (-02) for Berlin 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, 16 Jul 2013 01:16:55 -0000 Hi all: The latest version of our agenda is now available at http://www.ietf.org/proceedings/87/agenda/agenda-87-ipfix Cheers, Nevil PS: To presenters - since our session is in the first time-slot of the week, please send me your slides by about 1800 on Sunday 28 July (or earlier) so that I can get them onto the Meeting Materials page! -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From iesg-secretary@ietf.org Tue Jul 16 11:18:14 2013 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 DE5BA21F9950; Tue, 16 Jul 2013 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 gFwl+2n+8gEH; Tue, 16 Jul 2013 11:18:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AD021E8088; Tue, 16 Jul 2013 11:18:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.52 Message-ID: <20130716181813.14154.38776.idtracker@ietfa.amsl.com> Date: Tue, 16 Jul 2013 11:18:13 -0700 Cc: ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' to Internet Standard (draft-ietf-ipfix-protocol-rfc5101bis-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, 16 Jul 2013 18:18:15 -0000 The IESG has approved the following document: - 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' (draft-ietf-ipfix-protocol-rfc5101bis-10.txt) as Internet Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary The documents obsoletes RFC 5101. It does not change the technical content of the RFC5101 protocol specification, but it add several clarifications. The WG jointly worked on improving RFC5101 based on implementations experience and document reviews. There is strong consensus on the document. Document Quality This is an update of RFC 5101 based on a lot of practical experiences with implementing and operating the IPFIX protocol. Changes compared to RFC 5101 result from these experiences. Personnel Juergen Quittek is the document shepherd. He has reviewed it personally and believes that this version is ready for forwarding to the IESG for publication. From joelja@bogus.com Tue Jul 16 12:11:28 2013 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 E1A3F11E80D7 for ; Tue, 16 Jul 2013 12:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 hs-wytjTW2rC for ; Tue, 16 Jul 2013 12:11:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2967211E80EA for ; Tue, 16 Jul 2013 12:11:28 -0700 (PDT) Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r6GJBRVx067271 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 16 Jul 2013 19:11:27 GMT (envelope-from joelja@bogus.com) Message-ID: <51E59ADA.7090902@bogus.com> Date: Tue, 16 Jul 2013 12:11:22 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20130716181813.14154.38776.idtracker@ietfa.amsl.com> In-Reply-To: <20130716181813.14154.38776.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130716181813.14154.38776.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 16 Jul 2013 19:11:27 +0000 (UTC) Subject: [IPFIX] Fwd: Protocol Action: 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' to Internet Standard (draft-ietf-ipfix-protocol-rfc5101bis-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, 16 Jul 2013 19:11:29 -0000 Thanks guys, we made it. joel -------- Original Message -------- Subject: Protocol Action: 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' to Internet Standard (draft-ietf-ipfix-protocol-rfc5101bis-10.txt) Date: Tue, 16 Jul 2013 11:18:13 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: ipfix chair , ipfix mailing list , RFC Editor The IESG has approved the following document: - 'Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information' (draft-ietf-ipfix-protocol-rfc5101bis-10.txt) as Internet Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis/ Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary The documents obsoletes RFC 5101. It does not change the technical content of the RFC5101 protocol specification, but it add several clarifications. The WG jointly worked on improving RFC5101 based on implementations experience and document reviews. There is strong consensus on the document. Document Quality This is an update of RFC 5101 based on a lot of practical experiences with implementing and operating the IPFIX protocol. Changes compared to RFC 5101 result from these experiences. Personnel Juergen Quittek is the document shepherd. He has reviewed it personally and believes that this version is ready for forwarding to the IESG for publication. From bclaise@cisco.com Wed Jul 17 01:58:48 2013 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 1B22021F9DBA for ; Wed, 17 Jul 2013 01:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.334 X-Spam-Level: X-Spam-Status: No, score=-10.334 tagged_above=-999 required=5 tests=[AWL=0.264, 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 dBK5rNz2P6+r for ; Wed, 17 Jul 2013 01:58:44 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id D3B3821F9D38 for ; Wed, 17 Jul 2013 01:58:43 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6H8wh88015453 for ; Wed, 17 Jul 2013 04:58:43 -0400 (EDT) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6H8wgBo017617 for ; Wed, 17 Jul 2013 04:58:42 -0400 (EDT) Message-ID: <51E65CC2.7000904@cisco.com> Date: Wed, 17 Jul 2013 10:58:42 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <51E41F08.4060407@cisco.com> In-Reply-To: <51E41F08.4060407@cisco.com> X-Forwarded-Message-Id: <51E41F08.4060407@cisco.com> Content-Type: multipart/alternative; boundary="------------080501080908070208030507" Subject: [IPFIX] Fwd: [ippm] Performance Metrics Registry: new draft 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, 17 Jul 2013 08:58:48 -0000 This is a multi-part message in MIME format. --------------080501080908070208030507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Your feedback is welcome regarding this draft. The connection with the IPFIX registry is mentioned. Regards, Benoit -------- Original Message -------- Subject: [ippm] Performance Metrics Registry: new draft Date: Mon, 15 Jul 2013 18:10:48 +0200 From: Benoit Claise To: IETF IPPM WG Dear all, Let me introduce http://datatracker.ietf.org/doc/draft-claise-ippm-perf-metric-registry/ This draft creates of a new IANA registry, for performance metrics that follows the RFC6390 template. And, let's not forget that the IPPM charter mentions: "Metric definitions will follow the template given in RFC 6390." Thanks Brian for giving me 10 min to present this draft. Regards, Benoit. _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --------------080501080908070208030507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Your feedback is welcome regarding this draft.
The connection with the IPFIX registry is mentioned.

Regards, Benoit


-------- Original Message --------
Subject: [ippm] Performance Metrics Registry: new draft
Date: Mon, 15 Jul 2013 18:10:48 +0200
From: Benoit Claise <bclaise@cisco.com>
To: IETF IPPM WG <ippm@ietf.org> 


Dear all,

Let me introduce 
http://datatracker.ietf.org/doc/draft-claise-ippm-perf-metric-registry/
This draft creates of a new IANA registry, for performance metrics that 
follows the RFC6390 template.
And, let's not forget that the IPPM charter mentions: "Metric 
definitions will follow the template given in RFC 6390."

Thanks Brian for giving me 10 min to present this draft.

Regards, Benoit.



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


--------------080501080908070208030507-- From bclaise@cisco.com Wed Jul 17 03:15:06 2013 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 5A62221F9983 for ; Wed, 17 Jul 2013 03:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 dN0EAnuTNow2 for ; Wed, 17 Jul 2013 03:15:01 -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 E940221F9957 for ; Wed, 17 Jul 2013 03:15:00 -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 r6HAExcq007799 for ; Wed, 17 Jul 2013 12:15:00 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6HAEhpF027541 for ; Wed, 17 Jul 2013 12:14:53 +0200 (CEST) Message-ID: <51E66E93.9030807@cisco.com> Date: Wed, 17 Jul 2013 12:14:43 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] While checking IPFIX IANA registry ... 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, 17 Jul 2013 10:15:06 -0000 Dear all, While preparing for the IPFIX tutorial (Sunday at next IETF), and specifically while double-checking the IPFIX IANA registry, I realized that we closed the gap below 300. For the little story, when we worked on the PSAMP drafts, we started to allocate the PSAMP IEs above 300, to avoid any clashes with the IPFIX drafts. Now, this gap 2xx-300 is fully allocated. That's a good news. It stresses that the PSAMP Metering Process is simply an IPFIX Metering Process with flows composed of one packet. Finally, it stresses that IPFIX is really an exporting protocol, that doesn't care what Metering Process is. Regards, Benoit From paitken@cisco.com Fri Jul 19 05:17:43 2013 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 7B58521E80AD for ; Fri, 19 Jul 2013 05:17:43 -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 s+kBXsbZriT7 for ; Fri, 19 Jul 2013 05:17:38 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id A0CC511E810E for ; Fri, 19 Jul 2013 05:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3021; q=dns/txt; s=iport; t=1374236257; x=1375445857; h=message-id:date:from:mime-version:to:subject; bh=yBwoELmjmFfn5j82V6EolWdBnYXOmeQXI3DF0XiXves=; b=JGDffemfyXr9oczAZS2dfccnMev0GskxY9zqzZ73B7X3EF4xo/DMdn/F MuzAU/NI7mONBw+XfA9xHVuPr4YaV/FVLARrUZyWjIqnSG+2Npn7VJ0Ee utProzs1qPqngtJXhn/pifFGwjW9jFhCLJj9ye1GIZRxTeeRglp+w2tPr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN8t6VGQ/khR/2dsb2JhbABagwaJabRshAYWdIMWDSABHBYYAwIBAgFLDQgBAYgMliWgRpQUA5ddhiOLKoMT X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208,217";a="16072011" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 19 Jul 2013 12:17:34 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6JCHVD5007009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Jul 2013 12:17:32 GMT Received: from [10.61.194.17] ([10.61.194.17]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6JCHUD7019150 for ; Fri, 19 Jul 2013 13:17:30 +0100 (BST) Message-ID: <51E92E5A.7040401@cisco.com> Date: Fri, 19 Jul 2013 13:17:30 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------040802050203090501050200" Subject: [IPFIX] TCP flags? 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: Fri, 19 Jul 2013 12:17:43 -0000 This is a multi-part message in MIME format. --------------040802050203090501050200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear IPFIX experts, IANA's IPFIX registry defines field #6, tcpControlBits, as an unsigned8 flags following RFC793: 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Reserved | URG | ACK | PSH | RST | SYN | FIN | +-----+-----+-----+-----+-----+-----+-----+-----+ This is missing the ECE and CWR bits from (Std) RFC 3168, and ECN Nonce Sum (NS) bit from (Exp) RFC 3540. Per RFC3540, the TCP flags field is like so: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | N | C | E | U | A | P | R | S | F | | Header Length | Reserved | S | W | C | R | C | S | S | Y | I | | | | | R | E | G | K | H | T | N | N | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - where bits 7, 8, and 9 aren't defined in IPFIX. Q1: can we updated tcpControlBits to include the ECE and CWR bits from RFC 3168? Q2: how should the ECN Nonce Sum be reported? Thanks, P. --------------040802050203090501050200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear IPFIX experts,

IANA's IPFIX registry defines field #6, tcpControlBits, as an unsigned8 flags following RFC793:
0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|  Reserved | URG | ACK | PSH | RST | SYN | FIN |
+-----+-----+-----+-----+-----+-----+-----+-----+

This is missing the ECE and CWR bits from (Std) RFC 3168, and ECN Nonce Sum (NS) bit from (Exp) RFC 3540.

Per RFC3540, the TCP flags field is like so:
     0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |               |           | N | C | E | U | A | P | R | S | F |
   | Header Length | Reserved  | S | W | C | R | C | S | S | Y | I |
   |               |           |   | R | E | G | K | H | T | N | N |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

- where bits 7, 8, and 9 aren't defined in IPFIX.


Q1: can we updated tcpControlBits to include the ECE and CWR bits from RFC 3168?
Q2: how should the ECN Nonce Sum be reported?

Thanks,
P.
--------------040802050203090501050200-- From trammell@tik.ee.ethz.ch Fri Jul 19 05:30:40 2013 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 D516E11E811E for ; Fri, 19 Jul 2013 05:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 EHnVBbwM0PCA for ; Fri, 19 Jul 2013 05:30:25 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D5CF811E8105 for ; Fri, 19 Jul 2013 05:30:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 38CEBD930D; Fri, 19 Jul 2013 14:30: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 SL14DYeTpsmq; Fri, 19 Jul 2013 14:30: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 039EBD930A; Fri, 19 Jul 2013 14:30:22 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <51E92E5A.7040401@cisco.com> Date: Fri, 19 Jul 2013 14:30:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E92E5A.7040401@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1508) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] TCP flags? 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: Fri, 19 Jul 2013 12:30:41 -0000 hi, Paul, all, Good questions all, attempt at answers inline: On 19 Jul 2013, at 14:17 , Paul Aitken wrote: > Dear IPFIX experts, >=20 > IANA's IPFIX registry defines field #6, tcpControlBits, as an = unsigned8 flags following RFC793: > 0 1 2 3 4 5 6 7 > +-----+-----+-----+-----+-----+-----+-----+-----+ > | Reserved | URG | ACK | PSH | RST | SYN | FIN | > +-----+-----+-----+-----+-----+-----+-----+-----+ >=20 >=20 > This is missing the ECE and CWR bits from (Std) RFC 3168, and ECN = Nonce Sum (NS) bit from (Exp) RFC 3540. >=20 > Per RFC3540, the TCP flags field is like so: > 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | | | N | C | E | U | A | P | R | S | F | > | Header Length | Reserved | S | W | C | R | C | S | S | Y | I | > | | | | R | E | G | K | H | T | N | N | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >=20 >=20 > - where bits 7, 8, and 9 aren't defined in IPFIX. >=20 >=20 > Q1: can we updated tcpControlBits to include the ECE and CWR bits from = RFC 3168? We certainly should. I was actually surprised on rereading the registry = that ECE and CWR *weren't in the IE; QoF and YAF both export ECE and CWR = in violation of the definition.=20 > Q2: how should the ECN Nonce Sum be reported? My suggestion would be to define this field as an unsigned16: MSb LSb +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | N | C | E | U | A | P | R | S | F | | Reserved | S | W | C | R | C | S | S | Y | I | | | | R | E | G | K | H | T | N | N | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ with a specific note that when the IE is encoded as an unsigned8 using = reduced-length encoding, it has the following layout: MSb LSb +---+---+---+---+---+---+---+---+ | C | E | U | A | P | R | S | F | | W | C | R | C | S | S | Y | I | | R | E | G | K | H | T | N | N | +---+---+---+---+---+---+---+---+ and a further specific note that Collecting Processes should not assume = that CWR and ECE were not set simply because they're exported as 0, as = previous revisions of the Information Element did not include them. Yes, it's kludgy, but it has the advantage of describing the reality of = the status quo. As a further note, the use of *bit* numbers has already bitten us in the = past in this registry; I'd strongly suggest we either use "most = significant bit" and "least significant bit" as bit ordering terminology = in these diagrams, or dispose with normative bitfield diagrams = completely in favor of value tables, i.e.: 0x0100 =3D NS (ECN Nonce Sum, see RFC xxxx) 0x0080 =3D CWR (Congestion Window Reduced, see RFC 3168) 0x0040 =3D ECE (ECN Echo, see RFC 3168) 0x0020 =3D URG (Urgent pointer valid) 0x0010 =3D ACK (Acknowledgment number valid) 0x0008 =3D PSH (Push) 0x0004 =3D RST (Connection reset) 0x0002 =3D SYN (Connection synchronize) 0x0001 =3D FIN (Connection shutdown) Cheers, Brian= From paitken@cisco.com Fri Jul 19 05:49:05 2013 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 C436511E812A for ; Fri, 19 Jul 2013 05:49:05 -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 OZR9yQNSzKZE for ; Fri, 19 Jul 2013 05:49:00 -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 EA5A111E8117 for ; Fri, 19 Jul 2013 05:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3973; q=dns/txt; s=iport; t=1374238135; x=1375447735; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=e9Zbu8Jv0GBuOTbGCnDrgO2pDzzTzG7B7oAp58WKD+Y=; b=NeSkXjqQWyBdqX0gC2eTsI1c+RmiSuppko74MkUvLyvH7hXv5NXYLQwu iRl464DBJUoxIyuhamsS8VeUgm6PJZykhXmFi6+NkzFe4WHsQDFNOKbqB PIJ9PqLqSFWBN0zIk4P0BLNW15vFJtCusaXOLDyUsu3GVj+lvNiYdY84n M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAIo16VGQ/khL/2dsb2JhbABagwbBS4EQFnSCJAEBAQMBODMNAQULCxgJFg8JAwIBAgFFBg0BBQIBAYgGBrZ6kA8Hg34Dl12GI4sqgxM X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208";a="157072169" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 19 Jul 2013 12:48:47 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6JCmjIN015756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:48:46 GMT Received: from [10.61.194.17] ([10.61.194.17]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6JCmiJu021172; Fri, 19 Jul 2013 13:48:44 +0100 (BST) Message-ID: <51E935AC.3090706@cisco.com> Date: Fri, 19 Jul 2013 13:48:44 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Trammell References: <51E92E5A.7040401@cisco.com> 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] TCP flags? 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: Fri, 19 Jul 2013 12:49:05 -0000 Brian, > hi, Paul, all, > > Good questions all, attempt at answers inline: > > On 19 Jul 2013, at 14:17 , Paul Aitken wrote: > >> Dear IPFIX experts, >> >> IANA's IPFIX registry defines field #6, tcpControlBits, as an unsigned8 flags following RFC793: >> 0 1 2 3 4 5 6 7 >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> | Reserved | URG | ACK | PSH | RST | SYN | FIN | >> +-----+-----+-----+-----+-----+-----+-----+-----+ >> >> >> This is missing the ECE and CWR bits from (Std) RFC 3168, and ECN Nonce Sum (NS) bit from (Exp) RFC 3540. >> >> Per RFC3540, the TCP flags field is like so: >> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> | | | N | C | E | U | A | P | R | S | F | >> | Header Length | Reserved | S | W | C | R | C | S | S | Y | I | >> | | | | R | E | G | K | H | T | N | N | >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> >> >> - where bits 7, 8, and 9 aren't defined in IPFIX. >> >> >> Q1: can we updated tcpControlBits to include the ECE and CWR bits from RFC 3168? > We certainly should. I was actually surprised on rereading the registry that ECE and CWR *weren't in the IE; QoF and YAF both export ECE and CWR in violation of the definition. Admittedly, FNF also does the same because we're simply reporting the raw bits from the packets as we see them. >> Q2: how should the ECN Nonce Sum be reported? > My suggestion would be to define this field as an unsigned16: > > MSb LSb > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | | N | C | E | U | A | P | R | S | F | > | Reserved | S | W | C | R | C | S | S | Y | I | > | | | R | E | G | K | H | T | N | N | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > with a specific note that when the IE is encoded as an unsigned8 using reduced-length encoding, it has the following layout: > > MSb LSb > +---+---+---+---+---+---+---+---+ > | C | E | U | A | P | R | S | F | > | W | C | R | C | S | S | Y | I | > | R | E | G | K | H | T | N | N | > +---+---+---+---+---+---+---+---+ > > and a further specific note that Collecting Processes should not assume that CWR and ECE were not set simply because they're exported as 0, as previous revisions of the Information Element did not include them. > > Yes, it's kludgy, but it has the advantage of describing the reality of the status quo. I'm happy with that, except for enlarging the size from u8 to u16. Is that acceptable to collectors? Otherwise, the changes do seem to be in line with ie-doctors. > As a further note, the use of *bit* numbers has already bitten us in the past in this registry; True. Note that I copied the RFC3540 bit ordering, and it corresponds to the RFC793 bit ordering too. However, the disadvantage is that with the u8 form bit 7 is "FIN", whereas with the u16 form bit 7 is NS and FIN becomes bit 15... so that's confusing. > I'd strongly suggest we either use "most significant bit" and "least significant bit" as bit ordering terminology in these diagrams, or dispose with normative bitfield diagrams completely in favor of value tables, i.e.: > > 0x0100 = NS (ECN Nonce Sum, see RFC xxxx) > 0x0080 = CWR (Congestion Window Reduced, see RFC 3168) > 0x0040 = ECE (ECN Echo, see RFC 3168) > 0x0020 = URG (Urgent pointer valid) > 0x0010 = ACK (Acknowledgment number valid) > 0x0008 = PSH (Push) > 0x0004 = RST (Connection reset) > 0x0002 = SYN (Connection synchronize) > 0x0001 = FIN (Connection shutdown) That works. Thanks, P. From trammell@tik.ee.ethz.ch Fri Jul 19 06:11:59 2013 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 1DEF821E808B for ; Fri, 19 Jul 2013 06:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.181, 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 Ey6gqGFvqCbv for ; Fri, 19 Jul 2013 06:11:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 14B8C21E80AB for ; Fri, 19 Jul 2013 06:11:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 1A237D930B; Fri, 19 Jul 2013 15:11:52 +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 iY1MRE85uifv; Fri, 19 Jul 2013 15:11:51 +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 DD02FD930A; Fri, 19 Jul 2013 15:11:51 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <51E935AC.3090706@cisco.com> Date: Fri, 19 Jul 2013 15:11:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1508) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] TCP flags? 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: Fri, 19 Jul 2013 13:11:59 -0000 hi Paul, another idea inline. On 19 Jul 2013, at 14:48 , Paul Aitken wrote: >=20 >>> Q2: how should the ECN Nonce Sum be reported? >> My suggestion would be to define this field as an unsigned16: >>=20 >> MSb LSb >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >> | | N | C | E | U | A | P | R | S | F | >> | Reserved | S | W | C | R | C | S | S | Y | I | >> | | | R | E | G | K | H | T | N | N | >> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>=20 >> with a specific note that when the IE is encoded as an unsigned8 = using reduced-length encoding, it has the following layout: >>=20 >> MSb LSb >> +---+---+---+---+---+---+---+---+ >> | C | E | U | A | P | R | S | F | >> | W | C | R | C | S | S | Y | I | >> | R | E | G | K | H | T | N | N | >> +---+---+---+---+---+---+---+---+ >>=20 >> and a further specific note that Collecting Processes should not = assume that CWR and ECE were not set simply because they're exported as = 0, as previous revisions of the Information Element did not include = them. >>=20 >> Yes, it's kludgy, but it has the advantage of describing the reality = of the status quo. >=20 > I'm happy with that, except for enlarging the size from u8 to u16. Is = that acceptable to collectors? As far as I can tell, that's the only open question. Another possibility: expand this one to the full 8 bits (with a note = about CWR and ECE being potentially unsupported by old EPs), and define = a new unsigned8 IE for the high four bits of the increasingly = inaccurately named TCP flags byte, to futureproof against use of those = three bits. This has the advantage of having the same record encoding as the = unsigned16 version (if you follow tcpHighControlFlags with = tcpControlFlags in the template) at the expense of 4 extra template = bytes, while not having any possibility to break collectors that aren't = expecting it. Cheers, Brian From bclaise@cisco.com Fri Jul 19 06:21:56 2013 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 D226611E8128 for ; Fri, 19 Jul 2013 06:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.508 X-Spam-Level: X-Spam-Status: No, score=-10.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 G7F3l41idJqr for ; Fri, 19 Jul 2013 06:21:52 -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 6EA6F11E812C for ; Fri, 19 Jul 2013 06:21: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 r6JDLpDP021000; Fri, 19 Jul 2013 15:21:51 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6JDL9fW006145; Fri, 19 Jul 2013 15:21:30 +0200 (CEST) Message-ID: <51E93D44.5040600@cisco.com> Date: Fri, 19 Jul 2013 15:21:08 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Trammell References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> In-Reply-To: <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@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] TCP flags? 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: Fri, 19 Jul 2013 13:21:56 -0000 On 19/07/2013 15:11, Brian Trammell wrote: > hi Paul, > > another idea inline. > > On 19 Jul 2013, at 14:48 , Paul Aitken wrote: >>>> Q2: how should the ECN Nonce Sum be reported? >>> My suggestion would be to define this field as an unsigned16: >>> >>> MSb LSb >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> | | N | C | E | U | A | P | R | S | F | >>> | Reserved | S | W | C | R | C | S | S | Y | I | >>> | | | R | E | G | K | H | T | N | N | >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> >>> with a specific note that when the IE is encoded as an unsigned8 using reduced-length encoding, it has the following layout: >>> >>> MSb LSb >>> +---+---+---+---+---+---+---+---+ >>> | C | E | U | A | P | R | S | F | >>> | W | C | R | C | S | S | Y | I | >>> | R | E | G | K | H | T | N | N | >>> +---+---+---+---+---+---+---+---+ >>> >>> and a further specific note that Collecting Processes should not assume that CWR and ECE were not set simply because they're exported as 0, as previous revisions of the Information Element did not include them. >>> >>> Yes, it's kludgy, but it has the advantage of describing the reality of the status quo. >> I'm happy with that, except for enlarging the size from u8 to u16. Is that acceptable to collectors? > As far as I can tell, that's the only open question. > > Another possibility: expand this one to the full 8 bits (with a note about CWR and ECE being potentially unsupported by old EPs), and define a new unsigned8 IE for the high four bits of the increasingly inaccurately named TCP flags byte, to futureproof against use of those three bits. If you go that far (assuming that the change from u8 to u16 is a problem), why don't you simply have a new IE, u16 ... and deprecate the old one? Regards, Benoit > > This has the advantage of having the same record encoding as the unsigned16 version (if you follow tcpHighControlFlags with tcpControlFlags in the template) at the expense of 4 extra template bytes, while not having any possibility to break collectors that aren't expecting it. > > Cheers, > > Brian > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > From paitken@cisco.com Fri Jul 19 06:26:23 2013 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 9219511E812C for ; Fri, 19 Jul 2013 06:26: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=[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 LweFsRfAiYPK for ; Fri, 19 Jul 2013 06:26:18 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id C4AC311E8117 for ; Fri, 19 Jul 2013 06:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2345; q=dns/txt; s=iport; t=1374240377; x=1375449977; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=o+BRAEMgkfVK4jG7i1VCpIQbUliMHYl0kepDBiElr1I=; b=TCALDSvKXOo2lUQbI2Eclf8sfu7HLT0I8DNCzh/fmidk6+qactx0iMEg H9H5brAkz8WJFaY968gGOZU7y1vEbkB0faDUeYLXszuKx/NZdmCwxwwLP 6cYDTKgX2xvlz55X8EXHFvUm8VHHpoaoBkJlOliFoapk9xN0eKTEHklAz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABE96VGQ/khL/2dsb2JhbABagwbBS4EQFnSCJAEBAQMBOEABBQsLGAkWDwkDAgECAUUGDQEFAgEBiAYGtwaQDweDfgOXXYYjiyqDEw X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208";a="16075403" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 19 Jul 2013 13:26:16 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6JDQEJ3000331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 13:26:15 GMT Received: from [10.61.194.17] ([10.61.194.17]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6JDQDrf024023; Fri, 19 Jul 2013 14:26:14 +0100 (BST) Message-ID: <51E93E76.4010802@cisco.com> Date: Fri, 19 Jul 2013 14:26:14 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Trammell References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> In-Reply-To: <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@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] TCP flags? 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: Fri, 19 Jul 2013 13:26:23 -0000 Brian, > hi Paul, > > another idea inline. > > On 19 Jul 2013, at 14:48 , Paul Aitken wrote: >>>> Q2: how should the ECN Nonce Sum be reported? >>> My suggestion would be to define this field as an unsigned16: >>> >>> MSb LSb >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> | | N | C | E | U | A | P | R | S | F | >>> | Reserved | S | W | C | R | C | S | S | Y | I | >>> | | | R | E | G | K | H | T | N | N | >>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>> >>> with a specific note that when the IE is encoded as an unsigned8 using reduced-length encoding, it has the following layout: >>> >>> MSb LSb >>> +---+---+---+---+---+---+---+---+ >>> | C | E | U | A | P | R | S | F | >>> | W | C | R | C | S | S | Y | I | >>> | R | E | G | K | H | T | N | N | >>> +---+---+---+---+---+---+---+---+ >>> >>> and a further specific note that Collecting Processes should not assume that CWR and ECE were not set simply because they're exported as 0, as previous revisions of the Information Element did not include them. >>> >>> Yes, it's kludgy, but it has the advantage of describing the reality of the status quo. >> I'm happy with that, except for enlarging the size from u8 to u16. Is that acceptable to collectors? > As far as I can tell, that's the only open question. > > Another possibility: expand this one to the full 8 bits (with a note about CWR and ECE being potentially unsupported by old EPs), and define a new unsigned8 IE for the high four bits of the increasingly inaccurately named TCP flags byte, to futureproof against use of those three bits. > > This has the advantage of having the same record encoding as the unsigned16 version (if you follow tcpHighControlFlags with tcpControlFlags in the template) at the expense of 4 extra template bytes, while not having any possibility to break collectors that aren't expecting it. Yes, that would work too. It'd be slightly more efficient to define the new field as u16 containing all the bits, and export either/or. A collector update is required either way... P. From trammell@tik.ee.ethz.ch Fri Jul 19 06:51:52 2013 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 B24F511E8131 for ; Fri, 19 Jul 2013 06:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 cjOL0NAlWp76 for ; Fri, 19 Jul 2013 06:51:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6991721E80D0 for ; Fri, 19 Jul 2013 06:51:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D38EED930D; Fri, 19 Jul 2013 15:51:14 +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 sZ6psLe2H7dy; Fri, 19 Jul 2013 15:51:14 +0200 (MEST) Received: from [10.152.227.71] (unknown [213.55.184.148]) (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 52FDBD930B; Fri, 19 Jul 2013 15:51:14 +0200 (MEST) References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> <51E93E76.4010802@cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <51E93E76.4010802@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8B26930D-79A9-43F9-9C68-B783C9DF4557@tik.ee.ethz.ch> X-Mailer: iPhone Mail (10B329) From: Brian Trammell Date: Fri, 19 Jul 2013 15:51:10 +0200 To: Paul Aitken Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] TCP flags? 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: Fri, 19 Jul 2013 13:51:53 -0000 Hi Paul,=20 Inline, sent from my iPhone On 19.07.2013, at 15:26, Paul Aitken wrote: > Brian, >=20 >> hi Paul, >>=20 >> another idea inline. >>=20 >> On 19 Jul 2013, at 14:48 , Paul Aitken wrote: >>>>> Q2: how should the ECN Nonce Sum be reported? >>>> My suggestion would be to define this field as an unsigned16: >>>>=20 >>>> MSb LSb >>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>> | | N | C | E | U | A | P | R | S | F | >>>> | Reserved | S | W | C | R | C | S | S | Y | I | >>>> | | | R | E | G | K | H | T | N | N | >>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>=20 >>>> with a specific note that when the IE is encoded as an unsigned8 using r= educed-length encoding, it has the following layout: >>>>=20 >>>> MSb LSb >>>> +---+---+---+---+---+---+---+---+ >>>> | C | E | U | A | P | R | S | F | >>>> | W | C | R | C | S | S | Y | I | >>>> | R | E | G | K | H | T | N | N | >>>> +---+---+---+---+---+---+---+---+ >>>>=20 >>>> and a further specific note that Collecting Processes should not assume= that CWR and ECE were not set simply because they're exported as 0, as prev= ious revisions of the Information Element did not include them. >>>>=20 >>>> Yes, it's kludgy, but it has the advantage of describing the reality of= the status quo. >>> I'm happy with that, except for enlarging the size from u8 to u16. Is th= at acceptable to collectors? >> As far as I can tell, that's the only open question. >>=20 >> Another possibility: expand this one to the full 8 bits (with a note abou= t CWR and ECE being potentially unsupported by old EPs), and define a new un= signed8 IE for the high four bits of the increasingly inaccurately named TCP= flags byte, to futureproof against use of those three bits. >>=20 >> This has the advantage of having the same record encoding as the unsigned= 16 version (if you follow tcpHighControlFlags with tcpControlFlags in the te= mplate) at the expense of 4 extra template bytes, while not having any possi= bility to break collectors that aren't expecting it. >=20 > Yes, that would work too. >=20 > It'd be slightly more efficient to define the new field as u16 containing a= ll the bits, and export either/or. >=20 > A collector update is required either way... Not if an exporter that's ECN Nonce aware is exporting to a collector that i= sn't; in that case, it gets the low 8 bits from the tcpControlBits and the i= gnores the high four (one) as an unknown IE. Cheers B= From paitken@cisco.com Fri Jul 19 07:01:42 2013 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 D361721E80DE for ; Fri, 19 Jul 2013 07:01:42 -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 MTgHZGuVJ4mI for ; Fri, 19 Jul 2013 07:01:37 -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 96ECF21E80D8 for ; Fri, 19 Jul 2013 07:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2913; q=dns/txt; s=iport; t=1374242496; x=1375452096; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=s7Nb8fy9s1GqZWngHdLQ0qLELVC5PcWPZgipXXMjluk=; b=WagPctLgddyfMeE3tB6HXcrBQblXWRK3dauxQVp+Iy8FQeFjzL4R0onb Gs/e2xfpcC/4++Q9RW5VA8OJDeL6eyS/SOjpEF+xtHnj8eyhfnl91j0Ub T1EL8dAN2bx7bmU393EW461/3gQ7AdHeRZyUMC6/GfrIb1Pq6W6Z/1n32 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAH1F6VGQ/khR/2dsb2JhbABbgwbBS4EPFnSCJAEBAQQ4QAEQCxgJFg8JAwIBAgFFBg0BBQIBAReHdbcXkA8Hg34Dl12GI4sqgxM X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208";a="84727648" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 19 Jul 2013 14:01:24 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6JE1MYq022007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 14:01:22 GMT Received: from [10.61.194.17] ([10.61.194.17]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6JE1LVI026946; Fri, 19 Jul 2013 15:01:21 +0100 (BST) Message-ID: <51E946B2.4070702@cisco.com> Date: Fri, 19 Jul 2013 15:01:22 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Trammell References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> <51E93E76.4010802@cisco.com> <8B26930D-79A9-43F9-9C68-B783C9DF4557@tik.ee.ethz.ch> In-Reply-To: <8B26930D-79A9-43F9-9C68-B783C9DF4557@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] TCP flags? 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: Fri, 19 Jul 2013 14:01:42 -0000 Brian, So we have at least 3 solutions. We need a wider audience and feedback from collector vendors. P. On 19/07/13 14:51, Brian Trammell wrote: > Hi Paul, > > Inline, sent from my iPhone > > On 19.07.2013, at 15:26, Paul Aitken wrote: > >> Brian, >> >>> hi Paul, >>> >>> another idea inline. >>> >>> On 19 Jul 2013, at 14:48 , Paul Aitken wrote: >>>>>> Q2: how should the ECN Nonce Sum be reported? >>>>> My suggestion would be to define this field as an unsigned16: >>>>> >>>>> MSb LSb >>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>> | | N | C | E | U | A | P | R | S | F | >>>>> | Reserved | S | W | C | R | C | S | S | Y | I | >>>>> | | | R | E | G | K | H | T | N | N | >>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>> >>>>> with a specific note that when the IE is encoded as an unsigned8 using reduced-length encoding, it has the following layout: >>>>> >>>>> MSb LSb >>>>> +---+---+---+---+---+---+---+---+ >>>>> | C | E | U | A | P | R | S | F | >>>>> | W | C | R | C | S | S | Y | I | >>>>> | R | E | G | K | H | T | N | N | >>>>> +---+---+---+---+---+---+---+---+ >>>>> >>>>> and a further specific note that Collecting Processes should not assume that CWR and ECE were not set simply because they're exported as 0, as previous revisions of the Information Element did not include them. >>>>> >>>>> Yes, it's kludgy, but it has the advantage of describing the reality of the status quo. >>>> I'm happy with that, except for enlarging the size from u8 to u16. Is that acceptable to collectors? >>> As far as I can tell, that's the only open question. >>> >>> Another possibility: expand this one to the full 8 bits (with a note about CWR and ECE being potentially unsupported by old EPs), and define a new unsigned8 IE for the high four bits of the increasingly inaccurately named TCP flags byte, to futureproof against use of those three bits. >>> >>> This has the advantage of having the same record encoding as the unsigned16 version (if you follow tcpHighControlFlags with tcpControlFlags in the template) at the expense of 4 extra template bytes, while not having any possibility to break collectors that aren't expecting it. >> Yes, that would work too. >> >> It'd be slightly more efficient to define the new field as u16 containing all the bits, and export either/or. >> >> A collector update is required either way... > Not if an exporter that's ECN Nonce aware is exporting to a collector that isn't; in that case, it gets the low 8 bits from the tcpControlBits and the ignores the high four (one) as an unknown IE. > > Cheers B From fanpeng@chinamobile.com Fri Jul 19 09:09:25 2013 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 82BE221F9956 for ; Fri, 19 Jul 2013 09:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_221=2.222] 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 Rd4QahCnegmR for ; Fri, 19 Jul 2013 09:09:20 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id ABB6421E804E for ; Fri, 19 Jul 2013 09:09:19 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee251e96460f2d-3ff2d; Sat, 20 Jul 2013 00:08:02 +0800 (CST) X-RM-TRANSID: 2ee251e96460f2d-3ff2d Received: from X6X8D79D8F49E2 (unknown[125.97.242.89]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee151e96459abd-6b5d0; Sat, 20 Jul 2013 00:08:02 +0800 (CST) X-RM-TRANSID: 2ee151e96459abd-6b5d0 From: "Fan, Peng" To: "'IETF IPFIX Working Group'" Date: Sat, 20 Jul 2013 00:11:08 +0800 Message-ID: <00de01ce849a$94dcc750$be9655f0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DF_01CE84DD.A3000750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6EmoxZ0eZTkddsQLm3ADTX7nk2lw== Content-Language: zh-cn Subject: [IPFIX] Exporting application information? 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: Fri, 19 Jul 2013 16:09:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DF_01CE84DD.A3000750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear IPFIXers, We posted two drafts about requirement and IE definition exporting application layer information using IPFIX. Your comments are welcomed. http://www.ietf.org/id/draft-fan-ipfix-content-info-req-00.txt http://www.ietf.org/id/draft-fan-ipfix-content-info-ie-00.txt Note that the purpose of the drafts are to discuss the needs to extend current function of IPFIX and define new IEs used for reporting application-layer specific information, though, after talking with chairs and Benoit, we find the drafts may cause misunderstanding for intercepting or something. We are thinking the work can be carried out in the aspect of protocols (which are on the layers above layer 4), and specific fields of protocols (say a header field) can be exported globally and statistically without specific targets for monitoring traffic flows. One example protocol is HTTP. The following are some of the specific use cases: 1. we may have to define httpRequestedUrl and httpRequestedHost to monitor on the peering/transit routers connecting other ISPs networks the traffic that goes out into their networks. A list of web site hosts together with traffic volume destined to them is vital to determine which outside web sites absorb traffic most and should be brought into our network. 2. today in many providers' networks we have to monitor the performance of web sites, e.g. download duration of a web page, success rate of request, etc. Then at least we will need httpRequestMethod, httpRequestReferer, and httpResponseStatusCode. 3. we need httpUserAgent to give us browser platform information statistics when designing and promoting apps and services. Thank you for your review. Regards, Peng ------=_NextPart_000_00DF_01CE84DD.A3000750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = IPFIXers,

 

We posted two drafts about requirement and IE definition = exporting application layer information using IPFIX. Your comments are = welcomed.

 

h= ttp://www.ietf.org/id/draft-fan-ipfix-content-info-req-00.txt

ht= tp://www.ietf.org/id/draft-fan-ipfix-content-info-ie-00.txt

 

Note that the purpose of the drafts are to discuss the = needs to extend current function of IPFIX and define new IEs used for = reporting application-layer specific information, though, after talking = with chairs and Benoit, we find the drafts may cause misunderstanding = for intercepting or something. We are thinking the work can be carried = out in the aspect of protocols (which are on the layers above layer 4), = and specific fields of protocols (say a header field) can be exported = globally and statistically without specific targets for monitoring = traffic flows.

 

One example protocol is HTTP. The following are some of the = specific use cases:

1. we may have to define httpRequestedUrl and = httpRequestedHost to monitor on the peering/transit routers connecting = other ISPs networks the traffic that goes out into their networks. A = list of web site hosts together with traffic volume destined to them is = vital to determine which outside web sites absorb traffic most and = should be brought into our network.

2. today in many providers' = networks we have to monitor the performance of web sites, e.g. download = duration of a web page, success rate of request, etc. Then at least we = will need httpRequestMethod, httpRequestReferer, and = httpResponseStatusCode.

3. we need httpUserAgent to give = us browser platform information statistics when designing and promoting = apps and services.

 

Thank you for your review.

 

Regards,

Peng

------=_NextPart_000_00DF_01CE84DD.A3000750-- From andrewf@plixer.com Mon Jul 22 08:51:17 2013 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 0C24721E808E for ; Mon, 22 Jul 2013 08:51:17 -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=[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 9PJisND93hSh for ; Mon, 22 Jul 2013 08:51:11 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [64.140.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7C27721E8099 for ; Mon, 22 Jul 2013 08:51:11 -0700 (PDT) Received: from [10.11.1.15] ([10.11.1.15]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 22 Jul 2013 11:51:09 -0400 Message-ID: <51ED54FE.9090300@plixer.com> Date: Mon, 22 Jul 2013 11:51:26 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Aitken References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> <51E93E76.4010802@cisco.com> <8B26930D-79A9-43F9-9C68-B783C9DF4557@tik.ee.ethz.ch> <51E946B2.4070702@cisco.com> In-Reply-To: <51E946B2.4070702@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2013 15:51:09.0891 (UTC) FILETIME=[48EBC930:01CE86F3] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] TCP flags? 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, 22 Jul 2013 15:51:17 -0000 Hi all, I've been on vacation so let me recap and make sure I have all the options straight. Options 1) add ECE and CWR bits to the current definition with a note that " Collecting Processes should not assume that CWR and ECE were not set simply because they're exported as 0, as previous revisions of the Information Element did not include them". 2) update the current definition to unsigned 16 with similar wording to option 1 if the 8bit reduced size encoding is exported. Using the extended 16 bits would allow the export of ECN Nonce Sum and remove the ambiguity about CWR and ECE that exists in the 8 bit export. 3) Deprecate current IE and replace it with a new 16 bit IE. Assuming I got the above correct here are my thoughts. If we are going to make the changes for option 1 we might as well go all the way to option 2. We've covered this before, but having separate data types for different integer lengths is pretty much pointless since the size is always exported in the template. From a collector stand point I pretty much have to respect the length in the template so increasing this to a unsigned 16 is no real work for me. The only real difference I see between options 2 and 3 is that the reduced size encoding for option 2 will always be ambiguous for two bits. I don't yet have an opinion on how big a deal that is. Can we increase the size of the current TCP flags and deprecate the export of the reduced size encoding? I currently have a very slight preference for option 2 (with or without deprecating reduced size encoding), but there is still a quite, but persistent, voice in the back of my head saying option 3 is "the right thing". -Andrew On 07/19/2013 10:01 AM, Paul Aitken wrote: > Brian, > > So we have at least 3 solutions. We need a wider audience and feedback > from collector vendors. > > P. > > > On 19/07/13 14:51, Brian Trammell wrote: >> Hi Paul, >> >> Inline, sent from my iPhone >> >> On 19.07.2013, at 15:26, Paul Aitken wrote: >> >>> Brian, >>> >>>> hi Paul, >>>> >>>> another idea inline. >>>> >>>> On 19 Jul 2013, at 14:48 , Paul Aitken wrote: >>>>>>> Q2: how should the ECN Nonce Sum be reported? >>>>>> My suggestion would be to define this field as an unsigned16: >>>>>> >>>>>> MSb LSb >>>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>>> | | N | C | E | U | A | P | R | S | >>>>>> F | >>>>>> | Reserved | S | W | C | R | C | S | S | Y | >>>>>> I | >>>>>> | | | R | E | G | K | H | T | N | >>>>>> N | >>>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>>> >>>>>> with a specific note that when the IE is encoded as an unsigned8 >>>>>> using reduced-length encoding, it has the following layout: >>>>>> >>>>>> MSb LSb >>>>>> +---+---+---+---+---+---+---+---+ >>>>>> | C | E | U | A | P | R | S | F | >>>>>> | W | C | R | C | S | S | Y | I | >>>>>> | R | E | G | K | H | T | N | N | >>>>>> +---+---+---+---+---+---+---+---+ >>>>>> >>>>>> and a further specific note that Collecting Processes should not >>>>>> assume that CWR and ECE were not set simply because they're >>>>>> exported as 0, as previous revisions of the Information Element >>>>>> did not include them. >>>>>> >>>>>> Yes, it's kludgy, but it has the advantage of describing the >>>>>> reality of the status quo. >>>>> I'm happy with that, except for enlarging the size from u8 to u16. >>>>> Is that acceptable to collectors? >>>> As far as I can tell, that's the only open question. >>>> >>>> Another possibility: expand this one to the full 8 bits (with a >>>> note about CWR and ECE being potentially unsupported by old EPs), >>>> and define a new unsigned8 IE for the high four bits of the >>>> increasingly inaccurately named TCP flags byte, to futureproof >>>> against use of those three bits. >>>> >>>> This has the advantage of having the same record encoding as the >>>> unsigned16 version (if you follow tcpHighControlFlags with >>>> tcpControlFlags in the template) at the expense of 4 extra template >>>> bytes, while not having any possibility to break collectors that >>>> aren't expecting it. >>> Yes, that would work too. >>> >>> It'd be slightly more efficient to define the new field as u16 >>> containing all the bits, and export either/or. >>> >>> A collector update is required either way... >> Not if an exporter that's ECN Nonce aware is exporting to a collector >> that isn't; in that case, it gets the low 8 bits from the >> tcpControlBits and the ignores the high four (one) as an unknown IE. >> >> Cheers B > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Mon Jul 22 12:02:27 2013 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 E6FE921F8456 for ; Mon, 22 Jul 2013 12:02:27 -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 Ix6VKfwsZM6H for ; Mon, 22 Jul 2013 12:02:23 -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 D88FE11E80D5 for ; Mon, 22 Jul 2013 12:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6250; q=dns/txt; s=iport; t=1374519725; x=1375729325; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZoecHZRZiM45HuMhEo2J8JmRXPulhpSfYmJGe6oWYLM=; b=arH8/l16BkA7LyQUr+h9gXpPjSAOgZGltZlGX+FJ7Eb0bf0W5WDgo6tk 4Wu7E+uy8aAgJHcuGnj32TCfUedrMqhHLAIh3FR+EzfkjQPMzzEs7wuXU 8qkujaPxDwH72rXfMskqXYD4e6vwXAgUQ7szfiqqmcfh84QiaDI0/dcX2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAFGA7VGQ/khN/2dsb2JhbABbgwY1AcEBgRYWdIIkAQEBAwEBAQE1NgoBBQsLGAkWDwkDAgECARUwBg0BBQIBAReHbwYMuAwEkBYHg34DlAaDV4YjiyqDEw X-IronPort-AV: E=Sophos;i="4.89,720,1367971200"; d="scan'208";a="84928900" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 22 Jul 2013 19:02:02 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6MJ1xZu008575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 19:02:00 GMT Received: from [10.61.167.37] ([10.61.167.37]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6MJ1uMY017353; Mon, 22 Jul 2013 20:01:58 +0100 (BST) Message-ID: <51ED81A7.1000805@cisco.com> Date: Mon, 22 Jul 2013 20:01:59 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andrew Feren References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> <51E93E76.4010802@cisco.com> <8B26930D-79A9-43F9-9C68-B783C9DF4557@tik.ee.ethz.ch> <51E946B2.4070702@cisco.com> <51ED54FE.9090300@plixer.com> In-Reply-To: <51ED54FE.9090300@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] TCP flags? 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, 22 Jul 2013 19:02:28 -0000 Andrew, > Hi all, > > I've been on vacation so let me recap and make sure I have all the > options straight. > > Options > 1) add ECE and CWR bits to the current definition with a note that " > Collecting Processes should not assume that CWR and ECE were not set > simply because they're exported as 0, as previous revisions of the > Information Element did not include them". > > 2) update the current definition to unsigned 16 with similar wording > to option 1 if the 8bit reduced size encoding is exported. Using the > extended 16 bits would allow the export of ECN Nonce Sum and remove > the ambiguity about CWR and ECE that exists in the 8 bit export. > > 3) Deprecate current IE and replace it with a new 16 bit IE. Another possibility was to add a new IE for the uppermost bits. In some cases the two IEs could be exported alongside each other, so the 16 bits would be in order (although that need not always be the case). > Assuming I got the above correct here are my thoughts. > > If we are going to make the changes for option 1 we might as well go > all the way to option 2. We've covered this before, but having > separate data types for different integer lengths is pretty much > pointless since the size is always exported in the template. From a > collector stand point I pretty much have to respect the length in the > template so increasing this to a unsigned 16 is no real work for me. What I said before: changing the size doesn't actually change the type. Fundamentally we only have signed and unsigned, in various sizes. If we'd recognised this years ago, we wouldn't need the "reduced size encoding" rule; collectors would just accept whatever the templates tell them. > The only real difference I see between options 2 and 3 is that the > reduced size encoding for option 2 will always be ambiguous for two > bits. I don't yet have an opinion on how big a deal that is. Can we > increase the size of the current TCP flags and deprecate the export of > the reduced size encoding? That could work. However, existing implementations would continue to export 8 bits, where the top 2 bits are ambiguous. > I currently have a very slight preference for option 2 (with or > without deprecating reduced size encoding), but there is still a > quite, but persistent, voice in the back of my head saying option 3 is > "the right thing". Is it possible that some collectors might break if they receive a field with a different size from what 5102 / IANA says? eg, there was a problem with old versions of wireshark where it had built-in expectations of field sizes, and couldn't cope with the change of sampler ID from 8 bits to 16 bits to 32 bits. If that might be the case, then a new IE is indicated. OTOH, if nobody knows of such a possibility, then (2) might work equally as well. P. > On 07/19/2013 10:01 AM, Paul Aitken wrote: >> Brian, >> >> So we have at least 3 solutions. We need a wider audience and >> feedback from collector vendors. >> >> P. >> >> >> On 19/07/13 14:51, Brian Trammell wrote: >>> Hi Paul, >>> >>> Inline, sent from my iPhone >>> >>> On 19.07.2013, at 15:26, Paul Aitken wrote: >>> >>>> Brian, >>>> >>>>> hi Paul, >>>>> >>>>> another idea inline. >>>>> >>>>> On 19 Jul 2013, at 14:48 , Paul Aitken wrote: >>>>>>>> Q2: how should the ECN Nonce Sum be reported? >>>>>>> My suggestion would be to define this field as an unsigned16: >>>>>>> >>>>>>> MSb LSb >>>>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>>>> | | N | C | E | U | A | P | R | S >>>>>>> | F | >>>>>>> | Reserved | S | W | C | R | C | S | S | Y >>>>>>> | I | >>>>>>> | | | R | E | G | K | H | T | N >>>>>>> | N | >>>>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>>>> >>>>>>> with a specific note that when the IE is encoded as an unsigned8 >>>>>>> using reduced-length encoding, it has the following layout: >>>>>>> >>>>>>> MSb LSb >>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>> | C | E | U | A | P | R | S | F | >>>>>>> | W | C | R | C | S | S | Y | I | >>>>>>> | R | E | G | K | H | T | N | N | >>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>> >>>>>>> and a further specific note that Collecting Processes should not >>>>>>> assume that CWR and ECE were not set simply because they're >>>>>>> exported as 0, as previous revisions of the Information Element >>>>>>> did not include them. >>>>>>> >>>>>>> Yes, it's kludgy, but it has the advantage of describing the >>>>>>> reality of the status quo. >>>>>> I'm happy with that, except for enlarging the size from u8 to >>>>>> u16. Is that acceptable to collectors? >>>>> As far as I can tell, that's the only open question. >>>>> >>>>> Another possibility: expand this one to the full 8 bits (with a >>>>> note about CWR and ECE being potentially unsupported by old EPs), >>>>> and define a new unsigned8 IE for the high four bits of the >>>>> increasingly inaccurately named TCP flags byte, to futureproof >>>>> against use of those three bits. >>>>> >>>>> This has the advantage of having the same record encoding as the >>>>> unsigned16 version (if you follow tcpHighControlFlags with >>>>> tcpControlFlags in the template) at the expense of 4 extra >>>>> template bytes, while not having any possibility to break >>>>> collectors that aren't expecting it. >>>> Yes, that would work too. >>>> >>>> It'd be slightly more efficient to define the new field as u16 >>>> containing all the bits, and export either/or. >>>> >>>> A collector update is required either way... >>> Not if an exporter that's ECN Nonce aware is exporting to a >>> collector that isn't; in that case, it gets the low 8 bits from the >>> tcpControlBits and the ignores the high four (one) as an unknown IE. >>> >>> Cheers B >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Tue Jul 23 05:52:12 2013 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 96CF711E8142 for ; Tue, 23 Jul 2013 05:52:12 -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=[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 NW-ffvr1BCEE for ; Tue, 23 Jul 2013 05:51:58 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [64.140.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7B411E814B for ; Tue, 23 Jul 2013 05:51:51 -0700 (PDT) Received: from [10.11.1.15] ([10.11.1.15]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 23 Jul 2013 08:51:50 -0400 Message-ID: <51EE7C78.1060503@plixer.com> Date: Tue, 23 Jul 2013 08:52:08 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Aitken References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> <51E93E76.4010802@cisco.com> <8B26930D-79A9-43F9-9C68-B783C9DF4557@tik.ee.ethz.ch> <51E946B2.4070702@cisco.com> <51ED54FE.9090300@plixer.com> <51ED81A7.1000805@cisco.com> In-Reply-To: <51ED81A7.1000805@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2013 12:51:50.0678 (UTC) FILETIME=[6657EB60:01CE87A3] Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] TCP flags? 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, 23 Jul 2013 12:52:13 -0000 Hi Paul, On 07/22/2013 03:01 PM, Paul Aitken wrote: > Andrew, > >> Hi all, >> >> I've been on vacation so let me recap and make sure I have all the >> options straight. >> >> Options >> 1) add ECE and CWR bits to the current definition with a note that " >> Collecting Processes should not assume that CWR and ECE were not set >> simply because they're exported as 0, as previous revisions of the >> Information Element did not include them". >> >> 2) update the current definition to unsigned 16 with similar wording >> to option 1 if the 8bit reduced size encoding is exported. Using >> the extended 16 bits would allow the export of ECN Nonce Sum and >> remove the ambiguity about CWR and ECE that exists in the 8 bit export. >> >> 3) Deprecate current IE and replace it with a new 16 bit IE. > > Another possibility was to add a new IE for the uppermost bits. In > some cases the two IEs could be exported alongside each other, so the > 16 bits would be in order (although that need not always be the case). I don't like the option of a new IE for just the high bits. If we must create a new IE I think we should go all the way and take option 3. Exporting the an IE for the high bits and the existing IE adjacent to each other is cute, but seems like a lot of complexity for no real gain. One other question. With this option would the semantics of the existing IE change if both IEs are exported or would the ECE and CWR bits just remain ambiguous? > > >> Assuming I got the above correct here are my thoughts. >> >> If we are going to make the changes for option 1 we might as well go >> all the way to option 2. We've covered this before, but having >> separate data types for different integer lengths is pretty much >> pointless since the size is always exported in the template. From a >> collector stand point I pretty much have to respect the length in the >> template so increasing this to a unsigned 16 is no real work for me. > > What I said before: changing the size doesn't actually change the > type. Fundamentally we only have signed and unsigned, in various > sizes. If we'd recognised this years ago, we wouldn't need the > "reduced size encoding" rule; collectors would just accept whatever > the templates tell them. > > >> The only real difference I see between options 2 and 3 is that the >> reduced size encoding for option 2 will always be ambiguous for two >> bits. I don't yet have an opinion on how big a deal that is. Can we >> increase the size of the current TCP flags and deprecate the export >> of the reduced size encoding? > > That could work. However, existing implementations would continue to > export 8 bits, where the top 2 bits are ambiguous. That is true regardless of what option we ultimately decide on. > > >> I currently have a very slight preference for option 2 (with or >> without deprecating reduced size encoding), but there is still a >> quite, but persistent, voice in the back of my head saying option 3 >> is "the right thing". > > Is it possible that some collectors might break if they receive a > field with a different size from what 5102 / IANA says? eg, there was > a problem with old versions of wireshark where it had built-in > expectations of field sizes, and couldn't cope with the change of > sampler ID from 8 bits to 16 bits to 32 bits. This is a more general issue for wireshark than just sampler ID. Any IE sent with reduced size encoding was liable to blow things up. 8 and 4 byte decodes were implemented for some IEs where people had run into both encodings. Other sizes would still have caused issues. I ran into this about a month ago for an IE specified as unsigned64, but with a decode expecting unsigned32. It appears that the latest dev branch of wireshark is better about this, but I haven't really looked to see how complete the fixes are. > If that might be the case, then a new IE is indicated. OTOH, if nobody > knows of such a possibility, then (2) might work equally as well. I can only speak for my implementation and I don't see 2 as a problem. However, as you pointed out implementations like wireshark are known to have had issues with similar changes in the past. That said I'm not sure how much weight I give to wireshark's IPFIX implementation. Last time I looked wireshark didn't handle other protocol details like template IDs that change after an exporter reboot. I still like option 2, but could be persuaded that 3 is the better option. -Andrew > > P. > > >> On 07/19/2013 10:01 AM, Paul Aitken wrote: >>> Brian, >>> >>> So we have at least 3 solutions. We need a wider audience and >>> feedback from collector vendors. >>> >>> P. >>> >>> >>> On 19/07/13 14:51, Brian Trammell wrote: >>>> Hi Paul, >>>> >>>> Inline, sent from my iPhone >>>> >>>> On 19.07.2013, at 15:26, Paul Aitken wrote: >>>> >>>>> Brian, >>>>> >>>>>> hi Paul, >>>>>> >>>>>> another idea inline. >>>>>> >>>>>> On 19 Jul 2013, at 14:48 , Paul Aitken wrote: >>>>>>>>> Q2: how should the ECN Nonce Sum be reported? >>>>>>>> My suggestion would be to define this field as an unsigned16: >>>>>>>> >>>>>>>> MSb LSb >>>>>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>>>>> | | N | C | E | U | A | P | R | S >>>>>>>> | F | >>>>>>>> | Reserved | S | W | C | R | C | S | S | Y >>>>>>>> | I | >>>>>>>> | | | R | E | G | K | H | T | N >>>>>>>> | N | >>>>>>>> +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>>>>> >>>>>>>> with a specific note that when the IE is encoded as an >>>>>>>> unsigned8 using reduced-length encoding, it has the following >>>>>>>> layout: >>>>>>>> >>>>>>>> MSb LSb >>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>> | C | E | U | A | P | R | S | F | >>>>>>>> | W | C | R | C | S | S | Y | I | >>>>>>>> | R | E | G | K | H | T | N | N | >>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>> >>>>>>>> and a further specific note that Collecting Processes should >>>>>>>> not assume that CWR and ECE were not set simply because they're >>>>>>>> exported as 0, as previous revisions of the Information Element >>>>>>>> did not include them. >>>>>>>> >>>>>>>> Yes, it's kludgy, but it has the advantage of describing the >>>>>>>> reality of the status quo. >>>>>>> I'm happy with that, except for enlarging the size from u8 to >>>>>>> u16. Is that acceptable to collectors? >>>>>> As far as I can tell, that's the only open question. >>>>>> >>>>>> Another possibility: expand this one to the full 8 bits (with a >>>>>> note about CWR and ECE being potentially unsupported by old EPs), >>>>>> and define a new unsigned8 IE for the high four bits of the >>>>>> increasingly inaccurately named TCP flags byte, to futureproof >>>>>> against use of those three bits. >>>>>> >>>>>> This has the advantage of having the same record encoding as the >>>>>> unsigned16 version (if you follow tcpHighControlFlags with >>>>>> tcpControlFlags in the template) at the expense of 4 extra >>>>>> template bytes, while not having any possibility to break >>>>>> collectors that aren't expecting it. >>>>> Yes, that would work too. >>>>> >>>>> It'd be slightly more efficient to define the new field as u16 >>>>> containing all the bits, and export either/or. >>>>> >>>>> A collector update is required either way... >>>> Not if an exporter that's ECN Nonce aware is exporting to a >>>> collector that isn't; in that case, it gets the low 8 bits from the >>>> tcpControlBits and the ignores the high four (one) as an unknown IE. >>>> >>>> Cheers B >>> >>> _______________________________________________ >>> IPFIX mailing list >>> IPFIX@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipfix > From paitken@cisco.com Tue Jul 23 06:07:59 2013 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 A1A7921E8064 for ; Tue, 23 Jul 2013 06:07:59 -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 ALrFItpAP2e4 for ; Tue, 23 Jul 2013 06:07:53 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0D82F11E81DB for ; Tue, 23 Jul 2013 06:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4173; q=dns/txt; s=iport; t=1374584869; x=1375794469; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NBVGneYK0BFPcmwaSH9ZbDsqyXsok9LfNYGcIIIUdOM=; b=JsWBeyzvYIY1M6lZ+nzHbb6Jo/uZrkWrG6sK3h/48gYvz+9humBCMXy6 7J3Db/+AoVJ8+j6EWJsuIprgJemrXccCfElkbiR/fcR9uQUT9yMv5jFqz aZDn7B1ajDCHowDPerO8ztfKwDzfOHztO540omhk68BJ4nIBTMxwh9JRA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAIV/7lGQ/khL/2dsb2JhbABbgwbBP4ERFnSCJAEBAQMBODQKAgEFCwshFg8JAwIBAgFFBg0BBwEBiAYGuE+QEweDfgOUBoNXhiOLKoMT X-IronPort-AV: E=Sophos;i="4.89,727,1367971200"; d="scan'208";a="16342688" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 23 Jul 2013 13:07:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6ND7fE7010362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 13:07:41 GMT Received: from [144.254.153.45] (dhcp-144-254-153-45.cisco.com [144.254.153.45]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6ND7eoI003996; Tue, 23 Jul 2013 14:07:40 +0100 (BST) Message-ID: <51EE8020.6090000@cisco.com> Date: Tue, 23 Jul 2013 14:07:44 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andrew Feren References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> <51E93E76.4010802@cisco.com> <8B26930D-79A9-43F9-9C68-B783C9DF4557@tik.ee.ethz.ch> <51E946B2.4070702@cisco.com> <51ED54FE.9090300@plixer.com> <51ED81A7.1000805@cisco.com> <51EE7C78.1060503@plixer.com> In-Reply-To: <51EE7C78.1060503@plixer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] TCP flags? 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, 23 Jul 2013 13:07:59 -0000 Andrew, >> Another possibility was to add a new IE for the uppermost bits. In >> some cases the two IEs could be exported alongside each other, so the >> 16 bits would be in order (although that need not always be the case). > > I don't like the option of a new IE for just the high bits. If we > must create a new IE I think we should go all the way and take option > 3. Exporting the an IE for the high bits and the existing IE adjacent > to each other is cute, but seems like a lot of complexity for no real > gain. > > One other question. With this option would the semantics of the > existing IE change if both IEs are exported or would the ECE and CWR > bits just remain ambiguous? I guess all the bits would be defined. However, I like this less than option 2 or 3. >>> Assuming I got the above correct here are my thoughts. >>> >>> If we are going to make the changes for option 1 we might as well go >>> all the way to option 2. We've covered this before, but having >>> separate data types for different integer lengths is pretty much >>> pointless since the size is always exported in the template. From a >>> collector stand point I pretty much have to respect the length in >>> the template so increasing this to a unsigned 16 is no real work for >>> me. >> >> What I said before: changing the size doesn't actually change the >> type. Fundamentally we only have signed and unsigned, in various >> sizes. If we'd recognised this years ago, we wouldn't need the >> "reduced size encoding" rule; collectors would just accept whatever >> the templates tell them. >> >> >>> The only real difference I see between options 2 and 3 is that the >>> reduced size encoding for option 2 will always be ambiguous for two >>> bits. I don't yet have an opinion on how big a deal that is. Can we >>> increase the size of the current TCP flags and deprecate the export >>> of the reduced size encoding? >> >> That could work. However, existing implementations would continue to >> export 8 bits, where the top 2 bits are ambiguous. > > That is true regardless of what option we ultimately decide on. > >> >> >>> I currently have a very slight preference for option 2 (with or >>> without deprecating reduced size encoding), but there is still a >>> quite, but persistent, voice in the back of my head saying option 3 >>> is "the right thing". >> >> Is it possible that some collectors might break if they receive a >> field with a different size from what 5102 / IANA says? eg, there was >> a problem with old versions of wireshark where it had built-in >> expectations of field sizes, and couldn't cope with the change of >> sampler ID from 8 bits to 16 bits to 32 bits. > > This is a more general issue for wireshark than just sampler ID. Any > IE sent with reduced size encoding was liable to blow things up. 8 > and 4 byte decodes were implemented for some IEs where people had run > into both encodings. Other sizes would still have caused issues. I > ran into this about a month ago for an IE specified as unsigned64, but > with a decode expecting unsigned32. It appears that the latest dev > branch of wireshark is better about this, but I haven't really looked > to see how complete the fixes are. > > >> If that might be the case, then a new IE is indicated. OTOH, if >> nobody knows of such a possibility, then (2) might work equally as well. > > I can only speak for my implementation and I don't see 2 as a > problem. However, as you pointed out implementations like wireshark > are known to have had issues with similar changes in the past. That > said I'm not sure how much weight I give to wireshark's IPFIX > implementation. Last time I looked wireshark didn't handle other > protocol details like template IDs that change after an exporter reboot. Wireshark's dissector has improved, but I think it needs completely rewritten by someone who's actually familiar with netflow and IPFIX. > I still like option 2, but could be persuaded that 3 is the better option. +1 Does anyone object to option 2? P. From trammell@tik.ee.ethz.ch Tue Jul 23 06:09:27 2013 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 8E48811E81DB for ; Tue, 23 Jul 2013 06:09:27 -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 Zu7UCJUWSg0C for ; Tue, 23 Jul 2013 06:09:22 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 71EA721E8064 for ; Tue, 23 Jul 2013 06:09:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B2B7BD930B; Tue, 23 Jul 2013 15:09:17 +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 drjNZWg-ZphW; Tue, 23 Jul 2013 15:09:17 +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 7BDA8D9305; Tue, 23 Jul 2013 15:09:17 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <51EE7C78.1060503@plixer.com> Date: Tue, 23 Jul 2013 15:09:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> <51E93E76.4010802@cisco.com> <8B26930D-79A9-43F9-9C68-B783C9DF4557@tik.ee.ethz.ch> <51E946B2.4070702@cisco.com> <51ED54FE.9090300@plixer.com> <51ED81A7.1000805@cisco.com> <51EE7C78.1060503@plixer.com> To: Andrew Feren X-Mailer: Apple Mail (2.1508) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] TCP flags? 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, 23 Jul 2013 13:09:27 -0000 hi Andrew, Paul, On 23 Jul 2013, at 14:52 , Andrew Feren wrote: > Hi Paul, >=20 > On 07/22/2013 03:01 PM, Paul Aitken wrote: >> Andrew, >>=20 >>> Hi all, >>>=20 >>> I've been on vacation so let me recap and make sure I have all the = options straight. >>>=20 >>> Options >>> 1) add ECE and CWR bits to the current definition with a note that " = Collecting Processes should not assume that CWR and ECE were not set = simply because they're exported as 0, as previous revisions of the = Information Element did not include them". >>>=20 >>> 2) update the current definition to unsigned 16 with similar wording = to option 1 if the 8bit reduced size encoding is exported. Using the = extended 16 bits would allow the export of ECN Nonce Sum and remove the = ambiguity about CWR and ECE that exists in the 8 bit export. >>>=20 >>> 3) Deprecate current IE and replace it with a new 16 bit IE. >>=20 >> Another possibility was to add a new IE for the uppermost bits. In = some cases the two IEs could be exported alongside each other, so the 16 = bits would be in order (although that need not always be the case). >=20 > I don't like the option of a new IE for just the high bits. If we = must create a new IE I think we should go all the way and take option 3. = Exporting the an IE for the high bits and the existing IE adjacent to = each other is cute, but seems like a lot of complexity for no real gain. Point. One thing to consider: we're talking here about the passive observation = of ECN, which we hope becomes more interesting as ECN deployment and = activation continues, but at the moment is kind of a backwater. While an = increasing number of ECN capable hosts exist (per Kuhlewind, Neuner, = Trammell, "On the state of ECN and TCP Options in the Internet", PAM = 2013, about 30% of the Alexa Top 100k list will happily negotiate ECN = with you as of August 2012, and that number is increasing), the servers = are defaulting to "ECN on request", but most clients don't request it, = so you don't see much ECN actually used (in the same paper, we saw about = the same amount of ECN negotiation, passively observed, as we did = persistent misuse of the ECT bits in the IP header; since we were using = good old-fashioned ("Inflexible"?) NetFlow, we didn't see the ECE or CWR = bits here.) One would presume that ECN Nonce only gets used if ECN does, = and the ECN Nonce flag doesn't imply calculation of correct nonces, just = that ECN Nonce was activated on the flow and the nonce sum was once odd. > One other question. With this option would the semantics of the = existing IE change if both IEs are exported or would the ECE and CWR = bits just remain ambiguous? One could assume that if an Exporter exports tcpHighControlFlags, that = CWR and ECE are also valid. We can make that same assertion about = exporting tcpControlFlags as an unsigned16, though. >>=20 >>> Assuming I got the above correct here are my thoughts. >>>=20 >>> If we are going to make the changes for option 1 we might as well go = all the way to option 2. We've covered this before, but having separate = data types for different integer lengths is pretty much pointless since = the size is always exported in the template. =46rom a collector stand = point I pretty much have to respect the length in the template so = increasing this to a unsigned 16 is no real work for me. >>=20 >> What I said before: changing the size doesn't actually change the = type. Fundamentally we only have signed and unsigned, in various sizes. = If we'd recognised this years ago, we wouldn't need the "reduced size = encoding" rule; collectors would just accept whatever the templates tell = them. >>=20 >>=20 >>> The only real difference I see between options 2 and 3 is that the = reduced size encoding for option 2 will always be ambiguous for two = bits. I don't yet have an opinion on how big a deal that is. Can we = increase the size of the current TCP flags and deprecate the export of = the reduced size encoding? >>=20 >> That could work. However, existing implementations would continue to = export 8 bits, where the top 2 bits are ambiguous. >=20 > That is true regardless of what option we ultimately decide on. An updated IE definition noting this ambiguity in the description, is, I = think, necessary (no matter what). >>=20 >>=20 >>> I currently have a very slight preference for option 2 (with or = without deprecating reduced size encoding), but there is still a quite, = but persistent, voice in the back of my head saying option 3 is "the = right thing". >>=20 >> Is it possible that some collectors might break if they receive a = field with a different size from what 5102 / IANA says? eg, there was a = problem with old versions of wireshark where it had built-in = expectations of field sizes, and couldn't cope with the change of = sampler ID from 8 bits to 16 bits to 32 bits. >=20 > This is a more general issue for wireshark than just sampler ID. Any = IE sent with reduced size encoding was liable to blow things up. 8 and = 4 byte decodes were implemented for some IEs where people had run into = both encodings. Other sizes would still have caused issues. I ran into = this about a month ago for an IE specified as unsigned64, but with a = decode expecting unsigned32. It appears that the latest dev branch of = wireshark is better about this, but I haven't really looked to see how = complete the fixes are. >> If that might be the case, then a new IE is indicated. OTOH, if = nobody knows of such a possibility, then (2) might work equally as well. >=20 > I can only speak for my implementation and I don't see 2 as a problem. = However, as you pointed out implementations like wireshark are known to = have had issues with similar changes in the past. That said I'm not = sure how much weight I give to wireshark's IPFIX implementation. Last = time I looked wireshark didn't handle other protocol details like = template IDs that change after an exporter reboot. I've got on my list of things to do in my copious free time having a = look at improving the wireshark dissector for IPFIX. I mainly use ripfix = / python-ipfix for debugging IPFIX because of bad experiences with the = wireshark dissector years ago, and I wasn't aware that anyone was trying = to use it / that it was still maintained at all. > I still like option 2, but could be persuaded that 3 is the better = option. Option 2 would be my preferred option; Option 3 (deprecation) seems like = a whole lot of procedural effort (especially when at least n EP vendors = are already exporting the high two bits regardless of the spec). The = tcpHighControlBits option was a hack I proposed in case option 2 was = somehow unacceptable. Cheers, Brian >>> On 07/19/2013 10:01 AM, Paul Aitken wrote: >>>> Brian, >>>>=20 >>>> So we have at least 3 solutions. We need a wider audience and = feedback from collector vendors. >>>>=20 >>>> P. >>>>=20 >>>>=20 >>>> On 19/07/13 14:51, Brian Trammell wrote: >>>>> Hi Paul, >>>>>=20 >>>>> Inline, sent from my iPhone >>>>>=20 >>>>> On 19.07.2013, at 15:26, Paul Aitken wrote: >>>>>=20 >>>>>> Brian, >>>>>>=20 >>>>>>> hi Paul, >>>>>>>=20 >>>>>>> another idea inline. >>>>>>>=20 >>>>>>> On 19 Jul 2013, at 14:48 , Paul Aitken = wrote: >>>>>>>>>> Q2: how should the ECN Nonce Sum be reported? >>>>>>>>> My suggestion would be to define this field as an unsigned16: >>>>>>>>>=20 >>>>>>>>> MSb LSb >>>>>>>>> = +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>>>>>> | | N | C | E | U | A | P | R | S = | F | >>>>>>>>> | Reserved | S | W | C | R | C | S | S | Y = | I | >>>>>>>>> | | | R | E | G | K | H | T | N = | N | >>>>>>>>> = +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ >>>>>>>>>=20 >>>>>>>>> with a specific note that when the IE is encoded as an = unsigned8 using reduced-length encoding, it has the following layout: >>>>>>>>>=20 >>>>>>>>> MSb LSb >>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>> | C | E | U | A | P | R | S | F | >>>>>>>>> | W | C | R | C | S | S | Y | I | >>>>>>>>> | R | E | G | K | H | T | N | N | >>>>>>>>> +---+---+---+---+---+---+---+---+ >>>>>>>>>=20 >>>>>>>>> and a further specific note that Collecting Processes should = not assume that CWR and ECE were not set simply because they're exported = as 0, as previous revisions of the Information Element did not include = them. >>>>>>>>>=20 >>>>>>>>> Yes, it's kludgy, but it has the advantage of describing the = reality of the status quo. >>>>>>>> I'm happy with that, except for enlarging the size from u8 to = u16. Is that acceptable to collectors? >>>>>>> As far as I can tell, that's the only open question. >>>>>>>=20 >>>>>>> Another possibility: expand this one to the full 8 bits (with a = note about CWR and ECE being potentially unsupported by old EPs), and = define a new unsigned8 IE for the high four bits of the increasingly = inaccurately named TCP flags byte, to futureproof against use of those = three bits. >>>>>>>=20 >>>>>>> This has the advantage of having the same record encoding as the = unsigned16 version (if you follow tcpHighControlFlags with = tcpControlFlags in the template) at the expense of 4 extra template = bytes, while not having any possibility to break collectors that aren't = expecting it. >>>>>> Yes, that would work too. >>>>>>=20 >>>>>> It'd be slightly more efficient to define the new field as u16 = containing all the bits, and export either/or. >>>>>>=20 >>>>>> A collector update is required either way... >>>>> Not if an exporter that's ECN Nonce aware is exporting to a = collector that isn't; in that case, it gets the low 8 bits from the = tcpControlBits and the ignores the high four (one) as an unknown IE. >>>>>=20 >>>>> Cheers B >>>>=20 >>>> _______________________________________________ >>>> IPFIX mailing list >>>> IPFIX@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipfix >>=20 From paitken@cisco.com Tue Jul 23 06:32:02 2013 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 04E9D11E8108 for ; Tue, 23 Jul 2013 06:32:02 -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 8mxnNcyMiUIf for ; Tue, 23 Jul 2013 06:31:56 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E5BC211E80AE for ; Tue, 23 Jul 2013 06:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=934; q=dns/txt; s=iport; t=1374586316; x=1375795916; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hMSIiYHDMD+E7qKWu0225nF8Vs8BclDu5eRZFEuTUqs=; b=cJrzNfNTTE1MWkMqLBawo0OK00NKrH/ZenkwgUaA/07pb8x8798MEh1g uHY2SMCES95HL9NF23A0txJhDPNbqWJGY4QX0VZTEbh+1D+yew4p0aEnY 87UaVEwNA2pnetM2r2YbyGATP9sV8b5h3Tm6xgxjJXZKarboMvapmRwKo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAHOE7lGQ/khR/2dsb2JhbABbgwbBP4ESFnSCJAEBAQMBOEABBQsLIRYPCQMCAQIBRQYNAQcBAYgGBrhSkBMHg34Dl12GI4sqgxM X-IronPort-AV: E=Sophos;i="4.89,727,1367971200"; d="scan'208";a="15869966" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 23 Jul 2013 13:31:54 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6NDVpsV014838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Jul 2013 13:31:52 GMT Received: from [144.254.153.45] (dhcp-144-254-153-45.cisco.com [144.254.153.45]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6NDVpaH005755; Tue, 23 Jul 2013 14:31:51 +0100 (BST) Message-ID: <51EE85CA.7090602@cisco.com> Date: Tue, 23 Jul 2013 14:31:54 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Trammell References: <51E92E5A.7040401@cisco.com> <51E935AC.3090706@cisco.com> <4AF5348D-1A76-4791-A6BD-C8B50C6B5E8A@tik.ee.ethz.ch> <51E93E76.4010802@cisco.com> <8B26930D-79A9-43F9-9C68-B783C9DF4557@tik.ee.ethz.ch> <51E946B2.4070702@cisco.com> <51ED54FE.9090300@plixer.com> <51ED81A7.1000805@cisco.com> <51EE7C78.1060503@plixer.com> 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] TCP flags? 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, 23 Jul 2013 13:32:02 -0000 Brian, > 've got on my list of things to do in my copious free time having a look at improving the wireshark dissector for IPFIX. +1 > I mainly use ripfix / python-ipfix for debugging IPFIX because of bad experiences with the wireshark dissector years ago, and I wasn't aware that anyone was trying to use it / that it was still maintained at all. I do - though I'm aware of several caveats and don't blindly trust what wireshark says. >> I still like option 2, but could be persuaded that 3 is the better option. > Option 2 would be my preferred option; Option 3 (deprecation) seems like a whole lot of procedural effort (especially when at least n EP vendors are already exporting the high two bits regardless of the spec). The tcpHighControlBits option was a hack I proposed in case option 2 was somehow unacceptable. +1 I'm reading this as 3 votes for option 2: extended the existing IE to 16 bits. From ietf-secretariat-reply@ietf.org Wed Jul 24 11:13:02 2013 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 BA59811E8125 for ; Wed, 24 Jul 2013 11:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 UUR-+aSRyMmA for ; Wed, 24 Jul 2013 11:13:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D7F11E8233 for ; Wed, 24 Jul 2013 11:13:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: ipfix@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130724181302.19600.61943.idtracker@ietfa.amsl.com> Date: Wed, 24 Jul 2013 11:13:02 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 24 Jul 2013 15:12:40 -0700 Subject: [IPFIX] Milestones changed for ipfix WG 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, 24 Jul 2013 18:13:02 -0000 Changed milestone "Submit Internet-Draft on IP Flow Export Applicability Statement", set due date to December 2002 from December 2002. Changed milestone "Select IPFIX protocol, revise Architecture and Data Model drafts", set due date to February 2003 from February 2003. Changed milestone "Submit IPFX-REQUIREMENTS to IESG for publication as Informational RFC", set due date to April 2003 from April 2003. Changed milestone "Submit IPFIX Protocol Evaluation Report to IESG for publication as Informational RFC", set due date to May 2004 from May 2004. Changed milestone "Publish Internet Draft on IPFIX Implementation Guidelines", set due date to August 2006 from August 2006. Changed milestone "Publish Internet Draft on IPFIX Testing", set due date to August 2006 from August 2006. Changed milestone "Publish Internet Draft on Reducing Redundancy in IPFIX data transfer", set due date to August 2006 from August 2006. Changed milestone "Publish Internet Draft on IPFIX MIB", set due date to August 2006 from August 2006. Changed milestone "Publish Internet Draft on Handling IPFIX Bidirectional Flows", set due date to August 2006 from August 2006. Changed milestone "Submit IPFIX Biflows draft to IESG for publication as Standards Track RFC", set due date to March 2007 from March 2007. Changed milestone "Publish Internet draft on IPFIX Type Information Export", set due date to December 2007 from December 2007. Changed milestone "Publish Internet draft on IPFIX Configuration Data Model", set due date to December 2007 from December 2007. Changed milestone "Publish Internet draft on IPFIX File Format", set due date to December 2007 from December 2007. Changed milestone "Publish Internet draft on Single SCTP Stream Reporting", set due date to December 2007 from December 2007. Changed milestone "Publish Internet draft on IPFIX Mediation Problem Statement", set due date to January 2008 from January 2008. Changed milestone "Submit File Format draft to IESG for publication as Standards track RFC", set due date to January 2008 from January 2008. Changed milestone "Submit IPFIX MIB draft to IESG for publication as Standards track RFC", set due date to March 2008 from March 2008. Changed milestone "Submit Single SCTP Stream draft to IESG for publication as Informational RFC", set due date to January 2009 from January 2009. Changed milestone "Submit Mediation Problem Statement I-D to IESG for publication as Informational RFC", set due date to October 2009 from October 2009. Changed milestone "Submit initial draft on anonymization support", set due date to October 2009 from October 2009. Changed milestone "Submit initial draft on flow selection", set due date to October 2009 from October 2009. Changed milestone "Submit initial draft on structuring information elements", set due date to October 2009 from October 2009. Changed milestone "Submit final version of PSAMP MIB module", set due date to August 2010 from August 2010. Changed milestone "Submit Configuration Data Model draft to IESG for publication as Standards track RFC", set due date to August 2010 from August 2010. Changed milestone "Submit Mediation Framework I-D to IESG for publication as Informational RFC", set due date to August 2010 from August 2010. Changed milestone "Submit anonymization support I-D to IESG for publication as Experimental RFC", set due date to October 2010 from October 2010. Changed milestone "Submit structuring information elements I-D to IESG for publication as Standards Track RFC", set due date to December 2010 from December 2010. Changed milestone "Publish Internet-Draft on guidelines for IE developers and Reviewers", set due date to November 2011 from November 2011. Changed milestone "Publish Internet-Draft on IPFIX use at mediators", set due date to November 2011 from November 2011. Changed milestone "Publish Internet-Draft on intermediate aggregation", set due date to November 2011 from November 2011. Changed milestone "Publish Internet-Draft on exporting MIB objects", set due date to November 2011 from November 2011. Changed milestone "Publish Internet-Draft on data link IEs", set due date to November 2011 from November 2011. Changed milestone "Publish Internet-Draft revising RFC 5101", set due date to December 2011 from December 2011. Changed milestone "Publish Internet-Draft revising RFC 5102", set due date to December 2011 from December 2011. Changed milestone "Submit flow selection I-D to IESG for publication as Standards Track RFC", set due date to December 2011 from December 2011. Changed milestone "Submit guidelines for IE developers and reviewers for publication as Informational BCP RFC", set due date to April 2012 from April 2012. Changed milestone "Submit revised IPFIX MIB for publications as Standards track RFC", set due date to April 2012 from April 2012. Changed milestone "Submit intermediate aggregation for publication as Standards track RFC", set due date to October 2012 from October 2012. Changed milestone "Submit data link IEs for publication as Standards track RFC", set due date to February 2013 from February 2013. Changed milestone "Submit IPFIX use at mediators for publication as Standards track RFC", set due date to April 2013 from April 2013. Changed milestone "Submit revised RFC 5101 for publication as Standards track RFC", set due date to April 2013 from April 2013, resolved as "Done". Changed milestone "Submit revised RFC 5102 for publication as Standards track RFC", set due date to April 2013 from April 2013. URL: http://datatracker.ietf.org/wg/ipfix/charter/ From wwwrun@rfc-editor.org Fri Jul 26 13:26:30 2013 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 84B8E11E80FB for ; Fri, 26 Jul 2013 13:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 F+9J5tu8paSx for ; Fri, 26 Jul 2013 13:26:30 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D64211E814F for ; Fri, 26 Jul 2013 13:26:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F1648B1E004; Fri, 26 Jul 2013 13:23:18 -0700 (PDT) To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20130726202318.F1648B1E004@rfc-editor.org> Date: Fri, 26 Jul 2013 13:23:18 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5655 (3687) 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: Fri, 26 Jul 2013 20:26:30 -0000 The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3687 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: 8.1.4 Original Text ------------- | messageScope [scope] | A marker denoting this Option | | | applies to the whole IPFIX message; | | | content is ignored. Corrected Text -------------- | messageScope [scope] | A marker denoting this Option | | | applies to the whole IPFIX Message; | | | content is ignored. Notes ----- s/IPFIX message/IPFIX Message/ - because that's the technical term defined in RFC5101 to which this draft refers Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Jul 26 13:28:06 2013 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 A2D8711E815B for ; Fri, 26 Jul 2013 13:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Uwh-ZclOBL7o for ; Fri, 26 Jul 2013 13:28:06 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C907411E80FB for ; Fri, 26 Jul 2013 13:28:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B9C14B1E004; Fri, 26 Jul 2013 13:24:54 -0700 (PDT) To: brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name, bclaise@cisco.com, joelja@bogus.com, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20130726202454.B9C14B1E004@rfc-editor.org> Date: Fri, 26 Jul 2013 13:24:54 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Technical Errata Reported] RFC5655 (3688) 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: Fri, 26 Jul 2013 20:28:06 -0000 The following errata report has been submitted for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3688 -------------------------------------- Type: Technical Reported by: Paul Aitken Section: B.1.1 Original Text ------------- Export Time: Aside from being called UNIX Secs in the NetFlow V9 packet header specification, the export time in seconds since 1 January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX message headers. Corrected Text -------------- Export Time: Aside from being called UNIX Secs in the NetFlow V9 packet header specification, the export time in seconds since 1 January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX Message headers. Notes ----- s/IPFIX message/IPFIX Message/ - because that's the technical term defined in RFC5101 to which this draft refers Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From trammell@tik.ee.ethz.ch Fri Jul 26 14:43:03 2013 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 6576C11E8162 for ; Fri, 26 Jul 2013 14:43:03 -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 XWi8PcZgrGmF for ; Fri, 26 Jul 2013 14:42:58 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B2C1411E8150 for ; Fri, 26 Jul 2013 14:42:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8E667D9309; Fri, 26 Jul 2013 23:42:54 +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 3e8hx11oy4ie; Fri, 26 Jul 2013 23:42:54 +0200 (MEST) Received: from zephyr.intern (unknown [213.23.104.157]) (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 D3E3FD9308; Fri, 26 Jul 2013 23:42:53 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <20130726202318.F1648B1E004@rfc-editor.org> Date: Fri, 26 Jul 2013 23:42:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02D2E711-41F9-45FB-A84F-82D338E09F31@tik.ee.ethz.ch> References: <20130726202318.F1648B1E004@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1508) Cc: ipfix@ietf.org, joelja@bogus.com, Nevil Brownlee , Tanja Zseby , Arno Wagner Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (3687) 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: Fri, 26 Jul 2013 21:43:03 -0000 Greetings, all,=20 Apparently, this erratum was filed with the incorrect type ("Technical" = as opposed to "Editorial"); I recommend correction of the type, or that = the erratum be rejected and refiled with the proper status. Regards, Brian On 26 Jul 2013, at 22:23, RFC Errata System = wrote: > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D3687 >=20 > -------------------------------------- > Type: Technical > Reported by: Paul Aitken >=20 > Section: 8.1.4 >=20 > Original Text > ------------- > | messageScope [scope] | A marker denoting this Option = | > | | applies to the whole IPFIX message; = | > | | content is ignored. >=20 > Corrected Text > -------------- > | messageScope [scope] | A marker denoting this Option = | > | | applies to the whole IPFIX Message; = | > | | content is ignored. >=20 > Notes > ----- > s/IPFIX message/IPFIX Message/ >=20 > - because that's the technical term defined in RFC5101 to which this = draft refers >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Fri Jul 26 14:43:43 2013 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 F27A311E8177 for ; Fri, 26 Jul 2013 14:43:42 -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 vE8dH5L9PdX6 for ; Fri, 26 Jul 2013 14:43: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 50F0211E8150 for ; Fri, 26 Jul 2013 14:43:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 95FB4D9309; Fri, 26 Jul 2013 23:43: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 aJb2rDdS9yFz; Fri, 26 Jul 2013 23:43:37 +0200 (MEST) Received: from zephyr.intern (unknown [213.23.104.157]) (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 DA47DD9308; Fri, 26 Jul 2013 23:43:35 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <20130726202454.B9C14B1E004@rfc-editor.org> Date: Fri, 26 Jul 2013 23:43:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47ED2CD8-DA05-4D87-8208-50648889DCD6@tik.ee.ethz.ch> References: <20130726202454.B9C14B1E004@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1508) Cc: "ipfix@ietf.org Working Group" , "joelja@bogus.com jaeggli" , Nevil Brownlee , Tanja Zseby , Arno Wagner Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (3688) 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: Fri, 26 Jul 2013 21:43:43 -0000 Greetings, all,=20 As with the other erratum on 5655, this erratum was filed with the = incorrect type ("Technical" as opposed to "Editorial"); I recommend = correction of the type, or that the erratum be rejected and refiled with = the proper status. Regards, Brian On 26 Jul 2013, at 22:24, RFC Errata System = wrote: > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D3688 >=20 > -------------------------------------- > Type: Technical > Reported by: Paul Aitken >=20 > Section: B.1.1 >=20 > Original Text > ------------- > Export Time: Aside from being called UNIX Secs in the NetFlow V9 > packet header specification, the export time in seconds since 1 > January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX > message headers. >=20 > Corrected Text > -------------- > Export Time: Aside from being called UNIX Secs in the NetFlow V9 > packet header specification, the export time in seconds since 1 > January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX > Message headers. >=20 > Notes > ----- > s/IPFIX message/IPFIX Message/ >=20 > - because that's the technical term defined in RFC5101 to which this = draft refers >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Fri Jul 26 15:02:32 2013 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 80B9111E816E for ; Fri, 26 Jul 2013 15:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.321 X-Spam-Level: X-Spam-Status: No, score=-10.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 PBzEE1Y5FuC5 for ; Fri, 26 Jul 2013 15:02:27 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4A24A11E8162 for ; Fri, 26 Jul 2013 15:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2752; q=dns/txt; s=iport; t=1374876147; x=1376085747; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4Yh7FeEfZHe9+wp6idnAR+IZpFNvPXnxeGK9VQ7hMoY=; b=mgK1i3rl84CVlfFXXJcThoLLovclVlM0V+hU5T9QiAMdZHhQuoks+Map XXlYYLZeCoQ0hI9SvMnq46k8dNW7n2J2mLl+EEN1Mx704mk0xFAYHbGRm kOthA6o6lUFw/CnvAvU2gC7vUfSzAcxWCZwpecPYtdnQEkfs//p+mbE/V E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AggFAD7x8lGQ/khL/2dsb2JhbABBGoMGNb4sgRkWdIIkAQEBBAEBATU2CgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIDAwzuD+PfQeEBQOXX4YjiymDFXk X-IronPort-AV: E=Sophos;i="4.89,729,1367971200"; d="scan'208";a="16045052" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 26 Jul 2013 22:02:25 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6QM2NLa011206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Jul 2013 22:02:24 GMT Received: from [10.61.94.60] (ams3-vpn-dhcp7741.cisco.com [10.61.94.60]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6QM2LvW013977; Fri, 26 Jul 2013 23:02:22 +0100 (BST) Message-ID: <51F2F1ED.6020809@cisco.com> Date: Fri, 26 Jul 2013 23:02:21 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Trammell References: <20130726202318.F1648B1E004@rfc-editor.org> <02D2E711-41F9-45FB-A84F-82D338E09F31@tik.ee.ethz.ch> In-Reply-To: <02D2E711-41F9-45FB-A84F-82D338E09F31@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org, joelja@bogus.com, Nevil Brownlee , Tanja Zseby , Arno Wagner , RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (3687) 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: Fri, 26 Jul 2013 22:02:32 -0000 Brian, I believe it's a technical error, because "IPFIX Message" is a defined term in the RFC 5101 terminology. P. On 26/07/13 22:42, Brian Trammell wrote: > Greetings, all, > > Apparently, this erratum was filed with the incorrect type ("Technical" as opposed to "Editorial"); I recommend correction of the type, or that the erratum be rejected and refiled with the proper status. > > Regards, > > Brian > > On 26 Jul 2013, at 22:23, RFC Errata System wrote: > >> The following errata report has been submitted for RFC5655, >> "Specification of the IP Flow Information Export (IPFIX) File Format". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3687 >> >> -------------------------------------- >> Type: Technical >> Reported by: Paul Aitken >> >> Section: 8.1.4 >> >> Original Text >> ------------- >> | messageScope [scope] | A marker denoting this Option | >> | | applies to the whole IPFIX message; | >> | | content is ignored. >> >> Corrected Text >> -------------- >> | messageScope [scope] | A marker denoting this Option | >> | | applies to the whole IPFIX Message; | >> | | content is ignored. >> >> Notes >> ----- >> s/IPFIX message/IPFIX Message/ >> >> - because that's the technical term defined in RFC5101 to which this draft refers >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5655 (draft-ietf-ipfix-file-05) >> -------------------------------------- >> Title : Specification of the IP Flow Information Export (IPFIX) File Format >> Publication Date : October 2009 >> Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> 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 From bclaise@cisco.com Fri Jul 26 15:25:44 2013 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 DBFA911E8182 for ; Fri, 26 Jul 2013 15:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.547 X-Spam-Level: X-Spam-Status: No, score=-10.547 tagged_above=-999 required=5 tests=[AWL=0.051, 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 Oj26UhhsbMay for ; Fri, 26 Jul 2013 15:25:40 -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 7F98911E818A for ; Fri, 26 Jul 2013 15:25:40 -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 r6QMPORd007569; Sat, 27 Jul 2013 00:25:24 +0200 (CEST) Received: from [10.61.214.14] ([10.61.214.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6QMNaFs028083; Sat, 27 Jul 2013 00:23:57 +0200 (CEST) Message-ID: <51F2F6CF.6030503@cisco.com> Date: Sat, 27 Jul 2013 00:23:11 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Trammell References: <20130726202318.F1648B1E004@rfc-editor.org> <02D2E711-41F9-45FB-A84F-82D338E09F31@tik.ee.ethz.ch> In-Reply-To: <02D2E711-41F9-45FB-A84F-82D338E09F31@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------080806060507020400040204" Cc: ipfix@ietf.org, joelja@bogus.com, Nevil Brownlee , Tanja Zseby , Arno Wagner , RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (3687) 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: Fri, 26 Jul 2013 22:25:45 -0000 This is a multi-part message in MIME format. --------------080806060507020400040204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Errata changed to "Editorial", and accepted as "Held for Document Update" Regards, Benoit* * > Greetings, all, > > Apparently, this erratum was filed with the incorrect type ("Technical" as opposed to "Editorial"); I recommend correction of the type, or that the erratum be rejected and refiled with the proper status. > > Regards, > > Brian > > On 26 Jul 2013, at 22:23, RFC Errata System wrote: > >> The following errata report has been submitted for RFC5655, >> "Specification of the IP Flow Information Export (IPFIX) File Format". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3687 >> >> -------------------------------------- >> Type: Technical >> Reported by: Paul Aitken >> >> Section: 8.1.4 >> >> Original Text >> ------------- >> | messageScope [scope] | A marker denoting this Option | >> | | applies to the whole IPFIX message; | >> | | content is ignored. >> >> Corrected Text >> -------------- >> | messageScope [scope] | A marker denoting this Option | >> | | applies to the whole IPFIX Message; | >> | | content is ignored. >> >> Notes >> ----- >> s/IPFIX message/IPFIX Message/ >> >> - because that's the technical term defined in RFC5101 to which this draft refers >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5655 (draft-ietf-ipfix-file-05) >> -------------------------------------- >> Title : Specification of the IP Flow Information Export (IPFIX) File Format >> Publication Date : October 2009 >> Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --------------080806060507020400040204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Errata changed to "Editorial", and accepted as "Held for Document Update"

Regards, Benoit
Greetings, all, 

Apparently, this erratum was filed with the incorrect type ("Technical" as opposed to "Editorial"); I recommend correction of the type, or that the erratum be rejected and refiled with the proper status.

Regards,

Brian

On 26 Jul 2013, at 22:23, RFC Errata System <rfc-editor@rfc-editor.org> wrote:


The following errata report has been submitted for RFC5655,
"Specification of the IP Flow Information Export (IPFIX) File Format".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3687

--------------------------------------
Type: Technical
Reported by: Paul Aitken <paitken@cisco.com>

Section: 8.1.4

Original Text
-------------
  | messageScope [scope]       | A marker denoting this Option        |
  |                            | applies to the whole IPFIX message;  |
  |                            | content is ignored.

Corrected Text
--------------
  | messageScope [scope]       | A marker denoting this Option        |
  |                            | applies to the whole IPFIX Message;  |
  |                            | content is ignored.

Notes
-----
s/IPFIX message/IPFIX Message/

- because that's the technical term defined in RFC5101 to which this draft refers

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5655 (draft-ietf-ipfix-file-05)
--------------------------------------
Title               : Specification of the IP Flow Information Export (IPFIX) File Format
Publication Date    : October 2009
Author(s)           : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------080806060507020400040204-- From bclaise@cisco.com Fri Jul 26 15:25:52 2013 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 D325511E8182 for ; Fri, 26 Jul 2013 15:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 uusVzcyhH6Z7 for ; Fri, 26 Jul 2013 15:25:48 -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 7222D11E818F for ; Fri, 26 Jul 2013 15:25:48 -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 r6QMPZoL007660; Sat, 27 Jul 2013 00:25:35 +0200 (CEST) Received: from [10.61.214.14] ([10.61.214.14]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r6QMNnx8028238; Sat, 27 Jul 2013 00:24:09 +0200 (CEST) Message-ID: <51F2F6DC.9000407@cisco.com> Date: Sat, 27 Jul 2013 00:23:24 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Brian Trammell References: <20130726202454.B9C14B1E004@rfc-editor.org> <47ED2CD8-DA05-4D87-8208-50648889DCD6@tik.ee.ethz.ch> In-Reply-To: <47ED2CD8-DA05-4D87-8208-50648889DCD6@tik.ee.ethz.ch> Content-Type: multipart/alternative; boundary="------------090104070801090806020605" Cc: "ipfix@ietf.org Working Group" , "joelja@bogus.com jaeggli" , Nevil Brownlee , Tanja Zseby , Arno Wagner , RFC Errata System Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (3688) 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: Fri, 26 Jul 2013 22:25:52 -0000 This is a multi-part message in MIME format. --------------090104070801090806020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Errata changed to "Editorial", and accepted as "Held for Document Update" Regards, Benoit* * > Greetings, all, > > As with the other erratum on 5655, this erratum was filed with the incorrect type ("Technical" as opposed to "Editorial"); I recommend correction of the type, or that the erratum be rejected and refiled with the proper status. > > Regards, > > Brian > > On 26 Jul 2013, at 22:24, RFC Errata System wrote: > >> The following errata report has been submitted for RFC5655, >> "Specification of the IP Flow Information Export (IPFIX) File Format". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3688 >> >> -------------------------------------- >> Type: Technical >> Reported by: Paul Aitken >> >> Section: B.1.1 >> >> Original Text >> ------------- >> Export Time: Aside from being called UNIX Secs in the NetFlow V9 >> packet header specification, the export time in seconds since 1 >> January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX >> message headers. >> >> Corrected Text >> -------------- >> Export Time: Aside from being called UNIX Secs in the NetFlow V9 >> packet header specification, the export time in seconds since 1 >> January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX >> Message headers. >> >> Notes >> ----- >> s/IPFIX message/IPFIX Message/ >> >> - because that's the technical term defined in RFC5101 to which this draft refers >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5655 (draft-ietf-ipfix-file-05) >> -------------------------------------- >> Title : Specification of the IP Flow Information Export (IPFIX) File Format >> Publication Date : October 2009 >> Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner >> Category : PROPOSED STANDARD >> Source : IP Flow Information Export >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > > --------------090104070801090806020605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Errata changed to "Editorial", and accepted as "Held for Document Update"

Regards, Benoit
Greetings, all, 

As with the other erratum on 5655, this erratum was filed with the incorrect type ("Technical" as opposed to "Editorial"); I recommend correction of the type, or that the erratum be rejected and refiled with the proper status.

Regards,

Brian

On 26 Jul 2013, at 22:24, RFC Errata System <rfc-editor@rfc-editor.org> wrote:


The following errata report has been submitted for RFC5655,
"Specification of the IP Flow Information Export (IPFIX) File Format".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=3688

--------------------------------------
Type: Technical
Reported by: Paul Aitken <paitken@cisco.com>

Section: B.1.1

Original Text
-------------
  Export Time:   Aside from being called UNIX Secs in the NetFlow V9
     packet header specification, the export time in seconds since 1
     January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX
     message headers.

Corrected Text
--------------
  Export Time:   Aside from being called UNIX Secs in the NetFlow V9
     packet header specification, the export time in seconds since 1
     January 1970 at 0000 UTC appears in both NetFlow V9 and IPFIX
     Message headers.

Notes
-----
s/IPFIX message/IPFIX Message/

- because that's the technical term defined in RFC5101 to which this draft refers

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5655 (draft-ietf-ipfix-file-05)
--------------------------------------
Title               : Specification of the IP Flow Information Export (IPFIX) File Format
Publication Date    : October 2009
Author(s)           : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner
Category            : PROPOSED STANDARD
Source              : IP Flow Information Export
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------090104070801090806020605-- From ietf-ipr@ietf.org Sat Jul 27 06:13:53 2013 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 160F521F9A44; Sat, 27 Jul 2013 06:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 j08-8XIXh2Vp; Sat, 27 Jul 2013 06:13:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A16621F9A1E; Sat, 27 Jul 2013 06:13:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: bclaise@cisco.com,paitken@cisco.com,j.schoenwaelder@jacobs-university.de X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130727131352.13619.42888.idtracker@ietfa.amsl.com> Date: Sat, 27 Jul 2013 06:13:52 -0700 Cc: ipfix@ietf.org, joelja@bogus.com, n.brownlee@auckland.ac.nz, ipr-announce@ietf.org Subject: [IPFIX] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ipfix-mib-variable-export-02 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, 27 Jul 2013 13:13:53 -0000 Dear Benoit Claise, Paul Aitken, J=C3=BCrgen Sch=C3=B6nw=C3=A4lder: An IPR disclosure that pertains to your Internet-Draft entitled "Exporting= MIB Variables using the IPFIX Protocol" (draft-ietf-ipfix-mib-variable-export) = was submitted to the IETF Secretariat on 2013-07-25 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2146/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-ipfix-mib-variable- export-02.""); The IETF Secretariat From internet-drafts@ietf.org Mon Jul 29 01:47:46 2013 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 0D5CD21F9F80; Mon, 29 Jul 2013 01:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 OJW2BJ+ByuPv; Mon, 29 Jul 2013 01:47:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D2121F9D98; Mon, 29 Jul 2013 01:47:38 -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.60p1 Message-ID: <20130729084738.32167.72890.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 01:47:38 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-06.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, 29 Jul 2013 08:47:46 -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 Group = of the IETF. Title : Operation of the IP Flow Information Export (IPFIX) Prot= ocol on IPFIX Mediators Author(s) : Benoit Claise Atsushi Kobayashi Brian Trammell Filename : draft-ietf-ipfix-mediation-protocol-06.txt Pages : 28 Date : 2013-07-29 Abstract: This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Mon Jul 29 02:16:38 2013 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 508CF21F99FA for ; Mon, 29 Jul 2013 02:16: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 hm5guJ56T9jV for ; Mon, 29 Jul 2013 02:16:33 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 5536221F9F01 for ; Mon, 29 Jul 2013 02:16:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id B73BFD930D for ; Mon, 29 Jul 2013 11:16:32 +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 d9MCyQmGDTrt for ; Mon, 29 Jul 2013 11:16:32 +0200 (MEST) Received: from dhcp-90be.meeting.ietf.org (dhcp-90be.meeting.ietf.org [130.129.8.190]) (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 85677D9304 for ; Mon, 29 Jul 2013 11:16:32 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <20130729084738.32167.72890.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 11:16:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130729084738.32167.72890.idtracker@ietfa.amsl.com> To: ipfix@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-06.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, 29 Jul 2013 09:16:38 -0000 Greetings, all, This is the -06 revision mentioned in the meeting (see slides for = deltas); we believe this revision addresses all WGLC comments and is = ready for the IESG. Best regards, Brian On 29 Jul 2013, at 10:47, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Flow Information Export Working = Group of the IETF. >=20 > Title : Operation of the IP Flow Information Export = (IPFIX) Protocol on IPFIX Mediators > Author(s) : Benoit Claise > Atsushi Kobayashi > Brian Trammell > Filename : draft-ietf-ipfix-mediation-protocol-06.txt > Pages : 28 > Date : 2013-07-29 >=20 > Abstract: > This document specifies the operation of the IP Flow Information > Export (IPFIX) protocol specific to IPFIX Mediators, including > Template and Observation Point management, timing considerations, = and > other Mediator-specific concerns. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-06 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From paitken@cisco.com Mon Jul 29 07:53:21 2013 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 6815111E80F0 for ; Mon, 29 Jul 2013 07:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.344 X-Spam-Level: X-Spam-Status: No, score=-10.344 tagged_above=-999 required=5 tests=[AWL=0.254, 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 25dCP8uf4hK3 for ; Mon, 29 Jul 2013 07:53:13 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 20A2221F9E45 for ; Mon, 29 Jul 2013 07:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6401; q=dns/txt; s=iport; t=1375109592; x=1376319192; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=BBqZxP7NxvjRppfOt7aJjpr7gfN1Wu/JtdL+ql1HnLs=; b=kyPcgIsG3JyRsfzvoDssMT195mYJTC/Nku6agU7bDzQpi3qi8MV86uWg mGv2jjaK5RjdPQSnJL8G+xeqQpJSNFYRXdvGlP7ijIOlvov9IHhlMLAqd CG/RegxGcHZu2tgiFEEFGVma+vGUJGRTcXIAx8Cs/CZXQnD6SWb9MOl94 U=; X-IronPort-AV: E=Sophos;i="4.89,729,1367971200"; d="scan'208,217";a="16115140" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 29 Jul 2013 14:53:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6TEr4IW011667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 14:53:04 GMT Received: from [10.61.213.12] ([10.61.213.12]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r6TEr0W8027572; Mon, 29 Jul 2013 15:53:00 +0100 (BST) Message-ID: <51F681CB.7090106@cisco.com> Date: Mon, 29 Jul 2013 15:52:59 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Benoit Claise References: <20130729084739.32167.51280.idtracker@ietfa.amsl.com> <51F66007.1070808@cisco.com> In-Reply-To: <51F66007.1070808@cisco.com> Content-Type: multipart/alternative; boundary="------------030805040708070205050902" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] Fwd: New Version Notification for draft-ietf-ipfix-mediation-protocol-06.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, 29 Jul 2013 14:53:21 -0000 This is a multi-part message in MIME format. --------------030805040708070205050902 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The -05 to -06 changes are good. P. On 29/07/13 13:28, Benoit Claise wrote: > Hi Paul, > > Please tell us if you're fine with the draft? > > Regards, Benoit > > > -------- Original Message -------- > Subject: New Version Notification for > draft-ietf-ipfix-mediation-protocol-06.txt > Date: Mon, 29 Jul 2013 01:47:39 -0700 > From: internet-drafts@ietf.org > To: Benoit Claise , Atsushi Kobayashi > , Brian Trammell > > > > A new version of I-D, draft-ietf-ipfix-mediation-protocol-06.txt > has been successfully submitted by Benoit Claise and posted to the > IETF repository. > > Filename: draft-ietf-ipfix-mediation-protocol > Revision: 06 > Title: Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators > Creation date: 2013-07-29 > Group: ipfix > Number of pages: 28 > URL:http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-06.txt > Status:http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol > Htmlized:http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-06 > Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mediation-protocol-06 > > Abstract: > This document specifies the operation of the IP Flow Information > Export (IPFIX) protocol specific to IPFIX Mediators, including > Template and Observation Point management, timing considerations, and > other Mediator-specific concerns. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > --------------030805040708070205050902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
The -05 to -06 changes are good.

P.


On 29/07/13 13:28, Benoit Claise wrote:
Hi Paul,

Please tell us if you're fine with the draft?

Regards, Benoit


-------- Original Message --------
Subject: New Version Notification for draft-ietf-ipfix-mediation-protocol-06.txt
Date: Mon, 29 Jul 2013 01:47:39 -0700
From: internet-drafts@ietf.org
To: Benoit Claise <bclaise@cisco.com>, Atsushi Kobayashi <akoba@nttv6.net>, Brian Trammell <trammell@tik.ee.ethz.ch> 


A new version of I-D, draft-ietf-ipfix-mediation-protocol-06.txt
has been successfully submitted by Benoit Claise and posted to the
IETF repository.

Filename:	 draft-ietf-ipfix-mediation-protocol
Revision:	 06
Title:		 Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators
Creation date:	 2013-07-29
Group:		 ipfix
Number of pages: 28
URL:             http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediation-protocol-06.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-ipfix-mediation-protocol
Htmlized:        http://tools.ietf.org/html/draft-ietf-ipfix-mediation-protocol-06
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-mediation-protocol-06

Abstract:
   This document specifies the operation of the IP Flow Information
   Export (IPFIX) protocol specific to IPFIX Mediators, including
   Template and Observation Point management, timing considerations, and
   other Mediator-specific concerns.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--------------030805040708070205050902-- From trammell@tik.ee.ethz.ch Tue Jul 30 02:14:01 2013 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 93EB221E80DD for ; Tue, 30 Jul 2013 02:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Vdtxd8VfLptZ for ; Tue, 30 Jul 2013 02:13:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B129C11E81C8 for ; Tue, 30 Jul 2013 02:07:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3B9C7D9309 for ; Tue, 30 Jul 2013 11:07: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 POojlOVHTqLF for ; Tue, 30 Jul 2013 11:07:22 +0200 (MEST) Received: from dhcp-90be.meeting.ietf.org (dhcp-90be.meeting.ietf.org [130.129.8.190]) (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 093BBD9308 for ; Tue, 30 Jul 2013 11:07:22 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jul 2013 11:07:24 +0200 References: <20130730085932.1947.69728.idtracker@ietfa.amsl.com> To: "ipfix@ietf.org Group" Message-Id: <5CF0D719-2C84-4FD8-A565-0EBABBF30D9D@tik.ee.ethz.ch> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [IPFIX] Fwd: New Version Notification for draft-trammell-ipfix-text-adt-02.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, 30 Jul 2013 09:14:02 -0000 Greetings, all, This is the textual representation of IPFIX ADTs draft we referred to in = the meeting yesterday; this revision should be content-complete. Please = read and comment; I'd like to consider this for adoption as a WG item, = or to be done in opsawg, depending on what we decide the future of the = IPFIX WG is. Thanks, best regards, Brian Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-trammell-ipfix-text-adt-02.txt > Date: 30 July 2013 10:59:32 GMT+02:00 > To: Brian Trammell >=20 >=20 > A new version of I-D, draft-trammell-ipfix-text-adt-02.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Filename: draft-trammell-ipfix-text-adt > Revision: 02 > Title: Textual Representation of IPFIX Abstract Data = Types > Creation date: 2013-07-30 > Group: Individual Submission > Number of pages: 11 > URL: = http://www.ietf.org/internet-drafts/draft-trammell-ipfix-text-adt-02.txt > Status: = http://datatracker.ietf.org/doc/draft-trammell-ipfix-text-adt > Htmlized: = http://tools.ietf.org/html/draft-trammell-ipfix-text-adt-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-trammell-ipfix-text-adt-02 >=20 > Abstract: > This document defines UTF-8 representations for IPFIX abstract data > types, to support interoperable usage of the IPFIX Information > Elements with protocols based on textual encodings. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat