From paitken@cisco.com Fri Feb 1 01:45:10 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 3207421F8561 for ; Fri, 1 Feb 2013 01:45:10 -0800 (PST) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-68Sc6-udRG for ; Fri, 1 Feb 2013 01:45:09 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E2E3B21F8558 for ; Fri, 1 Feb 2013 01:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5470; q=dns/txt; s=iport; t=1359711909; x=1360921509; h=message-id:date:from:mime-version:to:subject; bh=X3XaMnbNFklhOCH3FcBmTSW6W/cCfgF1gA5AFgtjmpI=; b=BSaFLZiofQq1npsPDHduYptIn5RYHwVtgzw/u8mdAZWZg6u+u/txj8Fr /3/B9liRQP098+yQZfs8x9LpeZPCfWy8rCR/VXxtxZNBT4jrjQ/cTuvXG 8y0IYfC+qugSW8WPLWNYtVQqOTgF27i20WLoOPCJ8bA/6EPG9vWyj9ssc g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO6NC1GQ/khN/2dsb2JhbABFgzm7axZzgxANPRYYAwIBAgFLDQgBAYgNoRyhK4JKjkIDlhSFcIpegns X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208,217";a="80168671" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 01 Feb 2013 09:45:07 +0000 Received: from [10.55.90.227] (dhcp-10-55-90-227.cisco.com [10.55.90.227]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r119j725014581 for ; Fri, 1 Feb 2013 09:45:07 GMT Message-ID: <510B8EA3.3050205@cisco.com> Date: Fri, 01 Feb 2013 09:45:07 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------050900030306010707010900" Subject: [IPFIX] IPFIX observationPointId uniqueness 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, 01 Feb 2013 09:45:10 -0000 This is a multi-part message in MIME format. --------------050900030306010707010900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear IPFIX experts, IPFIX observationPointId (#138) is defined as: An identifier of an Observation Point that is unique per Observation Domain. It is RECOMMENDED that this identifier is also unique per IPFIX Device. Typically, this Information Element is used for limiting the scope of other Information Elements. We now also have observationPointType (#277), defined as: Type of observation point. Values assigned to date are: 1. Physical port 2. Port channel 3. Vlan. Could we relax the uniqueness requirements of observationPointId when an observationPointType is also exported, such that the { observationPointType, observationPointId } pair must be unique, though not the observationPointId itself. The reason being that observation points of different types already have IDs, though these are not unique. eg, we have interface 1, 2, 3, ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... So an extra mediation layer is required to convert values from each of these number spaces into unique IDs in the observationPointId number space - which becomes harder as we add more places that observations can be made, ie more observationPointTypes. Whereas prefixing with the observationPointType achieves the required uniqueness in a faster, simpler, and more reliable way. To achieve this, I'd propose the following definition change: An identifier of an Observation Point that is unique per Observation Domain and per observationPointType, if specified. It is RECOMMENDED that this identifier is also unique per IPFIX Device. Typically, this Information Element is used for limiting the scope of other Information Elements. For backwards compatibility, we could define observationPointType = 0 to be "unspecified". Thanks, P. --------------050900030306010707010900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear IPFIX experts,

IPFIX observationPointId (#138) is defined as:

         An identifier of an Observation Point that is unique per
         Observation Domain.  It is RECOMMENDED that this identifier is
         also unique per IPFIX Device.  Typically, this Information
         Element is used for limiting the scope of other Information
         Elements.

We now also have observationPointType (#277), defined as:

          Type of observation point. Values assigned to date are:
       
          1. Physical port
          2. Port channel
          3. Vlan.


Could we relax the uniqueness requirements of observationPointId when an observationPointType is also exported, such that the { observationPointType, observationPointId } pair must be unique, though not the observationPointId itself.

The reason being that observation points of different types already have IDs, though these are not unique. eg, we have interface 1, 2, 3, ...; vlan 1, 2, 3, ...; port 1, 2, 3, ...

So an extra mediation layer is required to convert values from each of these number spaces into unique IDs in the observationPointId number space - which becomes harder as we add more places that observations can be made, ie more observationPointTypes.

Whereas prefixing with the observationPointType achieves the required uniqueness in a faster, simpler, and more reliable way.

To achieve this, I'd propose the following definition change:

         An identifier of an Observation Point that is unique per
         Observation Domain and per observationPointType, if specified.
         It is RECOMMENDED that this identifier is
         also unique per IPFIX Device.  Typically, this Information
         Element is used for limiting the scope of other Information
         Elements.

For backwards compatibility, we could define observationPointType = 0 to be "unspecified".

Thanks,
P.
--------------050900030306010707010900-- From trammell@tik.ee.ethz.ch Fri Feb 1 02:16:20 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 0FCF721F87D7 for ; Fri, 1 Feb 2013 02:16:20 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfRDU14xCK61 for ; Fri, 1 Feb 2013 02:16:19 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDE621F879D for ; Fri, 1 Feb 2013 02:16:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E97ADD9305; Fri, 1 Feb 2013 11:16:12 +0100 (MET) 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 7dgnQSIRktoL; Fri, 1 Feb 2013 11:16:12 +0100 (MET) 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 A2611D9304; Fri, 1 Feb 2013 11:16:12 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <510B8EA3.3050205@cisco.com> Date: Fri, 1 Feb 2013 11:16:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <75A8DB09-64E9-4EB5-9887-1E591AC1CFCA@tik.ee.ethz.ch> References: <510B8EA3.3050205@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1283) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness 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, 01 Feb 2013 10:16:20 -0000 hi Paul, Sounds reasonable to me. Cheers, Brian On 1 Feb 2013, at 10:45 , Paul Aitken wrote: > Dear IPFIX experts, >=20 > IPFIX observationPointId (#138) is defined as: >=20 > An identifier of an Observation Point that is unique per > Observation Domain. It is RECOMMENDED that this identifier = is > also unique per IPFIX Device. Typically, this Information > Element is used for limiting the scope of other Information > Elements. >=20 > We now also have observationPointType (#277), defined as: >=20 > Type of observation point. Values assigned to date are: > =20 > 1. Physical port > 2. Port channel > 3. Vlan. >=20 >=20 > Could we relax the uniqueness requirements of observationPointId when = an observationPointType is also exported, such that the { = observationPointType, observationPointId } pair must be unique, though = not the observationPointId itself. >=20 > The reason being that observation points of different types already = have IDs, though these are not unique. eg, we have interface 1, 2, 3, = ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... >=20 > So an extra mediation layer is required to convert values from each of = these number spaces into unique IDs in the observationPointId number = space - which becomes harder as we add more places that observations can = be made, ie more observationPointTypes. >=20 > Whereas prefixing with the observationPointType achieves the required = uniqueness in a faster, simpler, and more reliable way. >=20 > To achieve this, I'd propose the following definition change: >=20 > An identifier of an Observation Point that is unique per > Observation Domain and per observationPointType, if = specified. > It is RECOMMENDED that this identifier is > also unique per IPFIX Device. Typically, this Information > Element is used for limiting the scope of other Information > Elements. >=20 > For backwards compatibility, we could define observationPointType =3D = 0 to be "unspecified". >=20 > Thanks, > P. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Mon Feb 4 14:19: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 C250D21F8B30 for ; Mon, 4 Feb 2013 14:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovzdWcCZHiYP for ; Mon, 4 Feb 2013 14:19:40 -0800 (PST) Received: from smtp.plixer.com (smtp.plixer.com [64.140.243.151]) by ietfa.amsl.com (Postfix) with ESMTP id D566821F8B1A for ; Mon, 4 Feb 2013 14:19:39 -0800 (PST) Received: from [10.1.150.110] ([10.1.150.110]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Feb 2013 17:19:39 -0500 Message-ID: <511033FB.3000209@plixer.com> Date: Mon, 04 Feb 2013 17:19:39 -0500 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: ipfix@ietf.org References: <510B8EA3.3050205@cisco.com> In-Reply-To: <510B8EA3.3050205@cisco.com> Content-Type: multipart/alternative; boundary="------------070402080109070306080003" X-OriginalArrivalTime: 04 Feb 2013 22:19:39.0022 (UTC) FILETIME=[B8D8EAE0:01CE0325] Subject: Re: [IPFIX] IPFIX observationPointId uniqueness 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, 04 Feb 2013 22:19:40 -0000 This is a multi-part message in MIME format. --------------070402080109070306080003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, This seems like a good idea. -Andrew On 02/01/2013 04:45 AM, Paul Aitken wrote: > Dear IPFIX experts, > > IPFIX observationPointId (#138) is defined as: > > An identifier of an Observation Point that is unique per > Observation Domain. It is RECOMMENDED that this identifier is > also unique per IPFIX Device. Typically, this Information > Element is used for limiting the scope of other Information > Elements. > > We now also have observationPointType (#277), defined as: > > Type of observation point. Values assigned to date are: > > 1. Physical port > 2. Port channel > 3. Vlan. > > > Could we relax the uniqueness requirements of observationPointId when > an observationPointType is also exported, such that the { > observationPointType, observationPointId } pair must be unique, though > not the observationPointId itself. > > The reason being that observation points of different types already > have IDs, though these are not unique. eg, we have interface 1, 2, 3, > ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... > > So an extra mediation layer is required to convert values from each of > these number spaces into unique IDs in the observationPointId number > space - which becomes harder as we add more places that observations > can be made, ie more observationPointTypes. > > Whereas prefixing with the observationPointType achieves the required > uniqueness in a faster, simpler, and more reliable way. > > To achieve this, I'd propose the following definition change: > > An identifier of an Observation Point that is unique per > Observation Domain and per observationPointType, if specified. > It is RECOMMENDED that this identifier is > also unique per IPFIX Device. Typically, this Information > Element is used for limiting the scope of other Information > Elements. > > For backwards compatibility, we could define observationPointType = 0 > to be "unspecified". > > Thanks, > P. > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------070402080109070306080003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Paul,

This seems like a good idea.

-Andrew

On 02/01/2013 04:45 AM, Paul Aitken wrote:
Dear IPFIX experts,

IPFIX observationPointId (#138) is defined as:

         An identifier of an Observation Point that is unique per
         Observation Domain.  It is RECOMMENDED that this identifier is
         also unique per IPFIX Device.  Typically, this Information
         Element is used for limiting the scope of other Information
         Elements.

We now also have observationPointType (#277), defined as:

          Type of observation point. Values assigned to date are:
       
          1. Physical port
          2. Port channel
          3. Vlan.


Could we relax the uniqueness requirements of observationPointId when an observationPointType is also exported, such that the { observationPointType, observationPointId } pair must be unique, though not the observationPointId itself.

The reason being that observation points of different types already have IDs, though these are not unique. eg, we have interface 1, 2, 3, ...; vlan 1, 2, 3, ...; port 1, 2, 3, ...

So an extra mediation layer is required to convert values from each of these number spaces into unique IDs in the observationPointId number space - which becomes harder as we add more places that observations can be made, ie more observationPointTypes.

Whereas prefixing with the observationPointType achieves the required uniqueness in a faster, simpler, and more reliable way.

To achieve this, I'd propose the following definition change:

         An identifier of an Observation Point that is unique per
         Observation Domain and per observationPointType, if specified.
         It is RECOMMENDED that this identifier is
         also unique per IPFIX Device.  Typically, this Information
         Element is used for limiting the scope of other Information
         Elements.

For backwards compatibility, we could define observationPointType = 0 to be "unspecified".

Thanks,
P.


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

--------------070402080109070306080003-- From akoba@orange.plala.or.jp Mon Feb 11 06:45: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 45C2821F87D4 for ; Mon, 11 Feb 2013 06:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.51 X-Spam-Level: *** X-Spam-Status: No, score=3.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9yGLkiEa3do for ; Mon, 11 Feb 2013 06:45:41 -0800 (PST) Received: from msa01b.plala.or.jp (msa01.plala.or.jp [58.93.240.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D5F21F8715 for ; Mon, 11 Feb 2013 06:45:39 -0800 (PST) Received: from [192.168.1.13] (really [114.181.153.248]) by msa01b.plala.or.jp with SMTP id <20130211144532.JLHW24119.msa01b.plala.or.jp@[192.168.1.13]>; Mon, 11 Feb 2013 23:45:32 +0900 Date: Mon, 11 Feb 2013 23:45:32 +0900 From: ATSUSHI KOBAYASHI To: "Pat Thaler" In-Reply-To: References: Message-Id: <20130211234532.8F75.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.61.01 [ja] X-VirusScan: Outbound; msa01b; Mon, 11 Feb 2013 23:45:32 +0900 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Fwd: WG Last Call for draft-ietf-ipfix-data-link-layer-monitoring-01 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, 11 Feb 2013 14:45:42 -0000 Hi Pat, Thank you for detailed your review. Sorry for late reply. I rewrote the parts related to 802.1Q-2011 incorporating IEEE 802.1ad and 802.1ah. I have not yet rewrote the parts related to IEEE802.1Qbg and IEEE802.1BR. Please see in-line. On Wed, 19 Dec 2012 03:25:58 +0000 "Pat Thaler" wrote: > There are a number of items that should be corrected in this draft. > > > * The draft is out of date with respect to status of 802.1 and 802.3 standards. Please replace with current references. > > o The amendments IEEE 802.1ad and 802.1ah are not active standards as the material from them was incorporated into IEEE 802.1Q revisions. References to them should be changed to the current revision of 802.1Q > > o The current revision of 802.1Q is IEEE Std 802.1Q-2011. > Ok, I will correct it. > o The current revision of 802.3 is IEEE Std 802.3-2012 (which has been approved and should be published shortly). It doesn't have a subclause 3.5. This was removed in the 2008 revision of 802.3 as the subclause just duplicated information from 802.1Q. 802.1Q should be used as the reference for fields such as VLAN ID and priority code point. > Yes, I confirmed the clause 9 in IEEE 802.1Q-2011. The reference 802.3 will be removed. > o 802.1BR only specifies Bridge Port Extension so only Figure B-4 shows a frame format specified in 802.1BR > Yes, I will correct the title of Figure B-4. > o 802.1Qbg Edge Virtual Bridging specifies use of an S-Tag to identify traffic belonging to S-Channels (i.e. a virtual link) on a physical link between an end station and the adjacent bridge so the formats in Figure B-1 and B-2 would apply to 802.1Qbg, not 802.1BR. > Yes, I will correct the title of Figure B-1 and B-2. > * The frame formats for Edge Virtual Bridging and Port Extension apply only between the end node and adjacent bridge (for figures B-1 and B-2) or within an Extended Bridge (i.e. a controlling bridge plus its port extenders, figure B-3). They are never used between bridges for those standards. The Edge Virtual Bridge frame formats use the same tags as Provider Bridged frame formats (Figure A-3 and A-4). When the frames with that format are used between bridges it is provider bridging which is used in some data centers as well as in the WAN. It would be better to organize the frame format annexes as frame formats used between bridges and frame formats used for Edge Virtual Bridging between edge devices and their bridge and within an Extended Bridge. > > * 2.2 Data Center Bridging - the content here seems confused. It isn't clear what the relevance of this summary is to the draft since information elements for the IEEE 802.1BR E-Tag have not been added. The E-Tag only appears between elements of an Extended Bridge and the Controlling Bridge has visibility of all the traffic in the Extended Bridge so it isn't clear to me that data link layer monitoring is relevant to it (any more than it would be to monitoring traffic between blades in a blade bridge). The C-Tag is used in Data Center Bridging the same way as in all 802.1Q bridging so that isn't a special case. The use of the S-Tag for Edge Virtual Bridging S-Channels only occurs on the link between an end station and its adjacent bridge. No additional elements are needed for these. The conclusion that Data Center Bridging complicates traffic measurement is not substantiated. Please remove 2.2 or if it is retained make it more clear and accurate. > In current version, it does not describe the overview of Edge Virtual Bridging and Bridge Port Extension. I will remove subsection 2.2. However, I will add substitute subsection about IEEE802.1Qbg and IEEE802.1BR. I am not specialist about Ethernet layer, it takes time more than two weeks to learn more about IEEE802.1Qbg. > * 2.3 Multiple Path Ethernet Summary - says "two solutions are discussed for standardization" implying that the standards haven't been finished. IEEE Std 802.1aq-2012 Shortest Path Bridging is an approved standard which was published in June. I will rewrite as follows. There are two solutions; one is Shortest Path Bridging [IEEE802.1aq], the other is TRILL (Transparent Interconnection of Lots of Links) [RFC6325]. > > * 2.4 VXLAN - The limit of the 12-bit VLAN ID is not the motivating factor for Network Virtualization Overlay (NVO3). If it was, the I-Tag which supports a 24-bit service identifier would suffice. A more significant motivator for the NVO3 is allowing for IP and MAC address isolation between the data center (which may be a layer 3 data center) and the tenant networks and between the tenant networks. The problem statement draft, draft-ietf-nvo3-overlay-problem-statement-01, provides a more complete description of the motivating factors. VXLAN is not the only proposed encapsulation for NVO3. It seems early to mention this topic as we haven't decided on which solutions to standardize. No information elements have been added for it so 2.4 could be deleted. If it remains, it should point to the NVO3 work in general rather than a specific proposal. > Ok, I will remove the subsection 2.4. > * 5.1 and 5.2 - formally, there is no such thing as an 802.1ad frame or 802.1ah since 802.1ad and 802.1ah have been rolled into 802.1Q. You could use S-Tagged and B-Tagged frame. Ok, I will use it. Regards, Atsushi > > Regards, > Pat Thaler -- KOBAYASHI ATSUSHI From n.brownlee@auckland.ac.nz Mon Feb 11 18:49: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 E6B0321F8826 for ; Mon, 11 Feb 2013 18:49:55 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihJvC4iw+aDg for ; Mon, 11 Feb 2013 18:49:54 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1183521F8820 for ; Mon, 11 Feb 2013 18:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1360637394; x=1392173394; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=3oLmQAVfHamHAhdOkiUcbVnTQxVpgVdgM7x7/18leHk=; b=A6Zci4OrOHupOQZ6c8+lA4JbpVw5vCRGX0pKVLpk0QgL9M/6bjBbS5qD TDNqYlQrGpAmlpq9gAJ7AxWMaVMlLxB2WNGpSPCUDqCYw48NHehfj1gYY z3jOOY5nzCQ0Bk1r9xVzTQyiGUYZPjn2mdPhZmRSLxvEmhH3ghVwJKQTs U=; X-IronPort-AV: E=Sophos;i="4.84,647,1355050800"; d="scan'208";a="170063216" 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; 12 Feb 2013 15:49:51 +1300 Message-ID: <5119ADCF.20904@auckland.ac.nz> Date: Tue, 12 Feb 2013 15:49:51 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Getting set for IETF 86 in Orlando 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, 12 Feb 2013 02:49:56 -0000 Hi all: The IPFIX meeting is on Thursday morning, 14 March, 0900-1130 (a little more time than I'd requested!). Right now we have three active WG drafts, - Link-layer Monitoring - Mediation Protocol - MIB Variable Export Draft authors, will you be at the meeting in Orlando? If not, will you be able to present remotely vie MeeTecho? Please let me know real soon now. Also, since we're likely to have some time available in the session, does anyone have any non-WG drafts they'd like to present? 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 trammell@tik.ee.ethz.ch Mon Feb 11 22:38: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 E8CF821F8C2F for ; Mon, 11 Feb 2013 22:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxWvr9+0NqsH for ; Mon, 11 Feb 2013 22:38:51 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4D10521F8C18 for ; Mon, 11 Feb 2013 22:38:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id F2BC4D9307; Tue, 12 Feb 2013 07:38:49 +0100 (MET) 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 4uAp4+8SXLft; Tue, 12 Feb 2013 07:38:49 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 A53CCD9305; Tue, 12 Feb 2013 07:38:49 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: <5119ADCF.20904@auckland.ac.nz> Date: Tue, 12 Feb 2013 07:38:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4018AB9D-29A4-4AB6-96EB-7102BBAF90FE@tik.ee.ethz.ch> References: <5119ADCF.20904@auckland.ac.nz> To: Nevil Brownlee X-Mailer: Apple Mail (2.1499) Cc: IPFIX Working Group Subject: Re: [IPFIX] Getting set for IETF 86 in Orlando 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, 12 Feb 2013 06:38:52 -0000 Hi, Nevil, I'll be present WRT the mediation protocol draft, but honestly work on = this has stalled as RFC5101bis and RFC5102bis have taken all our IPFIX = cycles since Atlanta. There are still open issues in medproto which need = to be handled, which we expect to do after 5101/5102 are finished. Given = that, I don't think it's worth doing a full presentation on this time = around. I'd like about five minutes to present draft-trammell-ipfix-text-adt = (announced on the list 5 November 2012: = http://www.ietf.org/mail-archive/web/ipfix/current/msg06644.html), which = was published during the Atlanta meeting but not discussed there, and = has not advanced since. It proposes a set of standard text = representations for IPFIX ADTs so the infomodel can be used with XML or = JSON/YAML/etc.-based serialization schemes; mainly, I'm looking for = feedback on whether such a thing would be of interest to the WG. Cheers, Brian On Feb 12, 2013, at 3:49 AM, Nevil Brownlee = wrote: >=20 > Hi all: >=20 > The IPFIX meeting is on Thursday morning, 14 March, 0900-1130 > (a little more time than I'd requested!). >=20 > Right now we have three active WG drafts, > - Link-layer Monitoring > - Mediation Protocol > - MIB Variable Export >=20 > Draft authors, will you be at the meeting in Orlando? > If not, will you be able to present remotely vie MeeTecho? >=20 > Please let me know real soon now. >=20 > Also, since we're likely to have some time available in the > session, does anyone have any non-WG drafts they'd like to present? >=20 > Cheers, Nevil >=20 > --=20 > --------------------------------------------------------------------- > 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 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Tue Feb 12 01:00: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 52F8A21F8A84 for ; Tue, 12 Feb 2013 01:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptQk9O2WkV2n for ; Tue, 12 Feb 2013 01:00:11 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 71F6C21F852C for ; Tue, 12 Feb 2013 01:00:11 -0800 (PST) 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 r1C8xwDv001085; Tue, 12 Feb 2013 09:59:58 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1C8x2pr016555; Tue, 12 Feb 2013 09:59:22 +0100 (CET) Message-ID: <511A0456.5070504@cisco.com> Date: Tue, 12 Feb 2013 09:59:02 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian Trammell References: <5119ADCF.20904@auckland.ac.nz> <4018AB9D-29A4-4AB6-96EB-7102BBAF90FE@tik.ee.ethz.ch> In-Reply-To: <4018AB9D-29A4-4AB6-96EB-7102BBAF90FE@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nevil Brownlee , IPFIX Working Group Subject: Re: [IPFIX] Getting set for IETF 86 in Orlando 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, 12 Feb 2013 09:00:12 -0000 Hi Nevil, > Hi, Nevil, > > I'll be present WRT the mediation protocol draft, but honestly work on this has stalled as RFC5101bis and RFC5102bis have taken all our IPFIX cycles since Atlanta. There are still open issues in medproto which need to be handled, which we expect to do after 5101/5102 are finished. Given that, I don't think it's worth doing a full presentation on this time around. I will work on improving medproto. Expect a new version. Regards, Benoit > > I'd like about five minutes to present draft-trammell-ipfix-text-adt (announced on the list 5 November 2012: http://www.ietf.org/mail-archive/web/ipfix/current/msg06644.html), which was published during the Atlanta meeting but not discussed there, and has not advanced since. It proposes a set of standard text representations for IPFIX ADTs so the infomodel can be used with XML or JSON/YAML/etc.-based serialization schemes; mainly, I'm looking for feedback on whether such a thing would be of interest to the WG. > > Cheers, > > Brian > > On Feb 12, 2013, at 3:49 AM, Nevil Brownlee wrote: > >> Hi all: >> >> The IPFIX meeting is on Thursday morning, 14 March, 0900-1130 >> (a little more time than I'd requested!). >> >> Right now we have three active WG drafts, >> - Link-layer Monitoring >> - Mediation Protocol >> - MIB Variable Export >> >> Draft authors, will you be at the meeting in Orlando? >> If not, will you be able to present remotely vie MeeTecho? >> >> Please let me know real soon now. >> >> Also, since we're likely to have some time available in the >> session, does anyone have any non-WG drafts they'd like to present? >> >> 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 >> _______________________________________________ >> 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 paitken@cisco.com Tue Feb 12 03:15: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 E4EB021F8CD0 for ; Tue, 12 Feb 2013 03:15:30 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbHrE82sPB3l for ; Tue, 12 Feb 2013 03:15:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0174021F8CE9 for ; Tue, 12 Feb 2013 03:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=736; q=dns/txt; s=iport; t=1360667730; x=1361877330; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hV2wLRh0j1hshBHkzthryLDhWfkC+xD0lUMGaT6BN18=; b=dSzpK8w8kSwPsYM7V07F38fnvb97rRowzLqPMMlpUNDiyimSX+lOKjbJ xNdAIQztSgzxHCKBANtU6Y7d6/mTCdvhY7HLqto9WumkdrObWCO/rqqQe Z+SpQcod2QQZs8igkXMP327R0SBVcCxNZ1KPiN5uxWPwNu5l0H6fa7bEZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUJAM0jGlGQ/khM/2dsb2JhbABEDr1BglMEBIEJFnOCHwEBAQQ4QAEQCw4KCRYPCQMCAQIBRQYNAQcBAYgOrw2QDJIHA5YkhXGKYoJHPw X-IronPort-AV: E=Sophos;i="4.84,648,1355097600"; d="scan'208";a="150393620" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 12 Feb 2013 11:15:28 +0000 Received: from [144.254.153.46] (dhcp-144-254-153-46.cisco.com [144.254.153.46]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1CBFRmw026574; Tue, 12 Feb 2013 11:15:27 GMT Message-ID: <511A2450.1040703@cisco.com> Date: Tue, 12 Feb 2013 11:15:28 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nevil Brownlee References: <5119ADCF.20904@auckland.ac.nz> In-Reply-To: <5119ADCF.20904@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] Getting set for IETF 86 in Orlando 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, 12 Feb 2013 11:15:31 -0000 Nevil, I'm not planning to be in Orlando, so I shall have to endure the awesomeness that is Meetecho. P. On 12/02/13 02:49, Nevil Brownlee wrote: > > Hi all: > > The IPFIX meeting is on Thursday morning, 14 March, 0900-1130 > (a little more time than I'd requested!). > > Right now we have three active WG drafts, > - Link-layer Monitoring > - Mediation Protocol > - MIB Variable Export > > Draft authors, will you be at the meeting in Orlando? > If not, will you be able to present remotely vie MeeTecho? > > Please let me know real soon now. > > Also, since we're likely to have some time available in the > session, does anyone have any non-WG drafts they'd like to present? > > Cheers, Nevil > From internet-drafts@ietf.org Tue Feb 12 07:21: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 8EBA621F8EBE; Tue, 12 Feb 2013 07:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EsYg4ivpQ-g; Tue, 12 Feb 2013 07:21:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0455821F8EC4; Tue, 12 Feb 2013 07:21:53 -0800 (PST) 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.37 Message-ID: <20130212152153.26830.54752.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 07:21:53 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-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, 12 Feb 2013 15:21:53 -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 Model for IP Flow Information eXport (IPFIX) Author(s) : Benoit Claise Brian Trammell Filename : draft-ietf-ipfix-information-model-rfc5102bis-10.txt Pages : 23 Date : 2013-02-12 Abstract: This document defines the datatypes and management policy for the information model for the IP Flow Information eXport (IPFIX) protocol. This information model is maintained as the IANA IPFIX Information Element Registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX Protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX Protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102= bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc51= 02bis-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Tue Feb 12 07:23: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 79D0D21F8CDF for ; Tue, 12 Feb 2013 07:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7dMF6Z77rlc for ; Tue, 12 Feb 2013 07:23:05 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF3421F88F5 for ; Tue, 12 Feb 2013 07:23:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id E16BED930C for ; Tue, 12 Feb 2013 16:22:59 +0100 (MET) 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 BoCKraz8JbYC for ; Tue, 12 Feb 2013 16:22:59 +0100 (MET) 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 ABA78D930B for ; Tue, 12 Feb 2013 16:22:59 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Brian Trammell In-Reply-To: <20130212152153.26830.54752.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 16:22:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130212152153.26830.54752.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group X-Mailer: Apple Mail (2.1283) Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-information-model-rfc5102bis-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, 12 Feb 2013 15:23:06 -0000 Greetings, all, This revision addresses IESG and area review comments and DISCUSSes. Cheers, Brian On 12 Feb 2013, at 16:21 , 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 : Information Model for IP Flow Information = eXport (IPFIX) > Author(s) : Benoit Claise > Brian Trammell > Filename : = draft-ietf-ipfix-information-model-rfc5102bis-10.txt > Pages : 23 > Date : 2013-02-12 >=20 > Abstract: > This document defines the datatypes and management policy for the > information model for the IP Flow Information eXport (IPFIX) > protocol. This information model is maintained as the IANA IPFIX > Information Element Registry, the initial contents of which were > defined by RFC 5102. This information model is used by the IPFIX > Protocol for encoding measured traffic information and information > related to the traffic Observation Point, the traffic Metering > Process, and the Exporting Process. Although developed for the IPFIX > Protocol, the model is defined in an open way that easily allows > using it in other protocols, interfaces, and applications. This > document obsoletes RFC 5102. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc510= 2bis >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-1= 0 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-information-model-rfc5= 102bis-10 >=20 >=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 iesg-secretary@ietf.org Wed Feb 13 08:20: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 E5FBC21F8893; Wed, 13 Feb 2013 08:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7edECLB2ZQ3q; Wed, 13 Feb 2013 08:20:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D37021F88BE; Wed, 13 Feb 2013 08:20:17 -0800 (PST) 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.40 Message-ID: <20130213162017.10719.48567.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2013 08:20:17 -0800 Cc: ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Information Model for IP Flow Information eXport (IPFIX)' to Proposed Standard (draft-ietf-ipfix-information-model-rfc5102bis-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: Wed, 13 Feb 2013 16:20:18 -0000 The IESG has approved the following document: - 'Information Model for IP Flow Information eXport (IPFIX)' (draft-ietf-ipfix-information-model-rfc5102bis-10.txt) as Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102bis/ Technical Summary: This document provides an overview of the information model for the IP Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX Information Element Registry. It is used by the IPFIX Protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX Protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. Working Group Summary: The documents has been significantly changed in content compared to RFC 5202. The main reason for the change is the existence of an IANA registry for IPFIX information elements. This change was fully aggreed on in WG discussions. Document Quality: This is an update of RFC 5102 based on a lot of practica experiences with specifying registering and implementing IPFIX information elements. Changes compared to RFC 5102 result from these experiences. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? 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 iesg-secretary@ietf.org Wed Feb 13 08:20:18 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 2E94E21F8887 for ; Wed, 13 Feb 2013 08:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6kJy4lOIWKi; Wed, 13 Feb 2013 08:20:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BF521F890E; Wed, 13 Feb 2013 08:20:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-ipfix-information-model-rfc5102bis X-IETF-Draft-revision: 10 Message-ID: <20130213162017.10719.70866.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2013 08:20:17 -0800 Cc: ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Information Model for IP Flow Information eXport (IPFIX)' to Proposed Standard (draft-ietf-ipfix-information-model-rfc5102bis-10.txt) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:20:18 -0000 The IESG has approved the following document: - 'Information Model for IP Flow Information eXport (IPFIX)' (draft-ietf-ipfix-information-model-rfc5102bis-10.txt) as Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-information-model-rfc5102bis/ Technical Summary: This document provides an overview of the information model for the IP Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX Information Element Registry. It is used by the IPFIX Protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX Protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. Working Group Summary: The documents has been significantly changed in content compared to RFC 5202. The main reason for the change is the existence of an IANA registry for IPFIX information elements. This change was fully aggreed on in WG discussions. Document Quality: This is an update of RFC 5102 based on a lot of practica experiences with specifying registering and implementing IPFIX information elements. Changes compared to RFC 5102 result from these experiences. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? 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 Thu Feb 14 16:29:09 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 5AAA221F8681 for ; Thu, 14 Feb 2013 16:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.534 X-Spam-Level: X-Spam-Status: No, score=-10.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvWINfddR3u6 for ; Thu, 14 Feb 2013 16:29:08 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 57E1221F8630 for ; Thu, 14 Feb 2013 16:29:08 -0800 (PST) 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 r1F0T5tQ006395; Fri, 15 Feb 2013 01:29:05 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1F0S9QJ009511; Fri, 15 Feb 2013 01:28:29 +0100 (CET) Message-ID: <511D8119.6090801@cisco.com> Date: Fri, 15 Feb 2013 01:28:09 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Brian Trammell References: <50C2696C.9040606@plixer.com> <5DF30BA2-E4D2-4B9D-A3D6-EF980F115310@tik.ee.ethz.ch> In-Reply-To: <5DF30BA2-E4D2-4B9D-A3D6-EF980F115310@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] latency reporting 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, 15 Feb 2013 00:29:09 -0000 Brian, Exactly. This is the reason why we have specified RFC 6390, and specifically the performance metric template. See http://tools.ietf.org/html/rfc6390#section-5.4.4 Normative o Metric Name o Metric Description o Method of Measurement or Calculation o Units of Measurement o Measurement Point(s) with Potential Measurement Domain o Measurement Timing Informative o Implementation o Verification o Use and Applications o Reporting Model Regards, Benot > Hi, Andrew, all, > > I think all of these are useful (indeed, many must think so if you're seeing them from shipping exporters). However, just as with jitter, to some extent, you'll see different Information Elements out there because there are different ways to calculate things, and each of these measurement methods actually is producing a different type of data. RTT derived from synack measurement near the initiator gives you totally different results than synack measurement near the responder (the latter being essentially useless). RTT derived via TWAMP is something different entirely, as you're not measuring application latency along with network latency, and you know you have the whole path. > > So we have to be careful about precise definitions if we're going to end up with data we can properly interpret. On that point, I'm not sure I support the idea of having a single overarching "jitter" or "latency" or "rtt" Information Element then selecting an algorithm externally, unless that external selection was flexible enough to handle all the algorithm, OP-placement, passive/active measurement, and other attributes/issues. This seems like it could be a job for extended field specifiers, but we'd have to think about where to draw the line between "IE attribute" and "new IE" very, very carefully here. > > Jitter's another beast entirely, because there's such a variety of definitions and algorithms that you can end up with broadly incomparable numbers; at least with RTT everyone's kind of trying to get at the same number. > > Indeed, this is a problem we'll most probably be addressing the semantic side of, in part, in the IPPM working group. > > One further point, inline: > > On Dec 7, 2012, at 11:10 PM, Andrew Feren wrote: > >> Hi all, >> >> I've been doing some review and clean up of my local IE database and I see around a dozen IEs related to latency and RTT from various exporters/vendors. This seems like a measurement that could use a standard IE for reporting. Here are my thoughts so far... >> >> Name: latencyMilliseconds >> Type: unsigned32 >> Semantic: quantity >> Description: latency measured in milliseconds. >> Units: milliseconds >> >> Name: roundTripTimeMilliseconds >> Type: unsigned32 >> Semantic: quantity >> Description: Round trip time measured in milliseconds. >> Units: milliseconds >> >> Perhaps the above needs to be fleshed out with some Extended Field Specifiers as has been discussed recently for jitter. >> >> On a related note an IE that I am not seeing from most of the exporters sending latency information, but which can be useful when diagnosing problems is out of order packet information. >> >> Name: outOfOrderPacketDeltaCount >> Type: unsigned64 >> Semantic: deltaCounter >> Description: The number of out of order packets since the previous report (if any) for this Flow at the Observation Point. >> Units: packets > This doesn't suffer _as much_ from OP-sensitivity (reordering generally/often happens due to retransmission as opposed to routers behaving badly) but there is a problem of definition: what is an out of order packet? As with timing issues, there are a lot of little details you have to work out in order to get comparable numbers; those details should be explicitly explained in the definition. > > Cheers, > > Brian > >> Name: outOfOrderPacketTotalCount >> Type: unsigned64 >> Semantic: totalCounter >> Description: The total number of out of order packets for this Flow at the Observation Point since the Metering Process (re-)initialization for this Observation Point. >> Units: packets >> >> -Andrew >> _______________________________________________ >> 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 Thu Feb 14 16:38:36 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 D704221F8920 for ; Thu, 14 Feb 2013 16:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TjbVGUF0OXs for ; Thu, 14 Feb 2013 16:38:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3960221F8962 for ; Thu, 14 Feb 2013 16:38:34 -0800 (PST) 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 r1F0OAkB005974 for ; Fri, 15 Feb 2013 01:24:10 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1F0NiO8007220; Fri, 15 Feb 2013 01:23:50 +0100 (CET) Message-ID: <511D8010.6030209@cisco.com> Date: Fri, 15 Feb 2013 01:23:44 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Aitken References: <510B8EA3.3050205@cisco.com> In-Reply-To: <510B8EA3.3050205@cisco.com> Content-Type: multipart/alternative; boundary="------------020401060702060707030504" Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness 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, 15 Feb 2013 00:38:36 -0000 This is a multi-part message in MIME format. --------------020401060702060707030504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul, At first glance, it looks reasonable. But what would be the consequence on the Selection Sequence Report Interpretation(see http://tools.ietf.org/html/rfc5476#section-6.5.1). If we use the observationPointId and it's not unique, then we need to include the observationPointType? Note that the sentence "It is RECOMMENDED that this identifier is also unique per IPFIX Device." was inserted specifically for this. Regards, Benot > Dear IPFIX experts, > > IPFIX observationPointId (#138) is defined as: > > An identifier of an Observation Point that is unique per > Observation Domain. It is RECOMMENDED that this identifier is > also unique per IPFIX Device. Typically, this Information > Element is used for limiting the scope of other Information > Elements. > > We now also have observationPointType (#277), defined as: > > Type of observation point. Values assigned to date are: > > 1. Physical port > 2. Port channel > 3. Vlan. > > > Could we relax the uniqueness requirements of observationPointId when > an observationPointType is also exported, such that the { > observationPointType, observationPointId } pair must be unique, though > not the observationPointId itself. > > The reason being that observation points of different types already > have IDs, though these are not unique. eg, we have interface 1, 2, 3, > ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... > > So an extra mediation layer is required to convert values from each of > these number spaces into unique IDs in the observationPointId number > space - which becomes harder as we add more places that observations > can be made, ie more observationPointTypes. > > Whereas prefixing with the observationPointType achieves the required > uniqueness in a faster, simpler, and more reliable way. > > To achieve this, I'd propose the following definition change: > > An identifier of an Observation Point that is unique per > Observation Domain and per observationPointType, if specified. > It is RECOMMENDED that this identifier is > also unique per IPFIX Device. Typically, this Information > Element is used for limiting the scope of other Information > Elements. > > For backwards compatibility, we could define observationPointType = 0 > to be "unspecified". > > Thanks, > P. > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------020401060702060707030504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Paul,

At first glance, it looks reasonable.
But what would be the consequence on the Selection Sequence Report Interpretation (see http://tools.ietf.org/html/rfc5476#section-6.5.1). If we use the observationPointId and it's not unique, then we need to include the observationPointType?
Note that the sentence "It is RECOMMENDED that this identifier is also unique per IPFIX Device." was inserted specifically for this.

Regards, Benot
Dear IPFIX experts,

IPFIX observationPointId (#138) is defined as:

         An identifier of an Observation Point that is unique per
         Observation Domain.  It is RECOMMENDED that this identifier is
         also unique per IPFIX Device.  Typically, this Information
         Element is used for limiting the scope of other Information
         Elements.

We now also have observationPointType (#277), defined as:

          Type of observation point. Values assigned to date are:
       
          1. Physical port
          2. Port channel
          3. Vlan.


Could we relax the uniqueness requirements of observationPointId when an observationPointType is also exported, such that the { observationPointType, observationPointId } pair must be unique, though not the observationPointId itself.

The reason being that observation points of different types already have IDs, though these are not unique. eg, we have interface 1, 2, 3, ...; vlan 1, 2, 3, ...; port 1, 2, 3, ...

So an extra mediation layer is required to convert values from each of these number spaces into unique IDs in the observationPointId number space - which becomes harder as we add more places that observations can be made, ie more observationPointTypes.

Whereas prefixing with the observationPointType achieves the required uniqueness in a faster, simpler, and more reliable way.

To achieve this, I'd propose the following definition change:

         An identifier of an Observation Point that is unique per
         Observation Domain and per observationPointType, if specified.
         It is RECOMMENDED that this identifier is
         also unique per IPFIX Device.  Typically, this Information
         Element is used for limiting the scope of other Information
         Elements.

For backwards compatibility, we could define observationPointType = 0 to be "unspecified".

Thanks,
P.


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

--------------020401060702060707030504-- From muenz@net.in.tum.de Fri Feb 15 01:25:49 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 C0CA021F8530 for ; Fri, 15 Feb 2013 01:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVx59mL9UjcE for ; Fri, 15 Feb 2013 01:25:46 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mailsender1.informatik.tu-muenchen.de [131.159.0.97]) by ietfa.amsl.com (Postfix) with ESMTP id EC4DA21F84FB for ; Fri, 15 Feb 2013 01:25:43 -0800 (PST) Received: from [192.168.2.36] (g230147057.adsl.alicedsl.de [92.230.147.57]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 43C3D19B1440; Fri, 15 Feb 2013 10:25:39 +0100 (CET) Message-ID: <511DFF13.6050001@net.in.tum.de> Date: Fri, 15 Feb 2013 10:25:39 +0100 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Benoit Claise References: <510B8EA3.3050205@cisco.com> <511D8010.6030209@cisco.com> In-Reply-To: <511D8010.6030209@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX observationPointId uniqueness 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, 15 Feb 2013 09:25:49 -0000 Benoit, Paul, Like Benoit, I do not have a good feeling about this proposal. On the other hand, I have not found any RFC that really requires the use of OPIDs. Even RFC5476 leaves it open whether the OP is identified by OPID or any other IE. Therefore, I have been silent until now. IPFIX-CONFIG assumes that the OPID is assigned by the IPFIX device, i.e. it is not a configuration parameter. I think that we agree here. Up to now, the IPFIX RFCs do not impose any restriction on the OPID except for the uniqueness per OD. This means that various implementations are possible right now: 1) OPID is equal to an internal identifier (e.g. internal interface number) or a non-IPFIX MIB index (e.g. ifIndex, entPhysicalIndex). 2) OPID is equal to the IPFIX-MIB index ipfixObservationPointIndex 3) OPID is unrelated to any other index, the IPFIX device provides the internal mapping If IPFIX-MIB is supported by the device, the natural choice for me would be 2). This would allow easy mapping of MIB entries and IPFIX export. As Paul points out, 1) only works as long as the internal identifiers are unique per OD. My questions to Paul are: - Do you really need OPID for your purpose? Have you thought about using IEs like ingressPhysicalInterface or ingressInterface? Or, if these IEs are not appropriate, about defining new IEs? - If you need to use OPIDs and if you want to avoid any mapping, have you thought about assigning the different sources (interface cards, VLANs) to different ODs? Regards, Gerhard On 15.02.2013 01:23, Benoit Claise wrote: > Paul, > > At first glance, it looks reasonable. > But what would be the consequence on the Selection Sequence Report > Interpretation(see http://tools.ietf.org/html/rfc5476#section-6.5.1). If > we use the observationPointId and it's not unique, then we need to > include the observationPointType? > Note that the sentence "It is RECOMMENDED that this identifier is also > unique per IPFIX Device." was inserted specifically for this. > > Regards, Benot >> Dear IPFIX experts, >> >> IPFIX observationPointId (#138) is defined as: >> >> An identifier of an Observation Point that is unique per >> Observation Domain. It is RECOMMENDED that this identifier is >> also unique per IPFIX Device. Typically, this Information >> Element is used for limiting the scope of other Information >> Elements. >> >> We now also have observationPointType (#277), defined as: >> >> Type of observation point. Values assigned to date are: >> >> 1. Physical port >> 2. Port channel >> 3. Vlan. >> >> >> Could we relax the uniqueness requirements of observationPointId when >> an observationPointType is also exported, such that the { >> observationPointType, observationPointId } pair must be unique, though >> not the observationPointId itself. >> >> The reason being that observation points of different types already >> have IDs, though these are not unique. eg, we have interface 1, 2, 3, >> ...; vlan 1, 2, 3, ...; port 1, 2, 3, ... >> >> So an extra mediation layer is required to convert values from each of >> these number spaces into unique IDs in the observationPointId number >> space - which becomes harder as we add more places that observations >> can be made, ie more observationPointTypes. >> >> Whereas prefixing with the observationPointType achieves the required >> uniqueness in a faster, simpler, and more reliable way. >> >> To achieve this, I'd propose the following definition change: >> >> An identifier of an Observation Point that is unique per >> Observation Domain and per observationPointType, if specified. >> It is RECOMMENDED that this identifier is >> also unique per IPFIX Device. Typically, this Information >> Element is used for limiting the scope of other Information >> Elements. >> >> For backwards compatibility, we could define observationPointType = 0 >> to be "unspecified". >> >> Thanks, >> P. >> >> >> _______________________________________________ >> 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 paitken@cisco.com Fri Feb 15 10:02:15 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 108AE21F8808 for ; Fri, 15 Feb 2013 10:02:15 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcFQtnl2w6Q0 for ; Fri, 15 Feb 2013 10:02:14 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCE221F85C0 for ; Fri, 15 Feb 2013 10:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4724; q=dns/txt; s=iport; t=1360951333; x=1362160933; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=zzPelHNszFtKjeJKcOiMsaWY/8Repsc03T91O0CyMZI=; b=Wlx8ZRLoSYq9thlIpixMeRbyQ7nc8hBZTexqckGUIH3vShChxMLkUKnK eV6mz3fjp6RSZxpnl4JzoIsVVF42V9+HCva5Y38t2RQbJw01JOf2FGMfA LhnHda2fNWapdD3+x7ikK1b6BYtWtWUfTjbvz7AGoOASe/eeoIrMfnQis 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAIp2HlGQ/khL/2dsb2JhbABEgzWDFIVbs019FnOCHwEBAQQjVAENBA8NAwECChYLAgIJAwIBAgE7AggGDQYCAQEFiAkMqm6SPY8aBhIGgieBEwOWKIEdhFSKZIMH X-IronPort-AV: E=Sophos;i="4.84,674,1355097600"; d="scan'208,217";a="11830072" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 15 Feb 2013 18:02:11 +0000 Received: from [10.55.82.22] (dhcp-10-55-82-22.cisco.com [10.55.82.22]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1FI2B8i027262 for ; Fri, 15 Feb 2013 18:02:11 GMT Message-ID: <511E7824.8030003@cisco.com> Date: Fri, 15 Feb 2013 18:02:12 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: IETF IPFIX Working Group References: <20130215175612.9303.52214.idtracker@ietfa.amsl.com> In-Reply-To: <20130215175612.9303.52214.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130215175612.9303.52214.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030804020505040408090007" Subject: [IPFIX] Fwd: New Version Notification for draft-aitken-ipfix-equivalent-ies-00.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: Fri, 15 Feb 2013 18:02:15 -0000 This is a multi-part message in MIME format. --------------030804020505040408090007 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit This is the counter-draft to draft-inacio-ipfix-penie-00. Unfortunately it didn't get posted last time due to some formatting and nits issues, which I've now fixed. P. -------- Original Message -------- Subject: New Version Notification for draft-aitken-ipfix-equivalent-ies-00.txt Date: Fri, 15 Feb 2013 09:56:12 -0800 From: internet-drafts@ietf.org To: paitken@cisco.com A new version of I-D, draft-aitken-ipfix-equivalent-ies-00.txt has been successfully submitted by Paul Aitken and posted to the IETF repository. Filename: draft-aitken-ipfix-equivalent-ies Revision: 00 Title: Reporting Equivalent IPFIX Information Elements Creation date: 2013-02-15 Group: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-aitken-ipfix-equivalent-ies-00.txt Status: http://datatracker.ietf.org/doc/draft-aitken-ipfix-equivalent-ies Htmlized: http://tools.ietf.org/html/draft-aitken-ipfix-equivalent-ies-00 Abstract: This document proposes a method for IPFIX Exporting Processes to inform Collecting Processes of equivalent Information Elements, so that the Collecting Process can understand the equivalence and be enabled to process data across a change of Information Elements. The IETF Secretariat --------------030804020505040408090007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit This is the counter-draft to draft-inacio-ipfix-penie-00.

Unfortunately it didn't get posted last time due to some formatting and nits issues, which I've now fixed.

P.


-------- Original Message --------
Subject: New Version Notification for draft-aitken-ipfix-equivalent-ies-00.txt
Date: Fri, 15 Feb 2013 09:56:12 -0800
From: internet-drafts@ietf.org
To: paitken@cisco.com 


A new version of I-D, draft-aitken-ipfix-equivalent-ies-00.txt
has been successfully submitted by Paul Aitken and posted to the
IETF repository.

Filename:	 draft-aitken-ipfix-equivalent-ies
Revision:	 00
Title:		 Reporting Equivalent IPFIX Information Elements
Creation date:	 2013-02-15
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-aitken-ipfix-equivalent-ies-00.txt
Status:          http://datatracker.ietf.org/doc/draft-aitken-ipfix-equivalent-ies
Htmlized:        http://tools.ietf.org/html/draft-aitken-ipfix-equivalent-ies-00


Abstract:
     This document proposes a method for IPFIX Exporting Processes
     to inform Collecting Processes of equivalent Information
     Elements, so that the Collecting Process can understand the
     equivalence and be enabled to process data across a change of
     Information Elements.


                                                                                  


The IETF Secretariat


--------------030804020505040408090007-- From ramk@Brocade.com Sun Feb 17 22:41: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 C6F4521F8BA7 for ; Sun, 17 Feb 2013 22:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D85yqtgFlEq6 for ; Sun, 17 Feb 2013 22:41:45 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 490F321F8BA4 for ; Sun, 17 Feb 2013 22:41:45 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r1I6fTId030289; Sun, 17 Feb 2013 22:41:43 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1aju8rgb2f-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 17 Feb 2013 22:41:43 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sun, 17 Feb 2013 22:41:42 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Sun, 17 Feb 2013 22:41:42 -0800 From: ramki Krishnan To: "ipfix@ietf.org" Date: Sun, 17 Feb 2013 22:41:35 -0800 Thread-Topic: New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-01.txt Thread-Index: Ac4NXzVz0nQ3AsPbQ86TE5em8fyk1wAQzvnA Message-ID: References: <20130217223618.23473.71237.idtracker@ietfa.amsl.com> In-Reply-To: <20130217223618.23473.71237.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-18_01:2013-02-15, 2013-02-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1302170396 Cc: David Meyer , "ning.so@tatacommunications.com" Subject: Re: [IPFIX] New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-01.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, 18 Feb 2013 06:41:47 -0000 RGVhciBBbGwsDQoNClRoZSBjb250ZW50IG9mIHRoZSBkcmFmdCBoYXMgYmVlbiBzdWJzdGFudGlh bGx5IGVuaGFuY2VkIHdpdGggc2ltdWxhdGlvbiByZXN1bHRzIGZvciB0aGUgc3VnZ2VzdGVkIHRl Y2huaXF1ZXMuIExvb2tpbmcgZm9yd2FyZCB0byB5b3VyIGNvbW1lbnRzLiANCg0KVGhhbmtzLA0K UmFtDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5 LCBGZWJydWFyeSAxNywgMjAxMyAyOjM2IFBNDQpUbzogcmFta2kgS3Jpc2huYW4NCkNjOiBuaW5n LnNvQHRhdGFjb21tdW5pY2F0aW9ucy5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQta3Jpc2huYW4taXBmaXgtZmxvdy1hd2FyZS1wYWNrZXQtc2FtcGxpbmct MDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWtyaXNobmFuLWlwZml4LWZs b3ctYXdhcmUtcGFja2V0LXNhbXBsaW5nLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSByYW0ga3Jpc2huYW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5 Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWtyaXNobmFuLWlwZml4LWZsb3ctYXdhcmUtcGFja2V0LXNh bXBsaW5nDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBGbG93IEF3YXJlIFBhY2tldCBTYW1wbGlu ZyBUZWNobmlxdWVzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0xNw0KR3JvdXA6CQkgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDExDQpVUkw6ICAgICAgICAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtyaXNobmFuLWlwZml4LWZs b3ctYXdhcmUtcGFja2V0LXNhbXBsaW5nLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyaXNobmFuLWlwZml4LWZsb3ctYXdhcmUt cGFja2V0LXNhbXBsaW5nDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWtyaXNobmFuLWlwZml4LWZsb3ctYXdhcmUtcGFja2V0LXNhbXBsaW5nLTAxDQpE aWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWty aXNobmFuLWlwZml4LWZsb3ctYXdhcmUtcGFja2V0LXNhbXBsaW5nLTAxDQoNCkFic3RyYWN0Og0K ICAgVGhlIGRlbWFuZHMgb24gdGhlIG5ldHdvcmtpbmcgaW5mcmFzdHJ1Y3R1cmUgYW5kIHRodXMg dGhlDQogICBzd2l0Y2gvcm91dGVyIGJhbmR3aWR0aHMgYXJlIGdyb3dpbmcgZXhwb25lbnRpYWxs eTsgdGhlIGRyaXZlcnMgYXJlDQogICBiYW5kd2lkdGggaHVuZ3J5IHJpY2ggbWVkaWEgYXBwbGlj YXRpb25zLCBpbnRlciBkYXRhIGNlbnRlcg0KICAgY29tbXVuaWNhdGlvbnMgZXRjLiBVc2luZyBz YW1wbGluZyB0ZWNobmlxdWVzLCBmb3IgYSBnaXZlbiBzYW1wbGluZw0KICAgcmF0ZSwgdGhlIGFt b3VudCBvZiBzYW1wbGVzIHRoYXQgbmVlZCB0byBiZSBwcm9jZXNzZWQgaXMgaW5jcmVhc2luZw0K ICAgZXhwb25lbnRpYWxseS4gVGhpcyBkcmFmdCBzdWdnZXN0cyBmbG93IGF3YXJlIHNhbXBsaW5n IHRlY2huaXF1ZXMgZm9yDQogICBoYW5kbGluZyB2YXJpb3VzIHNjZW5hcmlvcyB3aXRoIG1pbmlt YWwgc2FtcGxpbmcgb3ZlcmhlYWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From trammell@tik.ee.ethz.ch Sun Feb 17 23:49: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 C0BDE21F8BAF for ; Sun, 17 Feb 2013 23:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu8OL9OD4uW9 for ; Sun, 17 Feb 2013 23:49:11 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFDF21F8B60 for ; Sun, 17 Feb 2013 23:49:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 946FFD9304; Mon, 18 Feb 2013 08:49:08 +0100 (MET) 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 btoGdOnfJqf9; Mon, 18 Feb 2013 08:49:08 +0100 (MET) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) (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 31647D9305; Mon, 18 Feb 2013 08:49:08 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Brian Trammell In-Reply-To: Date: Mon, 18 Feb 2013 08:49:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4CA8A9E3-4E44-473D-B7A6-88A55FEDD060@tik.ee.ethz.ch> References: <20130217223618.23473.71237.idtracker@ietfa.amsl.com> To: ramki Krishnan X-Mailer: Apple Mail (2.1499) Cc: David Meyer , "ning.so@tatacommunications.com" , "ipfix@ietf.org" Subject: Re: [IPFIX] New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-01.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, 18 Feb 2013 07:49:12 -0000 Hi, Ram, Thanks for the interesting draft. I have a couple of comments and = questions thereon... Section 2.1.3 appears to describe a counting Bloom filter using = thresholding and periodic reset; it would be nice to point this out = explicitly.=20 The algorithm presented would seem to have the problem that effective = filtered flow size is phase-dependent: that is, relatively smaller = constant-rate flows beginning early within a counting Bloom filter reset = interval would be detected with the same probability as relatively = larger flows beginning toward the interval. This is not a problem for = long big flows, but flows shorter than the reset interval and crossing a = reset interval will be variably detected based on when they begin. 30 = seconds (the interval in the example) is therefore probably toward the = long end of what you can get away with for an interval. You may want to have a look at Bianchi et al "Measurement Data Reduction = through Variation Rate Metering", proc. INFOCOM 2010, which addresses = this problem (with respect to key variation counting for scan detection = flow prefiltering) using rotating conservative counting Bloom filters = with periodic decay. If you're not concerned with borderline-big flows, = and the phase dependence is acceptable, the technique presented there = may not apply. (On that, a clear applicability statement -- why would I want to do = this, and in which application areas -- would be nice to see, too). In section 6: > for exporting the identified large flows to an external > entity, it is recommended to use one of the protocols recommended = in > evaluation of candidate protocols for IPFIX [RFC 3955] Why recommend an RFC 3955 candidate protocol for large flow export, as = opposed to IPFIX itself?=20 Also in section 6: > For any > packet formats (for e.g. VXLAN, NVGRE) which are not covered by the > above RFCs, a flow export data model needs to be defined=20 As I understand it, in isolating large flows, the various encapsulations = are really more a problem for the MP's packet decode logic. How a packet = is encapsulated is actually a separate problem from what information you = want to export about each flow. Of course, if you're dealing with encaps = that IPFIX doesn't have IEs for yet, you may want to define them so you = can export information about them, but that seems to orthogonal to the = aim of the draft. Best regards, Brian On Feb 18, 2013, at 7:41 AM, ramki Krishnan wrote: > Dear All, >=20 > The content of the draft has been substantially enhanced with = simulation results for the suggested techniques. Looking forward to your = comments.=20 >=20 > Thanks, > Ram >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Sunday, February 17, 2013 2:36 PM > To: ramki Krishnan > Cc: ning.so@tatacommunications.com > Subject: New Version Notification for = draft-krishnan-ipfix-flow-aware-packet-sampling-01.txt >=20 >=20 > A new version of I-D, = draft-krishnan-ipfix-flow-aware-packet-sampling-01.txt > has been successfully submitted by ram krishnan and posted to the IETF = repository. >=20 > Filename: draft-krishnan-ipfix-flow-aware-packet-sampling > Revision: 01 > Title: Flow Aware Packet Sampling Techniques > Creation date: 2013-02-17 > Group: Individual Submission > Number of pages: 11 > URL: = http://www.ietf.org/internet-drafts/draft-krishnan-ipfix-flow-aware-packet= -sampling-01.txt > Status: = http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sam= pling > Htmlized: = http://tools.ietf.org/html/draft-krishnan-ipfix-flow-aware-packet-sampling= -01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-krishnan-ipfix-flow-aware-packet-= sampling-01 >=20 > Abstract: > The demands on the networking infrastructure and thus the > switch/router bandwidths are growing exponentially; the drivers are > bandwidth hungry rich media applications, inter data center > communications etc. Using sampling techniques, for a given sampling > rate, the amount of samples that need to be processed is increasing > exponentially. This draft suggests flow aware sampling techniques = for > handling various scenarios with minimal sampling overhead. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Mon Feb 18 06:51:50 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 9D5F121F899F; Mon, 18 Feb 2013 06:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RabOsdUgaWGc; Mon, 18 Feb 2013 06:51:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2770E21F8942; Mon, 18 Feb 2013 06:51:50 -0800 (PST) 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.40 Message-ID: <20130218145150.14470.36460.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 06:51:50 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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, 18 Feb 2013 14:51: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-06.txt Pages : 69 Date : 2013-02-18 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trammell@tik.ee.ethz.ch Mon Feb 18 07:15: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 19A0121F8A56 for ; Mon, 18 Feb 2013 07:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kNdmr3kEmU6 for ; Mon, 18 Feb 2013 07:14:59 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 26D7621F86CE for ; Mon, 18 Feb 2013 07:14:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 28D37D9309 for ; Mon, 18 Feb 2013 16:14:57 +0100 (MET) 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 7wvyODWq-Z93 for ; Mon, 18 Feb 2013 16:14:56 +0100 (MET) 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 EDE04D9305 for ; Mon, 18 Feb 2013 16:14:56 +0100 (MET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Brian Trammell In-Reply-To: <20130218145150.14470.36460.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 16:14:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48814FFB-7B44-4743-A2D4-B0BCDD800A62@tik.ee.ethz.ch> References: <20130218145150.14470.36460.idtracker@ietfa.amsl.com> To: IETF IPFIX Working Group X-Mailer: Apple Mail (2.1283) Subject: Re: [IPFIX] I-D Action: draft-ietf-ipfix-protocol-rfc5101bis-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, 18 Feb 2013 15:15:00 -0000 Greetings, all, This revision incorporates clarifications and editorial changes from an = extensive review, and comments from a security area review on = RFC5102bis. Best regards, Brian On 18 Feb 2013, at 15:51 , 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 : 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-06.txt > Pages : 69 > Date : 2013-02-18 >=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 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-protocol-rfc5101bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipfix-protocol-rfc5101bis-06 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-protocol-rfc5101bis-06= >=20 >=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 ramk@Brocade.com Mon Feb 18 08:34: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 0F62521F8B0B for ; Mon, 18 Feb 2013 08:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxV-4EwvFbPo for ; Mon, 18 Feb 2013 08:34:26 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6C96921F8B04 for ; Mon, 18 Feb 2013 08:34:25 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r1IGYOii022814; Mon, 18 Feb 2013 08:34:24 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1aj4hq0wwy-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2013 08:34:23 -0800 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 18 Feb 2013 08:34:22 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Mon, 18 Feb 2013 08:34:22 -0800 From: ramki Krishnan To: Brian Trammell Date: Mon, 18 Feb 2013 08:34:14 -0800 Thread-Topic: [IPFIX] New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-01.txt Thread-Index: Ac4NrHFzk9MMmVb+SPmNGBsYw/47DAAQ2Lcg Message-ID: References: <20130217223618.23473.71237.idtracker@ietfa.amsl.com> <4CA8A9E3-4E44-473D-B7A6-88A55FEDD060@tik.ee.ethz.ch> In-Reply-To: <4CA8A9E3-4E44-473D-B7A6-88A55FEDD060@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-18_04:2013-02-18, 2013-02-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1302180134 Cc: David Meyer , "ning.so@tatacommunications.com" , "ipfix@ietf.org" Subject: Re: [IPFIX] New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-01.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, 18 Feb 2013 16:34:28 -0000 Hi Brian, Thanks a lot for your comments. Please find responses inline. Thanks, Ram -----Original Message----- From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch]=20 Sent: Sunday, February 17, 2013 11:49 PM To: ramki Krishnan Cc: ipfix@ietf.org; David Meyer; ning.so@tatacommunications.com Subject: Re: [IPFIX] New Version Notification for draft-krishnan-ipfix-flow= -aware-packet-sampling-01.txt Hi, Ram, Thanks for the interesting draft. I have a couple of comments and questions= thereon... Section 2.1.3 appears to describe a counting Bloom filter using thresholdin= g and periodic reset; it would be nice to point this out explicitly.=20 [ramki Krishnan] Thanks, will do. The algorithm presented would seem to have the problem that effective filte= red flow size is phase-dependent: that is, relatively smaller constant-rate= flows beginning early within a counting Bloom filter reset interval would = be detected with the same probability as relatively larger flows beginning = toward the interval. This is not a problem for long big flows, but flows sh= orter than the reset interval and crossing a reset interval will be variabl= y detected based on when they begin. 30 seconds (the interval in the exampl= e) is therefore probably toward the long end of what you can get away with = for an interval. You may want to have a look at Bianchi et al "Measurement Data Reduction th= rough Variation Rate Metering", proc. INFOCOM 2010, which addresses this pr= oblem (with respect to key variation counting for scan detection flow prefi= ltering) using rotating conservative counting Bloom filters with periodic d= ecay. If you're not concerned with borderline-big flows, and the phase depe= ndence is acceptable, the technique presented there may not apply. (On that, a clear applicability statement -- why would I want to do this, = and in which application areas -- would be nice to see, too). [ramki Krishnan] Thanks for the reference, will add the applicability state= ment also. By any chance, could you please share a copy of the paper ? In section 6: > for exporting the identified large flows to an external > entity, it is recommended to use one of the protocols recommended in > evaluation of candidate protocols for IPFIX [RFC 3955] Why recommend an RFC 3955 candidate protocol for large flow export, as oppo= sed to IPFIX itself?=20 [ramki Krishnan] The aim was to keep the flow information export formats g= eneric -- since this draft is being pursued in the IPFIX working group, it = is worth narrowing it down to IPFIX as you suggested. Also in section 6: > For any > packet formats (for e.g. VXLAN, NVGRE) which are not covered by the > above RFCs, a flow export data model needs to be defined=20 As I understand it, in isolating large flows, the various encapsulations ar= e really more a problem for the MP's packet decode logic. How a packet is e= ncapsulated is actually a separate problem from what information you want t= o export about each flow. Of course, if you're dealing with encaps that IPF= IX doesn't have IEs for yet, you may want to define them so you can export = information about them, but that seems to orthogonal to the aim of the draf= t. [ramki Krishnan] The aim is to identify gaps in standardization in depende= nt areas -- encaps for which IPFIX doesn't have IEs yet, would be a separat= e draft. Best regards, Brian On Feb 18, 2013, at 7:41 AM, ramki Krishnan wrote: > Dear All, >=20 > The content of the draft has been substantially enhanced with simulation = results for the suggested techniques. Looking forward to your comments.=20 >=20 > Thanks, > Ram >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Sunday, February 17, 2013 2:36 PM > To: ramki Krishnan > Cc: ning.so@tatacommunications.com > Subject: New Version Notification for draft-krishnan-ipfix-flow-aware-pac= ket-sampling-01.txt >=20 >=20 > A new version of I-D, draft-krishnan-ipfix-flow-aware-packet-sampling-01.= txt > has been successfully submitted by ram krishnan and posted to the IETF re= pository. >=20 > Filename: draft-krishnan-ipfix-flow-aware-packet-sampling > Revision: 01 > Title: Flow Aware Packet Sampling Techniques > Creation date: 2013-02-17 > Group: Individual Submission > Number of pages: 11 > URL: http://www.ietf.org/internet-drafts/draft-krishnan-ipfix= -flow-aware-packet-sampling-01.txt > Status: http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flo= w-aware-packet-sampling > Htmlized: http://tools.ietf.org/html/draft-krishnan-ipfix-flow-awa= re-packet-sampling-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-krishnan-ipfix-= flow-aware-packet-sampling-01 >=20 > Abstract: > The demands on the networking infrastructure and thus the > switch/router bandwidths are growing exponentially; the drivers are > bandwidth hungry rich media applications, inter data center > communications etc. Using sampling techniques, for a given sampling > rate, the amount of samples that need to be processed is increasing > exponentially. This draft suggests flow aware sampling techniques for > handling various scenarios with minimal sampling overhead. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Wed Feb 20 16:35:04 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 EC7B621E804B for ; Wed, 20 Feb 2013 16:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3QdMwmZVlIY for ; Wed, 20 Feb 2013 16:35:04 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id F00A021E8049 for ; Wed, 20 Feb 2013 16:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1361406904; x=1392942904; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=NaV93B/8qQZn5W9K8oHLrFSBrlWqVch1vIir9eLQWNU=; b=DykufTwt3YRRbeDTPldy046s3a5n4u8Hb8FXetzwg5n8zpdxPyy55UE7 SMAfoGl70q64wU4o9CB6bJfoSUOLIRtEKEy3DXubleKl8errM547XM5KH QN0uquZRRSszpQCNIwzsU7qaY8QGYDlgKN79VuBEeC3QN4rDxkAMVdjzz Y=; X-IronPort-AV: E=Sophos;i="4.84,705,1355050800"; d="scan'208";a="171434548" 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; 21 Feb 2013 13:35:02 +1300 Message-ID: <51256BB6.9000505@auckland.ac.nz> Date: Thu, 21 Feb 2013 13:35:02 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 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 of IPFIX Agenda for Orlando meeting 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, 21 Feb 2013 00:35:05 -0000 Hi all: My first draft of our agenda is available at http://www.ietf.org/proceedings/86/agenda/agenda-86-ipfix Please send any corrections, suggestions for improvements, etc to me soon. Also, iof you have drafts you'd like to present, we have some time available. 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 ramk@Brocade.com Wed Feb 20 16:45:07 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 4F6F421F8C85 for ; Wed, 20 Feb 2013 16:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6289iyG84uu for ; Wed, 20 Feb 2013 16:45:06 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 735D721F8C68 for ; Wed, 20 Feb 2013 16:45:06 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r1L0gmxp011136; Wed, 20 Feb 2013 16:45:01 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1amwgcgdv5-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Feb 2013 16:45:01 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 20 Feb 2013 16:45:01 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 20 Feb 2013 16:45:00 -0800 From: ramki Krishnan To: Nevil Brownlee , IPFIX Working Group Date: Wed, 20 Feb 2013 16:44:57 -0800 Thread-Topic: [IPFIX] First draft of IPFIX Agenda for Orlando meeting Thread-Index: Ac4Py0/6gf633UN6TvW0sy0uIif5dwAAQEmQ Message-ID: References: <51256BB6.9000505@auckland.ac.nz> In-Reply-To: <51256BB6.9000505@auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-20_11:2013-02-20, 2013-02-20, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1302200254 Subject: Re: [IPFIX] First draft of IPFIX Agenda for Orlando meeting 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, 21 Feb 2013 00:45:07 -0000 Dear Neville, Is the meeting on Wed. or Thu. ? The link below indicates Thursday. https://datatracker.ietf.org/meeting/86/agenda.html Also, please fix my name as "Ram Krishnan" Thanks, Ram -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of N= evil Brownlee Sent: Wednesday, February 20, 2013 4:35 PM To: IPFIX Working Group Subject: [IPFIX] First draft of IPFIX Agenda for Orlando meeting Hi all: My first draft of our agenda is available at http://www.ietf.org/proceedings/86/agenda/agenda-86-ipfix Please send any corrections, suggestions for improvements, etc to me soon. = Also, iof you have drafts you'd like to present, we have some time availab= le. 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From internet-drafts@ietf.org Fri Feb 22 13:30:39 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 A451E21F8EA4; Fri, 22 Feb 2013 13:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC7M0kctb4tV; Fri, 22 Feb 2013 13:30:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0243F21F8E1E; Fri, 22 Feb 2013 13:30:39 -0800 (PST) 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.40 Message-ID: <20130222213039.10329.31677.idtracker@ietfa.amsl.com> Date: Fri, 22 Feb 2013 13:30:39 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-data-link-layer-monitoring-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: Fri, 22 Feb 2013 21:30:39 -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-02.txt Pages : 35 Date : 2013-02-22 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-data-link-layer-monitor= ing-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Feb 23 02:59: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 F3F1D21F8F7A; Sat, 23 Feb 2013 02:59:00 -0800 (PST) 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.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcryp2VY0l0s; Sat, 23 Feb 2013 02:59:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAF121F8F86; Sat, 23 Feb 2013 02:59:00 -0800 (PST) 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.40 Message-ID: <20130223105900.31873.1990.idtracker@ietfa.amsl.com> Date: Sat, 23 Feb 2013 02:59:00 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-13.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: Sat, 23 Feb 2013 10:59:01 -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 : Flow Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-13.txt Pages : 43 Date : 2013-02-23 Abstract: Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-flow-selection-tech-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ramk@Brocade.com Sat Feb 23 18:17: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 2F85721F84A8 for ; Sat, 23 Feb 2013 18:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD0av8PWRxzk for ; Sat, 23 Feb 2013 18:17:51 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id DC12221F84A2 for ; Sat, 23 Feb 2013 18:17:51 -0800 (PST) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r1O2HoZ9007438; Sat, 23 Feb 2013 18:17:50 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1aq12m04s6-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 23 Feb 2013 18:17:50 -0800 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Sat, 23 Feb 2013 18:17:49 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Sat, 23 Feb 2013 18:17:49 -0800 From: ramki Krishnan To: IPFIX Working Group Date: Sat, 23 Feb 2013 18:17:43 -0800 Thread-Topic: New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-02.txt Thread-Index: Ac4SNNU0xhjGhN9zQWWjyqPV41QpkAAAAjkw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-23_06:2013-02-22, 2013-02-23, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1302230334 Cc: "dmm@1-4-5.net" , Ning So Subject: [IPFIX] FW: New Version Notification for draft-krishnan-ipfix-flow-aware-packet-sampling-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: Sun, 24 Feb 2013 02:17:53 -0000 QWxsLA0KDQpBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHBvc3RlZCAtLSBsb29raW5nIGZvcndhcmQg dG8geW91ciBjb21tZW50cy4NCg0KQnJpYW4gLS0gdGhhbmtzIHZlcnkgbXVjaCBmb3IgeW91ciBj b21tZW50cyBvbiB0aGUgcHJldmlvdXMgdmVyc2lvbi4NCg0KVGhhbmtzLA0KUmFtDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5 IDIzLCAyMDEzIDY6MTUgUE0NClRvOiByYW1raSBLcmlzaG5hbg0KQ2M6IHJhbWtpIEtyaXNobmFu OyBkbW1AMS00LTUubmV0OyBuaW5nLnNvQHRhdGFjb21tdW5pY2F0aW9ucy5jb20NClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQta3Jpc2huYW4taXBmaXgtZmxvdy1h d2FyZS1wYWNrZXQtc2FtcGxpbmctMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWtyaXNobmFuLWlwZml4LWZsb3ctYXdhcmUtcGFja2V0LXNhbXBsaW5nLTAyLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSByYW0ga3Jpc2huYW4gYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWtyaXNobmFuLWlwZml4 LWZsb3ctYXdhcmUtcGFja2V0LXNhbXBsaW5nDQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBGbG93 IEF3YXJlIFBhY2tldCBTYW1wbGluZyBUZWNobmlxdWVzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0w Mi0yMw0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEx DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWtyaXNobmFuLWlwZml4LWZsb3ctYXdhcmUtcGFja2V0LXNhbXBsaW5nLTAyLnR4dA0KU3Rh dHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyaXNo bmFuLWlwZml4LWZsb3ctYXdhcmUtcGFja2V0LXNhbXBsaW5nDQpIdG1saXplZDogICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtyaXNobmFuLWlwZml4LWZsb3ctYXdhcmUt cGFja2V0LXNhbXBsaW5nLTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWtyaXNobmFuLWlwZml4LWZsb3ctYXdhcmUtcGFja2V0LXNhbXBs aW5nLTAyDQoNCkFic3RyYWN0Og0KICAgVGhlIGRlbWFuZHMgb24gdGhlIG5ldHdvcmtpbmcgaW5m cmFzdHJ1Y3R1cmUgYW5kIHRodXMgdGhlDQogICBzd2l0Y2gvcm91dGVyIGJhbmR3aWR0aHMgYXJl IGdyb3dpbmcgZXhwb25lbnRpYWxseTsgdGhlIGRyaXZlcnMgYXJlDQogICBiYW5kd2lkdGggaHVu Z3J5IHJpY2ggbWVkaWEgYXBwbGljYXRpb25zLCBpbnRlciBkYXRhIGNlbnRlcg0KICAgY29tbXVu aWNhdGlvbnMgZXRjLiBVc2luZyBzYW1wbGluZyB0ZWNobmlxdWVzLCBmb3IgYSBnaXZlbiBzYW1w bGluZw0KICAgcmF0ZSwgdGhlIGFtb3VudCBvZiBzYW1wbGVzIHRoYXQgbmVlZCB0byBiZSBwcm9j ZXNzZWQgaXMgaW5jcmVhc2luZw0KICAgZXhwb25lbnRpYWxseS4gVGhpcyBkcmFmdCBzdWdnZXN0 cyBmbG93IGF3YXJlIHNhbXBsaW5nIHRlY2huaXF1ZXMgZm9yDQogICBoYW5kbGluZyB2YXJpb3Vz IHNjZW5hcmlvcyB3aXRoIG1pbmltYWwgc2FtcGxpbmcgb3ZlcmhlYWQuDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From bclaise@cisco.com Sun Feb 24 07:07: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 A8A5C21F85ED for ; Sun, 24 Feb 2013 07:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffvPdkwsub8G for ; Sun, 24 Feb 2013 07:07:41 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF2621F8447 for ; Sun, 24 Feb 2013 07:07:40 -0800 (PST) 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 r1OF7bkr019314; Sun, 24 Feb 2013 16:07:37 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1OF7FaS005940; Sun, 24 Feb 2013 16:07:27 +0100 (CET) Message-ID: <512A2CA3.8060809@cisco.com> Date: Sun, 24 Feb 2013 16:07:15 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20130223105900.31873.39377.idtracker@ietfa.amsl.com> In-Reply-To: <20130223105900.31873.39377.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------040302030301030107070209" Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Subject: Re: [IPFIX] New Version Notification - draft-ietf-ipfix-flow-selection-tech-13.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: Sun, 24 Feb 2013 15:07:42 -0000 This is a multi-part message in MIME format. --------------040302030301030107070209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Looking at the diff, I have the following feedback. flowSelectorAlgorithm is a new IE, to be registered by IANA I see this in section 7.1: New assignments for the registry will be administered by IANA and are subject to Expert Review [RFC5226 ]. This new registry should be in the IANA considerations section. For an example of the IANA considerations, see http://tools.ietf.org/html/rfc6313#section-11.3 So the section 7.1 to 7.11 should be in the IANA considerations section. Also, in that registry, I see: +----+------------------------+--------------------------+ |TBDx| Flow-state Dependent | No agreed Parameters | | | Intermediate Flow | | | | Selection Process | | +----+------------------------+--------------------------+ This should be +----+------------------------+--------------------------+ | 9 | Flow-state Dependent | No agreed Parameters | | | Intermediate Flow | | | | Selection Process | | +----+------------------------+--------------------------+ On this last point, I realized that I mislead you. Mea culpa. I see in section 7.x Status: Proposed The status should be "current" Really, http://tools.ietf.org/html/rfc6313#section-11.3 is a good example. And finally, there are new fields in http://www.iana.org/assignments/ipfix/ipfix.xml since you posted you version. For example "revision". Instruct IANA that they need to put the value 0. These comments can be taken into account part of the WGLC to come. Up to chairs to decide. Regards, Benoit > A new version (-13) has been submitted for draft-ietf-ipfix-flow-selection-tech: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-13.txt > > Sub state has been changed to AD Followup from Revised ID Needed > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ > > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-flow-selection-tech-13 > > IETF Secretariat. > > > --------------040302030301030107070209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dear authors,

Looking at the diff, I have the following feedback.

flowSelectorAlgorithm is a new IE, to be registered by IANA
I see this in section 7.1:
New assignments for the registry will be administered by
IANA and are subject to Expert Review [RFC5226].
This new registry should be in the IANA considerations section.
For an example of the IANA considerations, see http://tools.ietf.org/html/rfc6313#section-11.3
So the section 7.1 to 7.11 should be in the IANA considerations section.

Also, in that registry, I see:
   +----+------------------------+--------------------------+
   |TBDx| Flow-state Dependent   | No agreed Parameters     |
   |    | Intermediate Flow      |                          |
   |    | Selection Process      |                          |
   +----+------------------------+--------------------------+
This should be
   +----+------------------------+--------------------------+
   |  9 | Flow-state Dependent   | No agreed Parameters     |
   |    | Intermediate Flow      |                          |
   |    | Selection Process      |                          |
   +----+------------------------+--------------------------+
On this last point, I realized that I mislead you. Mea culpa.

I see  in section 7.x
   Status: Proposed
The status should be "current"

Really, http://tools.ietf.org/html/rfc6313#section-11.3 is a good example.

And finally, there are new fields in http://www.iana.org/assignments/ipfix/ipfix.xml since you posted you version. For example "revision". Instruct IANA that they need to put the value 0.

These comments can be taken into account part of the WGLC to come. Up to chairs to decide.

Regards, Benoit
A new version (-13) has been submitted for draft-ietf-ipfix-flow-selection-tech:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-13.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-flow-selection-tech-13

IETF Secretariat.

--------------040302030301030107070209-- From paitken@cisco.com Sun Feb 24 08:40: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 0AE8821F903E for ; Sun, 24 Feb 2013 08:40:52 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOcsRF5QA8tB for ; Sun, 24 Feb 2013 08:40:50 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id E53F821F903B for ; Sun, 24 Feb 2013 08:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8598; q=dns/txt; s=iport; t=1361724037; x=1362933637; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=zN+rxX/8hX05NOkMx3k4i2XvCHz5h6yI+LAxvYmiEDk=; b=Rq74jVX8stk+LZKj7rBZdUSiHQp3j5D3+uOti9ovI8l8nSpQSWARgAG9 fSMF9vbvstcyYey+XJpB2FlUM2QpbYc86rzU2w3e7qQv2iAn7ni2Fgz+g ZWwgGND0rlBD/Jw+dyi1cvvl0jYSsq7NIO7ruX9Ctjjsk57Fb3UsRDpPL I=; X-IronPort-AV: E=Sophos;i="4.84,728,1355097600"; d="scan'208,217";a="12019746" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 24 Feb 2013 16:40:33 +0000 Received: from [10.55.83.124] (dhcp-10-55-83-124.cisco.com [10.55.83.124]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1OGeWMT014792; Sun, 24 Feb 2013 16:40:33 GMT Message-ID: <512A4282.6050401@cisco.com> Date: Sun, 24 Feb 2013 16:40:34 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Benoit Claise , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org References: <20130223105900.31873.39377.idtracker@ietfa.amsl.com> <512A2CA3.8060809@cisco.com> In-Reply-To: <512A2CA3.8060809@cisco.com> Content-Type: multipart/alternative; boundary="------------070806020702020708000301" Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] New Version Notification - draft-ietf-ipfix-flow-selection-tech-13.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: Sun, 24 Feb 2013 16:40:52 -0000 This is a multi-part message in MIME format. --------------070806020702020708000301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benoit, Authors, Rather than defining a new "flowSelectorAlgorithm", shouldn't the proposed algorithms be added to the existing selectorAlgorithm #304? This only requires removing "packet" from the existing definition (or s/packet/packet and flow/), and allow that a Selection Process can be either a packet selection process or a flow selection process. P. On 24/02/13 15:07, Benoit Claise wrote: > Dear authors, > > Looking at the diff, I have the following feedback. > > flowSelectorAlgorithm is a new IE, to be registered by IANA > I see this in section 7.1: > > New assignments for the registry will be administered by > IANA and are subject to Expert Review [RFC5226 ]. > > This new registry should be in the IANA considerations section. > For an example of the IANA considerations, see > http://tools.ietf.org/html/rfc6313#section-11.3 > So the section 7.1 to 7.11 should be in the IANA considerations section. > > Also, in that registry, I see: > +----+------------------------+--------------------------+ > |TBDx| Flow-state Dependent | No agreed Parameters | > | | Intermediate Flow | | > | | Selection Process | | > +----+------------------------+--------------------------+ > This should be > +----+------------------------+--------------------------+ > | 9 | Flow-state Dependent | No agreed Parameters | > | | Intermediate Flow | | > | | Selection Process | | > +----+------------------------+--------------------------+ > On this last point, I realized that I mislead you. Mea culpa. > > I see in section 7.x > Status: Proposed > The status should be "current" > > Really, http://tools.ietf.org/html/rfc6313#section-11.3 is a good example. > > And finally, there are new fields in > http://www.iana.org/assignments/ipfix/ipfix.xml since you posted you > version. For example "revision". Instruct IANA that they need to put > the value 0. > > These comments can be taken into account part of the WGLC to come. Up > to chairs to decide. > > Regards, Benoit >> A new version (-13) has been submitted for draft-ietf-ipfix-flow-selection-tech: >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-13.txt >> >> Sub state has been changed to AD Followup from Revised ID Needed >> >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ >> >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-flow-selection-tech-13 >> >> IETF Secretariat. >> >> >> > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------070806020702020708000301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Benoit, Authors,

Rather than defining a new "flowSelectorAlgorithm", shouldn't the proposed algorithms be added to the existing selectorAlgorithm #304?

This only requires removing "packet" from the existing definition (or s/packet/packet and flow/), and allow that a Selection Process can be either a packet selection process or a flow selection process.

P.


On 24/02/13 15:07, Benoit Claise wrote:
Dear authors,

Looking at the diff, I have the following feedback.

flowSelectorAlgorithm is a new IE, to be registered by IANA
I see this in section 7.1:
New assignments for the registry will be administered by
IANA and are subject to Expert Review [RFC5226].
This new registry should be in the IANA considerations section.
For an example of the IANA considerations, see http://tools.ietf.org/html/rfc6313#section-11.3
So the section 7.1 to 7.11 should be in the IANA considerations section.

Also, in that registry, I see:
   +----+------------------------+--------------------------+
   |TBDx| Flow-state Dependent   | No agreed Parameters     |
   |    | Intermediate Flow      |                          |
   |    | Selection Process      |                          |
   +----+------------------------+--------------------------+
This should be
   +----+------------------------+--------------------------+
   |  9 | Flow-state Dependent   | No agreed Parameters     |
   |    | Intermediate Flow      |                          |
   |    | Selection Process      |                          |
   +----+------------------------+--------------------------+
On this last point, I realized that I mislead you. Mea culpa.

I see  in section 7.x
   Status: Proposed
The status should be "current"

Really, http://tools.ietf.org/html/rfc6313#section-11.3 is a good example.

And finally, there are new fields in http://www.iana.org/assignments/ipfix/ipfix.xml since you posted you version. For example "revision". Instruct IANA that they need to put the value 0.

These comments can be taken into account part of the WGLC to come. Up to chairs to decide.

Regards, Benoit
A new version (-13) has been submitted for draft-ietf-ipfix-flow-selection-tech:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-13.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-flow-selection-tech-13

IETF Secretariat.







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

--------------070806020702020708000301-- From bclaise@cisco.com Sun Feb 24 09:40: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 E60F121F9080 for ; Sun, 24 Feb 2013 09:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccmmNABMp3Br for ; Sun, 24 Feb 2013 09:40:00 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C4FC721F9073 for ; Sun, 24 Feb 2013 09:39:59 -0800 (PST) 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 r1OHSdlh000935; Sun, 24 Feb 2013 18:28:39 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1OHS8KA015372; Sun, 24 Feb 2013 18:28:13 +0100 (CET) Message-ID: <512A4DA8.4040809@cisco.com> Date: Sun, 24 Feb 2013 18:28:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Paul Aitken References: <20130223105900.31873.39377.idtracker@ietfa.amsl.com> <512A2CA3.8060809@cisco.com> <512A4282.6050401@cisco.com> In-Reply-To: <512A4282.6050401@cisco.com> Content-Type: multipart/alternative; boundary="------------050509000208080107050406" Cc: "ipfix@ietf.org" , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Subject: Re: [IPFIX] New Version Notification - draft-ietf-ipfix-flow-selection-tech-13.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: Sun, 24 Feb 2013 17:40:01 -0000 This is a multi-part message in MIME format. --------------050509000208080107050406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 24/02/2013 17:40, Paul Aitken wrote: > Benoit, Authors, > > Rather than defining a new "flowSelectorAlgorithm", shouldn't the > proposed algorithms be added to the existing selectorAlgorithm #304? > > This only requires removing "packet" from the existing definition (or > s/packet/packet and flow/), and allow that a Selection Process can be > either a packet selection process or a flow selection process. That would be nice, but I guess we would have to update all the PSAMP RFCs. In particular, http://tools.ietf.org/html/rfc5477#section-8.2.1 So in practice, not sure that will happen. Regards, Benoit > > P. > > > On 24/02/13 15:07, Benoit Claise wrote: >> Dear authors, >> >> Looking at the diff, I have the following feedback. >> >> flowSelectorAlgorithm is a new IE, to be registered by IANA >> I see this in section 7.1: >> >> New assignments for the registry will be administered by >> IANA and are subject to Expert Review [RFC5226 ]. >> >> This new registry should be in the IANA considerations section. >> For an example of the IANA considerations, see >> http://tools.ietf.org/html/rfc6313#section-11.3 >> So the section 7.1 to 7.11 should be in the IANA considerations section. >> >> Also, in that registry, I see: >> +----+------------------------+--------------------------+ >> |TBDx| Flow-state Dependent | No agreed Parameters | >> | | Intermediate Flow | | >> | | Selection Process | | >> +----+------------------------+--------------------------+ >> This should be >> +----+------------------------+--------------------------+ >> | 9 | Flow-state Dependent | No agreed Parameters | >> | | Intermediate Flow | | >> | | Selection Process | | >> +----+------------------------+--------------------------+ >> On this last point, I realized that I mislead you. Mea culpa. >> >> I see in section 7.x >> Status: Proposed >> The status should be "current" >> >> Really, http://tools.ietf.org/html/rfc6313#section-11.3 is a good >> example. >> >> And finally, there are new fields in >> http://www.iana.org/assignments/ipfix/ipfix.xml since you posted you >> version. For example "revision". Instruct IANA that they need to put >> the value 0. >> >> These comments can be taken into account part of the WGLC to come. Up >> to chairs to decide. >> >> Regards, Benoit >>> A new version (-13) has been submitted for draft-ietf-ipfix-flow-selection-tech: >>> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-13.txt >>> >>> Sub state has been changed to AD Followup from Revised ID Needed >>> >>> >>> The IETF datatracker page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ >>> >>> Diff from previous version: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-flow-selection-tech-13 >>> >>> IETF Secretariat. >>> >>> >>> >> >> >> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix > --------------050509000208080107050406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 24/02/2013 17:40, Paul Aitken wrote:
Benoit, Authors,

Rather than defining a new "flowSelectorAlgorithm", shouldn't the proposed algorithms be added to the existing selectorAlgorithm #304?

This only requires removing "packet" from the existing definition (or s/packet/packet and flow/), and allow that a Selection Process can be either a packet selection process or a flow selection process.
That would be nice, but I guess we would have to update all the PSAMP RFCs. In particular, http://tools.ietf.org/html/rfc5477#section-8.2.1
So in practice, not sure that will happen.

Regards, Benoit

P.


On 24/02/13 15:07, Benoit Claise wrote:
Dear authors,

Looking at the diff, I have the following feedback.

flowSelectorAlgorithm is a new IE, to be registered by IANA
I see this in section 7.1:
New assignments for the registry will be administered by
IANA and are subject to Expert Review [RFC5226].
This new registry should be in the IANA considerations section.
For an example of the IANA considerations, see http://tools.ietf.org/html/rfc6313#section-11.3
So the section 7.1 to 7.11 should be in the IANA considerations section.

Also, in that registry, I see:
   +----+------------------------+--------------------------+
   |TBDx| Flow-state Dependent   | No agreed Parameters     |
   |    | Intermediate Flow      |                          |
   |    | Selection Process      |                          |
   +----+------------------------+--------------------------+
This should be
   +----+------------------------+--------------------------+
   |  9 | Flow-state Dependent   | No agreed Parameters     |
   |    | Intermediate Flow      |                          |
   |    | Selection Process      |                          |
   +----+------------------------+--------------------------+
On this last point, I realized that I mislead you. Mea culpa.

I see  in section 7.x
   Status: Proposed
The status should be "current"

Really, http://tools.ietf.org/html/rfc6313#section-11.3 is a good example.

And finally, there are new fields in http://www.iana.org/assignments/ipfix/ipfix.xml since you posted you version. For example "revision". Instruct IANA that they need to put the value 0.

These comments can be taken into account part of the WGLC to come. Up to chairs to decide.

Regards, Benoit
A new version (-13) has been submitted for draft-ietf-ipfix-flow-selection-tech:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-13.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-flow-selection-tech-13

IETF Secretariat.







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


--------------050509000208080107050406-- From akoba@orange.plala.or.jp Sun Feb 24 12:51:08 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 74B4321F911D for ; Sun, 24 Feb 2013 12:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.369 X-Spam-Level: *** X-Spam-Status: No, score=3.369 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_37=0.6, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eSj8+eStnIV for ; Sun, 24 Feb 2013 12:51:07 -0800 (PST) Received: from msa03b.plala.or.jp (msa03.plala.or.jp [58.93.240.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4432121F911B for ; Sun, 24 Feb 2013 12:51:03 -0800 (PST) Received: from [192.168.1.11] (really [121.114.126.45]) by msa03b.plala.or.jp with SMTP id <20130224205056.RNEV17222.msa03b.plala.or.jp@[192.168.1.11]>; Mon, 25 Feb 2013 05:50:56 +0900 Date: Mon, 25 Feb 2013 05:50:56 +0900 From: ATSUSHI KOBAYASHI To: "Pat Thaler" In-Reply-To: References: Message-Id: <20130225055056.1468.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.61.01 [ja] X-VirusScan: Outbound; msa03b; Mon, 25 Feb 2013 05:50:56 +0900 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Fwd: WG Last Call for draft-ietf-ipfix-data-link-layer-monitoring-01 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, 24 Feb 2013 20:51:08 -0000 Hi Pat, We have finished to improve the draft in accordance with your comments. Please let us know your comments for new version. http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-02 We improved it about the several issues: a) "2.2. Virtual Ethernet Technology Summary" We improved subsection 2.2, and changed the title from "Data Center Bridging Summary". It describes Edge Virtual Bridging and Bridge Port Extension. b) "2.3. Multiple Path Ethernet Summary" Removed it. c) New Information Elements "dot1qTagProtocolIdentification" The reuse of dot1qVlanId for C-TAG, S-TAG, and B-TAG makes difficult to recognize its semantic. Thus, we added dot1qTagProtocolIdentification Information Elements. It indicates TAG type. d) New Information Elements related to E-TAG in IEEE 802.1BR In the old draft, there was no Information Element related to E-TAG used in Port Extention. we added dot1brEChannelTag and dot1brEChannelPriority. Thanks to them, we can monitor VM-to-VM traffic within emulated Extended Bridge. Regards, Atsushi On Wed, 19 Dec 2012 03:25:58 +0000 "Pat Thaler" wrote: > There are a number of items that should be corrected in this draft. > > > * The draft is out of date with respect to status of 802.1 and 802.3 standards. Please replace with current references. > > o The amendments IEEE 802.1ad and 802.1ah are not active standards as the material from them was incorporated into IEEE 802.1Q revisions. References to them should be changed to the current revision of 802.1Q > > o The current revision of 802.1Q is IEEE Std 802.1Q-2011. > > o The current revision of 802.3 is IEEE Std 802.3-2012 (which has been approved and should be published shortly). It doesn't have a subclause 3.5. This was removed in the 2008 revision of 802.3 as the subclause just duplicated information from 802.1Q. 802.1Q should be used as the reference for fields such as VLAN ID and priority code point. > > o 802.1BR only specifies Bridge Port Extension so only Figure B-4 shows a frame format specified in 802.1BR > > o 802.1Qbg Edge Virtual Bridging specifies use of an S-Tag to identify traffic belonging to S-Channels (i.e. a virtual link) on a physical link between an end station and the adjacent bridge so the formats in Figure B-1 and B-2 would apply to 802.1Qbg, not 802.1BR. > > * The frame formats for Edge Virtual Bridging and Port Extension apply only between the end node and adjacent bridge (for figures B-1 and B-2) or within an Extended Bridge (i.e. a controlling bridge plus its port extenders, figure B-3). They are never used between bridges for those standards. The Edge Virtual Bridge frame formats use the same tags as Provider Bridged frame formats (Figure A-3 and A-4). When the frames with that format are used between bridges it is provider bridging which is used in some data centers as well as in the WAN. It would be better to organize the frame format annexes as frame formats used between bridges and frame formats used for Edge Virtual Bridging between edge devices and their bridge and within an Extended Bridge. > > * 2.2 Data Center Bridging - the content here seems confused. It isn't clear what the relevance of this summary is to the draft since information elements for the IEEE 802.1BR E-Tag have not been added. The E-Tag only appears between elements of an Extended Bridge and the Controlling Bridge has visibility of all the traffic in the Extended Bridge so it isn't clear to me that data link layer monitoring is relevant to it (any more than it would be to monitoring traffic between blades in a blade bridge). The C-Tag is used in Data Center Bridging the same way as in all 802.1Q bridging so that isn't a special case. The use of the S-Tag for Edge Virtual Bridging S-Channels only occurs on the link between an end station and its adjacent bridge. No additional elements are needed for these. The conclusion that Data Center Bridging complicates traffic measurement is not substantiated. Please remove 2.2 or if it is retained make it more clear and accurate. > > * 2.3 Multiple Path Ethernet Summary - says "two solutions are discussed for standardization" implying that the standards haven't been finished. IEEE Std 802.1aq-2012 Shortest Path Bridging is an approved standard which was published in June. > > * 2.4 VXLAN - The limit of the 12-bit VLAN ID is not the motivating factor for Network Virtualization Overlay (NVO3). If it was, the I-Tag which supports a 24-bit service identifier would suffice. A more significant motivator for the NVO3 is allowing for IP and MAC address isolation between the data center (which may be a layer 3 data center) and the tenant networks and between the tenant networks. The problem statement draft, draft-ietf-nvo3-overlay-problem-statement-01, provides a more complete description of the motivating factors. VXLAN is not the only proposed encapsulation for NVO3. It seems early to mention this topic as we haven't decided on which solutions to standardize. No information elements have been added for it so 2.4 could be deleted. If it remains, it should point to the NVO3 work in general rather than a specific proposal. > > * 5.1 and 5.2 - formally, there is no such thing as an 802.1ad frame or 802.1ah since 802.1ad and 802.1ah have been rolled into 802.1Q. You could use S-Tagged and B-Tagged frame. > > Regards, > Pat Thaler -- KOBAYASHI ATSUSHI From paitken@cisco.com Mon Feb 25 01:28:18 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 589F921F9231 for ; Mon, 25 Feb 2013 01:28:18 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjG7olsr5RIn for ; Mon, 25 Feb 2013 01:28:17 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAC721F90B5 for ; Mon, 25 Feb 2013 01:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3156; q=dns/txt; s=iport; t=1361784497; x=1362994097; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=BLly4rt70oull1z5a0yfmsQ7Vx3n8yfdOkOyBPSEeDg=; b=KX2Ho4ZL6UKaOrCfB4XXSH/uP8WnPmZ9uQlJoMaeA0kR5rb4A4ab3Uzt wjXTD9BV0amreWo9lTcmzD+dXihJW35VKDhRZ11LOt1k7Q5ZcFzogz0e2 2tB7rsfjAmt6mnvpOtgvLAvn6d+tVRJ+v2WpBrD4PrDaqN9u1vi86xEuf Q=; X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; d="scan'208,217";a="12042634" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 25 Feb 2013 09:28:13 +0000 Received: from [10.55.87.41] (dhcp-10-55-87-41.cisco.com [10.55.87.41]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1P9SCVl026625; Mon, 25 Feb 2013 09:28:12 GMT Message-ID: <512B2EAD.1060602@cisco.com> Date: Mon, 25 Feb 2013 09:28:13 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Benoit Claise References: <20130223105900.31873.39377.idtracker@ietfa.amsl.com> <512A2CA3.8060809@cisco.com> <512A4282.6050401@cisco.com> <512A4DA8.4040809@cisco.com> In-Reply-To: <512A4DA8.4040809@cisco.com> Content-Type: multipart/alternative; boundary="------------070206050004020207040905" Cc: "ipfix@ietf.org" , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Subject: Re: [IPFIX] New Version Notification - draft-ietf-ipfix-flow-selection-tech-13.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, 25 Feb 2013 09:28:18 -0000 This is a multi-part message in MIME format. --------------070206050004020207040905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Benoit, > On 24/02/2013 17:40, Paul Aitken wrote: >> Benoit, Authors, >> >> Rather than defining a new "flowSelectorAlgorithm", shouldn't the >> proposed algorithms be added to the existing selectorAlgorithm #304? >> >> This only requires removing "packet" from the existing definition (or >> s/packet/packet and flow/), and allow that a Selection Process can be >> either a packet selection process or a flow selection process. > That would be nice, but I guess we would have to update all the PSAMP > RFCs. In particular, http://tools.ietf.org/html/rfc5477#section-8.2.1 No, because we already decided that IANA's IPFIX registry is the master repository over the IPFIX RFCs - the registry can be updated, corrected, and extended, whereas the RFCs cannot. So the same must hold for the PSAMP RFCs. P. --------------070206050004020207040905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Benoit,

On 24/02/2013 17:40, Paul Aitken wrote:
Benoit, Authors,

Rather than defining a new "flowSelectorAlgorithm", shouldn't the proposed algorithms be added to the existing selectorAlgorithm #304?

This only requires removing "packet" from the existing definition (or s/packet/packet and flow/), and allow that a Selection Process can be either a packet selection process or a flow selection process.
That would be nice, but I guess we would have to update all the PSAMP RFCs. In particular, http://tools.ietf.org/html/rfc5477#section-8.2.1

No, because we already decided that IANA's IPFIX registry is the master repository over the IPFIX RFCs - the registry can be updated, corrected, and extended, whereas the RFCs cannot.

So the same must hold for the PSAMP RFCs.

P.

--------------070206050004020207040905-- From bclaise@cisco.com Mon Feb 25 01:44: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 D250E21F900A for ; Mon, 25 Feb 2013 01:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrlRzJL9HtSj for ; Mon, 25 Feb 2013 01:44:19 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id F1DF721F8FF2 for ; Mon, 25 Feb 2013 01:44:18 -0800 (PST) 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 r1P9iHG5029638; Mon, 25 Feb 2013 10:44:18 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1P9hkKB007012; Mon, 25 Feb 2013 10:43:51 +0100 (CET) Message-ID: <512B3252.8000601@cisco.com> Date: Mon, 25 Feb 2013 10:43:46 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Paul Aitken References: <20130223105900.31873.39377.idtracker@ietfa.amsl.com> <512A2CA3.8060809@cisco.com> <512A4282.6050401@cisco.com> <512A4DA8.4040809@cisco.com> <512B2EAD.1060602@cisco.com> In-Reply-To: <512B2EAD.1060602@cisco.com> Content-Type: multipart/alternative; boundary="------------060706040908050801000908" Cc: "ipfix@ietf.org" , draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Subject: Re: [IPFIX] New Version Notification - draft-ietf-ipfix-flow-selection-tech-13.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, 25 Feb 2013 09:44:19 -0000 This is a multi-part message in MIME format. --------------060706040908050801000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 25/02/2013 10:28, Paul Aitken wrote: > Benoit, > >> On 24/02/2013 17:40, Paul Aitken wrote: >>> Benoit, Authors, >>> >>> Rather than defining a new "flowSelectorAlgorithm", shouldn't the >>> proposed algorithms be added to the existing selectorAlgorithm #304? >>> >>> This only requires removing "packet" from the existing definition >>> (or s/packet/packet and flow/), and allow that a Selection Process >>> can be either a packet selection process or a flow selection process. >> That would be nice, but I guess we would have to update all the PSAMP >> RFCs. In particular, http://tools.ietf.org/html/rfc5477#section-8.2.1 > > No, because we already decided that IANA's IPFIX registry is the > master repository over the IPFIX RFCs - the registry can be updated, > corrected, and extended, whereas the RFCs cannot. Master registry for the IE definitions, granted. However, IPFIX is not only composed of IPFIX IEs, but also of specifications on how to use those IEs. For example, RFC 5476, RFC 6728. So changing this definition seems very easy, but I'm concerned by the implications on the current set of RFCs. On top of that selectorAlgorithm is special because there is an IANA registry bound to it (http://tools.ietf.org/html/rfc5477#section-8.2.1) The selectorAlgorithm registry is maintained by IANA. New assignments for the registry will be administered by IANA and are subject to Expert Review [RFC5226 ]. That's one basic required change, for which a new RFC is required. Regards, Benoit > So the same must hold for the PSAMP RFCs. > > P. > --------------060706040908050801000908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 25/02/2013 10:28, Paul Aitken wrote:
Benoit,

On 24/02/2013 17:40, Paul Aitken wrote:
Benoit, Authors,

Rather than defining a new "flowSelectorAlgorithm", shouldn't the proposed algorithms be added to the existing selectorAlgorithm #304?

This only requires removing "packet" from the existing definition (or s/packet/packet and flow/), and allow that a Selection Process can be either a packet selection process or a flow selection process.
That would be nice, but I guess we would have to update all the PSAMP RFCs. In particular, http://tools.ietf.org/html/rfc5477#section-8.2.1

No, because we already decided that IANA's IPFIX registry is the master repository over the IPFIX RFCs - the registry can be updated, corrected, and extended, whereas the RFCs cannot.
Master registry for the IE definitions, granted.
However, IPFIX is not only composed of IPFIX IEs, but also of specifications on how to use those IEs. For example, RFC 5476, RFC 6728. So changing this definition seems very easy, but I'm concerned by the implications on the current set of RFCs.

On top of that selectorAlgorithm is special because there is an IANA registry bound to it (http://tools.ietf.org/html/rfc5477#section-8.2.1)
      The selectorAlgorithm registry is maintained by IANA.  New
      assignments for the registry will be administered by IANA and are
      subject to Expert Review [RFC5226].
That's one basic required change, for which a new RFC is required.

Regards, Benoit
So the same must hold for the PSAMP RFCs.

P.


--------------060706040908050801000908-- From internet-drafts@ietf.org Mon Feb 25 09:39:50 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 12A421F0D09; Mon, 25 Feb 2013 09:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EphkNo4MKoVZ; Mon, 25 Feb 2013 09:39:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FF121E8034; Mon, 25 Feb 2013 09:39:49 -0800 (PST) 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.40 Message-ID: <20130225173949.14480.85970.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 09:39:49 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mediation-protocol-04.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, 25 Feb 2013 17:39:50 -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-04.txt Pages : 28 Date : 2013-02-25 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mediation-protocol-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From n.brownlee@auckland.ac.nz Mon Feb 25 13:00:04 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 A1D9321F90B1 for ; Mon, 25 Feb 2013 13:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu0w6WE+zDQ9 for ; Mon, 25 Feb 2013 13:00:03 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id F167921F91ED for ; Mon, 25 Feb 2013 13:00:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1361826003; x=1393362003; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=H/8dAWRa0zOLVDp9AEvuvf/gguAOZm0bysi+xygXOKI=; b=FXC88L59JA4iWVqSJo7lDKH+Znmk0xrB7L+7twQEy9z0IbLIJ4u4y5GY thL9R8gGtx75kBWEPBBQ8Ib5NIoonxHHWr72MqpeyR+CI/I39qGhWSDYE rFBBRZILdZe7BOZy3seDNl4eYaKsVgm+3RMamxgLKqX/+wBDAdMKpqoEI Q=; X-IronPort-AV: E=Sophos;i="4.84,737,1355050800"; d="scan'208";a="172029470" 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; 26 Feb 2013 09:59:58 +1300 Message-ID: <512BD0CE.2000302@auckland.ac.nz> Date: Tue, 26 Feb 2013 09:59:58 +1300 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] New WG Last Call for Linbk-layer Monitoring 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: Mon, 25 Feb 2013 21:00:04 -0000 Hi all: We have a new version of this draft, draft-ietf-ipfix-data-link-layer-monitoring-02, 22 Feb 2013, thanks very much to the authors. This version has a lot of changes from the previous one, mostly in response to feedback from our IEEE Liaison, so we need a new WG Last Call. That WGLC starts now, and will end on Wednesday, 13 March (the day before the IPFIX meeting in Orlando). Do please read the draft, and send your comments (even just "it seems OK now") to the IPFIX list. 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 internet-drafts@ietf.org Mon Feb 25 15:25:37 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 8542E21F9059; Mon, 25 Feb 2013 15:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1T0NwsuqX6U; Mon, 25 Feb 2013 15:25:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E2B1F0D0A; Mon, 25 Feb 2013 15:25:35 -0800 (PST) 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.40 Message-ID: <20130225232535.11227.58789.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:25:35 -0800 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-mib-variable-export-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: Mon, 25 Feb 2013 23:25:37 -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 : Exporting MIB Variables using the IPFIX Protocol Author(s) : Benoit Claise Paul Aitken Juergen Schoenwaelder Filename : draft-ietf-ipfix-mib-variable-export-02.txt Pages : 58 Date : 2013-02-25 Abstract: This document specifies a way to complement IPFIX Flow Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. This method requires an extension to the current IPFIX protocol. New Template Set and Options Template Sets are specified to allow the export of Extended Field Specifiers, which may represent IPFIX Information Elements and Simple Network Management Protocol (SNMP) MIB Objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipfix-mib-variable-export There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipfix-mib-variable-export-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipfix-mib-variable-export-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From pthaler@broadcom.com Mon Feb 25 18:25: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 5143A21E812C for ; Mon, 25 Feb 2013 18:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.765 X-Spam-Level: X-Spam-Status: No, score=-6.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, FUZZY_VLIUM=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1YqO+nMzReS for ; Mon, 25 Feb 2013 18:25:37 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id ECD7D21E8127 for ; Mon, 25 Feb 2013 18:25:36 -0800 (PST) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 25 Feb 2013 18:23:18 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 25 Feb 2013 18:25:23 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Mon, 25 Feb 2013 18:25:22 -0800 From: "Pat Thaler" To: "Nevil Brownlee" , "IPFIX Working Group" Thread-Topic: [IPFIX] New WG Last Call for Linbk-layer Monitoring draft Thread-Index: AQHOE5sdZHlFAv0Rt065rKN0ScMh35iLVPlw Date: Tue, 26 Feb 2013 02:25:22 +0000 Message-ID: References: <512BD0CE.2000302@auckland.ac.nz> In-Reply-To: <512BD0CE.2000302@auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7D32C31C23C3387051-03-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [IPFIX] New WG Last Call for Linbk-layer Monitoring 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: Tue, 26 Feb 2013 02:25:38 -0000 Hi Nevil, Thank you for your attention to my comments. The draft is improved but stil= l could use some changes.=20 2.2 The draft links VEPA and S-channels (the "c" is lower case) - they shou= ldn't be linked - they are separate capabilities. A host system could suppo= rt or use VEPA without having S-channel capability or without having enable= d that capability. It could also use S-channels without using VEPA. IEEE 802.1Qbg specifies two kinds of Edge Relay (ER) - VEPA and VEB A VEPA is a bridge-like device on a host system that forwards all internal= traffic to the adjacent Bridge and then distributes any traffic received f= rom the adjacent EVB Bridge to the internal ports (usually VMs) A Virtual Edge Bridge (VEB) is a Bridge but since it is on a host, it is n= ot required to support learning (because it may be configured with all inte= rnal addresses and can assume that any unknown address goes to its external= port) and spanning tree (because it has only one external port and is alwa= ys at an edge of the tree). S-channels are virtual links between a host system and the EVB Bridge - thi= s allows the EVB Bridge to treat the traffic in an S-channel as if it comes= in on a separate port. For example, to apply port-based filtering rules to= the traffic. In the host, an S-channel may be attached to a VEB or a VEPA = (or directly to an internal port, but in the standard there is a rudimentar= y two-port ER there to at least enable inserting and removing C-VLAN tags).= =20 I don't recall saving compute resources being presented as a rationale when= we were making the case for including it in 802.1Qbg. The VEPA still has t= o examine the received frames to distribute them to the correct VM(s). The = VEPA advantages presented were the other ones you mention - making all the= VM to VM traffic visible to the EVB Bridge so that it can be monitored an= d so the EVB Bridge can apply filtering to it - both because the EVB Bridge= may more filtering capability and because it may be more trusted to do the= filtering.=20 One might use S-channels because one wants to use a VEB for some VMs and a = VEPA for others, to have greater separation between the traffic in the chan= nels - e.g. the EVB Bridge being able to treat the traffic as if it came in= on separate ports. The sentence: "Frame format used in S-channel is complied with S-TAG format= " is awkward and an odd use of comply. Suggest "When S-channel is in use, f= rames on the link carry an S-tag to identify the S-channel.=20 Since the S-tag is only use local to a single link to identify a virtual po= rt, it isn't clear that link monitoring needs to monitor an S-tag used for = this purpose. It could monitor the traffic based on the virtual port. Note= that the S-VID used for this case only has link local significance. Regards, Pat -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of N= evil Brownlee Sent: Monday, February 25, 2013 1:00 PM To: IPFIX Working Group Subject: [IPFIX] New WG Last Call for Linbk-layer Monitoring draft Hi all: We have a new version of this draft, draft-ietf-ipfix-data-link-layer-monitoring-02, 22 Feb 2013, thanks very much to the authors. This version has a lot of changes from the previous one, mostly in response to feedback from our IEEE Liaison, so we need a new WG Last Call. That WGLC starts now, and will end on Wednesday, 13 March (the day before the IPFIX meeting in Orlando). Do please read the draft, and send your comments (even just "it seems OK now") to the IPFIX list. Cheers, Nevil --=20 --------------------------------------------------------------------- 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From pthaler@broadcom.com Mon Feb 25 18:29: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 F370721E8147 for ; Mon, 25 Feb 2013 18:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7xG+LOdZ2Mr for ; Mon, 25 Feb 2013 18:29:20 -0800 (PST) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6D21E8127 for ; Mon, 25 Feb 2013 18:29:20 -0800 (PST) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 25 Feb 2013 18:27:02 -0800 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.9) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 25 Feb 2013 18:29:07 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS03.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Mon, 25 Feb 2013 18:29:06 -0800 From: "Pat Thaler" To: "Nevil Brownlee" , "IPFIX Working Group" Thread-Topic: [IPFIX] New WG Last Call for Linbk-layer Monitoring draft Thread-Index: AQHOE5sdZHlFAv0Rt065rKN0ScMh35iLalVA Date: Tue, 26 Feb 2013 02:29:06 +0000 Message-ID: References: <512BD0CE.2000302@auckland.ac.nz> In-Reply-To: <512BD0CE.2000302@auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7D32C2FC23C3387688-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [IPFIX] New WG Last Call for Linbk-layer Monitoring 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: Tue, 26 Feb 2013 02:29:21 -0000 In 3. The information elements TBD04 to TBD09 are not necessary for all of = IEEE 802.1Q. Only a Provider Backbone Bridge (PBB) would need these. A cus= tomer bridge knows nothing about I-Tags.=20 I think that got lost when updating the reference from the PBB amendment to= the IEEE 802.1Q revision that includes the material from the amendment. Regards, Pat -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of N= evil Brownlee Sent: Monday, February 25, 2013 1:00 PM To: IPFIX Working Group Subject: [IPFIX] New WG Last Call for Linbk-layer Monitoring draft Hi all: We have a new version of this draft, draft-ietf-ipfix-data-link-layer-monitoring-02, 22 Feb 2013, thanks very much to the authors. This version has a lot of changes from the previous one, mostly in response to feedback from our IEEE Liaison, so we need a new WG Last Call. That WGLC starts now, and will end on Wednesday, 13 March (the day before the IPFIX meeting in Orlando). Do please read the draft, and send your comments (even just "it seems OK now") to the IPFIX list. Cheers, Nevil --=20 --------------------------------------------------------------------- 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From pthaler@broadcom.com Mon Feb 25 18:29: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 33CC421E8153 for ; Mon, 25 Feb 2013 18:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.724 X-Spam-Level: X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjDCN2vz0YwJ for ; Mon, 25 Feb 2013 18:29:29 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id AD71121E8127 for ; Mon, 25 Feb 2013 18:29:29 -0800 (PST) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 25 Feb 2013 18:25:57 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.11) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Mon, 25 Feb 2013 18:27:05 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Mon, 25 Feb 2013 18:26:44 -0800 From: "Pat Thaler" To: "Nevil Brownlee" , "IPFIX Working Group" Thread-Topic: [IPFIX] New WG Last Call for Linbk-layer Monitoring draft Thread-Index: AQHOE5sdZHlFAv0Rt065rKN0ScMh35iLajFg Date: Tue, 26 Feb 2013 02:26:43 +0000 Message-ID: References: <512BD0CE.2000302@auckland.ac.nz> In-Reply-To: <512BD0CE.2000302@auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7D32C2BE3S43340735-06-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [IPFIX] New WG Last Call for Linbk-layer Monitoring 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: Tue, 26 Feb 2013 02:29:30 -0000 Hi Nevil, My comments were not a formal IEEE Liaison. They were my comments as an exp= erienced IEEE 802.1 participant. I think the authors misunderstood my point regarding IEEE 802.1BR. The E-Ta= g and its fields should not be added to the Information Elements. An E-chan= nels and E-Tags are internal to an Extended Bridge. All the traffic on the = Extended Bridge goes through the Controlling Bridge. An E-channel is a virt= ual port on the Extended Bridge and traffic can be monitored by monitoring = the virtual port. Port Extenders are not addressable from outside the Contr= olling Bridge. The Controlling Bridge has any management agents and control= s the Port Extenders including collecting any statistics they gather on the= ir ports.=20 Any flows going through an Extended Bridge flows can be fully monitored by = monitoring the same means as for any IEEE 802.1 Bridge.=20 Therefore, TBD10 and TBD11 should be removed. Regards, Pat -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of N= evil Brownlee Sent: Monday, February 25, 2013 1:00 PM To: IPFIX Working Group Subject: [IPFIX] New WG Last Call for Linbk-layer Monitoring draft Hi all: We have a new version of this draft, draft-ietf-ipfix-data-link-layer-monitoring-02, 22 Feb 2013, thanks very much to the authors. This version has a lot of changes from the previous one, mostly in response to feedback from our IEEE Liaison, so we need a new WG Last Call. That WGLC starts now, and will end on Wednesday, 13 March (the day before the IPFIX meeting in Orlando). Do please read the draft, and send your comments (even just "it seems OK now") to the IPFIX list. Cheers, Nevil --=20 --------------------------------------------------------------------- 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 _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Wed Feb 27 03:07:36 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 63EEC21F84F8 for ; Wed, 27 Feb 2013 03:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSDEvUL8vK5T for ; Wed, 27 Feb 2013 03:07:34 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id BA20921F84D9 for ; Wed, 27 Feb 2013 03:07:33 -0800 (PST) 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 r1RB7TlD022740; Wed, 27 Feb 2013 12:07:29 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1RB780L023634; Wed, 27 Feb 2013 12:07:18 +0100 (CET) Message-ID: <512DE8DC.1070902@cisco.com> Date: Wed, 27 Feb 2013 12:07:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <20130223105900.31873.39377.idtracker@ietfa.amsl.com> <512A2CA3.8060809@cisco.com> In-Reply-To: <512A2CA3.8060809@cisco.com> Content-Type: multipart/alternative; boundary="------------080409000202080202020002" Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org Subject: [IPFIX] One more feedback on XML: New Version Notification - draft-ietf-ipfix-flow-selection-tech-13.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, 27 Feb 2013 11:07:36 -0000 This is a multi-part message in MIME format. --------------080409000202080202020002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, One more feedback, and a question for the WG Based on feedback received from the OPS DIRECTORATE on RFC5102bis, the following was inserted http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-10#section-7.3 The reference to the current schema is embedded in the registry [IPFIX-IANA ]; this schema may change from time to time as necessary to support the maintenance of the registry. As such, the schema urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA ] specified in [RFC5102 ] has been deprecated. Should the IPFIX draft remove the reference to the RFC5102 xsd? Typically for this draft, it means removing the appendix A (http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-13#appendix-A) Personally, I believe it makes sense to remove it. Regards, Benoit (as a contributor) > Dear authors, > > Looking at the diff, I have the following feedback. > > flowSelectorAlgorithm is a new IE, to be registered by IANA > I see this in section 7.1: > > New assignments for the registry will be administered by > IANA and are subject to Expert Review [RFC5226 ]. > > This new registry should be in the IANA considerations section. > For an example of the IANA considerations, see > http://tools.ietf.org/html/rfc6313#section-11.3 > So the section 7.1 to 7.11 should be in the IANA considerations section. > > Also, in that registry, I see: > +----+------------------------+--------------------------+ > |TBDx| Flow-state Dependent | No agreed Parameters | > | | Intermediate Flow | | > | | Selection Process | | > +----+------------------------+--------------------------+ > This should be > +----+------------------------+--------------------------+ > | 9 | Flow-state Dependent | No agreed Parameters | > | | Intermediate Flow | | > | | Selection Process | | > +----+------------------------+--------------------------+ > On this last point, I realized that I mislead you. Mea culpa. > > I see in section 7.x > Status: Proposed > The status should be "current" > > Really, http://tools.ietf.org/html/rfc6313#section-11.3 is a good example. > > And finally, there are new fields in > http://www.iana.org/assignments/ipfix/ipfix.xml since you posted you > version. For example "revision". Instruct IANA that they need to put > the value 0. > > These comments can be taken into account part of the WGLC to come. Up > to chairs to decide. > > Regards, Benoit >> A new version (-13) has been submitted for draft-ietf-ipfix-flow-selection-tech: >> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-13.txt >> >> Sub state has been changed to AD Followup from Revised ID Needed >> >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ >> >> Diff from previous version: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-flow-selection-tech-13 >> >> IETF Secretariat. >> >> >> > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------080409000202080202020002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear authors,

One more feedback, and a question for the WG
Based on feedback received from the OPS DIRECTORATE on RFC5102bis, the following was inserted
http://tools.ietf.org/html/draft-ietf-ipfix-information-model-rfc5102bis-10#section-7.3
   The reference to the current schema is embedded in the registry
   [IPFIX-IANA]; this schema may change from time to time as necessary
   to support the maintenance of the registry. As such, the schema
   urn:ietf:params:xml:schema:ipfix-info [IPFIX-XML-SCHEMA] specified in
   [RFC5102] has been deprecated.
Should the IPFIX draft remove the reference to the RFC5102 xsd?
Typically for this draft, it means removing the appendix A (http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-13#appendix-A)
Personally, I believe it makes sense to remove it.

Regards, Benoit (as a contributor)
Dear authors,

Looking at the diff, I have the following feedback.

flowSelectorAlgorithm is a new IE, to be registered by IANA
I see this in section 7.1:
New assignments for the registry will be administered by
IANA and are subject to Expert Review [RFC5226].
This new registry should be in the IANA considerations section.
For an example of the IANA considerations, see http://tools.ietf.org/html/rfc6313#section-11.3
So the section 7.1 to 7.11 should be in the IANA considerations section.

Also, in that registry, I see:
   +----+------------------------+--------------------------+
   |TBDx| Flow-state Dependent   | No agreed Parameters     |
   |    | Intermediate Flow      |                          |
   |    | Selection Process      |                          |
   +----+------------------------+--------------------------+
This should be
   +----+------------------------+--------------------------+
   |  9 | Flow-state Dependent   | No agreed Parameters     |
   |    | Intermediate Flow      |                          |
   |    | Selection Process      |                          |
   +----+------------------------+--------------------------+
On this last point, I realized that I mislead you. Mea culpa.

I see  in section 7.x
   Status: Proposed
The status should be "current"

Really, http://tools.ietf.org/html/rfc6313#section-11.3 is a good example.

And finally, there are new fields in http://www.iana.org/assignments/ipfix/ipfix.xml since you posted you version. For example "revision". Instruct IANA that they need to put the value 0.

These comments can be taken into account part of the WGLC to come. Up to chairs to decide.

Regards, Benoit
A new version (-13) has been submitted for draft-ietf-ipfix-flow-selection-tech:
http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-13.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipfix-flow-selection-tech-13

IETF Secretariat.







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

--------------080409000202080202020002-- From Quittek@neclab.eu Wed Feb 27 04:29:41 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 7CB5F21F854D; Wed, 27 Feb 2013 04:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrQ9T3F8ATtT; Wed, 27 Feb 2013 04:29:40 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9C521F8548; Wed, 27 Feb 2013 04:29:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D15A61022BF; Wed, 27 Feb 2013 13:29:38 +0100 (CET) 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 N3ESTajtNi5R; Wed, 27 Feb 2013 13:29:38 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id AECF31022BD; Wed, 27 Feb 2013 13:29:18 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 27 Feb 2013 13:28:44 +0100 From: Juergen Quittek To: Benoit Claise , IESG Secretary , IETF IPFIX Working Group Thread-Topic: Write-up for draft-ietf-ipfix-protocol-rfc5101bis-06 Thread-Index: AQHOFOX6EGeU2WAq/024/C/ZqFT0ng== Date: Wed, 27 Feb 2013 12:28:43 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <0326F127DA54EC40813D723A4BA468B8@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ronald Bonica Subject: [IPFIX] Write-up for draft-ietf-ipfix-protocol-rfc5101bis-06 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, 27 Feb 2013 12:29:41 -0000 Dear Benoit and dear IESG Secretary, Below please find the write up for draft-ietf-ipfix-protocol-rfc5101bis-06. The draft is ready for forwarding to the IESG for publication as Internet Standard. Best regards, Juergen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Write-up for draft-ietf-ipfix-protocol-rfc5101bis-06 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Internet Standard. The header indicates: "Category: Standards Track". It is appropriate. The RFC obsoletes standards track RFC 5201. there3 are multiple experimental and commercial implementations of RFC5101. They have been tested at interop events. Errata's of RFC5101 have been solved without invalidating existing implementations. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: 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. 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: Who is the Document Shepherd? Who is the Responsible Area Director? 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. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed the draft and is fully convinced that it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document had multiple individual reviews from key WG members during WG last call. Several comments were made and have been addressed when updating the document after the reviews. The shepherd has no concern about the depth or breadth of the reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no such issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. =20 (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR disclosure filed. It is known by the WG and has been discussed. It is not different from the IPR disclosures that had already been filed for RFC 5101. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG as a whole understands and agrees with it. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet- Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a few nits. - The reference to draft-claise-ipfix- information-model-rfc5102bis-01 is outdated and has a wrong author list.=20 - The reference to draft-ietf-ipfix-mediation-protocol-03 is outdated. These can be fixed in an update after IETF last call. =20 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No further formal review required except for a thorough review by IANA which will be conducted anyway. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? Yes, there is a references to draft-ietf-ipfix-information-model- rfc5101bis which is already in the RFC editor queue. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. RFC 5101 will be obsoleted by this document. This is explicitly mentioned in the abstract and introduction. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Most tet in the IANA considerations section repeats what has already been stated in RFC5101. The only new action for IANA is replacing references in IANA registries to RFC5101 with references to this document. =20 (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no new IANA registries requested by this document. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None to be done. From bclaise@cisco.com Wed Feb 27 05:08: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 692B021F8528; Wed, 27 Feb 2013 05:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJIBDfbF0AZX; Wed, 27 Feb 2013 05:08:47 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB2621F8459; Wed, 27 Feb 2013 05:08:46 -0800 (PST) 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 r1RD8jBL006775; Wed, 27 Feb 2013 14:08:45 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1RD89Oj015152; Wed, 27 Feb 2013 14:08:24 +0100 (CET) Message-ID: <512E0539.1020008@cisco.com> Date: Wed, 27 Feb 2013 14:08:09 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ronald Bonica , IESG Secretary , IETF IPFIX Working Group Subject: Re: [IPFIX] Write-up for draft-ietf-ipfix-protocol-rfc5101bis-06 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, 27 Feb 2013 13:08:48 -0000 Hi Juergen, Secretariat, Thanks for this. See inline for two small corrections. Secretariat, can you please use those corrections when posting the write-up. > Dear Benoit and dear IESG Secretary, > > Below please find the write up for > draft-ietf-ipfix-protocol-rfc5101bis-06. > The draft is ready for forwarding to the IESG > for publication as Internet Standard. > > Best regards, > Juergen > > > ==================================================== > Write-up for draft-ietf-ipfix-protocol-rfc5101bis-06 > ==================================================== > > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? > Why is this the proper type of RFC? Is this type of RFC indicated > in the title page header? > > Internet Standard. The header indicates: "Category: Standards Track". > It is appropriate. The RFC obsoletes standards track RFC 5201. OLD: RFC 5201 NEW: RFC 5101 > there3 are multiple experimental and commercial implementations > of RFC5101. They have been tested at interop events. Errata's > of RFC5101 have been solved without invalidating existing > implementations. > > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. > Recent examples can be found in the "Action" announcements for > approved documents. The approval announcement contains the following > sections: > > Technical Summary: > > 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. > > > 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: > > Who is the Document Shepherd? Who is the Responsible Area Director? > > 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. > > (3) Briefly describe the review of this document that was performed > by the Document Shepherd. If this version of the document is not > ready for publication, please explain why the document is being > forwarded to the IESG. > > The document shepherd has reviewed the draft and is fully convinced > that it is ready for publication. > > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? > > The document had multiple individual reviews from key WG members > during WG last call. Several comments were made and have been > addressed when updating the document after the reviews. The > shepherd has no concern about the depth or breadth of the reviews. > > (5) Do portions of the document need review from a particular or > from broader perspective, e.g., security, operational complexity, > AAA, DNS, DHCP, XML, or internationalization? If so, describe the > review that took place. > > No. > > (6) Describe any specific concerns or issues that the Document > Shepherd has with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he or she > is uncomfortable with certain parts of the document, or has concerns > whether there really is a need for it. In any event, if the WG has > discussed those issues and has indicated that it still wishes to > advance the document, detail those concerns here. > > There are no such issues. > > (7) Has each author confirmed that any and all appropriate IPR > disclosures required for full conformance with the provisions of > BCP 78 and BCP 79 have already been filed. If not, explain why? > > Yes. > > (8) Has an IPR disclosure been filed that references this > document? If so, summarize any WG discussion and conclusion > regarding the IPR disclosures. > > There is one IPR disclosure filed. It is known by the WG > and has been discussed. It is not different from the IPR > disclosures that had already been filed for RFC 5101. > > (9) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with others > being silent, or does the WG as a whole understand and agree with > it? > > The WG as a whole understands and agrees with it. > > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It should > be in a separate email because this questionnaire is publicly > available.) > > No. > > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the Internet- > Drafts Checklist). Boilerplate checks are not enough; this check > needs to be thorough. > > There are a few nits. > - The reference to draft-claise-ipfix- > information-model-rfc5102bis-01 is outdated and has a wrong > author list. > - The reference to draft-ietf-ipfix-mediation-protocol-03 > is outdated. > These can be fixed in an update after IETF last call. > > (12) Describe how the document meets any required formal review > criteria, such as the MIB Doctor, media type, and URI type reviews. > > No further formal review required except for a thorough review > by IANA which will be conducted anyway. > > (13) Have all references within this document been identified as > either normative or informative? > > Yes. > > (14) Are there normative references to documents that are not ready > for advancement or are otherwise in an unclear state? If such > normative references exist, what is the plan for their completion? > > Yes, there is a references to draft-ietf-ipfix-information-model- > rfc5101bis which is already in the RFC editor queue. OLD: draft-ietf-ipfix-information-model- rfc5101bis NEW: draft-ietf-ipfix-information-model-rfc5102bis Regards, Benoit > > (15) Are there downward normative references references (see RFC > 3967)? If so, list these downward references to support the Area > Director in the Last Call procedure. > > No. > > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, > listed in the abstract, and discussed in the introduction? If the > RFCs are not listed in the Abstract and Introduction, explain why, > and point to the part of the document where the relationship of this > document to the other RFCs is discussed. If this information is not > in the document, explain why the WG considers it unnecessary. > > RFC 5101 will be obsoleted by this document. This is explicitly > mentioned in the abstract and introduction. > > (17) Describe the Document Shepherd's review of the IANA > considerations section, especially with regard to its consistency > with the body of the document. Confirm that all protocol extensions > that the document makes are associated with the appropriate > reservations in IANA registries. Confirm that any referenced IANA > registries have been clearly identified. Confirm that newly created > IANA registries include a detailed specification of the initial > contents for the registry, that allocations procedures for future > registrations are defined, and a reasonable name for the new registry > has been suggested (see RFC 5226). > > Most tet in the IANA considerations section repeats what has > already been stated in RFC5101. The only new action for IANA > is replacing references in IANA registries to RFC5101 with > references to this document. > > (18) List any new IANA registries that require Expert Review for > future allocations. Provide any public guidance that the IESG would > find useful in selecting the IANA Experts for these new registries. > > There are no new IANA registries requested by this document. > > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal > language, such as XML code, BNF rules, MIB definitions, etc. > > None to be done. > > > >