From Quittek@neclab.eu Fri Jul 1 00:43:24 2011 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 E711A21F8833 for ; Fri, 1 Jul 2011 00:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 62cKz8adAFDR for ; Fri, 1 Jul 2011 00:43:24 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id EE20721F882B for ; Fri, 1 Jul 2011 00:43:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 03A4828000231 for ; Fri, 1 Jul 2011 09:43:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWmfO0jAtf7w for ; Fri, 1 Jul 2011 09:43:22 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.netlab.nec.de (Postfix) with ESMTP id C108828000226 for ; Fri, 1 Jul 2011 09:43:17 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.5]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0270.001; Fri, 1 Jul 2011 09:43:18 +0200 From: Juergen Quittek To: IETF IPFIX Working Group Thread-Topic: [IPFIX] RFC5815 (IPFIX MIB) IANA Consideration issues Thread-Index: Acw2UTDP4s1AG749R2qYS+FDccCBuABcVcUV Date: Fri, 1 Jul 2011 07:43:16 +0000 Message-ID: In-Reply-To: <75581E268A48F849916117B977D76D372CC427D7@Polydeuces.office.hd> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.10.0.110428 x-originating-ip: [10.1.2.219] Content-Type: text/plain; charset="us-ascii" Content-ID: <64033F34472B6B4AA6D8B18C327A8959@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPFIX] RFC5815 (IPFIX MIB) IANA Consideration issues 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 Jul 2011 07:43:25 -0000 Dear all, I support Thomas' request. Currently, we have a registry at IANA at http://www.iana.org/assignments/ianaipfixselector-mib As you can see if you click the link, there the entire MIB module is maintained by IANA. This implies that if we want to add a new selector function, then the MIB module will be modified and implementers need replac= e older versions. This is not what was really intended by the authors of the RFC 5815 (IPFIX MIB). The die was rather having IANA maintain a a registry for just NUMBERS of selector functions that would be appended to OID ipfixSelectorFunctions, as it is commonly done for smi-numbers at http://www.iana.org/assignments/smi-numbers So the IANA action that we need is - remove the registry of the IPFIX-SELECTOR-MIB - instead create a new entry at the smi-numbers registry for the prefix ipfixSelectorFunctions There we would then add the selector functions defined in the PSAMP-MIB and potential further MIB modules. Please send your comments if you have questions or disagree with this proposal. Note that if we do so, we would need to run IETF last call for th= e PSAMP-MIB again, because this is a significant change to the document. My proposal would be to discuss it on the mailing list now and have a final discussion at the IPFIX session in Quebec. Thanks,=20 Juergen Am 29.06.11 13:58 schrieb "Thomas Dietz" unter : > Dear all, >=20 > in the course of editing the PSAMP MIB draft we identified that the IANA > Considerations in RFC 5815 (the IPFIX MIB RFC) do not make sense. Putting > the whole IPFIX SELECTOR MIB under IANA control and creating a registry > hereof is not what we need here. >=20 > I propose to change that and only put up a registry that registers the OI= Ds > of the subtrees under the ipfixSelectorFunctions OID. Each subtree -- as > described in the RFC -- represents a Selector Function and its parameters > (in a table). So the root of the subtree (i.e. its OID) has to be registe= red > in the new registry. In addition the document where this subtree is defin= ed > has to be registered. The review process setup in RFC5815 can remain as i= t > is. >=20 > Implementing this change needs -- according to our ADs -- an updated > RFC5815. >=20 > Please comment on this issue. Any feedback is welcome. >=20 > Best Regards, >=20 > Thomas From bclaise@cisco.com Fri Jul 1 01:56:48 2011 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 92DDD21F8892 for ; Fri, 1 Jul 2011 01:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] 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 07XRtAazFYJN for ; Fri, 1 Jul 2011 01:56:47 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECF721F888F for ; Fri, 1 Jul 2011 01:56:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p618uk9j023306; Fri, 1 Jul 2011 10:56:46 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p618ujS3018763; Fri, 1 Jul 2011 10:56:46 +0200 (CEST) Message-ID: <4E0D8BCD.1010702@cisco.com> Date: Fri, 01 Jul 2011 10:56:45 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 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: IETF IPFIX Working Group Subject: Re: [IPFIX] RFC5815 (IPFIX MIB) IANA Consideration issues 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 Jul 2011 08:56:48 -0000 Hi Juergen, I support the proposal. Regards, Benoit. > Dear all, > > I support Thomas' request. > > Currently, we have a registry at IANA at > http://www.iana.org/assignments/ianaipfixselector-mib > > As you can see if you click the link, there the entire MIB module is > maintained by IANA. This implies that if we want to add a new selector > function, then the MIB module will be modified and implementers need replace > older versions. > > This is not what was really intended by the authors of the RFC 5815 (IPFIX > MIB). The die was rather having IANA maintain a a registry for just NUMBERS > of selector functions that would be appended to OID ipfixSelectorFunctions, > as it is commonly done for smi-numbers at > http://www.iana.org/assignments/smi-numbers > > So the IANA action that we need is > > - remove the registry of the IPFIX-SELECTOR-MIB > - instead create a new entry at the smi-numbers registry > for the prefix ipfixSelectorFunctions > > There we would then add the selector functions defined in the PSAMP-MIB and > potential further MIB modules. > > Please send your comments if you have questions or disagree with this > proposal. Note that if we do so, we would need to run IETF last call for the > PSAMP-MIB again, because this is a significant change to the document. > My proposal would be to discuss it on the mailing list now and have a final > discussion at the IPFIX session in Quebec. > > Thanks, > > Juergen > > > > > Am 29.06.11 13:58 schrieb "Thomas Dietz" unter: > >> Dear all, >> >> in the course of editing the PSAMP MIB draft we identified that the IANA >> Considerations in RFC 5815 (the IPFIX MIB RFC) do not make sense. Putting >> the whole IPFIX SELECTOR MIB under IANA control and creating a registry >> hereof is not what we need here. >> >> I propose to change that and only put up a registry that registers the OIDs >> of the subtrees under the ipfixSelectorFunctions OID. Each subtree -- as >> described in the RFC -- represents a Selector Function and its parameters >> (in a table). So the root of the subtree (i.e. its OID) has to be registered >> in the new registry. In addition the document where this subtree is defined >> has to be registered. The review process setup in RFC5815 can remain as it >> is. >> >> Implementing this change needs -- according to our ADs -- an updated >> RFC5815. >> >> Please comment on this issue. Any feedback is welcome. >> >> Best Regards, >> >> Thomas > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From wwwrun@rfc-editor.org Sun Jul 3 12:27:46 2011 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 BFF0421F85DD for ; Sun, 3 Jul 2011 12:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.271 X-Spam-Level: X-Spam-Status: No, score=-102.271 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 dT4JHQXoMOWC for ; Sun, 3 Jul 2011 12:27:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 589FA21F85C3 for ; Sun, 3 Jul 2011 12:27:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A7E6498C4E8; Sun, 3 Jul 2011 12:27:45 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110703192745.A7E6498C4E8@rfc-editor.org> Date: Sun, 3 Jul 2011 12:27:45 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2852) 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, 03 Jul 2011 19:27:46 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2852 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: Figure O Original Text ------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope N Field Length | Scope N Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Field Length | Option 1 Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Option 1 Enterprise Number | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Corrected Text -------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope N Field Length | Scope N Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Scope N Enterprise Number |1| Option 1 Infor. Element Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option 1 Field Length | Option 1 Enterprise Number ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Option 1 Enterprise Number | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Notes ----- Notice that the rows don't line up properly. I think this is because the ellipsis were supposed to overlap the edges. Compare with the diagram in A.4.3. Perhaps the ellipsis in the figure in section A.4.2 could also be modified for consistency. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From bclaise@cisco.com Mon Jul 4 09:11:32 2011 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 2F50421F870D for ; Mon, 4 Jul 2011 09:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] 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 LPfGc2eTmrE1 for ; Mon, 4 Jul 2011 09:11:30 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C8F2121F8708 for ; Mon, 4 Jul 2011 09:11:23 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p64G7YY5029387; Mon, 4 Jul 2011 18:07:34 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p64G7Xu6018077; Mon, 4 Jul 2011 18:07:33 +0200 (CEST) Message-ID: <4E11E545.9030202@cisco.com> Date: Mon, 04 Jul 2011 18:07:33 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Zseby, Tanja" , "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] WG: I-D Action: draft-ietf-ipfix-flow-selection-tech-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, 04 Jul 2011 16:11:32 -0000 Dear draft-ietf-ipfix-flow-selection-tech-06 authors, Some of your IE defintions contain "Units: Flow Entries". I wonder why? RFC 5102 speaks of "Units: flow" Regards, Benoit From n.brownlee@auckland.ac.nz Mon Jul 4 18:38:29 2011 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 D2B2B21F872D for ; Mon, 4 Jul 2011 18:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 TaMuWQQyBrDS for ; Mon, 4 Jul 2011 18:38:29 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id AD7E921F8727 for ; Mon, 4 Jul 2011 18:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1309829908; x=1341365908; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4E126B08.1010506@auckland.ac.nz>|Date:=20 Tue,=2005=20Jul=202011=2013:38:16=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20DRAFT=20agenda=20-00=20for=20IPFIX=20at=20IET F=2081=20(Quebec=20City)|Content-Transfer-Encoding:=207bi t; bh=AnuJp/ZMkGHwefqYOxEv6k2ZiZ0eQNZMe15Ir5z8x1Q=; b=PJF5qj5BuVhIFIoFbH6/B7AFJO5X1S1IJ96M29ZKjnqu6dQbTIsjq+5r qabbsPCwHgZFiMCKZxzka5mudLFTLOZhai/0mupcxtl/w7OptcIq1rQB1 c3p1STdp/kHFnNkriRa3gG3zENkpMsl2JnrVD32PW+JKbYoFevjASU+Z6 4=; X-IronPort-AV: E=Sophos;i="4.65,476,1304251200"; d="scan'208";a="70269194" 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; 05 Jul 2011 13:38:17 +1200 Message-ID: <4E126B08.1010506@auckland.ac.nz> Date: Tue, 05 Jul 2011 13:38:16 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] DRAFT agenda -00 for IPFIX at IETF 81 (Quebec City) 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, 05 Jul 2011 01:38:29 -0000 Hi all: Here's a -00 version of our agenda for Quebec City. Where I'm not sure who would present something I've indicated that using (?). Our main goal for this meeting, I believe, is to decide how many of the drafts listed we should take up as WG items, and to write down answers to the questions: - Who is prepared to _work_ on them? - How long do we expect them to take? Comments, suggestions for improvements, etc are welcome, please email them to the IPFIX list. Cheers, Nevil =========================================== IP Flow Information Export WG (ipfix) DRAFT-00 Agenda for IETF 81, Quebec City Wedesday, July 27, 1300-1500, Room 2101 =========================================== Chairs: Juergen Quittek Nevil Brownlee AGENDA: 1. Agenda review = 5 min 2. Update from last meeting / WG Status (Nevil) = 10 min Export-per-SCTP-Stream - in queue, waiting on sctp stream-reset Structured Data - in RFC-EDIT state Config Model - IESG waiting for revised ID PSAMP MIB - IESG waiting for revised ID Flow Selection Techniques -06 published, needs revised ID, then nevil will submit writeup 3. Current WG drafts = 0 min All in (2) above. 4. What next for IPFIX? = 5 min We're now ready to consider how IPFIX should develop. This section of the agenda is intended as (the continuation of) our re-chartering discussion. For any of these we need to work out - Who is prepared to _work_ on them? - How long do we expect them to take? a) Progressing IPFIX Standards-Track RFCs to Draft Standard = 20 min (Juergen/Nevil) - New versions of the base standards, 5101 and 5102, which implement small changes that did not affect interoperation, (for example adding detail where there are gaps in 5101) as a Standards Track successor to 5101. Once that had been published as an RFC for some time we could work on moving it to Draft; that should be possible in a reasonably short time. - draft-mentz-ipfix-dtls-recommendations-02 Recommendations for Implementing IPFIX over DTLS, 14 Mar 11 Where should these go - update of Implementation Guidelines perhaps? b) Recent drafts = 70 min - draft-trammell-ipfix-ie-doctors-02 (Brian Trammell) Guidelines for Information Elements, 24 Jun 11 We need to decide a. Should we develop an 'IE Guidelines' draft? or, b. Do we want to have an 'IE Doctors' team (with IESG overview), an expanded group of IE Expert reviewers, or what? - draft-trammel-ipfix-a9n-03 (Brian Trammell) IPFIX Aggregation, 28 Jun 11 A much-needed mediator function - draft-kashima-ipfix-data-link-layer-monitoring-05 (?) Information Elements for Data Link Layer Traffic Measurement, 15 Mar 11 - draft-claise-ipfix-mediation-protocol-03 (Benoit CLaise) Protocol for PFIX Mediation, 14 Feb 11 - draft-johnson-ipfix-mib-variable-export-01 (?) Exporting MIB objects, 7 Apr 11 5. Any Other Business = 10 min Presentation slides will be available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=81 (search for IPFIX in the Operations and Management Area) Participation via jabber is offered at ipfix@jabber.ietf.org -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From bclaise@cisco.com Wed Jul 6 00:35:59 2011 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 EE36821F8599 for ; Wed, 6 Jul 2011 00:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, 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 Yv8KDMpB4PlL for ; Wed, 6 Jul 2011 00:35:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 36D2921F8523 for ; Wed, 6 Jul 2011 00:35:59 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p667ZuBE028661 for ; Wed, 6 Jul 2011 09:35:57 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p667ZtfT024876 for ; Wed, 6 Jul 2011 09:35:56 +0200 (CEST) Message-ID: <4E14105B.4080101@cisco.com> Date: Wed, 06 Jul 2011 09:35:55 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: multipart/alternative; boundary="------------030508070006040903000107" Subject: [IPFIX] New Version Notification for draft-claise-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: Wed, 06 Jul 2011 07:36:00 -0000 This is a multi-part message in MIME format. --------------030508070006040903000107 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, A new version of the IPFIX Mediation Protocol has been posted. The biggest change is the addition of the protocol information in the examples related to the Transport Session Information. Indeed, the Transport Session is not only composed of IP addresses, and port, but also the protocol. All open issues have been resolved. This draft would now benefit from reviews from the community. Regards, Benoit. -------- Original Message -------- Subject: New Version Notification for draft-claise-ipfix-mediation-protocol-04.txt Date: Wed, 06 Jul 2011 00:31:25 -0700 From: internet-drafts@ietf.org To: bclaise@cisco.com CC: bclaise@cisco.com, akoba@nttv6.net, trammell@tik.ee.ethz.ch A new version of I-D, draft-claise-ipfix-mediation-protocol-04.txt has been successfully submitted by Benoit Claise and posted to the IETF repository. Filename: draft-claise-ipfix-mediation-protocol Revision: 04 Title: Specification of the Protocol for IPFIX Mediations Creation date: 2011-07-07 WG ID: Individual Submission Number of pages: 31 Abstract: This document specifies the IP Flow Information Export (IPFIX) protocol specific to the Mediation. The IETF Secretariat --------------030508070006040903000107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear all,

A new version of the IPFIX Mediation Protocol has been posted.
The biggest change is the addition of the protocol information in the examples related to the Transport Session Information.
Indeed, the Transport Session is not only composed of IP addresses, and port, but also the protocol.

All open issues have been resolved.
This draft would now benefit from reviews from the community.

Regards, Benoit.


-------- Original Message --------
Subject: New Version Notification for draft-claise-ipfix-mediation-protocol-04.txt
Date: Wed, 06 Jul 2011 00:31:25 -0700
From: internet-drafts@ietf.org
To: bclaise@cisco.com
CC: bclaise@cisco.com, akoba@nttv6.net, trammell@tik.ee.ethz.ch 


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

Filename:	 draft-claise-ipfix-mediation-protocol
Revision:	 04
Title:		 Specification of the Protocol for IPFIX Mediations
Creation date:	 2011-07-07
WG ID:		 Individual Submission
Number of pages: 31

Abstract:
        This document specifies the IP Flow Information Export
        (IPFIX) protocol specific to the Mediation.

                                                                                  


The IETF Secretariat
--------------030508070006040903000107-- From muenz@net.in.tum.de Wed Jul 6 15:25:09 2011 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 06E8121F8AF2 for ; Wed, 6 Jul 2011 15:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RslugNjM9CZA for ; Wed, 6 Jul 2011 15:25:08 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5F44621F8AEB for ; Wed, 6 Jul 2011 15:25:08 -0700 (PDT) Received: from [131.159.20.248] (vpn-4.net.in.tum.de [131.159.20.248]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 10FAA2088DD5; Thu, 7 Jul 2011 00:28:00 +0200 (CEST) Message-ID: <4E14E0B4.8000509@net.in.tum.de> Date: Thu, 07 Jul 2011 00:24:52 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPFIX Working Group Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 22:25:09 -0000 Dan, Please find my replies inline. On 01.06.2011 17:39, Romascanu, Dan (Dan) wrote: > Hi, > > I performed the AD review of > draft-ietf-ipfix-configuration-model-09.txt. This document is in good > shape and I am sending it to IETF Last Call. Please consider the > comments below together with the other IETF Last Call comments. > > Technical Comments are marked T and Editorial comments are marked R. > > T1. Section 4.2.2 - how is probability expressed - as a value between 0 > and 1? I have added the following sentence: "The probability is expressed as a value between 0 and 1." > T2. Section 4.7: > > If SCTP is transport protocol, Exporter or > Collector may be multi-homed SCTP endpoints (see [RFC4960], Section > 6.4) and use more than one IP address. > > A capitalized 2119 MAY seems to be appropriate here. Changed. > E1. In Section 4.1: > > However, indexes SHOULD only be used as identifiers if > an SNMP agent on the same Monitoring Device enables access to the > corresponding MIB objects. > > s/indexes/indices/ > s/MIB objects/MIB tables/ > > Similarly > > ifIndex SHOULD only be used if an SNMP agent enables > access to the corresponding MIB object in the ifTable. > Similarly, a physical entity is either identified by its name > (entPhysicalName) or the entPhysicalIndex value of the > corresponding object in the ENTITY-MIB module [RFC4133]. > entPhysicalIndex SHOULD only be used if an SNMP agent enables > access to the corresponding MIB object in the entPhysicalTable. > > Indices are by definition not-accessible, but accessing the tables that > they index should be sufficient as the index can be extracted from the > OIDs of the objects in the table. Changed as follows: "ifIndex SHOULD only be used if an SNMP agent enables access to the ifTable. Similarly, a physical entity is either identified by its name (entPhysicalName) or the entPhysicalIndex value of the corresponding object in the ENTITY-MIB module [RFC4133]. entPhysicalIndex SHOULD only be used if an SNMP agent enables access to the entPhysicalTable." I hope that this is what you suggested. > E2. In section 4.3 > > > cacheDiscontinuityTime: Timestamp of the most recent occasion at > which dataRecords suffered a discontinuity. In contrast to > ipfixMeteringProcessDiscontinuityTime, the time is absolute and > not relative to sysUpTime. > Note that this parameter corresponds to > ipfixMeteringProcessDiscontinuityTime in the IPFIX MIB module > [RFC5815]. > > Better say 'functionally corresponds' ... Changed. I also adopted this wording in the YANG descriptions. Thanks, Gerhard > Thanks and Regards, > > Dan > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From dromasca@avaya.com Thu Jul 7 02:59:34 2011 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 02EBD21F87CA for ; Thu, 7 Jul 2011 02:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.033 X-Spam-Level: X-Spam-Status: No, score=-103.033 tagged_above=-999 required=5 tests=[AWL=0.566, 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 Lsk1XpX-+a3k for ; Thu, 7 Jul 2011 02:59:33 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D185521F87B2 for ; Thu, 7 Jul 2011 02:59:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBAKeCFU6HCzI1/2dsb2JhbABTmGWPNHexHAKbGIY4BJdhiyg X-IronPort-AV: E=Sophos;i="4.65,492,1304308800"; d="scan'208";a="255300558" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jul 2011 05:59:30 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Jul 2011 05:52:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 11:59:26 +0200 Message-ID: In-Reply-To: <4E14E0B4.8000509@net.in.tum.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-configuration-model-09.txt Thread-Index: Acw8K5ItQPFR9sUETp6A/b1fj+hQUAAYJbaA References: <4E14E0B4.8000509@net.in.tum.de> From: "Romascanu, Dan (Dan)" To: "Gerhard Muenz" Cc: IPFIX Working Group Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 09:59:34 -0000 Hi Gerhard,=20 Thank you for the answers and for addressing my comments. The proposed changes are fine.=20 Can you issue the revised I-D before the submission deadline on Monday, so that I can place the document on the agenda of the 7/14 IESG telechat?=20 Regards, Dan=20 > -----Original Message----- > From: Gerhard Muenz [mailto:muenz@net.in.tum.de] > Sent: Thursday, July 07, 2011 1:25 AM > To: Romascanu, Dan (Dan) > Cc: IPFIX Working Group > Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-configuration-model- > 09.txt >=20 >=20 > Dan, >=20 > Please find my replies inline. >=20 > On 01.06.2011 17:39, Romascanu, Dan (Dan) wrote: > > Hi, > > > > I performed the AD review of > > draft-ietf-ipfix-configuration-model-09.txt. This document is in good > > shape and I am sending it to IETF Last Call. Please consider the > > comments below together with the other IETF Last Call comments. > > > > Technical Comments are marked T and Editorial comments are marked R. > > > > T1. Section 4.2.2 - how is probability expressed - as a value between > 0 > > and 1? >=20 > I have added the following sentence: > "The probability is expressed as a value between 0 and 1." >=20 > > T2. Section 4.7: > > > > If SCTP is transport protocol, Exporter or > > Collector may be multi-homed SCTP endpoints (see [RFC4960], > Section > > 6.4) and use more than one IP address. > > > > A capitalized 2119 MAY seems to be appropriate here. >=20 > Changed. >=20 > > E1. In Section 4.1: > > > > However, indexes SHOULD only be used as identifiers if > > an SNMP agent on the same Monitoring Device enables access to the > > corresponding MIB objects. > > > > s/indexes/indices/ > > s/MIB objects/MIB tables/ > > > > Similarly > > > > ifIndex SHOULD only be used if an SNMP agent enables > > access to the corresponding MIB object in the ifTable. > > Similarly, a physical entity is either identified by its name > > (entPhysicalName) or the entPhysicalIndex value of the > > corresponding object in the ENTITY-MIB module [RFC4133]. > > entPhysicalIndex SHOULD only be used if an SNMP agent enables > > access to the corresponding MIB object in the > entPhysicalTable. > > > > Indices are by definition not-accessible, but accessing the tables > that > > they index should be sufficient as the index can be extracted from > the > > OIDs of the objects in the table. >=20 > Changed as follows: >=20 > "ifIndex SHOULD only be used if an SNMP agent enables > access to the ifTable. > Similarly, a physical entity is either identified by its name > (entPhysicalName) or the entPhysicalIndex value of the > corresponding object in the ENTITY-MIB module [RFC4133]. > entPhysicalIndex SHOULD only be used if an SNMP agent enables > access to the entPhysicalTable." >=20 > I hope that this is what you suggested. >=20 > > E2. In section 4.3 > > > > > > cacheDiscontinuityTime: Timestamp of the most recent occasion at > > which dataRecords suffered a discontinuity. In contrast to > > ipfixMeteringProcessDiscontinuityTime, the time is absolute > and > > not relative to sysUpTime. > > Note that this parameter corresponds to > > ipfixMeteringProcessDiscontinuityTime in the IPFIX MIB module > > [RFC5815]. > > > > Better say 'functionally corresponds' ... >=20 > Changed. I also adopted this wording in the YANG descriptions. >=20 > Thanks, > Gerhard >=20 > > Thanks and Regards, > > > > Dan > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Thu Jul 7 03:33:07 2011 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 55BE921F85C1 for ; Thu, 7 Jul 2011 03:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] 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 0bT2p3fY7JpP for ; Thu, 7 Jul 2011 03:33:06 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC3D21F85BB for ; Thu, 7 Jul 2011 03:33:06 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67ATK01009071; Thu, 7 Jul 2011 12:29:20 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67ATFao013879; Thu, 7 Jul 2011 12:29:15 +0200 (CEST) Message-ID: <4E158A7B.2030809@cisco.com> Date: Thu, 07 Jul 2011 12:29:15 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipfix@ietf.org References: <20110630093904.GB3317@elstar.local> In-Reply-To: <20110630093904.GB3317@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] ipfix mib export and context information X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 10:33:07 -0000 Dear all, Let me ask the question differently. Do you see a use case for the export, within a single flow record, of MIB variables from different SNMP contexts? Regards, Benoit. > Hi, > > as explained in section 3.3 of RFC 3411, MIB objects (identified by an > OID) always exist in a context. A context is identified by a > contextEngineID and a contextName. In colloquial terms, the > contextEngineID identifies an SNMP agent and a contextName identifies > an OID tree accessible on that agent. In short, within a management > domain, a unique name of a MIB object is the following 4-tuple: > > (contextEngineID, contextName, object-type OID, instance-identifier) > | | | | > +-----------+------------+ +--------------+-----------------+ > | | > context OID > > Many agents only have one context (the so called default context) and > hence this is mostly invisible for many people. However, in certain > situations, contexts are used. The classic example are bridges that > have an instance of the BRIDGE-MIB for each VLAN (in this case the > contextName used to distinguish BRIDGE-MIB instances is usually the > VLAN name). > > For exporting MIB objects in IPFIX, we need to deal with the > representation of contexts: > > a) If a MIB object exists in the default context (zero length > contextName), then the contextName is not carried in IPFIX. > > b) If a MIB object exists in a non-default context, then the > contextName needs to be carried in IPFIX. There are again two > options: > > b.1) The contextName is associated to the template. This means all MIB > objects in an IPFIX flow record must belong to the same SNMP > context. Continuing the example mentioned above, you would not be > able to have flow record that carries a MIB object for multiple > VLANs. (Note that a similar restriction exists in SNMP since a > PDU is always scoped to one context.) The trade-off here is that > flow records are smaller at the expense of having to deal with > more template options in cases where many contexts are used. > > b.2) The contextName is associated to a MIB object in a flow record. > This allows to have objects existing in different SNMP contexts > on the same "agent" to be carried in a single flow record. > However, there is a price for this flexibility since context > information is now repeated in every flow record. > > Independent of the options a), b.1), and b.2) above, there is a > question whether the contextEngineID should be carried somewhere? This > would disambiguate things if a device has multiple SNMP agents running > concurrently. If the contextEngineID is carried, then this should > likely be part of the template information, not the flow records. > > So the main question at this point (sorry for the lengthy > explanation): Should we go for b.1) or b.2) or even allow both b.1) > and b.2)? > > /js > From j.schoenwaelder@jacobs-university.de Thu Jul 7 04:01:06 2011 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 AE6FD21F8647 for ; Thu, 7 Jul 2011 04:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.197 X-Spam-Level: X-Spam-Status: No, score=-102.197 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 e75UdqiJ6y2v for ; Thu, 7 Jul 2011 04:01:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CCA5821F84F5 for ; Thu, 7 Jul 2011 04:01:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CC7620BDF; Thu, 7 Jul 2011 13:01:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Kup1pLGv0ber; Thu, 7 Jul 2011 13:01:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA7D320BDD; Thu, 7 Jul 2011 13:01:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6CD23199CCF7; Thu, 7 Jul 2011 13:01:02 +0200 (CEST) Date: Thu, 7 Jul 2011 13:01:02 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20110707110102.GB8896@elstar.local> Mail-Followup-To: Benoit Claise , ipfix@ietf.org References: <20110630093904.GB3317@elstar.local> <4E158A7B.2030809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E158A7B.2030809@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipfix@ietf.org Subject: Re: [IPFIX] ipfix mib export and context information X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 11:01:06 -0000 On Thu, Jul 07, 2011 at 12:29:15PM +0200, Benoit Claise wrote: > Dear all, > > Let me ask the question differently. > Do you see a use case for the export, within a single flow record, > of MIB variables from different SNMP contexts? Depends on the definition of "flow". As long as we keep the definition found in RFC 3917 section 2.1, the likelihood of exporting MIB variables from different SNMP context for a single flow record is likely diminishing small. That said, I think the main use case for MIB variable export via IPFIX seems to be related to a much more liberal definition of a "flow", that is, one uses IPFIX to simply stream MIB variables towards a collector instead of polling them, likely independent of any traffic flows. In such a scenario, the likelihood to want different SNMP contexts in a single flow record might increase, but it might still be acceptable to have a limitation that a single flow record can only carry data from a single context (since SNMP has kind of the same restriction - a PDU is always bound to a specific context). So I guess my answer is "no", I do not see a strong use case for having data from different contexts in a single flow record (but different flow records should be able to carry data from different SNMP contexts). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Jul 7 04:42:59 2011 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 21DAD21F8812 for ; Thu, 7 Jul 2011 04:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.069 X-Spam-Level: X-Spam-Status: No, score=-103.069 tagged_above=-999 required=5 tests=[AWL=0.530, 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 SKqRuSY-8nRX for ; Thu, 7 Jul 2011 04:42:58 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9F221F8795 for ; Thu, 7 Jul 2011 04:42:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBACebFU7GmAcF/2dsb2JhbABNBphljzV3sTgCmxUCgzqCfASXYYso X-IronPort-AV: E=Sophos;i="4.65,493,1304308800"; d="scan'208";a="255318530" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jul 2011 07:42:56 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jul 2011 07:41:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 7 Jul 2011 13:42:54 +0200 Message-ID: In-Reply-To: <20110707110102.GB8896@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] ipfix mib export and context information Thread-Index: Acw8lTeyr8GAaNNZRw2Z+e2C39v+YAABX5xA References: <20110630093904.GB3317@elstar.local> <4E158A7B.2030809@cisco.com> <20110707110102.GB8896@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Benoit Claise" Cc: ipfix@ietf.org Subject: Re: [IPFIX] ipfix mib export and context information X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 11:42:59 -0000 Hi,=20 I believe that this approach is also more consistent from a security point of vew and can remove possible concerns of disclosing information from different contexts if carried in the same flow record.=20 Regards, Dan=20 (speaking as contributor) > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Juergen Schoenwaelder > Sent: Thursday, July 07, 2011 2:01 PM > To: Benoit Claise > Cc: ipfix@ietf.org > Subject: Re: [IPFIX] ipfix mib export and context information >=20 > On Thu, Jul 07, 2011 at 12:29:15PM +0200, Benoit Claise wrote: > > Dear all, > > > > Let me ask the question differently. > > Do you see a use case for the export, within a single flow record, > > of MIB variables from different SNMP contexts? >=20 > Depends on the definition of "flow". As long as we keep the definition > found in RFC 3917 section 2.1, the likelihood of exporting MIB > variables from different SNMP context for a single flow record is > likely diminishing small. >=20 > That said, I think the main use case for MIB variable export via IPFIX > seems to be related to a much more liberal definition of a "flow", > that is, one uses IPFIX to simply stream MIB variables towards a > collector instead of polling them, likely independent of any traffic > flows. In such a scenario, the likelihood to want different SNMP > contexts in a single flow record might increase, but it might still be > acceptable to have a limitation that a single flow record can only > carry data from a single context (since SNMP has kind of the same > restriction - a PDU is always bound to a specific context). >=20 > So I guess my answer is "no", I do not see a strong use case for > having data from different contexts in a single flow record (but > different flow records should be able to carry data from different > SNMP contexts). >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Thu Jul 7 04:42:59 2011 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 3218621F8795 for ; Thu, 7 Jul 2011 04:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 gksiETZPQJE5 for ; Thu, 7 Jul 2011 04:42:58 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6F67F21F87FF for ; Thu, 7 Jul 2011 04:42:58 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67BgvGS018260 for ; Thu, 7 Jul 2011 13:42:57 +0200 (CEST) Received: from [10.55.43.52] (ams-bclaise-8713.cisco.com [10.55.43.52]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67BguLQ013098 for ; Thu, 7 Jul 2011 13:42:57 +0200 (CEST) Message-ID: <4E159BC0.8010704@cisco.com> Date: Thu, 07 Jul 2011 13:42:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipfix@ietf.org References: <20110630093904.GB3317@elstar.local> <4E158A7B.2030809@cisco.com> <20110707110102.GB8896@elstar.local> In-Reply-To: <20110707110102.GB8896@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] ipfix mib export and context information X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 11:42:59 -0000 Juergen, Good summary. Basically, I would agree that there is no strong use cases right now So I would like to the draft to the solution a) and b.1) from your initial email. Regards, Benoit. > On Thu, Jul 07, 2011 at 12:29:15PM +0200, Benoit Claise wrote: >> Dear all, >> >> Let me ask the question differently. >> Do you see a use case for the export, within a single flow record, >> of MIB variables from different SNMP contexts? > Depends on the definition of "flow". As long as we keep the definition > found in RFC 3917 section 2.1, the likelihood of exporting MIB > variables from different SNMP context for a single flow record is > likely diminishing small. > > That said, I think the main use case for MIB variable export via IPFIX > seems to be related to a much more liberal definition of a "flow", > that is, one uses IPFIX to simply stream MIB variables towards a > collector instead of polling them, likely independent of any traffic > flows. In such a scenario, the likelihood to want different SNMP > contexts in a single flow record might increase, but it might still be > acceptable to have a limitation that a single flow record can only > carry data from a single context (since SNMP has kind of the same > restriction - a PDU is always bound to a specific context). > > So I guess my answer is "no", I do not see a strong use case for > having data from different contexts in a single flow record (but > different flow records should be able to carry data from different > SNMP contexts). > > /js > From dromasca@avaya.com Mon Jul 11 02:05:16 2011 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 8FB1121F88D5 for ; Mon, 11 Jul 2011 02:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[AWL=0.452, 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 pjmwG4K0EU-u for ; Mon, 11 Jul 2011 02:05:15 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0B321F8893 for ; Mon, 11 Jul 2011 02:05:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAALe7Gk7GmAcF/2dsb2JhbABTmAmPN3ereAKaeIVbXwSXb4su X-IronPort-AV: E=Sophos;i="4.65,514,1304308800"; d="scan'208";a="255883452" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Jul 2011 05:05:13 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Jul 2011 05:03:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2011 11:05:10 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] AD review of draft-ietf-ipfix-configuration-model-09.txt Thread-Index: Acw8K5ItQPFR9sUETp6A/b1fj+hQUAAYJbaAAMcsVkA= References: <4E14E0B4.8000509@net.in.tum.de> From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , "Gerhard Muenz" Cc: IPFIX Working Group Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-configuration-model-09.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 09:05:16 -0000 Hi Gerhard,=20 Please make sure that the updated version will be submitted today before the pre-IETF Internet Draft final submission cut-off by 17:00 PT (00:00 UTC). If a revised version of the document is not submitted today I will need to mover the document from the agenda of the IESG telechat of this week to the next one which will take place only after the IETF meeting.=20 Thanks and Regards, Dan=20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of Romascanu, Dan (Dan) > Sent: Thursday, July 07, 2011 12:59 PM > To: Gerhard Muenz > Cc: IPFIX Working Group > Subject: Re: [IPFIX] AD review of draft-ietf-ipfix-configuration-model- > 09.txt >=20 >=20 >=20 > Hi Gerhard, >=20 >=20 > Thank you for the answers and for addressing my comments. The proposed > changes are fine. >=20 > Can you issue the revised I-D before the submission deadline on Monday, > so that I can place the document on the agenda of the 7/14 IESG > telechat? >=20 > Regards, >=20 > Dan > > -----Original Message----- > > From: Gerhard Muenz [mailto:muenz@net.in.tum.de] > > Sent: Thursday, July 07, 2011 1:25 AM > > To: Romascanu, Dan (Dan) > > Cc: IPFIX Working Group > > Subject: Re: [IPFIX] AD review of > draft-ietf-ipfix-configuration-model- > > 09.txt > > > > > > Dan, > > > > Please find my replies inline. > > > > On 01.06.2011 17:39, Romascanu, Dan (Dan) wrote: > > > Hi, > > > > > > I performed the AD review of > > > draft-ietf-ipfix-configuration-model-09.txt. This document is in > good > > > shape and I am sending it to IETF Last Call. Please consider the > > > comments below together with the other IETF Last Call comments. > > > > > > Technical Comments are marked T and Editorial comments are marked > R. > > > > > > T1. Section 4.2.2 - how is probability expressed - as a value > between > > 0 > > > and 1? > > > > I have added the following sentence: > > "The probability is expressed as a value between 0 and 1." > > > > > T2. Section 4.7: > > > > > > If SCTP is transport protocol, Exporter or > > > Collector may be multi-homed SCTP endpoints (see [RFC4960], > > Section > > > 6.4) and use more than one IP address. > > > > > > A capitalized 2119 MAY seems to be appropriate here. > > > > Changed. > > > > > E1. In Section 4.1: > > > > > > However, indexes SHOULD only be used as identifiers if > > > an SNMP agent on the same Monitoring Device enables access to > the > > > corresponding MIB objects. > > > > > > s/indexes/indices/ > > > s/MIB objects/MIB tables/ > > > > > > Similarly > > > > > > ifIndex SHOULD only be used if an SNMP agent enables > > > access to the corresponding MIB object in the ifTable. > > > Similarly, a physical entity is either identified by its > name > > > (entPhysicalName) or the entPhysicalIndex value of the > > > corresponding object in the ENTITY-MIB module [RFC4133]. > > > entPhysicalIndex SHOULD only be used if an SNMP agent > enables > > > access to the corresponding MIB object in the > > entPhysicalTable. > > > > > > Indices are by definition not-accessible, but accessing the tables > > that > > > they index should be sufficient as the index can be extracted from > > the > > > OIDs of the objects in the table. > > > > Changed as follows: > > > > "ifIndex SHOULD only be used if an SNMP agent enables > > access to the ifTable. > > Similarly, a physical entity is either identified by its name > > (entPhysicalName) or the entPhysicalIndex value of the > > corresponding object in the ENTITY-MIB module [RFC4133]. > > entPhysicalIndex SHOULD only be used if an SNMP agent enables > > access to the entPhysicalTable." > > > > I hope that this is what you suggested. > > > > > E2. In section 4.3 > > > > > > > > > cacheDiscontinuityTime: Timestamp of the most recent occasion at > > > which dataRecords suffered a discontinuity. In contrast to > > > ipfixMeteringProcessDiscontinuityTime, the time is absolute > > and > > > not relative to sysUpTime. > > > Note that this parameter corresponds to > > > ipfixMeteringProcessDiscontinuityTime in the IPFIX MIB > module > > > [RFC5815]. > > > > > > Better say 'functionally corresponds' ... > > > > Changed. I also adopted this wording in the YANG descriptions. > > > > Thanks, > > Gerhard > > > > > Thanks and Regards, > > > > > > Dan > > > > > > _______________________________________________ > > > 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 Internet-Drafts@ietf.org Mon Jul 11 08:00:02 2011 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 8E4E021F8B5F; Mon, 11 Jul 2011 08:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 Bo6FfOvvZsWA; Mon, 11 Jul 2011 08:00:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151BD21F8BDF; Mon, 11 Jul 2011 08:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711150002.6503.89032.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 08:00:02 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D ACTION:draft-ietf-ipfix-configuration-model-10.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:00:02 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Configuration Data Model for IPFIX and PSAMP Author(s) : G. Muenz, et al Filename : draft-ietf-ipfix-configuration-model-10.txt Pages : 126 Date : 2011-07-11 This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipfix-configuration-model-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-07-11075734.I-D@ietf.org> --NextPart-- From muenz@net.in.tum.de Mon Jul 11 10:52:41 2011 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 D9CB521F8E41 for ; Mon, 11 Jul 2011 10:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2+SRFwZhi9o for ; Mon, 11 Jul 2011 10:52:41 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0278821F8D8F for ; Mon, 11 Jul 2011 10:52:40 -0700 (PDT) Received: from [192.168.1.2] (e181055204.adsl.alicedsl.de [85.181.55.204]) by mail.net.in.tum.de (Postfix) with ESMTPSA id A438F202FD46 for ; Mon, 11 Jul 2011 19:56:11 +0200 (CEST) Message-ID: <4E1B386C.8010409@net.in.tum.de> Date: Mon, 11 Jul 2011 19:52:44 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <20110711150002.6503.89032.idtracker@ietfa.amsl.com> In-Reply-To: <20110711150002.6503.89032.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] I-D ACTION:draft-ietf-ipfix-configuration-model-10.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 17:52:42 -0000 Dear all, The new version of the IPFIX configuration draft adopts the comments by Dan (AD Evaluation) and Vijay K. Gurbani (IETF LC). In addition, we decided to add explicit references to PSAMP MIB objects since PSAMP MIB is supposed to be published very soon. Such references had been removed earlier when the future of PSAMP MIB was still uncertain. Finally, the description clauses in the YANG module were completed with textual references to the corresponding IPFIX/PSAMP MIB objects, where these were missing. Thanks, Gerhard On 11.07.2011 17:00, Internet-Drafts@ietf.org wrote: > A new Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > Title : Configuration Data Model for IPFIX and PSAMP > Author(s) : G. Muenz, et al > Filename : draft-ietf-ipfix-configuration-model-10.txt > Pages : 126 > Date : 2011-07-11 > > This document specifies a data model for configuring and monitoring > Selection Processes, Caches, Exporting Processes, and Collecting > Processes of IPFIX and PSAMP compliant Monitoring Devices using the > NETCONF protocol. The data model is defined using UML (Unified > Modeling Language) class diagrams and formally specified using YANG. > The configuration data is encoded in Extensible Markup Language > (XML). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-configuration-model-10.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From wwwrun@rfc-editor.org Mon Jul 11 12:27:46 2011 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 8348221F8E3A for ; Mon, 11 Jul 2011 12:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 q++FRz12o46w for ; Mon, 11 Jul 2011 12:27:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD8121F8E34 for ; Mon, 11 Jul 2011 12:27:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D59B698C4EB; Mon, 11 Jul 2011 12:27:41 -0700 (PDT) To: bclaise@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110711192741.D59B698C4EB@rfc-editor.org> Date: Mon, 11 Jul 2011 12:27:41 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC5101 (2857) 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 Jul 2011 19:27:46 -0000 The following errata report has been submitted for RFC5101, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5101&eid=2857 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 6.2, 4th par Original Text ------------- If reduced sizing is used, Corrected Text -------------- If reduced size encoding is used, Notes ----- s/reduced sizing/reduced size encoding/ Another instance also in this section: "Reduced sizing can also be used". Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5101 (draft-ietf-ipfix-protocol-26) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information Publication Date : January 2008 Author(s) : B. Claise, Ed. Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From internet-drafts@ietf.org Mon Jul 11 14:26:13 2011 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 D47ED11E82AC; Mon, 11 Jul 2011 14:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 P4DCvkEgP4h1; Mon, 11 Jul 2011 14:26:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D2B11E82A4; Mon, 11 Jul 2011 14:26:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711212613.4037.632.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 14:26:13 -0700 Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action: draft-ietf-ipfix-flow-selection-tech-07.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, 11 Jul 2011 21:26:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Flow Information Export Working Gr= oup of the IETF. Title : Flow Selection Techniques Author(s) : Salvatore D'Antonio Tanja Zseby Christian Henke Lorenzo Peluso Filename : draft-ietf-ipfix-flow-selection-tech-07.txt Pages : 23 Date : 2011-07-11 Flow selection is the process of selecting a subset of flows from all flows observed at an observation point. Flow selection reduces the effort of post-processing flow data and transferring Flow Records. This document describes motivations for flow selection and presents flow selection techniques. It provides an information model for configuring flow selection techniques and discusses what information about a flow selection process should be exported. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-07= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipfix-flow-selection-tech-07.= txt From dromasca@avaya.com Thu Jul 14 09:39:28 2011 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 B613E21F8D20 for ; Thu, 14 Jul 2011 09:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.248 X-Spam-Level: X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 QNfVLplxcN71 for ; Thu, 14 Jul 2011 09:39:28 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id C46DD21F8D05 for ; Thu, 14 Jul 2011 09:39:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMwaH07GmAcF/2dsb2JhbABTp1V3q0KDdgKbT4VbXwSYAYs2 X-IronPort-AV: E=Sophos;i="4.65,529,1304308800"; d="scan'208";a="256620878" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Jul 2011 12:39:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Jul 2011 12:37:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2011 18:39:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipfix-configuration-model-10 approved as Proposed Standard Thread-Index: AcxCRJZHbALZHswiRharj1MBz9x7rA== From: "Romascanu, Dan (Dan)" To: "IPFIX Working Group" Subject: [IPFIX] draft-ietf-ipfix-configuration-model-10 approved as Proposed Standard 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, 14 Jul 2011 16:39:28 -0000 Hi,=20 The IESG has just approved draft-ietf-ipfix-configuration-model-10 as Proposed Standard.=20 Thanks to the editors, chairs and the whole WG for this achievement.=20 Regards, Dan=20 From paitken@cisco.com Fri Jul 15 06:52:18 2011 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 19E3521F85FE for ; Fri, 15 Jul 2011 06:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnwPkdTosgYy for ; Fri, 15 Jul 2011 06:52:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2A621F85E2 for ; Fri, 15 Jul 2011 06:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=607; q=dns/txt; s=iport; t=1310737937; x=1311947537; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=8iZ1E0gTLyg4O+THTol7gODZQ7rW8c9ps+015C8xcVs=; b=ZSGySn5nDzN5Ln3FltTRdqsT4KKKK2EyzIukLbYiHBaI7as/XXYKf56I FdvkyDAi5woNroL9yBSMf23Zw4m1UQM/CoyI4VS+JJbz5ET2nfW/4OzAj nTUbjGkRW3ysYSsQaj1fklTJqlm3tFkw3RGWNFbrZg9C5AxlexV+l66sX Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOxEIE6Q/khL/2dsb2JhbABTp2R3rEKBI54shjoEkmaFAYtT X-IronPort-AV: E=Sophos;i="4.65,535,1304294400"; d="scan'208";a="102553071" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2011 13:52:13 +0000 Received: from [10.61.99.10] (dhcp-10-61-99-10.cisco.com [10.61.99.10]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6FDqCAS019701 for ; Fri, 15 Jul 2011 13:52:13 GMT Message-ID: <4E20462D.3070009@cisco.com> Date: Fri, 15 Jul 2011 14:52:45 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] draft-johnson-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: Fri, 15 Jul 2011 13:52:18 -0000 Dear All, A new version of the IPFIX MIB variable export draft is available here: http://tools.ietf.org/id/draft-johnson-ipfix-mib-variable-export-02.txt The diff is here: http://tools.ietf.org/rfcdiff?url2=draft-johnson-ipfix-mib-variable-export-02.txt This version clarifies use of the Enterprise bit, discusses the use of indexed and non-indexed MIB Objects as scope fields, gives many more examples in section 5, and makes numerous small corrections to the text. We still have some open AIs related to context and indexing, so a version -03 can be expected. P. From n.brownlee@auckland.ac.nz Sun Jul 17 20:11:29 2011 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 30AE921F84CE for ; Sun, 17 Jul 2011 20:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74, 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 gTYvn70exCX8 for ; Sun, 17 Jul 2011 20:11:27 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 025F321F84D4 for ; Sun, 17 Jul 2011 20:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1310958687; x=1342494687; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4E23A45B.9050504@auckland.ac.nz>|Date:=20 Mon,=2018=20Jul=202011=2015:11:23=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20Preparation=20for=20Quebec=20IETF=20meeting |Content-Transfer-Encoding:=207bit; bh=gUaU6wzxgTC9fMgPts7s1/0lCy1B4+MVg1aQ4RJTtQk=; b=sXnEl3oQbwPKhdsuPOSMV+/To3Xoo1goapQVqDOjIEBKRDIGzJ7f4aN0 Ti4TEyYmfulIEA68sQeV4XvPBhW/4HZwlSyMD5DXfPYFnAphGMHNJGIAL z5wSBcHvuZoXuugylaJ/uqk8Uwjjz90zhyK1iBClI9mnDRkVMA6eTOr3E Q=; X-IronPort-AV: E=Sophos;i="4.67,220,1309694400"; d="scan'208";a="72262220" 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; 18 Jul 2011 15:11:24 +1200 Message-ID: <4E23A45B.9050504@auckland.ac.nz> Date: Mon, 18 Jul 2011 15:11:23 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Preparation for Quebec IETF 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: Mon, 18 Jul 2011 03:11:30 -0000 Hi all: The latest agenda draft is now on the Meeting Materials pages. For the last part, "drafts that could become WG items," I'd like to have a Presenter's name to put on the agenda. Please would those involved with the drafts decide who that will be, and let me know real soon now. Also, don't forget that I need to get the slides onto Meeting Materials well before our meeting. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From iesg-secretary@ietf.org Mon Jul 18 11:17:29 2011 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 1D18021F8579; Mon, 18 Jul 2011 11:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 a5lMngMXNBqa; Mon, 18 Jul 2011 11:17:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3930F21F85DA; Mon, 18 Jul 2011 11:17:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110718181720.1057.13337.idtracker@ietfa.amsl.com> Date: Mon, 18 Jul 2011 11:17:20 -0700 Cc: ipfix chair , ipfix mailing list , RFC Editor Subject: [IPFIX] Protocol Action: 'Configuration Data Model for IPFIX and PSAMP' to Proposed Standard (draft-ietf-ipfix-configuration-model-10.txt) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 18:17:29 -0000 The IESG has approved the following document: - 'Configuration Data Model for IPFIX and PSAMP' (draft-ietf-ipfix-configuration-model-10.txt) as a Proposed Standard This document is the product of the IP Flow Information Export Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipfix-configuration-model/ Technical Summary This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol [RFC4741]. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG [RFC6020]. The configuration data is encoded in Extensible Markup Language (XML). Working Group Summary The mediation framework was added to the IPIFX charter in 2008. The document was discussed at all meetings since then and had several revisions. There was nothing special about this document. There is a strong consensus in the IPFIX WG to publish this version of the document. There are no particular issues in the document without strong consensus in the IPFIX WG. Document Quality The document underwent a WG last call in the IPFIX WG and a YANG doctor review. This way, a high document quality has been achieved already. Personnel Juergen Quittek is the Document Shepherd. Dan Romascanu is the Responsible Area Director. RFC Editor Note OLD: [W3C.REC-xml-20040204] Paoli, J., Maler, E., Yergeau, F., Sperberg-McQueen, C., and T. Bray, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml- 20040204, February 2004, NEW: [W3C.REC-xml-20081126] Paoli, J., Yergeau, F., Sperberg-McQueen, C., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, . From vivekg@juniper.net Tue Jul 19 13:19:12 2011 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 7732421F8B13 for ; Tue, 19 Jul 2011 13:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 2on+YE0mzy9r for ; Tue, 19 Jul 2011 13:19:12 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id C083E21F8B16 for ; Tue, 19 Jul 2011 13:19:11 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTiXmv/65K/E/BuZSk6Mh3jpcWKjltUTK@postini.com; Tue, 19 Jul 2011 13:19:11 PDT Received: from p-emfe02-bng.jnpr.net (10.211.204.20) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Jul 2011 13:16:51 -0700 Received: from EMBX02-BNG.jnpr.net ([fe80::8ce3:7a6:9990:3c6e]) by p-emfe02-bng.jnpr.net ([::1]) with mapi; Wed, 20 Jul 2011 01:46:48 +0530 From: Vivek Gupta To: "ipfix@ietf.org" Date: Wed, 20 Jul 2011 01:46:46 +0530 Thread-Topic: IPFIX usage for Layer-2 VPNs Thread-Index: AcxGUMiSOe+YXUOhTOew9jZBLe1epw== Message-ID: <33E45EFC4B29EE4195B9440B22F885EA01B8095284@EMBX02-BNG.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_33E45EFC4B29EE4195B9440B22F885EA01B8095284EMBX02BNGjnpr_" MIME-Version: 1.0 Subject: [IPFIX] IPFIX usage for Layer-2 VPNs 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, 19 Jul 2011 20:21:58 -0000 --_000_33E45EFC4B29EE4195B9440B22F885EA01B8095284EMBX02BNGjnpr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Is there any draft available for supporting monitoring of layer-2 vpns (Vpl= s packets) using ipfix? It seems the standard support quite a few layer-2 fields (sub-ip fields), b= ut not all of them, which would be relevant for monitoring the traffic goin= g across in the router for a l2vpn. Regards, Vivek --_000_33E45EFC4B29EE4195B9440B22F885EA01B8095284EMBX02BNGjnpr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Is there any draft available for supporting monitoring of layer-2 vpns= (Vpls packets) using ipfix?
It seems the standard support quite a few layer-2 fields (sub-ip field= s), but not all of them, which would be relevant for monitoring the traffic= going across in the router for a l2vpn.
 
Regards,
Vivek
 
 --_000_33E45EFC4B29EE4195B9440B22F885EA01B8095284EMBX02BNGjnpr_-- From n.brownlee@auckland.ac.nz Tue Jul 19 18:01:02 2011 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 C9C8A21F8A35 for ; Tue, 19 Jul 2011 18:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 7neZMwAKDqIj for ; Tue, 19 Jul 2011 18:00:59 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id C0A1521F8A30 for ; Tue, 19 Jul 2011 18:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1311123659; x=1342659659; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; z=Message-ID:=20<4E2628BD.9040004@auckland.ac.nz>|Date:=20 Wed,=2020=20Jul=202011=2013:00:45=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20IPFIX=20Working=20Group=20 |Subject:=20Fwd:=20FW:=20IETF=2081=20Audio=20Streaming |References:=20|In-Reply-To:=20; bh=4ByziEzjnqWH1nXmk917wkFk0KzrcQQIXi5v0qa3Xdg=; b=OfYeyRL/XMkkCyt1QRJnZlnyeEr186JqH4jbVe+Rb2z5WsxUBeLOJ5c1 92SPRiW/raNlndAzLwM+9yStmfR//pAAiwiGzhmYaRgyQ8SST8Zwler6i qmA6aMw87c3dfl/3Y8znONzL9EKxw00D9v7gTSCtiaVMbS758OL0GLpGG 4=; X-IronPort-AV: E=Sophos;i="4.67,231,1309694400"; d="txt'?scan'208";a="72745327" 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; 20 Jul 2011 13:00:45 +1200 Message-ID: <4E2628BD.9040004@auckland.ac.nz> Date: Wed, 20 Jul 2011 13:00:45 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IPFIX Working Group References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------060300000809060708050603" Subject: [IPFIX] Fwd: FW: IETF 81 Audio Streaming 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, 20 Jul 2011 01:01:02 -0000 This is a multi-part message in MIME format. --------------060300000809060708050603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: FW: IETF 81 Audio Streaming Date: Sat, 16 Jul 2011 11:39:14 +0200 From: Romascanu, Dan (Dan) To: Hi, I suggest that you forward this information to your WG lists, for the benefit of people attending IETF-81 on site or remotely. Thanks and Regards, Dan From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Nick Kukich Sent: Saturday, July 16, 2011 12:53 AM To: ietf@ietf.org Subject: IETF 81 Audio Streaming Greetings! We're two weeks out from the beginning of meeting streaming. For those interested in monitoring sessions or participating remotely the following information may prove useful. - -Audio Streaming- All 8 parallel tracks at the IETF 81 meeting will be broadcast starting with the commencement of working group sessions on Monday, July 25, 2011 at 0900 EDT (GMT-4) and continue until Friday, July 29 at 1515 EDT. Because we have been asked several times in the past, note that if you wish to use the rooms that are being recorded for impromptu meeting during unscheduled sessions or lunch breaks that you can invite remote participants to tune in to the appropriate stream. Recording cannot be guaranteed for unscheduled sessions. Conversely, it should never be assumed that recording or observation is not occurring on open microphones, they are after all connected to the Internet. The links for streaming sources and the schedule are best retrieved from the IETF tools agenda, which as per Standard operating procedure will be located here: http://tools.ietf.org/agenda/81/ - -Jabber/XMPP- For information on IETF Jabber participation see: http://www.ietf.org/jabber/index.html or click on the Jabber links in the tools team agenda once you have a properly configured jabber/xmpp messaging client. - -Webex- Webex screen sharing participation is possible for a limited number of sessions. Consult with your working-group chair or the secretariat for more information. - -Ticketing- For prompt access to the meeting trouble desk, the email address is: mtd@ietf.org For streaming related issues please send email to ietf-streaming@verilan.com with info including the current time and affected streaming channel. Regards, Nick Kukich Network Engineer Verilan Event Services, Inc. 503.710.5115 --------------060300000809060708050603 Content-Type: text/plain; name="ATT4812602.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT4812602.txt" _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --------------060300000809060708050603-- From wwwrun@rfc-editor.org Wed Jul 20 15:59:28 2011 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 E0B0221F8AF0; Wed, 20 Jul 2011 15:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 laMfTPSVX9+K; Wed, 20 Jul 2011 15:59:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id B9E0121F8AED; Wed, 20 Jul 2011 15:59:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EB7E098C4F4; Wed, 20 Jul 2011 15:59:22 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110720225923.EB7E098C4F4@rfc-editor.org> Date: Wed, 20 Jul 2011 15:59:22 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] RFC 6313 on Export of Structured Data in IP Flow Information Export (IPFIX) 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, 20 Jul 2011 22:59:29 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6313 Title: Export of Structured Data in IP Flow Information Export (IPFIX) Author: B. Claise, G. Dhandapani, P. Aitken, S. Yates Status: Standards Track Stream: IETF Date: July 2011 Mailbox: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com Pages: 71 Characters: 163360 Updates: RFC5102 I-D Tag: draft-ietf-ipfix-structured-data-06.txt URL: http://www.rfc-editor.org/rfc/rfc6313.txt This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. [STANDARDS-TRACK] This document is a product of the IP Flow Information Export Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From skg.mnnit@gmail.com Thu Jul 21 03:32:51 2011 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 3267721F889A for ; Thu, 21 Jul 2011 03:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EdIis5e-LYZm for ; Thu, 21 Jul 2011 03:32:50 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1821F85EE for ; Thu, 21 Jul 2011 03:32:50 -0700 (PDT) Received: by fxe4 with SMTP id 4so3866883fxe.27 for ; Thu, 21 Jul 2011 03:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=z96M9E+Ig8bl2V06A62ECu+9Amp2SpdXQWzSpywn6jk=; b=hqemGLz3+YrRgjpebP8McdEN+PeCMQ19bvzqReyZTf1U2EiMCGRX7+1d/es4uJ6uY5 PHt8C5u2ec5eN3UVtuKkjf3g7pJnr6yPTF35/ItwzzYAG/jpu9A3fUKDqyva/C8/y5Bb Dt0EP5RzYCUInMg3oweM3gIGdtd9MfCnHavTk= MIME-Version: 1.0 Received: by 10.204.8.82 with SMTP id g18mr32012bkg.11.1311244369471; Thu, 21 Jul 2011 03:32:49 -0700 (PDT) Received: by 10.204.156.11 with HTTP; Thu, 21 Jul 2011 03:32:49 -0700 (PDT) Date: Thu, 21 Jul 2011 16:02:49 +0530 Message-ID: From: Saurabh Gupta To: ipfix@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1eab8db273804a891de8f X-Mailman-Approved-At: Thu, 21 Jul 2011 04:49:43 -0700 Subject: [IPFIX] Structured data type support 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 Jul 2011 10:43:02 -0000 --000e0cd1eab8db273804a891de8f Content-Type: text/plain; charset=ISO-8859-1 Hi All, I am new to this group. I am looking for library which provides support of IPFIX sub-templates. Regards, Saurabh --000e0cd1eab8db273804a891de8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,
=A0I am new to this group. I am looking for library which provi= des support of IPFIX sub-templates.

Regards,
=
=A0Saurabh
--000e0cd1eab8db273804a891de8f-- From n.brownlee@auckland.ac.nz Mon Jul 25 11:22:33 2011 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 2AC1421F8BF8 for ; Mon, 25 Jul 2011 11:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7Ffp9MCfdZe for ; Mon, 25 Jul 2011 11:22:32 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id B6FB821F8BED for ; Mon, 25 Jul 2011 11:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1311618152; x=1343154152; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; z=Message-ID:=20<4E2DB45C.5020505@auckland.ac.nz>|Date:=20 Tue,=2026=20Jul=202011=2006:22:20=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20ipfix@ietf.org|Subject:=20Slides=20for=20Wed nesday's=20meeting|Content-Transfer-Encoding:=207bit; bh=sKExLYJhMuughiEYC9AsEVlKXpWhiuhXPEgA2guCvKc=; b=U1FslGxvBdfCnhzPp7NlU4rKPn0g+WNrVu1S4wU+uCUUIHYSV1X46ldG fCO+DeUhmdYhy8C+nxiSeSooblr5dFyE2u2jFgRUJV51R8upZ3kiir9jC dyZVG3yd7eHsKcdPhz8MS8SabJDxmfUPv0YDYUfWSYWIP2O6Di1E0Y6Au 0=; X-IronPort-AV: E=Sophos;i="4.67,264,1309694400"; d="scan'208";a="73956005" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.18.191 - Outgoing - Outgoing-SSL Received: from unknown (HELO [130.129.18.191]) ([130.129.18.191]) by mx2-int.auckland.ac.nz with ESMTP; 26 Jul 2011 06:22:23 +1200 Message-ID: <4E2DB45C.5020505@auckland.ac.nz> Date: Tue, 26 Jul 2011 06:22:20 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] Slides for Wednesday's 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: Mon, 25 Jul 2011 18:22:33 -0000 Hi all: If you're presenting on Wednesday, please make sure you email .pdf files of your slides to me by 0900 Wednesday, so that I can get them onto the Meeting Materials page. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 . The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From paitken@cisco.com Tue Jul 26 05:30:15 2011 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 6240721F87E2 for ; Tue, 26 Jul 2011 05:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 NnauIzbd1vnf for ; Tue, 26 Jul 2011 05:30:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 148C121F8797 for ; Tue, 26 Jul 2011 05:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=9325; q=dns/txt; s=iport; t=1311683414; x=1312893014; h=message-id:date:from:mime-version:to:subject; bh=JvePRjuyXrJnup41tr2//kxKd9ex6fIczL8XvwoemBs=; b=Ol0abA33bpa4NXP7SZGx3BVjn5bGuV4P2tgGeetoYCkgRZnCpqU3phTI nPllZKU1s0KHQhOXtror/q6bxsqFsNJRdDS/1Eru08CFkVgtGCVGyDzhY fNjaaT/ymzYdlT2iZwE4nR5o/wXHE59r60zWgSaVRrp6Q/J/Ds8yV9aWg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADWyLk6Q/khL/2dsb2JhbABQAW8/IhgDAgECAQJYDg8BAR+CNqR/d6tCgSOeY4ZABJJyhQeLWg X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208,217";a="44348559" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 26 Jul 2011 12:30:12 +0000 Received: from [10.61.83.209] (ams3-vpn-dhcp5074.cisco.com [10.61.83.209]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QCUBMH031549 for ; Tue, 26 Jul 2011 12:30:11 GMT Message-ID: <4E2EB359.8070309@cisco.com> Date: Tue, 26 Jul 2011 13:30:17 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF IPFIX Working Group Content-Type: multipart/alternative; boundary="------------070901080007020104090405" Subject: [IPFIX] IPFIX export: SNMP versus physical Interface 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 Jul 2011 12:30:15 -0000 This is a multi-part message in MIME format. --------------070901080007020104090405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear IPFIXers, I noticed that the definitions of fields 10 and 14, and fields 252 and 253 are confusingly similar. See below. Cisco uses fields 10 and 14 to export the logical or virtual interface (eg. SVI, tunnel), while fields 252 and 253 export the actual physical interface. For example, if we have an SVI configured on a VLAN, the SNMP index of the SVI would be exported using fields 10 and 14, while the SNMP index of the physical port in that VLAN would be exported with fields 252 and 253. So I propose to update fields 10 and 11 to say, "the index of the logical or virtual interface ...", to contrast with 252 and 253 which say, "The index of a networking device's physical interface ...". And I propose to add the following text (copied from 10 and 14) to 252 and 253, to clarify that these are also SNMP ifIndex values: The value matches the value of managed object 'ifIndex' as defined in RFC 2863. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized, as specified in RFC 2863. The existing definitions are below for reference. Please shout now if you disagree. Thanks, P. 10 ingressInterface unsigned32 identifier current The index of the IP interface where packets of this Flow are being received. The value matches the value of managed object 'ifIndex' as defined in RFC 2863. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized, as specified in RFC 2863. See [RFC2863] for the definition of the ifIndex object. 14 egressInterface unsigned32 identifier current The index of the IP interface where packets of this Flow are being sent. The value matches the value of managed object 'ifIndex' as defined in RFC 2863. Note that ifIndex values are not assigned statically to an interface and that the interfaces may be renumbered every time the device's management system is re-initialized, as specified in RFC 2863. See [RFC2863] for the definition of the ifIndex object. 252 ingressPhysicalInterface unsigned32 identifier current The index of a networking device's physical interface (example, a switch port) where packets of this flow are being received. See [RFC2863] for the definition of the ifIndex object. 253 egressPhysicalInterface unsigned32 identifier current The index of a networking device's physical interface (example, a switch port) where packets of this flow are being sent. See [RFC2863] for the definition of the ifIndex object. --------------070901080007020104090405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear IPFIXers,

I noticed that the definitions of fields 10 and 14, and fields 252 and 253 are confusingly similar. See below.

Cisco uses fields 10 and 14 to export the logical or virtual interface (eg. SVI, tunnel), while fields 252 and 253 export the actual physical interface.

For example, if we have an SVI configured on a VLAN, the SNMP index of the SVI would be exported using fields 10 and 14, while the SNMP index of the physical port in that VLAN would be exported with fields 252 and 253.

So I propose to update fields 10 and 11 to say, "the index of the logical or virtual interface ...", to contrast with 252 and 253 which say, "The index of a networking device's physical interface ...".

And I propose to add the following text (copied from 10 and 14) to 252 and 253, to clarify that these are also SNMP ifIndex values:

           The value matches the value of
           managed object 'ifIndex' as defined in RFC 2863.
           Note that ifIndex values are not assigned statically to an
           interface and that the interfaces may be renumbered every
           time the device's management system is re-initialized, as
           specified in RFC 2863.


The existing definitions are below for reference.

Please shout now if you disagree.

Thanks,
P.


10 ingressInterface unsigned32 identifier current

           The index of the IP interface where packets of this Flow
           are being received.  The value matches the value of managed
           object 'ifIndex' as defined in RFC 2863.
           Note that ifIndex values are not assigned statically to an
           interface and that the interfaces may be renumbered every
           time the device's management system is re-initialized, as
           specified in RFC 2863.
        
          See [RFC2863] for the definition of the
          ifIndex object.


14 egressInterface unsigned32 identifier current

           The index of the IP interface where packets of
           this Flow are being sent.  The value matches the value of
           managed object 'ifIndex' as defined in RFC 2863.
           Note that ifIndex values are not assigned statically to an
           interface and that the interfaces may be renumbered every
           time the device's management system is re-initialized, as
           specified in RFC 2863.
      
          See [RFC2863] for the definition of the
          ifIndex object.


252 ingressPhysicalInterface unsigned32 identifier current

          The index of a networking device's physical interface (example, a
          switch port) where packets of this flow are being received.
                
          See [RFC2863] for the definition of the ifIndex object.


253 egressPhysicalInterface unsigned32 identifier current

          The index of a networking device's physical interface (example, a
          switch port) where packets of this flow are being sent.
                
          See [RFC2863] for the definition of the ifIndex object.

--------------070901080007020104090405-- From j.schoenwaelder@jacobs-university.de Tue Jul 26 06:15:18 2011 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 8D73821F8786 for ; Tue, 26 Jul 2011 06:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 RzylFLupF+8d for ; Tue, 26 Jul 2011 06:15:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C451A21F8560 for ; Tue, 26 Jul 2011 06:15:16 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CF5220BF8; Tue, 26 Jul 2011 15:15:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q3BN+OhFfL3X; Tue, 26 Jul 2011 15:15:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 355F520BEB; Tue, 26 Jul 2011 15:15:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B9FF1A18AD0; Tue, 26 Jul 2011 15:15:14 +0200 (CEST) Date: Tue, 26 Jul 2011 15:15:14 +0200 From: Juergen Schoenwaelder To: Paul Aitken Message-ID: <20110726131514.GA6421@elstar.local> Mail-Followup-To: Paul Aitken , IETF IPFIX Working Group References: <4E2EB359.8070309@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E2EB359.8070309@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 13:15:18 -0000 On Tue, Jul 26, 2011 at 01:30:17PM +0100, Paul Aitken wrote: > Dear IPFIXers, > > I noticed that the definitions of fields 10 and 14, and fields 252 > and 253 are confusingly similar. See below. > > Cisco uses fields 10 and 14 to export the logical or virtual > interface (eg. SVI, tunnel), while fields 252 and 253 export the > actual physical interface. > > For example, if we have an SVI configured on a VLAN, the SNMP index > of the SVI would be exported using fields 10 and 14, while the SNMP > index of the physical port in that VLAN would be exported with > fields 252 and 253. > > So I propose to update fields 10 and 11 to say, "the index of the > logical or virtual interface ...", to contrast with 252 and 253 > which say, "The index of a networking device's physical interface > ...". Not sure this is right because if I only have a physical interface and no logical/virtual interfaces, I think I still want to report the physical interface in fields 10 and 11, no? I am not sure why there is actually a need to change something here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From paitken@cisco.com Tue Jul 26 06:23:50 2011 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 0FAD721F8C58 for ; Tue, 26 Jul 2011 06:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTH2TKj7pHV0 for ; Tue, 26 Jul 2011 06:23:49 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7021F8C2E for ; Tue, 26 Jul 2011 06:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=1242; q=dns/txt; s=iport; t=1311686629; x=1312896229; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=2sojrMSa/2ZjwA9GEy28KbJWfrkJOjU4a6yvXSUXvj4=; b=LQeA2ygo+rt7iraXlK5soN4OGQoCK65t6bY5Q27m/nZs1n9O0U4jxzp1 AjVY1ldehIgiHZ6OSAC3Ig9RW7Gx5wI9i8hd/WBv/8HviHCaOVUe3AmPZ tUYHix8jpaAuw37HVf5fdnb8tmurh/JktYTuKMOYdSkYIG1WzdIYTVPwA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANy+Lk6Q/khL/2dsb2JhbAA1AQEBAQIBFAEpRgYMDBgJIg8JAwIBAgECUQcODwEBH6c1d4h8oyaeY4ZABJJyhQeLWg X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208";a="104362409" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 26 Jul 2011 13:23:47 +0000 Received: from [10.61.83.209] (ams3-vpn-dhcp5074.cisco.com [10.61.83.209]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6QDNlCf013759 for ; Tue, 26 Jul 2011 13:23:47 GMT Message-ID: <4E2EBFEA.7080109@cisco.com> Date: Tue, 26 Jul 2011 14:23:54 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF IPFIX Working Group References: <4E2EB359.8070309@cisco.com> <20110726131514.GA6421@elstar.local> In-Reply-To: <20110726131514.GA6421@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface 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 Jul 2011 13:23:50 -0000 Juergen, > On Tue, Jul 26, 2011 at 01:30:17PM +0100, Paul Aitken wrote: >> Dear IPFIXers, >> >> I noticed that the definitions of fields 10 and 14, and fields 252 >> and 253 are confusingly similar. See below. >> >> Cisco uses fields 10 and 14 to export the logical or virtual >> interface (eg. SVI, tunnel), while fields 252 and 253 export the >> actual physical interface. >> >> For example, if we have an SVI configured on a VLAN, the SNMP index >> of the SVI would be exported using fields 10 and 14, while the SNMP >> index of the physical port in that VLAN would be exported with >> fields 252 and 253. >> >> So I propose to update fields 10 and 11 to say, "the index of the >> logical or virtual interface ...", to contrast with 252 and 253 >> which say, "The index of a networking device's physical interface >> ...". > Not sure this is right because if I only have a physical interface and > no logical/virtual interfaces, I think I still want to report the > physical interface in fields 10 and 11, no? I am not sure why there is > actually a need to change something here. In this case, physical == logical, so either 10/14 or 252/253 would be correct. We've always used 10/14 in this case. P. From trammell@tik.ee.ethz.ch Tue Jul 26 06:31:04 2011 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 B877721F86AC for ; Tue, 26 Jul 2011 06:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owNA+pTg9ebP for ; Tue, 26 Jul 2011 06:31:03 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B6B7321F86A5 for ; Tue, 26 Jul 2011 06:31:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 47DDFD9324; Tue, 26 Jul 2011 15:31:02 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JMNyBFjuLame; Tue, 26 Jul 2011 15:31:01 +0200 (MEST) Received: from dhcp-678d.meeting.ietf.org (unknown [130.129.103.141]) (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 D7E90D9302; Tue, 26 Jul 2011 15:31:00 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4E2EBFEA.7080109@cisco.com> Date: Tue, 26 Jul 2011 09:29:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5F0DA83D-DA24-43C7-8F63-E68C80A7FCC5@tik.ee.ethz.ch> References: <4E2EB359.8070309@cisco.com> <20110726131514.GA6421@elstar.local> <4E2EBFEA.7080109@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1084) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface 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 Jul 2011 13:31:04 -0000 hi Paul, The intent is clear from your email, but the terminology here seems like = it might be implementation-specific; i'd be in favor of the change but = it should be clear that: 10/14 are for "interfaces" as the term is most commonly used (I'm not = saying that's the right way to say it, need more coffee) 252/253 are for "physical interfaces" in the special case that the = physical interface is different than the notional interface. Speaking of this in terms of interface "virtualization" requires someone = to know more about precisely what sort of virtualization... Cheers, Brian On Jul 26, 2011, at 9:23 AM, Paul Aitken wrote: > Juergen, >=20 >> On Tue, Jul 26, 2011 at 01:30:17PM +0100, Paul Aitken wrote: >>> Dear IPFIXers, >>>=20 >>> I noticed that the definitions of fields 10 and 14, and fields 252 >>> and 253 are confusingly similar. See below. >>>=20 >>> Cisco uses fields 10 and 14 to export the logical or virtual >>> interface (eg. SVI, tunnel), while fields 252 and 253 export the >>> actual physical interface. >>>=20 >>> For example, if we have an SVI configured on a VLAN, the SNMP index >>> of the SVI would be exported using fields 10 and 14, while the SNMP >>> index of the physical port in that VLAN would be exported with >>> fields 252 and 253. >>>=20 >>> So I propose to update fields 10 and 11 to say, "the index of the >>> logical or virtual interface ...", to contrast with 252 and 253 >>> which say, "The index of a networking device's physical interface >>> ...". >> Not sure this is right because if I only have a physical interface = and >> no logical/virtual interfaces, I think I still want to report the >> physical interface in fields 10 and 11, no? I am not sure why there = is >> actually a need to change something here. >=20 > In this case, physical =3D=3D logical, so either 10/14 or 252/253 = would be correct. >=20 > We've always used 10/14 in this case. >=20 > P. >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From andrewf@plixer.com Tue Jul 26 07:54:54 2011 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 CF7E511E80AD for ; Tue, 26 Jul 2011 07:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTeMlWy-1mNc for ; Tue, 26 Jul 2011 07:54:54 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id F01B011E80A3 for ; Tue, 26 Jul 2011 07:54:53 -0700 (PDT) Received: from [130.129.17.159] ([130.129.17.159]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 10:54:53 -0400 Message-ID: <4E2ED53C.6070803@plixer.com> Date: Tue, 26 Jul 2011 10:54:52 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipfix@ietf.org References: <4E2EB359.8070309@cisco.com> <20110726131514.GA6421@elstar.local> <4E2EBFEA.7080109@cisco.com> In-Reply-To: <4E2EBFEA.7080109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2011 14:54:53.0404 (UTC) FILETIME=[FA1081C0:01CC4BA3] Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface 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 Jul 2011 14:54:54 -0000 On 07/26/2011 09:23 AM, Paul Aitken wrote: > Juergen, > >> On Tue, Jul 26, 2011 at 01:30:17PM +0100, Paul Aitken wrote: >>> Dear IPFIXers, >>> >>> I noticed that the definitions of fields 10 and 14, and fields 252 >>> and 253 are confusingly similar. See below. >>> >>> Cisco uses fields 10 and 14 to export the logical or virtual >>> interface (eg. SVI, tunnel), while fields 252 and 253 export the >>> actual physical interface. >>> >>> For example, if we have an SVI configured on a VLAN, the SNMP index >>> of the SVI would be exported using fields 10 and 14, while the SNMP >>> index of the physical port in that VLAN would be exported with >>> fields 252 and 253. >>> >>> So I propose to update fields 10 and 11 to say, "the index of the >>> logical or virtual interface ...", to contrast with 252 and 253 >>> which say, "The index of a networking device's physical interface >>> ...". >> Not sure this is right because if I only have a physical interface and >> no logical/virtual interfaces, I think I still want to report the >> physical interface in fields 10 and 11, no? I am not sure why there is >> actually a need to change something here. > > In this case, physical == logical, so either 10/14 or 252/253 would be > correct. > > We've always used 10/14 in this case. > > P. > >From a collection and reporting perspective the important difference for me in these two sets of definitions isn't physical vs maybe not physical, but that "The value matches the value of managed object 'ifIndex' as defined in RFC 2863 ..." and everything that implies for elements 10/14. So I agree with Paul's approach. There are situations where either 10/14 or 252/253 could be used, but if RFC 2863 applies to your interface use 10/14. Maybe rather than replacing "IP interface" with "logical or virtual interface" it could just be "interface" or "network interface". On a related not I'm not sure the references for 252/253 need to refer readers to "[RFC2863] for the definition of the ifIndex object." -Andrew From j.schoenwaelder@jacobs-university.de Tue Jul 26 08:02:24 2011 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 0F0ED11E80A3 for ; Tue, 26 Jul 2011 08:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 W+EwvEK7xqWs for ; Tue, 26 Jul 2011 08:02:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 14DFB1F0C36 for ; Tue, 26 Jul 2011 08:02:23 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6ED2E20BFE; Tue, 26 Jul 2011 17:02:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nx6cLsdhlxbG; Tue, 26 Jul 2011 17:02:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15B7B20BF8; Tue, 26 Jul 2011 17:02:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 57F1B1A18E15; Tue, 26 Jul 2011 17:02:20 +0200 (CEST) Date: Tue, 26 Jul 2011 17:02:20 +0200 From: Juergen Schoenwaelder To: Andrew Feren Message-ID: <20110726150219.GA7287@elstar.local> Mail-Followup-To: Andrew Feren , ipfix@ietf.org References: <4E2EB359.8070309@cisco.com> <20110726131514.GA6421@elstar.local> <4E2EBFEA.7080109@cisco.com> <4E2ED53C.6070803@plixer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E2ED53C.6070803@plixer.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 15:02:24 -0000 On Tue, Jul 26, 2011 at 10:54:52AM -0400, Andrew Feren wrote: > From a collection and reporting perspective the important difference for > me in these two sets of definitions isn't physical vs maybe not > physical, but that "The value matches the value of managed object > 'ifIndex' as defined in RFC 2863 ..." and everything that implies for > elements 10/14. > > So I agree with Paul's approach. There are situations where either > 10/14 or 252/253 could be used, but if RFC 2863 applies to your > interface use 10/14. > > Maybe rather than replacing "IP interface" with "logical or virtual > interface" it could just be "interface" or "network interface". > > On a related not I'm not sure the references for 252/253 need to refer > readers to "[RFC2863] for the definition of the ifIndex object." RFC2863 always applies to an ifIndex object. I fail to see the problem. I find the definitions of these elements rather clear as they are written. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Quittek@neclab.eu Tue Jul 26 08:25:59 2011 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 79AD111E811C for ; Tue, 26 Jul 2011 08:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 vp2YXBG5IVqO for ; Tue, 26 Jul 2011 08:25:58 -0700 (PDT) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B974B11E810A for ; Tue, 26 Jul 2011 08:25:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0893C2800032C; Tue, 26 Jul 2011 17:25:56 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxpU60gI-ULp; Tue, 26 Jul 2011 17:25:55 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.netlab.nec.de (Postfix) with ESMTP id E059128000327; Tue, 26 Jul 2011 17:25:40 +0200 (CEST) Received: from Polydeuces.office.hd ([169.254.3.125]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Tue, 26 Jul 2011 17:25:41 +0200 From: Juergen Quittek To: Juergen Schoenwaelder , Andrew Feren Thread-Topic: [IPFIX] IPFIX export: SNMP versus physical Interface Thread-Index: AQHMS6hGIQFWk4i+J0edj8aD7cTPqw== Date: Tue, 26 Jul 2011 15:25:40 +0000 Message-ID: In-Reply-To: <20110726150219.GA7287@elstar.local> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <5323DBFA22CC784BA84D405A95ECE2BB@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface 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 Jul 2011 15:25:59 -0000 Hi all, [Writing as technical contrionbutor] I agree. In the definition of IEs #10 and #14 we refer to RFC2863 and state that the IE reports the ifIndex value for that interface. This still appears to be a very good choice and I don't think we should change this. It might be helpful using IEs #252 and #253 when reporting the physical interface is needed where a logical one reported by #10 or #14 is located. Juergen On 26.07.11 11:02, "Juergen Schoenwaelder" wrote: >On Tue, Jul 26, 2011 at 10:54:52AM -0400, Andrew Feren wrote: > >> From a collection and reporting perspective the important difference for >> me in these two sets of definitions isn't physical vs maybe not >> physical, but that "The value matches the value of managed object >> 'ifIndex' as defined in RFC 2863 ..." and everything that implies for >> elements 10/14. >>=20 >> So I agree with Paul's approach. There are situations where either >> 10/14 or 252/253 could be used, but if RFC 2863 applies to your >> interface use 10/14. >>=20 >> Maybe rather than replacing "IP interface" with "logical or virtual >> interface" it could just be "interface" or "network interface". >>=20 >> On a related not I'm not sure the references for 252/253 need to refer >> readers to "[RFC2863] for the definition of the ifIndex object." > >RFC2863 always applies to an ifIndex object. I fail to see the >problem. I find the definitions of these elements rather clear as they >are written. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 >_______________________________________________ >IPFIX mailing list >IPFIX@ietf.org >https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Tue Jul 26 13:29:16 2011 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 15DC111E8097 for ; Tue, 26 Jul 2011 13:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] 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 Akoys1TUTSdI for ; Tue, 26 Jul 2011 13:29:15 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4C11D5E8008 for ; Tue, 26 Jul 2011 13:29:15 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6QKTDRU028130; Tue, 26 Jul 2011 22:29:13 +0200 (CEST) Received: from [10.82.214.194] (rtp-vpn4-1730.cisco.com [10.82.214.194]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6QKT7oi018325; Tue, 26 Jul 2011 22:29:08 +0200 (CEST) Message-ID: <4E2F2393.7030600@cisco.com> Date: Tue, 26 Jul 2011 16:29:07 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Andrew Feren , ipfix@ietf.org, Juergen Schoenwaelder References: <4E2EB359.8070309@cisco.com> <20110726131514.GA6421@elstar.local> <4E2EBFEA.7080109@cisco.com> <4E2ED53C.6070803@plixer.com> <20110726150219.GA7287@elstar.local> In-Reply-To: <20110726150219.GA7287@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface 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 Jul 2011 20:29:16 -0000 Juergen, > On Tue, Jul 26, 2011 at 10:54:52AM -0400, Andrew Feren wrote: > >> From a collection and reporting perspective the important difference for >> me in these two sets of definitions isn't physical vs maybe not >> physical, but that "The value matches the value of managed object >> 'ifIndex' as defined in RFC 2863 ..." and everything that implies for >> elements 10/14. >> >> So I agree with Paul's approach. There are situations where either >> 10/14 or 252/253 could be used, but if RFC 2863 applies to your >> interface use 10/14. >> >> Maybe rather than replacing "IP interface" with "logical or virtual >> interface" it could just be "interface" or "network interface". >> >> On a related not I'm not sure the references for 252/253 need to refer >> readers to "[RFC2863] for the definition of the ifIndex object." > RFC2863 always applies to an ifIndex object. I fail to see the > problem. I find the definitions of these elements rather clear as they > are written. I agree. Both sets (10/14 and 252/253( are ifIndex. The second set applies to the physical ifIndex, while the first one might be non-physical. A Flow Record can contain both, and the Collector can draw the conclusions if the sets are different. So I would not change the definitions. A clarification might be welcome (even though I'm not convinced). However, where? - not in IANA, which specifies individual IE, and not the relation between them - maybe in the RFC5102 Proposed Draft RFC Regards, Benoit. > > /js > From andrewf@plixer.com Tue Jul 26 16:02:48 2011 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 ADECD21F8666 for ; Tue, 26 Jul 2011 16:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4hY413wH0ET for ; Tue, 26 Jul 2011 16:02:48 -0700 (PDT) Received: from smtp.plixer.com (smtp.plixer.com [66.186.184.193]) by ietfa.amsl.com (Postfix) with ESMTP id 0999921F857D for ; Tue, 26 Jul 2011 16:02:47 -0700 (PDT) Received: from [10.1.15.20] ([66.186.184.173]) by smtp.plixer.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 19:02:47 -0400 Message-ID: <4E2F478C.60603@plixer.com> Date: Tue, 26 Jul 2011 19:02:36 -0400 From: Andrew Feren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110627 Thunderbird/7.0a1 MIME-Version: 1.0 To: Benoit Claise References: <4E2EB359.8070309@cisco.com> <20110726131514.GA6421@elstar.local> <4E2EBFEA.7080109@cisco.com> <4E2ED53C.6070803@plixer.com> <20110726150219.GA7287@elstar.local> <4E2F2393.7030600@cisco.com> In-Reply-To: <4E2F2393.7030600@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2011 23:02:47.0390 (UTC) FILETIME=[22B847E0:01CC4BE8] Cc: ipfix@ietf.org Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface 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 Jul 2011 23:02:48 -0000 On 07/26/2011 04:29 PM, Benoit Claise wrote: > Juergen, > >> On Tue, Jul 26, 2011 at 10:54:52AM -0400, Andrew Feren wrote: >> >>> From a collection and reporting perspective the important >>> difference for >>> me in these two sets of definitions isn't physical vs maybe not >>> physical, but that "The value matches the value of managed object >>> 'ifIndex' as defined in RFC 2863 ..." and everything that implies for >>> elements 10/14. >>> >>> So I agree with Paul's approach. There are situations where either >>> 10/14 or 252/253 could be used, but if RFC 2863 applies to your >>> interface use 10/14. >>> >>> Maybe rather than replacing "IP interface" with "logical or virtual >>> interface" it could just be "interface" or "network interface". >>> >>> On a related not I'm not sure the references for 252/253 need to refer >>> readers to "[RFC2863] for the definition of the ifIndex object." >> RFC2863 always applies to an ifIndex object. I fail to see the >> problem. I find the definitions of these elements rather clear as they >> are written. > I agree. > Both sets (10/14 and 252/253( are ifIndex. > The second set applies to the physical ifIndex, while the first one > might be non-physical. > A Flow Record can contain both, and the Collector can draw the > conclusions if the sets are different. > > So I would not change the definitions. > A clarification might be welcome (even though I'm not convinced). > However, where? > - not in IANA, which specifies individual IE, and not the relation > between them > - maybe in the RFC5102 Proposed Draft RFC > > Regards, Benoit. Thanks. This makes sense to me now. Two things could have made this clearer to me when I read the docs. 1) if the IANA description of 252/253 contained similar language to what is in the descriptions for 10/14. Something like "The value matches the value of a physical 'ifIndex' as defined in RFC 2863." I know when I see one description (10/14) specify RFC 2862 and the description for a different, but similar, element (252/253) makes no mention of RFC 2862 it is not clear to me if the second element must be "as defined in RFC 2862". I start to wonder if the description is incomplete or the reference section is a cut and paste error or something. 2) I like Benoit's suggestion of putting a description of the relationship between these two sets of elements somewhere. I don't have an opinion on the right location for #2. -Andrew From inacio@cert.org Wed Jul 27 03:31:13 2011 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 58EB621F8509 for ; Wed, 27 Jul 2011 03:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD617V0JlHou for ; Wed, 27 Jul 2011 03:31:12 -0700 (PDT) Received: from shetland.sei.cmu.edu (shetland.sei.cmu.edu [192.58.107.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDDD21F8520 for ; Wed, 27 Jul 2011 03:31:11 -0700 (PDT) Received: from timber.sei.cmu.edu (timber.sei.cmu.edu [10.64.21.23]) by shetland.sei.cmu.edu (8.14.4/8.14.4/1294) with ESMTP id p6RAV3Qf007288; Wed, 27 Jul 2011 06:31:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cert.org; s=jthatj15xw2j; t=1311762663; bh=QSqdjlj0Cy6AKFvN4dgKPXYzI4FVtaWU4/rRDRLzERs=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version:Sender: Reply-To; b=b60Cd/ApLQ5OQrBhV14fftKBPVUpZRi5JO8JmYFLFK96OAwXwg5oMNcZt2ull3n1k 9yHWkSuDWwohrw6YfwLo/4rIYJWa9F6p6fiLK3s4MTgv17Vgit1CPgDxSo/bbpZrwU RgocxcCT4FeuV59r1nI966tbs6+bYUGZBKdiqFBc= Received: from owa.sei.cmu.edu (vader.sei.cmu.edu [10.64.28.14]) by timber.sei.cmu.edu (8.14.4/8.14.4/1348) with ESMTP id p6RAV2LW005402; Wed, 27 Jul 2011 06:31:02 -0400 Received: from EXCHANGE.sei.cmu.edu ([10.64.28.13]) by vader.sei.cmu.edu ([10.64.28.14]) with mapi; Wed, 27 Jul 2011 06:31:02 -0400 From: Chris Inacio To: Saurabh Gupta Date: Wed, 27 Jul 2011 06:31:03 -0400 Thread-Topic: [IPFIX] Structured data type support Thread-Index: AcxMSEeCqfwmzu30QqeRAk7JoYXzfg== Message-ID: <975D142B-8357-4A56-8AE3-75F436C31D3A@cert.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] Structured data type support 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 Jul 2011 10:31:13 -0000 You can try our library from CERT, fixbuf. http://tools.netsa.cert.org Chris Inacio On Jul 21, 2011, at 6:32 AM, Saurabh Gupta wrote: > Hi All, > I am new to this group. I am looking for library which provides support = of IPFIX sub-templates. >=20 > Regards, > Saurabh > From braun@net.in.tum.de Wed Jul 27 06:21:27 2011 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 5C53321F850B for ; Wed, 27 Jul 2011 06:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF0Sh7yc40Cl for ; Wed, 27 Jul 2011 06:21:26 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id 781FB21F8678 for ; Wed, 27 Jul 2011 06:21:25 -0700 (PDT) Received: from honshu.net.in.tum.de (honshu.net.in.tum.de [131.159.20.100]) by mail.net.in.tum.de (Postfix) with ESMTPSA id AD2122083FE5 for ; Wed, 27 Jul 2011 15:23:18 +0200 (CEST) From: Lothar Braun Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2011 15:21:23 +0200 Message-Id: <476242D1-B10B-472E-A1CA-209C8F11F37B@net.in.tum.de> To: IPFIX list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [IPFIX] DTLS Recommendations 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 Jul 2011 13:21:27 -0000 Hi all, with the WG meeting approaching and me only participating remotely, I = would like to share some thoughts on the DTLS recommendations draft by = mail. There has not been an update on = draft-mentz-ipfix-dtls-recommendations-02 because we didn't get any = additional feedback and we didn't feel that any changes were necessary. Some input on where to move with the draft (this is basically the same = what I presented at the meeting in Prague :-)): The draft identifies issues with IPFIX over DTLS/UDP and DTLS/SCTP. Most = of them can be addressed by updating the implementation guidelines. Some = other things (might) require text in the protocol spec: DTLS/SCTP DTLS renegotiations (changing the keying material for long-lasting = associations), require stall of IPFIX export before the negotiation can = occur. As a consequence, buffers might fill up and messages might get = lost within the exporter. This is highly implementation specific and can = therefore be addressed in the implementation guidelines. DTLS/UDP Incorrect PATH MTU estimation: Messages can get lost if path MTU is not configured correctly. Using = DTLS heartbeats, one could use the heartbeats to estimate the correct = path MTU. This is purely optional and does not require changes to IPFIX, = as the heartbeat mechanism is part of the DTLS layer, and can be = therefore part of the implementation guidelines. Collector state loss This is probably the most severe problem with IPFIX and DTLS, because = there is a huge difference between IPFIX over UDP and IPFIX over = UDP/DTLS.=20 If DTLS is employed, both the Collector and the Exporter need to hold = DTLS-specific state in order to communicate. This state is established = at association setup and required for all the communication after the = setup. If the Collector looses this state (either due to a crash, a = reconfiguration, or a reboot), it will not be able to decode any further = Messages from the Exporter. Even worse, the Exporter cannot detect that = state loss because IPFIX is a purely unidirectional protocol and the = Exporter does not get any feedback from the Collector. This means that IPFIX will behave differently with UDP on the transport = layer depending on whether DTLS is used or not: If a state loss occurs on IPFIX over UDP (e.g. template information gets = lost), IPFIX will automatically recover because the Exporter is required = to re-send this state information (e..g the Templates) periodically. If = a state loss occurs on IPFIX over DTLS/UDP, no recovery will take place = within this transport association. I think this is a protocol issue, and = should be somehow addressed by the protocol. I can see two options: 1.) the protocol specification highlights that this problem exists, and = specifies that an Exporter should deal with this problem (e.g. according = to the tips that are given in an updated version of the guidelines). The = guidelines can then be updated to contain the solution/work-arounds from = draft-mentz-ipfix-dtls-recommendations-02. 2.) The protocol specification requires the Exporter to implement one of = the options we proposed in draft-mentz-ipfix-dtls-recommendations-02 = (preferably require the use of DTLS heartbeats) to detect Collector = state information loss. Option 2 would most likely introduce a dependency on DTLS heartbeats, = which could be a problem: The DTLS heartbeat document is currently not a = RFC. yet. It is still a working group document of the TLS group = (http://tools.ietf.org/html/draft-ietf-tls-dtls-heartbeat-02). It will = be discussed on TLS WG meeting on thursday = (http://www.ietf.org/proceedings/81/agenda/tls.txt), and it might be a = blocker for an updated version of the protocol specs. Pre-Shared Keys (DTLS and TLS with all transport binding): This is not a problem, but a nice to have feature: RFC 5101 requires the = use of X509 certificates for authentication between the Collector and = the Exporter. Deploying and maintaining a X509 infrastructure is complex = and might be an overkill for small deployments. RFC4279 defines = ciphersuites which build on pre-shared keys for authentication. If the group would like to allow pre-shared keys for authentication, a = change to RFC 5101 in Section "11.3 Authentication" would be required. Best regards, Lothar -- Lothar Braun Chair for Network Architectures and Services (I8) Department of Informatics Technische Universit=E4t M=FCnchen Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18010 Fax: +49 89 289-18033 E-mail: braun@net.in.tum.de=20 From bclaise@cisco.com Wed Jul 27 23:01:48 2011 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 98E1611E80A4 for ; Wed, 27 Jul 2011 23:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] 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 MtojIH86Z83n for ; Wed, 27 Jul 2011 23:01:48 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E9CA111E8070 for ; Wed, 27 Jul 2011 23:01:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S61kso017398 for ; Thu, 28 Jul 2011 08:01:46 +0200 (CEST) Received: from [10.86.251.97] (bxb-vpn3-865.cisco.com [10.86.251.97]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S61jcI021146 for ; Thu, 28 Jul 2011 08:01:46 +0200 (CEST) Message-ID: <4E30FB49.8030308@cisco.com> Date: Thu, 28 Jul 2011 02:01:45 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] draft-ietf-ipfix-flow-selection-tech-07 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, 28 Jul 2011 06:01:48 -0000 Dear all, Today, during the WG meeting, I had the action item to double-check the IE id. Basically, no problem with Write-up on that front. From that list, the TBD1 should be assigned the value 3, as specified in http://tools.ietf.org/html/draft-yourtchenko-cisco-ies-01#section-3.1 +------+---------------------------+ | ID | Name | +------+---------------------------+ | TBD1 | fsFlowRecordTotalCount | +------+---------------------------+ | TBD2 | fsFlowRecordSelectedCount | +------+---------------------------+ | TBD3 | fsPacketTotalCount | +------+---------------------------+ | TBD4 | fsPacketSelectedCount | +------+---------------------------+ | TBD5 | fsOctetTotalCount | +------+---------------------------+ | TBD6 | fsOctetSelectedCount | +------+---------------------------+ Not sure what the process is. - directly replace TBD1 by 3 in the draft - warn the IPFIX IANA expert, i.e. Nevil, that 3 should be assigned - something else? Regards, Benoit. From bclaise@cisco.com Wed Jul 27 23:04:50 2011 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 B5C0911E80B1 for ; Wed, 27 Jul 2011 23:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, 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 MZbt1G--KIgw for ; Wed, 27 Jul 2011 23:04:50 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E2E8811E8070 for ; Wed, 27 Jul 2011 23:04:49 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S64mW7017782 for ; Thu, 28 Jul 2011 08:04:48 +0200 (CEST) Received: from [10.86.251.97] (bxb-vpn3-865.cisco.com [10.86.251.97]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6S64huD023024 for ; Thu, 28 Jul 2011 08:04:43 +0200 (CEST) Message-ID: <4E30FBFB.6050105@cisco.com> Date: Thu, 28 Jul 2011 02:04:43 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "ipfix@ietf.org" References: <4E30FB49.8030308@cisco.com> In-Reply-To: <4E30FB49.8030308@cisco.com> X-Forwarded-Message-Id: <4E30FB49.8030308@cisco.com> Content-Type: multipart/alternative; boundary="------------000500090406030206000704" Subject: [IPFIX] originalFlowsPresent versus fsFlowRecordTotalCount 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, 28 Jul 2011 06:04:50 -0000 This is a multi-part message in MIME format. --------------000500090406030206000704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Following on that thread, do we really two IEs for originalFlowsPresent versus fsFlowRecordTotalCount? In other words, do we need different IEs for different Intermediate Functions? Then why not originalFlowsPresentForAnonymization? You see where I'm going ;-) Regards, Benoit. -------- Original Message -------- Subject: [IPFIX] draft-ietf-ipfix-flow-selection-tech-07 Date: Thu, 28 Jul 2011 02:01:45 -0400 From: Benoit Claise To: ipfix@ietf.org Dear all, Today, during the WG meeting, I had the action item to double-check the IE id. Basically, no problem with Write-up on that front. From that list, the TBD1 should be assigned the value 3, as specified in http://tools.ietf.org/html/draft-yourtchenko-cisco-ies-01#section-3.1 +------+---------------------------+ | ID | Name | +------+---------------------------+ | TBD1 | fsFlowRecordTotalCount | +------+---------------------------+ | TBD2 | fsFlowRecordSelectedCount | +------+---------------------------+ | TBD3 | fsPacketTotalCount | +------+---------------------------+ | TBD4 | fsPacketSelectedCount | +------+---------------------------+ | TBD5 | fsOctetTotalCount | +------+---------------------------+ | TBD6 | fsOctetSelectedCount | +------+---------------------------+ Not sure what the process is. - directly replace TBD1 by 3 in the draft - warn the IPFIX IANA expert, i.e. Nevil, that 3 should be assigned - something else? Regards, Benoit. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --------------000500090406030206000704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Following on that thread, do we really two IEs for originalFlowsPresent versus fsFlowRecordTotalCount?
In other words, do we need different IEs for different Intermediate Functions?
Then why not originalFlowsPresentForAnonymization? You see where I'm going ;-)

Regards, Benoit.

-------- Original Message --------
Subject: [IPFIX] draft-ietf-ipfix-flow-selection-tech-07
Date: Thu, 28 Jul 2011 02:01:45 -0400
From: Benoit Claise <bclaise@cisco.com>
To: ipfix@ietf.org <ipfix@ietf.org> 


Dear all,

Today, during the WG meeting, I had the action item to double-check the 
IE id.
Basically, no problem with Write-up on that front.

>From that list, the TBD1 should be assigned the value 3, as specified 
in http://tools.ietf.org/html/draft-yourtchenko-cisco-ies-01#section-3.1

                   +------+---------------------------+
                   | ID   | Name                      |
                   +------+---------------------------+
                   | TBD1 | fsFlowRecordTotalCount    |
                   +------+---------------------------+
                   | TBD2 | fsFlowRecordSelectedCount |
                   +------+---------------------------+
                   | TBD3 | fsPacketTotalCount        |
                   +------+---------------------------+
                   | TBD4 | fsPacketSelectedCount     |
                   +------+---------------------------+
                   | TBD5 | fsOctetTotalCount         |
                   +------+---------------------------+
                   | TBD6 | fsOctetSelectedCount      |
                   +------+---------------------------+

Not sure what the process is.
    - directly replace TBD1 by 3 in the draft
    - warn the IPFIX IANA expert, i.e. Nevil, that 3 should be assigned
    - something else?

Regards, Benoit.
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
--------------000500090406030206000704-- From paitken@cisco.com Thu Jul 28 02:29:19 2011 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 4133321F8C6A for ; Thu, 28 Jul 2011 02:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvEeXEW7T09R for ; Thu, 28 Jul 2011 02:29:18 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28521F8C5F for ; Thu, 28 Jul 2011 02:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=2032; q=dns/txt; s=iport; t=1311845359; x=1313054959; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=veFm0TIUhSywDc8bdEzq0jid+7m0vCFObQrCCgLdI2E=; b=TLi/9+8W3zATtRYu/bBOZoSLOVW+Zo55STvl5oY/ZeLkSaMrGRsCJPYP gVHZexMt3O/63gbEog+8smL1Qv74Inw2FvgMqYCzcXyt9bdQnh3aDqKJH mBUqbgD68vO77KX2sioRL/P2dczAr1ACmsZ7ll5s59jIauSS8wDFltn5Y M=; X-IronPort-AV: E=Sophos;i="4.67,281,1309737600"; d="scan'208";a="45108697" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 28 Jul 2011 09:29:10 +0000 Received: from [10.61.67.165] (ams3-vpn-dhcp933.cisco.com [10.61.67.165]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6S9T9XI017609; Thu, 28 Jul 2011 09:29:09 GMT Message-ID: <4E312BEB.7080303@cisco.com> Date: Thu, 28 Jul 2011 10:29:15 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Benoit Claise References: <4E30FB49.8030308@cisco.com> In-Reply-To: <4E30FB49.8030308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] draft-ietf-ipfix-flow-selection-tech-07 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, 28 Jul 2011 09:29:19 -0000 Benoit, All, If fsFlowRecordTotalCountis equivalent to field #3, isn't fsPacketTotalCount equivalent to #2 and fsOctetTotalCount equivalent to #1 ? Also, there is an issue with section 7 of this draft: it doesn't describe the semantics for any of the new IEs. The word "Total" in the names seems to describe their function and not the semantic. It's especially important to know whether these are absolute or delta counts. P. On 28/07/11 07:01, Benoit Claise wrote: > Dear all, > > Today, during the WG meeting, I had the action item to double-check > the IE id. > Basically, no problem with Write-up on that front. > > From that list, the TBD1 should be assigned the value 3, as specified > in http://tools.ietf.org/html/draft-yourtchenko-cisco-ies-01#section-3.1 > > +------+---------------------------+ > | ID | Name | > +------+---------------------------+ > | TBD1 | fsFlowRecordTotalCount | > +------+---------------------------+ > | TBD2 | fsFlowRecordSelectedCount | > +------+---------------------------+ > | TBD3 | fsPacketTotalCount | > +------+---------------------------+ > | TBD4 | fsPacketSelectedCount | > +------+---------------------------+ > | TBD5 | fsOctetTotalCount | > +------+---------------------------+ > | TBD6 | fsOctetSelectedCount | > +------+---------------------------+ > > Not sure what the process is. > - directly replace TBD1 by 3 in the draft > - warn the IPFIX IANA expert, i.e. Nevil, that 3 should be assigned > - something else? > > Regards, Benoit. > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From c.henke@tu-berlin.de Thu Jul 28 04:51:27 2011 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 1A7C121F8C62 for ; Thu, 28 Jul 2011 04:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449, 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 tZdxbXnMBmNt for ; Thu, 28 Jul 2011 04:51:26 -0700 (PDT) Received: from mail.tu-berlin.de (mail.tu-berlin.de [130.149.7.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4A43921F8C63 for ; Thu, 28 Jul 2011 04:51:26 -0700 (PDT) X-tubIT-Incoming-IP: 195.37.78.250 Received: from fokus8250.fokus.fraunhofer.de ([195.37.78.250] helo=chhPC) by mail.tu-berlin.de (exim-4.75/mailfrontend-4) with esmtpa for id 1QmP7d-0003ak-A5; Thu, 28 Jul 2011 13:51:25 +0200 From: "Christian Henke" To: References: <4E30FB49.8030308@cisco.com> <4E312BEB.7080303@cisco.com> In-Reply-To: <4E312BEB.7080303@cisco.com> Date: Thu, 28 Jul 2011 13:51:16 +0200 Message-ID: <000701cc4d1c$a8535b80$f8fa1280$@henke@tu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxNCNZ16K32D5dWSOC6R9NzLgXwxAAE6W+A Content-Language: de X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.7.28.113314 X-PMX-Spam: Gauge=IIIIIII, Probability=0%, Report='' Subject: Re: [IPFIX] draft-ietf-ipfix-flow-selection-tech-07 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, 28 Jul 2011 11:51:27 -0000 Hello, Okay our original idea by introducing these TBDs was:=20 The difference between the proposed IEs and the IEs #1-#3 is that we = only look at the packets and flows that arrive at the flow selection process. = So when there is a prior selection process (e.g. packet selection) we get = less packets and flows at the Flow Selection Process. Imagine that you want = to measure all the packets TotalCount before Packet Selection, before Flow Selection (TBD3) and After Flow Selection (TBD4). In order to = differentiate between these Counters we introduced these TBDs. The TBD are Total and Not DeltaCounters. They are only reset after the measurement interval but not each after each export. Following Benoits explanation it makes sense and keeps the IE list short = to use the original IEs and to send a flow record containing the selection Algorithm and the corresponding counter IEs so the semantics is clear. = So the proposed IEs would be needless.=20 Since there is no FlowSelectionAlgorithm IE specified yet, I would then propose another IE similar to 304 selectorAlgorithm which specifies the Algorithm used for FlowSelection. =20 =20 Regards, Christian -----Urspr=FCngliche Nachricht----- Von: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] Im Auftrag = von Paul Aitken Gesendet: Donnerstag, 28. Juli 2011 11:29 An: Benoit Claise Cc: ipfix@ietf.org Betreff: Re: [IPFIX] draft-ietf-ipfix-flow-selection-tech-07 Benoit, All, If fsFlowRecordTotalCountis equivalent to field #3, isn't=20 fsPacketTotalCount equivalent to #2 and fsOctetTotalCount equivalent to = #1 ? Also, there is an issue with section 7 of this draft: it doesn't=20 describe the semantics for any of the new IEs. The word "Total" in the names seems to describe their function and not=20 the semantic. It's especially important to know whether these are absolute or delta=20 counts. P. On 28/07/11 07:01, Benoit Claise wrote: > Dear all, > > Today, during the WG meeting, I had the action item to double-check=20 > the IE id. > Basically, no problem with Write-up on that front. > > From that list, the TBD1 should be assigned the value 3, as specified=20 > in = http://tools.ietf.org/html/draft-yourtchenko-cisco-ies-01#section-3.1 > > +------+---------------------------+ > | ID | Name | > +------+---------------------------+ > | TBD1 | fsFlowRecordTotalCount | > +------+---------------------------+ > | TBD2 | fsFlowRecordSelectedCount | > +------+---------------------------+ > | TBD3 | fsPacketTotalCount | > +------+---------------------------+ > | TBD4 | fsPacketSelectedCount | > +------+---------------------------+ > | TBD5 | fsOctetTotalCount | > +------+---------------------------+ > | TBD6 | fsOctetSelectedCount | > +------+---------------------------+ > > Not sure what the process is. > - directly replace TBD1 by 3 in the draft > - warn the IPFIX IANA expert, i.e. Nevil, that 3 should be = assigned > - something else? > > Regards, Benoit. > _______________________________________________ > 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 wwwrun@rfc-editor.org Thu Jul 28 15:37:27 2011 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 2A4FB11E8082 for ; Thu, 28 Jul 2011 15:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ofey1WykkRli for ; Thu, 28 Jul 2011 15:37:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9152611E807E for ; Thu, 28 Jul 2011 15:37:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 765D098C4EF; Thu, 28 Jul 2011 15:37:26 -0700 (PDT) To: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110728223726.765D098C4EF@rfc-editor.org> Date: Thu, 28 Jul 2011 15:37:26 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6313 (2873) 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, 28 Jul 2011 22:37:27 -0000 The following errata report has been submitted for RFC6313, "Export of Structured Data in IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=2873 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 11 Original Text ------------- Two new IPFIX registries have been created, and the existing IPFIX Information Element registry has been updated as detailed below. Corrected Text -------------- A new IPFIX registry has been created, and the existing IPFIX Information Element registry has been updated as detailed below. Notes ----- Only one new registry has been created - for the "structured data types semantics", per section 11.4 of the document. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6313 (draft-ietf-ipfix-structured-data-06) -------------------------------------- Title : Export of Structured Data in IP Flow Information Export (IPFIX) Publication Date : July 2011 Author(s) : B. Claise, G. Dhandapani, P. Aitken, S. Yates Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Jul 28 15:45:39 2011 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 8DE9921F857D for ; Thu, 28 Jul 2011 15:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ziGaj6aXwi8n for ; Thu, 28 Jul 2011 15:45:39 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0A41621F8574 for ; Thu, 28 Jul 2011 15:45:39 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E452998C4EF; Thu, 28 Jul 2011 15:45:38 -0700 (PDT) To: bclaise@cisco.com, gowri@cisco.com, paitken@cisco.com, syates@cisco.com, dromasca@avaya.com, rbonica@juniper.net, n.brownlee@auckland.ac.nz, quittek@neclab.eu From: RFC Errata System Message-Id: <20110728224538.E452998C4EF@rfc-editor.org> Date: Thu, 28 Jul 2011 15:45:38 -0700 (PDT) Cc: ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Editorial Errata Reported] RFC6313 (2874) 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, 28 Jul 2011 22:45:39 -0000 The following errata report has been submitted for RFC6313, "Export of Structured Data in IP Flow Information Export (IPFIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6313&eid=2874 -------------------------------------- Type: Editorial Reported by: Paul Aitken Section: 11 Original Text ------------- This document specifies several new IPFIX abstract data types, a new IPFIX Data Type Semantic, and several new Information Elements. Corrected Text -------------- This document specifies several new IPFIX abstract data types, a new IPFIX Data Type Semantic, and several new Information Elements. Furthermore, this document updates the schema at http://www.iana.org/assignments/xml-registry/schema/ipfix.xsd with the changes specified in Appendix A. Notes ----- Agreed addition of "Furthermore ,,. Appendix A." was overlooked during AUTH48. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6313 (draft-ietf-ipfix-structured-data-06) -------------------------------------- Title : Export of Structured Data in IP Flow Information Export (IPFIX) Publication Date : July 2011 Author(s) : B. Claise, G. Dhandapani, P. Aitken, S. Yates Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From Quittek@neclab.eu Thu Jul 28 16:50:23 2011 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 34AAE11E809C for ; Thu, 28 Jul 2011 16:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.326 X-Spam-Level: X-Spam-Status: No, score=-102.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 B-CWxAbY5jFV for ; Thu, 28 Jul 2011 16:50:22 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 986965E8004 for ; Thu, 28 Jul 2011 16:50:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0807F28000329; Fri, 29 Jul 2011 01:50:22 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgsX21LIq3or; Fri, 29 Jul 2011 01:50:21 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D602428000198; Fri, 29 Jul 2011 01:50:01 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.20]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0270.001; Fri, 29 Jul 2011 01:50:01 +0200 From: Juergen Quittek To: Benoit Claise , IETF IPFIX Working Group Thread-Topic: [IPFIX] IPFIX export: SNMP versus physical Interface Thread-Index: AQHMTYEQUQd+KBvGBk+W+HZkzeB47g== Date: Thu, 28 Jul 2011 23:50:01 +0000 Message-ID: In-Reply-To: <4E2F2393.7030600@cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.7.0.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <23BC8F4FD69FAB418D28B61570F9BC65@office.hd> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface 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, 28 Jul 2011 23:50:23 -0000 Hi Benoit, I think we cannot change the specification of an IE once it has been registered at IANA. If we do so, existing implementations based on the spec at IANA may break. Juergen On 26.07.11 16:29, "Benoit Claise" wrote: >Juergen, > >> On Tue, Jul 26, 2011 at 10:54:52AM -0400, Andrew Feren wrote: >> >>> From a collection and reporting perspective the important difference >>>for >>> me in these two sets of definitions isn't physical vs maybe not >>> physical, but that "The value matches the value of managed object >>> 'ifIndex' as defined in RFC 2863 ..." and everything that implies for >>> elements 10/14. >>> >>> So I agree with Paul's approach. There are situations where either >>> 10/14 or 252/253 could be used, but if RFC 2863 applies to your >>> interface use 10/14. >>> >>> Maybe rather than replacing "IP interface" with "logical or virtual >>> interface" it could just be "interface" or "network interface". >>> >>> On a related not I'm not sure the references for 252/253 need to refer >>> readers to "[RFC2863] for the definition of the ifIndex object." >> RFC2863 always applies to an ifIndex object. I fail to see the >> problem. I find the definitions of these elements rather clear as they >> are written. >I agree. >Both sets (10/14 and 252/253( are ifIndex. >The second set applies to the physical ifIndex, while the first one >might be non-physical. >A Flow Record can contain both, and the Collector can draw the >conclusions if the sets are different. > >So I would not change the definitions. >A clarification might be welcome (even though I'm not convinced). >However, where? >- not in IANA, which specifies individual IE, and not the relation >between them >- maybe in the RFC5102 Proposed Draft RFC > >Regards, Benoit. >> >> /js >> > >_______________________________________________ >IPFIX mailing list >IPFIX@ietf.org >https://www.ietf.org/mailman/listinfo/ipfix From bclaise@cisco.com Thu Jul 28 16:54:25 2011 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 0917711E8104 for ; Thu, 28 Jul 2011 16:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] 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 sk8nAxS3pQID for ; Thu, 28 Jul 2011 16:54:24 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7033711E809C for ; Thu, 28 Jul 2011 16:54:20 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SNsJHg012387; Fri, 29 Jul 2011 01:54:19 +0200 (CEST) Received: from [10.86.247.35] ([10.86.247.35]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p6SNsFbR019316; Fri, 29 Jul 2011 01:54:16 +0200 (CEST) Message-ID: <4E31F6A7.2050407@cisco.com> Date: Thu, 28 Jul 2011 19:54:15 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 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: IETF IPFIX Working Group Subject: Re: [IPFIX] IPFIX export: SNMP versus physical Interface 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, 28 Jul 2011 23:54:25 -0000 Juergen, I don't want to change the IE description. See below "So I would not change the definitions." Regards, benoit > Hi Benoit, > > I think we cannot change the specification of an IE once it has been > registered at IANA. > If we do so, existing implementations based on the spec at IANA may break. > > Juergen > > > On 26.07.11 16:29, "Benoit Claise" wrote: > >> Juergen, >> >>> On Tue, Jul 26, 2011 at 10:54:52AM -0400, Andrew Feren wrote: >>> >>>> From a collection and reporting perspective the important difference >>>> for >>>> me in these two sets of definitions isn't physical vs maybe not >>>> physical, but that "The value matches the value of managed object >>>> 'ifIndex' as defined in RFC 2863 ..." and everything that implies for >>>> elements 10/14. >>>> >>>> So I agree with Paul's approach. There are situations where either >>>> 10/14 or 252/253 could be used, but if RFC 2863 applies to your >>>> interface use 10/14. >>>> >>>> Maybe rather than replacing "IP interface" with "logical or virtual >>>> interface" it could just be "interface" or "network interface". >>>> >>>> On a related not I'm not sure the references for 252/253 need to refer >>>> readers to "[RFC2863] for the definition of the ifIndex object." >>> RFC2863 always applies to an ifIndex object. I fail to see the >>> problem. I find the definitions of these elements rather clear as they >>> are written. >> I agree. >> Both sets (10/14 and 252/253( are ifIndex. >> The second set applies to the physical ifIndex, while the first one >> might be non-physical. >> A Flow Record can contain both, and the Collector can draw the >> conclusions if the sets are different. >> >> So I would not change the definitions. >> A clarification might be welcome (even though I'm not convinced). >> However, where? >> - not in IANA, which specifies individual IE, and not the relation >> between them >> - maybe in the RFC5102 Proposed Draft RFC >> >> Regards, Benoit. >>> /js >>> >> _______________________________________________ >> IPFIX mailing list >> IPFIX@ietf.org >> https://www.ietf.org/mailman/listinfo/ipfix From n.brownlee@auckland.ac.nz Fri Jul 29 05:30:41 2011 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 D3FE321F8560 for ; Fri, 29 Jul 2011 05:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.227 X-Spam-Level: X-Spam-Status: No, score=-103.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 6nBbReP2lDeR for ; Fri, 29 Jul 2011 05:30:40 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2B12521F855C for ; Fri, 29 Jul 2011 05:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1311942640; x=1343478640; h=message-id:date:from:mime-version:to:subject; z=Message-ID:=20<4E32A7EB.2080108@auckland.ac.nz>|Date:=20 Sat,=2030=20Jul=202011=2000:30:35=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20ipfix@ietf.org|Subject:=20Qebec=20Meeting=20 Minutes; bh=6lBr1cdb3YTxFVUoFmiGTpK8DubrBFKhu+Rn//OeLwk=; b=QV/VY7v/+pPRGUFPOn1ksB+h2uLFVyobSXIgcTWCswjs47qZoLU94lbp eF2flfXaw/CN13hHFxL1+nT+3rR43ycdlLkTFiB89m7zn+owBW8lADPi7 k3wUSR2NmdkMMwoLcH9ntR9VsQk7ejiNutnFaz698IxitWWRfgNx6JRIr k=; X-IronPort-AV: E=Sophos;i="4.67,287,1309694400"; d="txt'?scan'208";a="74825181" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 69.70.11.155 - Outgoing - Outgoing-SSL Received: from modemcable155.11-70-69.static.videotron.ca (HELO [172.16.52.23]) ([69.70.11.155]) by mx2-int.auckland.ac.nz with ESMTP; 30 Jul 2011 00:30:37 +1200 Message-ID: <4E32A7EB.2080108@auckland.ac.nz> Date: Sat, 30 Jul 2011 00:30:35 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: ipfix@ietf.org Content-Type: multipart/mixed; boundary="------------020701020604090007070803" Subject: [IPFIX] Qebec Meeting Minutes 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, 29 Jul 2011 12:30:41 -0000 This is a multi-part message in MIME format. --------------020701020604090007070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all: Here are the DRAFT minutes of our meeting on Wednesday. Please let me know if they need any corrections. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand --------------020701020604090007070803 Content-Type: text/plain; name="81-minutes-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="81-minutes-03.txt" Minutes of the IPFIX meeting at IETF 81 About 25 people present Scribes: Andrew Feren, Chris Innacio & Nevil Brownlee Juergen Quittek opened the meeting, pointing out that all but two drafts from our current charter have now been approved. Two remain: - Flow Selection (Benoit to check IE values, Nevil to submit write-up) - PSAMP MIB We expect that these two will be finished shortly. Juergen presented the PSAMP MIB. The IPFIX MIB (RFC 5815) was intended to use a registry for ipfixSelectorFunctions, but instead IANA created an IPFIX SELECTOR MIB, which would need to be changed each time we add a new selector function. After some discussion, we decided to stop maintaining the IPFIX SELECTOR MIB and create new OID registry for ipfixSelectorFunctions. That will require changes to the PSAMP MIB and to RFC 5815; since that requires AD approval, these will be new WG work items. Benoit Claise presented "Exporting MIB Variables" (now at -02), pointing out that this has issues with exporting variables from different SNMP contexts, but that would clearly be useful. Clear consensus as new WG item. Benoit presented the "IPFIX Mediation Protocol" draft (now at -04), a method of exporting information about mediation processes. Clear consensus as new WG item. Brian Trammell presented the "IE Doctors" draft (now at -01). This documents the process for establishing new IPFIX Information Elements. Clear consensus as new WG item. Brian presented the "IPFIX Aggregation" draft (now at -03), which would establish an Intermediate Process to perform spatial and temporal aggregation in IPFIX Mediators. Clear consensus as new WG item. We have one other draft that was presented in earlier meetings - "Link Layer IEs." We discussed whether this could be a "trial run for the IE Doctors," or a WG item. We reached consensus for it as a WG item, with the proviso that it will need views from Layer 2 domain experts, e.g. IEEE 802.1. Nevil led a discussion on "updating the IPFIX base standards," at least 5101 and 5102. These would include changes made by errata, and some editorial work to clarify text in the light of experience. The DTLS question was raised - should this be included in a new version of 5153 (Implementation Guidelines)? Consensus reached to update 5101 and 5102, and to EITHER revise 5153 OR to create a new document from the DTLS draft [the latter to be decided on the mailing list]. Andrew Yourtchenko presented a new draft that will document the Cisco IEs, 1-127. This could be an Independent Submission, or it could remain as an Internet Draft, updated over time then allowed to expire. Benoit explained that it will make information about these NetFlow v9 IEs available, thus easing the transition to IPFIX. [In other words, the range 1-127 will eventually be filled in, and the distinction between below and above 127 will then disappear. Some of the IEs will be deprecated, some will be reused]. The WG chairs will write a new charter covering all the 'consensus' drafts above and their milestones, and send it to the list. Once consensus is reached on the list, we will our Area Director to take it to IESG for approval. The meeting finished at 1435. - - - - - One-para Summary The IPFIX WG met on Wednesday afternoon. The WG has two current work items, these should be completed by 1 September. We discussed eight individual drafts, reaching consensus that - bearing in mind that five of these have had several revisions - we wish to revise our charter to include all of them. - - - - - --------------020701020604090007070803-- From n.brownlee@auckland.ac.nz Fri Jul 29 08:02:51 2011 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 07D6111E808C for ; Fri, 29 Jul 2011 08:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xn88WW8umT5I for ; Fri, 29 Jul 2011 08:02:50 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9211E808B for ; Fri, 29 Jul 2011 08:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1311951769; x=1343487769; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4E32CB95.5060000@auckland.ac.nz>|Date:=20 Sat,=2030=20Jul=202011=2003:02:45=20+1200|From:=20Nevil =20Brownlee=20|MIME-Version: =201.0|To:=20iana-prot-param-comment@iana.org|CC:=20ipfix @ietf.org|Subject:=20Re:=20[IANA=20#476592]=20clarify=20I PFIX=20interface=20information=20elements|References:=20< RT-Ticket-476592@icann.org>=20<4E2EB62D.80607@cisco.com> =20|In-Reply-To:=20|Content-Transfer-Encoding:=207bit; bh=+H5XLHfO6rSoNiHpiP2VCS7wGsQCMqPRHmgK14celI0=; b=p40IKbRhLrqsuMf4uKO4J76xcT1fE8s3owPzKuoJVSrGXp2/tdAqq2KR 9WhINLSYptnewYvjMcq5e2TDNs7koi3A58uHjj9+XkTzcD9BiyRcmaCGN 8U/KioIJ2fVIftncUWXTNcX20P4lICWMYR4h2N3OCwwKtTA6VNLXqaiz5 E=; X-IronPort-AV: E=Sophos;i="4.67,287,1309694400"; d="scan'208";a="74833583" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 130.129.18.191 - Outgoing - Outgoing-SSL Received: from dhcp-12bf.meeting.ietf.org (HELO [130.129.18.191]) ([130.129.18.191]) by mx2-int.auckland.ac.nz with ESMTP; 30 Jul 2011 03:02:47 +1200 Message-ID: <4E32CB95.5060000@auckland.ac.nz> Date: Sat, 30 Jul 2011 03:02:45 +1200 From: Nevil Brownlee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: iana-prot-param-comment@iana.org References: <4E2EB62D.80607@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [IANA #476592] clarify IPFIX interface information elements 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, 29 Jul 2011 15:02:51 -0000 Hi Amanda: WG consensus (on the IPFIX list) is that we should NOT make this change. Instead, it looks as though we should make a clarifying statement about it, but we haven't yet reached agreement on where that statement should appear. Cheers, Nevil On 27/07/11 09:40, Amanda Baber via RT wrote: > Hi Nevil, > > Are you OK with these changes? > > thanks, > Amanda > > On Tue Jul 26 12:42:44 2011, paitken@cisco.com wrote: >> Dear IANA, >> >> Subject to the WG chair / expert reviewer's approval, and per the WG >> email attached below, I propose the following four clarifications be >> made to the IPFIX Information Elements registry at >> http://www.iana.org/assignments/ipfix/ipfix.xml >> >> Note that the changes are highlighted in red for convenience, though >> this colour is not intended to be used in the registry. >> >> Thanks, >> P. >> >> >> #10 ingressInterface >> >> OLD >> The index of the IP interface where packets of this Flow >> are being received. The value matches the value of managed >> object 'ifIndex' as defined in RFC 2863. >> Note that ifIndex values are not assigned statically to an >> interface and that the interfaces may be renumbered every >> time the device's management system is re-initialized, as >> specified in RFC 2863. >> NEW >> The index of the logical or virtual IP interface where >> packets of this Flow >> are being received. The value matches the value of managed >> object 'ifIndex' as defined in RFC 2863. >> Note that ifIndex values are not assigned statically to an >> interface and that the interfaces may be renumbered every >> time the device's management system is re-initialized, as >> specified in RFC 2863. >> END >> >> >> #14 egressInterface >> >> OLD >> The index of the IP interface where packets of >> this Flow are being sent. The value matches the value of >> managed object 'ifIndex' as defined in RFC 2863. >> Note that ifIndex values are not assigned statically to an >> interface and that the interfaces may be renumbered every >> time the device's management system is re-initialized, as >> specified in RFC 2863. >> NEW >> The index of the logical or virtual IP interface where >> packets of >> this Flow are being sent. The value matches the value of >> managed object 'ifIndex' as defined in RFC 2863. >> Note that ifIndex values are not assigned statically to an >> interface and that the interfaces may be renumbered every >> time the device's management system is re-initialized, as >> specified in RFC 2863. >> END >> >> >> #252 ingressPhysicalInterface >> >> OLD >> The index of a networking device's physical interface >> (example, a >> switch port) where packets of this flow are being received. >> NEW >> The index of a networking device's physical interface >> (example, a >> switch port) where packets of this flow are being received. >> The value matches the value of managed object 'ifIndex' as >> defined in RFC 2863. >> Note that ifIndex values are not assigned statically to an >> interface and that the interfaces may be renumbered every >> time the device's management system is re-initialized, as >> specified in RFC 2863. >> END >> >> >> #253 egressPhysicalInterface >> >> OLD >> The index of a networking device's physical interface >> (example, a >> switch port) where packets of this flow are being sent. >> NEW >> The index of a networking device's physical interface >> (example, a >> switch port) where packets of this flow are being sent. >> The value matches the value of managed object 'ifIndex' as >> defined in RFC 2863. >> Note that ifIndex values are not assigned statically to an >> interface and that the interfaces may be renumbered every >> time the device's management system is re-initialized, as >> specified in RFC 2863. >> END >> >> >> -------- Original Message -------- >> Subject: IPFIX export: SNMP versus physical Interface >> Date: Tue, 26 Jul 2011 13:30:17 +0100 >> From: Paul Aitken >> To: IETF IPFIX Working Group >> >> >> >> Dear IPFIXers, >> >> I noticed that the definitions of fields 10 and 14, and fields 252 and >> 253 are confusingly similar. See below. >> >> Cisco uses fields 10 and 14 to export the logical or virtual interface >> (eg. SVI, tunnel), while fields 252 and 253 export the actual physical >> interface. >> >> For example, if we have an SVI configured on a VLAN, the SNMP index of >> the SVI would be exported using fields 10 and 14, while the SNMP index >> of the physical port in that VLAN would be exported with fields 252 > and 253. >> >> So I propose to update fields 10 and 11 to say, "the index of the >> logical or virtual interface ...", to contrast with 252 and 253 which >> say, "The index of a networking device's physical interface ...". >> >> And I propose to add the following text (copied from 10 and 14) to 252 >> and 253, to clarify that these are also SNMP ifIndex values: >> >> The value matches the value of >> managed object 'ifIndex' as defined in RFC 2863. >> Note that ifIndex values are not assigned statically to an >> interface and that the interfaces may be renumbered every >> time the device's management system is re-initialized, as >> specified in RFC 2863. >> >> >> The existing definitions are below for reference. >> >> Please shout now if you disagree. >> >> Thanks, >> P. >> >> >> 10 ingressInterface unsigned32 identifier current >> >> The index of the IP interface where packets of this Flow >> are being received. The value matches the value of managed >> object 'ifIndex' as defined in RFC 2863. >> Note that ifIndex values are not assigned statically to an >> interface and that the interfaces may be renumbered every >> time the device's management system is re-initialized, as >> specified in RFC 2863. >> >> See [RFC2863] for the definition of the >> ifIndex object. >> >> >> 14 egressInterface unsigned32 identifier current >> >> The index of the IP interface where packets of >> this Flow are being sent. The value matches the value of >> managed object 'ifIndex' as defined in RFC 2863. >> Note that ifIndex values are not assigned statically to an >> interface and that the interfaces may be renumbered every >> time the device's management system is re-initialized, as >> specified in RFC 2863. >> >> See [RFC2863] for the definition of the >> ifIndex object. >> >> >> 252 ingressPhysicalInterface unsigned32 identifier current >> >> The index of a networking device's physical interface >> (example, a >> switch port) where packets of this flow are being received. >> >> See [RFC2863] for the definition of the ifIndex object. >> >> >> 253 egressPhysicalInterface unsigned32 identifier current >> >> The index of a networking device's physical interface >> (example, a >> switch port) where packets of this flow are being sent. >> >> See [RFC2863] for the definition of the ifIndex object. >> > > > -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand From muenz@net.in.tum.de Sun Jul 31 09:59:37 2011 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 5B13121F874B for ; Sun, 31 Jul 2011 09:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-eoTV93xq7A for ; Sun, 31 Jul 2011 09:59:37 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by ietfa.amsl.com (Postfix) with ESMTP id D308121F86EC for ; Sun, 31 Jul 2011 09:59:36 -0700 (PDT) Received: from [192.168.1.2] (e181055142.adsl.alicedsl.de [85.181.55.142]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 1B329201C8CD for ; Sun, 31 Jul 2011 19:01:58 +0200 (CEST) Message-ID: <4E3589E5.4060709@net.in.tum.de> Date: Sun, 31 Jul 2011 18:59:17 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <4E32A7EB.2080108@auckland.ac.nz> In-Reply-To: <4E32A7EB.2080108@auckland.ac.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] Qebec Meeting Minutes 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, 31 Jul 2011 16:59:37 -0000 Hi, > Juergen presented the PSAMP MIB. The IPFIX MIB (RFC 5815) was > intended to use a registry for ipfixSelectorFunctions, but instead > IANA created an IPFIX SELECTOR MIB, which would need to be changed > each time we add a new selector function. After some discussion, we > decided to stop maintaining the IPFIX SELECTOR MIB and create new OID > registry for ipfixSelectorFunctions. That will require changes to the > PSAMP MIB and to RFC 5815; since that requires AD approval, these will > be new WG work items. Note that this will be a blocker for the IPFIX config draft since it depends on RFC5815 and the upcoming PSAMP MIB RFC. If IPFIX-SELECTOR-MIB is abandoned, some explanatory text probably needs to be changed (in addition to references). Gerhard