From nobody Thu Apr 2 13:36:55 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091891A1A63 for ; Thu, 2 Apr 2015 13:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22sUjyR8eh9u for ; Thu, 2 Apr 2015 13:36:48 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223AB1A1A5A for ; Thu, 2 Apr 2015 13:36:48 -0700 (PDT) Received: from [192.168.2.26] (f053233063.adsl.alicedsl.de [78.53.233.63]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 3A6BA191C88C; Thu, 2 Apr 2015 22:36:45 +0200 (CEST) Message-ID: <551DA857.2050104@net.in.tum.de> Date: Thu, 02 Apr 2015 22:36:39 +0200 From: Gerhard Muenz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Petr Velan References: <54AC4097.1050602@plixer.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080809030505030005090800" Archived-At: Cc: ipfix@ietf.org Subject: Re: [IPFIX] NetFlow v9 to IPFIX conversion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 20:36:55 -0000 This is a multi-part message in MIME format. --------------080809030505030005090800 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Petr, I do not understand the use case of the new PEN that you suggest. It does not make sense to register a PEN for an ID space that is not centrally managed in a kind of registry because uniqueness of ID usage must be ensured. Usually, the owner of a PEN maintains such a registry. Is there a registry that lists all vendor specific Netflow 9 Field Types? If not, how can you be sure that there are no collisions in the ID space? I think that you need to find and use the PENs of the vendors that have defined the additional Netflow 9 Field Types IEs, regardless of whether the IDs are below or above 2^15. Unfortunately, there is no PEN for general experimental use (at least I have not found any) that you could use as a fallback if you do not find an appropriate vendor PEN. If you want to use your own non-standard IEs, then you should use the PEN of your organization: 8057 CESNET CESNET masters team masters&cesnet.cz Maybe, you can also use this PEN to map Field Types for which you do not find a vendor. Regards, Gerhard On 26.03.2015 08:14, Petr Velan wrote: > Hi Andrew, all, > > thank you for your explanation regarding nprobe. > > However, we also need a fallback for unknown exporters with IEs > > 2^15. The generic requests for PENs need organization name, contact > name and email address. I can try to request the PEN for NetFlow v9 > compatibility myself, but I'd like it to be more public. Therefore, I > suggest to complete the request with something like: > *Organization Name*: NetFlow v9 to IPFIX > *Contact Name*: IPFIX WG > *Contact E-Mail: *ipfix@ietf.org > > This is just a first proposal to get things moving, please add your > thoughts. Once the PEN is granted, we can move forward and explain its > purpose in a short RFC. > > Petr > > On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren > wrote: > > Hi Petr, > > On 01/06/2015 07:03 AM, Petr Velan wrote: >> Hello all, >> >> I'm not sure whether this is the right place to ask, but we >> encountered following problem when converting NetFlow v9 messages >> to IPFIX. >> >> Some vendors (I've heard of ntop) are using elements IDs large >> than 32767 in NetFlow v9. When converting messages with these >> elements to IPFIX, they are considered to be Enterprise Numbers. >> To generate proper IPFIX message, we need to do one of the following: >> a) Generate a list of the elements and map them to PEN of the >> correct vendor. However, this would result in an attempt to cover >> all possible elements that anybody used in NetFlow v9. Moreover, >> we would still have to somehow handle the cases where the element >> is unknown > This should help with ntop/nprobe > > Recent versions of nprobe (since version 5.5.5 I think) all use > the following mapping. > > PEN = 35632 and IPFIXID = (v9ID - 57472) > > For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION > 57667. The IPFIX equivalent would be > MYSQL_SERVER_VERSION(35632/195). > > The nprobe docs have a complete list. > > Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but > later allocated in IANA. There is no good way to convert those v9 > exports to IPFIX. > > -Andrew > > >> b) Request a PEN for NetFlow compatibility and just add this PEN >> for every element that has ID larger than 32767. >> >> Personally, I believe that the b) is more general and >> error-prone. Do you think, that it would be possible to dedicate >> whole PEN to this cause? >> >> Thank you for any opinions, >> >> Petr Velan >> >> >> >> _______________________________________________ >> 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 --------------080809030505030005090800 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Petr,

I do not understand the use case of the new PEN that you suggest.

It does not make sense to register a PEN for an ID space that is not centrally managed in a kind of registry because uniqueness of ID usage must be ensured. Usually, the owner of a PEN maintains such a registry.

Is there a registry that lists all vendor specific Netflow 9 Field Types?
If not, how can you be sure that there are no collisions in the ID space?

I think that you need to find and use the PENs of the vendors that have defined the additional Netflow 9 Field Types IEs, regardless of whether the IDs are below or above 2^15. Unfortunately, there is no PEN for general experimental use (at least I have not found any) that you could use as a fallback if you do not find an appropriate vendor PEN.

If you want to use your own non-standard IEs, then you should use the PEN of your organization:

8057
  CESNET
    CESNET masters team
      masters&cesnet.cz

Maybe, you can also use this PEN to map Field Types for which you do not find a vendor.

Regards,
Gerhard
 

On 26.03.2015 08:14, Petr Velan wrote:
Hi Andrew, all,

thank you for your explanation regarding nprobe.

However, we also need a fallback for unknown exporters with IEs > 2^15. The generic requests for PENs need organization name, contact name and email address. I can try to request the PEN for NetFlow v9 compatibility myself, but I'd like it to be more public. Therefore, I suggest to complete the request with something like:
Organization Name: NetFlow v9 to IPFIX
Contact Name: IPFIX WG
Contact E-Mail: ipfix@ietf.org

This is just a first proposal to get things moving, please add your thoughts. Once the PEN is granted, we can move forward and explain its purpose in a short RFC.

Petr

On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren <andrewf@plixer.com> wrote:
Hi Petr,

On 01/06/2015 07:03 AM, Petr Velan wrote:
Hello all,

I'm not sure whether this is the right place to ask, but we encountered following problem when converting NetFlow v9 messages to IPFIX.

Some vendors (I've heard of ntop) are using elements IDs large than 32767 in NetFlow v9. When converting messages with these elements to IPFIX, they are considered to be Enterprise Numbers. To generate proper IPFIX message, we need to do one of the following:
a) Generate a list of the elements and map them to PEN of the correct vendor. However, this would result in an attempt to cover all possible elements that anybody used in NetFlow v9. Moreover, we would still have to somehow handle the cases where the element is unknown
 This should help with ntop/nprobe

Recent versions of nprobe (since version 5.5.5 I think) all use the following mapping.

PEN = 35632 and IPFIXID = (v9ID - 57472)

For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION 57667.  The IPFIX equivalent would be
MYSQL_SERVER_VERSION(35632/195).

The nprobe docs have a complete list.

Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but later allocated in IANA.  There is no good way to convert those v9 exports to IPFIX.

-Andrew
b) Request a PEN for NetFlow compatibility and just add this PEN for every element that has ID larger than 32767.

Personally, I believe that the b) is more general and error-prone. Do you think, that it would be possible to dedicate whole PEN to this cause?

Thank you for any opinions,

Petr Velan



 
_______________________________________________
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

--------------080809030505030005090800-- From prashant.upadhyaya@aricent.com Thu Apr 9 22:33:13 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEEF1A6FFF for ; Thu, 9 Apr 2015 22:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3EoENYGx_G6 for ; Thu, 9 Apr 2015 22:33:11 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580441A6EFC for ; Thu, 9 Apr 2015 22:33:11 -0700 (PDT) Received: from jaguar.aricent.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 92EF921A4B6 for ; Fri, 10 Apr 2015 11:03:08 +0530 (IST) Received: from GURCASV01.AD.ARICENT.COM (unknown [10.203.26.91]) by jaguar.aricent.com (Postfix) with ESMTPS id 779F221A491 for ; Fri, 10 Apr 2015 11:03:08 +0530 (IST) Received: from GURMBXV02.AD.ARICENT.COM (10.203.26.97) by GURMBXV03.AD.ARICENT.COM (10.203.26.98) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 10 Apr 2015 11:03:06 +0530 Received: from GURMBXV02.AD.ARICENT.COM ([10.203.26.97]) by GURMBXV02.AD.ARICENT.COM ([169.254.4.228]) with mapi id 15.00.0847.030; Fri, 10 Apr 2015 11:03:06 +0530 From: Prashant Upadhyaya To: "ipfix@ietf.org" Thread-Topic: Question regarding packet capturing with IPFIX Thread-Index: AdBzT4DkarROHuwfSsaYZ9X6lSAFtA== Date: Fri, 10 Apr 2015 05:33:05 +0000 Message-ID: <3280fb63009e499dbdeeceeb1049f06f@GURMBXV02.AD.ARICENT.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.203.178.60] Content-Type: multipart/alternative; boundary="_000_3280fb63009e499dbdeeceeb1049f06fGURMBXV02ADARICENTCOM_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [IPFIX] Question regarding packet capturing with IPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 05:34:57 -0000 --_000_3280fb63009e499dbdeeceeb1049f06fGURMBXV02ADARICENTCOM_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We can sample an IP flow with IPFix. My question is that when a packet is picked up in the sampling in IPFix, ca= n I take that full packet out and export it outside for analysis or only a = certain number of bytes of that packet as an upper limit. Eg. when using sFlow, the sampled packet's maximum number of bytes captured= is 256. Regards -Prashant "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." --_000_3280fb63009e499dbdeeceeb1049f06fGURMBXV02ADARICENTCOM_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We can sample an IP flow with IPFix.

My question is that when a packet is picked up in th= e sampling in IPFix, can I take that full packet out and export it outside = for analysis or only a certain number of bytes of that packet as an upper l= imit.

Eg. when using sFlow, the sampled packet’s max= imum number of bytes captured is 256.

 

Regards

-Prashant

 

"DISCLAIMER: This message is proprietary to Aricent and is intended so= lely for the use of the individual to whom it is addressed. It may contain = privileged or confidential information and should not be circulated or used= for any purpose other than for what it is intended. If you have received this message in error, please notify = the originator immediately. If you are not the intended recipient, you are = notified that you are strictly prohibited from using, copying, altering, or= disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from= the use of the information transmitted by this email including damage from= virus." --_000_3280fb63009e499dbdeeceeb1049f06fGURMBXV02ADARICENTCOM_-- From nobody Fri Apr 10 01:18:57 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A920A1B2ABD for ; Fri, 10 Apr 2015 01:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15qNi3cDjCUo for ; Fri, 10 Apr 2015 01:18:53 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B7D1A7011 for ; Fri, 10 Apr 2015 01:18:53 -0700 (PDT) Received: from pps.filterd (m0048192.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t3A83Rgs022392; Fri, 10 Apr 2015 01:18:42 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1tp0txs3db-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 10 Apr 2015 01:18:42 -0700 Received: from BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 10 Apr 2015 01:18:41 -0700 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 10 Apr 2015 02:18:40 -0600 Received: from EMEAWP-CASH02.corp.brocade.com (172.29.19.10) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 10 Apr 2015 02:18:39 -0600 Received: from EMEA-EXCH01.corp.brocade.com ([fe80::18c9:7b21:74fd:7e48]) by EMEAWP-CASH02.corp.brocade.com ([fe80::4878:eab3:43ba:cfca%12]) with mapi; Fri, 10 Apr 2015 10:18:38 +0200 From: Paul Aitken To: Prashant Upadhyaya , "ipfix@ietf.org" Date: Fri, 10 Apr 2015 10:18:30 +0200 Thread-Topic: Question regarding packet capturing with IPFIX Thread-Index: AdBzT4DkarROHuwfSsaYZ9X6lSAFtAAEDJxQ Message-ID: <23B7BE54EACBED43957AB709C564F7B702B6E4448F@EMEA-EXCH01.corp.brocade.com> References: <3280fb63009e499dbdeeceeb1049f06f@GURMBXV02.AD.ARICENT.COM> In-Reply-To: <3280fb63009e499dbdeeceeb1049f06f@GURMBXV02.AD.ARICENT.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_23B7BE54EACBED43957AB709C564F7B702B6E4448FEMEAEXCH01cor_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-10_02:2015-04-09,2015-04-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504100066 Archived-At: Subject: Re: [IPFIX] Question regarding packet capturing with IPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 08:18:55 -0000 --_000_23B7BE54EACBED43957AB709C564F7B702B6E4448FEMEAEXCH01cor_ Content-Type: text/plain; charset="us-ascii" Prashant, Refer to RFC2804, "IETF Policy on Wiretapping". Several of the IPFIX and PSAMP RFCs (7013, 7014, 7133, 5474, 5476, 5477) refer to that. Some of the Information Elements also specifically call out RFC2804 - eg, 313 ipHeaderPacketSection: With sufficient length, this element also reports octets from the IP payload. However, full packet capture of arbitrary packet streams is explicitly out of scope per the Security Considerations sections of [RFC5477] and [RFC2804]. P. From: IPFIX [mailto:ipfix-bounces@ietf.org] On Behalf Of Prashant Upadhyaya Sent: 10 April 2015 06:33 To: ipfix@ietf.org Subject: [IPFIX] Question regarding packet capturing with IPFIX Hi, We can sample an IP flow with IPFix. My question is that when a packet is picked up in the sampling in IPFix, can I take that full packet out and export it outside for analysis or only a certain number of bytes of that packet as an upper limit. Eg. when using sFlow, the sampled packet's maximum number of bytes captured is 256. Regards -Prashant "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." --_000_23B7BE54EACBED43957AB709C564F7B702B6E4448FEMEAEXCH01cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Prashant,

 

Refer to RFC28= 04, “IETF Policy on Wiretapping”. Several of the IPFIX and PSAM= P RFCs (7013, 7014, 7133, 5474, 5476, 5477) refer to that.

 

Some of the Info= rmation Elements also specifically call out RFC2804 - eg, 313 ipHeaderPacket= Section:

 

With sufficient length, this element = also reports octets from the IP payload. However, full packet capture of ar= bitrary packet streams is explicitly out of scope per the Security Consider= ations sections of [RFC5477] and [RFC2804].

 

P.

 

<= p class=3DMsoNormal> <= /p>

From: IPFIX [mailto:ipfix-bounce= s@ietf.org] On Behalf Of Prashant Upadhyaya
Sent: 10 April= 2015 06:33
To: ipfix@ietf.org
Subject: [IPFIX] Questio= n regarding packet capturing with IPFIX

 

Hi,=

 

We can s= ample an IP flow with IPFix.

My question= is that when a packet is picked up in the sampling in IPFix, can I take th= at full packet out and export it outside for analysis or only a certain num= ber of bytes of that packet as an upper limit.

Eg. when using sFlow, the sampled packet’s maximum number of b= ytes captured is 256.

 <= /p>

Regards

-Prashan= t

 

= "DISCLAIMER: This message is proprietary to Aricent and is intended so= lely for the use of the individual to whom it is addressed. It may contain = privileged or confidential information and should not be circulated or used= for any purpose other than for what it is intended. If you have received t= his message in error, please notify the originator immediately. If you are = not the intended recipient, you are notified that you are strictly prohibit= ed from using, copying, altering, or disclosing the contents of this messag= e. Aricent accepts no responsibility for loss or damage arising from the us= e of the information transmitted by this email including damage from virus.= "

= --_000_23B7BE54EACBED43957AB709C564F7B702B6E4448FEMEAEXCH01cor_-- From nobody Thu Apr 16 01:09:32 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D077B1B2BB8 for ; Thu, 16 Apr 2015 01:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRgbagozgLqH for ; Thu, 16 Apr 2015 01:09:29 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA691B2BCC for ; Thu, 16 Apr 2015 01:09:28 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so52626480lbb.2 for ; Thu, 16 Apr 2015 01:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VlQ26xeIhQDn2HAS/9OHeaSL0MJoAqjKqKiR0vRD2fI=; b=xtlk71eb29CBiQIq3RZEHF+pVpOkTkboIBytokJJnNuVcAnWTSwVm1a/F3zNSxgnRO 3+e+SqOEalztet82PLz44y6o+wg1lVQZmS20kVsdXiijOVTVDnlEbK6F7f0uqHgn1pHC P/6FhQUhH/iwD/ImOwndKDT6UlCs4JAA5Y1Kf/e73MQ1yrJak96Z4Tjis1dFAVodUiXD fL88SIUn3UFo0aqgFrpaTMekWwR7sDObiVomPgVN5F3GREQXtOycCfLKw+03QNtQfm/8 Da80L19Enlyes1FH7xNF6+H6fArzDQ11loNudjhETw9ygObbOdblVgDl1adTEYWN/U9w aFzg== MIME-Version: 1.0 X-Received: by 10.152.5.134 with SMTP id s6mr27237890las.6.1429171767075; Thu, 16 Apr 2015 01:09:27 -0700 (PDT) Sender: thorgrin@gmail.com Received: by 10.25.16.65 with HTTP; Thu, 16 Apr 2015 01:09:27 -0700 (PDT) In-Reply-To: <551DA857.2050104@net.in.tum.de> References: <54AC4097.1050602@plixer.com> <551DA857.2050104@net.in.tum.de> Date: Thu, 16 Apr 2015 10:09:27 +0200 X-Google-Sender-Auth: 63xRJ_ncgVfefQVGe5LL349V9Kk Message-ID: From: Petr Velan To: Gerhard Muenz Content-Type: multipart/alternative; boundary=089e013d10107fe9cb0513d2fb37 Archived-At: Cc: ipfix@ietf.org Subject: Re: [IPFIX] NetFlow v9 to IPFIX conversion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 08:09:32 -0000 --089e013d10107fe9cb0513d2fb37 Content-Type: text/plain; charset=UTF-8 Hi Gerhard, the problem we are facing here is that the NetFlow v9 ID space is not centrally managed, therefore we cannot hope to cover all possible IDs and vendors, since they can change. Moreover, as you say, the owner of a PEN maintains his ID registry, therefore we should not use someones PEN just because he defined the nf9 elements. What I propose is similar to RFC 5612. We should define an NetFlow to IPFIX conversion PEN which could be used by anyone for mapping nf9 elements with ID > 2^15. The ID of that element would not be changed, only the PEN would be added, which, as an added benefit, would be fairly easy to implement in IPFIX mediators. No central management is necessary, just as you need to know the nf9 elements that you use, you would have to know the semantics from the appropriate vendor. The collisions cannot be avoided, however, they are not managed in nf9 either. As you say, there is currently no PEN for general experimental use that could be used as a fallback. I think that creating a specific PEN for this task is the right solution. Best regards, Petr On Thu, Apr 2, 2015 at 10:36 PM, Gerhard Muenz wrote: > > Hi Petr, > > I do not understand the use case of the new PEN that you suggest. > > It does not make sense to register a PEN for an ID space that is not > centrally managed in a kind of registry because uniqueness of ID usage must > be ensured. Usually, the owner of a PEN maintains such a registry. > > Is there a registry that lists all vendor specific Netflow 9 Field Types? > If not, how can you be sure that there are no collisions in the ID space? > > I think that you need to find and use the PENs of the vendors that have > defined the additional Netflow 9 Field Types IEs, regardless of whether the > IDs are below or above 2^15. Unfortunately, there is no PEN for general > experimental use (at least I have not found any) that you could use as a > fallback if you do not find an appropriate vendor PEN. > > If you want to use your own non-standard IEs, then you should use the PEN > of your organization: > > 8057 > CESNET > CESNET masters team > masters&cesnet.cz > > Maybe, you can also use this PEN to map Field Types for which you do not > find a vendor. > > Regards, > Gerhard > > > > On 26.03.2015 08:14, Petr Velan wrote: > > Hi Andrew, all, > > thank you for your explanation regarding nprobe. > > However, we also need a fallback for unknown exporters with IEs > 2^15. > The generic requests for PENs need organization name, contact name and > email address. I can try to request the PEN for NetFlow v9 compatibility > myself, but I'd like it to be more public. Therefore, I suggest to complete > the request with something like: > *Organization Name*: NetFlow v9 to IPFIX > *Contact Name*: IPFIX WG > *Contact E-Mail: *ipfix@ietf.org > > This is just a first proposal to get things moving, please add your > thoughts. Once the PEN is granted, we can move forward and explain its > purpose in a short RFC. > > Petr > > On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren wrote: > >> Hi Petr, >> >> On 01/06/2015 07:03 AM, Petr Velan wrote: >> >> Hello all, >> >> I'm not sure whether this is the right place to ask, but we encountered >> following problem when converting NetFlow v9 messages to IPFIX. >> >> Some vendors (I've heard of ntop) are using elements IDs large than >> 32767 in NetFlow v9. When converting messages with these elements to IPFIX, >> they are considered to be Enterprise Numbers. To generate proper IPFIX >> message, we need to do one of the following: >> a) Generate a list of the elements and map them to PEN of the correct >> vendor. However, this would result in an attempt to cover all possible >> elements that anybody used in NetFlow v9. Moreover, we would still have to >> somehow handle the cases where the element is unknown >> >> This should help with ntop/nprobe >> >> Recent versions of nprobe (since version 5.5.5 I think) all use the >> following mapping. >> >> PEN = 35632 and IPFIXID = (v9ID - 57472) >> >> For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION >> 57667. The IPFIX equivalent would be >> MYSQL_SERVER_VERSION(35632/195). >> >> The nprobe docs have a complete list. >> >> Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but later >> allocated in IANA. There is no good way to convert those v9 exports to >> IPFIX. >> >> -Andrew >> >> >> b) Request a PEN for NetFlow compatibility and just add this PEN for >> every element that has ID larger than 32767. >> >> Personally, I believe that the b) is more general and error-prone. Do >> you think, that it would be possible to dedicate whole PEN to this cause? >> >> Thank you for any opinions, >> >> Petr Velan >> >> >> >> _______________________________________________ >> IPFIX mailing listIPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix >> >> >> > > > _______________________________________________ > IPFIX mailing listIPFIX@ietf.orghttps://www.ietf.org/mailman/listinfo/ipfix > > > --089e013d10107fe9cb0513d2fb37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Gerhard,

the problem w= e are facing here is that the NetFlow v9 ID space is not centrally managed,= therefore we cannot hope to cover all possible IDs and vendors, since they= can change. Moreover, as you say, the owner of a PEN maintains his ID registry, therefore we should not use someones PEN just because he defi= ned the nf9 elements.

What I propose is similar to RFC 5612. W= e should define an NetFlow to IPFIX conversion PEN which could be used by a= nyone for mapping nf9 elements with ID > 2^15. The ID of that element wo= uld not be changed, only the PEN would be added, which, as an added benefit= , would be fairly easy to implement in IPFIX mediators. No central manageme= nt is necessary, just as you need to know the nf9 elements that you use, yo= u would have to know the semantics from the appropriate vendor. The collisi= ons cannot be avoided, however, they are not managed in nf9 either.

=
As you say, there is currently no PEN for general experimental use that could be used as a fallback. I th= ink that creating a specific PEN for this task is the right solution.
Best regards,
Petr
<= div>

On Thu, Apr 2= , 2015 at 10:36 PM, Gerhard Muenz <muenz@net.in.tum.de> wr= ote:
=20 =20 =20

Hi Petr,

I do not understand the use case of the new PEN that you suggest.

It does not make sense to register a PEN for an ID space that is not centrally managed in a kind of registry because uniqueness of ID usage must be ensured. Usually, the owner of a PEN maintains such a registry.

Is there a registry that lists all vendor specific Netflow 9 Field Types?
If not, how can you be sure that there are no collisions in the ID space?

I think that you need to find and use the PENs of the vendors that have defined the additional Netflow 9 Field Types IEs, regardless of whether the IDs are below or above 2^15. Unfortunately, there is no PEN for general experimental use (at least I have not found any) that you could use as a fallback if you do not find an appropriate vendor PEN.

If you want to use your own non-standard IEs, then you should use the PEN of your organization:

8057
=C2=A0 CESNET
=C2=A0=C2=A0=C2=A0 CESNET masters team
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 masters&cesnet.cz

Maybe, you can also use this PEN to map Field Types for which you do not find a vendor.

Regards,
Gerhard

=C2=A0

On 26.03.2015 08:14, Petr Velan wrote:
Hi Andrew, all,

thank you for your explanation regarding nprobe.

However, we also need a fallback for unknown exporters with IEs > 2^15. The generic requests for PENs need organization name, contact name and email address. I can try to request the PEN for NetFlow v9 compatibility myself, but I'd like it to b= e more public. Therefore, I suggest to complete the request with something like:
Organization Name: NetFlow v9 to IPFIX
Contact Name: IPFIX WG
Contact E-Mail: ipfix@ietf.org

This is just a first proposal to get things moving, please add your thoughts. Once the PEN is granted, we can move forward and explain its purpose in a short RFC.

Petr

On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren <andrewf@plixer.com> wrote:
Hi Petr,

On 01/06/2015 07:03 AM, Petr Velan wrote:
Hello all,

I'm not sure whether this is the right place to ask, but we encountered following problem when converting NetFlow v9 messages to IPFIX.

Some vendors (I've heard of ntop) are using elements IDs large than 32767 in NetFlow v9. When converting messages with these elements to IPFIX, they are considered to be Enterprise Numbers. To generate proper IPFIX message, we need to do one of the following:
a) Generate a list of the elements and map them to PEN of the correct vendor. However, this would result in an attempt to cover all possible elements that anybody used in NetFlow v9. Moreover, we would still have to somehow handle the cases where the element is unknown
 This should help with ntop/nprobe

Recent versions of nprobe (since version 5.5.5 I think) all use the following mapping.

PEN =3D 35632 and IPFIXID =3D (v9ID - 57472)

For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION 57667.=C2=A0 The IPFIX equivalent would = be
MYSQL_SERVER_VERSION(35632/195).

The nprobe docs have a complete list.

Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but later allocated in IANA.=C2=A0 There is no good way to convert those v9 exports to IPFIX.

-Andrew
b) Request a PEN for NetFlow compatibility and just add this PEN for every element that has ID larger than 32767.

Personally, I believe that the b) is more general and error-prone. Do you think, that it would be possible to dedicate whole PEN to this cause?

Thank you for any opinions,

Petr Velan



 
_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/ipfix





_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/ipfix


--089e013d10107fe9cb0513d2fb37-- From nobody Thu Apr 16 02:54:48 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C75F1B30BF for ; Thu, 16 Apr 2015 02:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sfeG2xaO47A for ; Thu, 16 Apr 2015 02:54:42 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3771ACDEB for ; Thu, 16 Apr 2015 02:54:42 -0700 (PDT) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t3G9V5cK011212; Thu, 16 Apr 2015 02:54:35 -0700 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1tsmk3aw62-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Apr 2015 02:54:35 -0700 Received: from BRMWP-EXMB12.corp.brocade.com (172.16.59.130) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 16 Apr 2015 03:54:34 -0600 Received: from EMEAWP-CASH01.corp.brocade.com (172.29.18.10) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 16 Apr 2015 03:54:33 -0600 Received: from [172.27.212.80] (172.27.212.80) by imapeu.brocade.com (172.29.18.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 16 Apr 2015 11:54:31 +0200 Message-ID: <552F86D6.4050704@brocade.com> Date: Thu, 16 Apr 2015 10:54:30 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0 MIME-Version: 1.0 To: Petr Velan , Gerhard Muenz References: <54AC4097.1050602@plixer.com> <551DA857.2050104@net.in.tum.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040401040503000409030408" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-16_04:2015-04-15,2015-04-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504160082 Archived-At: Cc: "ipfix@ietf.org" Subject: Re: [IPFIX] NetFlow v9 to IPFIX conversion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 09:54:46 -0000 --------------040401040503000409030408 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Petr, > the problem we are facing here is that the NetFlow v9 ID space is not > centrally managed NetFlow v9 is a cisco protocol, and the IDs are allocated by Cisco's netflow police. Contact ipfix-iana@cisco.com. Anyone using NFv9 IDs without contacting them is asking for trouble (ie, ID collisions). > therefore we cannot hope to cover all possible IDs and vendors, since > they can change. Moreover, as you say, the owner of a PEN maintains > his ID registry, therefore we should not use someones PEN just because > he defined the nf9 elements. Equally, nobody should be self-defining NFv9 elements without reference to Cisco, because they've no idea what IDs Cisco (or others) might use in future. > What I propose is similar to RFC 5612. We should define an NetFlow to > IPFIX conversion PEN which could be used by anyone for mapping nf9 > elements with ID > 2^15. The ID of that element would not be changed, > only the PEN would be added, which, as an added benefit, would be > fairly easy to implement in IPFIX mediators. No central management is > necessary, just as you need to know the nf9 elements that you use, you > would have to know the semantics from the appropriate vendor. The > collisions cannot be avoided, however, they are not managed in nf9 either. > > As you say, there is currently no PEN for general experimental use > that could be used as a fallback. Even if there was, you shouldn't use such a PEN in a released product because it could conflict with someone else's usage. P. > I think that creating a specific PEN for this task is the right solution. > > Best regards, > Petr > > On Thu, Apr 2, 2015 at 10:36 PM, Gerhard Muenz > wrote: > > > Hi Petr, > > I do not understand the use case of the new PEN that you suggest. > > It does not make sense to register a PEN for an ID space that is > not centrally managed in a kind of registry because uniqueness of > ID usage must be ensured. Usually, the owner of a PEN maintains > such a registry. > > Is there a registry that lists all vendor specific Netflow 9 Field > Types? > If not, how can you be sure that there are no collisions in the ID > space? > > I think that you need to find and use the PENs of the vendors that > have defined the additional Netflow 9 Field Types IEs, regardless > of whether the IDs are below or above 2^15. Unfortunately, there > is no PEN for general experimental use (at least I have not found > any) that you could use as a fallback if you do not find an > appropriate vendor PEN. > > If you want to use your own non-standard IEs, then you should use > the PEN of your organization: > > 8057 > CESNET > CESNET masters team > masters&cesnet.cz > > Maybe, you can also use this PEN to map Field Types for which you > do not find a vendor. > > Regards, > Gerhard > > > > On 26.03.2015 08:14, Petr Velan wrote: >> Hi Andrew, all, >> >> thank you for your explanation regarding nprobe. >> >> However, we also need a fallback for unknown exporters with IEs > >> 2^15. The generic requests for PENs need organization name, >> contact name and email address. I can try to request the PEN for >> NetFlow v9 compatibility myself, but I'd like it to be more >> public. Therefore, I suggest to complete the request with >> something like: >> *Organization Name*: NetFlow v9 to IPFIX >> *Contact Name*: IPFIX WG >> *Contact E-Mail: *ipfix@ietf.org >> >> This is just a first proposal to get things moving, please add >> your thoughts. Once the PEN is granted, we can move forward and >> explain its purpose in a short RFC. >> >> Petr >> >> On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren > > wrote: >> >> Hi Petr, >> >> On 01/06/2015 07:03 AM, Petr Velan wrote: >>> Hello all, >>> >>> I'm not sure whether this is the right place to ask, but we >>> encountered following problem when converting NetFlow v9 >>> messages to IPFIX. >>> >>> Some vendors (I've heard of ntop) are using elements IDs >>> large than 32767 in NetFlow v9. When converting messages >>> with these elements to IPFIX, they are considered to be >>> Enterprise Numbers. To generate proper IPFIX message, we >>> need to do one of the following: >>> a) Generate a list of the elements and map them to PEN of >>> the correct vendor. However, this would result in an attempt >>> to cover all possible elements that anybody used in NetFlow >>> v9. Moreover, we would still have to somehow handle the >>> cases where the element is unknown >> This should help with ntop/nprobe >> >> Recent versions of nprobe (since version 5.5.5 I think) all >> use the following mapping. >> >> PEN = 35632 and IPFIXID = (v9ID - 57472) >> >> For example, one v9 IE that nprobe exports is >> MYSQL_SERVER_VERSION 57667. The IPFIX equivalent would be >> MYSQL_SERVER_VERSION(35632/195). >> >> The nprobe docs have a complete list. >> >> Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, >> but later allocated in IANA. There is no good way to convert >> those v9 exports to IPFIX. >> >> -Andrew >> >> >>> b) Request a PEN for NetFlow compatibility and just add this >>> PEN for every element that has ID larger than 32767. >>> >>> Personally, I believe that the b) is more general and >>> error-prone. Do you think, that it would be possible to >>> dedicate whole PEN to this cause? >>> >>> Thank you for any opinions, >>> >>> Petr Velan >>> >>> >>> >>> _______________________________________________ >>> 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 > > --------------040401040503000409030408 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Petr,

the problem we are facing here is that the NetFlow v9 ID space is not centrally managed

NetFlow v9 is a cisco protocol, and the IDs are allocated by Cisco's netflow police. Contact ipfix-iana@cisco.com.

Anyone using NFv9 IDs without contacting them is asking for trouble (ie, ID collisions).


therefore we cannot hope to cover all possible IDs and vendors, since they can change. Moreover, as you say, the owner of a PEN maintains his ID registry, therefore we should not use someones PEN just because he defined the nf9 elements.

Equally, nobody should be self-defining NFv9 elements without reference to Cisco, because they've no idea what IDs Cisco (or others) might use in future.


What I propose is similar to RFC 5612. We should define an NetFlow to IPFIX conversion PEN which could be used by anyone for mapping nf9 elements with ID > 2^15. The ID of that element would not be changed, only the PEN would be added, which, as an added benefit, would be fairly easy to implement in IPFIX mediators. No central management is necessary, just as you need to know the nf9 elements that you use, you would have to know the semantics from the appropriate vendor. The collisions cannot be avoided, however, they are not managed in nf9 either.

As you say, there is currently no PEN for general experimental use that could be used as a fallback.

Even if there was, you shouldn't use such a PEN in a released product because it could conflict with someone else's usage.

P.


I think that creating a specific PEN for this task is the right solution.

Best regards,
Petr

On Thu, Apr 2, 2015 at 10:36 PM, Gerhard Muenz <muenz@net.in.tum.de> wrote:

Hi Petr,

I do not understand the use case of the new PEN that you suggest.

It does not make sense to register a PEN for an ID space that is not centrally managed in a kind of registry because uniqueness of ID usage must be ensured. Usually, the owner of a PEN maintains such a registry.

Is there a registry that lists all vendor specific Netflow 9 Field Types?
If not, how can you be sure that there are no collisions in the ID space?

I think that you need to find and use the PENs of the vendors that have defined the additional Netflow 9 Field Types IEs, regardless of whether the IDs are below or above 2^15. Unfortunately, there is no PEN for general experimental use (at least I have not found any) that you could use as a fallback if you do not find an appropriate vendor PEN.

If you want to use your own non-standard IEs, then you should use the PEN of your organization:

8057
  CESNET
    CESNET masters team
      masters&cesnet.cz

Maybe, you can also use this PEN to map Field Types for which you do not find a vendor.

Regards,
Gerhard

 

On 26.03.2015 08:14, Petr Velan wrote:
Hi Andrew, all,

thank you for your explanation regarding nprobe.

However, we also need a fallback for unknown exporters with IEs > 2^15. The generic requests for PENs need organization name, contact name and email address. I can try to request the PEN for NetFlow v9 compatibility myself, but I'd like it to be more public. Therefore, I suggest to complete the request with something like:
Organization Name: NetFlow v9 to IPFIX
Contact Name: IPFIX WG
Contact E-Mail: ipfix@ietf.org

This is just a first proposal to get things moving, please add your thoughts. Once the PEN is granted, we can move forward and explain its purpose in a short RFC.

Petr

On Tue, Jan 6, 2015 at 9:07 PM, Andrew Feren <andrewf@plixer.com> wrote:
Hi Petr,

On 01/06/2015 07:03 AM, Petr Velan wrote:
Hello all,

I'm not sure whether this is the right place to ask, but we encountered following problem when converting NetFlow v9 messages to IPFIX.

Some vendors (I've heard of ntop) are using elements IDs large than 32767 in NetFlow v9. When converting messages with these elements to IPFIX, they are considered to be Enterprise Numbers. To generate proper IPFIX message, we need to do one of the following:
a) Generate a list of the elements and map them to PEN of the correct vendor. However, this would result in an attempt to cover all possible elements that anybody used in NetFlow v9. Moreover, we would still have to somehow handle the cases where the element is unknown
 This should help with ntop/nprobe

Recent versions of nprobe (since version 5.5.5 I think) all use the following mapping.

PEN = 35632 and IPFIXID = (v9ID - 57472)

For example, one v9 IE that nprobe exports is MYSQL_SERVER_VERSION 57667.  The IPFIX equivalent would be
MYSQL_SERVER_VERSION(35632/195).

The nprobe docs have a complete list.

Older versions of nprobe (pre ~2010) use IEs not in RFC 3954, but later allocated in IANA.  There is no good way to convert those v9 exports to IPFIX.

-Andrew
b) Request a PEN for NetFlow compatibility and just add this PEN for every element that has ID larger than 32767.

Personally, I believe that the b) is more general and error-prone. Do you think, that it would be possible to dedicate whole PEN to this cause?

Thank you for any opinions,

Petr Velan



 
_______________________________________________
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



--------------040401040503000409030408-- From nobody Sun Apr 19 11:39:20 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40431A894E for ; Sun, 19 Apr 2015 11:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKKIjfc81N-2 for ; Sun, 19 Apr 2015 11:39:17 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219AD1A893A for ; Sun, 19 Apr 2015 11:39:17 -0700 (PDT) Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:99b1:5e7f:7696:3880]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3JIdGeM095266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 19 Apr 2015 18:39:16 GMT (envelope-from joelja@bogus.com) To: IPFIX Working Group From: joel jaeggli message-id: <5533F654.20103@bogus.com> Date: Sun, 19 Apr 2015 11:39:16 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QpaXsjOJegj1HDdk2fa3rVN3bbJcNUOsF" Archived-At: Subject: [IPFIX] errata filed http://www.rfc-editor.org/rfc/rfc5655.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 18:39:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QpaXsjOJegj1HDdk2fa3rVN3bbJcNUOsF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable https://www.rfc-editor.org/verify_errata_select.php?eid=3D4308 what say you? Status: Reported Type: Editorial Reported By: Paul Aitken Date Reported: 2015-03-19 Section A.5 says: A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 317 bytes of the example File constructed above would appear as in the annotated Figure 10 below. It should say: A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 285 bytes of the example File constructed above would appear as in the annotated Figure 10 below. Notes: s/317/285/ Figure 10 shows 18 lines of 16 octets each, less three octets in the final row. (18 x 16 - 3) =3D 285 octets. This can also be confirmed by the revised numbering in errata 2030 - though note that the dump is numbered from octet zero: 272: 80 02 00 50 06 00 00 46 50 00 00 00 41 Since the offset of the final octet ("41") is 284, the overall length must be 285. --QpaXsjOJegj1HDdk2fa3rVN3bbJcNUOsF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUz9lQACgkQ8AA1q7Z/VrL84wCeKLksiIGeRYZDw4e2rffZFzoB 1HEAn35MaDXP+g9ZEiemb5wNybjWVt+L =At7s -----END PGP SIGNATURE----- --QpaXsjOJegj1HDdk2fa3rVN3bbJcNUOsF-- From nobody Mon Apr 20 08:18:06 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69461B2ED0 for ; Mon, 20 Apr 2015 08:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvmYJ3i1BCBh for ; Mon, 20 Apr 2015 08:18:03 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750521B2EC7 for ; Mon, 20 Apr 2015 08:18:03 -0700 (PDT) Received: from mb-aye.local ([8.18.217.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3KFI1h3008344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 15:18:02 GMT (envelope-from joelja@bogus.com) To: "ipfix-chairs@tools.ietf.org" , IPFIX Working Group From: joel jaeggli message-id: <553518A5.9020901@bogus.com> Date: Mon, 20 Apr 2015 08:17:57 -0700 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0 mime-version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gN3LsqTRW5D7ltWSrHPlhSsXJtALdLBgm" Archived-At: Subject: [IPFIX] errata lodged against rfc 5655 X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 15:18:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gN3LsqTRW5D7ltWSrHPlhSsXJtALdLBgm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable https://www.rfc-editor.org/verify_errata_select.php?eid=3D4308 Status: Reported Type: Editorial Reported By: Paul Aitken Date Reported: 2015-03-19 Section A.5 says: A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 317 bytes of the example File constructed above would appear as in the annotated Figure 10 below. It should say: A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 285 bytes of the example File constructed above would appear as in the annotated Figure 10 below. Notes: s/317/285/ Figure 10 shows 18 lines of 16 octets each, less three octets in the final row. (18 x 16 - 3) =3D 285 octets. This can also be confirmed by the revised numbering in errata 2030 - though note that the dump is numbered from octet zero: 272: 80 02 00 50 06 00 00 46 50 00 00 00 41 Since the offset of the final octet ("41") is 284, the overall length must be 285. what do we think? thanks joel --gN3LsqTRW5D7ltWSrHPlhSsXJtALdLBgm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlU1GKUACgkQ8AA1q7Z/VrKvtwCfexbhdI9iTfOhwk0mxQDwUPK9 DsEAmwY2q/kOFW+We7ZQJANcsBrjq+G/ =qpgl -----END PGP SIGNATURE----- --gN3LsqTRW5D7ltWSrHPlhSsXJtALdLBgm-- From nobody Tue Apr 21 03:03:32 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A1E1A8AE4 for ; Tue, 21 Apr 2015 03:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAn6Ta9RqImt for ; Tue, 21 Apr 2015 03:03:28 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E181A8AD4 for ; Tue, 21 Apr 2015 03:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4284; q=dns/txt; s=iport; t=1429610517; x=1430820117; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=UXBRON8Sik1Oumn+ldJgAQ0j1ZtnjL86bW/BvQYmg9c=; b=hQfDYc7rO6ebu/4oYB3Vo1sl1R7W51GwOHOQsDUd0l5V1rvMLk50TIxT sIUCVfj+r6iWGKiNXvEVRGQDPzA26P8zQ1AgkizAT5ng/+i35JH7EwQiD FyKC3Ad4YHKHTIag0v1fKm29qRSsUTo8Pp21DGyJwaDw8mIoK5Wq4UJ91 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D9AwAGHzZV/xbLJq1BGoNeXMYUCYFFAQmGBAKBeRQBAQEBAQEBfYQhAQEEAQEBawoRCwQdFg8JAwIBAgEVMAYBDAYCAQGIJw03yVQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizeFC4QtAQSbV4cpjX8iggIDGQSBUzwxARGCMgEBAQ X-IronPort-AV: E=Sophos;i="5.11,615,1422921600"; d="scan'208,217";a="437142865" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 21 Apr 2015 10:01:55 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t3LA1sQ9027460; Tue, 21 Apr 2015 10:01:55 GMT Message-ID: <55362044.1000101@cisco.com> Date: Tue, 21 Apr 2015 12:02:44 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: joel jaeggli , IPFIX Working Group References: <5533F654.20103@bogus.com> In-Reply-To: <5533F654.20103@bogus.com> Content-Type: multipart/alternative; boundary="------------020202010004090805070107" Archived-At: Subject: Re: [IPFIX] errata filed http://www.rfc-editor.org/rfc/rfc5655.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 10:03:30 -0000 This is a multi-part message in MIME format. --------------020202010004090805070107 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Joel, Dear all, I discussed this errata with the RFC editor a few weeks ago. http://www.rfc-editor.org/errata_search.php?eid=2030, which was similar, has been updated with s/317/285/ Next, I'll reject this errata below. Regards, Benoit > https://www.rfc-editor.org/verify_errata_select.php?eid=4308 > > what say you? > > > Status: Reported > Type: Editorial > > Reported By: Paul Aitken > Date Reported: 2015-03-19 > Section A.5 says: > > A.5. Complete File Example > > Bringing together the examples above and adding message headers as > appropriate, a hex dump of the first 317 bytes of the example File > constructed above would appear as in the annotated Figure 10 below. > It should say: > > A.5. Complete File Example > > Bringing together the examples above and adding message headers as > appropriate, a hex dump of the first 285 bytes of the example File > constructed above would appear as in the annotated Figure 10 below. > Notes: > > s/317/285/ > > Figure 10 shows 18 lines of 16 octets each, less three octets in the > final row. > (18 x 16 - 3) = 285 octets. > > This can also be confirmed by the revised numbering in errata 2030 - > though note that the dump is numbered from octet zero: > > 272: 80 02 00 50 06 00 00 46 50 00 00 00 41 > > Since the offset of the final octet ("41") is 284, the overall length > must be 285. > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------020202010004090805070107 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
Joel, Dear all,

I discussed this errata with the RFC editor a few weeks ago.
http://www.rfc-editor.org/errata_search.php?eid=2030, which was similar, has been updated with s/317/285/
Next, I'll reject this errata below.

Regards, Benoit
https://www.rfc-editor.org/verify_errata_select.php?eid=4308

what say you?


Status: Reported
Type: Editorial

Reported By: Paul Aitken
Date Reported: 2015-03-19
Section A.5 says:

A.5.  Complete File Example

   Bringing together the examples above and adding message headers as
   appropriate, a hex dump of the first 317 bytes of the example File
   constructed above would appear as in the annotated Figure 10 below.
It should say:

A.5.  Complete File Example

   Bringing together the examples above and adding message headers as
   appropriate, a hex dump of the first 285 bytes of the example File
   constructed above would appear as in the annotated Figure 10 below.
Notes:

s/317/285/

Figure 10 shows 18 lines of 16 octets each, less three octets in the
final row.
(18 x 16 - 3) = 285 octets.

This can also be confirmed by the revised numbering in errata 2030 -
though note that the dump is numbered from octet zero:

272: 80 02 00 50 06 00 00 46 50 00 00 00 41

Since the offset of the final octet ("41") is 284, the overall length
must be 285.





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

--------------020202010004090805070107-- From nobody Tue Apr 21 03:03:52 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B021A8AFE; Tue, 21 Apr 2015 03:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZZLzgyGk-AL; Tue, 21 Apr 2015 03:03:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 99EE91A8A05; Tue, 21 Apr 2015 03:03:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1E816180092; Tue, 21 Apr 2015 03:02:34 -0700 (PDT) To: paitken@brocade.com, brian.trammell@hitachi-eu.com, elisa.boschi@hitachi-eu.com, lutz.mark@ifam.fraunhofer.de, tanja.zseby@fokus.fraunhofer.de, arno@wagner.name X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150421100234.1E816180092@rfc-editor.org> Date: Tue, 21 Apr 2015 03:02:34 -0700 (PDT) Archived-At: Cc: iesg@ietf.org, ipfix@ietf.org, rfc-editor@rfc-editor.org Subject: [IPFIX] [Errata Rejected] RFC5655 (4308) X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 10:03:51 -0000 The following errata report has been rejected for RFC5655, "Specification of the IP Flow Information Export (IPFIX) File Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5655&eid=4308 -------------------------------------- Status: Rejected Type: Editorial Reported by: Paul Aitken Date Reported: 2015-03-19 Rejected by: Benoit Claise (IESG) Section: A.5 Original Text ------------- A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 317 bytes of the example File constructed above would appear as in the annotated Figure 10 below. Corrected Text -------------- A.5. Complete File Example Bringing together the examples above and adding message headers as appropriate, a hex dump of the first 285 bytes of the example File constructed above would appear as in the annotated Figure 10 below. Notes ----- s/317/285/ Figure 10 shows 18 lines of 16 octets each, less three octets in the final row. (18 x 16 - 3) = 285 octets. This can also be confirmed by the revised numbering in errata 2030 - though note that the dump is numbered from octet zero: 272: 80 02 00 50 06 00 00 46 50 00 00 00 41 Since the offset of the final octet ("41") is 284, the overall length must be 285. --VERIFIER NOTES-- The errata 2030 has been updated to reflect this, as proposed by Paul Aitken. -------------------------------------- RFC5655 (draft-ietf-ipfix-file-05) -------------------------------------- Title : Specification of the IP Flow Information Export (IPFIX) File Format Publication Date : October 2009 Author(s) : B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner Category : PROPOSED STANDARD Source : IP Flow Information Export Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Sun Apr 26 15:40:51 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1E1A882B; Sun, 26 Apr 2015 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUN8ufYZpa2m; Sun, 26 Apr 2015 15:40:48 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3021A8772; Sun, 26 Apr 2015 15:40:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6F7B724061E; Sun, 26 Apr 2015 15:40:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (ip-64-134-97-72.public.wayport.net [64.134.97.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D43B9240173; Sun, 26 Apr 2015 15:40:47 -0700 (PDT) Message-ID: <553D6926.40507@joelhalpern.com> Date: Sun, 26 Apr 2015 18:39:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Nagendra Kumar Nainar (naikumar)" , "ipfix@ietf.org" , "sfc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-kumar-ipfix-sfc-extension@tools.ietf.org" Subject: Re: [IPFIX] [sfc] FW: I-D Action: draft-kumar-ipfix-sfc-extension-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 22:40:50 -0000 I am wondering if the nextSFF fields really belong here? I see several problems with them. If the observation is being made before the SF, or between multiple local SF, then the information does not exist. Even if the observation is being made after the last local SF, the identification of the next SFF, as understood by this SFF, may well not be an IP address. What the local SFF knows may be an IP address, and Ethernet Address, an MPLS label, etc. So I am not sure this makes sense as a reportable. Otherwise, it looks quite reasonable and useful. Yours, Joel On 4/26/15 4:35 PM, Nagendra Kumar Nainar (naikumar) wrote: > Hi, > > Below is the draft proposed on IPFIX information elements for SFC. > > We welcome any comments/feedbacks. > > Regards, > Draft Authors. > > On 3/9/15, 8:49 AM, "internet-drafts@ietf.org" > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : IPFIX Information Element extension for SFC >> Authors : Nagendra Kumar >> Carlos Pignataro >> Paul Quinn >> Filename : draft-kumar-ipfix-sfc-extension-00.txt >> Pages : 11 >> Date : 2015-03-09 >> >> Abstract: >> Service Function Chaining (SFC) is an architecture that enables any >> operator to apply selective set of services by steering the traffic >> through an ordered set of service functions without any topology >> dependency. >> >> This document defines the required Information Elements to represent >> the details about service flows over any Service Function Path. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-kumar-ipfix-sfc-extension/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-kumar-ipfix-sfc-extension-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Sun Apr 26 22:32:07 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679D31A901C; Sun, 26 Apr 2015 13:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z43OV1Cb82r5; Sun, 26 Apr 2015 13:36:01 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B231A8FD5; Sun, 26 Apr 2015 13:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1797; q=dns/txt; s=iport; t=1430080561; x=1431290161; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=I/PFD5r02OHIGEwWmwJVv7H6RymeJT1AFwBqKSpNKuM=; b=YpdPPmfsz+JM3qLxgMfv3TOPwuJCDN7ZRfzXyQlmSmPkojZpURbsEKd+ wKb3Tw5SCEMNWZcp5IoGIAKpCVymJT8F2RxB5EC8rvwy4JaxRusBd/iCQ K+2h19K/06sfH5wk5okyN5B27GzZ+6x4loMa0VitlpSrq9jolWa2RCpzB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BSBABBSz1V/5xdJa1cgwxTXAXFNWYJgUgKhgQCgRw4FAEBAQEBAQGBCoQhAQEEAQEBNzQLEgEIEiQ3CxcEAQYDAgQBDQUJiCINxGoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiziFBQIFhC0FkVWEAYY4gSI9gwuKKYZOI4N0bwGBQ4EAAQEB X-IronPort-AV: E=Sophos;i="5.11,652,1422921600"; d="scan'208";a="144713730" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 26 Apr 2015 20:36:00 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3QKa0Qa021517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Apr 2015 20:36:00 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.90]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Sun, 26 Apr 2015 15:36:00 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "ipfix@ietf.org" , "sfc@ietf.org" Thread-Topic: I-D Action: draft-kumar-ipfix-sfc-extension-00.txt Thread-Index: AQHQgGCaz1YmKYTy8UWC225FKC3D+Q== Date: Sun, 26 Apr 2015 20:35:59 +0000 Message-ID: In-Reply-To: <20150309124951.25309.98356.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.250.206] Content-Type: text/plain; charset="us-ascii" Content-ID: <13CF2017A7E0EF4498D11BAD7AECDEB1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sun, 26 Apr 2015 22:32:05 -0700 Cc: "draft-kumar-ipfix-sfc-extension@tools.ietf.org" Subject: [IPFIX] FW: I-D Action: draft-kumar-ipfix-sfc-extension-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2015 20:36:02 -0000 Hi, Below is the draft proposed on IPFIX information elements for SFC. We welcome any comments/feedbacks. Regards, Draft Authors. On 3/9/15, 8:49 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IPFIX Information Element extension for SFC > Authors : Nagendra Kumar > Carlos Pignataro > Paul Quinn > Filename : draft-kumar-ipfix-sfc-extension-00.txt > Pages : 11 > Date : 2015-03-09 > >Abstract: > Service Function Chaining (SFC) is an architecture that enables any > operator to apply selective set of services by steering the traffic > through an ordered set of service functions without any topology > dependency. > > This document defines the required Information Elements to represent > the details about service flows over any Service Function Path. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-kumar-ipfix-sfc-extension/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-kumar-ipfix-sfc-extension-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Apr 28 18:39:37 2015 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430E91A92DC; Tue, 28 Apr 2015 18:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgNn09jbppLm; Tue, 28 Apr 2015 18:39:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EC21A92BD; Tue, 28 Apr 2015 18:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3221; q=dns/txt; s=iport; t=1430271573; x=1431481173; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+H9iX99PorxZEhEyo0HfMszKdPLcJJFvE08JUMBH1hk=; b=XETy1THzH+W6q1mlgQP8KaBiQSQJlt1ZP7SISmg+1rKR4CT/sB4kq4i0 o5gOdiH8e19SE2nrQ2lFVfUv8qoUefZktgOcaMYVQwxRcD1b7Yfmp+3bH 5gSaRnA+9749CyAmgAO/yMI6Xq1MOO/sD88MwTmea2AI6kCovn6mR0g37 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BBBQDYNUBV/4cNJK1cgwxTXAXGOII4CoYEAoE4TAEBAQEBAYELhCABAQEEAQEBNzQLEgEIEgYeNwsXBQkCBAENBQmIIg3HKwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOIUFAgUChCsFkWWEBIY7gSM9gwyJVliGUiODdG8BgUOBAQEBAQ X-IronPort-AV: E=Sophos;i="5.11,668,1422921600"; d="scan'208";a="415584702" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 29 Apr 2015 01:39:32 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3T1dWeL028262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Apr 2015 01:39:32 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.151]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 20:39:32 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "Joel M. Halpern" , "ipfix@ietf.org" , "sfc@ietf.org" Thread-Topic: [sfc] FW: I-D Action: draft-kumar-ipfix-sfc-extension-00.txt Thread-Index: AQHQgGCaz1YmKYTy8UWC225FKC3D+Z1gNswAgAMT3oA= Date: Wed, 29 Apr 2015 01:39:31 +0000 Message-ID: In-Reply-To: <553D6926.40507@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.118.20.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D56CEC34BB17843886A2CDFDEB8B72A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-kumar-ipfix-sfc-extension@tools.ietf.org" Subject: Re: [IPFIX] [sfc] FW: I-D Action: draft-kumar-ipfix-sfc-extension-00.txt X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 01:39:35 -0000 Hi Joel, Thanks for the comments. Please see inline.. >I am wondering if the nextSFF fields really belong here? >I see several problems with them. If the observation is being made >before the SF, or between multiple local SF, then the information does >not exist. =20 I think unobserved field by metering process while generating flow record is not specific to SFC scenarios. This is discussed in below draft, https://tools.ietf.org/html/draft-aitken-ipfix-unobserved-fields-03 I think the consensus can be applicable for SFC scenarios as well. >Even if the observation is being made after the last local >SF, the identification of the next SFF, as understood by this SFF, may >well not be an IP address. What the local SFF knows may be an IP >address, and Ethernet Address, an MPLS label, etc. So I am not sure >this makes sense as a reportable. Good point. I will check this and will include the update in next revision. > >Otherwise, it looks quite reasonable and useful. Thanks, Nagendra > > >On 4/26/15 4:35 PM, Nagendra Kumar Nainar (naikumar) wrote: >> Hi, >> >> Below is the draft proposed on IPFIX information elements for SFC. >> >> We welcome any comments/feedbacks. >> >> Regards, >> Draft Authors. >> >> On 3/9/15, 8:49 AM, "internet-drafts@ietf.org" >> >> wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> >>> Title : IPFIX Information Element extension for SFC >>> Authors : Nagendra Kumar >>> Carlos Pignataro >>> Paul Quinn >>> Filename : draft-kumar-ipfix-sfc-extension-00.txt >>> Pages : 11 >>> Date : 2015-03-09 >>> >>> Abstract: >>> Service Function Chaining (SFC) is an architecture that enables any >>> operator to apply selective set of services by steering the traffic >>> through an ordered set of service functions without any topology >>> dependency. >>> >>> This document defines the required Information Elements to represent >>> the details about service flows over any Service Function Path. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-kumar-ipfix-sfc-extension/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-kumar-ipfix-sfc-extension-00 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>