From trammell@tik.ee.ethz.ch Wed Jan 6 02:57:49 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680143A686D for ; Wed, 6 Jan 2010 02:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4INNxoRdefoH for ; Wed, 6 Jan 2010 02:57:48 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 45AC73A6816 for ; Wed, 6 Jan 2010 02:57:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9258CD9362; Wed, 6 Jan 2010 11:57:44 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rysc+8C-VBso; Wed, 6 Jan 2010 11:57:44 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 466E1D9339; Wed, 6 Jan 2010 11:57:44 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <200912281822.nBSIMQ8n028844@boreas.isi.edu> Date: Wed, 6 Jan 2010 11:57:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <81A44FCB-613E-4A29-B42B-EC08F2BBCDCC@tik.ee.ethz.ch> References: <200912281822.nBSIMQ8n028844@boreas.isi.edu> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ah@TR-Sys.de, ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1984) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 10:57:49 -0000 Agreed, on first correction. On Dec 28, 2009, at 7:22 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D1984 >=20 > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes >=20 > Section: 5.8, pg.13 >=20 > Original Text > ------------- > Certain use cases for archival flow storage require the storage of > collection infrastructure details alongside the data itself. These > details include information about how and when data was received, = and > where it was received from. They are useful for auditing as well as > | for the replaying received data for testing purposes. >=20 >=20 >=20 > Corrected Text > -------------- > Certain use cases for archival flow storage require the storage of > collection infrastructure details alongside the data itself. These > details include information about how and when data was received, = and > where it was received from. They are useful for auditing as well as > | for replaying received data for testing purposes. >=20 >=20 >=20 > Notes > ----- > Alternative for last line: >=20 > | for the replay of received data for testing purposes. >=20 >=20 > Additional editorial remark (keep for update!): =20 > In Section 1.1, there's an unexpected blank line inserted into > the first paragraph on page 5. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Jan 6 02:58:02 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03DE3A6816 for ; Wed, 6 Jan 2010 02:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWw+YJ7tnRx7 for ; Wed, 6 Jan 2010 02:58:02 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id F150F3A67B0 for ; Wed, 6 Jan 2010 02:58:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 31D8AD9362; Wed, 6 Jan 2010 11:57:59 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Jn5w07D2WxQf; Wed, 6 Jan 2010 11:57:58 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id C1BD4D9339; Wed, 6 Jan 2010 11:57:58 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <200912281825.nBSIPBCa029622@boreas.isi.edu> Date: Wed, 6 Jan 2010 11:57:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8C8B567D-4737-4FE4-8542-6BE5AFF4A1FA@tik.ee.ethz.ch> References: <200912281825.nBSIPBCa029622@boreas.isi.edu> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ah@TR-Sys.de, ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1985) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 10:58:03 -0000 Agreed. On Dec 28, 2009, at 7:25 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D1985 >=20 > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes >=20 > Section: 7.1, pg.16 >=20 > Original Text > ------------- > ... third bullet, at the bottom of page 16: >=20 > o resolve any conflict between a resent definition and a previous > definition by assuming that the new Template replaces the old, as > | consistent with Template expiration and ID reuse when using UDP = at > the IPFIX transport protocol; and >=20 >=20 > Corrected Text > -------------- > o resolve any conflict between a resent definition and a previous > definition by assuming that the new Template replaces the old, as > | consistent with Template expiration and ID reuse when using UDP = as > the IPFIX transport protocol; and >=20 >=20 > Notes > ----- > Rationale: typo; s/at/as/ . >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Jan 6 02:58:15 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026473A6816 for ; Wed, 6 Jan 2010 02:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G89nNcTp6-YI for ; Wed, 6 Jan 2010 02:58:14 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 15CE03A68AA for ; Wed, 6 Jan 2010 02:58:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3F481D9395; Wed, 6 Jan 2010 11:58:11 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jcb-uMDD13b3; Wed, 6 Jan 2010 11:58:10 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id B3618D938C; Wed, 6 Jan 2010 11:58:10 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <200912281828.nBSISJNS000893@boreas.isi.edu> Date: Wed, 6 Jan 2010 11:58:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <24D42B51-D1F6-4DE7-8AF6-8FBADDEC0DDE@tik.ee.ethz.ch> References: <200912281828.nBSISJNS000893@boreas.isi.edu> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ah@TR-Sys.de, ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1986) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 10:58:15 -0000 Agreed. On Dec 28, 2009, at 7:28 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D1986 >=20 > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes >=20 > Section: 8.1.4, pg.26 >=20 > Original Text > ------------- > ... first paragraph: >=20 > [...]. This Options Template > | also allows the storage of the export session metadata provided the > Export Session Details Options Template, for storing information = from > multiple Transport Sessions in the same IPFIX File. >=20 >=20 > Corrected Text > -------------- > [...]. This Options Template > | also allows the storage of the export session metadata provided by > the Export Session Details Options Template, for storing information > from multiple Transport Sessions in the same IPFIX File. >=20 >=20 > Notes > ----- > Rationale: missing word, "by". >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Jan 6 02:58:30 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4126E3A68B2 for ; Wed, 6 Jan 2010 02:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSVMINWPqUsJ for ; Wed, 6 Jan 2010 02:58:29 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 5917F3A68B1 for ; Wed, 6 Jan 2010 02:58:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8ACFDD938C; Wed, 6 Jan 2010 11:58:26 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hNDpUTpxZbA5; Wed, 6 Jan 2010 11:58:26 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 47DA4D9339; Wed, 6 Jan 2010 11:58:26 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <200912281831.nBSIVN6Q002156@boreas.isi.edu> Date: Wed, 6 Jan 2010 11:58:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7F27213B-2F8F-42D2-B10E-C610E570F266@tik.ee.ethz.ch> References: <200912281831.nBSIVN6Q002156@boreas.isi.edu> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ah@TR-Sys.de, ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1987) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 10:58:30 -0000 Agreed. On Dec 28, 2009, at 7:31 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D1987 >=20 > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes >=20 > Section: 9, 1st para >=20 > Original Text > ------------- > In order to ensure the integrity of IPFIX Files and the identity of > IPFIX File Writers, File Writers and File Readers SHOULD provide for > an interoperable and easily implemented method for signing IPFIX > | Files, and verifying those signatures. This section specifies = method > | via CMS detached signatures. >=20 >=20 > Corrected Text > -------------- > In order to ensure the integrity of IPFIX Files and the identity of > IPFIX File Writers, File Writers and File Readers SHOULD provide for > an interoperable and easily implemented method for signing IPFIX > | Files, and verifying those signatures. This section specifies one > | such method via CMS detached signatures. >=20 >=20 > Notes > ----- > Rationale: missing word(s); suggest inserting "one such". >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Jan 6 02:58:56 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411263A6867 for ; Wed, 6 Jan 2010 02:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7yQsULXpjU2 for ; Wed, 6 Jan 2010 02:58:55 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 50F6F3A68AA for ; Wed, 6 Jan 2010 02:58:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8FF1CD9362; Wed, 6 Jan 2010 11:58:52 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pGCN-6JBeEJ9; Wed, 6 Jan 2010 11:58:52 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3542FD9339; Wed, 6 Jan 2010 11:58:52 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <200912281842.nBSIgkPq007587@boreas.isi.edu> Date: Wed, 6 Jan 2010 11:58:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <14894E1F-4645-4EBF-B6F3-1F18ECB1284F@tik.ee.ethz.ch> References: <200912281842.nBSIgkPq007587@boreas.isi.edu> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ah@TR-Sys.de, ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1989) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 10:58:56 -0000 No. Information content here refers to the amount of the record devoted = to information, as opposed to record structure. If there is a general = agreement that the wording here is confusing (on rereading, it isn't = IMO) and tends to lead to misunderstanding, then I would suggest fixing = by a complete reformulation of the sentence in question. On Dec 28, 2009, at 7:42 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D1989 >=20 > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes >=20 > Section: 10, pg. 39 >=20 > Original Text > ------------- > [...] > | IPFIX Templates tend to increase the information content per record > by not requiring the export of irrelevant or non-present fields in > records, and the technique described in [RFC5473] also reduces the > export of redundant information. [...] >=20 > Corrected Text > -------------- > [...] > | IPFIX Templates tend to decrease the information content per record > by not requiring the export of irrelevant or non-present fields in > records, and the technique described in [RFC5473] also reduces the > export of redundant information. [...] >=20 > Notes > ----- > Rationale: arguably s/increase/decrease/ . >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Wed Jan 6 04:09:40 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E3B3A67ED for ; Wed, 6 Jan 2010 04:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMw5BHDI5Bto for ; Wed, 6 Jan 2010 04:09:36 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id A97D83A67B7 for ; Wed, 6 Jan 2010 04:09:35 -0800 (PST) Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 5499637DB for ; Wed, 6 Jan 2010 13:09:28 +0100 (CET) Message-ID: <4B447DFB.2070208@net.in.tum.de> Date: Wed, 06 Jan 2010 13:11:39 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ipfix@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [IPFIX] [Fwd: Re: WGLC comments on draft-ietf-ipfix-configuration-model-04] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 12:09:40 -0000 Obviously, this mail did not make it to the ML. -------- Original Message -------- Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-configuration-model-04 Date: Mon, 04 Jan 2010 12:59:13 +0100 From: Gerhard Muenz To: Atsushi Kobayashi CC: ipfix@ietf.org References: <20091210164010.8C60.17391CF2@nttv6.net> Hi Atsushi, Thank you very much for you comments. Please find my answers inline. Regards, Gerhard Atsushi Kobayashi wrote: > Dear Gerhard, Benoit, and Paul, > > I would like to show the respect for your great effort for writing this > document. This document contains all of parameters and statistics with > regard to IPFIX and PSAMP specification. Thus, it needs hard review even > if except for section 6. > > I put my comments and questions in inline, please see it. > >> >> >> IP Flow Information Export WG G. Muenz >> Internet-Draft TU Muenchen >> Intended status: Standards Track B. Claise >> Expires: April 26, 2010 P. Aitken >> Cisco Systems, Inc. >> October 23, 2009 >> >> >> Configuration Data Model for IPFIX and PSAMP >> >> >> Status of this Memo >> >> This Internet-Draft is submitted to IETF in full conformance with the >> provisions of BCP 78 and BCP 79. This document may contain material >> from IETF Documents or IETF Contributions published or made publicly >> available before November 10, 2008. The person(s) controlling the >> copyright in some of this material may not have granted the IETF >> Trust the right to allow modifications of such material outside the >> IETF Standards Process. Without obtaining an adequate license from >> the person(s) controlling the copyright in such materials, this >> document may not be modified outside the IETF Standards Process, and >> derivative works of it may not be created outside the IETF Standards >> Process, except to format it for publication as an RFC or to >> translate it into languages other than English. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups. Note that >> other groups may also distribute working documents as Internet- >> Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> This Internet-Draft will expire on April 26, 2010. >> >> Copyright Notice >> >> Copyright (c) 2009 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents in effect on the date of >> publication of this document (http://trustee.ietf.org/license-info). >> Please review these documents carefully, as they describe your rights >> and restrictions with respect to this document. >> >> Abstract >> >> This document specifies a data model for the configuration of >> selection processes, caches, exporting processes, and collecting > > Why do you capitalize the first letter of above terms? Fixed. > >> processes of IPFIX and PSAMP compliant monitoring devices using UML >> (Unified Modeling Language) class diagrams. The configuration data >> is encoded in Extensible Markup Language (XML). The structure of the >> data model is specified in a YANG module to ensure compatibility with >> the NETCONF protocol. >> >> [snip] >> 1. Introduction >> >> IPFIX and PSAMP compliant Monitoring Devices (routers, switches, >> monitoring probes, Collectors etc.) offer various configuration >> possibilities that allow adapting network monitoring to the goals and >> purposes of the application, such as accounting and charging, traffic >> analysis, performance monitoring, security monitoring. The use of a >> common vendor-independent configuration data model for IPFIX and >> PSAMP compliant Monitoring Devices facilitates network management and >> configuration, especially if Monitoring Devices of different >> implementers and/or manufacturers are deployed simultaneously. On >> the one hand, a vendor-independent configuration data model helps >> storing and managing the configuration data of Monitoring Devices in >> a consistent format. On the other hand, it can be used for local and >> remote configuration of Monitoring Devices. However, this requires >> that Monitoring Devices natively support the configuration data >> model, or that a mapping between the configuration data model and the >> device-specific representation of configuration data is provided. >> > > I want to confirm the meaning of "mapping" in last sentence. > If a vender deploy the different configuration model at first, does it > need to replace them with the common configuration data? No. "Mapping between the configuration data model and device-specific configuration data" means that CDM parameters must correspond to device-specific parameters. If this is fulfilled, the CDM can be easily converted into the device-specific data (CLI, XML, or whatever) and vice versa. On the other hand, if the device-specific parameters have a very different meaning, a conversion is not possible (or at least difficult). Side note: The conversion can be realized at different places, for example: - in the management system - on the device by running an agent What shall we do with the last sentence "However,...."? Remove it? >> The purpose of this document is the specification of a vendor- >> independent configuration data model that covers the commonly >> available configuration parameters of Selection Processes, Caches, >> Exporting Processes, and Collecting Processes. The configuration >> data model is defined using UML (Unified Modeling Language) class >> diagrams [UML] while the actual configuration data is encoded in >> Extensible Markup Language (XML) [W3C.REC-xml-20040204]. An XML >> document conforming to the configuration data model contains the >> configuration data of one Monitoring Device. In order to ensure >> compatibility with the NETCONF protocol [RFC4741], YANG >> [I-D.ietf-netmod-yang] is used as the modeling language. If >> required, the YANG specification of the configuration data model can >> be converted into XML Schema language [W3C.REC-xmlschema-0-20041028] >> using the pyang tool [YANG-WEB]. YANG provides mechanisms to adapt >> the configuration data model to device-specific constraints and to >> augment the model with additional device-specific or vendor-specific >> parameters. >> >> For the configuration of remote Monitoring Devices, an appropriate >> protocol is needed to transfer the XML encoded configuration data. >> The configuration data model is compatible with the NETCONF protocol >> [RFC4741]. However, alternative protocols, such as the Simple Object >> Access Protocol (SOAP) [W3C.REC-soap12-part1-20070427], are also >> suitable for transferring XML data from a network management system >> to a Monitoring Device. >> [snip] >> 2. Terminology [snip] >> In addition to the existing IPFIX and PSAMP terminology, the >> following terms are defined: >> >> Cache: The Cache is a functional block in a Metering Process which >> maintains IPFIX Flow Records or PSAMP Packet Reports. According >> to [RFC5101], the maintenance of Flow Records may include creating >> new records, updating existing ones, computing Flow statistics, >> deriving further Flow properties, detecting Flow expiration, >> passing Flow Records to the Exporting Process, and deleting Flow >> Records. The maintenance of Packet Reports covers the same set of >> functions. > > In the case of PSAMP Packet Reports, how is the Cache used in Metering > Process? Is a PSAMP Packet Report maintained in Cache until deriving > further properties? It seems an implementation matter. The only difference between a PSAMP Packet Report and an IPFIX Flow Record is that the Packet Report always carries information about a single packet while the Flow Record may contain information about multiple packets. The CDM always includes a Cache as part of the Metering Process, even if Packet Reports are generated, because this is the place where the fields contained in the record are defined. The Cache Mode specifies the expiration policy and thus whether one or multiple packets are included in a record. Is there a need to clarify the definition of Cache? >> Cache Layout: The Cache Layout defines the superset of fields that >> are included in the Packet Reports or Flow Records maintained by >> the Cache. The fields are specified by the corresponding >> Information Elements. In general, the largest possible subset of >> the specified fields is derived for every Packet Report or Flow >> Record. More specific rules about which fields must be included >> are given in Section 4.3.1. >> >> Cache Mode: The Cache Mode specifies whether Packet Reports or Flow >> Records are generated by the Cache. In the case of Flow Records, >> it also specifies the Flow expiration policy. >> >> Monitoring Device: A Monitoring Device implements at least one of >> the functional blocks specified in the context of IPFIX or PSAMP. >> In particular, the term Monitoring Device encompasses Exporters, >> Collectors, IPFIX Devices, and PSAMP Devices. >> >> Selected Packet Stream: The Selected Packet Stream is the set of all >> packets selected by a Selection Process. >> >> >> 3. Structure of the Configuration Data Model >> >> The IPFIX reference model in [RFC5470] describes Metering Processes, >> Exporting Processes, and Collecting Processes as functional blocks of >> IPFIX Devices. The PSAMP framework [RFC5474] provides the >> corresponding information for PSAMP Devices and introduces Selection >> Processes as functional blocks within Metering Processes. In >> Section 2 of the document, the Cache is defined as another functional >> block within Metering Processes. Further explanations about the >> relationship between Selection Processes and Caches are given later >> on in this section. IPFIX File Reader and File Writer are defined as >> specific kinds of Exporting and Collecting Processes in >> [I-D.ietf-ipfix-file]. >> >> Monitoring Device implementations usually maintain the separation of >> various functional blocks although they do not necessarily implement >> all of them. Furthermore, they provide various configuration >> possibilities; some of them are specified as mandatory by the IPFIX >> protocol [RFC5101] or PSAMP protocol [RFC5476]. The configuration >> data model enables the setting of commonly available configuration >> parameters for Selection Processes, Caches, Exporting Processes, and >> Collecting Processes. In addition, it allows specifying the >> composition of functional blocks within a Monitoring Device >> configuration and their linkage with Observation Points. >> >> In a Monitoring Device implementation, the functionality of the >> Metering Process is commonly split into packet Sampling and Filtering >> functions performed by Selection Processes, and the maintenance of >> Flow Records and Packet Reports performed by Caches. Figure 1 >> illustrates this separation with the example of a basic Metering >> Process consisting of one Selection Process and one Cache. >> >> +-----------------------------------+ >> | Metering Process | >> | +-----------+ Selected | >> Observed | | Selection | Packet +-------+ | Stream of >> Packet -->| Process |---------->| Cache |--> Flow Records or >> Stream | +-----------+ Stream +-------+ | Packet Reports >> +-----------------------------------+ >> >> Figure 1: Selection Process and Cache forming a Metering Process >> >> The configuration data model adopts the separation of Selection >> Processes and Caches in order to support the flexible configuration >> and combination of these functional blocks. As defined in [RFC5476], >> the Selection Process takes the Observed Packet Stream as its input >> and selects a subset of that stream as its output (Selected Packet >> Stream). The action of the Selection Process on a single packet of >> its input is defined by a Primitive Selector or a Composite Selector. >> The Cache generates Flow Records or Packet Reports from the Selected >> Packet Stream, depending on the configured Cache Mode. >> >> The Observed Packet Stream at the input of a Selection Process MUST >> only contain packets originating from a single Observation Domain. >> Similarly, the Selected Packet Stream at the input of a Cache MUST >> only contain packets originating from a single Observation Domain. >> Packets from Observation Points belonging to different Observation >> Domains MUST NOT enter the same Selection Process or the same Cache. >> > > Observed packets at different Observation Domain can be input into different > Metering Process. Thus, they can not enter the same Metering Process. > I think that the above sentence is already clear in existing IPFIX > documents. Or it means other something? The whole paragraph will removed in the next version of the draft. We had a discussion about this issue in the context of IPFIX MIB. In fact, there is no IPFIX document which says that packets observed at different ODs must not enter the same MP. Therefore, we did not add any additional restriction on this in the IPFIX MIB, and we do not want to do this here, either. For clarification, I propose to add one sentence to the preceding paragraph: NEW: ... As defined in [RFC5476], the Selection Process takes the Observed Packet Stream as its input and selects a subset of that stream as its output (Selected Packet Stream). The Observed Packet Stream at the input of a Selection Process is composed of packets from a single Observation Point. ... Is this ok? >> Beyond the basic Metering Process shown in Figure 1, the >> configuration data model enables the specification of more complex >> configurations. A single Cache may process the output of multiple >> Selection Processes. The Selected Packet Stream may be copied to > > I cannot image that a single cache process the output from multiple Selection > Process. This sentence seems cause the inconsistency to the > definition of Observation Domain, when a Metering Process consisting of > a sequence of Selection Processes and Cahce. I do not understand your point. If there is any inconsistency, please explain it to me. > And I have another question. Are Selection Processes after Cahce > available as an IPFIX Mediation? No. This RFC will not cover IPFPIX Mediation. >> enter several Caches, for example one Cache that generates Flow >> Records and another Cache that generates Packet Reports. Selection >> Processes can also be cascaded, such that the Selected Packet Stream >> at the output of one Selection Process is passed to another Selection >> Process. Cascading Selection Processes can be useful in specific >> contexts such as the example in Section 7.3. >> >> The selection of parameters in the configuration data model is based >> on configuration issues discussed in the IPFIX and PSAMP documents >> [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475]. >> Furthermore, the structure and content of the IPFIX MIB module >> [I-D.ietf-ipfix-mib] and the PSAMP MIB module [I-D.ietf-psamp-mib] >> have been taken into consideration. Consistency between the >> configuration data model and the IPFIX and PSAMP MIB modules is an >> intended goal. Therefore, parameters in the configuration data model >> are named according to corresponding managed objects. Certain IPFIX >> MIB objects containing state data have been adopted as state >> parameters in the configuration data model. State parameters cannot >> be configured, yet their values can be queried from the Monitoring >> Device. > > They can be queried from other devices as well as Monitoring Device. I do not understand. Why shall a Monitoring Device query state information from another Monitoring Device? >> The next section explains how UML class diagrams are deployed to >> illustrate the structure of the configuration data model. >> Thereafter, Section 3.2 and Section 3.3 explain the class diagrams >> for the configuration of Exporters and Collectors, respectively. >> Each of the presented classes contains specific configuration >> parameters which are specified in Section 4. The formal definition >> of the configuration data model in YANG is given in Section 6. >> Section 7 illustrates the usage of the model with example >> configurations in XML. Section 5 gives a short introduction to YANG >> concepts that allow adapting the configuration data model to the >> capabilities of a device. >> >> 3.1. UML Representation >> >> We use UML class diagrams [UML] to explain the structure of the >> configuration data model. The attributes of the classes are the >> configuration or state parameters of the Monitoring Device. >> >> +------------------------------------------------+ >> | Destination | >> +------------------------------------------------+ >> | name |<>-----+ >> | exportMemberType = parallel | | 0..1 >> | ipfixVersion = 10 | | >> | transportProtocol | +------------+ >> | destinationIpAddress | | Transport- | >> | destinationPort = 4739|4740 | | Layer- | >> | sendBufferSize {opt.} | | Security | >> | rateLimit[0..1] | +------------+ >> | localIpAddress[0..*] {SCTP only} | >> | timedReliability = 0 {SCTP only} | >> | numberOfStreams {opt.} {SCTP only} | >> | sourceIpAddress[0..1] {UDP only} | >> | templateRefreshTimeout = 600 {UDP only} | >> | optionsTemplateRefreshTimeout = 600 {UDP only} | >> | templateRefreshPacket[0..1] {UDP only} | >> | optionsTemplateRefreshPacket[0..1] {UDP only} | >> +------------------------------------------------+ >> >> Figure 2: UML example: Destination class >> >> As an example, Figure 2 shows the UML diagram of the Destination >> class, which is specified in more detail in Section 4.4.1. The upper >> box contains the name of the class. The lower box lists the >> attributes of the class. The only parameters that MUST be configured >> by the user are name, transportProtocol, and destinationIpAddress. >> The remaining parameters have either defaults values, specific > ~~~~~~~~~~~~~~~ > default value? Fixed: The remaining parameters have either a default value, the "{opt.}" property, or a multiplicity indicator starting with zero. >> properties, or a multiplicity indicator starting with zero >> >> A default value is indicated after the attribute behind the equality >> symbol ("="). It means that this default value MUST be used by the >> Monitoring Device if the parameter is not configured by the user. In >> the example, IPFIX version 10 must be used if not configured >> differently. For destinationPort, two default values are indicated, >> namely the registered ports for IPFIX with and without transport >> layer security (i.e., DTLS or TLS), respectively. Note that such >> alternative default values cannot be formally specified in YANG. >> Instead, they are described in the "description" statement. >> >> An attribute with property "{opt.}", such as sendBufferSize in the >> Destination class, represents a parameter that MAY be configured by >> the user. Otherwise, the Monitoring Device will assign an >> appropriate value for this parameter. As a result, the parameter >> will always exist in the configuration data, yet it is not mandatory >> for the user to configure it. Note that this property cannot be >> formally specified in YANG. Instead, it is described in the >> "description" statement. >> >> The property "{SCTP only}" ("{UDP only}") means that the >> corresponding parameters are only available if the transport protocol >> is SCTP (UDP). In YANG, this is formalized in a "when" statement. >> >> Another property not shown in the example is "{readOnly}" specifying >> state parameters which cannot be configured by the user. >> >> An attribute with a multiplicity indicator of "[0..1]" represents an >> OPTIONAL configuration parameter. The parameter is not included in >> the configuration data unless the user configures it. Typically, the >> absence of the parameter has a specific meaning. For example, not >> configuring rateLimit in the Destination class means that no rate >> limiting will be applied to the exported data. >> >> A multiplicity indicator of "[0..*]" means that this parameter MAY be >> configured multiple times with different values. In the example, >> multiple local IP addresses may be configured if SCTP is transport >> protocol. Note that attributes without this multiplicity indicator >> MUST NOT appear more than once in each object of the class. >> [snip] >> 3.2. Exporter Configuration >> >> Figure 4 below shows the main classes of the configuration data model >> which are involved in the configuration of an IPFIX or PSAMP >> Exporter. The role of the classes can be briefly summarized as >> follows: >> >> o The ObservationPoint class specifies an Observation Point (i.e., >> an interface or linecard) of the Monitoring Device at which >> packets are captured for traffic measurements. An object of the >> ObservationPoint class may be associated with one or more objects >> of the SelectionProcess class configuring Selection Processes that >> process the observed packets in parallel. As long as an >> ObservationPoint object is specified without any references to >> SelectionProcess objects, the Observation Point is not deployed >> for traffic measurements. >> >> o The SelectionProcess class contains the configuration parameters >> of a Selection Process. The Selection Process may be composed of >> a single Selector or a sequence of Selectors, defining a Primitive >> or Composite Selector, respectively. >> >> The Selection Process selects packets from an Observed Packet >> Stream originating from one or multiple Observation Points. >> Therefore, a SelectionProcess object MAY be referred to from >> multiple ObservationPoint objects. The corresponding Observation >> Points must belong to the same Observation Domain. > > The Selection Process after Cache handles the Flow Records or Packet > Reports, not packets. All Selection Process are located in front of a Cache, not behind. > >> A Selection Process MAY pass the Selected Packet Stream to one or >> multiple Caches. Therefore, the SelectionProcess class enables >> references to objects of the Cache class. >> >> It is possible to cascade different Selection Processes. In this >> case, the Selected Packet Stream at the output of one or multiple >> Selection Processes is passed to the input of another Selection >> Process. Therefore, a SelectionProcess object MAY be referred to >> from multiple SelectionProcess objects. For the same reason, one >> SelectionProcess object may refer to other objects of the same >> class. When cascading multiple Selection Processes, it must be >> ensured that all packets entering a Selection Process have been >> observed at Observation Points belonging to the same Observation >> Domain. A configuration example is given later in Section 7.3. >> >> If a Selection Process is configured without any reference to >> Selection Processes or Caches that receive the selected packets, >> the selected packets are not accounted in any Packet Report or >> Flow Record. NEW: o The SelectionProcess class contains the configuration parameters of a Selection Process. The Selection Process may be composed of a single Selector or a sequence of Selectors, defining a Primitive or Composite Selector, respectively. The Selection Process selects packets from an Observed Packet Stream originating from an Observation Point. Therefore, a SelectionProcess object MAY be referred to from a single ObservationPoint object. It is possible to cascade different Selection Processes. In this case, the Selected Packet Stream at the output of a Selection Process is passed to the input of another Selection Process. Therefore, one SelectionProcess object may refer to other objects of the same class. A configuration example is given below in Section 7.3. A Selection Process MAY pass the Selected Packet Stream to one or multiple Caches. Therefore, the SelectionProcess class enables references to objects of the Cache class. If a Selection Process is configured without any reference to Selection Processes or Caches that receive the selected packets, the selected packets are not accounted in any Packet Report or Flow Record. >> >> o The Cache class contains configuration parameters of a Cache. A >> Cache may receive the output of one or more Selection Processes >> and maintains corresponding Packet Reports or Flow Records. >> Therefore, an object of the Cache class MAY be referred to from >> multiple SelectionProcess objects. However, the configuration >> MUST ensure that all packets entering the Selection Process have > ^^^^^^^^^^^^^^^^^ > Cache? > >> been observed at Observation Points belonging to the same >> Observation Domain. This whole sentence will be removed. >> >> Configuration parameters of the Cache class specify the size of >> the Cache, the Cache Mode and Layout, and expiration parameters. >> The Cache Mode determines if Packet Reports or Flow Records are >> generated. >> >> A Cache MAY pass its output to one or multiple Exporting Process. >> Therefore, the Cache class enables references to one or multiple >> objects of the ExportingProcess class. If a Cache object does not >> specify any reference to an ExportingProcess object, the Cache >> output is dropped. >> >> o The ExportingProcess class contains configuration parameters of an >> Exporting Process. It includes various transport protocol >> specific parameters and the export destinations. An object of the >> ExportingProcess class MAY be referred to from multiple objects of >> the Cache class. >> >> An Exporting Process MAY be configured as a File Writer according >> to [I-D.ietf-ipfix-file]. >> >> +------------------+ >> | ObservationPoint | >> +------------------+ >> 0..* | >> | >> 0..* V >> +------------------+ >> | SelectionProcess | >> +------------------+<-+ >> 0..* | 0..* | | 0..* >> | +---+ >> 0..* V >> +------------------+ >> | Cache | >> +------------------+ >> 0..* | >> | >> 0..* V >> +------------------+ >> | ExportingProcess | >> +------------------+ NEW: +------------------+ | ObservationPoint | +------------------+ 0..1 | | 0..* V +------------------+ | SelectionProcess | +------------------+<-+ 0..* | 0..1 | | 0..* | +---+ 0..* V +------------------+ | Cache | +------------------+ 0..* | | 0..* V +------------------+ | ExportingProcess | +------------------+ >> >> Figure 4: Class diagram of Exporter configuration >> [snip] >> 4.1. ObservationPoint Class >> >> +-------------------------------+ >> | ObservationPoint | >> +-------------------------------+ 1 +--------------------+ >> | name |<>----------| Interface/Linecard | >> | observationPointId {readOnly} | +--------------------+ >> | observationDomainId | >> | | 0..* 0..* +--------------------+ >> | |----------->| SelectionProcess | >> +-------------------------------+ +--------------------+ >> >> +------------------+ +----------------------------------+ >> | Interface | | Linecard | >> +------------------+ +----------------------------------+ >> | ifIndex/ifName | | entPhysicalIndex/entPhysicalName | >> | direction = both | | direction = both | >> +------------------+ +----------------------------------+ >> >> Figure 6: ObservationPoint class >> >> Figure 6 shows the ObservationPoint class that identifies an >> Observation Point of the Monitoring Device. The Observation Point >> can either be an interface or a linecard. >> >> An object of the ObservationPoint class MUST specify the ID of the >> Observation Domain the Observation Point belongs to. Observation >> Points that are configured with the same Observation Domain ID belong >> to the same Observation Domain. >> >> The Observation Point ID (i.e., the value of the Information Element >> observationPointId [RFC5102]) is assigned by the Monitoring Device. >> It appears as a state parameter in the ObservationPoint class. >> >> The configuration parameters to identify an interface or a linecard >> are as follows: >> >> ifIndex/ifName (interface only): Either the index or name of the >> interface MUST be specified according to corresponding objects in >> the IF-MIB [RFC2863]. >> >> entPhysicalIndex/entPhysicalName (linecard only): Either the index >> or name of the linecard MUST be specified according to >> corresponding objects in the ENTITY-MIB [RFC4133]. >> >> direction: This parameter specifies if ingress traffic, egress >> traffic, or both ingress and egress traffic is captured, using the >> values "ingress", "egress", and "both", respectively. If not >> configured, ingress and egress traffic is captured (i.e., the >> default value is "both"). If not applicable (e.g., in the case of >> a sniffing interface in promiscuous mode), the value of this >> parameter is ignored. > > I have one question. > In the case of a single ifIndex belonging to multiple Observation > Domains, can this Interface class be referred by multiple > ObservationPoint classes? With respect to the CDM, there is no restriction. Multiple ObservationPoint objects belonging to different Observation Domain IDs can have the same IfIndex value. >> An ObservationPoint object MAY refer to one or multiple >> SelectionProcess objects configuring Selection Processes that process >> the observed packets in parallel. >> >> 4.2. SelectionProcess Class >> >> +--------------------------------+ >> | SelectionProcess | >> +--------------------------------+ 1..* +----------+ >> | name |<>----------| Selector | >> | selectionSequenceId {readOnly} | +----------+ >> | | 0..* >> | |<---+ >> | | | >> | |----+ >> | | 0..* >> | | >> | | 0..* 0..* +----------+ >> | |----------->| Cache | >> +--------------------------------+ +----------+ >> >> Figure 7: SelectionProcess class >> >> Figure 7 shows the SelectionProcess class. The SelectionProcess >> class contains the configuration parameters of a Selection Process >> which selects packets from the Observed Packet Stream at its input >> and outputs the Selected Packet Stream to one or multiple other >> Selection Processes or Caches. A non-empty ordered list defines a >> sequence of Selectors. The actions defined by the Selectors are >> applied to the stream of incoming packet in the specified order. >> >> The state parameter selectionSequenceId contains the Selection >> Sequence ID (i.e., the value of the Information Element >> selectionSequenceId [RFC5477]) which is assigned by the Monitoring >> Device. The Selection Sequence ID MUST be unique within the >> Observation Domain as required by [RFC5477]. >> >> The output of one Selection Process MAY be processed by other >> Selection Processes. Therefore, the SelectionProcess class allows >> references to itself, meaning that one SelectionProcess object MAY >> refer to other SelectionProcess objects. >> >> A SelectionProcess object MAY include references to one or more >> objects of the Cache class configuring Caches that receive the >> Selected Packet Stream and generate corresponding Packet Reports or >> Flow Records. > > If SelectionProcess class embodies the function of Metering Process, I > prefer the name of MeteringProcess class instead of SelectionProcess > from the consistency with IPFIX-MIB. I do not understand. SelectonProcess class corresponds to ipfixSelectionProcessTable in the IPFIX-MIB. > > >> 4.2.1. Selector Class >> >> +--------------------------------------+ >> | Selector | >> +--------------------------------------+ 1 +-----------------+ >> | name |<>------+ SelectAll/ | >> | selectorId {readOnly} | | SampCountBased/ | >> | packetsObserved {readOnly} | | SampTimeBased/ | >> | packetsDropped {readOnly} | | SampRandOutOfN/ | >> | selectorDiscontinuityTime {readOnly} | | SampUniProb/ | >> | | | FilterMatch/ | >> | | | FilterHash/ | >> +--------------------------------------+ +-----------------+ >> >> Figure 8: Selector class >> >> The Selector class in Figure 8 contains the configuration and state >> parameters of a Selector. Standardized PSAMP Sampling and Filtering >> methods are described in [RFC5475]; their configuration parameters >> are specified in corresponding sampler (SampCountBased, >> SampTimeBased, SampRandOutOfN, SampUniProb) or filter (FilterMatch, >> FilterHash) classes. In addition, the SelectAll class, which has no >> parameters, is used for a Selector that selects all packets. The >> Selector class includes exactly one of these sampler and filter >> classes, depending on the applied method. >> >> The state parameter selectorId contains the Selector ID (i.e., the >> value of the Information Element selectorId [RFC5477]) assigned by >> the Monitoring Device. The Selector ID MUST be unique within the >> Observation Domain as required by [RFC5477]. >> >> As state parameters, the Selector class contains the Selector >> statistics packetsObserved and packetsDropped that correspond to the >> objects of the ipfixSelectorStatsTable in the IPFIX MIB module >> [I-D.ietf-ipfix-mib]. >> [snip] >> 4.2.3. Filter Classes >> >> +--------------------------+ >> | FilterMatch | >> +--------------------------+ >> | ieId/ieName | >> | ieEnterpriseNumber[0..1] | >> | value | >> +--------------------------+ >> >> +--------------------------+ >> | FilterHash | >> +--------------------------+ 1..* +---------------+ >> | hashFunction = BOB |<>-------| SelectedRange | >> | ipPayloadOffset = 0 | +---------------+ >> | ipPayloadSize = 8 | | name | >> | digestOutput = false | | min | >> | initialiserValue[0..1] | | max | >> +--------------------------+ +---------------+ >> >> Figure 10: Filter classes >> >> The Filter classes in Figure 10 contain the configuration parameters >> of specific Filtering methods. For property match filtering, the >> configuration parameters are: >> >> ieId, ieName, ieEnterpriseNumber: The property to be matched is >> specified by either ieId or ieName, specifying the ID or name of >> the Information Element, respectively. ieEnterpriseNumber MUST be >> used for enterprise-specific Information Elements. If >> ieEnterpriseNumber is omitted or zero, this is Information Element >> is not enterprise-specific but registered at IANA. >> >> value: Matching value. >> > > Can the ranges of value be defined like hash value? No. The reason is that min/max fields are not specified in the Selector Report Interpretation: http://tools.ietf.org/html/rfc5476#section-6.5.2.5 In the case of FilterHash, we do min/max fields in the Selector Report Interpretation: http://tools.ietf.org/html/rfc5476#section-6.5.2.6 > And, I would like to specify its instruction, "match" or "unmatch". This is not specified in the Selector Report Interpretation. Therefore, we cannot allow configuring this. >> For hash-based filtering, the configuration parameters are: >> >> hashFunction: Hash function to be used. The following parameter >> values are defined by the configuration data model: >> * BOB: BOB Hash Function as specified in [RFC5475], Appendix A.2 >> * IPSX: IP Shift-XOR (IPSX) Hash Function as specified in >> [RFC5475], Appendix A.1 >> * CRC: CRC-32 function as specified in [RFC1141] >> Default value is "BOB". >> >> ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSize >> configure the offset and the size of the payload section used as >> input to the hash function. Default values are 0 and 8, >> respectively, corresponding to the minimum configurable values >> according to [RFC5476], Section 6.2.5.6. These parameters >> correspond to the Information Elements hashIPPayloadOffset and >> hashIPPayloadSize [RFC5477]. >> >> digestOutput: digestOutput enables or disables the inclusion of the >> packet digest in the resulting PSAMP Packet Report. This requires >> that the Cache Layout of the Cache generating the Packet Reports >> includes a digestHashValue field. This parameter corresponds to >> the Information Element hashDigestOutput [RFC5477]. >> >> initialiserValue: Initializer value to the hash function. This >> parameter corresponds to the Information Element >> hashInitialiserValue [RFC5477]. If not configured by the user, >> the monitoring device arbitrarily chooses an initializer value. >> >> One or more ranges of matching hash values are defined by the min and >> max parameters of the SelectedRange subclass. These parameters >> correspond to the Information Elements hashSelectedRangeMin and >> hashSelectedRangeMax [RFC5477]. >> >> 4.3. Cache Class >> >> +-----------------------------------+ >> | Cache | >> +-----------------------------------+ 1 +-------------+ >> | name |<>----------| CacheLayout | >> | cacheMode | +-------------+ >> | maxRecords {opt.} | >> | activeTimeout {opt.} | 0..* 0..* +------------------+ >> | {except Cache Mode "immediate"} |----------->| ExportingProcess | >> | inactiveTimeout {opt.} | +------------------+ >> | {Cache Mode "timeout" only} | >> | activeFlows {readOnly} | >> | inactiveFlows {readOnly} | >> | cacheDataRecords {readOnly} | >> | cacheDiscontinuityTime {readOnly} | >> +-----------------------------------+ >> >> Figure 11: Cache class >> >> Figure 11 shows the Cache class that contains the configuration and >> state parameters of a Cache. The configuration parameters of the >> Cache class are as follows: >> >> cacheMode: Configures the Cache Mode. The following parameter >> values are specified by the configuration data model: >> * immediate: Data Records expire after the first packet >> * timeout: Data Records expire after active or inactive timeout >> * permanent: Data Records never expire, but are periodically >> exported with interval set by the active timeout >> In the case of "immediate", PSAMP Packet Reports are generated. >> Otherwise, IPFIX Flow Records are generated. >> >> maxRecords: Maximum number of Data Records in the Cache. If not >> configured by the user, the Monitoring Device sets this parameter. >> > > When a cache becomes max Records, new Flow Records can be dropped or > push the old one? Does it depend on the implementation matter? There are various possibilities, such as dropping or early expiration of Flows. I do not think that we need to specify the behavior. >> activeTimeout: This parameter configures the active timeout in >> milliseconds. It is not available for Cache Mode "immediate". >> The parameter value zero indicates infinity, meaning that there is >> no active timeout. If not configured by the user, the Monitoring >> Device sets this parameter. >> In the case of Cache Mode "timeout", the active timeout defines >> the time after which a Flow Record is expired even though packets >> matching this Flow are still received by the Cache. In the case >> of Cache Mode "permanent", the active timeout defines the interval >> for periodical export of Flow Records. > > In the case of Cache Mode "timeout", the timer for active timeout is set > per a Flow Record. In the case of Cache Mode "permanent", the timer > for active timeout is set per a Cache. > > If it is right, each meaning "active timeout" are different. Could you please > add some explanation. > >> inactiveTimeout: This parameter configures the inactive timeout in >> milliseconds. It is not available for Cache Modes "immediate" and >> "permanent". The parameter value zero indicates infinity, meaning >> that there is no inactive timeout. If not configured by the user, >> the Monitoring Device sets this parameter. >> The inactive timeout defines the time after which a Flow Record is >> expired if no packets matching this Flow are received by the >> Cache. NEW: activeTimeout: This parameter configures the time in milliseconds after which a Flow Record is expired even though packets matching this Flow are still received by the Cache. The parameter value zero indicates infinity, meaning that there is no active timeout. If not configured by the user, the Monitoring Device sets this parameter. This parameter is only available for Cache Mode "timeout". inactiveTimeout: This parameter configures the time in milliseconds after which a Flow Record is expired if no packets matching this Flow are received by the Cache. The parameter value zero indicates infinity, meaning that there is no inactive timeout. If not configured by the user, the Monitoring Device sets this parameter. This parameter is only available for Cache Mode "timeout". exportInterval: This parameter configures the interval for periodical export of Flow Records in milliseconds. If not configured by the user, the Monitoring Device sets this parameter. It is only available for Cache Mode "permanent". >> >> An object of the Cache class includes an object of the CacheLayout >> class that defines which fields are included in the Packet Reports or >> Flow Records. A Cache object MAY refer to one or multiple >> ExportingProcess objects configuring different Exporting Processes. >> >> As state parameters, the Cache class contains the Metering Process >> statistics activeFlows, inactiveFlows, and cacheDataRecords that >> correspond to the objects of the ipfixMeteringProcessStatsTable of >> the IPFIX MIB module [I-D.ietf-ipfix-mib]. >> [snip] >> 4.4.1. Destination Class >> >> +------------------------------------------------+ >> | Destination | >> +------------------------------------------------+ >> | name |<>-----+ >> | exportMemberType = parallel | | 0..1 >> | ipfixVersion = 10 | | >> | transportProtocol | +------------+ >> | destinationIpAddress | | Transport- | >> | destinationPort = 4739|4740 | | Layer- | >> | sendBufferSize {opt.} | | Security | >> | rateLimit[0..1] | +------------+ >> | localIpAddress[0..*] {SCTP only} | >> | timedReliability = 0 {SCTP only} | >> | numberOfStreams {opt.} {SCTP only} | >> | sourceIpAddress[0..1] {UDP only} | >> | templateRefreshTimeout = 600 {UDP only} | >> | optionsTemplateRefreshTimeout = 600 {UDP only} | >> | templateRefreshPacket[0..1] {UDP only} | >> | optionsTemplateRefreshPacket[0..1] {UDP only} | >> +------------------------------------------------+ >> >> Figure 14: Destination class >> >> The Destination class shown in Figure 14 contains the configuration >> parameters of one export destination (i.e., Collector) the Exporting >> Process sends IPFIX Messages to. Some of the parameters are only >> applicable if a specific transport protocol (SCTP, UDP, or TCP) is >> used. The following parameters apply to all transport protocols: >> >> exportMemberType: Configures the export member type that corresponds >> to the ipfixTransportSessionGroupMemberType object in >> [I-D.ietf-ipfix-mib]. The following parameter values are >> specified by the configuration data model: >> * primary: primary target of the Exporting Process >> * secondary: secondary target of the Exporting Process used when >> the primary target is not reachable >> * parallel: parallel exporting to all destinations and files of >> the Exporting Process >> * loadBalancing: load-balancing between different destinations >> and files of the Exporting Process >> "parallel" is the default value if this parameter is not >> configured. If one destination or file is configured as "primary" >> target, all other destinations and files must be configured as >> "secondary" targets. If "parallel" or "loadBalancing" is used, >> the same type must be configured for all destinations and File >> Writers of the Exporting Process. >> >> ipfixVersion: Version number of the IPFIX protocol used. If >> omitted, the default value is 10 (=0x000a) as specified in >> [RFC5101]. >> >> transportProtocol: One of "sctp", "udp", and "tcp". >> >> destinationIpAddress, destinationPort: Destination IP address and >> destination port number to be used. destinationIpAddress is a >> mandatory parameter. If destinationPort is omitted, standard port >> 4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS) >> is used. >> >> sendBufferSize: Size of the socket send buffer in bytes. >> >> rateLimit: Maximum number of bytes per second the Exporting Process >> may export to the given destination as required by [RFC5476]. The >> number of bytes is calculated from the lengths of the IPFIX >> Messages exported. If this parameter is not configured, no rate >> limiting is performed for this destination. >> >> The following parameters are applicable if SCTP is transport >> protocol: >> >> localIpAddress: This optional parameter MAY appear multiple times to >> specify the list of eligible local IP addresses of the SCTP >> association [RFC4960]. If omitted, all locally assigned IP >> addresses are used by the SCTP endpoint. >> >> timedReliability: Lifetime in milliseconds until an IPFIX Message >> containing Data Sets only is "abandoned" due to the timed >> reliability mechanism of PR-SCTP [RFC3758]. If this parameter is >> set to zero, reliable SCTP transport is used. >> >> numberOfStreams: Number of outbound streams requested for SCTP >> associations [RFC4960]. If not configured by the user, this >> parameter is set by the Monitoring Device. >> >> The following parameters are applicable if UDP is transport protocol: >> >> sourceIpAddress: This parameter sets the source IP address. If this >> parameter is omitted, the address assigned to the outgoing >> interface is used. >> > I would like to make available in the case of TCP. We adopted this parameter because the Cisco CLI has it for UDP. As far as I understand, it is not used to specify the outgoing interface but the (forged) source address in the IP header only. How do you want to forge the IP address of a TCP endpoint? It must belong to the interface. The parameter description remains unclear in the case of multiple addresses assigned to a single interface. I'm not sure what to do. We can remove the parameter. We can change to "...one of the addresses assigned to the outgoing interface is used." We can try to find a generic solution that defines the outgoing interface. >> templateRefreshTimeout, optionsTemplateRefreshTimeout, >> templateRefreshPacket, optionsTemplateRefreshPacket: Template >> refresh parameters when using UDP as transport protocol. >> templateRefreshTimeout and optionsTemplateRefreshTimeout are >> specified in seconds between resendings of (Options) Templates. >> If omitted, the default value of 600 seconds (10 minutes) is used >> [RFC5101]. templateRefreshPacket and optionsTemplateRefreshPacket >> are specified in number of IPFIX Messages. If omitted, the >> (Options) Templates are only resent after timeout. >> >> Using the TransportLayerSecurity class, transport layer security is >> enabled and configured for this export destination. If the transport >> protocol is SCTP or UDP, transport layer security is realized using >> DTLS. In the case of TCP, TLS is used instead. >> [snip] >> 4.7. Transport Session Class >> >> +------------------------------------------------------+ >> | TransportSession | >> +------------------------------------------------------+ >> | exportMemberType {readOnly} {Exporting Process only} |<>----+ 0..* >> | ipfixVersion {readOnly} | | >> | protocol {readOnly} {except File Reader/Writer} | +----------+ >> | sourceAddress {readOnly} {except File Reader/Writer} | | Template | >> | destinationAddress {readOnly} | +----------+ >> | {except File Reader/Writer} | >> | sourcePort {readOnly} {except File Reader/Writer} | >> | destinationPort {readOnly} | >> | {except File Reader/Writer} | >> | sctpAssocId {readOnly} {SCTP only} | >> | file {readOnly} {File Reader/Writer only} | >> | templateRefreshTimeout {readOnly} {UDP only} | >> | optionsTemplateRefreshTimeout {readOnly} {UDP only} | >> | templateRefreshPacket {readOnly} {UDP only} | >> | optionsTemplateRefreshPacket {readOnly} {UDP only} | >> | status {readOnly} | >> | rate {readOnly} | >> | packets {readOnly} | >> | bytes {readOnly} | >> | messages {readOnly} | >> | discardedMessages {readOnly} | >> | records {readOnly} | >> | templates {readOnly} | >> | optionsTemplates {readOnly} | >> | transportSessionDiscontinuityTime {readOnly} | >> +------------------------------------------------------+ >> >> Figure 21: TransportSession class >> >> The TransportSession class contains state data about Transport >> Sessions originating from an Exporting Process or terminating at a >> Collecting Process. The names and semantics of the state parameters >> correspond to the managed objects in the ipfixTransportSessionTable >> and ipfixTransportSessionStatsTable of the IPFIX MIB module >> [I-D.ietf-ipfix-mib]. Hence, if these state parameters are queried >> from the Monitoring Device, the corresponding IPFIX MIB values can be > > They can be queried from other management device. I do not understand. Are you confusing "queried from" with "queried by"? >> returned without any further processing. The MIB object >> ipfixTransportSessionDeviceMode is not included in the >> TransportSession class because its value can be derived from the >> scope in which a TransportSession object appears: exporting(1) if it >> belongs to an Exporting Process, collecting(2) if it belongs to a >> Collecting Process. >> >> The state parameter exportMemberType is only available if the >> TransportSession class is used within the ExportingProcess class. >> exportMemberType then contains the value of the MIB object >> ipfixExportMemberType of the ipfixExportTable of the IPFIX MIB >> [I-D.ietf-ipfix-mib]. >> > > The Destination already has exportMemberType. What is relation between > two object between the object in Destination class and one in this class? This is state data of a Transport Session, the other is configuration data of an Exporting Process. >> The TransportSession class is also used for state data of File >> Readers and File Writers. In this case, the "file" parameter >> specifies the name and location of the file as URI. To avoid >> ambiguities, the parameters "protocol", "sourceAddress", >> "destinationAddress", "sourcePort", "destinationPort", and >> "sctpAssocId" MUST NOT appear if the parameter "file" is present. >> The parameter "file" MUST NOT appear if at least one of the >> parameters "protocol", "sourceAddress", "destinationAddress", >> "sourcePort", "destinationPort", and "sctpAssocId" is present. Note >> that the parameter "file" is currently not included in the IPFIX MIB. >> > > The above paragraph can be removed. Because you already have File > Reader and Writer class. No. All these state parameters may be interesting for File Writers/Readers: | status {readOnly} | | rate {readOnly} | | packets {readOnly} | | bytes {readOnly} | | messages {readOnly} | | discardedMessages {readOnly} | | records {readOnly} | | templates {readOnly} | | optionsTemplates {readOnly} | | transportSessionDiscontinuityTime {readOnly} | Therefore, we have a Transport Session entry for File Readers/Writers. >> 4.7.1. Template Class >> >> +--------------------------------------+ >> | Template | >> +--------------------------------------+ >> | observationDomainId {readOnly} |<>---+ 0..* >> | templateId {readOnly} | | >> | setId {readOnly} | | >> | accessTime {readOnly} | | >> | templateDataRecords {readOnly} | | >> | templateDiscontinuityTime {readOnly} | | >> +--------------------------------------+ | >> | >> +-------------------------------+ >> | Field | >> +-------------------------------+ >> | ieId {readOnly} | >> | ieLength {readOnly} | >> | ieEnterpriseNumber {readOnly} | >> | flags {readOnly} | >> +-------------------------------+ >> >> Figure 22: Template class >> >> The Template class contains state data about Templates used by an >> Exporting Process or received by a Collecting Process in a specific >> Transport Session. The Field class defines one field of the >> Template. The names and semantics of the state parameters correspond >> to the managed objects in the ipfixTemplateTable, >> ipfixTemplateDefinitionTable, and ipfixTemplateStatsTable of the >> IPFIX MIB module [I-D.ietf-ipfix-mib]. Hence, if these state >> parameters are queried from the Monitoring Device, the corresponding >> IPFIX MIB values can be returned without any further processing. >> >> >> 5. Adaptation to Device Capabilities >> >> The configuration data model standardizes a superset of common IPFIX >> and PSAMP configuration parameters. A typical Monitoring Device >> implementation will not support the entire range of possible >> configurations. Certain functions may not be supported, such as the >> Collecting Process that does not exist on a Monitoring Device >> conceived as Exporter only. The configuration of other functions may >> be subject to resource limitations. For example, the Cache size is >> typically limited according to the available memory on the device. >> >> YANG [I-D.ietf-netmod-yang] offers several possibilities to restrict >> and adapt a configuration data model. The current version of YANG >> defines the concepts of "features" and "deviations". >> >> The feature concept allows the modeler to make proportions of the >> model conditional in a manner that is controlled by the device. >> Devices do not have to support these conditional parts to conform to >> the model. Those features that are supported by a device must be >> announced in the message of the NETCONF protocol [RFC4741]. >> >> The configuration data model for IPFIX and PSAMP covers the >> configuration of Exporters, Collectors, and devices that may act as >> both. As Exporters and Collectors implement different functions, the >> corresponding proportions of the model are conditional on the >> following features: >> >> exporter: If this feature is supported, Exporting Processes can be >> configured. >> >> collector: If this feature is supported, Collecting Processes can be >> configured. >> >> Exporters do not necessarily implement any Selection Processes, >> Caches, or even Observation Points in particular cases. Therefore, >> the corresponding proportions of the model are conditional on the >> following feature: >> >> meter: If this feature is supported, Observation Points, Selection >> Processes, and Caches can be configured. >> >> Additional features refer to different PSAMP Sampling and Filtering >> methods: >> >> psampSampCountBased: If this feature is supported, Sampling method >> sampCountBased can be configured. >> >> psampSampTimeBased: If this feature is supported, Sampling method >> sampTimeBased can be configured. >> >> psampSampRandOutOfN: If this feature is supported, Sampling method >> sampRandOutOfN can be configured. >> >> psampSampUniProb: If this feature is supported, Sampling method >> sampUniProb can be configured. >> >> psampFilterMatch: If this feature is supported, Filtering method >> filterMatch can be configured. >> >> psampFilterHash: If this feature is supported, Filtering method >> filterHash can be configured. >> >> The following features concern the support of UDP and TCP as >> transport protocols and the support of File Readers and File Writers: >> >> udpTransport: If this feature is supported, UDP can be used as >> transport protocol by Exporting Processes and Collecting >> Processes. >> >> tcpTransport: If this feature is supported, TCP can be used as >> transport protocol by Exporting Processes and Collecting >> Processes. >> >> fileReader: If this feature is supported, Collecting Processes can >> be configured as File Readers. >> >> fileReader: If this feature is supported, Exporting Processes can be > ^^^^^^^^^^ fileWriter? Fixed. > >> configured as File Writers. >> >> The deviation concept enables a device to announce deviations from >> the standard model. Deviations are typically used to specify >> limitations due to resource constraints. Deviations concern existing >> parameters of the standard model and must not be confused with model >> extensions that are realized with the YANG statement "augment". Just >> like features, deviations are announced in NETCONF's message. >> A usage example of deviations is given in Section 7.5. >> >> > > Regards, > Atsushi -- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Technische Universität München - Department of Informatics Boltzmannstr. 3, 85748 Garching bei München, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz -- Dipl.-Ing. Gerhard Münz Chair for Network Architectures and Services (I8) Technische Universität München - Department of Informatics Boltzmannstr. 3, 85748 Garching bei München, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz From trammell@tik.ee.ethz.ch Wed Jan 6 04:24:40 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A732B3A687C for ; Wed, 6 Jan 2010 04:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiJidLUwXdK1 for ; Wed, 6 Jan 2010 04:24:39 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 0F7C83A6452 for ; Wed, 6 Jan 2010 04:24:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 23B4FD9395; Wed, 6 Jan 2010 13:24:35 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iFl+sRfHyzDA; Wed, 6 Jan 2010 13:24:34 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id BB265D932D; Wed, 6 Jan 2010 13:24:34 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <200912281852.nBSIqwNl011301@boreas.isi.edu> Date: Wed, 6 Jan 2010 13:24:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <10040675-BC62-4267-BB3E-9E8182292DFB@tik.ee.ethz.ch> References: <200912281852.nBSIqwNl011301@boreas.isi.edu> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ah@TR-Sys.de, ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1991) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 12:24:40 -0000 Agreed, on first alternative. On Dec 28, 2009, at 7:52 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D1991 >=20 > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes >=20 > Section: 12.2, pg.43 >=20 > Original Text > ------------- > ... first paragraph: >=20 > [...]. The channel > | between the Exporting Process to Collecting Process using IPFIX is > signed by the Exporting Process key and protected via TLS and DTLS, > while the File is signed by the File Writer key and protected via > CMS. [...] >=20 > Corrected Text > -------------- > [...]. The channel > | from the Exporting Process to the Collecting Process using IPFIX is > signed by the Exporting Process key and protected via TLS and DTLS, > while the File is signed by the File Writer key and protected via > CMS. [...] >=20 > Notes > ----- > Rationale: > "channel between xxx to yyy" does not make sense. Either > "channel _from_ xxx to yyy" or "channel between xxx _and_ yyy" > should be written. > The Corrected Text above suggests the first alternative (based > on the essential unidirectionality of the information flow) and > balances the use of articles. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Jan 6 04:25:42 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34513A6881 for ; Wed, 6 Jan 2010 04:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Grs37EASHfV6 for ; Wed, 6 Jan 2010 04:25:41 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id B3E8D3A681B for ; Wed, 6 Jan 2010 04:25:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id DF787D932D; Wed, 6 Jan 2010 13:25:38 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mO+yt3os88YN; Wed, 6 Jan 2010 13:25:38 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7A71CD9329; Wed, 6 Jan 2010 13:25:38 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <200912281901.nBSJ1Rra014200@boreas.isi.edu> Date: Wed, 6 Jan 2010 13:25:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <669CFCD4-763C-4AF0-9DD2-1143722E9276@tik.ee.ethz.ch> References: <200912281901.nBSJ1Rra014200@boreas.isi.edu> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ah@TR-Sys.de, ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1992) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 12:25:42 -0000 Agreed; however, I would note that as 5652 obsoletes 3852, the risk of = misreading is minimal. On Dec 28, 2009, at 8:01 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D1992 >=20 > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes >=20 > Section: GLOBAL >=20 > Original Text > ------------- > Section 15.1 contains the outdated Normative Reference: >=20 > | [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", > | RFC 3852, July 2004. >=20 > "[RFC3852]" is used in Sections 5.6, 9.1, 9.1.1, and 12. >=20 > Corrected Text > -------------- > At the time of publication of RFC 5655, the replacement RFC already > had been published six weeks ago and should have been referred to, > due to the essential corrections it incorporates: >=20 > | [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", > | RFC 5652, September 2009. >=20 >=20 > Notes > ----- >=20 >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Jan 6 04:25:53 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477F13A6881 for ; Wed, 6 Jan 2010 04:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz5VPJlA3ZNY for ; Wed, 6 Jan 2010 04:25:52 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 4DDDA3A6452 for ; Wed, 6 Jan 2010 04:25:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 8A562D938F; Wed, 6 Jan 2010 13:25:49 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jXwXJgHi1yvU; Wed, 6 Jan 2010 13:25:49 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3A7D2D9362; Wed, 6 Jan 2010 13:25:49 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <200912281845.nBSIjHIS008435@boreas.isi.edu> Date: Wed, 6 Jan 2010 13:25:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5EF7CCB6-3975-43AF-953B-B2D85297B504@tik.ee.ethz.ch> References: <200912281845.nBSIjHIS008435@boreas.isi.edu> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ah@TR-Sys.de, ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Editorial Errata Reported] RFC5655 (1990) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 12:25:53 -0000 Completely agreed on the typographical error here (s/much/must/). I = suppose the which/that change is acceptable as well. On Dec 28, 2009, at 7:45 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D1990 >=20 > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes >=20 > Section: 12, pg.42 >=20 > Original Text > ------------- > [...]. However, aside > from merely applying CMS for signatures, there are several security > | issues which much be considered in certain circumstances; these are > covered in the subsections below. >=20 >=20 > Corrected Text > -------------- > [...]. However, aside > from merely applying CMS for signatures, there are several security > | issues that must be considered in certain circumstances; these are > covered in the subsections below. >=20 >=20 > Notes > ----- > Rationale: broken grammar; s/which much/that must/ . >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From trammell@tik.ee.ethz.ch Wed Jan 6 04:29:59 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139D73A6849 for ; Wed, 6 Jan 2010 04:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhBnE2Qn4NO4 for ; Wed, 6 Jan 2010 04:29:57 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 509793A6783 for ; Wed, 6 Jan 2010 04:29:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 89097D932D; Wed, 6 Jan 2010 13:29:54 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cafTh1L+PgVj; Wed, 6 Jan 2010 13:29:54 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 282A4D9329; Wed, 6 Jan 2010 13:29:54 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <200912281840.nBSIeDb3006406@boreas.isi.edu> Date: Wed, 6 Jan 2010 13:29:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6699D8EE-AB8A-4CA9-B392-3A2801867136@tik.ee.ethz.ch> References: <200912281840.nBSIeDb3006406@boreas.isi.edu> To: RFC Errata System X-Mailer: Apple Mail (2.1077) Cc: ah@TR-Sys.de, ipfix@ietf.org, rbonica@juniper.net, brian.trammell@hitachi-eu.com, n.brownlee@auckland.ac.nz, tanja.zseby@fokus.fraunhofer.de, quittek@netlab.nec.de, arno@wagner.name Subject: Re: [IPFIX] [Technical Errata Reported] RFC5655 (1988) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 12:29:59 -0000 Agreed; this was a copy/paste typo. SEQUENCE would increase clarity, as = well, I suppose; note that the summary in 9.1 was taken pretty much = directly from RFC5485 section 3, in which SEQUENCE does not appear. On Dec 28, 2009, at 7:40 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5655, > "Specification of the IP Flow Information Export (IPFIX) File Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5655&eid=3D1988 >=20 > -------------------------------------- > Type: Technical > Reported by: Alfred Hoenes >=20 > Section: 9.1.3, pg.39 >=20 > Original Text > ------------- > signedAttrs: an optional set of attributes that are signed along > with the content. >=20 > | digestAlgorithm: identifies the digital signature algorithm and > associated parameters used to generate the signature. >=20 > signature: the digital signature of the associated file. >=20 > unsignedAttrs: an optional set of attributes that are not signed. >=20 >=20 > Corrected Text > -------------- > signedAttrs: an optional set of attributes that are signed along > with the content. >=20 > | signatureAlgorithm: identifies the digital signature algorithm and > associated parameters used to generate the signature. >=20 > signature: the digital signature of the associated file. >=20 > unsignedAttrs: an optional set of attributes that are not signed. >=20 >=20 > Notes > ----- > Rationale:=20 > Same SEQUENCE element name listed twice, for two different = explanations. >=20 > Further Note (keep for update!): > In Section 9.1, in the ASN.1 on page 37, for a better approximation > to ASN.1, all pairs of curly braces, "{" ... "}", should better be > preceded by the keyword "SEQUENCE". >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5655 (draft-ietf-ipfix-file-05) > -------------------------------------- > Title : Specification of the IP Flow Information Export = (IPFIX) File Format > Publication Date : October 2009 > Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. = Wagner > Category : PROPOSED STANDARD > Source : IP Flow Information Export > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From snehama@avaya.com Wed Jan 6 23:17:02 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6203A6954 for ; Wed, 6 Jan 2010 23:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgkG3OO05aLw for ; Wed, 6 Jan 2010 23:17:01 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id D9BB93A67A4 for ; Wed, 6 Jan 2010 23:17:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,234,1262581200"; d="scan'208";a="170793366" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Jan 2010 02:16:57 -0500 Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jan 2010 02:16:56 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o077GZW24193 for ; Thu, 7 Jan 2010 07:16:35 GMT Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o077GW124625 for ; Thu, 7 Jan 2010 07:16:33 GMT 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 Jan 2010 01:10:01 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt Thread-Index: Acp30u8/+BELFMXJSASX8hTJvLUHWgFcTv4QBH/SvhA= References: From: "Shmulik Nehama" To: Subject: Re: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 07:17:02 -0000 The proposal to add the new information element "reliabilityReasonCode" makes sense...providing more clarity as to why a device is not reporting to the collector process. You propose two possible codes 0x00 and 0x01 for General and Reset. Will it not make sense to also have a code specific for when a device was under a hard reboot and has no information as to the start and end times of the reset? I am of the opinion that there may be collector apps interested in knowing if the device has rebooted...of course there are challenges involved in detecting a hard reboot and not all devices may be able to report information on such state change. Comments from anyone? Thanks Shmulik Nehama -----Original Message----- From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf Of sujay gupta Sent: Tuesday, December 08, 2009 12:22 PM To: ipfix@ietf.org Cc: Juergen Quittek Subject: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt HI, Request you to provide your comments and feedback on the following draft which has been submitted; Title: Reliability Template Extension for IPFIX draft-gupta-ipfix-reliability-template-ext-00.txt Brief: "IPFIX[RFC3917] mandates the IPFIX device should be reliable.To be reliable the individual components like the Metering process or the Exporting process should not fail to meter & export the flow information to the collector, else indicate its incapability explicitly. Currently, IPFIX transmits failure by sending count of packets,flows it failed to process along with the duration of the failure. This document outlines some of the limitations an IPFIX device may have and suggests solutions." A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gupta-ipfix-reliability-templa te-ext-00.txt Thanking you, -Sujay _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix From muenz@net.in.tum.de Thu Jan 7 01:02:38 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C9328C0FA for ; Thu, 7 Jan 2010 01:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJFjxXvo0cnD for ; Thu, 7 Jan 2010 01:02:37 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 33EF428C0E3 for ; Thu, 7 Jan 2010 01:02:36 -0800 (PST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 8A08A4A09; Thu, 7 Jan 2010 10:02:33 +0100 (CET) Message-ID: <4B45A3AF.4020409@net.in.tum.de> Date: Thu, 07 Jan 2010 10:04:47 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Shmulik Nehama References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010901040208070403060006" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2010 09:02:38 -0000 This is a cryptographically signed message in MIME format. --------------ms010901040208070403060006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Shmulik Nehama wrote: > The proposal to add the new information element "reliabilityReasonCode"= > makes sense...providing more clarity as to why a device is not reportin= g > to the collector process. You propose two possible codes 0x00 and 0x01 > for General and Reset. Will it not make sense to also have a code > specific for when a device was under a hard reboot and has no > information as to the start and end times of the reset? I am of the > opinion that there may be collector apps interested in knowing if the > device has rebooted...of course there are challenges involved in > detecting a hard reboot and not all devices may be able to report > information on such state change. >=20 > Comments from anyone? We already have systemInitTimeMilliseconds. By exporting this IE (e.g., in an Option), the Collector will know when=20 a reboot occurred. Furthermore, all relative counters are reset at this = time. You can calculate the gap between the last reliability report (including = octet and packet counters) and the new systemInitTimeMilliseconds value: (new_systemInitTimeMilliseconds)/1000 - Export_Time_of_last_rel_report This is the period of time for which you do not know how many packets=20 were discarded. If you want to have this information with higher precision, you can add=20 a millisecond time stamp to the reliability report (e.g.,=20 observationTimeMilliseconds). So, I'm not sure if we need reliabilityReasonCode. Regards, Gerhard >=20 > Thanks >=20 > Shmulik Nehama >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf > Of sujay gupta > Sent: Tuesday, December 08, 2009 12:22 PM > To: ipfix@ietf.org > Cc: Juergen Quittek > Subject: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt >=20 > HI, >=20 > Request you to provide your comments and feedback on the following draf= t > which has been submitted; >=20 > Title: > Reliability Template Extension for IPFIX > draft-gupta-ipfix-reliability-template-ext-00.txt >=20 > Brief: > "IPFIX[RFC3917] mandates the IPFIX device should be reliable.To be > reliable the individual components like the Metering process or the > Exporting process should not fail to meter & export the flow informatio= n > to the collector, else indicate its incapability explicitly. >=20 > Currently, IPFIX transmits failure by sending count of packets,flows it= > failed to process along with the duration of the failure. >=20 > This document outlines some of the limitations an IPFIX device may have= > and suggests solutions." >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-gupta-ipfix-reliability-templ= a > te-ext-00.txt >=20 > Thanking you, > -Sujay > _______________________________________________ > 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 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms010901040208070403060006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5 vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1 uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1 OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6 waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew 3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36 dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX 2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6 5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDEwNzA5MDQ0N1owIwYJKoZIhvcNAQkEMRYEFMNh ntbxVw0cR1RHEYCFFd/Ky2DEMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQAAOQt47VEIA6h/Ii667ljI4Psd76VMuZKRx3rDSP0b2iE0Fsm26MQf gQehNLtEjOZQEEuRjuz55g7akNQqWYUn0siH1OLNTl0F9qQOtU58oV/ZCLGywJzw4ZHQr+gm KJ+YAOenrXHg3uctpbJ6GOmTzOe0QOXRZWueHUffiYPIyXt2IfBDKa+6IFSzQHI18lUnASvj c0nonhrJrRlg1Bc8yqwetnKU2Ms8XZM6qkdpBqwyHxP2t8kldw2iFE/FYKdnSy9CnrVa2I6s E1DEBqLRPnHgxaUz2XQXV4lWKXtLjgbicDOFYbwS9Xuyhr+/EzbISfHRfCAPpEq5qE2qPny3 AAAAAAAA --------------ms010901040208070403060006-- From sujay.ietf@gmail.com Fri Jan 8 10:09:32 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE083A68A6 for ; Fri, 8 Jan 2010 10:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEQchQL92C1g for ; Fri, 8 Jan 2010 10:09:31 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id 95FA43A6840 for ; Fri, 8 Jan 2010 10:09:31 -0800 (PST) Received: by pwi20 with SMTP id 20so177076pwi.29 for ; Fri, 08 Jan 2010 10:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OLiNkbhCu3tDXIbzn4gN+fVOmYhqsdbDWyr+6Ppas0c=; b=slS/7panEZXEzD49fOVineVVtRTmkBHls/75xVKtVg6N9cYYymCIXCNms9I7/JsW05 TMT8U2KRlgJHAcnML9zvskz0Kixznkbhmay1poiNlWoBPOqVRvkCLqiDDKaTGWaBu/Sa H4nE8NDXwZSEoZcqkLckK0852UzUnFn/B6KyI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=D1s6r/0XUSZZnuy+csOr5fwXEQLSc3PCKmeXk2MEs7mlSUtOb32E5wLQejjR4WIunh Q36r+SefwsHEwn7ziGKkmr7O5ifnNEsY6F5Bhr/8ZHHEcrvQpHqOsWLkcV0ClzFCL1my 2pZE1CpymzQQKk+edTzi1fHsprhb6HjklO+Cs= MIME-Version: 1.0 Received: by 10.142.60.11 with SMTP id i11mr1207287wfa.270.1262974167167; Fri, 08 Jan 2010 10:09:27 -0800 (PST) In-Reply-To: <4B45A3AF.4020409@net.in.tum.de> References: <4B45A3AF.4020409@net.in.tum.de> Date: Fri, 8 Jan 2010 23:39:27 +0530 Message-ID: From: sujay gupta To: Gerhard Muenz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipfix@ietf.org Subject: Re: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2010 18:09:33 -0000 Hi Gerhard, Usage of the existing IE or a new IE , either would serve the purpose. Just the use of an explicit information sound's better. BR, -Sujay On Thu, Jan 7, 2010 at 2:34 PM, Gerhard Muenz wrote: > > Hi, > > Shmulik Nehama wrote: >> >> The proposal to add the new information element "reliabilityReasonCode" >> makes sense...providing more clarity as to why a device is not reporting >> to the collector process. You propose two possible codes 0x00 and 0x01 >> for General and Reset. Will it not make sense to also have a code >> specific for when a device was under a hard reboot and has no >> information as to the start and end times of the reset? I am of the >> opinion that there may be collector apps interested in knowing if the >> device has rebooted...of course there are challenges involved in >> detecting a hard reboot and not all devices may be able to report >> information on such state change. >> >> Comments from anyone? > > We already have systemInitTimeMilliseconds. > > By exporting this IE (e.g., in an Option), the Collector will know when a > reboot occurred. =A0Furthermore, all relative counters are reset at this = time. > > You can calculate the gap between the last reliability report (including > octet and packet counters) and the new systemInitTimeMilliseconds value: > > (new_systemInitTimeMilliseconds)/1000 =A0- Export_Time_of_last_rel_report > > This is the period of time for which you do not know how many packets wer= e > discarded. > > If you want to have this information with higher precision, you can add a > millisecond time stamp to the reliability report (e.g., > observationTimeMilliseconds). > > So, I'm not sure if we need reliabilityReasonCode. > > Regards, > Gerhard > > >> >> Thanks >> >> Shmulik Nehama >> >> >> >> >> >> -----Original Message----- >> From: ipfix-bounces@ietf.org [mailto:ipfix-bounces@ietf.org] On Behalf >> Of sujay gupta >> Sent: Tuesday, December 08, 2009 12:22 PM >> To: ipfix@ietf.org >> Cc: Juergen Quittek >> Subject: [IPFIX] draft-gupta-ipfix-reliability-template-ext-00.txt >> >> HI, >> >> Request you to provide your comments and feedback on the following draft >> which has been submitted; >> >> Title: >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Reliability Template Extension for IPFIX >> =A0 =A0 =A0 =A0 =A0 draft-gupta-ipfix-reliability-template-ext-00.txt >> >> Brief: >> "IPFIX[RFC3917] mandates the IPFIX device should be reliable.To be >> reliable the individual components like the Metering process or the >> Exporting process should not fail to meter & export the flow information >> to the collector, else indicate its incapability explicitly. >> >> Currently, IPFIX transmits failure by sending count of packets,flows it >> failed to process along with the duration of the failure. >> >> This document outlines some of the limitations an IPFIX device may have >> and suggests solutions." >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-gupta-ipfix-reliability-templa >> te-ext-00.txt >> >> Thanking you, >> -Sujay >> _______________________________________________ >> 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 > > -- > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Technische Universit=E4t M=FCnchen - Department of Informatics > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: =A0+49 89 289-18008 =A0 =A0 =A0 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de =A0 =A0WWW: http://www.net.in.tum.de/~muenz > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > From root@core3.amsl.com Tue Jan 12 02:00:03 2010 Return-Path: X-Original-To: ipfix@ietf.org Delivered-To: ipfix@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 741F83A67B3; Tue, 12 Jan 2010 02:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100112100003.741F83A67B3@core3.amsl.com> Date: Tue, 12 Jan 2010 02:00:01 -0800 (PST) Cc: ipfix@ietf.org Subject: [IPFIX] I-D Action:draft-ietf-ipfix-mib-10.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 10:00:03 -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 : Definitions of Managed Objects for IP Flow Information Export Author(s) : T. Dietz, et al. Filename : draft-ietf-ipfix-mib-10.txt Pages : 68 Date : 2010-01-12 This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 16, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mib-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-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-12015938.I-D@ietf.org> --NextPart-- From akoba@nttv6.net Sun Jan 17 08:28:25 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987B13A6768 for ; Sun, 17 Jan 2010 08:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.889 X-Spam-Level: ** X-Spam-Status: No, score=2.889 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_63=0.6, J_CHICKENPOX_73=0.6, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmiEQSvF0u92 for ; Sun, 17 Jan 2010 08:28:22 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [192.16.178.5]) by core3.amsl.com (Postfix) with ESMTP id 86B023A684D for ; Sun, 17 Jan 2010 08:28:21 -0800 (PST) Received: from [192.168.1.3] (mail.nttv6.net [IPv6:2001:fa8::25]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o0HGQw9B028542; Mon, 18 Jan 2010 01:26:59 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 18 Jan 2010 01:26:54 +0900 From: Atsushi Kobayashi To: Gerhard Muenz In-Reply-To: <4B41D811.6040009@net.in.tum.de> References: <20091210164010.8C60.17391CF2@nttv6.net> <4B41D811.6040009@net.in.tum.de> Message-Id: <20100118012652.1E15.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.52.03 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 18 Jan 2010 01:27:00 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-configuration-model-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 16:28:25 -0000 Hi Gerhard, Sorry for late reply. Please see in-line. > > >> 1. Introduction > >> > >> IPFIX and PSAMP compliant Monitoring Devices (routers, switches, > >> monitoring probes, Collectors etc.) offer various configuration > >> possibilities that allow adapting network monitoring to the goals and > >> purposes of the application, such as accounting and charging, traffic > >> analysis, performance monitoring, security monitoring. The use of a > >> common vendor-independent configuration data model for IPFIX and > >> PSAMP compliant Monitoring Devices facilitates network management and > >> configuration, especially if Monitoring Devices of different > >> implementers and/or manufacturers are deployed simultaneously. On > >> the one hand, a vendor-independent configuration data model helps > >> storing and managing the configuration data of Monitoring Devices in > >> a consistent format. On the other hand, it can be used for local and > >> remote configuration of Monitoring Devices. However, this requires > >> that Monitoring Devices natively support the configuration data > >> model, or that a mapping between the configuration data model and the > >> device-specific representation of configuration data is provided. > >> > > > > I want to confirm the meaning of "mapping" in last sentence. > > If a vender deploy the different configuration model at first, does it > > need to replace them with the common configuration data? > > No. > > "Mapping between the configuration data model and device-specific > configuration data" means that CDM parameters must correspond to > device-specific parameters. If this is fulfilled, the CDM can be easily > converted into the device-specific data (CLI, XML, or whatever) and vice > versa. On the other hand, if the device-specific parameters have a very > different meaning, a conversion is not possible (or at least difficult). > > Side note: The conversion can be realized at different places, for example: > - in the management system > - on the device by running an agent > > What shall we do with the last sentence "However,...."? > Remove it? > Is it better to remove the following? "or that a mapping between the configuration data model and the device-specific representation of configuration data is provided." > >> The purpose of this document is the specification of a vendor- > >> independent configuration data model that covers the commonly > >> available configuration parameters of Selection Processes, Caches, > >> Exporting Processes, and Collecting Processes. The configuration > >> data model is defined using UML (Unified Modeling Language) class > >> diagrams [UML] while the actual configuration data is encoded in > >> Extensible Markup Language (XML) [W3C.REC-xml-20040204]. An XML > >> document conforming to the configuration data model contains the > >> configuration data of one Monitoring Device. In order to ensure > >> compatibility with the NETCONF protocol [RFC4741], YANG > >> [I-D.ietf-netmod-yang] is used as the modeling language. If > >> required, the YANG specification of the configuration data model can > >> be converted into XML Schema language [W3C.REC-xmlschema-0-20041028] > >> using the pyang tool [YANG-WEB]. YANG provides mechanisms to adapt > >> the configuration data model to device-specific constraints and to > >> augment the model with additional device-specific or vendor-specific > >> parameters. > >> > >> For the configuration of remote Monitoring Devices, an appropriate > >> protocol is needed to transfer the XML encoded configuration data. > >> The configuration data model is compatible with the NETCONF protocol > >> [RFC4741]. However, alternative protocols, such as the Simple Object > >> Access Protocol (SOAP) [W3C.REC-soap12-part1-20070427], are also > >> suitable for transferring XML data from a network management system > >> to a Monitoring Device. > >> > > [snip] > > >> 2. Terminology > > [snip] > > >> In addition to the existing IPFIX and PSAMP terminology, the > >> following terms are defined: > >> > >> Cache: The Cache is a functional block in a Metering Process which > >> maintains IPFIX Flow Records or PSAMP Packet Reports. According > >> to [RFC5101], the maintenance of Flow Records may include creating > >> new records, updating existing ones, computing Flow statistics, > >> deriving further Flow properties, detecting Flow expiration, > >> passing Flow Records to the Exporting Process, and deleting Flow > >> Records. The maintenance of Packet Reports covers the same set of > >> functions. > > > > In the case of PSAMP Packet Reports, how is the Cache used in Metering > > Process? Is a PSAMP Packet Report maintained in Cache until deriving > > further properties? It seems an implementation matter. > > The only difference between a PSAMP Packet Report and an IPFIX Flow > Record is that the Packet Report always carries information about a > single packet while the Flow Record may contain information about > multiple packets. > > The CDM always includes a Cache as part of the Metering Process, even if > Packet Reports are generated, because this is the place where the fields > contained in the record are defined. The Cache Mode specifies the > expiration policy and thus whether one or multiple packets are included > in a record. > > Is there a need to clarify the definition of Cache? > Yes. In the case of Packet Reports, the current Cache definition does not clarify what functions Cache has. > >> Cache Layout: The Cache Layout defines the superset of fields that > >> are included in the Packet Reports or Flow Records maintained by > >> the Cache. The fields are specified by the corresponding > >> Information Elements. In general, the largest possible subset of > >> the specified fields is derived for every Packet Report or Flow > >> Record. More specific rules about which fields must be included > >> are given in Section 4.3.1. > >> > >> Cache Mode: The Cache Mode specifies whether Packet Reports or Flow > >> Records are generated by the Cache. In the case of Flow Records, > >> it also specifies the Flow expiration policy. > >> > >> Monitoring Device: A Monitoring Device implements at least one of > >> the functional blocks specified in the context of IPFIX or PSAMP. > >> In particular, the term Monitoring Device encompasses Exporters, > >> Collectors, IPFIX Devices, and PSAMP Devices. > >> > >> Selected Packet Stream: The Selected Packet Stream is the set of all > >> packets selected by a Selection Process. > >> > >> > >> 3. Structure of the Configuration Data Model > >> > >> The IPFIX reference model in [RFC5470] describes Metering Processes, > >> Exporting Processes, and Collecting Processes as functional blocks of > >> IPFIX Devices. The PSAMP framework [RFC5474] provides the > >> corresponding information for PSAMP Devices and introduces Selection > >> Processes as functional blocks within Metering Processes. In > >> Section 2 of the document, the Cache is defined as another functional > >> block within Metering Processes. Further explanations about the > >> relationship between Selection Processes and Caches are given later > >> on in this section. IPFIX File Reader and File Writer are defined as > >> specific kinds of Exporting and Collecting Processes in > >> [I-D.ietf-ipfix-file]. > >> > >> Monitoring Device implementations usually maintain the separation of > >> various functional blocks although they do not necessarily implement > >> all of them. Furthermore, they provide various configuration > >> possibilities; some of them are specified as mandatory by the IPFIX > >> protocol [RFC5101] or PSAMP protocol [RFC5476]. The configuration > >> data model enables the setting of commonly available configuration > >> parameters for Selection Processes, Caches, Exporting Processes, and > >> Collecting Processes. In addition, it allows specifying the > >> composition of functional blocks within a Monitoring Device > >> configuration and their linkage with Observation Points. > >> > >> In a Monitoring Device implementation, the functionality of the > >> Metering Process is commonly split into packet Sampling and Filtering > >> functions performed by Selection Processes, and the maintenance of > >> Flow Records and Packet Reports performed by Caches. Figure 1 > >> illustrates this separation with the example of a basic Metering > >> Process consisting of one Selection Process and one Cache. > >> > >> +-----------------------------------+ > >> | Metering Process | > >> | +-----------+ Selected | > >> Observed | | Selection | Packet +-------+ | Stream of > >> Packet -->| Process |---------->| Cache |--> Flow Records or > >> Stream | +-----------+ Stream +-------+ | Packet Reports > >> +-----------------------------------+ > >> > >> Figure 1: Selection Process and Cache forming a Metering Process > >> > >> The configuration data model adopts the separation of Selection > >> Processes and Caches in order to support the flexible configuration > >> and combination of these functional blocks. As defined in [RFC5476], > >> the Selection Process takes the Observed Packet Stream as its input > >> and selects a subset of that stream as its output (Selected Packet > >> Stream). The action of the Selection Process on a single packet of > >> its input is defined by a Primitive Selector or a Composite Selector. > >> The Cache generates Flow Records or Packet Reports from the Selected > >> Packet Stream, depending on the configured Cache Mode. > >> > >> The Observed Packet Stream at the input of a Selection Process MUST > >> only contain packets originating from a single Observation Domain. > >> Similarly, the Selected Packet Stream at the input of a Cache MUST > >> only contain packets originating from a single Observation Domain. > >> Packets from Observation Points belonging to different Observation > >> Domains MUST NOT enter the same Selection Process or the same Cache. > >> > > > > Observed packets at different Observation Domain can be input into different > > Metering Process. Thus, they can not enter the same Metering Process. > > I think that the above sentence is already clear in existing IPFIX > > documents. Or it means other something? > > The whole paragraph will removed in the next version of the draft. > > We had a discussion about this issue in the context of IPFIX MIB. In > fact, there is no IPFIX document which says that packets observed at > different ODs must not enter the same MP. Therefore, we did not add any > additional restriction on this in the IPFIX MIB, and we do not want to > do this here, either. > No IPFIX documents said that? > For clarification, I propose to add one sentence to the preceding paragraph: > > NEW: > ... As defined in [RFC5476], > the Selection Process takes the Observed Packet Stream as its input > and selects a subset of that stream as its output (Selected Packet > Stream). The Observed Packet Stream at the input of a Selection > Process is composed of packets from a single Observation Point. ... > > Is this ok? Fined. > >> Beyond the basic Metering Process shown in Figure 1, the > >> configuration data model enables the specification of more complex > >> configurations. A single Cache may process the output of multiple > >> Selection Processes. The Selected Packet Stream may be copied to > > > > I cannot image that a single cache process the output from multiple Selection > > Process. This sentence seems cause the inconsistency to the > > definition of Observation Domain, when a Metering Process consisting of > > a sequence of Selection Processes and Cahce. > > I do not understand your point. If there is any inconsistency, please > explain it to me. > When a single cache processes the input from multiple Selection Processes, it is not clear what components compose a single Metering Process. Observed Packet ----> Selection Process#1 -+ Stream | +----> Cache#1 ---> Observed | Packet ----> Selection Process#2 -+ Stream If you mean SP#1, SP#2, and Cahce#1 compose Metering Process#1, Observed packets at different Observation Domains can enter the same Metering Process. Or you mean SP#1 and Cahce#1 compose Metering Process#1, and SP#2 and Cache#1 compose Metering Process#2? On the other hand, in the following case, SP#1, Cache#1 and Cache#2 compose MP#1, or SP#1 and Cache#1 compose MP#1 and SP#1 and Cache#2 compose MP#2? Observed Packet ----> Selection Process#1 -+----> Cache#1 ---> Flow Stream | +----> Cache#2 ---> Packet Could you clarify which components compose a single MP in complicated cases? > > And I have another question. Are Selection Processes after Cahce > > available as an IPFIX Mediation? > > No. This RFC will not cover IPFPIX Mediation. > Ok. Have you already mentioned somewhere that the output of a Cache can not be input of another Selection Process and Cache? > >> enter several Caches, for example one Cache that generates Flow > >> Records and another Cache that generates Packet Reports. Selection > >> Processes can also be cascaded, such that the Selected Packet Stream > >> at the output of one Selection Process is passed to another Selection > >> Process. Cascading Selection Processes can be useful in specific > >> contexts such as the example in Section 7.3. > >> > >> The selection of parameters in the configuration data model is based > >> on configuration issues discussed in the IPFIX and PSAMP documents > >> [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC5475]. > >> Furthermore, the structure and content of the IPFIX MIB module > >> [I-D.ietf-ipfix-mib] and the PSAMP MIB module [I-D.ietf-psamp-mib] > >> have been taken into consideration. Consistency between the > >> configuration data model and the IPFIX and PSAMP MIB modules is an > >> intended goal. Therefore, parameters in the configuration data model > >> are named according to corresponding managed objects. Certain IPFIX > >> MIB objects containing state data have been adopted as state > >> parameters in the configuration data model. State parameters cannot > >> be configured, yet their values can be queried from the Monitoring > >> Device. > > > > They can be queried from other devices as well as Monitoring Device. > > I do not understand. Why shall a Monitoring Device query state > information from another Monitoring Device? I would like to say that generally other device(NMS or etc) as well as Monitoring Device can query state parameters. I am not sure why you limits only Monitoring Device on this. But, it is minor question. > > >> The next section explains how UML class diagrams are deployed to > >> illustrate the structure of the configuration data model. > >> Thereafter, Section 3.2 and Section 3.3 explain the class diagrams > >> for the configuration of Exporters and Collectors, respectively. > >> Each of the presented classes contains specific configuration > >> parameters which are specified in Section 4. The formal definition > >> of the configuration data model in YANG is given in Section 6. > >> Section 7 illustrates the usage of the model with example > >> configurations in XML. Section 5 gives a short introduction to YANG > >> concepts that allow adapting the configuration data model to the > >> capabilities of a device. > >> [snip] > >> 3.2. Exporter Configuration > >> > >> Figure 4 below shows the main classes of the configuration data model > >> which are involved in the configuration of an IPFIX or PSAMP > >> Exporter. The role of the classes can be briefly summarized as > >> follows: > >> > >> o The ObservationPoint class specifies an Observation Point (i.e., > >> an interface or linecard) of the Monitoring Device at which > >> packets are captured for traffic measurements. An object of the > >> ObservationPoint class may be associated with one or more objects > >> of the SelectionProcess class configuring Selection Processes that > >> process the observed packets in parallel. As long as an > >> ObservationPoint object is specified without any references to > >> SelectionProcess objects, the Observation Point is not deployed > >> for traffic measurements. > >> > >> o The SelectionProcess class contains the configuration parameters > >> of a Selection Process. The Selection Process may be composed of > >> a single Selector or a sequence of Selectors, defining a Primitive > >> or Composite Selector, respectively. > >> > >> The Selection Process selects packets from an Observed Packet > >> Stream originating from one or multiple Observation Points. > >> Therefore, a SelectionProcess object MAY be referred to from > >> multiple ObservationPoint objects. The corresponding Observation > >> Points must belong to the same Observation Domain. > > > > The Selection Process after Cache handles the Flow Records or Packet > > Reports, not packets. > > All Selection Process are located in front of a Cache, not behind. > Ok, please put above sentense in this document somewhere. > > > >> A Selection Process MAY pass the Selected Packet Stream to one or > >> multiple Caches. Therefore, the SelectionProcess class enables > >> references to objects of the Cache class. > >> > >> It is possible to cascade different Selection Processes. In this > >> case, the Selected Packet Stream at the output of one or multiple > >> Selection Processes is passed to the input of another Selection > >> Process. Therefore, a SelectionProcess object MAY be referred to > >> from multiple SelectionProcess objects. For the same reason, one > >> SelectionProcess object may refer to other objects of the same > >> class. When cascading multiple Selection Processes, it must be > >> ensured that all packets entering a Selection Process have been > >> observed at Observation Points belonging to the same Observation > >> Domain. A configuration example is given later in Section 7.3. > >> > >> If a Selection Process is configured without any reference to > >> Selection Processes or Caches that receive the selected packets, > >> the selected packets are not accounted in any Packet Report or > >> Flow Record. > > > NEW: > > o The SelectionProcess class contains the configuration parameters > of a Selection Process. The Selection Process may be composed of > a single Selector or a sequence of Selectors, defining a Primitive > or Composite Selector, respectively. > > The Selection Process selects packets from an Observed Packet > Stream originating from an Observation Point. Therefore, a > SelectionProcess object MAY be referred to from a single > ObservationPoint object. > Ok, it avoid to add the restriction. > It is possible to cascade different Selection Processes. In this > case, the Selected Packet Stream at the output of a Selection > Process is passed to the input of another Selection Process. > Therefore, one SelectionProcess object may refer to other objects > of the same class. A configuration example is given below in > Section 7.3. > > A Selection Process MAY pass the Selected Packet Stream to one or > multiple Caches. Therefore, the SelectionProcess class enables > references to objects of the Cache class. > > If a Selection Process is configured without any reference to > Selection Processes or Caches that receive the selected packets, > the selected packets are not accounted in any Packet Report or > Flow Record. > > > > >> > >> o The Cache class contains configuration parameters of a Cache. A > >> Cache may receive the output of one or more Selection Processes > >> and maintains corresponding Packet Reports or Flow Records. > >> Therefore, an object of the Cache class MAY be referred to from > >> multiple SelectionProcess objects. However, the configuration > >> MUST ensure that all packets entering the Selection Process have > > ^^^^^^^^^^^^^^^^^ > > Cache? > > > >> been observed at Observation Points belonging to the same > >> Observation Domain. > > This whole sentence will be removed. > > >> > >> Configuration parameters of the Cache class specify the size of > >> the Cache, the Cache Mode and Layout, and expiration parameters. > >> The Cache Mode determines if Packet Reports or Flow Records are > >> generated. > >> > >> A Cache MAY pass its output to one or multiple Exporting Process. > >> Therefore, the Cache class enables references to one or multiple > >> objects of the ExportingProcess class. If a Cache object does not > >> specify any reference to an ExportingProcess object, the Cache > >> output is dropped. > >> > >> o The ExportingProcess class contains configuration parameters of an > >> Exporting Process. It includes various transport protocol > >> specific parameters and the export destinations. An object of the > >> ExportingProcess class MAY be referred to from multiple objects of > >> the Cache class. > >> > >> An Exporting Process MAY be configured as a File Writer according > >> to [I-D.ietf-ipfix-file]. > >> > >> +------------------+ > >> | ObservationPoint | > >> +------------------+ > >> 0..* | > >> | > >> 0..* V > >> +------------------+ > >> | SelectionProcess | > >> +------------------+<-+ > >> 0..* | 0..* | | 0..* > >> | +---+ > >> 0..* V > >> +------------------+ > >> | Cache | > >> +------------------+ > >> 0..* | > >> | > >> 0..* V > >> +------------------+ > >> | ExportingProcess | > >> +------------------+ > > > NEW: > > +------------------+ > | ObservationPoint | > +------------------+ > 0..1 | > | > 0..* V > +------------------+ > | SelectionProcess | > +------------------+<-+ > 0..* | 0..1 | | 0..* > | +---+ > 0..* V > +------------------+ > | Cache | > +------------------+ > 0..* | > | > 0..* V > +------------------+ > | ExportingProcess | > +------------------+ > > Ok. > >> > >> Figure 4: Class diagram of Exporter configuration > >> > > [snip] > > >> 4.1. ObservationPoint Class > >> > >> +-------------------------------+ > >> | ObservationPoint | > >> +-------------------------------+ 1 +--------------------+ > >> | name |<>----------| Interface/Linecard | > >> | observationPointId {readOnly} | +--------------------+ > >> | observationDomainId | > >> | | 0..* 0..* +--------------------+ > >> | |----------->| SelectionProcess | > >> +-------------------------------+ +--------------------+ > >> > >> +------------------+ +----------------------------------+ > >> | Interface | | Linecard | > >> +------------------+ +----------------------------------+ > >> | ifIndex/ifName | | entPhysicalIndex/entPhysicalName | > >> | direction = both | | direction = both | > >> +------------------+ +----------------------------------+ > >> > >> Figure 6: ObservationPoint class > >> > >> Figure 6 shows the ObservationPoint class that identifies an > >> Observation Point of the Monitoring Device. The Observation Point > >> can either be an interface or a linecard. > >> > >> An object of the ObservationPoint class MUST specify the ID of the > >> Observation Domain the Observation Point belongs to. Observation > >> Points that are configured with the same Observation Domain ID belong > >> to the same Observation Domain. > >> > >> The Observation Point ID (i.e., the value of the Information Element > >> observationPointId [RFC5102]) is assigned by the Monitoring Device. > >> It appears as a state parameter in the ObservationPoint class. > >> > >> The configuration parameters to identify an interface or a linecard > >> are as follows: > >> > >> ifIndex/ifName (interface only): Either the index or name of the > >> interface MUST be specified according to corresponding objects in > >> the IF-MIB [RFC2863]. > >> > >> entPhysicalIndex/entPhysicalName (linecard only): Either the index > >> or name of the linecard MUST be specified according to > >> corresponding objects in the ENTITY-MIB [RFC4133]. > >> > >> direction: This parameter specifies if ingress traffic, egress > >> traffic, or both ingress and egress traffic is captured, using the > >> values "ingress", "egress", and "both", respectively. If not > >> configured, ingress and egress traffic is captured (i.e., the > >> default value is "both"). If not applicable (e.g., in the case of > >> a sniffing interface in promiscuous mode), the value of this > >> parameter is ignored. > > > > I have one question. > > In the case of a single ifIndex belonging to multiple Observation > > Domains, can this Interface class be referred by multiple > > ObservationPoint classes? > > With respect to the CDM, there is no restriction. Multiple > ObservationPoint objects belonging to different Observation Domain IDs > can have the same IfIndex value. > Ok. > >> An ObservationPoint object MAY refer to one or multiple > >> SelectionProcess objects configuring Selection Processes that process > >> the observed packets in parallel. > >> > >> 4.2. SelectionProcess Class > >> > >> +--------------------------------+ > >> | SelectionProcess | > >> +--------------------------------+ 1..* +----------+ > >> | name |<>----------| Selector | > >> | selectionSequenceId {readOnly} | +----------+ > >> | | 0..* > >> | |<---+ > >> | | | > >> | |----+ > >> | | 0..* > >> | | > >> | | 0..* 0..* +----------+ > >> | |----------->| Cache | > >> +--------------------------------+ +----------+ > >> > >> Figure 7: SelectionProcess class > >> > >> Figure 7 shows the SelectionProcess class. The SelectionProcess > >> class contains the configuration parameters of a Selection Process > >> which selects packets from the Observed Packet Stream at its input > >> and outputs the Selected Packet Stream to one or multiple other > >> Selection Processes or Caches. A non-empty ordered list defines a > >> sequence of Selectors. The actions defined by the Selectors are > >> applied to the stream of incoming packet in the specified order. > >> > >> The state parameter selectionSequenceId contains the Selection > >> Sequence ID (i.e., the value of the Information Element > >> selectionSequenceId [RFC5477]) which is assigned by the Monitoring > >> Device. The Selection Sequence ID MUST be unique within the > >> Observation Domain as required by [RFC5477]. > >> > >> The output of one Selection Process MAY be processed by other > >> Selection Processes. Therefore, the SelectionProcess class allows > >> references to itself, meaning that one SelectionProcess object MAY > >> refer to other SelectionProcess objects. > >> > >> A SelectionProcess object MAY include references to one or more > >> objects of the Cache class configuring Caches that receive the > >> Selected Packet Stream and generate corresponding Packet Reports or > >> Flow Records. > > > > If SelectionProcess class embodies the function of Metering Process, I > > prefer the name of MeteringProcess class instead of SelectionProcess > > from the consistency with IPFIX-MIB. > > I do not understand. SelectonProcess class corresponds to > ipfixSelectionProcessTable in the IPFIX-MIB. > In IPFIX-MIB, there is ipfixMeteringProcessTable related to Metering Process. On the other hand, IPFIX-CONFIG does not have some object whose name comes from Metering Process. Reader might look for it. And also, as I previously mentioned, it is not clear about the relation among MP, SP, and Cache in complicated cases. Could you add some Metering Process object, or describe clearly the relation? > > > > > >> 4.2.1. Selector Class > >> > >> +--------------------------------------+ > >> | Selector | > >> +--------------------------------------+ 1 +-----------------+ > >> | name |<>------+ SelectAll/ | > >> | selectorId {readOnly} | | SampCountBased/ | > >> | packetsObserved {readOnly} | | SampTimeBased/ | > >> | packetsDropped {readOnly} | | SampRandOutOfN/ | > >> | selectorDiscontinuityTime {readOnly} | | SampUniProb/ | > >> | | | FilterMatch/ | > >> | | | FilterHash/ | > >> +--------------------------------------+ +-----------------+ > >> > >> Figure 8: Selector class > >> > >> The Selector class in Figure 8 contains the configuration and state > >> parameters of a Selector. Standardized PSAMP Sampling and Filtering > >> methods are described in [RFC5475]; their configuration parameters > >> are specified in corresponding sampler (SampCountBased, > >> SampTimeBased, SampRandOutOfN, SampUniProb) or filter (FilterMatch, > >> FilterHash) classes. In addition, the SelectAll class, which has no > >> parameters, is used for a Selector that selects all packets. The > >> Selector class includes exactly one of these sampler and filter > >> classes, depending on the applied method. > >> > >> The state parameter selectorId contains the Selector ID (i.e., the > >> value of the Information Element selectorId [RFC5477]) assigned by > >> the Monitoring Device. The Selector ID MUST be unique within the > >> Observation Domain as required by [RFC5477]. > >> > >> As state parameters, the Selector class contains the Selector > >> statistics packetsObserved and packetsDropped that correspond to the > >> objects of the ipfixSelectorStatsTable in the IPFIX MIB module > >> [I-D.ietf-ipfix-mib]. > >> > > [snip] > > >> 4.2.3. Filter Classes > >> > >> +--------------------------+ > >> | FilterMatch | > >> +--------------------------+ > >> | ieId/ieName | > >> | ieEnterpriseNumber[0..1] | > >> | value | > >> +--------------------------+ > >> > >> +--------------------------+ > >> | FilterHash | > >> +--------------------------+ 1..* +---------------+ > >> | hashFunction = BOB |<>-------| SelectedRange | > >> | ipPayloadOffset = 0 | +---------------+ > >> | ipPayloadSize = 8 | | name | > >> | digestOutput = false | | min | > >> | initialiserValue[0..1] | | max | > >> +--------------------------+ +---------------+ > >> > >> Figure 10: Filter classes > >> > >> The Filter classes in Figure 10 contain the configuration parameters > >> of specific Filtering methods. For property match filtering, the > >> configuration parameters are: > >> > >> ieId, ieName, ieEnterpriseNumber: The property to be matched is > >> specified by either ieId or ieName, specifying the ID or name of > >> the Information Element, respectively. ieEnterpriseNumber MUST be > >> used for enterprise-specific Information Elements. If > >> ieEnterpriseNumber is omitted or zero, this is Information Element > >> is not enterprise-specific but registered at IANA. > >> > >> value: Matching value. > >> > > > > Can the ranges of value be defined like hash value? > > No. The reason is that min/max fields are not specified in the Selector > Report Interpretation: > http://tools.ietf.org/html/rfc5476#section-6.5.2.5 > > In the case of FilterHash, we do min/max fields in the Selector Report > Interpretation: > http://tools.ietf.org/html/rfc5476#section-6.5.2.6 > > > And, I would like to specify its instruction, "match" or "unmatch". > > This is not specified in the Selector Report Interpretation. Therefore, > we cannot allow configuring this. > Above all, they apparently would be required from viewpoint of usability. Please see http://tools.ietf.org/html/rfc5475#section-6.1 that described it as an extension of the basic model. Implementor will add above functions because only exact match is too poor. In that case, can IPFIX-CONFIG expand to add these functions? How does it expand? > >> For hash-based filtering, the configuration parameters are: > >> > >> hashFunction: Hash function to be used. The following parameter > >> values are defined by the configuration data model: > >> * BOB: BOB Hash Function as specified in [RFC5475], Appendix A.2 > >> * IPSX: IP Shift-XOR (IPSX) Hash Function as specified in > >> [RFC5475], Appendix A.1 > >> * CRC: CRC-32 function as specified in [RFC1141] > >> Default value is "BOB". > >> > >> ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSize > >> configure the offset and the size of the payload section used as > >> input to the hash function. Default values are 0 and 8, > >> respectively, corresponding to the minimum configurable values > >> according to [RFC5476], Section 6.2.5.6. These parameters > >> correspond to the Information Elements hashIPPayloadOffset and > >> hashIPPayloadSize [RFC5477]. > >> > >> digestOutput: digestOutput enables or disables the inclusion of the > >> packet digest in the resulting PSAMP Packet Report. This requires > >> that the Cache Layout of the Cache generating the Packet Reports > >> includes a digestHashValue field. This parameter corresponds to > >> the Information Element hashDigestOutput [RFC5477]. > >> > >> initialiserValue: Initializer value to the hash function. This > >> parameter corresponds to the Information Element > >> hashInitialiserValue [RFC5477]. If not configured by the user, > >> the monitoring device arbitrarily chooses an initializer value. > >> > >> One or more ranges of matching hash values are defined by the min and > >> max parameters of the SelectedRange subclass. These parameters > >> correspond to the Information Elements hashSelectedRangeMin and > >> hashSelectedRangeMax [RFC5477]. > >> > >> 4.3. Cache Class > >> > >> +-----------------------------------+ > >> | Cache | > >> +-----------------------------------+ 1 +-------------+ > >> | name |<>----------| CacheLayout | > >> | cacheMode | +-------------+ > >> | maxRecords {opt.} | > >> | activeTimeout {opt.} | 0..* 0..* +------------------+ > >> | {except Cache Mode "immediate"} |----------->| ExportingProcess | > >> | inactiveTimeout {opt.} | +------------------+ > >> | {Cache Mode "timeout" only} | > >> | activeFlows {readOnly} | > >> | inactiveFlows {readOnly} | > >> | cacheDataRecords {readOnly} | > >> | cacheDiscontinuityTime {readOnly} | > >> +-----------------------------------+ > >> > >> Figure 11: Cache class > >> > >> Figure 11 shows the Cache class that contains the configuration and > >> state parameters of a Cache. The configuration parameters of the > >> Cache class are as follows: > >> > >> cacheMode: Configures the Cache Mode. The following parameter > >> values are specified by the configuration data model: > >> * immediate: Data Records expire after the first packet > >> * timeout: Data Records expire after active or inactive timeout > >> * permanent: Data Records never expire, but are periodically > >> exported with interval set by the active timeout > >> In the case of "immediate", PSAMP Packet Reports are generated. > >> Otherwise, IPFIX Flow Records are generated. > >> > >> maxRecords: Maximum number of Data Records in the Cache. If not > >> configured by the user, the Monitoring Device sets this parameter. > >> > > > > When a cache becomes max Records, new Flow Records can be dropped or > > push the old one? Does it depend on the implementation matter? > > There are various possibilities, such as dropping or early expiration of > Flows. I do not think that we need to specify the behavior. > Ok. It is out of scope for the document. Could you please put above sentence. > >> activeTimeout: This parameter configures the active timeout in > >> milliseconds. It is not available for Cache Mode "immediate". > >> The parameter value zero indicates infinity, meaning that there is > >> no active timeout. If not configured by the user, the Monitoring > >> Device sets this parameter. > >> In the case of Cache Mode "timeout", the active timeout defines > >> the time after which a Flow Record is expired even though packets > >> matching this Flow are still received by the Cache. In the case > >> of Cache Mode "permanent", the active timeout defines the interval > >> for periodical export of Flow Records. > > > > In the case of Cache Mode "timeout", the timer for active timeout is set > > per a Flow Record. In the case of Cache Mode "permanent", the timer > > for active timeout is set per a Cache. > > > > If it is right, each meaning "active timeout" are different. Could you please > > add some explanation. > > > >> inactiveTimeout: This parameter configures the inactive timeout in > >> milliseconds. It is not available for Cache Modes "immediate" and > >> "permanent". The parameter value zero indicates infinity, meaning > >> that there is no inactive timeout. If not configured by the user, > >> the Monitoring Device sets this parameter. > >> The inactive timeout defines the time after which a Flow Record is > >> expired if no packets matching this Flow are received by the > >> Cache. > > NEW: > > activeTimeout: This parameter configures the time in milliseconds > after which a Flow Record is expired even though packets matching > this Flow are still received by the Cache. The parameter value > zero indicates infinity, meaning that there is no active timeout. > If not configured by the user, the Monitoring Device sets this > parameter. This parameter is only available for Cache Mode > "timeout". > > inactiveTimeout: This parameter configures the time in milliseconds > after which a Flow Record is expired if no packets matching this > Flow are received by the Cache. The parameter value zero > indicates infinity, meaning that there is no inactive timeout. If > not configured by the user, the Monitoring Device sets this > parameter. This parameter is only available for Cache Mode > "timeout". > > exportInterval: This parameter configures the interval for > periodical export of Flow Records in milliseconds. If not > configured by the user, the Monitoring Device sets this parameter. > It is only available for Cache Mode "permanent". > Ok, fined. > > >> > >> An object of the Cache class includes an object of the CacheLayout > >> class that defines which fields are included in the Packet Reports or > >> Flow Records. A Cache object MAY refer to one or multiple > >> ExportingProcess objects configuring different Exporting Processes. > >> > >> As state parameters, the Cache class contains the Metering Process > >> statistics activeFlows, inactiveFlows, and cacheDataRecords that > >> correspond to the objects of the ipfixMeteringProcessStatsTable of > >> the IPFIX MIB module [I-D.ietf-ipfix-mib]. > >> > > [snip] > > >> 4.4.1. Destination Class > >> > >> +------------------------------------------------+ > >> | Destination | > >> +------------------------------------------------+ > >> | name |<>-----+ > >> | exportMemberType = parallel | | 0..1 > >> | ipfixVersion = 10 | | > >> | transportProtocol | +------------+ > >> | destinationIpAddress | | Transport- | > >> | destinationPort = 4739|4740 | | Layer- | > >> | sendBufferSize {opt.} | | Security | > >> | rateLimit[0..1] | +------------+ > >> | localIpAddress[0..*] {SCTP only} | > >> | timedReliability = 0 {SCTP only} | > >> | numberOfStreams {opt.} {SCTP only} | > >> | sourceIpAddress[0..1] {UDP only} | > >> | templateRefreshTimeout = 600 {UDP only} | > >> | optionsTemplateRefreshTimeout = 600 {UDP only} | > >> | templateRefreshPacket[0..1] {UDP only} | > >> | optionsTemplateRefreshPacket[0..1] {UDP only} | > >> +------------------------------------------------+ > >> > >> Figure 14: Destination class > >> > >> The Destination class shown in Figure 14 contains the configuration > >> parameters of one export destination (i.e., Collector) the Exporting > >> Process sends IPFIX Messages to. Some of the parameters are only > >> applicable if a specific transport protocol (SCTP, UDP, or TCP) is > >> used. The following parameters apply to all transport protocols: > >> > >> exportMemberType: Configures the export member type that corresponds > >> to the ipfixTransportSessionGroupMemberType object in > >> [I-D.ietf-ipfix-mib]. The following parameter values are > >> specified by the configuration data model: > >> * primary: primary target of the Exporting Process > >> * secondary: secondary target of the Exporting Process used when > >> the primary target is not reachable > >> * parallel: parallel exporting to all destinations and files of > >> the Exporting Process > >> * loadBalancing: load-balancing between different destinations > >> and files of the Exporting Process > >> "parallel" is the default value if this parameter is not > >> configured. If one destination or file is configured as "primary" > >> target, all other destinations and files must be configured as > >> "secondary" targets. If "parallel" or "loadBalancing" is used, > >> the same type must be configured for all destinations and File > >> Writers of the Exporting Process. > >> > >> ipfixVersion: Version number of the IPFIX protocol used. If > >> omitted, the default value is 10 (=0x000a) as specified in > >> [RFC5101]. > >> > >> transportProtocol: One of "sctp", "udp", and "tcp". > >> > >> destinationIpAddress, destinationPort: Destination IP address and > >> destination port number to be used. destinationIpAddress is a > >> mandatory parameter. If destinationPort is omitted, standard port > >> 4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or DTLS) > >> is used. > >> > >> sendBufferSize: Size of the socket send buffer in bytes. > >> > >> rateLimit: Maximum number of bytes per second the Exporting Process > >> may export to the given destination as required by [RFC5476]. The > >> number of bytes is calculated from the lengths of the IPFIX > >> Messages exported. If this parameter is not configured, no rate > >> limiting is performed for this destination. > >> > >> The following parameters are applicable if SCTP is transport > >> protocol: > >> > >> localIpAddress: This optional parameter MAY appear multiple times to > >> specify the list of eligible local IP addresses of the SCTP > >> association [RFC4960]. If omitted, all locally assigned IP > >> addresses are used by the SCTP endpoint. > >> > >> timedReliability: Lifetime in milliseconds until an IPFIX Message > >> containing Data Sets only is "abandoned" due to the timed > >> reliability mechanism of PR-SCTP [RFC3758]. If this parameter is > >> set to zero, reliable SCTP transport is used. > >> > >> numberOfStreams: Number of outbound streams requested for SCTP > >> associations [RFC4960]. If not configured by the user, this > >> parameter is set by the Monitoring Device. > >> > >> The following parameters are applicable if UDP is transport protocol: > >> > >> sourceIpAddress: This parameter sets the source IP address. If this > >> parameter is omitted, the address assigned to the outgoing > >> interface is used. > >> > > I would like to make available in the case of TCP. > > We adopted this parameter because the Cisco CLI has it for UDP. As far > as I understand, it is not used to specify the outgoing interface but > the (forged) source address in the IP header only. > No. In current network operation, source IP address is important parameter as a indicator of exporting device(router). Operators are often confused that a source IP address is changed when route changes happen. Exporting device may select source address as a optimal exit points, or arbitrarily. Then, some collectors may fail to recognize identical exporting device before and after route changes. This function is necessary to avoid the confusion. > How do you want to forge the IP address of a TCP endpoint? It must > belong to the interface. > > The parameter description remains unclear in the case of multiple > addresses assigned to a single interface. > > I'm not sure what to do. > We can remove the parameter. > We can change to "...one of the addresses assigned to the outgoing > interface is used." > We can try to find a generic solution that defines the outgoing interface. I propose the following. The following parameters are applicable if TCP or UDP is transport protocol: sourceIpAddress: This parameter sets the source IP address. If this parameter is omitted, Exporter selects outgoing interface according to routing policy, and then arbitrarily assigns the address. > > >> templateRefreshTimeout, optionsTemplateRefreshTimeout, > >> templateRefreshPacket, optionsTemplateRefreshPacket: Template > >> refresh parameters when using UDP as transport protocol. > >> templateRefreshTimeout and optionsTemplateRefreshTimeout are > >> specified in seconds between resendings of (Options) Templates. > >> If omitted, the default value of 600 seconds (10 minutes) is used > >> [RFC5101]. templateRefreshPacket and optionsTemplateRefreshPacket > >> are specified in number of IPFIX Messages. If omitted, the > >> (Options) Templates are only resent after timeout. > >> > >> Using the TransportLayerSecurity class, transport layer security is > >> enabled and configured for this export destination. If the transport > >> protocol is SCTP or UDP, transport layer security is realized using > >> DTLS. In the case of TCP, TLS is used instead. > >> > > [snip] > > >> 4.7. Transport Session Class > >> > >> +------------------------------------------------------+ > >> | TransportSession | > >> +------------------------------------------------------+ > >> | exportMemberType {readOnly} {Exporting Process only} |<>----+ 0..* > >> | ipfixVersion {readOnly} | | > >> | protocol {readOnly} {except File Reader/Writer} | +----------+ > >> | sourceAddress {readOnly} {except File Reader/Writer} | | Template | > >> | destinationAddress {readOnly} | +----------+ > >> | {except File Reader/Writer} | > >> | sourcePort {readOnly} {except File Reader/Writer} | > >> | destinationPort {readOnly} | > >> | {except File Reader/Writer} | > >> | sctpAssocId {readOnly} {SCTP only} | > >> | file {readOnly} {File Reader/Writer only} | > >> | templateRefreshTimeout {readOnly} {UDP only} | > >> | optionsTemplateRefreshTimeout {readOnly} {UDP only} | > >> | templateRefreshPacket {readOnly} {UDP only} | > >> | optionsTemplateRefreshPacket {readOnly} {UDP only} | > >> | status {readOnly} | > >> | rate {readOnly} | > >> | packets {readOnly} | > >> | bytes {readOnly} | > >> | messages {readOnly} | > >> | discardedMessages {readOnly} | > >> | records {readOnly} | > >> | templates {readOnly} | > >> | optionsTemplates {readOnly} | > >> | transportSessionDiscontinuityTime {readOnly} | > >> +------------------------------------------------------+ > >> > >> Figure 21: TransportSession class > >> > >> The TransportSession class contains state data about Transport > >> Sessions originating from an Exporting Process or terminating at a > >> Collecting Process. The names and semantics of the state parameters > >> correspond to the managed objects in the ipfixTransportSessionTable > >> and ipfixTransportSessionStatsTable of the IPFIX MIB module > >> [I-D.ietf-ipfix-mib]. Hence, if these state parameters are queried > >> from the Monitoring Device, the corresponding IPFIX MIB values can be > > > > They can be queried from other management device. > > I do not understand. Are you confusing "queried from" with "queried by"? > My question is simple. Monitoring Device(Exporter and Collector) and other devices(NMS etc.) can query these state parameters. Why do you limit only the Monitoring Device? > >> returned without any further processing. The MIB object > >> ipfixTransportSessionDeviceMode is not included in the > >> TransportSession class because its value can be derived from the > >> scope in which a TransportSession object appears: exporting(1) if it > >> belongs to an Exporting Process, collecting(2) if it belongs to a > >> Collecting Process. > >> > >> The state parameter exportMemberType is only available if the > >> TransportSession class is used within the ExportingProcess class. > >> exportMemberType then contains the value of the MIB object > >> ipfixExportMemberType of the ipfixExportTable of the IPFIX MIB > >> [I-D.ietf-ipfix-mib]. > >> > > > > The Destination already has exportMemberType. What is relation between > > two object between the object in Destination class and one in this class? > > This is state data of a Transport Session, the other is configuration > data of an Exporting Process. > Ok. > >> The TransportSession class is also used for state data of File > >> Readers and File Writers. In this case, the "file" parameter > >> specifies the name and location of the file as URI. To avoid > >> ambiguities, the parameters "protocol", "sourceAddress", > >> "destinationAddress", "sourcePort", "destinationPort", and > >> "sctpAssocId" MUST NOT appear if the parameter "file" is present. > >> The parameter "file" MUST NOT appear if at least one of the > >> parameters "protocol", "sourceAddress", "destinationAddress", > >> "sourcePort", "destinationPort", and "sctpAssocId" is present. Note > >> that the parameter "file" is currently not included in the IPFIX MIB. > >> > > > > The above paragraph can be removed. Because you already have File > > Reader and Writer class. > > No. > > All these state parameters may be interesting for File Writers/Readers: > > | status {readOnly} | > | rate {readOnly} | > | packets {readOnly} | > | bytes {readOnly} | > | messages {readOnly} | > | discardedMessages {readOnly} | > | records {readOnly} | > | templates {readOnly} | > | optionsTemplates {readOnly} | > | transportSessionDiscontinuityTime {readOnly} | > > Therefore, we have a Transport Session entry for File Readers/Writers. > > Ok. Regards, Atsushi From akoba@nttv6.net Sun Jan 17 08:48:19 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11BFE3A695C for ; Sun, 17 Jan 2010 08:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.544 X-Spam-Level: * X-Spam-Status: No, score=1.544 tagged_above=-999 required=5 tests=[AWL=1.344, BAYES_00=-2.599, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTVbNUrcC1cG for ; Sun, 17 Jan 2010 08:48:18 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [192.16.178.5]) by core3.amsl.com (Postfix) with ESMTP id C631F3A6950 for ; Sun, 17 Jan 2010 08:48:17 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:49c6:a839:5244:ab54]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o0HGkxRJ028603; Mon, 18 Jan 2010 01:46:59 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 18 Jan 2010 01:44:07 +0900 From: Atsushi Kobayashi To: Atsushi Kobayashi In-Reply-To: <20091211103937.8C75.17391CF2@nttv6.net> References: <20091211014501.C13F23A6886@core3.amsl.com> <20091211103937.8C75.17391CF2@nttv6.net> Message-Id: <20100118012736.5619.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 18 Jan 2010 01:46:59 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] I-D Action:draft-ietf-ipfix-mediators-problem-statement-07.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2010 16:48:19 -0000 Dear Juergen, and all, According to minute of Hiroshima, it supposed to be submitted to IESG, after asking for objections on list. Mediation Problem Statement Kobayashi-san presenting - summary, history. New version by end November, then submit to IESG (Juergen will ask for objections on list). If no objection, could you please go to the next step. Regards, Atsushi On Fri, 11 Dec 2009 10:54:23 +0900 Atsushi Kobayashi wrote: > > Dear all, > > This is new version of Mediation Problem Statement with the changes that > solve issues raised up in 2nd WGLC. > > I appreciate Gerhard, Brian, and Sujay for your comments and suggestion > in WGLC. In the last IETF meeting, the new version was approved to > submission to IESG. Now. it is ready for IESG. > > Regards, > Atsushi > > On Thu, 10 Dec 2009 17:45:01 -0800 (PST) > 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 : IPFIX Mediation: Problem Statement > > Author(s) : A. Kobayashi, et al. > > Filename : draft-ietf-ipfix-mediators-problem-statement-07.txt > > Pages : 29 > > Date : 2009-12-10 > > > > Flow-based measurement is a popular method for various network > > monitoring usages. The sharing of flow-based information for > > monitoring applications having different requirements raises some > > open issues in terms of measurement system scalability, flow-based > > measurement flexibility, and export reliability that IPFIX Mediation > > may help resolve. This document describes some problems related to > > flow-based measurement that network administrators have been facing, > > and then describes IPFIX Mediation applicability examples along with > > the problems. > > > > Status of this Memo > > > > This Internet-Draft is submitted to IETF in full conformance with the > > provisions of BCP 78 and BCP 79. > > > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as Internet- > > Drafts. > > > > Internet-Drafts are draft documents valid for a maximum of six months > > and may be updated, replaced, or obsoleted by other documents at any > > time. It is inappropriate to use Internet-Drafts as reference > > material or to cite them other than as "work in progress." > > > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/ietf/1id-abstracts.txt. > > > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 5, 2010. > > > > Copyright Notice > > > > Copyright (c) 2009 IETF Trust and the persons identified as the > > document authors. All rights reserved. > > > > This document is subject to BCP 78 and the IETF Trust's Legal > > Provisions Relating to IETF Documents > > (http://trustee.ietf.org/license-info) in effect on the date of > > publication of this document. Please review these documents > > carefully, as they describe your rights and restrictions with respect > > to this document. Code Components extracted from this document must > > include Simplified BSD License text as described in Section 4.e of > > the Trust Legal Provisions and are provided without warranty as > > described in the BSD License. > > > > This document may contain material from IETF Documents or IETF > > Contributions published or made publicly available before November > > 10, 2008. The person(s) controlling the copyright in some of this > > material may not have granted the IETF Trust the right to allow > > modifications of such material outside the IETF Standards Process. > > Without obtaining an adequate license from the person(s) controlling > > the copyright in such materials, this document may not be modified > > outside the IETF Standards Process, and derivative works of it may > > not be created outside the IETF Standards Process, except to format > > it for publication as an RFC or to translate it into languages other > > than English. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-mediators-problem-statement-07.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. > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From Quittek@nw.neclab.eu Mon Jan 18 17:50:25 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 482513A6955; Mon, 18 Jan 2010 17:50:25 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo07loPY4bn3; Mon, 18 Jan 2010 17:50:23 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 47B993A6863; Mon, 18 Jan 2010 17:50:22 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 823662C0012C1; Tue, 19 Jan 2010 02:50:18 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDT+BOJtQ3eh; Tue, 19 Jan 2010 02:50:18 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 4720D2C0002FE; Tue, 19 Jan 2010 02:49:58 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jan 2010 01:49:57 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3346714163_34912132" Date: Tue, 19 Jan 2010 02:49:23 +0100 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: write-up for draft-ietf-ipfix-mediators-problem-statement-07 Thread-Index: AcqYqZ+3hsx/5r2aGkag3/8hMnQpgg== From: "Juergen Quittek" To: "Dan Romascanu" , "IESG Secretary" Cc: Ronald Bonica , IETF IPFIX Working Group Subject: [IPFIX] write-up for draft-ietf-ipfix-mediators-problem-statement-07 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 01:50:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3346714163_34912132 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Dan and dear IESG Secretary, Below please find the write up for draft-ietf-ipfix-mediators-problem-statement-07. The draft is ready for forwarding to the IESG for publication. Best regards, Juergen -- Juergen Quittek quittek@nw.neclab.eu Tel: +49 6221 4342-115 NEC Europe Limited, Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK Registered in England 2832014 ========================================================================== Write-up for draft-ietf-ipfix-mediators-problem-statement-07 ============================================================ (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Juergen Quittek is the document shepherd. He has reviewed it personally and believes that this version is ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document had multiple individual reviews from key WG members during two WG last calls. Several comments were made and have been addressed when updating the document after the WGLCs. The shepherd has no concern about the depth or breadth of the reviews. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? The document shepherd sees no need for an additional particular review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There is no such concern. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? 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. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There was no appeal. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document shepherd checked for ID nits. The IETF Trust Provisions Section needs to be updated, since it changed after the current version was posted. Some references need to be updated, because they have been published recently as RFCs. Also, in section 6.1 the document uses IPv4 addresses from the range 10.1.1.x in examples. These should be replaced by addresses of the ranges defined in RFC3330: 192.0.2.x, 198.51.100.x or 203.0.113.x. All of these changes can easily be made in the next update that is expected after IETF last call. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. One reference have been outdated since the document was submitted (IPFIX.MIB). This should be fixed after IETF last call. More references may need an update by then. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The document states correctly that there it has no actions for IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies an improvement to the PR-SCTP export specified in the IPFIX specifications in RFC5101. This method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, and reduced demands on the Collecting Process. Working Group Summary Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then describes IPFIX Mediation applicability examples along with the problems. Document Quality The document underwent two WG last call in the IPFIX WG. This way, a high document quality has been achieved already. Personnel Juergen Quittek is shepherding this document. Dan Romascanu is the responsible Area director. --B_3346714163_34912132 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSXGWojGLatuVYyBHij D6b442pmPzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAx MTkwMTQ5MjNaMA0GCSqGSIb3DQEBAQUABIIBACr/XF4RvJTKwrzijP9g9ua+Wu/yKzOtn0QC fuyZQvg2MKfrDDA4NFs2sbzyEMFRoeSPmnYD2iR0Yp/D715rCNhUuf+ZVKL+SbILCce2gxV0 MNV7tidDWz89Bb2QuXs4yPix2g6U4tZAi7aIbyVBKSaapr02kckLEHHjPR6mzUfso2F+Ljlx by8N4RG2/84wMUMasPDAkjRGY85YJ7CyX5ybJ+MNF8CLAXi751tXhSTvdF2dPnhUfd0kNtwf S5coTcoS4UNzNJClvqsb+IL+4YjrrlmF1Q0kHTIpjpKbszA7DCGEBjMHdBHYTbY8ErsHcgsC Epa20ab0dR7ghc30+eQ= --B_3346714163_34912132-- From Quittek@nw.neclab.eu Mon Jan 18 17:56:11 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE6E3A6812 for ; Mon, 18 Jan 2010 17:56:11 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml0582pScv-P for ; Mon, 18 Jan 2010 17:56:10 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 2CE323A6952 for ; Mon, 18 Jan 2010 17:56:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 6516A2C0012C1 for ; Tue, 19 Jan 2010 02:56:06 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kWe6pNF9n77 for ; Tue, 19 Jan 2010 02:56:06 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 2F4552C0002FE for ; Tue, 19 Jan 2010 02:56:01 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Jan 2010 01:56:00 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3346714557_34965020" Date: Tue, 19 Jan 2010 02:55:57 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [IPFIX] WG last call on draft-ietf-ipfix-configuration-model-04 Thread-Index: AcpvYRgUQbW+SV772Um/x/s4lgl5tQpSXJ5S From: "Juergen Quittek" To: "Juergen Quittek" , "IETF IPFIX Working Group" Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-configuration-model-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 01:56:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3346714557_34965020 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, I received only one review of this document during WGLC. Did I miss any review? I don't think a single review is enough to pass a WGLC successfully. Are there any volunteers for reviewing the draft? Thanks, Juergen On 27.11.09 13:56 "Juergen Quittek" wrote: > Dear all, > > At our session at Hiroshima we agreed to have working group last call > on draft-ietf-ipfix-configuration-model-04. > > The call starts today and will last until Friday December 11. > > A URL for this Internet-Draft is: > http://www.ietf.org/id/draft-ietf-ipfix-configuration-model-04.txt > > I will ask the NETMOD WG to also review the draft as soon as the > YANG specification is final. > > Please read the draft! > Please send your comments to this mailing list! > Please also send a message if you are fine with the draft as it is! > > Thank you, > > Juergen > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --B_3346714557_34965020 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSF3kJB+3CWChT0East P/Y1IpKRJDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDAx MTkwMTU1NTdaMA0GCSqGSIb3DQEBAQUABIIBAEOo4eO6gIFwOuyvBjWuP1wBH8ZLJQu6jpYG 1wFrHD7ZbxttznZ0WQq1g6SAG3mzTZuyywmKEKG61x7k2KjqbKVj35PWl1sO4+nJiTT3Sb30 u71A8BC5eDlWixivnYhYXBdUav+2EHURxcKU8uvaB2/RVSVl7qvWzbXwFhFo9WYQEU/d/urs a7HJDuDCaQbeMXW9Cbl2O30V17AnhV826XlwrQImbYd4t5az1ZQm2pHINWq6l0K+65zll5Ln B0CVZFKn7o7YuiAcfAHCCnujilu8XLj23pnnAzwdROIUsGPuM3eO5owrKloGn5HtLnVMnGkq Yp67Rvee/YvZu/n1GaM= --B_3346714557_34965020-- From n.brownlee@auckland.ac.nz Tue Jan 19 14:08:30 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFDD33A67AB for ; Tue, 19 Jan 2010 14:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPYyuhGgKWee for ; Tue, 19 Jan 2010 14:08:29 -0800 (PST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.37]) by core3.amsl.com (Postfix) with ESMTP id 8A78A3A67E1 for ; Tue, 19 Jan 2010 14:08:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9E6B1482D46 for ; Wed, 20 Jan 2010 11:08:09 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGd4xj1cjcrK for ; Wed, 20 Jan 2010 11:08:09 +1300 (NZDT) Received: from nevil-laptop.sfac.auckland.ac.nz (nevil-laptop.sfac.auckland.ac.nz [130.216.38.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 67C52482D3A for ; Wed, 20 Jan 2010 11:08:09 +1300 (NZDT) Message-ID: <4B562D49.8030205@auckland.ac.nz> Date: Wed, 20 Jan 2010 11:08:09 +1300 From: Nevil Brownlee User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: IPFIX Working Group Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 22:08:30 -0000 Forwarded as requested :-) -------- Original Message -------- Subject: questions regarding rfc 5101 implementation Date: Wed, 20 Jan 2010 09:21:52 +1300 From: Allwyn Carvalho To: ipfix@ietf.org CC: Nevil Brownlee [I have been trying to send this for some time, but my email does not make it through. Neville, can you help?. Thanks in advance.] I have a few of questions regarding RFC 5101 implementation which I don't see addressed in RFC 5153 (or at least the answer is not clear to me). Consider a Selection Process that has been configured to capture the following Information Elements (key and non-key): * sourceIPv4Address * destinationIPv4Address * protocolIdentifier * sourceTransportPort * destinationTransportPort * bgpSourceAsNumber * bgpDestinationAsNumber * flowStartMilliseconds * flowEndMilliseconds * octetDeltaCount * packetDeltaCount Clearly, all these IEs are not applicable to all flows. For example, source and destination transport port are not applicable to ICMP flows. And bgp source and/or destination AS number are not applicable if source/destination address was not learned via BGP. So, the first question is regarding the use of templates. Is an implementation supposed to maintain multiple templates for the different types of traffic? Or, is it supposed to have a single template and to use "dummy" values when a field is not applicable? I realize this could be implementation specific, but is there a guideline? Assuming the guideline is to use multiple templates, this leads me to my next question: is necessary for the Collecting process to know that the flow records (with different template ids) all come from the same Cache, and if so how will the Exporting Process ensure that this info is provided? I believe the answer to this could be to use the same Observation Domain ID in the Packet Header for all these flow records. But this leads me to the final question. Is the Observation Domain ID tied to a Cache, or is it tied to a set of Observation Points? In particular, here is the dilemma. Suppose it is required to aggregate the same packet streams onto multiple aggregation caches. Consider for example the following requirement: Cache 1: * sourceIPv4Address (key) * destinationIPv4Address (key) * flowStartMilliseconds (non-key) * flowEndMilliseconds (non-key) * octetDeltaCount (non-key) * packetDeltaCount (non-key) Cache 2: * sourceIPv4Address (key) * destinationIPv4Address (key) * bgpSourceAsNumber (key) * bgpDestinationAsNumber (key) * flowStartMilliseconds (non-key) * flowEndMilliseconds (non-key) * octetDeltaCount (non-key) * packetDeltaCount (non-key) The requirement is that every selected packet must get counted in each of the two caches. Now, when flow records are reported to the Collecting Process, should we be using the same or different Observation Domain ID for each Cache? The reason for the dilemma is that if we use a common Observation Domain ID when reporting each cache, it will not be possible for the Collecting Process to know which cache it came from. However, from RFC 5101, the Observation Domain ID is based only on the set of Observation Points, and it does not say what to do if there are multiple aggregation caches within the same Observation Domain. Here is the text from RFC 5101: Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That way, the Collecting Process can identify the specific Observation Domain from the Exporter that sends the IPFIX Messages. Every Observation Point is associated with an Observation Domain. It is RECOMMENDED that Observation Domain IDs also be unique per IPFIX Device. Final question: will the authors of RFC 5153 consider adding some language in the guidelines to address some of these issues? Thanks. Allwyn. -- --------------------------------------------------------------------- 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 Wed Jan 20 00:31:21 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0D63A68A9 for ; Wed, 20 Jan 2010 00:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2egeIYyiLq6 for ; Wed, 20 Jan 2010 00:31:19 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 90B943A67FE for ; Wed, 20 Jan 2010 00:31:18 -0800 (PST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id CDFE22E15; Wed, 20 Jan 2010 09:31:12 +0100 (CET) Message-ID: <4B56BFE2.7020704@net.in.tum.de> Date: Wed, 20 Jan 2010 09:33:38 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nevil Brownlee References: <4B562D49.8030205@auckland.ac.nz> In-Reply-To: <4B562D49.8030205@auckland.ac.nz> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050102060805080000050703" X-Virus-Scanned: ClamAV using ClamSMTP Cc: IPFIX Working Group Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 08:31:21 -0000 This is a cryptographically signed message in MIME format. --------------ms050102060805080000050703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Allwyn, Some quick answers inline. Nevil Brownlee wrote: > Forwarded as requested :-) >=20 > -------- Original Message -------- > Subject: questions regarding rfc 5101 implementation > Date: Wed, 20 Jan 2010 09:21:52 +1300 > From: Allwyn Carvalho > To: ipfix@ietf.org > CC: Nevil Brownlee >=20 > [I have been trying to send this for some time, but my email does not=20 > make it > through. Neville, can you help?. Thanks in advance.] >=20 > I have a few of questions regarding RFC 5101 implementation which I=20 > don't see > addressed in RFC 5153 (or at least the answer is not clear to me). >=20 > Consider a Selection Process that has been configured to capture the=20 > following > Information Elements (key and non-key): The Selection Process does not capture any IEs nor does it define key=20 and non-key fields. It's the Metering Process, or - as we define it in http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-04#sectio= n-4.3.1 - the Cache (as part of the Metering Process). > * sourceIPv4Address > * destinationIPv4Address > * protocolIdentifier > * sourceTransportPort > * destinationTransportPort > * bgpSourceAsNumber > * bgpDestinationAsNumber > * flowStartMilliseconds > * flowEndMilliseconds > * octetDeltaCount > * packetDeltaCount >=20 > Clearly, all these IEs are not applicable to all flows. For example,=20 > source and > destination transport port are not applicable to ICMP flows. And bgp=20 > source > and/or destination AS number are not applicable if source/destination=20 > address > was not learned via BGP. >=20 > So, the first question is regarding the use of templates. Is an=20 > implementation > supposed to maintain multiple templates for the different types of=20 > traffic? Or, > is it supposed to have a single template and to use "dummy" values when= =20 > a field > is not applicable? I realize this could be implementation specific, bu= t is > there a guideline? That is not specified in the standard, so it is implementation specific. = There is no guideline. Cisco uses dummy values in NetFlow.V9 (e.g. zero port-numbers for ICMP=20 flows). The problem is that you may have a large number of templates, which can=20 be inefficient. On the other hand, such invalid dummy values do not=20 exist for all IEs. If we use a single template, the solution will be to have a new IE which = defines a bitvector, and 1s in the bit vector indicate "valid" fields in = the record, 0s "invalid" fields (similar to flowKeyIndicator). The idea with this new IE is not mine, Paul Aitken mentioned it to me=20 some time ago. > Assuming the guideline is to use multiple templates, this leads me to m= y=20 > next > question: is necessary for the Collecting process to know that the flow= =20 > records > (with different template ids) all come from the same Cache, and if so=20 > how will > the Exporting Process ensure that this info is provided? >=20 > I believe the answer to this could be to use the same Observation Domai= n=20 > ID in > the Packet Header for all these flow records. But this leads me to the= =20 > final > question. Is the Observation Domain ID tied to a Cache, or is it tied = > to a set > of Observation Points? >=20 > In particular, here is the dilemma. Suppose it is required to aggregat= e=20 > the > same packet streams onto multiple aggregation caches. Consider for=20 > example the > following requirement: >=20 > Cache 1: >=20 > * sourceIPv4Address (key) > * destinationIPv4Address (key) > * flowStartMilliseconds (non-key) > * flowEndMilliseconds (non-key) > * octetDeltaCount (non-key) > * packetDeltaCount (non-key) >=20 > Cache 2: >=20 > * sourceIPv4Address (key) > * destinationIPv4Address (key) > * bgpSourceAsNumber (key) > * bgpDestinationAsNumber (key) > * flowStartMilliseconds (non-key) > * flowEndMilliseconds (non-key) > * octetDeltaCount (non-key) > * packetDeltaCount (non-key) >=20 > The requirement is that every selected packet must get counted in each = > of the > two caches. That is true (and the expected behavior). >=20 > Now, when flow records are reported to the Collecting Process, should w= e be > using the same or different Observation Domain ID for each Cache? The ODID specifies where the packet was observed, not the Cache! So, it=20 will be the same. >=20 > The reason for the dilemma is that if we use a common Observation Domai= n=20 > ID when > reporting each cache, it will not be possible for the Collecting Proces= s=20 > to know > which cache it came from. =20 If you know that you have configured two parallel caches, you also know=20 that you will receive two flow records for every observed flow. In this=20 case, you do not need any further information. PSAMP specifies how to report the selection sequence, but this does not=20 include the cache. Reporting internals of IPFIX metering processes has not been=20 standardized in similar detail as in PSAMP. However, you can export an=20 option template to associate flow records with the metering process ID=20 or alternatively standardize a new cacheId IE to specify a cache. It's true that the standard is not complete with this regard. In=20 practice, you will probably know the configuration of your exporters.=20 And you probably won't configure parallel caches as you propose. So, you = usually won't have this problem. Regards, Gerhard > However, from RFC 5101, the Observation > Domain ID is > based only on the set of Observation Points, and it does not say what t= o=20 > do if > there are multiple aggregation caches within the same Observation=20 > Domain. Here > is the text from RFC 5101: >=20 > Observation Domain >=20 > An Observation Domain is the largest set of Observation Points = for > which Flow information can be aggregated by a Metering Process.= > For example, a router line card may be an Observation Domain if= it > is composed of several interfaces, each of which is an Observat= ion > Point. In the IPFIX Message it generates, the Observation Doma= in > includes its Observation Domain ID, which is unique per Exporti= ng > Process. That way, the Collecting Process can identify the > specific Observation Domain from the Exporter that sends the IP= FIX > Messages. Every Observation Point is associated with an > Observation Domain. It is RECOMMENDED that Observation Domain = IDs > also be unique per IPFIX Device. >=20 > Final question: will the authors of RFC 5153 consider adding some=20 > language in > the guidelines to address some of these issues? >=20 > Thanks. > Allwyn. >=20 >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms050102060805080000050703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5 vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1 uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1 OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6 waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew 3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36 dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX 2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6 5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDEyMDA4MzMzOFowIwYJKoZIhvcNAQkEMRYEFLU7 VZkQoNw10ZyGNd2l3u3zUcJvMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQBjb0DAJdaQxcU7I6OTEnVUsueoKowbNsDYpRfNIzNPRKp+ax4eRwtt Gn2a7xzUC2C26UJGVLJkdyeQyrG3ZOvP7x64yviH7usKIU7CVXbg1qGdkseZiqDbbXQT8UEy cLDYonW8dLVDIERMQcP7hVB4SZ0iGsZ+MkqjsJd5neD94VPBDdA8Ah6duqhkCPhq/eALqUMi uoSTtvRZqklFl4zzHNer6U0EHqoH+vHP/9Q3BJH6T3PMgTqnSsocJjLC5b/74mwRSmNyQM8c VUkM8AqJDCoLPmPjSuayjjf15xHRppgQLlouyXnfDUFRZyH61YVX9tUtLRRaGkVVnZS7ISxn AAAAAAAA --------------ms050102060805080000050703-- From paitken@cisco.com Wed Jan 20 03:19:13 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DC43A69EF for ; Wed, 20 Jan 2010 03:19:13 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbKMMDNv+y+f for ; Wed, 20 Jan 2010 03:19:13 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 2081C3A6A87 for ; Wed, 20 Jan 2010 03:19:11 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAOp1VkuQ/uCWe2dsb2JhbACcAwEBFiQGpWOVP4Q2BA X-IronPort-AV: E=Sophos;i="4.49,309,1262563200"; d="scan'208";a="2602344" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 20 Jan 2010 10:49:39 +0000 Received: from [144.254.153.44] (dhcp-144-254-153-44.cisco.com [144.254.153.44]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0KBJ68H001442 for ; Wed, 20 Jan 2010 11:19:07 GMT Message-ID: <4B56E6AA.1060904@cisco.com> Date: Wed, 20 Jan 2010 11:19:06 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: ipfix@ietf.org References: <4B562D49.8030205@auckland.ac.nz> <4B56BFE2.7020704@net.in.tum.de> In-Reply-To: <4B56BFE2.7020704@net.in.tum.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 11:19:14 -0000 Gerhard, Allwyn, >> So, the first question is regarding the use of templates. Is an >> implementation supposed to maintain multiple templates for the >> different types of traffic? Or, is it supposed to have a single >> template and to use "dummy" values when a field is not applicable? >> I realize this could be implementation specific, but is there a >> guideline? > > That is not specified in the standard, so it is implementation > specific. There is no guideline. > > Cisco uses dummy values in NetFlow.V9 (e.g. zero port-numbers for > ICMP flows). > > The problem is that you may have a large number of templates, which > can be inefficient. On the other hand, such invalid dummy values do > not exist for all IEs. > > If we use a single template, the solution will be to have a new IE > which defines a bitvector, and 1s in the bit vector indicate "valid" > fields in the record, 0s "invalid" fields (similar to > flowKeyIndicator). > > The idea with this new IE is not mine, Paul Aitken mentioned it to > me some time ago. I'm planning to write a new draft to express this idea. We may use structured data rather than a bitfield to express the invalid (unobserved) fields, since there would be issues with mediators that don't understand the bitfield. The idea is not mine; Andrew Johnson mentioned it to me some time ago. >> Assuming the guideline is to use multiple templates, this leads me >> to my next question: is necessary for the Collecting process to >> know that the flow records (with different template ids) all come >> from the same Cache, I don't think so. >> and if so how will the Exporting Process ensure that this info is >> provided? >> >> I believe the answer to this could be to use the same Observation >> Domain ID in the Packet Header for all these flow records. But >> this leads me to the final question. Is the Observation Domain ID >> tied to a Cache, or is it tied to a set of Observation Points? The OD ID is related to the Observation Points. From RFC 5101: Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. A single cache could potentially observe data from multiple Metering Processes (eg, from multiple line cards). However, the key thing from the above definition is that these observations are not aggregatable - so the MP would have to keep each line card's observations separate from other line cards, eg by using the line card ID or OD ID as a key field. Clearly there's little advantage to using a single cache for this purpose; one cache per OD makes more sense. In this implementation, the OD ID and cache become synonymous. >> The reason for the dilemma is that if we use a common Observation >> Domain ID when reporting each cache, it will not be possible for >> the Collecting Process to know which cache it came from. Why is it necessary to know? >> However, from RFC 5101, the Observation Domain ID is based only on >> the set of Observation Points, and it does not say what to do if >> there are multiple aggregation caches within the same Observation >> Domain. If each cache is observing the same OD, then they would all report the same OD ID. Cheers, P. From andrjohn@cisco.com Wed Jan 20 04:08:14 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1F53A6A56 for ; Wed, 20 Jan 2010 04:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZlcg31CaAlt for ; Wed, 20 Jan 2010 04:08:14 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 946B43A6823 for ; Wed, 20 Jan 2010 04:08:13 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAAGaBVkuQ/uCWe2dsb2JhbACcAwEBFiQGpVmVQoQ2BA X-IronPort-AV: E=Sophos;i="4.49,310,1262563200"; d="scan'208";a="56321984" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Jan 2010 12:08:08 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0KC88q7012142 for ; Wed, 20 Jan 2010 12:08:08 GMT Received: from [144.254.153.30] (dhcp-144-254-153-30.cisco.com [144.254.153.30]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o0KC84X23141; Wed, 20 Jan 2010 12:08:04 GMT Message-ID: <4B56F226.2000202@cisco.com> Date: Wed, 20 Jan 2010 12:08:06 +0000 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Aitken References: <4B562D49.8030205@auckland.ac.nz> <4B56BFE2.7020704@net.in.tum.de> <4B56E6AA.1060904@cisco.com> In-Reply-To: <4B56E6AA.1060904@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 12:08:14 -0000 Paul Aitken wrote: [SNIP] > The OD ID is related to the Observation Points. From RFC 5101: > > Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an Observation Domain if it > is composed of several interfaces, each of which is an Observation > Point. > > A single cache could potentially observe data from multiple Metering > Processes (eg, from multiple line cards). However, the key thing from > the above definition is that these observations are not aggregatable - > so the MP would have to keep each line card's observations separate from > other line cards, eg by using the line card ID or OD ID as a key field. A single cache that observes data from Multiple Metering Process doesn't make sense to me, unless it is some sort of mediation device which would mean it was a Metering Process in its own right, with a new Observation Domain that was the sum of the parts. >From RFC 5470, "The typical functions of a Metering Process may include ... Maintaining database(s) of all the Flow Records from an Observation Domain." I think it's fair to say that database and cache are synonymous here. If you mean that a single "cache" is shared between multiple Metering Processes simply as a memory management model and each Metering Process is still in control of its own separate set of data, then logically each Metering Process still has its own database / cache. regards Andrew From trammell@tik.ee.ethz.ch Wed Jan 20 04:36:40 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238DA3A68F4 for ; Wed, 20 Jan 2010 04:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8rWUUM3sMLp for ; Wed, 20 Jan 2010 04:36:39 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id EA9323A6890 for ; Wed, 20 Jan 2010 04:36:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 86E3AD9394; Wed, 20 Jan 2010 13:36:33 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0G415itDK1Ec; Wed, 20 Jan 2010 13:36:33 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 50E21D936C; Wed, 20 Jan 2010 13:36:33 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4B56E6AA.1060904@cisco.com> Date: Wed, 20 Jan 2010 13:36:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79847F50-3F42-4F5D-861B-93EBC3F6C6EA@tik.ee.ethz.ch> References: <4B562D49.8030205@auckland.ac.nz> <4B56BFE2.7020704@net.in.tum.de> <4B56E6AA.1060904@cisco.com> To: Paul Aitken X-Mailer: Apple Mail (2.1077) Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 12:36:40 -0000 On Jan 20, 2010, at 12:19 PM, Paul Aitken wrote: > Gerhard, Allwyn, >=20 >>> So, the first question is regarding the use of templates. Is an >>> implementation supposed to maintain multiple templates for the >>> different types of traffic? Or, is it supposed to have a single >>> template and to use "dummy" values when a field is not applicable? >>> I realize this could be implementation specific, but is there a >>> guideline? >>=20 >> That is not specified in the standard, so it is implementation >> specific. There is no guideline. >>=20 >> Cisco uses dummy values in NetFlow.V9 (e.g. zero port-numbers for >> ICMP flows). >>=20 >> The problem is that you may have a large number of templates, which >> can be inefficient. On the other hand, such invalid dummy values do >> not exist for all IEs. >>=20 >> If we use a single template, the solution will be to have a new IE >> which defines a bitvector, and 1s in the bit vector indicate "valid" >> fields in the record, 0s "invalid" fields (similar to >> flowKeyIndicator). >>=20 >> The idea with this new IE is not mine, Paul Aitken mentioned it to >> me some time ago. >=20 > I'm planning to write a new draft to express this idea. We may use > structured data rather than a bitfield to express the invalid > (unobserved) fields, since there would be issues with mediators that > don't understand the bitfield. The idea is not mine; Andrew Johnson > mentioned it to me some time ago. I remember a conversation with Andrew, too, maybe in San Diego? Basically, "yes" to this thread, "but". I'll note that template flexibility is one of the big advantages of = IPFIX, and that I don't really buy the multiple template inefficiency = argument. In the worst case export, with multiple templates representing = the same underlying data model but omitting nulls or substituting = reduced- for full-length encoding IEs, the template switch overhead is 4 = octets per record (plus, unless you're using UDP (which you shouldn't = be) with a ridiculous template refresh time, epsilon octets per record = for additional template export). This worst case represents each record = in its own data set, and the average case is probably somewhat better = than that, especially depending on implementation and deployment = specifics such as maximum buffer delay time (which leads to messages = being exported without being MTU-sized), path MTU, and per-template = buffering.=20 A null bitfield introduces for all but the most trivial templates a 2- = to 4-octet overhead, and only allows null omission, not concurrent = export of full- and reduced-length encoded IEs. There are advantages to = the FLE/RLE switch: for a common example, consider octet and packet = count IEs, which are by default 8 octets, but in almost all flows (by = flow count, not by octet volume) can be represented with 2 or 4. This = saves 8 octets per record (16 per biflow) when allowing 4- and 8- octets = encodings, which saves 4 (12) net octets even in the pathological case, = where every other record in the stream is RLE. Of course, once you're = using this multiple-template export trick for RLS, you can apply the = same for null omission, with no implementation pain. In any case, in general we do need something better than simple dummy = values. They're okay for counters (where a 0 and a "dummy" value have = exactly the same semantics) and identifiers where the number space has = an explicit null value, probably okay in cases (such as ports) where = additional information (such as a protocolIdentifier value set to a = portless transport) allows disambiguation, and only maybe okay in cases = where protocol-specific values (think 0.0.0.0 address for DHCP) or = nonsensical ones (e.g. 0 UTC 1 January 1970) can be disambiguated with = special-casing or human intervention. Unless and until null bitfields = are available, multiple-template export is what we have. Cheers, Brian= From trammell@tik.ee.ethz.ch Wed Jan 20 04:37:22 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13E13A688F for ; Wed, 20 Jan 2010 04:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2ebJvpkZN7b for ; Wed, 20 Jan 2010 04:37:22 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 0BED73A683F for ; Wed, 20 Jan 2010 04:37:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BBFE3D9394; Wed, 20 Jan 2010 13:37:16 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id l3zSa19lIxly; Wed, 20 Jan 2010 13:37:16 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 89434D938F; Wed, 20 Jan 2010 13:37:16 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: Date: Wed, 20 Jan 2010 13:37:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E58BD98-7613-4E2B-98A8-C64422FF9DDA@tik.ee.ethz.ch> References: To: Juergen Quittek X-Mailer: Apple Mail (2.1077) Cc: IETF IPFIX Working Group Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-configuration-model-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 12:37:23 -0000 hi Juergen, all,=20 I will review the Configuration Model in the coming days, and post my = review to the list next week. Regards, Brian On Jan 19, 2010, at 2:55 AM, Juergen Quittek wrote: > Dear all, >=20 > I received only one review of this document during WGLC. > Did I miss any review? >=20 > I don't think a single review is enough to pass a WGLC > successfully.=20 >=20 > Are there any volunteers for reviewing the draft? >=20 > Thanks, >=20 > Juergen >=20 >=20 > On 27.11.09 13:56 "Juergen Quittek" wrote: >=20 >> Dear all,=20 >>=20 >> At our session at Hiroshima we agreed to have working group last call >> on draft-ietf-ipfix-configuration-model-04. >>=20 >> The call starts today and will last until Friday December 11. >>=20 >> A URL for this Internet-Draft is: >> http://www.ietf.org/id/draft-ietf-ipfix-configuration-model-04.txt >>=20 >> I will ask the NETMOD WG to also review the draft as soon as the >> YANG specification is final. >>=20 >> Please read the draft! >> Please send your comments to this mailing list! >> Please also send a message if you are fine with the draft as it is! >>=20 >> Thank you,=20 >>=20 >> Juergen=20 >> _______________________________________________ >> 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 muenz@net.in.tum.de Wed Jan 20 04:48:10 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9263A68F4 for ; Wed, 20 Jan 2010 04:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THMNaITY6DsF for ; Wed, 20 Jan 2010 04:48:09 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 630B13A6774 for ; Wed, 20 Jan 2010 04:48:09 -0800 (PST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id BEA622E15; Wed, 20 Jan 2010 13:48:03 +0100 (CET) Message-ID: <4B56FC16.5050901@net.in.tum.de> Date: Wed, 20 Jan 2010 13:50:30 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brian Trammell References: <4B562D49.8030205@auckland.ac.nz> <4B56BFE2.7020704@net.in.tum.de> <4B56E6AA.1060904@cisco.com> <79847F50-3F42-4F5D-861B-93EBC3F6C6EA@tik.ee.ethz.ch> In-Reply-To: <79847F50-3F42-4F5D-861B-93EBC3F6C6EA@tik.ee.ethz.ch> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020509060407090005040309" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 12:48:11 -0000 This is a cryptographically signed message in MIME format. --------------ms020509060407090005040309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Brian Trammell wrote: > On Jan 20, 2010, at 12:19 PM, Paul Aitken wrote: > >> Gerhard, Allwyn, >> >>>> So, the first question is regarding the use of templates. Is an >>>> implementation supposed to maintain multiple templates for the >>>> different types of traffic? Or, is it supposed to have a >>>> single template and to use "dummy" values when a field is not >>>> applicable? I realize this could be implementation specific, >>>> but is there a guideline? >>> That is not specified in the standard, so it is implementation >>> specific. There is no guideline. >>> >>> Cisco uses dummy values in NetFlow.V9 (e.g. zero port-numbers for >>> ICMP flows). >>> >>> The problem is that you may have a large number of templates, >>> which can be inefficient. On the other hand, such invalid dummy >>> values do not exist for all IEs. >>> >>> If we use a single template, the solution will be to have a new >>> IE which defines a bitvector, and 1s in the bit vector indicate >>> "valid" fields in the record, 0s "invalid" fields (similar to >>> flowKeyIndicator). >>> >>> The idea with this new IE is not mine, Paul Aitken mentioned it >>> to me some time ago. >> I'm planning to write a new draft to express this idea. We may use >> structured data rather than a bitfield to express the invalid >> (unobserved) fields, since there would be issues with mediators >> that don't understand the bitfield. The idea is not mine; Andrew >> Johnson mentioned it to me some time ago. > > I remember a conversation with Andrew, too, maybe in San Diego? > > Basically, "yes" to this thread, "but". > > I'll note that template flexibility is one of the big advantages of > IPFIX, and that I don't really buy the multiple template inefficiency > argument. In the worst case export, with multiple templates > representing the same underlying data model but omitting nulls or > substituting reduced- for full-length encoding IEs, the template > switch overhead is 4 octets per record (plus, unless you're using UDP > (which you shouldn't be) with a ridiculous template refresh time, > epsilon octets per record for additional template export). This worst > case represents each record in its own data set, and the average case > is probably somewhat better than that, especially depending on > implementation and deployment specifics such as maximum buffer delay > time (which leads to messages being exported without being > MTU-sized), path MTU, and per-template buffering. I think the argument against using many templates is that the exporting process implementation becomes more complex. With "invalid" fields, it can use a single template per cache/metering process. Without, it has to decide among multiple templates. Note that in general, I'm also not in favor of invalid fields in data records. Regards, Gerhard > A null bitfield introduces for all but the most trivial templates a > 2- to 4-octet overhead, and only allows null omission, not concurrent > export of full- and reduced-length encoded IEs. There are advantages > to the FLE/RLE switch: for a common example, consider octet and > packet count IEs, which are by default 8 octets, but in almost all > flows (by flow count, not by octet volume) can be represented with 2 > or 4. This saves 8 octets per record (16 per biflow) when allowing 4- > and 8- octets encodings, which saves 4 (12) net octets even in the > pathological case, where every other record in the stream is RLE. Of > course, once you're using this multiple-template export trick for > RLS, you can apply the same for null omission, with no implementation > pain. > > In any case, in general we do need something better than simple dummy > values. They're okay for counters (where a 0 and a "dummy" value have > exactly the same semantics) and identifiers where the number space > has an explicit null value, probably okay in cases (such as ports) > where additional information (such as a protocolIdentifier value set > to a portless transport) allows disambiguation, and only maybe okay > in cases where protocol-specific values (think 0.0.0.0 address for > DHCP) or nonsensical ones (e.g. 0 UTC 1 January 1970) can be > disambiguated with special-casing or human intervention. Unless and > until null bitfields are available, multiple-template export is what > we have. > > Cheers, > > Brian _______________________________________________ IPFIX mailing > list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --------------ms020509060407090005040309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5 vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1 uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1 OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6 waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew 3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36 dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX 2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6 5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDEyMDEyNTAzMFowIwYJKoZIhvcNAQkEMRYEFNmk pc0adSrLbShWi0hLROjWxoL2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQAunbB2slubxeAintcH1qJAjMb7I7pqaN0fh3KRZlB7BuEYpKyHRsL8 WZ7NHb8U0A3xFPoOz8Lp0fVwGXPmJr8oX8LtieKxzbDpySR+ecgg4iLaspREYHBOzF+r9xkf +mZO3feoKowogJAL+MRTpts6u7sJ1x7+jjUSyhF94ep0nOH/CoRAeziP5IDuDlzHCAjlr69w m0SMFimwNV/a4t7wIm7mBZB1WFx61P2E3SgZ+aeAFlj0I3e5SQbZLOxkzEWLcqduWE/JxSPi zSHI7GCR8NfiPJLgXOGPKHZgyo8wcLcDlNEElwT2WzudUF/JBfPgid9UBLJx7ao1LpR09vHW AAAAAAAA --------------ms020509060407090005040309-- From muenz@net.in.tum.de Wed Jan 20 04:51:10 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F693A6902 for ; Wed, 20 Jan 2010 04:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV9VHIC0HHUd for ; Wed, 20 Jan 2010 04:51:09 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id D3CA43A67AD for ; Wed, 20 Jan 2010 04:51:08 -0800 (PST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id B72F02E15; Wed, 20 Jan 2010 13:51:03 +0100 (CET) Message-ID: <4B56FCCA.5070903@net.in.tum.de> Date: Wed, 20 Jan 2010 13:53:30 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Andrew Johnson References: <4B562D49.8030205@auckland.ac.nz> <4B56BFE2.7020704@net.in.tum.de> <4B56E6AA.1060904@cisco.com> <4B56F226.2000202@cisco.com> In-Reply-To: <4B56F226.2000202@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020802050909050103090509" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 12:51:10 -0000 This is a cryptographically signed message in MIME format. --------------ms020802050909050103090509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Paul, Andrew, Andrew Johnson wrote: > Paul Aitken wrote: > [SNIP] >> The OD ID is related to the Observation Points. From RFC 5101: >> >> Observation Domain >> >> An Observation Domain is the largest set of Observation Points f= or >> which Flow information can be aggregated by a Metering Process. >> For example, a router line card may be an Observation Domain if = it >> is composed of several interfaces, each of which is an Observati= on >> Point. >> >> A single cache could potentially observe data from multiple Metering >> Processes (eg, from multiple line cards). However, the key thing from >> the above definition is that these observations are not aggregatable -= >> so the MP would have to keep each line card's observations separate fr= om >> other line cards, eg by using the line card ID or OD ID as a key field= =2E >=20 > A single cache that observes data from Multiple Metering Process doesn'= t > make sense to me, unless it is some sort of mediation device which woul= d > mean it was a Metering Process in its own right, with a new Observation= > Domain that was the sum of the parts. I'm a bit confused by the terms you use. The cache is part of the=20 Metering Process. Do you mean that a single cache should/should not=20 account packets from multiple selection processes? Regards, Gerhard > From RFC 5470, "The typical functions of a Metering Process may include= > ... Maintaining database(s) of all the Flow Records from an Observation= > Domain." >=20 > I think it's fair to say that database and cache are synonymous here. >=20 > If you mean that a single "cache" is shared between multiple Metering > Processes simply as a memory management model and each Metering Process= > is still in control of its own separate set of data, then logically > each Metering Process still has its own database / cache. >=20 > regards >=20 > Andrew >=20 > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms020802050909050103090509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5 vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1 uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1 OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6 waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew 3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36 dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX 2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6 5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDEyMDEyNTMzMFowIwYJKoZIhvcNAQkEMRYEFD/q EJZeJNF0Ingq9wGEj0rF/VpFMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQAMsvzj1OZ+7x3BrVJnI6qZ3tIzFoW2TLYIEOPUGoj5/0llZjjcSqO+ 4qh7LHHVi6V0nPgKQSVkeIbRZEjEx4C3YdaNdPUTVJ8H4Bj23oOr1diSiBUlTfotH5KyYqPx ybvffWKWPUWso0zVJpRI8E8XBY1cwzJNlpvn0HUS/cPqr0EWW0H2qB/YCKJOGenZKndx31SW r8CJ0JVgZTOpylDiM4/oSgsotHgOiVzMscHCZ1aC7Az1RMiJydczodr3x658Wp/LZSbrHe4q nD+4iXbxrjlC2Jj197WgMABvc/H9xZvNu5oSaZsKtzF52H7bJGhGnCnogJATH3RlgGcHx4V3 AAAAAAAA --------------ms020802050909050103090509-- From trammell@tik.ee.ethz.ch Wed Jan 20 05:08:10 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213703A6902 for ; Wed, 20 Jan 2010 05:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaplSn3o513U for ; Wed, 20 Jan 2010 05:08:09 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by core3.amsl.com (Postfix) with ESMTP id 1EBB53A67AD for ; Wed, 20 Jan 2010 05:08:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C6529D9369; Wed, 20 Jan 2010 14:07:59 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DU8fSrt049fL; Wed, 20 Jan 2010 14:07:59 +0100 (MET) Received: from pb-10072.ethz.ch (pb-10072.ethz.ch [82.130.103.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7649DD9333; Wed, 20 Jan 2010 14:07:59 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Brian Trammell In-Reply-To: <4B56FC16.5050901@net.in.tum.de> Date: Wed, 20 Jan 2010 14:07:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0D25674C-17B0-454B-85E4-3FF720910060@tik.ee.ethz.ch> References: <4B562D49.8030205@auckland.ac.nz> <4B56BFE2.7020704@net.in.tum.de> <4B56E6AA.1060904@cisco.com> <79847F50-3F42-4F5D-861B-93EBC3F6C6EA@tik.ee.ethz.ch> <4B56FC16.5050901@net.in.tum.de> To: Gerhard Muenz X-Mailer: Apple Mail (2.1077) Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 13:08:10 -0000 hi Gerhard, On Jan 20, 2010, at 1:50 PM, Gerhard Muenz wrote: >=20 > Brian, >=20 > Brian Trammell wrote: >> On Jan 20, 2010, at 12:19 PM, Paul Aitken wrote: >>> Gerhard, Allwyn, >>>>> So, the first question is regarding the use of templates. Is an >>>>> implementation supposed to maintain multiple templates for the >>>>> different types of traffic? Or, is it supposed to have a >>>>> single template and to use "dummy" values when a field is not >>>>> applicable? I realize this could be implementation specific, >>>>> but is there a guideline? >>>> That is not specified in the standard, so it is implementation = specific. There is no guideline. >>>> Cisco uses dummy values in NetFlow.V9 (e.g. zero port-numbers for >>>> ICMP flows). >>>> The problem is that you may have a large number of templates, >>>> which can be inefficient. On the other hand, such invalid dummy >>>> values do not exist for all IEs. >>>> If we use a single template, the solution will be to have a new >>>> IE which defines a bitvector, and 1s in the bit vector indicate >>>> "valid" fields in the record, 0s "invalid" fields (similar to = flowKeyIndicator). >>>> The idea with this new IE is not mine, Paul Aitken mentioned it >>>> to me some time ago. >>> I'm planning to write a new draft to express this idea. We may use = structured data rather than a bitfield to express the invalid = (unobserved) fields, since there would be issues with mediators >>> that don't understand the bitfield. The idea is not mine; Andrew >>> Johnson mentioned it to me some time ago. >> I remember a conversation with Andrew, too, maybe in San Diego? >> Basically, "yes" to this thread, "but". >> I'll note that template flexibility is one of the big advantages of >> IPFIX, and that I don't really buy the multiple template inefficiency >> argument. In the worst case export, with multiple templates >> representing the same underlying data model but omitting nulls or >> substituting reduced- for full-length encoding IEs, the template >> switch overhead is 4 octets per record (plus, unless you're using UDP >> (which you shouldn't be) with a ridiculous template refresh time, >> epsilon octets per record for additional template export). This worst >> case represents each record in its own data set, and the average case >> is probably somewhat better than that, especially depending on >> implementation and deployment specifics such as maximum buffer delay >> time (which leads to messages being exported without being >> MTU-sized), path MTU, and per-template buffering. >=20 > I think the argument against using many templates is that the = exporting process implementation becomes more complex. > With "invalid" fields, it can use a single template per cache/metering = process. Without, it has to decide among multiple templates. This is a point. In stripped-down EPs, the difference between one and = two templates is a big deal. In slightly more complicated ones, the = difference between two and three is trivial. It's been a while since I = looked at the code for this, but YAF does it with maybe ten lines of C, = looking at the record and choosing an appropriate template ID (which, = coincidentally, is calculated as a bitmap of which features the record = has...) But yes, the null-bitmap field is a good idea, if _only_ for the = simple-EP case. > Note that in general, I'm also not in favor of invalid fields in data = records. this, I already knew. :) Cheers, Brian From andrjohn@cisco.com Wed Jan 20 05:52:05 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17FAF3A6A0F for ; Wed, 20 Jan 2010 05:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmkbUB4UoOdv for ; Wed, 20 Jan 2010 05:52:04 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 9931B3A6938 for ; Wed, 20 Jan 2010 05:52:03 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIAABKZVkuQ/uCWe2dsb2JhbACcAwEBFiQGpX+VTIQ2BA X-IronPort-AV: E=Sophos;i="4.49,310,1262563200"; d="scan'208";a="2608714" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-2.cisco.com with ESMTP; 20 Jan 2010 13:22:30 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0KDpwJK009119; Wed, 20 Jan 2010 13:51:58 GMT Received: from [144.254.153.30] (dhcp-144-254-153-30.cisco.com [144.254.153.30]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o0KDpvX01372; Wed, 20 Jan 2010 13:51:57 GMT Message-ID: <4B570A80.20809@cisco.com> Date: Wed, 20 Jan 2010 13:52:00 +0000 From: Andrew Johnson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Brian Trammell References: <4B562D49.8030205@auckland.ac.nz> <4B56BFE2.7020704@net.in.tum.de> <4B56E6AA.1060904@cisco.com> <79847F50-3F42-4F5D-861B-93EBC3F6C6EA@tik.ee.ethz.ch> <4B56FC16.5050901@net.in.tum.de> <0D25674C-17B0-454B-85E4-3FF720910060@tik.ee.ethz.ch> In-Reply-To: <0D25674C-17B0-454B-85E4-3FF720910060@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 13:52:05 -0000 Brian Trammell wrote: > hi Gerhard, > > On Jan 20, 2010, at 1:50 PM, Gerhard Muenz wrote: > >> Brian, >> >> Brian Trammell wrote: >>> On Jan 20, 2010, at 12:19 PM, Paul Aitken wrote: >>>> Gerhard, Allwyn, >>>>>> So, the first question is regarding the use of templates. Is an >>>>>> implementation supposed to maintain multiple templates for the >>>>>> different types of traffic? Or, is it supposed to have a >>>>>> single template and to use "dummy" values when a field is not >>>>>> applicable? I realize this could be implementation specific, >>>>>> but is there a guideline? >>>>> That is not specified in the standard, so it is implementation specific. There is no guideline. >>>>> Cisco uses dummy values in NetFlow.V9 (e.g. zero port-numbers for >>>>> ICMP flows). >>>>> The problem is that you may have a large number of templates, >>>>> which can be inefficient. On the other hand, such invalid dummy >>>>> values do not exist for all IEs. >>>>> If we use a single template, the solution will be to have a new >>>>> IE which defines a bitvector, and 1s in the bit vector indicate >>>>> "valid" fields in the record, 0s "invalid" fields (similar to flowKeyIndicator). >>>>> The idea with this new IE is not mine, Paul Aitken mentioned it >>>>> to me some time ago. >>>> I'm planning to write a new draft to express this idea. We may use structured data rather than a bitfield to express the invalid (unobserved) fields, since there would be issues with mediators >>>> that don't understand the bitfield. The idea is not mine; Andrew >>>> Johnson mentioned it to me some time ago. >>> I remember a conversation with Andrew, too, maybe in San Diego? >>> Basically, "yes" to this thread, "but". >>> I'll note that template flexibility is one of the big advantages of >>> IPFIX, and that I don't really buy the multiple template inefficiency >>> argument. In the worst case export, with multiple templates >>> representing the same underlying data model but omitting nulls or >>> substituting reduced- for full-length encoding IEs, the template >>> switch overhead is 4 octets per record (plus, unless you're using UDP >>> (which you shouldn't be) with a ridiculous template refresh time, >>> epsilon octets per record for additional template export). This worst >>> case represents each record in its own data set, and the average case >>> is probably somewhat better than that, especially depending on >>> implementation and deployment specifics such as maximum buffer delay >>> time (which leads to messages being exported without being >>> MTU-sized), path MTU, and per-template buffering. >> I think the argument against using many templates is that the exporting process implementation becomes more complex. >> With "invalid" fields, it can use a single template per cache/metering process. Without, it has to decide among multiple templates. > > This is a point. In stripped-down EPs, the difference between one and two templates is a big deal. In slightly more complicated ones, the difference between two and three is trivial. It's been a while since I looked at the code for this, but YAF does it with maybe ten lines of C, looking at the record and choosing an appropriate template ID (which, coincidentally, is calculated as a bitmap of which features the record has...) > > But yes, the null-bitmap field is a good idea, if _only_ for the simple-EP case. No bitmaps! I'm really don't think they're a good idea. Since they can only be interpreted within the context of the record they are currently in, then each stage of flow handling that can manipulate that context has to understand these fields or, worse than simply losing the information, the fields become misleading. Look at the way the "flowKeyIndicator" field is supposed to be used. An option template is sent that shows you how to interpret a different template! For example, imagine a mediation device that accepts records from several sources, perhaps does some filtering, and then adds a "source ID" to each flow before passing them on to a central collector. We can't expect this simple device to understand every new "bitmask" field that gets invented. Consider a simple collector that stores the flows in a big database, for later interpretation. The only data that is lost in the process is the order the received fields are in. This is enough to make the bitmask fields useless. Cheers Andrew >> Note that in general, I'm also not in favor of invalid fields in data records. > > this, I already knew. :) > > Cheers, > > Brian > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix From akoba@nttv6.net Thu Jan 21 18:53:49 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550F13A67F8 for ; Thu, 21 Jan 2010 18:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiSjvk2ouv1w for ; Thu, 21 Jan 2010 18:53:48 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 5155A3A67F6 for ; Thu, 21 Jan 2010 18:53:47 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:917c:2661:31eb:bcf4]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o0LEV1n4061468; Thu, 21 Jan 2010 23:31:01 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 21 Jan 2010 23:27:46 +0900 From: Atsushi Kobayashi To: Andrew Johnson , ipfix@ietf.org In-Reply-To: <4B570A80.20809@cisco.com> References: <0D25674C-17B0-454B-85E4-3FF720910060@tik.ee.ethz.ch> <4B570A80.20809@cisco.com> Message-Id: <20100121232647.3FB7.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 21 Jan 2010 23:31:02 +0900 (JST) Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 02:53:49 -0000 Hi Andrew, and all, On Wed, 20 Jan 2010 13:52:00 +0000 Andrew Johnson wrote: [snip] > > This is a point. In stripped-down EPs, the difference between one and two templates is a big deal. In slightly more complicated ones, the difference between two and three is trivial. It's been a while since I looked at the code for this, but YAF does it with maybe ten lines of C, looking at the record and choosing an appropriate template ID (which, coincidentally, is calculated as a bitmap of which features the record has...) > > > > But yes, the null-bitmap field is a good idea, if _only_ for the simple-EP case. > I agree to export the information whatever bitmap or structured-data. There have already been issues in our flow measurement operation. For example, when the value of origin ASN is 0, we cannot see if it comes from null AS path in BGP routedb or if the destination address cannot be found in BGP routedb that is bogon. It is a big difference. > No bitmaps! I'm really don't think they're a good idea. Since they can only > be interpreted within the context of the record they are currently in, then each > stage of flow handling that can manipulate that context has to understand these > fields or, worse than simply losing the information, the fields become misleading. > > Look at the way the "flowKeyIndicator" field is supposed to be used. An option > template is sent that shows you how to interpret a different template! > > For example, imagine a mediation device that accepts records from several sources, > perhaps does some filtering, and then adds a "source ID" to each flow before > passing them on to a central collector. We can't expect this simple device to > understand every new "bitmask" field that gets invented. > > Consider a simple collector that stores the flows in a big database, for later > interpretation. The only data that is lost in the process is the order the > received fields are in. This is enough to make the bitmask fields useless. > I think the bit field for "invalid/valid" depends on its own flow. Thus, this information needs to be included in a flow record. I assume your proposal is to export the information as optional separated data. But, I cannot come up with your detailed idea. Could you explain more? Regards, Atsushi > Cheers > > Andrew > > > >> Note that in general, I'm also not in favor of invalid fields in data records. > > > > this, I already knew. :) > > > > Cheers, > > > > Brian > > > > _______________________________________________ > > 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 --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From akoba@nttv6.net Thu Jan 21 18:53:56 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDCF13A6874 for ; Thu, 21 Jan 2010 18:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEZrOfzJd4m4 for ; Thu, 21 Jan 2010 18:53:56 -0800 (PST) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 0A57D3A6864 for ; Thu, 21 Jan 2010 18:53:55 -0800 (PST) Received: from [10.10.10.20] ([IPv6:2001:fa8:1000:0:917c:2661:31eb:bcf4]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o0L5XZw6058781; Thu, 21 Jan 2010 14:33:35 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Thu, 21 Jan 2010 14:30:21 +0900 From: Atsushi Kobayashi To: Andrew Johnson In-Reply-To: <4B570A80.20809@cisco.com> References: <0D25674C-17B0-454B-85E4-3FF720910060@tik.ee.ethz.ch> <4B570A80.20809@cisco.com> Message-Id: <20100121134842.3FA8.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Thu, 21 Jan 2010 14:33:36 +0900 (JST) Cc: ipfix@ietf.org Subject: Re: [IPFIX] [Fwd: questions regarding rfc 5101 implementation] X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 02:53:57 -0000 Hi Andrew, and all, On Wed, 20 Jan 2010 13:52:00 +0000 Andrew Johnson wrote: [snip] > > This is a point. In stripped-down EPs, the difference between one and two templates is a big deal. In slightly more complicated ones, the difference between two and three is trivial. It's been a while since I looked at the code for this, but YAF does it with maybe ten lines of C, looking at the record and choosing an appropriate template ID (which, coincidentally, is calculated as a bitmap of which features the record has...) > > > > But yes, the null-bitmap field is a good idea, if _only_ for the simple-EP case. > I agree to export the information whatever bitmap or structured-data. There have already been issues in our flow measurement operation. For example, when the value of origin ASN is 0, we cannot see if it comes from null AS path in BGP routedb or if the destination address cannot be found in BGP routedb that is bogon. It is a big difference. > No bitmaps! I'm really don't think they're a good idea. Since they can only > be interpreted within the context of the record they are currently in, then each > stage of flow handling that can manipulate that context has to understand these > fields or, worse than simply losing the information, the fields become misleading. > > Look at the way the "flowKeyIndicator" field is supposed to be used. An option > template is sent that shows you how to interpret a different template! > > For example, imagine a mediation device that accepts records from several sources, > perhaps does some filtering, and then adds a "source ID" to each flow before > passing them on to a central collector. We can't expect this simple device to > understand every new "bitmask" field that gets invented. > > Consider a simple collector that stores the flows in a big database, for later > interpretation. The only data that is lost in the process is the order the > received fields are in. This is enough to make the bitmask fields useless. > I think the bit field for "invalid/valid" depends on its own flow. Thus, this information needs to be included in a flow record. I assume your proposal is to export the information as optional separated data. But, I cannot come up with your detailed idea. Could you explain more? Regards, Atsushi > Cheers > > Andrew > > > >> Note that in general, I'm also not in favor of invalid fields in data records. > > > > this, I already knew. :) > > > > Cheers, > > > > Brian > > > > _______________________________________________ > > 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 --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From muenz@net.in.tum.de Fri Jan 22 09:02:39 2010 Return-Path: X-Original-To: ipfix@core3.amsl.com Delivered-To: ipfix@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552F128C0CF for ; Fri, 22 Jan 2010 09:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_63=0.6, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NPvBh7qBaYa for ; Fri, 22 Jan 2010 09:02:36 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 6C5653A6950 for ; Fri, 22 Jan 2010 09:02:34 -0800 (PST) Received: from [131.159.20.108] (repulse.net.in.tum.de [131.159.20.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id A91B4955; Fri, 22 Jan 2010 18:02:27 +0100 (CET) Message-ID: <4B59DAB8.8040705@net.in.tum.de> Date: Fri, 22 Jan 2010 18:04:56 +0100 From: Gerhard Muenz User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Atsushi Kobayashi References: <20091210164010.8C60.17391CF2@nttv6.net> <4B41D811.6040009@net.in.tum.de> <20100118012652.1E15.17391CF2@nttv6.net> In-Reply-To: <20100118012652.1E15.17391CF2@nttv6.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030106060203000408090305" X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipfix@ietf.org Subject: Re: [IPFIX] WGLC comments on draft-ietf-ipfix-configuration-model-04 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 17:02:39 -0000 This is a cryptographically signed message in MIME format. --------------ms030106060203000408090305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Atsushi, Please find answers to your comments inline. Regards, Gerhard Atsushi Kobayashi wrote: > Hi Gerhard, >=20 > Sorry for late reply. > Please see in-line. >=20 >>>> 1. Introduction >>>> >>>> IPFIX and PSAMP compliant Monitoring Devices (routers, switches, >>>> monitoring probes, Collectors etc.) offer various configuration >>>> possibilities that allow adapting network monitoring to the goals= and >>>> purposes of the application, such as accounting and charging, tra= ffic >>>> analysis, performance monitoring, security monitoring. The use o= f a >>>> common vendor-independent configuration data model for IPFIX and >>>> PSAMP compliant Monitoring Devices facilitates network management= and >>>> configuration, especially if Monitoring Devices of different >>>> implementers and/or manufacturers are deployed simultaneously. O= n >>>> the one hand, a vendor-independent configuration data model helps= >>>> storing and managing the configuration data of Monitoring Devices= in >>>> a consistent format. On the other hand, it can be used for local= and >>>> remote configuration of Monitoring Devices. However, this requir= es >>>> that Monitoring Devices natively support the configuration data >>>> model, or that a mapping between the configuration data model and= the >>>> device-specific representation of configuration data is provided.= >>>> >>> I want to confirm the meaning of "mapping" in last sentence. >>> If a vender deploy the different configuration model at first, does i= t >>> need to replace them with the common configuration data? >> No. >> >> "Mapping between the configuration data model and device-specific=20 >> configuration data" means that CDM parameters must correspond to=20 >> device-specific parameters. If this is fulfilled, the CDM can be easi= ly=20 >> converted into the device-specific data (CLI, XML, or whatever) and vi= ce=20 >> versa. On the other hand, if the device-specific parameters have a ve= ry=20 >> different meaning, a conversion is not possible (or at least difficult= ). >> >> Side note: The conversion can be realized at different places, for exa= mple: >> - in the management system >> - on the device by running an agent >> >> What shall we do with the last sentence "However,...."? >> Remove it? >> >=20 > Is it better to remove the following? >=20 > "or that a mapping between the configuration data model and the > device-specific representation of configuration data is provided." Ok. >>>> The purpose of this document is the specification of a vendor- >>>> independent configuration data model that covers the commonly >>>> available configuration parameters of Selection Processes, Caches= , >>>> Exporting Processes, and Collecting Processes. The configuration= >>>> data model is defined using UML (Unified Modeling Language) class= >>>> diagrams [UML] while the actual configuration data is encoded in >>>> Extensible Markup Language (XML) [W3C.REC-xml-20040204]. An XML >>>> document conforming to the configuration data model contains the >>>> configuration data of one Monitoring Device. In order to ensure >>>> compatibility with the NETCONF protocol [RFC4741], YANG >>>> [I-D.ietf-netmod-yang] is used as the modeling language. If >>>> required, the YANG specification of the configuration data model = can >>>> be converted into XML Schema language [W3C.REC-xmlschema-0-200410= 28] >>>> using the pyang tool [YANG-WEB]. YANG provides mechanisms to ada= pt >>>> the configuration data model to device-specific constraints and t= o >>>> augment the model with additional device-specific or vendor-speci= fic >>>> parameters. >>>> >>>> For the configuration of remote Monitoring Devices, an appropriat= e >>>> protocol is needed to transfer the XML encoded configuration data= =2E >>>> The configuration data model is compatible with the NETCONF proto= col >>>> [RFC4741]. However, alternative protocols, such as the Simple Ob= ject >>>> Access Protocol (SOAP) [W3C.REC-soap12-part1-20070427], are also >>>> suitable for transferring XML data from a network management syst= em >>>> to a Monitoring Device. >>>> >> [snip] >> >>>> 2. Terminology >> [snip] >> >>>> In addition to the existing IPFIX and PSAMP terminology, the >>>> following terms are defined: >>>> >>>> Cache: The Cache is a functional block in a Metering Process whi= ch >>>> maintains IPFIX Flow Records or PSAMP Packet Reports. Accordi= ng >>>> to [RFC5101], the maintenance of Flow Records may include crea= ting >>>> new records, updating existing ones, computing Flow statistics= , >>>> deriving further Flow properties, detecting Flow expiration, >>>> passing Flow Records to the Exporting Process, and deleting Fl= ow >>>> Records. The maintenance of Packet Reports covers the same se= t of >>>> functions. >>> In the case of PSAMP Packet Reports, how is the Cache used in Meterin= g >>> Process? Is a PSAMP Packet Report maintained in Cache until deriving >>> further properties? It seems an implementation matter. >> The only difference between a PSAMP Packet Report and an IPFIX Flow=20 >> Record is that the Packet Report always carries information about a=20 >> single packet while the Flow Record may contain information about=20 >> multiple packets. >> >> The CDM always includes a Cache as part of the Metering Process, even = if=20 >> Packet Reports are generated, because this is the place where the fiel= ds=20 >> contained in the record are defined. The Cache Mode specifies the=20 >> expiration policy and thus whether one or multiple packets are include= d=20 >> in a record. >> >> Is there a need to clarify the definition of Cache? >> > Yes. >=20 > In the case of Packet Reports, the current Cache definition does not > clarify what functions Cache has. NEW: Cache: The Cache is a functional block in a Metering Process which generates IPFIX Flow Records or PSAMP Packet Reports from a Selected Packet Stream, in accordance with its configuration. If Flow Records are generated, the Cache performs tasks like creating= new records, updating existing ones, computing Flow statistics, deriving further Flow properties, detecting Flow expiration, passing Flow Records to the Exporting Process, and deleting Flow Records. If Packet Reports are generated, the Cache performs tasks like extracting packet contents and derived packet properties from the Selected Packet Stream, creating new records, and passing them as Packet Reports to the Exporting Process. Is this ok? >>>> Cache Layout: The Cache Layout defines the superset of fields th= at >>>> are included in the Packet Reports or Flow Records maintained = by >>>> the Cache. The fields are specified by the corresponding >>>> Information Elements. In general, the largest possible subset= of >>>> the specified fields is derived for every Packet Report or Flo= w >>>> Record. More specific rules about which fields must be includ= ed >>>> are given in Section 4.3.1. >>>> >>>> Cache Mode: The Cache Mode specifies whether Packet Reports or F= low >>>> Records are generated by the Cache. In the case of Flow Recor= ds, >>>> it also specifies the Flow expiration policy. >>>> >>>> Monitoring Device: A Monitoring Device implements at least one o= f >>>> the functional blocks specified in the context of IPFIX or PSA= MP. >>>> In particular, the term Monitoring Device encompasses Exporter= s, >>>> Collectors, IPFIX Devices, and PSAMP Devices. >>>> >>>> Selected Packet Stream: The Selected Packet Stream is the set of= all >>>> packets selected by a Selection Process. >>>> Beyond the basic Metering Process shown in Figure 1, the >>>> configuration data model enables the specification of more comple= x >>>> configurations. A single Cache may process the output of multipl= e >>>> Selection Processes. The Selected Packet Stream may be copied to= >>> I cannot image that a single cache process the output from multiple S= election >>> Process. This sentence seems cause the inconsistency to the >>> definition of Observation Domain, when a Metering Process consisting = of >>> a sequence of Selection Processes and Cahce. >> I do not understand your point. If there is any inconsistency, please= =20 >> explain it to me. >> >=20 > When a single cache processes the input from multiple Selection Process= es, > it is not clear what components compose a single Metering Process. >=20 > Observed > Packet ----> Selection Process#1 -+ > Stream | > +----> Cache#1 ---> > Observed | > Packet ----> Selection Process#2 -+ > Stream =20 > =20 > If you mean SP#1, SP#2, and Cahce#1 compose Metering Process#1, Observe= d > packets at different Observation Domains can enter the same Metering > Process. >=20 > Or you mean SP#1 and Cahce#1 compose Metering Process#1, and SP#2 and > Cache#1 compose Metering Process#2? Your example is a single Metering Process. > On the other hand, in the following case, SP#1, Cache#1 and Cache#2 > compose MP#1, or SP#1 and Cache#1 compose MP#1 and SP#1 and Cache#2 > compose MP#2? >=20 >=20 > Observed > Packet ----> Selection Process#1 -+----> Cache#1 ---> Flow > Stream | > +----> Cache#2 ---> Packet >=20 > Could you clarify which components compose a single MP in complicated > cases? Again, a single Metering Process. The text says: In a Monitoring Device implementation, the functionality of the Metering Process is commonly split into packet Sampling and Filtering= functions performed by Selection Processes, and the maintenance of Flow Records and Packet Reports performed by Caches. It talks about Caches (plural), so there is no limitation. What do you think about adding this sentence: A Metering Process may be composed of multiple Selection Processes and multiple Caches. >>> And I have another question. Are Selection Processes after Cahce >>> available as an IPFIX Mediation?=20 >> No. This RFC will not cover IPFPIX Mediation. >> > Ok. >=20 > Have you already mentioned somewhere that the output of a Cache can not= > be input of another Selection Process and Cache? The text says: As defined in [RFC5476], the Selection Process takes the Observed Packet Stream as its input and selects a subset of that stream as its output (Selected Packet Stream). So, it should be clear that a Selection Process cannot process Flow=20 Records nor Packet Reports. Regarding the Cache, see the new definition proposed above: Cache: The Cache is a functional block in a Metering Process which generates IPFIX Flow Records or PSAMP Packet Reports from a Selected Packet Stream, in accordance with its configuration. So, it should be clear that a Cache takes a Selected Packet Stream as=20 its input, not Flow Records or Packet Reports. This is also shown in Figur 1. >>>> enter several Caches, for example one Cache that generates Flow >>>> Records and another Cache that generates Packet Reports. Selecti= on >>>> Processes can also be cascaded, such that the Selected Packet Str= eam >>>> at the output of one Selection Process is passed to another Selec= tion >>>> Process. Cascading Selection Processes can be useful in specific= >>>> contexts such as the example in Section 7.3. >>>> >>>> The selection of parameters in the configuration data model is ba= sed >>>> on configuration issues discussed in the IPFIX and PSAMP document= s >>>> [RFC3917], [RFC5101], [RFC5470], [RFC5476], [RFC5474], and [RFC54= 75]. >>>> Furthermore, the structure and content of the IPFIX MIB module >>>> [I-D.ietf-ipfix-mib] and the PSAMP MIB module [I-D.ietf-psamp-mib= ] >>>> have been taken into consideration. Consistency between the >>>> configuration data model and the IPFIX and PSAMP MIB modules is a= n >>>> intended goal. Therefore, parameters in the configuration data m= odel >>>> are named according to corresponding managed objects. Certain IP= FIX >>>> MIB objects containing state data have been adopted as state >>>> parameters in the configuration data model. State parameters can= not >>>> be configured, yet their values can be queried from the Monitorin= g >>>> Device. >>> They can be queried from other devices as well as Monitoring Device. >> I do not understand. Why shall a Monitoring Device query state=20 >> information from another Monitoring Device? >=20 > I would like to say that generally other device(NMS or etc) as well as > Monitoring Device can query state parameters. Yes, NMS may query state parameters. Shall put this as an example? State parameters cannot be configured, yet their values can be queried from the Monitoring Device, for example by a network management station (NMS). > I am not sure why you limits only Monitoring Device on this.=20 > But, it is minor question. I think that you misunderstand the phrase. It does NOT say: "their values can be queried BY the Monitoring Device" >>>> The next section explains how UML class diagrams are deployed to >>>> illustrate the structure of the configuration data model. >>>> Thereafter, Section 3.2 and Section 3.3 explain the class diagram= s >>>> for the configuration of Exporters and Collectors, respectively. >>>> Each of the presented classes contains specific configuration >>>> parameters which are specified in Section 4. The formal definiti= on >>>> of the configuration data model in YANG is given in Section 6. >>>> Section 7 illustrates the usage of the model with example >>>> configurations in XML. Section 5 gives a short introduction to Y= ANG >>>> concepts that allow adapting the configuration data model to the >>>> capabilities of a device. >>>> >=20 > [snip] >=20 >>>> 3.2. Exporter Configuration >>>> >>>> Figure 4 below shows the main classes of the configuration data m= odel >>>> which are involved in the configuration of an IPFIX or PSAMP >>>> Exporter. The role of the classes can be briefly summarized as >>>> follows: >>>> >>>> o The ObservationPoint class specifies an Observation Point (i.e= =2E, >>>> an interface or linecard) of the Monitoring Device at which >>>> packets are captured for traffic measurements. An object of t= he >>>> ObservationPoint class may be associated with one or more obje= cts >>>> of the SelectionProcess class configuring Selection Processes = that >>>> process the observed packets in parallel. As long as an >>>> ObservationPoint object is specified without any references to= >>>> SelectionProcess objects, the Observation Point is not deploye= d >>>> for traffic measurements. >>>> >>>> o The SelectionProcess class contains the configuration paramete= rs >>>> of a Selection Process. The Selection Process may be composed= of >>>> a single Selector or a sequence of Selectors, defining a Primi= tive >>>> or Composite Selector, respectively. >>>> >>>> The Selection Process selects packets from an Observed Packet >>>> Stream originating from one or multiple Observation Points. >>>> Therefore, a SelectionProcess object MAY be referred to from >>>> multiple ObservationPoint objects. The corresponding Observat= ion >>>> Points must belong to the same Observation Domain. >>> The Selection Process after Cache handles the Flow Records or Packet >>> Reports, not packets. >> All Selection Process are located in front of a Cache, not behind. >> >=20 > Ok, please put above sentense in this document somewhere. See comment above. With the new term definition of Cache (which mentions Selected Packet=20 Stream), I hope that this is clear now. >>>> 4.2. SelectionProcess Class >>>> >>>> +--------------------------------+ >>>> | SelectionProcess | >>>> +--------------------------------+ 1..* +----------+ >>>> | name |<>----------| Selector | >>>> | selectionSequenceId {readOnly} | +----------+ >>>> | | 0..* >>>> | |<---+ >>>> | | | >>>> | |----+ >>>> | | 0..* >>>> | | >>>> | | 0..* 0..* +----------+ >>>> | |----------->| Cache | >>>> +--------------------------------+ +----------+ >>>> >>>> Figure 7: SelectionProcess class >>>> >>>> Figure 7 shows the SelectionProcess class. The SelectionProcess >>>> class contains the configuration parameters of a Selection Proces= s >>>> which selects packets from the Observed Packet Stream at its inpu= t >>>> and outputs the Selected Packet Stream to one or multiple other >>>> Selection Processes or Caches. A non-empty ordered list defines = a >>>> sequence of Selectors. The actions defined by the Selectors are >>>> applied to the stream of incoming packet in the specified order. >>>> >>>> The state parameter selectionSequenceId contains the Selection >>>> Sequence ID (i.e., the value of the Information Element >>>> selectionSequenceId [RFC5477]) which is assigned by the Monitorin= g >>>> Device. The Selection Sequence ID MUST be unique within the >>>> Observation Domain as required by [RFC5477]. >>>> >>>> The output of one Selection Process MAY be processed by other >>>> Selection Processes. Therefore, the SelectionProcess class allow= s >>>> references to itself, meaning that one SelectionProcess object MA= Y >>>> refer to other SelectionProcess objects. >>>> >>>> A SelectionProcess object MAY include references to one or more >>>> objects of the Cache class configuring Caches that receive the >>>> Selected Packet Stream and generate corresponding Packet Reports = or >>>> Flow Records. >>> If SelectionProcess class embodies the function of Metering Process, = I >>> prefer the name of MeteringProcess class instead of SelectionProcess >>> from the consistency with IPFIX-MIB. >> I do not understand. SelectonProcess class corresponds to=20 >> ipfixSelectionProcessTable in the IPFIX-MIB. >> >=20 > In IPFIX-MIB, there is ipfixMeteringProcessTable related to Metering > Process. On the other hand, IPFIX-CONFIG does not have some object whos= e > name comes from Metering Process. Reader might look for it. > > And also, as I previously mentioned, it is not clear about the relation= > among MP, SP, and Cache in complicated cases. See my proposed changes above. > Could you add some Metering Process object, or describe clearly the > relation? We decided not to add any Metering Process class to the model because=20 there are no parameters to configure. Another problem is that no other object would refer to a MeteringProcess = object. ObservationPoint objects refer to explicit SelectionProcess=20 objects. That cannot be changed. >>>> 4.2.1. Selector Class >>>> >>>> +--------------------------------------+ >>>> | Selector | >>>> +--------------------------------------+ 1 +---------------= --+ >>>> | name |<>------+ SelectAll/ = | >>>> | selectorId {readOnly} | | SampCountBased= / | >>>> | packetsObserved {readOnly} | | SampTimeBased/= | >>>> | packetsDropped {readOnly} | | SampRandOutOfN= / | >>>> | selectorDiscontinuityTime {readOnly} | | SampUniProb/ = | >>>> | | | FilterMatch/ = | >>>> | | | FilterHash/ = | >>>> +--------------------------------------+ +---------------= --+ >>>> >>>> Figure 8: Selector class >>>> >>>> The Selector class in Figure 8 contains the configuration and sta= te >>>> parameters of a Selector. Standardized PSAMP Sampling and Filter= ing >>>> methods are described in [RFC5475]; their configuration parameter= s >>>> are specified in corresponding sampler (SampCountBased, >>>> SampTimeBased, SampRandOutOfN, SampUniProb) or filter (FilterMatc= h, >>>> FilterHash) classes. In addition, the SelectAll class, which has= no >>>> parameters, is used for a Selector that selects all packets. The= >>>> Selector class includes exactly one of these sampler and filter >>>> classes, depending on the applied method. >>>> >>>> The state parameter selectorId contains the Selector ID (i.e., th= e >>>> value of the Information Element selectorId [RFC5477]) assigned b= y >>>> the Monitoring Device. The Selector ID MUST be unique within the= >>>> Observation Domain as required by [RFC5477]. >>>> >>>> As state parameters, the Selector class contains the Selector >>>> statistics packetsObserved and packetsDropped that correspond to = the >>>> objects of the ipfixSelectorStatsTable in the IPFIX MIB module >>>> [I-D.ietf-ipfix-mib]. >>>> >> [snip] >> >>>> 4.2.3. Filter Classes >>>> >>>> +--------------------------+ >>>> | FilterMatch | >>>> +--------------------------+ >>>> | ieId/ieName | >>>> | ieEnterpriseNumber[0..1] | >>>> | value | >>>> +--------------------------+ >>>> >>>> +--------------------------+ >>>> | FilterHash | >>>> +--------------------------+ 1..* +---------------+ >>>> | hashFunction =3D BOB |<>-------| SelectedRange | >>>> | ipPayloadOffset =3D 0 | +---------------+ >>>> | ipPayloadSize =3D 8 | | name | >>>> | digestOutput =3D false | | min | >>>> | initialiserValue[0..1] | | max | >>>> +--------------------------+ +---------------+ >>>> >>>> Figure 10: Filter classes >>>> >>>> The Filter classes in Figure 10 contain the configuration paramet= ers >>>> of specific Filtering methods. For property match filtering, the= >>>> configuration parameters are: >>>> >>>> ieId, ieName, ieEnterpriseNumber: The property to be matched is >>>> specified by either ieId or ieName, specifying the ID or name = of >>>> the Information Element, respectively. ieEnterpriseNumber MUST= be >>>> used for enterprise-specific Information Elements. If >>>> ieEnterpriseNumber is omitted or zero, this is Information Ele= ment >>>> is not enterprise-specific but registered at IANA. >>>> >>>> value: Matching value. >>>> >>> Can the ranges of value be defined like hash value? >> No. The reason is that min/max fields are not specified in the Select= or=20 >> Report Interpretation: >> http://tools.ietf.org/html/rfc5476#section-6.5.2.5 >> >> In the case of FilterHash, we do min/max fields in the Selector Report= =20 >> Interpretation: >> http://tools.ietf.org/html/rfc5476#section-6.5.2.6 >> >>> And, I would like to specify its instruction, "match" or "unmatch". >> This is not specified in the Selector Report Interpretation. Therefore= ,=20 >> we cannot allow configuring this. >> >=20 > Above all, they apparently would be required from viewpoint of usabilit= y. I agree. But this is not the document to solve this problem. > Please see http://tools.ietf.org/html/rfc5475#section-6.1 that describe= d > it as an extension of the basic model. >=20 > Implementor will add above functions because only exact match is too > poor. In that case, can IPFIX-CONFIG expand to add these functions?=20 > How does it expand? The model can be extensible by vendors or in later revisions of the model= =2E >>>> For hash-based filtering, the configuration parameters are: >>>> >>>> hashFunction: Hash function to be used. The following parameter= >>>> values are defined by the configuration data model: >>>> * BOB: BOB Hash Function as specified in [RFC5475], Appendix = A.2 >>>> * IPSX: IP Shift-XOR (IPSX) Hash Function as specified in >>>> [RFC5475], Appendix A.1 >>>> * CRC: CRC-32 function as specified in [RFC1141] >>>> Default value is "BOB". >>>> >>>> ipPayloadOffset, ipPayloadSize: ipPayloadOffset and ipPayloadSiz= e >>>> configure the offset and the size of the payload section used = as >>>> input to the hash function. Default values are 0 and 8, >>>> respectively, corresponding to the minimum configurable values= >>>> according to [RFC5476], Section 6.2.5.6. These parameters >>>> correspond to the Information Elements hashIPPayloadOffset and= >>>> hashIPPayloadSize [RFC5477]. >>>> >>>> digestOutput: digestOutput enables or disables the inclusion of = the >>>> packet digest in the resulting PSAMP Packet Report. This requ= ires >>>> that the Cache Layout of the Cache generating the Packet Repor= ts >>>> includes a digestHashValue field. This parameter corresponds = to >>>> the Information Element hashDigestOutput [RFC5477]. >>>> >>>> initialiserValue: Initializer value to the hash function. This >>>> parameter corresponds to the Information Element >>>> hashInitialiserValue [RFC5477]. If not configured by the user= , >>>> the monitoring device arbitrarily chooses an initializer value= =2E >>>> >>>> One or more ranges of matching hash values are defined by the min= and >>>> max parameters of the SelectedRange subclass. These parameters >>>> correspond to the Information Elements hashSelectedRangeMin and >>>> hashSelectedRangeMax [RFC5477]. >>>> >>>> 4.3. Cache Class >>>> >>>> +-----------------------------------+ >>>> | Cache | >>>> +-----------------------------------+ 1 +-------------+ >>>> | name |<>----------| CacheLayout | >>>> | cacheMode | +-------------+ >>>> | maxRecords {opt.} | >>>> | activeTimeout {opt.} | 0..* 0..* +---------------= ---+ >>>> | {except Cache Mode "immediate"} |----------->| ExportingProce= ss | >>>> | inactiveTimeout {opt.} | +---------------= ---+ >>>> | {Cache Mode "timeout" only} | >>>> | activeFlows {readOnly} | >>>> | inactiveFlows {readOnly} | >>>> | cacheDataRecords {readOnly} | >>>> | cacheDiscontinuityTime {readOnly} | >>>> +-----------------------------------+ >>>> >>>> Figure 11: Cache class >>>> >>>> Figure 11 shows the Cache class that contains the configuration a= nd >>>> state parameters of a Cache. The configuration parameters of the= >>>> Cache class are as follows: >>>> >>>> cacheMode: Configures the Cache Mode. The following parameter >>>> values are specified by the configuration data model: >>>> * immediate: Data Records expire after the first packet >>>> * timeout: Data Records expire after active or inactive timeo= ut >>>> * permanent: Data Records never expire, but are periodically >>>> exported with interval set by the active timeout >>>> In the case of "immediate", PSAMP Packet Reports are generated= =2E >>>> Otherwise, IPFIX Flow Records are generated. >>>> >>>> maxRecords: Maximum number of Data Records in the Cache. If not= >>>> configured by the user, the Monitoring Device sets this parame= ter. >>>> >>> When a cache becomes max Records, new Flow Records can be dropped or >>> push the old one? Does it depend on the implementation matter? >> There are various possibilities, such as dropping or early expiration = of=20 >> Flows. I do not think that we need to specify the behavior. >> > Ok. It is out of scope for the document. Could you please put above se= ntence. NEW: maxRecords: Maximum number of Data Records in the Cache. If the Cache stores this number of Data Records, no additional record can= be created before any of the existing records is removed. If not configured by the user, the Monitoring Device sets this parameter. Is this ok? >>>> An object of the Cache class includes an object of the CacheLayou= t >>>> class that defines which fields are included in the Packet Report= s or >>>> Flow Records. A Cache object MAY refer to one or multiple >>>> ExportingProcess objects configuring different Exporting Processe= s. >>>> >>>> As state parameters, the Cache class contains the Metering Proces= s >>>> statistics activeFlows, inactiveFlows, and cacheDataRecords that >>>> correspond to the objects of the ipfixMeteringProcessStatsTable o= f >>>> the IPFIX MIB module [I-D.ietf-ipfix-mib]. >>>> >> [snip] >> >>>> 4.4.1. Destination Class >>>> >>>> +------------------------------------------------+ >>>> | Destination | >>>> +------------------------------------------------+ >>>> | name |<>-----+ >>>> | exportMemberType =3D parallel | | 0..= 1 >>>> | ipfixVersion =3D 10 | | >>>> | transportProtocol | +----------= --+ >>>> | destinationIpAddress | | Transport= - | >>>> | destinationPort =3D 4739|4740 | | Layer- = | >>>> | sendBufferSize {opt.} | | Security = | >>>> | rateLimit[0..1] | +----------= --+ >>>> | localIpAddress[0..*] {SCTP only} | >>>> | timedReliability =3D 0 {SCTP only} | >>>> | numberOfStreams {opt.} {SCTP only} | >>>> | sourceIpAddress[0..1] {UDP only} | >>>> | templateRefreshTimeout =3D 600 {UDP only} | >>>> | optionsTemplateRefreshTimeout =3D 600 {UDP only} | >>>> | templateRefreshPacket[0..1] {UDP only} | >>>> | optionsTemplateRefreshPacket[0..1] {UDP only} | >>>> +------------------------------------------------+ >>>> >>>> Figure 14: Destination class >>>> >>>> The Destination class shown in Figure 14 contains the configurati= on >>>> parameters of one export destination (i.e., Collector) the Export= ing >>>> Process sends IPFIX Messages to. Some of the parameters are only= >>>> applicable if a specific transport protocol (SCTP, UDP, or TCP) i= s >>>> used. The following parameters apply to all transport protocols:= >>>> >>>> exportMemberType: Configures the export member type that corresp= onds >>>> to the ipfixTransportSessionGroupMemberType object in >>>> [I-D.ietf-ipfix-mib]. The following parameter values are >>>> specified by the configuration data model: >>>> * primary: primary target of the Exporting Process >>>> * secondary: secondary target of the Exporting Process used w= hen >>>> the primary target is not reachable >>>> * parallel: parallel exporting to all destinations and files = of >>>> the Exporting Process >>>> * loadBalancing: load-balancing between different destination= s >>>> and files of the Exporting Process >>>> "parallel" is the default value if this parameter is not >>>> configured. If one destination or file is configured as "prim= ary" >>>> target, all other destinations and files must be configured as= >>>> "secondary" targets. If "parallel" or "loadBalancing" is used= , >>>> the same type must be configured for all destinations and File= >>>> Writers of the Exporting Process. >>>> >>>> ipfixVersion: Version number of the IPFIX protocol used. If >>>> omitted, the default value is 10 (=3D0x000a) as specified in >>>> [RFC5101]. >>>> >>>> transportProtocol: One of "sctp", "udp", and "tcp". >>>> >>>> destinationIpAddress, destinationPort: Destination IP address an= d >>>> destination port number to be used. destinationIpAddress is a >>>> mandatory parameter. If destinationPort is omitted, standard = port >>>> 4739 (IPFIX without TLS and DTLS) or 4740 (IPFIX over TLS or D= TLS) >>>> is used. >>>> >>>> sendBufferSize: Size of the socket send buffer in bytes. >>>> >>>> rateLimit: Maximum number of bytes per second the Exporting Proc= ess >>>> may export to the given destination as required by [RFC5476]. = The >>>> number of bytes is calculated from the lengths of the IPFIX >>>> Messages exported. If this parameter is not configured, no ra= te >>>> limiting is performed for this destination. >>>> >>>> The following parameters are applicable if SCTP is transport >>>> protocol: >>>> >>>> localIpAddress: This optional parameter MAY appear multiple time= s to >>>> specify the list of eligible local IP addresses of the SCTP >>>> association [RFC4960]. If omitted, all locally assigned IP >>>> addresses are used by the SCTP endpoint. >>>> >>>> timedReliability: Lifetime in milliseconds until an IPFIX Messag= e >>>> containing Data Sets only is "abandoned" due to the timed >>>> reliability mechanism of PR-SCTP [RFC3758]. If this parameter= is >>>> set to zero, reliable SCTP transport is used. >>>> >>>> numberOfStreams: Number of outbound streams requested for SCTP >>>> associations [RFC4960]. If not configured by the user, this >>>> parameter is set by the Monitoring Device. >>>> >>>> The following parameters are applicable if UDP is transport proto= col: >>>> >>>> sourceIpAddress: This parameter sets the source IP address. If = this >>>> parameter is omitted, the address assigned to the outgoing >>>> interface is used. >>>> >>> I would like to make available in the case of TCP. >> We adopted this parameter because the Cisco CLI has it for UDP. As fa= r=20 >> as I understand, it is not used to specify the outgoing interface but = >> the (forged) source address in the IP header only. >> > No. In current network operation, source IP address is important > parameter as a indicator of exporting device(router). Operators are > often confused that a source IP address is changed when route changes > happen. Exporting device may select source address as a optimal exit po= ints, or > arbitrarily. Then, some collectors may fail to recognize identical > exporting device before and after route changes. > > This function is necessary to avoid the confusion. I will ask Benoit how this parameter is used. >> How do you want to forge the IP address of a TCP endpoint? It must=20 >> belong to the interface. >> >> The parameter description remains unclear in the case of multiple=20 >> addresses assigned to a single interface. >> >> I'm not sure what to do. >> We can remove the parameter. >> We can change to "...one of the addresses assigned to the outgoing=20 >> interface is used." >> We can try to find a generic solution that defines the outgoing interf= ace. >=20 > I propose the following. >=20 > The following parameters are applicable if TCP or UDP is transport > protocol: >=20 > sourceIpAddress: This parameter sets the source IP address.=20 > If this parameter is omitted, Exporter selects outgoing interface > according to routing policy, and then arbitrarily assigns the address. You cannot use an arbitrary source IP address with TCP. >>>> templateRefreshTimeout, optionsTemplateRefreshTimeout, >>>> templateRefreshPacket, optionsTemplateRefreshPacket: Template >>>> refresh parameters when using UDP as transport protocol. >>>> templateRefreshTimeout and optionsTemplateRefreshTimeout are >>>> specified in seconds between resendings of (Options) Templates= =2E >>>> If omitted, the default value of 600 seconds (10 minutes) is u= sed >>>> [RFC5101]. templateRefreshPacket and optionsTemplateRefreshPac= ket >>>> are specified in number of IPFIX Messages. If omitted, the >>>> (Options) Templates are only resent after timeout. >>>> >>>> Using the TransportLayerSecurity class, transport layer security = is >>>> enabled and configured for this export destination. If the trans= port >>>> protocol is SCTP or UDP, transport layer security is realized usi= ng >>>> DTLS. In the case of TCP, TLS is used instead. >>>> >> [snip] >> >>>> 4.7. Transport Session Class >>>> >>>> +------------------------------------------------------+ >>>> | TransportSession | >>>> +------------------------------------------------------+ >>>> | exportMemberType {readOnly} {Exporting Process only} |<>----+ 0= =2E.* >>>> | ipfixVersion {readOnly} | | >>>> | protocol {readOnly} {except File Reader/Writer} | +-------= ---+ >>>> | sourceAddress {readOnly} {except File Reader/Writer} | | Templa= te | >>>> | destinationAddress {readOnly} | +-------= ---+ >>>> | {except File Reader/Writer} | >>>> | sourcePort {readOnly} {except File Reader/Writer} | >>>> | destinationPort {readOnly} | >>>> | {except File Reader/Writer} | >>>> | sctpAssocId {readOnly} {SCTP only} | >>>> | file {readOnly} {File Reader/Writer only} | >>>> | templateRefreshTimeout {readOnly} {UDP only} | >>>> | optionsTemplateRefreshTimeout {readOnly} {UDP only} | >>>> | templateRefreshPacket {readOnly} {UDP only} | >>>> | optionsTemplateRefreshPacket {readOnly} {UDP only} | >>>> | status {readOnly} | >>>> | rate {readOnly} | >>>> | packets {readOnly} | >>>> | bytes {readOnly} | >>>> | messages {readOnly} | >>>> | discardedMessages {readOnly} | >>>> | records {readOnly} | >>>> | templates {readOnly} | >>>> | optionsTemplates {readOnly} | >>>> | transportSessionDiscontinuityTime {readOnly} | >>>> +------------------------------------------------------+ >>>> >>>> Figure 21: TransportSession class >>>> >>>> The TransportSession class contains state data about Transport >>>> Sessions originating from an Exporting Process or terminating at = a >>>> Collecting Process. The names and semantics of the state paramet= ers >>>> correspond to the managed objects in the ipfixTransportSessionTab= le >>>> and ipfixTransportSessionStatsTable of the IPFIX MIB module >>>> [I-D.ietf-ipfix-mib]. Hence, if these state parameters are queri= ed >>>> from the Monitoring Device, the corresponding IPFIX MIB values ca= n be >>> They can be queried from other management device. >> I do not understand. Are you confusing "queried from" with "queried b= y"? >> >=20 > My question is simple. >=20 > Monitoring Device(Exporter and Collector) and other devices(NMS etc.) > can query these state parameters. Why do you limit only the > Monitoring Device? It's a misunderstanding. See reply above. >>>> returned without any further processing. The MIB object >>>> ipfixTransportSessionDeviceMode is not included in the >>>> TransportSession class because its value can be derived from the >>>> scope in which a TransportSession object appears: exporting(1) if= it >>>> belongs to an Exporting Process, collecting(2) if it belongs to a= >>>> Collecting Process. --=20 Dipl.-Ing. Gerhard M=FCnz Chair for Network Architectures and Services (I8) Technische Universit=E4t M=FCnchen - Department of Informatics Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany Phone: +49 89 289-18008 Fax: +49 89 289-18033 E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz --------------ms030106060203000408090305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO5jCC BEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1 MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNl IGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnf rOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs +Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVch rKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjf aLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOB/zCB/DASBgNV HRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEFBQcC ARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWwzLTIwNDgt MTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAoMCagJKAihiBo dHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOBgQA8o9oC YzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aTi55u uUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBUowggQyoAMCAQICEF0kYdlVNx5E1qcmxun5IrswDQYJKoZI hvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEg Tm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1 YnNjcmliZXIgQ0EgLSBHMjAeFw0xMDAxMDIwMDAwMDBaFw0xMTAxMDIyMzU5NTlaMIIBEzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdv cmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBi eSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEz MDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRYw FAYDVQQDFA1HZXJoYXJkIE11ZW56MSIwIAYJKoZIhvcNAQkBFhNtdWVuekBuZXQuaW4udHVt LmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAl/YDW9cnAXJjesGhwtGwj9JN IHWXQ7QA18s+wGZNsQY0k4eKBeLTk/RAiC1hP+uQAXLoGQHQF/ljjQCQeRmnsN6w04iAzKVo Ru+NP7Y6ipn8uztx+z0Y3w43CO+LWUudp3PIF3+Fm2zwsAFXj/IYy/8Kq6m9+nQgYO/D4HoN DDR3//GepXghK0x93gR0GCkm8pgKINHNBD47/IZbDe/cIpAC9HaoxCeLiB1QaCDIYPIrJ0Vx kk0crAA0tPaMDjdSQTmNRAn2P+7Wg7K+DLvauBHfxLs8PrsolI+XdwiBu6henK9nPxvtoHmm mfxcdslKLbS9Xz2rHxi6PVVgv1ubWwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0w OzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQBPU7OeWNo2LRzsdu/RuuAk L5cj/RzeZ0xv9q4K/eosy9dRu45XACpPvb0fjc3u/dsY4m3jDqzUsB02IrrnF9jpEo10BJPw b/RZ7NaU7jC/gEknL3bSXiD2PVwL4ZI5ChH5+TJUboWhVh+FpOwOfP/yKk7wQM/46iXXzRIz enk0rcJp71k4aQgQTML3/8MDeD6TUipuQwQMY9n6T6DsNd/6JpGa+x9ZX4HIEG6+EWwQ85G5 vGfDBaq3dFrksHE75u7b7pf75wm9HIFU2SDHP2tymTHJt/XM9sqP1URIC57s+uZV0/d5KRc1 uPcJ0FAnAiC9o7ybPIh27shiq0FvOEwfMIIFSjCCBDKgAwIBAgIQXSRh2VU3HkTWpybG6fki uzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBv ZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMB4XDTEwMDEwMjAwMDAwMFoXDTExMDEwMjIzNTk1 OVowggETMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNl cnZpY2UxFjAUBgNVBAMUDUdlcmhhcmQgTXVlbnoxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCX9gNb1ycBcmN6 waHC0bCP0k0gdZdDtADXyz7AZk2xBjSTh4oF4tOT9ECILWE/65ABcugZAdAX+WONAJB5Gaew 3rDTiIDMpWhG740/tjqKmfy7O3H7PRjfDjcI74tZS52nc8gXf4WbbPCwAVeP8hjL/wqrqb36 dCBg78Pgeg0MNHf/8Z6leCErTH3eBHQYKSbymAog0c0EPjv8hlsN79wikAL0dqjEJ4uIHVBo IMhg8isnRXGSTRysADS09owON1JBOY1ECfY/7taDsr4Mu9q4Ed/Euzw+uyiUj5d3CIG7qF6c r2c/G+2geaaZ/Fx2yUottL1fPasfGLo9VWC/W5tbAgMBAAGjgcwwgckwCQYDVR0TBAIwADBE BgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAE9Ts55Y2jYt HOx279G64CQvlyP9HN5nTG/2rgr96izL11G7jlcAKk+9vR+Nze792xjibeMOrNSwHTYiuucX 2OkSjXQEk/Bv9Fns1pTuML+ASScvdtJeIPY9XAvhkjkKEfn5MlRuhaFWH4Wk7A58//IqTvBA z/jqJdfNEjN6eTStwmnvWThpCBBMwvf/wwN4PpNSKm5DBAxj2fpPoOw13/omkZr7H1lfgcgQ br4RbBDzkbm8Z8MFqrd0WuSwcTvm7tvul/vnCb0cgVTZIMc/a3KZMcm39cz2yo/VREgLnuz6 5lXT93kpFzW49wnQUCcCIL2jvJs8iHbuyGKrQW84TB8xggTsMIIE6AIBATCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcy AhBdJGHZVTceRNanJsbp+SK7MAkGBSsOAwIaBQCgggLOMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDEyMjE3MDQ1NlowIwYJKoZIhvcNAQkEMRYEFO2F JTj1atq+hDHC/+RBu/Vv4sKgMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw NTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBdJGHZVTceRNanJsbp+SK7 MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMy VGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMgIQXSRh2VU3HkTWpybG6fkiuzANBgkq hkiG9w0BAQEFAASCAQBKpKZpcUHm5vWUb0iLfkLvsR0rM0RDQdwk0znNgTylzr2WwzVpiVe4 24k5CJlObBL62fzVDN+M1ZvY2nsbeQ2mt+yC298kHTJ7RPMhKm94TCu7RjxcZqCd5u6SJ9SE iJ067dq/zdRNzGRT4cZeSLHoOY/XK8efm4Rj7KzfuCDqt768DQr6rCrfxWcWwUZHhGBiXVie AlrOESEBQNxZ0OEf3o9ovLlEPbwbOVHkC/xw8yPfl0CZeZAM6vVPkjVpVjUuHkOX3jzncmXq V4jjSyBgepo5CMt8jY4DxLsPkPZuClAoNcXDPSC0cDIHx+osl71EDqRtz20UAbLSY4IG2o4v AAAAAAAA --------------ms030106060203000408090305--