From majordomo@mil.doit.wisc.edu Mon Mar 1 06:26:20 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11318 for ; Mon, 1 Mar 2004 06:26:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Axl6r-0001gA-00 for ipfix-list@mil.doit.wisc.edu; Mon, 01 Mar 2004 04:57:17 -0600 Received: from gtfw2.enterasys.com ([12.25.1.128]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Axl6q-0001g3-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 01 Mar 2004 04:57:16 -0600 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i21AMVaj026819 for ; Mon, 1 Mar 2004 05:22:31 -0500 (EST) Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 01 Mar 2004 05:57:09 -0500 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Mon, 01 Mar 2004 05:57:09 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Mar 2004 05:57:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix-protocol] PROTOCOL-:Can we compare IPFIX with SNMP? Date: Mon, 1 Mar 2004 05:57:08 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA017E04B4@NHROCMBX1.ets.enterasys.com> Thread-Topic: [ipfix-protocol] PROTOCOL-:Can we compare IPFIX with SNMP? Thread-Index: AcP+xU42uOQmbBjsTDOkCGq984gJewAtbPjQ From: "Harrington, David" To: "???" , X-OriginalArrivalTime: 01 Mar 2004 10:57:09.0883 (UTC) FILETIME=[F1C5ACB0:01C3FF7B] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:80.8653 M:99.4056 P:95.9108 R:95.9108 S:74.3522 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Hi, SNMP may appear able to handle this functionality via mib definitions and traps, but it would be inadequate from a performance point of view.=20 The IPFIX protocol needs to be able to gather large amounts of flow information quickly and export it from the device very quickly. SNMP is not designed to export these large amounts of data quickly. We certainly would have considered SNMP if we felt it was applicable. Thank you for taking the time to look over these protocols and for providing your feedback. It is appreciated. David Harrington =20 dbh@enterasys.com co-chair, IETF SNMPv3 WG, concluded > -----Original Message----- > From: fengwf@iei-china.com [mailto:fengwf@iei-china.com]=20 > Sent: Sunday, February 29, 2004 10:02 PM > To: ipfix-protocol@net.doit.wisc.edu > Subject: [ipfix-protocol] PROTOCOL-:Can we compare IPFIX with SNMP? >=20 > Dear all: > I'm a freshman in this field,but when i have taken in=20 > it,I was puzzled about it. It seems that we can extend the=20 > SNMP protocol to realize our object. Maybe we can extend MIB=20 > definations to realize TEMPLATE and by TRAP realize the=20 > communication among exports and collects. You may say the=20 > network flows are active information and don't fit into MIB=20 > definations, but , even so, I think we can utilize the SNMP=20 > protocol instead of restart a new protocol(sure,i doesn't=20 > consider the commercial factors.).some aspects of SNMP are=20 > good,such as pooling and trap machanism, security control=20 > based on user, and the most important it is used widely and=20 > the actual standard. > Please react to me.I am puzzled. > =20 >=20 >=20 >=20 >=20 >=20 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Mar 1 14:15:11 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28673 for ; Mon, 1 Mar 2004 14:15:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Axslu-0005uk-00 for ipfix-list@mil.doit.wisc.edu; Mon, 01 Mar 2004 13:08:10 -0600 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Axslt-0005uc-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 01 Mar 2004 13:08:09 -0600 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i21J85uA003456; Mon, 1 Mar 2004 11:08:06 -0800 (PST) Received: from cisco.com ([10.32.15.71]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA09937; Mon, 1 Mar 2004 11:08:05 -0800 (PST) Message-ID: <40438A15.808@cisco.com> Date: Mon, 01 Mar 2004 11:08:05 -0800 From: Ganesh Sadasivan Organization: Cisco Systems Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: zander@fokus.fraunhofer.de, Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: PROTO-3: IP encapsulated packet [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] References: <402C14CA.30407@cisco.com> <402C2192.1010902@cisco.com> <2147483647.1077036478@[10.1.1.171]> <4032816D.5060204@cisco.com> <2147483647.1077095310@[10.1.1.171]> <403396F3.8000507@cisco.com> <403D0947.7070702@cisco.com> <403F87D4.6050908@fokus.fraunhofer.de> <403FA721.5060403@cisco.com> <1077978876.4040a6fc738b3@wwwnew.fokus.fraunhofer.de> <2147483647.1078054150@mac-0-a-95-6f-6e-46.dhcp.ietf59.or.kr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, If there is no obervability into the IP packet, naming it as an IP flow is incorrect for it is not known if it is an IP flow. The first question would be whether we want to classify such an observation point as IPFIX observation point? I am inclined to say that unless the observation point has the capability to peek into atleast 1 IP header in the packet that it observes, it should not be a valid IPFIX observation point. As far as a flow is concerned, even if the observation point has visibility into IP packets, it may not choose to define flows based on any of the fields in the IP header. Consider one more case. Say an observation point has capability to peek into the first 20 bytes after the L2 header and it receives IP and MPLS packets. For a normal IP packet, the metering process can get the entire header information. But if there is 1 MPLS label, part of the IP header becomes non-observable. If there are 5 or more labels, then not even a single byte of the IP header is visible. In such a case IMO they should not be counted as valid IPFIX flows. What you mentioned about IPSEC is one variation of a general problem of encapsulated packets .i.e " what is the flow definition in the case a packet has multiple encapsulations and the observability into all the encapsulations is limited either because of performance or capability at the observation point." IMHO we could have the following guidelines: 1. The observation Point MUST be able to observe atleast 1 IP header. 2. If there are multiple levels of encapsulation, the flow MAY be defined choosing fields from the encapsulation at any level. This depends on whether the observation point has the capacity to observe the fields that defines the flow. 3. We should build capability in the information model (and while encoding the templates) to describe the encapsulation information along with the field information. Thanks Ganesh Juergen Quittek wrote: > Dear all, > > I have a need for clarification: > > At an IP device, or better: at a device that handles the header of > an IP packet (whether it arrives encapsulated or not) I have no problem > with considering the sub-IP layers as flow attributes or even part of > the flow key. > > But at non-IP devices, for example an ATM or MPLS switch, where > packets/frames/cells are just forwarded based on their label/VPI/VCI > we enter a gray area: If we just look at the labels we need some > higher level/outside information in order to know that there are IP > packets carried with a certain label. Still we do not know if the label > is exclusively used for IP packets, for example when running Ethernet > over MPLS. > > So, if at the observation point no IP packet is visible to be observed, > then why should we call this an observed IP flow? > > A related issue is IPsec. The encapsulated IP flow is not visible at > the IP router forwarding it. Hence, is cannot observe it at the > observation > point. Hence, we do not consider it an observed IP flow. This would be > different in a situation where the router holds a copy of the key that is > needed for decoding the packets. If done so and the IP header can be > observed, > I would call it an observed IP flow (although this smells like > surveillance). > > Thanks, > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Mar 10 11:09:36 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17609 for ; Wed, 10 Mar 2004 11:09:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1B15vL-0001m3-00 for ipfix-list@mil.doit.wisc.edu; Wed, 10 Mar 2004 09:47:11 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1B15vK-0001lx-00 for ipfix@net.doit.wisc.edu; Wed, 10 Mar 2004 09:47:10 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i2AFl8YC003320 for ; Wed, 10 Mar 2004 16:47:08 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 645BAC3A56 for ; Wed, 10 Mar 2004 16:47:05 +0100 (CET) Date: Wed, 10 Mar 2004 16:47:58 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] draft minutes of Seoul session Message-ID: <2147483647.1078937278@[10.1.1.26]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Below find the draft minutes for our session in Seoul. They were recorded by Ralf Wolter with help from Tanja. Please read and comment. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de ======================================= Minutes of the IPFIX session at IETF 59 Wednesday March 3, 15:30 h - 17:30 h ======================================= Minutes taken by Ralf Wolter and Tanja Zseby ---------- Session summary To be inserted here. ---------- 1. WG Status (Juergen Quittek) Juergen presented the list of WG document and summarized their states. I-D draft-leinen-ipfix-eval-contrib-02.txt is a working group document although its name does not indicate it. ---------- 2.1. Requirement I-D: draft-ietf-ipfix-reqs-15.txt (Juergen) The WG discussed on whether encryption should be mandatory to implement or not. The document will not pass IESG if we would change it by weakening the security, so Jürgen proposed to leave it as is. --------- 2.2. Evaluation I-D: draft-leinen-ipfix-eval-contrib-02.txt (Simon Leinen) Simon got some feedback from the AD, so he prepared a revised draft. There are issues with status of the document, but there will be a workaround, a note about the references was added. There are still references to non-RFCs (e.g. requirements I-D) but in most cases the references are ok. [Juergen] Same problem in MIDCOM. There an evaluation documents where postponed until all references I-Ds became RFC. ---------- 3.1. Protocol Specification I-D: draft-ietf-ipfix-protocol-03.txt (Benoit Claise) Benoit described the changes from version 01 to 02 - Time synchronization - IEs for different precision - Flow records with multiple precision possible Q: [Juergen] Does a protocol implementation require support of all precisions? A: [Benoit] MUST only for microseconds (but he will double check) - Linkage with Info Model - Encoding rules - New Security section - Vendor specific information: [Juergen] There was a comment on the mailing list. FlowSet ID 2 and 3 might only be needed, and not 0 and 1 which were defined to be NetFlow compliant. Should be OK if FlowSet ID 0 and 1 are reserved for NetFlow, as the packet header already has a different version number (10) instead of the one which is used by NetFlow (9). - Metering process statistics - Option template for statistics - New proposal on mailing list from Maurizio - Editorial changes - Overview section on IPFIX docs Then he listed changes from version 02 to 03: - Terminology synchronized between protocol and architecture - Flow Expiration - Section Synchronized with architecture - Flow export vs. flow expiration - Editorial changes - Abstract and structure changed - Transport Protocol: finally agreed on SCTP MUST, TCP MAY, UDP MAY Q: [Juergen] Is an implementation compliant if it just supports PR-SCTP? A: [Benoit] MUST for PR-SCTP makes most sense, but I have to ask Nevil. A: [Nevil Brownlee (via Jabber)] I will talk to SCTP people on SCTP vs PR-SCTP. - Input is required for UDP and TCP: [Simon] volunteers to write one of these sections. Then Bemoit showed a list of 30 open issues and discussed some of them. - Exporter Time Accuracy: what if the exporter does not provide microsecond accuracy? [Simon] We should support devices with less accuracy but also export the accuracy provided by the device (option template). Precision field should be added to the template. [Simon (and others)] Support for exporters with less capabilities is needed. They can report their precision. He will send a proposal to the mailing list. - IP encapsulated packets: Benoit addressed the issue of whether limiting IPFIX to IP only or to be flexible for encapsulating protocols such as MPLS. He also roposed to also include GRE, IP-in-IP, IPv6 tunnel, MPLS, AtoM and replace "IP packets" by "packets" in the flow definition. [Juergen] feels that MPLS packets are covered by explicitly mentioning it in the requirements I-D, but AtoM is not. What about IP over Sonet, IP over lambda, SDH, etc.? Why limit to IP? The charter says we have to look for IP packets. [several] Discussion about the IP focus of the charter. Extending beyond IP would slow down the group. Even if we make it open for other protocols but make sure that everyone understands that we limit IPFIX to IP. If we limit it to IP only, there might be an issue with PSAMPs AtoM collection. [AD Bert Wijnen (via Jabber)] Don't try to boil the ocean. - Padding: currently a should for the exporting process, and a must for the collector. Proposal to have a MAY for the exporting process ---------- 3.2. Informatio Model I-D: draft-ietf-ipfix-info-03.txt (Juergen) Paul and Jeff couldn't make it, so Juergen presented. Several editorial changes were applied and the XML representation of the info model was changed. This change included replacing the representation of IPFIX protocol fields and adding an XML representation of field template and abstract data types. Juergen explained the new XML representation, which uses the xml2rfc tool from Marshall Rose. This will make the programming of IPFIX applications easy and increase safety. Juergen listed the open issues: - Datatypes: several changes applied like more precise names, Milliseconds and Nanoseconds were removed. They need to be added again. The IPDR data types were removed. Jeff wants to keep UUID, this needs to be discussed on the mailing list. - Field IDs: Some fields from NetFlowV9 should not be re-used, because they are NetFlow/Cisco specific. Still, the IDs of these fields should be reserved in order to avoid incompatibilities between IPFIX and NetFlowV9. This needs to be considered when registering fields IDs at IANA. - Some NetFlowV9 fields (like in/out packets) do not apply to an observer like a probe. How to deal with them? No comments from the room, to be solved on the mailing list. NFv9 has separate values for IPv4 and IPv6 netmask length. Sampling interval and sampling algorithm is used in NFv9 but probably not required (according to PSAMP). [Tanja,Benoit] Use the the PSAMP info model. - List of not yet used NFv9 fields: there are multiple fields defined by NFv9 which are not yet considered by IPFIX, but are candidates: engineType and engineID. [Benoit] Several line cards at one device require more granularity than the IP address. [Stewart Bryant] Engine ID and txpe are Cisco-specific. NFv9 defines 10 MPLSlabels, shall IPFIX also reserve 10 fields? [Simon] destClassOfService/ToS field should be reproted before and after writing it, maybe refer to DiffServ terminology. [Juergen] Let's sort it out on the mailing list. ---------- 4. new I-D on IPFIX implementation at middleboxes: draft-ietf-ipfix-info-03.txt (Martin Stiemerling) Refer to RFC 3234 for a definition of middleboxes. For IPFIX a clearly indication of the location of the observation point is required. An observation point in the midlebox might be ambiguous. Martin suggests to measure not within a middlebox, but outside of it with a clearly defined observation point. Still it is possible to report the effect of the middlebox on flows as 'middlebox internels. Open issues: - investigate security implications - should this become a WG draft? [Tanja] Middleboxes are not included in the applicability statement, so it should become a separate WG I-D. [Juergen] The results of the paper need to be considered in the info model by fields reporting middlebox internals, such as changed DSCP or tranlated addresses and prot numbers. [Benoit] We standardize export, we should rather not include middlebox recommendations for metering. [Emile Stephane] At least location of observation point should be included in other IPFIX document. Q: [?] Can a router that changes DSCP be a middlebox? A: [Juergen] A router in this case is a routing device with middlebox function. on this devices, the observation point must be defined relative to the middlebox function. Q: [Ralf Wolter] Do we limit IPFIX to ingress? A: [Juergen] No we don't! Conclusion: middlebox discussion to be finalized on the mailing list ---------- 5. WG Schedule Initial I-D Final I-D Deliverable Done Done IPFIX requirements Done May 04 IPFIX architecture Done May 04 IPFIX protocol Done May 04 IPFIX information model Done May 04 IPFIX applicability statement Q: [Juergen] When to finalize the architecture draft? A: [Benoit] May is too early, We will manage to have two iterations until the next IETF meeting. [Juergen] Information model will progress in parallel. [Tanja] I did not receive comments on the applicability I-D, so there is no new version. If more details are be requested, I will produce a new version. Iuggest to finish the protocol document first. Volunteers for sections on RMONMIB and TEWG relations to IPFIX are very welcome. [Benoit] Accidentally, there was no new version on the architecture. Ganesh will post one soon. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Mar 11 08:39:58 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01408 for ; Thu, 11 Mar 2004 08:39:58 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1B1QCp-0006TO-00 for ipfix-list@mil.doit.wisc.edu; Thu, 11 Mar 2004 07:26:35 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1B1QCo-0006TC-00 for ipfix@net.doit.wisc.edu; Thu, 11 Mar 2004 07:26:34 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i2BDQWYC035608 for ; Thu, 11 Mar 2004 14:26:33 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6A69F1108DC for ; Thu, 11 Mar 2004 14:26:31 +0100 (CET) Date: Thu, 11 Mar 2004 09:01:43 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] draft minutes of Seoul session Message-ID: <2147483647.1078995703@[10.1.1.171]> In-Reply-To: <2147483647.1078937278@[10.1.1.26]> References: <2147483647.1078937278@[10.1.1.26]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, The first comments on the minutes are coming from myself: --On 10.03.2004 16:47 Uhr +0100 Juergen Quittek wrote: > Dear all, > > Below find the draft minutes for our session in Seoul. > They were recorded by Ralf Wolter with help from Tanja. > > Please read and comment. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > ======================================= > Minutes of the IPFIX session at IETF 59 > Wednesday March 3, 15:30 h - 17:30 h > ======================================= > > Minutes taken by Ralf Wolter and Tanja Zseby > > ---------- > Session summary > To be inserted here. I forgot inserting the summary: The IPFIX WG discussed open issues of the protocol specification. Major issues were the required accuracy of timestamps. There seems to be agreement on having this unspecified and signaling it within an option record. A suggested extension of the definition of flows to also cover IP packet encapsulation properties was rejected. For several fields that exist in NetFlowV9 but not yet in IPFIX the WG discussed whether or not to include them in the IPFIX information model. A presentation on traffic metering at middleboxes showed that a large set of further fields is required in the information model. Document status: Two documents are already under review at the IESG. The discussion on calling the requirements document back because the security requirements are too hard is closed. The document can progress as it is. The remaining WG documents all have a deadline for completion in May. The editors estimated that this deadline will not be met, but that with two further iterations a stable version would probably be available at the next IETF meeting. > > ---------- > 1. WG Status (Juergen Quittek) > > Juergen presented the list of WG document and summarized document -> documents Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/