From majordomo@mil.doit.wisc.edu Fri Feb 1 07:12:03 2002 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 HAA19768 for ; Fri, 1 Feb 2002 07:12:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Wbnq-0004pu-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Feb 2002 05:24:22 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Wbno-0004pn-00 for ipfix@net.doit.wisc.edu; Fri, 01 Feb 2002 05:24:20 -0600 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g11BQ2Q16446 for ; Fri, 1 Feb 2002 05:26:02 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Feb 2002 05:24:18 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 05:23:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: conference call minutes (was "Re: [ipfix] arch and data con call") Date: Fri, 1 Feb 2002 06:23:19 -0500 Message-ID: Thread-Topic: conference call minutes (was "Re: [ipfix] arch and data con call") Thread-Index: AcGqzLhUptABRwBvTUGa2Ij+K0KeXwARwMtA From: To: , Cc: X-OriginalArrivalTime: 01 Feb 2002 11:23:20.0573 (UTC) FILETIME=[DA71B2D0:01C1AB12] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA19768 Hello Wang, Reinaldo, I also wanted to contribute for security section - it was not came up on the minutes. May be we can plan our action to come up with combined text. Regards Ramg >-----Original Message----- >From: ext Wang, Cliff [mailto:CWang@smartpipes.com] >Sent: Thursday, January 31, 2002 9:51 PM >To: 'plonka@doit.wisc.edu' >Cc: ipfix@net.doit.wisc.edu >Subject: RE: conference call minutes (was "Re: [ipfix] arch >and data con >call") > > >I (from SmartPipes)participated the call also and volunteered >to write the >security section and works on the NAT part with Reinaldo Penno. > > > >-----Original Message----- >From: Dave Plonka [mailto:plonka@doit.wisc.edu] >Sent: Thursday, January 31, 2002 4:23 PM >To: ipfix@net.doit.wisc.edu >Subject: conference call minutes (was "Re: [ipfix] arch and >data con call") > > > >IPFIX folks, > >Below, please find the minutes that I prepared following a >conference call >that was arranged to organize the IPFIX Internet Draft efforts. > >Thanks to KC Norseth and Enterasys for hosting the conference >call. A list >of those that participated follows the minutes below. > >---------------------------------------------------------------------- > >The call began Thu Jan 31 ~1300 CST 2002. > >The conference call roughly followed an agenda prepared by KC Norseth. > >During the discussion various people volunteered to be responsible for >contributing info on particular topics. Their names are noted below in >context. > >These topics were discussed: > >*) Why are three proposed draft documents laid out this way? > * IPFIX Requirements > * IPFIX Architecture > it was noted that protocol doesn't belong in Architecture > * IPFIX Data Model > > Specifically, the question was asked why not a protocol document. > (We discussed that we're not chartered to design a protocol, but > to concentrate on standardizing existing practice.) > > There is some confusion about what items belong in the Architecture > rather than Data model and vice versa. > >*) We discussed points suggested for the Architecture draft... > The first was "Summary of Operation": > > It was noted that some things about the flow definition (such as > what causes a flow to be instantiated, and what temporal > characteristics they have) are important to specifying the IPFIX > architecture. > >*) It was noted that the components or entities (and possibly >interfaces > between) are a key portion of the Architecture document. > > Capabilities negotiation was also mentioned for the Architecture. > Kevin Zhang volunteered to work on this. > > It was mentioned that a work-in-progress Internet Draft document > by Benoit and Ganesh does a good job of laying this out. > > It was also mentioned that the Architecture doc should lay out > a number of architecture/component "scenarios". > > It was discussed as to whether or not the Requirements document > should specify the flow definition. There was not support voiced > for making it more specific. > > There were other kudos for Benoit's & Ganesh's document for its > description of the flow "concept". > >*) Message formats > > It was noted that "messages formats" mostly belongs in a protocol > specification so may be out of scope. However, it was noted that > the items of information would be necessary for the Architecture > specification. > > Some folks referred to this as the "information model". > KC Norseth, Paul Calato, and Simon Leinen volunteered to work > on specifying this information. > > It was noted that the handshaking or interfaces between components > does belong in the Architecture. > > It was considered whether or not the "information model" belongs in > architecture or data model. It was suggested that perhaps it would > be best to focus on enumerating the important topics, and fit them > into the documents afterward. This idea was supported by others as > well. > > Kevin Zhan, Ram Gopal, Man Li, and +Benoit Claise volunteered to > work on the Architecture. > > Juergen Quittek volunteered to work work on Terminology. > >*) It was mentioned it was hoped that Benoit's & Ganesh's document > might serve as a strawman, or starting point for the next WG > document. > > The question was raised as to what would be best to do immediately > with that document. It was suggested that it be submitted as an > individual draft, and it will be considered as a template or as > input to working group documents, like other individual drafts that > have been prepared by other IPFIX participants. > >*) KC Norseth volunteered to work on Error Detection / Handling, and > data recovery. > > Other issues were raised as possibilities for needed to be addressed > in some fashion by the Architecture document. These include NAT, > firewalls and middleboxes. > > Reinaldo Penno volunteered to work on the NAT/firewall, and midcom > issues/interactions. > >*) KC Norseth volunteered to serve as document editor. > >*) The point was raised that the upcoming IPFIX document(s) >should address > or mention interactions with other IETF-specified topics such as > AAA, and Intrusion Detection. > > Tanja Zseby volunteered some information about AAA and >configuration for > flow export. > >*) It was noted that the I-D draft deadline is soon for the documents > as listed in our WG milestones. The submission deadlin is Feb. 22 > for IETF 53. > > As such, thee was support for setting a deadling of Friday, Feb. 8, > 2002 for those that volunteer info (above) to submit it to the > editor, preferably via the IPFIX mailing list >. > >*) It was suggested that, until we collect the information from those > volunteers and whether it fits into Architecture and Data Model > documents, perhaps we should refer to it as a (single) "design" > document for the time being. > >We signed off from the call at Thu Jan 31 ~1400 CST 2002. > >The following (at least) joined the conference call: > > George Carle > Tanja Zseby > Paul Calato > Dave Plonka > Kevin Zhang > KC Norseth > Bill Richards > Will Eatherton > Benoit Claise > Ganesh Sadasivan > Vamsi Valluri > Ram Gopal > Jc Martin > Carter Bullard > Juergen Quittek > Reinaldo Penno > Nevil Brownlee > Simon Leinen > >---------------------------------------------------------------------- > >Any errors are mine, but please follow-up to the mailing list >if you have >substantive corrections. > >Respectfully, >Dave > >-- >plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka >ARS:N9HZF Madison, >WI > >-- >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/ > >-- >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/ > -- 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 Fri Feb 1 09:06:02 2002 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 JAA22423 for ; Fri, 1 Feb 2002 09:06:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Wdzq-0000dp-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Feb 2002 07:44:54 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Wdzo-0000di-00 for ipfix@net.doit.wisc.edu; Fri, 01 Feb 2002 07:44:52 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id IAA26313; Fri, 1 Feb 2002 08:54:11 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma026278; Fri, 1 Feb 02 08:53:23 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 08:43:17 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA0641@slc-exc1.ctron.com> From: "Norseth, KC" To: "'plonka@doit.wisc.edu'" , ipfix@net.doit.wisc.edu Subject: RE: conference call minutes (was "Re: [ipfix] arch and data con c all") Date: Fri, 1 Feb 2002 08:43:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB26.6C519F40" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AB26.6C519F40 Content-Type: text/plain Nevil said he would give something on IPFIX, RTFM and mibs like rfc2720 , rfc2123 |-----Original Message----- |From: Dave Plonka [mailto:plonka@doit.wisc.edu] |Sent: Thursday, January 31, 2002 2:23 PM |To: ipfix@net.doit.wisc.edu |Subject: conference call minutes (was "Re: [ipfix] arch and |data con call") | | | |IPFIX folks, | |Below, please find the minutes that I prepared following a |conference call that was arranged to organize the IPFIX |Internet Draft efforts. | |Thanks to KC Norseth and Enterasys for hosting the conference |call. A list of those that participated follows the minutes below. | |---------------------------------------------------------------------- | |The call began Thu Jan 31 ~1300 CST 2002. | |The conference call roughly followed an agenda prepared by KC Norseth. | |During the discussion various people volunteered to be |responsible for contributing info on particular topics. Their |names are noted below in context. | |These topics were discussed: | |*) Why are three proposed draft documents laid out this way? | * IPFIX Requirements | * IPFIX Architecture | it was noted that protocol doesn't belong in Architecture | * IPFIX Data Model | | Specifically, the question was asked why not a protocol document. | (We discussed that we're not chartered to design a protocol, but | to concentrate on standardizing existing practice.) | | There is some confusion about what items belong in the Architecture | rather than Data model and vice versa. | |*) We discussed points suggested for the Architecture draft... | The first was "Summary of Operation": | | It was noted that some things about the flow definition (such as | what causes a flow to be instantiated, and what temporal | characteristics they have) are important to specifying the IPFIX | architecture. | |*) It was noted that the components or entities (and possibly |interfaces | between) are a key portion of the Architecture document. | | Capabilities negotiation was also mentioned for the Architecture. | Kevin Zhang volunteered to work on this. | | It was mentioned that a work-in-progress Internet Draft document | by Benoit and Ganesh does a good job of laying this out. | | It was also mentioned that the Architecture doc should lay out | a number of architecture/component "scenarios". | | It was discussed as to whether or not the Requirements document | should specify the flow definition. There was not support voiced | for making it more specific. | | There were other kudos for Benoit's & Ganesh's document for its | description of the flow "concept". | |*) Message formats | | It was noted that "messages formats" mostly belongs in a protocol | specification so may be out of scope. However, it was noted that | the items of information would be necessary for the Architecture | specification. | | Some folks referred to this as the "information model". | KC Norseth, Paul Calato, and Simon Leinen volunteered to work | on specifying this information. | | It was noted that the handshaking or interfaces between components | does belong in the Architecture. | | It was considered whether or not the "information model" belongs in | architecture or data model. It was suggested that perhaps it would | be best to focus on enumerating the important topics, and fit them | into the documents afterward. This idea was supported by others as | well. | | Kevin Zhan, Ram Gopal, Man Li, and +Benoit Claise volunteered to | work on the Architecture. | | Juergen Quittek volunteered to work work on Terminology. | |*) It was mentioned it was hoped that Benoit's & Ganesh's document | might serve as a strawman, or starting point for the next WG | document. | | The question was raised as to what would be best to do immediately | with that document. It was suggested that it be submitted as an | individual draft, and it will be considered as a template or as | input to working group documents, like other individual drafts that | have been prepared by other IPFIX participants. | |*) KC Norseth volunteered to work on Error Detection / Handling, and | data recovery. | | Other issues were raised as possibilities for needed to be addressed | in some fashion by the Architecture document. These include NAT, | firewalls and middleboxes. | | Reinaldo Penno volunteered to work on the NAT/firewall, and midcom | issues/interactions. | |*) KC Norseth volunteered to serve as document editor. | |*) The point was raised that the upcoming IPFIX document(s) |should address | or mention interactions with other IETF-specified topics such as | AAA, and Intrusion Detection. | | Tanja Zseby volunteered some information about AAA and |configuration for | flow export. | |*) It was noted that the I-D draft deadline is soon for the documents | as listed in our WG milestones. The submission deadlin is Feb. 22 | for IETF 53. | | As such, thee was support for setting a deadling of Friday, Feb. 8, | 2002 for those that volunteer info (above) to submit it to the | editor, preferably via the IPFIX mailing list |. | |*) It was suggested that, until we collect the information from those | volunteers and whether it fits into Architecture and Data Model | documents, perhaps we should refer to it as a (single) "design" | document for the time being. | |We signed off from the call at Thu Jan 31 ~1400 CST 2002. | |The following (at least) joined the conference call: | | George Carle | Tanja Zseby | Paul Calato | Dave Plonka | Kevin Zhang | KC Norseth | Bill Richards | Will Eatherton | Benoit Claise | Ganesh Sadasivan | Vamsi Valluri | Ram Gopal | Jc Martin | Carter Bullard | Juergen Quittek | Reinaldo Penno | Nevil Brownlee | Simon Leinen | |---------------------------------------------------------------------- | |Any errors are mine, but please follow-up to the mailing list |if you have substantive corrections. | |Respectfully, |Dave | |-- |plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka |ARS:N9HZF Madison, WI | |-- |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/ | ------_=_NextPart_001_01C1AB26.6C519F40 Content-Type: text/html RE: conference call minutes (was "Re: [ipfix] arch and data con call")

Nevil said he would give something on IPFIX, RTFM and mibs like rfc2720 , rfc2123

|-----Original Message-----
|From: Dave Plonka [mailto:plonka@doit.wisc.edu]
|Sent: Thursday, January 31, 2002 2:23 PM
|To: ipfix@net.doit.wisc.edu
|Subject: conference call minutes (was "Re: [ipfix] arch and
|data con call")
|
|
|
|IPFIX folks,
|
|Below, please find the minutes that I prepared following a
|conference call that was arranged to organize the IPFIX
|Internet Draft efforts.
|
|Thanks to KC Norseth and Enterasys for hosting the conference
|call. A list of those that participated follows the minutes below.
|
|----------------------------------------------------------------------
|
|The call began Thu Jan 31 ~1300 CST 2002.
|
|The conference call roughly followed an agenda prepared by KC Norseth.
|
|During the discussion various people volunteered to be
|responsible for contributing info on particular topics.  Their
|names are noted below in context.
|
|These topics were discussed:
|
|*) Why are three proposed draft documents laid out this way?
|   * IPFIX Requirements
|   * IPFIX Architecture
|        it was noted that protocol doesn't belong in Architecture
|   * IPFIX Data Model
|
|   Specifically, the question was asked why not a protocol document.
|   (We discussed that we're not chartered to design a protocol, but
|   to concentrate on standardizing existing practice.)
|
|   There is some confusion about what items belong in the Architecture
|   rather than Data model and vice versa.
|
|*) We discussed points suggested for the Architecture draft...
|   The first was "Summary of Operation":
|
|   It was noted that some things about the flow definition (such as
|   what causes a flow to be instantiated, and what temporal
|   characteristics they have) are important to specifying the IPFIX
|   architecture.
|
|*) It was noted that the components or entities (and possibly
|interfaces
|   between) are a key portion of the Architecture document.
|
|   Capabilities negotiation was also mentioned for the Architecture.
|   Kevin Zhang volunteered to work on this.
|
|   It was mentioned that a work-in-progress Internet Draft document
|   by Benoit and Ganesh does a good job of laying this out.
|
|   It was also mentioned that the Architecture doc should lay out
|   a number of architecture/component "scenarios".
|
|   It was discussed as to whether or not the Requirements document
|   should specify the flow definition.  There was not support voiced
|   for making it more specific.
|
|   There were other kudos for Benoit's & Ganesh's document for its
|   description of the flow "concept".
|
|*) Message formats
|
|   It was noted that "messages formats" mostly belongs in a protocol
|   specification so may be out of scope.  However, it was noted that
|   the items of information would be necessary for the Architecture
|   specification.
|
|   Some folks referred to this as the "information model".
|   KC Norseth, Paul Calato, and Simon Leinen volunteered to work
|   on specifying this information.
|
|   It was noted that the handshaking or interfaces between components
|   does belong in the Architecture.
|
|   It was considered whether or not the "information model" belongs in
|   architecture or data model.  It was suggested that perhaps it would
|   be best to focus on enumerating the important topics, and fit them
|   into the documents afterward.  This idea was supported by others as
|   well.
|
|   Kevin Zhan, Ram Gopal, Man Li, and +Benoit Claise volunteered to
|   work on the Architecture.
|
|   Juergen Quittek volunteered to work work on Terminology.
|
|*) It was mentioned it was hoped that Benoit's & Ganesh's document
|   might serve as a strawman, or starting point for the next WG
|   document.
|
|   The question was raised as to what would be best to do immediately
|   with that document.  It was suggested that it be submitted as an
|   individual draft, and it will be considered as a template or as
|   input to working group documents, like other individual drafts that
|   have been prepared by other IPFIX participants.
|
|*) KC Norseth volunteered to work on Error Detection / Handling, and
|   data recovery.
|
|   Other issues were raised as possibilities for needed to be addressed
|   in some fashion by the Architecture document.  These include NAT,
|   firewalls and middleboxes.
|
|   Reinaldo Penno volunteered to work on the NAT/firewall, and midcom
|   issues/interactions.
|
|*) KC Norseth volunteered to serve as document editor.
|
|*) The point was raised that the upcoming IPFIX document(s)
|should address
|   or mention interactions with other IETF-specified topics such as
|   AAA, and Intrusion Detection.
|
|   Tanja Zseby volunteered some information about AAA and
|configuration for
|   flow export.
|
|*) It was noted that the I-D draft deadline is soon for the documents
|   as listed in our WG milestones.  The submission deadlin is Feb. 22
|   for IETF 53.
|
|   As such, thee was support for setting a deadling of Friday, Feb. 8,
|   2002 for those that volunteer info (above) to submit it to the
|   editor, preferably via the IPFIX mailing list
|<ipfix@net.doit.wisc.edu>.
|
|*) It was suggested that, until we collect the information from those
|   volunteers and whether it fits into Architecture and Data Model
|   documents, perhaps we should refer to it as a (single) "design"
|   document for the time being.
|
|We signed off from the call at Thu Jan 31 ~1400 CST 2002.
|
|The following (at least) joined the conference call:
|
|   George Carle
|   Tanja Zseby
|   Paul Calato
|   Dave Plonka
|   Kevin Zhang
|   KC Norseth
|   Bill Richards
|   Will Eatherton
|   Benoit Claise
|   Ganesh Sadasivan
|   Vamsi Valluri
|   Ram Gopal
|   Jc Martin
|   Carter Bullard
|   Juergen Quittek
|   Reinaldo Penno
|   Nevil Brownlee
|   Simon Leinen
|
|----------------------------------------------------------------------
|
|Any errors are mine, but please follow-up to the mailing list
|if you have substantive corrections.
|
|Respectfully,
|Dave
|
|--
|plonka@doit.wisc.edu  http://net.doit.wisc.edu/~plonka 
|ARS:N9HZF  Madison, WI
|
|--
|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/
|

------_=_NextPart_001_01C1AB26.6C519F40-- -- 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 Fri Feb 1 11:57:16 2002 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 LAA03437 for ; Fri, 1 Feb 2002 11:57:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Wgbh-0004Ku-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Feb 2002 10:32:09 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Wgbf-0004Km-00 for ipfix@net.doit.wisc.edu; Fri, 01 Feb 2002 10:32:07 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id LAA10732 for ; Fri, 1 Feb 2002 11:41:26 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma010692; Fri, 1 Feb 02 11:40:25 -0500 Received: by cnc-exc2.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 11:30:22 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA0643@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Wang, Cliff'" , "Calato, Paul" Cc: "'ipfix@net.doit.wisc.edu'" Subject: [ipfix] NAT repoiting (was agenda) Date: Fri, 1 Feb 2002 11:30:23 -0500 X-MS-TNEF-Correlator: <59358A738F45D51186A30008C74CE250DA0643@slc-exc1.ctron.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1AB3D.BF31EF00" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1AB3D.BF31EF00 Content-Type: text/plain I am sending this to the whole list for concensus and comments.... Is it out of scope? It is definitly not a key component of the IPFIX data, where it is not even possible to get in a lot of circumstances. It does contain part of the Flow Information of a flow. If we can report it, it would be useful for attributes. What NAT atreibutes would want to be reported ? K.C. |-----Original Message----- |From: Wang, Cliff [mailto:CWang@smartpipes.com] |Sent: Friday, February 01, 2002 9:18 AM |To: Calato, Paul |Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; |kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix data; |ipfix chairs |Subject: RE: Agenda | | |Agree. But finding the NAT info should be out of the scope of this WG. | |On the other hand, the collector may have to deal the nasty |NAT issue when the flow reported may contain address of a |different address space. How to interprete that address seems |to me something we need to look at. | |The other issue is whether we will allow some kind of NAT ALG, |which translate the address in the report. Thoughts? | |-----Original Message----- |From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] |Sent: Friday, February 01, 2002 10:52 AM |To: Wang, Cliff |Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; |kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix data; |ipfix chairs |Subject: Re: Agenda | | | |We should provide a way to report the NAT info if the |device knows it. It is not a required field since not |all devices will have it. IMHO it should be reported |as attributes of one flow, not multiple flows. | |Paul | |"Wang, Cliff" wrote: |> |> The problem is that the NAT box is in the path and the probe may not |> have any knowledge of the outside IP address it may get |assigned. The |> collector may know the mapping if it knows the inside |private address |> of the probe. |> |> -----Original Message----- |> From: Benoit Claise [mailto:bclaise@cisco.com] |> Sent: Thursday, January 31, 2002 1:46 PM |> To: Reinaldo Penno |> Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; |> ipfix data; ipfix chairs |> Subject: Re: Agenda |> |> Hi all |> |> > |> > |> > other comments (not necessarily to be discussed on the call) |> > Concerning some form of capabilities negotiation I have It is also |> > useful for the case of overlapping flows (discussed on the list) |> > |> > Middlebox: |> > What about when the device is also a middlebox ? (sorry if this was |> > already hashed out on the list) If using NAT/NAPT should |the device |> > export the flow on the private side, public side or both? |Should the |> > behavior be agreed on the capabilities negotiation? |> |> It's in my mind the same behaviour as for unidirectional and |> bidirectional flows. |> In case the exporter has got the knowledge of the bi-directional |> flows and in case the bi-directional information make sense, the |> exporter MAY choose to export in the same Template/Flow Record, |> along with bidirectional accounting information. |> So |> In case the exporter is doing NAT, the exporter MAY choose to |> export |> |> in the same Template/Flow Record, both inside and outside ip |> addresses |> |> This just implies that the information model MUST have inside and |> outside IP addresses defined. |> |> Regards, Benoit |> |> > |> > |> > I think the most useful behavior would be export the flows on the |> > private and public side within the same record (or if in different |> > records provide some key to bind them together), so you know the |> > complete flow end-to-end. But in this case although we have two |> > seprate flows, it is still the same packet. Same reasoning can be |> > applied for proxy, proxy firewalls, etc. |> > |> > It would be impossible for a external probe to provde NAT |> > information. All it sees is the snapshot of what is passing by. |> > This could be worked out as a MAY. Whether it is resolved or not, |> > we should clarify the stance on NAT in the archecture. |> > |> > |> > [Penno, Reinaldo [SC9:T327:EXCH]] |> > |> > I wouldn't say it's impossible. It depends if the platform keeps |> > "memory" (full stateful NATs, proxies) or not . And yes, I agree |> > that whatever the outcome we should clarify NAT/NAPT |behavior on the |> > doc. |> > |> > regards, |> > |> > Reinaldo |> > |> > |> > | ------_=_NextPart_000_01C1AB3D.BF31EF00 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhcQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0gcCAAEACwAeABcABQAhAQEggAMADgAAANIHAgAB AAsAHgAVAAUAHwEBCYABACEAAABBNTI2QTY4ODI2MTdENjExODZBNjAwMDhDNzRDRTI1MADrBgEE gAEAHQAAAE5BVCByZXBvaXRpbmcgICAod2FzIGFnZW5kYSkAUAkBDYAEAAIAAAACAAIAAQOQBgCA DwAAMQAAAAMACVkBAAAACwARgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUAAAAAAAADAACACCAGAAAA AADAAAAAAAAARgAAAABShQAAzZIBAB4AAYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAA ADEwLjAAAAAACwACgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAAOACCAGAAAAAADAAAAA AAAARgAAAAABhQAAAAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAACwAFgAggBgAA AAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAaACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMA CIAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAgEJEAEAAAAdCgAAGQoAAJ0UAABMWkZ1ZHId yQMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo 4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSZAg YW0gFBBuZAuAsGcgdGgEAB2wbx2xsGUgd2gG8B5gbAQATwVAAhAFwAWgbmMJ8HPWdQQgAHBkH2Ft B4ACMLxzLiDRCqIKhAqASQQgbmkFQAhgIhFmHTAFoHD4ZT8gHOAFQB3hAQELgEEiAGx5IG5vBUBh 2CBrZSQAIFFwAiAgkYMiYh5CSVBGSVgjcPphAZAsHnEEkB5gIgEd4WkkImV2CfAgJPAEEGn3AmAe YB4RZxQgIfADoCRgAxewIlNjaXJjdW2fHwAAcB+gIMAjA2RvB5HfH3EBkCjhCrElR0YXsAfgzElu HzEAwHRpAiAiYl0kYGYscSpyIoB3HmBjfwORGCAk8CvBIgAmcCIBd/UIYGwgMGIeYB/gARAv0Gsf IyZAdAUQYiJAKlNX4xPgBUBOQVQw4RggMTT9L6V3AHAFQB4RMBEu1AmAxCA/IRpLLkMhCyEU1Hwt NuJPBRBnC4AHQHMF0AeQc2EooDbjNnVGrQNhOjGwAHBnJnBDHuA5ASAgWwDAAxAeEDpD2TlSQHMA wAAgcAUgKlH9IFFdCuM2sQZgAjA5MDjwCmkmMHkmcEZlYnJmdQrAJAAwMSZwAdAwoRRAOToxOBDA TTZ1XlQ6cBIgB0AmQG8mcFAmYS/QNnVDYzkwJ0I9CfBvIgE5sAtwFBAnO/8H8DKAN4Eq0D/wCfAk IEHglk4FsBQRaCZwS0NB4Ms2dSSAdguALnoT4DrB8ngA0GN0O5JB4DVyQvb3QeAFICOgeB0AKcBG ZyYyL0O3RpQT0Smwczv2dWKmagWQPJFSRTkwQSigfR1gYTZ1SuxKgAnRKnBC/yJBI6EddR5gMhIL gAIQHTB/HpAv1SI1HkIioyVUHeFX9kchBUtGTwOgHkIkMCah+iBEsWQmcB5CF5EesEUw/wWxAMAk ABPgJ6AeAgEAN5H/HkI3gB8AJAA2dU2jBBAKUD8mglGELcI0CFOCKyZhZP5kGCAEES1zNnUdcAEg JrG7JTFYdnMKsB+gKnBILIHnHhELgA6wcnAYIA6wHbH/MeFaVwngKfA75h4RB4AdMP8DcENBHYIu YSUQNHEeERew7G9rMOFQjVRRt1XkHeH/JpFR8y5hA/BTAB0AUwAsgR9eYiRwTPEiYjISQUxHryZw NnUegA3gaB2wcgBx/z+hXEIeYFh2KOEeQi7UKnDzYRAIYGdoILA0pUtGNu/vN/85Ay6QP6JABRAn oBQA/x4QJREUIDuSOgdsD20VO9/jPO899TEwOg5APqw5Wf9AT0FfQm9Df0SPRZ9Gr0e/u0jPSdZl Sm9+z2lwV09h+05EXABveCABACRRM2AkAP8eES7VTWsGkB4yWUZ4ER+g+yRwJCB3IeIqcCMkJCQY INxxdSmwNHEjoGUv4QCQ/x+RJBJpJWNBI3GEQjLhYwLjU8OE801ITyHyTjg0Fv+Hdh/xMQciYiUB LbMmcCQi/m0v0C0gC1BWtCphfxxACXVpJSI5WSIecANgDrA6/WklPm+mkjBhEoEBKDEdIP8d4jHS TWYG4HqQHeFnNQqw/x3AIAOVQ5MxHmBTgodIkjDfU8MAcCQAhJIesGQooCVW/yIxAJCBUSXQZqiN YVORKKLriycAkGclEGRoAh5gkcfvUuyEkh4zAMBwO0AdkYNR/yIBhJQeQguAmYNpJVwAbID/ZjJY dpHHJWWWU1CGkjlpn59qrpIwOPR0yzoHYmN1Q/5AKaAioW9To0dwJGEQCHBac3CzSgBwPYMzcac6 /DQ2P/A+xpLBP1F1zKNH/3Rydst4D3kfeiyjR3safE/PqcN9j36WkjlIaWMytq88ID64v7khUdUg ViAo/yQiJRAqQWqgBRAj8TO0HXA/BPAf4BQQZCFRhG4RbCn/ufkIUB+RBKAdgmOjLNIpYz+ekAGg AxAiAAiQJzFlZ/8kMAcwLSMc8FPDIyQHQF5g/7ipMDq91KehjHJskQtgnqS/jhO7gL0PHuK+Wbn5 TXCg/mQesJShkbiSMDHDAaAiMu9WR4QlwsYkYG3JVjSQu4D9XmByPaGDU2ISVOC5+QdA/xggWHBT ok4wvXIiQsdJLiLXH+AdgjIRLzIQUDIwTjX/XZbLqLn5DsCCN1bTvaWg5tuZgiZwcEnAHuBj1rMi IP8FwAbgHcAi8G+2TkQeQrn5/zAQU8EtMNfxZpEJwr2JwL+vLRNoppI5IyAnZxNtJAD/zOCV5Wqg XjHaRQhwHQAEIP0fMnUDAB1wGCCwwC0xpRH/IBHdd9wg4WqOFN135KIssP/E1B5C1NRSEwQgwYEe M5hP/dwgLeFp5CvGJCASKOHlJ//oHE3TLPYAwCSAHTIUEFKD4+Qr5bdNQVl8kV/A5ULvHiDU1Wc1 39NUXVALUQ6w/i8sY3XABaFScOQrB0ACIP9e4SIAZbDi7LChCGACMJ7D+yzIozhTrijkv+XGI1J0 8P/R1FKE7p/vpN131NTdf/eD//B/8Y7YA5/2IBKZVgUg/KffWHUHkPyvaBEd4Wof4CMxP/7hwSKT 1+wbFXGlIVVT/2SQiPQAh6HomW8q8SODnAHrAu91sWcbIXMmcKb0Cn//uT+6RBzwXqJf4J5DJ/Cn QP8wRdpHL7fU3VjRUYO5+aDn/yAh1yrzsv4K4YHyQbuAMMH/nwIo8Fm4ufkWRKHAgQZjpH8kkTOy 31UdIB4QKKEmoSn7JnDDEXkiMJ3oufkkwh6w16ExVtO2YS0/wC22YUyE/2czzmHE4+jQlaBoQi5S U8T/L7DDOnbwXABmMo4TL2POYb8EcGMC35da4RnwZ/FTFgT/VODB8F7CLpIwEc7KxcAE0feGYTDB gQF4cNEno0zRTFDvM2BTAAvxXCBjCmgOSy+Z/wShD9CZgJNRMKTv8VvRpQL/llT7gYECgVEyEbn5 9Zo+oF9jEYnSTGCE0Z+kc6UAcP9OMU7zYkDKsc5hlYCbsV7R/GJ5L6DDOgQD9QFOdBEQ/nIZ8NBE i5LvEjLRypBiZP8jBFihUvDFcGQh4KCFkWTn37piIKFONahhoPBmgcFPUv9YIIcCwfFNpGZkesFJ 8aqAd6MpDa+6U1t2U40gdcdbAFNDOTpUMzI3wDpFWENIXaloDkz5ERNuJ4nhU5GJ0N6yK4f/hRMJ 8E+w6jCE0aKFbjHAE/cZ8IIgzroi/pAPwKtQkUD+KMQh9MA58aEwxCKUYQvxbyeiwSHRUDdkIC+h 6jF5/wnAjSDCINsDwzpcYzGy08D/utGZFW1RYtE4r9IHkBXaR/+9pbn5+VApTxhGC7RQb7piL3XG Uj9Uf39XfVbAAAAAHgBwAAEAAAAdAAAATkFUIHJlcG9pdGluZyAgICh3YXMgYWdlbmRhKQAAAAAC AXEAAQAAABsAAAABwas8AmQY2EsY5KNPPad1dDdQXnfpAAAu4OAAAwAuAAAAAAALAAIAAQAAAB4A QhABAAAARgAAADw0NjUyNjQ0Qjk4REZGMzQ2OTY4MDFGOEYzMDcwRDNGRTAxMTg4NjRGQEQyQ1NQ RVhNMDAxLnNtYXJ0cGlwZXMuY29tPgAAAAMA3j+fTgAAAwD9P+QEAABAADkAAO8xvz2rwQEDAPE/ CQQAAB4AMUABAAAACQAAAEtDTk9SU0VUAAAAAAMAGkAAAAAAHgAwQAEAAAAJAAAAS0NOT1JTRVQA AAAAAwAZQAAAAAADACYAAAAAAAMANgAAAAAAAwCAEP////8LAPIQAQAAAAMAkhABAAAAAgFHAAEA AAAxAAAAYz1VUzthPSA7cD1jdHJvbjtsPVNMQy1FWEMxLTAyMDIwMTE2MzAyM1otMTk3OTYzAAAA AAIB+T8BAAAASwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1DVFJPTi9PVT1TSVRF LVNJWC9DTj1SRUNJUElFTlRTL0NOPUtDTk9SU0VUAAAeAPg/AQAAAAwAAABOb3JzZXRoLCBLQwAe ADhAAQAAAAkAAABLQ05PUlNFVAAAAAACAfs/AQAAAEsAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEA AAAAAAAAL089Q1RST04vT1U9U0lURS1TSVgvQ049UkVDSVBJRU5UUy9DTj1LQ05PUlNFVAAAHgD6 PwEAAAAMAAAATm9yc2V0aCwgS0MAHgA5QAEAAAAJAAAAS0NOT1JTRVQAAAAAQAAHMHpMLb89q8EB QAAIMETvQ749q8EBHgA9AAEAAAABAAAAAAAAAB4AHQ4BAAAAHQAAAE5BVCByZXBvaXRpbmcgICAo d2FzIGFnZW5kYSkAAAAAHgA1EAEAAAA8AAAAPDU5MzU4QTczOEY0NUQ1MTE4NkEzMDAwOEM3NENF MjUwREEwNjQzQHNsYy1leGMxLmN0cm9uLmNvbT4ACwApAAAAAAALACMAAAAAAAMABhCWDmsaAwAH EKEMAAADABAQAAAAAAMAERAKAAAAHgAIEAEAAABlAAAASUFNU0VORElOR1RISVNUT1RIRVdIT0xF TElTVEZPUkNPTkNFTlNVU0FORENPTU1FTlRTSVNJVE9VVE9GU0NPUEU/SVRJU0RFRklOSVRMWU5P VEFLRVlDT01QT05FTlRPRlRIRQAAAAACAX8AAQAAADwAAAA8NTkzNThBNzM4RjQ1RDUxMTg2QTMw MDA4Qzc0Q0UyNTBEQTA2NDNAc2xjLWV4YzEuY3Ryb24uY29tPgCV9w== ------_=_NextPart_000_01C1AB3D.BF31EF00-- -- 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 Fri Feb 1 12:16:25 2002 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 MAA04474 for ; Fri, 1 Feb 2002 12:16:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Wgx7-0004o2-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Feb 2002 10:54:17 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Wgx6-0004nM-00 for ipfix@net.doit.wisc.edu; Fri, 01 Feb 2002 10:54:16 -0600 Received: from riverstonenet.com (134.141.180.91 [134.141.180.91]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X7WWDYKP; Fri, 1 Feb 2002 08:53:07 -0800 Message-ID: <3C5AC7F3.2081A845@riverstonenet.com> Date: Fri, 01 Feb 2002 11:53:07 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Wang, Cliff" , ipfixx Subject: [ipfix] Re: NAT (aka agenda) References: <4652644B98DFF34696801F8F3070D3FE01188650@D2CSPEXM001.smartpipes.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit "Wang, Cliff" wrote: > > Comments in line. > > -----Original Message----- > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: Friday, February 01, 2002 11:31 AM > To: Wang, Cliff > Subject: Re: Agenda > > "Wang, Cliff" wrote: > > > > Agree. But finding the NAT info should be out of the scope of this WG. > > Not sure what you mean by "finding the NAT info". How the > device retrieves any of the info is beyond the scope > of the WG. We just provide a way to report it. > > [cliff] we are saying the same thing. > > > > > On the other hand, the collector may have to deal the nasty NAT issue > > when the flow reported may contain address of a different address > > space. How to interprete that address seems to me something we need to > > look at. > > > > The other issue is whether we will allow some kind of NAT ALG, which > > translate the address in the report. Thoughts? > > Collectors may do a lot of stuff based on information > which they got from non-IPFIX sources. But we, I don't > think, are investigating that. > > [cliff] > What I am think are the following cases: > 1) NAT does the report packet header address translation. The payload is not > touched. > Then the question is the report may carry private address that collector > may or may not recognize. > > 2) NAT does the report packet header address translation. If ipfix ALG is > built, it may also translate the IP address in the report. Then collector > doesn't care the private address space at all. But doing NAT ALG is > difficult and may not be applicable all the time. Still not quite sure I follow. So let me go through step by step and then you can point out where I've gone off track. 1) If the reporting device does not know any NAT info is can only report the IP's it sees in the packet. No affect on IPFIX in this case. If the collector has no NAT knowledge, the reports only show addresses seen. No affect on IPFIX. If the collector does have NAT knowledge it MAY be able to report on public or private addresses based on info it has. What ever the collector does and how it does it in this case is outside IPFIX. 2) the reporting device does have NAT knowledge. Lets say the reporting device is the one performing the translation. In this case IPFIX should provide a way to report the private and public addresses for the flow. This does affect IPFIX. If the collector has no NAT knowledge, it can make use of the data reported by the device, but no new requirements on IPFIX. If the collector has NAT knowledge, it can either use the info provided by the reporting device or it's own info. But no new requirements on IPFIX. So as I see it, the only time the IPFIX WG takes NAT into consideration is when the reporting device wants to transport NAT related info for a particular flow. Paul > > > > > -----Original Message----- > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > Sent: Friday, February 01, 2002 10:52 AM > > To: Wang, Cliff > > Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; > > kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix data; ipfix > > chairs > > Subject: Re: Agenda > > > > We should provide a way to report the NAT info if the > > device knows it. It is not a required field since not > > all devices will have it. IMHO it should be reported > > as attributes of one flow, not multiple flows. > > > > Paul > > > > "Wang, Cliff" wrote: > > > > > > The problem is that the NAT box is in the path and the probe may not > > > have any knowledge of the outside IP address it may get assigned. > > > The collector may know the mapping if it knows the inside private > > > address of the probe. > > > > > > -----Original Message----- > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > Sent: Thursday, January 31, 2002 1:46 PM > > > To: Reinaldo Penno > > > Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; > > > ipfix data; ipfix chairs > > > Subject: Re: Agenda > > > > > > Hi all > > > > > > > > > > > > > > > other comments (not necessarily to be discussed on the call) > > > > Concerning some form of capabilities negotiation I have It is also > > > > useful for the case of overlapping flows (discussed on the list) > > > > > > > > Middlebox: > > > > What about when the device is also a middlebox ? (sorry if this > > > > was already hashed out on the list) If using NAT/NAPT should the > > > > device export the flow on the private side, public side or both? > > > > Should the behavior be agreed on the capabilities negotiation? > > > > > > It's in my mind the same behaviour as for unidirectional and > > > bidirectional flows. > > > In case the exporter has got the knowledge of the bi-directional > > > flows and in case the bi-directional information make sense, the > > > exporter MAY choose to export in the same Template/Flow Record, > > > along with bidirectional accounting information. > > > So > > > In case the exporter is doing NAT, the exporter MAY choose to > > > export > > > > > > in the same Template/Flow Record, both inside and outside ip > > > addresses > > > > > > This just implies that the information model MUST have inside and > > > outside IP addresses defined. > > > > > > Regards, Benoit > > > > > > > > > > > > > > > I think the most useful behavior would be export the flows on the > > > > private and public side within the same record (or if in different > > > > records provide some key to bind them together), so you know the > > > > complete flow end-to-end. But in this case although we have two > > > > seprate flows, it is still the same packet. Same reasoning can be > > > > applied for proxy, proxy firewalls, etc. > > > > > > > > It would be impossible for a external probe to provde NAT > > > > information. All it sees is the snapshot of what is passing by. > > > > This could be worked out as a MAY. Whether it is resolved or not, > > > > we should clarify the stance on NAT in the archecture. > > > > > > > > > > > > [Penno, Reinaldo [SC9:T327:EXCH]] > > > > > > > > I wouldn't say it's impossible. It depends if the platform keeps > > > > "memory" (full stateful NATs, proxies) or not . And yes, I agree > > > > that whatever the outcome we should clarify NAT/NAPT behavior on > > > > the doc. > > > > > > > > regards, > > > > > > > > Reinaldo > > > > > > > > > > > > -- 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 Fri Feb 1 12:18:22 2002 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 MAA04562 for ; Fri, 1 Feb 2002 12:18:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16WguH-0004i6-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Feb 2002 10:51:21 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16WguF-0004hG-00 for ipfix@net.doit.wisc.edu; Fri, 01 Feb 2002 10:51:19 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g11Gok624908; Fri, 1 Feb 2002 08:50:46 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABB27309; Fri, 1 Feb 2002 08:51:07 -0800 (PST) Message-ID: <3C5AC972.E6C5CA5D@cisco.com> Date: Fri, 01 Feb 2002 08:59:31 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Norseth, KC" CC: "'Wang, Cliff'" , "Calato, Paul" , "'ipfix@net.doit.wisc.edu'" Subject: Re: [ipfix] NAT repoiting (was agenda) References: <59358A738F45D51186A30008C74CE250DA0643@slc-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit The only relevance I see here is an ability for the exporter to tell that "this is a NAT address type" (if it has the capability) and for the collector to recognize the structure of this field at the minimum and if it capable of understanding the semantics, it can do more interpretation. There are similar issues of multiple addresses with IPV6 mobility. But the general rule I think should be the collector should at the minimum be alse to understand the structure of the exported data even if does not know the semantics. Thanks Ganesh "Norseth, KC" wrote: > I am sending this to the whole list for concensus and comments.... > > Is it out of scope? It is definitly not a key component of the IPFIX data, > where it is not even possible to get in a lot of circumstances. It does > contain part of the Flow Information of a flow. If we can report it, it > would be useful for attributes. What NAT atreibutes would want to be > reported ? > > K.C. > > |-----Original Message----- > |From: Wang, Cliff [mailto:CWang@smartpipes.com] > |Sent: Friday, February 01, 2002 9:18 AM > |To: Calato, Paul > |Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; > |kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix data; > |ipfix chairs > |Subject: RE: Agenda > | > | > |Agree. But finding the NAT info should be out of the scope of this WG. > | > |On the other hand, the collector may have to deal the nasty > |NAT issue when the flow reported may contain address of a > |different address space. How to interprete that address seems > |to me something we need to look at. > | > |The other issue is whether we will allow some kind of NAT ALG, > |which translate the address in the report. Thoughts? > | > |-----Original Message----- > |From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > |Sent: Friday, February 01, 2002 10:52 AM > |To: Wang, Cliff > |Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; > |kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix data; > |ipfix chairs > |Subject: Re: Agenda > | > | > | > |We should provide a way to report the NAT info if the > |device knows it. It is not a required field since not > |all devices will have it. IMHO it should be reported > |as attributes of one flow, not multiple flows. > | > |Paul > | > |"Wang, Cliff" wrote: > |> > |> The problem is that the NAT box is in the path and the probe may not > |> have any knowledge of the outside IP address it may get > |assigned. The > |> collector may know the mapping if it knows the inside > |private address > |> of the probe. > |> > |> -----Original Message----- > |> From: Benoit Claise [mailto:bclaise@cisco.com] > |> Sent: Thursday, January 31, 2002 1:46 PM > |> To: Reinaldo Penno > |> Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; > |> ipfix data; ipfix chairs > |> Subject: Re: Agenda > |> > |> Hi all > |> > |> > > |> > > |> > other comments (not necessarily to be discussed on the call) > |> > Concerning some form of capabilities negotiation I have It is also > |> > useful for the case of overlapping flows (discussed on the list) > |> > > |> > Middlebox: > |> > What about when the device is also a middlebox ? (sorry if this was > |> > already hashed out on the list) If using NAT/NAPT should > |the device > |> > export the flow on the private side, public side or both? > |Should the > |> > behavior be agreed on the capabilities negotiation? > |> > |> It's in my mind the same behaviour as for unidirectional and > |> bidirectional flows. > |> In case the exporter has got the knowledge of the bi-directional > |> flows and in case the bi-directional information make sense, the > |> exporter MAY choose to export in the same Template/Flow Record, > |> along with bidirectional accounting information. > |> So > |> In case the exporter is doing NAT, the exporter MAY choose to > |> export > |> > |> in the same Template/Flow Record, both inside and outside ip > |> addresses > |> > |> This just implies that the information model MUST have inside and > |> outside IP addresses defined. > |> > |> Regards, Benoit > |> > |> > > |> > > |> > I think the most useful behavior would be export the flows on the > |> > private and public side within the same record (or if in different > |> > records provide some key to bind them together), so you know the > |> > complete flow end-to-end. But in this case although we have two > |> > seprate flows, it is still the same packet. Same reasoning can be > |> > applied for proxy, proxy firewalls, etc. > |> > > |> > It would be impossible for a external probe to provde NAT > |> > information. All it sees is the snapshot of what is passing by. > |> > This could be worked out as a MAY. Whether it is resolved or not, > |> > we should clarify the stance on NAT in the archecture. > |> > > |> > > |> > [Penno, Reinaldo [SC9:T327:EXCH]] > |> > > |> > I wouldn't say it's impossible. It depends if the platform keeps > |> > "memory" (full stateful NATs, proxies) or not . And yes, I agree > |> > that whatever the outcome we should clarify NAT/NAPT > |behavior on the > |> > doc. > |> > > |> > regards, > |> > > |> > Reinaldo > |> > > |> > > |> > > | > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/ms-tnef > Encoding: base64 -- 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 Fri Feb 1 13:31:43 2002 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 NAA06914 for ; Fri, 1 Feb 2002 13:31:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16WiF1-0006ei-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Feb 2002 12:16:51 -0600 Received: from d2cspimg001.smartpipes.com ([63.89.185.24]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16WiEy-0006eY-00 for ipfix@net.doit.wisc.edu; Fri, 01 Feb 2002 12:16:48 -0600 Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 18:16:18 -0000 Message-ID: <4652644B98DFF34696801F8F3070D3FE01188651@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'calato@riverstonenet.com'" , ipfixx Subject: [ipfix] RE: NAT (aka agenda) Date: Fri, 1 Feb 2002 18:16:17 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Precedence: bulk Sender: majordomo listserver Paul, I think we probably out of sync in the scenario we picture. I think we have potentially two scenarios: 1) NAT is performing on the flow being reported. Yes I am totally agree with your analysis. 2) NAT is between the probe and the collector. Actually I am talking about this case, where NAT performs on the reporting traffic. Again, I agree with your standing that if either probe or collector knows the NAT mapping, use it. Otherwise, it is out of the scope of this WG to find the NAT info. cliff -----Original Message----- From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] Sent: Friday, February 01, 2002 11:53 AM To: Wang, Cliff; ipfixx Subject: Re: NAT (aka agenda) "Wang, Cliff" wrote: > > Comments in line. > > -----Original Message----- > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: Friday, February 01, 2002 11:31 AM > To: Wang, Cliff > Subject: Re: Agenda > > "Wang, Cliff" wrote: > > > > Agree. But finding the NAT info should be out of the scope of this > > WG. > > Not sure what you mean by "finding the NAT info". How the > device retrieves any of the info is beyond the scope > of the WG. We just provide a way to report it. > > [cliff] we are saying the same thing. > > > > > On the other hand, the collector may have to deal the nasty NAT > > issue when the flow reported may contain address of a different > > address space. How to interprete that address seems to me something > > we need to look at. > > > > The other issue is whether we will allow some kind of NAT ALG, which > > translate the address in the report. Thoughts? > > Collectors may do a lot of stuff based on information > which they got from non-IPFIX sources. But we, I don't > think, are investigating that. > > [cliff] > What I am think are the following cases: > 1) NAT does the report packet header address translation. The payload > is not touched. > Then the question is the report may carry private address that > collector may or may not recognize. > > 2) NAT does the report packet header address translation. If ipfix ALG > is built, it may also translate the IP address in the report. Then > collector doesn't care the private address space at all. But doing NAT > ALG is difficult and may not be applicable all the time. Still not quite sure I follow. So let me go through step by step and then you can point out where I've gone off track. 1) If the reporting device does not know any NAT info is can only report the IP's it sees in the packet. No affect on IPFIX in this case. If the collector has no NAT knowledge, the reports only show addresses seen. No affect on IPFIX. If the collector does have NAT knowledge it MAY be able to report on public or private addresses based on info it has. What ever the collector does and how it does it in this case is outside IPFIX. 2) the reporting device does have NAT knowledge. Lets say the reporting device is the one performing the translation. In this case IPFIX should provide a way to report the private and public addresses for the flow. This does affect IPFIX. If the collector has no NAT knowledge, it can make use of the data reported by the device, but no new requirements on IPFIX. If the collector has NAT knowledge, it can either use the info provided by the reporting device or it's own info. But no new requirements on IPFIX. So as I see it, the only time the IPFIX WG takes NAT into consideration is when the reporting device wants to transport NAT related info for a particular flow. Paul > > > > > -----Original Message----- > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > Sent: Friday, February 01, 2002 10:52 AM > > To: Wang, Cliff > > Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; > > kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix data; ipfix > > chairs > > Subject: Re: Agenda > > > > We should provide a way to report the NAT info if the device knows > > it. It is not a required field since not all devices will have it. > > IMHO it should be reported as attributes of one flow, not multiple > > flows. > > > > Paul > > > > "Wang, Cliff" wrote: > > > > > > The problem is that the NAT box is in the path and the probe may > > > not have any knowledge of the outside IP address it may get > > > assigned. The collector may know the mapping if it knows the > > > inside private address of the probe. > > > > > > -----Original Message----- > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > Sent: Thursday, January 31, 2002 1:46 PM > > > To: Reinaldo Penno > > > Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; > > > ipfix data; ipfix chairs > > > Subject: Re: Agenda > > > > > > Hi all > > > > > > > > > > > > > > > other comments (not necessarily to be discussed on the call) > > > > Concerning some form of capabilities negotiation I have It is > > > > also useful for the case of overlapping flows (discussed on the > > > > list) > > > > > > > > Middlebox: > > > > What about when the device is also a middlebox ? (sorry if this > > > > was already hashed out on the list) If using NAT/NAPT should the > > > > device export the flow on the private side, public side or both? > > > > Should the behavior be agreed on the capabilities negotiation? > > > > > > It's in my mind the same behaviour as for unidirectional and > > > bidirectional flows. > > > In case the exporter has got the knowledge of the bi-directional > > > flows and in case the bi-directional information make sense, the > > > exporter MAY choose to export in the same Template/Flow Record, > > > along with bidirectional accounting information. > > > So > > > In case the exporter is doing NAT, the exporter MAY choose to > > > export > > > > > > in the same Template/Flow Record, both inside and outside ip > > > addresses > > > > > > This just implies that the information model MUST have inside and > > > outside IP addresses defined. > > > > > > Regards, Benoit > > > > > > > > > > > > > > > I think the most useful behavior would be export the flows on > > > > the private and public side within the same record (or if in > > > > different records provide some key to bind them together), so > > > > you know the complete flow end-to-end. But in this case although > > > > we have two seprate flows, it is still the same packet. Same > > > > reasoning can be applied for proxy, proxy firewalls, etc. > > > > > > > > It would be impossible for a external probe to provde NAT > > > > information. All it sees is the snapshot of what is passing by. > > > > This could be worked out as a MAY. Whether it is resolved or > > > > not, we should clarify the stance on NAT in the archecture. > > > > > > > > > > > > [Penno, Reinaldo [SC9:T327:EXCH]] > > > > > > > > I wouldn't say it's impossible. It depends if the platform keeps > > > > "memory" (full stateful NATs, proxies) or not . And yes, I agree > > > > that whatever the outcome we should clarify NAT/NAPT behavior on > > > > the doc. > > > > > > > > regards, > > > > > > > > Reinaldo > > > > > > > > > > > > -- 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 Fri Feb 1 14:14:11 2002 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 OAA08715 for ; Fri, 1 Feb 2002 14:14:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Wipy-0007Q4-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Feb 2002 12:55:02 -0600 Received: from pool-162-83-255-47.ny5030.east.verizon.net ([162.83.255.47] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Wipv-0007PU-00 for ipfix@net.doit.wisc.edu; Fri, 01 Feb 2002 12:54:59 -0600 Received: from sphynx (sphynx.newyork.qosient.com [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g11IswL28390 for ; Fri, 1 Feb 2002 13:54:59 -0500 Reply-To: From: "Carter Bullard" To: "'ipfixx'" Subject: RE: [ipfix] RE: NAT (aka agenda) Date: Fri, 1 Feb 2002 13:54:50 -0500 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6601900F@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <4652644B98DFF34696801F8F3070D3FE01188651@D2CSPEXM001.smartpipes.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Gentle people, Reporting an alias for a key element, such as an address which may be NAT'd, or the actual DNS name for a specific address in the flow key, are just a few of the additional attributes that we will want to provide in a flow report. Other examples may include the session protocol used, such as RTP, the application/ service name as an alias for the service port, or even the MAC addresses, as extended attributes of the src and dst identifiers. IPFIX should be able to handle any of these. I don't see NAT as particularly more or less complicated. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Wang, Cliff > Sent: Friday, February 01, 2002 1:16 PM > To: 'calato@riverstonenet.com'; ipfixx > Subject: [ipfix] RE: NAT (aka agenda) > > > Paul, > > I think we probably out of sync in the scenario we picture. I > think we have potentially two scenarios: > 1) NAT is performing on the flow being reported. Yes I am > totally agree with your analysis. > 2) NAT is between the probe and the collector. Actually I am > talking about this case, where NAT performs on the reporting traffic. > > Again, I agree with your standing that if either probe or > collector knows the NAT mapping, use it. Otherwise, it is out > of the scope of this WG to find the NAT info. > > cliff > > -----Original Message----- > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: Friday, February 01, 2002 11:53 AM > To: Wang, Cliff; ipfixx > Subject: Re: NAT (aka agenda) > > > "Wang, Cliff" wrote: > > > > Comments in line. > > > > -----Original Message----- > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > Sent: Friday, February 01, 2002 11:31 AM > > To: Wang, Cliff > > Subject: Re: Agenda > > > > "Wang, Cliff" wrote: > > > > > > Agree. But finding the NAT info should be out of the scope of this > > > WG. > > > > Not sure what you mean by "finding the NAT info". How the > > device retrieves any of the info is beyond the scope > > of the WG. We just provide a way to report it. > > > > [cliff] we are saying the same thing. > > > > > > > > On the other hand, the collector may have to deal the nasty NAT > > > issue when the flow reported may contain address of a different > > > address space. How to interprete that address seems to me > something > > > we need to look at. > > > > > > The other issue is whether we will allow some kind of NAT > ALG, which > > > translate the address in the report. Thoughts? > > > > Collectors may do a lot of stuff based on information > > which they got from non-IPFIX sources. But we, I don't > > think, are investigating that. > > > > [cliff] > > What I am think are the following cases: > > 1) NAT does the report packet header address translation. > The payload > > is not touched. > > Then the question is the report may carry private address that > > collector may or may not recognize. > > > > 2) NAT does the report packet header address translation. > If ipfix ALG > > is built, it may also translate the IP address in the report. Then > > collector doesn't care the private address space at all. > But doing NAT > > ALG is difficult and may not be applicable all the time. > > Still not quite sure I follow. So let me go through > step by step and then you can point out where I've > gone off track. > > 1) If the reporting device does not know any NAT info > is can only report the IP's it sees in the packet. > No affect on IPFIX in this case. > > If the collector has no NAT knowledge, the reports > only show addresses seen. No affect on IPFIX. > > If the collector does have NAT knowledge it MAY > be able to report on public or private addresses > based on info it has. What ever the collector does > and how it does it in this case is outside IPFIX. > > > 2) the reporting device does have NAT knowledge. > Lets say the reporting device is the one performing > the translation. In this case IPFIX should provide > a way to report the private and public addresses for > the flow. This does affect IPFIX. > > If the collector has no NAT knowledge, it can make > use of the data reported by the device, but no new > requirements on IPFIX. > > If the collector has NAT knowledge, it can either use > the info provided by the reporting device or it's own > info. But no new requirements on IPFIX. > > > So as I see it, the only time the IPFIX WG takes NAT > into consideration is when the reporting device wants > to transport NAT related info for a particular flow. > > Paul > > > > > > > > > > -----Original Message----- > > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > > Sent: Friday, February 01, 2002 10:52 AM > > > To: Wang, Cliff > > > Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; > > > kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix > data; ipfix > > > chairs > > > Subject: Re: Agenda > > > > > > We should provide a way to report the NAT info if the device knows > > > it. It is not a required field since not all devices will > have it. > > > IMHO it should be reported as attributes of one flow, not > multiple > > > flows. > > > > > > Paul > > > > > > "Wang, Cliff" wrote: > > > > > > > > The problem is that the NAT box is in the path and the probe may > > > > not have any knowledge of the outside IP address it may get > > > > assigned. The collector may know the mapping if it knows the > > > > inside private address of the probe. > > > > > > > > -----Original Message----- > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > > Sent: Thursday, January 31, 2002 1:46 PM > > > > To: Reinaldo Penno > > > > Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth; > ipfix arch; > > > > ipfix data; ipfix chairs > > > > Subject: Re: Agenda > > > > > > > > Hi all > > > > > > > > > > > > > > > > > > > other comments (not necessarily to be discussed on the call) > > > > > Concerning some form of capabilities negotiation I have It is > > > > > also useful for the case of overlapping flows > (discussed on the > > > > > list) > > > > > > > > > > Middlebox: > > > > > What about when the device is also a middlebox ? > (sorry if this > > > > > was already hashed out on the list) If using NAT/NAPT > should the > > > > > device export the flow on the private side, public > side or both? > > > > > Should the behavior be agreed on the capabilities negotiation? > > > > > > > > It's in my mind the same behaviour as for unidirectional and > > > > bidirectional flows. > > > > In case the exporter has got the knowledge of the > bi-directional > > > > flows and in case the bi-directional information > make sense, the > > > > exporter MAY choose to export in the same > Template/Flow Record, > > > > along with bidirectional accounting information. > > > > So > > > > In case the exporter is doing NAT, the exporter MAY > choose to > > > > export > > > > > > > > in the same Template/Flow Record, both inside and outside ip > > > > addresses > > > > > > > > This just implies that the information model MUST have > inside and > > > > outside IP addresses defined. > > > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > > > > I think the most useful behavior would be export the flows on > > > > > the private and public side within the same record (or if in > > > > > different records provide some key to bind them together), so > > > > > you know the complete flow end-to-end. But in this > case although > > > > > we have two seprate flows, it is still the same packet. Same > > > > > reasoning can be applied for proxy, proxy firewalls, etc. > > > > > > > > > > It would be impossible for a external probe to provde NAT > > > > > information. All it sees is the snapshot of what is > passing by. > > > > > This could be worked out as a MAY. Whether it is resolved or > > > > > not, we should clarify the stance on NAT in the archecture. > > > > > > > > > > > > > > > [Penno, Reinaldo [SC9:T327:EXCH]] > > > > > > > > > > I wouldn't say it's impossible. It depends if the > platform keeps > > > > > "memory" (full stateful NATs, proxies) or not . And > yes, I agree > > > > > that whatever the outcome we should clarify NAT/NAPT > behavior on > > > > > the doc. > > > > > > > > > > regards, > > > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > -- > 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/ > > -- 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 Fri Feb 1 19:02:37 2002 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 TAA14589 for ; Fri, 1 Feb 2002 19:02:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16WnLi-0001SE-00 for ipfix-list@mil.doit.wisc.edu; Fri, 01 Feb 2002 17:44:06 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16WnLe-0001Ri-00 for ipfix@net.doit.wisc.edu; Fri, 01 Feb 2002 17:44:03 -0600 Received: from cisco.com (dhcp-171-71-137-109.cisco.com [171.71.137.109]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA07674; Sat, 2 Feb 2002 00:43:26 +0100 (MET) Message-ID: <3C5B281D.8300B2FD@cisco.com> Date: Sat, 02 Feb 2002 00:43:26 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wang, Cliff" CC: "'calato@riverstonenet.com'" , ipfixx Subject: Re: [ipfix] RE: NAT (aka agenda) References: <4652644B98DFF34696801F8F3070D3FE01188651@D2CSPEXM001.smartpipes.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Cliff, "Wang, Cliff" wrote: > Paul, > > I think we probably out of sync in the scenario we picture. I think we have > potentially two scenarios: > 1) NAT is performing on the flow being reported. Yes I am totally agree with > your analysis. > 2) NAT is between the probe and the collector. Actually I am talking about > this case, where NAT performs on the reporting traffic. I think this case is out of the scope of the WG. This is actually a task for a mediation device which will analyze the data (in this case the IP addresses and ports) of the flow records received by the collector. In your case, the mediation device should contain an NAT translator. The charter doesn't speak about analyzing the flow records information. My 0.02 EURO Regards, Benoit > > > Again, I agree with your standing that if either probe or collector knows > the NAT mapping, use it. Otherwise, it is out of the scope of this WG to > find the NAT info. > > cliff > > -----Original Message----- > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: Friday, February 01, 2002 11:53 AM > To: Wang, Cliff; ipfixx > Subject: Re: NAT (aka agenda) > > "Wang, Cliff" wrote: > > > > Comments in line. > > > > -----Original Message----- > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > Sent: Friday, February 01, 2002 11:31 AM > > To: Wang, Cliff > > Subject: Re: Agenda > > > > "Wang, Cliff" wrote: > > > > > > Agree. But finding the NAT info should be out of the scope of this > > > WG. > > > > Not sure what you mean by "finding the NAT info". How the > > device retrieves any of the info is beyond the scope > > of the WG. We just provide a way to report it. > > > > [cliff] we are saying the same thing. > > > > > > > > On the other hand, the collector may have to deal the nasty NAT > > > issue when the flow reported may contain address of a different > > > address space. How to interprete that address seems to me something > > > we need to look at. > > > > > > The other issue is whether we will allow some kind of NAT ALG, which > > > translate the address in the report. Thoughts? > > > > Collectors may do a lot of stuff based on information > > which they got from non-IPFIX sources. But we, I don't > > think, are investigating that. > > > > [cliff] > > What I am think are the following cases: > > 1) NAT does the report packet header address translation. The payload > > is not touched. > > Then the question is the report may carry private address that > > collector may or may not recognize. > > > > 2) NAT does the report packet header address translation. If ipfix ALG > > is built, it may also translate the IP address in the report. Then > > collector doesn't care the private address space at all. But doing NAT > > ALG is difficult and may not be applicable all the time. > > Still not quite sure I follow. So let me go through > step by step and then you can point out where I've > gone off track. > > 1) If the reporting device does not know any NAT info > is can only report the IP's it sees in the packet. > No affect on IPFIX in this case. > > If the collector has no NAT knowledge, the reports > only show addresses seen. No affect on IPFIX. > > If the collector does have NAT knowledge it MAY > be able to report on public or private addresses > based on info it has. What ever the collector does > and how it does it in this case is outside IPFIX. > > 2) the reporting device does have NAT knowledge. > Lets say the reporting device is the one performing > the translation. In this case IPFIX should provide > a way to report the private and public addresses for > the flow. This does affect IPFIX. > > If the collector has no NAT knowledge, it can make > use of the data reported by the device, but no new > requirements on IPFIX. > > If the collector has NAT knowledge, it can either use > the info provided by the reporting device or it's own > info. But no new requirements on IPFIX. > > So as I see it, the only time the IPFIX WG takes NAT > into consideration is when the reporting device wants > to transport NAT related info for a particular flow. > > Paul > > > > > > > > > > -----Original Message----- > > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > > Sent: Friday, February 01, 2002 10:52 AM > > > To: Wang, Cliff > > > Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; > > > kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix data; ipfix > > > chairs > > > Subject: Re: Agenda > > > > > > We should provide a way to report the NAT info if the device knows > > > it. It is not a required field since not all devices will have it. > > > IMHO it should be reported as attributes of one flow, not multiple > > > flows. > > > > > > Paul > > > > > > "Wang, Cliff" wrote: > > > > > > > > The problem is that the NAT box is in the path and the probe may > > > > not have any knowledge of the outside IP address it may get > > > > assigned. The collector may know the mapping if it knows the > > > > inside private address of the probe. > > > > > > > > -----Original Message----- > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > > Sent: Thursday, January 31, 2002 1:46 PM > > > > To: Reinaldo Penno > > > > Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; > > > > ipfix data; ipfix chairs > > > > Subject: Re: Agenda > > > > > > > > Hi all > > > > > > > > > > > > > > > > > > > other comments (not necessarily to be discussed on the call) > > > > > Concerning some form of capabilities negotiation I have It is > > > > > also useful for the case of overlapping flows (discussed on the > > > > > list) > > > > > > > > > > Middlebox: > > > > > What about when the device is also a middlebox ? (sorry if this > > > > > was already hashed out on the list) If using NAT/NAPT should the > > > > > device export the flow on the private side, public side or both? > > > > > Should the behavior be agreed on the capabilities negotiation? > > > > > > > > It's in my mind the same behaviour as for unidirectional and > > > > bidirectional flows. > > > > In case the exporter has got the knowledge of the bi-directional > > > > flows and in case the bi-directional information make sense, the > > > > exporter MAY choose to export in the same Template/Flow Record, > > > > along with bidirectional accounting information. > > > > So > > > > In case the exporter is doing NAT, the exporter MAY choose to > > > > export > > > > > > > > in the same Template/Flow Record, both inside and outside ip > > > > addresses > > > > > > > > This just implies that the information model MUST have inside and > > > > outside IP addresses defined. > > > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > > > > I think the most useful behavior would be export the flows on > > > > > the private and public side within the same record (or if in > > > > > different records provide some key to bind them together), so > > > > > you know the complete flow end-to-end. But in this case although > > > > > we have two seprate flows, it is still the same packet. Same > > > > > reasoning can be applied for proxy, proxy firewalls, etc. > > > > > > > > > > It would be impossible for a external probe to provde NAT > > > > > information. All it sees is the snapshot of what is passing by. > > > > > This could be worked out as a MAY. Whether it is resolved or > > > > > not, we should clarify the stance on NAT in the archecture. > > > > > > > > > > > > > > > [Penno, Reinaldo [SC9:T327:EXCH]] > > > > > > > > > > I wouldn't say it's impossible. It depends if the platform keeps > > > > > "memory" (full stateful NATs, proxies) or not . And yes, I agree > > > > > that whatever the outcome we should clarify NAT/NAPT behavior on > > > > > the doc. > > > > > > > > > > regards, > > > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > -- > 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/ -- 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 Sat Feb 2 16:26:23 2002 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 QAA07793 for ; Sat, 2 Feb 2002 16:26:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16X7IQ-0006Lg-00 for ipfix-list@mil.doit.wisc.edu; Sat, 02 Feb 2002 15:02:02 -0600 Received: from d2cspimg001.smartpipes.com ([63.89.185.24]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16X7IO-0006Kf-00 for ipfix@net.doit.wisc.edu; Sat, 02 Feb 2002 15:02:00 -0600 Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Feb 2002 21:01:29 -0000 Message-ID: <4652644B98DFF34696801F8F3070D3FE01188659@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Benoit Claise'" Cc: "'calato@riverstonenet.com'" , ipfixx Subject: RE: [ipfix] RE: NAT (aka agenda) Date: Sat, 2 Feb 2002 21:01:22 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Precedence: bulk Sender: majordomo listserver I agree the crux of the issue is the interpretation of the reported data by the collector. But on the hand, if this is a valid scenario, IPFIX needs to either specify this is out of scope or try to find possible solutions. Otherwise the data reported may be useless. Let's listen to the outcome of the MIDBOX architecture team. -----Original Message----- From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Friday, February 01, 2002 6:43 PM To: Wang, Cliff Cc: 'calato@riverstonenet.com'; ipfixx Subject: Re: [ipfix] RE: NAT (aka agenda) Hi Cliff, "Wang, Cliff" wrote: > Paul, > > I think we probably out of sync in the scenario we picture. I think we > have potentially two scenarios: > 1) NAT is performing on the flow being reported. Yes I am totally > agree with your analysis. > 2) NAT is between the probe and the collector. Actually I am talking > about this case, where NAT performs on the reporting traffic. I think this case is out of the scope of the WG. This is actually a task for a mediation device which will analyze the data (in this case the IP addresses and ports) of the flow records received by the collector. In your case, the mediation device should contain an NAT translator. The charter doesn't speak about analyzing the flow records information. My 0.02 EURO Regards, Benoit > > > Again, I agree with your standing that if either probe or collector > knows the NAT mapping, use it. Otherwise, it is out of the scope of > this WG to find the NAT info. > > cliff > > -----Original Message----- > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: Friday, February 01, 2002 11:53 AM > To: Wang, Cliff; ipfixx > Subject: Re: NAT (aka agenda) > > "Wang, Cliff" wrote: > > > > Comments in line. > > > > -----Original Message----- > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > Sent: Friday, February 01, 2002 11:31 AM > > To: Wang, Cliff > > Subject: Re: Agenda > > > > "Wang, Cliff" wrote: > > > > > > Agree. But finding the NAT info should be out of the scope of this > > > WG. > > > > Not sure what you mean by "finding the NAT info". How the > > device retrieves any of the info is beyond the scope > > of the WG. We just provide a way to report it. > > > > [cliff] we are saying the same thing. > > > > > > > > On the other hand, the collector may have to deal the nasty NAT > > > issue when the flow reported may contain address of a different > > > address space. How to interprete that address seems to me > > > something we need to look at. > > > > > > The other issue is whether we will allow some kind of NAT ALG, > > > which translate the address in the report. Thoughts? > > > > Collectors may do a lot of stuff based on information > > which they got from non-IPFIX sources. But we, I don't > > think, are investigating that. > > > > [cliff] > > What I am think are the following cases: > > 1) NAT does the report packet header address translation. The > > payload is not touched. > > Then the question is the report may carry private address that > > collector may or may not recognize. > > > > 2) NAT does the report packet header address translation. If ipfix > > ALG is built, it may also translate the IP address in the report. > > Then collector doesn't care the private address space at all. But > > doing NAT ALG is difficult and may not be applicable all the time. > > Still not quite sure I follow. So let me go through > step by step and then you can point out where I've > gone off track. > > 1) If the reporting device does not know any NAT info > is can only report the IP's it sees in the packet. > No affect on IPFIX in this case. > > If the collector has no NAT knowledge, the reports > only show addresses seen. No affect on IPFIX. > > If the collector does have NAT knowledge it MAY > be able to report on public or private addresses > based on info it has. What ever the collector does > and how it does it in this case is outside IPFIX. > > 2) the reporting device does have NAT knowledge. > Lets say the reporting device is the one performing > the translation. In this case IPFIX should provide > a way to report the private and public addresses for > the flow. This does affect IPFIX. > > If the collector has no NAT knowledge, it can make > use of the data reported by the device, but no new > requirements on IPFIX. > > If the collector has NAT knowledge, it can either use > the info provided by the reporting device or it's own > info. But no new requirements on IPFIX. > > So as I see it, the only time the IPFIX WG takes NAT > into consideration is when the reporting device wants > to transport NAT related info for a particular flow. > > Paul > > > > > > > > > > -----Original Message----- > > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > > Sent: Friday, February 01, 2002 10:52 AM > > > To: Wang, Cliff > > > Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; > > > kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix data; ipfix > > > chairs > > > Subject: Re: Agenda > > > > > > We should provide a way to report the NAT info if the device knows > > > it. It is not a required field since not all devices will have it. > > > IMHO it should be reported as attributes of one flow, not multiple > > > flows. > > > > > > Paul > > > > > > "Wang, Cliff" wrote: > > > > > > > > The problem is that the NAT box is in the path and the probe may > > > > not have any knowledge of the outside IP address it may get > > > > assigned. The collector may know the mapping if it knows the > > > > inside private address of the probe. > > > > > > > > -----Original Message----- > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > > Sent: Thursday, January 31, 2002 1:46 PM > > > > To: Reinaldo Penno > > > > Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth; ipfix > > > > arch; ipfix data; ipfix chairs > > > > Subject: Re: Agenda > > > > > > > > Hi all > > > > > > > > > > > > > > > > > > > other comments (not necessarily to be discussed on the call) > > > > > Concerning some form of capabilities negotiation I have It is > > > > > also useful for the case of overlapping flows (discussed on > > > > > the > > > > > list) > > > > > > > > > > Middlebox: > > > > > What about when the device is also a middlebox ? (sorry if > > > > > this was already hashed out on the list) If using NAT/NAPT > > > > > should the device export the flow on the private side, public > > > > > side or both? Should the behavior be agreed on the > > > > > capabilities negotiation? > > > > > > > > It's in my mind the same behaviour as for unidirectional and > > > > bidirectional flows. > > > > In case the exporter has got the knowledge of the bi-directional > > > > flows and in case the bi-directional information make sense, the > > > > exporter MAY choose to export in the same Template/Flow Record, > > > > along with bidirectional accounting information. > > > > So > > > > In case the exporter is doing NAT, the exporter MAY choose > > > > to export > > > > > > > > in the same Template/Flow Record, both inside and outside ip > > > > addresses > > > > > > > > This just implies that the information model MUST have inside > > > > and outside IP addresses defined. > > > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > > > > I think the most useful behavior would be export the flows on > > > > > the private and public side within the same record (or if in > > > > > different records provide some key to bind them together), so > > > > > you know the complete flow end-to-end. But in this case > > > > > although we have two seprate flows, it is still the same > > > > > packet. Same reasoning can be applied for proxy, proxy > > > > > firewalls, etc. > > > > > > > > > > It would be impossible for a external probe to provde NAT > > > > > information. All it sees is the snapshot of what is passing > > > > > by. This could be worked out as a MAY. Whether it is resolved > > > > > or not, we should clarify the stance on NAT in the archecture. > > > > > > > > > > > > > > > [Penno, Reinaldo [SC9:T327:EXCH]] > > > > > > > > > > I wouldn't say it's impossible. It depends if the platform > > > > > keeps "memory" (full stateful NATs, proxies) or not . And yes, > > > > > I agree that whatever the outcome we should clarify NAT/NAPT > > > > > behavior on the doc. > > > > > > > > > > regards, > > > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > -- > 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/ -- 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 Feb 6 05:59:26 2002 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 FAA16504 for ; Wed, 6 Feb 2002 05:59:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YPMo-0005bU-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 04:31:54 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YPMm-0005au-00 for ipfix@net.doit.wisc.edu; Wed, 06 Feb 2002 04:31:52 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g16AVCg21451; Wed, 6 Feb 2002 11:31:12 +0100 (CET) Date: Wed, 6 Feb 2002 11:31:12 +0100 (CET) From: Benoit Claise Message-Id: <200202061031.g16AVCg21451@bru-cse-222.cisco.com> To: kcn@norseth.com, simon@limmat.switch.ch, ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Information Model X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver Hi, These are the information fields that Ganesh and I were thinking of in our document, which BTW has been sent to the editor (we're still waiting for an answer). Note: as I understood from Dave Plonka, all discussions must be moved to the generic ipfix mailing list. Regards, Benoit. Field Type Value Length Description IN_BYTES_32 1 4 32-bit counter for bytes associated with an IP Flow IN_PKTS_32 2 4 32-bit counter for packets associated with an IP Flow FLOWS 3 4 Number of main cache flows that were aggregated PROT 4 1 IP protocol byte. TOS 5 1 Type of service byte TCP_FLAGS 6 1 TCP Flags (cumulative OR of TCP flags) TCP/UDP source port L4_SRC_PORT 7 2 number (.e.g, FTP, Telnet, etc...) IPV4_SRC_ADDR 8 4 Source IPv4 Address SRC_MASK 9 1 source route's mask bits INPUT_SNMP 10 2 Input interface index TCP/UDP destination port L4_DST_PORT 11 2 number (.e.g, FTP, Telnet, etc...) IPV4_DST_ADDR 12 4 Destination IPv4 Address DST_MASK 13 1 destination route's mask Bits OUTPUT_SNMP 14 2 Output interface index IPV4_NEXT_HOP 15 4 Next hop router's IPv4 Address SRC_AS 16 4 Source BGP Autonomous System Number DST_AS 17 4 Destination BGP Autonomous System Number BGP_NEXT_HOP 18 4 Next-hop router in the BGP domain IPM_DPKTS 19 4 Packet count for IP Multicast IPM_DOCTETS 20 4 Octet (byte) count for IP Multicast SysUptime at which the LAST_SWITCHED 21 4 last packet of this flow was switched SysUptime at which the FIRST_SWITCHED 22 4 first packet of this flow was switched IN_BYTES_64 23 8 64-bit counter for bytes associated with an IP Flow IN_PKTS_64 24 8 64-bit counter for packets associated with an IP Flow MAC_ADDR 25 6 Layer 2 Media Access Control address associated with a flow VLAN_ID 26 2 Virtual LAN identifier associated with a flow IPV6_SRC_ADDR 27 16 IPv6 Source Address IPV6_DST_ADDR 28 16 IPv6 Destination Address IPV6_SRC_MASK 29 1 IPv6 Source Mask IPV6_DST_MASK 30 1 IPv6 Destination Mask FLOW_LABEL 31 2 IPV6 Flow Label ICMP Packet Type. This is ICMP_TYPE 32 1 reported as (ICMP Type * 256) + ICMP code IGMP_TYPE 33 1 IGMP Packet Type When using Sampling, the rate at which packets are sampled. For SAMPLING_INTERVAL 34 1 example, a value of 100 indicates that one of every hundred packets is sampled. The type of algorithm used for sampling data. Currently, the only sampling algorithm defined SAMPLING_ALGO 35 1 is: 0x02 packet-sampling Timeout value for active FLOW_ACTIVE_TIMEOUT 36 2 flow entries in the cache. Timeout value for inactive FLOW_INACTIVE_TIMEOUT 37 2 flow entries in the cache. OUT_BYTES_32 38 4 32-bit counter for bytes associated with an IP Flow OUT_PKTS_32 39 4 32-bit counter for packets associated with an IP Flow OUT_BYTES_64 40 8 64-bit counter for bytes associated with an IP Flow OUT_PKTS_64 41 8 64-bit counter for packets associated with an IP Flow inside TCP/UDP destination INSIDE_L4_SRC 42 2 port number (.e.g, FTP, Telnet, etc...) only applicable with NAT INSIDE_IPV4_SRC_ADDR 43 4 Source IPv4 Address only applicable with NAT TCP/UDP destination port INSIDE_L4_DST_PORT 44 2 number (.e.g, FTP, telnet etc...) only applicable with NAT INSIDE_IPV4_DST_ADDR 45 4 Destination IPv4 Address only applicable with NAT INSIDE_IPV6_SRC_ADDR 46 16 IPv6 Source Address only applicable with NAT INSIDE_IPV6_DST_ADDR 47 16 IPv6 Destination Address only applicable with NAT TCP/UDP destination port OUTSIDE_L4_SRC_PORT 48 2 number (.e.g, FTP, Telnet, etc...) only applicable with NAT OUTSIDE_IPV4_SRC_ADDR 49 4 Source IPv4 Address only applicable with NAT TCP/UDP destination port OUTSIDE_L4_DST_PORT 50 2 number (.e.g, FTP, Telnet, etc...) only applicable with NAT OUTSIDE_IPV4_DST_ADDR 51 4 Destination IPv4 Address only applicable with NAT OUTSIDE_IPV6_SRC_ADDR 52 16 IPv6 Source Address only applicable with NAT OUTSIDE_IPV6_DST_ADDR 53 16 IPv6 Destination Address only applicable with NAT Flow Direction 54 1 The direction of the flow observed at the observation point. If the observation point is a set of interface(s) the direction is w.r.t the wire. The "Value" column in the above table is a numeric identifier for the field type. When extensibility is needed (when new technologies are defined or when some new field types are needed), the newly added field types MUST be added to the list. They MUST be defined by the exporter and understood by the collector. Regards, Benoit. > > >>>>> "k" == kcn writes: > > That is the document. As I clarified myself earlier, I think this > > document is overkill for what we need but it has great information > > we can work from and extract. > > Agree - it's a good document to start from. > > I'd suggest sticking to the flow attributes/IEs that are mentioned in > the requirements draft (draft-ietf-ipfix-reqs-00.txt) for now, and try > to define as clearly as possible what each attribute's value should > represent. > > I expect that as we do this, we will understand some fundamental > categorizations of flow attributes, for example > > * attributes that can be derived directly from packet fields > * attributes that can be derived from other observables, such as the > time of observation, or the input interface ("observation point") > * attributes that can be derived from other state (e.g. routing > tables), such as the output interface or "AS" information. > > or > > * attributes that form a part of the flow "key" > * attributes that are combined from multiple packets (e.g. "bitwise > inclusive OR of the TCP flags of all TCP segments in a flow") > * attributes that are only computed when the flow is created, or when > the flow is exported > > Hopefully we can turn such categorizations (where deemed useful) into > re-usable terminology that could go into an introductory section of > this document, or into an architecture/terminology document. > > In the description of the specific flow aggregates, we should try to > talk in terms of data types such as "an unsigned integer between 0 and > 255" (e.g. for an "IP protocol" attribute), but avoid anything that is > related to a specific encoding. > -- > Simon Leinen simon@babar.switch.ch > SWITCH http://www.switch.ch/misc/leinen/ > > Computers hate being anthropomorphized. > -- 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 Feb 6 06:52:48 2002 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 GAA17707 for ; Wed, 6 Feb 2002 06:52:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YQJq-0000Mc-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 05:32:54 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YQJn-0000MT-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 05:32:51 -0600 Received: from fokus.fhg.de (dhcp206 [195.37.78.206]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g16BWlY12010; Wed, 6 Feb 2002 12:32:47 +0100 (MET) Message-ID: <3C6113C9.2080604@fokus.fhg.de> Date: Wed, 06 Feb 2002 12:30:17 +0100 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "K.C. Norseth" CC: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Content-Type: multipart/mixed; boundary="------------090600000705000405080007" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------090600000705000405080007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi K.C., attached you can find my contributions to the architecture document. - The first text contains some first thoughts on how IPFIX and AAA could communicate. - The second text contains considerations on how IPFIX can be used for QoS monitoring. Maybe this can also go into the architecture document (Ram Gopal for instance had a section on "some applications for IPFIX" in his text). Or do you think this should be put into a separate document ? Regards Tanja -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- --------------090600000705000405080007 Content-Type: text/plain; name="IPFIX-and-AAA.txt" Content-Disposition: inline; filename="IPFIX-and-AAA.txt" Content-Transfer-Encoding: 7bit Contribution to IPFIX WG Tanja Zseby FhI FOKUS February 2002 IPFIX and AAA AAA defines a protocol and an architecture for authentication, authorization and accounting for service usage. The DIAMETER protocol is used for AAA communication for network access services (Mobile IP, NASREQ, ROAMOPS). The AAA architecture [RFC2903] provides a framework for extending the AAA support also for other services. DIAMETER defines the exchange of messages between AAA entities, e.g. between AAA clients at access devices and AAA servers and among AAA servers. It is used also for the transfers of accounting records. For usage-based accounting measurement data from the network is needed to generate an accounting record. IPFIX provides a protocol to export measurement data from the measurement point to the consumer of this data (like network management and accounting systems). The provisioning of accounting with IPFIX can be realized without a AAA infrastructure. The collector can directly forward the measurement information to an accounting application. Nevertheless, if a AAA infrastructure is in place, IPFIX can provide the input for the generation of accounting records and several features of the AAA architecture can be used. Features include the mapping of a user ID to the flow information (by using authentication information), the generation of DIAMETER accounting records and the secure exchange of accounting records between domains with DIAMETER. Three possibilities to connect IPFIX and AAA can be distinguished: 1. Connecting via an AAA client One possibility to connect IPFIX and AAA is to run a AAA client on the IPFIX collector. This client can generate DIAMETER accounting messages and send them to a AAA server. The mapping of the flow information to a user ID can be done in the AAA server by using data from the authentication process. DIAMETER accounting messages can be sent to the accounting application or to other AAA servers (e.g. in roaming scenarios). +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | DIAMETER | | +--+--------+--+ | | AAA-C | | + +--------+ | | | | Collector | +--------------+ ^ | IPFIX | +------------+ | Exporter | +------------+ Figure 1: IPFIX collector connects to AAA server via AAA client 2. Connecting via an Application Specific Module (ASM) Another possibility is to directly connect the IPFIX collector with the AAA server via an application specific module (ASM). Application specific modules have been proposed by the IRTF AAA architecture research group (AAARCH) in [RFC2903]. They act as an interface between AAA server and service equipment. In this case the IPFIX collector is part of the ASM. The ASM acts as an interface between the IPFIX protocol and the input interface of the AAA server. The ASM translates the received IPFIX data into an appropriate format for the AAA server. The AAA server then can add information about the user ID and generate a DIAMETER accounting record. This accounting record can be sent to an accounting application or to other AAA serves. +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | +------------------+ | ASM | | +------------+ | | | Collector | | +------------------+ ^ | IPFIX | +------------+ | Exporter | +------------+ Figure 2: IPFIX connects to AAA server via ASM 3. Using DIAMETER as IPFIX protocol The third possibility is that the IPFIX exporter itself already uses the DIAMETER protocol, generates DIAMETER accounting records (or a simplified version) and directly can communicate with a AAA server. Nevertheless, DIAMETER and IPFIX address quite different problems. An IPFIX exporting device can be a router or another device with scarce resources. A simpler protocol than DIAMETER might be sufficient and much better suited for IPFIX. Furthermore, IPFIX also needs to support other applications than accounting. All this might require simplifications and extensions to the DIAMETER protocol that reduce the compatibility with the AAA server or increase the complexity of the server and with this also decreases the benefit of using DIAMETER in this context. --------------090600000705000405080007 Content-Type: text/plain; name="QoS-Monitoring-with-IPFIX.txt" Content-Disposition: inline; filename="QoS-Monitoring-with-IPFIX.txt" Content-Transfer-Encoding: 7bit Contribution to IPFIX WG Tanja Zseby FhI FOKUS February 2002 QoS Monitoring with IPFIX The performance QoS monitoring is one target application for using the IPFIX protocol. QoS monitoring is the passive observation of the transmission quality for single flows or traffic aggregates in the network. It is needed for instance for the validation of QoS guarantees in service level agreements. Some QoS metrics require the correlation of data from multiple measurement points. For this the clock of the involved exporting devices need to be synchronized. Furthermore such measurements would benefit from post-processing functions (e.g. packet ID generation) at the exporter and/or collector. This section describes how the monitoring of different metrics can be performed with IPFIX. The following metrics are considered: round trip time, one-way-delay, loss and delay variation. Measurement of Round-trip-time (RTT) with IPFIX The passive measurement of round-trip-times (RTT) can be performed by using packet pair matching techniques as described in [Brow00]. For the measurements, request/response packet pairs from protocols like DNS, ICMP, SNMP or TCP (syn/syn-ack, data/ack) are utilized to passively observe the RTT. As always for passive measurements this only works if the required traffic of interest is actually present in the network. In order to use this measurement technique, the IPFIX meter needs to measure both directions. A classification of the protocols mentioned above has to be done. That means parts of the transport header are used for the classification. Since a differentiation of flows in accordance to the transport header is one of the requirements for IPFIX, such classification can be performed without extensions. Nevertheless, the meter needs to recognize request and response packets for the given protocols and therefore needs to look further into the packet. This is not required for IPFIX but can be achieved by optional extensions to the classification process. The exporting device needs to assign a timestamp for the arrival of the packets. The calculation of the RTT can be done directly at the exporter or at the collector. In the first case IPFIX would transfer the calculated RTT to the collector. In the second case IPFIX needs to send the observed packet types and the timestamps to the collector. Measurement of One-way-delay (OWD) with IPFIX Passive one-way-delay measurements require the collection of data at two measurement points. It is required to recognize packets at the second measurement point in order to correlate packet arrival events from both points. This can be done for instance by capturing packet headers and parts of the packet and recognize packets based on this. In order to reduce the amount of measurement data a unique packet ID can be calculated from the header and part of the content e.g. by using a CRC or hash function [GrDM98, DuGr00, ZsZC01].Since IPFIX is not targeted at packet capturing these functionalities do not need to be supported by a standard IPFIX meter. Nevertheless, in some scenarios it might be sufficient to calculate a packet ID under consideration of header fields including datagramm ID and maybe sequence numbers (from transport protocols) without looking at parts of the packet content. Especially if packet IDs need to be unique only for a certain time interval or a certain amount of packet ID collisions is tolerable this can be a solution. Measurement of Loss with IPFIX Passive loss measurements for single flows can be performed at one measurement point for instance by using sequence numbers that are present in higher layer protocols. This requires the capturing of the sequence numbers of subsequent packets of the observed flow at the IPFIX meter. An alternative to this is to perform a two-point measurement as described above and just consider packets as lost, that do not arrive at the second measurement point in a given maximum time frame. Measurement of delay variation with IPFIX Delay variation is defined as the difference of one-way-delay values for selected packets.[DeCi01]. Therefore this metric can be calculated by performing passive measurement of one-way-delay for subsequent packets (e.g. of a flow) and then calculate the differences. Sampling for QoS Monitoring Since QoS monitoring can lead to an overwhelming amount of measurement result data, it would highly benefit from the deployment of mechanisms to reduce the measurement data, like aggregation of results and sampling. Sampling methods can be grouped according to the sampling strategy (systematic, random or stratified) and the trigger that starts a sampling interval (count-based, time-based or packet-content-based) [ClPB93]. Sampling can also be used as a method to dynamically reduce resource consumption if the meter is overloaded. Then the IPFIX meter can switch to a sampling method if too many packets have to be observed. Since the expected estimation error depends heavily on the used sampling strategy, the application that receives the data needs to be aware of the sampling scheme and the used parameters. Therefore it is important that the IPFIX exporter informs the collector precisely about the used sampling strategy. This is even more required if the IPFIX meter dynamically invokes sampling. [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions, http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-adelaide/pp-dist/ [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric for IPPM, , November 2001 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss Metric for IPPM, September 1999 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application of Sampling Methodologies to Network Traffic Characterization, Proceedings of ACM SIGCOMM'93, San Francisco, CA, USA, September 13 - 17, 1993 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, John G. CLEARY: Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000. [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric for IPPM, Request for Comments: 2679, September 1999 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation of Building Blocks for Passive One-way-delay Measurements, Proceedings of Passive and Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 (PAM 2001) --------------090600000705000405080007-- -- 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 Feb 6 11:34:33 2002 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 LAA25229 for ; Wed, 6 Feb 2002 11:34:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YUfn-00077f-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 10:11:51 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YUfl-00076u-00 for ipfix-data@net.doit.wisc.edu; Wed, 06 Feb 2002 10:11:49 -0600 Received: from riverstonenet.com (134.141.180.92 [134.141.180.92]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X7WWF0PR; Wed, 6 Feb 2002 08:10:37 -0800 Message-ID: <3C61557E.2F3B2D05@riverstonenet.com> Date: Wed, 06 Feb 2002 11:10:38 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Simon Leinen CC: kcn@norseth.com, data Subject: [ipfix-data] Re: Information Model References: <20020205204955.5721.cpmta@c001.snv.cp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Here is a first cut at the list of data elements to be reported. I of course hacked it out of the LFAP spec. I think we need to begin with a couple of guidlines (which we should augment as we go). They are just guidelines. 1. Data element values should be defined in terms of other specifications. Since we are only reporting things in other protocols, there should be little reason for us to define anything from scatch. 2. Each element should be able to be interpreted on it own. In other words, don't make me look though the rest of the message to figure out what this value means. The drawback is this can lead to data element explosion. We'll have to balance the tradeoffs. 3. Others?.... 1.1 Source Address IE Source address associated with a flow. Addresses can be of any type as described in RFC 1700 [note - we need a new reference here, 1700 has been obsoleted] 1.2 Destination Address IE Destination address associated with a flow. same as above. 1.3 Internal queue priority A switch may map several of its internal priority queues into a Premium, High, Medium or Low category. [ this sections needs more work] 1.4 Time IE The time (as a SNMPv2 TimeStamp [1443]) associated with the status/statistics observed or other events. 1.5 UTC Time IE The time in seconds since 00:00:00 UTC, January 1, 1970 associated with the status/statistics observed or other events. If both Time and UTC_TIME are present, UTC Time takes precedence. 1.6 Delta Time IE The number in 100ths of seconds over which the statistics were observed. TYPE is 71 and format is: 1.7 Class of Service IE The class of service associated with a flow. Class of Service Received Class of Service Transmitted 1 - IPv4, CoS value is defined by ToS in RFC 791 2 - IPv6, CoS value is defined by Traffic Class in RFC 2460 3 - MPLS, CoS value is defined by Exp in RFC 3032 4 - VLAN, CoS value is defined by user_priority in IEEE 802.1q[802.1q] and IEEE 802.1p[802.1p] [Can more than one Class of Service can be present??? PAC] 1.8 Source Exporter [ is that the right term?? PAC] Address IE Source Exporter address is the address of the Exporter reporting the flow, Address is same as is as shown for Source Address. This information is used by applications to later correlate the ingress/egress port with a specific Exporter. It is also used to maintain the source Exporter information when there is an intermediate proxy. For example, given the picture below: SW1 -------- P1 ------ FAS1 ^ | SW2---------- | Flows coming from SW1 and SW2 through proxy P1 would look to the Collector [ is this the rigth term??? PAC] like the same Exporter connection. With the Source Exporter in the message the original Exporter address is maintained. 1.9 Flow State IE Flow State is the intended End State for the Flow. Flow state has one of the following meanings: Flow is inactive Flow is active 1.10 Byte Count IE Contains the count of octets sent and received associated with the identified flow. The byte count can be for bytes received (towards source) or bytes sent (towards destination) or both (bi-directional flow). The byte count can be a running counter and is the count from the beginning of the flow establishment. The byte count can be a delta counter and is the count since the last report for this flow. 1.11 Packet Count IE Contains the count of packets sent and received associated with the identified flow. The packet count can be for packets received (towards source) or packets sent (towards destination) or both (bi-directional flow). The packet count can be a running counter and is the count from the beginning of the flow establishment. The packet count can be a delta counter and is the count since the last report for this flow. 1.12 Protocol Identifier IE e.g. TCP/UDP [ need an RFC reference here. PAC] 1.13 Source Port IE This IE is used to report UDP source port [see RFC 768] or TCP source port [see RFC 793]. 1.14 Destination Port IE This IE is used to report UDP destination port [see RFC 768] or TCP destination port [see RFC 793]. 1.15 Source AS IE The Autonomous System (AS) numbers for the source address associated with a flow. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4): 1.16 Destination AS IE The Autonomous System (AS) numbers for the destination address associated wit a flow. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). 1.17 Ingress Port IE The ingress ifIndex for the flow is provided in this IE. ifIndex is defined by RFC 2233. 1.18 Egress Port IE The egress ifIndex for the flow is provided in this IE. ifIndex is defined by RFC 2233. 1.19 Egress ATM Subinterface The egress vpi/vci for the flow is provided in this IE. vpi/vci id defined by the ATM Forum UNI 3.1 specification: 1.20 EGRESS_FRAME_RELAY_SUBINTERFACE IE The egress DLCI for the flow is provided in this IE. ITU Q.922 defines the DLCI range. The frDlcmiState is defined in RFC 2115 and defines the specific values of the DLCI. 1.21 NEXT_HOP_IP IE Address of the next hop. address is defined the same as for Source Address IE. 1.22 TCP Control Bits IE The TCP control bits seen for this flow. Note a 0 value for each bit only indicates that the flag was not detected (i.e. it may have occurred but was not detected by the reporting CCE). TCP Control Bits are defined by RFC 793. 1.23 Next Hop AS IE The Autonomous System (AS) numbers for the next hop IP. Autonomous System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). 1.24 Source Address Netmask IE The number of bits in the CIDR netmask, as defined in RFC 1519, for the source address. 1.25 Destination Address Netmask IE The CIDR netmask, as defined in RFC 1519, for the destination address. 1.26 Destination BGP Community IE The BGP community number for the destination address. BGP community number is defined by RFC 1997: 1.27 Source BGP Community IE The BGP community number for the source address. 1.28 Source VLAN ID IE The Source VLAN ID associated with the flow. VLAN ID is defined by IEEE standard 802.1q - 1998[802.1q]. [ Is this ultimate source VLAN or the source vlan of the port where the packet came in? Or do we need a way to represent both? PAC] 1.29 Destination VLAN ID IE The destination VLAN ID associated with the flow. VLAN ID is defined by IEEE standard 802.1q - 1998[802.1q]. [ Is this ultimate destination VLAN or the destination vlan of the port where the packet went out? Or do we need a way to represent both? PAC] 1.30 Source Virtual Address IE An Exporter may be involved in redirecting flows. This IE captures information needed for proper accounting of redirected flows. The Source Virtual IE contains the source address of the flow as transmitted by the Exporter. It is generally different than the source address IE, which contains the address of the actual source of the message. A type field would contain the type of translation performed on the source address. The following types are currently available: 1 - NAT 2 - LSNAT 3 - Web Cache The address is defined the same as for Source Address. 1.31 Source Virtual Port IE A CCE may be involved in redirecting flows. This IE captures information needed for proper accounting of redirected flows. The Source Virtual port IE contains the source port of the flow as transmitted by the CCE. It may be different than the source port IE, which contains the port of the actual source of the flow. An IP Protocol field is present and is defined by the IP protocol spec [RFC 791] (e.g. TCP/UDP). The fields indicates how to interpret the port value field. A type field contains the type of translation performed on the source port. The following types are currently available: 1 - NAT 2 - LSNAT 3 - Web Cache 1.32 Destination Virtual Address IE The Destination Virtual IE contains the destination address of the flow as received by the Exporter. It is generally different than the destination port number, which contains the actual destination address of the flow. 1.33 Destination Virtual Port IE The Destination Virtual port IE contains the destination port of the flow as received by the Exporter. It may be different than the destination port recorded in the destination port, which contains the actual destination port of the flow. 1.34 Vendor Specific IE Vendors may add their own information to the protocol. Information contained in this IE is vendor specific. OID and OID Value is defined by ITU X.680.X683 (1997) and is encoded as defined by ITU X.690.691(1997). This IE MUST not contain any information which cannot be safely ignored by the Exporter or Collector. If multiple Vendor Specific IE's with the same OID occur, then the vendor defines semantics of ordering. 1.35 Flow Label IE The Flow Label IE contains the IPV6 Flow Label information as defined by RFC 2460. 1.36 Fragment ID IE The fragment ID associated with the flow. RFC 791 and RFC 2460 define fragment ID. -- 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 Feb 6 11:35:07 2002 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 LAA25260 for ; Wed, 6 Feb 2002 11:35:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YUSh-0006ks-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 09:58:20 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YUSf-0006kB-00 for ipfix@net.doit.wisc.edu; Wed, 06 Feb 2002 09:58:17 -0600 Received: from cisco.com (bclaise-isdn-home5.cisco.com [10.49.4.222]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA20505 for ; Wed, 6 Feb 2002 16:57:45 +0100 (MET) Message-ID: <3C615278.BF79195B@cisco.com> Date: Wed, 06 Feb 2002 16:57:45 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: [ipfix] draft-gsadasiv-ipfix-proposal-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, Below is the URL for the Individual Draft that Ganesh and I sent last week to the invididuals who volunteers for the architecture and data model documents. This document has been reviewed and improved to insert some of the concerns discussed during our conference call. We advice you all to review it. We welcome any feedback. Again we would like to stress that, even if the document has been initially based on version 9, it goes far beyond. Our goal is that it should be used as a starting point for discussion amongst the IPFIX community. http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt As discussed during the conference call, if the feedback is positive after you review, we would like you to consider having this document as a working group document. Feedback? Regards, Ganesh and Benoit -- 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 Feb 6 13:18:14 2002 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 NAA27462 for ; Wed, 6 Feb 2002 13:18:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YWJk-0001U1-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 11:57:12 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YWJi-0001T7-00 for ipfix-data@net.doit.wisc.edu; Wed, 06 Feb 2002 11:57:10 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g16HqjU14677; Wed, 6 Feb 2002 11:52:45 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF47YX>; Wed, 6 Feb 2002 09:52:41 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00888BE0D@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, Simon Leinen Cc: kcn@norseth.com, data Subject: RE: [ipfix-data] Re: Information Model Date: Wed, 6 Feb 2002 09:52:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF37.13191EC0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AF37.13191EC0 Content-Type: text/plain; charset="iso-8859-1" Hello Paul, :-----Original Message----- :From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] :Sent: Wednesday, February 06, 2002 8:11 AM :To: Simon Leinen :Cc: kcn@norseth.com; data :Subject: [ipfix-data] Re: Information Model : : : :Here is a first cut at the list of data elements to be reported. :I of course hacked it out of the LFAP spec. : :I think we need to begin with a couple of guidlines (which :we should augment as we go). They are just guidelines. : : 1. Data element values should be defined in terms of : other specifications. Since we are only reporting : things in other protocols, there should be little : reason for us to define anything from scatch. I agree with this. : : 2. Each element should be able to be interpreted on : it own. In other words, don't make me look though : the rest of the message to figure out what this : value means. The drawback is this can lead to : data element explosion. We'll have to balance : the tradeoffs. Sounds fair. : : 3. Others?.... Define a minimum set (common denominator) of elements, extensions should be specificed on their own drafts and use capability negotiation to figure out if the peers understand them or not. I'm providing for the hability to negotiate extended flow type support in the capability negotiation section. regards, Reinaldo ------_=_NextPart_001_01C1AF37.13191EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] Re: Information Model

Hello Paul,

:-----Original Message-----
:From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
:Sent: Wednesday, February 06, 2002 8:11 AM
:To: Simon Leinen
:Cc: kcn@norseth.com; data
:Subject: [ipfix-data] Re: Information Model
:
:
:
:Here is a first cut at the list of data elements to = be reported.
:I of course hacked it out of the LFAP spec.
:
:I think we need to begin with a couple of guidlines = (which
:we should augment as we go). They are just = guidelines.
:
:        1. Data = element values should be defined in terms of
:           = other specifications. Since we are only reporting
:           = things in other protocols, there should be little
:           = reason for us to define anything from scatch.

I agree with this.

:
:        2. Each = element should be able to be interpreted on
:           = it own. In other words, don't make me look though    =
:           = the rest of the message to figure out what this
:           = value means. The drawback is this can lead to
:           = data element explosion. We'll have to balance
:           = the tradeoffs.

Sounds fair.

:
:        3. = Others?....

Define a minimum set (common denominator) of = elements, extensions should be specificed on their own drafts and use = capability negotiation to figure out if the peers understand them or = not.

I'm providing for the hability to negotiate extended = flow type support in the capability negotiation section.

regards,

Reinaldo

------_=_NextPart_001_01C1AF37.13191EC0-- -- 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 Feb 6 13:48:18 2002 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 NAA28218 for ; Wed, 6 Feb 2002 13:48:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YWnW-0002A2-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 12:27:58 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YWnT-00029H-00; Wed, 06 Feb 2002 12:27:55 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g16INQj19326; Wed, 6 Feb 2002 10:26:53 -0800 (PST) Received: from cisco.com (sjc-vpn1-543.cisco.com [10.21.98.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC52286; Wed, 6 Feb 2002 10:23:53 -0800 (PST) Message-ID: <3C6176B4.54E9A400@cisco.com> Date: Wed, 06 Feb 2002 10:32:20 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: "KC' 'Norseth" , ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu, ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Re: IPFIX Architecture References: Content-Type: multipart/mixed; boundary="------------78A039BF13702599DD184B8D" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------78A039BF13702599DD184B8D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Kevin, I have some comments on the arch spec portion. There are between 2 "G:"s. Thanks Ganesh --------------78A039BF13702599DD184B8D Content-Type: text/plain; charset=us-ascii; name="comments-draft-ietf-ipfix-arch-xacct-00.txt" Content-Disposition: inline; filename="comments-draft-ietf-ipfix-arch-xacct-00.txt" Content-Transfer-Encoding: 7bit 1 Scope This memo describes the architecture of an IP Flow Information eXport (IPFIX) system. The IPFIX architecture provides a high level view of key functions, interfaces, and protocols employed by the system, and serves as a guide for design, engineering, and deployment of such systems. The IPFIX architecture consists of - A reference model that depicts the key IPFIX entities and interfaces. - Functional descriptions of IPFIX entities. - Detailed descriptions of capabilities in support of IPFIX requirements. - Detailed descriptions of the relationship among IPFIX entities, and definition of the IP flow information export interface that meets the key requirements such as reliable, flexible, and efficient. - An IPFIX protocol architecture that present relationship among various layers, and their communication requirements. 1.1 Specification of Requirements In this document, the keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described in BCP 14. These keywords are not case sensitive in this document. 2 Terminology IPFIX Session An IPFIX Session is a logical connection between an exporter entity and one or multiple collector entity for the purpose of exporting IP flow information. Multiple sessions MAY be maintained concurrently in an exporting device. Template A Template defines the structure of any types of IP flow information record, and specifies the data type, meaning, and location of the fields in the record. 3 IPFIX Reference Model The following figure illustrates the reference model of an IPFIX system. It identifies key IPFIX entities and interfaces within the system. 3 +---------------+ +---------------+ | +----------+ | | +----------+ | | |Meter | | | |Processor | | | |Entity | | | |Entity | | | +----------+ |Exporting | +----------+ | | +----------+ |Interface | +----------+ | | |Exporter |<=|==========|=>|Collector | | | |Entity | | | |Entity | | | +----------+ | | +----------+ | | Exporting | | Collection | | Device | | Device | +---------------+ +---------------+ An exporting device is typically a network element (e.g. routers, measurement probes); a collection device may be part of mediation systems, accounting/billing systems, and network management systems to facilitate business and operation support. 3.1 IPFIX Entities 1.1.1 Exporter The primary task performed by the Exporter entity is to reliably, timely, and efficiently deliver IP flow information to the collector entity. The following functions are responsibilities of the exporter entity: G: what does it timely mean? We can compute the UTC time the flow started and ended. G: - Participating in a capability negotiation process with the collector entity in order to determine a commonly supported IPFIX exporting mechanism (e.g. IPFIX protocol, and its versions) G: Is the intention to make "capability negotiation" a MUST? IMHO the collector should accept whatever is being exporterd by the exporter. In most of the cases (atleast from a router point of view) the collector is only an intermediate box between the exporter and the final node that interprets the export information. The job of the collector from an information point of view would just be to grab all that the exporter sends. From an export protocol perspective, maybe it would make sense to do some kind of negotiation. But here also with so much of infrastructure existing already for reliability, security etc the question is whether we want to come with a new model or just concentrate on flow export.IMO there is no need for negotiation. G: - Participating in control information exchanges with the collector entity. The control information exchanges typically occur during the initial establishment of the exporting session, and may include procedures such as exporting session setup, security support, capability negotiation, protocol negotiation, IP flow information structure (template) negotiation, etc. G: The underlying transport or other protocol is something which can be configured by the sys. admin., whatever the way he wants: CLI, SNMP, telnet, ... G: - Establishing, maintaining, and removing the state associated with an exporting session. - Generating, transmitting, and receiving IPFIX messages. The IPFIX messages may include IPFIX control messages and IPFIX user messages. - Inserting IP flow information into IPFIX data messages according to an encoding scheme. To enable efficient data export, a template based encoding should be supported. G: Sending exporter configuration is one of the most important control information. G: - Segmenting IP Flow information into multiple IPFIX user messages, attaching required control information such as sequence numbers, error checks, etc. - Releasing the transmitted and acknowledged IP flow information from the memory. G: This is an implementation detail. Should be taken care of by the transport. G: - Supporting fail-over and fail-back procedures, and performing load balancing if required. G: Fail-back is not possible on a router -> too much memory needed. The best we can do is fail-over. G: 1.1.2 Collector The primary task performed by the Collector entity is to receive and acknowledge the IP flow information received from the exporter entity. The following functions are responsibilities of the collector entity: - Participating in the capability negotiation and control information exchanges with the Exporter entity. G: Same concerns on capability negotiation as above. G: - Establishing, maintaining, and removing the state associated with an exporting session. - Generating, transmitting, and receiving IPFIX messages. - Receiving IPFIX user messages according to a decoding scheme, checking message integrity, and acknowledging it after it is correctly received or optionally processed and persisted in storage. G: I feel this should be taken care of by the lower layers. G: - Re-sequencing the received IP flow information if required. In case a reliable, in-sequence delivery service is provided by lower layer protocol, this function can be omitted. G: If we have the timestamp per flow why is resequencing required G: - Supporting fail-over and fail-back procedures. G: This should be an exporter feature and not a collector feature. Are you suggesting an inter collector communication? IMO this out of scope for this doc. G: 1.1.3 Meter The primary task performed by the meter entity is to monitor IP flows, and derive IP flow information. How the meter entity measures and derives flow information is outside the scope of the IPFIX architecture, but the attributes used to describe flow information must comply with the IPFIX information model and IP flow definitions. G: The meter entity should interact with the exporter to export information as to how the metering is done. G: 1.1.4 Processor The primary task performed by the Processor entity is to process the received IP flow information based upon end application.s requirements. The functionality of the processor is outside the scope of the IPFIX architecture, though the following functions should be considered in designing and deploying an IPFIX system. G: At the minimum the processor should be able to understand the structure of the exported information. G: - IP flow information aggregation based upon some aspects of IP flows. - IP flow information filtering based upon some aspects of IP flows. 5 - Query additional information (e.g. address translation, user identification, etc.) related to an IP flow from other systems, to facilitate further processing. - Persistent receive IP flow information 3.2 IPFIX Exporting Interface The IPFIX Exporting interface connects an exporter entity with one or multiple collector entities. It MUST support the Internet Protocol (IP) for data communications. G: I guess V4 is a MUST, V6, MPLS is optional. G: 4 IPFIX Deployment Scenarios IPFIX exporting devices may vary greatly in their core functionality. At one hand, a core router needs to support high-speed interfaces and traffic throughput; it emphasizes on forwarding IP traffic quickly and may not be able to perform extensive measurement on IP flow. It is also likely to export high volume of IP flow information to external systems. On the other hand, a measurement probe or an access device is capable of providing more detailed information about IP flows and performing complex on-device processing. Consequently, it may only export low volume of IP flow information. Given the diversity of exporting devices, two deployment scenarios are described. These scenarios only serve as examples for IPFIX system design and deployment. 4.1 Exporting Interface over LAN The following figure illustrates the scenarios where an exporting device connects to the collecting devices over LAN. +----------+ +----------+ +------------+ |Exporting | |Collection|<==>| | |Device | |Device 1 | |Applications| +----------+ +----------+ |e.g. | ^ | ^ | |usage | | v | v |accounting, | --------------------------------------- |traffic | LAN |profiling, | --------------------------------------- |traffic | ^ | |engineering,| | v |QoS | +----------+ |Monitoring | |Collection|<==================>|etc. | |Device 2 | | | +----------+ +------------+ This scenario is suitable for collecting information from core routers. As the volume of exported data is typically high, LAN can 6 provide adequate bandwidth and introduce small latency to meet data exporting requirement. G: It is also important that the exporting overheads are minimized to handle the high volume. Features like reliability G: 4.2 Exporting Interface over WAN The following figure illustrates the scenario where an exporting device connects to the collecting devices over WAN. +----------+ |Collection| +------------+ |Device 1 |<==========>| | +----------+ |Applications| ^ |e.g. | | |usage | +----------+ +--|-------+ |accounting, | |Exporting |<--------|--- | |traffic | |Device |<--------|--------- | |profiling, | +----------+ | WAN | | |traffic | | | | |engineering,| | | | |QoS | +--------|-+ |Monitoring | | |etc. | v | | +----------+ | | |Collection|<==========>| | |Device 2 | +------------+ +----------+ This scenario maybe used to collect information from probes or access routers. It is critical that a congestion aware transport protocol (e.g. TCP, SCTP) is used. 5 Protocol Architecture The following figure illustrates the protocol architecture in supporting of the IPFIX system. 7 Exporting Device Collecting Device +----------------+ +----------------+ | IPFIX | | IPFIX | | User | | User | +----------------+ +----------------+ | IPFIX | | IPFIX | | Layer | | Layer | +----------------+ +----------------+ | Transport | | Transport | | Layer | | Layer | +----------------+-------------+----------------+ | IP Layer | +-----------------------------------------------+ The IFPIX protocol is designed an application running over a transport layer protocol. The transport layer protocol is responsible for delivering IPFIX messages between exporters and collectors. As the IPFIX system MUST be reliable, a reliable transport layer protocol (e.g. TCP, SCTP) should be used. Furthermore, IPFIX layer G: If the reliability is guarenteed by the network, is there a necessity for a reliable transport? As we explained in IETF-52, there are scalability concerns with TCP and making this mandartory would exclude the exporters with high volume from being IPFIX compliant. G: acknowledgement and flow control mechanisms should be supported to ensure flow information is not only correctly received, but also processed and persistent at the collection device. G: Why all these are mandatory for IPFIX layer. I agree the framework should take care of this. But if there is a capability already available why re-invent? G: 6 IPFIX Information Model The IPFIX information model is listed in the IPFIX requirement document. The information model consists of the minimum set of attributes that an IPFIX exporting device should be able to export. In conjunction with IP flow definitions, they provide locally accurate information about a flow. To meet application.s requirement may require the collection device to obtain additional information about the flow, e.g. address translation, user identification, etc. Additional flow information may also be required; in this case, equipment vendors may define extensions to the IPFIX information model. Any extension to the IPFIX information model should be conveyed between end points. This section presents a rigorous definition and sufficient statistics for these attributes. G: I guess this should be maintained in the requirements doc and not duplicated. There are lots of comments on this section. G: 6.1 Attributes related to IP Packet Header The following attributes are obtained directly from IP packet header belonging to a flow: G: What is meant by flow in the above sentence? G: - IP Version Number G: Why? Can't this be derived from address itself? G: - Source Address - Destination Address G: I suggest we keep separate field types for V4 and V6. G: There would be more like inner IP, outer IP etc within v4 and v6. It is better each of such attribute is enumerated. - Protocol Type - TOS (for version 4) G: Why not for V6? G: - Flow Label (for version 6) - DSCP (if DiffServ is supported) G: This is an incomplete list. What about L4 headers? G: 8 6.2 Attributes Related to Measurement The following attributes relates to measurements and measuring methodology: - Packet Counter - Dropped Packet Counter - Payload Byte Counter - Timestamp of the First Packet Observed - Timestamp of the Last Packet Observed - Timeout Indication - Sampling Method - Sampling Parameters 6.3 Attributes Related to Flow Definition The following attributes relates to IP flow definitions. - Incoming Interface - Outgoing Interface - Packet Treatment - Unique ID of the Observation Point - Unique ID of the Measuring Device 6.4 Attributes related to Upper Layers The following attributes provides information of upper layer protocols. - Source Port Address - MPLS Label (if MPLS is supported) 7 IPFIX Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version |Message ID(MID)| Session ID | Message Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Message Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G: The message should have the follwoing - sequence number if the collector wishes to sequence the packets. - the absolute time at which the message was sent and sysUpTime. - an ID to identify the exporter if the collector receives packets from multiple exporters. Why does one need a session ID? G: Version: 8 bit unsigned integer The Version field indicates the IPFIX protocol implementation. Message ID (MID): 8 bit unsigned integer The Message ID field identifies the type of the message. 9 Session ID: 8 bit unsigned char The Session ID field identifies the IPFIX exporting session with which the message is associated. Message Flags: 8 bit unsigned char The Message Flags field can be used to identify options associated with the message. Message Length: 32 bit unsigned integer The Message Length field is the total length of the IPFIX message in octet including the header. Message Payload: Variable Length It contains the control or user information exchanged between IPFIX end-points (exporter and collector entities). 8 IPFIX Messages To be added 9 IPFIX Template The IPFIX system MUST support efficient exporting of IP flow information. This can be achieved by negotiating a set of IPFIX Templates for an IPFIX session before actual IP flow information is exported. G: Templates can be exchanged at any time. This may be done as a result of a config change in the exporter or it may be a periodic update. G: A template defines the structure of an IPFIX user message payload by describing the data type, meaning, and location of the fields in the payload. By agreeing on IPFIX templates, IPFIX end- points understand how to process IPFIX user messages. As a result, an exporting device only needs to export actual flow information without attaching any descriptors of the attributes; this reduces the amount of bytes sent over communication links. G: I do not understand, how the collector can interpret pure data records without any descriptors as to what template it represents. G: A template is an ordered list of keys. A key specifies an attribute that a meter entity MAY export. The specification MUST consist of the description and the data type of the attribute. (e.g. 'Number of Sent Bytes' can be a key that is an 32 bit unsigned integer) An exporting device typically defines keys. Based on the IPFIX information model, a set of IPFIX standard keys can be defined. 9.1 Template Negotiation During the initial setup of an IPFIX session, template negotiation procedures should be carried out. It would allow all the IPFIX end- points to synchronize on a set of templates that will be used during IP flow information export. G: As I said above I really do not agree to this model. G: G: In short the fundamental aspects of disagreement are: - no template/capabilities/etc... negotiation in IPFIX - no MUST for reliable - no state information (except based on the transport protocol, if connection oriented) - no connection initiated from the collector. G: 10 Capability Negotiation 10 To be added 11 Redundancy and Error Handling To be added 12 Author's Address Questions about this memo can be directed to: Kevin Zhang XACCT Technologies, Inc. 2900 Lakeside Drive Santa Clara, CA 95054 Phone +1 301 992 4697 Email: kevin.zhang@xacct.com --------------78A039BF13702599DD184B8D-- -- 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 Feb 6 13:53:24 2002 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 NAA28342 for ; Wed, 6 Feb 2002 13:53:23 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YWoO-0002BB-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 12:28:52 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YWoL-0002Ab-00; Wed, 06 Feb 2002 12:28:50 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g16IRVj21550; Wed, 6 Feb 2002 10:27:33 -0800 (PST) Received: from cisco.com (sjc-vpn1-543.cisco.com [10.21.98.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC52465; Wed, 6 Feb 2002 10:27:54 -0800 (PST) Message-ID: <3C6177A5.B757801D@cisco.com> Date: Wed, 06 Feb 2002 10:36:21 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ram.gopal@nokia.com CC: kevin.zhang@xacct.com, knorseth@enterasys.com, ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu, Man.M.Li@nokia.com, ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] IPFIX Architecture writeup from Ram Gopal References: Content-Type: multipart/mixed; boundary="------------A648DF85699A1E36331846EC" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------A648DF85699A1E36331846EC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ram, Man Li, I have some comments on the arch spec portion that you sent out. The comments are inline between 2 "G:"s. Thanks Ganesh --------------A648DF85699A1E36331846EC Content-Type: text/plain; charset=us-ascii; name="comments-draft-gopal-ipfix-arch.txt" Content-Disposition: inline; filename="comments-draft-gopal-ipfix-arch.txt" Content-Transfer-Encoding: 7bit IPFIX working group Ram Gopal Internet Draft Man Li Expires July 2002 Nokia February 2002 IPFIX Architecture draft-gopal-ipfix-arch.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html . Abstract This document defines architecture for scalable monitoring, measuring and exporting IP flow information to collectors. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Gopal, Li Expires January, 2002 1 IPFIX Architecture July, 2001 1. Introduction Many applications e.g., Intrusion detection, traffic engineering, require the monitoring, measuring of IP traffic flows. It is hence important to have a standard way of exporting information related to IP flows. This document defines architecture for IP traffic flow monitoring, measuring and exporting. It provides a high-level description of the key components and their functions. 2. Scope This document defines architecture for IPFIX[3]. Specifically, this document o Describes the key architectural components of IPFIX. o Describes the external dependency and identifies those interfaces explicitly. o Defines architectural requirements, e.g., Recovery, Security, etc. o Defines the required external interfaces to interoperate with other protocol/architecture this may includes AAA or Diameter or Intrusion Detection system. G: I'm not sure what can be done in connection with AAA or other protocol here? G: o Identifies a minimal set of applications for IPFIX. 3. Architecture Overview Figure 1 shows the reference model for IPFIX. The blocks shown are logical entities. The functionalities of these components remain the same regardless of their placements inside a network. The main purpose of the IPFIX subsystems is to effectively communicate the information model using IPFIX. The information model is composed of set of attributes that are of interest to the applications. Each application may require a subset of the parameters specified in the information model. The information model is generalized and communicated between IPFIX endpoints as Templates for operational purpose. Gopal, Li Expires January, 2002 2 IPFIX Architecture July, 2001 +------------+ +-------------+ |Application | | Application | | (1) | . | (n) | +------------+ +-------------+ || || ====================== || || || +---------------+---------+ || | | | || | Exporter(1) | IPFIX |<=+ || | | | || || +---------------+---------+ || || . || || . || || +---------------+---------+ || +-------+-----------+ | | | || | | | | Exporter(n) | IPFIX |<=====>| IPFIX | Collector | | | | || | | | +---------------+---------+ || +-------+-----------+ || || || || +=====================+ || +-------+-------------+ || || || | | | || || ====>| IPFIX | Collector | +------------+ +-------------+ | |(Application)| |Observation | | Observation | +-------+-------------+ | Point(1) |.. | Point (n) | +------------+ +-------------+ Figure 1: IPFIX architectural view G: The diagram is confusing. Observation Point and exporter are 2 pieces of a single system and not separate entities. G: 3.1 Observation Point The observation point may be one or a set of interfaces through which the IP flows are monitored. The functions of an observation point include: o Monitoring and filtering of IP Flows according to configured rules o Forward either IP packets or requirement information to the Exporter o In some cases, an observation point may perform metering as well. G: Observation point is the place where metering is done. I did not understand why it is an option. Metering includes filtering also. From http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt: 4. Metering Process The following are requirements for the metering process. They describe the requirements for the process at the measurement instance. All measurements MUST be conducted from the point of view of the observation point. ..... G: The interface between the Observation point and the Exporter is beyond the scope of IPFIX. Gopal, Li Expires January, 2002 3 IPFIX Architecture July, 2001 3.2 Exporter The exporter is a subsystem that interacts with one or more observation points. The functions of an exporter include: o Performing Flow ID management that includes the creation of tags to refer a flow between Exporter and the Collector for configuration and statistical purpose. o Assembling collected information into the right format to be carried by the IPFIX protocol o Configuring observation points with flow monitoring rules G: Configuring the observation point itself is not a strict functionality of the exporter.But once some other subsystem has done the configuration, the exporter needs to send the configuration to the collector. G: o Measuring, aggregating and exporting IP Flow information to the respective collectors. The information collected can be either pushed periodically to the collector or pulled by the collector on demand. 3.3 IPFIX protocol IPFIX protocol may run on top of either Transport or IP layer. If the underlying network is not reliable, it is the responsibility of the IPFIX protocol to perform transport level functions. It is recommended to use reliable transport protocols like SCTP or TCP. The functions of IPFIX protocol include: o Reliably and securely transporting application level information between an exporter and a collector ( security functions are leveraged by using underlying security protocols) G: If reliability is guarenteed by transport layer or network, this is really not necessary. G: o Maintaining the communication links between IPFIX endpoints. This includes detection of loss of connections and recovery processes. 3.4 Collector Collector is a subsystem that interacts with one or more Exporters. The functions of the collector include: o Requesting an exporter sub-system to collect IP flows. G: It is the exporter who decides what to measure , where to measure & what to send. We are not defining how to configure a metering process from a collector. - the exporter configuration is out of the scope of this document - the exporter configuration SHOULD be done out of band G: o Communicating with different applications. o Maintaining a repository of IP flow statistics o Aggregating application level requests and form a template that will suitable for exporter. G: This is out of scope for this doc. G: The application(s) and the collector may be tightly coupled in one system. They may also be logically or physically a separate subsystem from the application(s). In which case, the communication between them is beyond the scope of IPFIX. Gopal, Li Expires January, 2002 4 IPFIX Architecture July, 2001 3.5 Applications IPFIX applications may be Billing, Network Surveillance, and Intrusion Detection sub-systems. etc.[3]. An application requests the Collector to gather the relevant IP Flow information. 4. Some Applications of IPFIX G: This is already covered in the req. spec.Is there a necessity to repeat it here? G: This section describes the IPFIX applications that are identified in the requirement document[3]. These applications are not exhaustive. 4.1 IPFIX usage in Intrusion Detection Intrusion Detection System (IDS) monitors and controls the security incidents [4]. Typical IDS system includes components like Data source, Sensor, Analyzer and Management stations[4]. A Sensor monitors the data source and raises the alarm to the Analyzer. The analyzer collects various incident information and reports this to the management station. With IPFIX, the event of interest can be exported either from collector or from exporter. For smooth integration, it will be better for the IDS system to integrate with the collector since the collector has all the aggregated information from different observation points. The IDS can request the collector to monitor the events or IP flow through an IPFIX template. 4.2 IPFIX usage in usage-based accounting Usage-based accounting typically includes monitoring of IP packets from a particular data source or user. This information is then used for billing purpose. Typically a usage-based application has details about the user service plans and the IP addresses being used by the user. The application may request an IPFIX collector to monitor the IP flows based on the service plan and the IP address of the user. The collector reports the IP flow statistics to the accounting application and it is the responsibility of the accounting application to correlate this statistics with a particular user in order to generate billing information. 4.3 IPFIX usage in Traffic Engineering/Traffic Profiling To better utilize the network, traffic engineering [5] is performed by the network administrator. IPFIX can monitor and report different flows. Using this information as a baseline, network administrators can perform optimized network planning and engineering. more to be written Gopal, Li Expires January, 2002 5 IPFIX Architecture July, 2001 5. Architectural Requirements 5.1 Recovery 5.2 Performance 5.3 Security Refer Security Consideration section for details 6. Security Consideration (a) Data Integrity and Authentication As IPFIX is relying on underling transport protocol like TCP or SCTP etc., IPFIX can leverage all the authentication and encryption mechanism to the underlying protocol e.g. TLS or IPSec. (b) End point Authentication Since there may be more than one application interested in the collected data. IPFIX exporter may be able to authenticate each collector on before exchanging of packets. This may be done by having pre-established security associations between endpoints. G: Yes. This can be achieved by using Authentication Header or ESP and need not be built into the IPFIX framework. G: (d) Resistance to attacks As a general security measure, any new protocol should not introduce possibilities of new attacks. IPFIX depends on the transport layers for basic communications. Hence DoS attack resistance and prevention is out of scope. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3. J. Quittek ,et al., Requirements for IP Flow Information Export , (work in progress) ,Internet Draft, Internet Engineering Task Force, , November 2001 4. M. Wood ,et al., Intrusion Detection Message Exchange Requirements,(work in progress), Internet Draft, Internet Engineering Task Force, draft-ietf-idwg-requirements-06,February 2002. Gopal, Li Expires January, 2002 6 IPFIX Architecture July, 2001 5. Daniel O. Awduche, et. al.,Overview and Principles of Internet Traffic Engineering, (work in progress), Internet Draft, Internet Engineering Task Force, draft-ietf-tewg-principles- 02.txt, May 2002 9. Author's Addresses Ram Gopal Nokia 5 Wayside Road, Burlington, MA 01803 Phone:+1 781 993 3685 Email: ram.gopal@nokia.com Man Li Nokia 5 Wayside Road, Burlington, MA 01803 Phone: +1 781 993 3923 Email: man.m.li@nokia.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Gopal, Li Expires January, 2002 7 --------------A648DF85699A1E36331846EC-- -- 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 Feb 6 14:11:38 2002 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 OAA28869 for ; Wed, 6 Feb 2002 14:11:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YX98-0002c8-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 12:50:18 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YX95-0002ax-00 for ipfix-data@net.doit.wisc.edu; Wed, 06 Feb 2002 12:50:16 -0600 Received: from riverstonenet.com (134.141.180.92 [134.141.180.92]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X7WWGB0T; Wed, 6 Feb 2002 10:49:05 -0800 Message-ID: <3C617AA2.B58DBB8@riverstonenet.com> Date: Wed, 06 Feb 2002 13:49:06 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: Simon Leinen , kcn@norseth.com, data Subject: Re: [ipfix-data] Re: Information Model References: <4F973E944951D311B6660008C7917CF00888BE0D@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > Hello Paul, > > :-----Original Message----- > :From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > :Sent: Wednesday, February 06, 2002 8:11 AM > :To: Simon Leinen > :Cc: kcn@norseth.com; data > :Subject: [ipfix-data] Re: Information Model > : > : > : > :Here is a first cut at the list of data elements to be reported. > :I of course hacked it out of the LFAP spec. > : > :I think we need to begin with a couple of guidlines (which > :we should augment as we go). They are just guidelines. > : > : 1. Data element values should be defined in terms of > : other specifications. Since we are only reporting > : things in other protocols, there should be little > : reason for us to define anything from scatch. > > I agree with this. > > : > : 2. Each element should be able to be interpreted on > : it own. In other words, don't make me look though > : the rest of the message to figure out what this > : value means. The drawback is this can lead to > : data element explosion. We'll have to balance > : the tradeoffs. > > Sounds fair. > > : > : 3. Others?.... > > Define a minimum set (common denominator) of elements, extensions > should be specificed on their own drafts and use capability > negotiation to figure out if the peers understand them or not. > > I'm providing for the hability to negotiate extended flow type support > in the capability negotiation section. I agree but we need to list all the data elements we can. If we do not, the someone building a IPFIX server will need to go to each vendor to figure out what data they have an what it means. You can negotiate about what data elements you support as an exporter but the semantics of that data should already be defined. > > regards, > > Reinaldo -- 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 Feb 6 15:32:12 2002 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 PAA01022 for ; Wed, 6 Feb 2002 15:32:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YYKu-0004EJ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 14:06:32 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YYKs-0004Cl-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 14:06:30 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g16K50j13349; Wed, 6 Feb 2002 12:05:42 -0800 (PST) Received: from cisco.com (sjc-vpn1-543.cisco.com [10.21.98.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC57167; Wed, 6 Feb 2002 12:05:29 -0800 (PST) Message-ID: <3C618E83.F1C57C73@cisco.com> Date: Wed, 06 Feb 2002 12:13:56 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: zseby@fokus.gmd.de CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring References: <3C6113C9.2080604@fokus.fhg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Tanja, Tanja Zseby wrote: > Hi K.C., > > attached you can find my contributions to the architecture document. > > - The first text contains some first thoughts on how IPFIX and AAA could > communicate. To me, this portion is entirely out of scope from an IPFIX arch point of view. This is more of an application which takes in flow records collected by the IPFIX collector. Similarly there could be other applications that use the collected flow records.IMO we should not be defining these interfaces in the archtecture. If there is something like an applicability doc, that would be a good place for this to go. But again the point is that IPFIX should not go all the way to define interfaces with each of the possible applications. > > > - The second text contains considerations on how IPFIX can be used for > QoS monitoring. Maybe this can also go into the architecture document > (Ram Gopal for instance had a section on "some applications for IPFIX" > in his text). Or do you think this should be put into a separate document ? This also looks to be good for an applicability doc. Thanks Ganesh > > > Regards > Tanja > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > -------------------------------------------------------------------------------------- > "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) > -------------------------------------------------------------------------------------- > -- 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 Feb 6 16:08:52 2002 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 QAA02102 for ; Wed, 6 Feb 2002 16:08:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YYtB-000513-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 14:41:57 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YYt7-00050s-00; Wed, 06 Feb 2002 14:41:53 -0600 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g16KhaQ27915; Wed, 6 Feb 2002 14:43:36 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Feb 2002 14:41:48 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Feb 2002 14:41:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ipfix-arch] RE: IPFIX Architecture writeup from Ram Gopal Date: Wed, 6 Feb 2002 15:41:47 -0500 Message-ID: Thread-Topic: IPFIX Architecture writeup from Ram Gopal Thread-Index: AcGvPKFHZRldqaUcSdii+qh5uh/9DQAER0RQ From: To: Cc: , , , , , , X-OriginalArrivalTime: 06 Feb 2002 20:41:48.0555 (UTC) FILETIME=[B2D2BDB0:01C1AF4E] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA02102 Hello Ganesh, see my line comments. (1) G: I'm not sure what can be done in connection with AAA or other protocol here? G: We fixed the sentence (2) G: The diagram is confusing. Observation Point and exporter are 2 pieces of a single system and not separate entities. G: The logical functionalities are described whether u have everything in one piece or distributed it is upto the implementation. (3) G: Observation point is the place where metering is done. I did not understand why it is an option. Metering includes filtering also. From http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt: 4. Metering Process The following are requirements for the metering process. They describe the requirements for the process at the measurement instance. All measurements MUST be conducted from the point of view of the observation point. ..... G: Refer requirement document 1.1 IPFlow The observation point may be a network interface of a device or an entire router, a probe, or a middlebox with several interfaces. Properties derived from packet treatment include for example the interface at which the packet arrived, the interface the packet will be forwarded to and potentially some other information. So observation point is just a probe , for example typically we may have more than one interface through which we would like to monitor the packet. My feeling is that requirement document should rectify Metering process definition. (4) G: If reliability is guaranteed by transport layer or network, this is really not necessary. G: We agree, removed this statement. (5) G: It is the exporter who decides what to measure , where to measure & what to send. We are not defining how to configure a metering process from a collector. - the exporter configuration is out of the scope of this document - the exporter configuration SHOULD be done out of band G: This may be one implementation, but generally exporter does metering, and reporting functions and more detailed in the document. Regarding configuration, what is said is one implementation. But collector should be able to request (Configure) and get the required Flow information. We are not defining what are the configuration information but we are describing the functionality over here. (6) G: This is already covered in the req. spec.Is there a necessity to repeat it here? G: I think this sentence is rephrased and content of the sections are different. We added more text from other authors. Hope compiled version of the document will give better picture. Regards Ramg -- 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 Feb 6 17:16:28 2002 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 RAA04163 for ; Wed, 6 Feb 2002 17:16:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Ya68-0006pv-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 15:59:24 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Ya66-0006pJ-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 15:59:22 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g16LweU04938; Wed, 6 Feb 2002 15:58:41 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVCW8>; Wed, 6 Feb 2002 13:58:36 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890EA4A@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Tanja Zseby , "K.C. Norseth" Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Date: Wed, 6 Feb 2002 13:58:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF59.6A28BF50" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AF59.6A28BF50 Content-Type: text/plain; charset="iso-8859-1" Hello, I just read this QoS doc, which BTW is very nice, but I wonder whether this is in-scope. I mean, how exactly you are going to perform QoS monitoring depend in so many factors...applications, networks, etc. It should be totally up to the implementation and indirectly who is doing the monitoring. Maybe a different draft suggesting recommendations on QoS measurement process for IPfix. Any thoughts? regards, Reinaldo :-----Original Message----- :From: Tanja Zseby [mailto:zseby@fokus.gmd.de] :Sent: Wednesday, February 06, 2002 3:30 AM :To: K.C. Norseth :Cc: ipfix-arch@net.doit.wisc.edu :Subject: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring : : :Hi K.C., : :attached you can find my contributions to the architecture document. : :- The first text contains some first thoughts on how IPFIX and :AAA could :communicate. : :- The second text contains considerations on how IPFIX can be used for :QoS monitoring. Maybe this can also go into the architecture document : (Ram Gopal for instance had a section on "some applications :for IPFIX" :in his text). Or do you think this should be put into a :separate document ? : :Regards :Tanja : :-- :Dipl.-Ing. Tanja Zseby :FhI FOKUS/Global Networking Email: :zseby@fokus.fhg.de :Kaiserin-Augusta-Allee 31 Phone: :+49-30-3463-7153 :D-10589 Berlin, Germany Fax: :+49-30-3463-8153 :--------------------------------------------------------------- :----------------------- :"Living on earth is expensive but it includes a free trip :around the sun." (Anonymous) :--------------------------------------------------------------- :----------------------- : : ------_=_NextPart_001_01C1AF59.6A28BF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS = Monitoring

Hello,

I just read this QoS doc, which BTW is very nice, but = I wonder whether this is in-scope. I mean, how exactly you are going to = perform QoS monitoring depend in so many factors...applications, = networks, etc. It should be totally up to the implementation and = indirectly who is doing the monitoring.

Maybe a different draft suggesting recommendations on = QoS measurement process for IPfix. Any thoughts?

regards,

Reinaldo



:-----Original Message-----
:From: Tanja Zseby [mailto:zseby@fokus.gmd.de]=
:Sent: Wednesday, February 06, 2002 3:30 AM
:To: K.C. Norseth
:Cc: ipfix-arch@net.doit.wisc.edu
:Subject: [ipfix-arch] IPFIX and AAA and IPFIX for = QoS Monitoring
:
:
:Hi K.C.,
:
:attached you can find my contributions to the = architecture document.
:
:- The first text contains some first thoughts on = how IPFIX and
:AAA could
:communicate.
:
:- The second text contains considerations on how = IPFIX can be used for
:QoS monitoring. Maybe this can also go into the = architecture document
: (Ram Gopal for instance had a section on = "some applications
:for IPFIX"
:in his text). Or do you think this should be put = into a
:separate document ?
:
:Regards
:Tanja
:
:--
:Dipl.-Ing. Tanja Zseby =         =             =            
:FhI FOKUS/Global Networking    =         =         Email:
:zseby@fokus.fhg.de    
:Kaiserin-Augusta-Allee = 31      =         =         =         Phone:
:+49-30-3463-7153
:D-10589 Berlin, = Germany        =         =         =         Fax:  
:+49-30-3463-8153
:--------------------------------------------------------------= -
:-----------------------
:"Living on earth is expensive but it includes = a free trip
:around the sun." (Anonymous)
:--------------------------------------------------------------= -
:-----------------------
:
:

------_=_NextPart_001_01C1AF59.6A28BF50-- -- 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 Feb 6 17:46:10 2002 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 RAA04566 for ; Wed, 6 Feb 2002 17:46:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YaV8-0007XC-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 16:25:14 -0600 Received: from mercury.sun.com ([192.9.25.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YaV6-0007Wv-00 for ipfix-data@net.doit.wisc.edu; Wed, 06 Feb 2002 16:25:12 -0600 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23756; Wed, 6 Feb 2002 14:25:06 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA16823; Wed, 6 Feb 2002 14:26:42 -0800 (PST) Received: from sun.com (inox.Eng.Sun.COM [129.146.85.133]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16MP4GB248821; Wed, 6 Feb 2002 14:25:04 -0800 (PST) Message-ID: <3C61AD4B.1D6176E3@sun.com> Date: Wed, 06 Feb 2002 14:25:15 -0800 From: Jc Martin Organization: Sun Microsystems X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Simon Leinen , kcn@norseth.com, data Subject: Re: [ipfix-data] Re: Information Model References: <20020205204955.5721.cpmta@c001.snv.cp.net> <3C61557E.2F3B2D05@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit See my comments inline. calato@riverstonenet.com wrote: > > Here is a first cut at the list of data elements to be reported. > I of course hacked it out of the LFAP spec. > > I think we need to begin with a couple of guidlines (which > we should augment as we go). They are just guidelines. > > 1. Data element values should be defined in terms of > other specifications. Since we are only reporting > things in other protocols, there should be little > reason for us to define anything from scatch. There are two parts in the above. One is where the protocol field is defined, and the other is where the field is encoded in another standard. So, for example, the source port is defined in RFC 768, but it's definition (representation ?) could be imported from RFC 1155 or CIM (like RFC3060 is doing). Also, it is worth mentioning the RFC 2924 as a source of information elements. At this point, I would like to say that there is already a great disparity between the various accounting mechanisms in the way the information is represented, it would be nice if IPFIX is not adding yet another way of counting packets (Acct-Output-Octets, Forward Packets,...) > > 2. Each element should be able to be interpreted on > it own. In other words, don't make me look though > the rest of the message to figure out what this > value means. The drawback is this can lead to > data element explosion. We'll have to balance > the tradeoffs. Is that preventing the use of template ? > > 3. Others?.... Should add something about the naming of attributes, using OIDs, DNs, ... Also, I would like to see some positioning with regards to CIM and SMIv2. Even if the attributes are defined in a template, both the template and the attributes should be named through a standard naming scheme. [snip] > > 1.7 Class of Service IE > > The class of service associated with a flow. > > Class of Service Received > Class of Service Transmitted > > 1 - IPv4, CoS value is defined by ToS in RFC 791 > 2 - IPv6, CoS value is defined by Traffic Class in RFC 2460 > 3 - MPLS, CoS value is defined by Exp in RFC 3032 > 4 - VLAN, CoS value is defined by user_priority in IEEE > 802.1q[802.1q] and IEEE 802.1p[802.1p] > > [Can more than one Class of Service can be present??? PAC] > Is there any interest in counting the number of packets/bits with the ECN (RFC 3168), or do you see that as an extension ? [snip] > 1.10 Byte Count IE > > Contains the count of octets sent and received associated with the > identified flow. > > The byte count can be for bytes received (towards source) or > bytes sent (towards destination) or both (bi-directional flow). > > The byte count can be a running counter and is the > count from the beginning of the flow establishment. > The byte count can be a delta counter and is the > count since the last report for this flow. > > 1.11 Packet Count IE > > Contains the count of packets sent and received associated with the > identified flow. > > The packet count can be for packets received (towards source) or > packets sent (towards destination) or both (bi-directional > flow). > > The packet count can be a running counter and is the > count from the beginning of the flow establishment. > The packet count can be a delta counter and is the > count since the last report for this flow. What do you mean by "can be" in the above cases ? It's either one or the other, and this need to be specified, or allowed in the coding. [snip] > 1.34 Vendor Specific IE > > Vendors may add their own information to the protocol. Information what does this sentence means ? Which protocol ? > contained in this IE is vendor specific. OID and OID Value is > defined by ITU X.680.X683 (1997) and is encoded as defined by ITU > X.690.691(1997). This IE MUST not contain any information which > cannot be safely ignored by the Exporter or Collector. If multiple > Vendor > Specific IE's with the same OID occur, then the vendor defines > semantics of ordering. you are mentionning the OID here, what about the other elements ? [snip] JC -- 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 Feb 6 18:07:43 2002 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 SAA04781 for ; Wed, 6 Feb 2002 18:07:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YafC-0007lj-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 16:35:38 -0600 Received: from mercury.sun.com ([192.9.25.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yaf9-0007lZ-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 16:35:35 -0600 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26386; Wed, 6 Feb 2002 14:35:29 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.105]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA22161; Wed, 6 Feb 2002 14:37:06 -0800 (PST) Received: from sun.com (inox.Eng.Sun.COM [129.146.85.133]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16MZSGB250948; Wed, 6 Feb 2002 14:35:28 -0800 (PST) Message-ID: <3C61AFBB.CBA7ACF@sun.com> Date: Wed, 06 Feb 2002 14:35:39 -0800 From: Jc Martin Organization: Sun Microsystems X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: zseby@fokus.gmd.de, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring References: <3C6113C9.2080604@fokus.fhg.de> <3C618E83.F1C57C73@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh, The interface between AAA and IPFIX can be as simple as a common set of attributes, coding, ... There should be an effort to avoid the proliferation of accounting attributes specially if they refer to the same element. Also, the mediation applications are merging multiple source of information to build the CDRs, it is likely that IPFIX records will be consolidated with radius records to determine the end user of a given IP address. I agree that this should be in an applicability doc, but it could also be taken into account when the architecture is defined. JC. Ganesh Sadasivan wrote: > > Hi Tanja, > > Tanja Zseby wrote: > > > Hi K.C., > > > > attached you can find my contributions to the architecture document. > > > > - The first text contains some first thoughts on how IPFIX and AAA could > > communicate. > > To me, this portion is entirely out of scope from an IPFIX arch point > of view. > This is more of an application which takes in flow records collected by the > IPFIX collector. Similarly there could be other applications that use the > collected flow records.IMO we should not be defining these interfaces in > the archtecture. > If there is something like an applicability doc, that would be a good place > for this to go. But again the point is that IPFIX should not go all the way to > define interfaces with each of the possible applications. > > > > > > > - The second text contains considerations on how IPFIX can be used for > > QoS monitoring. Maybe this can also go into the architecture document > > (Ram Gopal for instance had a section on "some applications for IPFIX" > > in his text). Or do you think this should be put into a separate document ? > > This also looks to be good for an applicability doc. > Thanks > Ganesh > > > > > > > Regards > > Tanja > > > > -- > > Dipl.-Ing. Tanja Zseby > > FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de > > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > > -------------------------------------------------------------------------------------- > > "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) > > -------------------------------------------------------------------------------------- > > > > -- > 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/ -- 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 Feb 6 18:09:25 2002 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 SAA04796 for ; Wed, 6 Feb 2002 18:09:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YamJ-0000AJ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 16:42:59 -0600 Received: from kathmandu.sun.com ([192.18.98.36]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YamH-0000AC-00 for ipfix-data@net.doit.wisc.edu; Wed, 06 Feb 2002 16:42:57 -0600 Received: from sunmail1.Sun.COM ([129.145.1.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02715; Wed, 6 Feb 2002 15:42:53 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id OAA25939; Wed, 6 Feb 2002 14:44:30 -0800 (PST) Received: from sun.com (inox.Eng.Sun.COM [129.146.85.133]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g16MgqGB252439; Wed, 6 Feb 2002 14:42:52 -0800 (PST) Message-ID: <3C61B177.1E55A0C@sun.com> Date: Wed, 06 Feb 2002 14:43:03 -0800 From: Jc Martin Organization: Sun Microsystems X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com, Simon Leinen , kcn@norseth.com, data Subject: Re: [ipfix-data] Re: Information Model References: <20020205204955.5721.cpmta@c001.snv.cp.net> <3C61557E.2F3B2D05@riverstonenet.com> <3C61AD4B.1D6176E3@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I reply to myself ,... > > Also, it is worth mentioning the RFC 2924 as a source of information > elements. > At this point, I would like to say that there is already a great > disparity between the various accounting mechanisms in the way > the information is represented, it would be nice if IPFIX is not > adding yet another way of counting packets (Acct-Output-Octets, > Forward Packets,...) The "counting packets" is just an example, and all elements are subject to the same remark. JC. -- 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 Feb 6 18:12:23 2002 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 SAA04882 for ; Wed, 6 Feb 2002 18:12:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yao9-0000Ey-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 16:44:53 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yao7-0000C4-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 16:44:51 -0600 Received: from cisco.com (bclaise-isdn-home5.cisco.com [10.49.4.222]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA09797; Wed, 6 Feb 2002 23:42:34 +0100 (MET) Message-ID: <3C61B157.2781B348@cisco.com> Date: Wed, 06 Feb 2002 23:42:31 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: Ganesh Sadasivan , "KC' 'Norseth" , ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Re: IPFIX Architecture References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Kevin, A couple of important points I would like to discuss amongst the group [I haven't copied the entire document] G: stands for Ganesh Kz: Kevin Zhang Ben: Benoit G: The underlying transport or other protocol is something which can be configured by the sys. admin., whatever the way he wants: CLI, SNMP, telnet, ... G: [kz3] What you are saying is correct. It depends on whether you want to do it in-band within the export protocol or out-band. However, do it within the protocol improves interoperability significantly which is exactly this WG is trying to achieve. [kz] [Ben] I don't know how it improves the interoperability to do the configuration inband. IPFIX stands for Flow Information eXport. So we have to standardize the export, not the configuration. So the direction:exporter -> collector and not the direction collector -> exporter. At least not for the configuration. Standardizing the configuration is a huge job. Do you think that vendors will spend time and money to developp again another configuration interface, next to CLI, SNMP, XML, etc...? And this just for an IPFIX protocol! What I'm thinking is that the configuration of the probe or the router is out of the scope of this document and is based on proprietary solutions. Proprietary solutions that you will very hardly standardize, because they all contains different proprietary features. [Ben] [kz2] "capability negotiation" is a MUST, this is key for the IPFIX system to be flexible enough to deal with various exporting devices (besides core routers). Your view is router-centric, at least in a probes case, what to collect, how to collect, and when to export are typically configurable by the applications through the collector. Furthermore, exactly due to the existing infrastructure, "capability negotiation" would be key for the exporter and collector to understand what are the lower layer support (e.g. security, transport protocol, etc.) for the interace. [kz] [Ben] Well, I guess that I have a "router-centric" view as you call it ;) As I expressed before, my view is that, because the exporter configuration must happen out-of-band, capabilities negotiation should not happen. 1. Neither capabilities negotiation for the exported fields in a template: because the template is based on what the exporter can do, not on what a collector thinks an exporter can do. In other words, you configure the exporter template (by whatever means), the transport protocol and where to export. Then the collector must be able to parse all the fields of the template. I refer you to section 8 of http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt for more details of what I'm thinking. 2. Neither transport protocol negotiation. The transport protocol is the first thing you will decide on in an accounting network design (accouting being just a generic term). I mean, depending if you want to be billing or traffic monitoring, you may use a connection-oriented transport compared to UDP, with or without IPSEC. Basically, you won't change very often your transport protocol. So why would like to invest time in a transport protocol negotiation? I would say that this would be configured once for all before you even start exporting the first flow record. [Ben] G: Fail-back is not possible on a router -> too much memory needed. The best we can do is fail-over. G: [kz6] I don't see big difference for memory requirement between fail-over and fail-back, would you please providing more details? [kz] [Ben] Fail-over means that as soon as you detect that the connection (only in case of a reliable transport protocol, not UDP) to the collector is lost, you can start sending to another collector. You may loose a few flow records depending on your transport protocol keepalive. Fail-back means that if we switch to another collection, we can' t loose any data. Again maybe a router-centric view ;), but Ganesh showed at the last IETF how much data we can produce per second when exporting from a router. I refer you to section 4.1.3 and 4.2.3 of http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt for more details of what I'm thinking. 4 Flow Export Protocol ................................... 9 4.1 Simple Export Model .................................... 10 4.1.1 Collector Crash ........................................ 10 4.1.2 Collector Redundancy ................................... 10 4.1.3 Collector Failover ..................................... 10 4.2 Export Model with Reliable Control Connection .......... 10 4.2.1 Collector Crash ........................................ 11 4.2.2 Collector Redundancy ................................... 11 4.2.3 Collector Failover ..................................... 12 [Ben] - Re-sequencing the received IP flow information if required. In case a reliable, in-sequence delivery service is provided by lower layer protocol, this function can be omitted. G: If we have the timestamp per flow why is resequencing required G: [kz7] Timestamp is not sufficient to detect message losses, particularly when unreliable transport protocol is used. [kz] [Ben] Right, but you can still have a sequence ID in the packet which will tell you if you are loosing some packets. Is this what you have in mind when talking about re-sequencing? Regards, Benoit [Ben] -- 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 Feb 6 20:15:55 2002 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 UAA06080 for ; Wed, 6 Feb 2002 20:15:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Ycoz-0004E5-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 18:53:53 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Ycox-0004DG-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 18:53:51 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g170rLP04338; Wed, 6 Feb 2002 16:53:21 -0800 (PST) Received: from cisco.com (sjc-vpn1-543.cisco.com [10.21.98.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC68768; Wed, 6 Feb 2002 16:53:42 -0800 (PST) Message-ID: <3C61D210.4C5C0D56@cisco.com> Date: Wed, 06 Feb 2002 17:02:08 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ram.gopal@nokia.com CC: Man.M.Li@nokia.com, ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Re: IPFIX Architecture writeup from Ram Gopal References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ram, See inline for my comments ram.gopal@nokia.com wrote: > Hello Ganesh, > > see my line comments. > > (1) > G: > I'm not sure what can be done in connection with AAA or > other protocol here? > G: > > We fixed the sentence > > (2) > G: > The diagram is confusing. > Observation Point and exporter are 2 pieces of a single system and not > separate entities. > G: > > The logical functionalities are described whether u have everything in one piece > or distributed it is upto the implementation. The point here is that IPFIX does not try to define the interface between observation point and exporter. Showing it as 2 pieces lets one think why the interface between these 2 should not be defined. Showing the way Kevin Zhang has shown for the exporter part looks cleaner to me. > > > (3) > G: > Observation point is the place where metering is done. > I did not understand why it is an option. Metering includes > filtering also. > From http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt: > > 4. Metering Process > > The following are requirements for the metering process. They > describe the requirements for the process at the measurement > instance. All measurements MUST be conducted from the point of view > of the observation point. > ..... > G: > > Refer requirement document 1.1 IPFlow > > The observation point may be a network interface of a device or an > entire router, a probe, or a middlebox with several interfaces. > Properties derived from packet treatment include for example the > interface at which the packet arrived, the interface the packet will > be forwarded to and potentially some other information. > > So observation point is just a probe , for example typically we may have more than > one interface through which we would like to monitor the packet. In the above example the Observation point (the probe) is an aggregation of interfaces. The metering is also done logically at the probe level which gets split up into the individual interfaces depending on the implementation. But the collector sees the observation point as the metering entity. I agree that metering process is not very clear in the req spec. > > > My feeling is that requirement document should rectify Metering process definition. > > (4) > > G: > If reliability is guaranteed by transport layer or network, this > is really not necessary. > G: > > We agree, removed this statement. > > (5) > > G: > It is the exporter who decides what to > measure , where to measure & what to send. We are not defining > how to configure a metering process from a collector. > - the exporter configuration is out of the scope of this document > - the exporter configuration SHOULD be done out of band > > G: > > This may be one implementation, but generally exporter does metering, and reporting functions and > more detailed in the document. > > Regarding configuration, what is said is one implementation. But collector should be able to > request (Configure) and get the required Flow information. For this the collector needs to understand the capability and to some extent the implementation of an exporter and this is a non-trivial problem to solve. > > > We are not defining what are the configuration information but we are describing > the functionality over here. > > (6) > > G: > This is already covered in the req. spec.Is there a necessity > to repeat it here? > G: > > I think this sentence is rephrased and content of the sections are different. We added more text from other authors. > Hope compiled version of the document will give better picture. It is better to have another doc. called applicability doc or so rather than keeping it as a part of the architecture. Thanks Ganesh > > > Regards > Ramg -- 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 Feb 6 22:05:40 2002 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 WAA09046 for ; Wed, 6 Feb 2002 22:05:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YecI-0006RL-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 20:48:54 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YecD-0006Qi-00; Wed, 06 Feb 2002 20:48:49 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g172lMU04361; Wed, 6 Feb 2002 20:47:22 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVGQ1>; Wed, 6 Feb 2002 18:47:17 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890ECBE@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan , kevin.zhang@xacct.com Cc: "KC' 'Norseth" , ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu, ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] RE: IPFIX Architecture Date: Wed, 6 Feb 2002 18:47:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF81.C1A6CA60" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AF81.C1A6CA60 Content-Type: text/plain; charset="iso-8859-1" Hello Ganesh/Folks my comments to Ganesh's comments. G: Is the intention to make "capability negotiation" a MUST? IMHO the collector should accept whatever is being exporterd by the exporter. In most of the cases (atleast from a router point of view) the collector is only an intermediate box between the exporter and the final node that interprets the export information. The job of the collector from an information point of view would just be to grab all that the exporter sends. From an export protocol perspective, maybe it would make sense to do some kind of negotiation. But here also with so much of infrastructure existing already for reliability, security etc the question is whether we want to come with a new model or just concentrate on flow export.IMO there is no need for negotiation. G: [Reinaldo] I basically disagree with this (and not because I wrote the capabilities section(;-)). Capability negotiation is very important part of the process. The capability negotiation will negotiate the use existing protocols and methods, not new ones. More specifically "In most of the cases (atleast from a router point of view) the collector is only an intermediate box between the exporter and the final node that interprets the export information. " I disagree. Are you talking about some specific implementation? And saying that he job of the collector from an information point of view would just be to grab all that the exporter sends it's not totally true. Maybe I want to use encryption, maybe I want to use TCP instead of SCTP, maybe I want to export overlapping flows..I do not want to send data that is not going to be useful or cannot be decoded properly. Maybe you have an specific implementaion in mind. G: The underlying transport or other protocol is something which can be configured by the sys. admin., whatever the way he wants: CLI, SNMP, telnet, ... G: [Reinaldo] huh? Again, are you talking about a specific implementation? I can expand this argument and say that everything can be configured by the sys.admin. This is hardly an argument. G: Fail-back is not possible on a router -> too much memory needed. The best we can do is fail-over. G: [Reinaldo] huh? Again, are you talking about some special implemetation? The word impossible I usually reserve for eternal life and not paying taxes (;-) G: " - Receiving IPFIX user messages according to a decoding scheme, checking message integrity, and acknowledging it after it is correctly received or optionally processed and persisted in storage. " I feel this should be taken care of by the lower layers. G: [Reinaldo] yep, I kind of agree with that, except that the collector is the only that can check for error on the IPfix protocol itself. G: If we have the timestamp per flow why is resequencing required G: [Reinaldo] humm...I need to think more about this one... G: If the reliability is guarenteed by the network, is there a necessity for a reliable transport? As we explained in IETF-52, there are scalability concerns with TCP and making this mandartory would exclude the exporters with high volume from being IPFIX compliant. G: [Reinaldo] I think saying that realiability might not be needed if is guaranteed by the network is a fair statement. But as Van Jacobson pointed out in your presentation, saying that TCP has anything to do with high volume, that's not the case. Any protocol that need to provide a similar functionality (congestion control, retransmission, windowing, etc) will have the same problem. He also pointed out some scalability issues in your server due to internal memory copyingy. So my point is that if you have a high volume server over a unrealible network and you use UDP as a transport, the IPfix protocol will need to provide TCP-like functionalities and you will have the *some* of the issues you mentioned. G: Why all these are mandatory for IPFIX layer. I agree the framework should take care of this. But if there is a capability already available why re-invent? G: [Reinaldo] yep,I agree with this. G: The message should have the follwoing - sequence number if the collector wishes to sequence the packets. G: [Reinaldo]. Again, are you talking about a specific implementation? I could use your own argument and say that this can be provided by the lower layers (TCP or SCTP). This is only a requirement for UDP. G: Templates can be exchanged at any time. This may be done as a result of a config change in the exporter or it may be a periodic update. G: [Reinaldo] Agreed, this is in the capability negotiation. G: In short the fundamental aspects of disagreement are: - no template/capabilities/etc... negotiation in IPFIX - no MUST for reliable - no state information (except based on the transport protocol, if connection oriented) - no connection initiated from the collector. G: [Reinaldo] I disagree with the first, I kind of disagree with the second, and agree with the third in terms that the connection can be initiated from both sides. regards, Reinaldo ------_=_NextPart_001_01C1AF81.C1A6CA60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IPFIX Architecture

Hello Ganesh/Folks

my comments to Ganesh's comments.

G:
   Is the intention to make = "capability negotiation" a MUST?
   IMHO  the collector should accept = whatever is
   being exporterd by the exporter. In = most of the cases (atleast
   from a router point of view)  the = collector is only an
   intermediate box between the exporter = and the final node that
   interprets the export information. The = job of the collector
   from an information point of view would = just be to grab all
   that the exporter sends.
   From an export protocol perspective, = maybe it would make sense to
   do some kind of negotiation. But here = also with so much of
   infrastructure existing already for = reliability, security
   etc the question is whether we want to = come with a new model
   or just concentrate on flow export.IMO = there is no need for
   negotiation.
G:
  

[Reinaldo] I basically disagree with this (and not = because I wrote the capabilities section(;-)). Capability negotiation = is very important part of the process. The capability negotiation will = negotiate the use existing protocols and methods, not new = ones.

More specifically "In most of the cases (atleast =
   from a router point of view)  the = collector is only an
   intermediate box between the exporter = and the final node that
   interprets the export information. = "

I disagree. Are you talking about some specific = implementation?

And saying that he job of the collector from an = information point of view would just be to grab all that the exporter = sends it's not totally true. Maybe I want to use encryption, maybe I = want to use TCP instead of SCTP, maybe I want to export overlapping = flows..I do not want to send data that is not going to be useful or = cannot be decoded properly. Maybe you have an specific implementaion in = mind.

G:
The underlying transport or other protocol is = something which can be
configured by the sys. admin., whatever the way he = wants:
CLI, SNMP, telnet, ...
G:

[Reinaldo] huh? Again, are you talking about a = specific implementation? I can expand this argument and say that = everything can be configured by the sys.admin. This is hardly an = argument.

G:
Fail-back is not possible on a router -> too much = memory needed.
The best we can do is fail-over.
G:

[Reinaldo] huh? Again, are you talking about some = special implemetation? The word impossible I usually reserve for = eternal life and not paying taxes (;-)

G:
"  -  Receiving IPFIX user messages = according to a decoding scheme,
  checking message integrity, and acknowledging = it after it is
  correctly received or optionally processed = and persisted in storage. "

I feel this should be taken care of by the lower = layers.
G:

[Reinaldo] yep, I kind of agree with that, except = that the collector is the only that can check for error on the IPfix = protocol itself.

G:
If we have the timestamp per flow why is = resequencing required
G:

[Reinaldo] humm...I need to think more about this = one...

G:
   If the reliability is guarenteed by the = network, is there a necessity
   for a reliable transport? As we = explained in IETF-52, there are
   scalability concerns with TCP and = making this mandartory would
   exclude the exporters with high volume = from being IPFIX compliant.
G:

[Reinaldo] I think saying that realiability might not = be needed if is guaranteed by the network is a fair statement.

But as Van Jacobson pointed out in your presentation, = saying that TCP has anything to do with high volume, that's not the = case. Any protocol that need to provide a similar functionality = (congestion control, retransmission, windowing, etc) will have the same = problem. He also pointed out some scalability issues in your server due = to internal memory copyingy.

So my point is that if you have a high volume server = over a unrealible network and you use UDP as a transport, the IPfix = protocol will need to provide TCP-like functionalities and you will = have the *some* of the issues you mentioned.

G:
   Why all these are mandatory for IPFIX = layer. I agree the framework
   should take care of this. But if there = is a capability already
   available why re-invent?
G:

[Reinaldo] yep,I agree with this.

G:
   The message should have the = follwoing
   - sequence number if the collector = wishes to sequence the packets.
G:

[Reinaldo]. Again, are you talking about a specific = implementation? I could use your own argument and say that this can be = provided by the lower layers (TCP or SCTP). This is only a requirement = for UDP.

G:
   Templates can be exchanged at any time. = This may be done
   as a result of a config change in the = exporter or it may be a
   periodic update.
G:

[Reinaldo] Agreed, this is in the capability = negotiation.

G:
In short the fundamental aspects of disagreement = are:
- no template/capabilities/etc... negotiation in = IPFIX
- no MUST for reliable
- no state information (except based on the = transport protocol, if
connection oriented)
- no connection initiated from the collector.
G:

[Reinaldo] I disagree with the first, I kind of = disagree with the second, and agree with the third in terms that the = connection can be initiated from both sides.

regards,

Reinaldo




------_=_NextPart_001_01C1AF81.C1A6CA60-- -- 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 Feb 6 22:52:53 2002 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 WAA10719 for ; Wed, 6 Feb 2002 22:52:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YfJe-0007Mi-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 21:33:42 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YfJY-0007M4-00; Wed, 06 Feb 2002 21:33:36 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g173WMU06185; Wed, 6 Feb 2002 21:32:23 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVGZK>; Wed, 6 Feb 2002 19:32:18 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890ECD8@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan , kevin.zhang@xacct.com Cc: "KC' 'Norseth" , ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture - timestamps... Date: Wed, 6 Feb 2002 19:32:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF88.0BB1A890" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AF88.0BB1A890 Content-Type: text/plain; charset="iso-8859-1" Hello, About the timestamp issue... Can't we use TCP's timestamp option instead of putting this on the flow header? It's a timestamp and it's already there. yeah, then it would not work for UDP. But then that might another thing for the capability negotiation phase... regards, Reinaldo -----Original Message----- From: Penno, Reinaldo [SC9:T327:EXCH] Sent: Wednesday, February 06, 2002 6:47 PM To: Ganesh Sadasivan; kevin.zhang@xacct.com Cc: KC' 'Norseth; ipfix-data-volunteers@net.doit.wisc.edu; ipfix-arch-volunteers@net.doit.wisc.edu; ipfix-chairs@net.doit.wisc.edu; ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] RE: IPFIX Architecture G: If we have the timestamp per flow why is resequencing required G: [Reinaldo] humm...I need to think more about this one... ------_=_NextPart_001_01C1AF88.0BB1A890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] RE: IPFIX Architecture - timestamps...

Hello,

About the timestamp issue...

Can't we use TCP's timestamp option instead of = putting this on the flow header? It's a timestamp and it's already = there. yeah, then it would not work for UDP. But then that might = another thing for the capability negotiation phase...

regards,

Reinaldo

-----Original Message-----
From: Penno, Reinaldo [SC9:T327:EXCH]
Sent: Wednesday, February 06, 2002 6:47 PM
To: Ganesh Sadasivan; kevin.zhang@xacct.com
Cc: KC' 'Norseth; = ipfix-data-volunteers@net.doit.wisc.edu; = ipfix-arch-volunteers@net.doit.wisc.edu; = ipfix-chairs@net.doit.wisc.edu; ipfix-arch@net.doit.wisc.edu

Subject: [ipfix-arch] RE: IPFIX Architecture


G:
If we have the timestamp per flow why is = resequencing required
G:
[Reinaldo] humm...I need to think more about this = one...

------_=_NextPart_001_01C1AF88.0BB1A890-- -- 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 Feb 6 23:14:27 2002 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 XAA10982 for ; Wed, 6 Feb 2002 23:14:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yfge-00002L-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 21:57:28 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yfgd-00001F-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 21:57:27 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g173ute05872; Wed, 6 Feb 2002 19:56:55 -0800 (PST) Received: from cisco.com (sjc-vpn1-543.cisco.com [10.21.98.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC74173; Wed, 6 Feb 2002 19:57:18 -0800 (PST) Message-ID: <3C61FD18.8853FD4C@cisco.com> Date: Wed, 06 Feb 2002 20:05:44 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: reinaldo_penno@nortelnetworks.com CC: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] RE: IPFIX Architecture Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Reinaldo, See my responses inline starting with [G]. Thanks Ganesh Hello Ganesh/Folks my comments to Ganesh's comments. G: Is the intention to make "capability negotiation" a MUST? IMHO the collector should accept whatever is being exporterd by the exporter. In most of the cases (atleast from a router point of view) the collector is only an intermediate box between the exporter and the final node that interprets the export information. The job of the collector from an information point of view would just be to grab all that the exporter sends. From an export protocol perspective, maybe it would make sense to do some kind of negotiation. But here also with so much of infrastructure existing already for reliability, security etc the question is whether we want to come with a new model or just concentrate on flow export.IMO there is no need for negotiation. G: [Reinaldo] I basically disagree with this (and not because I wrote the capabilities section(;-)). Capability negotiation is very important part of the process. The capability negotiation will negotiate the use existing protocols and methods, not new ones. [G] The existing protocols can be pre-setup in the exporter and collector by the administrator. There is whole suite of actions that needs to be done if one were to negotiate this operation. There is transport (TCP/SCTP/UDP), network layer (V4/V6), maybe lower layers like MPLS, methods of authentication, security (ipsec, TCP MD5), etc. Yes we can build an automated system which detects all these narrows to the least common denominator, sets up all these stacks and performs the export. But I do not see anything extra we can achieve other than the added complexity. It This is not like a data link protocol where one expects to negotiate and see the link up when a cable is plugged. More specifically "In most of the cases (atleast from a router point of view) the collector is only an intermediate box between the exporter and the final node that interprets the export information. " I disagree. Are you talking about some specific implementation? [G] No. A collection device is usually attached to multiple routers (I do not know about probes) There are some things like more aggregation that happens in the collector. This data gets fed into analyzers which perform the final analysis. And saying that he job of the collector from an information point of view would just be to grab all that the exporter sends it's not totally true. Maybe I want to use encryption, maybe I want to use TCP instead of SCTP, maybe I want to export overlapping flows..I do not want to send data that is not going to be useful or cannot be decoded properly. Maybe you have an specific implementaion in mind. [G] You can decide this by configuring the exporter to send only what is required. G: The underlying transport or other protocol is something which can be configured by the sys. admin., whatever the way he wants: CLI, SNMP, telnet, ... G: [Reinaldo] huh? Again, are you talking about a specific implementation? I can expand this argument and say that everything can be configured by the sys.admin. This is hardly an argument. G: Fail-back is not possible on a router -> too much memory needed. The best we can do is fail-over. G: [Reinaldo] huh? Again, are you talking about some special implemetation? The word impossible I usually reserve for eternal life and not paying taxes (;-) [G] I take back my statement. I was not sure of fail-back & fail-over. G: " - Receiving IPFIX user messages according to a decoding scheme, checking message integrity, and acknowledging it after it is correctly received or optionally processed and persisted in storage. " I feel this should be taken care of by the lower layers. G: [Reinaldo] yep, I kind of agree with that, except that the collector is the only that can check for error on the IPfix protocol itself. G: If we have the timestamp per flow why is resequencing required G: [Reinaldo] humm...I need to think more about this one... G: If the reliability is guarenteed by the network, is there a necessity for a reliable transport? As we explained in IETF-52, there are scalability concerns with TCP and making this mandartory would exclude the exporters with high volume from being IPFIX compliant. G: [Reinaldo] I think saying that realiability might not be needed if is guaranteed by the network is a fair statement. But as Van Jacobson pointed out in your presentation, saying that TCP has anything to do with high volume, that's not the case. Any protocol that need to provide a similar functionality (congestion control, retransmission, windowing, etc) will have the same problem. He also pointed out some scalability issues in your server due to internal memory copyingy. [G] Memory copy is only one issue. The memory buffering requirement to take care of even a single retransmission for high bandwidth router spans 10s to 100s of Megabytes. So TCP is out of question. In a network with reliability why add more task to the router processor by putting TCP? So my point is that if you have a high volume server over a unrealible network and you use UDP as a transport, the IPfix protocol will need to provide TCP-like functionalities and you will have the *some* of the issues you mentioned. G: Why all these are mandatory for IPFIX layer. I agree the framework should take care of this. But if there is a capability already available why re-invent? G: [Reinaldo] yep,I agree with this. G: The message should have the follwoing - sequence number if the collector wishes to sequence the packets. G: [Reinaldo]. Again, are you talking about a specific implementation? I could use your own argument and say that this can be provided by the lower layers (TCP or SCTP). This is only a requirement for UDP. [G] This would help to have a consistent implementation across transport protocols. G: Templates can be exchanged at any time. This may be done as a result of a config change in the exporter or it may be a periodic update. G: [Reinaldo] Agreed, this is in the capability negotiation. [G] I did not mean the negotiation part:) The exporter sends collector the template format. G: In short the fundamental aspects of disagreement are: - no template/capabilities/etc... negotiation in IPFIX - no MUST for reliable - no state information (except based on the transport protocol, if connection oriented) - no connection initiated from the collector. G: [Reinaldo] I disagree with the first, I kind of disagree with the second, and agree with the third in terms that the connection can be initiated from both sides. regards, Reinaldo -- 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 Feb 6 23:29:27 2002 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 XAA11121 for ; Wed, 6 Feb 2002 23:29:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yfx1-0000Ru-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 22:14:23 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yfwz-0000RZ-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 22:14:21 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g174Dpe13716; Wed, 6 Feb 2002 20:13:51 -0800 (PST) Received: from cisco.com (sjc-vpn1-543.cisco.com [10.21.98.31]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC74453; Wed, 6 Feb 2002 20:14:14 -0800 (PST) Message-ID: <3C620110.A0F1400C@cisco.com> Date: Wed, 06 Feb 2002 20:22:40 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: reinaldo_penno@nortelnetworks.com CC: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] RE: IPFIX Architecture - timestamps... Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hello, About the timestamp issue... Can't we use TCP's timestamp option instead of putting this on the flow header? It's a timestamp and it's already there. yeah, then it would not work for UDP. But then that might another thing for the capability negotiation phase... =========================================== [G] The timestamp stuck in a flow record when the flow sees the first and last packet. It has nothing to do with the time when it is transported. The timestamp in the flow header however is the time when the flows are packetized. This could be off from the actual time when the packet is sent out by TCP by 10-100msec depending on the implementation. It is an extra 10 bytes per packet for Timestamp option and it is an "option". IMO, this field should be protocol independent and should be part of the flow header. Thanks Ganesh ============================================ regards, Reinaldo -----Original Message----- From: Penno, Reinaldo [SC9:T327:EXCH] Sent: Wednesday, February 06, 2002 6:47 PM To: Ganesh Sadasivan; kevin.zhang@xacct.com Cc: KC' 'Norseth; ipfix-data-volunteers@net.doit.wisc.edu; ipfix-arch-volunteers@net.doit.wisc.edu; ipfix-chairs@net.doit.wisc.edu; ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] RE: IPFIX Architecture G: If we have the timestamp per flow why is resequencing required G: [Reinaldo] humm...I need to think more about this one... -- 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 Feb 6 23:51:50 2002 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 XAA11791 for ; Wed, 6 Feb 2002 23:51:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YgDW-0000rF-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 22:31:26 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YgDO-0000px-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 22:31:23 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g174UbU08316; Wed, 6 Feb 2002 22:30:37 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVHDH>; Wed, 6 Feb 2002 20:30:33 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890ECEF@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan Cc: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] RE: IPFIX Architecture Date: Wed, 6 Feb 2002 20:30:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF90.2E4A0980" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AF90.2E4A0980 Content-Type: text/plain; charset="utf-8" Hello Ganesh, more on our thread... :-----Original Message----- :From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] :Sent: Wednesday, February 06, 2002 8:06 PM :To: Penno, Reinaldo [SC9:T327:EXCH] :Cc: ipfix-arch@net.doit.wisc.edu :Subject: RE: IPFIX Architecture : : :Hi Reinaldo, : See my responses inline starting with [G]. :Thanks :Ganesh : :Hello Ganesh/Folks : :my comments to Ganesh's comments. : :G: : Is the intention to make "capability negotiation" a MUST? : IMHO the collector should accept whatever is : being exporterd by the exporter. In most of the cases (atleast : from a router point of view) the collector is only an : intermediate box between the exporter and the final node that : interprets the export information. The job of the collector : from an information point of view would just be to grab all : that the exporter sends. : From an export protocol perspective, maybe it would make sense to : do some kind of negotiation. But here also with so much of : infrastructure existing already for reliability, security : etc the question is whether we want to come with a new model : or just concentrate on flow export.IMO there is no need for : negotiation. :G: : : :[Reinaldo] I basically disagree with this (and not because I wrote the :capabilities section(;-)). Capability negotiation is very :important part of the process. The capability negotiation will :negotiate :the use existing protocols and methods, not new ones. : :[G] The existing protocols can be pre-setup in the exporter and :collector by the administrator. :There is whole suite of actions that needs to be done if one were to :negotiate this operation. :There is transport (TCP/SCTP/UDP), network layer (V4/V6), maybe lower :layers like :MPLS, methods of authentication, security (ipsec, TCP MD5), etc. Yes we :can build :an automated system which detects all these narrows to the least common :denominator, :sets up all these stacks and performs the export. But I do not see :anything extra we can :achieve other than the added complexity. It This is not like a :data link :protocol where one :expects to negotiate and see the link up when a cable is plugged. [Reinaldo] Well, first BGP also uses capability negotiation and it's not a data link protocol. Second, between us, this administrator argument stuff is not really going to fly. I can also instead of using IKE/PKI, pay somebody to enter all the public-keys in world and retype every time them they are needed. IMO you are not thiking outside the box here. Third, the example I give on the text (LCP), fits this the IPfix model really well since the endpoints have different needs and LCP is a protocol negotiating parameters for the correct operation of another protocol (IPCP). : :More specifically "In most of the cases (atleast : from a router point of view) the collector is only an : intermediate box between the exporter and the final node that : interprets the export information. " : :I disagree. Are you talking about some specific implementation? : :[G] No. A collection device is usually attached to multiple routers (I :do not know about probes) :There are some things like more aggregation that happens in the :collector. :This data gets fed into analyzers which perform the final analysis. Right, even then I still do not want to send useless and undecoded data. I mean, if you assume the high bandwidth scenario that you mention, I also antecipate a high volumen data, so the more focused the data, the least diak space, the better and faster the analysis can de done. Philosofically speaking, capability negotiation gives you the freedom tho choose the system behavior amongst several choices. I do not see from a technical standpoint (and from a protocol evoution) a reason not to have it. Through the capability negotiation you can say that you want for instance LAP, Netflow or CRANE instead of IPix. : :And saying that he job of the collector from an information point of :view would just be to grab all that the exporter sends it's :not totally true. Maybe I want to use encryption, maybe I want to use :TCP instead of SCTP, maybe I want to export overlapping :flows..I do not want to send data that is not going to be useful or :cannot be decoded properly. Maybe you have an specific :implementaion in mind. : :[G] You can decide this by configuring the exporter to send :only what is :required. [Reinaldo] see above : :[G] Memory copy is only one issue. The memory buffering requirement to :take care of :even a single retransmission for high bandwidth router spans :10s to 100s :of Megabytes. :So TCP is out of question. :In a network with reliability why add more task to the router processor :by :putting TCP? : So, based on your statement, should I assume that the only deployment scenario acceptable would be where the collector and exporter are co-located? I mean, you are saying that there is high bandwidth export data and TCP is out of the quesion...Don't you think you are restricting things too much here? : :[Reinaldo]. Again, are you talking about a specific implementation? I :could use your own argument and say that this can be :provided by the lower layers (TCP or SCTP). This is only a requirement :for UDP. : :[G] This would help to have a consistent implementation across :transport :protocols. Consistent for who? For me putting a sequence number there is wasting space and trying to mimic TCP/SCTP behavior. You have to decide if using functions that the lower layers already provide is good or bad. You cannot choose them selectively to fit your needs. : :[G] I did not mean the negotiation part:) The exporter sends collector :the template format. The capabilities negotiated (which include template negotiation) can be renegotiated at any time. cheers, Reinaldo ------_=_NextPart_001_01C1AF90.2E4A0980 Content-Type: text/html; charset="utf-8" RE: IPFIX Architecture

Hello Ganesh,

more on our thread...

:-----Original Message-----
:From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
:Sent: Wednesday, February 06, 2002 8:06 PM
:To: Penno, Reinaldo [SC9:T327:EXCH]
:Cc: ipfix-arch@net.doit.wisc.edu
:Subject: RE: IPFIX Architecture
:
:
:Hi Reinaldo,
:  See my responses inline  starting with [G].
:Thanks
:Ganesh
:
:Hello Ganesh/Folks
:
:my comments to Ganesh's comments.
:
:G:
:   Is the intention to make "capability negotiation" a MUST?
:   IMHO  the collector should accept whatever is
:   being exporterd by the exporter. In most of the cases (atleast
:   from a router point of view)  the collector is only an
:   intermediate box between the exporter and the final node that
:   interprets the export information. The job of the collector
:   from an information point of view would just be to grab all
:   that the exporter sends.
:   From an export protocol perspective, maybe it would make sense to
:   do some kind of negotiation. But here also with so much of
:   infrastructure existing already for reliability, security
:   etc the question is whether we want to come with a new model
:   or just concentrate on flow export.IMO there is no need for
:   negotiation.
:G:
:
:
:[Reinaldo] I basically disagree with this (and not because I wrote the
:capabilities section(;-)). Capability negotiation is very
:important part of the process. The capability negotiation will
:negotiate
:the use existing protocols and methods, not new ones.
:
:[G] The existing protocols can be pre-setup in the exporter and
:collector by the administrator.
:There is whole suite of actions that needs to be done if one were to
:negotiate this operation.
:There is transport (TCP/SCTP/UDP), network layer (V4/V6),  maybe lower
:layers like
:MPLS, methods of authentication, security (ipsec, TCP MD5), etc. Yes we
:can build
:an automated system which detects all these narrows to the least common
:denominator,
:sets up all these stacks and performs the export. But I do not see
:anything extra we can
:achieve other than the added complexity. It This is not like a
:data link
:protocol where one
:expects to negotiate and see the link up when a cable is plugged.

[Reinaldo] Well, first BGP also uses capability negotiation and it's not a data link protocol.

Second, between us, this administrator argument stuff is not really going to fly. I can also instead of using IKE/PKI, pay somebody to enter all the public-keys in world and retype every time them they are needed. IMO you are not thiking outside the box here.

Third, the example I give on the text (LCP), fits this the IPfix model really well since the endpoints have different needs and LCP is a protocol negotiating parameters for the correct operation of another protocol (IPCP).



:
:More specifically "In most of the cases (atleast
:   from a router point of view)  the collector is only an
:   intermediate box between the exporter and the final node that
:   interprets the export information. "
:
:I disagree. Are you talking about some specific implementation?
:
:[G] No. A collection device is usually attached to multiple routers (I
:do not know about probes)
:There are some things like more aggregation that happens in the
:collector.
:This data gets fed  into analyzers which perform the final analysis.

Right, even then I still do not want to send useless and undecoded data. I mean, if you assume the high bandwidth scenario that you mention, I also antecipate a high volumen data, so the more focused the data, the least diak space, the better and faster the analysis can de done.

Philosofically speaking, capability negotiation gives you the freedom tho choose the system behavior amongst several choices.   I do not see from a technical standpoint (and from a protocol evoution) a reason not to have it. Through the capability negotiation you can say that you want for instance LAP, Netflow or CRANE instead of IPix.

:
:And saying that he job of the collector from an information point of
:view would just be to grab all that the exporter sends it's
:not totally true. Maybe I want to use encryption, maybe I want to use
:TCP instead of SCTP, maybe I want to export overlapping
:flows..I do not want to send data that is not going to be useful or
:cannot be decoded properly. Maybe you have an specific
:implementaion in mind.
:
:[G] You can decide this by configuring the exporter to send
:only what is
:required.

[Reinaldo] see above
:
:[G] Memory copy is only one issue. The memory buffering requirement to
:take care of
:even a single retransmission for high bandwidth router spans
:10s to 100s
:of Megabytes.
:So TCP is out of question.
:In a network with reliability why add more task to the router processor
:by
:putting TCP?
:


So, based on your statement, should I assume that the only deployment scenario acceptable would be where the collector and exporter are co-located? I mean, you are saying that there is high bandwidth export data and TCP is out of the quesion...Don't you think you are restricting things too much here?

:
:[Reinaldo]. Again, are you talking about a specific implementation? I
:could use your own argument and say that this can be
:provided by the lower layers (TCP or SCTP). This is only a requirement
:for UDP.
:
:[G] This would help to have a consistent implementation across
:transport
:protocols.

Consistent for who? For me putting a sequence number there is wasting space and trying to mimic TCP/SCTP behavior. You have to decide if using functions that the lower layers already provide is good or bad. You cannot choose them selectively to fit your needs.

:
:[G] I did not mean the negotiation part:) The exporter sends collector
:the template format.

The capabilities negotiated (which include template negotiation) can be  renegotiated at any time.

cheers,

Reinaldo

------_=_NextPart_001_01C1AF90.2E4A0980-- -- 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 Feb 7 00:50:41 2002 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 AAA12437 for ; Thu, 7 Feb 2002 00:50:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YhAg-00021z-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 23:32:34 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YhAc-00021H-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 23:32:30 -0600 Received: from postal.cisco.com (postal.cisco.com [171.71.160.26]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g175Vvv11144; Wed, 6 Feb 2002 21:31:58 -0800 (PST) Received: from WILLW2K (rtp-vpn2-58.cisco.com [10.82.240.58]) by postal.cisco.com (Mirapoint) with SMTP id AAJ76066; Wed, 6 Feb 2002 21:32:07 -0800 (PST) Reply-To: From: "Will Eatherton" To: "Reinaldo Penno" , "Ganesh Sadasivan" Cc: Subject: RE: [ipfix-arch] RE: IPFIX Architecture Date: Wed, 6 Feb 2002 21:30:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C1AF55.815B9BB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4F973E944951D311B6660008C7917CF00890ECEF@zsc4c008.us.nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C1AF55.815B9BB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: IPFIX ArchitectureReinaldo, The notation for who is speaking in this thread is making me dizzy, but = I would like to state in a different way what Ganesh is saying on the = main topic of this thread. For the application of router export to a = collector we are saying that allowing UDP without required capability = negotiation (as an option) is important. Also I don't understand the desire in this thread to dance tip-toe = around the fact that there is already a widely deployed export protocol = used in the application of routers export and we (in this case Ganesh) = are giving you the feedback based on experience one vendor has gained = from experience with that protocol. We are seeing capability = negotiation as complex, not a requirement, and are suggesting it should = not be a MUST for IPFIX unless it isnt the goal of IPFIX to be = implemented on routers (is it a probe spec only ?). Last time I read the = intro to IETF there was weight put into using experience gained from = widely deployed protocols as templates for specifications. Will -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On = Behalf Of Reinaldo Penno Sent: Wednesday, February 06, 2002 8:31 PM To: Ganesh Sadasivan Cc: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] RE: IPFIX Architecture Hello Ganesh,=20 more on our thread...=20 :-----Original Message-----=20 :From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]=20 :Sent: Wednesday, February 06, 2002 8:06 PM=20 :To: Penno, Reinaldo [SC9:T327:EXCH]=20 :Cc: ipfix-arch@net.doit.wisc.edu=20 :Subject: RE: IPFIX Architecture=20 :=20 :=20 :Hi Reinaldo,=20 : See my responses inline starting with [G].=20 :Thanks=20 :Ganesh=20 :=20 :Hello Ganesh/Folks=20 :=20 :my comments to Ganesh's comments.=20 :=20 :G:=20 : Is the intention to make "capability negotiation" a MUST?=20 : IMHO the collector should accept whatever is=20 : being exporterd by the exporter. In most of the cases (atleast=20 : from a router point of view) the collector is only an=20 : intermediate box between the exporter and the final node that=20 : interprets the export information. The job of the collector=20 : from an information point of view would just be to grab all=20 : that the exporter sends.=20 : From an export protocol perspective, maybe it would make sense to=20 : do some kind of negotiation. But here also with so much of=20 : infrastructure existing already for reliability, security=20 : etc the question is whether we want to come with a new model=20 : or just concentrate on flow export.IMO there is no need for=20 : negotiation.=20 :G:=20 :=20 :=20 :[Reinaldo] I basically disagree with this (and not because I wrote = the=20 :capabilities section(;-)). Capability negotiation is very=20 :important part of the process. The capability negotiation will=20 :negotiate=20 :the use existing protocols and methods, not new ones.=20 :=20 :[G] The existing protocols can be pre-setup in the exporter and=20 :collector by the administrator.=20 :There is whole suite of actions that needs to be done if one were to=20 :negotiate this operation.=20 :There is transport (TCP/SCTP/UDP), network layer (V4/V6), maybe = lower=20 :layers like=20 :MPLS, methods of authentication, security (ipsec, TCP MD5), etc. Yes = we=20 :can build=20 :an automated system which detects all these narrows to the least = common=20 :denominator,=20 :sets up all these stacks and performs the export. But I do not see=20 :anything extra we can=20 :achieve other than the added complexity. It This is not like a=20 :data link=20 :protocol where one=20 :expects to negotiate and see the link up when a cable is plugged.=20 [Reinaldo] Well, first BGP also uses capability negotiation and it's = not a data link protocol.=20 Second, between us, this administrator argument stuff is not really = going to fly. I can also instead of using IKE/PKI, pay somebody to enter = all the public-keys in world and retype every time them they are needed. = IMO you are not thiking outside the box here. Third, the example I give on the text (LCP), fits this the IPfix model = really well since the endpoints have different needs and LCP is a = protocol negotiating parameters for the correct operation of another = protocol (IPCP). :=20 :More specifically "In most of the cases (atleast=20 : from a router point of view) the collector is only an=20 : intermediate box between the exporter and the final node that=20 : interprets the export information. "=20 :=20 :I disagree. Are you talking about some specific implementation?=20 :=20 :[G] No. A collection device is usually attached to multiple routers = (I=20 :do not know about probes)=20 :There are some things like more aggregation that happens in the=20 :collector.=20 :This data gets fed into analyzers which perform the final analysis.=20 Right, even then I still do not want to send useless and undecoded = data. I mean, if you assume the high bandwidth scenario that you = mention, I also antecipate a high volumen data, so the more focused the = data, the least diak space, the better and faster the analysis can de = done. Philosofically speaking, capability negotiation gives you the freedom = tho choose the system behavior amongst several choices. I do not see = from a technical standpoint (and from a protocol evoution) a reason not = to have it. Through the capability negotiation you can say that you want = for instance LAP, Netflow or CRANE instead of IPix. :=20 :And saying that he job of the collector from an information point of=20 :view would just be to grab all that the exporter sends it's=20 :not totally true. Maybe I want to use encryption, maybe I want to use = :TCP instead of SCTP, maybe I want to export overlapping=20 :flows..I do not want to send data that is not going to be useful or=20 :cannot be decoded properly. Maybe you have an specific=20 :implementaion in mind.=20 :=20 :[G] You can decide this by configuring the exporter to send=20 :only what is=20 :required.=20 [Reinaldo] see above=20 :=20 :[G] Memory copy is only one issue. The memory buffering requirement = to=20 :take care of=20 :even a single retransmission for high bandwidth router spans=20 :10s to 100s=20 :of Megabytes.=20 :So TCP is out of question.=20 :In a network with reliability why add more task to the router = processor=20 :by=20 :putting TCP?=20 :=20 So, based on your statement, should I assume that the only deployment = scenario acceptable would be where the collector and exporter are = co-located? I mean, you are saying that there is high bandwidth export = data and TCP is out of the quesion...Don't you think you are restricting = things too much here? :=20 :[Reinaldo]. Again, are you talking about a specific implementation? I = :could use your own argument and say that this can be=20 :provided by the lower layers (TCP or SCTP). This is only a = requirement=20 :for UDP.=20 :=20 :[G] This would help to have a consistent implementation across=20 :transport=20 :protocols.=20 Consistent for who? For me putting a sequence number there is wasting = space and trying to mimic TCP/SCTP behavior. You have to decide if using = functions that the lower layers already provide is good or bad. You = cannot choose them selectively to fit your needs. :=20 :[G] I did not mean the negotiation part:) The exporter sends = collector=20 :the template format.=20 The capabilities negotiated (which include template negotiation) can = be renegotiated at any time.=20 cheers,=20 Reinaldo=20 ------=_NextPart_000_001B_01C1AF55.815B9BB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: IPFIX Architecture
Reinaldo,
 
The=20 notation for who is speaking in this thread is making me dizzy, but I = would like=20 to state in a different way what Ganesh is saying on the=20 main
topic=20 of this thread.  For the application of router export to a = collector we are=20 saying that allowing UDP without required capability negotiation (as an=20 option) is important.
 
Also I=20 don't understand the desire in this thread to dance tip-toe around the = fact that=20 there is already a widely deployed export protocol used in=20 the application of routers export and we (in this case Ganesh) = are=20 giving you the feedback based on experience one vendor has gained = from=20 experience with that protocol.  We are seeing capability=20 negotiation as complex, not a requirement, and are suggesting it = should not=20 be a MUST for IPFIX unless it isnt the goal of IPFIX to be = implemented on=20 routers (is it a probe spec only ?). Last time I read the intro to = IETF=20 there was weight put into using experience gained from = widely deployed=20 protocols as templates for specifications.
 
Will
 
 
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo=20 Penno
Sent: Wednesday, February 06, 2002 8:31 = PM
To:=20 Ganesh Sadasivan
Cc: = ipfix-arch@net.doit.wisc.edu
Subject:=20 [ipfix-arch] RE: IPFIX Architecture

Hello Ganesh,

more on our thread...

:-----Original Message-----
:From:=20 Ganesh Sadasivan [mailto:gsadasiv@cisco.com] =
:Sent: Wednesday, February 06, 2002 8:06 PM =
:To: Penno, Reinaldo [SC9:T327:EXCH]
:Cc:=20 ipfix-arch@net.doit.wisc.edu
:Subject: RE: = IPFIX=20 Architecture
:
:=20
:Hi Reinaldo,
:  See = my=20 responses inline  starting with [G].
:Thanks
:Ganesh
:
:Hello Ganesh/Folks =
:
:my comments to Ganesh's = comments.=20
:
:G:
:   Is the intention to make "capability = negotiation" a=20 MUST?
:   IMHO  the collector = should=20 accept whatever is
:   being = exporterd by=20 the exporter. In most of the cases (atleast
:   from a router point of view)  the = collector is only=20 an
:   intermediate box between = the exporter=20 and the final node that
:   = interprets the=20 export information. The job of the collector
:   from an information point of view would just be = to grab=20 all
:   that the exporter = sends.=20
:   From an export protocol perspective, = maybe it=20 would make sense to
:   do some = kind of=20 negotiation. But here also with so much of
:   infrastructure existing already for = reliability,=20 security
:   etc the question is = whether we=20 want to come with a new model
:   = or just=20 concentrate on flow export.IMO there is no need for
:   negotiation.
:G:
:
:
:[Reinaldo] I=20 basically disagree with this (and not because I wrote the =
:capabilities section(;-)). Capability negotiation is = very=20
:important part of the process. The capability = negotiation=20 will
:negotiate
:the use=20 existing protocols and methods, not new ones.
:=20
:[G] The existing protocols can be pre-setup in the = exporter=20 and
:collector by the administrator. =
:There is whole suite of actions that needs to be done if one = were=20 to
:negotiate this operation. =
:There is transport (TCP/SCTP/UDP), network layer = (V4/V6),  maybe=20 lower
:layers like
:MPLS,=20 methods of authentication, security (ipsec, TCP MD5), etc. Yes = we=20
:can build
:an automated = system which=20 detects all these narrows to the least common
:denominator,
:sets up all these = stacks and=20 performs the export. But I do not see
:anything extra=20 we can
:achieve other than the added = complexity. It=20 This is not like a
:data link =
:protocol where one
:expects to = negotiate and=20 see the link up when a cable is plugged.

[Reinaldo] Well, first BGP also uses capability = negotiation=20 and it's not a data link protocol.

Second, between us, this administrator argument = stuff is not=20 really going to fly. I can also instead of using IKE/PKI, pay somebody = to=20 enter all the public-keys in world and retype every time them they are = needed.=20 IMO you are not thiking outside the box here.

Third, the example I give on the text (LCP), fits = this the=20 IPfix model really well since the endpoints have different needs and = LCP is a=20 protocol negotiating parameters for the correct operation of another = protocol=20 (IPCP).



:
:More specifically "In = most of the=20 cases (atleast
:   from a router = point of=20 view)  the collector is only an
:  =20 intermediate box between the exporter and the final node that =
:   interprets the export information. " =
:
:I disagree. Are you talking = about some=20 specific implementation?
:
:[G] No. A collection device is usually attached to multiple = routers=20 (I
:do not know about probes) =
:There are some things like more aggregation that happens in = the=20
:collector.
:This data = gets fed =20 into analyzers which perform the final analysis.

Right, even then I still do not want to send useless = and=20 undecoded data. I mean, if you assume the high bandwidth scenario that = you=20 mention, I also antecipate a high volumen data, so the more focused = the data,=20 the least diak space, the better and faster the analysis can de=20 done.

Philosofically speaking, capability negotiation = gives you the=20 freedom tho choose the system behavior amongst several = choices.   I=20 do not see from a technical standpoint (and from a protocol evoution) = a reason=20 not to have it. Through the capability negotiation you can say that = you want=20 for instance LAP, Netflow or CRANE instead of IPix.

:
:And saying that he job = of the=20 collector from an information point of
:view = would=20 just be to grab all that the exporter sends it's
:not=20 totally true. Maybe I want to use encryption, maybe I want to = use=20
:TCP instead of SCTP, maybe I want to export=20 overlapping
:flows..I do not want to send = data that is=20 not going to be useful or
:cannot be decoded = properly.=20 Maybe you have an specific
:implementaion in = mind.
:
:[G] You = can decide=20 this by configuring the exporter to send
:only what=20 is
:required.

[Reinaldo] see above
:=20
:[G] Memory copy is only one issue. The memory = buffering=20 requirement to
:take care of =
:even a single retransmission for high bandwidth router spans =
:10s to 100s
:of=20 Megabytes.
:So TCP is out of = question.=20
:In a network with reliability why add more task to = the=20 router processor
:by
:putting=20 TCP?
:


So, based on your statement, should I assume that = the only=20 deployment scenario acceptable would be where the collector and = exporter are=20 co-located? I mean, you are saying that there is high bandwidth export = data=20 and TCP is out of the quesion...Don't you think you are restricting = things too=20 much here?

:
:[Reinaldo]. Again, are = you talking=20 about a specific implementation? I
:could = use your own=20 argument and say that this can be
:provided = by the=20 lower layers (TCP or SCTP). This is only a requirement =
:for UDP.
:
:[G] This=20 would help to have a consistent implementation across
:transport
:protocols.

Consistent for who? For me putting a sequence number = there is=20 wasting space and trying to mimic TCP/SCTP behavior. You have to = decide if=20 using functions that the lower layers already provide is good or bad. = You=20 cannot choose them selectively to fit your needs.

:
:[G] I did not mean the = negotiation=20 part:) The exporter sends collector
:the = template=20 format.

The capabilities negotiated (which include template=20 negotiation) can be  renegotiated at any time.

cheers,

Reinaldo

------=_NextPart_000_001B_01C1AF55.815B9BB0-- -- 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 Feb 7 01:19:14 2002 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 BAA12806 for ; Thu, 7 Feb 2002 01:19:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yhf8-0002eJ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 00:04:02 -0600 Received: from c001-h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16Yhf4-0002de-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 00:03:58 -0600 Received: (cpmta 8178 invoked from network); 6 Feb 2002 22:03:26 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.115) with SMTP; 6 Feb 2002 22:03:26 -0800 X-Sent: 7 Feb 2002 06:03:26 GMT Message-ID: <010801c1af9d$7e94ece0$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: , "Reinaldo Penno" , "Ganesh Sadasivan" Cc: References: Subject: Re: [ipfix-arch] RE: IPFIX Architecture Date: Wed, 6 Feb 2002 23:05:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit RE: IPFIX ArchitectureFolks, |----- Original Message ----- |From: Will Eatherton |To: Reinaldo Penno ; Ganesh Sadasivan |Cc: ipfix-arch@net.doit.wisc.edu |Sent: Wednesday, February 06, 2002 10:30 PM |Subject: RE: [ipfix-arch] RE: IPFIX Architecture | | |Reinaldo, | |The notation for who is speaking in this thread is making me dizzy, but I would like to state in a different way what Ganesh is |saying on the main |topic of this thread. For the application of router export to a collector we are saying that allowing UDP without required |capability negotiation (as an option) is important. | |Also I don't understand the desire in this thread to dance tip-toe around the fact that there is already a widely deployed |export|protocol used in the application of routers export and we (in this case Ganesh) are giving you the feedback based on |experience one vendor has gained from experience with that protocol. We are seeing capability negotiation as complex, not a |requirement, and are suggesting it should not be a MUST for IPFIX unless it isnt the goal of IPFIX to be implemented on |routers (is it a probe spec only ?). Last time I read the intro to IETF there was weight put into using experience gained from |widely deployed protocols as templates for specifications. We definitly want to build on past experience. A lot of us have implemented NetFlow as well as other protocols. Each of us can tell success stories as well as horror stories of trying to implement them. We all can see places to improve - Templates, protocols, error management, whatever. Our goal is an open standard, not a propritary standard. As we build the IPFIX standard, we want it to be a standard that everyone can say is the best and can say it is everyones. I want the results of this WG to be specifications so well written that we don't have to worry that we have reverse-engineered every aspect, because every aspect of the standard is clear-cut. If we have a questionable topic, it needs to be clarified. If there is a question of scope, I would love to see it addressed. K.C. |Will | | |-----Original Message----- |From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno |Sent: Wednesday, February 06, 2002 8:31 PM |To: Ganesh Sadasivan |Cc: ipfix-arch@net.doit.wisc.edu |Subject: [ipfix-arch] RE: IPFIX Architecture | Hello Ganesh, more on our thread... :-----Original Message----- :From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] :Sent: Wednesday, February 06, 2002 8:06 PM :To: Penno, Reinaldo [SC9:T327:EXCH] :Cc: ipfix-arch@net.doit.wisc.edu :Subject: RE: IPFIX Architecture : : :Hi Reinaldo, : See my responses inline starting with [G]. :Thanks :Ganesh : :Hello Ganesh/Folks : :my comments to Ganesh's comments. : :G: : Is the intention to make "capability negotiation" a MUST? : IMHO the collector should accept whatever is : being exporterd by the exporter. In most of the cases (atleast : from a router point of view) the collector is only an : intermediate box between the exporter and the final node that : interprets the export information. The job of the collector : from an information point of view would just be to grab all : that the exporter sends. : From an export protocol perspective, maybe it would make sense to : do some kind of negotiation. But here also with so much of : infrastructure existing already for reliability, security : etc the question is whether we want to come with a new model : or just concentrate on flow export.IMO there is no need for : negotiation. :G: : : :[Reinaldo] I basically disagree with this (and not because I wrote the :capabilities section(;-)). Capability negotiation is very :important part of the process. The capability negotiation will :negotiate :the use existing protocols and methods, not new ones. : :[G] The existing protocols can be pre-setup in the exporter and :collector by the administrator. :There is whole suite of actions that needs to be done if one were to :negotiate this operation. :There is transport (TCP/SCTP/UDP), network layer (V4/V6), maybe lower :layers like :MPLS, methods of authentication, security (ipsec, TCP MD5), etc. Yes we :can build :an automated system which detects all these narrows to the least common :denominator, :sets up all these stacks and performs the export. But I do not see :anything extra we can :achieve other than the added complexity. It This is not like a :data link :protocol where one :expects to negotiate and see the link up when a cable is plugged. [Reinaldo] Well, first BGP also uses capability negotiation and it's not a data link protocol. Second, between us, this administrator argument stuff is not really going to fly. I can also instead of using IKE/PKI, pay somebody to enter all the public-keys in world and retype every time them they are needed. IMO you are not thiking outside the box here. Third, the example I give on the text (LCP), fits this the IPfix model really well since the endpoints have different needs and LCP is a protocol negotiating parameters for the correct operation of another protocol (IPCP). : :More specifically "In most of the cases (atleast : from a router point of view) the collector is only an : intermediate box between the exporter and the final node that : interprets the export information. " : :I disagree. Are you talking about some specific implementation? : :[G] No. A collection device is usually attached to multiple routers (I :do not know about probes) :There are some things like more aggregation that happens in the :collector. :This data gets fed into analyzers which perform the final analysis. Right, even then I still do not want to send useless and undecoded data. I mean, if you assume the high bandwidth scenario that you mention, I also antecipate a high volumen data, so the more focused the data, the least diak space, the better and faster the analysis can de done. Philosofically speaking, capability negotiation gives you the freedom tho choose the system behavior amongst several choices. I do not see from a technical standpoint (and from a protocol evoution) a reason not to have it. Through the capability negotiation you can say that you want for instance LAP, Netflow or CRANE instead of IPix. : :And saying that he job of the collector from an information point of :view would just be to grab all that the exporter sends it's :not totally true. Maybe I want to use encryption, maybe I want to use :TCP instead of SCTP, maybe I want to export overlapping :flows..I do not want to send data that is not going to be useful or :cannot be decoded properly. Maybe you have an specific :implementaion in mind. : :[G] You can decide this by configuring the exporter to send :only what is :required. [Reinaldo] see above : :[G] Memory copy is only one issue. The memory buffering requirement to :take care of :even a single retransmission for high bandwidth router spans :10s to 100s :of Megabytes. :So TCP is out of question. :In a network with reliability why add more task to the router processor :by :putting TCP? : So, based on your statement, should I assume that the only deployment scenario acceptable would be where the collector and exporter are co-located? I mean, you are saying that there is high bandwidth export data and TCP is out of the quesion...Don't you think you are restricting things too much here? : :[Reinaldo]. Again, are you talking about a specific implementation? I :could use your own argument and say that this can be :provided by the lower layers (TCP or SCTP). This is only a requirement :for UDP. : :[G] This would help to have a consistent implementation across :transport :protocols. Consistent for who? For me putting a sequence number there is wasting space and trying to mimic TCP/SCTP behavior. You have to decide if using functions that the lower layers already provide is good or bad. You cannot choose them selectively to fit your needs. : :[G] I did not mean the negotiation part:) The exporter sends collector :the template format. The capabilities negotiated (which include template negotiation) can be renegotiated at any time. cheers, Reinaldo -- 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 Feb 7 01:40:39 2002 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 AAA12436 for ; Thu, 7 Feb 2002 00:50:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YhAl-000226-00 for ipfix-list@mil.doit.wisc.edu; Wed, 06 Feb 2002 23:32:39 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YhAi-00021p-00 for ipfix-arch@net.doit.wisc.edu; Wed, 06 Feb 2002 23:32:37 -0600 Received: from postal.cisco.com (postal.cisco.com [171.71.160.26]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g175W6v11198; Wed, 6 Feb 2002 21:32:06 -0800 (PST) Received: from WILLW2K (rtp-vpn2-58.cisco.com [10.82.240.58]) by postal.cisco.com (Mirapoint) with SMTP id AAJ76067; Wed, 6 Feb 2002 21:32:15 -0800 (PST) Reply-To: From: "Will Eatherton" To: "Reinaldo Penno" , "Ganesh Sadasivan" Cc: Subject: RE: [ipfix-arch] RE: IPFIX Architecture Date: Wed, 6 Feb 2002 21:30:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C1AF55.8643B630" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4F973E944951D311B6660008C7917CF00890ECEF@zsc4c008.us.nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C1AF55.8643B630 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: IPFIX ArchitectureReinaldo, The notation for who is speaking in this thread is making me dizzy, but = I would like to state in a different way what Ganesh is saying on the = main topic of this thread. For the application of router export to a = collector we are saying that allowing UDP without required capability = negotiation (as an option) is important. Also I don't understand the desire in this thread to dance tip-toe = around the fact that there is already a widely deployed export protocol = used in the application of routers export and we (in this case Ganesh) = are giving you the feedback based on experience one vendor has gained = from experience with that protocol. We are seeing capability = negotiation as complex, not a requirement, and are suggesting it should = not be a MUST for IPFIX unless it isnt the goal of IPFIX to be = implemented on routers (is it a probe spec only ?). Last time I read the = intro to IETF there was weight put into using experience gained from = widely deployed protocols as templates for specifications. Will -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On = Behalf Of Reinaldo Penno Sent: Wednesday, February 06, 2002 8:31 PM To: Ganesh Sadasivan Cc: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] RE: IPFIX Architecture Hello Ganesh,=20 more on our thread...=20 :-----Original Message-----=20 :From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]=20 :Sent: Wednesday, February 06, 2002 8:06 PM=20 :To: Penno, Reinaldo [SC9:T327:EXCH]=20 :Cc: ipfix-arch@net.doit.wisc.edu=20 :Subject: RE: IPFIX Architecture=20 :=20 :=20 :Hi Reinaldo,=20 : See my responses inline starting with [G].=20 :Thanks=20 :Ganesh=20 :=20 :Hello Ganesh/Folks=20 :=20 :my comments to Ganesh's comments.=20 :=20 :G:=20 : Is the intention to make "capability negotiation" a MUST?=20 : IMHO the collector should accept whatever is=20 : being exporterd by the exporter. In most of the cases (atleast=20 : from a router point of view) the collector is only an=20 : intermediate box between the exporter and the final node that=20 : interprets the export information. The job of the collector=20 : from an information point of view would just be to grab all=20 : that the exporter sends.=20 : From an export protocol perspective, maybe it would make sense to=20 : do some kind of negotiation. But here also with so much of=20 : infrastructure existing already for reliability, security=20 : etc the question is whether we want to come with a new model=20 : or just concentrate on flow export.IMO there is no need for=20 : negotiation.=20 :G:=20 :=20 :=20 :[Reinaldo] I basically disagree with this (and not because I wrote = the=20 :capabilities section(;-)). Capability negotiation is very=20 :important part of the process. The capability negotiation will=20 :negotiate=20 :the use existing protocols and methods, not new ones.=20 :=20 :[G] The existing protocols can be pre-setup in the exporter and=20 :collector by the administrator.=20 :There is whole suite of actions that needs to be done if one were to=20 :negotiate this operation.=20 :There is transport (TCP/SCTP/UDP), network layer (V4/V6), maybe = lower=20 :layers like=20 :MPLS, methods of authentication, security (ipsec, TCP MD5), etc. Yes = we=20 :can build=20 :an automated system which detects all these narrows to the least = common=20 :denominator,=20 :sets up all these stacks and performs the export. But I do not see=20 :anything extra we can=20 :achieve other than the added complexity. It This is not like a=20 :data link=20 :protocol where one=20 :expects to negotiate and see the link up when a cable is plugged.=20 [Reinaldo] Well, first BGP also uses capability negotiation and it's = not a data link protocol.=20 Second, between us, this administrator argument stuff is not really = going to fly. I can also instead of using IKE/PKI, pay somebody to enter = all the public-keys in world and retype every time them they are needed. = IMO you are not thiking outside the box here. Third, the example I give on the text (LCP), fits this the IPfix model = really well since the endpoints have different needs and LCP is a = protocol negotiating parameters for the correct operation of another = protocol (IPCP). :=20 :More specifically "In most of the cases (atleast=20 : from a router point of view) the collector is only an=20 : intermediate box between the exporter and the final node that=20 : interprets the export information. "=20 :=20 :I disagree. Are you talking about some specific implementation?=20 :=20 :[G] No. A collection device is usually attached to multiple routers = (I=20 :do not know about probes)=20 :There are some things like more aggregation that happens in the=20 :collector.=20 :This data gets fed into analyzers which perform the final analysis.=20 Right, even then I still do not want to send useless and undecoded = data. I mean, if you assume the high bandwidth scenario that you = mention, I also antecipate a high volumen data, so the more focused the = data, the least diak space, the better and faster the analysis can de = done. Philosofically speaking, capability negotiation gives you the freedom = tho choose the system behavior amongst several choices. I do not see = from a technical standpoint (and from a protocol evoution) a reason not = to have it. Through the capability negotiation you can say that you want = for instance LAP, Netflow or CRANE instead of IPix. :=20 :And saying that he job of the collector from an information point of=20 :view would just be to grab all that the exporter sends it's=20 :not totally true. Maybe I want to use encryption, maybe I want to use = :TCP instead of SCTP, maybe I want to export overlapping=20 :flows..I do not want to send data that is not going to be useful or=20 :cannot be decoded properly. Maybe you have an specific=20 :implementaion in mind.=20 :=20 :[G] You can decide this by configuring the exporter to send=20 :only what is=20 :required.=20 [Reinaldo] see above=20 :=20 :[G] Memory copy is only one issue. The memory buffering requirement = to=20 :take care of=20 :even a single retransmission for high bandwidth router spans=20 :10s to 100s=20 :of Megabytes.=20 :So TCP is out of question.=20 :In a network with reliability why add more task to the router = processor=20 :by=20 :putting TCP?=20 :=20 So, based on your statement, should I assume that the only deployment = scenario acceptable would be where the collector and exporter are = co-located? I mean, you are saying that there is high bandwidth export = data and TCP is out of the quesion...Don't you think you are restricting = things too much here? :=20 :[Reinaldo]. Again, are you talking about a specific implementation? I = :could use your own argument and say that this can be=20 :provided by the lower layers (TCP or SCTP). This is only a = requirement=20 :for UDP.=20 :=20 :[G] This would help to have a consistent implementation across=20 :transport=20 :protocols.=20 Consistent for who? For me putting a sequence number there is wasting = space and trying to mimic TCP/SCTP behavior. You have to decide if using = functions that the lower layers already provide is good or bad. You = cannot choose them selectively to fit your needs. :=20 :[G] I did not mean the negotiation part:) The exporter sends = collector=20 :the template format.=20 The capabilities negotiated (which include template negotiation) can = be renegotiated at any time.=20 cheers,=20 Reinaldo=20 ------=_NextPart_000_001E_01C1AF55.8643B630 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: IPFIX Architecture
Reinaldo,
 
The=20 notation for who is speaking in this thread is making me dizzy, but I = would like=20 to state in a different way what Ganesh is saying on the=20 main
topic=20 of this thread.  For the application of router export to a = collector we are=20 saying that allowing UDP without required capability negotiation (as an=20 option) is important.
 
Also I=20 don't understand the desire in this thread to dance tip-toe around the = fact that=20 there is already a widely deployed export protocol used in=20 the application of routers export and we (in this case Ganesh) = are=20 giving you the feedback based on experience one vendor has gained = from=20 experience with that protocol.  We are seeing capability=20 negotiation as complex, not a requirement, and are suggesting it = should not=20 be a MUST for IPFIX unless it isnt the goal of IPFIX to be = implemented on=20 routers (is it a probe spec only ?). Last time I read the intro to = IETF=20 there was weight put into using experience gained from = widely deployed=20 protocols as templates for specifications.
 
Will
 
 
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo=20 Penno
Sent: Wednesday, February 06, 2002 8:31 = PM
To:=20 Ganesh Sadasivan
Cc: = ipfix-arch@net.doit.wisc.edu
Subject:=20 [ipfix-arch] RE: IPFIX Architecture

Hello Ganesh,

more on our thread...

:-----Original Message-----
:From:=20 Ganesh Sadasivan [mailto:gsadasiv@cisco.com] =
:Sent: Wednesday, February 06, 2002 8:06 PM =
:To: Penno, Reinaldo [SC9:T327:EXCH]
:Cc:=20 ipfix-arch@net.doit.wisc.edu
:Subject: RE: = IPFIX=20 Architecture
:
:=20
:Hi Reinaldo,
:  See = my=20 responses inline  starting with [G].
:Thanks
:Ganesh
:
:Hello Ganesh/Folks =
:
:my comments to Ganesh's = comments.=20
:
:G:
:   Is the intention to make "capability = negotiation" a=20 MUST?
:   IMHO  the collector = should=20 accept whatever is
:   being = exporterd by=20 the exporter. In most of the cases (atleast
:   from a router point of view)  the = collector is only=20 an
:   intermediate box between = the exporter=20 and the final node that
:   = interprets the=20 export information. The job of the collector
:   from an information point of view would just be = to grab=20 all
:   that the exporter = sends.=20
:   From an export protocol perspective, = maybe it=20 would make sense to
:   do some = kind of=20 negotiation. But here also with so much of
:   infrastructure existing already for = reliability,=20 security
:   etc the question is = whether we=20 want to come with a new model
:   = or just=20 concentrate on flow export.IMO there is no need for
:   negotiation.
:G:
:
:
:[Reinaldo] I=20 basically disagree with this (and not because I wrote the =
:capabilities section(;-)). Capability negotiation is = very=20
:important part of the process. The capability = negotiation=20 will
:negotiate
:the use=20 existing protocols and methods, not new ones.
:=20
:[G] The existing protocols can be pre-setup in the = exporter=20 and
:collector by the administrator. =
:There is whole suite of actions that needs to be done if one = were=20 to
:negotiate this operation. =
:There is transport (TCP/SCTP/UDP), network layer = (V4/V6),  maybe=20 lower
:layers like
:MPLS,=20 methods of authentication, security (ipsec, TCP MD5), etc. Yes = we=20
:can build
:an automated = system which=20 detects all these narrows to the least common
:denominator,
:sets up all these = stacks and=20 performs the export. But I do not see
:anything extra=20 we can
:achieve other than the added = complexity. It=20 This is not like a
:data link =
:protocol where one
:expects to = negotiate and=20 see the link up when a cable is plugged.

[Reinaldo] Well, first BGP also uses capability = negotiation=20 and it's not a data link protocol.

Second, between us, this administrator argument = stuff is not=20 really going to fly. I can also instead of using IKE/PKI, pay somebody = to=20 enter all the public-keys in world and retype every time them they are = needed.=20 IMO you are not thiking outside the box here.

Third, the example I give on the text (LCP), fits = this the=20 IPfix model really well since the endpoints have different needs and = LCP is a=20 protocol negotiating parameters for the correct operation of another = protocol=20 (IPCP).



:
:More specifically "In = most of the=20 cases (atleast
:   from a router = point of=20 view)  the collector is only an
:  =20 intermediate box between the exporter and the final node that =
:   interprets the export information. " =
:
:I disagree. Are you talking = about some=20 specific implementation?
:
:[G] No. A collection device is usually attached to multiple = routers=20 (I
:do not know about probes) =
:There are some things like more aggregation that happens in = the=20
:collector.
:This data = gets fed =20 into analyzers which perform the final analysis.

Right, even then I still do not want to send useless = and=20 undecoded data. I mean, if you assume the high bandwidth scenario that = you=20 mention, I also antecipate a high volumen data, so the more focused = the data,=20 the least diak space, the better and faster the analysis can de=20 done.

Philosofically speaking, capability negotiation = gives you the=20 freedom tho choose the system behavior amongst several = choices.   I=20 do not see from a technical standpoint (and from a protocol evoution) = a reason=20 not to have it. Through the capability negotiation you can say that = you want=20 for instance LAP, Netflow or CRANE instead of IPix.

:
:And saying that he job = of the=20 collector from an information point of
:view = would=20 just be to grab all that the exporter sends it's
:not=20 totally true. Maybe I want to use encryption, maybe I want to = use=20
:TCP instead of SCTP, maybe I want to export=20 overlapping
:flows..I do not want to send = data that is=20 not going to be useful or
:cannot be decoded = properly.=20 Maybe you have an specific
:implementaion in = mind.
:
:[G] You = can decide=20 this by configuring the exporter to send
:only what=20 is
:required.

[Reinaldo] see above
:=20
:[G] Memory copy is only one issue. The memory = buffering=20 requirement to
:take care of =
:even a single retransmission for high bandwidth router spans =
:10s to 100s
:of=20 Megabytes.
:So TCP is out of = question.=20
:In a network with reliability why add more task to = the=20 router processor
:by
:putting=20 TCP?
:


So, based on your statement, should I assume that = the only=20 deployment scenario acceptable would be where the collector and = exporter are=20 co-located? I mean, you are saying that there is high bandwidth export = data=20 and TCP is out of the quesion...Don't you think you are restricting = things too=20 much here?

:
:[Reinaldo]. Again, are = you talking=20 about a specific implementation? I
:could = use your own=20 argument and say that this can be
:provided = by the=20 lower layers (TCP or SCTP). This is only a requirement =
:for UDP.
:
:[G] This=20 would help to have a consistent implementation across
:transport
:protocols.

Consistent for who? For me putting a sequence number = there is=20 wasting space and trying to mimic TCP/SCTP behavior. You have to = decide if=20 using functions that the lower layers already provide is good or bad. = You=20 cannot choose them selectively to fit your needs.

:
:[G] I did not mean the = negotiation=20 part:) The exporter sends collector
:the = template=20 format.

The capabilities negotiated (which include template=20 negotiation) can be  renegotiated at any time.

cheers,

Reinaldo

------=_NextPart_000_001E_01C1AF55.8643B630-- -- 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 Feb 7 02:53:50 2002 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 CAA22018 for ; Thu, 7 Feb 2002 02:53:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yj66-0004Zt-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 01:35:58 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yj65-0004Z4-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 01:35:57 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g177ZHU14544; Thu, 7 Feb 2002 01:35:17 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVHV8>; Wed, 6 Feb 2002 23:35:12 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890ED0A@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: will@cisco.com, Ganesh Sadasivan Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Date: Wed, 6 Feb 2002 23:35:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AFA9.F9D51630" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AFA9.F9D51630 Content-Type: text/plain; charset="utf-8" Hello Will, first of all I would like to say that I do not think some of the stuff proposed by Ganesh/You is the right approach. I'm not saying Netflow is good or bad, I'm just do not think is the right think to do, no more no less. If you give me consistent arguments I can easily be convinced otherwise. Other comments inline. ----Original Message----- From: Will Eatherton [mailto:will@cisco.com] Sent: Wednesday, February 06, 2002 9:31 PM To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Reinaldo, The notation for who is speaking in this thread is making me dizzy, but I would like to state in a different way what Ganesh is saying on the main topic of this thread. For the application of router export to a collector we are saying that allowing UDP without required capability negotiation (as an option) is important. why is important? 1. As I said, you exchange a mere few packets and both ends agree that Netflow will be the IPfix protocol (or LFAP, or Diameter, or whatever) and you are done. What you are trying to propose is to make the IETF protocol rigid under the "using experience gained from widely deployed protocols " umbrella in order to fit an already deployed protocol of a single vendor. Unfortunaltely I do not agree with that. 2. Ganesh also mentioned that this is data link stuff, which I said it wasn't true since BGP implements a similar mechanism (BTW proposed by Cisco). 3. Then he said we should have sequence number on the IPfix protocol under the "would help to have a consistent implementation across transport " umbrella. My argument is that this is something to solve a specific UDP related problem only, and unless there is a better reason then the one above, no matter how you slide or dice it, we are wasting header space. Also I don't understand the desire in this thread to dance tip-toe around the fact that there is already a widely deployed export protocol used in the application of routers export and we (in this case Ganesh) are giving you the feedback based on experience one vendor has gained from experience with that protocol. And I agreed to some of these stuff ! But unfortunately some of other feedback is biased to how Netflow is implemented. As i said, I just do not think some of the stuff proposed by Ganesh/You is the right thing to do, no more no less. We are seeing capability negotiation as complex why it's complex? You have similar functionality already working for BGP today. You also have similar functionality working for PPP and OSPF also today. , not a requirement, and are suggesting it should not be a MUST for IPFIX unless it isnt the goal of IPFIX to be implemented on routers (is it a probe spec only ?). huh? Anyway, I think what I'm proposing is fair for everybody since several protocols can fullfill the IPfix requirements (Netflow, LFAP, CRANE, Diameter).and make the negotiation phase independent of the protocol used for the data flow. regards, Reinaldo ------_=_NextPart_001_01C1AFA9.F9D51630 Content-Type: text/html; charset="utf-8" RE: IPFIX Architecture
Hello Will,
 
first of all I would like to say that  I do not think some of the stuff proposed by Ganesh/You is the right approach. I'm not saying Netflow is good or bad, I'm just do not think is the right think to do, no more no less.
 
If you give me consistent arguments I can easily be convinced otherwise. Other comments inline.
 
 ----Original Message-----
From: Will Eatherton [mailto:will@cisco.com]
Sent: Wednesday, February 06, 2002 9:31 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan
Cc: ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] RE: IPFIX Architecture
Reinaldo,
 
The notation for who is speaking in this thread is making me dizzy, but I would like to state in a different way what Ganesh is saying on the main
topic of this thread.  For the application of router export to a collector we are saying that allowing UDP without required capability negotiation (as an option) is important. 
 
why is important?
 
1. As I said, you exchange a mere few packets and both ends agree that Netflow will be the IPfix protocol (or LFAP, or Diameter, or whatever) and you are done. What you are trying to propose is to make the IETF protocol rigid under the "using experience gained from widely deployed protocols " umbrella in order to fit an already deployed protocol of a single vendor. Unfortunaltely I do not agree with that.
 
2. Ganesh also mentioned that this is data link stuff, which I said it wasn't true since BGP implements a similar mechanism (BTW proposed by Cisco).
 
3. Then he said we should have sequence number on the IPfix protocol under the "would help to have a consistent implementation across
transport " umbrella. My argument is that this is something to solve a specific UDP related problem only, and unless there is a better reason then the one above, no matter how you slide or dice it, we are wasting header space.
 
Also I don't understand the desire in this thread to dance tip-toe around the fact that there is already a widely deployed export protocol used in the application of routers export and we (in this case Ganesh) are giving you the feedback based on experience one vendor has gained from experience with that protocol.   
 
And I agreed to some of these stuff ! But unfortunately some of other feedback is biased to how Netflow is implemented. As i said, I just do not think some of the stuff proposed by Ganesh/You is the right thing to do, no more no less.
 
 We are seeing capability negotiation as complex 
 
why it's complex? You have similar functionality already working for BGP today. You also have similar functionality working for PPP and OSPF also today.
 
 
 , not a requirement, and are suggesting it should not be a MUST for IPFIX unless it isnt the goal of IPFIX to be implemented on routers (is it a probe spec only ?).  
 
huh? Anyway, I think what I'm proposing is fair for everybody since several protocols can fullfill the IPfix requirements (Netflow, LFAP, CRANE, Diameter).and make the negotiation phase independent of the protocol used for the data flow.
 
regards,
 
Reinaldo
 
 
------_=_NextPart_001_01C1AFA9.F9D51630-- -- 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 Feb 7 04:20:12 2002 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 EAA23304 for ; Thu, 7 Feb 2002 04:20:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YkMr-0006T8-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 02:57:21 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YkMo-0006Sx-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 02:57:18 -0600 Received: from fokus.fhg.de (dhcp206 [195.37.78.206]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g178vCO26316; Thu, 7 Feb 2002 09:57:12 +0100 (MET) Message-ID: <3C6240D1.4090507@fokus.fhg.de> Date: Thu, 07 Feb 2002 09:54:41 +0100 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ram.gopal@nokia.com CC: zseby@fokus.gmd.de, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring References: Content-Type: multipart/alternative; boundary="------------080404070405070809080602" Precedence: bulk Sender: majordomo listserver --------------080404070405070809080602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Ram, ram.gopal@nokia.com wrote: >Hello Tanja, > >We are combining different sections from Kevin and you and forwarding to K.C. It will easy his compilation process. > O.K., thanks for this. > >WE are taking AAA scenario 1 and 2 and not 3. 3rd scenrio is not applicable to IPFIX. > I also see problems with realizing the 3rd scenario. Nevertheless, DIAMETER still is one candidate for the IPFIX protocol. That means there there has to be an evaluation (as for all the other candidates) with regard to the requirements first, before we can say whether this is applicable or not to IPFIX. (and that is mainly what I wrote in this section). > >Regarding Qos Monitoring we cannot do active measurement,rrt using flow unless the observation >point is the source of data. These belongs to IPPM and beyond scope of IPFIX. > As described in the text, QoS Monitoring is only passive measurement. All the described measurement techniques are passive. The RTT monitoring is based on existing traffic in the network. QoS Monitoring is one of the target applications for IPFIX. Therefore I think it is relevant for IPFIX. Maybe also for IPPM. Maybe we can check this with the IPPM group ? I thought that it would fit into your text into the section "some applications for IPFIX" because there you mention IPFIX applications like accounting, intrusion detection, traffic engineering, but there is no section on QoS Monitoring. If it doesnt fit in there, it is o.k. for me to put it in a separate document. > >Sampling of Qos is for PSAM working group. > Sampling is in our charter and is an optional feature for the IPFIX protocol from the requirements document. As far as I know there is no official psamp group until now (BOF planned for March ?) and the separation between IPFIX and psamp still needs some clarification. Regards Tanja > >We will add your content and merge all the 4 documents into the one. IF you want to submit as a separate document let me know we will delete the sections. > > >Regards >RAmg > > >>-----Original Message----- >>From: ext Tanja Zseby [mailto:zseby@fokus.gmd.de] >>Sent: Wednesday, February 06, 2002 6:30 AM >>To: K.C. Norseth >>Cc: ipfix-arch@net.doit.wisc.edu >>Subject: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring >> >> >>Hi K.C., >> >>attached you can find my contributions to the architecture document. >> >>- The first text contains some first thoughts on how IPFIX and >>AAA could >>communicate. >> >>- The second text contains considerations on how IPFIX can be used for >>QoS monitoring. Maybe this can also go into the architecture document >>(Ram Gopal for instance had a section on "some applications >>for IPFIX" >>in his text). Or do you think this should be put into a >>separate document ? >> >>Regards >>Tanja >> >>-- >>Dipl.-Ing. Tanja Zseby >>FhI FOKUS/Global Networking Email: >>zseby@fokus.fhg.de >>Kaiserin-Augusta-Allee 31 Phone: >>+49-30-3463-7153 >>D-10589 Berlin, Germany Fax: >>+49-30-3463-8153 >>--------------------------------------------------------------- >>----------------------- >>"Living on earth is expensive but it includes a free trip >>around the sun." (Anonymous) >>--------------------------------------------------------------- >>----------------------- >> >> > -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- --------------080404070405070809080602 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ram,

ram.gopal@nokia.com wrote:
Hello Tanja,

We are combining different sections from Kevin and you and forwarding to K.C. It will easy his compilation process.
O.K., thanks for this.

WE are taking AAA scenario 1 and 2 and not 3. 3rd scenrio is not applicable to IPFIX.
I also see problems with realizing the 3rd scenario. Nevertheless, DIAMETER still is one candidate for the IPFIX protocol. That means there there has to be an evaluation (as for all the other candidates) with regard to the requirements first, before we can say whether this is applicable or not to IPFIX. (and that is mainly what I wrote in this section).

Regarding Qos Monitoring we cannot do active measurement,rrt using flow unless the observation 
point is the source of data. These belongs to IPPM and  beyond scope of IPFIX.
As described in the text, QoS Monitoring is only passive measurement. All the described measurement techniques are passive. The RTT monitoring is based on existing traffic in the network. QoS Monitoring is one of the target applications for IPFIX. Therefore I think it is relevant for IPFIX. Maybe also for IPPM. Maybe we can check this with the IPPM group ? I thought that it would fit into your text into the section "some applications for IPFIX" because there you mention IPFIX applications like accounting, intrusion detection, traffic engineering, but there is no section on QoS Monitoring. If it doesnt fit in there, it is o.k. for me to put it in a separate document.


Sampling of Qos is for PSAM working group.
Sampling is in our charter and is an optional feature for the IPFIX protocol from the requirements document. As far as I know there is no official psamp group until now (BOF planned for March ?) and the separation between IPFIX and psamp still  needs some clarification.

Regards
Tanja


We will add your content and merge all the 4 documents into the one. IF you want to submit as a separate document let me know we will delete the sections.

 
Regards
RAmg
 

-----Original Message-----
From: ext Tanja Zseby [mailto:zseby@fokus.gmd.de]
Sent: Wednesday, February 06, 2002 6:30 AM
To: K.C. Norseth
Cc: ipfix-arch@net.doit.wisc.edu
Subject: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring


Hi K.C.,

attached you can find my contributions to the architecture document.

- The first text contains some first thoughts on how IPFIX and 
AAA could 
communicate.

- The second text contains considerations on how IPFIX can be used for 
QoS monitoring. Maybe this can also go into the architecture document 
(Ram Gopal for instance had a section on "some applications 
for IPFIX" 
in his text). Or do you think this should be put into a 
separate document ?

Regards
Tanja

-- 
Dipl.-Ing. 
Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: 
zseby@fokus.fhg.de	
Kaiserin-Augusta-Allee 31				Phone: 
+49-30-3463-7153
D-10589 Berlin, Germany				Fax:   
+49-30-3463-8153
---------------------------------------------------------------
----------------------- 
"Living on earth is expensive but it includes a free trip 
around the sun." (Anonymous)
---------------------------------------------------------------
-----------------------

>

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: zseby@fokus.fhg.de	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

--------------080404070405070809080602-- -- 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 Feb 7 04:41:40 2002 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 EAA23538 for ; Thu, 7 Feb 2002 04:41:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Ykoh-0007Cl-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 03:26:07 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Ykof-0007Cg-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 03:26:05 -0600 Received: from fokus.fhg.de (dhcp206 [195.37.78.206]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g179Q0O29678; Thu, 7 Feb 2002 10:26:00 +0100 (MET) Message-ID: <3C624791.6050909@fokus.fhg.de> Date: Thu, 07 Feb 2002 10:23:29 +0100 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Ganesh Sadasivan CC: zseby@fokus.gmd.de, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring References: <3C6113C9.2080604@fokus.fhg.de> <3C618E83.F1C57C73@cisco.com> Content-Type: multipart/alternative; boundary="------------060306010206000106070203" Precedence: bulk Sender: majordomo listserver --------------060306010206000106070203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Ganesh I agree, that different applications can be consumer of IPFIX data. Nevertheless, AAA defines a whole architecture for accounting and itself provides input to accounting and billing applications. Therefore I think we need to show how IPFIX and AAA can work together. I agree that it is not the task of IPFIX to define the interfaces. And maybe you are right, and the architecture document is not the rigtht place for this. If Nevil writes something on relations to RTFM we could put together a document on relations between IPFIX and other WGs/frameworks. Or really start a applicability document with sections for the target applications mentioned in the requirements draft. Regards Tanja Ganesh Sadasivan wrote: >Hi Tanja, > >Tanja Zseby wrote: > >>Hi K.C., >> >>attached you can find my contributions to the architecture document. >> >>- The first text contains some first thoughts on how IPFIX and AAA could >>communicate. >> > >To me, this portion is entirely out of scope from an IPFIX arch point >of view. >This is more of an application which takes in flow records collected by the >IPFIX collector. Similarly there could be other applications that use the >collected flow records.IMO we should not be defining these interfaces in >the archtecture. >If there is something like an applicability doc, that would be a good place >for this to go. But again the point is that IPFIX should not go all the way to >define interfaces with each of the possible applications. > > >> >>- The second text contains considerations on how IPFIX can be used for >>QoS monitoring. Maybe this can also go into the architecture document >> (Ram Gopal for instance had a section on "some applications for IPFIX" >>in his text). Or do you think this should be put into a separate document ? >> > >This also looks to be good for an applicability doc. >Thanks >Ganesh > >> >>Regards >>Tanja >> >>-- >>Dipl.-Ing. Tanja Zseby >>FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de >>Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 >>D-10589 Berlin, Germany Fax: +49-30-3463-8153 >>-------------------------------------------------------------------------------------- >>"Living on earth is expensive but it includes a free trip around the sun." (Anonymous) >>-------------------------------------------------------------------------------------- >> > -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- --------------060306010206000106070203 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Ganesh

I agree, that different applications can be consumer of IPFIX data. Nevertheless, AAA defines a whole architecture for accounting and itself provides input to accounting and billing applications. Therefore I think we need to show how IPFIX and AAA can work together. I agree that it is not the task of IPFIX to define the interfaces. And maybe you are right, and the architecture document is not the rigtht place for this. If Nevil writes something on relations to RTFM we could put together a document on relations between IPFIX and other WGs/frameworks. Or really start a applicability document with sections for the target applications mentioned in the requirements draft.

Regards
Tanja

Ganesh Sadasivan wrote:
Hi Tanja,

Tanja Zseby wrote:

Hi K.C.,

attached you can find my contributions to the architecture document.

- The first text contains some first thoughts on how IPFIX and AAA could
communicate.

To me, this portion is entirely out of scope from an IPFIX arch point
of view.
This is more of an application which takes in flow records collected by the
IPFIX collector. Similarly there could be other applications that use the
collected flow records.IMO we should not be defining these interfaces in
the archtecture.
If there is something like an applicability doc, that would be a good place
for this to go. But again the point is that IPFIX should not go all the way to
define interfaces with each of the possible applications.



- The second text contains considerations on how IPFIX can be used for
QoS monitoring. Maybe this can also go into the architecture document
 (Ram Gopal for instance had a section on "some applications for IPFIX"
in his text). Or do you think this should be put into a separate document ?

This also looks to be good for an applicability doc.
Thanks
Ganesh


Regards
Tanja

--
Dipl.-Ing. Tanja Zseby
FhI FOKUS/Global Networking                     Email: zseby@fokus.fhg.de
Kaiserin-Augusta-Allee 31                               Phone: +49-30-3463-7153
D-10589 Berlin, Germany                         Fax:   +49-30-3463-8153
--------------------------------------------------------------------------------------
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------



-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: zseby@fokus.fhg.de	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

--------------060306010206000106070203-- -- 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 Feb 7 05:03:03 2002 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 FAA24031 for ; Thu, 7 Feb 2002 05:03:02 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yl7w-0007eU-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 03:46:00 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yl7t-0007d9-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 03:45:57 -0600 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-251.cisco.com [144.254.7.251]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA11019; Thu, 7 Feb 2002 10:45:19 +0100 (MET) Message-ID: <3C624CB9.359B2769@cisco.com> Date: Thu, 07 Feb 2002 10:45:30 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture - timestamps... References: <3C620110.A0F1400C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, Ganesh Sadasivan wrote: > Hello, > > About the timestamp issue... > > Can't we use TCP's timestamp option instead of putting this on the flow > header? It's a timestamp and it's already there. yeah, > then it would not work for UDP. But then that might another thing for > the capability negotiation phase... > =========================================== > [G] The timestamp stuck in a flow record when the flow sees the first > and > last packet. It has nothing to do with the time when it is transported. > The timestamp in the flow header however is the time when the flows are > > packetized. This could be off from the actual time when the packet is > sent out > by TCP by 10-100msec depending on the implementation. Just to add in Ganesh's direction... And don't forget that a flow can stay a variable time in the cache if it's still active. So you can not compute anymore the UTC time the first packet was seen in a flow, if you only use the TCP timestamp. Regards, Benoit > It is an extra 10 > bytes > per packet for Timestamp option and it is an "option". > IMO, this field should be protocol independent and should be part of the > flow header. > Thanks > Ganesh > ============================================ > regards, > > Reinaldo > > -----Original Message----- > From: Penno, Reinaldo [SC9:T327:EXCH] > Sent: Wednesday, February 06, 2002 6:47 PM > To: Ganesh Sadasivan; kevin.zhang@xacct.com > Cc: KC' 'Norseth; ipfix-data-volunteers@net.doit.wisc.edu; > ipfix-arch-volunteers@net.doit.wisc.edu; > ipfix-chairs@net.doit.wisc.edu; ipfix-arch@net.doit.wisc.edu > > Subject: [ipfix-arch] RE: IPFIX Architecture > > G: > If we have the timestamp per flow why is resequencing required > G: > [Reinaldo] humm...I need to think more about this one... > > -- > 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/ -- 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 Feb 7 08:20:56 2002 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 IAA26057 for ; Thu, 7 Feb 2002 08:20:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yo9g-0005vC-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 07:00:00 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yo9d-0005v4-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 06:59:57 -0600 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g17D1jQ18132 for ; Thu, 7 Feb 2002 07:01:45 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Feb 2002 06:59:56 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Feb 2002 06:59:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: [ipfix-arch] RE: IPFIX Architecture writeup from Ram Gopal Date: Thu, 7 Feb 2002 07:59:54 -0500 Message-ID: Thread-Topic: IPFIX Architecture writeup from Ram Gopal Thread-Index: AcGvce8dEIKL8HK7Rb2d/ctT7Q7yuQAZWReQ From: To: Cc: , X-OriginalArrivalTime: 07 Feb 2002 12:59:56.0078 (UTC) FILETIME=[575014E0:01C1AFD7] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA26057 Hello Ganesh, Please see inline comments >> (2) >> G: >> The diagram is confusing. >> Observation Point and exporter are 2 pieces of a single >system and not >> separate entities. >> G: >> >> The logical functionalities are described whether u have >everything in one piece >> or distributed it is upto the implementation. > >The point here is that IPFIX does not try to define the >interface between >observation point and exporter. Showing it as 2 pieces lets >one think why >the interface between these 2 should not be defined. Showing >the way Kevin >Zhang has shown for the exporter part looks cleaner to me. We are defining the IPFIX endpoint and the protocol requirement for those endpoints. Logically exporter and collector two different components, even we had talk with Kevin also and merged the document into one. I think you view from logical functional point rather than physical view - No one wants to have big monolithic piece. >> >> >> (3) >> G: >> Observation point is the place where metering is done. >> I did not understand why it is an option. Metering includes >> filtering also. >> From >http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt: >> >> 4. Metering Process >> >> The following are requirements for the metering process. They >> describe the requirements for the process at the measurement >> instance. All measurements MUST be conducted from the >point of view >> of the observation point. >> ..... >> G: >> >> Refer requirement document 1.1 IPFlow >> >> The observation point may be a network interface of a device or an >> entire router, a probe, or a middlebox with several interfaces. >> Properties derived from packet treatment include for example the >> interface at which the packet arrived, the interface the >packet will >> be forwarded to and potentially some other information. >> >> So observation point is just a probe , for example typically >we may have more than >> one interface through which we would like to monitor the packet. > >In the above example the Observation point (the probe) is an >aggregation >of interfaces. The metering is also done logically at the >probe level which >gets split up into the individual interfaces depending on the >implementation. >But the collector sees the observation point as the metering entity. >I agree that metering process is not very clear in the req spec. It is your view how you view the collector. Any architecture there will be a logical division of functions, Collector may know where the observation points, as far the collector is concerned it is communicating to the exporter not to the observation points. >> (5) >> >> G: >> It is the exporter who decides what to >> measure , where to measure & what to send. We are not defining >> how to configure a metering process from a collector. >> - the exporter configuration is out of the scope of this document >> - the exporter configuration SHOULD be done out of band >> >> G: >> >> This may be one implementation, but generally exporter does >metering, and reporting functions and >> more detailed in the document. >> >> Regarding configuration, what is said is one implementation. >But collector should be able to >> request (Configure) and get the required Flow information. > >For this the collector needs to understand the capability and >to some extent the >implementation of an exporter and this is a non-trivial >problem to solve. It is your view, there is no problem in what we described, based on the Flow you will get the statistics or the data to the collector. I think want to put everything in one piece. >> (6) >> >> G: >> This is already covered in the req. spec.Is there a necessity >> to repeat it here? >> G: >> >> I think this sentence is rephrased and content of the >sections are different. We added more text from other authors. >> Hope compiled version of the document will give better picture. > >It is better to have another doc. called applicability doc or >so rather than keeping >it as a part of the architecture. I also agree with you, but we have only two documents as defined in charter. ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Thu Feb 7 09:39:17 2002 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 JAA28270 for ; Thu, 7 Feb 2002 09:39:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YpRY-00003F-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 08:22:32 -0600 Received: from iere.net.avaya.com ([198.152.12.101]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YpRV-000037-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 08:22:29 -0600 Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g17EL8N22565 for ; Thu, 7 Feb 2002 09:21:08 -0500 (EST) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g17EL5G22422 for ; Thu, 7 Feb 2002 09:21:05 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AFE2.FA9136D8" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Date: Thu, 7 Feb 2002 09:23:14 -0500 Message-ID: Thread-Topic: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Thread-Index: AcGvWuk4lbT6aAP3Q5yzXVCDV+qrEwCFlZ6w From: "Siddiqui, Anwar A (Anwar)" To: "Reinaldo Penno" , "Tanja Zseby" , "K.C. Norseth" Cc: , , "Romascanu, Dan (Dan)" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C1AFE2.FA9136D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 There are couple of issues with IPFIX and QOS Monitoring.=20 =20 1. There is RMON WG that is doing some work on QOS Monitoring.=20 There are some standard tarck work in this space like SMON, RMON, Application=20 Performance Measurement (APM), Transport Performance Measurement (TPM), Synthetic Source Measurement (SSPM) etc. are a few solutions that resdides in this space. There is also a proposed darft for Realtime Application QOS Monitoring (RAQMON)=20 in RMON WG presented during last 2 IETF sessions. This draft has=20 --> a MIB definition for storage of data and=20 --> A protocol interface between the end devices to report QOS parameters from an IP end device to a report collector.=20 =20 It was raised in that WG during RAQMON presentation whether IPFIX can be leveraged=20 as a "light weight" protocol such that the IP end devices can use that to report data to report collector?=20 =20 Is this within the charter of IPFIX WG? When IPFIX was chartered, it was focused towards billing and reliable transport resquirements were heavy. However this could be my misunderstanding too. Can some one plese comment on that.=20 =20 Here is a copy of the RAQMON draft that we are working from.=20 http://search.ietf.org/internet-drafts/draft-siddiqui-rmonmib-raqmon-mib -00.txt =20 BTW there is also IPPM WG deciding on various methodologies of QOS mesaurements. =20 Anwar -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Wednesday, February 06, 2002 4:59 PM To: Tanja Zseby; K.C. Norseth Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Hello,=20 I just read this QoS doc, which BTW is very nice, but I wonder whether this is in-scope. I mean, how exactly you are going to perform QoS monitoring depend in so many factors...applications, networks, etc. It should be totally up to the implementation and indirectly who is doing the monitoring. Maybe a different draft suggesting recommendations on QoS measurement process for IPfix. Any thoughts?=20 regards,=20 Reinaldo=20 :-----Original Message-----=20 :From: Tanja Zseby [ mailto:zseby@fokus.gmd.de]=20 :Sent: Wednesday, February 06, 2002 3:30 AM=20 :To: K.C. Norseth=20 :Cc: ipfix-arch@net.doit.wisc.edu=20 :Subject: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring=20 :=20 :=20 :Hi K.C.,=20 :=20 :attached you can find my contributions to the architecture document.=20 :=20 :- The first text contains some first thoughts on how IPFIX and=20 :AAA could=20 :communicate.=20 :=20 :- The second text contains considerations on how IPFIX can be used for=20 :QoS monitoring. Maybe this can also go into the architecture document=20 : (Ram Gopal for instance had a section on "some applications=20 :for IPFIX"=20 :in his text). Or do you think this should be put into a=20 :separate document ?=20 :=20 :Regards=20 :Tanja=20 :=20 :--=20 :Dipl.-Ing. Tanja Zseby =20 :FhI FOKUS/Global Networking Email:=20 :zseby@fokus.fhg.de =20 :Kaiserin-Augusta-Allee 31 Phone:=20 :+49-30-3463-7153=20 :D-10589 Berlin, Germany Fax: =20 :+49-30-3463-8153=20 :---------------------------------------------------------------=20 :-----------------------=20 :"Living on earth is expensive but it includes a free trip=20 :around the sun." (Anonymous)=20 :---------------------------------------------------------------=20 :-----------------------=20 :=20 :=20 ------_=_NextPart_001_01C1AFE2.FA9136D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS = Monitoring
Hello,
 
There=20 are couple of issues with IPFIX and QOS Monitoring.
 
1.=20 There is RMON WG that is doing some work on QOS Monitoring. =
There=20 are some standard tarck work in this space like SMON, RMON, Application=20
Performance Measurement (APM),  Transport Performance = Measurement=20 (TPM), 
Synthetic Source Measurement (SSPM) etc. are a few = solutions that=20 resdides in this space.
There=20 is also a proposed darft for Realtime Application QOS Monitoring = (RAQMON)=20
in=20 RMON WG presented during last 2 IETF sessions. This draft has=20
    --> a MIB definition for storage of data=20 and 
    --> A protocol interface = between the end=20 devices to report QOS parameters from an IP end=20 device
to=20 a report collector.
 
It=20 was raised in that WG during RAQMON presentation = whether IPFIX can=20 be leveraged
as a=20 "light weight" protocol such that the IP end devices can use = that to=20 report data
to=20 report collector?
 
Is=20 this within the charter of IPFIX WG? When IPFIX was chartered, it was = focused=20 towards
billing and reliable transport resquirements were heavy. = However this=20 could be my misunderstanding too.
Can=20 some one plese comment on that. 
 
Here=20 is a copy of the RAQMON draft that we are working from.
http://search.ietf.org/internet-drafts/draft-siddiqui-rmo= nmib-raqmon-mib-00.txt
 
BTW there is also IPPM WG deciding on various = methodologies=20 of QOS mesaurements.
 
Anwar
-----Original Message-----
From: Reinaldo Penno=20 [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Wednesday, = February=20 06, 2002 4:59 PM
To: Tanja Zseby; K.C. Norseth
Cc: = ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] IPFIX = and AAA=20 and IPFIX for QoS Monitoring

Hello,

I just read this QoS doc, which BTW is very nice, = but I wonder=20 whether this is in-scope. I mean, how exactly you are going to perform = QoS=20 monitoring depend in so many factors...applications, networks, etc. It = should=20 be totally up to the implementation and indirectly who is doing the=20 monitoring.

Maybe a different draft suggesting recommendations = on QoS=20 measurement process for IPfix. Any thoughts?

regards,

Reinaldo



:-----Original Message-----
:From:=20 Tanja Zseby [mailto:zseby@fokus.gmd.de] =
:Sent: Wednesday, February 06, 2002 3:30 AM =
:To: K.C. Norseth
:Cc:=20 ipfix-arch@net.doit.wisc.edu
:Subject: = [ipfix-arch]=20 IPFIX and AAA and IPFIX for QoS Monitoring
:=20
:
:Hi K.C., =
:
:attached you can find my = contributions to=20 the architecture document.
: =
:- The first text contains some first thoughts on how IPFIX = and=20
:AAA could
:communicate.
:
:- The=20 second text contains considerations on how IPFIX can be used for=20
:QoS monitoring. Maybe this can also go into = the=20 architecture document
: (Ram Gopal for = instance had a=20 section on "some applications
:for IPFIX"=20
:in his text). Or do you think this should = be put into=20 a
:separate document ?
:
:Regards
:Tanja
:
:--=20
:Dipl.-Ing. Tanja Zseby=20        =20            =20             =
:FhI FOKUS/Global Networking   =20        =20         Email:
:zseby@fokus.fhg.de    
:Kaiserin-Augusta-Allee 31     =20        =20        =20         Phone:
:+49-30-3463-7153
:D-10589 Berlin,=20 Germany       =20        =20        =20         Fax:   =
:+49-30-3463-8153
:---------------------------------------------------------------= =20
:-----------------------
:"Living on=20 earth is expensive but it includes a free trip
:around=20 the sun." (Anonymous)
:---------------------------------------------------------------= =20
:-----------------------
:=20
:

------_=_NextPart_001_01C1AFE2.FA9136D8-- -- 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 Feb 7 09:41:00 2002 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 JAA28337 for ; Thu, 7 Feb 2002 09:40:59 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YpR0-00001y-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 08:21:58 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YpQy-00001j-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 08:21:56 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id JAA22039 for ; Thu, 7 Feb 2002 09:31:17 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xmaa21863; Thu, 7 Feb 02 09:30:46 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 09:20:30 -0500 Message-ID: <0BF8B32B723ED5119E0B0002A551748B01FA0874@corp-exc3.ctron.com> From: "Harrington, David" To: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Date: Thu, 7 Feb 2002 09:20:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AFE2.98ABF340" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AFE2.98ABF340 Content-Type: text/plain; charset="UTF-8" Hi, I've seen working group after working group get hung up on the lower-level transport layer issues with TCP versus UDP versus SCTP. I recommend that IPFIX take the modular approach - identify a transport "box" in the architecture, then use a separate document to specify different possible transport mappings, and the specifics of things like retries can be described in the transport mapping document. Defining the fact that there is a box to handle transport issues let's the rest of the work continue without everything being dependent on the resolution of the transport issue. I strongly recommend keeping the transport parameters out of the IPFIX message. The IPFIX message should be consistent no matter which transport is being used. Having lots of "optional" or conditional things in the IPFIX message will make it dramatically harder for the two ends of a communication to interoperate in a useful manner. The goal is to set a "standard" so behavior is consistent and each side knows how to do their part of the job. It can be a good thing to favor flexibility over rigidity in software development, but standards development is slightly different than software development, and the primary goal should be interoperability - that requires clearly defining the expectations. It is a GOOD thing to make the standard "rigid" so there is interoperability. dbh -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Thursday, February 07, 2002 2:35 AM To: will@cisco.com; Ganesh Sadasivan Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Hello Will, first of all I would like to say that I do not think some of the stuff proposed by Ganesh/You is the right approach. I'm not saying Netflow is good or bad, I'm just do not think is the right think to do, no more no less. If you give me consistent arguments I can easily be convinced otherwise. Other comments inline. ----Original Message----- From: Will Eatherton [mailto:will@cisco.com] Sent: Wednesday, February 06, 2002 9:31 PM To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Reinaldo, The notation for who is speaking in this thread is making me dizzy, but I would like to state in a different way what Ganesh is saying on the main topic of this thread. For the application of router export to a collector we are saying that allowing UDP without required capability negotiation (as an option) is important. why is important? 1. As I said, you exchange a mere few packets and both ends agree that Netflow will be the IPfix protocol (or LFAP, or Diameter, or whatever) and you are done. What you are trying to propose is to make the IETF protocol rigid under the "using experience gained from widely deployed protocols " umbrella in order to fit an already deployed protocol of a single vendor. Unfortunaltely I do not agree with that. 2. Ganesh also mentioned that this is data link stuff, which I said it wasn't true since BGP implements a similar mechanism (BTW proposed by Cisco). 3. Then he said we should have sequence number on the IPfix protocol under the "would help to have a consistent implementation across transport " umbrella. My argument is that this is something to solve a specific UDP related problem only, and unless there is a better reason then the one above, no matter how you slide or dice it, we are wasting header space. Also I don't understand the desire in this thread to dance tip-toe around the fact that there is already a widely deployed export protocol used in the application of routers export and we (in this case Ganesh) are giving you the feedback based on experience one vendor has gained from experience with that protocol. And I agreed to some of these stuff ! But unfortunately some of other feedback is biased to how Netflow is implemented. As i said, I just do not think some of the stuff proposed by Ganesh/You is the right thing to do, no more no less. We are seeing capability negotiation as complex why it's complex? You have similar functionality already working for BGP today. You also have similar functionality working for PPP and OSPF also today. , not a requirement, and are suggesting it should not be a MUST for IPFIX unless it isnt the goal of IPFIX to be implemented on routers (is it a probe spec only ?). huh? Anyway, I think what I'm proposing is fair for everybody since several protocols can fullfill the IPfix requirements (Netflow, LFAP, CRANE, Diameter).and make the negotiation phase independent of the protocol used for the data flow. regards, Reinaldo ------_=_NextPart_001_01C1AFE2.98ABF340 Content-Type: text/html; charset="UTF-8" RE: IPFIX Architecture
Hi,
 
I've seen working group after working group get hung up on the lower-level transport layer issues with TCP versus UDP versus SCTP.
 
I recommend that IPFIX take the modular approach - identify a transport "box" in the architecture, then use a separate document to specify different possible transport mappings, and the specifics of things like retries can be described in the transport mapping document. Defining the fact that there is a box to handle transport issues let's the rest of the work continue without everything being dependent on the resolution of the transport issue.
 
I strongly recommend keeping the transport parameters out of the IPFIX message. The IPFIX message should be consistent no matter which transport is being used. Having lots of "optional" or conditional things in the IPFIX message will make it dramatically harder for the two ends of a communication to interoperate in a useful manner.
 
The goal is to set a "standard" so behavior is consistent and each side knows how to do their part of the job. It can be a good thing to favor flexibility over rigidity in software development, but standards development is slightly different than software development, and the primary goal should be interoperability - that requires clearly defining the expectations. It is a GOOD thing to make the standard "rigid" so there is interoperability.
 
dbh
 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Thursday, February 07, 2002 2:35 AM
To: will@cisco.com; Ganesh Sadasivan
Cc: ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] RE: IPFIX Architecture

Hello Will,
 
first of all I would like to say that  I do not think some of the stuff proposed by Ganesh/You is the right approach. I'm not saying Netflow is good or bad, I'm just do not think is the right think to do, no more no less.
 
If you give me consistent arguments I can easily be convinced otherwise. Other comments inline.
 
 ----Original Message-----
From: Will Eatherton [mailto:will@cisco.com]
Sent: Wednesday, February 06, 2002 9:31 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan
Cc: ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] RE: IPFIX Architecture
Reinaldo,
 
The notation for who is speaking in this thread is making me dizzy, but I would like to state in a different way what Ganesh is saying on the main
topic of this thread.  For the application of router export to a collector we are saying that allowing UDP without required capability negotiation (as an option) is important. 
 
why is important?
 
1. As I said, you exchange a mere few packets and both ends agree that Netflow will be the IPfix protocol (or LFAP, or Diameter, or whatever) and you are done. What you are trying to propose is to make the IETF protocol rigid under the "using experience gained from widely deployed protocols " umbrella in order to fit an already deployed protocol of a single vendor. Unfortunaltely I do not agree with that.
 
2. Ganesh also mentioned that this is data link stuff, which I said it wasn't true since BGP implements a similar mechanism (BTW proposed by Cisco).
 
3. Then he said we should have sequence number on the IPfix protocol under the "would help to have a consistent implementation across
transport " umbrella. My argument is that this is something to solve a specific UDP related problem only, and unless there is a better reason then the one above, no matter how you slide or dice it, we are wasting header space.
 
Also I don't understand the desire in this thread to dance tip-toe around the fact that there is already a widely deployed export protocol used in the application of routers export and we (in this case Ganesh) are giving you the feedback based on experience one vendor has gained from experience with that protocol.   
 
And I agreed to some of these stuff ! But unfortunately some of other feedback is biased to how Netflow is implemented. As i said, I just do not think some of the stuff proposed by Ganesh/You is the right thing to do, no more no less.
 
 We are seeing capability negotiation as complex 
 
why it's complex? You have similar functionality already working for BGP today. You also have similar functionality working for PPP and OSPF also today.
 
 
 , not a requirement, and are suggesting it should not be a MUST for IPFIX unless it isnt the goal of IPFIX to be implemented on routers (is it a probe spec only ?).  
 
huh? Anyway, I think what I'm proposing is fair for everybody since several protocols can fullfill the IPfix requirements (Netflow, LFAP, CRANE, Diameter).and make the negotiation phase independent of the protocol used for the data flow.
 
regards,
 
Reinaldo
 
 
------_=_NextPart_001_01C1AFE2.98ABF340-- -- 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 Feb 7 12:43:37 2002 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 MAA03535 for ; Thu, 7 Feb 2002 12:43:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YsIy-0003qQ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 11:25:52 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YsIv-0003pw-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 11:25:50 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g17HOjk08032; Thu, 7 Feb 2002 11:24:46 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVNSC>; Thu, 7 Feb 2002 09:24:40 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890EE9C@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "Harrington, David" , ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Date: Thu, 7 Feb 2002 09:24:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AFFC.53935B30" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AFFC.53935B30 Content-Type: text/plain; charset="utf-8" David, what you are proposing is very difficult to be done, because when we are architecting this "box" we need to know what the lower layers can or cannot provide us. So, should we put a sequence number on the header? Should we provide ack fields? etc, etc... Other comments inline... -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: Thursday, February 07, 2002 6:21 AM To: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Hi, I've seen working group after working group get hung up on the lower-level transport layer issues with TCP versus UDP versus SCTP. I recommend that IPFIX take the modular approach - identify a transport "box" in the architecture, then use a separate document to specify different possible transport mappings, and the specifics of things like retries can be described in the transport mapping document. Defining the fact that there is a box to handle transport issues let's the rest of the work continue without everything being dependent on the resolution of the transport issue. I strongly recommend keeping the transport parameters out of the IPFIX message. The IPFIX message should be consistent no matter which transport is being used. Having lots of "optional" or conditional things in the IPFIX message will make it dramatically harder for the two ends of a communication to interoperate in a useful manner. I can't follow this line of reasoning. I gave examples of several protocols that use capability negotiation and there is no problem. *Actually, it's the capability negotiation that makes them interoperable*. Can you imagine PPP without LCP? Or nowadays for that matter BGP without capabilites negotiation? Or even OSPF. The goal is to set a "standard" so behavior is consistent and each side knows how to do their part of the job. It can be a good thing to favor flexibility over rigidity in software development, but standards development is slightly different than software development, and the primary goal should be interoperability oops. Hold on. IETF is about rough consensus and *running code*. We are not doing paper exercise here. Eventually the standards will need to be coded and vendors will (as always) want to make their extensions for whatever purposes (customers, edge over the competition, etc). A protocol should be extensible. - that requires clearly defining the expectations. It is a GOOD thing to make the standard "rigid" so there is interoperability. being flexible has nothing to do with lack of interoperability. regards, Reinaldo dbh -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Thursday, February 07, 2002 2:35 AM To: will@cisco.com; Ganesh Sadasivan Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Hello Will, first of all I would like to say that I do not think some of the stuff proposed by Ganesh/You is the right approach. I'm not saying Netflow is good or bad, I'm just do not think is the right think to do, no more no less. If you give me consistent arguments I can easily be convinced otherwise. Other comments inline. ----Original Message----- From: Will Eatherton [mailto:will@cisco.com] Sent: Wednesday, February 06, 2002 9:31 PM To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Reinaldo, The notation for who is speaking in this thread is making me dizzy, but I would like to state in a different way what Ganesh is saying on the main topic of this thread. For the application of router export to a collector we are saying that allowing UDP without required capability negotiation (as an option) is important. why is important? 1. As I said, you exchange a mere few packets and both ends agree that Netflow will be the IPfix protocol (or LFAP, or Diameter, or whatever) and you are done. What you are trying to propose is to make the IETF protocol rigid under the "using experience gained from widely deployed protocols " umbrella in order to fit an already deployed protocol of a single vendor. Unfortunaltely I do not agree with that. 2. Ganesh also mentioned that this is data link stuff, which I said it wasn't true since BGP implements a similar mechanism (BTW proposed by Cisco). 3. Then he said we should have sequence number on the IPfix protocol under the "would help to have a consistent implementation across transport " umbrella. My argument is that this is something to solve a specific UDP related problem only, and unless there is a better reason then the one above, no matter how you slide or dice it, we are wasting header space. Also I don't understand the desire in this thread to dance tip-toe around the fact that there is already a widely deployed export protocol used in the application of routers export and we (in this case Ganesh) are giving you the feedback based on experience one vendor has gained from experience with that protocol. And I agreed to some of these stuff ! But unfortunately some of other feedback is biased to how Netflow is implemented. As i said, I just do not think some of the stuff proposed by Ganesh/You is the right thing to do, no more no less. We are seeing capability negotiation as complex why it's complex? You have similar functionality already working for BGP today. You also have similar functionality working for PPP and OSPF also today. , not a requirement, and are suggesting it should not be a MUST for IPFIX unless it isnt the goal of IPFIX to be implemented on routers (is it a probe spec only ?). huh? Anyway, I think what I'm proposing is fair for everybody since several protocols can fullfill the IPfix requirements (Netflow, LFAP, CRANE, Diameter).and make the negotiation phase independent of the protocol used for the data flow. regards, Reinaldo ------_=_NextPart_001_01C1AFFC.53935B30 Content-Type: text/html; charset="utf-8" RE: IPFIX Architecture
David,
 
what you are proposing is very difficult to be done, because when we are architecting this "box" we need to know what the lower layers can or cannot provide us. So, should we put a sequence number on the header? Should we provide ack fields? etc, etc...
 
Other comments inline...
 
-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com]
Sent: Thursday, February 07, 2002 6:21 AM
To: ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] RE: IPFIX Architecture

Hi,
 
I've seen working group after working group get hung up on the lower-level transport layer issues with TCP versus UDP versus SCTP.
 
I recommend that IPFIX take the modular approach - identify a transport "box" in the architecture, then use a separate document to specify different possible transport mappings, and the specifics of things like retries can be described in the transport mapping document. Defining the fact that there is a box to handle transport issues let's the rest of the work continue without everything being dependent on the resolution of the transport issue.
 
I strongly recommend keeping the transport parameters out of the IPFIX message. The IPFIX message should be consistent no matter which transport is being used. Having lots of "optional" or conditional things in the IPFIX message will make it dramatically harder for the two ends of a communication to interoperate in a useful manner.  
 
I can't follow this line of reasoning. I gave examples of several protocols that use capability negotiation and there is no problem.
 
*Actually, it's the capability negotiation that makes them interoperable*.
 
Can you imagine PPP without LCP? Or nowadays for that matter BGP without capabilites negotiation? Or even OSPF.
 
The goal is to set a "standard" so behavior is consistent and each side knows how to do their part of the job. It can be a good thing to favor flexibility over rigidity in software development, but standards development is slightly different than software development, and the primary goal should be interoperability 
 
oops. Hold on. IETF is about rough consensus and *running code*. We are not doing paper exercise here. Eventually the standards will need to be coded and vendors will (as always) want to make their extensions for whatever purposes (customers, edge over the competition, etc). A protocol should be extensible.
 
  - that requires clearly defining the expectations. It is a GOOD thing to make the standard "rigid" so there is interoperability.  
 
being flexible has nothing to do with lack of interoperability. 
 
regards,
 
Reinaldo 
 
dbh
 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Thursday, February 07, 2002 2:35 AM
To: will@cisco.com; Ganesh Sadasivan
Cc: ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] RE: IPFIX Architecture

Hello Will,
 
first of all I would like to say that  I do not think some of the stuff proposed by Ganesh/You is the right approach. I'm not saying Netflow is good or bad, I'm just do not think is the right think to do, no more no less.
 
If you give me consistent arguments I can easily be convinced otherwise. Other comments inline.
 
 ----Original Message-----
From: Will Eatherton [mailto:will@cisco.com]
Sent: Wednesday, February 06, 2002 9:31 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan
Cc: ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] RE: IPFIX Architecture
Reinaldo,
 
The notation for who is speaking in this thread is making me dizzy, but I would like to state in a different way what Ganesh is saying on the main
topic of this thread.  For the application of router export to a collector we are saying that allowing UDP without required capability negotiation (as an option) is important. 
 
why is important?
 
1. As I said, you exchange a mere few packets and both ends agree that Netflow will be the IPfix protocol (or LFAP, or Diameter, or whatever) and you are done. What you are trying to propose is to make the IETF protocol rigid under the "using experience gained from widely deployed protocols " umbrella in order to fit an already deployed protocol of a single vendor. Unfortunaltely I do not agree with that.
 
2. Ganesh also mentioned that this is data link stuff, which I said it wasn't true since BGP implements a similar mechanism (BTW proposed by Cisco).
 
3. Then he said we should have sequence number on the IPfix protocol under the "would help to have a consistent implementation across
transport " umbrella. My argument is that this is something to solve a specific UDP related problem only, and unless there is a better reason then the one above, no matter how you slide or dice it, we are wasting header space.
 
Also I don't understand the desire in this thread to dance tip-toe around the fact that there is already a widely deployed export protocol used in the application of routers export and we (in this case Ganesh) are giving you the feedback based on experience one vendor has gained from experience with that protocol.   
 
And I agreed to some of these stuff ! But unfortunately some of other feedback is biased to how Netflow is implemented. As i said, I just do not think some of the stuff proposed by Ganesh/You is the right thing to do, no more no less.
 
 We are seeing capability negotiation as complex 
 
why it's complex? You have similar functionality already working for BGP today. You also have similar functionality working for PPP and OSPF also today.
 
 
 , not a requirement, and are suggesting it should not be a MUST for IPFIX unless it isnt the goal of IPFIX to be implemented on routers (is it a probe spec only ?).  
 
huh? Anyway, I think what I'm proposing is fair for everybody since several protocols can fullfill the IPfix requirements (Netflow, LFAP, CRANE, Diameter).and make the negotiation phase independent of the protocol used for the data flow.
 
regards,
 
Reinaldo
 
 
------_=_NextPart_001_01C1AFFC.53935B30-- -- 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 Feb 7 14:43:55 2002 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 OAA07334 for ; Thu, 7 Feb 2002 14:43:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yu0Y-00068I-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 13:14:58 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yu0W-00067f-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 13:14:56 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g17JEOv08307; Thu, 7 Feb 2002 11:14:24 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC90437; Thu, 7 Feb 2002 11:14:47 -0800 (PST) Message-ID: <3C62D423.BA8F6413@cisco.com> Date: Thu, 07 Feb 2002 11:23:16 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tanja Zseby CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring References: <3C6113C9.2080604@fokus.fhg.de> <3C618E83.F1C57C73@cisco.com> <3C624791.6050909@fokus.fhg.de> Content-Type: multipart/alternative; boundary="------------145F08D9BC379412DAF348D3" Precedence: bulk Sender: majordomo listserver --------------145F08D9BC379412DAF348D3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Tanja, Tanja Zseby wrote: > Hi Ganesh > > I agree, that different applications can be consumer of IPFIX data. > Nevertheless, AAA defines a whole architecture for accounting and > itself provides input to accounting and billing applications. > Therefore I think we need to show how IPFIX and AAA can work together. > I agree that it is not the task of IPFIX to define the interfaces. And > maybe you are right, and the architecture document is not the rigtht > place for this. If Nevil writes something on relations to RTFM we > could put together a document on relations between IPFIX and other > WGs/frameworks. Or really start a applicability document with sections > for the target applications mentioned in the requirements draft. I think an applicability doc would be great to have considering that some many pieces outside IPFIX want to make use of the collected information. Thanks Ganesh > > > Regards > Tanja > > Ganesh Sadasivan wrote: > >> Hi Tanja, >> >> Tanja Zseby wrote: >> >> >> > Hi K.C., >> > >> > attached you can find my contributions to the architecture >> > document. >> > >> > - The first text contains some first thoughts on how IPFIX and AAA >> > could >> > communicate. >> > >> To me, this portion is entirely out of scope from an IPFIX arch >> point >> of view. >> This is more of an application which takes in flow records collected >> by the >> IPFIX collector. Similarly there could be other applications that >> use the >> collected flow records.IMO we should not be defining these >> interfaces in >> the archtecture. >> If there is something like an applicability doc, that would be a >> good place >> for this to go. But again the point is that IPFIX should not go all >> the way to >> define interfaces with each of the possible applications. >> >> >> >> > - The second text contains considerations on how IPFIX can be used >> > for >> > QoS monitoring. Maybe this can also go into the architecture >> > document >> > (Ram Gopal for instance had a section on "some applications for >> > IPFIX" >> > in his text). Or do you think this should be put into a separate >> > document ? >> > >> This also looks to be good for an applicability doc. >> Thanks >> Ganesh >> >> >> > Regards >> > Tanja >> > >> > -- >> > Dipl.-Ing. Tanja Zseby >> > FhI FOKUS/Global Networking Email: >> > zseby@fokus.fhg.de >> > Kaiserin-Augusta-Allee 31 Phone: >> > +49-30-3463-7153 >> > D-10589 Berlin, Germany Fax: >> > +49-30-3463-8153 >> > -------------------------------------------------------------------------------------- >> > "Living on earth is expensive but it includes a free trip around >> > the sun." (Anonymous) >> > -------------------------------------------------------------------------------------- >> > >> > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > -------------------------------------------------------------------------------------- > "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) > -------------------------------------------------------------------------------------- > > --------------145F08D9BC379412DAF348D3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Tanja,

Tanja Zseby wrote:

Hi Ganesh

I agree, that different applications can be consumer of IPFIX data. Nevertheless, AAA defines a whole architecture for accounting and itself provides input to accounting and billing applications. Therefore I think we need to show how IPFIX and AAA can work together. I agree that it is not the task of IPFIX to define the interfaces. And maybe you are right, and the architecture document is not the rigtht place for this. If Nevil writes something on relations to RTFM we could put together a document on relations between IPFIX and other WGs/frameworks. Or really start a applicability document with sections for the target applications mentioned in the requirements draft.

I think an applicability doc would be great to have considering that some many pieces
outside IPFIX want to make use of the collected information.
Thanks
Ganesh
 

Regards
Tanja

Ganesh Sadasivan wrote: 

Hi Tanja,

Tanja Zseby wrote:


Hi K.C.,

attached you can find my contributions to the architecture document.

- The first text contains some first thoughts on how IPFIX and AAA could
communicate.

To me, this portion is entirely out of scope from an IPFIX arch point
of view.
This is more of an application which takes in flow records collected by the
IPFIX collector. Similarly there could be other applications that use the
collected flow records.IMO we should not be defining these interfaces in
the archtecture.
If there is something like an applicability doc, that would be a good place
for this to go. But again the point is that IPFIX should not go all the way to
define interfaces with each of the possible applications.



- The second text contains considerations on how IPFIX can be used for
QoS monitoring. Maybe this can also go into the architecture document
 (Ram Gopal for instance had a section on "some applications for IPFIX"
in his text). Or do you think this should be put into a separate document ?

This also looks to be good for an applicability doc.
Thanks
Ganesh


Regards
Tanja

--
Dipl.-Ing. Tanja Zseby
FhI FOKUS/Global Networking                     Email: zseby@fokus.fhg.de
Kaiserin-Augusta-Allee 31                               Phone: +49-30-3463-7153
D-10589 Berlin, Germany                         Fax:   +49-30-3463-8153
--------------------------------------------------------------------------------------
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------


-- 
Dipl.-Ing. Tanja Zseby                                  
FhI FOKUS/Global Networking                     Email: zseby@fokus.fhg.de       
Kaiserin-Augusta-Allee 31                               Phone: +49-30-3463-7153
D-10589 Berlin, Germany                         Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------
 
--------------145F08D9BC379412DAF348D3-- -- 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 Feb 7 14:44:18 2002 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 OAA07346 for ; Thu, 7 Feb 2002 14:44:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Ytz0-00066S-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 13:13:22 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Ytyy-00065c-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 13:13:20 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g17JCne08517; Thu, 7 Feb 2002 11:12:49 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC90365; Thu, 7 Feb 2002 11:13:11 -0800 (PST) Message-ID: <3C62D3C2.C14FAB50@cisco.com> Date: Thu, 07 Feb 2002 11:21:39 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: will@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture References: <4F973E944951D311B6660008C7917CF00890ED0A@zsc4c008.us.nortel.com> Content-Type: multipart/alternative; boundary="------------19BBA878601AA5561576D283" Precedence: bulk Sender: majordomo listserver --------------19BBA878601AA5561576D283 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello Reinaldo, BGP does advertisements and not negotiation. The neighbours settle down for the least common set of advertised fields. But the most important point is that only the attributes that pertain to the BGP are negotiated and nothing outside its framework like transport connection, authentication (TCP MD5) etc. They are configured in the neighbours instead. Extending this to IPFIX framework, the only set of attribs that may need negotiation is templates and this too is optional. Atleast in router case I do not see a need to do this. BGP peers are not discovered or auto negotiated. They are configured instead. Negotiation is a great idea. But one has to look at the practical aspects also:) Thanks Ganesh Reinaldo Penno wrote: > Hello Will,first of all I would like to say that I do not think some > of the stuff proposed by Ganesh/You is the right approach. I'm not > saying Netflow is good or bad, I'm just do not think is the right > think to do, no more no less. If you give me consistent arguments I > can easily be convinced otherwise. Other comments inline.----Original > Message----- > From: Will Eatherton [mailto:will@cisco.com] > Sent: Wednesday, February 06, 2002 9:31 PM > To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan > Cc: ipfix-arch@net.doit.wisc.edu > Subject: RE: [ipfix-arch] RE: IPFIX Architecture > Reinaldo, > > The notation for who is speaking in this thread is making me > dizzy, but I would like to state in a different way what > Ganesh is saying on the maintopic of this thread. For the > application of router export to a collector we are saying > that allowing UDP without required capability negotiation > (as an option) is important.why is important? 1. As I said, > you exchange a mere few packets and both ends agree that > Netflow will be the IPfix protocol (or LFAP, or Diameter, or > whatever) and you are done. What you are trying to propose > is to make the IETF protocol rigid under the "using > experience gained from widely deployed protocols " umbrella > in order to fit an already deployed protocol of a single > vendor. Unfortunaltely I do not agree with that. 2. Ganesh > also mentioned that this is data link stuff, which I said it > wasn't true since BGP implements a similar mechanism (BTW > proposed by Cisco). 3. Then he said we should have sequence > number on the IPfix protocol under the "would help to have a > consistent implementation across > transport " umbrella. My argument is that this is something > to solve a specific UDP related problem only, and unless > there is a better reason then the one above, no matter how > you slide or dice it, we are wasting header space. Also I > don't understand the desire in this thread to dance tip-toe > around the fact that there is already a widely deployed > export protocol used in the application of routers export > and we (in this case Ganesh) are giving you the feedback > based on experience one vendor has gained from experience > with that protocol. And I agreed to some of these stuff ! > But unfortunately some of other feedback is biased to how > Netflow is implemented. As i said, I just do not think some > of the stuff proposed by Ganesh/You is the right thing to > do, no more no less. We are seeing capability negotiation as > complexwhy it's complex? You have similar functionality > already working for BGP today. You also have similar > functionality working for PPP and OSPF also today., not a > requirement, and are suggesting it should not be a MUST for > IPFIX unless it isnt the goal of IPFIX to be implemented on > routers (is it a probe spec only ?). huh? Anyway, I think > what I'm proposing is fair for everybody since several > protocols can fullfill the IPfix requirements (Netflow, > LFAP, CRANE, Diameter).and make the negotiation phase > independent of the protocol used for the data > flow.regards,Reinaldo > --------------19BBA878601AA5561576D283 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello Reinaldo,
   BGP does advertisements and not negotiation. The neighbours settle down for
   the least common set of advertised fields. But the most important point is that
   only the attributes that pertain to the BGP are negotiated and nothing outside its
   framework like transport connection, authentication (TCP MD5) etc.
  They are configured in the neighbours  instead.
   Extending this to IPFIX framework, the only set of attribs that may need negotiation is
   templates and this too is optional. Atleast in router case I do not see a need to do this.
   BGP peers are not discovered or auto negotiated. They are configured instead.
   Negotiation is a great idea. But one has to look at the practical aspects also:)
 

Thanks
Ganesh

Reinaldo Penno wrote:

 Hello Will,first of all I would like to say that  I do not think some of the stuff proposed by Ganesh/You is the right approach. I'm not saying Netflow is good or bad, I'm just do not think is the right think to do, no more no less. If you give me consistent arguments I can easily be convinced otherwise. Other comments inline.----Original Message-----
From: Will Eatherton [mailto:will@cisco.com]
Sent: Wednesday, February 06, 2002 9:31 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; Ganesh Sadasivan
Cc: ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] RE: IPFIX Architecture
Reinaldo,
The notation for who is speaking in this thread is making me dizzy, but I would like to state in a different way what Ganesh is saying on the maintopic of this thread.  For the application of router export to a collector we are saying that allowing UDP without required capability negotiation (as an option) is important.why is important? 1. As I said, you exchange a mere few packets and both ends agree that Netflow will be the IPfix protocol (or LFAP, or Diameter, or whatever) and you are done. What you are trying to propose is to make the IETF protocol rigid under the "using experience gained from widely deployed protocols " umbrella in order to fit an already deployed protocol of a single vendor. Unfortunaltely I do not agree with that. 2. Ganesh also mentioned that this is data link stuff, which I said it wasn't true since BGP implements a similar mechanism (BTW proposed by Cisco). 3. Then he said we should have sequence number on the IPfix protocol under the "would help to have a consistent implementation across
transport " umbrella. My argument is that this is something to solve a specific UDP related problem only, and unless there is a better reason then the one above, no matter how you slide or dice it, we are wasting header space. Also I don't understand the desire in this thread to dance tip-toe around the fact that there is already a widely deployed export protocol used in the application of routers export and we (in this case Ganesh) are giving you the feedback based on experience one vendor has gained from experience with that protocol. And I agreed to some of these stuff ! But unfortunately some of other feedback is biased to how Netflow is implemented. As i said, I just do not think some of the stuff proposed by Ganesh/You is the right thing to do, no more no less. We are seeing capability negotiation as complexwhy it's complex? You have similar functionality already working for BGP today. You also have similar functionality working for PPP and OSPF also today., not a requirement, and are suggesting it should not be a MUST for IPFIX unless it isnt the goal of IPFIX to be implemented on routers (is it a probe spec only ?). huh? Anyway, I think what I'm proposing is fair for everybody since several protocols can fullfill the IPfix requirements (Netflow, LFAP, CRANE, Diameter).and make the negotiation phase independent of the protocol used for the data flow.regards,Reinaldo
--------------19BBA878601AA5561576D283-- -- 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 Feb 7 14:55:09 2002 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 OAA07723 for ; Thu, 7 Feb 2002 14:55:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YuCY-0006Qm-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 13:27:22 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YuCX-0006QH-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 13:27:21 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g17JQoe19131; Thu, 7 Feb 2002 11:26:50 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC91002; Thu, 7 Feb 2002 11:27:12 -0800 (PST) Message-ID: <3C62D70C.E0FEFFDC@cisco.com> Date: Thu, 07 Feb 2002 11:35:40 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ram.gopal@nokia.com CC: Man.M.Li@nokia.com, ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Re: IPFIX Architecture writeup from Ram Gopal References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ram, See inline Ganesh ram.gopal@nokia.com wrote: > Hello Ganesh, > > Please see inline comments > > >> (2) > >> G: > >> The diagram is confusing. > >> Observation Point and exporter are 2 pieces of a single > >system and not > >> separate entities. > >> G: > >> > >> The logical functionalities are described whether u have > >everything in one piece > >> or distributed it is upto the implementation. > > > >The point here is that IPFIX does not try to define the > >interface between > >observation point and exporter. Showing it as 2 pieces lets > >one think why > >the interface between these 2 should not be defined. Showing > >the way Kevin > >Zhang has shown for the exporter part looks cleaner to me. > > We are defining the IPFIX endpoint and the protocol requirement for those endpoints. > Logically exporter and collector two different components, even we had talk with Kevin > also and merged the document into one. I think you view from logical functional point rather > than physical view - No one wants to have big monolithic piece. In the case of collector, you put 2 set of boxes [collector + App] [collector] [App] If you go by the arg. above it should be [ obsv. 1..n, exporter] [obsv 1..] [exporter]. > > > >> > >> > >> (3) > >> G: > >> Observation point is the place where metering is done. > >> I did not understand why it is an option. Metering includes > >> filtering also. > >> From > >http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt: > >> > >> 4. Metering Process > >> > >> The following are requirements for the metering process. They > >> describe the requirements for the process at the measurement > >> instance. All measurements MUST be conducted from the > >point of view > >> of the observation point. > >> ..... > >> G: > >> > >> Refer requirement document 1.1 IPFlow > >> > >> The observation point may be a network interface of a device or an > >> entire router, a probe, or a middlebox with several interfaces. > >> Properties derived from packet treatment include for example the > >> interface at which the packet arrived, the interface the > >packet will > >> be forwarded to and potentially some other information. > >> > >> So observation point is just a probe , for example typically > >we may have more than > >> one interface through which we would like to monitor the packet. > > > >In the above example the Observation point (the probe) is an > >aggregation > >of interfaces. The metering is also done logically at the > >probe level which > >gets split up into the individual interfaces depending on the > >implementation. > >But the collector sees the observation point as the metering entity. > >I agree that metering process is not very clear in the req spec. > > It is your view how you view the collector. Any architecture there will be a logical > division of functions, Collector may know where the observation points, as far the collector > is concerned it is communicating to the exporter not to the observation points. No, the point I wanted to convey is that observation point should be the logical place where the measuring is done as seen by the collector. > > > > >> (5) > >> > >> G: > >> It is the exporter who decides what to > >> measure , where to measure & what to send. We are not defining > >> how to configure a metering process from a collector. > >> - the exporter configuration is out of the scope of this document > >> - the exporter configuration SHOULD be done out of band > >> > >> G: > >> > >> This may be one implementation, but generally exporter does > >metering, and reporting functions and > >> more detailed in the document. > >> > >> Regarding configuration, what is said is one implementation. > >But collector should be able to > >> request (Configure) and get the required Flow information. > > > >For this the collector needs to understand the capability and > >to some extent the > >implementation of an exporter and this is a non-trivial > >problem to solve. > > It is your view, there is no problem in what we described, based on the Flow you will get > the statistics or the data to the collector. I think want to put everything in one piece. It is a bad idea. Exporter configuration should be out of scope to the IPFIX. Thanks Ganesh > > > > >> (6) > >> > >> G: > >> This is already covered in the req. spec.Is there a necessity > >> to repeat it here? > >> G: > >> > >> I think this sentence is rephrased and content of the > >sections are different. We added more text from other authors. > >> Hope compiled version of the document will give better picture. > > > >It is better to have another doc. called applicability doc or > >so rather than keeping > >it as a part of the architecture. > > I also agree with you, but we have only two documents as defined in charter. > > > -- 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 Feb 7 15:12:42 2002 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 PAA08265 for ; Thu, 7 Feb 2002 15:12:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yud1-0006yv-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 13:54:43 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yucz-0006yo-00 for ipfix@net.doit.wisc.edu; Thu, 07 Feb 2002 13:54:41 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA19339 for ; Thu, 7 Feb 2002 15:04:03 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma019302; Thu, 7 Feb 02 15:03:29 -0500 Received: by cnc-exc2.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 14:53:19 -0500 Message-ID: <0BF8B32B723ED5119E0B0002A551748B01FA0882@corp-exc3.ctron.com> From: "Harrington, David" To: ipfixx Subject: RE: [ipfix] RE: NAT (aka agenda) Date: Thu, 7 Feb 2002 14:53:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B011.14118670" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B011.14118670 Content-Type: text/plain Hi, Comments inline > -----Original Message----- > From: Wang, Cliff [mailto:CWang@smartpipes.com] > Sent: Friday, February 01, 2002 1:16 PM > To: Calato, Paul; ipfixx > Subject: [ipfix] RE: NAT (aka agenda) > > > Paul, > > I think we probably out of sync in the scenario we picture. I > think we have > potentially two scenarios: > 1) NAT is performing on the flow being reported. Yes I am > totally agree with > your analysis. > 2) NAT is between the probe and the collector. Actually I am > talking about > this case, where NAT performs on the reporting traffic. > > Again, I agree with your standing that if either probe or > collector knows > the NAT mapping, use it. Otherwise, it is out of the scope of > this WG to > find the NAT info. There is a concern that NAT hides what is actually happening on the network. In some cases this is desirable; in other cases it is not. For a billing application, it probably doesn't matter. The most likely billing scenario is a server farm with a NAT front-end, hiding the details of how the service is provided. The supplier is fairly likely to own both the back-end server and the front-end NAT device. For a network capacity planning application or a security application, and others, it may be very important to know that the flow actually occurred on a back-end server, which server it was, and possibly which front-end it was. Hiding the real network relationships makes it impossible to analyze the data in a useful way in situations where knowing the difference is important. Therefore, I think it is important to provide both addresses if both are known at the flow device, and for some applications it is important to not change the data in the report when passing through an ALG. See RFC2962 for a fuller discussion of the issues. dbh David Harrington Network Management Architect Office of the CTO Enterasys Networks > > cliff > > -----Original Message----- > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: Friday, February 01, 2002 11:53 AM > To: Wang, Cliff; ipfixx > Subject: Re: NAT (aka agenda) > > > "Wang, Cliff" wrote: > > > > Comments in line. > > > > -----Original Message----- > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > Sent: Friday, February 01, 2002 11:31 AM > > To: Wang, Cliff > > Subject: Re: Agenda > > > > "Wang, Cliff" wrote: > > > > > > Agree. But finding the NAT info should be out of the > scope of this > > > WG. > > > > Not sure what you mean by "finding the NAT info". How the > > device retrieves any of the info is beyond the scope > > of the WG. We just provide a way to report it. > > > > [cliff] we are saying the same thing. > > > > > > > > On the other hand, the collector may have to deal the nasty NAT > > > issue when the flow reported may contain address of a different > > > address space. How to interprete that address seems to me > something > > > we need to look at. > > > > > > The other issue is whether we will allow some kind of NAT > ALG, which > > > translate the address in the report. Thoughts? > > > > Collectors may do a lot of stuff based on information > > which they got from non-IPFIX sources. But we, I don't > > think, are investigating that. > > > > [cliff] > > What I am think are the following cases: > > 1) NAT does the report packet header address translation. > The payload > > is not touched. > > Then the question is the report may carry private address that > > collector may or may not recognize. > > > > 2) NAT does the report packet header address translation. > If ipfix ALG > > is built, it may also translate the IP address in the report. Then > > collector doesn't care the private address space at all. > But doing NAT > > ALG is difficult and may not be applicable all the time. > > Still not quite sure I follow. So let me go through > step by step and then you can point out where I've > gone off track. > > 1) If the reporting device does not know any NAT info > is can only report the IP's it sees in the packet. > No affect on IPFIX in this case. > > If the collector has no NAT knowledge, the reports > only show addresses seen. No affect on IPFIX. > > If the collector does have NAT knowledge it MAY > be able to report on public or private addresses > based on info it has. What ever the collector does > and how it does it in this case is outside IPFIX. > > > 2) the reporting device does have NAT knowledge. > Lets say the reporting device is the one performing > the translation. In this case IPFIX should provide > a way to report the private and public addresses for > the flow. This does affect IPFIX. > > If the collector has no NAT knowledge, it can make > use of the data reported by the device, but no new > requirements on IPFIX. > > If the collector has NAT knowledge, it can either use > the info provided by the reporting device or it's own > info. But no new requirements on IPFIX. > > > So as I see it, the only time the IPFIX WG takes NAT > into consideration is when the reporting device wants > to transport NAT related info for a particular flow. > > Paul > > > > > > > > > > -----Original Message----- > > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > > Sent: Friday, February 01, 2002 10:52 AM > > > To: Wang, Cliff > > > Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; > > > kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix > data; ipfix > > > chairs > > > Subject: Re: Agenda > > > > > > We should provide a way to report the NAT info if the > device knows > > > it. It is not a required field since not all devices will > have it. > > > IMHO it should be reported as attributes of one flow, not > multiple > > > flows. > > > > > > Paul > > > > > > "Wang, Cliff" wrote: > > > > > > > > The problem is that the NAT box is in the path and the > probe may > > > > not have any knowledge of the outside IP address it may get > > > > assigned. The collector may know the mapping if it knows the > > > > inside private address of the probe. > > > > > > > > -----Original Message----- > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > > > > Sent: Thursday, January 31, 2002 1:46 PM > > > > To: Reinaldo Penno > > > > Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth; > ipfix arch; > > > > ipfix data; ipfix chairs > > > > Subject: Re: Agenda > > > > > > > > Hi all > > > > > > > > > > > > > > > > > > > other comments (not necessarily to be discussed on the call) > > > > > Concerning some form of capabilities negotiation I have It is > > > > > also useful for the case of overlapping flows > (discussed on the > > > > > list) > > > > > > > > > > Middlebox: > > > > > What about when the device is also a middlebox ? > (sorry if this > > > > > was already hashed out on the list) If using NAT/NAPT > should the > > > > > device export the flow on the private side, public > side or both? > > > > > Should the behavior be agreed on the capabilities negotiation? > > > > > > > > It's in my mind the same behaviour as for unidirectional and > > > > bidirectional flows. > > > > In case the exporter has got the knowledge of the > bi-directional > > > > flows and in case the bi-directional information > make sense, the > > > > exporter MAY choose to export in the same > Template/Flow Record, > > > > along with bidirectional accounting information. > > > > So > > > > In case the exporter is doing NAT, the exporter MAY > choose to > > > > export > > > > > > > > in the same Template/Flow Record, both inside and > outside ip > > > > addresses > > > > > > > > This just implies that the information model MUST have > inside and > > > > outside IP addresses defined. > > > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > > > > I think the most useful behavior would be export the flows on > > > > > the private and public side within the same record (or if in > > > > > different records provide some key to bind them together), so > > > > > you know the complete flow end-to-end. But in this > case although > > > > > we have two seprate flows, it is still the same packet. Same > > > > > reasoning can be applied for proxy, proxy firewalls, etc. > > > > > > > > > > It would be impossible for a external probe to provde NAT > > > > > information. All it sees is the snapshot of what is > passing by. > > > > > This could be worked out as a MAY. Whether it is resolved or > > > > > not, we should clarify the stance on NAT in the archecture. > > > > > > > > > > > > > > > [Penno, Reinaldo [SC9:T327:EXCH]] > > > > > > > > > > I wouldn't say it's impossible. It depends if the > platform keeps > > > > > "memory" (full stateful NATs, proxies) or not . And > yes, I agree > > > > > that whatever the outcome we should clarify NAT/NAPT > behavior on > > > > > the doc. > > > > > > > > > > regards, > > > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > -- > 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/ > ------_=_NextPart_001_01C1B011.14118670 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] RE: NAT (aka agenda)

Hi,

Comments inline

> -----Original Message-----
> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> Sent: Friday, February 01, 2002 1:16 PM
> To: Calato, Paul; ipfixx
> Subject: [ipfix] RE: NAT (aka agenda)
>
>
> Paul,
>
> I think we probably out of sync in the scenario = we picture. I
> think we have
> potentially two scenarios:
> 1) NAT is performing on the flow being = reported. Yes I am
> totally agree with
> your analysis.
> 2) NAT is between the probe and the collector. = Actually I am
> talking about
> this case, where NAT performs on the reporting = traffic.
>
> Again, I agree with your standing that if = either probe or
> collector knows
> the NAT mapping, use it. Otherwise, it is out = of the scope of
> this WG to
> find the NAT info.

There is a concern that NAT hides what is actually = happening on the network. In some cases this is desirable; in other = cases it is not.

For a billing application, it probably doesn't = matter. The most likely billing scenario is a server farm with a NAT = front-end, hiding the details of how the service is provided. The = supplier is fairly likely to own both the back-end server and the = front-end NAT device.

For a network capacity planning application or a = security application, and others, it may be very important to know that = the flow actually occurred on a back-end server, which server it was, = and possibly which front-end it was. Hiding the real network = relationships makes it impossible to analyze the data in a useful way = in situations where knowing the difference is important.

Therefore, I think it is important to provide both = addresses if both are known at the flow device, and for some = applications it is important to not change the data in the report when = passing through an ALG.

See RFC2962 for a fuller discussion of the = issues.

dbh
David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks
 
>
> cliff
>
> -----Original Message-----
> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
> Sent: Friday, February 01, 2002 11:53 AM
> To: Wang, Cliff; ipfixx
> Subject: Re: NAT (aka agenda)
>
>
> "Wang, Cliff" wrote:
> >
> > Comments in line.
> >
> > -----Original Message-----
> > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
> > Sent: Friday, February 01, 2002 11:31 = AM
> > To: Wang, Cliff
> > Subject: Re: Agenda
> >
> > "Wang, Cliff" wrote:
> > >
> > > Agree. But finding the NAT info = should be out of the
> scope of this
> > > WG.
> >
> = >         Not sure what you = mean by "finding the NAT info". How the
> = >         device retrieves = any of the info is beyond the scope
> = >         of the WG. We just = provide a way to report it.
> >
> > [cliff] we are saying the same = thing.
> >
> > >
> > > On the other hand, the collector may = have to deal the nasty NAT
> > > issue when the flow reported may = contain address of a different
> > > address space. How to interprete that = address seems to me
> something
> > > we need to look at.
> > >
> > > The other issue is whether we will = allow some kind of NAT
> ALG, which
> > > translate the address in the report. = Thoughts?
> >
> = >         Collectors may do = a lot of stuff based on information
> = >         which they got = from non-IPFIX sources. But we, I don't
> = >         think, are = investigating that.
> >
> > [cliff]
> > What I am think are the following = cases:
> > 1) NAT does the report packet header = address translation.
> The payload
> > is not touched.
> >    Then the question is the = report may carry private address that
> > collector may or may not recognize.
> >
> > 2) NAT does the report packet header = address translation.
> If ipfix ALG
> > is built, it may also translate the IP = address in the report. Then
> > collector doesn't care the private address = space at all.
> But doing NAT
> > ALG is difficult and may not be applicable = all the time.
>
>       Still not quite = sure I follow. So let me go through
>       step by step and = then you can point out where I've
>       gone off = track.
>
>       1) If the = reporting device does not know any NAT info
>          is = can only report the IP's it sees in the packet.
>          No = affect on IPFIX in this case.
>
>          If = the collector has no NAT knowledge, the reports
>          = only show addresses seen. No affect on IPFIX.
>
>          If = the collector does have NAT knowledge it MAY
>          be = able to report on public or private addresses
>          = based on info it has. What ever the collector does
>          and = how it does it in this case is outside IPFIX.
>
>
>       2) the reporting = device does have NAT knowledge.
>          = Lets say the reporting device is the one performing
>          the = translation. In this case IPFIX should provide
>          a = way to report the private and public addresses for
>          the = flow. This does affect IPFIX.
>
>          If = the collector has no NAT knowledge, it can make
>          use = of the data reported by the device, but no new
>          = requirements on IPFIX.
>
>          If = the collector has NAT knowledge, it can either use
>          the = info provided by the reporting device or it's own
>          = info. But no new requirements on IPFIX.
>
>
>       So as I see it, = the only time the IPFIX WG takes NAT
>       into = consideration is when the reporting device wants
>       to transport NAT = related info for a particular flow.
>
>       Paul
>      
>
> >
> > >
> > > -----Original Message-----
> > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
> > > Sent: Friday, February 01, 2002 10:52 = AM
> > > To: Wang, Cliff
> > > Cc: 'Benoit Claise'; Reinaldo Penno; = Norseth, KC;
> > > kevin.zhang@xacct.com; K.C. Norseth; = ipfix arch; ipfix
> data; ipfix
> > > chairs
> > > Subject: Re: Agenda
> > >
> > > We should provide a way to report the = NAT info if the
> device knows
> > > it. It is not a required field since = not all devices will
> have it.
> > > IMHO it should be reported as = attributes of one flow, not
> multiple
> > > flows.
> > >
> > > Paul
> > >
> > > "Wang, Cliff" wrote:
> > > >
> > > > The problem is that the NAT box = is in the path and the
> probe may
> > > > not have any knowledge of the = outside IP address it may get
> > > > assigned. The collector may know = the mapping if it knows the
> > > > inside private address of the = probe.
> > > >
> > > > -----Original = Message-----
> > > > From: Benoit Claise [mailto:bclaise@cisco.com]
> > > > Sent: Thursday, January 31, 2002 = 1:46 PM
> > > > To: Reinaldo Penno
> > > > Cc: Norseth, KC; = kevin.zhang@xacct.com; K.C. Norseth;
> ipfix arch;
> > > > ipfix data; ipfix chairs
> > > > Subject: Re: Agenda
> > > >
> > > > Hi all
> > > >
> > > > >
> > > > >
> > > > > other comments (not = necessarily to be discussed on the call)
> > > > > Concerning some form of = capabilities negotiation I have It is
> > > > > also useful for the case of = overlapping flows
> (discussed on the
> > > > > list)
> > > > >
> > > > > Middlebox:
> > > > > What about when the device = is also a middlebox ?
> (sorry if this
> > > > > was already hashed out on = the list) If using NAT/NAPT
> should the
> > > > > device export the flow on = the private side, public
> side or both?
> > > > > Should the behavior be = agreed on the capabilities negotiation?
> > > >
> > > > It's in my mind the same = behaviour as for unidirectional and
> > > > bidirectional flows.
> > > >     In case = the exporter has got the knowledge of the
> bi-directional
> > > >     flows = and in case the bi-directional information
> make sense, the
> > > >     exporter = MAY choose to export in the same
> Template/Flow Record,
> > > >     along = with bidirectional accounting information.
> > > > So
> > > >     In case = the exporter is doing NAT, the exporter MAY
> choose to
> > > > export
> > > >
> > > >     in the = same Template/Flow Record, both inside and
> outside ip
> > > > addresses
> > > >
> > > > This just implies that the = information model MUST have
> inside and
> > > > outside IP addresses = defined.
> > > >
> > > > Regards, Benoit
> > > >
> > > > >
> > > > >
> > > > > I think the most useful = behavior would be export the flows on
> > > > > the private and public side = within the same record (or if in
> > > > > different records provide = some key to bind them together), so
> > > > > you know the complete flow = end-to-end. But in this
> case although
> > > > > we have two seprate flows, = it is still the same packet. Same
> > > > > reasoning can be applied = for proxy, proxy firewalls, etc.
> > > > >
> > > > > It would be impossible for = a external probe to provde NAT
> > > > > information. All it sees is = the snapshot of what is
> passing by.
> > > > > This could be worked out as = a MAY.  Whether it is resolved or
> > > > > not, we should clarify the = stance on NAT in the archecture.
> > > > >
> > > > >
> > > > > [Penno, Reinaldo = [SC9:T327:EXCH]]
> > > > >
> > > > > I wouldn't say it's = impossible. It depends if the
> platform keeps
> > > > > "memory" (full = stateful NATs, proxies) or not . And
> yes, I agree
> > > > > that whatever the outcome = we should clarify NAT/NAPT
> behavior on
> > > > > the doc.
> > > > >
> > > > > regards,
> > > > >
> > > > > Reinaldo
> > > > >
> > > > >
> > > > >
>
> --
> Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
> in message body
> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
> "unsubscribe ipfix" in message = body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B011.14118670-- -- 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 Feb 7 16:15:09 2002 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 QAA10055 for ; Thu, 7 Feb 2002 16:15:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yvbj-00019i-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 14:57:27 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yvbg-00018h-00 for ipfix@net.doit.wisc.edu; Thu, 07 Feb 2002 14:57:24 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g17KuKk02530; Thu, 7 Feb 2002 14:56:20 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVS03>; Thu, 7 Feb 2002 12:56:15 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890F183@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "Harrington, David" , ipfixx Subject: RE: [ipfix] RE: NAT (aka agenda) Date: Thu, 7 Feb 2002 12:56:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B019.E079E380" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B019.E079E380 Content-Type: text/plain; charset="iso-8859-1" Hello David, please refer to the MIDOCM discussion on the upcmong draft. I think I covered most of these issues. thanks, Reinaldo -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: Thursday, February 07, 2002 11:53 AM To: ipfixx Subject: RE: [ipfix] RE: NAT (aka agenda) Hi, Comments inline > -----Original Message----- > From: Wang, Cliff [ mailto:CWang@smartpipes.com ] > Sent: Friday, February 01, 2002 1:16 PM > To: Calato, Paul; ipfixx > Subject: [ipfix] RE: NAT (aka agenda) > > > Paul, > > I think we probably out of sync in the scenario we picture. I > think we have > potentially two scenarios: > 1) NAT is performing on the flow being reported. Yes I am > totally agree with > your analysis. > 2) NAT is between the probe and the collector. Actually I am > talking about > this case, where NAT performs on the reporting traffic. > > Again, I agree with your standing that if either probe or > collector knows > the NAT mapping, use it. Otherwise, it is out of the scope of > this WG to > find the NAT info. There is a concern that NAT hides what is actually happening on the network. In some cases this is desirable; in other cases it is not. For a billing application, it probably doesn't matter. The most likely billing scenario is a server farm with a NAT front-end, hiding the details of how the service is provided. The supplier is fairly likely to own both the back-end server and the front-end NAT device. For a network capacity planning application or a security application, and others, it may be very important to know that the flow actually occurred on a back-end server, which server it was, and possibly which front-end it was. Hiding the real network relationships makes it impossible to analyze the data in a useful way in situations where knowing the difference is important. Therefore, I think it is important to provide both addresses if both are known at the flow device, and for some applications it is important to not change the data in the report when passing through an ALG. See RFC2962 for a fuller discussion of the issues. dbh David Harrington Network Management Architect Office of the CTO Enterasys Networks > > cliff > > -----Original Message----- > From: calato@riverstonenet.com [ mailto:calato@riverstonenet.com ] > Sent: Friday, February 01, 2002 11:53 AM > To: Wang, Cliff; ipfixx > Subject: Re: NAT (aka agenda) > > > "Wang, Cliff" wrote: > > > > Comments in line. > > > > -----Original Message----- > > From: calato@riverstonenet.com [ mailto:calato@riverstonenet.com ] > > Sent: Friday, February 01, 2002 11:31 AM > > To: Wang, Cliff > > Subject: Re: Agenda > > > > "Wang, Cliff" wrote: > > > > > > Agree. But finding the NAT info should be out of the > scope of this > > > WG. > > > > Not sure what you mean by "finding the NAT info". How the > > device retrieves any of the info is beyond the scope > > of the WG. We just provide a way to report it. > > > > [cliff] we are saying the same thing. > > > > > > > > On the other hand, the collector may have to deal the nasty NAT > > > issue when the flow reported may contain address of a different > > > address space. How to interprete that address seems to me > something > > > we need to look at. > > > > > > The other issue is whether we will allow some kind of NAT > ALG, which > > > translate the address in the report. Thoughts? > > > > Collectors may do a lot of stuff based on information > > which they got from non-IPFIX sources. But we, I don't > > think, are investigating that. > > > > [cliff] > > What I am think are the following cases: > > 1) NAT does the report packet header address translation. > The payload > > is not touched. > > Then the question is the report may carry private address that > > collector may or may not recognize. > > > > 2) NAT does the report packet header address translation. > If ipfix ALG > > is built, it may also translate the IP address in the report. Then > > collector doesn't care the private address space at all. > But doing NAT > > ALG is difficult and may not be applicable all the time. > > Still not quite sure I follow. So let me go through > step by step and then you can point out where I've > gone off track. > > 1) If the reporting device does not know any NAT info > is can only report the IP's it sees in the packet. > No affect on IPFIX in this case. > > If the collector has no NAT knowledge, the reports > only show addresses seen. No affect on IPFIX. > > If the collector does have NAT knowledge it MAY > be able to report on public or private addresses > based on info it has. What ever the collector does > and how it does it in this case is outside IPFIX. > > > 2) the reporting device does have NAT knowledge. > Lets say the reporting device is the one performing > the translation. In this case IPFIX should provide > a way to report the private and public addresses for > the flow. This does affect IPFIX. > > If the collector has no NAT knowledge, it can make > use of the data reported by the device, but no new > requirements on IPFIX. > > If the collector has NAT knowledge, it can either use > the info provided by the reporting device or it's own > info. But no new requirements on IPFIX. > > > So as I see it, the only time the IPFIX WG takes NAT > into consideration is when the reporting device wants > to transport NAT related info for a particular flow. > > Paul > > > > > > > > > > -----Original Message----- > > > From: calato@riverstonenet.com [ mailto:calato@riverstonenet.com ] > > > Sent: Friday, February 01, 2002 10:52 AM > > > To: Wang, Cliff > > > Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC; > > > kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix > data; ipfix > > > chairs > > > Subject: Re: Agenda > > > > > > We should provide a way to report the NAT info if the > device knows > > > it. It is not a required field since not all devices will > have it. > > > IMHO it should be reported as attributes of one flow, not > multiple > > > flows. > > > > > > Paul > > > > > > "Wang, Cliff" wrote: > > > > > > > > The problem is that the NAT box is in the path and the > probe may > > > > not have any knowledge of the outside IP address it may get > > > > assigned. The collector may know the mapping if it knows the > > > > inside private address of the probe. > > > > > > > > -----Original Message----- > > > > From: Benoit Claise [ mailto:bclaise@cisco.com ] > > > > Sent: Thursday, January 31, 2002 1:46 PM > > > > To: Reinaldo Penno > > > > Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth; > ipfix arch; > > > > ipfix data; ipfix chairs > > > > Subject: Re: Agenda > > > > > > > > Hi all > > > > > > > > > > > > > > > > > > > other comments (not necessarily to be discussed on the call) > > > > > Concerning some form of capabilities negotiation I have It is > > > > > also useful for the case of overlapping flows > (discussed on the > > > > > list) > > > > > > > > > > Middlebox: > > > > > What about when the device is also a middlebox ? > (sorry if this > > > > > was already hashed out on the list) If using NAT/NAPT > should the > > > > > device export the flow on the private side, public > side or both? > > > > > Should the behavior be agreed on the capabilities negotiation? > > > > > > > > It's in my mind the same behaviour as for unidirectional and > > > > bidirectional flows. > > > > In case the exporter has got the knowledge of the > bi-directional > > > > flows and in case the bi-directional information > make sense, the > > > > exporter MAY choose to export in the same > Template/Flow Record, > > > > along with bidirectional accounting information. > > > > So > > > > In case the exporter is doing NAT, the exporter MAY > choose to > > > > export > > > > > > > > in the same Template/Flow Record, both inside and > outside ip > > > > addresses > > > > > > > > This just implies that the information model MUST have > inside and > > > > outside IP addresses defined. > > > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > > > > I think the most useful behavior would be export the flows on > > > > > the private and public side within the same record (or if in > > > > > different records provide some key to bind them together), so > > > > > you know the complete flow end-to-end. But in this > case although > > > > > we have two seprate flows, it is still the same packet. Same > > > > > reasoning can be applied for proxy, proxy firewalls, etc. > > > > > > > > > > It would be impossible for a external probe to provde NAT > > > > > information. All it sees is the snapshot of what is > passing by. > > > > > This could be worked out as a MAY. Whether it is resolved or > > > > > not, we should clarify the stance on NAT in the archecture. > > > > > > > > > > > > > > > [Penno, Reinaldo [SC9:T327:EXCH]] > > > > > > > > > > I wouldn't say it's impossible. It depends if the > platform keeps > > > > > "memory" (full stateful NATs, proxies) or not . And > yes, I agree > > > > > that whatever the outcome we should clarify NAT/NAPT > behavior on > > > > > the doc. > > > > > > > > > > regards, > > > > > > > > > > Reinaldo > > > > > > > > > > > > > > > > > -- > 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/ > ------_=_NextPart_001_01C1B019.E079E380 Content-Type: text/html; charset="iso-8859-1" RE: [ipfix] RE: NAT (aka agenda)
Hello David,
 
please refer to the MIDOCM discussion on the upcmong draft. I think I covered most of these issues.
 
thanks,
 
Reinaldo
-----Original Message-----
From: Harrington, David [mailto:dbh@enterasys.com]
Sent: Thursday, February 07, 2002 11:53 AM
To: ipfixx
Subject: RE: [ipfix] RE: NAT (aka agenda)

Hi,

Comments inline

> -----Original Message-----
> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> Sent: Friday, February 01, 2002 1:16 PM
> To: Calato, Paul; ipfixx
> Subject: [ipfix] RE: NAT (aka agenda)
>
>
> Paul,
>
> I think we probably out of sync in the scenario we picture. I
> think we have
> potentially two scenarios:
> 1) NAT is performing on the flow being reported. Yes I am
> totally agree with
> your analysis.
> 2) NAT is between the probe and the collector. Actually I am
> talking about
> this case, where NAT performs on the reporting traffic.
>
> Again, I agree with your standing that if either probe or
> collector knows
> the NAT mapping, use it. Otherwise, it is out of the scope of
> this WG to
> find the NAT info.

There is a concern that NAT hides what is actually happening on the network. In some cases this is desirable; in other cases it is not.

For a billing application, it probably doesn't matter. The most likely billing scenario is a server farm with a NAT front-end, hiding the details of how the service is provided. The supplier is fairly likely to own both the back-end server and the front-end NAT device.

For a network capacity planning application or a security application, and others, it may be very important to know that the flow actually occurred on a back-end server, which server it was, and possibly which front-end it was. Hiding the real network relationships makes it impossible to analyze the data in a useful way in situations where knowing the difference is important.

Therefore, I think it is important to provide both addresses if both are known at the flow device, and for some applications it is important to not change the data in the report when passing through an ALG.

See RFC2962 for a fuller discussion of the issues.

dbh
David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks
 
>
> cliff
>
> -----Original Message-----
> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com]
> Sent: Friday, February 01, 2002 11:53 AM
> To: Wang, Cliff; ipfixx
> Subject: Re: NAT (aka agenda)
>
>
> "Wang, Cliff" wrote:
> >
> > Comments in line.
> >
> > -----Original Message-----
> > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com]
> > Sent: Friday, February 01, 2002 11:31 AM
> > To: Wang, Cliff
> > Subject: Re: Agenda
> >
> > "Wang, Cliff" wrote:
> > >
> > > Agree. But finding the NAT info should be out of the
> scope of this
> > > WG.
> >
> >         Not sure what you mean by "finding the NAT info". How the
> >         device retrieves any of the info is beyond the scope
> >         of the WG. We just provide a way to report it.
> >
> > [cliff] we are saying the same thing.
> >
> > >
> > > On the other hand, the collector may have to deal the nasty NAT
> > > issue when the flow reported may contain address of a different
> > > address space. How to interprete that address seems to me
> something
> > > we need to look at.
> > >
> > > The other issue is whether we will allow some kind of NAT
> ALG, which
> > > translate the address in the report. Thoughts?
> >
> >         Collectors may do a lot of stuff based on information
> >         which they got from non-IPFIX sources. But we, I don't
> >         think, are investigating that.
> >
> > [cliff]
> > What I am think are the following cases:
> > 1) NAT does the report packet header address translation.
> The payload
> > is not touched.
> >    Then the question is the report may carry private address that
> > collector may or may not recognize.
> >
> > 2) NAT does the report packet header address translation.
> If ipfix ALG
> > is built, it may also translate the IP address in the report. Then
> > collector doesn't care the private address space at all.
> But doing NAT
> > ALG is difficult and may not be applicable all the time.
>
>       Still not quite sure I follow. So let me go through
>       step by step and then you can point out where I've
>       gone off track.
>
>       1) If the reporting device does not know any NAT info
>          is can only report the IP's it sees in the packet.
>          No affect on IPFIX in this case.
>
>          If the collector has no NAT knowledge, the reports
>          only show addresses seen. No affect on IPFIX.
>
>          If the collector does have NAT knowledge it MAY
>          be able to report on public or private addresses
>          based on info it has. What ever the collector does
>          and how it does it in this case is outside IPFIX.
>
>
>       2) the reporting device does have NAT knowledge.
>          Lets say the reporting device is the one performing
>          the translation. In this case IPFIX should provide
>          a way to report the private and public addresses for
>          the flow. This does affect IPFIX.
>
>          If the collector has no NAT knowledge, it can make
>          use of the data reported by the device, but no new
>          requirements on IPFIX.
>
>          If the collector has NAT knowledge, it can either use
>          the info provided by the reporting device or it's own
>          info. But no new requirements on IPFIX.
>
>
>       So as I see it, the only time the IPFIX WG takes NAT
>       into consideration is when the reporting device wants
>       to transport NAT related info for a particular flow.
>
>       Paul
>      
>
> >
> > >
> > > -----Original Message-----
> > > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com]
> > > Sent: Friday, February 01, 2002 10:52 AM
> > > To: Wang, Cliff
> > > Cc: 'Benoit Claise'; Reinaldo Penno; Norseth, KC;
> > > kevin.zhang@xacct.com; K.C. Norseth; ipfix arch; ipfix
> data; ipfix
> > > chairs
> > > Subject: Re: Agenda
> > >
> > > We should provide a way to report the NAT info if the
> device knows
> > > it. It is not a required field since not all devices will
> have it.
> > > IMHO it should be reported as attributes of one flow, not
> multiple
> > > flows.
> > >
> > > Paul
> > >
> > > "Wang, Cliff" wrote:
> > > >
> > > > The problem is that the NAT box is in the path and the
> probe may
> > > > not have any knowledge of the outside IP address it may get
> > > > assigned. The collector may know the mapping if it knows the
> > > > inside private address of the probe.
> > > >
> > > > -----Original Message-----
> > > > From: Benoit Claise [mailto:bclaise@cisco.com]
> > > > Sent: Thursday, January 31, 2002 1:46 PM
> > > > To: Reinaldo Penno
> > > > Cc: Norseth, KC; kevin.zhang@xacct.com; K.C. Norseth;
> ipfix arch;
> > > > ipfix data; ipfix chairs
> > > > Subject: Re: Agenda
> > > >
> > > > Hi all
> > > >
> > > > >
> > > > >
> > > > > other comments (not necessarily to be discussed on the call)
> > > > > Concerning some form of capabilities negotiation I have It is
> > > > > also useful for the case of overlapping flows
> (discussed on the
> > > > > list)
> > > > >
> > > > > Middlebox:
> > > > > What about when the device is also a middlebox ?
> (sorry if this
> > > > > was already hashed out on the list) If using NAT/NAPT
> should the
> > > > > device export the flow on the private side, public
> side or both?
> > > > > Should the behavior be agreed on the capabilities negotiation?
> > > >
> > > > It's in my mind the same behaviour as for unidirectional and
> > > > bidirectional flows.
> > > >     In case the exporter has got the knowledge of the
> bi-directional
> > > >     flows and in case the bi-directional information
> make sense, the
> > > >     exporter MAY choose to export in the same
> Template/Flow Record,
> > > >     along with bidirectional accounting information.
> > > > So
> > > >     In case the exporter is doing NAT, the exporter MAY
> choose to
> > > > export
> > > >
> > > >     in the same Template/Flow Record, both inside and
> outside ip
> > > > addresses
> > > >
> > > > This just implies that the information model MUST have
> inside and
> > > > outside IP addresses defined.
> > > >
> > > > Regards, Benoit
> > > >
> > > > >
> > > > >
> > > > > I think the most useful behavior would be export the flows on
> > > > > the private and public side within the same record (or if in
> > > > > different records provide some key to bind them together), so
> > > > > you know the complete flow end-to-end. But in this
> case although
> > > > > we have two seprate flows, it is still the same packet. Same
> > > > > reasoning can be applied for proxy, proxy firewalls, etc.
> > > > >
> > > > > It would be impossible for a external probe to provde NAT
> > > > > information. All it sees is the snapshot of what is
> passing by.
> > > > > This could be worked out as a MAY.  Whether it is resolved or
> > > > > not, we should clarify the stance on NAT in the archecture.
> > > > >
> > > > >
> > > > > [Penno, Reinaldo [SC9:T327:EXCH]]
> > > > >
> > > > > I wouldn't say it's impossible. It depends if the
> platform keeps
> > > > > "memory" (full stateful NATs, proxies) or not . And
> yes, I agree
> > > > > that whatever the outcome we should clarify NAT/NAPT
> behavior on
> > > > > the doc.
> > > > >
> > > > > regards,
> > > > >
> > > > > Reinaldo
> > > > >
> > > > >
> > > > >
>
> --
> 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/
>

------_=_NextPart_001_01C1B019.E079E380-- -- 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 Feb 7 16:31:16 2002 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 QAA10517 for ; Thu, 7 Feb 2002 16:31:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YvsW-0001bA-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 15:14:48 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YvsU-0001aY-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 15:14:46 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g17LE1k21442; Thu, 7 Feb 2002 15:14:01 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVTNS>; Thu, 7 Feb 2002 13:13:55 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890F1BB@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan Cc: will@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Date: Thu, 7 Feb 2002 13:13:54 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B01C.58E8CFF0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B01C.58E8CFF0 Content-Type: text/plain; charset="utf-8" Hello Ganesh, please refer to my comments. -----Original Message----- From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] Sent: Thursday, February 07, 2002 11:22 AM To: Penno, Reinaldo [SC9:T327:EXCH] Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture Hello Reinaldo, BGP does advertisements and not negotiation. The neighbours settle down for the least common set of advertised fields. oh Come on man (;-). That's dictionary play. It does capability negotiation through "advertisements" since in the BGP world peers send "advertisements" to each other. If you look at http://www.ietf.org/rfc/rfc2842.txt it's going to be clear that they want to settle down on a set of common optional parameters. You can call this something else, I call it capability negotiation, but the purpose is the same. But the most important point is that only the attributes that pertain to the BGP are negotiated and nothing outside its framework like transport connection, authentication (TCP MD5) etc. okay. So if we settle down that, for instance, UDP is the protocol of choice then we do not need to negotiate that. But if we do not settle for that, we need something to tell me what's going to be the transport protocol since I do not want to understand/icode/nterpret headers that I'm think are not useful if, for instance, I implemented with TCP. Also, I'm not advocating negotiating TCP options and things like that, it's only the transport protocol used. Any TCP options are done through TCP itself. The idea of CN is that in a heterogeneous network you only need to configure what the peers are, you do not need to say "ohh this is anetflow collector", this is a "CRANE exporter", "this is a IPfix v1 exporter", etc. okay, let me backtrack a little bit. did you read my capability negotiation write up? I proposed it as a totally different phase disconnect to any data flow. After the capability negotiation is done the connection is teared down and the protocol of choice gets to work. They are configured in the neighbours instead. Extending this to IPFIX framework, the only set of attribs that may need negotiation is templates and this too is optional. There are other parameters, please refer to the write up. Wouldn't be nice that instead of configuring netflow v1, v5, v9, etc to have this done automatically and knowing why it worked or not? What I'm proposing is a control communication completely orthogonal to the data communication. You do not need to change, for instance, netflow at all. It's not built in on the protocol like BGP. thanks, Reinaldo Atleast in router case I do not see a need to do this. BGP peers are not discovered or auto negotiated. They are configured instead. Negotiation is a great idea. But one has to look at the practical aspects also:) Thanks Ganesh ------_=_NextPart_001_01C1B01C.58E8CFF0 Content-Type: text/html; charset="utf-8"
Hello Ganesh,
 
please refer to my comments.
 
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, February 07, 2002 11:22 AM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] RE: IPFIX Architecture

Hello Reinaldo,
   BGP does advertisements and not negotiation. The neighbours settle down for
   the least common set of advertised fields.  
 
oh Come on man (;-). That's dictionary play. It does capability negotiation through "advertisements" since in the BGP world peers send "advertisements" to each other. If you look at http://www.ietf.org/rfc/rfc2842.txt it's going to be clear that they want to settle down on a set of common optional parameters. You can call this something else, I call it capability negotiation, but the purpose is the same.
 
 But the most important point is that
   only the attributes that pertain to the BGP are negotiated and nothing outside its
   framework like transport connection, authentication (TCP MD5) etc.  
 
okay. So if we settle down that, for instance, UDP is the protocol of choice then we do not need to negotiate that. But if we do not settle for that, we need something to tell me what's going to be the transport protocol since I do not want to understand/icode/nterpret headers that I'm think are not useful if, for instance, I implemented with TCP.
 
Also, I'm not advocating negotiating TCP options and things like that, it's only the transport protocol used. Any TCP options are done through TCP itself. The idea of CN is that in a heterogeneous network you only need to configure what the peers are, you do not need to say "ohh this is anetflow collector", this is a "CRANE exporter", "this is a IPfix v1 exporter", etc.
 
okay, let me backtrack a little bit. did you read my capability negotiation write up?  I proposed it as a totally different phase disconnect to any data flow. After the capability negotiation is done the connection is teared down and the protocol of choice gets to work.

  They are configured in the neighbours  instead.
   Extending this to IPFIX framework, the only set of attribs that may need negotiation is
   templates and this too is optional.  
 
There are other parameters, please refer to the write up. Wouldn't be nice that instead of configuring netflow v1, v5, v9, etc to have this done automatically and knowing why it worked or not? What I'm proposing is a control communication completely orthogonal to the data communication. You do not need to change, for instance, netflow at all.  It's not built in on the protocol like BGP.
 
thanks,
 
Reinaldo
 
 Atleast in router case I do not see a need to do this.
   BGP peers are not discovered or auto negotiated. They are configured instead.
   Negotiation is a great idea. But one has to look at the practical aspects also:)   

Thanks
Ganesh

 

------_=_NextPart_001_01C1B01C.58E8CFF0-- -- 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 Feb 7 16:43:26 2002 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 QAA10725 for ; Thu, 7 Feb 2002 16:43:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yw0s-0001oR-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 15:23:26 -0600 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yw0q-0001oI-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 15:23:24 -0600 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g17LNZQ18492 for ; Thu, 7 Feb 2002 15:23:35 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Feb 2002 15:23:22 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Feb 2002 15:23:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: [ipfix-arch] RE: IPFIX Architecture writeup from Ram Gopal Date: Thu, 7 Feb 2002 16:23:21 -0500 Message-ID: Thread-Topic: IPFIX Architecture writeup from Ram Gopal Thread-Index: AcGwDXrq6aShY3GjRKiE0HsUtgrFjQAEIo/Q From: To: Cc: , X-OriginalArrivalTime: 07 Feb 2002 21:23:22.0679 (UTC) FILETIME=[ABD99C70:01C1B01D] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA10725 Hello Ganesh, >> >> (2) >> >> G: >> >> The diagram is confusing. >> >> Observation Point and exporter are 2 pieces of a single >> >system and not >> >> separate entities. >> >> G: >> >> >> >> The logical functionalities are described whether u have >> >everything in one piece >> >> or distributed it is upto the implementation. >> > >> >The point here is that IPFIX does not try to define the >> >interface between >> >observation point and exporter. Showing it as 2 pieces lets >> >one think why >> >the interface between these 2 should not be defined. Showing >> >the way Kevin >> >Zhang has shown for the exporter part looks cleaner to me. >> >> We are defining the IPFIX endpoint and the protocol >requirement for those endpoints. >> Logically exporter and collector two different components, >even we had talk with Kevin >> also and merged the document into one. I think you view >from logical functional point rather >> than physical view - No one wants to have big monolithic piece. > >In the case of collector, you put 2 set of boxes >[collector + App] >[collector] [App] > >If you go by the arg. above it should be > >[ obsv. 1..n, exporter] >[obsv 1..] [exporter]. What we were conveyening is that different combications are possible. It is not forcing anything. You observe the figure and read the respective functionality of those subsystem. > >> >> 4. Metering Process >> >> >> >> The following are requirements for the metering process. They >> >> describe the requirements for the process at the measurement >> >> instance. All measurements MUST be conducted from the >> >point of view >> >> of the observation point. >> >> ..... >> >> G: >> >> >> >> Refer requirement document 1.1 IPFlow >> >> >> >> The observation point may be a network interface of a >device or an >> >> entire router, a probe, or a middlebox with several interfaces. >> >> Properties derived from packet treatment include for >example the >> >> interface at which the packet arrived, the interface the >> >packet will >> >> be forwarded to and potentially some other information. >> >> >> >> So observation point is just a probe , for example typically >> >we may have more than >> >> one interface through which we would like to monitor the packet. >> > >> >In the above example the Observation point (the probe) is an >> >aggregation >> >of interfaces. The metering is also done logically at the >> >probe level which >> >gets split up into the individual interfaces depending on the >> >implementation. >> >But the collector sees the observation point as the metering entity. >> >I agree that metering process is not very clear in the req spec. >> >> It is your view how you view the collector. Any architecture >there will be a logical >> division of functions, Collector may know where the >observation points, as far the collector >> is concerned it is communicating to the exporter not to the >observation points. > >No, the point I wanted to convey is that observation point >should be the logical >place where the measuring is done as seen by the collector. > Observation point is the point of observation it is logical. if you feel that observation point and the measurement is to be closely located fine and it is your view and that is why we have not defined any interface between Exporter and observation point. You think from generality and from specific implementation. >> >> (5) >> >> >> >> G: >> >> It is the exporter who decides what to >> >> measure , where to measure & what to send. We are not defining >> >> how to configure a metering process from a collector. >> >> - the exporter configuration is out of the scope of this document >> >> - the exporter configuration SHOULD be done out of band >> >> >> >> G: >> >> >> >> This may be one implementation, but generally exporter does >> >metering, and reporting functions and >> >> more detailed in the document. >> >> >> >> Regarding configuration, what is said is one implementation. >> >But collector should be able to >> >> request (Configure) and get the required Flow information. >> > >> >For this the collector needs to understand the capability and >> >to some extent the >> >implementation of an exporter and this is a non-trivial >> >problem to solve. >> >> It is your view, there is no problem in what we described, >based on the Flow you will get >> the statistics or the data to the collector. I think want to >put everything in one piece. > >It is a bad idea. Exporter configuration should be out of >scope to the IPFIX. I go by Kevin's argument, if you do configuration out-of-band ( as u mentioned earliar) no one stops that - but is a common mechanism which people may adopt . Regards Ramg ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Thu Feb 7 16:56:17 2002 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 QAA11002 for ; Thu, 7 Feb 2002 16:56:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YwF3-00027j-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 15:38:05 -0600 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YwF0-00026o-00 for ipfix@net.doit.wisc.edu; Thu, 07 Feb 2002 15:38:02 -0600 Received: from agile.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA07321; Thu, 7 Feb 2002 13:37:26 -0800 (PST) Received: from agile.yagosys.com (agile.yagosys.com [127.0.0.1]) by agile.yagosys.com (8.12.0/8.12.0) with ESMTP id g17LbQoa001410 for ; Thu, 7 Feb 2002 13:37:26 -0800 Received: (from mrm@localhost) by agile.yagosys.com (8.12.0/8.12.0/Submit) id g17LbPqo001409 for ipfix@net.doit.wisc.edu; Thu, 7 Feb 2002 13:37:25 -0800 Date: Thu, 7 Feb 2002 13:37:25 -0800 From: Michael MacFaden To: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: [ipfix-arch] RE: IPFIX Architecture Message-ID: <20020207133725.F1288@riverstonenet.com> References: <0BF8B32B723ED5119E0B0002A551748B01FA0874@corp-exc3.ctron.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0BF8B32B723ED5119E0B0002A551748B01FA0874@corp-exc3.ctron.com>; from dbh@enterasys.com on Thu, Feb 07, 2002 at 09:20:30AM -0500 X-Operating-System: GNU/Linux 2.4.17 Precedence: bulk Sender: majordomo listserver On Thu, Feb 07, 2002 at 09:20:30AM -0500, Harrington, David wrote: >I've seen working group after working group get hung up on the lower-level >transport layer issues with TCP versus UDP versus SCTP. > >I recommend that IPFIX take the modular approach - identify a transport >"box" in the architecture, then use a separate document to specify different >possible transport mappings, and the specifics of things like retries can be For an application to be successful in the real world, the application's requirements should dictate a primary transport. To support multple transports while supporting the "same" application would mean some functions must then also be moved to/from the application/transport. This is complex and leads to less interoperablity than we have now with proprietary protocols. To date, we have one hard requirement - use a flow controlled protocol. So either we use TCP/SCTP or use UDP with a flow control function in the application itself. Since we are not charted to do a "protocol" the choice is clear. Mike MacFaden -- 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 Feb 7 17:19:08 2002 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 RAA11398 for ; Thu, 7 Feb 2002 17:19:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Ywap-0002mM-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 16:00:35 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Ywan-0002jc-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 16:00:33 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g17M02v14142; Thu, 7 Feb 2002 14:00:02 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABC97415; Thu, 7 Feb 2002 14:00:24 -0800 (PST) Message-ID: <3C62FAF3.912C07EC@cisco.com> Date: Thu, 07 Feb 2002 14:08:51 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: will@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture References: <4F973E944951D311B6660008C7917CF00890F1BB@zsc4c008.us.nortel.com> Content-Type: multipart/alternative; boundary="------------A0D4B44E05352FAC2F240C30" Precedence: bulk Sender: majordomo listserver --------------A0D4B44E05352FAC2F240C30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 1. Embedding a set of protocols (netflow, crane, lfap) into IPFIX is a bad idea. There is nothing that we achieve out of this. One might as well use just the protocol and not IPFIX. A box usually would adopt only one export protocol and if it knows the collector there is no need for an IPFIX framework. 2. Automatically finding which transport one need to send on is only one small piece of information to setup the connection. One has to know the dst port to send on, TCP options like MD5 etc which needs to be configured at both ends anyways. Adding another piece of CLI or so to tell use TCP/UDP/. is much more simpler than creating a negotiation to do this. I really fail to understand what you gain in this whole process of negotiating transport and such rather than the added complexity!! 3. "Negotiation" is a multistep process where 2 sides try to converge as "advertisement" is just a broadcast of capabilities. At this point I wish someone else from the list also raised their opinion on this topic rather than we 2 debating with each other. Nevil, Dave, do you guys have any suggestions? Thanks Ganesh Reinaldo Penno wrote: > Hello Ganesh,please refer to my comments. > > -----Original Message----- > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] > Sent: Thursday, February 07, 2002 11:22 AM > To: Penno, Reinaldo [SC9:T327:EXCH] > Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu > Subject: Re: [ipfix-arch] RE: IPFIX Architecture > > Hello Reinaldo, > BGP does advertisements and not negotiation. The > neighbours settle down for > the least common set of advertised fields. oh Come on man > (;-). That's dictionary play. It does capability negotiation > through "advertisements" since in the BGP world peers send > "advertisements" to each other. If you look at > http://www.ietf.org/rfc/rfc2842.txt it's going to be clear > that they want to settle down on a set of common optional > parameters. You can call this something else, I call it > capability negotiation, but the purpose is the same. > > But the most important point is that > only the attributes that pertain to the BGP are > negotiated and nothing outside its > framework like transport connection, authentication (TCP > MD5) etc. okay. So if we settle down that, for instance, UDP > is the protocol of choice then we do not need to negotiate > that. But if we do not settle for that, we need something to > tell me what's going to be the transport protocol since I do > not want to understand/icode/nterpret headers that I'm think > are not useful if, for instance, I implemented with > TCP.Also, I'm not advocating negotiating TCP options and > things like that, it's only the transport protocol used. Any > TCP options are done through TCP itself. The idea of CN is > that in a heterogeneous network you only need to configure > what the peers are, you do not need to say "ohh this is > anetflow collector", this is a "CRANE exporter", "this is a > IPfix v1 exporter", etc.okay, let me backtrack a little bit. > did you read my capability negotiation write up? I proposed > it as a totally different phase disconnect to any data flow. > After the capability negotiation is done the connection is > teared down and the protocol of choice gets to work. > They are configured in the neighbours instead. > Extending this to IPFIX framework, the only set of > attribs that may need negotiation is > templates and this too is optional. There are other > parameters, please refer to the write up. Wouldn't be nice > that instead of configuring netflow v1, v5, v9, etc to have > this done automatically and knowing why it worked or not? > What I'm proposing is a control communication completely > orthogonal to the data communication. You do not need to > change, for instance, netflow at all. It's not built in on > the protocol like BGP.thanks,ReinaldoAtleast in router case > I do not see a need to do this. > BGP peers are not discovered or auto negotiated. They are > configured instead. > Negotiation is a great idea. But one has to look at the > practical aspects also:) Thanks > Ganesh > --------------A0D4B44E05352FAC2F240C30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 1. Embedding a set of  protocols (netflow, crane, lfap) into IPFIX is
    a bad idea. There is nothing that we achieve out of this. One might
   as well use just the protocol and not IPFIX. A box usually would
   adopt only one export protocol and if it knows the collector there is
   no need for an IPFIX framework.

2. Automatically finding which transport one need to send on is only one
   small piece of information to setup the connection. One has to know
   the dst port to send on, TCP options like MD5 etc which needs to
  be configured at both ends anyways. Adding another piece of CLI or
  so to tell use TCP/UDP/. is much more simpler than creating a negotiation
  to do this. I really fail to understand what you gain in this whole process
  of negotiating transport and such rather than the added complexity!!
 
3. "Negotiation" is a multistep process where 2 sides try to converge
   as "advertisement" is just a  broadcast of capabilities.

At this point I wish someone else from the list also raised
their opinion on this topic rather than we 2 debating with each other.
Nevil, Dave, do you guys have any suggestions?

Thanks
Ganesh

Reinaldo Penno wrote:

 Hello Ganesh,please refer to my comments.
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, February 07, 2002 11:22 AM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] RE: IPFIX Architecture
 
Hello Reinaldo,
   BGP does advertisements and not negotiation. The neighbours settle down for
   the least common set of advertised fields. oh Come on man (;-). That's dictionary play. It does capability negotiation through "advertisements" since in the BGP world peers send "advertisements" to each other. If you look at http://www.ietf.org/rfc/rfc2842.txt it's going to be clear that they want to settle down on a set of common optional parameters. You can call this something else, I call it capability negotiation, but the purpose is the same.
 
 But the most important point is that
   only the attributes that pertain to the BGP are negotiated and nothing outside its
   framework like transport connection, authentication (TCP MD5) etc. okay. So if we settle down that, for instance, UDP is the protocol of choice then we do not need to negotiate that. But if we do not settle for that, we need something to tell me what's going to be the transport protocol since I do not want to understand/icode/nterpret headers that I'm think are not useful if, for instance, I implemented with TCP.Also, I'm not advocating negotiating TCP options and things like that, it's only the transport protocol used. Any TCP options are done through TCP itself. The idea of CN is that in a heterogeneous network you only need to configure what the peers are, you do not need to say "ohh this is anetflow collector", this is a "CRANE exporter", "this is a IPfix v1 exporter", etc.okay, let me backtrack a little bit. did you read my capability negotiation write up?  I proposed it as a totally different phase disconnect to any data flow. After the capability negotiation is done the connection is teared down and the protocol of choice gets to work. 
  They are configured in the neighbours  instead.
   Extending this to IPFIX framework, the only set of attribs that may need negotiation is
   templates and this too is optional. There are other parameters, please refer to the write up. Wouldn't be nice that instead of configuring netflow v1, v5, v9, etc to have this done automatically and knowing why it worked or not? What I'm proposing is a control communication completely orthogonal to the data communication. You do not need to change, for instance, netflow at all.  It's not built in on the protocol like BGP.thanks,ReinaldoAtleast in router case I do not see a need to do this.
   BGP peers are not discovered or auto negotiated. They are configured instead.
   Negotiation is a great idea. But one has to look at the practical aspects also:) Thanks
Ganesh

--------------A0D4B44E05352FAC2F240C30-- -- 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 Feb 7 18:52:57 2002 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 SAA13363 for ; Thu, 7 Feb 2002 18:52:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yxzm-0004ok-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 17:30:26 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yxzj-0004nQ-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 17:30:23 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g17NTdk17527; Thu, 7 Feb 2002 17:29:40 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVV61>; Thu, 7 Feb 2002 15:29:39 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890F314@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan Cc: will@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Date: Thu, 7 Feb 2002 15:29:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B02F.4EE18AC0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B02F.4EE18AC0 Content-Type: text/plain; charset="utf-8" -----Original Message----- From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] Sent: Thursday, February 07, 2002 2:09 PM To: Penno, Reinaldo [SC9:T327:EXCH] Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture 1. Embedding a set of protocols (netflow, crane, lfap) into IPFIX is a bad idea. Nope, I'm embeding them into IPfix. Please refer to my write up. There is nothing that we achieve out of this. One might as well use just the protocol and not IPFIX. A box usually would adopt only one export protocol and if it knows the collector there is no need for an IPFIX framework. 2 . Automatically finding which transport one need to send on is only one small piece of information to setup the connection. One has to know the dst port to send on, TCP options like MD5 etc which needs to be configured at both ends anyways. Adding another piece of CLI or so to tell use TCP/UDP/. is much more simpler than creating a negotiation to do this. I really fail to understand what you gain in this whole process of negotiating transport and such rather than the added complexity!! So, why people did it for BGP, PPP, OSPF and others? Why not configure everything by hand? Why we have IKE? Why not pay someone to type in all keys in worlds in a on-demand basis everytime two systems want to use IPsec. Well, we do not even need networks. We just need big printers, truck loads of papers and a priority account with Federal Express. 3. "Negotiation" is a multistep process where 2 sides try to converge as "advertisement" is just a broadcast of capabilities. humpf...I'm not even going to comments on that. This seems to me a desperate argument. At this point I wish someone else from the list also raised their opinion on this topic rather than we 2 debating with each other. Nevil, Dave, do you guys have any suggestions? Thanks Ganesh Reinaldo Penno wrote: Hello Ganesh,please refer to my comments. -----Original Message----- From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com ] Sent: Thursday, February 07, 2002 11:22 AM To: Penno, Reinaldo [SC9:T327:EXCH] Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture Hello Reinaldo, BGP does advertisements and not negotiation. The neighbours settle down for the least common set of advertised fields. oh Come on man (;-). That's dictionary play. It does capability negotiation through "advertisements" since in the BGP world peers send "advertisements" to each other. If you look at http://www.ietf.org/rfc/rfc2842.txt it's going to be clear that they want to settle down on a set of common optional parameters. You can call this something else, I call it capability negotiation, but the purpose is the same. But the most important point is that only the attributes that pertain to the BGP are negotiated and nothing outside its framework like transport connection, authentication (TCP MD5) etc. okay. So if we settle down that, for instance, UDP is the protocol of choice then we do not need to negotiate that. But if we do not settle for that, we need something to tell me what's going to be the transport protocol since I do not want to understand/icode/nterpret headers that I'm think are not useful if, for instance, I implemented with TCP.Also, I'm not advocating negotiating TCP options and things like that, it's only the transport protocol used. Any TCP options are done through TCP itself. The idea of CN is that in a heterogeneous network you only need to configure what the peers are, you do not need to say "ohh this is anetflow collector", this is a "CRANE exporter", "this is a IPfix v1 exporter", etc.okay, let me backtrack a little bit. did you read my capability negotiation write up? I proposed it as a totally different phase disconnect to any data flow. After the capability negotiation is done the connection is teared down and the protocol of choice gets to work. They are configured in the neighbours instead. Extending this to IPFIX framework, the only set of attribs that may need negotiation is templates and this too is optional. There are other parameters, please refer to the write up. Wouldn't be nice that instead of configuring netflow v1, v5, v9, etc to have this done automatically and knowing why it worked or not? What I'm proposing is a control communication completely orthogonal to the data communication. You do not need to change, for instance, netflow at all. It's not built in on the protocol like BGP.thanks,ReinaldoAtleast in router case I do not see a need to do this. BGP peers are not discovered or auto negotiated. They are configured instead. Negotiation is a great idea. But one has to look at the practical aspects also:) Thanks Ganesh ------_=_NextPart_001_01C1B02F.4EE18AC0 Content-Type: text/html; charset="utf-8"
 
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, February 07, 2002 2:09 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] RE: IPFIX Architecture

1. Embedding a set of  protocols (netflow, crane, lfap) into IPFIX is
    a bad idea.  
 
Nope, I'm embeding them into IPfix. Please refer to my write up.
 
 There is nothing that we achieve out of this. One might
   as well use just the protocol and not IPFIX. A box usually would
   adopt only one export protocol and if it knows the collector there is
   no need for an IPFIX framework.  
 
 2 . Automatically finding which transport one need to send on is only one
   small piece of information to setup the connection. One has to know
   the dst port to send on, TCP options like MD5 etc which needs to
  be configured at both ends anyways. Adding another piece of CLI or
  so to tell use TCP/UDP/. is much more simpler than creating a negotiation
  to do this. I really fail to understand what you gain in this whole process
  of negotiating transport and such rather than the added complexity!!  
 
So, why people did it for BGP, PPP, OSPF and others? Why not configure everything by hand? Why we have IKE? Why not pay someone to type in all keys in worlds in a on-demand basis everytime two systems want to use IPsec.
 
Well, we do not even need networks. We just need big printers, truck loads of papers and  a priority account with Federal Express.
 
3. "Negotiation" is a multistep process where 2 sides try to converge
   as "advertisement" is just a  broadcast of capabilities.  
 
humpf...I'm not even going to comments on that. This seems to me a desperate argument. 
 
 At this point I wish someone else from the list also raised
their opinion on this topic rather than we 2 debating with each other.
Nevil, Dave, do you guys have any suggestions?

Thanks
Ganesh

Reinaldo Penno wrote:

 Hello Ganesh,please refer to my comments.
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, February 07, 2002 11:22 AM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] RE: IPFIX Architecture
 
Hello Reinaldo,
   BGP does advertisements and not negotiation. The neighbours settle down for
   the least common set of advertised fields. oh Come on man (;-). That's dictionary play. It does capability negotiation through "advertisements" since in the BGP world peers send "advertisements" to each other. If you look at http://www.ietf.org/rfc/rfc2842.txt it's going to be clear that they want to settle down on a set of common optional parameters. You can call this something else, I call it capability negotiation, but the purpose is the same.
 
 But the most important point is that
   only the attributes that pertain to the BGP are negotiated and nothing outside its
   framework like transport connection, authentication (TCP MD5) etc. okay. So if we settle down that, for instance, UDP is the protocol of choice then we do not need to negotiate that. But if we do not settle for that, we need something to tell me what's going to be the transport protocol since I do not want to understand/icode/nterpret headers that I'm think are not useful if, for instance, I implemented with TCP.Also, I'm not advocating negotiating TCP options and things like that, it's only the transport protocol used. Any TCP options are done through TCP itself. The idea of CN is that in a heterogeneous network you only need to configure what the peers are, you do not need to say "ohh this is anetflow collector", this is a "CRANE exporter", "this is a IPfix v1 exporter", etc.okay, let me backtrack a little bit. did you read my capability negotiation write up?  I proposed it as a totally different phase disconnect to any data flow. After the capability negotiation is done the connection is teared down and the protocol of choice gets to work. 
  They are configured in the neighbours  instead.
   Extending this to IPFIX framework, the only set of attribs that may need negotiation is
   templates and this too is optional. There are other parameters, please refer to the write up. Wouldn't be nice that instead of configuring netflow v1, v5, v9, etc to have this done automatically and knowing why it worked or not? What I'm proposing is a control communication completely orthogonal to the data communication. You do not need to change, for instance, netflow at all.  It's not built in on the protocol like BGP.thanks,ReinaldoAtleast in router case I do not see a need to do this.
   BGP peers are not discovered or auto negotiated. They are configured instead.
   Negotiation is a great idea. But one has to look at the practical aspects also:) Thanks
Ganesh

------_=_NextPart_001_01C1B02F.4EE18AC0-- -- 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 Feb 7 19:16:41 2002 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 TAA13695 for ; Thu, 7 Feb 2002 19:16:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YyPK-0005KZ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 17:56:50 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YyPI-0005Jo-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 17:56:48 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g17Nu4k22287; Thu, 7 Feb 2002 17:56:04 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVWH2>; Thu, 7 Feb 2002 15:56:03 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890F36A@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "Reinaldo Penno", Ganesh Sadasivan Cc: will@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Date: Thu, 7 Feb 2002 15:55:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B032.FCE2CD20" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B032.FCE2CD20 Content-Type: text/plain; charset="utf-8" Sorry, what I meant is regards, Reinaldo -----Original Message----- From: Penno, Reinaldo [SC9:T327:EXCH] Sent: Thursday, February 07, 2002 3:30 PM To: Ganesh Sadasivan Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture -----Original Message----- From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] Sent: Thursday, February 07, 2002 2:09 PM To: Penno, Reinaldo [SC9:T327:EXCH] Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture 1. Embedding a set of protocols (netflow, crane, lfap) into IPFIX is a bad idea. Nope, I'm embeding them into IPfix. Please refer to my write up. There is nothing that we achieve out of this. One might as well use just the protocol and not IPFIX. A box usually would adopt only one export protocol and if it knows the collector there is no need for an IPFIX framework. 2 . Automatically finding which transport one need to send on is only one small piece of information to setup the connection. One has to know the dst port to send on, TCP options like MD5 etc which needs to be configured at both ends anyways. Adding another piece of CLI or so to tell use TCP/UDP/. is much more simpler than creating a negotiation to do this. I really fail to understand what you gain in this whole process of negotiating transport and such rather than the added complexity!! So, why people did it for BGP, PPP, OSPF and others? Why not configure everything by hand? Why we have IKE? Why not pay someone to type in all keys in worlds in a on-demand basis everytime two systems want to use IPsec. Well, we do not even need networks. We just need big printers, truck loads of papers and a priority account with Federal Express. 3. "Negotiation" is a multistep process where 2 sides try to converge as "advertisement" is just a broadcast of capabilities. humpf...I'm not even going to comments on that. This seems to me a desperate argument. At this point I wish someone else from the list also raised their opinion on this topic rather than we 2 debating with each other. Nevil, Dave, do you guys have any suggestions? Thanks Ganesh Reinaldo Penno wrote: Hello Ganesh,please refer to my comments. -----Original Message----- From: Ganesh Sadasivan [ mailto:gsadasiv@cisco.com ] Sent: Thursday, February 07, 2002 11:22 AM To: Penno, Reinaldo [SC9:T327:EXCH] Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture Hello Reinaldo, BGP does advertisements and not negotiation. The neighbours settle down for the least common set of advertised fields. oh Come on man (;-). That's dictionary play. It does capability negotiation through "advertisements" since in the BGP world peers send "advertisements" to each other. If you look at http://www.ietf.org/rfc/rfc2842.txt it's going to be clear that they want to settle down on a set of common optional parameters. You can call this something else, I call it capability negotiation, but the purpose is the same. But the most important point is that only the attributes that pertain to the BGP are negotiated and nothing outside its framework like transport connection, authentication (TCP MD5) etc. okay. So if we settle down that, for instance, UDP is the protocol of choice then we do not need to negotiate that. But if we do not settle for that, we need something to tell me what's going to be the transport protocol since I do not want to understand/icode/nterpret headers that I'm think are not useful if, for instance, I implemented with TCP.Also, I'm not advocating negotiating TCP options and things like that, it's only the transport protocol used. Any TCP options are done through TCP itself. The idea of CN is that in a heterogeneous network you only need to configure what the peers are, you do not need to say "ohh this is anetflow collector", this is a "CRANE exporter", "this is a IPfix v1 exporter", etc.okay, let me backtrack a little bit. did you read my capability negotiation write up? I proposed it as a totally different phase disconnect to any data flow. After the capability negotiation is done the connection is teared down and the protocol of choice gets to work. They are configured in the neighbours instead. Extending this to IPFIX framework, the only set of attribs that may need negotiation is templates and this too is optional. There are other parameters, please refer to the write up. Wouldn't be nice that instead of configuring netflow v1, v5, v9, etc to have this done automatically and knowing why it worked or not? What I'm proposing is a control communication completely orthogonal to the data communication. You do not need to change, for instance, netflow at all. It's not built in on the protocol like BGP.thanks,ReinaldoAtleast in router case I do not see a need to do this. BGP peers are not discovered or auto negotiated. They are configured instead. Negotiation is a great idea. But one has to look at the practical aspects also:) Thanks Ganesh ------_=_NextPart_001_01C1B032.FCE2CD20 Content-Type: text/html; charset="utf-8"
Sorry, what I meant is <I'm NOT embedding them into IPfix data flow.>
 
regards,
 
Reinaldo
-----Original Message-----
From: Penno, Reinaldo [SC9:T327:EXCH]
Sent: Thursday, February 07, 2002 3:30 PM
To: Ganesh Sadasivan
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] RE: IPFIX Architecture

 
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, February 07, 2002 2:09 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] RE: IPFIX Architecture

1. Embedding a set of  protocols (netflow, crane, lfap) into IPFIX is
    a bad idea.  
 
Nope, I'm embeding them into IPfix. Please refer to my write up.
 
 There is nothing that we achieve out of this. One might
   as well use just the protocol and not IPFIX. A box usually would
   adopt only one export protocol and if it knows the collector there is
   no need for an IPFIX framework.  
 
 2 . Automatically finding which transport one need to send on is only one
   small piece of information to setup the connection. One has to know
   the dst port to send on, TCP options like MD5 etc which needs to
  be configured at both ends anyways. Adding another piece of CLI or
  so to tell use TCP/UDP/. is much more simpler than creating a negotiation
  to do this. I really fail to understand what you gain in this whole process
  of negotiating transport and such rather than the added complexity!!  
 
So, why people did it for BGP, PPP, OSPF and others? Why not configure everything by hand? Why we have IKE? Why not pay someone to type in all keys in worlds in a on-demand basis everytime two systems want to use IPsec.
 
Well, we do not even need networks. We just need big printers, truck loads of papers and  a priority account with Federal Express.
 
3. "Negotiation" is a multistep process where 2 sides try to converge
   as "advertisement" is just a  broadcast of capabilities.  
 
humpf...I'm not even going to comments on that. This seems to me a desperate argument. 
 
 At this point I wish someone else from the list also raised
their opinion on this topic rather than we 2 debating with each other.
Nevil, Dave, do you guys have any suggestions?

Thanks
Ganesh

Reinaldo Penno wrote:

 Hello Ganesh,please refer to my comments.
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, February 07, 2002 11:22 AM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] RE: IPFIX Architecture
 
Hello Reinaldo,
   BGP does advertisements and not negotiation. The neighbours settle down for
   the least common set of advertised fields. oh Come on man (;-). That's dictionary play. It does capability negotiation through "advertisements" since in the BGP world peers send "advertisements" to each other. If you look at http://www.ietf.org/rfc/rfc2842.txt it's going to be clear that they want to settle down on a set of common optional parameters. You can call this something else, I call it capability negotiation, but the purpose is the same.
 
 But the most important point is that
   only the attributes that pertain to the BGP are negotiated and nothing outside its
   framework like transport connection, authentication (TCP MD5) etc. okay. So if we settle down that, for instance, UDP is the protocol of choice then we do not need to negotiate that. But if we do not settle for that, we need something to tell me what's going to be the transport protocol since I do not want to understand/icode/nterpret headers that I'm think are not useful if, for instance, I implemented with TCP.Also, I'm not advocating negotiating TCP options and things like that, it's only the transport protocol used. Any TCP options are done through TCP itself. The idea of CN is that in a heterogeneous network you only need to configure what the peers are, you do not need to say "ohh this is anetflow collector", this is a "CRANE exporter", "this is a IPfix v1 exporter", etc.okay, let me backtrack a little bit. did you read my capability negotiation write up?  I proposed it as a totally different phase disconnect to any data flow. After the capability negotiation is done the connection is teared down and the protocol of choice gets to work. 
  They are configured in the neighbours  instead.
   Extending this to IPFIX framework, the only set of attribs that may need negotiation is
   templates and this too is optional. There are other parameters, please refer to the write up. Wouldn't be nice that instead of configuring netflow v1, v5, v9, etc to have this done automatically and knowing why it worked or not? What I'm proposing is a control communication completely orthogonal to the data communication. You do not need to change, for instance, netflow at all.  It's not built in on the protocol like BGP.thanks,ReinaldoAtleast in router case I do not see a need to do this.
   BGP peers are not discovered or auto negotiated. They are configured instead.
   Negotiation is a great idea. But one has to look at the practical aspects also:) Thanks
Ganesh

------_=_NextPart_001_01C1B032.FCE2CD20-- -- 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 Feb 7 19:29:36 2002 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 TAA13965 for ; Thu, 7 Feb 2002 19:29:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Yygb-0005jw-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 18:14:41 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Yyga-0005jU-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 18:14:40 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g180E9P18784; Thu, 7 Feb 2002 16:14:09 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABD02851; Thu, 7 Feb 2002 16:14:31 -0800 (PST) Message-ID: <3C631A62.B2FB6107@cisco.com> Date: Thu, 07 Feb 2002 16:22:58 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: will@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture References: <4F973E944951D311B6660008C7917CF00890F314@zsc4c008.us.nortel.com> Content-Type: multipart/alternative; boundary="------------782BD9EDC389FBB53F6941D3" Precedence: bulk Sender: majordomo listserver --------------782BD9EDC389FBB53F6941D3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 1. That's what I would say to you. Read your own draft before jumping into conclusion. 2. The way BGP and OSPF does their advertisment is very different from your proposal. Please read the respective RFCs for clarification. Compare that with your proposal and you can find what the diff. is between "negotiation" and "advertisement". I am stopping here and let the group decide which direction it wants to go. Regards Ganesh Reinaldo Penno wrote: > > > -----Original Message----- > From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] > Sent: Thursday, February 07, 2002 2:09 PM > To: Penno, Reinaldo [SC9:T327:EXCH] > Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu > Subject: Re: [ipfix-arch] RE: IPFIX Architecture > > 1. Embedding a set of protocols (netflow, crane, lfap) into > IPFIX is > a bad idea. Nope, I'm embeding them into IPfix. Please > refer to my write up.There is nothing that we achieve out of > this. One might > as well use just the protocol and not IPFIX. A box > usually would > adopt only one export protocol and if it knows the > collector there is > no need for an IPFIX framework. 2 . Automatically > finding which transport one need to send on is only one > small piece of information to setup the connection. One > has to know > the dst port to send on, TCP options like MD5 etc which > needs to > be configured at both ends anyways. Adding another piece > of CLI or > so to tell use TCP/UDP/. is much more simpler than > creating a negotiation > to do this. I really fail to understand what you gain in > this whole process > of negotiating transport and such rather than the added > complexity!! So, why people did it for BGP, PPP, OSPF and > others? Why not configure everything by hand? Why we have > IKE? Why not pay someone to type in all keys in worlds in a > on-demand basis everytime two systems want to use > IPsec. Well, we do not even need networks. We just need big > printers, truck loads of papers and a priority account with > Federal Express. > > 3. "Negotiation" is a multistep process where 2 sides try to > converge > as "advertisement" is just a broadcast of capabilities. > humpf...I'm not even going to comments on that. This seems > to me a desperate argument. At this point I wish someone > else from the list also raised > their opinion on this topic rather than we 2 debating with > each other. > Nevil, Dave, do you guys have any suggestions?Thanks > Ganesh > > Reinaldo Penno wrote: > > > Hello Ganesh,please refer to my comments. > > > > -----Original Message----- > > From: Ganesh Sadasivan > > [mailto:gsadasiv@cisco.com] > > Sent: Thursday, February 07, 2002 11:22 AM > > To: Penno, Reinaldo [SC9:T327:EXCH] > > Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu > > > > Subject: Re: [ipfix-arch] RE: IPFIX Architecture > > Hello Reinaldo, > > BGP does advertisements and not negotiation. > > The neighbours settle down for > > the least common set of advertised fields. oh > > Come on man (;-). That's dictionary play. It > > does capability negotiation through > > "advertisements" since in the BGP world peers > > send "advertisements" to each other. If you look > > at http://www.ietf.org/rfc/rfc2842.txt it's > > going to be clear that they want to settle down > > on a set of common optional parameters. You can > > call this something else, I call it capability > > negotiation, but the purpose is the same. > > > > But the most important point is that > > only the attributes that pertain to the BGP > > are negotiated and nothing outside its > > framework like transport connection, > > authentication (TCP MD5) etc. okay. So if we > > settle down that, for instance, UDP is the > > protocol of choice then we do not need to > > negotiate that. But if we do not settle for > > that, we need something to tell me what's going > > to be the transport protocol since I do not want > > to understand/icode/nterpret headers that I'm > > think are not useful if, for instance, I > > implemented with TCP.Also, I'm not advocating > > negotiating TCP options and things like that, > > it's only the transport protocol used. Any TCP > > options are done through TCP itself. The idea of > > CN is that in a heterogeneous network you only > > need to configure what the peers are, you do not > > need to say "ohh this is anetflow collector", > > this is a "CRANE exporter", "this is a IPfix v1 > > exporter", etc.okay, let me backtrack a little > > bit. did you read my capability negotiation > > write up? I proposed it as a totally different > > phase disconnect to any data flow. After the > > capability negotiation is done the connection is > > teared down and the protocol of choice gets to > > work. > > They are configured in the neighbours > > instead. > > Extending this to IPFIX framework, the only > > set of attribs that may need negotiation is > > templates and this too is optional. There are > > other parameters, please refer to the write up. > > Wouldn't be nice that instead of configuring > > netflow v1, v5, v9, etc to have this done > > automatically and knowing why it worked or not? > > What I'm proposing is a control communication > > completely orthogonal to the data communication. > > You do not need to change, for instance, netflow > > at all. It's not built in on the protocol like > > BGP.thanks,ReinaldoAtleast in router case I do > > not see a need to do this. > > BGP peers are not discovered or auto > > negotiated. They are configured instead. > > Negotiation is a great idea. But one has to > > look at the practical aspects also:) Thanks > > Ganesh > > --------------782BD9EDC389FBB53F6941D3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 1. That's what I would say to you. Read your own draft before
    jumping into conclusion.
2. The way  BGP and OSPF does their advertisment is very different
    from your proposal. Please read the respective RFCs for clarification.
    Compare that with your proposal and you can find what the diff. is
    between "negotiation" and "advertisement".

I am stopping here and let the group decide which direction it wants to go.

Regards
Ganesh

Reinaldo Penno wrote:

  
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, February 07, 2002 2:09 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] RE: IPFIX Architecture
 
1. Embedding a set of  protocols (netflow, crane, lfap) into IPFIX is
    a bad idea. Nope, I'm embeding them into IPfix. Please refer to my write up.There is nothing that we achieve out of this. One might
   as well use just the protocol and not IPFIX. A box usually would
   adopt only one export protocol and if it knows the collector there is
   no need for an IPFIX framework.  2 . Automatically finding which transport one need to send on is only one
   small piece of information to setup the connection. One has to know
   the dst port to send on, TCP options like MD5 etc which needs to
  be configured at both ends anyways. Adding another piece of CLI or
  so to tell use TCP/UDP/. is much more simpler than creating a negotiation
  to do this. I really fail to understand what you gain in this whole process
  of negotiating transport and such rather than the added complexity!! So, why people did it for BGP, PPP, OSPF and others? Why not configure everything by hand? Why we have IKE? Why not pay someone to type in all keys in worlds in a on-demand basis everytime two systems want to use IPsec. Well, we do not even need networks. We just need big printers, truck loads of papers and  a priority account with Federal Express.

3. "Negotiation" is a multistep process where 2 sides try to converge
   as "advertisement" is just a  broadcast of capabilities. humpf...I'm not even going to comments on that. This seems to me a desperate argument. At this point I wish someone else from the list also raised
their opinion on this topic rather than we 2 debating with each other.
Nevil, Dave, do you guys have any suggestions?Thanks
Ganesh

Reinaldo Penno wrote:

Hello Ganesh,please refer to my comments.
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, February 07, 2002 11:22 AM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] RE: IPFIX Architecture
Hello Reinaldo,
   BGP does advertisements and not negotiation. The neighbours settle down for
   the least common set of advertised fields. oh Come on man (;-). That's dictionary play. It does capability negotiation through "advertisements" since in the BGP world peers send "advertisements" to each other. If you look at http://www.ietf.org/rfc/rfc2842.txt it's going to be clear that they want to settle down on a set of common optional parameters. You can call this something else, I call it capability negotiation, but the purpose is the same.

But the most important point is that
   only the attributes that pertain to the BGP are negotiated and nothing outside its
   framework like transport connection, authentication (TCP MD5) etc. okay. So if we settle down that, for instance, UDP is the protocol of choice then we do not need to negotiate that. But if we do not settle for that, we need something to tell me what's going to be the transport protocol since I do not want to understand/icode/nterpret headers that I'm think are not useful if, for instance, I implemented with TCP.Also, I'm not advocating negotiating TCP options and things like that, it's only the transport protocol used. Any TCP options are done through TCP itself. The idea of CN is that in a heterogeneous network you only need to configure what the peers are, you do not need to say "ohh this is anetflow collector", this is a "CRANE exporter", "this is a IPfix v1 exporter", etc.okay, let me backtrack a little bit. did you read my capability negotiation write up?  I proposed it as a totally different phase disconnect to any data flow. After the capability negotiation is done the connection is teared down and the protocol of choice gets to work.
  They are configured in the neighbours  instead.
   Extending this to IPFIX framework, the only set of attribs that may need negotiation is
   templates and this too is optional. There are other parameters, please refer to the write up. Wouldn't be nice that instead of configuring netflow v1, v5, v9, etc to have this done automatically and knowing why it worked or not? What I'm proposing is a control communication completely orthogonal to the data communication. You do not need to change, for instance, netflow at all.  It's not built in on the protocol like BGP.thanks,ReinaldoAtleast in router case I do not see a need to do this.
   BGP peers are not discovered or auto negotiated. They are configured instead.
   Negotiation is a great idea. But one has to look at the practical aspects also:) Thanks
Ganesh

--------------782BD9EDC389FBB53F6941D3-- -- 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 Feb 7 20:26:41 2002 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 UAA15040 for ; Thu, 7 Feb 2002 20:26:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16YzZZ-0006ue-00 for ipfix-list@mil.doit.wisc.edu; Thu, 07 Feb 2002 19:11:29 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16YzZW-0006to-00 for ipfix-arch@net.doit.wisc.edu; Thu, 07 Feb 2002 19:11:27 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g181Afk16242; Thu, 7 Feb 2002 19:10:42 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFVXNV>; Thu, 7 Feb 2002 17:10:41 -0800 Message-ID: <4F973E944951D311B6660008C7917CF00890F3FA@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan Cc: will@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] RE: IPFIX Architecture Date: Thu, 7 Feb 2002 17:10:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B03D.6C733DF0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B03D.6C733DF0 Content-Type: text/plain; charset="utf-8" Hello Ganesh, -----Original Message----- From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] Sent: Thursday, February 07, 2002 4:23 PM To: Penno, Reinaldo [SC9:T327:EXCH] Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture 1. That's what I would say to you. Read your own draft before jumping into conclusion. 2. The way BGP and OSPF does their advertisment is very different from your proposal. Please read the respective RFCs for clarification. Compare that with your proposal and you can find what the diff. is between "negotiation" and "advertisement". I call this whole process negotiation. It's a "multistep" process as you like to call it. 1. peer A send OPEN message, 2. Peer B first determines if it supports capability negotiation. 3. If yes, it analyzes capabilities received and determine if they are acceptable. 4. If they are acceptable they proceed with the connection, 5. Otherwise Peer B sends a NOTIFICATION message including the offending optional capability. 6. Peer A receives the NOTIFICATION message and terminate the connection. It might retry to establish the connection later without this optional parameter. This interaction may happen several times. If this is not negotiation I do not know what this is. regards, Reinaldo ------_=_NextPart_001_01C1B03D.6C733DF0 Content-Type: text/html; charset="utf-8"
Hello Ganesh,
-----Original Message-----
From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
Sent: Thursday, February 07, 2002 4:23 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: will@cisco.com; ipfix-arch@net.doit.wisc.edu
Subject: Re: [ipfix-arch] RE: IPFIX Architecture

1. That's what I would say to you. Read your own draft before
    jumping into conclusion.
2. The way  BGP and OSPF does their advertisment is very different
    from your proposal. Please read the respective RFCs for clarification.
    Compare that with your proposal and you can find what the diff. is
    between "negotiation" and "advertisement".

I call this whole process negotiation.

It's a "multistep" process as you like to call it.

1. peer A send OPEN message,

2. Peer B first determines if it supports capability negotiation.

3. If yes,  it analyzes capabilities received and determine if they are acceptable.

4. If they are acceptable they proceed with the connection,

5. Otherwise Peer B sends a NOTIFICATION message including the offending optional capability.

6. Peer A  receives the NOTIFICATION message and terminate the connection. It might retry to establish the connection later without this optional parameter.

This interaction may happen several times. If this is not negotiation I do not know what this is.

regards,

Reinaldo

------_=_NextPart_001_01C1B03D.6C733DF0-- -- 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 Fri Feb 8 04:59:01 2002 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 EAA02269 for ; Fri, 8 Feb 2002 04:59:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16Z7Pa-0001R2-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 03:33:42 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16Z7PY-0001QW-00 for ipfix-arch@net.doit.wisc.edu; Fri, 08 Feb 2002 03:33:40 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g189WXj24141; Fri, 8 Feb 2002 10:32:33 +0100 (CET) Date: Fri, 8 Feb 2002 10:32:33 +0100 (CET) From: Benoit Claise Message-Id: <200202080932.g189WXj24141@bru-cse-222.cisco.com> To: bclaise@cisco.com, kevin.zhang@xacct.com Subject: RE: [ipfix-arch] Re: IPFIX Architecture Cc: gsadasiv@cisco.com, knorseth@enterasys.com, ipfix-arch@net.doit.wisc.edu X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver Kevin, My comments insides. Regards, Benoit. > > Hi Benoit, > > Please see my answers to some of your concerns. Thanks, > > Kevin > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Benoit Claise > > Sent: Wednesday, February 06, 2002 5:43 PM > > To: kevin.zhang@xacct.com > > Cc: Ganesh Sadasivan; KC' 'Norseth; ipfix-arch@net.doit.wisc.edu > > Subject: Re: [ipfix-arch] Re: IPFIX Architecture > > > > > > Hi Kevin, > > > > A couple of important points I would like to discuss amongst the > > group [I haven't copied the entire document] > > G: stands for Ganesh > > Kz: Kevin Zhang > > Ben: Benoit > > > > G: > > The underlying transport or other protocol is something which can be > > configured by the sys. admin., whatever the way he wants: > > CLI, SNMP, telnet, ... > > G: > > [kz3] What you are saying is correct. It depends on whether you > > want to do it in-band within the export protocol or > > out-band. However, do it within the protocol improves > > interoperability significantly which is exactly this WG is > > trying to achieve. > > [kz] > > > > [Ben] I don't know how it improves the interoperability to do the > > configuration inband. > > IPFIX stands for Flow Information eXport. So we have to > > standardize the export, not the configuration. So the > > direction:exporter -> collector and not the direction collector > > -> exporter. At least not for the configuration. > > Standardizing the configuration is a huge job. Do you think that > > vendors will spend time and money to developp again > > another configuration interface, next to CLI, SNMP, XML, etc...? > > And this just for an IPFIX protocol! > > What I'm thinking is that the configuration of the probe or the > > router is out of the scope of this document and is > > based on proprietary solutions. Proprietary solutions that you > > will very hardly standardize, because they all > > contains different proprietary features. > > [Ben] > > > [kz] Our objective is to achieve high interoperability through hopefully minimum standardization. Especially when multiple existing exporting protocols exist, we need to make both end-points aware of what protocol to use and what version to use, etc. By standarding the capability negotiation, both end-points can select the exporting mechanism they want to use. Otherwise, to achieve interoperability, we need to standardize a export protocol (e.g. Netflow, CRANE, LFAP, or Diameter), I am skeptical that the group will ever agree on one of them. > [kz] [Ben] I'm confused by your approach! You said: "Our objective is to achieve high interoperability..." But interoperability of what? You speak of multiple existing exporting protocols, what protocol/version to use... The goal is to have one new IPFIX protocol and not a collector that can once select Crane with a specific exporter, LFAP with another, IPFIX with a third one, Netflow with a four one, etc... If you speak of interoperability of IPFIX versions, we haven't yet started to agree on version 1. But if we all agree and do it right, I just hope that only the Information Model will evolve along the time, not the protocol If you speak of interoperability of different vendors, then I agree. And to come back to your initial statement of this thread: in-band provisioning of a IPFIX exporter improves interopability. I'm still not convinced at all. > > > > > [kz2] "capability negotiation" is a MUST, this is key for the > > IPFIX system to be flexible enough to deal with various > > exporting devices (besides core routers). Your view is > > router-centric, at least in a probes case, what to collect, > > how to collect, and when to export are typically configurable by > > the applications through the collector. > > Furthermore, exactly due to the existing infrastructure, > > "capability negotiation" would be key for the exporter and > > collector to understand what are the lower layer support (e.g. > > security, transport protocol, etc.) for the interace. > > [kz] > > > > [Ben] Well, I guess that I have a "router-centric" view as you call it ;) > > As I expressed before, my view is that, because the exporter > > configuration must happen out-of-band, capabilities > > negotiation should not happen. > > > > 1. Neither capabilities negotiation for the exported fields in a template: > > because the template is based on what the exporter can do, not on > > what a collector thinks an exporter can do. > > In other words, you configure the exporter template (by whatever > > means), the transport protocol and where to export. > > Then the collector must be able to parse all the fields of the template. > > I refer you to section 8 of > > http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal- > > 00.txt for more details > > of what I'm thinking. > > > > 2. Neither transport protocol negotiation. > > The transport protocol is the first thing you will decide on in > > an accounting network design (accouting being just a > > generic term). > > I mean, depending if you want to be billing or traffic > > monitoring, you may use a connection-oriented transport > > compared to UDP, with or without IPSEC. > > Basically, you won't change very often your transport protocol. > > So why would like to invest time in a transport protocol negotiation? > > I would say that this would be configured once for all before you > > even start exporting the first flow record. > > [Ben] > > > [kz] What to export should be determined jointly by the exporter and collector based upon end applications requirement and exporter's limitation. This is important if the exporter is a probe, the end application may only interested in some aspect of the flow information. "Capability negotiaton" allow you to achieve that. Transport layer negotiation is primarily reserved to accommadate future technologies, e.g. SCTP. > [kz] [Ben] I agree till: "What to export should be determined jointly by the exporter and collector based upon end applications requirement and exporter's limitation. This is important if the exporter is a probe, the end application may only interested in some aspect of the flow information." But you don't need a negotiation between the collector/exporter for that. I just call that provisioning. You want the Src IP address in your application, fine! You just configure it on the exporter. If you want your collector to do it, fine, but: - you don't need a negotiation for that - don't do the provisioning in-band (see the thread #1 above) And for transport protocol negotiation, I can't add more than David Harrington in his email: "I strongly recommend keeping the transport parameters out of the IPFIX message. The IPFIX message should be consistent no matter which transport is being used. Having lots of "optional" or conditional things in the IPFIX message will make it dramatically harder for the two ends of a communication to interoperate in a useful manner. The goal is to set a "standard" so behavior is consistent and each side knows how to do their part of the job. It can be a good thing to favor flexibility over rigidity in software development, but standards development is slightly different than software development, and the primary goal should be interoperability - that requires clearly defining the expectations. It is a GOOD thing to make the standard "rigid" so there is interoperability." This email contains a lot of common sense. > > > G: > > Fail-back is not possible on a router -> too much memory needed. > > The best we can do is fail-over. > > G: > > > > [kz6] I don't see big difference for memory requirement between > > fail-over and fail-back, would you please providing > > more details? > > [kz] > > > > [Ben] > > Fail-over means that as soon as you detect that the connection > > (only in case of a reliable transport protocol, not > > UDP) to the collector is lost, you can start sending to another > > collector. You may loose a few flow records depending > > on your transport protocol keepalive. > > Fail-back means that if we switch to another collection, we can' > > t loose any data. > > Again maybe a router-centric view ;), but Ganesh showed at the > > last IETF how much data we can produce per second when > > exporting from a router. > > > > I refer you to section 4.1.3 and 4.2.3 of > > http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt > > for more details of what I'm thinking. > > 4 Flow Export Protocol ................................... 9 > > 4.1 Simple Export Model .................................... 10 > > 4.1.1 Collector Crash ........................................ 10 > > 4.1.2 Collector Redundancy ................................... 10 > > 4.1.3 Collector Failover ..................................... 10 > > 4.2 Export Model with Reliable Control Connection .......... 10 > > 4.2.1 Collector Crash ........................................ 11 > > 4.2.2 Collector Redundancy ................................... 11 > > 4.2.3 Collector Failover ..................................... 12 > > [Ben] > > > [kz] I understand your concerns. [kz] > > > > > > - Re-sequencing the received IP flow information if required. In > > case a reliable, in-sequence delivery service is provided by lower > > layer protocol, this function can be omitted. > > G: > > If we have the timestamp per flow why is resequencing required > > G: > > [kz7] Timestamp is not sufficient to detect message losses, > > particularly when unreliable transport protocol is used. > > [kz] > > > > [Ben] > > Right, but you can still have a sequence ID in the packet which > > will tell you if you are loosing some packets. > > Is this what you have in mind when talking about re-sequencing? > > > > Regards, Benoit > > [Ben] > > > [kz] I think it's possible to include both sequence number and Timestamp in a user message [kz] This is what has been done in our proposal draft. Regards, Benoit. > > > > > > > > > > > -- > > 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/ > > > > > -- 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 Fri Feb 8 09:37:58 2002 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 JAA08148 for ; Fri, 8 Feb 2002 09:37:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZBfz-0001Cc-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 08:06:55 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZBfw-0001BI-00 for ipfix@net.doit.wisc.edu; Fri, 08 Feb 2002 08:06:53 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g18E6La68550 for ; Fri, 8 Feb 2002 15:06:21 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA30610 for ; Fri, 8 Feb 2002 15:06:21 +0100 Date: Fri, 08 Feb 2002 15:08:05 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] Terminology suggestion Message-ID: <3863571032.1013180885@[192.168.102.164]> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, Here is my suggestion for the IPFIX terminology. Maybe some more terms need to be defined, including 'flow rule', Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de 2.1. IP Traffic Flow or Flow see draft-ietf-ipfix-reqs-00.txt, section 1.1 2.2. Observation Point The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a port of a router, or an entire router with several ports. 2.3. Trafic Flow Meter or Meter A meter observes packets at one or more obsrvation points. It analyzes the content of the packets and maps them to flows. For each observed flow the meter computes statistics and maintains a flow record where it stores relevant flow infromation. 2.4. Metering Process The metering process includes all actions performed by a meter with respect to observing packets, timestamping them, analyzing them, mapping them to flows, computing flow statistics, detecting flow expiration, and maintaining flow records. 2.5. Flow Record A flow record keeps information a flow including characteristic properties of the flow, for example the source IP address, and measured properties of the flow, for example the total number of bytes of all packets of the flow. 2.6. Flow Information Exporter or Exporter The exporter sends flow records created and maintained by one or more meters to one or more data collectors. 2.7. Flow Information Data Collector or Data Colletor The data collector receives flow records from one or more exporters. The data collector might process or store received flow record, but these actions are out of the scope of this document. 2.8. Flow Information Export Flow information export denotes the process of transferring flow records from an exporter to a data collector. -- 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 Fri Feb 8 11:17:27 2002 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 LAA13214 for ; Fri, 8 Feb 2002 11:17:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZDQl-0003aI-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 09:59:19 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZDQi-0003ZO-00; Fri, 08 Feb 2002 09:59:16 -0600 Received: from riverstonenet.com (134.141.180.103 [134.141.180.103]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYW8ST; Fri, 8 Feb 2002 07:58:02 -0800 Message-ID: <3C63F588.63031219@riverstonenet.com> Date: Fri, 08 Feb 2002 10:58:00 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: kevin.zhang@xacct.com, "KC' 'Norseth" , ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Re: IPFIX Architecture References: <3C6176B4.54E9A400@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > - Supporting fail-over and fail-back procedures, and performing load > balancing if required. >G: >Fail-back is not possible on a router -> too much memory needed. >The best we can do is fail-over. >G: Not sure why. I think this is as simple as detecting the server is back and droping the existing connection in favor of the other. > - Supporting fail-over and fail-back procedures. > >G: >This should be an exporter feature and not a collector feature. >Are you suggesting an inter collector communication? >IMO this out of scope for this doc. >G: Collector to Collector communication is not in scope. Exporter to Collector is in scope and IMHO we need to define how and when to move between Collectors on a failure. > As the IPFIX system MUST be reliable, a reliable transport layer > protocol (e.g. TCP, SCTP) should be used. Furthermore, IPFIX layer > >G: > If the reliability is guarenteed by the network, is there a necessity > for a reliable transport? As we explained in IETF-52, there are > scalability concerns with TCP and making this mandartory would > exclude the exporters with high volume from being IPFIX compliant. >G: Transport level delivery is not the same as application level delivery. At minimum, a top of discussion for IPFIX is whether or not we are going to provide application level reliability in the protocol as an option. The reason you may want this is that only the collector can acknowledge when it has actually processed the information. For example, it may send an acknowldge when it has actually persisted the data. Ganesh Sadasivan wrote: > > Hi Kevin, > I have some comments on the arch spec portion. > There are between 2 "G:"s. > Thanks > Ganesh > > ------------------------------------------------------------------------ > > > 1 Scope > > This memo describes the architecture of an IP Flow Information eXport > (IPFIX) system. The IPFIX architecture provides a high level view of > key functions, interfaces, and protocols employed by the system, and > serves as a guide for design, engineering, and deployment of such > systems. > > The IPFIX architecture consists of > > - A reference model that depicts the key IPFIX entities and > interfaces. > > - Functional descriptions of IPFIX entities. > > - Detailed descriptions of capabilities in support of IPFIX > requirements. > > - Detailed descriptions of the relationship among IPFIX entities, > and definition of the IP flow information export interface that meets > the key requirements such as reliable, flexible, and efficient. > > - An IPFIX protocol architecture that present relationship among > various layers, and their communication requirements. > > 1.1 Specification of Requirements > > In this document, the keywords "MUST", "MUST NOT", "SHOULD", "SHOULD > NOT", and "MAY" are to be interpreted as described in BCP 14. These > keywords are not case sensitive in this document. > > 2 Terminology > > IPFIX Session > > An IPFIX Session is a logical connection between an exporter > entity and one or multiple collector entity for the purpose of > exporting IP flow information. Multiple sessions MAY be > maintained concurrently in an exporting device. > > Template > > A Template defines the structure of any types of IP flow > information record, and specifies the data type, meaning, and > location of the fields in the record. > > > 3 IPFIX Reference Model > > The following figure illustrates the reference model of an IPFIX > system. It identifies key IPFIX entities and interfaces within the > system. > > 3 > > > > +---------------+ +---------------+ > | +----------+ | | +----------+ | > | |Meter | | | |Processor | | > | |Entity | | | |Entity | | > | +----------+ |Exporting | +----------+ | > | +----------+ |Interface | +----------+ | > | |Exporter |<=|==========|=>|Collector | | > | |Entity | | | |Entity | | > | +----------+ | | +----------+ | > | Exporting | | Collection | > | Device | | Device | > +---------------+ +---------------+ > > An exporting device is typically a network element (e.g. routers, > measurement probes); a collection device may be part of mediation > systems, accounting/billing systems, and network management systems > to facilitate business and operation support. > > 3.1 IPFIX Entities > > 1.1.1 Exporter > > The primary task performed by the Exporter entity is to reliably, > timely, and efficiently deliver IP flow information to the collector > entity. The following functions are responsibilities of the exporter > entity: > G: > what does it timely mean? > We can compute the UTC time the flow started and ended. > G: > > - Participating in a capability negotiation process with the > collector entity in order to determine a commonly supported IPFIX > exporting mechanism (e.g. IPFIX protocol, and its versions) > > G: > Is the intention to make "capability negotiation" a MUST? > IMHO the collector should accept whatever is > being exporterd by the exporter. In most of the cases (atleast > from a router point of view) the collector is only an > intermediate box between the exporter and the final node that > interprets the export information. The job of the collector > from an information point of view would just be to grab all > that the exporter sends. > From an export protocol perspective, maybe it would make sense to > do some kind of negotiation. But here also with so much of > infrastructure existing already for reliability, security > etc the question is whether we want to come with a new model > or just concentrate on flow export.IMO there is no need for > negotiation. > G: > > > - Participating in control information exchanges with the collector > entity. The control information exchanges typically occur during the > initial establishment of the exporting session, and may include > procedures such as exporting session setup, security support, > capability negotiation, protocol negotiation, IP flow information > structure (template) negotiation, etc. > > G: > The underlying transport or other protocol is something which can be > configured by the sys. admin., whatever the way he wants: > CLI, SNMP, telnet, ... > G: > > - Establishing, maintaining, and removing the state associated with > an exporting session. > > - Generating, transmitting, and receiving IPFIX messages. The IPFIX > messages may include IPFIX control messages and IPFIX user messages. > > - Inserting IP flow information into IPFIX data messages according > to an encoding scheme. To enable efficient data export, a template > based encoding should be supported. > > G: > Sending exporter configuration is one of the most important control > information. > G: > > - Segmenting IP Flow information into multiple IPFIX user messages, > attaching required control information such as sequence numbers, > error checks, etc. > > - Releasing the transmitted and acknowledged IP flow information > from the memory. > G: > This is an implementation detail. Should be taken care of by the > transport. > G: > > - Supporting fail-over and fail-back procedures, and performing load > balancing if required. > G: > Fail-back is not possible on a router -> too much memory needed. > The best we can do is fail-over. > G: > > 1.1.2 Collector > > The primary task performed by the Collector entity is to receive and > acknowledge the IP flow information received from the exporter > entity. The following functions are responsibilities of the collector > entity: > > - Participating in the capability negotiation and control > information exchanges with the Exporter entity. > G: > Same concerns on capability negotiation as above. > G: > > - Establishing, maintaining, and removing the state associated with > an exporting session. > > - Generating, transmitting, and receiving IPFIX messages. > > - Receiving IPFIX user messages according to a decoding scheme, > checking message integrity, and acknowledging it after it is > correctly received or optionally processed and persisted in storage. > G: > I feel this should be taken care of by the lower layers. > G: > > - Re-sequencing the received IP flow information if required. In > case a reliable, in-sequence delivery service is provided by lower > layer protocol, this function can be omitted. > G: > If we have the timestamp per flow why is resequencing required > G: > > - Supporting fail-over and fail-back procedures. > > G: > This should be an exporter feature and not a collector feature. > Are you suggesting an inter collector communication? > IMO this out of scope for this doc. > G: > > 1.1.3 Meter > > The primary task performed by the meter entity is to monitor IP > flows, and derive IP flow information. How the meter entity measures > and derives flow information is outside the scope of the IPFIX > architecture, but the attributes used to describe flow information > must comply with the IPFIX information model and IP flow definitions. > > G: > The meter entity should interact with the exporter to export information > as to how the metering is done. > G: > > 1.1.4 Processor > > The primary task performed by the Processor entity is to process the > received IP flow information based upon end application.s > requirements. The functionality of the processor is outside the scope > of the IPFIX architecture, though the following functions should be > considered in designing and deploying an IPFIX system. > > G: > At the minimum the processor should be able to understand the > structure of the exported information. > G: > > - IP flow information aggregation based upon some aspects of IP > flows. > > - IP flow information filtering based upon some aspects of IP flows. > > > > 5 > > > - Query additional information (e.g. address translation, user > identification, etc.) related to an IP flow from other systems, to > facilitate further processing. > > - Persistent receive IP flow information > > 3.2 IPFIX Exporting Interface > > The IPFIX Exporting interface connects an exporter entity with one or > multiple collector entities. It MUST support the Internet Protocol > (IP) for data communications. > > G: > I guess V4 is a MUST, V6, MPLS is optional. > G: > > 4 IPFIX Deployment Scenarios > > IPFIX exporting devices may vary greatly in their core functionality. > At one hand, a core router needs to support high-speed interfaces and > traffic throughput; it emphasizes on forwarding IP traffic quickly > and may not be able to perform extensive measurement on IP flow. It > is also likely to export high volume of IP flow information to > external systems. On the other hand, a measurement probe or an > access device is capable of providing more detailed information about > IP flows and performing complex on-device processing. Consequently, > it may only export low volume of IP flow information. > > Given the diversity of exporting devices, two deployment scenarios > are described. These scenarios only serve as examples for IPFIX > system design and deployment. > > 4.1 Exporting Interface over LAN > > The following figure illustrates the scenarios where an exporting > device connects to the collecting devices over LAN. > > > +----------+ +----------+ +------------+ > |Exporting | |Collection|<==>| | > |Device | |Device 1 | |Applications| > +----------+ +----------+ |e.g. | > ^ | ^ | |usage | > | v | v |accounting, | > --------------------------------------- |traffic | > LAN |profiling, | > --------------------------------------- |traffic | > ^ | |engineering,| > | v |QoS | > +----------+ |Monitoring | > |Collection|<==================>|etc. | > |Device 2 | | | > +----------+ +------------+ > > This scenario is suitable for collecting information from core > routers. As the volume of exported data is typically high, LAN can > > > 6 > > > provide adequate bandwidth and introduce small latency to meet data > exporting requirement. > > G: > It is also important that the exporting overheads are minimized > to handle the high volume. Features like reliability > G: > > 4.2 Exporting Interface over WAN > > The following figure illustrates the scenario where an exporting > device connects to the collecting devices over WAN. > > +----------+ > |Collection| +------------+ > |Device 1 |<==========>| | > +----------+ |Applications| > ^ |e.g. | > | |usage | > +----------+ +--|-------+ |accounting, | > |Exporting |<--------|--- | |traffic | > |Device |<--------|--------- | |profiling, | > +----------+ | WAN | | |traffic | > | | | |engineering,| > | | | |QoS | > +--------|-+ |Monitoring | > | |etc. | > v | | > +----------+ | | > |Collection|<==========>| | > |Device 2 | +------------+ > +----------+ > > This scenario maybe used to collect information from probes or access > routers. It is critical that a congestion aware transport protocol > (e.g. TCP, SCTP) is used. > > 5 Protocol Architecture > > The following figure illustrates the protocol architecture in > supporting of the IPFIX system. > > > > 7 > > > > Exporting Device Collecting Device > +----------------+ +----------------+ > | IPFIX | | IPFIX | > | User | | User | > +----------------+ +----------------+ > | IPFIX | | IPFIX | > | Layer | | Layer | > +----------------+ +----------------+ > | Transport | | Transport | > | Layer | | Layer | > +----------------+-------------+----------------+ > | IP Layer | > +-----------------------------------------------+ > > The IFPIX protocol is designed an application running over a > transport layer protocol. The transport layer protocol is responsible > for delivering IPFIX messages between exporters and collectors. > > As the IPFIX system MUST be reliable, a reliable transport layer > protocol (e.g. TCP, SCTP) should be used. Furthermore, IPFIX layer > > G: > If the reliability is guarenteed by the network, is there a necessity > for a reliable transport? As we explained in IETF-52, there are > scalability concerns with TCP and making this mandartory would > exclude the exporters with high volume from being IPFIX compliant. > G: > > acknowledgement and flow control mechanisms should be supported to > ensure flow information is not only correctly received, but also > processed and persistent at the collection device. > > G: > Why all these are mandatory for IPFIX layer. I agree the framework > should take care of this. But if there is a capability already > available why re-invent? > G: > > 6 IPFIX Information Model > > The IPFIX information model is listed in the IPFIX requirement > document. The information model consists of the minimum set of > attributes that an IPFIX exporting device should be able to export. > In conjunction with IP flow definitions, they provide locally > accurate information about a flow. > > To meet application.s requirement may require the collection device > to obtain additional information about the flow, e.g. address > translation, user identification, etc. Additional flow information > may also be required; in this case, equipment vendors may define > extensions to the IPFIX information model. Any extension to the > IPFIX information model should be conveyed between end points. > > This section presents a rigorous definition and sufficient statistics > for these attributes. > G: > I guess this should be maintained in the requirements doc and > not duplicated. There are lots of comments on this section. > G: > > 6.1 Attributes related to IP Packet Header > > The following attributes are obtained directly from IP packet header > belonging to a flow: > G: > What is meant by flow in the above sentence? > G: > > - IP Version Number > G: > Why? Can't this be derived from address itself? > G: > > - Source Address > - Destination Address > G: > I suggest we keep separate field types for V4 and V6. > G: > There would be more like inner IP, outer IP etc within v4 and v6. > It is better each of such attribute is enumerated. > > - Protocol Type > - TOS (for version 4) > G: > Why not for V6? > G: > > - Flow Label (for version 6) > - DSCP (if DiffServ is supported) > G: > This is an incomplete list. What about L4 headers? > G: > > 8 > > > > 6.2 Attributes Related to Measurement > > The following attributes relates to measurements and > measuring methodology: > - Packet Counter > - Dropped Packet Counter > - Payload Byte Counter > - Timestamp of the First Packet Observed > - Timestamp of the Last Packet Observed > - Timeout Indication > - Sampling Method > - Sampling Parameters > > 6.3 Attributes Related to Flow Definition > > The following attributes relates to IP flow definitions. > > - Incoming Interface > - Outgoing Interface > - Packet Treatment > - Unique ID of the Observation Point > - Unique ID of the Measuring Device > > 6.4 Attributes related to Upper Layers > > The following attributes provides information of upper > layer protocols. > - Source Port Address > - MPLS Label (if MPLS is supported) > > > 7 IPFIX Message Format > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version |Message ID(MID)| Session ID | Message Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Message Payload ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > G: > The message should have the follwoing > - sequence number if the collector wishes to sequence the packets. > - the absolute time at which the message was sent and sysUpTime. > - an ID to identify the exporter if the collector receives packets > from multiple exporters. Why does one need a session ID? > G: > > Version: 8 bit unsigned integer > > The Version field indicates the IPFIX protocol implementation. > > Message ID (MID): 8 bit unsigned integer > > The Message ID field identifies the type of the message. > > > 9 > > > Session ID: 8 bit unsigned char > > The Session ID field identifies the IPFIX exporting session > with which the message is associated. > > Message Flags: 8 bit unsigned char > > The Message Flags field can be used to identify options > associated with the message. > > Message Length: 32 bit unsigned integer > > The Message Length field is the total length of the IPFIX > message in octet including the header. > > Message Payload: Variable Length > > It contains the control or user information exchanged between > IPFIX end-points (exporter and collector entities). > > 8 IPFIX Messages > > To be added > > 9 IPFIX Template > > The IPFIX system MUST support efficient exporting of IP flow > information. This can be achieved by negotiating a set of IPFIX > Templates for an IPFIX session before actual IP flow information is > exported. > > G: > Templates can be exchanged at any time. This may be done > as a result of a config change in the exporter or it may be a > periodic update. > G: > > A template defines the structure of an IPFIX user message > payload by describing the data type, meaning, and location of the > fields in the payload. By agreeing on IPFIX templates, IPFIX end- > points understand how to process IPFIX user messages. As a result, > an exporting device only needs to export actual flow information > without attaching any descriptors of the attributes; this reduces > the amount of bytes sent over communication links. > > G: > I do not understand, how the collector can interpret pure data > records without any descriptors as to what template it represents. > G: > > A template is an ordered list of keys. A key specifies an attribute > that a meter entity MAY export. The specification MUST consist of > the description and the data type of the attribute. (e.g. 'Number of > Sent Bytes' can be a key that is an 32 bit unsigned integer) An > exporting device typically defines keys. Based on the IPFIX > information model, a set of IPFIX standard keys can be defined. > > 9.1 Template Negotiation > > During the initial setup of an IPFIX session, template negotiation > procedures should be carried out. It would allow all the IPFIX end- > points to synchronize on a set of templates that will be used during > IP flow information export. > > G: > As I said above I really do not agree to this model. > G: > > G: > In short the fundamental aspects of disagreement are: > - no template/capabilities/etc... negotiation in IPFIX > - no MUST for reliable > - no state information (except based on the transport protocol, if > connection oriented) > - no connection initiated from the collector. > G: > > 10 Capability Negotiation > > > 10 > > > To be added > > 11 Redundancy and Error Handling > > To be added > > 12 Author's Address > > Questions about this memo can be directed to: > > Kevin Zhang > XACCT Technologies, Inc. > 2900 Lakeside Drive > Santa Clara, CA 95054 > Phone +1 301 992 4697 > Email: kevin.zhang@xacct.com -- 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 Fri Feb 8 11:29:31 2002 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 LAA13752 for ; Fri, 8 Feb 2002 11:29:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZDUd-0003it-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 10:03:19 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZDUb-0003i9-00; Fri, 08 Feb 2002 10:03:17 -0600 Received: from riverstonenet.com (134.141.180.103 [134.141.180.103]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYW8TW; Fri, 8 Feb 2002 08:02:06 -0800 Message-ID: <3C63F67C.F98BDDCC@riverstonenet.com> Date: Fri, 08 Feb 2002 11:02:04 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ram.gopal@nokia.com CC: gsadasiv@cisco.com, kevin.zhang@xacct.com, knorseth@enterasys.com, ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu, Man.M.Li@nokia.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture writeup from Ram Gopal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit ram.gopal@nokia.com wrote: > > Hello Ganesh, > > see my line comments. > > (1) > G: > I'm not sure what can be done in connection with AAA or > other protocol here? > G: > > We fixed the sentence > > (2) > G: > The diagram is confusing. > Observation Point and exporter are 2 pieces of a single system and not > separate entities. > G: > > The logical functionalities are described whether u have everything in one piece > or distributed it is upto the implementation. > > (3) > G: > Observation point is the place where metering is done. > I did not understand why it is an option. Metering includes > filtering also. > From http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt: > > 4. Metering Process > > The following are requirements for the metering process. They > describe the requirements for the process at the measurement > instance. All measurements MUST be conducted from the point of view > of the observation point. > ..... > G: > > Refer requirement document 1.1 IPFlow > > The observation point may be a network interface of a device or an > entire router, a probe, or a middlebox with several interfaces. > Properties derived from packet treatment include for example the > interface at which the packet arrived, the interface the packet will > be forwarded to and potentially some other information. > > So observation point is just a probe , for example typically we may have more than > one interface through which we would like to monitor the packet. > > My feeling is that requirement document should rectify Metering process definition. > > (4) > > G: > If reliability is guaranteed by transport layer or network, this > is really not necessary. > G: > > We agree, removed this statement. > What about application level reliability? > (5) > > G: > It is the exporter who decides what to > measure , where to measure & what to send. We are not defining > how to configure a metering process from a collector. > - the exporter configuration is out of the scope of this document > - the exporter configuration SHOULD be done out of band > > G: > > This may be one implementation, but generally exporter does metering, and reporting functions and > more detailed in the document. > > Regarding configuration, what is said is one implementation. But collector should be able to > request (Configure) and get the required Flow information. > > We are not defining what are the configuration information but we are describing > the functionality over here. > > (6) > > G: > This is already covered in the req. spec.Is there a necessity > to repeat it here? > G: > > I think this sentence is rephrased and content of the sections are different. We added more text from other authors. > Hope compiled version of the document will give better picture. > > Regards > Ramg > > -- > 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/ -- 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 Fri Feb 8 11:36:49 2002 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 LAA14014 for ; Fri, 8 Feb 2002 11:36:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZDla-00047k-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 10:20:50 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZDlY-00046X-00 for ipfix-data@net.doit.wisc.edu; Fri, 08 Feb 2002 10:20:48 -0600 Received: from riverstonenet.com (134.141.180.103 [134.141.180.103]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYW9SW; Fri, 8 Feb 2002 08:19:38 -0800 Message-ID: <3C63FA98.66C50F57@riverstonenet.com> Date: Fri, 08 Feb 2002 11:19:36 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jc Martin CC: Simon Leinen , kcn@norseth.com, data Subject: Re: [ipfix-data] Re: Information Model References: <20020205204955.5721.cpmta@c001.snv.cp.net> <3C61557E.2F3B2D05@riverstonenet.com> <3C61AD4B.1D6176E3@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jc Martin wrote: > > See my comments inline. > > calato@riverstonenet.com wrote: > > > > Here is a first cut at the list of data elements to be reported. > > I of course hacked it out of the LFAP spec. > > > > I think we need to begin with a couple of guidlines (which > > we should augment as we go). They are just guidelines. > > > > 1. Data element values should be defined in terms of > > other specifications. Since we are only reporting > > things in other protocols, there should be little > > reason for us to define anything from scatch. > There are two parts in the above. One is where the protocol field > is defined, and the other is where the field is encoded in another > standard. > So, for example, the source port is defined in RFC 768, but it's > definition (representation ?) could be imported from RFC 1155 or CIM > (like RFC3060 is doing). Are you talking about format on the wire? If so, I'm not attempting to define that. Just semantics > > Also, it is worth mentioning the RFC 2924 as a source of information > elements. > At this point, I would like to say that there is already a great > disparity between the various accounting mechanisms in the way > the information is represented, it would be nice if IPFIX is not > adding yet another way of counting packets (Acct-Output-Octets, > Forward Packets,...) > > > > > 2. Each element should be able to be interpreted on > > it own. In other words, don't make me look though > > the rest of the message to figure out what this > > value means. The drawback is this can lead to > > data element explosion. We'll have to balance > > the tradeoffs. > > Is that preventing the use of template ? I don't think so. But if you define one field to be the port number and another to be the protocol then I need to look at 2 fields to determine if it is a UDP port or a TCP port. The field would be better defined as tcp-port and udp-port so the fields stand on their own. > > > > > 3. Others?.... > > Should add something about the naming of attributes, using OIDs, DNs, ... > > Also, I would like to see some positioning with regards to CIM and SMIv2. > Even if the attributes are defined in a template, both the template and > the attributes should be named through a standard naming scheme. > > [snip] > > > > 1.7 Class of Service IE > > > > The class of service associated with a flow. > > > > Class of Service Received > > Class of Service Transmitted > > > > 1 - IPv4, CoS value is defined by ToS in RFC 791 > > 2 - IPv6, CoS value is defined by Traffic Class in RFC 2460 > > 3 - MPLS, CoS value is defined by Exp in RFC 3032 > > 4 - VLAN, CoS value is defined by user_priority in IEEE > > 802.1q[802.1q] and IEEE 802.1p[802.1p] > > > > [Can more than one Class of Service can be present??? PAC] > > > > Is there any interest in counting the number of packets/bits with the > ECN (RFC 3168), or do you see that as an extension ? I have no problem with that if people think they would have a use for that info. > > [snip] > > > 1.10 Byte Count IE > > > > Contains the count of octets sent and received associated with the > > identified flow. > > > > The byte count can be for bytes received (towards source) or > > bytes sent (towards destination) or both (bi-directional flow). > > > > The byte count can be a running counter and is the > > count from the beginning of the flow establishment. > > The byte count can be a delta counter and is the > > count since the last report for this flow. > > > > 1.11 Packet Count IE > > > > Contains the count of packets sent and received associated with the > > identified flow. > > > > The packet count can be for packets received (towards source) or > > packets sent (towards destination) or both (bi-directional > > flow). > > > > The packet count can be a running counter and is the > > count from the beginning of the flow establishment. > > The packet count can be a delta counter and is the > > count since the last report for this flow. > > What do you mean by "can be" in the above cases ? It's either one or the > other, and this need to be specified, or allowed in the coding. Right. can be just means there is more than one possible meaning. The encoding would have to tell you which one it is. > > [snip] > > > 1.34 Vendor Specific IE > > > > Vendors may add their own information to the protocol. Information > > what does this sentence means ? Which protocol ? The IPFIX protocol. If we define the fields transported and vendor A wants to add their own home grown piece of data this is where they do it. > > > contained in this IE is vendor specific. OID and OID Value is > > defined by ITU X.680.X683 (1997) and is encoded as defined by ITU > > X.690.691(1997). This IE MUST not contain any information which > > cannot be safely ignored by the Exporter or Collector. If multiple > > Vendor > > Specific IE's with the same OID occur, then the vendor defines > > semantics of ordering. > > you are mentionning the OID here, what about the other elements ? I'm not sure how the other elements are encoded. But in this case we MUST provide a way for vendors to add stuff with out stepping on each other. This OID is one way to solve it. If we use OID for the other elements as well then we wont need special mention here. But until the encoding stuff is done I added mention of OID here. > > [snip] > > JC -- 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 Fri Feb 8 12:02:37 2002 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 MAA14774 for ; Fri, 8 Feb 2002 12:02:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZE4L-0004WR-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 10:40:13 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZE4H-0004VN-00 for ipfix-arch@net.doit.wisc.edu; Fri, 08 Feb 2002 10:40:10 -0600 Received: from riverstonenet.com (134.141.180.103 [134.141.180.103]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYW9Y1; Fri, 8 Feb 2002 08:38:58 -0800 Message-ID: <3C63FF21.C4C2AF80@riverstonenet.com> Date: Fri, 08 Feb 2002 11:38:57 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: kevin.zhang@xacct.com, Ganesh Sadasivan , "KC' 'Norseth" , ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Re: IPFIX Architecture References: <3C61B157.2781B348@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit My comments inline. Benoit Claise wrote: > > Hi Kevin, > > A couple of important points I would like to discuss amongst the group [I haven't copied the entire document] > G: stands for Ganesh > Kz: Kevin Zhang > Ben: Benoit > > G: > The underlying transport or other protocol is something which can be > configured by the sys. admin., whatever the way he wants: > CLI, SNMP, telnet, ... > G: > [kz3] What you are saying is correct. It depends on whether you want to do it in-band within the export protocol or > out-band. However, do it within the protocol improves interoperability significantly which is exactly this WG is > trying to achieve. > [kz] > > [Ben] I don't know how it improves the interoperability to do the configuration inband. > IPFIX stands for Flow Information eXport. So we have to standardize the export, not the configuration. So the > direction:exporter -> collector and not the direction collector -> exporter. At least not for the configuration. > Standardizing the configuration is a huge job. Do you think that vendors will spend time and money to developp again > another configuration interface, next to CLI, SNMP, XML, etc...? And this just for an IPFIX protocol! > What I'm thinking is that the configuration of the probe or the router is out of the scope of this document and is > based on proprietary solutions. Proprietary solutions that you will very hardly standardize, because they all > contains different proprietary features. > [Ben] I agree we don't want to try and solve the entire config issue in band. But that should not rule out some simple negotiation. For example, it seems appropriate for the Collector to indicate what fields it is interested in. > > [kz2] "capability negotiation" is a MUST, this is key for the IPFIX system to be flexible enough to deal with various > exporting devices (besides core routers). Your view is router-centric, at least in a probes case, what to collect, > how to collect, and when to export are typically configurable by the applications through the collector. > Furthermore, exactly due to the existing infrastructure, "capability negotiation" would be key for the exporter and > collector to understand what are the lower layer support (e.g. security, transport protocol, etc.) for the interace. > [kz] > > [Ben] Well, I guess that I have a "router-centric" view as you call it ;) > As I expressed before, my view is that, because the exporter configuration must happen out-of-band, capabilities > negotiation should not happen. > > 1. Neither capabilities negotiation for the exported fields in a template: > because the template is based on what the exporter can do, not on what a collector thinks an exporter can do. > In other words, you configure the exporter template (by whatever means), the transport protocol and where to export. > Then the collector must be able to parse all the fields of the template. > I refer you to section 8 of http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt for more details > of what I'm thinking. Just because the exporter CAN send the data doesn't mean it should. It seems better to me to have some basic level of capability in all my exporters and then configure my collectors with the data of interest for my reports. > > 2. Neither transport protocol negotiation. > The transport protocol is the first thing you will decide on in an accounting network design (accouting being just a > generic term). > I mean, depending if you want to be billing or traffic monitoring, you may use a connection-oriented transport > compared to UDP, with or without IPSEC. > Basically, you won't change very often your transport protocol. > So why would like to invest time in a transport protocol negotiation? > I would say that this would be configured once for all before you even start exporting the first flow record. > [Ben] > I agree on this one. > G: > Fail-back is not possible on a router -> too much memory needed. > The best we can do is fail-over. > G: > > [kz6] I don't see big difference for memory requirement between fail-over and fail-back, would you please providing > more details? > [kz] > > [Ben] > Fail-over means that as soon as you detect that the connection (only in case of a reliable transport protocol, not > UDP) to the collector is lost, you can start sending to another collector. You may loose a few flow records depending > on your transport protocol keepalive. > Fail-back means that if we switch to another collection, we can' t loose any data. fail-back might just be stop talking to the backup and go back to the primary. > Again maybe a router-centric view ;), but Ganesh showed at the last IETF how much data we can produce per second when > exporting from a router. I don't think anyone at the meeting bought into those numbers. So this is not a good argument from my perspective. > > I refer you to section 4.1.3 and 4.2.3 of http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt > for more details of what I'm thinking. > 4 Flow Export Protocol ................................... 9 > 4.1 Simple Export Model .................................... 10 > 4.1.1 Collector Crash ........................................ 10 > 4.1.2 Collector Redundancy ................................... 10 > 4.1.3 Collector Failover ..................................... 10 > 4.2 Export Model with Reliable Control Connection .......... 10 > 4.2.1 Collector Crash ........................................ 11 > 4.2.2 Collector Redundancy ................................... 11 > 4.2.3 Collector Failover ..................................... 12 > [Ben] > > - Re-sequencing the received IP flow information if required. In > case a reliable, in-sequence delivery service is provided by lower > layer protocol, this function can be omitted. > G: > If we have the timestamp per flow why is resequencing required > G: > [kz7] Timestamp is not sufficient to detect message losses, particularly when unreliable transport protocol is used. > [kz] > > [Ben] > Right, but you can still have a sequence ID in the packet which will tell you if you are loosing some packets. > Is this what you have in mind when talking about re-sequencing? > > Regards, Benoit > [Ben] > > -- > 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/ -- 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 Fri Feb 8 12:06:24 2002 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 MAA14870 for ; Fri, 8 Feb 2002 12:06:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZEFa-0004lA-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 10:51:50 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZEFZ-0004ku-00 for ipfix-arch@net.doit.wisc.edu; Fri, 08 Feb 2002 10:51:49 -0600 Received: from riverstonenet.com (134.141.180.103 [134.141.180.103]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYW96Q; Fri, 8 Feb 2002 08:50:39 -0800 Message-ID: <3C6401DD.90D0209E@riverstonenet.com> Date: Fri, 08 Feb 2002 11:50:37 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: will@cisco.com CC: Reinaldo Penno , Ganesh Sadasivan , ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I'll have to second that. We need to be careful here not to define the best unused protocol ever. Configuration is a nasty issue and I believe we can come up with a useful first cut IPFIX protocol without much in terms of inband configuration. -- 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 Fri Feb 8 12:09:46 2002 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 MAA15082 for ; Fri, 8 Feb 2002 12:09:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZEHa-0004nx-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 10:53:54 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZEHY-0004nN-00; Fri, 08 Feb 2002 10:53:52 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g18GrDj07286; Fri, 8 Feb 2002 08:53:14 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABD20641; Fri, 8 Feb 2002 08:53:43 -0800 (PST) Message-ID: <3C640493.9BFB5157@cisco.com> Date: Fri, 08 Feb 2002 09:02:12 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: kevin.zhang@xacct.com, "KC' 'Norseth" , ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Re: IPFIX Architecture References: <3C6176B4.54E9A400@cisco.com> <3C63F588.63031219@riverstonenet.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, See inline. calato@riverstonenet.com wrote: > > - Supporting fail-over and fail-back procedures, and performing load > > balancing if required. > >G: > >Fail-back is not possible on a router -> too much memory needed. > >The best we can do is fail-over. > >G: > > Not sure why. I think this is as simple as detecting > the server is back and droping the existing connection > in favor of the other. > Please ignore the above statement. That was a mistake. > > > - Supporting fail-over and fail-back procedures. > > > >G: > >This should be an exporter feature and not a collector feature. > >Are you suggesting an inter collector communication? > >IMO this out of scope for this doc. > >G: > > Collector to Collector communication is not > in scope. Exporter to Collector is in scope > and IMHO we need to define how and when to move > between Collectors on a failure. Agreed. It is specified to some extent in the draft we published. You can look at it and comment on it. > > > > As the IPFIX system MUST be reliable, a reliable transport layer > > protocol (e.g. TCP, SCTP) should be used. Furthermore, IPFIX layer > > > >G: > > If the reliability is guarenteed by the network, is there a necessity > > for a reliable transport? As we explained in IETF-52, there are > > scalability concerns with TCP and making this mandartory would > > exclude the exporters with high volume from being IPFIX compliant. > >G: > > Transport level delivery is not the same as application > level delivery. At minimum, a top of discussion for IPFIX > is whether or not we are going to provide application level > reliability in the protocol as an option. > > The reason you may want this is that only the collector > can acknowledge when it has actually processed the > information. For example, it may send an acknowldge when > it has actually persisted the data. As long as this is optional & *not* negotiated, I agree to this. Thanks Ganesh > > > Ganesh Sadasivan wrote: > > > > Hi Kevin, > > I have some comments on the arch spec portion. > > There are between 2 "G:"s. > > Thanks > > Ganesh > > > > ------------------------------------------------------------------------ > > > > > > 1 Scope > > > > This memo describes the architecture of an IP Flow Information eXport > > (IPFIX) system. The IPFIX architecture provides a high level view of > > key functions, interfaces, and protocols employed by the system, and > > serves as a guide for design, engineering, and deployment of such > > systems. > > > > The IPFIX architecture consists of > > > > - A reference model that depicts the key IPFIX entities and > > interfaces. > > > > - Functional descriptions of IPFIX entities. > > > > - Detailed descriptions of capabilities in support of IPFIX > > requirements. > > > > - Detailed descriptions of the relationship among IPFIX entities, > > and definition of the IP flow information export interface that meets > > the key requirements such as reliable, flexible, and efficient. > > > > - An IPFIX protocol architecture that present relationship among > > various layers, and their communication requirements. > > > > 1.1 Specification of Requirements > > > > In this document, the keywords "MUST", "MUST NOT", "SHOULD", "SHOULD > > NOT", and "MAY" are to be interpreted as described in BCP 14. These > > keywords are not case sensitive in this document. > > > > 2 Terminology > > > > IPFIX Session > > > > An IPFIX Session is a logical connection between an exporter > > entity and one or multiple collector entity for the purpose of > > exporting IP flow information. Multiple sessions MAY be > > maintained concurrently in an exporting device. > > > > Template > > > > A Template defines the structure of any types of IP flow > > information record, and specifies the data type, meaning, and > > location of the fields in the record. > > > > > > 3 IPFIX Reference Model > > > > The following figure illustrates the reference model of an IPFIX > > system. It identifies key IPFIX entities and interfaces within the > > system. > > > > 3 > > > > > > > > +---------------+ +---------------+ > > | +----------+ | | +----------+ | > > | |Meter | | | |Processor | | > > | |Entity | | | |Entity | | > > | +----------+ |Exporting | +----------+ | > > | +----------+ |Interface | +----------+ | > > | |Exporter |<=|==========|=>|Collector | | > > | |Entity | | | |Entity | | > > | +----------+ | | +----------+ | > > | Exporting | | Collection | > > | Device | | Device | > > +---------------+ +---------------+ > > > > An exporting device is typically a network element (e.g. routers, > > measurement probes); a collection device may be part of mediation > > systems, accounting/billing systems, and network management systems > > to facilitate business and operation support. > > > > 3.1 IPFIX Entities > > > > 1.1.1 Exporter > > > > The primary task performed by the Exporter entity is to reliably, > > timely, and efficiently deliver IP flow information to the collector > > entity. The following functions are responsibilities of the exporter > > entity: > > G: > > what does it timely mean? > > We can compute the UTC time the flow started and ended. > > G: > > > > - Participating in a capability negotiation process with the > > collector entity in order to determine a commonly supported IPFIX > > exporting mechanism (e.g. IPFIX protocol, and its versions) > > > > G: > > Is the intention to make "capability negotiation" a MUST? > > IMHO the collector should accept whatever is > > being exporterd by the exporter. In most of the cases (atleast > > from a router point of view) the collector is only an > > intermediate box between the exporter and the final node that > > interprets the export information. The job of the collector > > from an information point of view would just be to grab all > > that the exporter sends. > > From an export protocol perspective, maybe it would make sense to > > do some kind of negotiation. But here also with so much of > > infrastructure existing already for reliability, security > > etc the question is whether we want to come with a new model > > or just concentrate on flow export.IMO there is no need for > > negotiation. > > G: > > > > > > - Participating in control information exchanges with the collector > > entity. The control information exchanges typically occur during the > > initial establishment of the exporting session, and may include > > procedures such as exporting session setup, security support, > > capability negotiation, protocol negotiation, IP flow information > > structure (template) negotiation, etc. > > > > G: > > The underlying transport or other protocol is something which can be > > configured by the sys. admin., whatever the way he wants: > > CLI, SNMP, telnet, ... > > G: > > > > - Establishing, maintaining, and removing the state associated with > > an exporting session. > > > > - Generating, transmitting, and receiving IPFIX messages. The IPFIX > > messages may include IPFIX control messages and IPFIX user messages. > > > > - Inserting IP flow information into IPFIX data messages according > > to an encoding scheme. To enable efficient data export, a template > > based encoding should be supported. > > > > G: > > Sending exporter configuration is one of the most important control > > information. > > G: > > > > - Segmenting IP Flow information into multiple IPFIX user messages, > > attaching required control information such as sequence numbers, > > error checks, etc. > > > > - Releasing the transmitted and acknowledged IP flow information > > from the memory. > > G: > > This is an implementation detail. Should be taken care of by the > > transport. > > G: > > > > - Supporting fail-over and fail-back procedures, and performing load > > balancing if required. > > G: > > Fail-back is not possible on a router -> too much memory needed. > > The best we can do is fail-over. > > G: > > > > 1.1.2 Collector > > > > The primary task performed by the Collector entity is to receive and > > acknowledge the IP flow information received from the exporter > > entity. The following functions are responsibilities of the collector > > entity: > > > > - Participating in the capability negotiation and control > > information exchanges with the Exporter entity. > > G: > > Same concerns on capability negotiation as above. > > G: > > > > - Establishing, maintaining, and removing the state associated with > > an exporting session. > > > > - Generating, transmitting, and receiving IPFIX messages. > > > > - Receiving IPFIX user messages according to a decoding scheme, > > checking message integrity, and acknowledging it after it is > > correctly received or optionally processed and persisted in storage. > > G: > > I feel this should be taken care of by the lower layers. > > G: > > > > - Re-sequencing the received IP flow information if required. In > > case a reliable, in-sequence delivery service is provided by lower > > layer protocol, this function can be omitted. > > G: > > If we have the timestamp per flow why is resequencing required > > G: > > > > - Supporting fail-over and fail-back procedures. > > > > G: > > This should be an exporter feature and not a collector feature. > > Are you suggesting an inter collector communication? > > IMO this out of scope for this doc. > > G: > > > > 1.1.3 Meter > > > > The primary task performed by the meter entity is to monitor IP > > flows, and derive IP flow information. How the meter entity measures > > and derives flow information is outside the scope of the IPFIX > > architecture, but the attributes used to describe flow information > > must comply with the IPFIX information model and IP flow definitions. > > > > G: > > The meter entity should interact with the exporter to export information > > as to how the metering is done. > > G: > > > > 1.1.4 Processor > > > > The primary task performed by the Processor entity is to process the > > received IP flow information based upon end application.s > > requirements. The functionality of the processor is outside the scope > > of the IPFIX architecture, though the following functions should be > > considered in designing and deploying an IPFIX system. > > > > G: > > At the minimum the processor should be able to understand the > > structure of the exported information. > > G: > > > > - IP flow information aggregation based upon some aspects of IP > > flows. > > > > - IP flow information filtering based upon some aspects of IP flows. > > > > > > > > 5 > > > > > > - Query additional information (e.g. address translation, user > > identification, etc.) related to an IP flow from other systems, to > > facilitate further processing. > > > > - Persistent receive IP flow information > > > > 3.2 IPFIX Exporting Interface > > > > The IPFIX Exporting interface connects an exporter entity with one or > > multiple collector entities. It MUST support the Internet Protocol > > (IP) for data communications. > > > > G: > > I guess V4 is a MUST, V6, MPLS is optional. > > G: > > > > 4 IPFIX Deployment Scenarios > > > > IPFIX exporting devices may vary greatly in their core functionality. > > At one hand, a core router needs to support high-speed interfaces and > > traffic throughput; it emphasizes on forwarding IP traffic quickly > > and may not be able to perform extensive measurement on IP flow. It > > is also likely to export high volume of IP flow information to > > external systems. On the other hand, a measurement probe or an > > access device is capable of providing more detailed information about > > IP flows and performing complex on-device processing. Consequently, > > it may only export low volume of IP flow information. > > > > Given the diversity of exporting devices, two deployment scenarios > > are described. These scenarios only serve as examples for IPFIX > > system design and deployment. > > > > 4.1 Exporting Interface over LAN > > > > The following figure illustrates the scenarios where an exporting > > device connects to the collecting devices over LAN. > > > > > > +----------+ +----------+ +------------+ > > |Exporting | |Collection|<==>| | > > |Device | |Device 1 | |Applications| > > +----------+ +----------+ |e.g. | > > ^ | ^ | |usage | > > | v | v |accounting, | > > --------------------------------------- |traffic | > > LAN |profiling, | > > --------------------------------------- |traffic | > > ^ | |engineering,| > > | v |QoS | > > +----------+ |Monitoring | > > |Collection|<==================>|etc. | > > |Device 2 | | | > > +----------+ +------------+ > > > > This scenario is suitable for collecting information from core > > routers. As the volume of exported data is typically high, LAN can > > > > > > 6 > > > > > > provide adequate bandwidth and introduce small latency to meet data > > exporting requirement. > > > > G: > > It is also important that the exporting overheads are minimized > > to handle the high volume. Features like reliability > > G: > > > > 4.2 Exporting Interface over WAN > > > > The following figure illustrates the scenario where an exporting > > device connects to the collecting devices over WAN. > > > > +----------+ > > |Collection| +------------+ > > |Device 1 |<==========>| | > > +----------+ |Applications| > > ^ |e.g. | > > | |usage | > > +----------+ +--|-------+ |accounting, | > > |Exporting |<--------|--- | |traffic | > > |Device |<--------|--------- | |profiling, | > > +----------+ | WAN | | |traffic | > > | | | |engineering,| > > | | | |QoS | > > +--------|-+ |Monitoring | > > | |etc. | > > v | | > > +----------+ | | > > |Collection|<==========>| | > > |Device 2 | +------------+ > > +----------+ > > > > This scenario maybe used to collect information from probes or access > > routers. It is critical that a congestion aware transport protocol > > (e.g. TCP, SCTP) is used. > > > > 5 Protocol Architecture > > > > The following figure illustrates the protocol architecture in > > supporting of the IPFIX system. > > > > > > > > 7 > > > > > > > > Exporting Device Collecting Device > > +----------------+ +----------------+ > > | IPFIX | | IPFIX | > > | User | | User | > > +----------------+ +----------------+ > > | IPFIX | | IPFIX | > > | Layer | | Layer | > > +----------------+ +----------------+ > > | Transport | | Transport | > > | Layer | | Layer | > > +----------------+-------------+----------------+ > > | IP Layer | > > +-----------------------------------------------+ > > > > The IFPIX protocol is designed an application running over a > > transport layer protocol. The transport layer protocol is responsible > > for delivering IPFIX messages between exporters and collectors. > > > > As the IPFIX system MUST be reliable, a reliable transport layer > > protocol (e.g. TCP, SCTP) should be used. Furthermore, IPFIX layer > > > > G: > > If the reliability is guarenteed by the network, is there a necessity > > for a reliable transport? As we explained in IETF-52, there are > > scalability concerns with TCP and making this mandartory would > > exclude the exporters with high volume from being IPFIX compliant. > > G: > > > > acknowledgement and flow control mechanisms should be supported to > > ensure flow information is not only correctly received, but also > > processed and persistent at the collection device. > > > > G: > > Why all these are mandatory for IPFIX layer. I agree the framework > > should take care of this. But if there is a capability already > > available why re-invent? > > G: > > > > 6 IPFIX Information Model > > > > The IPFIX information model is listed in the IPFIX requirement > > document. The information model consists of the minimum set of > > attributes that an IPFIX exporting device should be able to export. > > In conjunction with IP flow definitions, they provide locally > > accurate information about a flow. > > > > To meet application.s requirement may require the collection device > > to obtain additional information about the flow, e.g. address > > translation, user identification, etc. Additional flow information > > may also be required; in this case, equipment vendors may define > > extensions to the IPFIX information model. Any extension to the > > IPFIX information model should be conveyed between end points. > > > > This section presents a rigorous definition and sufficient statistics > > for these attributes. > > G: > > I guess this should be maintained in the requirements doc and > > not duplicated. There are lots of comments on this section. > > G: > > > > 6.1 Attributes related to IP Packet Header > > > > The following attributes are obtained directly from IP packet header > > belonging to a flow: > > G: > > What is meant by flow in the above sentence? > > G: > > > > - IP Version Number > > G: > > Why? Can't this be derived from address itself? > > G: > > > > - Source Address > > - Destination Address > > G: > > I suggest we keep separate field types for V4 and V6. > > G: > > There would be more like inner IP, outer IP etc within v4 and v6. > > It is better each of such attribute is enumerated. > > > > - Protocol Type > > - TOS (for version 4) > > G: > > Why not for V6? > > G: > > > > - Flow Label (for version 6) > > - DSCP (if DiffServ is supported) > > G: > > This is an incomplete list. What about L4 headers? > > G: > > > > 8 > > > > > > > > 6.2 Attributes Related to Measurement > > > > The following attributes relates to measurements and > > measuring methodology: > > - Packet Counter > > - Dropped Packet Counter > > - Payload Byte Counter > > - Timestamp of the First Packet Observed > > - Timestamp of the Last Packet Observed > > - Timeout Indication > > - Sampling Method > > - Sampling Parameters > > > > 6.3 Attributes Related to Flow Definition > > > > The following attributes relates to IP flow definitions. > > > > - Incoming Interface > > - Outgoing Interface > > - Packet Treatment > > - Unique ID of the Observation Point > > - Unique ID of the Measuring Device > > > > 6.4 Attributes related to Upper Layers > > > > The following attributes provides information of upper > > layer protocols. > > - Source Port Address > > - MPLS Label (if MPLS is supported) > > > > > > 7 IPFIX Message Format > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Version |Message ID(MID)| Session ID | Message Flags | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Message Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > ~ Message Payload ~ > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > G: > > The message should have the follwoing > > - sequence number if the collector wishes to sequence the packets. > > - the absolute time at which the message was sent and sysUpTime. > > - an ID to identify the exporter if the collector receives packets > > from multiple exporters. Why does one need a session ID? > > G: > > > > Version: 8 bit unsigned integer > > > > The Version field indicates the IPFIX protocol implementation. > > > > Message ID (MID): 8 bit unsigned integer > > > > The Message ID field identifies the type of the message. > > > > > > 9 > > > > > > Session ID: 8 bit unsigned char > > > > The Session ID field identifies the IPFIX exporting session > > with which the message is associated. > > > > Message Flags: 8 bit unsigned char > > > > The Message Flags field can be used to identify options > > associated with the message. > > > > Message Length: 32 bit unsigned integer > > > > The Message Length field is the total length of the IPFIX > > message in octet including the header. > > > > Message Payload: Variable Length > > > > It contains the control or user information exchanged between > > IPFIX end-points (exporter and collector entities). > > > > 8 IPFIX Messages > > > > To be added > > > > 9 IPFIX Template > > > > The IPFIX system MUST support efficient exporting of IP flow > > information. This can be achieved by negotiating a set of IPFIX > > Templates for an IPFIX session before actual IP flow information is > > exported. > > > > G: > > Templates can be exchanged at any time. This may be done > > as a result of a config change in the exporter or it may be a > > periodic update. > > G: > > > > A template defines the structure of an IPFIX user message > > payload by describing the data type, meaning, and location of the > > fields in the payload. By agreeing on IPFIX templates, IPFIX end- > > points understand how to process IPFIX user messages. As a result, > > an exporting device only needs to export actual flow information > > without attaching any descriptors of the attributes; this reduces > > the amount of bytes sent over communication links. > > > > G: > > I do not understand, how the collector can interpret pure data > > records without any descriptors as to what template it represents. > > G: > > > > A template is an ordered list of keys. A key specifies an attribute > > that a meter entity MAY export. The specification MUST consist of > > the description and the data type of the attribute. (e.g. 'Number of > > Sent Bytes' can be a key that is an 32 bit unsigned integer) An > > exporting device typically defines keys. Based on the IPFIX > > information model, a set of IPFIX standard keys can be defined. > > > > 9.1 Template Negotiation > > > > During the initial setup of an IPFIX session, template negotiation > > procedures should be carried out. It would allow all the IPFIX end- > > points to synchronize on a set of templates that will be used during > > IP flow information export. > > > > G: > > As I said above I really do not agree to this model. > > G: > > > > G: > > In short the fundamental aspects of disagreement are: > > - no template/capabilities/etc... negotiation in IPFIX > > - no MUST for reliable > > - no state information (except based on the transport protocol, if > > connection oriented) > > - no connection initiated from the collector. > > G: > > > > 10 Capability Negotiation > > > > > > 10 > > > > > > To be added > > > > 11 Redundancy and Error Handling > > > > To be added > > > > 12 Author's Address > > > > Questions about this memo can be directed to: > > > > Kevin Zhang > > XACCT Technologies, Inc. > > 2900 Lakeside Drive > > Santa Clara, CA 95054 > > Phone +1 301 992 4697 > > Email: kevin.zhang@xacct.com -- 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 Fri Feb 8 12:39:24 2002 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 MAA16750 for ; Fri, 8 Feb 2002 12:39:23 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZEkg-0005Wp-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 11:23:58 -0600 Received: from mercury.sun.com ([192.9.25.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZEke-0005Wi-00 for ipfix-data@net.doit.wisc.edu; Fri, 08 Feb 2002 11:23:56 -0600 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17336; Fri, 8 Feb 2002 09:23:47 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA14402; Fri, 8 Feb 2002 09:25:27 -0800 (PST) Received: from sun.com (inox.Eng.Sun.COM [129.146.85.133]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g18HJXAJ592890; Fri, 8 Feb 2002 09:23:43 -0800 (PST) Message-ID: <3C6408B1.CA9AB200@sun.com> Date: Fri, 08 Feb 2002 09:19:45 -0800 From: Jc Martin Organization: Sun Microsystems X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: Simon Leinen , kcn@norseth.com, data Subject: Re: [ipfix-data] Re: Information Model References: <20020205204955.5721.cpmta@c001.snv.cp.net> <3C61557E.2F3B2D05@riverstonenet.com> <3C61AD4B.1D6176E3@sun.com> <3C63FA98.66C50F57@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > > Jc Martin wrote: > > > > See my comments inline. > > > > calato@riverstonenet.com wrote: > > > > > > Here is a first cut at the list of data elements to be reported. > > > I of course hacked it out of the LFAP spec. > > > > > > I think we need to begin with a couple of guidlines (which > > > we should augment as we go). They are just guidelines. > > > > > > 1. Data element values should be defined in terms of > > > other specifications. Since we are only reporting > > > things in other protocols, there should be little > > > reason for us to define anything from scatch. > > There are two parts in the above. One is where the protocol field > > is defined, and the other is where the field is encoded in another > > standard. > > So, for example, the source port is defined in RFC 768, but it's > > definition (representation ?) could be imported from RFC 1155 or CIM > > (like RFC3060 is doing). > > Are you talking about format on the wire? If so, I'm > not attempting to define that. Just semantics Not only. You have some concepts, like Gauge, Counter, that have a specific semantic, and a well defined behavior. I don't have other examples, but I suspect that all parameters that are not directly derived from a protocol would fold in the same group (like interfaces,...). [snip] > > > contained in this IE is vendor specific. OID and OID Value is > > > defined by ITU X.680.X683 (1997) and is encoded as defined by ITU > > > X.690.691(1997). This IE MUST not contain any information which > > > cannot be safely ignored by the Exporter or Collector. If multiple > > > Vendor > > > Specific IE's with the same OID occur, then the vendor defines > > > semantics of ordering. > > > > you are mentionning the OID here, what about the other elements ? > > I'm not sure how the other elements are encoded. But in this > case we MUST provide a way for vendors to add stuff with out > stepping on each other. This OID is one way to solve it. If > we use OID for the other elements as well then we wont need > special mention here. But until the encoding stuff is done > I added mention of OID here. > I don't think that the notion of naming is specific to the encoding. It's a basic feature of the information model. I think that this should be spelled out in a specific section, and applied to all attributes or standard templates. JC. -- 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 Fri Feb 8 16:53:56 2002 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 QAA26057 for ; Fri, 8 Feb 2002 16:53:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZIY8-0002pD-00 for ipfix-list@mil.doit.wisc.edu; Fri, 08 Feb 2002 15:27:16 -0600 Received: from d2cspimg001.smartpipes.com ([63.89.185.24]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZIY5-0002oR-00; Fri, 08 Feb 2002 15:27:13 -0600 Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Feb 2002 21:26:43 -0000 Message-ID: <4652644B98DFF34696801F8F3070D3FE01188693@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'calato@riverstonenet.com'" , Ganesh Sadasivan Cc: kevin.zhang@xacct.com, "KC' 'Norseth" , ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] Re: IPFIX Architecture Date: Fri, 8 Feb 2002 21:26:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Precedence: bulk Sender: majordomo listserver You may need fail over if 1) you want load balancing 2) you assign some kind of priority to servers so that the when a high priority server comes back you roll the session over. I assume this requirement is only on the collector side. -----Original Message----- From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] Sent: Friday, February 08, 2002 10:58 AM To: Ganesh Sadasivan Cc: kevin.zhang@xacct.com; KC' 'Norseth; ipfix-data-volunteers@net.doit.wisc.edu; ipfix-arch-volunteers@net.doit.wisc.edu; ipfix-chairs@net.doit.wisc.edu; ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Re: IPFIX Architecture > - Supporting fail-over and fail-back procedures, and performing load > balancing if required. >G: >Fail-back is not possible on a router -> too much memory needed. The >best we can do is fail-over. >G: Not sure why. I think this is as simple as detecting the server is back and droping the existing connection in favor of the other. -- 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 Sat Feb 9 01:49:10 2002 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 BAA04479 for ; Sat, 9 Feb 2002 01:49:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZQwd-0005Vi-00 for ipfix-list@mil.doit.wisc.edu; Sat, 09 Feb 2002 00:25:07 -0600 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZQwb-0005Ue-00 for ipfix-arch@net.doit.wisc.edu; Sat, 09 Feb 2002 00:25:06 -0600 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g196P9j20738; Sat, 9 Feb 2002 07:25:09 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 8E38FC040; Sat, 9 Feb 2002 07:24:19 +0100 (CET) To: Tanja Zseby Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Message-ID: <1013235859.3c64c0937ea24@citadel.mobility.ccrle.nec.de> Date: Sat, 09 Feb 2002 07:24:19 +0100 (CET) From: quittek@ccrle.nec.de Cc: Ganesh Sadasivan , zseby@fokus.gmd.de, ipfix-arch@net.doit.wisc.edu References: <3C6113C9.2080604@fokus.fhg.de> <3C618E83.F1C57C73@cisco.com> <3C624791.6050909@fokus.fhg.de> In-Reply-To: <3C624791.6050909@fokus.fhg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Hi Tanja, I agree with your statement. The discussion of interaction with AAA should not be part of the architecture document. So, let's take it out of it. Also I agree that this might fit very well into an applicability document. Why don't you just start editing one based on your text. Best wishes, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de Tanja Zseby wrote: > Hi Ganesh > > I agree, that different applications can be consumer of IPFIX data. > Nevertheless, AAA defines a whole architecture for accounting and > itself provides input to accounting and billing applications. Therefore > > I think we need to show how IPFIX and AAA can work together. I agree > that it is not the task of IPFIX to define the interfaces. And maybe you > are right, and the architecture document is not the rigtht place for > this. If Nevil writes something on relations to RTFM we could put > together a document on relations between IPFIX and other WGs/frameworks. > > Or really start a applicability document with sections for the target > applications mentioned in the requirements draft. > [...] -- 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 Sat Feb 9 04:06:06 2002 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 EAA13295 for ; Sat, 9 Feb 2002 04:06:05 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZSsp-0000MH-00 for ipfix-list@mil.doit.wisc.edu; Sat, 09 Feb 2002 02:29:19 -0600 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZSsm-0000La-00 for ipfix-arch@net.doit.wisc.edu; Sat, 09 Feb 2002 02:29:16 -0600 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g198TXj21010 for ; Sat, 9 Feb 2002 09:29:33 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 34CD5C040; Sat, 9 Feb 2002 09:28:43 +0100 (CET) To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Configuration and capabilities negotiation Message-ID: <1013243323.3c64ddbb19dde@citadel.mobility.ccrle.nec.de> Date: Sat, 09 Feb 2002 09:28:43 +0100 (CET) From: quittek@ccrle.nec.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Hi all, Our charter says we should "select a protocol by which IP flow information can be transferred in a timely fashion from an "exporter" to a collection station or stations". There is no mentioning of configuring the meter and exporter, just of transferring flow information. I think that configuration should be done out of band. Either by another protocol or MIB (for which to develop we are not chartered) or by traditional CLI (as usual). Adding configuration to the protocol would make it very complicated. We would need another data model just for configuring the device. In my view this significanlty violates the general KISS requirement every IP protocol should meet. Further, our AD stated that we are standardizing common practice, and common practice is CLI configuration. As for capability negotiations, I have the same concern about keeping it simple. Definitely, I do not like to have any NEGOTIATION. If we really think it is necessary we might have the data collector requesting a set of attributes to be part of the flow record. But even this complicates an implementation significantly. If we consider several collectors receiving data from the same reporter, then we have to save a record format for each collector, configure the metering process such that all collectors are covered and export individual records to each collector. This would be a lot of work to implement it on a router. Much easier is having a single configuration via CLI including a specification of collectors to which identical records are to be sent. Please consider that the meter will be built partially in hardware which is costly. Here we can save a lot by reducing some functions. The data collector implemented by software can be much more flexible with less cost. So lets have a protocol which is more flexible as NetFlow version 1-7, but not much more complicated, in order to be successfully accepted by hardware vendors and application programmers. Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Sat Feb 9 11:04:37 2002 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 LAA16836 for ; Sat, 9 Feb 2002 11:04:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZZdt-0003sj-00 for ipfix-list@mil.doit.wisc.edu; Sat, 09 Feb 2002 09:42:21 -0600 Received: from pool-162-83-255-47.ny5030.east.verizon.net ([162.83.255.47] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZZdq-0003se-00 for ipfix-data@net.doit.wisc.edu; Sat, 09 Feb 2002 09:42:19 -0600 Received: from sphynx (sphynx.newyork.qosient.com [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g19FgEL19243; Sat, 9 Feb 2002 10:42:14 -0500 Reply-To: From: "Carter Bullard" To: , "'Simon Leinen'" Cc: , "'data'" Subject: [ipfix-data] Information Model supporting vendor specific IE's Date: Sat, 9 Feb 2002 10:42:05 -0500 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6603BEF0@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED6605109B@ptah.newyork.qosient.com> Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Gentle People, We'll need an of IE type that supports vendor specific metrics. Rather than requiring that an IE be approved, we should support vendor proprietary IE's in order to transport unique metrics. Ones that are not defined in the RFC. The inclusion of these IE types would be advertised at connect time, and the collector can decide if it will pass them through or not. I didn't see this in the list. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > calato@riverstonenet.com > Sent: Wednesday, February 06, 2002 11:11 AM > To: Simon Leinen > Cc: kcn@norseth.com; data > Subject: [ipfix-data] Re: Information Model > > > > Here is a first cut at the list of data elements to be > reported. I of course hacked it out of the LFAP spec. > > I think we need to begin with a couple of guidlines (which > we should augment as we go). They are just guidelines. > > 1. Data element values should be defined in terms of > other specifications. Since we are only reporting > things in other protocols, there should be little > reason for us to define anything from scatch. > > 2. Each element should be able to be interpreted on > it own. In other words, don't make me look though > the rest of the message to figure out what this > value means. The drawback is this can lead to > data element explosion. We'll have to balance > the tradeoffs. > > 3. Others?.... > > 1.1 Source Address IE > > Source address associated with a flow. Addresses can be > of any type > as described in RFC 1700 [note - we need a new reference > here, 1700 > has been obsoleted] > > 1.2 Destination Address IE > > Destination address associated with a flow. same as above. > > 1.3 Internal queue priority > > A switch may map several of its internal priority queues into a > Premium, High, Medium or Low category. > > [ this sections needs more work] > > > 1.4 Time IE > > The time (as a SNMPv2 TimeStamp [1443]) associated with the > status/statistics observed or other events. > > 1.5 UTC Time IE > > The time in seconds since 00:00:00 UTC, January 1, 1970 associated > with the status/statistics observed or other events. If both Time > and UTC_TIME are present, UTC Time takes precedence. > > 1.6 Delta Time IE > > The number in 100ths of seconds over which the statistics were > observed. TYPE is 71 and format is: > > > 1.7 Class of Service IE > > The class of service associated with a flow. > > Class of Service Received > Class of Service Transmitted > > 1 - IPv4, CoS value is defined by ToS in RFC 791 > 2 - IPv6, CoS value is defined by Traffic Class in RFC 2460 > 3 - MPLS, CoS value is defined by Exp in RFC 3032 > 4 - VLAN, CoS value is defined by user_priority in IEEE > 802.1q[802.1q] and IEEE 802.1p[802.1p] > > [Can more than one Class of Service can be present??? PAC] > > > > 1.8 Source Exporter [ is that the right term?? PAC] Address IE > > Source Exporter address is the address of the Exporter > reporting the flow, > Address is same as is as shown for Source Address. This > information is used by applications to later correlate the > ingress/egress port with a specific Exporter. It is also used to > maintain the source Exporter information when there is an > intermediate > proxy. For example, given the picture below: > > SW1 -------- P1 ------ FAS1 > ^ > | > SW2---------- | > > Flows coming from SW1 and SW2 through proxy P1 would look to the > Collector [ is this the rigth term??? PAC] like the same Exporter > connection. With the Source Exporter in the message the > original Exporter > address is maintained. > > > 1.9 Flow State IE > > Flow State is the intended End State for the Flow. > > Flow state has one of the following meanings: > > Flow is inactive > Flow is active > > 1.10 Byte Count IE > > Contains the count of octets sent and received associated with the > identified flow. > > The byte count can be for bytes received (towards source) or > bytes sent (towards destination) or both > (bi-directional flow). > > The byte count can be a running counter and is the > count from the beginning of the flow establishment. > The byte count can be a delta counter and is the > count since the last report for this flow. > > > > 1.11 Packet Count IE > > Contains the count of packets sent and received associated with the > identified flow. > > The packet count can be for packets received (towards source) or > packets sent (towards destination) or both > (bi-directional flow). > > The packet count can be a running counter and is the > count from the beginning of the flow establishment. > The packet count can be a delta counter and is the > count since the last report for this flow. > > > 1.12 Protocol Identifier IE > > e.g. TCP/UDP [ need an RFC reference here. PAC] > > 1.13 Source Port IE > > This IE is used to report UDP source port [see RFC 768] or > TCP source port [see RFC 793]. > > 1.14 Destination Port IE > > This IE is used to report UDP destination port [see RFC 768] or > TCP destination port [see RFC 793]. > > > 1.15 Source AS IE > > The Autonomous System (AS) numbers for the source address > associated with a flow. Autonomous System (AS) number is defined by > RFC 1930 and RFC 1771 (BGP-4): > > > 1.16 Destination AS IE > > The Autonomous System (AS) numbers for the destination address > associated wit a flow. Autonomous System (AS) number is defined by > RFC 1930 and RFC 1771 (BGP-4). > > > 1.17 Ingress Port IE > > The ingress ifIndex for the flow is provided in this IE. ifIndex is > defined by RFC 2233. > > 1.18 Egress Port IE > > The egress ifIndex for the flow is provided in this IE. ifIndex is > defined by RFC 2233. > > > 1.19 Egress ATM Subinterface > > The egress vpi/vci for the flow is provided in this IE. vpi/vci id > defined by the ATM Forum UNI 3.1 specification: > > > > 1.20 EGRESS_FRAME_RELAY_SUBINTERFACE IE > > The egress DLCI for the flow is provided in this IE. ITU Q.922 > defines the DLCI range. The frDlcmiState is defined in RFC 2115 and > defines the specific values of the DLCI. > > > > 1.21 NEXT_HOP_IP IE > > Address of the next hop. address is defined the same as for Source > Address IE. > > 1.22 TCP Control Bits IE > > The TCP control bits seen for this flow. Note a 0 value for each > bit only indicates that the flag was not detected (i.e. it may have > occurred but was not detected by the reporting CCE). TCP Control > Bits are defined by RFC 793. > > 1.23 Next Hop AS IE > > The Autonomous System (AS) numbers for the next hop IP. Autonomous > System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). > > > > 1.24 Source Address Netmask IE > > The number of bits in the CIDR netmask, as defined in RFC 1519, for > the source address. > > 1.25 Destination Address Netmask IE > > The CIDR netmask, as defined in RFC 1519, for the destination > address. > > > 1.26 Destination BGP Community IE > > The BGP community number for the destination address. BGP community > number is defined by RFC 1997: > > > 1.27 Source BGP Community IE > > The BGP community number for the source address. > > > > 1.28 Source VLAN ID IE > > The Source VLAN ID associated with the flow. VLAN ID is > defined by IEEE > standard 802.1q - 1998[802.1q]. > > [ Is this ultimate source VLAN or the source vlan of the port where > the packet came in? Or do we need a way to represent both? PAC] > > 1.29 Destination VLAN ID IE > > The destination VLAN ID associated with the flow. VLAN ID > is defined by IEEE > standard 802.1q - 1998[802.1q]. > > [ Is this ultimate destination VLAN or the destination vlan > of the port where > the packet went out? Or do we need a way to represent both? PAC] > > 1.30 Source Virtual Address IE > > An Exporter may be involved in redirecting flows. This IE captures > information needed for proper accounting of redirected flows. The > Source Virtual IE contains the source address of the flow as > transmitted by the Exporter. It is generally different > than the source > address IE, which contains the address of the actual source of the > message. > > A type field would contain the type of translation performed on the > source address. The following types are currently available: > > 1 - NAT > 2 - LSNAT > 3 - Web Cache > > The address is defined the same as for Source Address. > > 1.31 Source Virtual Port IE > > A CCE may be involved in redirecting flows. This IE captures > information needed for proper accounting of redirected flows. The > Source Virtual port IE contains the source port of the flow as > transmitted by the CCE. It may be different than the source port > IE, which contains the port of the actual source of the flow. > An IP Protocol field is present and is defined by the IP protocol > spec [RFC 791] (e.g. TCP/UDP). The fields indicates how to > interpret > the port value field. > > A type field contains the type of translation performed on the > source port. The following types are currently available: > > 1 - NAT > 2 - LSNAT > 3 - Web Cache > > > 1.32 Destination Virtual Address IE > > The Destination Virtual IE contains the destination address of the > flow as received by the Exporter. It is generally > different than the > destination port number, which contains the actual destination > address of the flow. > > > 1.33 Destination Virtual Port IE > > The Destination Virtual port IE contains the destination port of > the flow as received by the Exporter. It may be different than the > destination port recorded in the destination port, which > contains the > actual destination port of the flow. > > > 1.34 Vendor Specific IE > > Vendors may add their own information to the protocol. Information > contained in this IE is vendor specific. OID and OID Value is > defined by ITU X.680.X683 (1997) and is encoded as defined by ITU > X.690.691(1997). This IE MUST not contain any information which > cannot be safely ignored by the Exporter or Collector. If > multiple Vendor > Specific IE's with the same OID occur, then the vendor defines > semantics of ordering. > > > 1.35 Flow Label IE > > The Flow Label IE contains the IPV6 Flow Label information as > defined by RFC 2460. > > 1.36 Fragment ID IE > > The fragment ID associated with the flow. RFC 791 and RFC 2460 > define fragment ID. > > -- > 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/ > > -- 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 Sun Feb 10 01:52:47 2002 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 BAA25537 for ; Sun, 10 Feb 2002 01:52:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ZnW5-0004RH-00 for ipfix-list@mil.doit.wisc.edu; Sun, 10 Feb 2002 00:31:13 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ZnVw-0004Q9-00; Sun, 10 Feb 2002 00:31:04 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1A6USM18289; Sun, 10 Feb 2002 00:30:30 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFWNGC>; Sat, 9 Feb 2002 22:30:24 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982233@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: ipfix-arch@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu Cc: quittek@ccrle.nec.de Subject: [ipfix-arch] Answer to the recent comments on the Architecture Draft Date: Sat, 9 Feb 2002 22:30:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B1FC.6BFD4580" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B1FC.6BFD4580 Content-Type: text/plain; charset="iso-8859-1" Hello Juergen, let me address your concerns in one email, although some of these items were already discussed ad-nauseum. Here it goes. 1 - General Stuff: : :The draft distributed by KC discusses a lot of far related :issues, but some essential components of the architecture are :(so far) rather poorly described. This is different in the :I-D of Ganesh and Benoit. : :So why don't we take some text from it. I think their intention :is to contribute to the joint document (see their title). I really do not know what you mean by this. Are you trying to help them? :Please consider that the meter will be built partially in hardware :which is costly. Here we can save a lot by reducing some functions. :The data collector implemented by software can be much more flexible :with less cost. huh? What are you talking about? okay, then *your* meter or who else you are going to supply CHIPs to is going to be built partially in hardware. Please do not generalize. The meter can be a PC-probe running some software. :So lets have a protocol which is more flexible as NetFlow version :1-7, I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it. :but not much more complicated, in order to be successfully :accepted by hardware vendors and application programmers. ohh, please...Then Netflow is just right? 2 - Middlebox: :In my view this section is completely useless in its current :state. What does it say about the architecture? : :It states that if you meter on a firewall you can do this, :you can do that. Maybe you can do even other things. :Yes, a firewall can silently drop packets, drop them :and export them, or drop them and send a message about this. :But this is not a text book. What is the suggestion for the :architecture? This is the first draft of the architecutre document. In the next interaction we will propose what methods SHOULD be supported if you offer firewall services. As far the text book statement, I disagree. Some people confuse technical writing with bad writing. I think that providing a small introductory section and associated reference is a good writing practice. Of course , you feel free to disagree. : :My suggestion is deleting this section, and replacing it by :a more general paragraph added to the description of the :metering process, which is a subsection missing in section 4. :There we can discuss packet drop at an observation point. :Something like: : : Observed packets might be dropped at an observation point. : If the meter can observe also the act of dropping it may : add information on this to the flow record. Well, I disagree with this. This is on the other hand is too generic. In the architecture document we need to set some sort of expectations on the behavior of the exporter when other services running on the same device can alter the result of measurement process. : :Then I suggest to add two IEs to section 9: This is already there... .. :We do not need a lecture on what is a NAT and what is a 'twice NAT'. :This is (or should be) covered by other RFCs focussing on this issue. My argument is the same as before. Some people confuse technical writing with bad writing. I think that providing a small introductory section and associted reference is a good writing practice that is followed in several RFC/I-D. Of course , you feel free to dsagree. :I suggest to replace sections 6.4.2. and 6.4.3. by a more general :discussion of the issue in section 4, for eample: : : Observed packets might be modified at an observation point. : Examples are changing the MPLS label, changing the DiffServ Code : point at DiffServ markers, replacing IP addresses and port numbers : at NATs, and even the increment of the TTL field. : Same as above, this is too generic (specially in the case NAT). I think we should set a minimum set of architectural considerations when dealing with NAT. For instance, that is composed of two flows, that in the case of twice NAT you should/must export both flows (private and public) or otherwise notify the collector, etc, etc :This comment refers to sections 6.4.2. Tunneling in the draft :distributed by KC. : :The statement in the first paragraph is clearly an applicability :statement. It does not belong to section 6 titled 'Architectural :Requirements', but to a section called 'Applicability'. Or, if :we will have a seaprate draft on applicability, we should move :it there. Just like the NAT case, issues and behavior related to *Tunnel terminates on exporter *Tunnel initiates on exporter *Exporter implements tunnel switching should be discussed and the set of expectations established. In the case of tunnel switching for instance, we should/must export the flows of the incoming and outgoing tunnel. :This comment refers to sections 6.4.5. VPNs in the draft :distributed by KC. : :The first two paragraphs and subsection 6.4.5.1 (without :6.4.5.1.1. and 6.4.5.1.2.) belong to a section on applicability :statements and not to the IPFIX architectural requirements. The portion of text you mentioned is a introduction to the problem statement. I could have just written section 6.4.5.1.2. directly, but again, I consider that good practice and several RFC/I-D follow this model. Somebody that do not understand VPN will just be lost. For that matter, the bottom line is that this whole draft is not explicitly directed to you or even the people of this mailing list, but to a much wider audience (the whole IETF and beyond). : :Section 6.4.5.1.1. makes a good point in requesting an IE for :the VPN-ID. However, the statement "MUST include VPN-ID in the :exported flow record" is too strong. We may require that it :MUST be able to do so, but the user should be free o configure :export such that VPN-ID is not exported. Can you elaborate on why not exporting this? 3 - Capability Negotiation: :I think that configuration should be done out of band. Either :by another :protocol or MIB (for which to develop we are not chartered) or by :traditional CLI (as usual). We are not chartered to do a protocol, so the point is moot. The capability negotiation (or advertisment some people prefer it) would then by definition be "another protocol". "traditional CLI (as usual)". Let me be straight to the point here to avoid tip-toeing around the issue. Are you talking about Cisco routers? How come you say this is the usual method? For whom? Tons of vendors support some form of HTTP or GUI configuration. : :Adding configuration to the protocol would make it very complicated. :We would need another data model just for configuring the device. :In my view this significanlty violates the general KISS requirement :every IP protocol should meet. : Are you saying that PPP, BGP and OSPF are bad designed protocols? : :As for capability negotiations, I have the same concern about keeping :it simple. Definitely, I do not like to have any NEGOTIATION. If we :really think it is necessary we might have the data collector :requesting : Again this is a question of semantics. For me what BGP does is negotiation, you may call it a "multi-step" advertisement. :But even this complicates an implementation significantly. If we :consider several collectors receiving data from the same reporter, :then we have to save a record format for each collector, configure :the metering process such that all collectors are covered and export :individual records to each collector. : That's exactly why we should have a capability . Unless you are suggesting that for the first time in history exporters and collectors from different vendors will have exactly the same capabilities. Let's suppose the exporters in your example above have different levels of compliance to the standard, have vendor-extensions, etc. This is the more general case and in fact I doubt that in a big heterogeneus network all the componenets will be from a single vendor. :This would be a lot of work to implement it on a router. Much easier :is having a single configuration via CLI including a specification of :collectors to which identical records are to be sent. : So,instead of just saying to exporter what is the IP addres of the collectors (from different vendors) and have them figure out what are the capabilities, you are saying that "it's easier" (sic) to this by command line? Are you talking about Cisco routers or maybe your personal preferences? regards, Reinaldo ------_=_NextPart_001_01C1B1FC.6BFD4580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture Draft

Hello Juergen,

let me address your concerns in one email, although = some of these items were already discussed ad-nauseum.

Here it goes.

1 - General Stuff:

:
:The draft distributed by KC discusses a lot of far = related
:issues, but some essential components of the = architecture are
:(so far) rather poorly described. This is different = in the
:I-D of Ganesh and Benoit.
:
:So why don't we take some text from it. I think = their intention
:is to contribute to the joint document (see their = title).

I really do not know what you mean by this. Are you = trying to help them?

:Please consider that the meter will be built = partially in hardware
:which is costly. Here we can save a lot by reducing = some functions.
:The data collector implemented by software can be = much more flexible
:with less cost.

huh? What are you talking about? okay, then *your* = meter or who else you are going to supply CHIPs to is going to be built = partially in hardware. Please do not generalize. The meter can be a = PC-probe running some software.

:So lets have a protocol which is more flexible as = NetFlow version
:1-7,

I will not comment on that too much...Basically we = are not here to reverse-engineer Netflow, but to incorporate some good = ideas from it.

:but not much more complicated, in order to be = successfully
:accepted by hardware vendors and application = programmers.

ohh, please...Then Netflow is just right?



2 - Middlebox:

:In my view this section is completely useless in its = current
:state. What does it say about the = architecture?
:
:It states that if you meter on a firewall you can = do this,
:you can do that. Maybe you can do even other = things.
:Yes, a firewall can silently drop packets, drop = them
:and export them, or drop them and send a message = about this.
:But this is not a text book. What is the suggestion = for the
:architecture?

This is the first draft of the architecutre document. = In the next interaction we will propose  what methods SHOULD be = supported if you offer firewall services.

As far the text book statement, I disagree. Some = people confuse technical writing with bad writing. I think that = providing a small introductory section and associated reference is a = good writing practice. Of course , you feel free to = disagree.

:
:My suggestion is deleting this section, and = replacing it by
:a more general paragraph added to the description = of the
:metering process, which is a subsection missing in = section 4.
:There we can discuss packet drop at an observation = point.
:Something like:
:
:    Observed packets might be = dropped at an observation point.
:    If the meter can observe also = the act of dropping it may
:    add information on this to the = flow record.

Well, I disagree with this. This is on the other hand = is too generic. In the architecture document we need to set some sort = of expectations on the behavior of the exporter when other services = running on the same device can alter the result of measurement = process.


:
:Then I suggest to add two IEs to section 9:

This is already there...

<snip>..<snip>


:We do not need a lecture on what is a NAT and what = is a 'twice NAT'.
:This is (or should be) covered by other RFCs = focussing on this issue.

My argument is the same as before. Some people = confuse technical writing with bad writing. I think that providing a = small introductory section and associted reference is a good writing = practice that is followed in several RFC/I-D. Of course , you feel free = to dsagree.

 
:I suggest to replace sections 6.4.2. and 6.4.3. by = a more general
:discussion of the issue in section 4, for = eample:
:
:    Observed packets might be = modified at an observation point.
:    Examples are changing the MPLS = label, changing the DiffServ Code
:    point at DiffServ markers, = replacing IP addresses and port numbers
:    at NATs, and even the increment = of the TTL field.
:

Same as above, this is too generic (specially in the = case NAT). I think we should set a minimum set of architectural = considerations when dealing with NAT. For instance, that is composed of = two flows, that in the case of twice NAT you should/must export both = flows (private and public) or otherwise notify the collector, etc, = etc

:This comment refers to sections 6.4.2. Tunneling in = the draft
:distributed by KC.
:
:The statement in the first paragraph is clearly an = applicability
:statement. It does not belong to section 6 titled = 'Architectural
:Requirements', but to a section called = 'Applicability'. Or, if
:we will have a seaprate draft on applicability, we = should move
:it there.

Just like the NAT case, issues and behavior related = to

*Tunnel terminates on exporter

*Tunnel initiates on exporter

*Exporter implements tunnel switching

should be discussed and the set of expectations = established. In the case of tunnel switching for instance, we = should/must export the flows of the incoming and outgoing tunnel. =


:This comment refers to sections 6.4.5. VPNs in the = draft
:distributed by KC.
:
:The first two paragraphs and subsection 6.4.5.1 = (without
:6.4.5.1.1. and 6.4.5.1.2.) belong to a section on = applicability
:statements and not to the IPFIX architectural = requirements.

The portion of text you mentioned is a introduction = to the problem statement. I could have just written section 6.4.5.1.2. = directly, but again, I consider that good practice and several RFC/I-D = follow this model. Somebody that do not understand VPN will just be = lost.

For that matter, the bottom line is that this whole = draft is not explicitly directed to you or even the people of this = mailing list, but to a much wider audience (the whole IETF and = beyond).

 
:
:Section 6.4.5.1.1. makes a good point in requesting = an IE for
:the VPN-ID. However, the statement "MUST = include VPN-ID in the
:exported flow record" is too strong. We may = require that it
:MUST be able to do so, but the user should be free = o configure
:export such that VPN-ID is not exported.

Can you elaborate on why not exporting this?

3 - Capability Negotiation:

:I think that configuration should be done out of = band. Either
:by another
:protocol or MIB (for which to develop we are not = chartered) or by
:traditional CLI (as usual).

We are not chartered to do a protocol, so the point = is moot. The capability negotiation (or advertisment some people prefer = it) would then by definition be "another = protocol".

"traditional CLI (as usual)". Let me be = straight to the point here to avoid tip-toeing around the issue. Are = you talking about Cisco routers? How come you say this is the usual = method? For whom? Tons of vendors support some form of HTTP or GUI = configuration.

:
:Adding configuration to the protocol would make it = very complicated.
:We would need another data model just for = configuring the device.
:In my view this significanlty violates the general = KISS requirement
:every IP protocol should meet.
:

Are you saying that PPP, BGP and OSPF are bad = designed protocols?

:
:As for capability negotiations, I have the same = concern about keeping
:it simple. Definitely, I do not like to have any = NEGOTIATION. If we
:really think it is necessary we might have the data = collector
:requesting
:

Again this is a question of semantics. For me what = BGP does is negotiation, you may call it a "multi-step" = advertisement.

:But even this complicates an implementation = significantly. If we
:consider several collectors receiving data from the = same reporter,
:then we have to save a record format for each = collector, configure
:the metering process such that all collectors are = covered and export
:individual records to each collector.
:

That's exactly why we should have a capability = <negotiation,advertisement>. Unless you are suggesting that for = the first time in history exporters and collectors from different = vendors will have exactly the same capabilities.

Let's suppose the exporters in your example above = have different levels of compliance to the standard, have = vendor-extensions, etc. This is the more general case and in fact I = doubt that in a big heterogeneus network all the componenets will be = from a single vendor.

:This would be a lot of work to implement it on a = router. Much easier
:is having a single configuration via CLI including = a specification of
:collectors to which identical records are to be = sent.
:

So,instead of just saying to exporter what is the IP = addres of the collectors (from different vendors) and have them figure = out what are the capabilities, you are saying that "it's = easier" (sic) to this by command line? Are you talking about Cisco = routers or maybe your personal preferences?


regards,

Reinaldo






------_=_NextPart_001_01C1B1FC.6BFD4580-- -- 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 Sun Feb 10 20:39:42 2002 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 UAA13198 for ; Sun, 10 Feb 2002 20:39:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16a52r-0003nN-00 for ipfix-list@mil.doit.wisc.edu; Sun, 10 Feb 2002 19:14:13 -0600 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16a52p-0003ml-00 for ipfix-arch@net.doit.wisc.edu; Sun, 10 Feb 2002 19:14:11 -0600 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g1B1EVj27667 for ; Mon, 11 Feb 2002 02:14:31 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id D6ECEC040; Mon, 11 Feb 2002 02:13:39 +0100 (CET) To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] definition of uni-/bi-directional flows Message-ID: <1013390019.3c671ac3b2cde@citadel.mobility.ccrle.nec.de> Date: Mon, 11 Feb 2002 02:13:39 +0100 (CET) From: quittek@ccrle.nec.de MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Hi all, I just ran into a strange problem: I tried to define precisely what is a uni-directional / bi-directional flow and found out that although I am discussing with you for quite some time using these terms, I cannot tell precisely, what they are. Does anyone have such a definition? Of course I can define them easily when I restrict flows to 5-tuple TCP/UDP flow without wild-carding, but when I start to include aggregated flows, for example all packets originating in a specific subnet, and ICMP flows, and multicast flows (multi-directional?), then it gets much more complicated. 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 Mon Feb 11 01:25:50 2002 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 BAA17897 for ; Mon, 11 Feb 2002 01:25:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16a9cw-0001ko-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 00:07:46 -0600 Received: from c001-h008.c001.snv.cp.net ([209.228.32.122] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16a9cu-0001jI-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 00:07:44 -0600 Received: (cpmta 18286 invoked from network); 10 Feb 2002 22:07:12 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.122) with SMTP; 10 Feb 2002 22:07:12 -0800 X-Sent: 11 Feb 2002 06:07:12 GMT Message-ID: <012001c1b2c2$b3cc6140$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: Subject: [ipfix] IPFIX Drafts Date: Sun, 10 Feb 2002 23:09:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Here are the drafts for the IPFIX dated 2-10-2002. If you cannot access them on the website, email me and I will send them to you. I have tried to put together the components as well as possible, but I know I missed things. What we need to do now is to correct items wrong, add items missing, fill in any blanks, reorder the sections and prepare them to go out. NOTE. I did split the architecture and the data drafts into 2. It ended up being easier to work with and discuss. There are still some issues being discussed. Not all of that is put in the documents. Juergen has also added some comments yesterday, but no one has had a chance to discuss them, so they are not included. I will add them as they get closure. As you comment on things, please work all comments on the numbering I have in these documents. Text format: http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt Word format: http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc A couple of things. I am seeing a "us versus them" attitude in the WG on the draft the Beniot and Ganesh put together. This is not right. These documents are great. I think it is now time that we work together and make one set of documents that the whole group agrees on. Like ours, theirs document some work to complete. Lets combine their work with ours and have one set of documents for the WG. When I put ot my first 2 drafts together, The were never intended to be the real WG documents. We needed to start somewhere so after talking to Nevil, I put them out to get things going and start the discussion. We now have documents that are workable that everyone has been able to provide input to. K.C. -- 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 Feb 11 03:20:40 2002 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 DAA26367 for ; Mon, 11 Feb 2002 03:20:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aBHs-0003ww-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 01:54:08 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aBHp-0003wI-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 01:54:06 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g1B7rYG13710; Mon, 11 Feb 2002 08:53:34 +0100 (CET) Date: Mon, 11 Feb 2002 08:53:34 +0100 (CET) From: Benoit Claise Message-Id: <200202110753.g1B7rYG13710@bru-cse-222.cisco.com> To: ipfix-arch@net.doit.wisc.edu, reinaldo_penno@nortelnetworks.com Subject: Re: [ipfix-arch] Answer to the recent comments on the Architecture Draft Cc: quittek@ccrle.nec.de X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver Mister Penno, > > 1 - General Stuff: > > : > :The draft distributed by KC discusses a lot of far related > :issues, but some essential components of the architecture are > :(so far) rather poorly described. This is different in the > :I-D of Ganesh and Benoit. > : > :So why don't we take some text from it. I think their intention > :is to contribute to the joint document (see their title). > > I really do not know what you mean by this. Are you trying to help them? > It seems that you have a little problem either with Ganesh and me. Or either with the company that Ganesh and I are working for. As I don't know you from anywhere, I tend to be believe of the latter option. Because, what kind of reply did you formulate? Is this a technical argument? Or just to be negative to what engineers of a certain company are proposing. Please explain. BTW, one of Steve Coya's sentence during the introduction presentation before an IETF is: "don't come to the playground if you're not ready to share your toys".And this is what Ganesh and I have doing, by even sharing our customers feedback. But you seem to be negativ to whatever we propose... by principle? While we are at the explanation time, just a little remark that made me smile. But I'm not sure many people noticed. I read through your paragraph IPFIX WG Kevin Zhang Internet Draft XACCT Technologies Expiration: August 2002 Reinaldo Penno NortelNetworks February 2002 Contributions to the IPFIX Architecture (Capability Negotiation) ... 10.2.2 Reliability ... In the case there are multiple collectors operating redundant mode, the exporter MAY multicast the flow records to the set of collectors that joined the export multicast group, instead of sending several unicast streams towards the different collectors. Multicast would lower the bandwidth requirements on the export link in case that the collectors are on the same media, and could lower the internal bus utilization on the exporter. And I thought.. Hmmm, I know this paragraph. It looks familiar. http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt Yes actually I wrote it ;) So what's the point here? Instead of having a discussion on basic architecture pints, are we just writing and writing paragraphs just to make sure to have his own name on a draft/rfc? Basically, I don't care too much about my name if we do this IPFIX right... Have a nice day. Benoit. -- 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 Feb 11 04:00:58 2002 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 EAA26815 for ; Mon, 11 Feb 2002 04:00:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aC1q-0004z6-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 02:41:38 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aC1n-0004xY-00; Mon, 11 Feb 2002 02:41:36 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1B8f5a94329; Mon, 11 Feb 2002 09:41:05 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id JAA24931; Mon, 11 Feb 2002 09:41:02 +0100 Date: Mon, 11 Feb 2002 09:42:52 +0100 From: Juergen Quittek To: Reinaldo Penno , ipfix-arch@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu Subject: [ipfix-arch] not integrating Ganesh's and Benoit's contribution (was: Re: Answer to the recent comments on the Architecture Draft) Message-ID: <4103258389.1013420572@[192.168.102.164]> In-Reply-To: <4F973E944951D311B6660008C7917CF008982233@zsc4c008.us.nortel.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Reinaldo, First of all, I separated my comments into several emails covering different subject. As you noticed, I covered different subjects in these messages. And my experience is that discussing several issues in parallel with the same subject line is a bad idea, because then it is harder to follow discussions on the individual subjects. Therefore, I split again my responses to your message. Here is the first one. --On 09 February 2002 22:30 -0800 Reinaldo Penno wrote: > > Hello Juergen, > > let me address your concerns in one email, although some of these items were already discussed ad-nauseum. > > Here it goes. > > 1 - General Stuff: > > : > :The draft distributed by KC discusses a lot of far related > :issues, but some essential components of the architecture are > :(so far) rather poorly described. This is different in the > :I-D of Ganesh and Benoit. > : > :So why don't we take some text from it. I think their intention > :is to contribute to the joint document (see their title). > > I really do not know what you mean by this. Are you trying to help them? What do you mean by "helping THEM"? Is there a 'us' and 'them'? They are members of the design team. My intention is to help US in making good progress. For what would Ganesh and Benoit need my help? For futher making technically good contributions to this working group? I think that so far, they made the most substancial contributions to our architecture discussion - technically speaking. I agree, that they should have told us earlier, how much effort they already spent in the architecture. But I think beyond his they did everything right. They just compiled all their contributions in the I-D text format and distributed them. It was a decision of the design team at the last phone conference that they should submit their contributions as an individual I-D. This is exactly the working groups are recommended to exchange and discuss contributions of the size of theirs. My point is that I am confused about the fact that KC ignored everything they wrote when compiling the design team's draft, particularly because issues covered by Ganesh's and Benoit's draft are not covered in the drqaft he distributed. Is a later integration planned? Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Feb 11 05:22:29 2002 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 FAA27707 for ; Mon, 11 Feb 2002 05:22:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aDGN-0006tm-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 04:00:43 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aDGJ-0006rV-00; Mon, 11 Feb 2002 04:00:39 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1BA08a99088; Mon, 11 Feb 2002 11:00:08 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA25831; Mon, 11 Feb 2002 11:00:05 +0100 Date: Mon, 11 Feb 2002 11:01:56 +0100 From: Juergen Quittek To: Reinaldo Penno , ipfix-arch@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu Subject: design goal: hardware support? (was [ipfix-arch] Answer to the recent comments on the Architecture Draft) Message-ID: <4108001609.1013425316@[192.168.102.164]> In-Reply-To: <4F973E944951D311B6660008C7917CF008982233@zsc4c008.us.nortel.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Reinaldo, --On 09 February 2002 22:30 -0800 Reinaldo Penno wrote: > > Hello Juergen, > > let me address your concerns in one email, although some of these items were already discussed ad-nauseum. > > Here it goes. > > 1 - General Stuff: > > : > :The draft distributed by KC discusses a lot of far related > :issues, but some essential components of the architecture are > :(so far) rather poorly described. This is different in the > :I-D of Ganesh and Benoit. > : > :So why don't we take some text from it. I think their intention > :is to contribute to the joint document (see their title). > > I really do not know what you mean by this. Are you trying to help them? > > :Please consider that the meter will be built partially in hardware > :which is costly. Here we can save a lot by reducing some functions. > :The data collector implemented by software can be much more flexible > :with less cost. > > huh? What are you talking about? okay, then *your* meter or who else > you are going to supply CHIPs to is going to be built partially in hardware. > Please do not generalize. The meter can be a PC-probe running some software. Sorry, I guess you got me wrong. I did not say all implementations of the meter must be in hardware. I just said that there will be hardware-supported implementations of the meter (at least this is my plan at NEC). Therefore I like to have an eye on not making hardare implementations too costly, particularly when choosing the features of the meter. I do not understand why you concluded that I generalize and ignore software implementations. > > :So lets have a protocol which is more flexible as NetFlow version > :1-7, > > I will not comment on that too much...Basically we are not here to > reverse-engineer Netflow, but to incorporate some good ideas from it. I fully agree. Particularly, we do not have to re-engineer anything, because we have Cisco engineers on board. > > :but not much more complicated, in order to be successfully > :accepted by hardware vendors and application programmers. > > ohh, please...Then Netflow is just right? Well, if you had read my explicit statement a few lines above, you would know that I do not think that NetFlow 1-7 is what we need. But I definitely think that we should define something that easily intergrated into router products. Therefore cost of development and cost of production are not to be completely ignored. Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Feb 11 05:27:10 2002 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 FAA27785 for ; Mon, 11 Feb 2002 05:27:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aDRR-0007F5-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 04:12:09 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aDRP-0007Dn-00 for ipfix-req@net.doit.wisc.edu; Mon, 11 Feb 2002 04:12:07 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1BABaa99436 for ; Mon, 11 Feb 2002 11:11:36 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id LAA25946 for ; Mon, 11 Feb 2002 11:11:33 +0100 Date: Mon, 11 Feb 2002 11:13:24 +0100 From: Juergen Quittek To: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Message-ID: <4108689799.1013426004@[192.168.102.164]> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, Here is my list of proposed changes to draft-ietf-ipfix-reqs-00.txt. I know that Benoit also is going to send some suggestions. And of course anyone else should feel free to do so. Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de 1. insert new section "2. Terminology" 2. Make section "1.1 IP Flows" new section "2.1. IP Traffic Flows or Flows" 3. Add sections 2.2 to 2.8: 2.2. Observation Point The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a port of a router, or an entire router with several ports. 2.3. Trafic Flow Meter or Meter A meter observes packets at one or more obsrvation points. It analyzes the content of the packets and maps them to flows. For each observed flow the meter computes statistics and maintains a flow record where it stores relevant flow infromation. 2.4. Metering Process The metering process includes all actions performed by a meter with respect to observing packets, timestamping them, analyzing them, mapping them to flows, computing flow statistics, detecting flow expiration, and maintaining flow records. 2.5. Flow Record A flow record keeps information a flow including characteristic properties of the flow, for example the source IP address, and measured properties of the flow, for example the total number of bytes of all packets of the flow. 2.6. Flow Information Exporter or Exporter The exporter sends flow records created and maintained by one or more meters to one or more data collectors. 2.7. Flow Information Data Collector or Data Colletor The data collector receives flow records from one or more exporters. The data collector might process or store received flow record, but these actions are out of the scope of this document. 2.8. Flow Information Exort Flow information export denotes the process of transferring flow records from an exporter to a data collector. 4. Remove section 2.5 Network Surveillance 5. In section 2.6, 3rd paragraph: remove "'Heisenberg' effects," 6. In section 4.1, last sentence: replace "then it SHOULD be stored ... inaccurately." by "then the measuring device MUST be able to detect this failure and to report about it." 7. Replace section "4.2 Sampling" by section "4.2 Overload Behavior": In case of an overload, e. g. lack of memory or processing power, the measuring device MAY change the metering process in order to cope with the lack of resources. Possible reactions include: - Reduce the number of flow accounts. This can be achieved by more coarse grained flow measurement or by a restriction of the flow accounts to a subset of the set of original ones. - Sample packets before they are processed by the meter. - Stop metering. Overload behavior is not restricted to the three options listed above. But in any case, the overload behavior MUST be clearly defined. For example in case of sampling, the sampling method and all its parameters MUST be known or indicated. 8. Append to section "4.3 Timestamps" Also in case of a switch to overload behavior, a timestap MUST be generated for this event as well as for a switch back to regular behavior. 9. Change section 5.3.1. "Congestion Awareness" to "Congestion-Friendlyness" Replace text of subsection by "For the flow information export a congestion-friendly protocol MUST be supported." 10. Insert new section 5.3.3 Robustness Data transfer SHOULD be robust against network and system fault conditions. Robustness may be supported for example by - flow control - by deploying redundant data receiving systems - fail-over/fail-back procedures. However, robustness should not be traded with congestion-friendlyness which has higher priority. 11. Update reference [MIDBOXTAX] which is now updated to version -03. 12. Remove all entries for network surveillance from table in Appendix 13. Update Table in appendix according to changes in text. -- 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 Feb 11 06:36:00 2002 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 GAA28382 for ; Mon, 11 Feb 2002 06:36:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aEQZ-0001oU-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 05:15:19 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aEQW-0001oL-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 05:15:16 -0600 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BBH3Q14699 for ; Mon, 11 Feb 2002 05:17:06 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Feb 2002 05:15:12 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 05:15:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Date: Mon, 11 Feb 2002 06:15:10 -0500 Message-ID: Thread-Topic: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Thread-Index: AcGxNGMXBEabwaTxRPmsu201OzLU+ABufLEQ From: To: , Cc: , , X-OriginalArrivalTime: 11 Feb 2002 11:15:11.0402 (UTC) FILETIME=[5F01A0A0:01C1B2ED] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA28382 As per charter we have only two deliverables. This is the main reason we have to put it architecture. Regards Ramg >-----Original Message----- >From: ext quittek@ccrle.nec.de [mailto:quittek@ccrle.nec.de] >Sent: Saturday, February 09, 2002 1:24 AM >To: Tanja Zseby >Cc: Ganesh Sadasivan; zseby@fokus.gmd.de; ipfix-arch@net.doit.wisc.edu >Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring > > >Hi Tanja, > >I agree with your statement. The discussion of interaction with AAA >should not be part of the architecture document. So, let's take it >out of it. > >Also I agree that this might fit very well into an applicability >document. Why don't you just start editing one based on your text. > >Best wishes, > > Juergen >-- >Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > >Tanja Zseby wrote: > >> Hi Ganesh >> >> I agree, that different applications can be consumer of IPFIX data. >> Nevertheless, AAA defines a whole architecture for accounting and >> itself provides input to accounting and billing >applications. Therefore >> >> I think we need to show how IPFIX and AAA can work together. I agree >> that it is not the task of IPFIX to define the interfaces. >And maybe you >> are right, and the architecture document is not the rigtht place for >> this. If Nevil writes something on relations to RTFM we could put >> together a document on relations between IPFIX and other >WGs/frameworks. >> >> Or really start a applicability document with sections for >the target >> applications mentioned in the requirements draft. >> >[...] > >-- >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/ > -- 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 Feb 11 06:36:16 2002 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 GAA28394 for ; Mon, 11 Feb 2002 06:36:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aEWJ-000266-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 05:21:15 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aEWI-00025W-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 05:21:14 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1BBKha02374; Mon, 11 Feb 2002 12:20:43 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA26785; Mon, 11 Feb 2002 12:20:40 +0100 Date: Mon, 11 Feb 2002 12:22:30 +0100 From: Juergen Quittek To: ram.gopal@nokia.com, zseby@fokus.gmd.de cc: gsadasiv@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Message-ID: <4112836121.1013430150@[192.168.102.164]> In-Reply-To: X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ram, --On 11 February 2002 06:15 -0500 ram.gopal@nokia.com wrote: > As per charter we have only two deliverables. This is the > main reason we have to put it architecture. > Regards > Ramg I would be fine with having a separate section in the architecture RFC titled "applicability statements" or similarly. However, if you refer to the charter, then please read the last goal stated there: "May 02 - Submit IPFX-ARCHITECTURE to IESG for publication, Proposed Standard RFC (also need an Applicability Statement RFC)" Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > >> -----Original Message----- >> From: ext quittek@ccrle.nec.de [mailto:quittek@ccrle.nec.de] >> Sent: Saturday, February 09, 2002 1:24 AM >> To: Tanja Zseby >> Cc: Ganesh Sadasivan; zseby@fokus.gmd.de; ipfix-arch@net.doit.wisc.edu >> Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring >> >> >> Hi Tanja, >> >> I agree with your statement. The discussion of interaction with AAA >> should not be part of the architecture document. So, let's take it >> out of it. >> >> Also I agree that this might fit very well into an applicability >> document. Why don't you just start editing one based on your text. >> >> Best wishes, >> >> Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> >> >> Tanja Zseby wrote: >> >>> Hi Ganesh >>> >>> I agree, that different applications can be consumer of IPFIX data. >>> Nevertheless, AAA defines a whole architecture for accounting and >>> itself provides input to accounting and billing >> applications. Therefore >>> >>> I think we need to show how IPFIX and AAA can work together. I agree >>> that it is not the task of IPFIX to define the interfaces. >> And maybe you >>> are right, and the architecture document is not the rigtht place for >>> this. If Nevil writes something on relations to RTFM we could put >>> together a document on relations between IPFIX and other >> WGs/frameworks. >>> >>> Or really start a applicability document with sections for >> the target >>> applications mentioned in the requirements draft. >>> >> [...] >> >> -- >> 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/ >> > -- 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 Feb 11 06:36:18 2002 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 GAA28405 for ; Mon, 11 Feb 2002 06:36:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aERX-0001pt-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 05:16:19 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aERV-0001pK-00; Mon, 11 Feb 2002 05:16:17 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1BBFka02274; Mon, 11 Feb 2002 12:15:46 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA26730; Mon, 11 Feb 2002 12:15:43 +0100 Date: Mon, 11 Feb 2002 12:17:32 +0100 From: Juergen Quittek To: Reinaldo Penno , ipfix-arch@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu Subject: middlebox issues (was: [ipfix-arch] Answer to the recent comments on the Architecture Draft) Message-ID: <4112538423.1013429852@[192.168.102.164]> In-Reply-To: <4F973E944951D311B6660008C7917CF008982233@zsc4c008.us.nortel.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Reinaldo, --On 09 February 2002 22:30 -0800 Reinaldo Penno wrote: > [...] > > 2 - Middlebox: > > :In my view this section is completely useless in its current > :state. What does it say about the architecture? > : > :It states that if you meter on a firewall you can do this, > :you can do that. Maybe you can do even other things. > :Yes, a firewall can silently drop packets, drop them > :and export them, or drop them and send a message about this. > :But this is not a text book. What is the suggestion for the > :architecture? > > This is the first draft of the architecutre document. In the > next interaction we will propose what methods SHOULD be > supported if you offer firewall services. OK, let's continue discussion when we have the concrete text. > As far the text book statement, I disagree. Some people > confuse technical writing with bad writing. I think that > providing a small introductory section and associated reference > is a good writing practice. Of course , you feel free to disagree. Thank you for allowing me to disagree. I just mentioned text books, because it should explain the difference. Writing a good text book need good writing skills as well as writing good standards documents. However, the goals of both kinds of documentd are different. In standard documents you wat to have a clear and unambigous definiton or description of technical issues. Now, if we are writing a standard document concerning flow information export we should definitely explain in detail what is a flow what is the metering process and the export process. However, when we talk about NATs in our document, we should not try to define them again, but rather refer to another document containing a definition agreed on by NAT experts. In this case RFC 2663 would serve well. Otherwise we risk to create ambiguities by having differences in the two definitions. > : > :My suggestion is deleting this section, and replacing it by > :a more general paragraph added to the description of the > :metering process, which is a subsection missing in section 4. > :There we can discuss packet drop at an observation point. > :Something like: > : > : Observed packets might be dropped at an observation point. > : If the meter can observe also the act of dropping it may > : add information on this to the flow record. > > Well, I disagree with this. This is on the other hand is too > generic. In the architecture document we need to set some sort > of expectations on the behavior of the exporter when other > services running on the same device can alter the result of > measurement process. I do not think we need to have service specific expectations. We can be open to implementations on a firewall to report on packet dropping or not. Otherwise you could not run a general prupose software implementation on a firewall, if it cannot report on firewall specific dropping. May be the three lines I suggested are too generic, but I do not see a reason yet, why we have to distinguish dropping on a firewall, drooping on a router, dropping at a traffic shaper, ... > : > :Then I suggest to add two IEs to section 9: > > This is already there... Thank you. I already found it and sent my more concrete comments on it to the architecture volunteers list. > > .. > > :We do not need a lecture on what is a NAT and what is a 'twice NAT'. > :This is (or should be) covered by other RFCs focussing on this issue. > > My argument is the same as before. Some people confuse > technical writing with bad writing. I think that providing a > small introductory section and associted reference is a good > writing practice that is followed in several RFC/I-D. > Of course, you feel free to dsagree. As mentioned above I distinguish good textbook writing from good conference paper writing and good standard document writing. > > :I suggest to replace sections 6.4.2. and 6.4.3. by a more general > :discussion of the issue in section 4, for eample: > : > : Observed packets might be modified at an observation point. > : Examples are changing the MPLS label, changing the DiffServ Code > : point at DiffServ markers, replacing IP addresses and port numbers > : at NATs, and even the increment of the TTL field. > : > > Same as above, this is too generic (specially in the case NAT). > I think we should set a minimum set of architectural considerations > when dealing with NAT. For instance, that is composed of two flows, > that in the case of twice NAT you should/must export both flows > (private and public) or otherwise notify the collector, etc, etc So you consider these to be two flows? Why then having the extra fields you call virtual address, virtual port, etc, if you anyway report two different flows? Just a reference to the other flow would be fine. I think we would go very well with a generic coverage of all middleboxes modifying packet headers (other than TTL). Particularly, after you already suggested that the modified field contains a tag indicating the reason for modification (NAT, DSCP marking, ...). > > :This comment refers to sections 6.4.2. Tunneling in the draft > :distributed by KC. > : > :The statement in the first paragraph is clearly an applicability > :statement. It does not belong to section 6 titled 'Architectural > :Requirements', but to a section called 'Applicability'. Or, if > :we will have a seaprate draft on applicability, we should move > :it there. > > Just like the NAT case, issues and behavior related to > > *Tunnel terminates on exporter > > *Tunnel initiates on exporter > > *Exporter implements tunnel switching > > should be discussed and the set of expectations established. In the > case of tunnel switching for instance, we should/must export the flows > of the incoming and outgoing tunnel. Similar to one of my statements above, I would not like to disallow a general pupose software implementation of IPFIX to run on a tunnel switch and to ignore all tunnel considerations by just monitoring the IP stack. This should be possible and the default case of our architecture! Specific things like support of tunneling is nice to have, but should definitely be optional. > :This comment refers to sections 6.4.5. VPNs in the draft > :distributed by KC. > : > :The first two paragraphs and subsection 6.4.5.1 (without > :6.4.5.1.1. and 6.4.5.1.2.) belong to a section on applicability > :statements and not to the IPFIX architectural requirements. > > The portion of text you mentioned is a introduction to the problem > statement. I could have just written section 6.4.5.1.2. directly, > but again, I consider that good practice and several RFC/I-D follow > this model. Somebody that do not understand VPN will just be lost. > > For that matter, the bottom line is that this whole draft is not > explicitly directed to you or even the people of this mailing list, > but to a much wider audience (the whole IETF and beyond). I still would remove these sections, but I do not insist in all the cuts I suggested. So let's go on and try to get more text > > > : > :Section 6.4.5.1.1. makes a good point in requesting an IE for > :the VPN-ID. However, the statement "MUST include VPN-ID in the > :exported flow record" is too strong. We may require that it > :MUST be able to do so, but the user should be free o configure > :export such that VPN-ID is not exported. > > Can you elaborate on why not exporting this? I did not say "forbid export", but just "not require export all times". Users should be able to select and configure themselves what fields to be exported. Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Feb 11 06:42:01 2002 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 GAA28483 for ; Mon, 11 Feb 2002 06:42:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aEYf-00029o-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 05:23:41 -0600 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aEYd-00029d-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 05:23:39 -0600 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BBNoQ04711 for ; Mon, 11 Feb 2002 05:23:50 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Feb 2002 05:23:37 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 05:23:36 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Date: Mon, 11 Feb 2002 06:23:35 -0500 Message-ID: Thread-Topic: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring Thread-Index: AcGy7kcpVP9widqGSF696Cmq7YQz5wAATUyw From: To: , Cc: , X-OriginalArrivalTime: 11 Feb 2002 11:23:36.0015 (UTC) FILETIME=[8BC775F0:01C1B2EE] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA28483 Its good then we can move the contents to last section ( may be ) as applicability. Regards Ramg >-----Original Message----- >From: ext Juergen Quittek [mailto:quittek@ccrle.nec.de] >Sent: Monday, February 11, 2002 6:23 AM >To: Gopal Ram (NRC/Boston); zseby@fokus.gmd.de >Cc: gsadasiv@cisco.com; ipfix-arch@net.doit.wisc.edu >Subject: RE: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring > > >Hi Ram, > >--On 11 February 2002 06:15 -0500 ram.gopal@nokia.com wrote: >> As per charter we have only two deliverables. This is the >> main reason we have to put it architecture. >> Regards >> Ramg > >I would be fine with having a separate section in the architecture >RFC titled "applicability statements" or similarly. > >However, if you refer to the charter, then please read the last >goal stated there: > > "May 02 - Submit IPFX-ARCHITECTURE to IESG for publication, > Proposed Standard RFC (also need an Applicability Statement RFC)" > >Cheers, > > Juergen >-- >Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > >> >>> -----Original Message----- >>> From: ext quittek@ccrle.nec.de [mailto:quittek@ccrle.nec.de] >>> Sent: Saturday, February 09, 2002 1:24 AM >>> To: Tanja Zseby >>> Cc: Ganesh Sadasivan; zseby@fokus.gmd.de; >ipfix-arch@net.doit.wisc.edu >>> Subject: Re: [ipfix-arch] IPFIX and AAA and IPFIX for QoS Monitoring >>> >>> >>> Hi Tanja, >>> >>> I agree with your statement. The discussion of interaction with AAA >>> should not be part of the architecture document. So, let's take it >>> out of it. >>> >>> Also I agree that this might fit very well into an applicability >>> document. Why don't you just start editing one based on your text. >>> >>> Best wishes, >>> >>> Juergen >>> -- >>> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >>> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >>> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >>> >>> >>> Tanja Zseby wrote: >>> >>>> Hi Ganesh >>>> >>>> I agree, that different applications can be consumer of IPFIX data. >>>> Nevertheless, AAA defines a whole architecture for accounting and >>>> itself provides input to accounting and billing >>> applications. Therefore >>>> >>>> I think we need to show how IPFIX and AAA can work >together. I agree >>>> that it is not the task of IPFIX to define the interfaces. >>> And maybe you >>>> are right, and the architecture document is not the rigtht >place for >>>> this. If Nevil writes something on relations to RTFM we could put >>>> together a document on relations between IPFIX and other >>> WGs/frameworks. >>>> >>>> Or really start a applicability document with sections for >>> the target >>>> applications mentioned in the requirements draft. >>>> >>> [...] >>> >>> -- >>> 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/ >>> >> > > > -- 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 Feb 11 08:03:53 2002 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 IAA29970 for ; Mon, 11 Feb 2002 08:03:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aFpk-0004U3-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 06:45:24 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aFph-0004Ts-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 06:45:22 -0600 Received: from fokus.fhg.de (dhcp187 [195.37.78.187]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1BCjJE19924 for ; Mon, 11 Feb 2002 13:45:19 +0100 (MET) Message-ID: <3C67BBDE.D6F73CF5@fokus.fhg.de> Date: Mon, 11 Feb 2002 13:41:02 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: "ipfix-arch@net.doit.wisc.edu" Subject: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit The draft is in a very early state but nevertheless i have some comments/questions: section 2: "* Describes the required mechanisms to interoperate with other protocol/architecture this may includes AAA or Diameter or Intrusion Detection system. * Identifies a minimal set of applications for IPFIX." I don't understand why this is part of the architecture document. It's fine to list a set of applications but describing these and the interaction with IPFIX is IMHO out of scope of the draft. section 3: Instead of repeating the terminology it may be sufficient to refer to the req. draft for some of the terms (assuming that the terminology drafts includes these as proposed by Juergen). section 4.1: "* In some cases, an observation point may perform metering as well." Whats does that mean? section 4.2: "* Measuring, aggregating and exporting IP Flow information to the respective collectors." The exporter does measurement? "* May perform appropriate middle-box functions to translate the flow information." I would suggest deleting or rewording this to something like: May add middle-box information to flow record but the exporter certainly does not perform middlebox functions. Am I right that the exporter does the packet to flow classification and statistics calculation? section 4.3: The text totally confuses me. Why is reliability and security now a function of the IPFIX protocol? The reqirements are already in the requirement draft and the protocol spec. will be in some future protocol draft I guess. Probably a wording issue which can be solved by omitting the word protocol. section 4.4: Why does the collector need to maintain a repository of IP flow statistics? Can't the application do that? section 5: Out of scope of this draft IMHO. There should be either an application draft or maybe different application drafts. section 6: I would suggest putting the requirements to the front after terminology section 6.4: I don't understand what are here the requirements on the architecture!? I don't think that these are architectural requirements. My understanding of this section is that according to certain middlebox functionality which may be done on the same system the exporter lives on IPFIX can provide specific information. I suggest to move that section at least a separate section "Architecture Considerations". Furthermore I think that it does *not* belong into the draft to define what information are exported based on some middlebox functionality. Maybe this sectio even could go into another draft. To avoid misunderstanding: I like the section but I think the place is wrong. section 6.5: Same comments as to 6.4 section 6.6: Again why is this in requirement section? I am not sure if it is a good idea to have some complex capability negotiation as part of IPFIX. How does this section relate to the IPFIX configuration? There seems to be some overlapp. section 6.6.1: It is possible that several protocols (e.g. LFAP, CRANE, Netflow, Diameter) meet the IPFIX requirements. In this case, this capability is used to negotiate which protocol the end points will use. Does this sections tells me that there is no single IPFIX protocol but instead there are a couple of protcols? So in the end we have a couple of protocols and each vendor implements a different. ;-) I think there should be a standardized protocol. section 6.6.2.6: What is the exact definition of overlapping flows? section 7: This could be extended e.g. by adding about transport protocol in the scanrios. -- Sebastian -- 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 Feb 11 08:30:49 2002 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 IAA01032 for ; Mon, 11 Feb 2002 08:30:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aGIz-00059i-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 07:15:37 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aGIx-00059W-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 07:15:35 -0600 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BDHRQ17711 for ; Mon, 11 Feb 2002 07:17:27 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Feb 2002 07:15:34 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 07:14:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt Date: Mon, 11 Feb 2002 08:14:53 -0500 Message-ID: Thread-Topic: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt Thread-Index: AcGy+xH6gwGFMUL1TkSoHrZT09oxnwAAu/AA From: To: , X-OriginalArrivalTime: 11 Feb 2002 13:14:54.0645 (UTC) FILETIME=[188D8650:01C1B2FE] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA01032 > >The draft is in a very early state but nevertheless i have >some comments/questions: > >section 2: > >"* Describes the required mechanisms to interoperate with >other protocol/architecture >this may includes AAA or Diameter or Intrusion Detection system. >* Identifies a minimal set of applications for IPFIX." > >I don't understand why this is part of the architecture >document. It's fine to list >a set of applications but describing these and the interaction >with IPFIX is IMHO >out of scope of the draft. Architecture should address both architectural requirements and should be support a mechanism for identified applications. I also agree some extent is may be out of scope and should be in applicability document we do not have one separate deliverable for this and this is the reason we covered in the architecture. > >section 3: Instead of repeating the terminology it may be >sufficient to refer to the >req. draft for some of the terms (assuming that the >terminology drafts includes these >as proposed by Juergen). Agree. >section 4.1: > >"* In some cases, an observation point may perform metering as well." > >Whats does that mean? > >section 4.2: > >"* Measuring, aggregating and exporting IP Flow information to >the respective collectors." > >The exporter does measurement? It is a logical functions it is upto the implementation where to place the functionality whether in exporter or collector or some other component. Logically the ideal place could be on exporter, where it is close to the traffic. >"* May perform appropriate middle-box functions to translate >the flow information." > >I would suggest deleting or rewording this to something like: >May add middle-box >information to flow record but the exporter certainly does not >perform middlebox >functions. Agreed. >Am I right that the exporter does the packet to flow >classification and statistics >calculation? Yes. >section 4.4: > >Why does the collector need to maintain a repository of IP >flow statistics? Can't the >application do that? May be for off-line analysis. Regards Ramg -- 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 Feb 11 09:12:00 2002 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 JAA02759 for ; Mon, 11 Feb 2002 09:12:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aGvz-00062z-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 07:55:55 -0600 Received: from [216.52.49.36] (helo=bosvwl02) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16aGvy-000620-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 07:55:54 -0600 Received: from 192.168.200.81 by bosvwl02 (InterScan E-Mail VirusWall NT); Mon, 11 Feb 2002 08:49:50 -0500 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 19:18:08 +0530 Received: from kecmsg01.ad.infosys.com ([204.4.54.44]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 19:18:07 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1B302.BC693E18" Subject: RE: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt Date: Mon, 11 Feb 2002 19:18:07 +0530 Message-ID: <10B94DB22F15D211B5740008C728A3020C1DE3F6@kecmsg01.ad.infosys.com> X-MS-TNEF-Correlator: <10B94DB22F15D211B5740008C728A3020C1DE3F6@kecmsg01.ad.infosys.com> Thread-Topic: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt Thread-Index: AcGy+xH6gwGFMUL1TkSoHrZT09oxnwAAu/AAAAEBkPk= From: "VENKATG" To: , , X-OriginalArrivalTime: 11 Feb 2002 13:48:07.0876 (UTC) FILETIME=[BC9C7040:01C1B302] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C1B302.BC693E18 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, This might have been discussed before, but i've not followed all the past mails very closely, hence this question. In the filw http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt and under section 5 [ Information Elements ], there does not seem to be any mention on the 'Version No' as one of the Information Elements. Do we not need this ? I feel that this would be needed once we use/extend the same frame-work for IPv6. Regards - venkat =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Venkatraman G Infosys Technologies Limited Bangalore=20 India-561229 ------_=_NextPart_001_01C1B302.BC693E18 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IggNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEATAAAAFJFOiBbaXBmaXgtYXJjaF0g Q29tbWVudHMvcXVlc3Rpb25zIG9uIGRyYWZ0LWlldGYtaXBmaXgtYXJjaGl0ZWN0dXJlLTAwLnR4 dACvGwEFgAMADgAAANIHAgALABMAEgAHAAEAEwEBIIADAA4AAADSBwIACwATABIABwABABMBAQmA AQAhAAAAMDIyNEUzNTk0MTI0REQ0NkFFREU0RTIxODA1NTAzMjEA7gYBA5AGANQJAAA2AAAAAwA2 AAAAAABAADkAGD5pvAKzwQEeAD0AAQAAAAUAAABSRTogAAAAAAIBRwABAAAANgAAAGM9VVM7YT0g O3A9SVRMSU5GT1NZUztsPUtFQ01TRzAxLTAyMDIxMTEzNDgwN1otMjMyNjI5AAAAHgBJAAEAAABM AAAAUkU6IFtpcGZpeC1hcmNoXSBDb21tZW50cy9xdWVzdGlvbnMgb24gZHJhZnQtaWV0Zi1pcGZp eC1hcmNoaXRlY3R1cmUtMDAudHh0AEAATgCAhJIX/rLBAR4AWgABAAAAFAAAAHJhbS5nb3BhbEBu b2tpYS5jb20AAgFbAAEAAABFAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAcmFtLmdvcGFsQG5v a2lhLmNvbQBTTVRQAHJhbS5nb3BhbEBub2tpYS5jb20AAAAAAgFcAAEAAAAZAAAAU01UUDpSQU0u R09QQUxATk9LSUEuQ09NAAAAAB4AXQABAAAAFAAAAHJhbS5nb3BhbEBub2tpYS5jb20AAgFeAAEA AABFAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAcmFtLmdvcGFsQG5va2lhLmNvbQBTTVRQAHJh bS5nb3BhbEBub2tpYS5jb20AAAAAAgFfAAEAAAAZAAAAU01UUDpSQU0uR09QQUxATk9LSUEuQ09N AAAAAB4AZgABAAAABQAAAFNNVFAAAAAAHgBnAAEAAAAUAAAAcmFtLmdvcGFsQG5va2lhLmNvbQAe AGgAAQAAAAUAAABTTVRQAAAAAB4AaQABAAAAFAAAAHJhbS5nb3BhbEBub2tpYS5jb20AHgBwAAEA AABIAAAAW2lwZml4LWFyY2hdIENvbW1lbnRzL3F1ZXN0aW9ucyBvbiBkcmFmdC1pZXRmLWlwZml4 LWFyY2hpdGVjdHVyZS0wMC50eHQAAgFxAAEAAAAgAAAAAcGy+xH6gwGFMUL1TkSoHrZT09oxnwAA u/AAAAEBkPkeAHQAAQAAADIAAAB6YW5kZXJAZm9rdXMuZ21kLmRlOyBpcGZpeC1hcmNoQG5ldC5k b2l0Lndpc2MuZWR1AAAAHgAaDAEAAAAIAAAAVkVOS0FURwAeAB0OAQAAAEgAAABbaXBmaXgtYXJj aF0gQ29tbWVudHMvcXVlc3Rpb25zIG9uIGRyYWZ0LWlldGYtaXBmaXgtYXJjaGl0ZWN0dXJlLTAw LnR4dAACAQkQAQAAAG0CAABpAgAAlgMAAExaRnWwQ+V9AwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3 /wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI 7wn3tjsYHw4wNREiDGBjAFDzCwkBZDM2FlALpgrjCoCYSGksHPQc9FRoBABgIG1pZ2gFQBPgdkhl IGIJ4SBkBABjvnUEEAmAHzECEBggLB8wknUFQGknHxFubwVAdQIQbBewdyABB0ADIHT2aB8gCrBz BUAAwAMQBCBhHxByeSBjF7AUEGzmeSCQImBuYx8gIlAeYVZxClAisGkCIC4dikk7A6AiUmYDEAfg HsB0cJg6Ly8hQBQCaC4FsFxnLwiQADAoAHAmkHjQL2RyYQGALSgSKRARKHItZGEBkC0wMLouDNB0 HYoAcCAQdStQCxKBFBBjJRIgNSBbHiAmICBRAMAsE0VsZfcHgAIwBCBdIJAiURggH4C+bweRIUIU EC2AIkBvHzF9IgBuI3AtkiwiLDEiUieOVgSQAJAsMU5vJyIA5wQgAiAfIG9mIkMsry2x/SVbRC9w IdAhMzIAIAEkg34/MpAhcAngIjIp4CR0d/0IYGwgEjVDIAECICRRNOF5H9BlLw7BCfA1gh8gc15h B4AhcCjQB4AtNyByhmshcQXASVB2NiVbsRz0UmVnCxEEIC0jMexuayngHYo9Pg8/Hz9i3xz0MQA9 AjnxA5FHJcYCENRzeQQgVAWQaCFAF7DWZwiQBCBMB3BpDrALMf0dEkIAcDxgF7EfICXGH5BJKgA1 Ng4gMjkc9H0BRlAAAAAeADUQAQAAAEMAAAA8MTBCOTREQjIyRjE1RDIxMUI1NzQwMDA4QzcyOEEz MDIwQzFERTNGNkBrZWNtc2cwMS5hZC5pbmZvc3lzLmNvbT4AAB4ARxABAAAADwAAAG1lc3NhZ2Uv cmZjODIyAAALAPIQAQAAAB8A8xABAAAApAAAAFIARQAlADMAQQAgAFsAaQBwAGYAaQB4AC0AYQBy AGMAaABdACAAQwBvAG0AbQBlAG4AdABzAP/4cQB1AGUAcwB0AGkAbwBuAHMAIABvAG4AIABkAHIA YQBmAHQALQBpAGUAdABmAC0AaQBwAGYAaQB4AC0AYQByAGMAaABpAHQAZQBjAHQAdQByAGUALQAw ADAALgB0AHgAdAAuAEUATQBMAAAACwD2EAAAAABAAAcw9un6BwKzwQFAAAgw0FB8vAKzwQEDAN4/ 5AQAAAMA8T8JAAAAHgD4PwEAAAAIAAAAVkVOS0FURwACAfk/AQAAAE0AAAAAAAAA3KdAyMBCEBq0 uQgAKy/hggEAAAAAAAAAL089SVRMSU5GT1NZUy9PVT1JVExLRUMvQ049UkVDSVBJRU5UUy9DTj1W RU5LQVRHAAAAAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB+z8BAAAAHgAA AAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAA AwAdQAAAAAADAB5AAAAAAB4AMEABAAAACAAAAFZFTktBVEcAHgAxQAEAAAAIAAAAVkVOS0FURwAe ADJAAQAAABQAAAByYW0uZ29wYWxAbm9raWEuY29tAB4AM0ABAAAAFAAAAHJhbS5nb3BhbEBub2tp YS5jb20AHgA4QAEAAAAIAAAAVkVOS0FURwAeADlAAQAAAAIAAAAuAAAACwApAAAAAAALACMAAAAA AAMABhA2ed2rAwAHENEBAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAASEksVEhJU01JR0hU SEFWRUJFRU5ESVNDVVNTRURCRUZPUkUsQlVUSVZFTk9URk9MTE9XRURBTExUSEVQQVNUTUFJTFNW RVJZQ0xPU0VMWSxIRU5DRVRISVNRVUVTVElPTklOVAAAAAACAX8AAQAAAEMAAAA8MTBCOTREQjIy RjE1RDIxMUI1NzQwMDA4QzcyOEEzMDIwQzFERTNGNkBrZWNtc2cwMS5hZC5pbmZvc3lzLmNvbT4A AF5g ------_=_NextPart_001_01C1B302.BC693E18-- -- 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 Feb 11 09:18:37 2002 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 JAA03059 for ; Mon, 11 Feb 2002 09:18:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aH4E-0006HD-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 08:04:26 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aH4C-0006GA-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 08:04:24 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1BE3sa07096; Mon, 11 Feb 2002 15:03:54 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA28631; Mon, 11 Feb 2002 15:03:50 +0100 Date: Mon, 11 Feb 2002 15:05:41 +0100 From: Juergen Quittek To: VENKATG , ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt Message-ID: <4122626459.1013439941@[192.168.102.164]> In-Reply-To: <10B94DB22F15D211B5740008C728A3020C1DE3F6@kecmsg01.ad.infosys.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 11 February 2002 19:18 +0530 VENKATG wrote: > > Hi, > > This might have been discussed before, but i've not followed all the > past mails very closely, hence this question. > > In the filw http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt > > and under section 5 [ Information Elements ], there does not seem to be > any mention on the 'Version No' as one of the Information Elements. > > Do we not need this ? I feel that this would be needed once we > use/extend the same frame-work for IPv6. > > > Regards - venkat > > ======================================= > Venkatraman G > Infosys Technologies Limited > Bangalore > India-561229 -- 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 Feb 11 09:24:57 2002 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 JAA03494 for ; Mon, 11 Feb 2002 09:24:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aH9n-0006OT-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 08:10:11 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aH9l-0006Nj-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 08:10:09 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1BE9da07264; Mon, 11 Feb 2002 15:09:39 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id PAA28688; Mon, 11 Feb 2002 15:09:35 +0100 Date: Mon, 11 Feb 2002 15:11:26 +0100 From: Juergen Quittek To: VENKATG , ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt Message-ID: <4122971675.1013440286@[192.168.102.164]> In-Reply-To: <10B94DB22F15D211B5740008C728A3020C1DE3F6@kecmsg01.ad.infosys.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Venkat, sorry, my previous email slipped to the outbox before I entered my comments. --On 11 February 2002 19:18 +0530 VENKATG wrote: > Hi, > > This might have been discussed before, but i've not followed all the > past mails very closely, hence this question. > > In the filw http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt > > and under section 5 [ Information Elements ], there does not seem to be > any mention on the 'Version No' as one of the Information Elements. > > Do we not need this ? I feel that this would be needed once we > use/extend the same frame-work for IPv6. I completely agree. This is already part of the requirements. Considering support for NAT-PTs (acting as gateways between IPv4 and IPv6) we should also include and IE for "virtual" or "modified" IP version Number. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > Regards - venkat > > ======================================= > Venkatraman G > Infosys Technologies Limited > Bangalore > India-561229 -- 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 Feb 11 10:03:28 2002 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 KAA04556 for ; Mon, 11 Feb 2002 10:03:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aHkO-0007F5-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 08:48:00 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aHkM-0007EN-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 08:47:58 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYA4K; Mon, 11 Feb 2002 06:46:46 -0800 Message-ID: <3C67D955.2C6990DB@riverstonenet.com> Date: Mon, 11 Feb 2002 09:46:45 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: Reinaldo Penno , will@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture References: <4F973E944951D311B6660008C7917CF00890F1BB@zsc4c008.us.nortel.com> <3C62FAF3.912C07EC@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I'll just restate my position. I think configuration in general should be done outside the protocol. The only exception so far for me is allowing in-band the setting of fields reported. It is a difficult point to argue because Reinaldo can show all the nice things you can do with in-band negotiation, which is true. But the devil and the hassle is in the details which you don't see until implemention. By then it is too late to turn back. For example, one of the things we configure is what ports we want to collect flows on. Is that done in-band? Does the collector tell the exporter? We also tell it the pattern of flows to report on (done as an ACL). Is that done in band? What happens if I'm talking to more than one collector and I get conflicting requests? Paul -- 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 Feb 11 10:08:57 2002 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 KAA04734 for ; Mon, 11 Feb 2002 10:08:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aHpj-0007OO-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 08:53:31 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aHph-0007Nf-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 08:53:29 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYAVZ; Mon, 11 Feb 2002 06:52:19 -0800 Message-ID: <3C67DAA1.DD04A0D6@riverstonenet.com> Date: Mon, 11 Feb 2002 09:52:17 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: Reinaldo Penno , will@cisco.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] RE: IPFIX Architecture References: <4F973E944951D311B6660008C7917CF00890F314@zsc4c008.us.nortel.com> <3C631A62.B2FB6107@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit One more thing on this. I might also be better to do a IPFIX V1 without negotiation and then look at it again for V2 when we have a better idea for the IPFIX protocol and the kinds of things that would benefit from negotiation. Paul -- 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 Feb 11 10:38:08 2002 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 KAA06136 for ; Mon, 11 Feb 2002 10:38:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aIA8-00005a-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 09:14:36 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aIA6-000053-00 for ipfix-data@net.doit.wisc.edu; Mon, 11 Feb 2002 09:14:34 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYA7Y; Mon, 11 Feb 2002 07:13:23 -0800 Message-ID: <3C67DF92.9300E75A@riverstonenet.com> Date: Mon, 11 Feb 2002 10:13:22 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jc Martin CC: Simon Leinen , kcn@norseth.com, data Subject: Re: [ipfix-data] Re: Information Model References: <20020205204955.5721.cpmta@c001.snv.cp.net> <3C61557E.2F3B2D05@riverstonenet.com> <3C61AD4B.1D6176E3@sun.com> <3C63FA98.66C50F57@riverstonenet.com> <3C6408B1.CA9AB200@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jc Martin wrote: > > calato@riverstonenet.com wrote: > > > > Jc Martin wrote: > > > > > > See my comments inline. > > > > > > calato@riverstonenet.com wrote: > > > > > > > > Here is a first cut at the list of data elements to be reported. > > > > I of course hacked it out of the LFAP spec. > > > > > > > > I think we need to begin with a couple of guidlines (which > > > > we should augment as we go). They are just guidelines. > > > > > > > > 1. Data element values should be defined in terms of > > > > other specifications. Since we are only reporting > > > > things in other protocols, there should be little > > > > reason for us to define anything from scatch. > > > There are two parts in the above. One is where the protocol field > > > is defined, and the other is where the field is encoded in another > > > standard. > > > So, for example, the source port is defined in RFC 768, but it's > > > definition (representation ?) could be imported from RFC 1155 or CIM > > > (like RFC3060 is doing). > > > > Are you talking about format on the wire? If so, I'm > > not attempting to define that. Just semantics > > Not only. You have some concepts, like Gauge, Counter, that have a specific > semantic, and a well defined behavior. > I don't have other examples, but I suspect that all parameters that are not > directly derived from a protocol would fold in the same group (like interfaces,...). Ahhh, so if I understand, you are saying that for things not coming from another protocol spec, there are likely definitions we can use from other specs. I recall seeing the Gauge, Counter stuff somewhere. > > [snip] > > > > > contained in this IE is vendor specific. OID and OID Value is > > > > defined by ITU X.680.X683 (1997) and is encoded as defined by ITU > > > > X.690.691(1997). This IE MUST not contain any information which > > > > cannot be safely ignored by the Exporter or Collector. If multiple > > > > Vendor > > > > Specific IE's with the same OID occur, then the vendor defines > > > > semantics of ordering. > > > > > > you are mentionning the OID here, what about the other elements ? > > > > I'm not sure how the other elements are encoded. But in this > > case we MUST provide a way for vendors to add stuff with out > > stepping on each other. This OID is one way to solve it. If > > we use OID for the other elements as well then we wont need > > special mention here. But until the encoding stuff is done > > I added mention of OID here. > > > I don't think that the notion of naming is specific to the encoding. > It's a basic feature of the information model. I think that this > should be spelled out in a specific section, and applied to all > attributes or standard templates. What I meant was that most of the accounting specs today create their own numbering system. If IPFIX does that then we need to use OID for the Vendor stuff. But if IPFIX has OIDs to refer (name) to their data elelemts then the vendor one will not be special. > > JC. -- 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 Feb 11 10:41:25 2002 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 KAA06313 for ; Mon, 11 Feb 2002 10:41:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aIL9-0000Mg-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 09:25:59 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aIL7-0000Lt-00; Mon, 11 Feb 2002 09:25:57 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYBA4; Mon, 11 Feb 2002 07:24:46 -0800 Message-ID: <3C67E23C.28362D1C@riverstonenet.com> Date: Mon, 11 Feb 2002 10:24:44 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Wang, Cliff" CC: Ganesh Sadasivan , kevin.zhang@xacct.com, "KC' 'Norseth" , ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, ipfix-chairs@net.doit.wisc.edu, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Re: IPFIX Architecture References: <4652644B98DFF34696801F8F3070D3FE01188693@D2CSPEXM001.smartpipes.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit "Wang, Cliff" wrote: > > You may need fail over if 1) you want load balancing 2) you assign some kind > of priority to servers so that the when a high priority server comes back > you roll the session over. I assume this requirement is only on the > collector side. Depends on who initiates the connection, I think. > > -----Original Message----- > From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > Sent: Friday, February 08, 2002 10:58 AM > To: Ganesh Sadasivan > Cc: kevin.zhang@xacct.com; KC' 'Norseth; > ipfix-data-volunteers@net.doit.wisc.edu; > ipfix-arch-volunteers@net.doit.wisc.edu; ipfix-chairs@net.doit.wisc.edu; > ipfix-arch@net.doit.wisc.edu > Subject: Re: [ipfix-arch] Re: IPFIX Architecture > > > - Supporting fail-over and fail-back procedures, and performing load > > balancing if required. > >G: > >Fail-back is not possible on a router -> too much memory needed. The > >best we can do is fail-over. > >G: > > Not sure why. I think this is as simple as detecting > the server is back and droping the existing connection > in favor of the other. -- 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 Feb 11 10:42:43 2002 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 KAA06352 for ; Mon, 11 Feb 2002 10:42:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aIMA-0000Ns-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 09:27:02 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aIM8-0000N7-00; Mon, 11 Feb 2002 09:27:00 -0600 Received: from postal.cisco.com (postal.cisco.com [171.71.160.26]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1BFPMZ21595; Mon, 11 Feb 2002 07:25:22 -0800 (PST) Received: from WILLW2K (rtp-vpn1-423.cisco.com [10.82.225.167]) by postal.cisco.com (Mirapoint) with SMTP id AAK00494; Mon, 11 Feb 2002 07:25:40 -0800 (PST) Reply-To: From: "Will Eatherton" To: "Reinaldo Penno" , , Cc: , , Subject: [ipfix-arch] Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Mon, 11 Feb 2002 07:24:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C1B2CD.136795C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <4F973E944951D311B6660008C7917CF008982233@zsc4c008.us.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1B2CD.136795C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Answer to the recent comments on the Architecture DraftGroup, Cisco's interest in IPFIX was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner). If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo, it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol. Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX. It seems time for an official call on what is in/out of scope for IPFIX. As has been mentioned here multiple times we would like to hear : - the exporter configuration is out of the scope of this document (the exporter configuration out of band) - no transport negotiation (which transport) - no capability negotiation Will :So lets have a protocol which is more flexible as NetFlow version :1-7, I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it. :but not much more complicated, in order to be successfully :accepted by hardware vendors and application programmers. ohh, please...Then Netflow is just right? Reinaldo ------=_NextPart_000_0000_01C1B2CD.136795C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture = Draft
Group,
 
Cisco's interest in IPFIX  was to help = establish=20 a non-proprietary protocol similar to netflow but more flexible = allowing us=20 to add value to our customers (and do so in a timely = manner).  If=20 IPFIX goes down a path along the lines as being advocated recent = threads by=20 Reinaldo,  it is unclear if the added burden of the protocol = will be=20 make it worth the benefits of a non-proprietary = protocol.  Given it=20 seems I have seen roughly the same conversation occur 3 times in past = several=20 day, It is unclear if further email discussion on this topic will = resolve the=20 underlying question as to the scope of IPFIX.  It seems=20 time for an official call on what is in/out of scope for=20 IPFIX.  As has been mentioned here multiple times we = would like=20 to hear :  

- the exporter = configuration is out of=20 the scope of this document =20  (the exporter configuration out of band)

- no transport = negotiation (which=20 transport)

 - no capability=20 negotiation

Will

:So lets have a protocol which is more flexible as = NetFlow=20 version
:1-7,

I will not comment on that too much...Basically we = are not=20 here to reverse-engineer Netflow, but to incorporate some good ideas = from=20 it.

:but not much more complicated, in order to be=20 successfully
:accepted by hardware vendors = and=20 application programmers.

ohh, please...Then Netflow is just right? =

Reinaldo=20






------=_NextPart_000_0000_01C1B2CD.136795C0-- -- 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 Feb 11 10:49:57 2002 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 KAA06743 for ; Mon, 11 Feb 2002 10:49:56 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aIPO-0000Sw-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 09:30:22 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aIPM-0000Re-00 for ipfix-req@net.doit.wisc.edu; Mon, 11 Feb 2002 09:30:21 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g1BFTnb27134; Mon, 11 Feb 2002 16:29:49 +0100 (CET) Date: Mon, 11 Feb 2002 16:29:49 +0100 (CET) From: Benoit Claise Message-Id: <200202111529.g1BFTnb27134@bru-cse-222.cisco.com> To: ipfix-req@net.doit.wisc.edu, quittek@ccrle.nec.de Subject: [ipfix-req] Re: [ipfix] Terminology suggestion X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver Hi Juergen, Here are my input on this terminology, as promised during the conf. call. Note that whether the definitions go into the requirements draft or in the architecture doesn't make any difference to me. This only thing of importance is that, if the requirement draft dissapears with the time, we don't want to loose the defintions. One solution is that the architecture document will have to repeat the definitions. > > see draft-ietf-ipfix-reqs-00.txt, section 1.1 I just copied the definition from draft-ietf-ipfix-reqs-00.txt for completeness. A flow is a set of packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties derived from the data contained in the packet and from the packet treatment at the observation point. I would go a little bit further in the definition, by describing what a property coul be: A flow is defined as a set of packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: a. one or more of packet header fields (eg. destination IP address) b. one or more properties of the packet itself (eg. packet length) c. one or more of fields derived from packet treatment (eg. AS number) A packet is defined to belong to a flow if it matches all the defined properties of the flow. > > 2.2. Observation Point > The observation point is a location in the network where IP packets > can be observed. Examples are a line to which a probe is attached, > a shared medium, such as an Ethernet-based LAN, a port of a router, > or an entire router with several ports. I agree with the definition above, but I would be more specific: The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a port of a router, or an entire router with several ports. The observation is characterized by one or a set of interfaces (physical or logical) of the exporter. Note: the exporter is defined below. > > 2.3. Trafic Flow Meter or Meter > A meter observes packets at one or more observation points. > It analyzes the content of the packets and maps them to flows. > For each observed flow the meter computes statistics and maintains > a flow record where it stores relevant flow infromation. I think that the concept of exporter makes more sense. And I believe that you are mixing 2 definitions: - the exporter (ex: a router or a probe) - the metering process which analyzes the traffic So I would just remove this definition and leave the exporter/metering process as 2 definitions. * Exporter: The entity on which flows are measured and are exported. The exporter can be a router, a middlebox [2], or a traffic measurement probe. > > 2.4. Metering Process > The metering process includes all actions performed by a meter > with respect to observing packets, timestamping them, analyzing them, > mapping them to flows, computing flow statistics, detecting flow > expiration, and maintaining flow records. Measurement process that is carried out at the observation domain. The metering process includes all actions performed by a meter with respect to observing packets, timestamping them, analyzing them, mapping them to flows, computing flow statistics, detecting flow expiration, and maintaining flow records. Note: we had to introduce the concept of observation domain. * Observation Domain: The set of observation points which is the largest aggregatable set of flow information at the exporter is termed as an observation domain. The observation domain presents itself a unique ID to the collector for identifying the export packets generated by it. Example: The observation domian could be a router linecard, composed of several interfaces with each interface being an observation point. Why the concept of observation domain? Typically for a linecard on a router, which is an independant entity. So an exporter can be composed of several observation domains (read linecards). There is one metering process per observation domain (read linecard). You can do flow aggregations for these linecard flows but not between flows from different linecards. Note: I agree that we are missing a high level picture of this in draft-gsadasiv-ipfix-proposal-00.txt > > 2.5. Flow Record > A flow record keeps information a flow including characteristic > properties of the flow, for example the source IP address, > and measured properties of the flow, for example the total number > of bytes of all packets of the flow. All packets belonging to a particular flow have a set of common properties. But the flow record doesn't necessarily have the notion of its own properties. I would remove the properties part. Here is the definition I would propose. * Flow Record: A flow record provides information about a specific flow that was measured at an observation point using a certain set of methods within an exporter. > > 2.6. Flow Information Exporter or Exporter > The exporter sends flow records created and maintained by one or > more meters to one or more data collectors. See my previous remark about exporter versus meter > > 2.7. Flow Information Data Collector or Data Collector > The data collector receives flow records from one or more exporters. > The data collector might process or store received flow record, > but these actions are out of the scope of this document. OK. We called it just collector. But this is just a detail! Regards, Benoit. > > 2.8. Flow Information Export > Flow information export denotes the process of transferring flow > records from an exporter to a data collector. > > > -- > 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/ > -- 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 Feb 11 11:39:12 2002 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 LAA08845 for ; Mon, 11 Feb 2002 11:39:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aJAT-0001XF-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 10:19:01 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aJAQ-0001X2-00; Mon, 11 Feb 2002 10:18:58 -0600 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BGKmQ04489; Mon, 11 Feb 2002 10:20:48 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Feb 2002 10:18:55 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 10:18:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B317.CB6A6F62" Subject: RE: [ipfix-arch] Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Mon, 11 Feb 2002 11:18:52 -0500 Message-ID: Thread-Topic: [ipfix-arch] Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Thread-Index: AcGzEbQqTVmtlNTjSouBSrKSZ/cpWAABpB9g From: To: , , , Cc: , , X-OriginalArrivalTime: 11 Feb 2002 16:18:52.0950 (UTC) FILETIME=[CBE53360:01C1B317] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C1B317.CB6A6F62 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 Your point is well taken, but making a protocol to do some = configuration does not make the protocol a burden. If you prefer to have out-of band mechanism that's fine. I think we = are not mandating any thing. It is nice if one protocol provides both configuration and management. =20 =20 Regards Ramg -----Original Message----- From: ext Will Eatherton [mailto:will@cisco.com] Sent: Monday, February 11, 2002 10:24 AM To: Reinaldo Penno; ipfix-arch@net.doit.wisc.edu; = ipfix-arch-volunteers@net.doit.wisc.edu Cc: quittek@ccrle.nec.de; knorseth@enterasys.com; plonka@doit.wisc.edu Subject: [ipfix-arch] Scope of IPFIX (was Answer to the recent comments = on the Architecture Draft) Group, =20 Cisco's interest in IPFIX was to help establish a non-proprietary = protocol similar to netflow but more flexible allowing us to add value = to our customers (and do so in a timely manner). If IPFIX goes down a = path along the lines as being advocated recent threads by Reinaldo, it = is unclear if the added burden of the protocol will be make it worth the = benefits of a non-proprietary protocol. Given it seems I have seen = roughly the same conversation occur 3 times in past several day, It is = unclear if further email discussion on this topic will resolve the = underlying question as to the scope of IPFIX. It seems time for an = official call on what is in/out of scope for IPFIX. As has been = mentioned here multiple times we would like to hear : =20 - the exporter configuration is out of the scope of this document (the = exporter configuration out of band) - no transport negotiation (which transport) - no capability negotiation Will :So lets have a protocol which is more flexible as NetFlow version=20 :1-7,=20 I will not comment on that too much...Basically we are not here to = reverse-engineer Netflow, but to incorporate some good ideas from it. :but not much more complicated, in order to be successfully=20 :accepted by hardware vendors and application programmers.=20 ohh, please...Then Netflow is just right?=20 Reinaldo=20 ------_=_NextPart_001_01C1B317.CB6A6F62 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture Draft
Hello,
 
Your=20 point is well taken, but making a protocol to do  some = configuration does=20 not make the protocol a burden.
 If you prefer to have out-of band = mechanism=20 that's fine. I think  we are not mandating any = thing.  =20 It is nice if one  protocol  provides
 both configuration and=20 management.
 
 
Regards
Ramg
-----Original Message-----
From: ext Will Eatherton = [mailto:will@cisco.com]
Sent: Monday, February 11, 2002 = 10:24=20 AM
To: Reinaldo Penno; ipfix-arch@net.doit.wisc.edu;=20 ipfix-arch-volunteers@net.doit.wisc.edu
Cc: = quittek@ccrle.nec.de;=20 knorseth@enterasys.com; plonka@doit.wisc.edu
Subject: = [ipfix-arch]=20 Scope of IPFIX (was Answer to the recent comments on the Architecture=20 Draft)

Group,
 
Cisco's interest in IPFIX  was to help = establish=20 a non-proprietary protocol similar to netflow but more flexible = allowing=20 us to add value to our customers (and do so in a timely=20 manner).  If IPFIX goes down a path along the lines as = being=20 advocated recent threads by Reinaldo,  it is unclear if the = added=20 burden of the protocol will be make it worth the benefits of a = non-proprietary=20 protocol.  Given it seems I have seen roughly the same = conversation=20 occur 3 times in past several day, It is unclear if further email = discussion=20 on this topic will resolve the underlying question as to the scope of=20 IPFIX.  It seems time for an official call on what = is=20 in/out of scope for IPFIX.  As has been mentioned here = multiple=20 times we would like to hear :  

- the exporter = configuration is out=20 of the scope of this document =20  (the exporter configuration out of band)

- no transport = negotiation (which=20 transport)

 - no capability=20 negotiation

Will

:So lets have a protocol which is more flexible as = NetFlow=20 version
:1-7,

I will not comment on that too much...Basically we = are not=20 here to reverse-engineer Netflow, but to incorporate some good ideas = from=20 it.

:but not much more complicated, in order to be=20 successfully
:accepted by hardware vendors = and=20 application programmers.

ohh, please...Then Netflow is just right? =

Reinaldo=20






------_=_NextPart_001_01C1B317.CB6A6F62-- -- 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 Feb 11 11:56:16 2002 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 LAA09849 for ; Mon, 11 Feb 2002 11:56:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aJOH-0001qb-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 10:33:17 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aJOF-0001ps-00 for ipfix-data@net.doit.wisc.edu; Mon, 11 Feb 2002 10:33:15 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYB5B; Mon, 11 Feb 2002 08:32:01 -0800 Message-ID: <3C67F1FF.22EB8EAC@riverstonenet.com> Date: Mon, 11 Feb 2002 11:31:59 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: carter@qosient.com CC: "'Simon Leinen'" , kcn@norseth.com, "'data'" Subject: [ipfix-data] Re: Information Model supporting vendor specific IE's References: <5C8959A16A71B449AE793CF52FBBED6603BEF0@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Alrady there... 9.34. Vendor Specific IE Vendors may add their own information to the protocol. Information contained in this IE is vendor specific. OID and OID Value is defined by ITU X.680.X683 (1997) and is encoded as defined by ITU X.690.691(1997). This IE MUST not contain any information which cannot be safely ignored by the Exporter or Collector. If multiple Vendor Specific IE's with the same OID occur, then the vendor defines semantics of ordering. Carter Bullard wrote: > > Gentle People, > We'll need an of IE type that supports vendor specific > metrics. Rather than requiring that an IE be approved, > we should support vendor proprietary IE's in order to > transport unique metrics. Ones that are not defined > in the RFC. The inclusion of these IE types would > be advertised at connect time, and the collector can > decide if it will pass them through or not. > > I didn't see this in the list. > > Carter > > Carter Bullard > QoSient, LLC > 300 E. 56th Street, Suite 18K > New York, New York 10022 > > carter@qosient.com > Phone +1 212 588-9133 > Fax +1 212 588-9134 > http://qosient.com > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > > calato@riverstonenet.com > > Sent: Wednesday, February 06, 2002 11:11 AM > > To: Simon Leinen > > Cc: kcn@norseth.com; data > > Subject: [ipfix-data] Re: Information Model > > > > > > > > Here is a first cut at the list of data elements to be > > reported. I of course hacked it out of the LFAP spec. > > > > I think we need to begin with a couple of guidlines (which > > we should augment as we go). They are just guidelines. > > > > 1. Data element values should be defined in terms of > > other specifications. Since we are only reporting > > things in other protocols, there should be little > > reason for us to define anything from scatch. > > > > 2. Each element should be able to be interpreted on > > it own. In other words, don't make me look though > > the rest of the message to figure out what this > > value means. The drawback is this can lead to > > data element explosion. We'll have to balance > > the tradeoffs. > > > > 3. Others?.... > > > > 1.1 Source Address IE > > > > Source address associated with a flow. Addresses can be > > of any type > > as described in RFC 1700 [note - we need a new reference > > here, 1700 > > has been obsoleted] > > > > 1.2 Destination Address IE > > > > Destination address associated with a flow. same as above. > > > > 1.3 Internal queue priority > > > > A switch may map several of its internal priority queues into a > > Premium, High, Medium or Low category. > > > > [ this sections needs more work] > > > > > > 1.4 Time IE > > > > The time (as a SNMPv2 TimeStamp [1443]) associated with the > > status/statistics observed or other events. > > > > 1.5 UTC Time IE > > > > The time in seconds since 00:00:00 UTC, January 1, 1970 associated > > with the status/statistics observed or other events. If both Time > > and UTC_TIME are present, UTC Time takes precedence. > > > > 1.6 Delta Time IE > > > > The number in 100ths of seconds over which the statistics were > > observed. TYPE is 71 and format is: > > > > > > 1.7 Class of Service IE > > > > The class of service associated with a flow. > > > > Class of Service Received > > Class of Service Transmitted > > > > 1 - IPv4, CoS value is defined by ToS in RFC 791 > > 2 - IPv6, CoS value is defined by Traffic Class in RFC 2460 > > 3 - MPLS, CoS value is defined by Exp in RFC 3032 > > 4 - VLAN, CoS value is defined by user_priority in IEEE > > 802.1q[802.1q] and IEEE 802.1p[802.1p] > > > > [Can more than one Class of Service can be present??? PAC] > > > > > > > > 1.8 Source Exporter [ is that the right term?? PAC] Address IE > > > > Source Exporter address is the address of the Exporter > > reporting the flow, > > Address is same as is as shown for Source Address. This > > information is used by applications to later correlate the > > ingress/egress port with a specific Exporter. It is also used to > > maintain the source Exporter information when there is an > > intermediate > > proxy. For example, given the picture below: > > > > SW1 -------- P1 ------ FAS1 > > ^ > > | > > SW2---------- | > > > > Flows coming from SW1 and SW2 through proxy P1 would look to the > > Collector [ is this the rigth term??? PAC] like the same Exporter > > connection. With the Source Exporter in the message the > > original Exporter > > address is maintained. > > > > > > 1.9 Flow State IE > > > > Flow State is the intended End State for the Flow. > > > > Flow state has one of the following meanings: > > > > Flow is inactive > > Flow is active > > > > 1.10 Byte Count IE > > > > Contains the count of octets sent and received associated with the > > identified flow. > > > > The byte count can be for bytes received (towards source) or > > bytes sent (towards destination) or both > > (bi-directional flow). > > > > The byte count can be a running counter and is the > > count from the beginning of the flow establishment. > > The byte count can be a delta counter and is the > > count since the last report for this flow. > > > > > > > > 1.11 Packet Count IE > > > > Contains the count of packets sent and received associated with the > > identified flow. > > > > The packet count can be for packets received (towards source) or > > packets sent (towards destination) or both > > (bi-directional flow). > > > > The packet count can be a running counter and is the > > count from the beginning of the flow establishment. > > The packet count can be a delta counter and is the > > count since the last report for this flow. > > > > > > 1.12 Protocol Identifier IE > > > > e.g. TCP/UDP [ need an RFC reference here. PAC] > > > > 1.13 Source Port IE > > > > This IE is used to report UDP source port [see RFC 768] or > > TCP source port [see RFC 793]. > > > > 1.14 Destination Port IE > > > > This IE is used to report UDP destination port [see RFC 768] or > > TCP destination port [see RFC 793]. > > > > > > 1.15 Source AS IE > > > > The Autonomous System (AS) numbers for the source address > > associated with a flow. Autonomous System (AS) number is defined by > > RFC 1930 and RFC 1771 (BGP-4): > > > > > > 1.16 Destination AS IE > > > > The Autonomous System (AS) numbers for the destination address > > associated wit a flow. Autonomous System (AS) number is defined by > > RFC 1930 and RFC 1771 (BGP-4). > > > > > > 1.17 Ingress Port IE > > > > The ingress ifIndex for the flow is provided in this IE. ifIndex is > > defined by RFC 2233. > > > > 1.18 Egress Port IE > > > > The egress ifIndex for the flow is provided in this IE. ifIndex is > > defined by RFC 2233. > > > > > > 1.19 Egress ATM Subinterface > > > > The egress vpi/vci for the flow is provided in this IE. vpi/vci id > > defined by the ATM Forum UNI 3.1 specification: > > > > > > > > 1.20 EGRESS_FRAME_RELAY_SUBINTERFACE IE > > > > The egress DLCI for the flow is provided in this IE. ITU Q.922 > > defines the DLCI range. The frDlcmiState is defined in RFC 2115 and > > defines the specific values of the DLCI. > > > > > > > > 1.21 NEXT_HOP_IP IE > > > > Address of the next hop. address is defined the same as for Source > > Address IE. > > > > 1.22 TCP Control Bits IE > > > > The TCP control bits seen for this flow. Note a 0 value for each > > bit only indicates that the flag was not detected (i.e. it may have > > occurred but was not detected by the reporting CCE). TCP Control > > Bits are defined by RFC 793. > > > > 1.23 Next Hop AS IE > > > > The Autonomous System (AS) numbers for the next hop IP. Autonomous > > System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). > > > > > > > > 1.24 Source Address Netmask IE > > > > The number of bits in the CIDR netmask, as defined in RFC 1519, for > > the source address. > > > > 1.25 Destination Address Netmask IE > > > > The CIDR netmask, as defined in RFC 1519, for the destination > > address. > > > > > > 1.26 Destination BGP Community IE > > > > The BGP community number for the destination address. BGP community > > number is defined by RFC 1997: > > > > > > 1.27 Source BGP Community IE > > > > The BGP community number for the source address. > > > > > > > > 1.28 Source VLAN ID IE > > > > The Source VLAN ID associated with the flow. VLAN ID is > > defined by IEEE > > standard 802.1q - 1998[802.1q]. > > > > [ Is this ultimate source VLAN or the source vlan of the port where > > the packet came in? Or do we need a way to represent both? PAC] > > > > 1.29 Destination VLAN ID IE > > > > The destination VLAN ID associated with the flow. VLAN ID > > is defined by IEEE > > standard 802.1q - 1998[802.1q]. > > > > [ Is this ultimate destination VLAN or the destination vlan > > of the port where > > the packet went out? Or do we need a way to represent both? PAC] > > > > 1.30 Source Virtual Address IE > > > > An Exporter may be involved in redirecting flows. This IE captures > > information needed for proper accounting of redirected flows. The > > Source Virtual IE contains the source address of the flow as > > transmitted by the Exporter. It is generally different > > than the source > > address IE, which contains the address of the actual source of the > > message. > > > > A type field would contain the type of translation performed on the > > source address. The following types are currently available: > > > > 1 - NAT > > 2 - LSNAT > > 3 - Web Cache > > > > The address is defined the same as for Source Address. > > > > 1.31 Source Virtual Port IE > > > > A CCE may be involved in redirecting flows. This IE captures > > information needed for proper accounting of redirected flows. The > > Source Virtual port IE contains the source port of the flow as > > transmitted by the CCE. It may be different than the source port > > IE, which contains the port of the actual source of the flow. > > An IP Protocol field is present and is defined by the IP protocol > > spec [RFC 791] (e.g. TCP/UDP). The fields indicates how to > > interpret > > the port value field. > > > > A type field contains the type of translation performed on the > > source port. The following types are currently available: > > > > 1 - NAT > > 2 - LSNAT > > 3 - Web Cache > > > > > > 1.32 Destination Virtual Address IE > > > > The Destination Virtual IE contains the destination address of the > > flow as received by the Exporter. It is generally > > different than the > > destination port number, which contains the actual destination > > address of the flow. > > > > > > 1.33 Destination Virtual Port IE > > > > The Destination Virtual port IE contains the destination port of > > the flow as received by the Exporter. It may be different than the > > destination port recorded in the destination port, which > > contains the > > actual destination port of the flow. > > > > > > 1.34 Vendor Specific IE > > > > Vendors may add their own information to the protocol. Information > > contained in this IE is vendor specific. OID and OID Value is > > defined by ITU X.680.X683 (1997) and is encoded as defined by ITU > > X.690.691(1997). This IE MUST not contain any information which > > cannot be safely ignored by the Exporter or Collector. If > > multiple Vendor > > Specific IE's with the same OID occur, then the vendor defines > > semantics of ordering. > > > > > > 1.35 Flow Label IE > > > > The Flow Label IE contains the IPV6 Flow Label information as > > defined by RFC 2460. > > > > 1.36 Fragment ID IE > > > > The fragment ID associated with the flow. RFC 791 and RFC 2460 > > define fragment ID. > > > > -- > > 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/ > > > > -- 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 Feb 11 12:08:52 2002 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 MAA10621 for ; Mon, 11 Feb 2002 12:08:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aJgq-0002GW-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 10:52:28 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aJgp-0002Fx-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 10:52:27 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYCAR; Mon, 11 Feb 2002 08:51:16 -0800 Message-ID: <3C67F683.51999910@riverstonenet.com> Date: Mon, 11 Feb 2002 11:51:15 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: VENKATG , ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt References: <4122971675.1013440286@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi Venkat, > > sorry, my previous email slipped to the outbox > before I entered my comments. > > --On 11 February 2002 19:18 +0530 VENKATG wrote: > > Hi, > > > > This might have been discussed before, but i've not followed all the > > past mails very closely, hence this question. > > > > In the filw http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt > > > > and under section 5 [ Information Elements ], there does not seem to be > > any mention on the 'Version No' as one of the Information Elements. > > > > Do we not need this ? I feel that this would be needed once we > > use/extend the same frame-work for IPv6. > > I completely agree. This is already part of the requirements. > > Considering support for NAT-PTs (acting as gateways > between IPv4 and IPv6) we should also include and IE > for "virtual" or "modified" IP version Number. The virtual stuff is there. And as stated earlier, the version details are left for later. But version will some how be included. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > > > > Regards - venkat > > > > ======================================= > > Venkatraman G > > Infosys Technologies Limited > > Bangalore > > India-561229 > > -- > 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/ -- 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 Feb 11 12:08:58 2002 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 MAA10634 for ; Mon, 11 Feb 2002 12:08:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aJeF-0002EZ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 10:49:47 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aJeC-0002EK-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 10:49:44 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYB03; Mon, 11 Feb 2002 08:48:32 -0800 Message-ID: <3C67F5DF.F02B3F68@riverstonenet.com> Date: Mon, 11 Feb 2002 11:48:31 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: VENKATG CC: ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architecture-00.txt References: <10B94DB22F15D211B5740008C728A3020C1DE3F6@kecmsg01.ad.infosys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Depends on how the address is encoded. If the address family is included no version if needed. If not, them we either need a version of the IE itself can specify (e.g. SRC_ADDR_IPV4, SRC_ADDR_IPV6) I left those details for later. Paul VENKATG wrote: > > Hi, > > This might have been discussed before, but i've not followed all the > past mails very closely, hence this question. > > In the filw http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt > > and under section 5 [ Information Elements ], there does not seem to be > any mention on the 'Version No' as one of the Information Elements. > > Do we not need this ? I feel that this would be needed once we > use/extend the same frame-work for IPv6. > > Regards - venkat > > ======================================= > Venkatraman G > Infosys Technologies Limited > Bangalore > India-561229 -- 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 Feb 11 14:14:00 2002 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 OAA14369 for ; Mon, 11 Feb 2002 14:14:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aLYq-0004mY-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 12:52:20 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aLYo-0004lY-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 12:52:18 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1BIpkE12588; Mon, 11 Feb 2002 10:51:46 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABD77001; Mon, 11 Feb 2002 10:52:07 -0800 (PST) Message-ID: <3C6814D5.7A8C8406@cisco.com> Date: Mon, 11 Feb 2002 11:00:38 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: quittek@ccrle.nec.de CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] definition of uni-/bi-directional flows References: <1013390019.3c671ac3b2cde@citadel.mobility.ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Jurgene, Refer to section 2.0 of the draft submitted by Benoit and me. It gives a detailed defintion of a uni-directional flow. Bi-directional is a restricted set of uni-directional flows which have a sensible reverse mapping at the same observation point. I am not sure to what precision one can define a bi-directional flow. Thanks Ganesh quittek@ccrle.nec.de wrote: > Hi all, > > I just ran into a strange problem: I tried to define precisely > what is a uni-directional / bi-directional flow and found out > that although I am discussing with you for quite some time > using these terms, I cannot tell precisely, what they are. > > Does anyone have such a definition? > > Of course I can define them easily when I restrict flows to > 5-tuple TCP/UDP flow without wild-carding, but when I start to > include aggregated flows, for example all packets originating > in a specific subnet, and ICMP flows, and multicast flows > (multi-directional?), then it gets much more complicated. > > 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/ -- 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 Feb 11 14:25:48 2002 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 OAA14673 for ; Mon, 11 Feb 2002 14:25:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aLq7-0005B0-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 13:10:11 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aLq5-0005A0-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 13:10:09 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1BJ9ca15133; Mon, 11 Feb 2002 20:09:38 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA31812; Mon, 11 Feb 2002 20:09:38 +0100 Date: Mon, 11 Feb 2002 20:11:14 +0100 From: Juergen Quittek To: Ganesh Sadasivan cc: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] definition of uni-/bi-directional flows Message-ID: <4140960312.1013458274@[192.168.102.164]> In-Reply-To: <3C6814D5.7A8C8406@cisco.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ganesh, --On 11 February 2002 11:00 -0800 Ganesh Sadasivan wrote: > Hi Jurgene, > Refer to section 2.0 of the draft submitted by Benoit and me. It > gives a detailed defintion of a uni-directional flow. Bi-directional > is a restricted set of uni-directional flows which have a sensible > reverse mapping at the same observation point. I am not sure to > what precision one can define a bi-directional flow. The flows you define are not necessarily what intuition would call uni-directional. If you for example map all traffic with a source or destination port 80 into one flow I would not call it uni-directional. What you do is that you define a general flow and then say the regular case is the uni-directional one, and bi-directional is some special kind. My claim is that already uni-directional is a special kind, which we have not defined yet, although we all might have a good intuition teeling us what would be a uni-directional or bi-directional flow. Best wishes, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Thanks > Ganesh > > quittek@ccrle.nec.de wrote: > >> Hi all, >> >> I just ran into a strange problem: I tried to define precisely >> what is a uni-directional / bi-directional flow and found out >> that although I am discussing with you for quite some time >> using these terms, I cannot tell precisely, what they are. >> >> Does anyone have such a definition? >> >> Of course I can define them easily when I restrict flows to >> 5-tuple TCP/UDP flow without wild-carding, but when I start to >> include aggregated flows, for example all packets originating >> in a specific subnet, and ICMP flows, and multicast flows >> (multi-directional?), then it gets much more complicated. >> >> 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/ > -- 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 Feb 11 14:37:11 2002 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 OAA15005 for ; Mon, 11 Feb 2002 14:37:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aM0s-0005OR-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 13:21:18 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aM0q-0005OB-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 13:21:16 -0600 Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1BJKkh26881; Mon, 11 Feb 2002 11:20:46 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-59.cisco.com [171.71.137.59]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ABX70747; Mon, 11 Feb 2002 11:12:12 -0800 (PST) Message-ID: <3C681883.F2C1CAB8@cisco.com> Date: Mon, 11 Feb 2002 11:16:19 -0800 From: Peram Marimuthu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "K.C. Norseth" CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX Drafts References: <012001c1b2c2$b3cc6140$850f880a@slc252750> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit "K.C. Norseth" wrote: > > Text format: > http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt > http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt > > Word format: > http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc > http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc > Isnt the title presumptious? I dont see anything that indicates that this is anything more than an individual contribution. Peram -- 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 Feb 11 14:45:48 2002 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 OAA15188 for ; Mon, 11 Feb 2002 14:45:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aM6i-0005Xm-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 13:27:20 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aM6g-0005Wn-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 13:27:18 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYY1X7; Mon, 11 Feb 2002 11:26:04 -0800 Message-ID: <3C681ACB.DEBAF126@riverstonenet.com> Date: Mon, 11 Feb 2002 14:26:03 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Peram Marimuthu CC: "K.C. Norseth" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX Drafts References: <012001c1b2c2$b3cc6140$850f880a@slc252750> <3C681883.F2C1CAB8@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Gee, I hope it is more than an individual contribution. KC has been taking text from the group and putting it together into a single IPFIX document. That was how I understoond it anyway. Paul Peram Marimuthu wrote: > > "K.C. Norseth" wrote: > > > > > > Text format: > > http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt > > http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt > > > > Word format: > > http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc > > http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc > > > > Isnt the title presumptious? I dont see anything that indicates that > this is anything more than an individual contribution. > > Peram > > -- > 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/ -- 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 Feb 11 14:51:13 2002 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 OAA15348 for ; Mon, 11 Feb 2002 14:51:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aMDw-0005hT-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 13:34:48 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aMDu-0005h1-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 13:34:46 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1BJYFt24969; Mon, 11 Feb 2002 11:34:15 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABD78841; Mon, 11 Feb 2002 11:34:38 -0800 (PST) Message-ID: <3C681ECC.D09A8945@cisco.com> Date: Mon, 11 Feb 2002 11:43:09 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] definition of uni-/bi-directional flows References: <4140960312.1013458274@[192.168.102.164]> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Jurgene, You are correct. What I should have added is: When the direction w.r.t wire is specified, then it can be furthur categorised as uni/bi.. The direction however is optional and may not be applicable in all the cases. I beleive the scope of the flow is restricted to an observation point and not end-to-end. Thanks Ganesh Juergen Quittek wrote: > Hi Ganesh, > > --On 11 February 2002 11:00 -0800 Ganesh Sadasivan wrote: > > > Hi Jurgene, > > Refer to section 2.0 of the draft submitted by Benoit and me. It > > gives a detailed defintion of a uni-directional flow. Bi-directional > > is a restricted set of uni-directional flows which have a sensible > > reverse mapping at the same observation point. I am not sure to > > what precision one can define a bi-directional flow. > > The flows you define are not necessarily what intuition would call > uni-directional. If you for example map all traffic with a source > or destination port 80 into one flow I would not call it uni-directional. > > What you do is that you define a general flow and then say the regular > case is the uni-directional one, and bi-directional is some special > kind. My claim is that already uni-directional is a special kind, which > we have not defined yet, although we all might have a good intuition > teeling us what would be a uni-directional or bi-directional flow. > > Best wishes, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > > Thanks > > Ganesh > > > > quittek@ccrle.nec.de wrote: > > > >> Hi all, > >> > >> I just ran into a strange problem: I tried to define precisely > >> what is a uni-directional / bi-directional flow and found out > >> that although I am discussing with you for quite some time > >> using these terms, I cannot tell precisely, what they are. > >> > >> Does anyone have such a definition? > >> > >> Of course I can define them easily when I restrict flows to > >> 5-tuple TCP/UDP flow without wild-carding, but when I start to > >> include aggregated flows, for example all packets originating > >> in a specific subnet, and ICMP flows, and multicast flows > >> (multi-directional?), then it gets much more complicated. > >> > >> 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/ > > -- 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 Feb 11 15:00:13 2002 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 PAA15558 for ; Mon, 11 Feb 2002 15:00:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aMHW-0005o0-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 13:38:30 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aMHT-0005my-00 for ipfix-data@net.doit.wisc.edu; Mon, 11 Feb 2002 13:38:28 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYY155; Mon, 11 Feb 2002 11:37:14 -0800 Message-ID: <3C681D69.7062CF53@riverstonenet.com> Date: Mon, 11 Feb 2002 14:37:13 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: data Subject: [ipfix-data] Proposal for 3 new IE's Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Can we add the following 3 IE's to the data doc. VPN-ID - TBD (I still need a spec reference) 5.5.3. Dropped Byte Count IE Contains the count of octets dropped at the observation point associated with the identified flow. The dropped byte count can be a running counter and is the count from the beginning of the flow establishment. The byte count can be a delta counter and is the count since the last report for this flow. 5.5.4. Dropped Packet Count IE Contains the count of packets dropped at the observation point associated with the identified flow. The dropped packet count can be a running counter and is the count from the beginning of the flow establishment. The dropped packet count can be a delta counter and is the count since the last report for this flow. -- 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 Feb 11 15:11:42 2002 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 PAA15892 for ; Mon, 11 Feb 2002 15:11:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aMSy-0005zZ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 13:50:20 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aMSw-0005zQ-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 13:50:18 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id OAA09663; Mon, 11 Feb 2002 14:59:42 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma008326; Mon, 11 Feb 02 14:42:57 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXN3D0>; Mon, 11 Feb 2002 14:32:33 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA069E@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Peram Marimuthu'" , "K.C. Norseth" Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] IPFIX Drafts Date: Mon, 11 Feb 2002 14:32:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B332.E6B6F050" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B332.E6B6F050 Content-Type: text/plain No. These work in progress drafts are being done by the design teams that were set up at the last conference, ans subsequest wg phone calls. It is on my site and I put it out because I am the one cutting and pasting the teams work together. The work if you have been following contains information from all the team members who sent it to me for imput. Is it complete? No. I am trying to incorporate the work of Ganesh and Benoit now. Can it be replaced by another submission? Sure. K.C. |-----Original Message----- |From: Peram Marimuthu [mailto:peram@cisco.com] |Sent: Monday, February 11, 2002 12:16 PM |To: K.C. Norseth |Cc: ipfix@net.doit.wisc.edu |Subject: Re: [ipfix] IPFIX Drafts | | | | |"K.C. Norseth" wrote: | |> | |> Text format: |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt |> |> Word format: |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc |> | |Isnt the title presumptious? I dont see anything that |indicates that this is anything more than an individual contribution. | |Peram | | |-- |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/ | ------_=_NextPart_001_01C1B332.E6B6F050 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] IPFIX Drafts

No.  These work in progress drafts are being = done by the design teams that were set up at the last conference, ans = subsequest wg phone calls.  It is on my site and I put it out = because I am the one cutting and pasting the teams work together.  = The work if you have been following contains information from all the = team members who sent it to me for imput.  Is it complete? = No.  I am trying to incorporate the work of Ganesh and Benoit = now.  Can it be replaced by another submission? Sure.

K.C.

|-----Original Message-----
|From: Peram Marimuthu [mailto:peram@cisco.com]
|Sent: Monday, February 11, 2002 12:16 PM
|To: K.C. Norseth
|Cc: ipfix@net.doit.wisc.edu
|Subject: Re: [ipfix] IPFIX Drafts
|
|
|
|
|"K.C. Norseth" wrote:
|
|> <snip>
|
|> Text format:
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00= .txt
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-archite= cture-00.txt
|>
|> Word format:
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-archite= cture-00.doc
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00= .doc
|>
|
|Isnt the title presumptious? I dont see anything = that
|indicates that this is anything more than an = individual contribution.
|
|Peram
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1B332.E6B6F050-- -- 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 Feb 11 15:21:18 2002 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 PAA16145 for ; Mon, 11 Feb 2002 15:21:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aMe2-0006Kr-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 14:01:46 -0600 Received: from d2cspimg001.smartpipes.com ([63.89.185.24]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aMe0-0006K5-00 for ipfix-data@net.doit.wisc.edu; Mon, 11 Feb 2002 14:01:44 -0600 Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Feb 2002 20:01:13 -0000 Message-ID: <4652644B98DFF34696801F8F3070D3FE0118869F@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'calato@riverstonenet.com'" , data Subject: RE: [ipfix-data] Proposal for 3 new IE's Date: Mon, 11 Feb 2002 20:01:08 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Precedence: bulk Sender: majordomo listserver RFC 2685, "Virtual Private Networks Identifier" -----Original Message----- From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] Sent: Monday, February 11, 2002 2:37 PM To: data Subject: [ipfix-data] Proposal for 3 new IE's Can we add the following 3 IE's to the data doc. VPN-ID - TBD (I still need a spec reference) 5.5.3. Dropped Byte Count IE Contains the count of octets dropped at the observation point associated with the identified flow. The dropped byte count can be a running counter and is the count from the beginning of the flow establishment. The byte count can be a delta counter and is the count since the last report for this flow. 5.5.4. Dropped Packet Count IE Contains the count of packets dropped at the observation point associated with the identified flow. The dropped packet count can be a running counter and is the count from the beginning of the flow establishment. The dropped packet count can be a delta counter and is the count since the last report for this flow. -- 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/ -- 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 Feb 11 15:22:54 2002 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 PAA16177 for ; Mon, 11 Feb 2002 15:22:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aMiz-0006SB-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 14:06:53 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aMix-0006RQ-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 14:06:51 -0600 Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1BK66Z20001; Mon, 11 Feb 2002 12:06:07 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-59.cisco.com [171.71.137.59]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ABX72403; Mon, 11 Feb 2002 12:03:47 -0800 (PST) Message-ID: <3C682499.7C15091E@cisco.com> Date: Mon, 11 Feb 2002 12:07:54 -0800 From: Peram Marimuthu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Norseth, KC" CC: "K.C. Norseth" , ipfix@net.doit.wisc.edu, Ganesh Sadasivan , Benoit Claise Subject: Re: [ipfix] IPFIX Drafts References: <59358A738F45D51186A30008C74CE250DA069E@slc-exc1.ctron.com> Content-Type: multipart/alternative; boundary="------------EC03EA5ABC4BEA497B2959CB" Precedence: bulk Sender: majordomo listserver --------------EC03EA5ABC4BEA497B2959CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The way I see it, there are two drafts - one authored by Ganesh and Benoit and the second one authored by everyone else who is on IPFIX-volunteer mailing list. Until the official draft is chosen, it is everyone's responsibility to discuss both drafts and call it draft-"private-name". Peram "Norseth, KC" wrote: > > > No. These work in progress drafts are being done by the design teams that were set up > at the last conference, ans subsequest wg phone calls. It is on my site and I put it > out because I am the one cutting and pasting the teams work together. The work if you > have been following contains information from all the team members who sent it to me for > imput. Is it complete? No. I am trying to incorporate the work of Ganesh and Benoit > now. Can it be replaced by another submission? Sure. > > K.C. > > |-----Original Message----- > |From: Peram Marimuthu [mailto:peram@cisco.com] > |Sent: Monday, February 11, 2002 12:16 PM > |To: K.C. Norseth > |Cc: ipfix@net.doit.wisc.edu > |Subject: Re: [ipfix] IPFIX Drafts > | > | > | > | > |"K.C. Norseth" wrote: > | > |> > | > |> Text format: > |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt > |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt > |> > |> Word format: > |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc > |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc > |> > | > |Isnt the title presumptious? I dont see anything that > |indicates that this is anything more than an individual contribution. > | > |Peram > | > | > |-- > |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/ > | --------------EC03EA5ABC4BEA497B2959CB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The way I see it, there are two drafts - one authored by Ganesh and Benoit
and the second one authored by everyone else who is on IPFIX-volunteer mailing list.

Until the official draft is chosen, it is everyone's responsibility to discuss both drafts
and call it draft-"private-name".

Peram

"Norseth, KC" wrote:

 

No.  These work in progress drafts are being done by the design teams that were set up at the last conference, ans subsequest wg phone calls.  It is on my site and I put it out because I am the one cutting and pasting the teams work together.  The work if you have been following contains information from all the team members who sent it to me for imput.  Is it complete? No.  I am trying to incorporate the work of Ganesh and Benoit now.  Can it be replaced by another submission? Sure.

K.C.

|-----Original Message-----
|From: Peram Marimuthu [mailto:peram@cisco.com]
|Sent: Monday, February 11, 2002 12:16 PM
|To: K.C. Norseth
|Cc: ipfix@net.doit.wisc.edu
|Subject: Re: [ipfix] IPFIX Drafts
|
|
|
|
|"K.C. Norseth" wrote:
|
|> <snip>
|
|> Text format:
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt
|>
|> Word format:
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc
|>
|
|Isnt the title presumptious? I dont see anything that
|indicates that this is anything more than an individual contribution.
|
|Peram
|
|
|--
|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/
|

--------------EC03EA5ABC4BEA497B2959CB-- -- 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 Feb 11 15:33:36 2002 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 PAA16461 for ; Mon, 11 Feb 2002 15:33:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aMoO-0006aD-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 14:12:28 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aMoM-0006ZV-00 for ipfix-data@net.doit.wisc.edu; Mon, 11 Feb 2002 14:12:26 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYGDV; Mon, 11 Feb 2002 12:11:12 -0800 Message-ID: <3C682560.B63A5128@riverstonenet.com> Date: Mon, 11 Feb 2002 15:11:12 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: data Subject: Re: [ipfix-data] Proposal for 3 new IE's References: <3C681D69.7062CF53@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > > Can we add the following 3 IE's to the data doc. > > VPN-ID - TBD (I still need a spec reference) Here is the text. Thanks to Cliff for the spec reference. Global VPN Identifier IE The VPN identifier associated with the flow as defined in RFC 2685. > > 5.5.3. Dropped Byte Count IE > > Contains the count of octets dropped at the observation point > associated with the identified flow. > > The dropped byte count can be a running counter and is the count from > the > beginning of the flow establishment. > > The byte count can be a delta counter and is the count since the > last report for this flow. > > 5.5.4. Dropped Packet Count IE > > Contains the count of packets dropped at the observation point > associated with the identified flow. > > The dropped packet count can be a running counter and is the count from > the > beginning of the flow establishment. > > The dropped packet count can be a delta counter and is the count since > the > last report for this flow. > > -- > 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/ -- 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 Feb 11 15:51:32 2002 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 PAA16857 for ; Mon, 11 Feb 2002 15:51:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aNAl-000731-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 14:35:35 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aNAi-00072s-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 14:35:32 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA16001; Mon, 11 Feb 2002 15:44:42 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma015974; Mon, 11 Feb 02 15:44:28 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXNPHG>; Mon, 11 Feb 2002 15:34:04 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA069F@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Peram Marimuthu'" Cc: "K.C. Norseth" , ipfix@net.doit.wisc.edu, Ganesh Sadasivan , Benoit Claise Subject: RE: [ipfix] IPFIX Drafts Date: Mon, 11 Feb 2002 15:34:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B33B.7EDEFD70" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B33B.7EDEFD70 Content-Type: text/plain What we want to do is make one set of documents, as a team effort. For the moment, these can be called George and Gracie for all I care. The point is, the working group teams defined by the working group are working on 2 documents. To help the design team work together, they are referenced as such. When these documents are to be released, they will be the commulation of the groups. I hope that these will also be the accumulation of Beniot and Ganesh did as well as everyone else is involved. The final WG documents have to be reviewed by the working group chairs. They can decide the names, like they did for Benoit and Ganesh. For those who are worried about names of unsubmitted documents, - George is the archecture draft - Gracie is the data draft. You can refer to them as such if you would like. K.C. -----Original Message----- From: Peram Marimuthu [mailto:peram@cisco.com] Sent: Monday, February 11, 2002 1:08 PM To: Norseth, KC Cc: K.C. Norseth; ipfix@net.doit.wisc.edu; Ganesh Sadasivan; Benoit Claise Subject: Re: [ipfix] IPFIX Drafts The way I see it, there are two drafts - one authored by Ganesh and Benoit and the second one authored by everyone else who is on IPFIX-volunteer mailing list. Until the official draft is chosen, it is everyone's responsibility to discuss both drafts and call it draft-"private-name". Peram "Norseth, KC" wrote: No. These work in progress drafts are being done by the design teams that were set up at the last conference, ans subsequest wg phone calls. It is on my site and I put it out because I am the one cutting and pasting the teams work together. The work if you have been following contains information from all the team members who sent it to me for imput. Is it complete? No. I am trying to incorporate the work of Ganesh and Benoit now. Can it be replaced by another submission? Sure. K.C. |-----Original Message----- |From: Peram Marimuthu [mailto:peram@cisco.com ] |Sent: Monday, February 11, 2002 12:16 PM |To: K.C. Norseth |Cc: ipfix@net.doit.wisc.edu |Subject: Re: [ipfix] IPFIX Drafts | | | | |"K.C. Norseth" wrote: | |> | |> Text format: |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt |> |> Word format: |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc |> | |Isnt the title presumptious? I dont see anything that |indicates that this is anything more than an individual contribution. | |Peram | | |-- |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/ | ------_=_NextPart_001_01C1B33B.7EDEFD70 Content-Type: text/html Message
What we want to do is make one set of documents, as a team effort.  For the moment, these can be called George and Gracie for all I care.  The point is, the working group teams defined by the working group are working on 2 documents.  To help the design team work together, they are referenced as such. When these documents are to be released, they will be the commulation of the groups. I hope that these will also be the accumulation of Beniot and Ganesh did as well as everyone else is involved.  The final WG documents have to be reviewed by the working group chairs.  They can decide the names, like they did for Benoit and Ganesh.
 
For those who are worried about names of unsubmitted documents,
- George is the archecture draft
- Gracie is the data draft.
 
You can refer to them as such if you would like.
 
K.C.
 
-----Original Message-----
From: Peram Marimuthu [mailto:peram@cisco.com]
Sent: Monday, February 11, 2002 1:08 PM
To: Norseth, KC
Cc: K.C. Norseth; ipfix@net.doit.wisc.edu; Ganesh Sadasivan; Benoit Claise
Subject: Re: [ipfix] IPFIX Drafts

The way I see it, there are two drafts - one authored by Ganesh and Benoit
and the second one authored by everyone else who is on IPFIX-volunteer mailing list.

Until the official draft is chosen, it is everyone's responsibility to discuss both drafts
and call it draft-"private-name".

Peram

"Norseth, KC" wrote:

 

No.  These work in progress drafts are being done by the design teams that were set up at the last conference, ans subsequest wg phone calls.  It is on my site and I put it out because I am the one cutting and pasting the teams work together.  The work if you have been following contains information from all the team members who sent it to me for imput.  Is it complete? No.  I am trying to incorporate the work of Ganesh and Benoit now.  Can it be replaced by another submission? Sure.

K.C.

|-----Original Message-----
|From: Peram Marimuthu [mailto:peram@cisco.com]
|Sent: Monday, February 11, 2002 12:16 PM
|To: K.C. Norseth
|Cc: ipfix@net.doit.wisc.edu
|Subject: Re: [ipfix] IPFIX Drafts
|
|
|
|
|"K.C. Norseth" wrote:
|
|> <snip>
|
|> Text format:
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt
|>
|> Word format:
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc
|>
|
|Isnt the title presumptious? I dont see anything that
|indicates that this is anything more than an individual contribution.
|
|Peram
|
|
|--
|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/
|

------_=_NextPart_001_01C1B33B.7EDEFD70-- -- 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 Feb 11 16:12:01 2002 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 QAA17239 for ; Mon, 11 Feb 2002 16:12:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aNVd-0007bf-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 14:57:09 -0600 Received: from c001-h002.c001.snv.cp.net ([209.228.32.116] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16aNVc-0007aZ-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 14:57:08 -0600 Received: (cpmta 23753 invoked from network); 11 Feb 2002 12:56:37 -0800 Date: 11 Feb 2002 12:56:37 -0800 Message-ID: <20020211205637.23752.cpmta@c001.snv.cp.net> X-Sent: 11 Feb 2002 20:56:37 GMT Received: from [12.25.1.128] by mail.norseth.com with HTTP; 11 Feb 2002 12:56:37 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: ipfix@net.doit.wisc.edu From: kcn@norseth.com X-Mailer: Web Mail 3.9.3.5 X-Sent-From: kcn@norseth.com Subject: [ipfix] draft-gsadasiv-ipfix-proposal-00.txt Precedence: bulk Sender: majordomo listserver I am trying to imcorporate the Beniot's and Ganesh's draft into the team drafts (http://search.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt). Any ideas and suggestions to what is should be done, what replaces what, and so forth? I have some ideas already, but would like the opinions of all. K.C. -- 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 Feb 11 16:12:02 2002 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 QAA17241 for ; Mon, 11 Feb 2002 16:12:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aNVI-0007as-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 14:56:48 -0600 Received: from c001-h002.c001.snv.cp.net ([209.228.32.116] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16aNVG-0007ZD-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 14:56:46 -0600 Received: (cpmta 23742 invoked from network); 11 Feb 2002 12:56:15 -0800 Date: 11 Feb 2002 12:56:15 -0800 Message-ID: <20020211205615.23741.cpmta@c001.snv.cp.net> X-Sent: 11 Feb 2002 20:56:15 GMT Received: from [12.25.1.128] by mail.norseth.com with HTTP; 11 Feb 2002 12:56:15 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: ipfix@net.doit.wisc.edu From: kcn@norseth.com X-Mailer: Web Mail 3.9.3.5 X-Sent-From: kcn@norseth.com Subject: [ipfix] draft-gsadasiv-ipfix-proposal-00.txt Precedence: bulk Sender: majordomo listserver I am trying to imcorporate the Beniot's and Ganesh's draft into the team drafts (http://search.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt). Any ideas and suggestions to what is should be done, what replaces what, and so forth? I have some ideas already, but would like the opinions of all. K.C. -- 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 Feb 11 16:14:33 2002 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 QAA17334 for ; Mon, 11 Feb 2002 16:14:33 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aNWl-0007e1-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 14:58:19 -0600 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aNWj-0007ds-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 14:58:17 -0600 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BKwUQ07230 for ; Mon, 11 Feb 2002 14:58:30 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Feb 2002 14:58:15 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Feb 2002 14:57:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B33E.B475E3AF" Subject: RE: [ipfix] IPFIX Drafts Date: Mon, 11 Feb 2002 15:57:24 -0500 Message-ID: Thread-Topic: [ipfix] IPFIX Drafts Thread-Index: AcGzPQh91hYUFp6LSVOyn2utxl1h1AAAW6eA From: To: , Cc: , , , X-OriginalArrivalTime: 11 Feb 2002 20:57:24.0973 (UTC) FILETIME=[B50989D0:01C1B33E] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------_=_NextPart_001_01C1B33E.B475E3AF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 Please recollect the last IETF meeting, WG chair has welcomed every one = to contribute collectively as a design team to produce the documents and = at that time there were no problem and infact Cisco folks also = volunteered to produce the documents. After getting accepted from the WG = chairs and in the IETF meeting, the product which will be produced will = be a IETF working document. =20 FYI, there were lot of products like and they made their presentations = in the IETF and they submitted their documents either as individual or = information documents. Ganesh also mentioned that he would like to submit as a informational = document and wants some inputs from the design team to comment on the = document. =20 =20 =20 =20 I think we should call as IETF document rather than individual = submission. =20 Regards Ramg =20 =20 -----Original Message----- From: ext Peram Marimuthu [mailto:peram@cisco.com] Sent: Monday, February 11, 2002 3:08 PM To: Norseth, KC Cc: K.C. Norseth; ipfix@net.doit.wisc.edu; Ganesh Sadasivan; Benoit = Claise Subject: Re: [ipfix] IPFIX Drafts The way I see it, there are two drafts - one authored by Ganesh and = Benoit=20 and the second one authored by everyone else who is on IPFIX-volunteer = mailing list.=20 Until the official draft is chosen, it is everyone's responsibility to = discuss both drafts=20 and call it draft-"private-name".=20 Peram=20 "Norseth, KC" wrote:=20 =20 No. These work in progress drafts are being done by the design teams = that were set up at the last conference, ans subsequest wg phone calls. = It is on my site and I put it out because I am the one cutting and = pasting the teams work together. The work if you have been following = contains information from all the team members who sent it to me for = imput. Is it complete? No. I am trying to incorporate the work of = Ganesh and Benoit now. Can it be replaced by another submission? Sure.=20 K.C.=20 |-----Original Message-----=20 |From: Peram Marimuthu [ mailto:peram@cisco.com]=20 |Sent: Monday, February 11, 2002 12:16 PM=20 |To: K.C. Norseth=20 |Cc: ipfix@net.doit.wisc.edu=20 |Subject: Re: [ipfix] IPFIX Drafts=20 |=20 |=20 |=20 |=20 |"K.C. Norseth" wrote:=20 |=20 |> =20 |=20 |> Text format:=20 |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt=20 |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt=20 |>=20 |> Word format:=20 |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc=20 |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc=20 |>=20 |=20 |Isnt the title presumptious? I dont see anything that=20 |indicates that this is anything more than an individual contribution.=20 |=20 |Peram=20 |=20 |=20 |--=20 |Help mailto:majordomo@net.doit.wisc.edu and say "help"=20 |in message body=20 |Unsubscribe mailto:majordomo@net.doit.wisc.edu and say=20 |"unsubscribe ipfix" in message body=20 |Archive http://ipfix.doit.wisc.edu/archive/=20 | ------_=_NextPart_001_01C1B33E.B475E3AF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Please=20 recollect the last IETF meeting, WG chair has welcomed every one to = contribute=20 collectively as a design team to produce the documents and at that time = there=20 were no problem and infact Cisco folks also volunteered to produce the=20 documents. After getting accepted from the WG chairs and in the IETF = meeting,=20 the product which will be produced will be a IETF working=20 document.
 
FYI,=20 there were lot of products like and they made their = presentations in the=20 IETF and they submitted their documents either as individual or = information=20 documents.
 Ganesh also mentioned that he would = like to=20 submit as a informational document and wants some inputs from the=20 design team to comment on the document.
 
 
 
 
I=20 think we should call as IETF document rather than individual=20 submission.
 
Regards
Ramg
 
 
-----Original = Message-----
From: ext=20 Peram Marimuthu [mailto:peram@cisco.com]
Sent: Monday, = February 11,=20 2002 3:08 PM
To: Norseth, KC
Cc: K.C. Norseth;=20 ipfix@net.doit.wisc.edu; Ganesh Sadasivan; Benoit = Claise
Subject: Re:=20 [ipfix] IPFIX Drafts

The=20 way I see it, there are two drafts - one authored by Ganesh and Benoit =
and=20 the second one authored by everyone else who is on IPFIX-volunteer = mailing=20 list.=20

Until the official draft is chosen, it is everyone's responsibility = to=20 discuss both drafts
and call it draft-"private-name".=20

Peram=20

"Norseth, KC" wrote:=20

 =20

No.  These work in progress drafts are being = done by=20 the design teams that were set up at the last conference, ans = subsequest wg=20 phone calls.  It is on my site and I put it out because I am = the one=20 cutting and pasting the teams work together.  The work if you = have been=20 following contains information from all the team members who sent it = to me=20 for imput.  Is it complete? No.  I am trying to = incorporate the=20 work of Ganesh and Benoit now.  Can it be replaced by another=20 submission? Sure.=20

K.C.=20

|-----Original Message-----
|From:=20 Peram Marimuthu [mailto:peram@cisco.com] =
|Sent: Monday, February 11, 2002 12:16 PM
|To: K.C. Norseth
|Cc:=20 ipfix@net.doit.wisc.edu
|Subject: Re: = [ipfix] IPFIX=20 Drafts
|
|=20
|
|
|"K.C. Norseth" wrote:
| =
|> <snip>
| =
|> Text format:
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.tx= t=20
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architectu= re-00.txt=20
|>
|> Word = format:=20
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architectu= re-00.doc=20
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.do= c=20
|>
| =
|Isnt the title presumptious? I dont see anything = that=20
|indicates that this is anything more than an = individual=20 contribution.
|
|Peram
|
|=20
|--
|Help        mailto:majordomo@net.doit.wis= c.edu=20 and say "help"
|in message body =
|Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
|"unsubscribe ipfix" in message = body=20
|Archive     http://ipfix.doit.wisc.edu/archive/ =
|

------_=_NextPart_001_01C1B33E.B475E3AF-- -- 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 Feb 11 16:23:24 2002 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 QAA17555 for ; Mon, 11 Feb 2002 16:23:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aNfn-00009F-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 15:07:39 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aNfl-00008M-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 15:07:38 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYGT3; Mon, 11 Feb 2002 13:06:25 -0800 Message-ID: <3C683250.78CB65BD@riverstonenet.com> Date: Mon, 11 Feb 2002 16:06:24 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: kcn@norseth.com CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] draft-gsadasiv-ipfix-proposal-00.txt References: <20020211205615.23741.cpmta@c001.snv.cp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit In general sections 2 and 3 should be worked in. The sections on wire formats can, I think, be left out for now. I will go through section 7 to see what needs to be incorportated into the data model and send out some text for comment. I think most fields are covered. The stuff on reporting the flow defintion needs to be incorporated somewhere. But I'm not sure if it is the Arch or Data doc. My 2 cents. Paul kcn@norseth.com wrote: > > I am trying to imcorporate the Beniot's and Ganesh's draft into the team drafts (http://search.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt). > > Any ideas and suggestions to what is should be done, what replaces what, and so forth? I have some ideas already, but would like the opinions of all. > > K.C. > > -- > 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/ -- 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 Feb 11 17:03:33 2002 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 RAA19053 for ; Mon, 11 Feb 2002 17:03:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aOEf-00012C-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 15:43:41 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aOEd-000125-00 for ipfix-data@net.doit.wisc.edu; Mon, 11 Feb 2002 15:43:39 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id QAA21752; Mon, 11 Feb 2002 16:53:04 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma021733; Mon, 11 Feb 02 16:52:22 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXNRGT>; Mon, 11 Feb 2002 16:41:58 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06A0@slc-exc1.ctron.com> From: "Norseth, KC" To: "Calato, Paul" , data Subject: RE: [ipfix-data] Proposal for 3 new IE's Date: Mon, 11 Feb 2002 16:42:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B344.FB1240B0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B344.FB1240B0 Content-Type: text/plain What section would be best for Global VPN Identifier IE? In general, I split the IE's into sections. Was I ok on this? |-----Original Message----- |From: Calato, Paul |Sent: Monday, February 11, 2002 1:11 PM |To: data |Subject: Re: [ipfix-data] Proposal for 3 new IE's | | |calato@riverstonenet.com wrote: |> |> Can we add the following 3 IE's to the data doc. |> |> VPN-ID - TBD (I still need a spec reference) | |Here is the text. Thanks to Cliff for the spec |reference. | |Global VPN Identifier IE | |The VPN identifier associated with the flow as defined |in RFC 2685. | | |> |> 5.5.3. Dropped Byte Count IE |> |> Contains the count of octets dropped at the observation point |> associated with the identified flow. |> |> The dropped byte count can be a running counter and is the |count from |> the beginning of the flow establishment. |> |> The byte count can be a delta counter and is the count since |the last |> report for this flow. |> |> 5.5.4. Dropped Packet Count IE |> |> Contains the count of packets dropped at the observation point |> associated with the identified flow. |> |> The dropped packet count can be a running counter and is the count |> from the beginning of the flow establishment. |> |> The dropped packet count can be a delta counter and is the |count since |> the last report for this flow. |> |> -- |> 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/ | |-- |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/ | ------_=_NextPart_001_01C1B344.FB1240B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] Proposal for 3 new IE's

What section would be best for Global VPN Identifier = IE?

In general, I split the IE's into sections.  Was = I ok on this?

|-----Original Message-----
|From: Calato, Paul
|Sent: Monday, February 11, 2002 1:11 PM
|To: data
|Subject: Re: [ipfix-data] Proposal for 3 new = IE's
|
|
|calato@riverstonenet.com wrote:
|>
|> Can we add the following 3 IE's to the data = doc.
|>
|> VPN-ID - TBD (I still need a spec = reference)
|
|Here is the text. Thanks to Cliff for the = spec
|reference.
|
|Global VPN Identifier IE
|
|The VPN identifier associated with the flow as = defined
|in RFC 2685.
|
|
|>
|> 5.5.3. Dropped Byte Count IE
|>
|> Contains the count of octets dropped at the = observation point
|> associated with the identified flow.
|>
|> The dropped byte count can be a running = counter and is the
|count from
|> the beginning of the flow = establishment.
|>
|> The byte count can be a delta counter and is = the count since
|the last
|> report for this flow.
|>
|> 5.5.4. Dropped Packet Count IE
|>
|> Contains the count of packets dropped at the = observation point
|> associated with the identified flow.
|>
|> The dropped packet count can be a running = counter and is the count
|> from the beginning of the flow = establishment.
|>
|> The dropped packet count can be a delta = counter and is the
|count since
|> the last report for this flow.
|>
|> --
|> Help        = mailto:majordomo@net.doit.wi= sc.edu and say
|"help" in message body
|> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say "unsubscribe
|> ipfix" in message body
|> Archive     http://ipfix.doit.wisc.edu/archive/
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1B344.FB1240B0-- -- 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 Feb 11 17:05:59 2002 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 RAA19123 for ; Mon, 11 Feb 2002 17:05:59 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aOL3-0001Aq-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 15:50:17 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aOL0-0001Aj-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 15:50:15 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id QAA22310; Mon, 11 Feb 2002 16:59:40 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma022290; Mon, 11 Feb 02 16:59:04 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXNRMJ>; Mon, 11 Feb 2002 16:48:40 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06A1@slc-exc1.ctron.com> From: "Norseth, KC" To: "Norseth, KC" , "'Peram Marimuthu'" , "K.C. Norseth" Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] IPFIX Drafts Date: Mon, 11 Feb 2002 16:49:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B345.EA5FD970" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B345.EA5FD970 Content-Type: text/plain One thing that I should have explained better. The editor names on the drafts, As I incorporated their information they gave me, I was putting their name in the document. The next cut will have Benoit and Ganesh as part of the editors. I have not included their draft components yet, but am planning for tonight. For simplicity, I placed all names alphabetically. K.C. -----Original Message----- From: Norseth, KC Sent: Monday, February 11, 2002 12:33 PM To: 'Peram Marimuthu'; K.C. Norseth Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] IPFIX Drafts No. These work in progress drafts are being done by the design teams that were set up at the last conference, ans subsequest wg phone calls. It is on my site and I put it out because I am the one cutting and pasting the teams work together. The work if you have been following contains information from all the team members who sent it to me for imput. Is it complete? No. I am trying to incorporate the work of Ganesh and Benoit now. Can it be replaced by another submission? Sure. K.C. |-----Original Message----- |From: Peram Marimuthu [mailto:peram@cisco.com ] |Sent: Monday, February 11, 2002 12:16 PM |To: K.C. Norseth |Cc: ipfix@net.doit.wisc.edu |Subject: Re: [ipfix] IPFIX Drafts | | | | |"K.C. Norseth" wrote: | |> | |> Text format: |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt |> |> Word format: |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc |> | |Isnt the title presumptious? I dont see anything that |indicates that this is anything more than an individual contribution. | |Peram | | |-- |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/ | ------_=_NextPart_001_01C1B345.EA5FD970 Content-Type: text/html Message
One thing that I should have explained better.  The editor names on the drafts,  As I incorporated their information they gave me, I was putting their name in the document.  The next cut will have Benoit and Ganesh as part of the editors.  I have not included their draft components yet, but am planning for tonight.  For simplicity, I placed all names alphabetically.
 
K.C.
-----Original Message-----
From: Norseth, KC
Sent: Monday, February 11, 2002 12:33 PM
To: 'Peram Marimuthu'; K.C. Norseth
Cc: ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] IPFIX Drafts

No.  These work in progress drafts are being done by the design teams that were set up at the last conference, ans subsequest wg phone calls.  It is on my site and I put it out because I am the one cutting and pasting the teams work together.  The work if you have been following contains information from all the team members who sent it to me for imput.  Is it complete? No.  I am trying to incorporate the work of Ganesh and Benoit now.  Can it be replaced by another submission? Sure.

K.C.

|-----Original Message-----
|From: Peram Marimuthu [mailto:peram@cisco.com]
|Sent: Monday, February 11, 2002 12:16 PM
|To: K.C. Norseth
|Cc: ipfix@net.doit.wisc.edu
|Subject: Re: [ipfix] IPFIX Drafts
|
|
|
|
|"K.C. Norseth" wrote:
|
|> <snip>
|
|> Text format:
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt
|>
|> Word format:
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc
|> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc
|>
|
|Isnt the title presumptious? I dont see anything that
|indicates that this is anything more than an individual contribution.
|
|Peram
|
|
|--
|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/
|

------_=_NextPart_001_01C1B345.EA5FD970-- -- 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 Feb 11 17:16:52 2002 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 RAA19398 for ; Mon, 11 Feb 2002 17:16:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aOWF-0001Pj-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 16:01:51 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aOWD-0001Ov-00 for ipfix-data@net.doit.wisc.edu; Mon, 11 Feb 2002 16:01:50 -0600 Received: from riverstonenet.com (134.141.180.96 [134.141.180.96]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYHR8; Mon, 11 Feb 2002 14:00:35 -0800 Message-ID: <3C683F01.36E8268F@riverstonenet.com> Date: Mon, 11 Feb 2002 17:00:33 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Norseth, KC" CC: data Subject: Re: [ipfix-data] Proposal for 3 new IE's References: <59358A738F45D51186A30008C74CE250DA06A0@slc-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Doesn't matter to me. Put it where you think it fits best. "Norseth, KC" wrote: > > What section would be best for Global VPN Identifier IE? > > In general, I split the IE's into sections. Was I ok on this? > > |-----Original Message----- > |From: Calato, Paul > |Sent: Monday, February 11, 2002 1:11 PM > |To: data > |Subject: Re: [ipfix-data] Proposal for 3 new IE's > | > | > |calato@riverstonenet.com wrote: > |> > |> Can we add the following 3 IE's to the data doc. > |> > |> VPN-ID - TBD (I still need a spec reference) > | > |Here is the text. Thanks to Cliff for the spec > |reference. > | > |Global VPN Identifier IE > | > |The VPN identifier associated with the flow as defined > |in RFC 2685. > | > | > |> > |> 5.5.3. Dropped Byte Count IE > |> > |> Contains the count of octets dropped at the observation point > |> associated with the identified flow. > |> > |> The dropped byte count can be a running counter and is the > |count from > |> the beginning of the flow establishment. > |> > |> The byte count can be a delta counter and is the count since > |the last > |> report for this flow. > |> > |> 5.5.4. Dropped Packet Count IE > |> > |> Contains the count of packets dropped at the observation point > |> associated with the identified flow. > |> > |> The dropped packet count can be a running counter and is the count > |> from the beginning of the flow establishment. > |> > |> The dropped packet count can be a delta counter and is the > |count since > |> the last report for this flow. > |> > |> -- > |> 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/ > | > |-- > |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/ > | -- 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 Feb 11 17:31:03 2002 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 RAA19673 for ; Mon, 11 Feb 2002 17:31:02 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aOfe-0001dl-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 16:11:34 -0600 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aOfc-0001d6-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 16:11:32 -0600 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g1BMB4j33157; Mon, 11 Feb 2002 23:11:04 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 3FBB7C040; Mon, 11 Feb 2002 23:10:08 +0100 (CET) To: Peram Marimuthu Subject: Re: [ipfix] IPFIX Drafts Message-ID: <1013465408.3c6841402431a@citadel.mobility.ccrle.nec.de> Date: Mon, 11 Feb 2002 23:10:08 +0100 (CET) From: quittek@ccrle.nec.de Cc: "Norseth, KC" , "K.C. Norseth" , ipfix@net.doit.wisc.edu, Ganesh Sadasivan , Benoit Claise References: <59358A738F45D51186A30008C74CE250DA069E@slc-exc1.ctron.com> <3C682499.7C15091E@cisco.com> In-Reply-To: <3C682499.7C15091E@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Zitiere Peram Marimuthu : > The way I see it, there are two drafts - one authored by Ganesh and > Benoit > and the second one authored by everyone else who is on IPFIX-volunteer > mailing list. > > Until the official draft is chosen, it is everyone's responsibility to > discuss both drafts What do you mean by official? Probably you mean a working group I-D. There are different ways to get to a working group I-D. One procedure is having a proposal shoot-out. This is maybe what you are thinking of. This working group chose another approach: the design team which is established to produce the working group I-D. There is not a competition of different drafts, but a competition of ideas and suggestions to be integrated into the WG I-D. And you can see Ganesh's and Benoit's individual draft as a large contribution of suggestions for the WG I-D. Anyway, independent of which way you choose, for becoming a WG I-D you need approval by a WG chair. And without anticipating the approval decision of our chairs, I think that the design team with KC as editor is backed by them. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > and call it draft-"private-name". > > Peram > > "Norseth, KC" wrote: > > > > > > > No. These work in progress drafts are being done by the design teams > that were set up > > at the last conference, ans subsequest wg phone calls. It is on my > site and I put it > > out because I am the one cutting and pasting the teams work together. > The work if you > > have been following contains information from all the team members who > sent it to me for > > imput. Is it complete? No. I am trying to incorporate the work of > Ganesh and Benoit > > now. Can it be replaced by another submission? Sure. > > > > K.C. > > > > |-----Original Message----- > > |From: Peram Marimuthu [mailto:peram@cisco.com] > > |Sent: Monday, February 11, 2002 12:16 PM > > |To: K.C. Norseth > > |Cc: ipfix@net.doit.wisc.edu > > |Subject: Re: [ipfix] IPFIX Drafts > > | > > | > > | > > | > > |"K.C. Norseth" wrote: > > | > > |> > > | > > |> Text format: > > |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt > > |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt > > |> > > |> Word format: > > |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc > > |> http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc > > |> > > | > > |Isnt the title presumptious? I dont see anything that > > |indicates that this is anything more than an individual > contribution. > > | > > |Peram > > | > > | > > |-- > > |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/ > > | > -- 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 Feb 11 19:02:24 2002 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 TAA20586 for ; Mon, 11 Feb 2002 19:02:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aQ8a-0003a3-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 17:45:32 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aQ8X-0003YU-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 17:45:29 -0600 Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1BNivE11858; Mon, 11 Feb 2002 15:44:57 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-59.cisco.com [171.71.137.59]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ABX78727; Mon, 11 Feb 2002 15:42:29 -0800 (PST) Message-ID: <3C6857DC.D0515670@cisco.com> Date: Mon, 11 Feb 2002 15:46:36 -0800 From: Peram Marimuthu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: quittek@ccrle.nec.de CC: "Norseth, KC" , "K.C. Norseth" , ipfix@net.doit.wisc.edu, Ganesh Sadasivan , Benoit Claise Subject: Re: [ipfix] IPFIX Drafts References: <59358A738F45D51186A30008C74CE250DA069E@slc-exc1.ctron.com> <3C682499.7C15091E@cisco.com> <1013465408.3c6841402431a@citadel.mobility.ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > > > This working group chose another approach: the design team which > is established to produce the working group I-D. There is not a competition > of different drafts, but a competition of ideas and suggestions to > be integrated into the WG I-D. And you can see Ganesh's and Benoit's > individual draft as a large contribution of suggestions for the WG I-D. I am glad you view Ganesh/Benoit as a "large contribution" to the working group ID. Their write-up has significant technical contribution and is well worth being the foundation of WGID. Quoting what you wrote in another thread " My point is that I am confused about the fact that KC ignored everything they wrote when compiling the design team's draft, particularly because issues covered by Ganesh's and Benoit's draft are not covered in the drqaft he distributed. " I agree to this completely. Why not base the WGID from G/B's draft and build from there? Peram -- 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 Feb 11 19:23:16 2002 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 TAA20857 for ; Mon, 11 Feb 2002 19:23:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aQTX-0004BB-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 18:07:11 -0600 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aQTU-0004A4-00 for ipfix-req@net.doit.wisc.edu; Mon, 11 Feb 2002 18:07:08 -0600 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g1C04Dj33434; Tue, 12 Feb 2002 01:04:13 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 8CE7DC040; Tue, 12 Feb 2002 01:03:21 +0100 (CET) To: Benoit Claise Subject: [ipfix-req] Re: [ipfix] Terminology suggestion Message-ID: <1013472201.3c685bc97479f@citadel.mobility.ccrle.nec.de> Date: Tue, 12 Feb 2002 01:03:21 +0100 (CET) From: quittek@ccrle.nec.de Cc: ipfix-req@net.doit.wisc.edu, quittek@ccrle.nec.de References: <200202111529.g1BFTnb27134@bru-cse-222.cisco.com> In-Reply-To: <200202111529.g1BFTnb27134@bru-cse-222.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Hi Benoit, Benoit Claise wrote: > Hi Juergen, > > Here are my input on this terminology, as promised during the conf. > call. > > Note that whether the definitions go into the requirements draft or in > the architecture doesn't make any difference to me. This only thing of > importance is that, if the requirement draft dissapears with the time, > we don't want to loose the defintions. One solution is that the > architecture document will have to repeat the definitions. > > > > > see draft-ietf-ipfix-reqs-00.txt, section 1.1 > > I just copied the definition from draft-ietf-ipfix-reqs-00.txt for > completeness. > A flow is a set of packets passing an observation point in the > network during a certain time interval. All packets belonging to a > particular flow have a set of common properties derived from the > data contained in the packet and from the packet treatment at the > observation point. > > I would go a little bit further in the definition, by describing what a > property coul be: > A flow is defined as a set of packets passing an observation point in the > network during a certain time interval. All packets belonging to a > particular flow have a set of common properties. Each property is > defined as the result of applying a function to the values of: > > a. one or more of packet header fields (eg. destination IP address) > b. one or more properties of the packet itself (eg. packet length) > c. one or more of fields derived from packet treatment (eg. AS > number) > > A packet is defined to belong to a flow if it matches all the defined > properties of the flow. Fine. But we should mention somewhere that also partial matches might be sufficient. > > > > 2.2. Observation Point > > The observation point is a location in the network where IP packets > > can be observed. Examples are a line to which a probe is attached, > > a shared medium, such as an Ethernet-based LAN, a port of a router, > > or an entire router with several ports. > > I agree with the definition above, but I would be more specific: > The observation point is a location in the network where IP packets > can be observed. Examples are a line to which a probe is attached, > a shared medium, such as an Ethernet-based LAN, a port of a router, > or an entire router with several ports. The observation is characterized > by one or a set of interfaces (physical or logical) of the exporter. I think the last sentence is too restrictive. Why excluding packet samplers sending samples from a remote observation point to a meter? > Note: the exporter is defined below. > > > > 2.3. Trafic Flow Meter or Meter > > A meter observes packets at one or more observation points. > > It analyzes the content of the packets and maps them to flows. > > For each observed flow the meter computes statistics and maintains > > a flow record where it stores relevant flow infromation. > > I think that the concept of exporter makes more sense. > And I believe that you are mixing 2 definitions: No, it's just the opposite: I want to separate meter and exporter. > - the exporter (ex: a router or a probe) > - the metering process which analyzes the traffic > So I would just remove this definition and leave the exporter/metering > process > as 2 definitions. > > * Exporter: The entity on which flows are measured and are > exported. The exporter can be a router, a middlebox [2], or a > traffic measurement probe. Here you are mixing metering and exporting. I see two function blocks in our architecture: The meter executing the metering process and the exporter participating as sender in the flow information export process. > > > > 2.4. Metering Process > > The metering process includes all actions performed by a meter > > with respect to observing packets, timestamping them, analyzing them, > > mapping them to flows, computing flow statistics, detecting flow > > expiration, and maintaining flow records. > > Measurement process that is carried out at the observation domain. > The metering process includes all actions performed by a meter > with respect to observing packets, timestamping them, analyzing them, > mapping them to flows, computing flow statistics, detecting flow > expiration, and maintaining flow records. > > Note: we had to introduce the concept of observation domain. > > * Observation Domain: The set of observation points which is the > largest aggregatable set of flow information at the exporter is > termed as an observation domain. The observation domain presents > itself a unique ID to the collector for identifying the export > packets generated by it. > > Example: The observation domian could be a router linecard, > composed of several interfaces with each interface being an > observation point. > > Why the concept of observation domain? > Typically for a linecard on a router, which is an independant entity. > So an exporter can be composed of several observation domains (read > linecards). > There is one metering process per observation domain (read linecard). > You can do flow aggregations for these linecard flows but not between > flows from different linecards. Well you are approaching my hierarchy: exporter - meter - observation point The meter processes (and aggregates) packets from one or more observation points and generates flow records. The sum of its observation points outlines your observation domain. The exporter exports flow records produced by one or more meters. First you say is "delete the term of meter" and then "add the term of observation domain", because now we need it. If you just keep the meter, you do not need the observation domain and you have an concept which is easier to understand and which also matches the function blocks of the architecture. > Note: I agree that we are missing a high level picture of this in > draft-gsadasiv-ipfix-proposal-00.txt > > > > > 2.5. Flow Record > > A flow record keeps information a flow including characteristic > > properties of the flow, for example the source IP address, > > and measured properties of the flow, for example the total number > > of bytes of all packets of the flow. > > All packets belonging to a particular flow have a set of common > properties. > But the flow record doesn't necessarily have the notion of its own > properties. > I would remove the properties part. > Here is the definition I would propose. > > * Flow Record: A flow record provides information about a specific > flow that was measured at an observation point using a certain > set of methods within an exporter. > > > > 2.6. Flow Information Exporter or Exporter > > The exporter sends flow records created and maintained by one or > > more meters to one or more data collectors. > > See my previous remark about exporter versus meter dito > > > > 2.7. Flow Information Data Collector or Data Collector > > The data collector receives flow records from one or more exporters. > > The data collector might process or store received flow record, > > but these actions are out of the scope of this document. > > OK. We called it just collector. But this is just a detail! Fine. What about the heading "Flow Information Collector or Collector" and then renaming all data collectors into collectors? Best wishes, Juergen > > Regards, Benoit. > > > > > > 2.8. Flow Information Export > > Flow information export denotes the process of transferring flow > > records from an exporter to a data collector. > > > > > > -- > > 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/ > > > > -- 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 Feb 11 19:34:43 2002 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 TAA21008 for ; Mon, 11 Feb 2002 19:34:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aQeh-0004Qv-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 18:18:43 -0600 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aQee-0004QJ-00 for ipfix-req@net.doit.wisc.edu; Mon, 11 Feb 2002 18:18:40 -0600 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g1C0EGj33458; Tue, 12 Feb 2002 01:14:16 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 9889AC040; Tue, 12 Feb 2002 01:13:24 +0100 (CET) To: Benoit Claise Subject: [ipfix-req] Re: [ipfix] Terminology suggestion Message-ID: <1013472804.3c685e2489dbc@citadel.mobility.ccrle.nec.de> Date: Tue, 12 Feb 2002 01:13:24 +0100 (CET) From: quittek@ccrle.nec.de Cc: ipfix-req@net.doit.wisc.edu, quittek@ccrle.nec.de References: <200202111529.g1BFTnb27134@bru-cse-222.cisco.com> In-Reply-To: <200202111529.g1BFTnb27134@bru-cse-222.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Hi Benoit, Benoit Claise wrote: > Hi Juergen, > > Here are my input on this terminology, as promised during the conf. > call. > > Note that whether the definitions go into the requirements draft or in > the architecture doesn't make any difference to me. This only thing of > importance is that, if the requirement draft dissapears with the time, > we don't want to loose the defintions. One solution is that the > architecture document will have to repeat the definitions. > > > > > see draft-ietf-ipfix-reqs-00.txt, section 1.1 > > I just copied the definition from draft-ietf-ipfix-reqs-00.txt for > completeness. > A flow is a set of packets passing an observation point in the > network during a certain time interval. All packets belonging to a > particular flow have a set of common properties derived from the > data contained in the packet and from the packet treatment at the > observation point. > > I would go a little bit further in the definition, by describing what a > property coul be: > A flow is defined as a set of packets passing an observation point in the > network during a certain time interval. All packets belonging to a > particular flow have a set of common properties. Each property is > defined as the result of applying a function to the values of: > > a. one or more of packet header fields (eg. destination IP address) > b. one or more properties of the packet itself (eg. packet length) > c. one or more of fields derived from packet treatment (eg. AS > number) > > A packet is defined to belong to a flow if it matches all the defined > properties of the flow. Fine. But we should mention somewhere that also partial matches might be sufficient. > > > > 2.2. Observation Point > > The observation point is a location in the network where IP packets > > can be observed. Examples are a line to which a probe is attached, > > a shared medium, such as an Ethernet-based LAN, a port of a router, > > or an entire router with several ports. > > I agree with the definition above, but I would be more specific: > The observation point is a location in the network where IP packets > can be observed. Examples are a line to which a probe is attached, > a shared medium, such as an Ethernet-based LAN, a port of a router, > or an entire router with several ports. The observation is characterized > by one or a set of interfaces (physical or logical) of the exporter. I think the last sentence is too restrictive. Why excluding packet samplers sending samples from a remote observation point to a meter? > Note: the exporter is defined below. > > > > 2.3. Trafic Flow Meter or Meter > > A meter observes packets at one or more observation points. > > It analyzes the content of the packets and maps them to flows. > > For each observed flow the meter computes statistics and maintains > > a flow record where it stores relevant flow infromation. > > I think that the concept of exporter makes more sense. > And I believe that you are mixing 2 definitions: No, it's just the opposite: I want to separate meter and exporter. > - the exporter (ex: a router or a probe) > - the metering process which analyzes the traffic > So I would just remove this definition and leave the exporter/metering > process > as 2 definitions. > > * Exporter: The entity on which flows are measured and are > exported. The exporter can be a router, a middlebox [2], or a > traffic measurement probe. Here you are mixing metering and exporting. I see two function blocks in our architecture: The meter executing the metering process and the exporter participating as sender in the flow information export process. > > > > 2.4. Metering Process > > The metering process includes all actions performed by a meter > > with respect to observing packets, timestamping them, analyzing them, > > mapping them to flows, computing flow statistics, detecting flow > > expiration, and maintaining flow records. > > Measurement process that is carried out at the observation domain. > The metering process includes all actions performed by a meter > with respect to observing packets, timestamping them, analyzing them, > mapping them to flows, computing flow statistics, detecting flow > expiration, and maintaining flow records. > > Note: we had to introduce the concept of observation domain. > > * Observation Domain: The set of observation points which is the > largest aggregatable set of flow information at the exporter is > termed as an observation domain. The observation domain presents > itself a unique ID to the collector for identifying the export > packets generated by it. > > Example: The observation domian could be a router linecard, > composed of several interfaces with each interface being an > observation point. > > Why the concept of observation domain? > Typically for a linecard on a router, which is an independant entity. > So an exporter can be composed of several observation domains (read > linecards). > There is one metering process per observation domain (read linecard). > You can do flow aggregations for these linecard flows but not between > flows from different linecards. Well you are approaching my hierarchy: exporter - meter - observation point The meter processes (and aggregates) packets from one or more observation points and generates flow records. The sum of its observation points outlines your observation domain. The exporter exports flow records produced by one or more meters. First you say is "delete the term of meter" and then "add the term of observation domain", because now we need it. If you just keep the meter, you do not need the observation domain and you have an concept which is easier to understand and which also matches the function blocks of the architecture. > Note: I agree that we are missing a high level picture of this in > draft-gsadasiv-ipfix-proposal-00.txt > > > > > 2.5. Flow Record > > A flow record keeps information a flow including characteristic > > properties of the flow, for example the source IP address, > > and measured properties of the flow, for example the total number > > of bytes of all packets of the flow. > > All packets belonging to a particular flow have a set of common > properties. > But the flow record doesn't necessarily have the notion of its own > properties. > I would remove the properties part. > Here is the definition I would propose. > > * Flow Record: A flow record provides information about a specific > flow that was measured at an observation point using a certain > set of methods within an exporter. > > > > 2.6. Flow Information Exporter or Exporter > > The exporter sends flow records created and maintained by one or > > more meters to one or more data collectors. > > See my previous remark about exporter versus meter dito > > > > 2.7. Flow Information Data Collector or Data Collector > > The data collector receives flow records from one or more exporters. > > The data collector might process or store received flow record, > > but these actions are out of the scope of this document. > > OK. We called it just collector. But this is just a detail! Fine. What about the heading "Flow Information Collector or Collector" and then renaming all data collectors into collectors? Best wishes, Juergen > > Regards, Benoit. > > > > > > 2.8. Flow Information Export > > Flow information export denotes the process of transferring flow > > records from an exporter to a data collector. > > > > > > -- > > 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/ > > > > -- 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 Feb 11 19:43:10 2002 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 TAA21083 for ; Mon, 11 Feb 2002 19:43:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aQlC-0004ZC-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 18:25:26 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aQlA-0004Xp-00; Mon, 11 Feb 2002 18:25:24 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C0HIW11688; Mon, 11 Feb 2002 18:17:19 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFW0VW>; Mon, 11 Feb 2002 16:17:17 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982AA1@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , ipfix-arch@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu Cc: Benoit Claise , Ganesh Sadasivan Subject: [ipfix-arch] Ganesh's and Benoit's contribution - Clarification Date: Mon, 11 Feb 2002 16:17:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B35A.9FB91520" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B35A.9FB91520 Content-Type: text/plain; charset="iso-8859-1" :What do you mean by "helping THEM"? Is there a 'us' and 'them'? :They are members of the design team. My intention is to help US :in making good progress. : Gee..I was a few hours away from my computer and it seems this statement caused a commotion. This was not I meant by a long shot. I just asked if you were working with them on their solution, that's it. The problem is that since the discussion was already heated people interpreted it in thw rong way,i.e, as some sort of an attack. As I said more than once, I have **nothing** against netflow or Cisco folks on this list. Now, I understand that questions like mine that challenge some assumptions on the directions of this WG may annoy some people, but this is the IETF process. regards, Reialdo ------_=_NextPart_001_01C1B35A.9FB91520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ganesh's and Benoit's contribution - Clarification

:What do you mean by "helping THEM"? Is = there a 'us' and 'them'?
:They are members of the design team. My intention = is to help US
:in making good progress.
:

Gee..I was a few hours away from my computer and it = seems this statement caused a commotion. This was not I meant by a long = shot. I just asked if you were working with them on their solution, = that's it.

The problem is that since the discussion was already = heated people interpreted it in thw rong way,i.e, as some sort of an = attack.

As I said more than once, I have **nothing** against = netflow or Cisco folks on this list.

Now, I understand that questions like mine that = challenge some assumptions on the directions of this WG may annoy some = people, but this is the IETF process.

regards,

Reialdo

------_=_NextPart_001_01C1B35A.9FB91520-- -- 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 Feb 11 20:12:50 2002 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 UAA21313 for ; Mon, 11 Feb 2002 20:12:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aR7p-00051c-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 18:48:49 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aR7o-000518-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 18:48:48 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C0m9W13691; Mon, 11 Feb 2002 18:48:09 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXADG>; Mon, 11 Feb 2002 16:48:07 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982AEF@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Benoit Claise Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] Answer to the recent comments on the Architectur e Draft Date: Mon, 11 Feb 2002 16:48:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B35E.EF1DF460" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B35E.EF1DF460 Content-Type: text/plain; charset="iso-8859-1" Bernoit, I've already sent a clarification to the mailing list. I think due to the fact that the discussion was somewhat heated people interpret it the wrong way. Anyway, as I always said, I do not have anything against you or Cisco. I just think some things we can improve things realted to netflow. When you say "But you seem to be negativ to whatever we propose" it's not true. Unfortunately some of the things I disagree seems to mean a lot to Cisco, because they clearly overshadow the things I agreed with you. Reinaldo :-----Original Message----- :From: Benoit Claise [mailto:bclaise@cisco.com] :Sent: Sunday, February 10, 2002 11:54 PM :To: ipfix-arch@net.doit.wisc.edu; Penno, Reinaldo [SC9:T327:EXCH] :Cc: quittek@ccrle.nec.de :Subject: Re: [ipfix-arch] Answer to the recent comments on the :Architecture Draft : : :Mister Penno, : :> :> 1 - General Stuff: :> :> : :> :The draft distributed by KC discusses a lot of far related :> :issues, but some essential components of the architecture are :> :(so far) rather poorly described. This is different in the :> :I-D of Ganesh and Benoit. :> : :> :So why don't we take some text from it. I think their intention :> :is to contribute to the joint document (see their title). :> :> I really do not know what you mean by this. Are you trying :to help them? :> : :It seems that you have a little problem either with Ganesh and :me. Or either with the company that Ganesh and I are working :for. As I don't know you from anywhere, I tend to be believe :of the latter option. :Because, what kind of reply did you formulate? Is this a :technical argument? :Or just to be negative to what engineers of a certain company :are proposing. : :Please explain. : :BTW, one of Steve Coya's sentence during the introduction :presentation before an IETF is: "don't come to the playground :if you're not ready to share your toys".And this is what :Ganesh and I have doing, by even sharing our customers :feedback. But you seem to be negativ to whatever we propose... :by principle? : : :While we are at the explanation time, just a little remark :that made me smile. :But I'm not sure many people noticed. : :I read through your paragraph : : IPFIX WG :Kevin Zhang : Internet Draft XACCT :Technologies : Expiration: August 2002 Reinaldo Penno : NortelNetworks : : :February 2002 : : : : Contributions to the IPFIX Architecture : (Capability Negotiation) : : ... : :10.2.2 Reliability : : ... : : In the case there are multiple collectors operating redundant mode, : the exporter MAY multicast the flow records to the set of collectors : that joined the export multicast group, instead of sending several : unicast streams towards the different collectors. Multicast would : lower the bandwidth requirements on the export link in case that the : collectors are on the same media, and could lower the internal bus : utilization on the exporter. : : :And I thought.. Hmmm, I know this paragraph. It looks familiar. :http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-propos al-00.txt Yes actually I wrote it ;) So what's the point here? Instead of having a discussion on basic architecture pints, are we just writing and writing paragraphs just to make sure to have his own name on a draft/rfc? Basically, I don't care too much about my name if we do this IPFIX right... Have a nice day. Benoit. ------_=_NextPart_001_01C1B35E.EF1DF460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] Answer to the recent comments on the = Architecture Draft

Bernoit,

I've already sent a clarification to the mailing = list. I think due to the fact that the discussion was somewhat heated = people interpret it the wrong way.

Anyway, as I always said, I do not have anything = against you or Cisco. I just think some things we can improve things = realted to netflow.

When you say "But you seem to be negativ to = whatever we propose" it's not true.

Unfortunately some of the things I disagree seems to = mean a lot to Cisco, because they clearly overshadow the things I = agreed with you.

Reinaldo

:-----Original Message-----
:From: Benoit Claise [mailto:bclaise@cisco.com]
:Sent: Sunday, February 10, 2002 11:54 PM
:To: ipfix-arch@net.doit.wisc.edu; Penno, Reinaldo = [SC9:T327:EXCH]
:Cc: quittek@ccrle.nec.de
:Subject: Re: [ipfix-arch] Answer to the recent = comments on the
:Architecture Draft
:
:
:Mister Penno,
:
:>
:> 1 - General Stuff:
:>
:> :
:> :The draft distributed by KC discusses a lot = of far related
:> :issues, but some essential components of the = architecture are
:> :(so far) rather poorly described. This is = different in the
:> :I-D of Ganesh and Benoit.
:> :
:> :So why don't we take some text from it. I = think their intention
:> :is to contribute to the joint document (see = their title).
:>
:> I really do not know what you mean by this. = Are you trying
:to help them?
:>
:
:It seems that you have a little problem either with = Ganesh and
:me. Or either with the company that Ganesh and I = are working
:for. As I don't know you from anywhere, I tend to = be believe
:of the latter option.
:Because, what kind of reply did you formulate? Is = this a
:technical argument?
:Or just to be negative to what engineers of a = certain company
:are proposing.
:
:Please explain.
:
:BTW, one of Steve Coya's sentence during the = introduction
:presentation before an IETF is: "don't come to = the playground
:if you're not ready to share your toys".And = this is what
:Ganesh and I have doing, by even sharing our = customers
:feedback. But you seem to be negativ to whatever we = propose...
:by principle?
:
:
:While we are at the explanation time, just a little = remark
:that made me smile.
:But I'm not sure many people noticed.
:
:I read through your paragraph
:
:   IPFIX = WG           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;
:Kevin Zhang 
:   Internet = Draft           &= nbsp;           &= nbsp;            = XACCT
:Technologies
:   Expiration: August = 2002           &n= bsp;           &n= bsp;       Reinaldo Penno
:          &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;          = NortelNetworks
:   
:          &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           =
:February 2002
:   
:   
:
:          &n= bsp;     Contributions to the IPFIX Architecture =
:          &n= bsp;            = (Capability Negotiation)
:
:  ...
:
:10.2.2 Reliability
:
:  ...
:
:  In the case there are multiple collectors = operating redundant mode,
:  the exporter MAY multicast the flow records = to the set of collectors
:  that joined the export multicast group, = instead of sending several
:  unicast streams towards the different = collectors. Multicast would
:  lower the bandwidth requirements on the = export link in case that the
:  collectors are on the same media, and could = lower the internal bus
:  utilization on the exporter.
:
:
:And I thought.. Hmmm, I know this paragraph. It = looks familiar.
:http://www.ietf.org/internet-drafts/draft-gsadasiv-ipf= ix-propos
al-00.txt
Yes actually I wrote it ;)

So what's the point here? Instead of having a = discussion on basic architecture pints, are we just writing and writing = paragraphs just to make sure to have his own name on a = draft/rfc?

Basically, I don't care too much about my name if we = do this IPFIX right...

Have a nice day. Benoit.


------_=_NextPart_001_01C1B35E.EF1DF460-- -- 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 Feb 11 20:37:11 2002 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 UAA21609 for ; Mon, 11 Feb 2002 20:37:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aReg-0005lU-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 19:22:46 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aRee-0005kv-00 for ipfix-req@net.doit.wisc.edu; Mon, 11 Feb 2002 19:22:44 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C1M5W19483; Mon, 11 Feb 2002 19:22:05 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXA3N>; Mon, 11 Feb 2002 17:22:03 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982B2A@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Mon, 11 Feb 2002 17:21:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B363.AA11C4F0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B363.AA11C4F0 Content-Type: text/plain; charset="iso-8859-1" Hello Juergen, :-----Original Message----- :From: Juergen Quittek [mailto:quittek@ccrle.nec.de] :Sent: Monday, February 11, 2002 2:13 AM :To: ipfix-req@net.doit.wisc.edu :Subject: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt : : : :9. Change section 5.3.1. "Congestion Awareness" to : "Congestion-Friendlyness" : Replace text of subsection by "For the flow information : export a congestion-friendly protocol MUST be supported." : this might be a chiken and egg thing, but what's the definition of a "congestion-friendly" protocol? regards, Reinaldo ------_=_NextPart_001_01C1B363.AA11C4F0 Content-Type: text/html; charset="iso-8859-1" RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt

Hello Juergen,

:-----Original Message-----
:From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
:Sent: Monday, February 11, 2002 2:13 AM
:To: ipfix-req@net.doit.wisc.edu
:Subject: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt
:
:
:
:9. Change section 5.3.1. "Congestion Awareness" to
:   "Congestion-Friendlyness"
:   Replace text of subsection by "For the flow information
:   export a congestion-friendly protocol MUST be supported."
:

this might be a chiken and egg thing, but what's the definition of a "congestion-friendly" protocol?

regards,

Reinaldo

------_=_NextPart_001_01C1B363.AA11C4F0-- -- 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 Feb 11 20:51:34 2002 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 UAA21726 for ; Mon, 11 Feb 2002 20:51:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aRmk-0005yK-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 19:31:06 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aRmj-0005xc-00 for ipfix-arch@net.doit.wisc.edu; Mon, 11 Feb 2002 19:31:05 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C1UPW19907; Mon, 11 Feb 2002 19:30:25 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXARK>; Mon, 11 Feb 2002 17:30:24 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982B34@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Sebastian Zander , ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] Comments/questions on draft-ietf-ipfix-architect ure-00.txt Date: Mon, 11 Feb 2002 17:30:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B364.D61AB2E0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B364.D61AB2E0 Content-Type: text/plain; charset="iso-8859-1" :-----Original Message----- :From: Sebastian Zander [mailto:zander@fokus.gmd.de] :Sent: Monday, February 11, 2002 4:41 AM :To: ipfix-arch@net.doit.wisc.edu :Subject: [ipfix-arch] Comments/questions on :draft-ietf-ipfix-architecture-00.txt : : :The draft is in a very early state but nevertheless i have :some comments/questions: : :section 2: : :"* Describes the required mechanisms to interoperate with :other protocol/architecture :this may includes AAA or Diameter or Intrusion Detection system. :* Identifies a minimal set of applications for IPFIX." : :I don't understand why this is part of the architecture :document. It's fine to list :a set of applications but describing these and the interaction :with IPFIX is IMHO :out of scope of the draft. : : :"* May perform appropriate middle-box functions to translate :the flow information." : :I would suggest deleting or rewording this to something like: :May add middle-box :information to flow record but the exporter certainly does not :perform middlebox :functions. okay, agrred. The exporter itself as a self-contained entity does not perform middlebox functions, but middlebox functions change how the exporter see the flows. : :Am I right that the exporter does the packet to flow :classification and statistics :calculation? : :section 4.3: The text totally confuses me. Why is reliability :and security now a function :of the IPFIX protocol? The reqirements are already in the :requirement draft and the protocol :spec. will be in some future protocol draft I guess. Probably :a wording issue which :can be solved by omitting the word protocol. : :section 4.4: : :Why does the collector need to maintain a repository of IP :flow statistics? Can't the :application do that? : :section 5: : :Out of scope of this draft IMHO. There should be either an :application draft or maybe :different application drafts. : : :It is possible that several protocols (e.g. LFAP, CRANE, :Netflow, Diameter) meet the :IPFIX requirements. In this case, this capability is used to :negotiate which protocol :the end points will use. : :Does this sections tells me that there is no single IPFIX :protocol but instead there :are a couple of protcols? So in the end we have a couple of :protocols and each vendor :implements a different. ;-) I think there should be a :standardized protocol. : We might omit this part from the capability negotiation since this would be another parameter. It would be up to vendor to include in the capability negotiation its protocol as a vendor-extension. So, I'll reword this section :section 6.6.2.6: : :What is the exact definition of overlapping flows? : I'll add that. It's when a flow is reported twice without the exporter or collector knowing about it. thanks, Reinaldo ------_=_NextPart_001_01C1B364.D61AB2E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] Comments/questions on = draft-ietf-ipfix-architecture-00.txt

:-----Original Message-----
:From: Sebastian Zander [mailto:zander@fokus.gmd.de]
:Sent: Monday, February 11, 2002 4:41 AM
:To: ipfix-arch@net.doit.wisc.edu
:Subject: [ipfix-arch] Comments/questions on
:draft-ietf-ipfix-architecture-00.txt
:
:
:The draft is in a very early state but nevertheless = i have
:some comments/questions:
:
:section 2:
:
:"* Describes the required mechanisms  to = interoperate with
:other protocol/architecture
:this may includes AAA or Diameter or Intrusion = Detection system.
:* Identifies a minimal set of applications for = IPFIX."
:
:I don't understand why this is part of the = architecture
:document. It's fine to list
:a set of applications but describing these and the = interaction
:with IPFIX is IMHO
:out of scope of the draft.
:
:
:"* May perform appropriate middle-box = functions to translate
:the flow information."
:
:I would suggest deleting or rewording this to = something like:
:May add middle-box
:information to flow record but the exporter = certainly does not
:perform middlebox
:functions.

okay, agrred. The exporter itself as a self-contained = entity does not perform middlebox functions, but middlebox functions = change how the exporter see the flows.

:
:Am I right that the exporter does the packet to = flow
:classification and statistics
:calculation?
:
:section 4.3: The text totally confuses me. Why is = reliability
:and security now a function
:of the IPFIX protocol? The reqirements are already = in the
:requirement draft and the protocol
:spec. will be in some future protocol draft I = guess. Probably
:a wording issue which
:can be solved by omitting the word protocol.
:
:section 4.4:
:
:Why does the collector need to maintain a = repository of IP
:flow statistics? Can't the
:application do that?
:
:section 5:
:
:Out of scope of this draft IMHO. There should be = either an
:application draft or maybe
:different application drafts.
:
:
:It is possible that several protocols (e.g. LFAP, = CRANE,
:Netflow, Diameter) meet the
:IPFIX requirements.  In this case, this = capability is used to
:negotiate which protocol
:the end points will use.
:
:Does this sections tells me that there is no single = IPFIX
:protocol but instead there
:are a couple of protcols? So in the end we have a = couple of
:protocols and each vendor
:implements a different. ;-) I think there should be = a
:standardized protocol.
:
We might omit this part from the capability = negotiation since this would be another parameter. It would be up to = vendor to include in the capability negotiation its protocol as a = vendor-extension. So, I'll reword this section

:section 6.6.2.6:
:
:What is the exact definition of overlapping = flows?
:

I'll add that. It's when a flow is reported twice = without the exporter or collector knowing about it.

thanks,

Reinaldo

------_=_NextPart_001_01C1B364.D61AB2E0-- -- 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 Feb 11 20:57:36 2002 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 UAA21811 for ; Mon, 11 Feb 2002 20:57:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aRxO-0006DP-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 19:42:06 -0600 Received: from pool-162-83-255-47.ny5030.east.verizon.net ([162.83.255.47] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aRxL-0006DI-00 for ipfix-data@net.doit.wisc.edu; Mon, 11 Feb 2002 19:42:03 -0600 Received: from sphynx (sphynx.newyork.qosient.com [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g1C1fwL20368; Mon, 11 Feb 2002 20:41:58 -0500 Reply-To: From: "Carter Bullard" To: Cc: "'Simon Leinen'" , , "'data'" Subject: RE: [ipfix-data] Re: Information Model supporting vendor specific IE's Date: Mon, 11 Feb 2002 20:41:50 -0500 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6603BEF2@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660511B1@ptah.newyork.qosient.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Excellent! Sorry that I missed it when I went through the first time! Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of > calato@riverstonenet.com > Sent: Monday, February 11, 2002 11:32 AM > To: carter@qosient.com > Cc: 'Simon Leinen'; kcn@norseth.com; 'data' > Subject: [ipfix-data] Re: Information Model supporting vendor > specific IE's > > > Alrady there... > > 9.34. Vendor Specific IE > > Vendors may add their own information to the protocol. Information > contained in this IE is vendor specific. OID and OID Value is > defined by ITU X.680.X683 (1997) and is encoded as defined by ITU > X.690.691(1997). This IE MUST not contain any information which > cannot be safely ignored by the Exporter or Collector. If multiple > Vendor Specific IE's with the same OID occur, then the vendor > defines semantics of ordering. > > > > > Carter Bullard wrote: > > > > Gentle People, > > We'll need an of IE type that supports vendor specific > metrics. Rather > > than requiring that an IE be approved, we should support vendor > > proprietary IE's in order to transport unique metrics. > Ones that are > > not defined in the RFC. The inclusion of these IE types would > > be advertised at connect time, and the collector can > > decide if it will pass them through or not. > > > > I didn't see this in the list. > > > > Carter > > > > Carter Bullard > > QoSient, LLC > > 300 E. 56th Street, Suite 18K > > New York, New York 10022 > > > > carter@qosient.com > > Phone +1 212 588-9133 > > Fax +1 212 588-9134 > > http://qosient.com > > > > > -----Original Message----- > > > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On > > > Behalf Of calato@riverstonenet.com > > > Sent: Wednesday, February 06, 2002 11:11 AM > > > To: Simon Leinen > > > Cc: kcn@norseth.com; data > > > Subject: [ipfix-data] Re: Information Model > > > > > > > > > > > > Here is a first cut at the list of data elements to be > reported. I > > > of course hacked it out of the LFAP spec. > > > > > > I think we need to begin with a couple of guidlines > (which we should > > > augment as we go). They are just guidelines. > > > > > > 1. Data element values should be defined in terms of > > > other specifications. Since we are only reporting > > > things in other protocols, there should be little > > > reason for us to define anything from scatch. > > > > > > 2. Each element should be able to be interpreted on > > > it own. In other words, don't make me look though > > > the rest of the message to figure out what this > > > value means. The drawback is this can lead to > > > data element explosion. We'll have to balance > > > the tradeoffs. > > > > > > 3. Others?.... > > > > > > 1.1 Source Address IE > > > > > > Source address associated with a flow. Addresses can > be of any > > > type > > > as described in RFC 1700 [note - we need a new > reference here, > > > 1700 > > > has been obsoleted] > > > > > > 1.2 Destination Address IE > > > > > > Destination address associated with a flow. same as above. > > > > > > 1.3 Internal queue priority > > > > > > A switch may map several of its internal priority queues into a > > > Premium, High, Medium or Low category. > > > > > > [ this sections needs more work] > > > > > > > > > 1.4 Time IE > > > > > > The time (as a SNMPv2 TimeStamp [1443]) associated with the > > > status/statistics observed or other events. > > > > > > 1.5 UTC Time IE > > > > > > The time in seconds since 00:00:00 UTC, January 1, 1970 > associated > > > with the status/statistics observed or other events. If > both Time > > > and UTC_TIME are present, UTC Time takes precedence. > > > > > > 1.6 Delta Time IE > > > > > > The number in 100ths of seconds over which the statistics were > > > observed. TYPE is 71 and format is: > > > > > > > > > 1.7 Class of Service IE > > > > > > The class of service associated with a flow. > > > > > > Class of Service Received > > > Class of Service Transmitted > > > > > > 1 - IPv4, CoS value is defined by ToS in RFC 791 > > > 2 - IPv6, CoS value is defined by Traffic Class in RFC 2460 > > > 3 - MPLS, CoS value is defined by Exp in RFC 3032 > > > 4 - VLAN, CoS value is defined by user_priority in IEEE > > > 802.1q[802.1q] and IEEE 802.1p[802.1p] > > > > > > [Can more than one Class of Service can be present??? PAC] > > > > > > > > > > > > 1.8 Source Exporter [ is that the right term?? PAC] Address IE > > > > > > Source Exporter address is the address of the Exporter > reporting > > > the flow, > > > Address is same as is as shown for Source Address. This > > > information is used by applications to later correlate the > > > ingress/egress port with a specific Exporter. It is > also used to > > > maintain the source Exporter information when there is an > > > intermediate > > > proxy. For example, given the picture below: > > > > > > SW1 -------- P1 ------ FAS1 > > > ^ > > > | > > > SW2---------- | > > > > > > Flows coming from SW1 and SW2 through proxy P1 would > look to the > > > Collector [ is this the rigth term??? PAC] like the > same Exporter > > > connection. With the Source Exporter in the message > the original > > > Exporter > > > address is maintained. > > > > > > > > > 1.9 Flow State IE > > > > > > Flow State is the intended End State for the Flow. > > > > > > Flow state has one of the following meanings: > > > > > > Flow is inactive > > > Flow is active > > > > > > 1.10 Byte Count IE > > > > > > Contains the count of octets sent and received > associated with the > > > identified flow. > > > > > > The byte count can be for bytes received (towards source) or > > > bytes sent (towards destination) or both (bi-directional > > > flow). > > > > > > The byte count can be a running counter and is the > > > count from the beginning of the flow establishment. > > > The byte count can be a delta counter and is the > > > count since the last report for this flow. > > > > > > > > > > > > 1.11 Packet Count IE > > > > > > Contains the count of packets sent and received > associated with the > > > identified flow. > > > > > > The packet count can be for packets received (towards source) or > > > packets sent (towards destination) or both > (bi-directional > > > flow). > > > > > > The packet count can be a running counter and is the > > > count from the beginning of the flow establishment. > > > The packet count can be a delta counter and is the > > > count since the last report for this flow. > > > > > > > > > 1.12 Protocol Identifier IE > > > > > > e.g. TCP/UDP [ need an RFC reference here. PAC] > > > > > > 1.13 Source Port IE > > > > > > This IE is used to report UDP source port [see RFC 768] or > > > TCP source port [see RFC 793]. > > > > > > 1.14 Destination Port IE > > > > > > This IE is used to report UDP destination port [see > RFC 768] or > > > TCP destination port [see RFC 793]. > > > > > > > > > 1.15 Source AS IE > > > > > > The Autonomous System (AS) numbers for the source address > > > associated with a flow. Autonomous System (AS) number > is defined by > > > RFC 1930 and RFC 1771 (BGP-4): > > > > > > > > > 1.16 Destination AS IE > > > > > > The Autonomous System (AS) numbers for the destination address > > > associated wit a flow. Autonomous System (AS) number > is defined by > > > RFC 1930 and RFC 1771 (BGP-4). > > > > > > > > > 1.17 Ingress Port IE > > > > > > The ingress ifIndex for the flow is provided in this > IE. ifIndex is > > > defined by RFC 2233. > > > > > > 1.18 Egress Port IE > > > > > > The egress ifIndex for the flow is provided in this > IE. ifIndex is > > > defined by RFC 2233. > > > > > > > > > 1.19 Egress ATM Subinterface > > > > > > The egress vpi/vci for the flow is provided in this > IE. vpi/vci id > > > defined by the ATM Forum UNI 3.1 specification: > > > > > > > > > > > > 1.20 EGRESS_FRAME_RELAY_SUBINTERFACE IE > > > > > > The egress DLCI for the flow is provided in this IE. ITU Q.922 > > > defines the DLCI range. The frDlcmiState is defined in > RFC 2115 and > > > defines the specific values of the DLCI. > > > > > > > > > > > > 1.21 NEXT_HOP_IP IE > > > > > > Address of the next hop. address is defined the same > as for Source > > > Address IE. > > > > > > 1.22 TCP Control Bits IE > > > > > > The TCP control bits seen for this flow. Note a 0 > value for each > > > bit only indicates that the flag was not detected > (i.e. it may have > > > occurred but was not detected by the reporting CCE). > TCP Control > > > Bits are defined by RFC 793. > > > > > > 1.23 Next Hop AS IE > > > > > > The Autonomous System (AS) numbers for the next hop > IP. Autonomous > > > System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). > > > > > > > > > > > > 1.24 Source Address Netmask IE > > > > > > The number of bits in the CIDR netmask, as defined in > RFC 1519, for > > > the source address. > > > > > > 1.25 Destination Address Netmask IE > > > > > > The CIDR netmask, as defined in RFC 1519, for the destination > > > address. > > > > > > > > > 1.26 Destination BGP Community IE > > > > > > The BGP community number for the destination address. > BGP community > > > number is defined by RFC 1997: > > > > > > > > > 1.27 Source BGP Community IE > > > > > > The BGP community number for the source address. > > > > > > > > > > > > 1.28 Source VLAN ID IE > > > > > > The Source VLAN ID associated with the flow. VLAN ID is > defined by > > > IEEE > > > standard 802.1q - 1998[802.1q]. > > > > > > [ Is this ultimate source VLAN or the source vlan of > the port where > > > the packet came in? Or do we need a way to represent > both? PAC] > > > > > > 1.29 Destination VLAN ID IE > > > > > > The destination VLAN ID associated with the flow. VLAN ID is > > > defined by IEEE > > > standard 802.1q - 1998[802.1q]. > > > > > > [ Is this ultimate destination VLAN or the destination > vlan of the > > > port where > > > the packet went out? Or do we need a way to represent > both? PAC] > > > > > > 1.30 Source Virtual Address IE > > > > > > An Exporter may be involved in redirecting flows. This > IE captures > > > information needed for proper accounting of redirected > flows. The > > > Source Virtual IE contains the source address of the flow as > > > transmitted by the Exporter. It is generally different > than the > > > source > > > address IE, which contains the address of the actual > source of the > > > message. > > > > > > A type field would contain the type of translation > performed on the > > > source address. The following types are currently available: > > > > > > 1 - NAT > > > 2 - LSNAT > > > 3 - Web Cache > > > > > > The address is defined the same as for Source Address. > > > > > > 1.31 Source Virtual Port IE > > > > > > A CCE may be involved in redirecting flows. This IE captures > > > information needed for proper accounting of redirected > flows. The > > > Source Virtual port IE contains the source port of the flow as > > > transmitted by the CCE. It may be different than the > source port > > > IE, which contains the port of the actual source of the flow. > > > An IP Protocol field is present and is defined by the > IP protocol > > > spec [RFC 791] (e.g. TCP/UDP). The fields indicates how to > > > interpret > > > the port value field. > > > > > > A type field contains the type of translation performed on the > > > source port. The following types are currently available: > > > > > > 1 - NAT > > > 2 - LSNAT > > > 3 - Web Cache > > > > > > > > > 1.32 Destination Virtual Address IE > > > > > > The Destination Virtual IE contains the destination > address of the > > > flow as received by the Exporter. It is generally > different than > > > the > > > destination port number, which contains the actual destination > > > address of the flow. > > > > > > > > > 1.33 Destination Virtual Port IE > > > > > > The Destination Virtual port IE contains the > destination port of > > > the flow as received by the Exporter. It may be > different than the > > > destination port recorded in the destination port, > which contains > > > the > > > actual destination port of the flow. > > > > > > > > > 1.34 Vendor Specific IE > > > > > > Vendors may add their own information to the protocol. > Information > > > contained in this IE is vendor specific. OID and OID Value is > > > defined by ITU X.680.X683 (1997) and is encoded as > defined by ITU > > > X.690.691(1997). This IE MUST not contain any information which > > > cannot be safely ignored by the Exporter or Collector. > If multiple > > > Vendor > > > Specific IE's with the same OID occur, then the vendor defines > > > semantics of ordering. > > > > > > > > > 1.35 Flow Label IE > > > > > > The Flow Label IE contains the IPV6 Flow Label information as > > > defined by RFC 2460. > > > > > > 1.36 Fragment ID IE > > > > > > The fragment ID associated with the flow. RFC 791 and RFC 2460 > > > define fragment ID. > > > > > > -- > > > 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/ > > > > > > > > -- > 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/ > > -- 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 Feb 11 21:00:31 2002 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 VAA21861 for ; Mon, 11 Feb 2002 21:00:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aRvv-0006Av-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 19:40:35 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aRvs-00069y-00 for ipfix-req@net.doit.wisc.edu; Mon, 11 Feb 2002 19:40:32 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C1dqW20366; Mon, 11 Feb 2002 19:39:52 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXAT5>; Mon, 11 Feb 2002 17:39:50 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982B42@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Benoit Claise , ipfix-req@net.doit.wisc.edu, quittek@ccrle.nec.de Subject: RE: [ipfix-req] Re: [ipfix] Terminology suggestion Date: Mon, 11 Feb 2002 17:39:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B366.26CBC890" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B366.26CBC890 Content-Type: text/plain; charset="iso-8859-1" comments inline... :-----Original Message----- :From: Benoit Claise [mailto:bclaise@cisco.com] :Sent: Monday, February 11, 2002 7:30 AM :To: ipfix-req@net.doit.wisc.edu; quittek@ccrle.nec.de :Subject: [ipfix-req] Re: [ipfix] Terminology suggestion : : : :Note: we had to introduce the concept of observation domain. : : * Observation Domain: The set of observation points which is the : largest aggregatable set of flow information at the exporter is : termed as an observation domain. The observation domain presents : itself a unique ID to the collector for identifying the export : packets generated by it. : : Example: The observation domian could be a router linecard, : composed of several interfaces with each interface being an : observation point. : :Why the concept of observation domain? :Typically for a linecard on a router, which is an independant entity. :So an exporter can be composed of several observation domains :(read linecards). I agree with this. :There is one metering process per observation domain (read linecard). :You can do flow aggregations for these linecard flows but not :between flows from different linecards. : okay...So this means that if a flow comes into a linecard, gets metered/exported, goes out to the other linecard, it can be metered and exported again, right (assuming linecard have their own rules)? regards, Reinaldo ------_=_NextPart_001_01C1B366.26CBC890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-req] Re: [ipfix] Terminology suggestion

comments inline...

:-----Original Message-----
:From: Benoit Claise [mailto:bclaise@cisco.com]
:Sent: Monday, February 11, 2002 7:30 AM
:To: ipfix-req@net.doit.wisc.edu; = quittek@ccrle.nec.de
:Subject: [ipfix-req] Re: [ipfix] Terminology = suggestion
:
:
:
:Note: we had to introduce the concept of = observation domain.
:
:     * Observation Domain: The = set of observation points which is the
:       largest = aggregatable set of flow information at the exporter is
:       termed as an = observation domain. The observation domain presents
:       itself a = unique ID to the collector for identifying the export
:       packets = generated by it.
:
:       Example: The = observation domian could be a router linecard,
:       composed of = several interfaces with each interface being an
:       observation = point.
:
:Why the concept of observation domain?
:Typically for a linecard on a router, which is an = independant entity.
:So an exporter can be composed of several = observation domains
:(read linecards).

I agree with this. 

:There is one metering process per observation domain = (read linecard).
:You can do flow aggregations for these linecard = flows but not
:between flows from different linecards.
:

okay...So this means that if a flow comes into a = linecard, gets metered/exported, goes out to the other linecard, it can = be metered and exported again, right (assuming linecard have their own = rules)?

regards,

Reinaldo
 

------_=_NextPart_001_01C1B366.26CBC890-- -- 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 Feb 11 21:23:39 2002 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 VAA22066 for ; Mon, 11 Feb 2002 21:23:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aSJV-0006hj-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 20:04:57 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aSJT-0006h8-00 for ipfix-req@net.doit.wisc.edu; Mon, 11 Feb 2002 20:04:55 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1C24Oh24760; Mon, 11 Feb 2002 18:04:24 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABD93275; Mon, 11 Feb 2002 18:04:46 -0800 (PST) Message-ID: <3C687A3C.618D0F41@cisco.com> Date: Mon, 11 Feb 2002 18:13:17 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: quittek@ccrle.nec.de CC: Benoit Claise , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Re: [ipfix] Terminology suggestion References: <200202111529.g1BFTnb27134@bru-cse-222.cisco.com> <1013472201.3c685bc97479f@citadel.mobility.ccrle.nec.de> Content-Type: multipart/alternative; boundary="------------45DF3413E92DF5EEBCD462D9" Precedence: bulk Sender: majordomo listserver --------------45DF3413E92DF5EEBCD462D9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jurgene, Some comments. quittek@ccrle.nec.de wrote: > Hi Benoit, > > Benoit Claise wrote: > > > Hi Juergen, > > > > Here are my input on this terminology, as promised during the conf. > > call. > > > > Note that whether the definitions go into the requirements draft or in > > the architecture doesn't make any difference to me. This only thing of > > importance is that, if the requirement draft dissapears with the time, > > we don't want to loose the defintions. One solution is that the > > architecture document will have to repeat the definitions. > > > > > > > > see draft-ietf-ipfix-reqs-00.txt, section 1.1 > > > > I just copied the definition from draft-ietf-ipfix-reqs-00.txt for > > completeness. > > A flow is a set of packets passing an observation point in the > > network during a certain time interval. All packets belonging to a > > particular flow have a set of common properties derived from the > > data contained in the packet and from the packet treatment at the > > observation point. > > > > I would go a little bit further in the definition, by describing what a > > property coul be: > > A flow is defined as a set of packets passing an observation point in the > > network during a certain time interval. All packets belonging to a > > particular flow have a set of common properties. Each property is > > defined as the result of applying a function to the values of: > > > > a. one or more of packet header fields (eg. destination IP address) > > b. one or more properties of the packet itself (eg. packet length) > > c. one or more of fields derived from packet treatment (eg. AS > > number) > > > > A packet is defined to belong to a flow if it matches all the defined > > properties of the flow. > > Fine. But we should mention somewhere that also partial matches might be > sufficient. The parial matches are covered when we say "as the result of applying a function to the values of:". > > > > > > > > 2.2. Observation Point > > > The observation point is a location in the network where IP packets > > > can be observed. Examples are a line to which a probe is attached, > > > a shared medium, such as an Ethernet-based LAN, a port of a router, > > > or an entire router with several ports. > > > > I agree with the definition above, but I would be more specific: > > The observation point is a location in the network where IP packets > > can be observed. Examples are a line to which a probe is attached, > > a shared medium, such as an Ethernet-based LAN, a port of a router, > > or an entire router with several ports. The observation is characterized > > by one or a set of interfaces (physical or logical) of the exporter. > > I think the last sentence is too restrictive. Why excluding packet > samplers sending samples from a remote observation point to a meter? I do not understand this. Can you elaborate? > > > > Note: the exporter is defined below. > > > > > > 2.3. Trafic Flow Meter or Meter > > > A meter observes packets at one or more observation points. > > > It analyzes the content of the packets and maps them to flows. > > > For each observed flow the meter computes statistics and maintains > > > a flow record where it stores relevant flow infromation. > > > > I think that the concept of exporter makes more sense. > > And I believe that you are mixing 2 definitions: > > No, it's just the opposite: I want to separate meter and exporter. > > > - the exporter (ex: a router or a probe) > > - the metering process which analyzes the traffic > > So I would just remove this definition and leave the exporter/metering > > process > > as 2 definitions. > > > > * Exporter: The entity on which flows are measured and are > > exported. The exporter can be a router, a middlebox [2], or a > > traffic measurement probe. > > Here you are mixing metering and exporting. > > I see two function blocks in our architecture: The meter executing the > metering process and the exporter participating as sender in the flow > information export process. > > > > > > > > 2.4. Metering Process > > > The metering process includes all actions performed by a meter > > > with respect to observing packets, timestamping them, analyzing them, > > > mapping them to flows, computing flow statistics, detecting flow > > > expiration, and maintaining flow records. > > > > Measurement process that is carried out at the observation domain. > > The metering process includes all actions performed by a meter > > with respect to observing packets, timestamping them, analyzing them, > > mapping them to flows, computing flow statistics, detecting flow > > expiration, and maintaining flow records. > > > > Note: we had to introduce the concept of observation domain. > > > > * Observation Domain: The set of observation points which is the > > largest aggregatable set of flow information at the exporter is > > termed as an observation domain. The observation domain presents > > itself a unique ID to the collector for identifying the export > > packets generated by it. > > > > Example: The observation domian could be a router linecard, > > composed of several interfaces with each interface being an > > observation point. > > > > Why the concept of observation domain? > > Typically for a linecard on a router, which is an independant entity. > > So an exporter can be composed of several observation domains (read > > linecards). > > There is one metering process per observation domain (read linecard). > > You can do flow aggregations for these linecard flows but not between > > flows from different linecards. > > Well you are approaching my hierarchy: > exporter - meter - observation point > > The meter processes (and aggregates) packets from one or more > observation points and generates flow records. The sum of its > observation points outlines your observation domain. > The exporter exports flow records produced by one or more meters. I guess there is some confusion. The observation domain could do some level of metering. But metering itself is independent of an observation domain. If I draw a picture of the inetntion of observation domain, it would look like: +---------------------------------------------------------------------+ | Observation Domain | | +------+ +------+ | | |Meter1| .... |MeterM| (Perform packet | | +------+ +------+ metering) | | ^ ^ | | | | | | +-------+--------+ +-------+--------+ | | | | | | | | v v v v | | +------------+ +------------+ +------------+ +-------------+| | |Obsv Point11 |..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn || | +------------+ +------------+ +------------+ +-------------+| +---------------------------------------------------------------------+ ^ ^ | | v v +----------+ +----------+ |Meter (O1)| .... |Meter (OP)| (Perform flow metering etc). +----------+ +----------+ | | +-------+--------+ | v +---------------+ | exporter | +---------------+ Another point to note is that in draft-gsadasiv-ipfix-proposal-00.txt, we have made meter to observation point 1 to 1. Though theoritically what is drawn above looks fine, I have a little difficulty in understanding when this would be the case. > > > First you say is "delete the term of meter" and then > "add the term of observation domain", because now we need it. > > If you just keep the meter, you do not need the observation > domain and you have an concept which is easier to understand > and which also matches the function blocks of the architecture. > > > Note: I agree that we are missing a high level picture of this in > > draft-gsadasiv-ipfix-proposal-00.txt > > > > > > > > 2.5. Flow Record > > > A flow record keeps information a flow including characteristic > > > properties of the flow, for example the source IP address, > > > and measured properties of the flow, for example the total number > > > of bytes of all packets of the flow. > > > > All packets belonging to a particular flow have a set of common > > properties. > > But the flow record doesn't necessarily have the notion of its own > > properties. > > I would remove the properties part. > > Here is the definition I would propose. > > > > * Flow Record: A flow record provides information about a specific > > flow that was measured at an observation point using a certain > > set of methods within an exporter. > > > > > > 2.6. Flow Information Exporter or Exporter > > > The exporter sends flow records created and maintained by one or > > > more meters to one or more data collectors. > > > > See my previous remark about exporter versus meter > > dito > > > > > > > 2.7. Flow Information Data Collector or Data Collector > > > The data collector receives flow records from one or more exporters. > > > The data collector might process or store received flow record, > > > but these actions are out of the scope of this document. > > > > OK. We called it just collector. But this is just a detail! > > Fine. What about the heading "Flow Information Collector or Collector" > and then renaming all data collectors into collectors? > > Best wishes, > > Juergen > > > > > Regards, Benoit. > > > > > > > > > > 2.8. Flow Information Export > > > Flow information export denotes the process of transferring flow > > > records from an exporter to a data collector. > > > > > > > > > -- > > > 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/ > > > > > > > > > -- > 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/ --------------45DF3413E92DF5EEBCD462D9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jurgene,
  Some comments.

quittek@ccrle.nec.de wrote:

Hi Benoit,

Benoit Claise <bclaise@cisco.com> wrote:

> Hi Juergen,
>
> Here are my input on this terminology, as promised during the conf.
> call.
>
> Note that whether the definitions go into the requirements draft or in
> the architecture doesn't make any difference to me. This only thing of
> importance is that, if the requirement draft dissapears with the time,
> we don't want to loose the defintions. One solution is that the
> architecture document will have to repeat the definitions.
>
> >
> > see draft-ietf-ipfix-reqs-00.txt, section 1.1
>
> I just copied the definition from draft-ietf-ipfix-reqs-00.txt for
> completeness.
>       A flow is a set of packets passing an observation point in the
>       network during a certain time interval. All packets belonging to a
>       particular flow have a set of common properties derived from the
>       data contained in the packet and from the packet treatment at the
>       observation point.
>
> I would go a little bit further in the definition, by describing what a
> property coul be:
>    A flow is defined as a set of packets passing an observation point in the
>    network during a certain time interval. All packets belonging to a
>    particular flow have a set of common properties.  Each property is
>    defined as the result of applying a function to the values of:
>
>      a. one or more of packet header fields (eg. destination IP address)
>      b. one or more properties of the packet itself (eg. packet length)
>      c. one or more of fields derived from packet treatment (eg. AS
>         number)
>
>    A packet is defined to belong to a flow if it matches all the defined
>    properties of the flow.

Fine. But we should mention somewhere that also partial matches might be
sufficient.

The parial matches are covered when we say  "as the result of applying a function
to the values of:".
 

> >
> > 2.2.   Observation Point
> > The observation point is a location in the network where IP packets
> > can be observed.  Examples are a line to which a probe is attached,
> > a shared medium, such as an Ethernet-based LAN,  a port of a router,
> > or an entire router with several ports.
>
> I agree with the definition above, but I would be more specific:
> The observation point is a location in the network where IP packets
> can be observed.  Examples are a line to which a probe is attached,
> a shared medium, such as an Ethernet-based LAN, a port of a router,
> or an entire router with several ports. The observation is characterized
> by one or a set of interfaces (physical or logical) of the exporter.

I think the last sentence is too restrictive. Why excluding packet
samplers sending samples from a remote observation point to a meter?

I do not understand this. Can you elaborate?
 

> Note: the exporter is defined below.
> >
> > 2.3.   Trafic Flow Meter or Meter
> > A  meter observes packets at one or more observation points.
> > It analyzes the content of the packets and maps them to flows.
> > For each observed flow the meter computes statistics and maintains
> > a flow record where it stores relevant flow infromation.
>
> I think that the concept of exporter makes more sense.
> And I believe that you are mixing 2 definitions:

No, it's just the opposite: I want to separate meter and exporter.

> - the exporter (ex: a router or a probe)
> - the metering process which analyzes the traffic
> So I would just remove this definition and leave the exporter/metering
> process
> as 2 definitions.
>
>      * Exporter: The entity on which flows are measured and are
>        exported. The exporter can be a router, a middlebox [2], or a
>        traffic measurement probe.

Here you are mixing metering and exporting.

I see two function blocks in our architecture: The meter executing the
metering process and the exporter participating as sender in the flow
information export process.

 

> >
> > 2.4.   Metering Process
> > The metering process includes all actions performed by a meter
> > with respect to observing packets, timestamping them, analyzing them,
> > mapping them to flows, computing flow statistics, detecting flow
> > expiration, and maintaining flow records.
>
> Measurement process that is carried out at the observation domain.
> The metering process includes all actions performed by a meter
> with respect to observing packets, timestamping them, analyzing them,
> mapping them to flows, computing flow statistics, detecting flow
> expiration, and maintaining flow records.
>
> Note: we had to introduce the concept of observation domain.
>
>      * Observation Domain: The set of observation points which is the
>        largest aggregatable set of flow information at the exporter is
>        termed as an observation domain. The observation domain presents
>        itself a unique ID to the collector for identifying the export
>        packets generated by it.
>
>        Example: The observation domian could be a router linecard,
>        composed of several interfaces with each interface being an
>        observation point.
>
> Why the concept of observation domain?
> Typically for a linecard on a router, which is an independant entity.
> So an exporter can be composed of several observation domains (read
> linecards).
> There is one metering process per observation domain (read linecard).
> You can do flow aggregations for these linecard flows but not between
> flows from different linecards.

Well you are approaching my hierarchy:
exporter - meter - observation point

The meter processes (and aggregates) packets from one or more
observation points and generates flow records. The sum of its
observation points outlines your observation domain.
The exporter exports flow records produced by one or more meters.

I guess there is some confusion. The observation domain could
do some level of metering.
But metering itself is independent of an observation domain.
If I draw a picture of the inetntion of observation domain,
it would look like:

+---------------------------------------------------------------------+
|                    Observation Domain                               |
|          +------+                          +------+                 |
|          |Meter1|          ....            |MeterM| (Perform packet |
|          +------+                          +------+  metering)      |
|              ^                                  ^                   |
|              |                                  |                   |
|      +-------+--------+                 +-------+--------+          |
|      |                |                 |                |          |
|      v                v                 v                v          |
| +------------+   +------------+     +------------+   +-------------+|
| |Obsv Point11 |..|Obsv Point1k|     |Obsv PointM1|.. |Obsv PointMn ||
| +------------+   +------------+     +------------+   +-------------+|
+---------------------------------------------------------------------+
          ^                     ^
          |                     |
          v                     v
          +----------+          +----------+
     |Meter (O1)|   ....   |Meter (OP)| (Perform flow metering etc).
     +----------+          +----------+
              |                |
              +-------+--------+
                      |
                      v
               +---------------+
               |  exporter     |
               +---------------+

Another point to note is that in draft-gsadasiv-ipfix-proposal-00.txt,
we have made meter to observation point 1 to 1. Though theoritically
what is drawn above looks fine, I have a little difficulty in
understanding when this would be the case.

 

First you say is "delete the term of meter" and then
"add the term of observation domain", because now we need it.

If you just keep the meter, you do not need the observation
domain and you have an concept which is easier to understand
and which also matches the function blocks of the architecture.

> Note: I agree that we are missing a high level picture of this in
> draft-gsadasiv-ipfix-proposal-00.txt
>
> >
> > 2.5.   Flow Record
> > A flow record keeps information a flow including characteristic
> > properties of the flow, for example the source IP address,
> > and measured properties of the flow, for example the total number
> > of bytes of all packets of the flow.
>
> All packets belonging to a particular flow have a set of common
> properties.
> But the flow record doesn't necessarily have the notion of its own
> properties.
> I would remove the properties part.
> Here is the definition I would propose.
>
>      * Flow Record: A flow record provides information about a specific
>        flow that was measured at an observation point using a certain
>        set of methods within an exporter.
> >
> > 2.6.   Flow Information Exporter or Exporter
> > The exporter sends flow records created and maintained by one or
> > more meters to one or more data collectors.
>
> See my previous remark about exporter versus meter

dito

> >
> > 2.7.  Flow Information Data Collector or Data Collector
> > The data collector receives flow records from one or more exporters.
> > The data collector might process or store received flow record,
> > but these actions are out of the scope of this document.
>
> OK. We called it just collector. But this is just a detail!

Fine. What about the heading "Flow Information Collector or Collector"
and then renaming all data collectors into collectors?

Best wishes,

    Juergen

>
> Regards, Benoit.
>
>
> >
> > 2.8.   Flow Information Export
> > Flow information export denotes the process of transferring flow
> > records from an exporter to a data collector.
> >
> >
> > --
> > 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/
> >
>
>

--
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/

--------------45DF3413E92DF5EEBCD462D9-- -- 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 Feb 11 21:23:52 2002 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 VAA22078 for ; Mon, 11 Feb 2002 21:23:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aSMF-0006lq-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 20:07:47 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aSMC-0006lD-00; Mon, 11 Feb 2002 20:07:44 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C275W23997; Mon, 11 Feb 2002 20:07:05 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXAYS>; Mon, 11 Feb 2002 18:07:04 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982B59@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , ipfix-arch@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu Subject: RE: middlebox issues (was: [ipfix-arch] Answer to the recent comm ents on the Architecture Draft) Date: Mon, 11 Feb 2002 18:06:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B369.F3F40C80" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B369.F3F40C80 Content-Type: text/plain; charset="iso-8859-1" Juergen, comments inline. :-----Original Message----- :From: Juergen Quittek [mailto:quittek@ccrle.nec.de] :Sent: Monday, February 11, 2002 3:18 AM :To: Penno, Reinaldo [SC9:T327:EXCH]; ipfix-arch@net.doit.wisc.edu; :ipfix-arch-volunteers@net.doit.wisc.edu :Subject: middlebox issues (was: [ipfix-arch] Answer to the recent :comments on the Architecture Draft) : : :> As far the text book statement, I disagree. Some people :> confuse technical writing with bad writing. I think that :> providing a small introductory section and associated reference :> is a good writing practice. Of course , you feel free to disagree. : :Thank you for allowing me to disagree. I just mentioned text books, :because it should explain the difference. Writing a good text book :need good writing skills as well as writing good standards :documents. However, the goals of both kinds of documentd are :different. : :In standard documents you wat to have a clear and unambigous :definiton or description of technical issues. Now, if we are :writing a standard document concerning flow information export :we should definitely explain in detail what is a flow what :is the metering process and the export process. : :However, when we talk about NATs in our document, we should not :try to define them again, but rather refer to another document :containing a definition agreed on by NAT experts. In this case :RFC 2663 would serve well. Otherwise we risk to create :ambiguities by having differences in the two definitions. right, but in the NAT section would say it would be good to write only "refer to RFC2663"? I put only one paragraph, I will try to shorten it. : :May be the three lines I suggested are too generic, but I do :not see a reason yet, why we have to distinguish dropping :on a firewall, drooping on a router, dropping at a traffic :shaper, ... : I would say that dropping on a firewall is a administrative dropping. It's different , for instance , from when you drop fragmented TCP/UDP packets when running NAPT. The same goes for policing and shaping respectively. There is a good discussion on this idea in http://community.roxen.com/developers/idocs/drafts/draft-iab-nat-implication s-09.html. http://community.roxen.com/developers/idocs/drafts/draft-iab-unsaf-considera tions-01.html :> :> Same as above, this is too generic (specially in the case NAT). :> I think we should set a minimum set of architectural considerations :> when dealing with NAT. For instance, that is composed of two flows, :> that in the case of twice NAT you should/must export both flows :> (private and public) or otherwise notify the collector, etc, etc : :So you consider these to be two flows? Why then having the extra :fields you call virtual address, virtual port, etc, if you anyway :report two different flows? Just a reference to the other flow :would be fine. I debated this issue before. If the definition of one flow is a 5-tuple, then NAT is by definition composed of two flows. Now, you can report the two flows separate or in the same flow record. Reporting them separte means providing something to bind them. Toughts? : :I think we would go very well with a generic coverage of all :middleboxes modifying packet headers (other than TTL). Particularly, :after you already suggested that the modified field contains :a tag indicating the reason for modification (NAT, DSCP marking, ...). : What about OPES? Should we say that in the case an OPES service in running on the same box the number of packets in the flow MUST be exported? See http://community.roxen.com/developers/idocs/drafts/draft-iab-opes-01.html :> : : :I still would remove these sections, but I do not insist in all the :cuts I suggested. So let's go on and try to get more text Again, I can shorten them and just make a reference. :> :> :> : :> :Section 6.4.5.1.1. makes a good point in requesting an IE for :> :the VPN-ID. However, the statement "MUST include VPN-ID in the :> :exported flow record" is too strong. We may require that it :> :MUST be able to do so, but the user should be free o configure :> :export such that VPN-ID is not exported. :> :> Can you elaborate on why not exporting this? : :I did not say "forbid export", but just "not require export :all times". Users should be able to select and configure :themselves what fields to be exported. okay..But I guess the information would be useless. It the same case as twice NAT. thanks for the comments, Reinaldo ------_=_NextPart_001_01C1B369.F3F40C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: middlebox issues (was: [ipfix-arch] Answer to the recent = comments on the Architecture Draft)

Juergen,

comments inline.

:-----Original Message-----
:From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
:Sent: Monday, February 11, 2002 3:18 AM
:To: Penno, Reinaldo [SC9:T327:EXCH]; = ipfix-arch@net.doit.wisc.edu;
:ipfix-arch-volunteers@net.doit.wisc.edu
:Subject: middlebox issues (was: [ipfix-arch] Answer = to the recent
:comments on the Architecture Draft)
:
:
:> As far the text book statement, I disagree. = Some people
:> confuse technical writing with bad writing. I = think that
:> providing a small introductory section and = associated reference
:> is a good writing practice. Of course , you = feel free to disagree.
:
:Thank you for allowing me to disagree. I just = mentioned text books,
:because it should explain the difference. Writing a = good text book
:need good writing skills as well as writing good = standards
:documents. However, the goals of both kinds of = documentd are
:different.
:
:In standard documents you wat to have a clear and = unambigous
:definiton or description of technical issues. Now, = if we are
:writing a standard document concerning flow = information export
:we should definitely explain in detail what is a = flow what
:is the metering process and the export = process.
:
:However, when we talk about NATs in our document, = we should not
:try to define them again, but rather refer to = another document
:containing a definition agreed on by NAT experts. = In this case
:RFC 2663 would serve well. Otherwise we risk to = create
:ambiguities by having differences in the two = definitions.

right, but in the NAT section would say it would be = good to write only "refer to RFC2663"? I put only one = paragraph, I will try to shorten it.

:
:May be the three lines I suggested are too generic, = but I do
:not see a reason yet, why we have to distinguish = dropping
:on a firewall, drooping on a router, dropping at a = traffic
:shaper, ...
:

I would say that dropping on a firewall is a = administrative dropping. It's different , for instance , from when you = drop fragmented TCP/UDP packets when running NAPT. The same goes for = policing and shaping respectively. There is a good discussion on this = idea in

http://community.roxen.com/developers/idocs/drafts/dra= ft-iab-nat-implications-09.html.
http://community.roxen.com/developers/idocs/drafts/dra= ft-iab-unsaf-considerations-01.html


:>
:> Same as above, this is too generic (specially = in the case NAT).
:> I think we should set a minimum set of = architectural considerations
:> when dealing with NAT. For instance, that is = composed of two flows,
:> that in the case of twice NAT you should/must = export both flows
:> (private and public) or otherwise notify the = collector, etc, etc
:
:So you consider these to be two flows? Why then = having the extra
:fields you call virtual address, virtual port, etc, = if you anyway
:report two different flows? Just a reference to the = other flow
:would be fine.

I debated this issue before. If the definition of one = flow is a 5-tuple, then NAT is by definition composed of two flows. = Now, you can report the two flows separate or in the same flow record. = Reporting them separte means providing something to bind = them.

Toughts?

:
:I think we would go very well with a generic = coverage of all
:middleboxes modifying packet headers (other than = TTL). Particularly,
:after you already suggested that the modified field = contains
:a tag indicating the reason for modification (NAT, = DSCP marking, ...).
:

What about OPES? Should we say that in the case an = OPES service in running on the same box the number of packets in the = flow MUST be exported?

See http://community.roxen.com/developers/idocs/drafts/dra= ft-iab-opes-01.html

:>
:
:
:I still would remove these sections, but I do not = insist in all the
:cuts I suggested. So let's go on and try to get = more text

Again, I can shorten them and just make a = reference.

:>
:>
:> :
:> :Section 6.4.5.1.1. makes a good point in = requesting an IE for
:> :the VPN-ID. However, the statement "MUST = include VPN-ID in the
:> :exported flow record" is too strong. We = may require that it
:> :MUST be able to do so, but the user should be = free o configure
:> :export such that VPN-ID is not = exported.
:>
:> Can you elaborate on why not exporting = this?
:
:I did not say "forbid export", but just = "not require export
:all times". Users should be able to select and = configure
:themselves what fields to be exported.

okay..But I guess the information would be useless. = It the same case as twice NAT.

thanks for the comments,

Reinaldo

------_=_NextPart_001_01C1B369.F3F40C80-- -- 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 Feb 11 23:47:35 2002 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 XAA25797 for ; Mon, 11 Feb 2002 23:47:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aUTV-000240-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 22:23:25 -0600 Received: from c001-h000.c001.snv.cp.net ([209.228.32.114] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16aUTT-00022q-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 22:23:23 -0600 Received: (cpmta 12228 invoked from network); 11 Feb 2002 20:22:50 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.114) with SMTP; 11 Feb 2002 20:22:50 -0800 X-Sent: 12 Feb 2002 04:22:50 GMT Message-ID: <012201c1b37d$4b5610a0$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: , References: Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Mon, 11 Feb 2002 21:25:23 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011F_01C1B342.9DD240A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_011F_01C1B342.9DD240A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture DraftWill, I agree. Let's go for the wg concensus. What do people say? | - the exporter configuration is out of the scope of this document = (the exporter configuration out of band) Configuration I think is out of scope, unless we hook it to an existing = mib or something. I so, we can refer to that mib or process. |- no transport negotiation (which transport) we need to define the action of each transport type. | - no capability negotiation Nice, but necessary? K.C. ----- Original Message -----=20 From: Will Eatherton=20 To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu ; = ipfix-arch-volunteers@net.doit.wisc.edu=20 Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; = plonka@doit.wisc.edu=20 Sent: Monday, February 11, 2002 8:24 AM Subject: Scope of IPFIX (was Answer to the recent comments on the = Architecture Draft) Group, =20 Cisco's interest in IPFIX was to help establish a non-proprietary = protocol similar to netflow but more flexible allowing us to add value = to our customers (and do so in a timely manner). If IPFIX goes down a = path along the lines as being advocated recent threads by Reinaldo, it = is unclear if the added burden of the protocol will be make it worth the = benefits of a non-proprietary protocol. Given it seems I have seen = roughly the same conversation occur 3 times in past several day, It is = unclear if further email discussion on this topic will resolve the = underlying question as to the scope of IPFIX. It seems time for an = official call on what is in/out of scope for IPFIX. As has been = mentioned here multiple times we would like to hear : =20 - the exporter configuration is out of the scope of this document = (the exporter configuration out of band) - no transport negotiation (which transport) - no capability negotiation Will :So lets have a protocol which is more flexible as NetFlow version=20 :1-7,=20 I will not comment on that too much...Basically we are not here to = reverse-engineer Netflow, but to incorporate some good ideas from it. :but not much more complicated, in order to be successfully=20 :accepted by hardware vendors and application programmers.=20 ohh, please...Then Netflow is just right?=20 Reinaldo=20 ------=_NextPart_000_011F_01C1B342.9DD240A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture = Draft
Will,
 
I agree. Let's go=20 for the wg concensus.  What do people say?
 
| - the exporter=20 configuration is out of the scope of this document   (the exporter configuration out of=20 band)
 
Configuration I=20 think is out of scope, unless we hook it to an existing mib or = something. =20 I so, we can refer to that mib or process.

|- no transport = negotiation (which=20 transport)

we need to define the action of each = transport=20 type.

| - no capability=20 negotiation

Nice, but necessary?

 
K.C.
----- Original Message -----
From:=20 Will = Eatherton
To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu = ; ipfix-arch-volunteers@net= .doit.wisc.edu=20
Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; plonka@doit.wisc.edu
Sent: Monday, February 11, 2002 = 8:24=20 AM
Subject: Scope of IPFIX (was = Answer to=20 the recent comments on the Architecture Draft)

Group,
 
Cisco's interest in IPFIX  was to help = establish=20 a non-proprietary protocol similar to netflow but more flexible = allowing=20 us to add value to our customers (and do so in a timely=20 manner).  If IPFIX goes down a path along the lines as = being=20 advocated recent threads by Reinaldo,  it is unclear if the = added=20 burden of the protocol will be make it worth the benefits of a = non-proprietary=20 protocol.  Given it seems I have seen roughly the same = conversation=20 occur 3 times in past several day, It is unclear if further email = discussion=20 on this topic will resolve the underlying question as to the scope of=20 IPFIX.  It seems time for an official call on what = is=20 in/out of scope for IPFIX.  As has been mentioned here = multiple=20 times we would like to hear :  

- the exporter = configuration is out=20 of the scope of this document =20  (the exporter configuration out of band)

- no transport = negotiation (which=20 transport)

 - no capability=20 negotiation

Will

:So lets have a protocol which is more flexible as = NetFlow=20 version
:1-7,

I will not comment on that too much...Basically we = are not=20 here to reverse-engineer Netflow, but to incorporate some good ideas = from=20 it.

:but not much more complicated, in order to be=20 successfully
:accepted by hardware vendors = and=20 application programmers.

ohh, please...Then Netflow is just right? =

Reinaldo=20






------=_NextPart_000_011F_01C1B342.9DD240A0-- -- 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 Tue Feb 12 00:19:41 2002 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 AAA26130 for ; Tue, 12 Feb 2002 00:19:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aV0y-0002jU-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 22:58:00 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aV0w-0002ix-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 22:57:58 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C4vDW02925; Mon, 11 Feb 2002 22:57:14 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXBTF>; Mon, 11 Feb 2002 20:57:12 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982BA6@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "K.C. Norseth" , will@cisco.com, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Mon, 11 Feb 2002 20:57:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B381.B8B642B0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B381.B8B642B0 Content-Type: text/plain; charset="iso-8859-1" Hello Norseth, I think the right question to answer is not if it is "necessary", since you can always pay somebody to be some sort of CLI configuration master and do everything by hand. I think the right question is if it should be on the architecture document or not and with whihch level of compliance. I think it should be on the arch document and maybe putting it with a SHOULD instead of a MUST will make (most) people happy. cheers, Reinaldo -----Original Message----- From: K.C. Norseth [mailto:kcn@norseth.com] Sent: Monday, February 11, 2002 8:25 PM To: will@cisco.com; ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Will, I agree. Let's go for the wg concensus. What do people say? | - the exporter configuration is out of the scope of this document (the exporter configuration out of band) Configuration I think is out of scope, unless we hook it to an existing mib or something. I so, we can refer to that mib or process. |- no transport negotiation (which transport) we need to define the action of each transport type. | - no capability negotiation Nice, but necessary? K.C. ----- Original Message ----- From: Will Eatherton To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu ; ipfix-arch-volunteers@net.doit.wisc.edu Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; plonka@doit.wisc.edu Sent: Monday, February 11, 2002 8:24 AM Subject: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Group, Cisco's interest in IPFIX was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner). If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo, it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol. Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX. It seems time for an official call on what is in/out of scope for IPFIX. As has been mentioned here multiple times we would like to hear : - the exporter configuration is out of the scope of this document (the exporter configuration out of band) - no transport negotiation (which transport) - no capability negotiation Will :So lets have a protocol which is more flexible as NetFlow version :1-7, I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it. :but not much more complicated, in order to be successfully :accepted by hardware vendors and application programmers. ohh, please...Then Netflow is just right? Reinaldo ------_=_NextPart_001_01C1B381.B8B642B0 Content-Type: text/html; charset="iso-8859-1" Answer to the recent comments on the Architecture Draft
Hello Norseth,
 
I think the right question to answer is not if it is "necessary", since you can always pay somebody to be some sort of CLI configuration master and do everything by hand.  
I think the right question is if it should be on the architecture document or not and with whihch level of compliance.
 
I think it should be on the arch document and maybe putting it with a SHOULD instead of a MUST will make (most) people happy.
 
cheers,
 
Reinaldo
 
 
 -----Original Message-----
From: K.C. Norseth [mailto:kcn@norseth.com]
Sent: Monday, February 11, 2002 8:25 PM
To: will@cisco.com; ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Will,
 
I agree. Let's go for the wg concensus.  What do people say?
 
| - the exporter configuration is out of the scope of this document   (the exporter configuration out of band)
 
Configuration I think is out of scope, unless we hook it to an existing mib or something.  I so, we can refer to that mib or process.

|- no transport negotiation (which transport)

we need to define the action of each transport type.

| - no capability negotiation

Nice, but necessary?  

 
K.C.
----- Original Message -----
Sent: Monday, February 11, 2002 8:24 AM
Subject: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Group,
 
Cisco's interest in IPFIX  was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner).  If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo,  it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol.  Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX.  It seems time for an official call on what is in/out of scope for IPFIX.  As has been mentioned here multiple times we would like to hear :  

- the exporter configuration is out of the scope of this document   (the exporter configuration out of band)

- no transport negotiation (which transport)

 - no capability negotiation

Will

:So lets have a protocol which is more flexible as NetFlow version
:1-7,

I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it.

:but not much more complicated, in order to be successfully
:accepted by hardware vendors and application programmers.

ohh, please...Then Netflow is just right?

Reinaldo






------_=_NextPart_001_01C1B381.B8B642B0-- -- 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 Tue Feb 12 00:27:11 2002 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 AAA26513 for ; Tue, 12 Feb 2002 00:27:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aVC3-0002wj-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 23:09:27 -0600 Received: from c001-h007.c001.snv.cp.net ([209.228.32.121] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16aVC1-0002wB-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 23:09:25 -0600 Received: (cpmta 26528 invoked from network); 11 Feb 2002 21:08:52 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.121) with SMTP; 11 Feb 2002 21:08:52 -0800 X-Sent: 12 Feb 2002 05:08:52 GMT Message-ID: <013901c1b383$b969f060$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: "Reinaldo Penno" , , References: <4F973E944951D311B6660008C7917CF008982BA6@zsc4c008.us.nortel.com> Subject: Re: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Mon, 11 Feb 2002 22:11:25 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0136_01C1B349.0BD3D0E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0136_01C1B349.0BD3D0E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture DraftHi Reinaldo, Althoug it is a dream of all operators to have a common CLI, IPFIX would = never happen if we wait for it to happen. Would the configuration be = XML, Text, SNMP,COPS,? K.C. ----- Original Message -----=20 From: Reinaldo Penno=20 To: K.C. Norseth ; will@cisco.com ; ipfix@net.doit.wisc.edu=20 Sent: Monday, February 11, 2002 9:57 PM Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the Architecture Draft) Hello Norseth, =20 I think the right question to answer is not if it is "necessary", = since you can always pay somebody to be some sort of CLI configuration = master and do everything by hand. =20 I think the right question is if it should be on the architecture = document or not and with whihch level of compliance.=20 =20 I think it should be on the arch document and maybe putting it with a = SHOULD instead of a MUST will make (most) people happy. =20 cheers, =20 Reinaldo =20 =20 -----Original Message----- From: K.C. Norseth [mailto:kcn@norseth.com] Sent: Monday, February 11, 2002 8:25 PM To: will@cisco.com; ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments = on the Architecture Draft) Will, I agree. Let's go for the wg concensus. What do people say? | - the exporter configuration is out of the scope of this document = (the exporter configuration out of band) =20 Configuration I think is out of scope, unless we hook it to an = existing mib or something. I so, we can refer to that mib or process. |- no transport negotiation (which transport) we need to define the action of each transport type. | - no capability negotiation Nice, but necessary? =20 =20 K.C. ----- Original Message -----=20 From: Will Eatherton=20 To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu ; = ipfix-arch-volunteers@net.doit.wisc.edu=20 Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; = plonka@doit.wisc.edu=20 Sent: Monday, February 11, 2002 8:24 AM Subject: Scope of IPFIX (was Answer to the recent comments on the = Architecture Draft) Group, =20 Cisco's interest in IPFIX was to help establish a non-proprietary = protocol similar to netflow but more flexible allowing us to add value = to our customers (and do so in a timely manner). If IPFIX goes down a = path along the lines as being advocated recent threads by Reinaldo, it = is unclear if the added burden of the protocol will be make it worth the = benefits of a non-proprietary protocol. Given it seems I have seen = roughly the same conversation occur 3 times in past several day, It is = unclear if further email discussion on this topic will resolve the = underlying question as to the scope of IPFIX. It seems time for an = official call on what is in/out of scope for IPFIX. As has been = mentioned here multiple times we would like to hear : =20 - the exporter configuration is out of the scope of this document = (the exporter configuration out of band) - no transport negotiation (which transport) - no capability negotiation Will :So lets have a protocol which is more flexible as NetFlow = version=20 :1-7,=20 I will not comment on that too much...Basically we are not here = to reverse-engineer Netflow, but to incorporate some good ideas from it. :but not much more complicated, in order to be successfully=20 :accepted by hardware vendors and application programmers.=20 ohh, please...Then Netflow is just right?=20 Reinaldo=20 ------=_NextPart_000_0136_01C1B349.0BD3D0E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture = Draft
Hi Reinaldo,
 
Althoug it is a dream of all operators = to have a=20 common CLI, IPFIX would never happen if we wait for it to happen. Would = the=20 configuration be XML, Text, SNMP,COPS,?
 
K.C.
 
----- Original Message -----
From:=20 Reinaldo Penno
To: K.C. Norseth ; will@cisco.com ; ipfix@net.doit.wisc.edu
Sent: Monday, February 11, 2002 = 9:57=20 PM
Subject: RE: [ipfix] Re: Scope = of IPFIX=20 (was Answer to the recent comments on the Architecture Draft)

Hello Norseth,
 
I=20 think the right question to answer is not if it is "necessary", since = you can=20 always pay somebody to be some sort of CLI configuration master and do = everything by hand.  
I=20 think the right question is if it should be on the architecture = document or=20 not and with whihch level of compliance.
 
I=20 think it should be on the arch document and maybe putting it with = a=20 SHOULD instead of a MUST will make (most) people = happy.
 
cheers,
 
Reinaldo
 
 
 -----Original=20 Message-----
From: K.C. Norseth=20 [mailto:kcn@norseth.com]
Sent: Monday, February 11, 2002 = 8:25=20 PM
To: will@cisco.com; = ipfix@net.doit.wisc.edu
Subject:=20 [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the=20 Architecture Draft)

Will,
 
I agree. Let's=20 go for the wg concensus.  What do people say?
 
| - the=20 exporter configuration is out of the scope of this document   (the = exporter configuration out of=20 band)
 
Configuration I=20 think is out of scope, unless we hook it to an existing mib or=20 something.  I so, we can refer to that mib or = process.

|- no transport = negotiation (which=20 transport)

we need to define the action of each = transport=20 type.

| - no = capability=20 negotiation

Nice, but necessary?  

 
K.C.
----- Original Message ----- =
From:=20 Will = Eatherton=20
To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu ; = ipfix-arch-volunteers@net= .doit.wisc.edu=20
Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; plonka@doit.wisc.edu
Sent: Monday, February 11, = 2002 8:24=20 AM
Subject: Scope of IPFIX = (was Answer=20 to the recent comments on the Architecture Draft)

Group,
 
Cisco's interest in IPFIX  was to help = establish=20 a non-proprietary protocol similar to netflow but more = flexible=20 allowing us to add value to our customers (and do so in a = timely=20 manner).  If IPFIX goes down a path along the lines = as=20 being advocated recent threads by Reinaldo,  it is = unclear if=20 the added burden of the protocol will be make it worth the = benefits of a=20 non-proprietary protocol.  Given it seems I have seen = roughly=20 the same conversation occur 3 times in past several day, It is = unclear if=20 further email discussion on this topic will resolve the underlying = question as to the scope of IPFIX.  It seems = time for an=20 official call on what is in/out of scope for = IPFIX.  As has=20 been mentioned here multiple times we would like to hear=20 :  

- the exporter = configuration is=20 out of the scope of this document =20  (the exporter configuration out of band)

- no transport = negotiation (which=20 transport)

 - no = capability=20 negotiation

Will

:So lets have a protocol which is more = flexible as=20 NetFlow version
:1-7,

I will not comment on that too = much...Basically we are=20 not here to reverse-engineer Netflow, but to incorporate some = good ideas=20 from it.

:but not much more complicated, in order to be = successfully
:accepted by hardware = vendors and=20 application programmers.

ohh, please...Then Netflow is just = right?

Reinaldo=20 =






------=_NextPart_000_0136_01C1B349.0BD3D0E0-- -- 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 Tue Feb 12 00:42:12 2002 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 AAA26705 for ; Tue, 12 Feb 2002 00:42:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aVNN-0003B2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 23:21:09 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aVNL-00039w-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 23:21:07 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C5KSW04774; Mon, 11 Feb 2002 23:20:28 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXBVT>; Mon, 11 Feb 2002 21:20:26 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982BAD@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "K.C. Norseth" , will@cisco.com, ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Mon, 11 Feb 2002 21:20:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B384.F965FC30" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B384.F965FC30 Content-Type: text/plain; charset="iso-8859-1" Hello K.C., I think we are talking about slightly different things...One of the points against Capability Negotiation raised by Ganesh was that a sys admin could do that. So, this is always true, you can always pay someone to do "everything", but it's hardly an argument against CN (Capability Negotiation) or any protocol. So, capability negotiation and a lot of other things will never be "necessary" from a point of view of somone who is willing to pay a sys admin to do all that work. So IMO the best question to ask is the one I proposed in the previous email, i.e., "do you think it should be on the doc and with which level of compliance?" As for last email I didn't quite understand the question. Are you asking me what the capability negotiation protocol would be? regards, Reinaldo -----Original Message----- From: K.C. Norseth [mailto:kcn@norseth.com] Sent: Monday, February 11, 2002 9:11 PM To: Penno, Reinaldo [SC9:T327:EXCH]; will@cisco.com; ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Hi Reinaldo, Althoug it is a dream of all operators to have a common CLI, IPFIX would never happen if we wait for it to happen. Would the configuration be XML, Text, SNMP,COPS,? K.C. ----- Original Message ----- From: Reinaldo Penno To: K.C. Norseth ; will@cisco.com ; ipfix@net.doit.wisc.edu Sent: Monday, February 11, 2002 9:57 PM Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Hello Norseth, I think the right question to answer is not if it is "necessary", since you can always pay somebody to be some sort of CLI configuration master and do everything by hand. I think the right question is if it should be on the architecture document or not and with whihch level of compliance. I think it should be on the arch document and maybe putting it with a SHOULD instead of a MUST will make (most) people happy. cheers, Reinaldo -----Original Message----- From: K.C. Norseth [mailto:kcn@norseth.com] Sent: Monday, February 11, 2002 8:25 PM To: will@cisco.com; ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Will, I agree. Let's go for the wg concensus. What do people say? | - the exporter configuration is out of the scope of this document (the exporter configuration out of band) Configuration I think is out of scope, unless we hook it to an existing mib or something. I so, we can refer to that mib or process. |- no transport negotiation (which transport) we need to define the action of each transport type. | - no capability negotiation Nice, but necessary? K.C. ----- Original Message ----- From: Will Eatherton To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu ; ipfix-arch-volunteers@net.doit.wisc.edu Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; plonka@doit.wisc.edu Sent: Monday, February 11, 2002 8:24 AM Subject: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Group, Cisco's interest in IPFIX was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner). If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo, it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol. Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX. It seems time for an official call on what is in/out of scope for IPFIX. As has been mentioned here multiple times we would like to hear : - the exporter configuration is out of the scope of this document (the exporter configuration out of band) - no transport negotiation (which transport) - no capability negotiation Will :So lets have a protocol which is more flexible as NetFlow version :1-7, I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it. :but not much more complicated, in order to be successfully :accepted by hardware vendors and application programmers. ohh, please...Then Netflow is just right? Reinaldo ------_=_NextPart_001_01C1B384.F965FC30 Content-Type: text/html; charset="iso-8859-1" Answer to the recent comments on the Architecture Draft
Hello K.C.,
 
I think we are talking about slightly different things...One of the points against Capability Negotiation raised by Ganesh was that a sys admin could do that. So, this is always true, you can always pay someone to do "everything", but it's hardly an argument against CN (Capability Negotiation) or any protocol.
 
So, capability negotiation and a lot of other things will never be "necessary" from a point of view of somone who is willing to pay a sys admin to do all that work. So IMO the best question to ask is the one I proposed in the previous email, i.e., "do you think it should be on the doc and with which level of compliance?"
 
As for last email I didn't quite understand the question. Are you asking me what the capability negotiation protocol would be?
 
regards,
 
Reinaldo
-----Original Message-----
From: K.C. Norseth [mailto:kcn@norseth.com]
Sent: Monday, February 11, 2002 9:11 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; will@cisco.com; ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Hi Reinaldo,
 
Althoug it is a dream of all operators to have a common CLI, IPFIX would never happen if we wait for it to happen. Would the configuration be XML, Text, SNMP,COPS,?
 
K.C.
 
----- Original Message -----
Sent: Monday, February 11, 2002 9:57 PM
Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Hello Norseth,
 
I think the right question to answer is not if it is "necessary", since you can always pay somebody to be some sort of CLI configuration master and do everything by hand.  
I think the right question is if it should be on the architecture document or not and with whihch level of compliance.
 
I think it should be on the arch document and maybe putting it with a SHOULD instead of a MUST will make (most) people happy.
 
cheers,
 
Reinaldo
 
 
 -----Original Message-----
From: K.C. Norseth [mailto:kcn@norseth.com]
Sent: Monday, February 11, 2002 8:25 PM
To: will@cisco.com; ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Will,
 
I agree. Let's go for the wg concensus.  What do people say?
 
| - the exporter configuration is out of the scope of this document   (the exporter configuration out of band)
 
Configuration I think is out of scope, unless we hook it to an existing mib or something.  I so, we can refer to that mib or process.

|- no transport negotiation (which transport)

we need to define the action of each transport type.

| - no capability negotiation

Nice, but necessary?  

 
K.C.
----- Original Message -----
Sent: Monday, February 11, 2002 8:24 AM
Subject: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Group,
 
Cisco's interest in IPFIX  was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner).  If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo,  it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol.  Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX.  It seems time for an official call on what is in/out of scope for IPFIX.  As has been mentioned here multiple times we would like to hear :  

- the exporter configuration is out of the scope of this document   (the exporter configuration out of band)

- no transport negotiation (which transport)

 - no capability negotiation

Will

:So lets have a protocol which is more flexible as NetFlow version
:1-7,

I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it.

:but not much more complicated, in order to be successfully
:accepted by hardware vendors and application programmers.

ohh, please...Then Netflow is just right?

Reinaldo






------_=_NextPart_001_01C1B384.F965FC30-- -- 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 Tue Feb 12 00:55:06 2002 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 AAA26801 for ; Tue, 12 Feb 2002 00:55:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aVet-0003aM-00 for ipfix-list@mil.doit.wisc.edu; Mon, 11 Feb 2002 23:39:15 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aVeq-0003Zr-00 for ipfix@net.doit.wisc.edu; Mon, 11 Feb 2002 23:39:12 -0600 Received: from postal.cisco.com (postal.cisco.com [171.71.160.26]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1C5ceh26890; Mon, 11 Feb 2002 21:38:40 -0800 (PST) Received: from WILLW2K (rtp-vpn2-74.cisco.com [10.82.240.74]) by postal.cisco.com (Mirapoint) with SMTP id AAK08675; Mon, 11 Feb 2002 21:38:51 -0800 (PST) Reply-To: From: "Will Eatherton" To: "Reinaldo Penno" , "K.C. Norseth" , Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Mon, 11 Feb 2002 21:37:12 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C1B344.43DF24D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <4F973E944951D311B6660008C7917CF008982BA6@zsc4c008.us.nortel.com> Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C1B344.43DF24D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Answer to the recent comments on the Architecture DraftLets be more clear cut then this. I dont want to have a major architectural SHOULD on something we believe is fundamentally flawed and will occupy signficant group time to spec if it is left in. We need a clear decision to move forward. A spec that includes SHOULDS for all proposed features is weak. WIll -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno Sent: Monday, February 11, 2002 8:57 PM To: K.C. Norseth; will@cisco.com; ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Hello Norseth, I think the right question to answer is not if it is "necessary", since you can always pay somebody to be some sort of CLI configuration master and do everything by hand. I think the right question is if it should be on the architecture document or not and with whihch level of compliance. I think it should be on the arch document and maybe putting it with a SHOULD instead of a MUST will make (most) people happy. cheers, Reinaldo -----Original Message----- From: K.C. Norseth [mailto:kcn@norseth.com] Sent: Monday, February 11, 2002 8:25 PM To: will@cisco.com; ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Will, I agree. Let's go for the wg concensus. What do people say? | - the exporter configuration is out of the scope of this document (the exporter configuration out of band) Configuration I think is out of scope, unless we hook it to an existing mib or something. I so, we can refer to that mib or process. |- no transport negotiation (which transport) we need to define the action of each transport type. | - no capability negotiation Nice, but necessary? K.C. ----- Original Message ----- From: Will Eatherton To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu ; ipfix-arch-volunteers@net.doit.wisc.edu Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; plonka@doit.wisc.edu Sent: Monday, February 11, 2002 8:24 AM Subject: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Group, Cisco's interest in IPFIX was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner). If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo, it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol. Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX. It seems time for an official call on what is in/out of scope for IPFIX. As has been mentioned here multiple times we would like to hear : - the exporter configuration is out of the scope of this document (the exporter configuration out of band) - no transport negotiation (which transport) - no capability negotiation Will :So lets have a protocol which is more flexible as NetFlow version :1-7, I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it. :but not much more complicated, in order to be successfully :accepted by hardware vendors and application programmers. ohh, please...Then Netflow is just right? Reinaldo ------=_NextPart_000_0008_01C1B344.43DF24D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture = Draft
Lets=20 be more clear cut then this. I dont want to have a major = architectural=20 SHOULD on something we believe is fundamentally=20 flawed and will occupy signficant group time to spec if it is left = in.  We=20 need a clear decision to move forward.  A spec that includes = SHOULDS=20 for all proposed features is weak.
 
WIll
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo=20 Penno
Sent: Monday, February 11, 2002 8:57 PM
To: = K.C.=20 Norseth; will@cisco.com; ipfix@net.doit.wisc.edu
Subject: = RE:=20 [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the=20 Architecture Draft)

Hello Norseth,
 
I=20 think the right question to answer is not if it is "necessary", since = you can=20 always pay somebody to be some sort of CLI configuration master and do = everything by hand.  
I=20 think the right question is if it should be on the architecture = document or=20 not and with whihch level of compliance.
 
I=20 think it should be on the arch document and maybe putting it with = a=20 SHOULD instead of a MUST will make (most) people = happy.
 
cheers,
 
Reinaldo
 
 
 -----Original=20 Message-----
From: K.C. Norseth=20 [mailto:kcn@norseth.com]
Sent: Monday, February 11, 2002 = 8:25=20 PM
To: will@cisco.com; = ipfix@net.doit.wisc.edu
Subject:=20 [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the=20 Architecture Draft)

Will,
 
I agree. Let's=20 go for the wg concensus.  What do people say?
 
| - the=20 exporter configuration is out of the scope of this document   (the = exporter configuration out of=20 band)
 
Configuration I=20 think is out of scope, unless we hook it to an existing mib or=20 something.  I so, we can refer to that mib or = process.

|- no transport = negotiation (which=20 transport)

we need to define the action of each = transport=20 type.

| - no = capability=20 negotiation

Nice, but necessary?  

 
K.C.
----- Original Message ----- =
From:=20 Will = Eatherton=20
To: Reinaldo = Penno ; ipfix-arch@net.doit.wisc.edu= =20 ; ipfix-arch-volunt= eers@net.doit.wisc.edu=20
Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com = ; plonka@doit.wisc.edu =
Sent: Monday, February 11, = 2002 8:24=20 AM
Subject: Scope of IPFIX = (was Answer=20 to the recent comments on the Architecture Draft)

Group,
 
Cisco's interest in IPFIX  was to help = establish=20 a non-proprietary protocol similar to netflow but more = flexible=20 allowing us to add value to our customers (and do so in a = timely=20 manner).  If IPFIX goes down a path along the lines = as=20 being advocated recent threads by Reinaldo,  it is = unclear if=20 the added burden of the protocol will be make it worth the = benefits of a=20 non-proprietary protocol.  Given it seems I have seen = roughly=20 the same conversation occur 3 times in past several day, It is = unclear if=20 further email discussion on this topic will resolve the underlying = question as to the scope of IPFIX.  It seems = time for an=20 official call on what is in/out of scope for = IPFIX.  As has=20 been mentioned here multiple times we would like to hear=20 :  

- the exporter = configuration is=20 out of the scope of this document =20  (the exporter configuration out of band)

- no transport = negotiation (which=20 transport)

 - no = capability=20 negotiation

Will

:So lets have a protocol which is more = flexible as=20 NetFlow version
:1-7,

I will not comment on that too = much...Basically we are=20 not here to reverse-engineer Netflow, but to incorporate some = good ideas=20 from it.

:but not much more complicated, in order to be = successfully
:accepted by hardware = vendors and=20 application programmers.

ohh, please...Then Netflow is just = right?

Reinaldo=20 =






------=_NextPart_000_0008_01C1B344.43DF24D0-- -- 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 Tue Feb 12 01:19:11 2002 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 BAA26950 for ; Tue, 12 Feb 2002 01:19:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aVzN-00042T-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 00:00:25 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aVzK-0003yq-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 00:00:22 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C5xgm06715; Mon, 11 Feb 2002 23:59:42 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXBXJ>; Mon, 11 Feb 2002 21:59:40 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982BB5@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: will@cisco.com, "K.C. Norseth" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Mon, 11 Feb 2002 21:59:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B38A.7309DED0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B38A.7309DED0 Content-Type: text/plain; charset="iso-8859-1" inline... -----Original Message----- From: Will Eatherton [mailto:will@cisco.com] Sent: Monday, February 11, 2002 9:37 PM To: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Lets be more clear cut then this. I dont want to have a major architectural SHOULD on something we believe is fundamentally flawed I didn't hear any solid arguments saying why it's flawed. I heard "the sys admin can do it", "it's negotiation, not advertisement", "For the application of router export to a collector we are saying that allowing UDP without required capability negotiation (as an option) is important" and will occupy signficant group time to spec if it is left in. not true. We need a clear decision to move forward. A spec that includes SHOULDS for all proposed features is weak. huh ? No spec include SHOULDs for **all proposed features** as you said, and IPfix is not doing this either. Reinaldo WIll -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno Sent: Monday, February 11, 2002 8:57 PM To: K.C. Norseth; will@cisco.com; ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Hello Norseth, I think the right question to answer is not if it is "necessary", since you can always pay somebody to be some sort of CLI configuration master and do everything by hand. I think the right question is if it should be on the architecture document or not and with whihch level of compliance. I think it should be on the arch document and maybe putting it with a SHOULD instead of a MUST will make (most) people happy. cheers, Reinaldo -----Original Message----- From: K.C. Norseth [mailto:kcn@norseth.com] Sent: Monday, February 11, 2002 8:25 PM To: will@cisco.com; ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Will, I agree. Let's go for the wg concensus. What do people say? | - the exporter configuration is out of the scope of this document (the exporter configuration out of band) Configuration I think is out of scope, unless we hook it to an existing mib or something. I so, we can refer to that mib or process. |- no transport negotiation (which transport) we need to define the action of each transport type. | - no capability negotiation Nice, but necessary? K.C. ----- Original Message ----- From: Will Eatherton To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu ; ipfix-arch-volunteers@net.doit.wisc.edu Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; plonka@doit.wisc.edu Sent: Monday, February 11, 2002 8:24 AM Subject: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Group, Cisco's interest in IPFIX was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner). If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo, it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol. Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX. It seems time for an official call on what is in/out of scope for IPFIX. As has been mentioned here multiple times we would like to hear : - the exporter configuration is out of the scope of this document (the exporter configuration out of band) - no transport negotiation (which transport) - no capability negotiation Will :So lets have a protocol which is more flexible as NetFlow version :1-7, I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it. :but not much more complicated, in order to be successfully :accepted by hardware vendors and application programmers. ohh, please...Then Netflow is just right? Reinaldo ------_=_NextPart_001_01C1B38A.7309DED0 Content-Type: text/html; charset="iso-8859-1" Answer to the recent comments on the Architecture Draft
inline...
-----Original Message-----
From: Will Eatherton [mailto:will@cisco.com]
Sent: Monday, February 11, 2002 9:37 PM
To: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Lets be more clear cut then this. I dont want to have a major architectural SHOULD on something we believe is fundamentally flawed  
 
I didn't hear any solid arguments saying why it's flawed. I heard
 
"the sys admin can do it",
"it's negotiation, not advertisement",
"For the application of router export to a collector we are saying that allowing UDP without required capability negotiation (as an option) is important"
 
 and will occupy signficant group time to spec if it is left in.   
 
not true.
 
 We need a clear decision to move forward.  A spec that includes SHOULDS for all proposed features is weak. 
 
huh ? No spec include SHOULDs for **all proposed features** as you said, and IPfix is not doing this either.
 
Reinaldo
 
WIll
-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno
Sent: Monday, February 11, 2002 8:57 PM
To: K.C. Norseth; will@cisco.com; ipfix@net.doit.wisc.edu
Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Hello Norseth,
 
I think the right question to answer is not if it is "necessary", since you can always pay somebody to be some sort of CLI configuration master and do everything by hand.  
I think the right question is if it should be on the architecture document or not and with whihch level of compliance.
 
I think it should be on the arch document and maybe putting it with a SHOULD instead of a MUST will make (most) people happy.
 
cheers,
 
Reinaldo
 
 
 -----Original Message-----
From: K.C. Norseth [mailto:kcn@norseth.com]
Sent: Monday, February 11, 2002 8:25 PM
To: will@cisco.com; ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Will,
 
I agree. Let's go for the wg concensus.  What do people say?
 
| - the exporter configuration is out of the scope of this document   (the exporter configuration out of band)
 
Configuration I think is out of scope, unless we hook it to an existing mib or something.  I so, we can refer to that mib or process.

|- no transport negotiation (which transport)

we need to define the action of each transport type.

| - no capability negotiation

Nice, but necessary?  

 
K.C.
----- Original Message -----
Sent: Monday, February 11, 2002 8:24 AM
Subject: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)

Group,
 
Cisco's interest in IPFIX  was to help establish a non-proprietary protocol similar to netflow but more flexible allowing us to add value to our customers (and do so in a timely manner).  If IPFIX goes down a path along the lines as being advocated recent threads by Reinaldo,  it is unclear if the added burden of the protocol will be make it worth the benefits of a non-proprietary protocol.  Given it seems I have seen roughly the same conversation occur 3 times in past several day, It is unclear if further email discussion on this topic will resolve the underlying question as to the scope of IPFIX.  It seems time for an official call on what is in/out of scope for IPFIX.  As has been mentioned here multiple times we would like to hear :  

- the exporter configuration is out of the scope of this document   (the exporter configuration out of band)

- no transport negotiation (which transport)

 - no capability negotiation

Will

:So lets have a protocol which is more flexible as NetFlow version
:1-7,

I will not comment on that too much...Basically we are not here to reverse-engineer Netflow, but to incorporate some good ideas from it.

:but not much more complicated, in order to be successfully
:accepted by hardware vendors and application programmers.

ohh, please...Then Netflow is just right?

Reinaldo






------_=_NextPart_001_01C1B38A.7309DED0-- -- 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 Tue Feb 12 01:29:53 2002 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 BAA27017 for ; Tue, 12 Feb 2002 01:29:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aW3h-00048P-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 00:04:53 -0600 Received: from c001-h008.c001.snv.cp.net ([209.228.32.122] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16aW3f-00047a-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 00:04:51 -0600 Received: (cpmta 17904 invoked from network); 11 Feb 2002 22:04:16 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.122) with SMTP; 11 Feb 2002 22:04:16 -0800 X-Sent: 12 Feb 2002 06:04:16 GMT Message-ID: <018401c1b38b$769fe160$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: Cc: "K.C. Norseth" , Subject: [ipfix-req] Terminology Date: Mon, 11 Feb 2002 23:06:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit As per the conversations on the terminology sections of the drafts, I have removed these to see if they can be incorporated into the requirements draft. I can put them back if you think they should be back. K.C. 1. Terminology Flow Information Exporter or Exporter The exporter sends flow records created and maintained by one or more meters to one or more data collectors. Flow Information Data Collector or Data Collector The data collector receives flow records from one or more exporters. The data collector might process or store received flow record, but these actions are out of the scope of this document. Flow Information Export Flow information export denotes the process of transferring flow records from an exporter to a data collector. Flow Record A flow record keeps information a flow including characteristic properties of the flow, for example the source IP address, and measured properties of the flow, for example the total number of bytes of all packets of the flow. Information Element (IE) IPFIX Session An IPFIX Session is a logical connection between an exporter entity and one or multiple collector entity for the purpose of exporting IP flow information. Multiple sessions MAY be maintained concurrently in an exporting device. IP Traffic Flow or Flow see draft-ietf-ipfix-reqs-00.txt, section 1.1 Metering Process The metering process includes all actions performed by a meter with respect to observing packets, timestamping them, analyzing them, mapping them to flows, computing flow statistics, detecting flow expiration, and maintaining flow records. Observation Point The observation point is a location in the network where IP packets can be observed. Examples are a line to which a probe is attached, a shared medium, such as an Ethernet-based LAN, a port of a router, or an entire router with several ports. Template A Template defines the structure of any types of IP flow information record, and specifies the data type, meaning, and location of the fields in the record. Traffic Flow Meter or Meter A meter observes packets at one or more observation points. It analyzes the content of the packets and maps them to flows. For each observed flow the meter computes statistics and maintains a flow record where it stores relevant flow information. -- 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 Tue Feb 12 01:29:56 2002 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 BAA27028 for ; Tue, 12 Feb 2002 01:29:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aWA4-0004Gm-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 00:11:28 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aWA1-0004Fy-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 00:11:26 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C6Arm06906; Tue, 12 Feb 2002 00:10:54 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXBYB>; Mon, 11 Feb 2002 22:10:52 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982BB7@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: ipfix@net.doit.wisc.edu Cc: "K.C. Norseth" Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Mon, 11 Feb 2002 22:10:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B38C.05495590" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B38C.05495590 Content-Type: text/plain; charset="iso-8859-1" Hello, correct me if I'm wrong. Cisco proposal is that Capability Negotiation does not appear in the draft at all (no matter what compliance level). People can express opinions based on that. regards, Reinaldo ------_=_NextPart_001_01C1B38C.05495590 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the Architecture Draft)

Hello,

correct me if I'm wrong. Cisco proposal is that = Capability Negotiation does not appear in the draft at all (no matter = what compliance level).

People can express opinions based on that.

regards,

Reinaldo

------_=_NextPart_001_01C1B38C.05495590-- -- 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 Tue Feb 12 01:39:20 2002 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 BAA27108 for ; Tue, 12 Feb 2002 01:39:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aWJn-0004QL-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 00:21:31 -0600 Received: from c001-h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16aWJl-0004PZ-00 for ipfix-arch@net.doit.wisc.edu; Tue, 12 Feb 2002 00:21:29 -0600 Received: (cpmta 24525 invoked from network); 11 Feb 2002 22:20:54 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.115) with SMTP; 11 Feb 2002 22:20:54 -0800 X-Sent: 12 Feb 2002 06:20:54 GMT Message-ID: <01cd01c1b38d$c97170a0$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: "Ganesh Sadasivan" Cc: References: <4140960312.1013458274@[192.168.102.164]> <3C681ECC.D09A8945@cisco.com> Subject: Re: [ipfix-arch] definition of uni-/bi-directional flows Date: Mon, 11 Feb 2002 23:15:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh, Can you expand on what your revised text will be? K.C. ----- Original Message ----- From: Ganesh Sadasivan To: Juergen Quittek Cc: Sent: Monday, February 11, 2002 12:43 PM Subject: Re: [ipfix-arch] definition of uni-/bi-directional flows | Hi Jurgene, | You are correct. What I should have added is: | When the direction w.r.t wire is specified, then it can be furthur | categorised as uni/bi.. The direction however is optional and may | not be applicable in all the cases. I beleive the scope of the flow is | restricted to an observation point and not end-to-end. | Thanks | Ganesh | | Juergen Quittek wrote: | | > Hi Ganesh, | > | > --On 11 February 2002 11:00 -0800 Ganesh Sadasivan wrote: | > | > > Hi Jurgene, | > > Refer to section 2.0 of the draft submitted by Benoit and me. It | > > gives a detailed defintion of a uni-directional flow. Bi-directional | > > is a restricted set of uni-directional flows which have a sensible | > > reverse mapping at the same observation point. I am not sure to | > > what precision one can define a bi-directional flow. | > | > The flows you define are not necessarily what intuition would call | > uni-directional. If you for example map all traffic with a source | > or destination port 80 into one flow I would not call it uni-directional. | > | > What you do is that you define a general flow and then say the regular | > case is the uni-directional one, and bi-directional is some special | > kind. My claim is that already uni-directional is a special kind, which | > we have not defined yet, although we all might have a good intuition | > teeling us what would be a uni-directional or bi-directional flow. | > | > Best wishes, | > | > Juergen | > -- | > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 | > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 | > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de | > | > > | > > Thanks | > > Ganesh | > > | > > quittek@ccrle.nec.de wrote: | > > | > >> Hi all, | > >> | > >> I just ran into a strange problem: I tried to define precisely | > >> what is a uni-directional / bi-directional flow and found out | > >> that although I am discussing with you for quite some time | > >> using these terms, I cannot tell precisely, what they are. | > >> | > >> Does anyone have such a definition? | > >> | > >> Of course I can define them easily when I restrict flows to | > >> 5-tuple TCP/UDP flow without wild-carding, but when I start to | > >> include aggregated flows, for example all packets originating | > >> in a specific subnet, and ICMP flows, and multicast flows | > >> (multi-directional?), then it gets much more complicated. | > >> | > >> 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/ | > > | | | -- | 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/ | -- 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 Tue Feb 12 02:00:19 2002 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 CAA27871 for ; Tue, 12 Feb 2002 02:00:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aWg7-0004rm-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 00:44:35 -0600 Received: from c001-h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16aWg4-0004rA-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 00:44:32 -0600 Received: (cpmta 3626 invoked from network); 11 Feb 2002 22:44:01 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.115) with SMTP; 11 Feb 2002 22:44:01 -0800 X-Sent: 12 Feb 2002 06:44:01 GMT Message-ID: <022501c1b391$03f37040$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: Subject: [ipfix] Draft updates - Date: Mon, 11 Feb 2002 23:46:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Folks, Enclosed is the location for the new drafts. I have included Benoit and Ganeshes (B/G) document in them as suggested by people. The previous documents are avaiable in the doc021002/ directory. (http://www.norseth.org/ietf/ipfix) http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.doc http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.doc I do want to apologize. There was a misunderstanding. I had not included Benoits and Ganeshes draft because I was waiting for them to tell me to or someone to. They are great and should be incorporated, so now they are. On the arch document. I have removed the terminology section. These do fit better inthe requirements doc. On the data document. I have combined what I saw was missing the B/G's document had. They were in 2 different formats. Rather than try to convet outright, I started putting them in the original format. Ileft the Value and size in the text. The B/G elements need more explanation than what was provided. Benoit, Ganesh, Would this be possible? I also added a section of packet management, which is things like version. This needs more. What am I mising? Paul wrote on address types. "Depends on how the address is encoded. If the address family is included no version if needed.If not, them we either need a version of theIE itself can specify (e.g. SRC_ADDR_IPV4, SRC_ADDR_IPV6)" We need to address this. I left this alone form B/G doc, but it is dissimilar to what was there. We need to standardize. I hope we are getting the content defined better. I will keep working on smoothing the items out. K.C. -- 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 Tue Feb 12 03:39:38 2002 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 DAA06222 for ; Tue, 12 Feb 2002 03:39:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aY9a-0006uF-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 02:19:06 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aY9Y-0006ty-00; Tue, 12 Feb 2002 02:19:05 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C8IUm09613; Tue, 12 Feb 2002 02:18:31 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXB9F>; Tue, 12 Feb 2002 00:18:28 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982BCA@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "K.C. Norseth" , ipfix@net.doit.wisc.edu Cc: data , calato@riverstonenet.com Subject: RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 00:18:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B39D.D8EF3FC0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B39D.D8EF3FC0 Content-Type: text/plain; charset="iso-8859-1" Comments: First ol all, would you guys mind if I rewrite this whole section using the words "private side" and "public side" so we align our nomenclature to RFC2663? Also, the subsection titles refer to "virtual" this and that, but the IEs refer to "outside" and "inside". So, we need some unified terminology. I also think that using inside and outside can cause confusion since the exporter/collector does not know what's inside and outside. See draft-iab-unsaf-considerations-01.html other stuff. 1 ---- In 5.11.6. "A type field contains the type of translation performed on the source port. The following types are currently available: 1. - NAT 2. - LSNAT 3. - Web Cache" Could we elaborate a bit more on what we mean by webcache? The exporter is not the webcache per se, so maybe we should change it to "application redirection". Now, even in this case, application redirection/webcache is itself a form of NAT. Or can also mean changing only L2 addresses (MAC addresses) in the Direct Server Return case. So this option needs some splitting (more options to be more specific). 2 ---- In 5.11.6 and 5.11.7 is said that "The Source Virtual IE contains the source address/port of the flow as *transmitted* by the Exporter." then in 5.11.18 and 5.11.9 "The Destination Virtual IE contains the destination address of the flow/port as *received* by the Exporter" It should be *transmited* by the exporter, ie, you need an almost complete 5-tuple set of IEs for the private side and for the public side. 3 ---- Also in 5.11.8 (Destination Virtual Address IE) "The Destination Virtual IE contains the destination address of the flow as received by the Exporter. It is generally different than the destination port number, which contains the actual destination address of the flow." I've already read this 3 times but maybe is getting late... but the destination address of the flow is always different than the destination port number. One is a port number, the other is a IP address. I suggest to change it to. "The Destination Virtual IE contains the destination address of the flow as trasnmited by the Exporter. It might be different than the destination source address, which contains the original destination address of the flow." BTW, what is LSNAT? 4 ---- 5.14.4. Internal queue priority "A switch may map several of its internal priority queues into a Premium, High, Medium or Low category." I couldn't grasp this one. Wouldn't this be a vendor extension IE? Not only the number of queues but even the names are vendor specific. 5 ---- "5.10.1. Source Address Netmask IE The number of bits in the CIDR netmask, as defined in RFC 1519, for the source address. 5.10.2. Destination Address Netmask IE The CIDR netmask, as defined in RFC 1519, for the destination address." We should use the same definition for both (or bits or netmask). 6 ---- "5.9.3. Egress ATM Subinterface" Instead of "Subinterface", how about the old "circuit"? "Egress ATM Circuit" 7 ---- "5.9.4. EGRESS_FRAME_RELAY_SUBINTERFACE IE The egress DLCI for the flow is provided in this IE. ITU Q.922 defines the DLCI range." Can we just call it "EGRESS_FRAME_RELAY_DLCI"? The definition mentions DLCI but we call it subinterface in the title? 8 ---- "5.11.4. Source VLAN ID IE" Shouldn't we also have an IE for the priority bits (802.1p)? regards, Reinaldo ------_=_NextPart_001_01C1B39D.D8EF3FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Draft updates - Comments on the data model

Comments:

First ol all, would you guys mind if I rewrite this = whole section using the words "private side" and "public = side" so we align our nomenclature to RFC2663?

Also, the subsection titles refer to = "virtual" this and that, but the IEs refer to = "outside" and "inside". So, we need some unified = terminology. I also think that using inside and outside can cause = confusion since the exporter/collector does not know what's inside and = outside. See draft-iab-unsaf-considerations-01.html 

other stuff.

1 ----

In 5.11.6.

"A type field contains the type of translation = performed on the source port. The following types are currently = available:

1. - NAT
2. - LSNAT
3. - Web Cache"


Could we elaborate a bit more on what we mean by = webcache? The exporter is not the webcache per se, so maybe we should = change it to "application redirection".

Now, even in this case, application = redirection/webcache is itself a form of NAT. Or can also mean changing = only L2 addresses (MAC addresses) in the Direct Server Return case. So = this option needs some splitting (more options to be more specific). =

2 ----

In 5.11.6 and 5.11.7 is said that

"The Source Virtual IE contains the source = address/port of the flow as *transmitted* by the Exporter."

then in 5.11.18 and 5.11.9

"The Destination Virtual IE contains the = destination address of the flow/port as *received* by the = Exporter"

It should be *transmited* by the exporter, ie, you = need an almost complete 5-tuple set of IEs for the private side and for = the public side.

3 ----

Also in 5.11.8 (Destination Virtual Address = IE)

"The Destination Virtual IE contains the = destination address of the flow as received by the Exporter. It is = generally different than the destination port number, which contains = the actual destination address of the flow."

I've already read this 3 times but maybe is getting = late... but the destination address of the flow is always different = than the destination port number. One is a port number, the other is a = IP address.

I suggest to change it to.

"The Destination Virtual IE contains the = destination address of the flow as trasnmited by the Exporter. It might = be different than the destination source address, which contains the = original destination address of the flow."

BTW, what is LSNAT?

4 ----

5.14.4.  Internal queue priority

"A switch may map several of its internal = priority queues into a Premium, High, Medium or Low = category."

I couldn't grasp this one. Wouldn't this be a vendor = extension IE? Not only the number of queues but even the names are = vendor specific.

5 ----

"5.10.1.  Source Address Netmask IE

The number of bits in the CIDR netmask, as defined in = RFC 1519, for the source address.

5.10.2.  Destination Address Netmask IE

The CIDR netmask, as defined in RFC 1519, for the = destination address."

We should use the same definition for both (or bits = or netmask).

6 ----

"5.9.3.  Egress ATM = Subinterface"

Instead of "Subinterface", how about the = old "circuit"? "Egress ATM Circuit"

7 ----

"5.9.4.  EGRESS_FRAME_RELAY_SUBINTERFACE = IE

The egress DLCI for the flow is provided in this IE. = ITU Q.922 defines the DLCI range."

Can we just call it = "EGRESS_FRAME_RELAY_DLCI"? The definition mentions DLCI but = we call it subinterface in the title?

8 ----

"5.11.4.  Source VLAN ID IE"

Shouldn't we also have an IE for the priority bits = (802.1p)?


regards,

Reinaldo




------_=_NextPart_001_01C1B39D.D8EF3FC0-- -- 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 Tue Feb 12 04:38:26 2002 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 EAA06846 for ; Tue, 12 Feb 2002 04:38:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aYc4-0007WE-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 02:48:32 -0600 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aYc2-0007Vu-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 02:48:30 -0600 Received: from agile.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id AAA10709; Tue, 12 Feb 2002 00:47:59 -0800 (PST) Received: from agile.yagosys.com (agile.yagosys.com [127.0.0.1]) by agile.yagosys.com (8.12.0/8.12.0) with ESMTP id g1C8lwiZ001379 for ; Tue, 12 Feb 2002 00:47:58 -0800 Received: (from mrm@localhost) by agile.yagosys.com (8.12.0/8.12.0/Submit) id g1C8lv0v001378 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 00:47:57 -0800 Date: Tue, 12 Feb 2002 00:47:57 -0800 From: Michael MacFaden To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Message-ID: <20020212004757.C1356@riverstonenet.com> References: <012201c1b37d$4b5610a0$850f880a@slc252750> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <012201c1b37d$4b5610a0$850f880a@slc252750>; from kcn@norseth.com on Mon, Feb 11, 2002 at 09:25:23PM -0700 X-Operating-System: GNU/Linux 2.4.17 Precedence: bulk Sender: majordomo listserver On Mon, Feb 11, 2002 at 09:25:23PM -0700, K.C. Norseth wrote: >Answer to the recent comments on the Architecture DraftWill, > >I agree. Let's go for the wg concensus. What do people say? > >| - the exporter configuration is out of the scope of this document (the exporter configuration out of band) Inband configuration makes the protocol more complex as well as being prone to additional security risks. So I'd prefer in-band configuration not be part of the scope of the current effort. That said, I would not wan to rule out experimentation or future ability to add such a feature in a way that can be cleanly discovered in a mixed envionment. An SNMP MIB module should be made available to monitor the various components and to define, if any, standard configuration objects. Mike MacFaden -- 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 Tue Feb 12 04:38:26 2002 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 EAA06858 for ; Tue, 12 Feb 2002 04:38:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aYUk-0007M4-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 02:40:58 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aY9Y-0006ty-00; Tue, 12 Feb 2002 02:19:05 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1C8IUm09613; Tue, 12 Feb 2002 02:18:31 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXB9F>; Tue, 12 Feb 2002 00:18:28 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982BCA@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "K.C. Norseth" , ipfix@net.doit.wisc.edu Cc: data , calato@riverstonenet.com Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 00:18:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B39D.D8EF3FC0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B39D.D8EF3FC0 Content-Type: text/plain; charset="iso-8859-1" Comments: First ol all, would you guys mind if I rewrite this whole section using the words "private side" and "public side" so we align our nomenclature to RFC2663? Also, the subsection titles refer to "virtual" this and that, but the IEs refer to "outside" and "inside". So, we need some unified terminology. I also think that using inside and outside can cause confusion since the exporter/collector does not know what's inside and outside. See draft-iab-unsaf-considerations-01.html other stuff. 1 ---- In 5.11.6. "A type field contains the type of translation performed on the source port. The following types are currently available: 1. - NAT 2. - LSNAT 3. - Web Cache" Could we elaborate a bit more on what we mean by webcache? The exporter is not the webcache per se, so maybe we should change it to "application redirection". Now, even in this case, application redirection/webcache is itself a form of NAT. Or can also mean changing only L2 addresses (MAC addresses) in the Direct Server Return case. So this option needs some splitting (more options to be more specific). 2 ---- In 5.11.6 and 5.11.7 is said that "The Source Virtual IE contains the source address/port of the flow as *transmitted* by the Exporter." then in 5.11.18 and 5.11.9 "The Destination Virtual IE contains the destination address of the flow/port as *received* by the Exporter" It should be *transmited* by the exporter, ie, you need an almost complete 5-tuple set of IEs for the private side and for the public side. 3 ---- Also in 5.11.8 (Destination Virtual Address IE) "The Destination Virtual IE contains the destination address of the flow as received by the Exporter. It is generally different than the destination port number, which contains the actual destination address of the flow." I've already read this 3 times but maybe is getting late... but the destination address of the flow is always different than the destination port number. One is a port number, the other is a IP address. I suggest to change it to. "The Destination Virtual IE contains the destination address of the flow as trasnmited by the Exporter. It might be different than the destination source address, which contains the original destination address of the flow." BTW, what is LSNAT? 4 ---- 5.14.4. Internal queue priority "A switch may map several of its internal priority queues into a Premium, High, Medium or Low category." I couldn't grasp this one. Wouldn't this be a vendor extension IE? Not only the number of queues but even the names are vendor specific. 5 ---- "5.10.1. Source Address Netmask IE The number of bits in the CIDR netmask, as defined in RFC 1519, for the source address. 5.10.2. Destination Address Netmask IE The CIDR netmask, as defined in RFC 1519, for the destination address." We should use the same definition for both (or bits or netmask). 6 ---- "5.9.3. Egress ATM Subinterface" Instead of "Subinterface", how about the old "circuit"? "Egress ATM Circuit" 7 ---- "5.9.4. EGRESS_FRAME_RELAY_SUBINTERFACE IE The egress DLCI for the flow is provided in this IE. ITU Q.922 defines the DLCI range." Can we just call it "EGRESS_FRAME_RELAY_DLCI"? The definition mentions DLCI but we call it subinterface in the title? 8 ---- "5.11.4. Source VLAN ID IE" Shouldn't we also have an IE for the priority bits (802.1p)? regards, Reinaldo ------_=_NextPart_001_01C1B39D.D8EF3FC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Draft updates - Comments on the data model

Comments:

First ol all, would you guys mind if I rewrite this = whole section using the words "private side" and "public = side" so we align our nomenclature to RFC2663?

Also, the subsection titles refer to = "virtual" this and that, but the IEs refer to = "outside" and "inside". So, we need some unified = terminology. I also think that using inside and outside can cause = confusion since the exporter/collector does not know what's inside and = outside. See draft-iab-unsaf-considerations-01.html 

other stuff.

1 ----

In 5.11.6.

"A type field contains the type of translation = performed on the source port. The following types are currently = available:

1. - NAT
2. - LSNAT
3. - Web Cache"


Could we elaborate a bit more on what we mean by = webcache? The exporter is not the webcache per se, so maybe we should = change it to "application redirection".

Now, even in this case, application = redirection/webcache is itself a form of NAT. Or can also mean changing = only L2 addresses (MAC addresses) in the Direct Server Return case. So = this option needs some splitting (more options to be more specific). =

2 ----

In 5.11.6 and 5.11.7 is said that

"The Source Virtual IE contains the source = address/port of the flow as *transmitted* by the Exporter."

then in 5.11.18 and 5.11.9

"The Destination Virtual IE contains the = destination address of the flow/port as *received* by the = Exporter"

It should be *transmited* by the exporter, ie, you = need an almost complete 5-tuple set of IEs for the private side and for = the public side.

3 ----

Also in 5.11.8 (Destination Virtual Address = IE)

"The Destination Virtual IE contains the = destination address of the flow as received by the Exporter. It is = generally different than the destination port number, which contains = the actual destination address of the flow."

I've already read this 3 times but maybe is getting = late... but the destination address of the flow is always different = than the destination port number. One is a port number, the other is a = IP address.

I suggest to change it to.

"The Destination Virtual IE contains the = destination address of the flow as trasnmited by the Exporter. It might = be different than the destination source address, which contains the = original destination address of the flow."

BTW, what is LSNAT?

4 ----

5.14.4.  Internal queue priority

"A switch may map several of its internal = priority queues into a Premium, High, Medium or Low = category."

I couldn't grasp this one. Wouldn't this be a vendor = extension IE? Not only the number of queues but even the names are = vendor specific.

5 ----

"5.10.1.  Source Address Netmask IE

The number of bits in the CIDR netmask, as defined in = RFC 1519, for the source address.

5.10.2.  Destination Address Netmask IE

The CIDR netmask, as defined in RFC 1519, for the = destination address."

We should use the same definition for both (or bits = or netmask).

6 ----

"5.9.3.  Egress ATM = Subinterface"

Instead of "Subinterface", how about the = old "circuit"? "Egress ATM Circuit"

7 ----

"5.9.4.  EGRESS_FRAME_RELAY_SUBINTERFACE = IE

The egress DLCI for the flow is provided in this IE. = ITU Q.922 defines the DLCI range."

Can we just call it = "EGRESS_FRAME_RELAY_DLCI"? The definition mentions DLCI but = we call it subinterface in the title?

8 ----

"5.11.4.  Source VLAN ID IE"

Shouldn't we also have an IE for the priority bits = (802.1p)?


regards,

Reinaldo




------_=_NextPart_001_01C1B39D.D8EF3FC0-- -- 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 Tue Feb 12 05:42:11 2002 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 FAA07425 for ; Tue, 12 Feb 2002 05:42:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aa3D-0002Ak-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 04:20:39 -0600 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aa3B-0002Aa-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 04:20:37 -0600 Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16aa2o-0005vT-00; Tue, 12 Feb 2002 05:20:14 -0500 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Reinaldo Penno" Cc: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <4F973E944951D311B6660008C7917CF008982B2A@zsc4c008.us.nortel.com> Message-Id: Date: Tue, 12 Feb 2002 05:20:14 -0500 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > this might be a chiken and egg thing, but what's the definition of a > "congestion-friendly" protocol? see rfc 2914 -- 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 Tue Feb 12 07:37:47 2002 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 HAA09630 for ; Tue, 12 Feb 2002 07:37:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16abqE-0006R5-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 06:15:22 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16abqC-0006Q0-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 06:15:20 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1CCEla31348; Tue, 12 Feb 2002 13:14:47 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA07240; Tue, 12 Feb 2002 13:14:47 +0100 Date: Tue, 12 Feb 2002 13:16:34 +0100 From: Juergen Quittek To: Reinaldo Penno , ipfix@net.doit.wisc.edu cc: "K.C. Norseth" Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Message-ID: <4202479722.1013519794@[192.168.102.164]> In-Reply-To: <4F973E944951D311B6660008C7917CF008982BB7@zsc4c008.us.nortel.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Reinaldo, --On 11 February 2002 22:10 -0800 Reinaldo Penno wrote: > > Hello, > > correct me if I'm wrong. Cisco proposal is that Capability > Negotiation does not appear in the draft at all (no matter > what compliance level). You are completely wrong. There is nothing like a Cisco proposal. This is Will's proposal. At the IETF we care about inidividual opinions ignoring the affiliation. Of course it is no coincident that people working together at the same company share some opinions, but still there is no Cisco voice. I also do not take all the statements you made as Nortel positions, but as your private ones. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > People can express opinions based on that. > > regards, > > Reinaldo -- 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 Tue Feb 12 07:53:19 2002 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 HAA09929 for ; Tue, 12 Feb 2002 07:53:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ac3C-0006ey-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 06:28:46 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ac3B-0006eL-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 06:28:45 -0600 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA23005; Tue, 12 Feb 2002 13:28:07 +0100 (MET) Message-ID: <3C690A62.94C9B0EF@cisco.com> Date: Tue, 12 Feb 2002 13:28:19 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: quittek@ccrle.nec.de CC: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] Re: [ipfix] Terminology suggestion References: <200202111529.g1BFTnb27134@bru-cse-222.cisco.com> <1013472804.3c685e2489dbc@citadel.mobility.ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, quittek@ccrle.nec.de wrote: > Hi Benoit, > > Benoit Claise wrote: > > > Hi Juergen, > > > > Here are my input on this terminology, as promised during the conf. > > call. > > > > Note that whether the definitions go into the requirements draft or in > > the architecture doesn't make any difference to me. This only thing of > > importance is that, if the requirement draft dissapears with the time, > > we don't want to loose the defintions. One solution is that the > > architecture document will have to repeat the definitions. > > > > > > > > see draft-ietf-ipfix-reqs-00.txt, section 1.1 > > > > I just copied the definition from draft-ietf-ipfix-reqs-00.txt for > > completeness. > > A flow is a set of packets passing an observation point in the > > network during a certain time interval. All packets belonging to a > > particular flow have a set of common properties derived from the > > data contained in the packet and from the packet treatment at the > > observation point. > > > > I would go a little bit further in the definition, by describing what a > > property coul be: > > A flow is defined as a set of packets passing an observation point in the > > network during a certain time interval. All packets belonging to a > > particular flow have a set of common properties. Each property is > > defined as the result of applying a function to the values of: > > > > a. one or more of packet header fields (eg. destination IP address) > > b. one or more properties of the packet itself (eg. packet length) > > c. one or more of fields derived from packet treatment (eg. AS > > number) > > > > A packet is defined to belong to a flow if it matches all the defined > > properties of the flow. > > Fine. But we should mention somewhere that also partial matches might be > sufficient. This was implicit in our definition, i.e. the function could be anything. If you still have problem, we can try to find another way to express it. > > > > > > > > 2.2. Observation Point > > > The observation point is a location in the network where IP packets > > > can be observed. Examples are a line to which a probe is attached, > > > a shared medium, such as an Ethernet-based LAN, a port of a router, > > > or an entire router with several ports. > > > > I agree with the definition above, but I would be more specific: > > The observation point is a location in the network where IP packets > > can be observed. Examples are a line to which a probe is attached, > > a shared medium, such as an Ethernet-based LAN, a port of a router, > > or an entire router with several ports. The observation is characterized > > by one or a set of interfaces (physical or logical) of the exporter. > > I think the last sentence is too restrictive. Why excluding packet > samplers sending samples from a remote observation point to a meter? 1. If you have in mind a port copy, then you copy the packets from one port to another port. So the observation point is an interface the packets are copied to. 2. If you have in mind (what we call on Cisco devices) the remote span, i.e. one device doing a port copy from own of its own port to a port to a remote device, then the observation point is an interface the packets are copied to. So what's in comon between 1. and 2., the interface. 3. Now, if you mean that you do packet sampling in one interface and send the results to another device (or observation domain), this is something which for me is not feasable, at least in my mind. Because the sampling function is part of metering process. So observation point is actually where you sample. Note: the sample mechanism part (or not) of the metering process is a principle we should agree before going much further. This concept must be part of the requirement document. Now, I'm trying to imagine one application where your scenario would be usefull.... A router composed of linecard 1 and linecard 2. We have 2 observation domains, 2 metering processes (one per line card). The packets observed on an interface of linecard1 would be sampled, but not exported to the collector. Instead they would be sent to the linecard 2 for latter processing with the flow locally seen. That's right that you could possibly do some more aggregations on line card 2... but do you have something specific in mind? Because I see one drawback here: the IPFIX flow records have to be processed twice within the router: once a "local export" to another observation domain, then the "real" export. And as you know, this costs in terms of CPU. > > > > Note: the exporter is defined below. > > > > > > 2.3. Trafic Flow Meter or Meter > > > A meter observes packets at one or more observation points. > > > It analyzes the content of the packets and maps them to flows. > > > For each observed flow the meter computes statistics and maintains > > > a flow record where it stores relevant flow infromation. > > > > I think that the concept of exporter makes more sense. > > And I believe that you are mixing 2 definitions: > > No, it's just the opposite: I want to separate meter and exporter. > > > - the exporter (ex: a router or a probe) > > - the metering process which analyzes the traffic > > So I would just remove this definition and leave the exporter/metering > > process > > as 2 definitions. > > > > * Exporter: The entity on which flows are measured and are > > exported. The exporter can be a router, a middlebox [2], or a > > traffic measurement probe. > > Here you are mixing metering and exporting. > > I see two function blocks in our architecture: The meter executing the > metering process and the exporter participating as sender in the flow > information export process. I understand you concern and see my definition is not too clear. In my mind, the metering process (on an observation point) will take care of sampling (if configured), creating flows AND exporting. But it doesn't mean that all of function must be enable; for example, you can create flows, observe them on the router and not exporting, just to quickly detect and block a DOS attack. NOTE: metering process composed or not of (sampling + flow creation + exporting) is something else we should quickly/clearly define in our definition, after a group agreement. Justification: why does the metering process also contain the export function? Again the example of a router composed of linecard 1 and linecard 2. We have 2 observation domains, 2 metering processes (one per line card). If the metering process on linecard 1 wants to export flow, it should according to your view, export first the flow to the router main board, which in turn will export it. You will use the CPU on the Line card 1 AND on the main board. Not very efficient with distributed system. And keep in mind that the main board will, according to your view, have to process the export flow records from all the line card. This looks like a perfect bottle neck! But by having the metering process also exporting, you will have a sequence ID per observation domain. This is an extra advantage. So if you miss flow records from a specific line card (because of CPU/memory constraints), you know that the other line card flow records are intact. And you can concentrate on the troubleshooting of just one line card. > > > > > > > > 2.4. Metering Process > > > The metering process includes all actions performed by a meter > > > with respect to observing packets, timestamping them, analyzing them, > > > mapping them to flows, computing flow statistics, detecting flow > > > expiration, and maintaining flow records. > > > > Measurement process that is carried out at the observation domain. > > The metering process includes all actions performed by a meter > > with respect to observing packets, timestamping them, analyzing them, > > mapping them to flows, computing flow statistics, detecting flow > > expiration, and maintaining flow records. > > > > Note: we had to introduce the concept of observation domain. > > > > * Observation Domain: The set of observation points which is the > > largest aggregatable set of flow information at the exporter is > > termed as an observation domain. The observation domain presents > > itself a unique ID to the collector for identifying the export > > packets generated by it. > > > > Example: The observation domian could be a router linecard, > > composed of several interfaces with each interface being an > > observation point. > > > > Why the concept of observation domain? > > Typically for a linecard on a router, which is an independant entity. > > So an exporter can be composed of several observation domains (read > > linecards). > > There is one metering process per observation domain (read linecard). > > You can do flow aggregations for these linecard flows but not between > > flows from different linecards. > > Well you are approaching my hierarchy: > exporter - meter - observation point Yes, that's it for the high level view. But as expressed above, the exporter is composed of one or more metering process, actually one per observation domain. And the exporter doesn't take care of the real flow records export which is defined part of the metering process. Now, whether to call it meter or observation domain, I looks to me than observation domain is more obvious but this is really a small detail. So based on an email from Ganesh on the same thread, Ganesh>Another point to note is that in draft-gsadasiv-ipfix-proposal-00.txt, Ganesh>we have made meter to observation point 1 to 1. a high level view would be: +------------------------------------------------------------------------------------+ | Exporter | | +---------------------------------------------------------------------+ | | | Observation Domain 1 | | | | +----------------------------+ | | | | | Metering Process | | | | | +----------------------------+ | | | | ^ | | | | | | | | | +--------+---------+ | | | | | | | | | | v v | | | | +--------------+ +--------------+ | | | | |Obsv Point 1| .. |Obsv Point k| | | | | +---------------+ +--------------+ | | | +---------------------------------------------------------------------+ | | .... | | +---------------------------------------------------------------------+ | | | Observation Domain L | | | | +----------------------------+ | | | | | Metering Process | | | | | +----------------------------+ | | | | ^ | | | | | | | | | +--------+---------+ | | | | | | | | | | v v | | | | +--------------+ +--------------+ | | | | |Obsv Point 1| .. |Obsv Point k| | | | | +---------------+ +--------------+ | | | +---------------------------------------------------------------------+ | |+-------------------------------------------------------------------------------------+ > > > The meter processes (and aggregates) packets from one or more > observation points and generates flow records. The sum of its > observation points outlines your observation domain. > The exporter exports flow records produced by one or more meters. > > First you say is "delete the term of meter" and then > "add the term of observation domain", because now we need it. > > If you just keep the meter, you do not need the observation > domain and you have an concept which is easier to understand > and which also matches the function blocks of the architecture. > > > Note: I agree that we are missing a high level picture of this in > > draft-gsadasiv-ipfix-proposal-00.txt > > > > > > > > 2.5. Flow Record > > > A flow record keeps information a flow including characteristic > > > properties of the flow, for example the source IP address, > > > and measured properties of the flow, for example the total number > > > of bytes of all packets of the flow. > > > > All packets belonging to a particular flow have a set of common > > properties. > > But the flow record doesn't necessarily have the notion of its own > > properties. > > I would remove the properties part. > > Here is the definition I would propose. > > > > * Flow Record: A flow record provides information about a specific > > flow that was measured at an observation point using a certain > > set of methods within an exporter. > > > > > > 2.6. Flow Information Exporter or Exporter > > > The exporter sends flow records created and maintained by one or > > > more meters to one or more data collectors. > > > > See my previous remark about exporter versus meter > > dito > > > > > > > 2.7. Flow Information Data Collector or Data Collector > > > The data collector receives flow records from one or more exporters. > > > The data collector might process or store received flow record, > > > but these actions are out of the scope of this document. > > > > OK. We called it just collector. But this is just a detail! > > Fine. What about the heading "Flow Information Collector or Collector" > and then renaming all data collectors into collectors? Fair enough. Regards, Benoit > > > Best wishes, > > Juergen > > > > > Regards, Benoit. > > > > > > > > > > 2.8. Flow Information Export > > > Flow information export denotes the process of transferring flow > > > records from an exporter to a data collector. > > > > > > > > > -- > > > 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/ > > > > > > > -- 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 Tue Feb 12 08:03:17 2002 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 IAA10071 for ; Tue, 12 Feb 2002 08:03:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16acFW-0006yn-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 06:41:30 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16acFT-0006xb-00; Tue, 12 Feb 2002 06:41:27 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1CCeka32074; Tue, 12 Feb 2002 13:40:47 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA07491; Tue, 12 Feb 2002 13:40:45 +0100 Date: Tue, 12 Feb 2002 13:42:32 +0100 From: Juergen Quittek To: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu cc: data , calato@riverstonenet.com Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Message-ID: <4204037903.1013521352@[192.168.102.164]> In-Reply-To: <4F973E944951D311B6660008C7917CF008982BCA@zsc4c008.us.nortel.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > > Comments: > > First ol all, would you guys mind if I rewrite this whole > section using the words "private side" and "public side" so > we align our nomenclature to RFC2663? Why risking further inconsistencies? Just refer to RFC 2663. All you want to introduce is well explained there. > > Also, the subsection titles refer to "virtual" this and that, > but the IEs refer to "outside" and "inside". So, we need some > unified terminology. I also think that using inside and outside > can cause confusion since the exporter/collector does not know > what's inside and outside. See draft-iab-unsaf-considerations-01.html I still have problems with "virtual", "inside", and "outside". This applies to firewalls and IPv4 NATs, but not to several other boxes. Why not using more general terms, such as "received" and "transmitted" or "original" and "modified". These terms would apply to a wider range of boxes (what is "inside" for a NAT-PT?). This would make the draft more independent from certain NAT/firewall scenarios and would be understandable even for people who do not care about NAT issues at all. Reinaldo, you talked about good writing. I think this includes avoiding irrelevant information (while still remaining clearly understandable). > other stuff. > [...] > > then in 5.11.18 and 5.11.9 > > "The Destination Virtual IE contains the destination address of > the flow/port as *received* by the Exporter" > > It should be *transmited* by the exporter, ie, you need an almost > complete 5-tuple set of IEs for the private side and for the > public side. You see, it already gets confusing. "received/original destination" would have been a much better choice of term compared to "virtual destination". Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Tue Feb 12 08:19:37 2002 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 IAA10328 for ; Tue, 12 Feb 2002 08:19:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16acbt-0007Z2-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 07:04:37 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16acFT-0006xb-00; Tue, 12 Feb 2002 06:41:27 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1CCeka32074; Tue, 12 Feb 2002 13:40:47 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA07491; Tue, 12 Feb 2002 13:40:45 +0100 Date: Tue, 12 Feb 2002 13:42:32 +0100 From: Juergen Quittek To: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu cc: data , calato@riverstonenet.com Subject: RE: [ipfix] Draft updates - Comments on the data model Message-ID: <4204037903.1013521352@[192.168.102.164]> In-Reply-To: <4F973E944951D311B6660008C7917CF008982BCA@zsc4c008.us.nortel.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > > Comments: > > First ol all, would you guys mind if I rewrite this whole > section using the words "private side" and "public side" so > we align our nomenclature to RFC2663? Why risking further inconsistencies? Just refer to RFC 2663. All you want to introduce is well explained there. > > Also, the subsection titles refer to "virtual" this and that, > but the IEs refer to "outside" and "inside". So, we need some > unified terminology. I also think that using inside and outside > can cause confusion since the exporter/collector does not know > what's inside and outside. See draft-iab-unsaf-considerations-01.html I still have problems with "virtual", "inside", and "outside". This applies to firewalls and IPv4 NATs, but not to several other boxes. Why not using more general terms, such as "received" and "transmitted" or "original" and "modified". These terms would apply to a wider range of boxes (what is "inside" for a NAT-PT?). This would make the draft more independent from certain NAT/firewall scenarios and would be understandable even for people who do not care about NAT issues at all. Reinaldo, you talked about good writing. I think this includes avoiding irrelevant information (while still remaining clearly understandable). > other stuff. > [...] > > then in 5.11.18 and 5.11.9 > > "The Destination Virtual IE contains the destination address of > the flow/port as *received* by the Exporter" > > It should be *transmited* by the exporter, ie, you need an almost > complete 5-tuple set of IEs for the private side and for the > public side. You see, it already gets confusing. "received/original destination" would have been a much better choice of term compared to "virtual destination". Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Tue Feb 12 08:38:21 2002 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 IAA10866 for ; Tue, 12 Feb 2002 08:38:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16acs1-000090-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 07:21:17 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16accT-0007ZH-00; Tue, 12 Feb 2002 07:05:13 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CD4Xm18823; Tue, 12 Feb 2002 07:04:33 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXCWQ>; Tue, 12 Feb 2002 05:04:31 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982BE9@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , "K.C. Norseth" , ipfix@net.doit.wisc.edu Cc: data , calato@riverstonenet.com Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 05:04:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3C5.CC2B6610" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3C5.CC2B6610 Content-Type: text/plain; charset="iso-8859-1" Juergen, comments inline.. >-----Original Message----- >From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >Sent: Tuesday, February 12, 2002 4:43 AM >To: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; >ipfix@net.doit.wisc.edu >Cc: data; calato@riverstonenet.com >Subject: RE: [ipfix] Draft updates - Comments on the data model > > >--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > >> >> Comments: >> >> First ol all, would you guys mind if I rewrite this whole >> section using the words "private side" and "public side" so >> we align our nomenclature to RFC2663? > >Why risking further inconsistencies? Just refer to RFC 2663. >All you want to introduce is well explained there. agreed. > >> >> Also, the subsection titles refer to "virtual" this and that, >> but the IEs refer to "outside" and "inside". So, we need some >> unified terminology. I also think that using inside and outside >> can cause confusion since the exporter/collector does not know >> what's inside and outside. See draft-iab-unsaf-considerations-01.html > >I still have problems with "virtual", "inside", and "outside". >This applies to firewalls and IPv4 NATs, but not to several other >boxes. Why not using more general terms, such as "received" and >"transmitted" or "original" and "modified". These terms would >apply to a wider range of boxes (what is "inside" for a NAT-PT?). well, then we are in agressive agreement(;-) That's exactly what I wrote. > >This would make the draft more independent from certain NAT/firewall >scenarios and would be understandable even for people who do not care >about NAT issues at all. > >Reinaldo, you talked about good writing. I think this includes >avoiding irrelevant information (while still remaining clearly >understandable). I would also prefer different terms. Anybody against changing? Paul? > >> other stuff. >> >[...] >> >> then in 5.11.18 and 5.11.9 >> >> "The Destination Virtual IE contains the destination address of >> the flow/port as *received* by the Exporter" >> >> It should be *transmited* by the exporter, ie, you need an almost >> complete 5-tuple set of IEs for the private side and for the >> public side. > >You see, it already gets confusing. "received/original destination" >would have been a much better choice of term compared to "virtual >destination". > > Juergen >-- >Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > ------_=_NextPart_001_01C1B3C5.CC2B6610 Content-Type: text/html; charset="iso-8859-1" RE: [ipfix] Draft updates - Comments on the data model

Juergen,

comments inline..

>-----Original Message-----
>From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>Sent: Tuesday, February 12, 2002 4:43 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth;
>ipfix@net.doit.wisc.edu
>Cc: data; calato@riverstonenet.com
>Subject: RE: [ipfix] Draft updates - Comments on the data model
>
>
>--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
>
>>
>> Comments:
>>
>> First ol all, would you guys mind if I rewrite this whole
>> section using the words "private side" and "public side" so
>> we align our nomenclature to RFC2663?
>
>Why risking further inconsistencies? Just refer to RFC 2663.
>All you want to introduce is well explained there.

agreed.
>
>>
>> Also, the subsection titles refer to "virtual" this and that,
>> but the IEs refer to "outside" and "inside". So, we need some
>> unified terminology. I also think that using inside and outside
>> can cause confusion since the exporter/collector does not know
>> what's inside and outside. See draft-iab-unsaf-considerations-01.html
>
>I still have problems with "virtual", "inside", and "outside".
>This applies to firewalls and IPv4 NATs, but not to several other
>boxes. Why not using more general terms, such as "received" and
>"transmitted" or "original" and "modified". These terms would
>apply to a wider range of boxes (what is "inside" for a NAT-PT?).

well, then we are in agressive agreement(;-) That's exactly what I wrote.

>
>This would make the draft more independent from certain NAT/firewall
>scenarios and would be understandable even for people who do not care
>about NAT issues at all.
>
>Reinaldo, you talked about good writing. I think this includes
>avoiding irrelevant information (while still remaining clearly
>understandable).

I would also prefer different terms. Anybody against changing? Paul?

>
>> other stuff.
>>
>[...]
>>
>> then in 5.11.18 and 5.11.9
>>
>> "The Destination Virtual IE contains the destination address of
>> the flow/port as *received* by the Exporter"
>>
>> It should be *transmited* by the exporter, ie, you need an almost
>> complete 5-tuple set of IEs for the private side and for the
>> public side.
>
>You see, it already gets confusing. "received/original destination"
>would have been a much better choice of term compared to "virtual
>destination".
>
>    Juergen
>--
>Juergen Quittek     quittek@ccrle.nec.de     Tel: +49 6221 90511-15
>NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
>Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>
>
>

------_=_NextPart_001_01C1B3C5.CC2B6610-- -- 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 Tue Feb 12 09:04:22 2002 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 JAA11883 for ; Tue, 12 Feb 2002 09:04:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16adHi-0000ff-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 07:47:50 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16adHf-0000fW-00; Tue, 12 Feb 2002 07:47:48 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id IAA16510; Tue, 12 Feb 2002 08:57:10 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma016448; Tue, 12 Feb 02 08:56:53 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXNZJ2>; Tue, 12 Feb 2002 08:46:28 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06A5@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Juergen Quittek'" , Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu Cc: data , "Calato, Paul" Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 08:46:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3CB.B8BEA780" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3CB.B8BEA780 Content-Type: text/plain There is a need to do some rewrite in the data, to make the source look like one document. Currently, the document is of 2 definit design styles. If someone can help with that, it would be great. Just let me know what section so we are not working on the same piece. I will be focusing on this myself. K.C. |-----Original Message----- |From: Juergen Quittek [mailto:quittek@ccrle.nec.de] |Sent: Tuesday, February 12, 2002 5:43 AM |To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu |Cc: data; Calato, Paul |Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on |the data model | | |--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: | |> |> Comments: |> |> First ol all, would you guys mind if I rewrite this whole section |> using the words "private side" and "public side" so we align our |> nomenclature to RFC2663? | |Why risking further inconsistencies? Just refer to RFC 2663. |All you want to introduce is well explained there. | |> |> Also, the subsection titles refer to "virtual" this and |that, but the |> IEs refer to "outside" and "inside". So, we need some unified |> terminology. I also think that using inside and outside can cause |> confusion since the exporter/collector does not know what's |inside and |> outside. See draft-iab-unsaf-considerations-01.html | |I still have problems with "virtual", "inside", and "outside". |This applies to firewalls and IPv4 NATs, but not to several |other boxes. Why not using more general terms, such as |"received" and "transmitted" or "original" and "modified". |These terms would apply to a wider range of boxes (what is |"inside" for a NAT-PT?). | |This would make the draft more independent from certain |NAT/firewall scenarios and would be understandable even for |people who do not care about NAT issues at all. | |Reinaldo, you talked about good writing. I think this includes |avoiding irrelevant information (while still remaining clearly |understandable). | |> other stuff. |> |[...] |> |> then in 5.11.18 and 5.11.9 |> |> "The Destination Virtual IE contains the destination address of the |> flow/port as *received* by the Exporter" |> |> It should be *transmited* by the exporter, ie, you need an almost |> complete 5-tuple set of IEs for the private side and for the public |> side. | |You see, it already gets confusing. "received/original |destination" would have been a much better choice of term |compared to "virtual destination". | | Juergen |-- |Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 |NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 |Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de | | | |-- |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/ | ------_=_NextPart_001_01C1B3CB.B8BEA780 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the = data model

There is a need to do some rewrite in the data, to = make the source look like one document.  Currently, the document = is of 2 definit design styles.  If someone can help with that, it = would be great.  Just let me know what section so we are not = working on the same piece.  I will be focusing on this = myself.

K.C.

|-----Original Message-----
|From: Juergen Quittek [mailto:quittek@ccrle.nec.de] =
|Sent: Tuesday, February 12, 2002 5:43 AM
|To: Reinaldo Penno; K.C. Norseth; = ipfix@net.doit.wisc.edu
|Cc: data; Calato, Paul
|Subject: [ipfix-data] RE: [ipfix] Draft updates - = Comments on
|the data model
|
|
|--On 12 February 2002 00:18 -0800 Reinaldo Penno = wrote:
|
|>
|> Comments:
|>
|> First ol all, would you guys mind if I rewrite = this whole section
|> using the words "private side" and = "public side" so we align our
|> nomenclature to RFC2663?
|
|Why risking further inconsistencies? Just refer to = RFC 2663.
|All you want to introduce is well explained = there.
|
|>
|> Also, the subsection titles refer to = "virtual" this and
|that, but the
|> IEs refer to "outside" and = "inside". So, we need some unified
|> terminology. I also think that using inside = and outside can cause
|> confusion since the exporter/collector does = not know what's
|inside and
|> outside. See = draft-iab-unsaf-considerations-01.html
|
|I still have problems with "virtual", = "inside", and "outside".
|This applies to firewalls and IPv4 NATs, but not to = several
|other boxes. Why not using more general terms, such = as
|"received" and "transmitted" or = "original" and "modified".
|These terms would apply to a wider range of boxes = (what is
|"inside" for a NAT-PT?).
|
|This would make the draft more independent from = certain
|NAT/firewall scenarios and would be understandable = even for
|people who do not care about NAT issues at = all.
|
|Reinaldo, you talked about good writing. I think = this includes
|avoiding irrelevant information (while still = remaining clearly
|understandable).
|
|> other stuff.
|>
|[...]
|>
|> then in 5.11.18 and 5.11.9
|>
|> "The Destination Virtual IE contains the = destination address of the
|> flow/port as *received* by the = Exporter"
|>
|> It should be *transmited* by the exporter, ie, = you need an almost
|> complete 5-tuple set of IEs for the private = side and for the public
|> side.
|
|You see, it already gets confusing. = "received/original
|destination" would have been a much better = choice of term
|compared to "virtual destination".
|
|    Juergen
|--
|Juergen Quittek     = quittek@ccrle.nec.de     Tel: +49 6221 = 90511-15
|NEC Europe Ltd.,    Network = Laboratories     Fax: +49 6221 90511-55
|Adenauerplatz 6, 69115 Heidelberg, = Germany   http://www.ccrle.nec.de
|
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1B3CB.B8BEA780-- -- 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 Tue Feb 12 09:11:24 2002 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 IAA10338 for ; Tue, 12 Feb 2002 08:19:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16accV-0007aP-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 07:05:15 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16accT-0007ZH-00; Tue, 12 Feb 2002 07:05:13 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CD4Xm18823; Tue, 12 Feb 2002 07:04:33 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXCWQ>; Tue, 12 Feb 2002 05:04:31 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982BE9@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , "K.C. Norseth" , ipfix@net.doit.wisc.edu Cc: data , calato@riverstonenet.com Subject: RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 05:04:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3C5.CC2B6610" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3C5.CC2B6610 Content-Type: text/plain; charset="iso-8859-1" Juergen, comments inline.. >-----Original Message----- >From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >Sent: Tuesday, February 12, 2002 4:43 AM >To: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; >ipfix@net.doit.wisc.edu >Cc: data; calato@riverstonenet.com >Subject: RE: [ipfix] Draft updates - Comments on the data model > > >--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > >> >> Comments: >> >> First ol all, would you guys mind if I rewrite this whole >> section using the words "private side" and "public side" so >> we align our nomenclature to RFC2663? > >Why risking further inconsistencies? Just refer to RFC 2663. >All you want to introduce is well explained there. agreed. > >> >> Also, the subsection titles refer to "virtual" this and that, >> but the IEs refer to "outside" and "inside". So, we need some >> unified terminology. I also think that using inside and outside >> can cause confusion since the exporter/collector does not know >> what's inside and outside. See draft-iab-unsaf-considerations-01.html > >I still have problems with "virtual", "inside", and "outside". >This applies to firewalls and IPv4 NATs, but not to several other >boxes. Why not using more general terms, such as "received" and >"transmitted" or "original" and "modified". These terms would >apply to a wider range of boxes (what is "inside" for a NAT-PT?). well, then we are in agressive agreement(;-) That's exactly what I wrote. > >This would make the draft more independent from certain NAT/firewall >scenarios and would be understandable even for people who do not care >about NAT issues at all. > >Reinaldo, you talked about good writing. I think this includes >avoiding irrelevant information (while still remaining clearly >understandable). I would also prefer different terms. Anybody against changing? Paul? > >> other stuff. >> >[...] >> >> then in 5.11.18 and 5.11.9 >> >> "The Destination Virtual IE contains the destination address of >> the flow/port as *received* by the Exporter" >> >> It should be *transmited* by the exporter, ie, you need an almost >> complete 5-tuple set of IEs for the private side and for the >> public side. > >You see, it already gets confusing. "received/original destination" >would have been a much better choice of term compared to "virtual >destination". > > Juergen >-- >Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > ------_=_NextPart_001_01C1B3C5.CC2B6610 Content-Type: text/html; charset="iso-8859-1" RE: [ipfix] Draft updates - Comments on the data model

Juergen,

comments inline..

>-----Original Message-----
>From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>Sent: Tuesday, February 12, 2002 4:43 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth;
>ipfix@net.doit.wisc.edu
>Cc: data; calato@riverstonenet.com
>Subject: RE: [ipfix] Draft updates - Comments on the data model
>
>
>--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
>
>>
>> Comments:
>>
>> First ol all, would you guys mind if I rewrite this whole
>> section using the words "private side" and "public side" so
>> we align our nomenclature to RFC2663?
>
>Why risking further inconsistencies? Just refer to RFC 2663.
>All you want to introduce is well explained there.

agreed.
>
>>
>> Also, the subsection titles refer to "virtual" this and that,
>> but the IEs refer to "outside" and "inside". So, we need some
>> unified terminology. I also think that using inside and outside
>> can cause confusion since the exporter/collector does not know
>> what's inside and outside. See draft-iab-unsaf-considerations-01.html
>
>I still have problems with "virtual", "inside", and "outside".
>This applies to firewalls and IPv4 NATs, but not to several other
>boxes. Why not using more general terms, such as "received" and
>"transmitted" or "original" and "modified". These terms would
>apply to a wider range of boxes (what is "inside" for a NAT-PT?).

well, then we are in agressive agreement(;-) That's exactly what I wrote.

>
>This would make the draft more independent from certain NAT/firewall
>scenarios and would be understandable even for people who do not care
>about NAT issues at all.
>
>Reinaldo, you talked about good writing. I think this includes
>avoiding irrelevant information (while still remaining clearly
>understandable).

I would also prefer different terms. Anybody against changing? Paul?

>
>> other stuff.
>>
>[...]
>>
>> then in 5.11.18 and 5.11.9
>>
>> "The Destination Virtual IE contains the destination address of
>> the flow/port as *received* by the Exporter"
>>
>> It should be *transmited* by the exporter, ie, you need an almost
>> complete 5-tuple set of IEs for the private side and for the
>> public side.
>
>You see, it already gets confusing. "received/original destination"
>would have been a much better choice of term compared to "virtual
>destination".
>
>    Juergen
>--
>Juergen Quittek     quittek@ccrle.nec.de     Tel: +49 6221 90511-15
>NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
>Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
>
>
>

------_=_NextPart_001_01C1B3C5.CC2B6610-- -- 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 Tue Feb 12 09:16:37 2002 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 JAA12445 for ; Tue, 12 Feb 2002 09:16:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16adSV-0000vU-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 07:58:59 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16adSS-0000vC-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 07:58:56 -0600 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA12077; Tue, 12 Feb 2002 14:58:21 +0100 (MET) Message-ID: <3C691F88.E3651638@cisco.com> Date: Tue, 12 Feb 2002 14:58:32 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-req@net.doit.wisc.edu, quittek@ccrle.nec.de Subject: Re: [ipfix-req] Re: [ipfix] Terminology suggestion References: <4F973E944951D311B6660008C7917CF008982B42@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo, > > > :There is one metering process per observation domain (read linecard). > > :You can do flow aggregations for these linecard flows but not > :between flows from different linecards. > : > > okay...So this means that if a flow comes into a linecard, gets > metered/exported, goes out to the other linecard, it can be metered > and exported again, right (assuming linecard have their own rules)? Possibly. Regards, Benoit -- 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 Tue Feb 12 09:24:50 2002 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 JAA12740 for ; Tue, 12 Feb 2002 09:24:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16adZL-00013p-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 08:06:03 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16adHf-0000fW-00; Tue, 12 Feb 2002 07:47:48 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id IAA16510; Tue, 12 Feb 2002 08:57:10 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma016448; Tue, 12 Feb 02 08:56:53 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXNZJ2>; Tue, 12 Feb 2002 08:46:28 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06A5@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Juergen Quittek'" , Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu Cc: data , "Calato, Paul" Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 08:46:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3CB.B8BEA780" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3CB.B8BEA780 Content-Type: text/plain There is a need to do some rewrite in the data, to make the source look like one document. Currently, the document is of 2 definit design styles. If someone can help with that, it would be great. Just let me know what section so we are not working on the same piece. I will be focusing on this myself. K.C. |-----Original Message----- |From: Juergen Quittek [mailto:quittek@ccrle.nec.de] |Sent: Tuesday, February 12, 2002 5:43 AM |To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu |Cc: data; Calato, Paul |Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on |the data model | | |--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: | |> |> Comments: |> |> First ol all, would you guys mind if I rewrite this whole section |> using the words "private side" and "public side" so we align our |> nomenclature to RFC2663? | |Why risking further inconsistencies? Just refer to RFC 2663. |All you want to introduce is well explained there. | |> |> Also, the subsection titles refer to "virtual" this and |that, but the |> IEs refer to "outside" and "inside". So, we need some unified |> terminology. I also think that using inside and outside can cause |> confusion since the exporter/collector does not know what's |inside and |> outside. See draft-iab-unsaf-considerations-01.html | |I still have problems with "virtual", "inside", and "outside". |This applies to firewalls and IPv4 NATs, but not to several |other boxes. Why not using more general terms, such as |"received" and "transmitted" or "original" and "modified". |These terms would apply to a wider range of boxes (what is |"inside" for a NAT-PT?). | |This would make the draft more independent from certain |NAT/firewall scenarios and would be understandable even for |people who do not care about NAT issues at all. | |Reinaldo, you talked about good writing. I think this includes |avoiding irrelevant information (while still remaining clearly |understandable). | |> other stuff. |> |[...] |> |> then in 5.11.18 and 5.11.9 |> |> "The Destination Virtual IE contains the destination address of the |> flow/port as *received* by the Exporter" |> |> It should be *transmited* by the exporter, ie, you need an almost |> complete 5-tuple set of IEs for the private side and for the public |> side. | |You see, it already gets confusing. "received/original |destination" would have been a much better choice of term |compared to "virtual destination". | | Juergen |-- |Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 |NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 |Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de | | | |-- |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/ | ------_=_NextPart_001_01C1B3CB.B8BEA780 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the = data model

There is a need to do some rewrite in the data, to = make the source look like one document.  Currently, the document = is of 2 definit design styles.  If someone can help with that, it = would be great.  Just let me know what section so we are not = working on the same piece.  I will be focusing on this = myself.

K.C.

|-----Original Message-----
|From: Juergen Quittek [mailto:quittek@ccrle.nec.de] =
|Sent: Tuesday, February 12, 2002 5:43 AM
|To: Reinaldo Penno; K.C. Norseth; = ipfix@net.doit.wisc.edu
|Cc: data; Calato, Paul
|Subject: [ipfix-data] RE: [ipfix] Draft updates - = Comments on
|the data model
|
|
|--On 12 February 2002 00:18 -0800 Reinaldo Penno = wrote:
|
|>
|> Comments:
|>
|> First ol all, would you guys mind if I rewrite = this whole section
|> using the words "private side" and = "public side" so we align our
|> nomenclature to RFC2663?
|
|Why risking further inconsistencies? Just refer to = RFC 2663.
|All you want to introduce is well explained = there.
|
|>
|> Also, the subsection titles refer to = "virtual" this and
|that, but the
|> IEs refer to "outside" and = "inside". So, we need some unified
|> terminology. I also think that using inside = and outside can cause
|> confusion since the exporter/collector does = not know what's
|inside and
|> outside. See = draft-iab-unsaf-considerations-01.html
|
|I still have problems with "virtual", = "inside", and "outside".
|This applies to firewalls and IPv4 NATs, but not to = several
|other boxes. Why not using more general terms, such = as
|"received" and "transmitted" or = "original" and "modified".
|These terms would apply to a wider range of boxes = (what is
|"inside" for a NAT-PT?).
|
|This would make the draft more independent from = certain
|NAT/firewall scenarios and would be understandable = even for
|people who do not care about NAT issues at = all.
|
|Reinaldo, you talked about good writing. I think = this includes
|avoiding irrelevant information (while still = remaining clearly
|understandable).
|
|> other stuff.
|>
|[...]
|>
|> then in 5.11.18 and 5.11.9
|>
|> "The Destination Virtual IE contains the = destination address of the
|> flow/port as *received* by the = Exporter"
|>
|> It should be *transmited* by the exporter, ie, = you need an almost
|> complete 5-tuple set of IEs for the private = side and for the public
|> side.
|
|You see, it already gets confusing. = "received/original
|destination" would have been a much better = choice of term
|compared to "virtual destination".
|
|    Juergen
|--
|Juergen Quittek     = quittek@ccrle.nec.de     Tel: +49 6221 = 90511-15
|NEC Europe Ltd.,    Network = Laboratories     Fax: +49 6221 90511-55
|Adenauerplatz 6, 69115 Heidelberg, = Germany   http://www.ccrle.nec.de
|
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1B3CB.B8BEA780-- -- 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 Tue Feb 12 09:28:51 2002 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 JAA13009 for ; Tue, 12 Feb 2002 09:28:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16adYU-000136-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 08:05:10 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16adYT-00012H-00 for ipfix-data@net.doit.wisc.edu; Tue, 12 Feb 2002 08:05:09 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CE3sm02416; Tue, 12 Feb 2002 08:03:55 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXDJQ>; Tue, 12 Feb 2002 06:03:52 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982C08@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "Norseth, KC" , "'Juergen Quittek'" , "K.C. Norseth" Cc: data , "Calato, Paul" Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 06:03:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3CE.17A41A30" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3CE.17A41A30 Content-Type: text/plain; charset="iso-8859-1" Hello K.C. I cannot access the URL of the drafts anymore... Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also. regards, Reinaldo -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Tuesday, February 12, 2002 5:47 AM To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model There is a need to do some rewrite in the data, to make the source look like one document. Currently, the document is of 2 definit design styles. If someone can help with that, it would be great. Just let me know what section so we are not working on the same piece. I will be focusing on this myself. K.C. |-----Original Message----- |From: Juergen Quittek [ mailto:quittek@ccrle.nec.de ] |Sent: Tuesday, February 12, 2002 5:43 AM |To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu |Cc: data; Calato, Paul |Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on |the data model | | |--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: | |> |> Comments: |> |> First ol all, would you guys mind if I rewrite this whole section |> using the words "private side" and "public side" so we align our |> nomenclature to RFC2663? | |Why risking further inconsistencies? Just refer to RFC 2663. |All you want to introduce is well explained there. | |> |> Also, the subsection titles refer to "virtual" this and |that, but the |> IEs refer to "outside" and "inside". So, we need some unified |> terminology. I also think that using inside and outside can cause |> confusion since the exporter/collector does not know what's |inside and |> outside. See draft-iab-unsaf-considerations-01.html | |I still have problems with "virtual", "inside", and "outside". |This applies to firewalls and IPv4 NATs, but not to several |other boxes. Why not using more general terms, such as |"received" and "transmitted" or "original" and "modified". |These terms would apply to a wider range of boxes (what is |"inside" for a NAT-PT?). | |This would make the draft more independent from certain |NAT/firewall scenarios and would be understandable even for |people who do not care about NAT issues at all. | |Reinaldo, you talked about good writing. I think this includes |avoiding irrelevant information (while still remaining clearly |understandable). | |> other stuff. |> |[...] |> |> then in 5.11.18 and 5.11.9 |> |> "The Destination Virtual IE contains the destination address of the |> flow/port as *received* by the Exporter" |> |> It should be *transmited* by the exporter, ie, you need an almost |> complete 5-tuple set of IEs for the private side and for the public |> side. | |You see, it already gets confusing. "received/original |destination" would have been a much better choice of term |compared to "virtual destination". | | Juergen |-- |Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 |NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 |Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de | | | |-- |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/ | ------_=_NextPart_001_01C1B3CE.17A41A30 Content-Type: text/html; charset="iso-8859-1" RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model
Hello K.C.
 
I cannot access the URL of the drafts anymore...
 
Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also.
 
regards,
 
Reinaldo
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Tuesday, February 12, 2002 5:47 AM
To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

There is a need to do some rewrite in the data, to make the source look like one document.  Currently, the document is of 2 definit design styles.  If someone can help with that, it would be great.  Just let me know what section so we are not working on the same piece.  I will be focusing on this myself.

K.C.

|-----Original Message-----
|From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
|Sent: Tuesday, February 12, 2002 5:43 AM
|To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu
|Cc: data; Calato, Paul
|Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on
|the data model
|
|
|--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
|
|>
|> Comments:
|>
|> First ol all, would you guys mind if I rewrite this whole section
|> using the words "private side" and "public side" so we align our
|> nomenclature to RFC2663?
|
|Why risking further inconsistencies? Just refer to RFC 2663.
|All you want to introduce is well explained there.
|
|>
|> Also, the subsection titles refer to "virtual" this and
|that, but the
|> IEs refer to "outside" and "inside". So, we need some unified
|> terminology. I also think that using inside and outside can cause
|> confusion since the exporter/collector does not know what's
|inside and
|> outside. See draft-iab-unsaf-considerations-01.html
|
|I still have problems with "virtual", "inside", and "outside".
|This applies to firewalls and IPv4 NATs, but not to several
|other boxes. Why not using more general terms, such as
|"received" and "transmitted" or "original" and "modified".
|These terms would apply to a wider range of boxes (what is
|"inside" for a NAT-PT?).
|
|This would make the draft more independent from certain
|NAT/firewall scenarios and would be understandable even for
|people who do not care about NAT issues at all.
|
|Reinaldo, you talked about good writing. I think this includes
|avoiding irrelevant information (while still remaining clearly
|understandable).
|
|> other stuff.
|>
|[...]
|>
|> then in 5.11.18 and 5.11.9
|>
|> "The Destination Virtual IE contains the destination address of the
|> flow/port as *received* by the Exporter"
|>
|> It should be *transmited* by the exporter, ie, you need an almost
|> complete 5-tuple set of IEs for the private side and for the public
|> side.
|
|You see, it already gets confusing. "received/original
|destination" would have been a much better choice of term
|compared to "virtual destination".
|
|    Juergen
|--
|Juergen Quittek     quittek@ccrle.nec.de     Tel: +49 6221 90511-15
|NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
|Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
|
|
|
|--
|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/
|

------_=_NextPart_001_01C1B3CE.17A41A30-- -- 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 Tue Feb 12 10:07:20 2002 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 KAA14296 for ; Tue, 12 Feb 2002 10:07:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aeCK-0001tM-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 08:46:20 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aeCH-0001tC-00 for ipfix-data@net.doit.wisc.edu; Tue, 12 Feb 2002 08:46:17 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id JAA21783; Tue, 12 Feb 2002 09:55:40 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma021756; Tue, 12 Feb 02 09:54:56 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXN534>; Tue, 12 Feb 2002 09:44:29 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06A6@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Reinaldo Penno'" , "'Juergen Quittek'" , "K.C. Norseth" Cc: data , "Calato, Paul" Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 09:44:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3D3.D3B8CEA0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3D3.D3B8CEA0 Content-Type: text/plain Hi Reinaldo, sounds good. 5.12 - NAT 5.14.4 - Internal Queue Priority 5.10.1-2 - netmask 5.9.3-4 - ATM & Frame Relay 5.11.4 - VLAN. (I duped VLAN, it is also 5.14.11), just make one. Sorry on the URL down. It has small bandwidth and unfortunately, if it doesn't come back up on its own, It will be down until I can get to it this afternoon. I can send anyone the drafts if they cannot access my url. I have the documents in both Word and Text format. K.C. -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 12, 2002 7:04 AM To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Hello K.C. I cannot access the URL of the drafts anymore... Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also. regards, Reinaldo -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Tuesday, February 12, 2002 5:47 AM To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model There is a need to do some rewrite in the data, to make the source look like one document. Currently, the document is of 2 definit design styles. If someone can help with that, it would be great. Just let me know what section so we are not working on the same piece. I will be focusing on this myself. K.C. |-----Original Message----- |From: Juergen Quittek [mailto:quittek@ccrle.nec.de ] |Sent: Tuesday, February 12, 2002 5:43 AM |To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu |Cc: data; Calato, Paul |Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on |the data model | | |--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: | |> |> Comments: |> |> First ol all, would you guys mind if I rewrite this whole section |> using the words "private side" and "public side" so we align our |> nomenclature to RFC2663? | |Why risking further inconsistencies? Just refer to RFC 2663. |All you want to introduce is well explained there. | |> |> Also, the subsection titles refer to "virtual" this and |that, but the |> IEs refer to "outside" and "inside". So, we need some unified |> terminology. I also think that using inside and outside can cause |> confusion since the exporter/collector does not know what's |inside and |> outside. See draft-iab-unsaf-considerations-01.html | |I still have problems with "virtual", "inside", and "outside". |This applies to firewalls and IPv4 NATs, but not to several |other boxes. Why not using more general terms, such as |"received" and "transmitted" or "original" and "modified". |These terms would apply to a wider range of boxes (what is |"inside" for a NAT-PT?). | |This would make the draft more independent from certain |NAT/firewall scenarios and would be understandable even for |people who do not care about NAT issues at all. | |Reinaldo, you talked about good writing. I think this includes |avoiding irrelevant information (while still remaining clearly |understandable). | |> other stuff. |> |[...] |> |> then in 5.11.18 and 5.11.9 |> |> "The Destination Virtual IE contains the destination address of the |> flow/port as *received* by the Exporter" |> |> It should be *transmited* by the exporter, ie, you need an almost |> complete 5-tuple set of IEs for the private side and for the public |> side. | |You see, it already gets confusing. "received/original |destination" would have been a much better choice of term |compared to "virtual destination". | | Juergen |-- |Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 |NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 |Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de | | | |-- |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/ | ------_=_NextPart_001_01C1B3D3.D3B8CEA0 Content-Type: text/html Message
Hi Reinaldo,
 
sounds good.
 
5.12 - NAT
5.14.4 - Internal Queue Priority
5.10.1-2 - netmask
5.9.3-4 - ATM & Frame Relay
5.11.4 - VLAN.  (I duped VLAN, it is also 5.14.11), just make one.
 
Sorry on the URL down.  It has small bandwidth and unfortunately, if it doesn't come back up on its own, It will be down until I can get to it this afternoon. I can send anyone the drafts if they cannot access my url.  I have the documents in both Word and Text format.
 
K.C.
 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, February 12, 2002 7:04 AM
To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

Hello K.C.
 
I cannot access the URL of the drafts anymore...
 
Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also.
 
regards,
 
Reinaldo
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Tuesday, February 12, 2002 5:47 AM
To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

There is a need to do some rewrite in the data, to make the source look like one document.  Currently, the document is of 2 definit design styles.  If someone can help with that, it would be great.  Just let me know what section so we are not working on the same piece.  I will be focusing on this myself.

K.C.

|-----Original Message-----
|From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
|Sent: Tuesday, February 12, 2002 5:43 AM
|To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu
|Cc: data; Calato, Paul
|Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on
|the data model
|
|
|--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
|
|>
|> Comments:
|>
|> First ol all, would you guys mind if I rewrite this whole section
|> using the words "private side" and "public side" so we align our
|> nomenclature to RFC2663?
|
|Why risking further inconsistencies? Just refer to RFC 2663.
|All you want to introduce is well explained there.
|
|>
|> Also, the subsection titles refer to "virtual" this and
|that, but the
|> IEs refer to "outside" and "inside". So, we need some unified
|> terminology. I also think that using inside and outside can cause
|> confusion since the exporter/collector does not know what's
|inside and
|> outside. See draft-iab-unsaf-considerations-01.html
|
|I still have problems with "virtual", "inside", and "outside".
|This applies to firewalls and IPv4 NATs, but not to several
|other boxes. Why not using more general terms, such as
|"received" and "transmitted" or "original" and "modified".
|These terms would apply to a wider range of boxes (what is
|"inside" for a NAT-PT?).
|
|This would make the draft more independent from certain
|NAT/firewall scenarios and would be understandable even for
|people who do not care about NAT issues at all.
|
|Reinaldo, you talked about good writing. I think this includes
|avoiding irrelevant information (while still remaining clearly
|understandable).
|
|> other stuff.
|>
|[...]
|>
|> then in 5.11.18 and 5.11.9
|>
|> "The Destination Virtual IE contains the destination address of the
|> flow/port as *received* by the Exporter"
|>
|> It should be *transmited* by the exporter, ie, you need an almost
|> complete 5-tuple set of IEs for the private side and for the public
|> side.
|
|You see, it already gets confusing. "received/original
|destination" would have been a much better choice of term
|compared to "virtual destination".
|
|    Juergen
|--
|Juergen Quittek     quittek@ccrle.nec.de     Tel: +49 6221 90511-15
|NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
|Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
|
|
|
|--
|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/
|

------_=_NextPart_001_01C1B3D3.D3B8CEA0-- -- 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 Tue Feb 12 10:15:06 2002 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 KAA14710 for ; Tue, 12 Feb 2002 10:15:05 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aeJE-00025D-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 08:53:28 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aeJC-00023A-00 for ipfix-data@net.doit.wisc.edu; Tue, 12 Feb 2002 08:53:26 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CEqFm12670; Tue, 12 Feb 2002 08:52:15 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFX1GJ>; Tue, 12 Feb 2002 06:52:13 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982C31@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "Norseth, KC" , "'Juergen Quittek'" , "K.C. Norseth" Cc: data , "Calato, Paul" Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 06:52:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3D4.D67D7770" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3D4.D67D7770 Content-Type: text/plain; charset="iso-8859-1" Hello K.C. The NAT part includes 5.11.6, 5.11.7, 5.11.8 and 5.11.9. Can you send me both docs in word format? thanks, Reinaldo -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Tuesday, February 12, 2002 6:45 AM To: Penno, Reinaldo [SC9:T327:EXCH]; 'Juergen Quittek'; K.C. Norseth Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Hi Reinaldo, sounds good. 5.12 - NAT 5.14.4 - Internal Queue Priority 5.10.1-2 - netmask 5.9.3-4 - ATM & Frame Relay 5.11.4 - VLAN. (I duped VLAN, it is also 5.14.11), just make one. Sorry on the URL down. It has small bandwidth and unfortunately, if it doesn't come back up on its own, It will be down until I can get to it this afternoon. I can send anyone the drafts if they cannot access my url. I have the documents in both Word and Text format. K.C. -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 12, 2002 7:04 AM To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Hello K.C. I cannot access the URL of the drafts anymore... Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also. regards, Reinaldo -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Tuesday, February 12, 2002 5:47 AM To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model There is a need to do some rewrite in the data, to make the source look like one document. Currently, the document is of 2 definit design styles. If someone can help with that, it would be great. Just let me know what section so we are not working on the same piece. I will be focusing on this myself. K.C. |-----Original Message----- |From: Juergen Quittek [ mailto:quittek@ccrle.nec.de ] |Sent: Tuesday, February 12, 2002 5:43 AM |To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu |Cc: data; Calato, Paul |Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on |the data model | | |--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: | |> |> Comments: |> |> First ol all, would you guys mind if I rewrite this whole section |> using the words "private side" and "public side" so we align our |> nomenclature to RFC2663? | |Why risking further inconsistencies? Just refer to RFC 2663. |All you want to introduce is well explained there. | |> |> Also, the subsection titles refer to "virtual" this and |that, but the |> IEs refer to "outside" and "inside". So, we need some unified |> terminology. I also think that using inside and outside can cause |> confusion since the exporter/collector does not know what's |inside and |> outside. See draft-iab-unsaf-considerations-01.html | |I still have problems with "virtual", "inside", and "outside". |This applies to firewalls and IPv4 NATs, but not to several |other boxes. Why not using more general terms, such as |"received" and "transmitted" or "original" and "modified". |These terms would apply to a wider range of boxes (what is |"inside" for a NAT-PT?). | |This would make the draft more independent from certain |NAT/firewall scenarios and would be understandable even for |people who do not care about NAT issues at all. | |Reinaldo, you talked about good writing. I think this includes |avoiding irrelevant information (while still remaining clearly |understandable). | |> other stuff. |> |[...] |> |> then in 5.11.18 and 5.11.9 |> |> "The Destination Virtual IE contains the destination address of the |> flow/port as *received* by the Exporter" |> |> It should be *transmited* by the exporter, ie, you need an almost |> complete 5-tuple set of IEs for the private side and for the public |> side. | |You see, it already gets confusing. "received/original |destination" would have been a much better choice of term |compared to "virtual destination". | | Juergen |-- |Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 |NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 |Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de | | | |-- |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/ | ------_=_NextPart_001_01C1B3D4.D67D7770 Content-Type: text/html; charset="iso-8859-1" Message
Hello K.C.
 
The NAT part includes 5.11.6, 5.11.7, 5.11.8 and 5.11.9. Can you send me both docs in word format?
 
thanks,
 
Reinaldo
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Tuesday, February 12, 2002 6:45 AM
To: Penno, Reinaldo [SC9:T327:EXCH]; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

Hi Reinaldo,
 
sounds good.
 
5.12 - NAT
5.14.4 - Internal Queue Priority
5.10.1-2 - netmask
5.9.3-4 - ATM & Frame Relay
5.11.4 - VLAN.  (I duped VLAN, it is also 5.14.11), just make one.
 
Sorry on the URL down.  It has small bandwidth and unfortunately, if it doesn't come back up on its own, It will be down until I can get to it this afternoon. I can send anyone the drafts if they cannot access my url.  I have the documents in both Word and Text format.
 
K.C.
 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, February 12, 2002 7:04 AM
To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

Hello K.C.
 
I cannot access the URL of the drafts anymore...
 
Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also.
 
regards,
 
Reinaldo
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Tuesday, February 12, 2002 5:47 AM
To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

There is a need to do some rewrite in the data, to make the source look like one document.  Currently, the document is of 2 definit design styles.  If someone can help with that, it would be great.  Just let me know what section so we are not working on the same piece.  I will be focusing on this myself.

K.C.

|-----Original Message-----
|From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
|Sent: Tuesday, February 12, 2002 5:43 AM
|To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu
|Cc: data; Calato, Paul
|Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on
|the data model
|
|
|--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
|
|>
|> Comments:
|>
|> First ol all, would you guys mind if I rewrite this whole section
|> using the words "private side" and "public side" so we align our
|> nomenclature to RFC2663?
|
|Why risking further inconsistencies? Just refer to RFC 2663.
|All you want to introduce is well explained there.
|
|>
|> Also, the subsection titles refer to "virtual" this and
|that, but the
|> IEs refer to "outside" and "inside". So, we need some unified
|> terminology. I also think that using inside and outside can cause
|> confusion since the exporter/collector does not know what's
|inside and
|> outside. See draft-iab-unsaf-considerations-01.html
|
|I still have problems with "virtual", "inside", and "outside".
|This applies to firewalls and IPv4 NATs, but not to several
|other boxes. Why not using more general terms, such as
|"received" and "transmitted" or "original" and "modified".
|These terms would apply to a wider range of boxes (what is
|"inside" for a NAT-PT?).
|
|This would make the draft more independent from certain
|NAT/firewall scenarios and would be understandable even for
|people who do not care about NAT issues at all.
|
|Reinaldo, you talked about good writing. I think this includes
|avoiding irrelevant information (while still remaining clearly
|understandable).
|
|> other stuff.
|>
|[...]
|>
|> then in 5.11.18 and 5.11.9
|>
|> "The Destination Virtual IE contains the destination address of the
|> flow/port as *received* by the Exporter"
|>
|> It should be *transmited* by the exporter, ie, you need an almost
|> complete 5-tuple set of IEs for the private side and for the public
|> side.
|
|You see, it already gets confusing. "received/original
|destination" would have been a much better choice of term
|compared to "virtual destination".
|
|    Juergen
|--
|Juergen Quittek     quittek@ccrle.nec.de     Tel: +49 6221 90511-15
|NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
|Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
|
|
|
|--
|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/
|

------_=_NextPart_001_01C1B3D4.D67D7770-- -- 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 Tue Feb 12 10:19:01 2002 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 KAA14815 for ; Tue, 12 Feb 2002 10:19:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aeOm-0002Dk-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 08:59:12 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aeOj-0002Dc-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 08:59:09 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id KAA22761 for ; Tue, 12 Feb 2002 10:08:33 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma022736; Tue, 12 Feb 02 10:07:44 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXN5ZQ>; Tue, 12 Feb 2002 09:57:18 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06A8@slc-exc1.ctron.com> From: "Norseth, KC" To: "'ipfix@net.doit.wisc.edu'" Subject: [ipfix] New Drafts enclosed Date: Tue, 12 Feb 2002 09:56:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B3D5.794697C0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1B3D5.794697C0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3D5.794697C0" ------_=_NextPart_001_01C1B3D5.794697C0 Content-Type: text/plain My domain went down this morning, and will be unavailable for the day. I have enclosed the drafts here in text format for anyone who had not gotten them yet. If anyone wants them in word format, let me know and I will send them. K.C. <> <> K.C. Norseth Firmware Engineering - Routing Enterasys Networks Phone: 801.887.9823 FAX: 801.972.5789 Email: knorseth@enterasys.com www: http://www.enterasys.com <> ------_=_NextPart_001_01C1B3D5.794697C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable New Drafts enclosed

My domain went down this morning, and = will be unavailable for the day.  I have enclosed the drafts here = in text format for anyone who had not gotten them yet.  If anyone = wants them in word format, let me know and I will send them.

K.C.
= <<draft-ietf-ipfix-data-00.txt>> = <<draft-ietf-ipfix-architecture-00.txt>>

K.C. = Norseth
Firmware = Engineering -  Routing
Enterasys = Networks
   Phone: 801.887.9823
   = FAX:    801.972.5789
   = Email:   knorseth@enterasys.com
   = www:    http://www.enterasys.com=
<<Norseth, = KC.vcf>>

------_=_NextPart_001_01C1B3D5.794697C0-- ------_=_NextPart_000_01C1B3D5.794697C0 Content-Type: text/plain; name="draft-ietf-ipfix-data-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ipfix-data-00.txt" Content-Transfer-Encoding: quoted-printable IPFIX working group Internet Draft draft-ietf-ipfix-data-00.txt Expires: August 2002 Benoit Claise Cisco Systems P. Calato Riverstone Networks Inc Ram Gopal Man Li Nokia =20 K.C. Norseth Enterasys Networks Reinaldo Penno NortelNetworks J. Quittek NEC Europe Ltd. Ganesh Sadasivan Cisco Systems, Inc.Kevin Zhang XACCT Technologies Tanja Zseby FhI FOKUS February 2002 IPFIX Architecture Architecture Model for IP Flow Information Export draft-ietf-ipfix-data-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all = provisions of Section 10 of RFC2026 [1].=20 Internet-Drafts are working documents of the Internet Engineering Task = Force (IETF), its areas, and its working groups. Note that other groups = may also distribute working documents as Internet-Drafts. = Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet- Drafts as reference material = or to cite them other than as "work in progress."=20 The list of current Internet-Drafts can be accessed at = http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at = http://www.ietf.org/shadow.html. Abstract This document defines architecture for scalable monitoring, measuring = and exporting IP flow information to collectors. =20 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are to be interpreted as described in RFC-2119 [1]. 1. Introduction 5 2. Scope 5 3. Terminology 5 4. Information Model 5 4.1. Attributes related to IP Packet Header 6 4.2. Attributes Related to Measurement 6 4.3. Attributes Related to Flow Definition 6 4.4. Attributes related to Upper Layers 6 4.5. IPFIX Template 7 4.5.1. Template Negotiation 7 5. Information Elements 7 5.1. Packet Management 7 5.1.1. Version Number 7 5.1.2. FLOWS 7 5.1.3. FLOW_LABEL 7 5.2. IP Address 7 5.2.1. Source Address IE 7 5.2.2. Destination Address IE 8 5.2.3. NEXT_HOP_IP IE 8 5.3. Time Stamps 8 5.3.1. Time IE 8 5.3.2. UTC Time IE 8 5.3.3. Delta Time IE 8 5.4. Service Types 8 5.4.1. Class of Service IE 8 5.4.2. TCP Control Bits IE 9 5.4.3. Protocol Identifier IE 9 5.4.4. Source Exporter [ is that the right term?? PAC] Address IE 9 5.5. Flow State IE 9 5.6. Statistical Elements 9 5.6.1. Byte Count IE 10 5.6.2. Packet Count IE 10 5.6.3. Dropped Byte Count IE 10 5.6.4. Dropped Packet Count IE 10 5.7. Port Information 11 5.7.1. Source Port IE 11 5.7.2. Destination Port IE 11 5.8. Autonomous System (AS) 11 5.8.1. Source AS IE 11 5.8.2. Destination AS IE 11 5.8.3. Next Hop AS IE 11 5.9. IfIndexes and Interfaces 11 5.9.1. Ingress Port IE 11 5.9.2. Egress Port IE 11 5.9.3. Egress ATM Subinterface 12 5.9.4. EGRESS_FRAME_RELAY_SUBINTERFACE IE 12 5.10. NetMasks 12 5.10.1. Source Address Netmask IE 12 5.10.2. Destination Address Netmask IE 12 5.11. BGP & Vlan IE's 12 5.11.1. Destination BGP Community IE 12 5.11.2. Source BGP Community IE 12 5.11.3. BGP_NEXT_HOP 12 5.11.4. Source VLAN ID IE 12 5.11.5. Destination VLAN ID IE 13 5.11.6. Source Virtual Address IE 13 5.11.7. Source Virtual Port IE 13 5.11.8. Destination Virtual Address IE 14 5.11.9. Destination Virtual Port IE 14 5.12. NAT 14 5.12.1. INSIDE_L4_SRC 14 5.12.2. INSIDE_IPV4_SRC_ADDR 14 5.12.3. INSIDE_L4_DST_PORT 14 5.12.4. INSIDE_IPV4_DST_ADDR 14 5.12.5. INSIDE_IPV6_SRC_ADDR 14 5.12.6. INSIDE_IPV6_DST_ADDR 14 5.12.7. OUTSIDE_L4_SRC_PORT 14 5.12.8. OUTSIDE_IPV4_SRC_ADDR 15 5.12.9. OUTSIDE_L4_DST_PORT 15 5.12.10. OUTSIDE_IPV4_DST_ADDR 15 5.12.11. OUTSIDE_IPV6_SRC_ADDR 15 5.12.12. OUTSIDE_IPV6_DST_ADDR 15 5.13. Vendor Specific IE 15 5.14. Misc. Information Elements 15 5.14.1. Flow Label IE 15 5.14.2. Flow Direction 15 5.14.3. Fragment ID IE 16 5.14.4. Internal queue priority 16 5.14.5. Global VPN Identifier IE 16 5.14.6. IPM_DPKTS 16 5.14.7. IPM_DOCTETS 16 5.14.8. LAST_SWITCHED 16 5.14.9. FIRST_SWITCHED 16 5.14.10. MAC_ADDR 16 5.14.11. VLAN_ID 16 5.14.12. ICMP_TYPE 16 5.14.13. IGMP_TYPE 16 5.15. Sampling 17 5.15.1. SAMPLING_INTERVAL 17 5.15.2. SAMPLING_ALGO 17 5.15.3. FLOW_ACTIVE_TIMEOUT 17 5.15.4. FLOW_INACTIVE_TIMEOUT 17 6. References 17 7. Acknowledgements 19 8. Author's Addresses 20 9. Full Copyright Statement 21 10. Stuff to Add 21 11. End of stuff to add 21 1. Introduction Many applications e.g., Intrusion detection, traffic engineering, = require the monitoring, measuring of IP traffic flows. It is hence = important to have a standard way of exporting information related to IP = flows. This document defines architecture for IP traffic flow = monitoring, measuring and exporting. It provides a high-level = description of the key components and their functions.=20 2. Scope This document defines information data model for IPFIX[3]. = Specifically, this document=20 3. Terminology MOVED to the Requirements draft 4. Information Model I think we need to begin with a couple of guidlines (which we should augment as we go). They are just guidelines. 1. Data element values should be defined in terms of other = specifications. Since we are only reporting things in other protocols, = there should be little reason for us to define anything from scatch. 2. Each element should be able to be interpreted on it own. In other = words, don't make me look though the rest of the message to figure out = what this value means. The drawback is this can lead to data element = explosion. We'll have to balance the tradeoffs. 3. Others? The IPFIX information model is listed in the IPFIX requirement = document. The information model consists of the minimum set of = attributes that an IPFIX exporting device should be able to export. In = conjunction with IP flow definitions, they provide locally accurate = information about a flow. To meet application's requirement may require the collection device to = obtain additional information about the flow, e.g. address translation, = user identification, etc. Additional flow information may also be = required; in this case, equipment vendors may define extensions to the = IPFIX information model. Any extension to the IPFIX information model = should be conveyed between end points. This section presents a rigorous definition and sufficient statistics = for these attributes. 4.1. Attributes related to IP Packet Header=20 The following attributes are obtained directly from IP packet header = belonging to a flow: =20 o IP Version Number=20 o Source Address=20 o Destination Address=20 o Protocol Type=20 o TOS (for version 4)=20 o Flow Label (for version 6)=20 o DSCP (if DiffServ is supported)=20 4.2. Attributes Related to Measurement=20 The following attributes relates to measurements and measuring = methodology: o Packet Counter=20 o Dropped Packet Counter=20 o Payload Byte Counter=20 o Timestamp of the First Packet Observed=20 o Timestamp of the Last Packet Observed=20 o Timeout Indication=20 o Sampling Method=20 o Sampling Parameters=20 4.3. Attributes Related to Flow Definition=20 The following attributes relates to IP flow definitions. o Incoming Interface=20 o Outgoing Interface=20 o Packet Treatment=20 o Unique ID of the Observation Point=20 o Unique ID of the Measuring Device=20 4.4. Attributes related to Upper Layers=20 The following attributes provides information of upper layer protocols. o Source Port Address=20 o MPLS Label (if MPLS is supported)=20 4.5. IPFIX Template=20 The IPFIX system MUST support efficient exporting of IP flow = information. This can be achieved by negotiating a set of IPFIX = Templates for an IPFIX session before actual IP flow information is = exported. A template defines the structure of an IPFIX user message = payload by describing the data type, meaning, and location of the = fields in the payload. By agreeing on IPFIX templates, IPFIX end-points = understand how to process IPFIX user messages. As a result, an = exporting device only needs to export actual flow information without = attaching any descriptors of the attributes; this reduces the amount of = bytes sent over communication links. A template is an ordered list of keys. A key specifies an attribute = that a meter entity MAY export. The specification MUST consist of the = description and the data type of the attribute. (e.g. 'Number of Sent = Bytes' can be a key that is an 32 bit unsigned integer) An exporting = device typically defines keys. Based on the IPFIX information model, a = set of IPFIX standard keys can be defined. 4.5.1. Template Negotiation=20 During the initial setup of an IPFIX session, template negotiation = procedures should be carried out. It would allow all the IPFIX = end-points to synchronize on a set of templates that will be used = during IP flow information export. 5. Information Elements 5.1. Packet Management This information contains the fields needed to manage the data packets = transmitted 5.1.1. Version Number [Need to expand more] 5.1.2. FLOWS V#3 S#4 =20 Number of main cache flows 5.1.3. FLOW_LABEL V#31 S#2 IPV6 Flow Label [Need to expand more] 5.2. IP Address 5.2.1. Source Address IE Source address associated with a flow. Addresses can be of any type as = described in RFC 1700 [note - we need a new reference here, 1700 has = been obsoleted] 5.2.2. Destination Address IE Destination address associated with a flow. same as above. 5.2.3. NEXT_HOP_IP IE Address of the next hop. address is defined the same as for Source = Address IE. 5.3. Time Stamps 5.3.1. Time IE The time (as a SNMPv2 TimeStamp [1443]) associated with the = status/statistics observed or other events. 5.3.2. UTC Time IE The time in seconds since 00:00:00 UTC, January 1, 1970 associated with = the status/statistics observed or other events. If both Time and = UTC_TIME are present, UTC Time takes precedence.=20 5.3.3. Delta Time IE The number in 100ths of seconds over which the statistics were = observed. TYPE is 71 and format is: 5.4. Service Types 5.4.1. Class of Service IE The class of service associated with a flow.=20 Class of Service Received Class of Service Transmitted =20 1. IPv4, CoS value is defined by ToS in RFC 791 2. IPv6, CoS value is defined by Traffic Class in RFC 2460 3. MPLS, CoS value is defined by Exp in RFC 3032 4. VLAN, CoS value is defined by user_priority in IEEE802.1q[802.1q] = and IEEE 802.1p[802.1p] =20 [Can more than one Class of Service can be present??? PAC] =20 5.4.2. TCP Control Bits IE The TCP control bits seen for this flow. Note a 0 value for each bit = only indicates that the flag was not detected (i.e. it may have = occurred but was not detected by the reporting CCE). TCP Control Bits = are defined by RFC 793.=20 5.4.3. Protocol Identifier IE e.g. TCP/UDP [ need an RFC reference here. PAC]=20 5.4.4. Source Exporter [ is that the right term?? PAC] Address IE Source Exporter address is the address of the Exporter reporting the = flow, Address is same as is as shown for Source Address. This = information is used by applications to later correlate the = ingress/egress port with a specific Exporter. It is also used to = maintain the source Exporter information when there is an intermediate = proxy. For example, given the picture below: =20 SW1 -------- P1 ------ FAS1 ^ | SW2---------- | =20 Flows coming from SW1 and SW2 through proxy P1 would look to the = Collector [ is this the rigth term??? PAC] like the same Exporter = connection. With the Source Exporter in the message the original = Exporter address is maintained. 5.5. Flow State IE Flow State is the intended End State for the Flow. Flow state has one of the following meanings: Flow is inactive Flow is active 5.6. Statistical Elements To be added 5.6.1. Byte Count IE Contains the count of octets sent and received associated with the = identified flow.=20 The byte count can be for bytes received (towards source) or bytes = sent (towards destination) or both (bi-directional flow). The byte count can be a running counter and is the count from the = beginning of the flow establishment. The byte count can be a delta counter and is the count since the last = report for this flow. 5.6.2. Packet Count IE Contains the count of packets sent and received associated with the = identified flow.=20 The packet count can be for packets received (towards source) or = packets sent (towards destination) or both (bi-directional flow). The packet count can be a running counter and is the count from the = beginning of the flow establishment. The packet count can be a delta counter and is the count since the last = report for this flow. 5.6.3. Dropped Byte Count IE Contains the count of octets dropped at the observation point = associated with the identified flow.=20 The dropped byte count can be a running counter and is the count from = the beginning of the flow establishment. The byte count can be a delta counter and is the count since the last = report for this flow. 5.6.4. Dropped Packet Count IE Contains the count of packets dropped at the observation point = associated with the identified flow.=20 The dropped packet count can be a running counter and is the count from = the beginning of the flow establishment. The dropped packet count can be a delta counter and is the count since = the last report for this flow. 5.7. Port Information To be added 5.7.1. Source Port IE This IE is used to report UDP source port [see RFC 768] or TCP source = port [see RFC 793]. 5.7.2. Destination Port IE This IE is used to report UDP destination port [see RFC 768] or TCP = destination port [see RFC 793]. 5.8. Autonomous System (AS) To be added 5.8.1. Source AS IE The Autonomous System (AS) numbers for the source address associated = with a flow. Autonomous System (AS) number is defined by RFC 1930 and = RFC 1771 (BGP-4): 5.8.2. Destination AS IE The Autonomous System (AS) numbers for the destination address = associated wit a flow. Autonomous System (AS) number is defined by RFC = 1930 and RFC 1771 (BGP-4). 5.8.3. Next Hop AS IE The Autonomous System (AS) numbers for the next hop IP. Autonomous = System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). 5.9. IfIndexes and Interfaces To be added 5.9.1. Ingress Port IE The ingress ifIndex for the flow is provided in this IE. ifIndex is = defined by RFC 2233. 5.9.2. Egress Port IE The egress ifIndex for the flow is provided in this IE. ifIndex is = defined by RFC 2233. 5.9.3. Egress ATM Subinterface The egress vpi/vci for the flow is provided in this IE. vpi/vci id = defined by the ATM Forum UNI 3.1 specification: 5.9.4. EGRESS_FRAME_RELAY_SUBINTERFACE IE The egress DLCI for the flow is provided in this IE. ITU Q.922 defines = the DLCI range. The frDlcmiState is defined in RFC 2115 and defines the = specific values of the DLCI. 5.10. NetMasks 5.10.1. Source Address Netmask IE The number of bits in the CIDR netmask, as defined in RFC 1519, for the = source address. 5.10.2. Destination Address Netmask IE The CIDR netmask, as defined in RFC 1519, for the destination address.=20 5.11. BGP & Vlan IE's 5.11.1. Destination BGP Community IE The BGP community number for the destination address. BGP community = number is defined by RFC 1997: 5.11.2. Source BGP Community IE The BGP community number for the source address.=20 5.11.3. BGP_NEXT_HOP V#18 S#4 =20 Next-hop router in the BGP domain 5.11.4. Source VLAN ID IE The Source VLAN ID associated with the flow. VLAN ID is defined by IEEE = standard 802.1q - 1998[802.1q].=20 [ Is this ultimate source VLAN or the source vlan of the port where the = packet came in? Or do we need a way to represent both? PAC] 5.11.5. Destination VLAN ID IE The destination VLAN ID associated with the flow. VLAN ID is defined by = IEEE standard 802.1q - 1998[802.1q]. =20 [ Is this ultimate destination VLAN or the destination vlan of the port = where the packet went out? Or do we need a way to represent both? PAC] 1.1. Virtual Information 5.11.6. Source Virtual Address IE An Exporter may be involved in redirecting flows. This IE captures = information needed for proper accounting of redirected flows. The = Source Virtual IE contains the source address of the flow as = transmitted by the Exporter. It is generally different than the source = address IE, which contains the address of the actual source of the = message. A type field would contain the type of translation performed on the = source address. The following types are currently available: 1. - NAT 2. - LSNAT 3. - Web Cache The address is defined the same as for Source Address. 5.11.7. Source Virtual Port IE A CCE may be involved in redirecting flows. This IE captures = information needed for proper accounting of redirected flows. The = Source Virtual port IE contains the source port of the flow as = transmitted by the CCE. It may be different than the source port IE, = which contains the port of the actual source of the flow. An IP = Protocol field is present and is defined by the IP protocol spec [RFC = 791] (e.g. TCP/UDP). The fields indicates how to interpret the port = value field. A type field contains the type of translation performed on the source = port. The following types are currently available: 1. - NAT 2. - LSNAT 3. - Web Cache 5.11.8. Destination Virtual Address IE The Destination Virtual IE contains the destination address of the flow = as received by the Exporter. It is generally different than the = destination port number, which contains the actual destination address = of the flow. 5.11.9. Destination Virtual Port IE The Destination Virtual port IE contains the destination port of the = flow as received by the Exporter. It may be different than the = destination port recorded in the destination port, which contains the = actual destination port of the flow. 5.12. NAT 5.12.1. INSIDE_L4_SRC V#42 S#2 NAT port number (.e.g, FTP, Telnet, etc...) only applicable with NAT 5.12.2. INSIDE_IPV4_SRC_ADDR V#43 S#4 Source IPv4 Address only applicable with NAT TCP/UDP destination port 5.12.3. INSIDE_L4_DST_PORT V#44 S#2 The number (.e.g, FTP, telnet etc...) only applicable with NAT 5.12.4. INSIDE_IPV4_DST_ADDR V#45 S#4 Destination IPv4 Address only applicable with NAT 5.12.5. INSIDE_IPV6_SRC_ADDR V#46 S#16 IPv6 Source Address only applicable with NAT 5.12.6. INSIDE_IPV6_DST_ADDR V#47 #16 IPv6 Destination Address only applicable with NAT 5.12.7. OUTSIDE_L4_SRC_PORT V#48 S#2 TCP/UDP destination port number (.e.g, FTP, Telnet, etc...) only = applicable with NAT 5.12.8. OUTSIDE_IPV4_SRC_ADDR V#49 S#4 Source IPv4 Address only applicable with NAT TCP/UDP destination port 5.12.9. OUTSIDE_L4_DST_PORT V#50 S#2 number (.e.g, FTP, Telnet, etc...) only applicable with NAT 5.12.10. OUTSIDE_IPV4_DST_ADDR V#51 S#4 Destination IPv4 Address only applicable with NAT 5.12.11. OUTSIDE_IPV6_SRC_ADDR V#52 S#16 IPv6 Source Address only applicable with NAT 5.12.12. OUTSIDE_IPV6_DST_ADDR V#53 S#16 IPv6 Destination Address only applicable with NAT 5.13. Vendor Specific IE Vendors may add their own information to the protocol. Information = contained in this IE is vendor specific. OID and OID Value is defined = by ITU X.680.X683 (1997) and is encoded as defined by ITU = X.690.691(1997). This IE MUST not contain any information which cannot = be safely ignored by the Exporter or Collector. If multiple Vendor = Specific IE's with the same OID occur, then the vendor defines = semantics of ordering. 5.14. Misc. Information Elements To be added 5.14.1. Flow Label IE The Flow Label IE contains the IPV6 Flow Label information as defined = by RFC 2460.=20 5.14.2. Flow Direction V#54 S#1 The direction of the flow observed at the observation point. If the = observation point is a set of interface(s) the direction is w.r.t the = wire. 5.14.3. Fragment ID IE The fragment ID associated with the flow. RFC 791 and RFC 2460 define = fragment ID. 5.14.4. Internal queue priority A switch may map several of its internal priority queues into a = Premium, High, Medium or Low category. [ this sections needs more work] 5.14.5. Global VPN Identifier IE The VPN identifier associated with the flow as defined in RFC 2685. 5.14.6. IPM_DPKTS V#19 S#4 Packet count for IP Multicast 5.14.7. IPM_DOCTETS V#20 S#4 Octet (byte) count for IP Multicast 5.14.8. LAST_SWITCHED V#21 S#4 SysUptime at which the last packet of this flow was switched 5.14.9. FIRST_SWITCHED V#22 S#4 SysUptime at which the first packet of this flow was switched [Need to expand more] 5.14.10. MAC_ADDR V#25 S#6 Layer 2 Media Access Control address associated with a flow 5.14.11. VLAN_ID V#26 S#2 Virtual LAN identifier associated with a flow 5.14.12. ICMP_TYPE V#32 S#1 ICMP Packet Type. This is reported as (ICMP Type * 256) + ICMP code 5.14.13. IGMP_TYPE V#33 S#1 IGMP Packet Type 5.15. Sampling 5.15.1. SAMPLING_INTERVAL V#34 S#1 When using Sampling, the rate at which packets are sampled. For = example, a value of 100 indicates that one of every hundred packets is = sampled. 5.15.2. SAMPLING_ALGO V#35 S#1 The type of algorithm used for sampling data. = Currently, the only sampling algorithm defined is: 0x02 packet-sampling 5.15.3. FLOW_ACTIVE_TIMEOUT V#36 S#2 Timeout value for active flow entries in the cache. 5.15.4. FLOW_INACTIVE_TIMEOUT V#37 S#2 Timeout value for inactive flow entries in the cache. 6. References 3. J. Quittek ,et al.," Requirements for IP Flow Information Export ", = (work in progress) ,Internet Draft, Internet Engineering Task Force, = , November 2001 4. M. Wood ,et al.," Intrusion Detection Message Exchange = Requirements",(work in progress), Internet Draft, Internet Engineering = Task Force, draft-ietf-idwg-requirements-06,February 2002. 5. Daniel O. Awduche, et. al.," Overview and Principles of Internet = Traffic Engineering", (work in progress), Internet Draft, Internet = Engineering Task Force, draft-ietf-tewg-principles-02.txt, May 2002=20 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions,=20 http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-adelaide/pp-di= st/ [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric = for IPPM,=20 , November 2001 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss = Metric for=20 IPPM, September 1999 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application = of Sampling Methodologies to Network Traffic Characterization, Proceedings of ACM = SIGCOMM'93,=20 San Francisco, CA, USA, September 13 - 17, 1993 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, = John G. CLEARY:=20 Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay = Variation on=20 the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for = Direct Traffic=20 Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, = August 28 -=20 September 1, 2000. [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric = for IPPM,=20 Request for Comments: 2679, September 1999 =20 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation of = Building Blocks=20 for Passive One-way-delay Measurements, Proceedings of Passive and = Active Measurement=20 Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 (PAM = 2001)=20 [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture and = framework," work in progress. October 2001. [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address = Translator (NAT) Terminology and Considerations", RFC 2663, August = 1999. [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network = Address Translator (Traditional NAT)", RFC 3022, January 2001. [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider = Provisioned Virtual Private Networks ", work in progress, = , January 2002.=20 [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft = , July 2001. [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and = W. Weiss, "An Architecture for Differentiated Services", RFC 2475, = December 1998. [1] Requirements for IP Flow Export, = [2] K.Zhang, et al., "Common Reliable Accounting for Network Element = (CRANE)", , February 2002 [3] G. Sadasivan, et al., "Flow Export Architecture", = , January 2002 =20 [4] Carlson, James, "PPP Design, Implementation and Debugging", Second = Edition . 7. Acknowledgements We like to thank all the people contributing to the requirements discussion on the mailing list, and the design teams for a lot of = valuable comments. George Carle Tanja Zseby Paul Calato Dave Plonka Kevin Zhang KC Norseth Phill Richards Will Eatherton Benoit Claise Ganesh Sadasivan Vamsi Valluri Ram Gopal Jc Martin Carter Bullard Juergen Quittek Reinaldo Penno Nevil Brownlee Simon Leinen 8. Author's Addresses Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Paul Calato Riverstone Networks, Inc. 5200 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 (603) 557-6913 Email: calato@riverstonenet.com Ganesh Sadasivan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1 (408) 527-0251 Email: gsadasiv@cisco.com Ram Gopal Nokia=20 5 Wayside Road,=20 Burlington, MA 01803 Phone:+1 781 993 3685 Email: ram.gopal@nokia.com Man Li=20 Nokia=20 5 Wayside Road,=20 Burlington, MA 01803=20 Phone: +1 781 993 3923=20 Email: man.m.li@nokia.com=20 K.C. Norseth Enterasys Networks 2691 S. Decker Lake Lane Salt Lake City, Utah 84119 Phone: +1 801 887 9823 Email: knorseth@enterasys.com Reinaldo Penno Nortel Networks, Inc.=20 2305 Mission College Boulevard Building SC9-B1240 =20 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com=20 Juergen Quittek NEC Europe Ltd. Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Kevin Zhang =20 XACCT Technologies, Inc.=20 2900 Lakeside Drive=20 Santa Clara, CA 95054=20 Phone +1 301 992 4697=20 Email: kevin.zhang@xacct.com Tanja Zseby GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 Email: zseby@fokus.gmd.de 9. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This = document and translations of it may be copied and furnished to others, = and derivative works that comment on or otherwise explain it or assist = in its implementation may be prepared, copied, published and = distributed, in whole or in part, without restriction of any kind, = provided that the above copyright notice and this paragraph are = included on all such copies and derivative works. However, this = document itself may not be modified in any way, such as by removing the = copyright notice or references to the Internet Society or other = Internet organizations, except as needed for the purpose of developing = Internet standards in which case the procedures for copyrights defined = in the Internet Standards process must be followed, or as required to = translate it into. 10. Stuff to Add 11. End of stuff to add =20 IPFIX Information Data Model February, 2002 =20 IPFIX WG Expires August, 2002 [Page 4] Gopal, Li,Zhang,Tanja Expires July 2002 [Page 1] ------_=_NextPart_000_01C1B3D5.794697C0 Content-Type: text/plain; name="draft-ietf-ipfix-architecture-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ipfix-architecture-00.txt" Content-Transfer-Encoding: quoted-printable IPFIX working group Internet Draft draft-ietf-ipfix-Architecture-00.txt Expires: August 2002 Benoit Claise Cisco Systems P. Calato Riverstone Networks Inc Ram Gopal Man Li Nokia =20 K.C. Norseth Enterasys Networks Reinaldo Penno NortelNetworks J. Quittek NEC Europe Ltd. Ganesh Sadasivan Cisco Systems, Inc. Kevin Zhang XACCT Technologies Tanja Zseby FhI FOKUS February 2002 IPFIX Architecture Architecture Model for IP Flow Information Export draft-ietf-ipfix-architecture-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all = provisions of Section 10 of RFC2026 [1].=20 Internet-Drafts are working documents of the Internet Engineering Task = Force (IETF), its areas, and its working groups. Note that other groups = may also distribute working documents as Internet-Drafts. = Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet- Drafts as reference material = or to cite them other than as "work in progress."=20 The list of current Internet-Drafts can be accessed at = http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at = http://www.ietf.org/shadow.html. Abstract This document defines architecture for scalable monitoring, measuring = and exporting IP flow information to collectors. =20 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are to be interpreted as described in RFC-2119 [1]. 1. Introduction 4 2. Scope 4 3. Terminology 4 4. IPFIX reference Model 4 4.1. Flow Type and Flow Definition 5 4.1.1. Observation Point 7 4.1.2. Unidirectional and Bidirectional Flows 7 4.2. Metering Process Functions 8 4.2.1. Flow Classification 8 4.2.2. Selection Criteria Of Packets 8 4.2.3. Selection Criteria of flows for export 9 4.2.4. Flow Expiration 9 4.3. Exporter 10 4.4. IPFIX protocol 10 4.5. Collector 11 4.6. Relationship to RTFM 11 4.7. Applications 11 5. Some Applications of IPFIX 11 5.1. IPFIX usage in Intrusion Detection 12 5.2. IPFIX and AAA 12 5.2.1. Connecting via an AAA client 13 5.2.2. Connecting via an Application Specific Module (ASM) 14 5.3. IPFIX usage in Traffic Engineering/Traffic Profiling 14 6. Architectural Requirements (BLANK) 15 6.1. Recovery (BLANK) 15 6.2. Performance (BLANK) 15 6.3. Security 15 6.4. IPfix Considerations for Middleboxes 15 6.4.1. Firewall 15 6.4.2. Network Address Translation 16 6.4.3. Traffic Conditioners 17 6.4.4. Tunneling 19 6.4.5. VPNs 19 6.5. QoS Monitoring with IPFIX 21 6.5.1. Measurement of Round-trip-time (RTT) with IPFIX 21 6.5.2. Measurement of One-way-delay (OWD) with IPFIX 22 6.5.3. Measurement of Loss with IPFIX 22 6.5.4. Measurement of delay variation with IPFIX 23 6.5.5. Sampling for QoS Monitoring 23 6.6. 10 Capability Negotiation 23 6.6.1. Phase I 24 6.6.2. Phase II 25 6.6.3. Renegotiation of Capabilities 27 6.6.4. Caching of Negotiated Parameters 28 7. IPFIX Deployment Scenarios 28 7.1. Exporting Interface over LAN 28 7.2. Exporting Interface over WAN 29 8. Security Consideration 30 9. References 30 10. Acknowledgements 32 11. Author's Addresses 34 12. Full Copyright Statement 35 13. Stuff to Add 35 14. End of stuff to add 36 1. Introduction Many applications e.g., Intrusion detection, traffic engineering, = require the monitoring, measuring of IP traffic flows. It is hence = important to have a standard way of exporting information related to IP = flows. This document defines architecture for IP traffic flow = monitoring, measuring and exporting. It provides a high-level = description of the key components and their functions.=20 2. Scope This document defines architecture for IPFIX[3]. Specifically, this = document=20 o Describes the key architectural components of IPFIX. o Describes the external dependency and identifies those interfaces = explicitly.=20 o Defines architectural requirements, e.g., Recovery, Security, etc. o Describes the required mechanisms to interoperate with other = protocol/architecture this may includes AAA or Diameter or Intrusion = Detection system. o Identifies a minimal set of applications for IPFIX. 3. Terminology MOVED to the Requirements draft 4. IPFIX reference Model Figure 1 shows the reference model for IPFIX. The blocks shown are = logical entities. The functionalities of these components remain the = same regardless of their placements inside a network.=20 The main purpose of the IPFIX subsystems is to effectively communicate = the information model using IPFIX. The information model is composed of = set of attributes that are of interest to the applications. Each = application may require a subset of the parameters specified in the = information model. The information model is generalized and = communicated between IPFIX endpoints as Templates for operational = purpose. +------------+ +-------------+ |Application | | Application | = =20 | (1) |.... | (n) | +------------+ +-------------+ || || = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 || ||=20 ||=20 +---------------+---------+ || =20 | | | ||=20 | Exporter(1) | IPFIX |<=3D+ ||=20 | | | || || =20 +---------------+---------+ || || =20 . || || =20 . || ||=20 +---------------+---------+ || +-------+-----------+ | | | || | | | | Exporter(n) | IPFIX |<=3D=3D=3D=3D=3D>| IPFIX | Collector | | | | || | | | +---------------+---------+ || +-------+-----------+ || ||=20 || || = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ = || +-------+-------------+=20 || || || | | | || || =3D=3D=3D=3D>| IPFIX | = Collector | +------------+ +-------------+ | |(Application)| |Observation | | Observation | +-------+-------------+ = =20 | Point(1) |.... | Point (n) | +------------+ +-------------+ Figure 1: IPFIX Reference Model 4.1. Flow Type and Flow Definition As defined in the requirement draft [1], "A flow is a set of packets passing an observation point in the network = during a certain time interval. All packets belonging to a particular = flow have a set of common properties derived from the data contained in = the packet and from the packet treatment at the observation point." In this draft we define the flow more specifically. A flow is defined = as a set of packets passing an observation point in the network during = a certain time interval. All packets belonging to a particular flow = have a set of common properties. Each property is defined as the = result of applying a function to the values of: a. one or more of packet header fields (eg. destination IP address) b. one or more properties of the packet itself (eg. packet length) c. one or more of fields derived from packet treatment (eg. AS number) A packet is defined to belong to a flow if it matches all the defined = properties of the flow. Flows can be defined in multiple ways. Some = examples are: Example 1: To create flows, we define the different fields to distinguish flows. = The different combination of the field values creates unique flows. If = the keys are defined as {source IP address, destination IP address, = TOS}, then all of 1. {192.1.40.1, 171.6.23.5, 4} 2. {192.1.40.23, 171.6.23.67, 4} 3. {192.1.40.23, 171.6.23.67, 2} 4. {198.20.9.200, 171.6.23.67, 4} are different flows. Example 2: To create flows, we can apply a match function to all the packets that = pass through an observation point, in order to aggregate some values. = This could be done by defining the keys as {source IP address, = destination IP address, TOS} like in the example 1, and applying the = function which masks the least significant 8 bits of the source IP = address and destination IP address (.i.e the resultant is a /24 = address). The 4 flows from example 1 would now be aggregated into 3 = flows, by merging the flows 1. ans 2. into a single flow. 1. {192.1.40.0/24, 171.6.23.0/24, 4} 2. {192.1.40.0/24, 171.6.23.0/24, 2} 3. {198.20.9.0/24, 171.6.23.0/24, 4} Example 3: To create flows, we can filter some field values on all packets that = pass the observation point, in order to select only certain flows. The = filter is defined by choosing fixed values for specific fields from the = packet. All the packets that go from a customer network 192.1.40.0/24 to = another customer network 171.6.23.0/24 with TOS value of 4 define a = flow. All other combinations don't define a flow and are not taken into = account. The 3 flows from example 2 would now be reduced to 1 flow, by = filtering away the second and the third flow. {192.1.40.0/24, = 171.6.23.0/24, 4}. The above example can be thought of as a function F takes as input = {source IP address, destination IP address, TOS}. The function selects = only the packets which satisfies all the 3 conditions which are: * mask the least significant 8 bits of source IP address, compare = against 192.1.40.0. * mask the least significant 8 bits of destination IP address, compare = against 171.6.23.0. * tos value equal to 4. Depending on the values of {source IP address, destination IP address, = TOS} of the different observed packets, the metering process function F = would choose/filter/aggregate different sets of packets, which would = create different flows. In other words, based on various combination = of values of {source IP address, destination IP address, TOS}, F(source = IP address, destination IP address, TOS) would results in the = definition of one or more flows. The function F is referred to as Flow = Type. 4.1.1. Observation Point For definition refer to section 1.2. A flow is uniquely defined by the = way it gets measured at an observation point. Example: The flow defined in the example 1 of section 2., can be used at 2 = different observation points 'a' and 'b' in 2 different ways. = Observation point 'a' measures the packets that match the flow = {192.1.40.0/8, 171.6.23.0/8, 4} at a sampling rate of 1 in 10 and 'b' = measures packets that match the same flow with a sampling rate of 1 in = 100. 4.1.2. Unidirectional and Bidirectional Flows A flow defined by the above terms is unidirectional. In case the = exporter has got the knowledge of the bi-directional flows and in case = the bi-directional information make sense, the exporter MAY choose to = export in the same Template/Flow Record, along with bidirectional = accounting information. This would save some bandwidth as the exporter = won't have to send two unidirectional flow records. [GANESH-2-11-02 - Please expand more] =20 When the direction w.r.t wire is specified, then it can be further categorized as uni/bi.. The direction however is optional and may not be applicable in all the cases. 4.2. Metering Process Functions 4.2.1. Flow Classification The collector MUST be able to map the flow to the corresponding = property types defined by the flow type. This can be done only if the = collector has a mapping from flow type identifier (carried in each flow = record) to its actual structure. More details of how this can be = acheived is decribed in section 5. In addition the collecter, when it receives the flow records, MAY need = the following interpreting the flow records furthur: a. Observation Point. b. Selection Criteria of Packets As mentioned in section 2.1, a flow record can be better analyzed if = the Observation Point from which it is measured is known. As such it is = recomended that the flow record carry the Observation Point information = along with the flow records when exported. In cases where there is a = single observation point or where the observation point information is = not relevant, the exporter MAY choose not to add this to the flow = records. 4.2.2. Selection Criteria Of Packets The measurement device MAY define rules so that only certain packets = within a flow can be chosen for measurement at an observation point. = This MAY be done by one of the two types of methods defined below or a = combination of them. A combination of each of these ways can be = adopted to select the packets .i.e one can define a set of methods {F1, = S1, F2, S2, S3} executed in certain sequence at an observation point to = collect flows of a particular type. 4.2.2.1. Funtion on properties that determines a flow type (Fi) Packets that satisfy a function on the fields defined by the packet = header fields or fields obtained while doing the packet processing or = the properties of the packet itself. Example: Mask/Match of the fields that define a filter. The filter may be = defined as {Protocol =3D=3D TCP, Destination Port between 80 and 120}. = Multiple such filters could be used in any sequence to select packets. 4.2.2.2. Sampling packets on a flow type (Si) Packets that satisfy the sampling criteria for this flow type. Example: Sample every 100th packet that was received at an observation point and = collect the flow information for a particular flow type. choosing all = the packets is a special case where sampling rate is 1:1. 4.2.3. Selection Criteria of flows for export The measurement device MAY define additional rules so that only certain = flows records are picked up for export. This MAY be done by either one = of the two types of methods defined in 2.3.1 and 2.3.2 or a combination = of them. Example: The flow records which meets the following selection criteria are only = exported. 1. All flow records whose destination IP address matches {20.3.1.5}. 2. Every other (.i.e sampling rate 1 in 2) flow record whose = destination IP address matches {160.0.1.30}. 4.2.4. Flow Expiration A flow is considered to be inactive if no packets of this flow has been = observed at the observation point for a given timeout interval. The = flow can be exported under the following conditions: 1. If the exporter can deduce the end of a flow, the exporter SHOULD = export the flow records when the end of the flow is detected. For = example: flow generated by TCP type of traffic where the FIN or RST = bits indicate the end of the flow 2. If the flow has been inactive for a certain period of time. This = inactivity timeout SHOULD be configurable. For example: flow generated = by UDP type of traffic. 3. For long aging flows, the exporter SHOULD export the flow records on = regular basis, in order to: a. report the flow records periodic accounting information to the = collector b. avoid counter wrapping This activity timeout SHOULD be configurable 4. If the exporter experiences resources constraints, a flow MAY be = prematurely expired (example: memory) 4.3. Exporter The exporter is a subsystem that interacts with one or more observation = points. The functions of an exporter may include: * Performing Flow ID management (capabilities negotiation)that includes = the creation of tags to refer a flow between Exporter and the Collector = for configuration and statistical purpose. * Assembling collected information into the right format to be carried = by the IPFIX protocol * Configuring observation points with flow monitoring rules * Measuring, aggregating and exporting IP Flow information to the respec= tive collectors. * May perform appropriate middle-box functions to translate the flow = information.=20 =20 The information collected can be either pushed periodically to the = collector or pulled by the collector on demand. 4.4. IPFIX protocol IPFIX protocol may run on top of either Transport or IP layer. If the = underlying network is not reliable, it is the responsibility of the = IPFIX protocol to perform transport level functions. It is recommended = to use reliable transport protocols like SCTP or TCP. The functions of IPFIX protocol include: * Reliably and securely transporting application level information = between an exporter and a collector ( security functions are leveraged = by using underlying security protocols) * Maintaining the communication links between IPFIX endpoints. = Supporting fail-over and fail-back procedures, and performing load = balancing if required. =20 4.5. Collector Collector is a subsystem that interacts with one or more Exporters. The = functions of the collector may include: * Performing Flow ID management (capabilities negotiation)that includes = the creation of tags to refer a flow between Exporter and the Collector = for configuration and statistical purpose. * Requesting an exporter sub-system to collect IP flows. * Communicating with different applications.=20 * Maintaining a repository of IP flow statistics=20 * Aggregating application level requests and form a template that will = suitable for exporter. =20 The application(s) and the collector may be tightly coupled in one = system. They may also be logically or physically a separate subsystem = from the application(s). In which case, the communication between them = is beyond the scope of IPFIX. 4.6. Relationship to RTFM To be filled out by Nevil Brownlee 4.7. Applications IPFIX applications may be Billing, Network Surveillance, and Intrusion = Detection sub-systems. etc.[3]. An application requests the Collector = to gather the relevant IP Flow information. =20 5. Some Applications of IPFIX This section describes the required mechanism to interoperate with = IPFIX applications that are identified in the requirement document[3]. = These applications are not exhaustive. =20 5.1. IPFIX usage in Intrusion Detection Intrusion Detection System (IDS) monitors and controls the security = incidents [4]. Typical IDS system includes components like Data source, = Sensor, Analyzer and Management stations[4]. A Sensor monitors the data = source and raises the alarm to the Analyzer. The analyzer collects = various incident information and reports this to the management = station. With IPFIX, the event of interest can be exported either from collector = or from exporter. For smooth integration, it will be better for the IDS = system to integrate with the collector since the collector has all the = aggregated information from different observation points. The IDS can = request the collector to monitor the events or IP flow through an IPFIX = template. =20 5.2. IPFIX and AAA AAA defines a protocol and an architecture for authentication, = authorization and accounting for service usage. The DIAMETER protocol = is used for AAA communication for network access services (Mobile IP, = NASREQ, ROAMOPS). The AAA architecture [XXX-RFC2903] provides a = framework for extending the AAA support also for other services. = DIAMETER defines the exchange of messages between AAA entities, e.g. = between AAA clients at access devices and AAA servers and among AAA = servers. It is used also for the transfers of accounting records. For = usage-based accounting measurement data from the network is needed to = generate an accounting record. IPFIX provides a protocol to export = measurement data from the measurement point to the consumer of this = data (like network management and accounting systems). The provisioning = of accounting with IPFIX can be realized without a AAA infrastructure. = The collector can directly forward the measurement information to an = accounting application. Nevertheless, if a AAA infrastructure is in = place, IPFIX can provide the input for the generation of accounting = records and several features of the AAA architecture can be used. = Features include the mapping of a user ID to the flow information (by = using authentication information), the generation of DIAMETER = accounting records and the secure exchange of accounting records = between domains with DIAMETER. Three possibilities to connect IPFIX and = AAA can be distinguished:=20 5.2.1. Connecting via an AAA client One possibility to connect IPFIX and AAA is to run a AAA client on the = IPFIX collector. This client can generate DIAMETER accounting messages = and send them to a AAA server. The mapping of the flow information to a = user ID can be done in the AAA server by using data from the = authentication process. DIAMETER accounting messages can be sent to the = accounting application or to other AAA servers (e.g. in roaming = scenarios). +---------+ DIAMETER +---------+=20 | AAA-S |------------->| AAA-S | +---------+ +---------+=20 ^ | DIAMETER =09 | | +--+--------+--+ | | AAA-C | | + +--------+ | | | | Collector | +--------------+ =20 ^ | IPFIX =09 | +------------+ | Exporter | +------------+ =20 Figure 2: IPFIX collector connects to AAA server via AAA client=20 5.2.2. Connecting via an Application Specific Module (ASM) Another possibility is to directly connect the IPFIX collector with the = AAA server via an application specific module (ASM). Application = specific modules have been proposed by the IRTF AAA architecture = research group (AAARCH) in [RFC2903]. They act as an interface between = AAA server and service equipment. In this case the IPFIX collector is = part of the ASM. The ASM acts as an interface between the IPFIX = protocol and the input interface of the AAA server. The ASM translates = the received IPFIX data into an appropriate format for the AAA server. = The AAA server then can add information about the user ID and generate = a DIAMETER accounting record. This accounting record can be sent to an = accounting=20 application or to other AAA serves.=20 +---------+ DIAMETER +---------+=20 | AAA-S |------------->| AAA-S | +---------+ +---------+=20 ^ | =09 +------------------+ | ASM | | +------------+ | | | Collector | | +------------------+ ^ | IPFIX =09 | +------------+ | Exporter | +------------+ =20 Figure 3: IPFIX connects to AAA server via ASM 5.3. IPFIX usage in Traffic Engineering/Traffic Profiling To better utilize the network, traffic engineering [5] is performed by = the network administrator. IPFIX can monitor and report different = flows. Using this information as a baseline, network administrators can = perform optimized network planning and engineering. =20 more to be written=20 6. Architectural Requirements (BLANK) more to be written 6.1. Recovery (BLANK) more to be written 6.2. Performance (BLANK) more to be written 6.3. Security Refer Security Consideration section for details 6.4. IPfix Considerations for Middleboxes A Middlebox is a network intermediate device that implements one or = more of the middlebox services. Policy based packet filtering (a.k.a. = firewall), Network address translation (NAT), Intrusion detection, Load = balancing, Policy based tunneling and IPsec security are all examples = of a middlebox function (or service). [MCFW]. For instance, a NAT = middlebox is a middlebox implementing NAT service and a firewall = middlebox is a middlebox implementing firewall service.=20 It is expected that the exporter in the IPfix architecture will = probably implement some form of middlebox service given its ubiquity = today. Since some of these middlebox services might affect flow = exportation and how the collector interprets them, there is a need to = provide an analysis of these implications in relation to the IPfix = architecture and a set of recommendations.=20 The following sections provide a non-exaustive analysis of middlebox = services, its implications on the IPfix architecture and a = corresponding set of recommendations. 6.4.1. Firewall Firewall is a policy based packet filtering middlebox function, = typically used for restricting access to/from specific devices and = applications. The policies are often termed Access Control Lists = (ACLs)[MCFW]. =20 The firewall middlebox service allow the exporter to explicitly drop = packets based on some administrative policy. In this case, the exporter = can take one of the following actions that will have a direct impact on = the information provided by the collector to the user. * Silently Discard In this case the packet is discarded and no flow information record is = sent to the collector. * Discard and export flow In this case the packet is discard and the flow information record is = sent to the collector. * Discard and export flow with discard notification In this case the packet is discard and the flow information record is = sent to the collector with an indication that the packet was discarded. 6.4.2. Network Address Translation Network Address Translation is a method by which IP addresses are = mapped from one address realm to another, providing transparent routing = to end hosts. Transparent routing here refers to modifying end-node = addresses en-route and maintaining state for these updates so that when = a datagram leaves one realm and enters another, datagrams pertaining to = a session are forwarded to the right end-host in either realm = [NAT-TERM].=20 From an exporter (middlebox) perspective, a NAT is composed of two = flows, one from the client to the NAT middlebox and another from the = NAT middlebox to the destination. Based on this fact, the exporter has = several modes of operation, i.e., it can export the private realm flow, = the public realm, or both. This is further constrained by the flavor of = NAT implemented, meaning that in order for the exported information to = be useful for the collector, sometimes the associated flows on the two = realms need to be exported in the same flow record.=20 Although there are many flavors of address translation that lend = themselves to different applications, this section will only address = the IPfix architecture implications of traditional NAT, bi-directional = NAT and twice NAT. 6.4.2.1. Traditional NAT Traditional NAT would allow hosts within a private network to = transparently access hosts in the external network, in most cases. In a = traditional NAT, sessions are unidirectional, outbound from the private = network. This is in contrast with bi-directional NAT, which permits = sessions in both inbound and outbound directions. A detailed = description of traditional NAT may be found in section [NAT-TERM]. If the exporter is providing traditional NAT service and only the = private realm flow is exported, only destination based information can = be inferred from the collector. The reason for this is twofold. First, = the collector will not be able to find the reverse flow (when = applicable) associated with a private realm flow record, and second is = that in the more general scenario the collector can be connected to = several exporters providing NAT service and there might be overlapping = private realm addresses between the networks connected to these = exporters. In a traditional NAT scenario the exporter SHOULD export private and = public realm information in the same flow record or provide the = collector with a unique key to associate the two if exported on = different flow records. 6.4.2.2. Bi-Directional NAT With a bi-directional NAT, sessions can be initiated from hosts in the = public network as well as the private network. Private network = addresses are bound to globally unique addresses, statically or = dynamically as connections are established in either direction. = Detailed description of Bi-Directional may be found in section = [NAT-TERM]. 6.4.2.3. Twice NAT Twice NAT is a variation of NAT in that both the source and destination = addresses are modified by NAT as a datagram crosses address realms. = This is in contrast to Traditional-NAT and Bi-Directional NAT, where = only one of the addresses (either source or destination) is translated. = Note, there is no such term as 'Once-NAT'. Detailed description of = Bi-Directional may be found in section [NAT-TERM]. In the case of twice NAT the exporter MUST export private and public = realm information in the same flow record or provide the collector with = a unique key to associate the two if exported on different flow = records. 6.4.3. Traffic Conditioners A traffic conditioner may contain the following elements: meter, = marker, shaper, and dropper. A traffic stream is selected by a = classifier, which steers the packets to a logical instance of a traffic = conditioner[DIFF-ARCH]. From an IPfix architecture perspective we are going to address marking, = shaping and dropping services. 6.4.3.1. Marking=20 Diffserv packet markers set the DS field of a packet to a particular = codepoint, adding the marked packet to a particular DS behavior = aggregate. The marker may be configured to mark all packets which are = steered to it to a single codepoint, or may be configured to mark a = packet to one of a set of codepoints used to select a PHB in a PHB = group, according to the state of a meter. When the marker changes the = codepoint in a packet it is said to have "re-marked" the packet = [DIFF-ARCH]. From and IPfix architecture perspective, the exporter can take one of = the following actions when it needs to remark a packet. * Unmarked flow The exporter can export the flow before it was remarked. This mode of = operation is strongly disencouraged. * Remarked flow The exporter can export the flow after it was remarked.=20 * Unmarked and remarked flow. The exporter can export the flow before and after it was remarked or = export the flow before it was remarked and an indication of what was = the DSCP after it was remarked.=20 6.4.3.2. Shapers Shapers delay some or all of the packets in a traffic stream in Order = to bring the stream into compliance with a traffic profile. A shaper = usually has a finite-size buffer, and packets may be discarded if there = is not sufficient buffer space to hold the delayed packets. For an IPfix perspective, since the discard of a packet by a shaper is = not voluntary, no indication should be sent to the collector.=20 6.4.3.3. Droppers Droppers discard some or all of the packets in a traffic stream in = order to bring the stream into compliance with a traffic profile. This = process is know as "policing" the stream. Note that a dropper can be = implemented as a special case of a shaper by setting the shaper buffer = size to zero (or a few) packets. In a manner analogous to the middlebox firewall service, middlebox = policing services also allow the exporter to explicitly drop packets = based on some administrative policy.=20 The three possible export behaviors described for the firewall service = when a packet needs to be dropped are also applicable to here, i.e., = silent discard, discard and export flow, discard and export flow with = discard notification. 6.4.4. Tunneling The exporter can export the flows before and/or after they get = tunneled. In the later case the encapsulated flow information might not = be available due to confidentiality precautions such as those used by = IPsec, or due to the fact the exporter lacks the necessary intelligence = to inspect the encapsulated packet. Moreover, depending on where in the = network the exporter is located, it might only be able to export flows = associated with the tunnel, without visibility into the encapsulated = packet. Apart from what was said above, it should also be factor in the fact = that flows exported before they get tunneled, will provide information = about the private network sites, but not necessarily about the = backbone, since the route taken by the packet it's now know at that = point in time (and vice-versa). Tunnel terminates on exporter Tunnel initiates on exporter Exporter implements tunnel switching 6.4.5. VPNs The term "Virtual Private Network" (VPN) refers to the communication = between a set of sites, making use of a shared network infrastructure. = Multiple sites of a private network may therefore communicate via the = public infrastructure, in order to facilitate the operation of the = private network. The logical structure of the VPN, such as addressing, = topology, connectivity, reachability, and access control, is equivalent = to part of or all of a conventional private network using private = facilities [RFC2764] [VPN-2547BIS]. There are multiple flavors of VPNs, the one with more relevance to the = IPfix architecture is the PE-based-VPN. A PE-based VPN (or Provider = Edge-based Virtual Private Network) is one in which PE devices in the = SP network provide the VPN. This allows the existence of the VPN to be = hidden from the CE devices, which can operate as if part of a normal = customer network. A detailed discussion of VPNs can be found in = [PPVPN-FR]. 6.4.5.1. Layer 3 PE-based VPN A layer 3 PE-based VPN is one in which the SP takes part in IP level = forwarding based on the customer network's IP address space. In = general, the customer network is likely to make use of private and/or = non-unique IP addresses. This implies that at least some devices in = the provider network needs to understand the IP address space as used = in the customer network. Typically this knowledge is limited to the PE = device [PPVPN-FR] which is directly attached to the customer. In a layer 3 PE-based VPN the provider will need to participate in some = aspects of management and provisioning of the VPNs, such as ensuring = that the PE devices are configured to support the correct VPNs. This = implies that layer 3 PE-based VPNs are by definition provider = provisioned VPNs [PPVPN-FR]. In order to connect the different VPN sites belonging to the same VPN = the SP uses a tunneling technique such as MPLS, L2TP or IPsec. These = tunnels originate and terminate on PE devices.=20 One of the characteristics of a layer 3 PE-based VPNs is that they = offload some aspects of VPN management from the customer network. From = an IPfix architecture perspective, this means that the SP is the one = that potentially will be providing the IPfix service for the VPNs that = it provides connectivity. The exporter in Layer 3 PE-based VPN can be located on the customer's = network, on the SP's backbone (P Router) or on the edge (PE router). = The premise of this discussion is that the exporter is the one = providing middlebox services, so in the case of VPNs we assume that the = exporter is located in a PE device.=20 6.4.5.1.1. Tunneling [Reinaldo: Just reference 13.4] 6.4.5.1.2. Overlapping Address Realms In the case the exporter plays the role of a PE router [VPN-2547BIS] in = a provider provisioned VPN scenario and has VPNs with overlapping = private address realms, it can only provide useful non-conflicting = information to the provider for intra-VPN traffic if it uses a = technique that allows the collector to uniquely identify to which VPN = the flow belongs. Several techniques could be used to accomplish this goal. One of these = techniques is to include the VPN Global unique identifier [VPN-ID] as = one of the keys in the flow record.=20 In the case the exporter supports VPNs with overlapping private address = realms, it MUST include the VPN-ID [VPN-ID] in the exported flow = record. 6.4.5.2. Layer 2 PE-based VPN [TBD] A layer 2 PE-based VPN is one in which the network is aware of the VPN, = but does only layer 2 forwarding and signaling. This implies that the = SP provisions and maintains layer 2 connectivity between CE devices = [VPN-L2]. Forwarding options include MAC addresses (such as LAN emulation), use = of point-to-point link layer connections (FR or ATM), = multipoint-to-point (using MPLS multipoint to point LSPs), and = point-to-multipoint (e.g., ATM VCCs). For a layer 2 PE-based VPN, the PE device may be a router, LSR, or IP = switch. From the CE's perspective, the PE will be operating as a = switch. 6.5. QoS Monitoring with IPFIX=20 The performance QoS monitoring is one target application for using the = IPFIX protocol. QoS monitoring is the passive observation of the = transmission quality for single flows or traffic aggregates in the = network. It is needed for instance for the validation of QoS guarantees = in service level agreements. Some QoS metrics require the correlation = of data from multiple measurement points. For this the clock of the = involved exporting devices need to be synchronized. Furthermore such = measurements would benefit from post-processing functions (e.g. packet = ID generation) at the exporter and/or collector. This section describes = how the monitoring of different metrics can be performed with IPFIX. = The following metrics are considered: round trip time, one-way-delay, = loss and delay variation. 6.5.1. Measurement of Round-trip-time (RTT) with IPFIX The passive measurement of round-trip-times (RTT) can be performed by = using packet pair matching techniques as described in [Brow00]. For the = measurements, request/response packet pairs from protocols like DNS, = ICMP,SNMP or TCP (syn/syn-ack, data/ack) are utilized to passively = observe the RTT. As always for passive measurements this only works if = the required traffic of interest is actually present in the network. In = order to use this measurement technique, the IPFIX meter needs to = measure both directions. A classification of the protocols mentioned = above has to be done. That means parts of the transport header are used = for the classification. Since a differentiation of flows in accordance = to the transport header is one of the requirements for IPFIX, such = classification can be performed without extensions. Nevertheless, the = meter needs to recognize request and response packets for the given = protocols and therefore needs to look further into the packet. This is = not required for IPFIX but can be achieved by optional extensions to = the classification process. The exporting device needs to assign a = timestamp for the arrival of the packets. The calculation of the RTT = can be done directly at the exporter or at the collector. In the first = case IPFIX would transfer the calculated RTT to the collector. In the = second case IPFIX needs to send the observed packet types and the = timestamps to the collector. 6.5.2. Measurement of One-way-delay (OWD) with IPFIX Passive one-way-delay measurements require the collection of data at = two measurement points. It is required to recognize packets at the = second measurement point in order to correlate packet arrival events = from both points. This can be done for instance by capturing packet = headers and parts of the packet and recognize packets based on this. In = order to reduce the amount of measurement data a unique packet ID can = be calculated from the header and part of the content e.g. by using a = CRC or hash function [GrDM98, DuGr00, ZsZC01].Since IPFIX is not = targeted at packet capturing these functionalities do not need to be = supported by a standard IPFIX meter. Nevertheless, in some scenarios it = might be sufficient to calculate a packet ID under consideration of = header fields including datagramm ID and maybe sequence numbers (from = transport protocols) without looking at parts of the packet content. = Especially if packet IDs need to be unique only for a certain time = interval or a certain amount of packet ID collisions is tolerable this = can be a solution.=20 6.5.3. Measurement of Loss with IPFIX Passive loss measurements for single flows can be performed at one = measurement point for instance by using sequence numbers that are = present in higher layer protocols. This requires the capturing of the = sequence numbers of subsequent packets of the observed flow at the = IPFIX meter. An alternative to this is to perform a two-point = measurement as described above and just consider packets as lost, that = do not arrive at the second measurement point in a given maximum time = frame.=20 6.5.4. Measurement of delay variation with IPFIX Delay variation is defined as the difference of one-way-delay values = for selected packets.[DeCi01]. Therefore this metric can be calculated = by performing passive measurement of one-way-delay for subsequent = packets (e.g. of a flow) and then calculate the differences.=20 6.5.5. Sampling for QoS Monitoring Since QoS monitoring can lead to an overwhelming amount of measurement = result data, it would highly benefit from the deployment of mechanisms = to reduce the measurement data, like aggregation of results and = sampling. Sampling methods can be grouped according to the sampling = strategy (systematic, random or stratified) and the trigger that starts = a sampling interval (count-based, time-based or packet-content-based) = [ClPB93]. Sampling can also be used as a method to dynamically reduce = resource consumption if the meter is overloaded. Then the IPFIX meter = can switch to a sampling method if too many packets have to be = observed. Since the expected estimation error depends heavily on the = used sampling strategy, the application that receives the data needs to = be aware of the sampling scheme and the used parameters. Therefore it = is important that the IPFIX exporter informs the collector precisely = about the used sampling strategy. This is even more required if the = IPFIX meter dynamically invokes sampling. 6.6. 10 Capability Negotiation The capability negotiation is composed of two phases. In the first = Phase, basic capabilities regarding the exporting interface support are = negotiated between IPFIX end-points. If this phase fails, the = negotiation process will terminate and status information will be = provided to upper layers.=20 In the second phase, more specific capabilities are negotiated, for = instance, extended information model support, redundancy support, = templates, and supported messages. One could use, for instance, a capability negotiation process similar = to LCP [RFC 1661]. For each capability proposed by one of the peers in = each of the phases, the answer can be a reject, ack or nak. More specifically, the system sending a Configure-Request is telling = the peer system that it is willing to receive data sent with the = enclosed options enabled. If the peer does not recognize (or = administratively prohibits) one or more options in the = Configure-Request message, it must return just these options in a = Configure-Reject message and the original sender must then remove the = options from a subsequent Configure-Request message. If some of these options were recognized but unacceptable with the = supplied parameters, the peer would then respond with a Configure-Nak = containing only the offending options and a suggested modified value = for the parameters (called a hint). The receiver of the Configure-Nak = then should decide if the hinted value is acceptable and, if so, send a = new Configure-Request reflecting the requested changes plus the = original values for the unchanged options. The sender of the = Configure-Request may not send back any message other than = Configure-Request in response to Configure-Nak, so the only recourses = available if the hint is unreasonable are to drop the option from = subsequent Configure-Request messages, use Protocol-Reject to disable = the protocol, or disconnect the link entirely. Finally, if all options are acceptable, the peer then responds with = Configure-Ack with exactly the same options list as given in the = Configure-Request to indicate that all of the enclosed options were = acceptable and that are now enabled. 6.6.1. Phase I In the first phase, basic capabilities regarding the exporting = interface support are negotiated between IPFIX end-points. If this = phase fails, the negotiation process will terminate and status = information will be provided to users.=20 The Phase I negotiation should be carried over UDP, as it is a widely = supported transport protocol.=20 6.6.1.1. Security support The security support capability is used to negotiate which methods = (e.g. IPSec, TLS, MD5, etc) can be used to provide confidentiality, = integrity and protection against spoofed attacks. 6.6.1.2. IPFIX protocol=20 It is possible that several protocols (e.g. LFAP, CRANE, Netflow, = Diameter) meet the IPFIX requirements. In this case, this capability = is used to negotiate which protocol the end points will use.=20 6.6.1.3. Version of Protocol=20 This capability is used to negotiate which version of the protocol = exporter and collector will use to communicate. Agreeing on a specific = version indicates that the end-points support all the semantics and = dynamic procedures specified by a version of the protocol.=20 The protocol syntax (information model, data model, coding schemes, = etc) should be negotiated in Phase II. =20 6.6.1.4. Transport layer support This capability is used to negotiate the transport layer protocol used = between the exporter and collector. As the reliability is a key requirement of an IPFIX system, the = transport protocol should be connection oriented, congestion aware, = reliable, and providing in-sequence data delivery (e.g. TCP, SCTP). Under some circumstances e.g., when the network path between exporter = and collectors ensures abundant bandwidth and 'no' packet loss due to = congestion, a lightweight transport protocol such as UDP may be = employed. In this case, the upper layer must provide capabilities to = ensure reliability, e.g. message integrity check, loss detection, = acknowledgment, etc. 6.6.2. Phase II In this phase, the IPFIX protocol initiates its own connection setup = that involves further capability negotiation. 6.6.2.1. Data collection triggers and policies *Update interval [TBD] *Sampling [TBD] *Aggregation rules[TBD] * Caching The exporter caches a certain amount of data before sending it to the = collector. If the collector fails, the exporter will need to hold more = data than normal while it waits for the collector to come back or = switch to different one. In order to provide for these two modes of = operation, the exporter could be configured with two levels of caching. = One level when the system is operating normally and a second when a = failure occurs. If the exporter detects that a server is unavailable; = it should use the higher cache level that allows it to hold more data = than it does in normal operation. 6.6.2.2. Reliability This capability is used to negotiate parameters related to fail-over = support, load balancing, keepalives, etc. For instance, exporter and collector SHOULD set the keepalive (in the = case of TCP) or the HEARTBEAT interval in the case of SCTP to a = sufficiently low value so that it can quickly detect a collector crash. = On detecting a Keepalive timeout, the exporter SHOULD stop sending the = flow export data to the collector and bring down the transport = connection.=20 If the exporter detects that a collector is unavailable and fail-over = was negotiated, it should try to switch to the stand-by collector in = order to resume service. If the exporter does not keep a live = connection to the stand-by collector, it MUST go through the = capabilities negotiation process described in this section before it = could export data.=20 In the case there are multiple collectors operating redundant mode, the = exporter MAY multicast the flow records to the set of collectors that = joined the export multicast group, instead of sending several unicast = streams towards the different collectors. Multicast would lower the = bandwidth requirements on the export link in case that the collectors = are on the same media, and could lower the internal bus utilization on = the exporter. In the case there are multiple collectors operating in load-balancing = mode, a weight number associated with each server MAY be used to infer = the amount of exported flows each server should receive.=20 It should be noted that servers operating in a redundant or = load-balancing mode could be running different version of the IPfix = protocol and also use different capabilities. 6.6.2.3. Templates=20 This capability is used to negotiate a common set of templates = corresponding to an IPFIX session between the exporter and collector. A = locally unique template identifier (template ID) MUST be assigned to = each template, and carried along with IPFIX user messages to ensure = correct decoding of IP flow information. Exporter and collector MUST = use the same set of templates during a session. The templates can be = renegotiated but MUST always be agreed on by all IPFIX end-points = participated in the IPFIX session before they can be used. =20 The exporter and collector MUST agree on a common set of templates = before the collector can start sending data according to them.=20 The template negotiation follows the LCP method described earlier. The = collector may propose changes to the templates received from an = exporter (e.g. enabling some keys and disabling others), or it can = acknowledge the templates as is. In the case that a template or a key = is not recognized by the collector (e.g. they might be added to the = exporter after the collector configuration has completed), the = collector MAY choose to disable each unknown key or unknown templates = in order to avoid unnecessary traffic. A template is disabled when all = the keys are disabled.=20 6.6.2.4. Extended flow type support Beside standardized minimum set of possible flow properties, the = exporter should be able to classify and export flows based on extended = information such as (but not limited to) URL, RTP Media type and SIP = Method. This capability is used to negotiate what are those extended = properties. 6.6.2.5. Messages Supported A particular protocol or version might have optional messages that=20 are not mandatory. This capability is used to negotiate what are=20 those optional messages types supported.=20 6.6.2.6. Overlapping flows This capability is used to negotiate the support of overlapping flow = awareness, i.e., if exporter has the means of inferring if the same = will be exported more than once and letting the collector of this fact. = In the absence of explicit negotiation of this capability, the = collector MUST consider that all flows reported can overlap. In the = case the device reports overlapping between certain flows, the = collector SHOULD take this into consideration, but MUST NOT assume that = other flows will not overlap 6.6.2.7. MIDCOM related Capabilities [TBD] To Be Added 6.6.3. Renegotiation of Capabilities=20 Only renegotiation of capabilities agreed on phase II can be performed = without tearing down the connection.=20 The initial negotiation can deal with a wealth of settings and assign = ID's to various capability versions. The re-negotiation needs only to = refer these IDs and require simple acknowledgement. 6.6.4. Caching of Negotiated Parameters [Reinaldo] If you need to open a connection every time you need to = export a low (or at least frequently), is there any advantage to cache = the capabilities and associate a key so that you don't have to = renegotiate them?=20 [Kevin] This is a tough one. My understanding is that IPFIX tries to = deal with high volume data export, with rather static configuration, = and a session or connection last for a very long time. Caching the = capability requires the "state information" be managed by the exporter = and collector, and then we need to talk about how to aging, removing, = and updating them.=20 [Reinaldo] Here you can reuse the ID's mentioned on the renegotiation = of capabilities. In order to be able to renegotiate using the ID's you = need to keep state anyway. 7. IPFIX Deployment Scenarios IPFIX exporting devices may vary greatly in their core functionality. = At one hand, a core router needs to support high-speed interfaces and = traffic throughput; it emphasizes on forwarding IP traffic quickly and = may not be able to perform extensive measurement on IP flow. It is also = likely to export high volume of IP flow information to external = systems. On the other hand, a measurement probe or an access device is = capable of providing more detailed information about IP flows and = performing complex on-device processing. Consequently, it may only = export low volume of IP flow information.=20 =20 Given the diversity of exporting devices, two deployment scenarios are = described. These scenarios only serve as examples for IPFIX system = design and deployment. =20 7.1. Exporting Interface over LAN=20 The following figure illustrates the scenarios where an exporting=20 device connects to the collecting devices over LAN.=20 =20 =20 +----------+ +----------+ +------------+ =20 |Exporting | |Collection|<=3D=3D>| |=20 |Device | |Device 1 | |Applications|=20 +----------+ +----------+ |e.g. |=20 ^ | ^ | |usage |=20 | v | v |accounting, |=20 --------------------------------------- |traffic |=20 LAN |profiling, | =20 --------------------------------------- |traffic |=20 ^ | |engineering,| =20 | v |QoS |=20 +----------+ |Monitoring |=20 = |Collection|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|etc= . |=20 |Device 2 | | |=20 +----------+ +------------+=20 =20 =20 This scenario is suitable for collecting information from core=20 routers. As the volume of exported data is typically high, LAN can=20 provide adequate bandwidth and introduce small latency to meet data = exporting requirement. =20 =20 7.2. Exporting Interface over WAN=20 =20 The following figure illustrates the scenario where an exporting=20 device connects to the collecting devices over WAN.=20 =20 +----------+ =20 |Collection| +------------+=20 |Device 1 |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| = |=20 +----------+ |Applications|=20 ^ |e.g. |=20 | |usage |=20 +----------+ +--|-------+ |accounting, | =20 |Exporting |<--------|--- | |traffic |=20 |Device |<--------|--------- | |profiling, |=20 +----------+ | WAN | | |traffic | =20 | | | |engineering,|=20 | | | |QoS |=20 +--------|-+ |Monitoring |=20 | |etc. | =20 v | |=20 +----------+ | |=20 |Collection|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| = |=20 |Device 2 | +------------+=20 +----------+=20 =20 This scenario maybe used to collect information from probes or access = routers. It is critical that a congestion aware transport protocol = (e.g. TCP, SCTP) is used. 8. Security Consideration (a) Data Integrity and Authentication As IPFIX is relying on underling transport protocol like TCP or SCTP = etc., IPFIX can leverage all the authentication and encryption = mechanism to the underlying protocol e.g. TLS or IPSec. =20 =20 (b) End point Authentication Since there may be more than one application interested in the = collected data. IPFIX exporter may be able to authenticate each = collector on before exchanging of packets. This may be done by having = pre-established security associations between endpoints. (c) Resistance to attacks As a general security measure, any new protocol should not introduce = possibilities of new attacks. IPFIX depends on the transport layers for = basic communications. Hence DoS attack resistance and prevention is out = of scope. =20 9. References 3. J. Quittek ,et al.," Requirements for IP Flow Information Export ", = (work in progress) ,Internet Draft, Internet Engineering Task Force, = , November 2001 4. M. Wood ,et al.," Intrusion Detection Message Exchange = Requirements",(work in progress), Internet Draft, Internet Engineering = Task Force, draft-ietf-idwg-requirements-06,February 2002. 5. Daniel O. Awduche, et. al.," Overview and Principles of Internet = Traffic Engineering", (work in progress), Internet Draft, Internet = Engineering Task Force, draft-ietf-tewg-principles-02.txt, May 2002=20 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions,=20 http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-adelaide/pp-di= st/ [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric = for IPPM,=20 , November 2001 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss = Metric for=20 IPPM, September 1999 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application = of Sampling Methodologies to Network Traffic Characterization, Proceedings of ACM = SIGCOMM'93,=20 San Francisco, CA, USA, September 13 - 17, 1993 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, = John G. CLEARY:=20 Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay = Variation on=20 the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for = Direct Traffic=20 Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, = August 28 -=20 September 1, 2000. [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric = for IPPM,=20 Request for Comments: 2679, September 1999 =20 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation of = Building Blocks=20 for Passive One-way-delay Measurements, Proceedings of Passive and = Active Measurement=20 Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 (PAM = 2001)=20 [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture and = framework," work in progress. October 2001. [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address = Translator (NAT) Terminology and Considerations", RFC 2663, August = 1999. [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network = Address Translator (Traditional NAT)", RFC 3022, January 2001. [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider = Provisioned Virtual Private Networks ", work in progress, = , January 2002.=20 [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft = , July 2001. [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and = W. Weiss, "An Architecture for Differentiated Services", RFC 2475, = December 1998. [1] Requirements for IP Flow Export, = [2] K.Zhang, et al., "Common Reliable Accounting for Network Element = (CRANE)", , February 2002 [3] G. Sadasivan, et al., "Flow Export Architecture", = , January 2002 =20 [4] Carlson, James, "PPP Design, Implementation and Debugging", Second = Edition . 10. Acknowledgements We like to thank all the people contributing to the requirements discussion on the mailing list, and the design teams for a lot of = valuable comments. George Carle Tanja Zseby Paul Calato Dave Plonka Kevin Zhang KC Norseth Phill Richards Will Eatherton Benoit Claise Ganesh Sadasivan Vamsi Valluri Ram Gopal Jc Martin Carter Bullard Juergen Quittek Reinaldo Penno Nevil Brownlee Simon Leinen 11. Author's Addresses Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Paul Calato Riverstone Networks, Inc. 5200 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 (603) 557-6913 Email: calato@riverstonenet.com Ganesh Sadasivan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1 (408) 527-0251 Email: gsadasiv@cisco.com Ram Gopal Nokia=20 5 Wayside Road,=20 Burlington, MA 01803 Phone:+1 781 993 3685 Email: ram.gopal@nokia.com Man Li=20 Nokia=20 5 Wayside Road,=20 Burlington, MA 01803=20 Phone: +1 781 993 3923=20 Email: man.m.li@nokia.com=20 K.C. Norseth Enterasys Networks 2691 S. Decker Lake Lane Salt Lake City, Utah 84119 Phone: +1 801 887 9823 Email: knorseth@enterasys.com Reinaldo Penno Nortel Networks, Inc.=20 2305 Mission College Boulevard Building SC9-B1240 =20 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com=20 Juergen Quittek NEC Europe Ltd. Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Kevin Zhang =20 XACCT Technologies, Inc.=20 2900 Lakeside Drive=20 Santa Clara, CA 95054=20 Phone +1 301 992 4697=20 Email: kevin.zhang@xacct.com Tanja Zseby GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 Email: zseby@fokus.gmd.de 12. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This = document and translations of it may be copied and furnished to others, = and derivative works that comment on or otherwise explain it or assist = in its implementation may be prepared, copied, published and = distributed, in whole or in part, without restriction of any kind, = provided that the above copyright notice and this paragraph are = included on all such copies and derivative works. However, this = document itself may not be modified in any way, such as by removing the = copyright notice or references to the Internet Society or other = Internet organizations, except as needed for the purpose of developing = Internet standards in which case the procedures for copyrights defined = in the Internet Standards process must be followed, or as required to = translate it into. 13. Stuff to Add The following items need to be addressed: * Iana Port Number for IPFIX=20 14. End of stuff to add =20 IPFIX Architecture February, 2002 =20 IPFIX WG Expires August, 2002 [Page 36] IPFIX Design Team Expires July 2002 [Page 1] ------_=_NextPart_000_01C1B3D5.794697C0 Content-Type: application/octet-stream; name="Norseth, KC.vcf" Content-Disposition: attachment; filename="Norseth, KC.vcf" BEGIN:VCARD VERSION:2.1 N:Norseth;KC FN:Norseth, KC ORG:Cabletron Systems, Inc.;5167 TEL;WORK;VOICE:53823 ADR;WORK:;Salt Lake City;2835 South Decker Lake Drive;Salt Lake City;UT;84119;US LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Salt Lake City=0D=0A2835 South Decker Lake Drive=0D=0ASalt Lake City, UT 841= 19=0D=0AUS EMAIL;PREF;INTERNET:knorseth@cabletron.com REV:19991213T143559Z END:VCARD ------_=_NextPart_000_01C1B3D5.794697C0-- -- 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 Tue Feb 12 10:27:10 2002 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 KAA15093 for ; Tue, 12 Feb 2002 10:27:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aeT7-0002Lk-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 09:03:41 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aeT4-0002Le-00 for ipfix-data@net.doit.wisc.edu; Tue, 12 Feb 2002 09:03:38 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id KAA23186; Tue, 12 Feb 2002 10:13:02 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma023142; Tue, 12 Feb 02 10:12:14 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXN59M>; Tue, 12 Feb 2002 10:01:48 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06AA@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Reinaldo Penno'" Cc: data Subject: [ipfix-data] Comments on the data model - rewrites. Date: Tue, 12 Feb 2002 10:02:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3D6.3EE98870" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3D6.3EE98870 Content-Type: text/plain Hi Reinaldo, I sent the word format in a seperate doc. I assume that you also want to include 5.11.5? K.C. -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 12, 2002 7:52 AM To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Hello K.C. The NAT part includes 5.11.6, 5.11.7, 5.11.8 and 5.11.9. Can you send me both docs in word format? thanks, Reinaldo -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Tuesday, February 12, 2002 6:45 AM To: Penno, Reinaldo [SC9:T327:EXCH]; 'Juergen Quittek'; K.C. Norseth Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Hi Reinaldo, sounds good. 5.12 - NAT 5.14.4 - Internal Queue Priority 5.10.1-2 - netmask 5.9.3-4 - ATM & Frame Relay 5.11.4 - VLAN. (I duped VLAN, it is also 5.14.11), just make one. Sorry on the URL down. It has small bandwidth and unfortunately, if it doesn't come back up on its own, It will be down until I can get to it this afternoon. I can send anyone the drafts if they cannot access my url. I have the documents in both Word and Text format. K.C. -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 12, 2002 7:04 AM To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Hello K.C. I cannot access the URL of the drafts anymore... Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also. regards, Reinaldo -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Tuesday, February 12, 2002 5:47 AM To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model There is a need to do some rewrite in the data, to make the source look like one document. Currently, the document is of 2 definit design styles. If someone can help with that, it would be great. Just let me know what section so we are not working on the same piece. I will be focusing on this myself. K.C. |-----Original Message----- |From: Juergen Quittek [mailto:quittek@ccrle.nec.de ] |Sent: Tuesday, February 12, 2002 5:43 AM |To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu |Cc: data; Calato, Paul |Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on |the data model | | |--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: | |> |> Comments: |> |> First ol all, would you guys mind if I rewrite this whole section |> using the words "private side" and "public side" so we align our |> nomenclature to RFC2663? | |Why risking further inconsistencies? Just refer to RFC 2663. |All you want to introduce is well explained there. | |> |> Also, the subsection titles refer to "virtual" this and |that, but the |> IEs refer to "outside" and "inside". So, we need some unified |> terminology. I also think that using inside and outside can cause |> confusion since the exporter/collector does not know what's |inside and |> outside. See draft-iab-unsaf-considerations-01.html | |I still have problems with "virtual", "inside", and "outside". |This applies to firewalls and IPv4 NATs, but not to several |other boxes. Why not using more general terms, such as |"received" and "transmitted" or "original" and "modified". |These terms would apply to a wider range of boxes (what is |"inside" for a NAT-PT?). | |This would make the draft more independent from certain |NAT/firewall scenarios and would be understandable even for |people who do not care about NAT issues at all. | |Reinaldo, you talked about good writing. I think this includes |avoiding irrelevant information (while still remaining clearly |understandable). | |> other stuff. |> |[...] |> |> then in 5.11.18 and 5.11.9 |> |> "The Destination Virtual IE contains the destination address of the |> flow/port as *received* by the Exporter" |> |> It should be *transmited* by the exporter, ie, you need an almost |> complete 5-tuple set of IEs for the private side and for the public |> side. | |You see, it already gets confusing. "received/original |destination" would have been a much better choice of term |compared to "virtual destination". | | Juergen |-- |Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 |NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 |Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de | | | |-- |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/ | ------_=_NextPart_001_01C1B3D6.3EE98870 Content-Type: text/html Message
Hi Reinaldo,
 
I sent the word format in a seperate doc.  I assume that you also want to include 5.11.5?
 
K.C.
 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, February 12, 2002 7:52 AM
To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

Hello K.C.
 
The NAT part includes 5.11.6, 5.11.7, 5.11.8 and 5.11.9. Can you send me both docs in word format?
 
thanks,
 
Reinaldo
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Tuesday, February 12, 2002 6:45 AM
To: Penno, Reinaldo [SC9:T327:EXCH]; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

Hi Reinaldo,
 
sounds good.
 
5.12 - NAT
5.14.4 - Internal Queue Priority
5.10.1-2 - netmask
5.9.3-4 - ATM & Frame Relay
5.11.4 - VLAN.  (I duped VLAN, it is also 5.14.11), just make one.
 
Sorry on the URL down.  It has small bandwidth and unfortunately, if it doesn't come back up on its own, It will be down until I can get to it this afternoon. I can send anyone the drafts if they cannot access my url.  I have the documents in both Word and Text format.
 
K.C.
 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, February 12, 2002 7:04 AM
To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

Hello K.C.
 
I cannot access the URL of the drafts anymore...
 
Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also.
 
regards,
 
Reinaldo
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Tuesday, February 12, 2002 5:47 AM
To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

There is a need to do some rewrite in the data, to make the source look like one document.  Currently, the document is of 2 definit design styles.  If someone can help with that, it would be great.  Just let me know what section so we are not working on the same piece.  I will be focusing on this myself.

K.C.

|-----Original Message-----
|From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
|Sent: Tuesday, February 12, 2002 5:43 AM
|To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu
|Cc: data; Calato, Paul
|Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on
|the data model
|
|
|--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
|
|>
|> Comments:
|>
|> First ol all, would you guys mind if I rewrite this whole section
|> using the words "private side" and "public side" so we align our
|> nomenclature to RFC2663?
|
|Why risking further inconsistencies? Just refer to RFC 2663.
|All you want to introduce is well explained there.
|
|>
|> Also, the subsection titles refer to "virtual" this and
|that, but the
|> IEs refer to "outside" and "inside". So, we need some unified
|> terminology. I also think that using inside and outside can cause
|> confusion since the exporter/collector does not know what's
|inside and
|> outside. See draft-iab-unsaf-considerations-01.html
|
|I still have problems with "virtual", "inside", and "outside".
|This applies to firewalls and IPv4 NATs, but not to several
|other boxes. Why not using more general terms, such as
|"received" and "transmitted" or "original" and "modified".
|These terms would apply to a wider range of boxes (what is
|"inside" for a NAT-PT?).
|
|This would make the draft more independent from certain
|NAT/firewall scenarios and would be understandable even for
|people who do not care about NAT issues at all.
|
|Reinaldo, you talked about good writing. I think this includes
|avoiding irrelevant information (while still remaining clearly
|understandable).
|
|> other stuff.
|>
|[...]
|>
|> then in 5.11.18 and 5.11.9
|>
|> "The Destination Virtual IE contains the destination address of the
|> flow/port as *received* by the Exporter"
|>
|> It should be *transmited* by the exporter, ie, you need an almost
|> complete 5-tuple set of IEs for the private side and for the public
|> side.
|
|You see, it already gets confusing. "received/original
|destination" would have been a much better choice of term
|compared to "virtual destination".
|
|    Juergen
|--
|Juergen Quittek     quittek@ccrle.nec.de     Tel: +49 6221 90511-15
|NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
|Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
|
|
|
|--
|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/
|

------_=_NextPart_001_01C1B3D6.3EE98870-- -- 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 Tue Feb 12 10:38:18 2002 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 KAA15484 for ; Tue, 12 Feb 2002 10:38:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aeJU-00025a-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 08:53:44 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aeJS-00025T-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 08:53:42 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id KAA22203; Tue, 12 Feb 2002 10:01:03 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma022188; Tue, 12 Feb 02 10:00:25 -0500 Received: by cnc-exc2.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Feb 2002 09:50:09 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06A7@slc-exc1.ctron.com> From: "Norseth, KC" To: "MacFaden, Mike" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Tue, 12 Feb 2002 09:50:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3D4.97EA2DF0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3D4.97EA2DF0 Content-Type: text/plain Hi Mike. A mib was not in our charter, but it would be useful to have. We'll see what the chairs have to say about that. Nevil was going to write a section about the relationship to RTFM, but that doesn't do what you suggest. K.C. |-----Original Message----- |From: MacFaden, Mike |Sent: Tuesday, February 12, 2002 1:48 AM |To: ipfix@net.doit.wisc.edu |Subject: Re: [ipfix] Re: Scope of IPFIX (was Answer to the |recent comments on the Architecture Draft) | | |On Mon, Feb 11, 2002 at 09:25:23PM -0700, K.C. Norseth wrote: |>Answer to the recent comments on the Architecture DraftWill, |> |>I agree. Let's go for the wg concensus. What do people say? |> |>| - the exporter configuration is out of the scope of this |document (the exporter configuration out of band) | | |Inband configuration makes the protocol more complex |as well as being prone to additional security risks. | |So I'd prefer in-band configuration not be part of the scope of the |current effort. | |That said, I would not wan to rule out experimentation |or future ability to add such a feature in a way that |can be cleanly discovered in a mixed envionment. | |An SNMP MIB module should be made available to monitor |the various components and to define, if any, standard |configuration objects. | |Mike MacFaden | | | |-- |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/ | ------_=_NextPart_001_01C1B3D4.97EA2DF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the Architecture Draft)

Hi Mike.

A mib was not in our charter, but it would be useful = to have.  We'll see what the chairs have to say about that.  = Nevil was going to write a section about the relationship to RTFM, but = that doesn't do what you suggest.

K.C.


|-----Original Message-----
|From: MacFaden, Mike
|Sent: Tuesday, February 12, 2002 1:48 AM
|To: ipfix@net.doit.wisc.edu
|Subject: Re: [ipfix] Re: Scope of IPFIX (was Answer = to the
|recent comments on the Architecture Draft)
|
|
|On Mon, Feb 11, 2002 at 09:25:23PM -0700, K.C. = Norseth wrote:
|>Answer to the recent comments on the = Architecture DraftWill,
|>
|>I agree. Let's go for the wg concensus.  = What do people say?
|>
|>| - the exporter configuration is out of the = scope of this
|document   (the exporter configuration = out of band)
|
|
|Inband configuration makes the protocol more = complex
|as well as being prone to additional security = risks.
|
|So I'd prefer in-band configuration not be part of = the scope of the
|current effort.
|
|That said, I would not wan to rule out = experimentation
|or future ability to add such a feature in a way = that
|can be cleanly discovered in a mixed envionment. =
|
|An SNMP MIB module should be made available to = monitor
|the various components and to define, if any, = standard
|configuration objects.
|
|Mike MacFaden
|
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1B3D4.97EA2DF0-- -- 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 Tue Feb 12 10:38:34 2002 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 KAA15505 for ; Tue, 12 Feb 2002 10:38:33 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aeYK-0002Sc-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 09:09:04 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aeYI-0002SF-00 for ipfix-data@net.doit.wisc.edu; Tue, 12 Feb 2002 09:09:02 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1CF7wv28647; Tue, 12 Feb 2002 09:07:59 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFX1PG>; Tue, 12 Feb 2002 07:07:56 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008982C3F@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "Norseth, KC" Cc: data Subject: [ipfix-data] RE: Comments on the data model - rewrites. Date: Tue, 12 Feb 2002 07:07:46 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3D7.076821D0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3D7.076821D0 Content-Type: text/plain; charset="iso-8859-1" okay, I can get the VLAN stuff. 5.11.4 and 5.11.5. regards, Reinaldo -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Tuesday, February 12, 2002 7:02 AM To: Penno, Reinaldo [SC9:T327:EXCH] Cc: data Subject: Comments on the data model - rewrites. Hi Reinaldo, I sent the word format in a seperate doc. I assume that you also want to include 5.11.5? K.C. -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 12, 2002 7:52 AM To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Hello K.C. The NAT part includes 5.11.6, 5.11.7, 5.11.8 and 5.11.9. Can you send me both docs in word format? thanks, Reinaldo -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Tuesday, February 12, 2002 6:45 AM To: Penno, Reinaldo [SC9:T327:EXCH]; 'Juergen Quittek'; K.C. Norseth Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Hi Reinaldo, sounds good. 5.12 - NAT 5.14.4 - Internal Queue Priority 5.10.1-2 - netmask 5.9.3-4 - ATM & Frame Relay 5.11.4 - VLAN. (I duped VLAN, it is also 5.14.11), just make one. Sorry on the URL down. It has small bandwidth and unfortunately, if it doesn't come back up on its own, It will be down until I can get to it this afternoon. I can send anyone the drafts if they cannot access my url. I have the documents in both Word and Text format. K.C. -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 12, 2002 7:04 AM To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Hello K.C. I cannot access the URL of the drafts anymore... Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also. regards, Reinaldo -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Tuesday, February 12, 2002 5:47 AM To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu Cc: data; Calato, Paul Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model There is a need to do some rewrite in the data, to make the source look like one document. Currently, the document is of 2 definit design styles. If someone can help with that, it would be great. Just let me know what section so we are not working on the same piece. I will be focusing on this myself. K.C. |-----Original Message----- |From: Juergen Quittek [ mailto:quittek@ccrle.nec.de ] |Sent: Tuesday, February 12, 2002 5:43 AM |To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu |Cc: data; Calato, Paul |Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on |the data model | | |--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: | |> |> Comments: |> |> First ol all, would you guys mind if I rewrite this whole section |> using the words "private side" and "public side" so we align our |> nomenclature to RFC2663? | |Why risking further inconsistencies? Just refer to RFC 2663. |All you want to introduce is well explained there. | |> |> Also, the subsection titles refer to "virtual" this and |that, but the |> IEs refer to "outside" and "inside". So, we need some unified |> terminology. I also think that using inside and outside can cause |> confusion since the exporter/collector does not know what's |inside and |> outside. See draft-iab-unsaf-considerations-01.html | |I still have problems with "virtual", "inside", and "outside". |This applies to firewalls and IPv4 NATs, but not to several |other boxes. Why not using more general terms, such as |"received" and "transmitted" or "original" and "modified". |These terms would apply to a wider range of boxes (what is |"inside" for a NAT-PT?). | |This would make the draft more independent from certain |NAT/firewall scenarios and would be understandable even for |people who do not care about NAT issues at all. | |Reinaldo, you talked about good writing. I think this includes |avoiding irrelevant information (while still remaining clearly |understandable). | |> other stuff. |> |[...] |> |> then in 5.11.18 and 5.11.9 |> |> "The Destination Virtual IE contains the destination address of the |> flow/port as *received* by the Exporter" |> |> It should be *transmited* by the exporter, ie, you need an almost |> complete 5-tuple set of IEs for the private side and for the public |> side. | |You see, it already gets confusing. "received/original |destination" would have been a much better choice of term |compared to "virtual destination". | | Juergen |-- |Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 |NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 |Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de | | | |-- |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/ | ------_=_NextPart_001_01C1B3D7.076821D0 Content-Type: text/html; charset="iso-8859-1" Message
okay, I can get the VLAN stuff. 5.11.4 and 5.11.5.
 
regards,
 
Reinaldo
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Tuesday, February 12, 2002 7:02 AM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: data
Subject: Comments on the data model - rewrites.

Hi Reinaldo,
 
I sent the word format in a seperate doc.  I assume that you also want to include 5.11.5?
 
K.C.
 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, February 12, 2002 7:52 AM
To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

Hello K.C.
 
The NAT part includes 5.11.6, 5.11.7, 5.11.8 and 5.11.9. Can you send me both docs in word format?
 
thanks,
 
Reinaldo
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Tuesday, February 12, 2002 6:45 AM
To: Penno, Reinaldo [SC9:T327:EXCH]; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

Hi Reinaldo,
 
sounds good.
 
5.12 - NAT
5.14.4 - Internal Queue Priority
5.10.1-2 - netmask
5.9.3-4 - ATM & Frame Relay
5.11.4 - VLAN.  (I duped VLAN, it is also 5.14.11), just make one.
 
Sorry on the URL down.  It has small bandwidth and unfortunately, if it doesn't come back up on its own, It will be down until I can get to it this afternoon. I can send anyone the drafts if they cannot access my url.  I have the documents in both Word and Text format.
 
K.C.
 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, February 12, 2002 7:04 AM
To: Norseth, KC; 'Juergen Quittek'; K.C. Norseth
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

Hello K.C.
 
I cannot access the URL of the drafts anymore...
 
Anyway, I can work on the sections I commented on. The ones related to NAT/Firewall/Cache/etc and 5.14.4, 5.10.1, 5.10.2, 5.9.3, 5.9.4. 5.11.4 and I can come up the IEs for 802.1p. I believe Juergen already wrote some text for NAT sections also.
 
regards,
 
Reinaldo
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Tuesday, February 12, 2002 5:47 AM
To: 'Juergen Quittek'; Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; ipfix@net.doit.wisc.edu
Cc: data; Calato, Paul
Subject: RE: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model

There is a need to do some rewrite in the data, to make the source look like one document.  Currently, the document is of 2 definit design styles.  If someone can help with that, it would be great.  Just let me know what section so we are not working on the same piece.  I will be focusing on this myself.

K.C.

|-----Original Message-----
|From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
|Sent: Tuesday, February 12, 2002 5:43 AM
|To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu
|Cc: data; Calato, Paul
|Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on
|the data model
|
|
|--On 12 February 2002 00:18 -0800 Reinaldo Penno wrote:
|
|>
|> Comments:
|>
|> First ol all, would you guys mind if I rewrite this whole section
|> using the words "private side" and "public side" so we align our
|> nomenclature to RFC2663?
|
|Why risking further inconsistencies? Just refer to RFC 2663.
|All you want to introduce is well explained there.
|
|>
|> Also, the subsection titles refer to "virtual" this and
|that, but the
|> IEs refer to "outside" and "inside". So, we need some unified
|> terminology. I also think that using inside and outside can cause
|> confusion since the exporter/collector does not know what's
|inside and
|> outside. See draft-iab-unsaf-considerations-01.html
|
|I still have problems with "virtual", "inside", and "outside".
|This applies to firewalls and IPv4 NATs, but not to several
|other boxes. Why not using more general terms, such as
|"received" and "transmitted" or "original" and "modified".
|These terms would apply to a wider range of boxes (what is
|"inside" for a NAT-PT?).
|
|This would make the draft more independent from certain
|NAT/firewall scenarios and would be understandable even for
|people who do not care about NAT issues at all.
|
|Reinaldo, you talked about good writing. I think this includes
|avoiding irrelevant information (while still remaining clearly
|understandable).
|
|> other stuff.
|>
|[...]
|>
|> then in 5.11.18 and 5.11.9
|>
|> "The Destination Virtual IE contains the destination address of the
|> flow/port as *received* by the Exporter"
|>
|> It should be *transmited* by the exporter, ie, you need an almost
|> complete 5-tuple set of IEs for the private side and for the public
|> side.
|
|You see, it already gets confusing. "received/original
|destination" would have been a much better choice of term
|compared to "virtual destination".
|
|    Juergen
|--
|Juergen Quittek     quittek@ccrle.nec.de     Tel: +49 6221 90511-15
|NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
|Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de
|
|
|
|--
|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/
|

------_=_NextPart_001_01C1B3D7.076821D0-- -- 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 Tue Feb 12 10:42:47 2002 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 KAA15642 for ; Tue, 12 Feb 2002 10:42:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aekP-0002hE-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 09:21:33 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aekN-0002gY-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 09:21:31 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1CFL1a36119; Tue, 12 Feb 2002 16:21:01 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA08759; Tue, 12 Feb 2002 16:21:00 +0100 Date: Tue, 12 Feb 2002 16:22:49 +0100 From: Juergen Quittek To: Benoit Claise cc: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] Re: [ipfix] Terminology suggestion Message-ID: <4213654798.1013530969@[192.168.102.164]> In-Reply-To: <3C690A62.94C9B0EF@cisco.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, --On 12 February 2002 13:28 +0100 Benoit Claise wrote: > Hi Juergen, > > quittek@ccrle.nec.de wrote: > >> Hi Benoit, >> >> Benoit Claise wrote: >> >> > Hi Juergen, >> > >> > Here are my input on this terminology, as promised during the conf. >> > call. >> > >> > Note that whether the definitions go into the requirements draft or in >> > the architecture doesn't make any difference to me. This only thing of >> > importance is that, if the requirement draft dissapears with the time, >> > we don't want to loose the defintions. One solution is that the >> > architecture document will have to repeat the definitions. >> > >> > > >> > > see draft-ietf-ipfix-reqs-00.txt, section 1.1 >> > >> > I just copied the definition from draft-ietf-ipfix-reqs-00.txt for >> > completeness. >> > A flow is a set of packets passing an observation point in the >> > network during a certain time interval. All packets belonging to a >> > particular flow have a set of common properties derived from the >> > data contained in the packet and from the packet treatment at the >> > observation point. >> > >> > I would go a little bit further in the definition, by describing what a >> > property coul be: >> > A flow is defined as a set of packets passing an observation point in the >> > network during a certain time interval. All packets belonging to a >> > particular flow have a set of common properties. Each property is >> > defined as the result of applying a function to the values of: >> > >> > a. one or more of packet header fields (eg. destination IP address) >> > b. one or more properties of the packet itself (eg. packet length) >> > c. one or more of fields derived from packet treatment (eg. AS >> > number) >> > >> > A packet is defined to belong to a flow if it matches all the defined >> > properties of the flow. >> >> Fine. But we should mention somewhere that also partial matches might be >> sufficient. > > This was implicit in our definition, i.e. the function could be anything. > If you still have problem, we can try to find another way to express it. I think I am a bit confused by the word "matches" in your last sentence. The functions are already a kind of machting functions. Now the last sentence says that a packet belongs to a flow where it matches all matching functions. What about "A packet is defined to belong to a flow if it the defined are evaluated successfully / evaluate to 'true' / are met / ... something like that. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Tue Feb 12 10:54:56 2002 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 KAA16076 for ; Tue, 12 Feb 2002 10:54:56 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aev4-0002xE-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 09:32:34 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aev2-0002wZ-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 09:32:32 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1CFW1a36468; Tue, 12 Feb 2002 16:32:01 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.164] (beta.heidelberg.ccrle.nec.de [192.168.102.164]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA08854; Tue, 12 Feb 2002 16:32:01 +0100 Date: Tue, 12 Feb 2002 16:33:49 +0100 From: Juergen Quittek To: Ganesh Sadasivan cc: Benoit Claise , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Re: [ipfix] Terminology suggestion Message-ID: <4214315248.1013531629@[192.168.102.164]> In-Reply-To: <3C6936C4.BCAA9F20@cisco.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit --On 12 February 2002 07:37 -0800 Ganesh Sadasivan wrote: > instead of matches a better wording would be "completely satisfies". > Ganesh Yes, much better. Juergen > > Juergen Quittek wrote: > >> Hi Benoit, >> >> --On 12 February 2002 13:28 +0100 Benoit Claise wrote: >> >> > Hi Juergen, >> > >> > quittek@ccrle.nec.de wrote: >> > >> >> Hi Benoit, >> >> >> >> Benoit Claise wrote: >> >> >> >> > Hi Juergen, >> >> > >> >> > Here are my input on this terminology, as promised during the conf. >> >> > call. >> >> > >> >> > Note that whether the definitions go into the requirements draft or in >> >> > the architecture doesn't make any difference to me. This only thing of >> >> > importance is that, if the requirement draft dissapears with the time, >> >> > we don't want to loose the defintions. One solution is that the >> >> > architecture document will have to repeat the definitions. >> >> > >> >> > > >> >> > > see draft-ietf-ipfix-reqs-00.txt, section 1.1 >> >> > >> >> > I just copied the definition from draft-ietf-ipfix-reqs-00.txt for >> >> > completeness. >> >> > A flow is a set of packets passing an observation point in the >> >> > network during a certain time interval. All packets belonging to a >> >> > particular flow have a set of common properties derived from the >> >> > data contained in the packet and from the packet treatment at the >> >> > observation point. >> >> > >> >> > I would go a little bit further in the definition, by describing what a >> >> > property coul be: >> >> > A flow is defined as a set of packets passing an observation point in the >> >> > network during a certain time interval. All packets belonging to a >> >> > particular flow have a set of common properties. Each property is >> >> > defined as the result of applying a function to the values of: >> >> > >> >> > a. one or more of packet header fields (eg. destination IP address) >> >> > b. one or more properties of the packet itself (eg. packet length) >> >> > c. one or more of fields derived from packet treatment (eg. AS >> >> > number) >> >> > >> >> > A packet is defined to belong to a flow if it matches all the defined >> >> > properties of the flow. >> >> >> >> Fine. But we should mention somewhere that also partial matches might be >> >> sufficient. >> > >> > This was implicit in our definition, i.e. the function could be anything. >> > If you still have problem, we can try to find another way to express it. >> >> I think I am a bit confused by the word "matches" in your last sentence. >> The functions are already a kind of machting functions. Now the last sentence >> says that a packet belongs to a flow where it matches all matching functions. >> >> What about "A packet is defined to belong to a flow if it the defined >> are evaluated successfully / evaluate to 'true' / are met / ... something >> like that. >> >> Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de >> >> -- >> 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/ > -- 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 Tue Feb 12 10:55:25 2002 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 KAA16098 for ; Tue, 12 Feb 2002 10:55:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aerv-0002sQ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 09:29:19 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aert-0002rY-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 09:29:17 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1CFSkh29500; Tue, 12 Feb 2002 07:28:46 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE04910; Tue, 12 Feb 2002 07:29:08 -0800 (PST) Message-ID: <3C6936C4.BCAA9F20@cisco.com> Date: Tue, 12 Feb 2002 07:37:40 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Re: [ipfix] Terminology suggestion References: <4213654798.1013530969@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit instead of matches a better wording would be "completely satisfies". Ganesh Juergen Quittek wrote: > Hi Benoit, > > --On 12 February 2002 13:28 +0100 Benoit Claise wrote: > > > Hi Juergen, > > > > quittek@ccrle.nec.de wrote: > > > >> Hi Benoit, > >> > >> Benoit Claise wrote: > >> > >> > Hi Juergen, > >> > > >> > Here are my input on this terminology, as promised during the conf. > >> > call. > >> > > >> > Note that whether the definitions go into the requirements draft or in > >> > the architecture doesn't make any difference to me. This only thing of > >> > importance is that, if the requirement draft dissapears with the time, > >> > we don't want to loose the defintions. One solution is that the > >> > architecture document will have to repeat the definitions. > >> > > >> > > > >> > > see draft-ietf-ipfix-reqs-00.txt, section 1.1 > >> > > >> > I just copied the definition from draft-ietf-ipfix-reqs-00.txt for > >> > completeness. > >> > A flow is a set of packets passing an observation point in the > >> > network during a certain time interval. All packets belonging to a > >> > particular flow have a set of common properties derived from the > >> > data contained in the packet and from the packet treatment at the > >> > observation point. > >> > > >> > I would go a little bit further in the definition, by describing what a > >> > property coul be: > >> > A flow is defined as a set of packets passing an observation point in the > >> > network during a certain time interval. All packets belonging to a > >> > particular flow have a set of common properties. Each property is > >> > defined as the result of applying a function to the values of: > >> > > >> > a. one or more of packet header fields (eg. destination IP address) > >> > b. one or more properties of the packet itself (eg. packet length) > >> > c. one or more of fields derived from packet treatment (eg. AS > >> > number) > >> > > >> > A packet is defined to belong to a flow if it matches all the defined > >> > properties of the flow. > >> > >> Fine. But we should mention somewhere that also partial matches might be > >> sufficient. > > > > This was implicit in our definition, i.e. the function could be anything. > > If you still have problem, we can try to find another way to express it. > > I think I am a bit confused by the word "matches" in your last sentence. > The functions are already a kind of machting functions. Now the last sentence > says that a packet belongs to a flow where it matches all matching functions. > > What about "A packet is defined to belong to a flow if it the defined > are evaluated successfully / evaluate to 'true' / are met / ... something > like that. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > -- > 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/ -- 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 Tue Feb 12 11:14:26 2002 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 LAA16777 for ; Tue, 12 Feb 2002 11:14:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16afHO-0003Ru-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 09:55:38 -0600 Received: from mailhub.lawrence.edu ([143.44.65.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16afHK-0003Ri-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 09:55:34 -0600 Received: from lawrence.edu ([143.44.97.41]) by lawrence.edu (PMDF V6.0-025 #44893) with ESMTP id <0GRF00A2JGT2ZR@lawrence.edu> for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 10:07:50 -0600 (CST) Date: Tue, 12 Feb 2002 09:55:33 -0600 From: Robert Lowe Subject: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 To: ipfix@net.doit.wisc.edu Message-id: <3C693AF5.99E74D6F@lawrence.edu> Organization: Lawrence University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi! Just a few simple questions from a lurker here, that perhaps Ganesh or Benoit can best answer. Please excuse me, if I've overlooked something in my rather quick reading of this. Section 4.1 If detection of a collector crash is impossible only because of the underlying transport, e.g. UDP, why not add an _optional_ keepalive exchange between exporter and collector? This would still not introduce as much overhead as using a reliable transport, or introduce multiple control information connections when using redundant collectors, as you outline in section 4.2. Section 5.4 You mention that templates should be periodically sent from exporter to collector. If the collector were to acknowledge receipt of these, could this not act as a simple keepalive as well? Granted, this is not something one would want to have happen frequently. Am I to assume that the collector can initiate these as well? I'm not advocating this as a form of capability negotiation (see below). --------- A few more comments regarding templates, although ones which probably fall within the realm of operational vs. protocol issues... Early on there was some discussion regarding the impact of IPFIX on the network itself, and if/how the exporter or collector should react to overload conditions. As I recall, Peter Phaal indicated that from an analysis point of view, it would not be good to change the sample rate. However, when faced with an overload condition: 1) On the exporter, should it: a. continue as is, and drop packets when it has to, or b. fall-back to a user pre-defined sampling rate, compromising IPFIX data to avoid dropping packets ?? 2) On the collector, should it: a. continue, and lose flow data because it cannot process it all, or b. signal a fall-back to a different sampling rate via a new template? If the solution uses the verb "buy", don't mention it! ;-) I can accept a good argument that these are operational issues. Also, this could be related to how an exporter deals with DoS attacks, which I haven't heard anything about recently. Perhaps all of you gentle folk talk about this stuff at IETF meetings, which I don't get to attend. -Robert -- 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 Tue Feb 12 11:37:55 2002 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 LAA17524 for ; Tue, 12 Feb 2002 11:37:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16afiW-00044N-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 10:23:40 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16afiU-00043c-00 for ipfix-arch@net.doit.wisc.edu; Tue, 12 Feb 2002 10:23:38 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1CGN6h09433; Tue, 12 Feb 2002 08:23:06 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE06140; Tue, 12 Feb 2002 08:23:29 -0800 (PST) Message-ID: <3C69437B.2F6C4626@cisco.com> Date: Tue, 12 Feb 2002 08:32:01 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "K.C. Norseth" CC: ipfix-arch@net.doit.wisc.edu, calato@riverstonenet.com Subject: Re: [ipfix-arch] definition of uni-/bi-directional flows References: <4140960312.1013458274@[192.168.102.164]> <3C681ECC.D09A8945@cisco.com> <01cd01c1b38d$c97170a0$850f880a@slc252750> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit KC, This may require some more refinement.. Let {KF1,KF2.., KFn} define the set of fields consisting of atleast one of : a . one or more of packet header fields b. one or more properties of the packet itself c. one or more of fields derived from packet treatment The corresponding flow is F(KF1,KF2.., KFn). If the flow has any characteristics which pertain to a direction w.r.t to the wire, then it is a uni-directional flow. Say forms a pair which defines the characteristic in a direction w.r.t wire. If defines the in the other direction w.r.t the wire, then Bi-directional flow can be defined as F(KF1,.. , ...KFn). Where "|" means "OR" and <> just delimits the internal set. Ganesh "K.C. Norseth" wrote: > Ganesh, > > Can you expand on what your revised text will be? > > K.C. > > ----- Original Message ----- > From: Ganesh Sadasivan > To: Juergen Quittek > Cc: > Sent: Monday, February 11, 2002 12:43 PM > Subject: Re: [ipfix-arch] definition of uni-/bi-directional flows > > | Hi Jurgene, > | You are correct. What I should have added is: > | When the direction w.r.t wire is specified, then it can be furthur > | categorised as uni/bi.. The direction however is optional and may > | not be applicable in all the cases. I beleive the scope of the flow is > | restricted to an observation point and not end-to-end. > | Thanks > | Ganesh > | > | Juergen Quittek wrote: > | > | > Hi Ganesh, > | > > | > --On 11 February 2002 11:00 -0800 Ganesh Sadasivan wrote: > | > > | > > Hi Jurgene, > | > > Refer to section 2.0 of the draft submitted by Benoit and me. It > | > > gives a detailed defintion of a uni-directional flow. > Bi-directional > | > > is a restricted set of uni-directional flows which have a sensible > | > > reverse mapping at the same observation point. I am not sure to > | > > what precision one can define a bi-directional flow. > | > > | > The flows you define are not necessarily what intuition would call > | > uni-directional. If you for example map all traffic with a source > | > or destination port 80 into one flow I would not call it > uni-directional. > | > > | > What you do is that you define a general flow and then say the regular > | > case is the uni-directional one, and bi-directional is some special > | > kind. My claim is that already uni-directional is a special kind, which > | > we have not defined yet, although we all might have a good intuition > | > teeling us what would be a uni-directional or bi-directional flow. > | > > | > Best wishes, > | > > | > Juergen > | > -- > | > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > | > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > | > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > | > > | > > > | > > Thanks > | > > Ganesh > | > > > | > > quittek@ccrle.nec.de wrote: > | > > > | > >> Hi all, > | > >> > | > >> I just ran into a strange problem: I tried to define precisely > | > >> what is a uni-directional / bi-directional flow and found out > | > >> that although I am discussing with you for quite some time > | > >> using these terms, I cannot tell precisely, what they are. > | > >> > | > >> Does anyone have such a definition? > | > >> > | > >> Of course I can define them easily when I restrict flows to > | > >> 5-tuple TCP/UDP flow without wild-carding, but when I start to > | > >> include aggregated flows, for example all packets originating > | > >> in a specific subnet, and ICMP flows, and multicast flows > | > >> (multi-directional?), then it gets much more complicated. > | > >> > | > >> 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/ > | > > > | > | > | -- > | 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/ > | > > -- > 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/ -- 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 Tue Feb 12 11:39:27 2002 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 LAA17625 for ; Tue, 12 Feb 2002 11:39:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16afh1-00040q-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 10:22:07 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16afgy-0003zu-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 10:22:04 -0600 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA10590; Tue, 12 Feb 2002 17:19:06 +0100 (MET) Message-ID: <3C694086.5D0B0891@cisco.com> Date: Tue, 12 Feb 2002 17:19:18 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <4108689799.1013426004@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, Juergen Quittek wrote: > Hi all, > > Here is my list of proposed changes to draft-ietf-ipfix-reqs-00.txt. > > I know that Benoit also is going to send some suggestions. > And of course anyone else should feel free to do so. 1. I have one question whose answer should in the requirement draft. What do we do with ICMP, IGMP? others? Do we report this traffic with IPFIX. If yes, this must be described. 2. I think we should have statements in the requirement document about: - configuration will be done out-bound Note: this is at least the direction I see in the working group on that one: Will, KC, Juergen, Mike, Ganesh and I versus Reinaldo, Kevin a version 2 of the IPFIX protocol could investigate the needs of in-band configuration - no transport negotiation (which transport) - no capability negotiation But the decisions about the last 2 bullets are still under discussion. These are the 2 next big points the group has to agree on. 3. We also want to stress that we are trying to standardize the direction exporter -> collector and not necessarely the direction collector -> exporter. Maybe in the chapter about "push and pull mode reporting" 5.4, next to "The measuring device MUST support push mode reporting, it MAY support pull mode reporting." 4. all occurences of measuring device should be replaced by exporter 5. Let's not forget the comment from Nevil Section 4.5 Timeouts. More detail needed here. At least we need to say "user must be able to specify timeout interval for fixed timeout intervals." And maybe we should allow for some kinds of dynamic timeouts too, e.g. "timeout after specified minimum time, when no packets have been seen for twice the average inter-packet time while the flow was active." ??? 6. I would remove the remotely from sectiont 6., this could be confusing. The measuring device MUST provide a way of configuring the traffic measurement and the traffic data export remotely. > > > Cheers, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > 1. insert new section "2. Terminology" > > 2. Make section "1.1 IP Flows" new section "2.1. IP Traffic > Flows or Flows" - Maybe the flow definition will have to be adapted. See our terminology thread. - The observation point definition should be removed from there. > > > 3. Add sections 2.2 to 2.8: Sure we will have to insert the definitions but there are still under discussion. > > 2.2. Observation Point > The observation point is a location in the network > where IP packets can be observed. Examples are a line > to which a probe is attached, a shared medium, such as > an Ethernet-based LAN, a port of a router, or an > entire router with several ports. > > 2.3. Trafic Flow Meter or Meter > A meter observes packets at one or more obsrvation > points. It analyzes the content of the packets and maps > them to flows. For each observed flow the meter computes > statistics and maintains a flow record where it stores > relevant flow infromation. > > 2.4. Metering Process > The metering process includes all actions performed by a > meter with respect to observing packets, timestamping > them, analyzing them, mapping them to flows, computing > flow statistics, detecting flow expiration, and > maintaining flow records. > > 2.5. Flow Record > A flow record keeps information a flow including > characteristic properties of the flow, for example the > source IP address, and measured properties of the flow, > for example the total number of bytes of all packets of > the flow. > > 2.6. Flow Information Exporter or Exporter > The exporter sends flow records created and maintained > by one or more meters to one or more data collectors. > > 2.7. Flow Information Data Collector or Data Colletor > The data collector receives flow records from one or > more exporters. The data collector might process or > store received flow record, but these actions are out > of the scope of this document. > > 2.8. Flow Information Exort > Flow information export denotes the process of > transferring flow records from an exporter to a data > collector. > > 4. Remove section 2.5 Network Surveillance > > 5. In section 2.6, 3rd paragraph: > remove "'Heisenberg' effects," > > 6. In section 4.1, last sentence: > replace "then it SHOULD be stored ... inaccurately." > by "then the measuring device MUST be able to detect > this failure and to report about it." > > 7. Replace section "4.2 Sampling" by section "4.2 Overload > Behavior": I tend to disagree. The metering can do sampling versus full And in case of overload, the metering process might switch to sampling. These are 2 different topics. If you want to keep overload behavior, here is what I can propose: 4.2. Sampling The measuring device MAY support measuring traffic by packet sampling. If sampling is supported the sampling method and its parameters MUST be well defined. 4.2.1 Overload Behavior In case of an overload, e. g. lack of memory or processing power, the measuring device MAY change the metering process in order to cope with the lack of resources. Possible reactions include: - Reduce the number of flow accounts. This can be achieved by more coarse grained flow measurement or by a restriction of the flow accounts to a subset of the set of original ones. - Sample packets before they are processed by the meter. - Stop metering. Overload behavior is not restricted to the three options listed above. But in any case, the overload behavior MUST be clearly defined. For example in case of sampling, the sampling method and all its parameters MUST be known or indicated. > > > 8. Append to section "4.3 Timestamps" > Also in case of a switch to overload behavior, a > timestap MUST be generated for this event as well as for > a switch back to regular behavior. I'm not too sure what you mean. That's it for now. Regards, Benoit > > > > 9. Change section 5.3.1. "Congestion Awareness" to > "Congestion-Friendlyness" > Replace text of subsection by "For the flow information > export a congestion-friendly protocol MUST be supported." > > 10. Insert new section 5.3.3 Robustness > Data transfer SHOULD be robust against network and > system fault conditions. Robustness may be supported for > example by > - flow control > - by deploying redundant data receiving systems > - fail-over/fail-back procedures. > However, robustness should not be traded with > congestion-friendlyness which has higher priority. > > 11. Update reference [MIDBOXTAX] which is now updated to > version -03. > > 12. Remove all entries for network surveillance from table > in Appendix > > 13. Update Table in appendix according to changes in text. > > -- > 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/ -- 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 Tue Feb 12 12:08:22 2002 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 MAA18713 for ; Tue, 12 Feb 2002 12:08:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ag1i-0004bC-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 10:43:30 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ag1e-0004ah-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 10:43:26 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1CGgsh23360; Tue, 12 Feb 2002 08:42:55 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE06647; Tue, 12 Feb 2002 08:43:16 -0800 (PST) Message-ID: <3C694823.AC526311@cisco.com> Date: Tue, 12 Feb 2002 08:51:48 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Lowe CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 References: <3C693AF5.99E74D6F@lawrence.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Robert Lowe wrote: > Hi! > > Just a few simple questions from a lurker here, that perhaps Ganesh or Benoit > can best answer. Please excuse me, if I've overlooked something in my rather > quick reading of this. > > Section 4.1 > > If detection of a collector crash is impossible only because of the underlying > transport, e.g. UDP, why not add an _optional_ keepalive exchange between exporter > and collector? This would still not introduce as much overhead as using a > reliable transport, or introduce multiple control information connections > when using redundant collectors, as you outline in section 4.2. This could be done. > > > Section 5.4 > > You mention that templates should be periodically sent from exporter to > collector. If the collector were to acknowledge receipt of these, could > this not act as a simple keepalive as well? Granted, this is not something > one would want to have happen frequently. Am I to assume that the collector > can initiate these as well? I'm not advocating this as a form of capability > negotiation (see below). One can mix data & control stream into one. ACKing becomes an overhead in such a case. > > > --------- > > A few more comments regarding templates, although ones which probably fall > within the realm of operational vs. protocol issues... > > Early on there was some discussion regarding the impact of IPFIX on the > network itself, and if/how the exporter or collector should react to > overload conditions. As I recall, Peter Phaal indicated that from an > analysis point of view, it would not be good to change the sample rate. > However, when faced with an overload condition: > > 1) On the exporter, should it: > a. continue as is, and drop packets when it has to, or > b. fall-back to a user pre-defined sampling rate, compromising > IPFIX data to avoid dropping packets ?? a. would be the default but keep a count of what gets dropped. . b. is optional since not all devices may be able to support this. > > > 2) On the collector, should it: > a. continue, and lose flow data because it cannot process it all, or > b. signal a fall-back to a different sampling rate via a new template? a. would be the default. b. is in the lines of inband config. I would say raise an alarm to the management station which decides the appropriate action to be taken. Thanks Ganesh > > > If the solution uses the verb "buy", don't mention it! ;-) I can accept a > good argument that these are operational issues. > > Also, this could be related to how an exporter deals with DoS attacks, which > I haven't heard anything about recently. Perhaps all of you gentle folk > talk about this stuff at IETF meetings, which I don't get to attend. > > -Robert > > -- > 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/ -- 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 Tue Feb 12 12:11:35 2002 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 MAA18873 for ; Tue, 12 Feb 2002 12:11:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16agA1-0004ik-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 10:52:05 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ag9z-0004ib-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 10:52:03 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id MAA03273; Tue, 12 Feb 2002 12:01:28 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xmac03078; Tue, 12 Feb 02 12:01:06 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXN87J>; Tue, 12 Feb 2002 11:50:15 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06B3@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Robert Lowe'" , ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 Date: Tue, 12 Feb 2002 11:50:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B3E5.65D2EFD0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B3E5.65D2EFD0 Content-Type: text/plain Hi Robert, Lurkers are welcome. |-----Original Message----- |From: Robert Lowe [mailto:robert.h.lowe@lawrence.edu] |Sent: Tuesday, February 12, 2002 8:56 AM |To: ipfix@net.doit.wisc.edu |Subject: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 | | |Hi! | |Just a few simple questions from a lurker here, that perhaps |Ganesh or Benoit |can best answer. Please excuse me, if I've overlooked |something in my rather |quick reading of this. | |Section 4.1 | |If detection of a collector crash is impossible only because |of the underlying transport, e.g. UDP, why not add an |_optional_ keepalive exchange between exporter and collector? |This would still not introduce as much overhead as using a |reliable transport, or introduce multiple control information |connections when using redundant collectors, as you outline in |section 4.2. This is a section I am working on. I have not had a chance to finish it yet. We need some way of communicating between the collector and the exporter, if just to let the exporter know the collector is not there for failover. |Section 5.4 | |You mention that templates should be periodically sent from |exporter to |collector. If the collector were to acknowledge receipt of |these, could this not act as a simple keepalive as well? |Granted, this is not something one would want to have happen |frequently. Am I to assume that the collector can initiate |these as well? I'm not advocating this as a form of |capability negotiation (see below). Good point. Some response from the collector is a signal there. | |--------- | |A few more comments regarding templates, although ones which |probably fall within the realm of operational vs. protocol issues... | |Early on there was some discussion regarding the impact of |IPFIX on the network itself, and if/how the exporter or |collector should react to overload conditions. As I recall, |Peter Phaal indicated that from an analysis point of view, it |would not be good to change the sample rate. However, when |faced with an overload condition: | |1) On the exporter, should it: | a. continue as is, and drop packets when it has to, or | b. fall-back to a user pre-defined sampling rate, compromising | IPFIX data to avoid dropping packets ?? | |2) On the collector, should it: | a. continue, and lose flow data because it cannot |process it all, or | b. signal a fall-back to a different sampling rate via |a new template? | |If the solution uses the verb "buy", don't mention it! ;-) I |can accept a good argument that these are operational issues. This is very dangerous to have the exporter switch to sampling automatically. This could really confuse the information being gathered. You could get the message from the reports that volume has dropped down during a period of time, but in reality, it is dnagerously high. K.C. |Also, this could be related to how an exporter deals with DoS |attacks, which I haven't heard anything about recently. |Perhaps all of you gentle folk talk about this stuff at IETF |meetings, which I don't get to attend. | |-Robert | |-- |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/ | ------_=_NextPart_001_01C1B3E5.65D2EFD0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] Questions regarding = draft-gsadasiv-ipfix-proposal-00

Hi Robert, 

Lurkers are welcome.

|-----Original Message-----
|From: Robert Lowe [mailto:robert.h.lowe@lawrence= .edu]
|Sent: Tuesday, February 12, 2002 8:56 AM
|To: ipfix@net.doit.wisc.edu
|Subject: [ipfix] Questions regarding = draft-gsadasiv-ipfix-proposal-00
|
|
|Hi!
|
|Just a few simple questions from a lurker here, = that perhaps
|Ganesh or Benoit
|can best answer.  Please excuse me, if I've = overlooked
|something in my rather
|quick reading of this.
|
|Section 4.1
|
|If detection of a collector crash is impossible = only because
|of the underlying transport, e.g. UDP, why not add = an
|_optional_ keepalive exchange between exporter and = collector? 
|This would still not introduce as much overhead as = using a
|reliable transport, or introduce multiple control = information
|connections when using redundant collectors, as you = outline in
|section 4.2.

This is a section I am working on.  I have not = had a chance to finish it yet.  We need some way of communicating = between the collector and the exporter, if just to let the exporter = know the collector is not there for failover.

|Section 5.4
|
|You mention that templates should be periodically = sent from
|exporter to
|collector.  If the collector were to = acknowledge receipt of
|these, could this not act as a simple keepalive as = well? 
|Granted, this is not something one would want to = have happen
|frequently.  Am I to assume that the collector = can initiate
|these as well?  I'm not advocating this as a = form of
|capability negotiation (see below).

Good point.  Some response from the collector is = a signal there.
|
|---------
|
|A few more comments regarding templates, although = ones which
|probably fall within the realm of operational vs. = protocol issues...
|
|Early on there was some discussion regarding the = impact of
|IPFIX on the network itself, and if/how the = exporter or
|collector should react to overload = conditions.  As I recall,
|Peter Phaal indicated that from an analysis point = of view, it
|would not be good to change the sample rate. = However, when
|faced with an overload condition:
|
|1) On the exporter, should it:
|       a. continue as = is, and drop packets when it has to, or
|        b. = fall-back to a user pre-defined sampling rate, compromising
|           = IPFIX data to avoid dropping packets ??
|
|2) On the collector, should it:
|        a. = continue, and lose flow data because it cannot
|process it all, or
|        b. = signal a fall-back to a different sampling rate via
|a new template?
|
|If the solution uses the verb "buy", = don't mention it!  ;-)  I
|can accept a good argument that these are = operational issues.

This is very dangerous to have the exporter switch to = sampling automatically.  This could really confuse the information = being gathered.  You could get the message from the reports that = volume has dropped down during a period of time, but in reality, it is = dnagerously high.

K.C.

|Also, this could be related to how an exporter deals = with DoS
|attacks, which I haven't heard anything about = recently. 
|Perhaps all of you gentle folk talk about this = stuff at IETF
|meetings, which I don't get to attend.
|
|-Robert
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1B3E5.65D2EFD0-- -- 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 Tue Feb 12 12:23:57 2002 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 MAA19286 for ; Tue, 12 Feb 2002 12:23:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16agMq-00056U-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 11:05:20 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16agMo-00055E-00; Tue, 12 Feb 2002 11:05:19 -0600 Received: from riverstonenet.com (134.141.180.88 [134.141.180.88]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYY4DG; Tue, 12 Feb 2002 09:04:03 -0800 Message-ID: <3C694B02.F6BBD5F2@riverstonenet.com> Date: Tue, 12 Feb 2002 12:04:02 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: [ipfix-data] Re: [ipfix] Draft updates - Comments on the data model References: <4204037903.1013521352@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Comments in-line... Juergen Quittek wrote: > > --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > > > > > Comments: > > > > First ol all, would you guys mind if I rewrite this whole > > section using the words "private side" and "public side" so > > we align our nomenclature to RFC2663? > > Why risking further inconsistencies? Just refer to RFC 2663. > All you want to introduce is well explained there. > > > > > Also, the subsection titles refer to "virtual" this and that, > > but the IEs refer to "outside" and "inside". So, we need some > > unified terminology. I also think that using inside and outside > > can cause confusion since the exporter/collector does not know > > what's inside and outside. See draft-iab-unsaf-considerations-01.html > > I still have problems with "virtual", "inside", and "outside". > This applies to firewalls and IPv4 NATs, but not to several other > boxes. Why not using more general terms, such as "received" and > "transmitted" or "original" and "modified". These terms would > apply to a wider range of boxes (what is "inside" for a NAT-PT?). > > This would make the draft more independent from certain NAT/firewall > scenarios and would be understandable even for people who do not care > about NAT issues at all. I thought I addressed this already buit let me try again. BTW - I believe this my proposal is not at all specific to NAT/firewall. Maybe an example is the best way to explain it. Using your terminology it looks like this Flow on the way out... C -> IP-R gets translated to C -> IP-A Gets reported as Src = C Dest-Received = IP-O Dest-Transmitted = IP-A On the way back IP-A -> C gets translated to IP-O -> C Gets Reported as Src-Received = IP-A Src-Transmitted = IP-O Dest = C Now suppose I want to find all the flows to and from my virtual IP. First I need a list of virtual IP's so I can find them. Then I need to search both the received and transmitted fields for both Src and Dest. It can be done but it can also be easier (maybe not easier for the IPFIX protocol but that's not what we're here for). If reported as I proposed it looks like this... Src = C Dest-virtual = IP-O Dest-Actual = IP-A Src-virtual = IP-O Src-Actal = IP-A Dest = C Now if I want to see all the traffic for my virtual IP's I just look for flows that have the same src or dest virtual address. I don't need a list and the query is simple. Also, the data in the fields is clear. The actual field is where the packet actually came from or went to. The virtual is the requested source or destination. This work for ANY packet that gets re-directed for ANY reason. Even if IP's are not actually modified. Such as MAC based re-direction. > > Reinaldo, you talked about good writing. I think this includes > avoiding irrelevant information (while still remaining clearly > understandable). > > > other stuff. > > > [...] > > > > then in 5.11.18 and 5.11.9 > > > > "The Destination Virtual IE contains the destination address of > > the flow/port as *received* by the Exporter" > > > > It should be *transmited* by the exporter, ie, you need an almost > > complete 5-tuple set of IEs for the private side and for the > > public side. > > You see, it already gets confusing. "received/original destination" > would have been a much better choice of term compared to "virtual > destination". > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Tue Feb 12 12:43:37 2002 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 MAA19930 for ; Tue, 12 Feb 2002 12:43:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aggM-0005YZ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 11:25:30 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16agMo-00055E-00; Tue, 12 Feb 2002 11:05:19 -0600 Received: from riverstonenet.com (134.141.180.88 [134.141.180.88]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYY4DG; Tue, 12 Feb 2002 09:04:03 -0800 Message-ID: <3C694B02.F6BBD5F2@riverstonenet.com> Date: Tue, 12 Feb 2002 12:04:02 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: Re: [ipfix] Draft updates - Comments on the data model References: <4204037903.1013521352@[192.168.102.164]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Comments in-line... Juergen Quittek wrote: > > --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > > > > > Comments: > > > > First ol all, would you guys mind if I rewrite this whole > > section using the words "private side" and "public side" so > > we align our nomenclature to RFC2663? > > Why risking further inconsistencies? Just refer to RFC 2663. > All you want to introduce is well explained there. > > > > > Also, the subsection titles refer to "virtual" this and that, > > but the IEs refer to "outside" and "inside". So, we need some > > unified terminology. I also think that using inside and outside > > can cause confusion since the exporter/collector does not know > > what's inside and outside. See draft-iab-unsaf-considerations-01.html > > I still have problems with "virtual", "inside", and "outside". > This applies to firewalls and IPv4 NATs, but not to several other > boxes. Why not using more general terms, such as "received" and > "transmitted" or "original" and "modified". These terms would > apply to a wider range of boxes (what is "inside" for a NAT-PT?). > > This would make the draft more independent from certain NAT/firewall > scenarios and would be understandable even for people who do not care > about NAT issues at all. I thought I addressed this already buit let me try again. BTW - I believe this my proposal is not at all specific to NAT/firewall. Maybe an example is the best way to explain it. Using your terminology it looks like this Flow on the way out... C -> IP-R gets translated to C -> IP-A Gets reported as Src = C Dest-Received = IP-O Dest-Transmitted = IP-A On the way back IP-A -> C gets translated to IP-O -> C Gets Reported as Src-Received = IP-A Src-Transmitted = IP-O Dest = C Now suppose I want to find all the flows to and from my virtual IP. First I need a list of virtual IP's so I can find them. Then I need to search both the received and transmitted fields for both Src and Dest. It can be done but it can also be easier (maybe not easier for the IPFIX protocol but that's not what we're here for). If reported as I proposed it looks like this... Src = C Dest-virtual = IP-O Dest-Actual = IP-A Src-virtual = IP-O Src-Actal = IP-A Dest = C Now if I want to see all the traffic for my virtual IP's I just look for flows that have the same src or dest virtual address. I don't need a list and the query is simple. Also, the data in the fields is clear. The actual field is where the packet actually came from or went to. The virtual is the requested source or destination. This work for ANY packet that gets re-directed for ANY reason. Even if IP's are not actually modified. Such as MAC based re-direction. > > Reinaldo, you talked about good writing. I think this includes > avoiding irrelevant information (while still remaining clearly > understandable). > > > other stuff. > > > [...] > > > > then in 5.11.18 and 5.11.9 > > > > "The Destination Virtual IE contains the destination address of > > the flow/port as *received* by the Exporter" > > > > It should be *transmited* by the exporter, ie, you need an almost > > complete 5-tuple set of IEs for the private side and for the > > public side. > > You see, it already gets confusing. "received/original destination" > would have been a much better choice of term compared to "virtual > destination". > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Tue Feb 12 13:06:09 2002 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 NAA20447 for ; Tue, 12 Feb 2002 13:06:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ah1L-000636-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 11:47:11 -0600 Received: from eng4.oar.net ([192.148.244.24]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16ah1J-00062y-00 for ipfix-arch@net.doit.wisc.edu; Tue, 12 Feb 2002 11:47:09 -0600 Received: (qmail 2161 invoked by uid 4454); 12 Feb 2002 17:46:52 -0000 Date: Tue, 12 Feb 2002 12:46:52 -0500 From: Mark Fullmer To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] draft-gsadasiv-ipfix-proposal-00.txt Message-ID: <20020212124652.A2133@net.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Precedence: bulk Sender: majordomo listserver A few comments on draft-gsadasiv-ipfix-proposal-00.txt. This made it to a few people but the list bounced the address I originally sent from * Flow Header: Every flow export packet includes a flow header which carries some general information about the exporter, packet identification etc. ### Using the export "packet" term too soon, ie if this is a TCP control connection the packet may be partial. defined as a set of packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: a. one or more of packet header fields (eg. destination IP address) b. one or more properties of the packet itself (eg. packet length) c. one or more of fields derived from packet treatment (eg. AS number) ### This implies that if an IP address:AS mapping changes then there would be a new flow if additional packets are are received from the original IP. This needs clarification. An implementation may choose to do the AS and potentially other accounting fields lookup during the export phase. A packet is defined to belong to a flow if it matches all the defined properties of the flow. Flows can be defined in multiple ways. Some examples are: Example 1: To create flows, we define the different fields to distinguish flows. The different combination of the field values creates unique flows. If the keys are defined as {source IP address, destination IP address, TOS}, then all of ### This is misleading, flow state is created by traffic, not by defining them. It would be interesting to see multicast flow state created by the multicast routing protocols instead of traffic, I'll get to this in a different message. pass the observation point, in order to select only certain flows. The filter is defined by choosing fixed values for specific fields from the packet. All the packets that go from a customer network 192.1.40.0/24 to another customer network 171.6.23.0/24 with TOS value of 4 define a flow. All other combinations don't define a flow and are not taken into account. The 3 flows from example 2 would now be reduced to 1 flow, by filtering away the second and the third flow. {192.1.40.0/24, 171.6.23.0/24, 4}. ### I think we need some crude ascii art here. packets from observation point || || \/ sampling || || \/ filtering || || \/ translations || || \/ flow-engine || || \/ filtering of potential exports || || \/ export-queue || IPFIX || \/ collector Above the flow-engine can be considered the metering process and below it the IPFX protocol. flow-engine could be expanded to include bidirectional and aggregation explanations. 2.2. Unidirectional and Bidirectional Flows A flow defined by the above terms is unidirectional. In case the exporter has got the knowledge of the bi-directional flows and in case the bi-directional information make sense, the exporter MAY choose to export in the same Template/Flow Record, along with bidirectional accounting information. This would save some bandwidth as the exporter won't have to send two unidirectional flow records. ### You're referencing Template and Flow Record before defining them. is recomended that the flow record carry the Observation Point information along with the flow records when exported. In cases where there is a single observation point or where the observation point information is not relevant, the exporter MAY choose not to add this to the flow records. ### Record or Header. This may be too detailed verbage here since the export process is not detailed until later. 3.2.2. Sampling packets on a flow type (Si) Packets that satisfy the sampling criteria for this flow type. Example: Sample every 100th packet that was received at an observation point and collect the flow information for a particular flow type. Choosing all the packets is a special case where sampling rate is 1:1. ### Need to use consistent wording when describing the maintenance of flow state. 'collect' is used here. 3.3. Selection Criteria of flows for export The measurement device MAY define additional rules so that only certain flows records are picked up for export. This MAY be done by either one of the two types of methods defined in 2.3.1 and 2.3.2 or a combination of them. Example: The flow records which meets the following selection criteria are ### You're talking about exporting before defining what the export is. Need to establish relationship between flow state expiration and export first. 4. Flow Export Protocol The information that needs to be exported from the exporter can be classified into the following categories: * Control Information - This includes the flow type definition, selection criteria for packets within the flow. This is also called as control stream. ### This is implying you're sending things like ACL's that define the filters? Good luck getting the group to agree on a standard format for ACL's :) multicast group, instead of sending several unicast streams towards the different collectors. Multicast would lower the bandwidth requirements on the export link in case that the collectors are on the same media, and could lower the internal bus utilization on the exporter. Using multicast session with more than one collector joining the flow export multicast group, redundancy of collectors can be easily achieved. ### Add some verbage about Multicast and security issues. Anyone can join group, etc. secondary and a priority assigned to them. The primary collector crash is detected at the exporter by the break in control connection (depending on the transport protocol the connection timeout mechanisms differ). On detecting loss of connectivity, the exporter opens data stream with the secondary collector of the next highest priority. This collector now becomes the primary. The maximum export data loss would be the amount of data exported in the time between when the loss of connectivity to the collector happened, and the time at which this was detected by the exporter. ### Why is the separate control channel optional. Why not just define it and make it TCP? It simplifies a bunch of other things later on. When using TCP a procedure must be defined if the collector can not decode the packet (ie garbled TCP stream). For example reset the connection. The control connection should include a simple authenticator like a shared secret so the collector can have some confidence it's a valid exporter. Sequence Number: Exporter generated number which uniquely identifies a packet. The sequence number increments for subsequent export packets. A separate sequence number is manintained for control and export data packets if control and data are send in separate packets. ### In the current NetFlow export implementation the sequence number is per flow so the collector can calculate lost flows. With per packet sequence number this functionality is lost. Mixing in control information complicates it even more (did you lose a control packet or flow packet). Source ID: Unique identifier per observation domain. ### There needs to be an exporter ID (IP address) so that replicated IPFX packets retain the exporter. I'd like to see the Source ID restricted to 16 bits so the collector doesn't need to maintain a hash table to track the sequence numbers per exporter. 5.2. Template and Template Flowsets Templates are used to completely identify the structure and semantics of a particular information that needs to be communicated from the exporter to the collector. Each template is uniquely identified by a Template ID. The Template ID is a 16 bit identifier. A block of templates from <0-255> are reserved for sending some of the control information. The rest of the template IDs can be used by the exporter to define the templates for the various flow types defined within the exporter. A Template within an export packet is called as a template record. A Template Flowset is a collection of one or more template records which have been grouped together in an export packet. The Flowset ID of a template flowset maps to a particular template format. ### Your template explanation took a while to digest. How about including some common terminology like Type Length Value, ie the Template is the Type and Length, the flow records are the Values. 5.3.1. Case A, Template for Flow Record Definition The common examples of this case are templates for exported flow records, and templates for flow related statistics or errors in the exporter. Example of statistics information: total numbers of flows. The format of the Template Flowset for this case is described below: ### Need common terminology again. Statistics or Accounting? 5.4. Template Export Management The exporter takes the following steps for template export: * Periodically sends the entire template information and configuration information to the collector. This corresponds to the set of all Template IDs along with their descriptions and the set of all Observation IDs along with their descriptions. The periodic export frequency SHOULD be configurable in the exporter. ### If the control connection is required this can go away. The format of the Data Flowset is described below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowSet ID = Template ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1 - Field Value 1 | Record 1 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2 - Field Value 1 | Record 2 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 3 - Field Value 1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ### Verbage needs to be added about alignment. u_int32's on 32 bit boundries, u_in16's on on 16 bit boundries, etc. This also implies needing a 'NULL' field type for padding. Need to define byte order of fields. Also the exporter SHOULD provide optimal encoding, ie u_int32 u_int16 u_int16 u_int8 u_int8 u_int8 u_int8 not u_int8 pad pad pad u_int32 u_int8 pad pad pad u_int16 u_int8 pad u_int16 u_int8 pad In case the exporter is doing NAT [3] and in case the observation domain has got the knowledge of both inside and outside parameters, the exporter MAY choose to export both inside and outside parameters in the same Template/Flow Record (The NAT parameters being the IP address and/or the UDP/TCP ports). If not the exporter will only export the parameters observed at the observation point. ### s/got// IPV4_SRC_ADDR 8 4 Source IPv4 Address SRC_MASK 9 1 source route's mask bits ### IPV4_SRC_MASK, be consistent INPUT_SNMP 10 2 Input interface index ### just call it ifIndex TCP/UDP destination port L4_DST_PORT 11 2 number (.e.g, FTP, Telnet, etc...) IPV4_DST_ADDR 12 4 Destination IPv4 Address DST_MASK 13 1 destination route's mask ### ditto Bits OUTPUT_SNMP 14 2 Output interface index ### ditto IPV4_NEXT_HOP 15 4 Next hop router's IPv4 Address SRC_AS 16 4 Source BGP Autonomous ### Unicast source AS. Remember we have a multicast RIB too. Maybe for multicast it's the multicast source AS (they should be the same) DST_AS 17 4 Destination BGP Autonomous System Number IN_BYTES_64 23 8 64-bit counter for bytes associated with an IP Flow IN_PKTS_64 24 8 64-bit counter for packets associated with an IP Flow ### what about IN_*_32? FLOW_LABEL 31 2 IPV6 Flow Label ### IPV6_ packets are sampled. For SAMPLING_INTERVAL 34 1 example, a value of 100 indicates that one of every hundred packets is sampled. ### This looks too restrictive, need at least 2 bytes, ie what about 1/1000 ### Juniper also has a run length The type of algorithm used for sampling data. Currently, the only sampling algorithm defined SAMPLING_ALGO 35 1 is: 0x02 packet-sampling Timeout value for active FLOW_ACTIVE_TIMEOUT 36 2 flow entries in the cache. Timeout value for inactive FLOW_INACTIVE_TIMEOUT 37 2 flow entries in the cache. ### This looks like control channel information. Should indicate this. 8. The Collector Side The collector SHOULD receive template definitions from the exporter, before receiving flow records. The flow records can then be decoded and stored locally on the collector. In case the template definitions have not been received at the time a Flow Record is received, the collector SHOULD keep the Flow Record for later decoding when the template definitions will be received. The collector MUST decode and store the entire flow records, even if the semantics of one or more of the field types in the template associated with the flow record is not understood. ### The "MUST decode and store" the entire flow record should be dropped. The collector may decide to only store some of the fields. It may also decide to add fields of its own, for example exporter source. mark -- 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 Tue Feb 12 13:50:56 2002 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 NAA21827 for ; Tue, 12 Feb 2002 13:50:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ahaG-0006n5-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 12:23:16 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ahaE-0006lp-00 for ipfix-data@net.doit.wisc.edu; Tue, 12 Feb 2002 12:23:14 -0600 Received: from riverstonenet.com (134.141.180.88 [134.141.180.88]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYYVJX; Tue, 12 Feb 2002 10:21:57 -0800 Message-ID: <3C695D44.40D5A338@riverstonenet.com> Date: Tue, 12 Feb 2002 13:21:56 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Norseth, KC" , data Subject: [ipfix-data] Data Doc References: <3C695880.69C2A4FB@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit KC, here are a bunch of edits. If you want, send me the source and I'll take editor responsibilties for it. Paul calato@riverstonenet.com wrote: > > IPFIX working group > Internet Draft > draft-ietf-ipfix-data-00.txt > Expires: August 2002 > > Benoit Claise > Cisco Systems > P. Calato > Riverstone Networks Inc > Ram Gopal > Man Li > Nokia > K.C. Norseth > Enterasys Networks > Reinaldo Penno > NortelNetworks > J. Quittek > NEC Europe Ltd. > Ganesh Sadasivan > Cisco Systems, Inc.Kevin Zhang > XACCT Technologies > Tanja Zseby > FhI FOKUS > > February 2002 > > IPFIX Architecture > Architecture Model for IP Flow Information Export > draft-ietf-ipfix-data-00.txt > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with all > provisions of Section 10 of RFC2026 [1]. > > Internet-Drafts are working documents of the Internet Engineering Task > Force (IETF), its areas, and its working groups. Note that other groups > may also distribute working documents as Internet-Drafts. > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet- Drafts as reference material > or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Abstract > > This document defines architecture for scalable monitoring, measuring > and exporting IP flow information to collectors. > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC-2119 [1]. > > 1. Introduction 5 > 2. Scope 5 > 3. Terminology 5 > 4. Information Model 5 > 4.1. Attributes related to IP Packet Header 6 > 4.2. Attributes Related to Measurement 6 > 4.3. Attributes Related to Flow Definition 6 > 4.4. Attributes related to Upper Layers 6 > 4.5. IPFIX Template 7 > 4.5.1. Template Negotiation 7 > 5. Information Elements 7 > 5.1. Packet Management 7 > 5.1.1. Version Number 7 > 5.1.2. FLOWS 7 > 5.1.3. FLOW_LABEL 7 > 5.2. IP Address 7 > 5.2.1. Source Address IE 7 > 5.2.2. Destination Address IE 8 > 5.2.3. NEXT_HOP_IP IE 8 > 5.3. Time Stamps 8 > 5.3.1. Time IE 8 > 5.3.2. UTC Time IE 8 > 5.3.3. Delta Time IE 8 > 5.4. Service Types 8 > 5.4.1. Class of Service IE 8 > 5.4.2. TCP Control Bits IE 9 > 5.4.3. Protocol Identifier IE 9 > 5.4.4. Source Exporter [ is that the right term?? PAC] Address IE > 9 > 5.5. Flow State IE 9 > 5.6. Statistical Elements 9 > 5.6.1. Byte Count IE 10 > 5.6.2. Packet Count IE 10 > 5.6.3. Dropped Byte Count IE 10 > 5.6.4. Dropped Packet Count IE 10 > 5.7. Port Information 11 > 5.7.1. Source Port IE 11 > 5.7.2. Destination Port IE 11 > 5.8. Autonomous System (AS) 11 > 5.8.1. Source AS IE 11 > 5.8.2. Destination AS IE 11 > 5.8.3. Next Hop AS IE 11 > 5.9. IfIndexes and Interfaces 11 > 5.9.1. Ingress Port IE 11 > 5.9.2. Egress Port IE 11 > 5.9.3. Egress ATM Subinterface 12 > 5.9.4. EGRESS_FRAME_RELAY_SUBINTERFACE IE 12 > 5.10. NetMasks 12 > 5.10.1. Source Address Netmask IE 12 > 5.10.2. Destination Address Netmask IE 12 > 5.11. BGP & Vlan IE's 12 > 5.11.1. Destination BGP Community IE 12 > 5.11.2. Source BGP Community IE 12 > 5.11.3. BGP_NEXT_HOP 12 > 5.11.4. Source VLAN ID IE 12 > 5.11.5. Destination VLAN ID IE 13 > 5.11.6. Source Virtual Address IE 13 > 5.11.7. Source Virtual Port IE 13 > 5.11.8. Destination Virtual Address IE 14 > 5.11.9. Destination Virtual Port IE 14 > 5.12. NAT 14 > 5.12.1. INSIDE_L4_SRC 14 > 5.12.2. INSIDE_IPV4_SRC_ADDR 14 > 5.12.3. INSIDE_L4_DST_PORT 14 > 5.12.4. INSIDE_IPV4_DST_ADDR 14 > 5.12.5. INSIDE_IPV6_SRC_ADDR 14 > 5.12.6. INSIDE_IPV6_DST_ADDR 14 > 5.12.7. OUTSIDE_L4_SRC_PORT 14 > 5.12.8. OUTSIDE_IPV4_SRC_ADDR 15 > 5.12.9. OUTSIDE_L4_DST_PORT 15 > 5.12.10. OUTSIDE_IPV4_DST_ADDR 15 > 5.12.11. OUTSIDE_IPV6_SRC_ADDR 15 > 5.12.12. OUTSIDE_IPV6_DST_ADDR 15 > 5.13. Vendor Specific IE 15 > 5.14. Misc. Information Elements 15 > 5.14.1. Flow Label IE 15 > 5.14.2. Flow Direction 15 > 5.14.3. Fragment ID IE 16 > 5.14.4. Internal queue priority 16 > 5.14.5. Global VPN Identifier IE 16 > 5.14.6. IPM_DPKTS 16 > 5.14.7. IPM_DOCTETS 16 > 5.14.8. LAST_SWITCHED 16 > 5.14.9. FIRST_SWITCHED 16 > 5.14.10. MAC_ADDR 16 > 5.14.11. VLAN_ID 16 > 5.14.12. ICMP_TYPE 16 > 5.14.13. IGMP_TYPE 16 > 5.15. Sampling 17 > 5.15.1. SAMPLING_INTERVAL 17 > 5.15.2. SAMPLING_ALGO 17 > 5.15.3. FLOW_ACTIVE_TIMEOUT 17 > 5.15.4. FLOW_INACTIVE_TIMEOUT 17 > 6. References 17 > 7. Acknowledgements 19 > 8. Author's Addresses 20 > 9. Full Copyright Statement 21 > 10. Stuff to Add 21 > 11. End of stuff to add 21 > > 1. Introduction > > Many applications e.g., Intrusion detection, traffic engineering, > require the monitoring, measuring of IP traffic flows. It is hence > important to have a standard way of exporting information related to IP > flows. This document defines architecture for IP traffic flow > monitoring, measuring and exporting. It provides a high-level > description of the key components and their functions. > > 2. Scope > > This document defines information data model for IPFIX[3]. Specifically, > this document > > 3. Terminology > MOVED to the Requirements draft > > 4. Information Model > Delete Start ============ > I think we need to begin with a couple of guidlines (which > we should augment as we go). They are just guidelines. > > 1. Data element values should be defined in terms of other > specifications. Since we are only reporting things in other protocols, > there should be little reason for us to define anything from scatch. > > 2. Each element should be able to be interpreted on it own. In other > words, don't make me look though the rest of the message to figure out > what this value means. The drawback is this can lead to data element > explosion. We'll have to balance the tradeoffs. > > 3. Others? Delete End =========== Those were just my comments. I don't think they belong in the document. > > The IPFIX information model is listed in the IPFIX requirement > document. The information model consists of the minimum set of > attributes that an IPFIX exporting device should be able to export. In > conjunction with IP flow definitions, they provide locally accurate > information about a flow. I do not think it is the minimum set. It is the full set to this point in time. We need to define the full set in order to get interoperabiltity. Vendors defining their own fields should be the exception rather than the rule. > > To meet application's requirement may require the collection device to > obtain additional information about the flow, e.g. address translation, > user identification, etc. Additional flow information may also be > required; in this case, equipment vendors may define extensions to the > IPFIX information model. Any extension to the IPFIX information model > should be conveyed between end points. > > This section presents a rigorous definition and sufficient statistics > for these attributes. > > 4.1. Attributes related to IP Packet Header > > The following attributes are obtained directly from IP packet header > belonging to a flow: > o IP Version Number > o Source Address > o Destination Address > o Protocol Type > o TOS (for version 4) > o Flow Label (for version 6) > o DSCP (if DiffServ is supported) > > 4.2. Attributes Related to Measurement > > The following attributes relates to measurements and measuring > methodology: > o Packet Counter > o Dropped Packet Counter > o Payload Byte Counter What is this?? > o Timestamp of the First Packet Observed > o Timestamp of the Last Packet Observed > o Timeout Indication > o Sampling Method > o Sampling Parameters > > 4.3. Attributes Related to Flow Definition > > The following attributes relates to IP flow definitions. > > o Incoming Interface > o Outgoing Interface > o Packet Treatment > o Unique ID of the Observation Point > o Unique ID of the Measuring Device > > 4.4. Attributes related to Upper Layers > > The following attributes provides information of upper layer protocols. > o Source Port Address > o MPLS Label (if MPLS is supported) Just a nit but MPLS is actaually a lower layer. Where are derived things like AS number? > > 4.5. IPFIX Template > > The IPFIX system MUST support efficient exporting of IP flow > information. This can be achieved by negotiating a set of IPFIX > Templates for an IPFIX session before actual IP flow information is > exported. A template defines the structure of an IPFIX user message > payload by describing the data type, meaning, and location of the fields > in the payload. By agreeing on IPFIX templates, IPFIX end-points > understand how to process IPFIX user messages. As a result, an exporting > device only needs to export actual flow information without attaching > any descriptors of the attributes; this reduces the amount of bytes sent > over communication links. > > A template is an ordered list of keys. A key specifies an attribute that > a meter entity MAY export. The specification MUST consist of the > description and the data type of the attribute. (e.g. 'Number of Sent > Bytes' can be a key that is an 32 bit unsigned integer) An exporting > device typically defines keys. Based on the IPFIX information model, a > set of IPFIX standard keys can be defined. > > 4.5.1. Template Negotiation > > During the initial setup of an IPFIX session, template negotiation > procedures should be carried out. It would allow all the IPFIX > end-points to synchronize on a set of templates that will be used during > IP flow information export. I assume a lot more discussion needs to happen here. > > 5. Information Elements > 5.1. Packet Management > > This information contains the fields needed to manage the data packets > transmitted > > 5.1.1. Version Number > > [Need to expand more] If this is IPFIX protocol version, it does not belong here. > > 5.1.2. FLOWS > V#3 S#4 > Number of main cache flows What is this??? > > 5.1.3. FLOW_LABEL > V#31 S#2 > IPV6 Flow Label > [Need to expand more] > Delete, already covered below in more detail. > 5.2. IP Address > > 5.2.1. Source Address IE > > Source address associated with a flow. Addresses can be of any type as > described in RFC 1700 [note - we need a new reference here, 1700 has > been obsoleted] > > 5.2.2. Destination Address IE > > Destination address associated with a flow. same as above. > > 5.2.3. NEXT_HOP_IP IE > > Address of the next hop. address is defined the same as for Source > Address IE. > > 5.3. Time Stamps > > 5.3.1. Time IE > > The time (as a SNMPv2 TimeStamp [1443]) associated with the > status/statistics observed or other events. > > 5.3.2. UTC Time IE > > The time in seconds since 00:00:00 UTC, January 1, 1970 associated with > the status/statistics observed or other events. If both Time and > UTC_TIME are present, UTC Time takes precedence. > > 5.3.3. Delta Time IE > > The number in 100ths of seconds over which the statistics were observed. > TYPE is 71 and format is: > > 5.4. Service Types > > 5.4.1. Class of Service IE > > The class of service associated with a flow. > > Class of Service Received > Class of Service Transmitted > > 1. IPv4, CoS value is defined by ToS in RFC 791 > 2. IPv6, CoS value is defined by Traffic Class in RFC 2460 > 3. MPLS, CoS value is defined by Exp in RFC 3032 > 4. VLAN, CoS value is defined by user_priority in IEEE802.1q[802.1q] and > IEEE 802.1p[802.1p] > > [Can more than one Class of Service can be present??? PAC] > > > 5.4.2. TCP Control Bits IE > > The TCP control bits seen for this flow. Note a 0 value for each bit > only indicates that the flag was not detected (i.e. it may have occurred > but was not detected by the reporting CCE). TCP Control Bits are defined > by RFC 793. > > 5.4.3. Protocol Identifier IE > > e.g. TCP/UDP [ need an RFC reference here. PAC] > > 5.4.4. Source Exporter [ is that the right term?? PAC] Address IE > > Source Exporter address is the address of the Exporter reporting the > flow, Address is same as is as shown for Source Address. This > information is used by applications to later correlate the > ingress/egress port with a specific Exporter. It is also used to > maintain the source Exporter information when there is an intermediate > proxy. For example, given the picture below: > > SW1 -------- P1 ------ FAS1 > ^ > | > SW2---------- | > > Flows coming from SW1 and SW2 through proxy P1 would look to the > Collector [ is this the rigth term??? PAC] like the same Exporter > connection. With the Source Exporter in the message the original > Exporter address is maintained. > > 5.5. Flow State IE > > Flow State is the intended End State for the Flow. > > Flow state has one of the following meanings: > > Flow is inactive > Flow is active > > 5.6. Statistical Elements > > To be added > > 5.6.1. Byte Count IE > > Contains the count of octets sent and received associated with the > identified flow. > > The byte count can be for bytes received (towards source) or bytes sent > (towards destination) or both (bi-directional flow). > > The byte count can be a running counter and is the count from the > beginning of the flow establishment. > > The byte count can be a delta counter and is the count since the last > report for this flow. > > 5.6.2. Packet Count IE > > Contains the count of packets sent and received associated with the > identified flow. > > The packet count can be for packets received (towards source) or packets > sent (towards destination) or both (bi-directional flow). > > The packet count can be a running counter and is the count from the > beginning of the flow establishment. > > The packet count can be a delta counter and is the count since the last > report for this flow. > > 5.6.3. Dropped Byte Count IE > > Contains the count of octets dropped at the observation point associated > with the identified flow. > > The dropped byte count can be a running counter and is the count from > the beginning of the flow establishment. > > The byte count can be a delta counter and is the count since the last > report for this flow. > > 5.6.4. Dropped Packet Count IE > > Contains the count of packets dropped at the observation point > associated with the identified flow. > > The dropped packet count can be a running counter and is the count from > the beginning of the flow establishment. > > The dropped packet count can be a delta counter and is the count since > the last report for this flow. > > 5.7. Port Information > > To be added > > 5.7.1. Source Port IE > > This IE is used to report UDP source port [see RFC 768] or TCP source > port [see RFC 793]. > > 5.7.2. Destination Port IE > > This IE is used to report UDP destination port [see RFC 768] or TCP > destination port [see RFC 793]. > > 5.8. Autonomous System (AS) > > To be added > > 5.8.1. Source AS IE > > The Autonomous System (AS) numbers for the source address associated > with a flow. Autonomous System (AS) number is defined by RFC 1930 and > RFC 1771 (BGP-4): > > 5.8.2. Destination AS IE > > The Autonomous System (AS) numbers for the destination address > associated wit a flow. Autonomous System (AS) number is defined by RFC > 1930 and RFC 1771 (BGP-4). > > 5.8.3. Next Hop AS IE > > The Autonomous System (AS) numbers for the next hop IP. Autonomous > System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). > > 5.9. IfIndexes and Interfaces > > To be added > > 5.9.1. Ingress Port IE > > The ingress ifIndex for the flow is provided in this IE. ifIndex is > defined by RFC 2233. > > 5.9.2. Egress Port IE > > The egress ifIndex for the flow is provided in this IE. ifIndex is > defined by RFC 2233. > > 5.9.3. Egress ATM Subinterface > > The egress vpi/vci for the flow is provided in this IE. vpi/vci id > defined by the ATM Forum UNI 3.1 specification: > > 5.9.4. EGRESS_FRAME_RELAY_SUBINTERFACE IE > > The egress DLCI for the flow is provided in this IE. ITU Q.922 defines > the DLCI range. The frDlcmiState is defined in RFC 2115 and defines the > specific values of the DLCI. > > 5.10. NetMasks > 5.10.1. Source Address Netmask IE > > The number of bits in the CIDR netmask, as defined in RFC 1519, for the > source address. > > 5.10.2. Destination Address Netmask IE > > The CIDR netmask, as defined in RFC 1519, for the destination address. > > 5.11. BGP & Vlan IE's > > 5.11.1. Destination BGP Community IE > > The BGP community number for the destination address. BGP community > number is defined by RFC 1997: > > 5.11.2. Source BGP Community IE > > The BGP community number for the source address. > > 5.11.3. BGP_NEXT_HOP > V#18 S#4 > Next-hop router in the BGP > domain > > 5.11.4. Source VLAN ID IE > > The Source VLAN ID associated with the flow. VLAN ID is defined by IEEE > standard 802.1q - 1998[802.1q]. > > [ Is this ultimate source VLAN or the source vlan of the port where the > packet came in? Or do we need a way to represent both? PAC] > > 5.11.5. Destination VLAN ID IE > > The destination VLAN ID associated with the flow. VLAN ID is defined by > IEEE standard 802.1q - 1998[802.1q]. > > [ Is this ultimate destination VLAN or the destination vlan of the port > where the packet went out? Or do we need a way to represent both? PAC] > > 1.1. Virtual Information > > 5.11.6. Source Virtual Address IE > > An Exporter may be involved in redirecting flows. This IE captures > information needed for proper accounting of redirected flows. The Source > Virtual IE contains the source address of the flow as transmitted by the > Exporter. It is generally different than the source address IE, which > contains the address of the actual source of the message. > > A type field would contain the type of translation performed on the > source address. The following types are currently available: > 1. - NAT > 2. - LSNAT > 3. - Web Cache > > The address is defined the same as for Source Address. > > 5.11.7. Source Virtual Port IE > > A CCE may be involved in redirecting flows. This IE captures information > needed for proper accounting of redirected flows. The Source Virtual > port IE contains the source port of the flow as transmitted by the CCE. > It may be different than the source port IE, which contains the port of > the actual source of the flow. An IP Protocol field is present and is > defined by the IP protocol spec [RFC 791] (e.g. TCP/UDP). The fields > indicates how to interpret the port value field. > > A type field contains the type of translation performed on the source > port. The following types are currently available: > > 1. - NAT > 2. - LSNAT > 3. - Web Cache > > 5.11.8. Destination Virtual Address IE > > The Destination Virtual IE contains the destination address of the flow > as received by the Exporter. It is generally different than the > destination port number, which contains the actual destination address > of the flow. > > 5.11.9. Destination Virtual Port IE > > The Destination Virtual port IE contains the destination port of the > flow as received by the Exporter. It may be different than the > destination port recorded in the destination port, which contains the > actual destination port of the flow. > Start delete ============ > 5.12. NAT > 5.12.1. INSIDE_L4_SRC > V#42 S#2 > > NAT port number (.e.g, FTP, Telnet, etc...) only applicable with NAT > > 5.12.2. INSIDE_IPV4_SRC_ADDR > V#43 S#4 > Source IPv4 Address only applicable with NAT TCP/UDP destination port > > 5.12.3. INSIDE_L4_DST_PORT > V#44 S#2 > The number (.e.g, FTP, telnet etc...) only applicable with NAT > > 5.12.4. INSIDE_IPV4_DST_ADDR > V#45 S#4 > Destination IPv4 Address only applicable with NAT > > 5.12.5. INSIDE_IPV6_SRC_ADDR > V#46 S#16 > IPv6 Source Address only applicable with NAT > > 5.12.6. INSIDE_IPV6_DST_ADDR > V#47 #16 > IPv6 Destination Address only applicable with NAT > > 5.12.7. OUTSIDE_L4_SRC_PORT > V#48 S#2 > TCP/UDP destination port number (.e.g, FTP, Telnet, etc...) only > applicable with NAT > > 5.12.8. OUTSIDE_IPV4_SRC_ADDR > V#49 S#4 > Source IPv4 Address only applicable with NAT TCP/UDP destination port > > 5.12.9. OUTSIDE_L4_DST_PORT > V#50 S#2 > number (.e.g, FTP, Telnet, etc...) only applicable with NAT > > 5.12.10. OUTSIDE_IPV4_DST_ADDR > V#51 S#4 > Destination IPv4 Address only applicable with NAT > > 5.12.11. OUTSIDE_IPV6_SRC_ADDR > V#52 S#16 > IPv6 Source Address only applicable with NAT > > 5.12.12. OUTSIDE_IPV6_DST_ADDR > V#53 S#16 > IPv6 Destination Address only applicable with NAT > Delete ENd ========== Already covered above in more detail above. Even if we disagree on the exact text, this stuyff is duplicate. > 5.13. Vendor Specific IE > > Vendors may add their own information to the protocol. Information > contained in this IE is vendor specific. OID and OID Value is defined by > ITU X.680.X683 (1997) and is encoded as defined by ITU X.690.691(1997). > This IE MUST not contain any information which cannot be safely ignored > by the Exporter or Collector. If multiple Vendor Specific IE's with the > same OID occur, then the vendor defines semantics of ordering. > > 5.14. Misc. Information Elements > > To be added > > 5.14.1. Flow Label IE > > The Flow Label IE contains the IPV6 Flow Label information as defined by > RFC 2460. > 5.14.2. Flow Direction > V#54 S#1 > The direction of the flow observed at the observation point. If the > observation point is a set of interface(s) the direction is w.r.t the > wire. > > 5.14.3. Fragment ID IE > > The fragment ID associated with the flow. RFC 791 and RFC 2460 define > fragment ID. > > 5.14.4. Internal queue priority > > A switch may map several of its internal priority queues into a Premium, > High, Medium or Low category. > > [ this sections needs more work] > > 5.14.5. Global VPN Identifier IE > > The VPN identifier associated with the flow as defined in RFC 2685. > > 5.14.6. IPM_DPKTS > V#19 S#4 > Packet count for IP Multicast > > 5.14.7. IPM_DOCTETS > V#20 S#4 > Octet (byte) count for IP Multicast IPM_DPKTS and IPM_DOCTETS should be moved to where the other counts are. > > 5.14.8. LAST_SWITCHED > V#21 S#4 > SysUptime at which the last packet of this flow was switched > > 5.14.9. FIRST_SWITCHED > V#22 S#4 > SysUptime at which the first packet of this flow was switched > [Need to expand more] > Move these with the other timestamp info, I'll work on combining. > 5.14.10. MAC_ADDR > V#25 S#6 > Layer 2 Media Access Control address associated with a flow > Delete. Already covered under the address stuff. > 5.14.11. VLAN_ID > V#26 S#2 > Virtual LAN identifier associated with a flow Delete. already covered in more detail. > > 5.14.12. ICMP_TYPE > V#32 S#1 > ICMP Packet Type. This is reported as (ICMP Type * 256) + ICMP code We need a spec reference. > > 5.14.13. IGMP_TYPE > V#33 S#1 > IGMP Packet Type we need a spec reference. > > 5.15. Sampling > > 5.15.1. SAMPLING_INTERVAL > V#34 S#1 > When using Sampling, the rate at which packets are sampled. For > example, a value of 100 indicates that one of every hundred packets is > sampled. > > 5.15.2. SAMPLING_ALGO > V#35 S#1 > The type of algorithm used for sampling > data. Currently, the only > sampling algorithm defined is: > 0x02 packet-sampling > > 5.15.3. FLOW_ACTIVE_TIMEOUT > V#36 S#2 > Timeout value for active flow entries in the cache. > > 5.15.4. FLOW_INACTIVE_TIMEOUT > V#37 S#2 > Timeout value for inactive flow entries in the cache. > > 6. References > > 3. J. Quittek ,et al.," Requirements for IP Flow Information Export ", > (work in progress) ,Internet Draft, Internet Engineering Task Force, > , November 2001 > > 4. M. Wood ,et al.," Intrusion Detection Message Exchange > Requirements",(work in progress), Internet Draft, Internet Engineering > Task Force, draft-ietf-idwg-requirements-06,February 2002. > > 5. Daniel O. Awduche, et. al.," Overview and Principles of Internet > Traffic Engineering", (work in progress), Internet Draft, Internet > Engineering Task Force, draft-ietf-tewg-principles-02.txt, May 2002 > > [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions, > http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-adelaide/pp-dist/ > > [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric for > IPPM, > , November 2001 > > [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss > Metric for > IPPM, September 1999 > > [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application > of Sampling > Methodologies to Network Traffic Characterization, Proceedings of ACM > SIGCOMM'93, > San Francisco, CA, USA, September 13 - 17, 1993 > > [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, > John G. CLEARY: > Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay > Variation on > the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 > > [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for > Direct Traffic > Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August > 28 - > September 1, 2000. > > [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric > for IPPM, > Request for Comments: 2679, September 1999 > > [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation > of Building Blocks > for Passive One-way-delay Measurements, Proceedings of Passive and > Active Measurement > Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 (PAM > 2001) > > [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture and > framework," work in progress. October 2001. > > [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator > (NAT) Terminology and Considerations", RFC 2663, August 1999. > > [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network > Address Translator (Traditional NAT)", RFC 3022, January 2001. > > [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider > Provisioned Virtual Private Networks ", work in progress, > , January 2002. > > [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft > , July 2001. > > [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. > Weiss, "An Architecture for Differentiated Services", RFC 2475, December > 1998. > > [1] Requirements for IP Flow Export, > > > [2] K.Zhang, et al., "Common Reliable Accounting for Network Element > (CRANE)", , February 2002 > > [3] G. Sadasivan, et al., "Flow Export Architecture", > , January 2002 > > [4] Carlson, James, "PPP Design, Implementation and Debugging", Second > Edition . > > 7. Acknowledgements > We like to thank all the people contributing to the requirements > discussion on the mailing list, and the design teams for a lot of > valuable comments. > > George Carle > Tanja Zseby > Paul Calato > Dave Plonka > Kevin Zhang > KC Norseth > Phill Richards > Will Eatherton > Benoit Claise > Ganesh Sadasivan > Vamsi Valluri > Ram Gopal > Jc Martin > Carter Bullard > Juergen Quittek > Reinaldo Penno > Nevil Brownlee > Simon Leinen > > 8. Author's Addresses > > Benoit Claise > Cisco Systems > De Kleetlaan 6a b1 > 1831 Diegem > Belgium > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > Paul Calato > Riverstone Networks, Inc. > 5200 Great America Parkway > Santa Clara, CA 95054 USA > Phone: +1 (603) 557-6913 > Email: calato@riverstonenet.com > > Ganesh Sadasivan > Cisco Systems, Inc. > 170 W. Tasman Dr. > San Jose, CA 95134 > USA > Phone: +1 (408) 527-0251 > Email: gsadasiv@cisco.com > > Ram Gopal > Nokia > 5 Wayside Road, > Burlington, MA 01803 > Phone:+1 781 993 3685 > Email: ram.gopal@nokia.com > > Man Li > Nokia > 5 Wayside Road, > Burlington, MA 01803 > Phone: +1 781 993 3923 > Email: man.m.li@nokia.com > > K.C. Norseth > Enterasys Networks > 2691 S. Decker Lake Lane > Salt Lake City, Utah 84119 > Phone: +1 801 887 9823 > Email: knorseth@enterasys.com > > Reinaldo Penno > Nortel Networks, Inc. > 2305 Mission College Boulevard > Building SC9-B1240 > Santa Clara, CA 95134 > Email: rpenno@nortelnetworks.com > > Juergen Quittek > NEC Europe Ltd. > Adenauerplatz 6 > 69115 Heidelberg > Germany > Phone: +49 6221 90511-15 > EMail: quittek@ccrle.nec.de > > Kevin Zhang > XACCT Technologies, Inc. > 2900 Lakeside Drive > Santa Clara, CA 95054 > Phone +1 301 992 4697 > Email: kevin.zhang@xacct.com > > Tanja Zseby > GMD FOKUS > Kaiserin-Augusta-Allee 31 > 10589 Berlin, Germany > Phone: +49 30 3463 7153 > Email: zseby@fokus.gmd.de > > 9. Full Copyright Statement > > "Copyright (C) The Internet Society (date). All Rights Reserved. This > document and translations of it may be copied and furnished to others, > and derivative works that comment on or otherwise explain it or assist > in its implementation may be prepared, copied, published and > distributed, in whole or in part, without restriction of any kind, > provided that the above copyright notice and this paragraph are included > on all such copies and derivative works. However, this document itself > may not be modified in any way, such as by removing the copyright notice > or references to the Internet Society or other Internet organizations, > except as needed for the purpose of developing Internet standards in > which case the procedures for copyrights defined in the Internet > Standards process must be followed, or as required to translate it into. > > 10. Stuff to Add > 11. End of stuff to add > > > IPFIX Information Data Model February, 2002 > > > IPFIX WG Expires August, 2002 [Page 4] > > Gopal, Li,Zhang,Tanja Expires July 2002 [Page 1] -- 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 Tue Feb 12 13:53:10 2002 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 NAA21901 for ; Tue, 12 Feb 2002 13:53:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ahh6-0006u9-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 12:30:20 -0600 Received: from [216.167.117.195] (helo=www.inmon.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ahh3-0006u0-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 12:30:17 -0600 Received: from phaalpc (w086.z065104045.sjc-ca.dsl.cnc.net [65.104.45.86]) by www.inmon.com (8.9.3/(dn/norelay)) with SMTP id NAA05517; Tue, 12 Feb 2002 13:30:05 -0500 Reply-To: From: "Peter Phaal" To: "'Benoit Claise'" , Cc: Subject: [ipfix-req] Remote sampling and middle boxes Date: Tue, 12 Feb 2002 10:29:37 -0800 Message-ID: <003a01c1b3f3$3ab2b660$3200000a@xo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C690A62.94C9B0EF@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > > I think the last sentence is too restrictive. Why excluding packet > > samplers sending samples from a remote observation point to a meter? > > 1. If you have in mind a port copy, then you copy the packets from one > port to another port. So the observation point is an > interface the packets are > copied to. > > 2. If you have in mind (what we call on Cisco devices) the > remote span, i.e. one > device > doing a port copy from own of its own port to a port to a > remote device, then > the observation point is an interface the packets are copied to. > > So what's in comon between 1. and 2., the interface. > > 3. Now, if you mean that you do packet sampling in one > interface and send > the results to another device (or observation domain), this > is something which for > me is not feasable, > at least in my mind. Because the sampling function is part of > metering process. > So observation point is actually where you sample. > Note: the sample mechanism part (or not) of the metering > process is a principle we > should agree before > going much further. This concept must be part of the > requirement document. > Now, I'm trying to imagine one application where your > scenario would be > usefull.... > A router composed of linecard 1 and linecard 2. We have 2 > observation domains, 2 > metering processes (one per line card). > The packets observed on an interface of linecard1 would be > sampled, but not > exported to the collector. Instead they would be sent to the > linecard 2 for latter > processing with the flow locally seen. That's right that you > could possibly do > some more aggregations on line card 2... but do you have > something specific in > mind? Because I see one drawback here: the IPFIX flow records > have to be processed > twice within the router: once a "local export" to another > observation domain, then > the "real" export. And as you know, this costs in terms of CPU. There are a number of situations in which it would be nice to use IPFIX to aggregate and export flow records based on remote sampling. 1. sFlow sends packet samples to a remote collector for aggregation. IPFIX would be a good way of exporting data from the aggregator. sFlow is supported across the Foundry Networks product line. 2. The PSAMP http://www.research.att.com/~duffield/psamp/ group are proposing to remotely export packet sampling. Again a remote aggregator of PSAMP data might want to export aggregates using IPFIX. 3. Juniper sampled mirroring can remotely forward samples. I assume that in each of these cases the IPFIX exporter is acting as a "middle box." Another situation would be a middle box that bridges netflow, LFAP or any other existing flow record into IPFIX flow records. Finally, a middle box aggregating IPFIX data from multiple IPFIX sources may want to re-export aggregates (possibly removing duplicate flows). I was looking through the drafts and it wasn't apparent to me how a middle box would export flows on behalf of other devices (indicating the true source of the data, and the scope of aggregation). Presumably one would need to add an entry in 5.1 in the Data Model: 5.1.x MEASUREMENT ORIGIN The IP address associated with the original measurement point. This may be the same address as the exporter, or it may refer to a remote device that provided the data. If flows are aggregated across multiple sources this could be a list of origins. (FLOWS and FLOW_LABEL are scoped to each MEASUREMENT ORIGIN. A corresponding adjustement to the Architecture document would also be required, perhaps showing that collectors can also export IPFIX. Peter ---------------------- Peter Phaal InMon Corp. Peter_Phaal@inmon.com -- 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 Tue Feb 12 14:06:24 2002 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 OAA22248 for ; Tue, 12 Feb 2002 14:06:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ahwf-0007GE-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 12:46:25 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ahwc-0007G8-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 12:46:23 -0600 Received: from fokus.fhg.de (dhcp187 [195.37.78.187]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1CIk9p00777; Tue, 12 Feb 2002 19:46:09 +0100 (MET) Message-ID: <3C6961EE.8A7BED8@fokus.fhg.de> Date: Tue, 12 Feb 2002 19:41:50 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <4108689799.1013426004@[192.168.102.164]> <3C694086.5D0B0891@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, I have some comments on your proposal. Benoit Claise schrieb: > > Juergen, > > Juergen Quittek wrote: > > > Hi all, > > > > Here is my list of proposed changes to draft-ietf-ipfix-reqs-00.txt. > > > > I know that Benoit also is going to send some suggestions. > > And of course anyone else should feel free to do so. > > 1. I have one question whose answer should in the requirement draft. > What do we do with ICMP, IGMP? others? > Do we report this traffic with IPFIX. If yes, this must be described. I think IPFIX should report them and you are right that we have to add something in the draft. > 2. I think we should have statements in the requirement document about: > - configuration will be done out-bound > Note: this is at least the direction I see in the working group on that one: > Will, KC, Juergen, Mike, Ganesh and I versus Reinaldo, Kevin > a version 2 of the IPFIX protocol could investigate the needs of in-band > configuration > - no transport negotiation (which transport) > - no capability negotiation > > But the decisions about the last 2 bullets are still under discussion. These are > the 2 next big points the group has to agree on. I agree to your points. However I don't think that these are requirements for IP flow information export and thus they don't belong into the draft. > 3. We also want to stress that we are trying to standardize the direction > exporter -> collector and not necessarely the direction collector -> exporter. > Maybe in the chapter about "push and pull mode reporting" 5.4, next to "The > measuring device MUST support push mode reporting, it MAY support pull mode > reporting." We could add a statement in 6. > 4. all occurences of measuring device should be replaced by exporter > > 5. Let's not forget the comment from Nevil > Section 4.5 Timeouts. More detail needed here. > At least we need to say "user must be able to specify timeout interval > for fixed timeout intervals." And maybe we should allow for some > kinds of dynamic timeouts too, e.g. "timeout after specified minimum > time, when no packets have been seen for twice the average inter-packet > time while the flow was active." ??? We could add in 4.5: Flow timeouts MAY be fixed timeout intervals or dynamic timeouts e.g. " Nevils text". In section 6 we have already specified that the configuration of the timeout is a MAY. So far there are no specific MUST requirements. At least we should make it a SHOULD. > 6. I would remove the remotely from sectiont 6., this could be confusing. > The measuring device MUST provide a way of configuring the traffic > measurement and the traffic data export remotely. Why is that confusing? Cheers, Sebastian > > > > > > Cheers, > > > > Juergen > > -- > > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > 1. insert new section "2. Terminology" > > > > 2. Make section "1.1 IP Flows" new section "2.1. IP Traffic > > Flows or Flows" > > - Maybe the flow definition will have to be adapted. > See our terminology thread. > - The observation point definition should be removed from there. > > > > > > > 3. Add sections 2.2 to 2.8: > > Sure we will have to insert the definitions but there are still under discussion. > > > > > 2.2. Observation Point > > The observation point is a location in the network > > where IP packets can be observed. Examples are a line > > to which a probe is attached, a shared medium, such as > > an Ethernet-based LAN, a port of a router, or an > > entire router with several ports. > > > > 2.3. Trafic Flow Meter or Meter > > A meter observes packets at one or more obsrvation > > points. It analyzes the content of the packets and maps > > them to flows. For each observed flow the meter computes > > statistics and maintains a flow record where it stores > > relevant flow infromation. > > > > 2.4. Metering Process > > The metering process includes all actions performed by a > > meter with respect to observing packets, timestamping > > them, analyzing them, mapping them to flows, computing > > flow statistics, detecting flow expiration, and > > maintaining flow records. > > > > 2.5. Flow Record > > A flow record keeps information a flow including > > characteristic properties of the flow, for example the > > source IP address, and measured properties of the flow, > > for example the total number of bytes of all packets of > > the flow. > > > > 2.6. Flow Information Exporter or Exporter > > The exporter sends flow records created and maintained > > by one or more meters to one or more data collectors. > > > > 2.7. Flow Information Data Collector or Data Colletor > > The data collector receives flow records from one or > > more exporters. The data collector might process or > > store received flow record, but these actions are out > > of the scope of this document. > > > > 2.8. Flow Information Exort > > Flow information export denotes the process of > > transferring flow records from an exporter to a data > > collector. > > > > 4. Remove section 2.5 Network Surveillance > > > > 5. In section 2.6, 3rd paragraph: > > remove "'Heisenberg' effects," > > > > 6. In section 4.1, last sentence: > > replace "then it SHOULD be stored ... inaccurately." > > by "then the measuring device MUST be able to detect > > this failure and to report about it." > > > > 7. Replace section "4.2 Sampling" by section "4.2 Overload > > Behavior": > > I tend to disagree. > The metering can do sampling versus full > And in case of overload, the metering process might switch to sampling. > These are 2 different topics. > If you want to keep overload behavior, here is what I can propose: > > 4.2. Sampling > > The measuring device MAY support measuring traffic by packet > sampling. If sampling is supported the sampling method and its > parameters MUST be well defined. > > 4.2.1 Overload Behavior > > In case of an overload, e. g. lack of memory or > processing power, the measuring device MAY change the > metering process in order to cope with the lack of > resources. Possible reactions include: > > - Reduce the number of flow accounts. This can be > achieved by more coarse grained flow measurement or > by a restriction of the flow accounts to a subset of > the set of original ones. > - Sample packets before they are processed by the meter. > - Stop metering. > > Overload behavior is not restricted to the three options > listed above. But in any case, the overload behavior > MUST be clearly defined. For example in case of sampling, > the sampling method and all its parameters MUST be known > or indicated. > > > > > > > 8. Append to section "4.3 Timestamps" > > Also in case of a switch to overload behavior, a > > timestap MUST be generated for this event as well as for > > a switch back to regular behavior. > > I'm not too sure what you mean. > > That's it for now. > > Regards, Benoit > > > > > > > > > > 9. Change section 5.3.1. "Congestion Awareness" to > > "Congestion-Friendlyness" > > Replace text of subsection by "For the flow information > > export a congestion-friendly protocol MUST be supported." > > > > 10. Insert new section 5.3.3 Robustness > > Data transfer SHOULD be robust against network and > > system fault conditions. Robustness may be supported for > > example by > > - flow control > > - by deploying redundant data receiving systems > > - fail-over/fail-back procedures. > > However, robustness should not be traded with > > congestion-friendlyness which has higher priority. > > > > 11. Update reference [MIDBOXTAX] which is now updated to > > version -03. > > > > 12. Remove all entries for network surveillance from table > > in Appendix > > > > 13. Update Table in appendix according to changes in text. > > > > -- > > 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/ > > -- > 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/ -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Tue Feb 12 14:08:43 2002 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 OAA22384 for ; Tue, 12 Feb 2002 14:08:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ai2w-0007P9-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 12:52:54 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ai2u-0007P2-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 12:52:52 -0600 Received: from fokus.fhg.de (dhcp187 [195.37.78.187]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1CIqep01401; Tue, 12 Feb 2002 19:52:40 +0100 (MET) Message-ID: <3C696375.BAE38BD7@fokus.fhg.de> Date: Tue, 12 Feb 2002 19:48:21 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: Peter_Phaal@inmon.com CC: "'Benoit Claise'" , quittek@ccrle.nec.de, ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Remote sampling and middle boxes References: <003a01c1b3f3$3ab2b660$3200000a@xo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Peter, Peter Phaal schrieb: [...] > > Presumably one would need to add an entry in 5.1 in the Data Model: > > 5.1.x MEASUREMENT ORIGIN > The IP address associated with the original measurement point. This may be > the same address as the exporter, or it may refer to a remote device that > provided the data. If flows are aggregated across multiple sources this > could be a list of origins. (FLOWS and FLOW_LABEL are scoped to each > MEASUREMENT ORIGIN. Quoting from the draft section 5.1: "The measuring device MUST be able to report the following attributes for each measured flow: [...] 18. unique identifier of the observation point 19. unique identifier of the measuring device " Is that not what you want? > A corresponding adjustement to the Architecture document would also be > required, perhaps showing that collectors can also export IPFIX. > > Peter > ---------------------- > Peter Phaal > InMon Corp. > > Peter_Phaal@inmon.com > Cheers, Sebastian -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Tue Feb 12 14:38:04 2002 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 OAA23326 for ; Tue, 12 Feb 2002 14:38:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aiVv-0000Hf-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 13:22:51 -0600 Received: from mailhub.lawrence.edu ([143.44.65.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aiVt-0000HZ-00 for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 13:22:49 -0600 Received: from lawrence.edu ([143.44.97.41]) by lawrence.edu (PMDF V6.0-025 #44893) with ESMTP id <0GRF00N4OQEHXU@lawrence.edu> for ipfix@net.doit.wisc.edu; Tue, 12 Feb 2002 13:35:05 -0600 (CST) Date: Tue, 12 Feb 2002 13:22:48 -0600 From: Robert Lowe Subject: Re: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 To: "Norseth, KC" Cc: ipfix@net.doit.wisc.edu Message-id: <3C696B88.4C1458B5@lawrence.edu> Organization: Lawrence University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <59358A738F45D51186A30008C74CE250DA06B3@slc-exc1.ctron.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > "Norseth, KC" wrote: Hi KC! > |A few more comments regarding templates, although ones which > |probably fall within the realm of operational vs. protocol issues... > | > |Early on there was some discussion regarding the impact of > |IPFIX on the network itself, and if/how the exporter or > |collector should react to overload conditions. As I recall, > |Peter Phaal indicated that from an analysis point of view, it > |would not be good to change the sample rate. However, when > |faced with an overload condition: > | > |1) On the exporter, should it: > | a. continue as is, and drop packets when it has to, or > | b. fall-back to a user pre-defined sampling rate, compromising > | IPFIX data to avoid dropping packets ?? > | > |2) On the collector, should it: > | a. continue, and lose flow data because it cannot > |process it all, or > | b. signal a fall-back to a different sampling rate via > |a new template? > | > |If the solution uses the verb "buy", don't mention it! ;-) I > |can accept a good argument that these are operational issues. > > This is very dangerous to have the exporter switch to sampling automatically. This > could really confuse the information being gathered. You could get the message from the > reports that volume has dropped down during a period of time, but in reality, it is > dnagerously high. No, I was assuming that the new template would somehow be recorded, or available during analysis, so that it would be recognized that the sampling rate changed and could be properly reflected in a report. I agree that not having this change record available during analysis makes the analysis pretty useless. But this is a kind of in-band config that would add more complexity than would seem to outweigh its benefit. I think I need to re-read a few things to better understand the use of templates in general too. Thanks! -Robert -- 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 Tue Feb 12 15:32:52 2002 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 PAA25499 for ; Tue, 12 Feb 2002 15:32:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ajLj-0001GY-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 14:16:23 -0600 Received: from [216.167.117.195] (helo=www.inmon.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ajLf-0001GQ-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 14:16:19 -0600 Received: from phaalpc (w086.z065104045.sjc-ca.dsl.cnc.net [65.104.45.86]) by www.inmon.com (8.9.3/(dn/norelay)) with SMTP id PAA09789; Tue, 12 Feb 2002 15:16:09 -0500 Reply-To: From: "Peter Phaal" To: "'Sebastian Zander'" Cc: "'Benoit Claise'" , , Subject: RE: [ipfix-req] Remote sampling and middle boxes Date: Tue, 12 Feb 2002 12:15:42 -0800 Message-ID: <004901c1b402$0c6d2ba0$3200000a@xo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C696375.BAE38BD7@fokus.fhg.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Sebastian Zander wrote: > Quoting from the draft section 5.1: > > "The measuring device MUST be able to report the following attributes > for each measured flow: > [...] > 18. unique identifier of the observation point > 19. unique identifier of the measuring device > " > > Is that not what you want? > I didn't see this language in the posted drafts . This might be sufficient if the design document supports multiple definitions of an observation point: 1. ifIndex|vlan ... (implies an observation point on measuring device). 2. Agent. (implies remote observation point on Agent) 3. Agent (all interfaces an remote Agent). 4. list of observation points (data aggregated from multiple observation points). An intermediate device collecting netflow, IPFIX, samples from multiple sources requires a degree of flexibility in describing the source of the data for each "virtual" or "proxy" observation point it re-exports using IPFIX. Is this type of measurement device within the scope IPFIX? Supporting multi-tiered IPFIX architectures would make for much greater scalability. My reading of the current architecture is that it limits itself to two or three tiers (depending on how one counts). It's not clear that an observation point could be an IPFIX collector, or that a collector could export IPFIX data. Peter ---------------------- Peter Phaal InMon Corp. Peter_Phaal@inmon.com -- 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 Tue Feb 12 18:07:43 2002 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 SAA00348 for ; Tue, 12 Feb 2002 18:07:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16allV-0004QI-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 16:51:09 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16allU-0004Q1-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 16:51:08 -0600 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA25283; Tue, 12 Feb 2002 23:50:23 +0100 (MET) Message-ID: <3C699C3A.9203D67D@cisco.com> Date: Tue, 12 Feb 2002 23:50:34 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sebastian Zander CC: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <4108689799.1013426004@[192.168.102.164]> <3C694086.5D0B0891@cisco.com> <3C6961EE.8A7BED8@fokus.fhg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Sebastian, [I skip the points on which we agree] > > > > 2. I think we should have statements in the requirement document about: > > - configuration will be done out-bound > > Note: this is at least the direction I see in the working group on that one: > > Will, KC, Juergen, Mike, Ganesh and I versus Reinaldo, Kevin > > a version 2 of the IPFIX protocol could investigate the needs of in-band > > configuration > > - no transport negotiation (which transport) > > - no capability negotiation > > > > But the decisions about the last 2 bullets are still under discussion. These are > > the 2 next big points the group has to agree on. > > I agree to your points. However I don't think that these are requirements for > IP flow information export and thus they don't belong into the draft. Someone please correct me if I'm wrong but the requirement draft is, not only what is required in the IPFIX protocol but also the scope of IPFIX protocol proposal. This is the reason why I wanted to add the IPFIX the big principles, to limit the scope of what will propose in IPFIX. Any other thought? > > > > 6. I would remove the remotely from sectiont 6., this could be confusing. > > The measuring device MUST provide a way of configuring the traffic > > measurement and the traffic data export remotely. > > Why is that confusing? What does the remotely refer to? - The way of configuring traffic measurement. Then I disagree because the exporter configuration should be out of the scope of IPFIX - The traffic data export. Then remotely is implicit Regards, Benoit > > > Cheers, > > Sebastian > > > > > > > > > > Cheers, > > > > > > Juergen > > > -- > > > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > > > 1. insert new section "2. Terminology" > > > > > > 2. Make section "1.1 IP Flows" new section "2.1. IP Traffic > > > Flows or Flows" > > > > - Maybe the flow definition will have to be adapted. > > See our terminology thread. > > - The observation point definition should be removed from there. > > > > > > > > > > > 3. Add sections 2.2 to 2.8: > > > > Sure we will have to insert the definitions but there are still under discussion. > > > > > > > > 2.2. Observation Point > > > The observation point is a location in the network > > > where IP packets can be observed. Examples are a line > > > to which a probe is attached, a shared medium, such as > > > an Ethernet-based LAN, a port of a router, or an > > > entire router with several ports. > > > > > > 2.3. Trafic Flow Meter or Meter > > > A meter observes packets at one or more obsrvation > > > points. It analyzes the content of the packets and maps > > > them to flows. For each observed flow the meter computes > > > statistics and maintains a flow record where it stores > > > relevant flow infromation. > > > > > > 2.4. Metering Process > > > The metering process includes all actions performed by a > > > meter with respect to observing packets, timestamping > > > them, analyzing them, mapping them to flows, computing > > > flow statistics, detecting flow expiration, and > > > maintaining flow records. > > > > > > 2.5. Flow Record > > > A flow record keeps information a flow including > > > characteristic properties of the flow, for example the > > > source IP address, and measured properties of the flow, > > > for example the total number of bytes of all packets of > > > the flow. > > > > > > 2.6. Flow Information Exporter or Exporter > > > The exporter sends flow records created and maintained > > > by one or more meters to one or more data collectors. > > > > > > 2.7. Flow Information Data Collector or Data Colletor > > > The data collector receives flow records from one or > > > more exporters. The data collector might process or > > > store received flow record, but these actions are out > > > of the scope of this document. > > > > > > 2.8. Flow Information Exort > > > Flow information export denotes the process of > > > transferring flow records from an exporter to a data > > > collector. > > > > > > 4. Remove section 2.5 Network Surveillance > > > > > > 5. In section 2.6, 3rd paragraph: > > > remove "'Heisenberg' effects," > > > > > > 6. In section 4.1, last sentence: > > > replace "then it SHOULD be stored ... inaccurately." > > > by "then the measuring device MUST be able to detect > > > this failure and to report about it." > > > > > > 7. Replace section "4.2 Sampling" by section "4.2 Overload > > > Behavior": > > > > I tend to disagree. > > The metering can do sampling versus full > > And in case of overload, the metering process might switch to sampling. > > These are 2 different topics. > > If you want to keep overload behavior, here is what I can propose: > > > > 4.2. Sampling > > > > The measuring device MAY support measuring traffic by packet > > sampling. If sampling is supported the sampling method and its > > parameters MUST be well defined. > > > > 4.2.1 Overload Behavior > > > > In case of an overload, e. g. lack of memory or > > processing power, the measuring device MAY change the > > metering process in order to cope with the lack of > > resources. Possible reactions include: > > > > - Reduce the number of flow accounts. This can be > > achieved by more coarse grained flow measurement or > > by a restriction of the flow accounts to a subset of > > the set of original ones. > > - Sample packets before they are processed by the meter. > > - Stop metering. > > > > Overload behavior is not restricted to the three options > > listed above. But in any case, the overload behavior > > MUST be clearly defined. For example in case of sampling, > > the sampling method and all its parameters MUST be known > > or indicated. > > > > > > > > > > > 8. Append to section "4.3 Timestamps" > > > Also in case of a switch to overload behavior, a > > > timestap MUST be generated for this event as well as for > > > a switch back to regular behavior. > > > > I'm not too sure what you mean. > > > > That's it for now. > > > > Regards, Benoit > > > > > > > > > > > > > > > > 9. Change section 5.3.1. "Congestion Awareness" to > > > "Congestion-Friendlyness" > > > Replace text of subsection by "For the flow information > > > export a congestion-friendly protocol MUST be supported." > > > > > > 10. Insert new section 5.3.3 Robustness > > > Data transfer SHOULD be robust against network and > > > system fault conditions. Robustness may be supported for > > > example by > > > - flow control > > > - by deploying redundant data receiving systems > > > - fail-over/fail-back procedures. > > > However, robustness should not be traded with > > > congestion-friendlyness which has higher priority. > > > > > > 11. Update reference [MIDBOXTAX] which is now updated to > > > version -03. > > > > > > 12. Remove all entries for network surveillance from table > > > in Appendix > > > > > > 13. Update Table in appendix according to changes in text. > > > > > > -- > > > 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/ > > > > -- > > 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/ > > -- > Sebastian Zander E-mail: zander@fokus.fhg.de > FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Tue Feb 12 18:26:42 2002 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 SAA00648 for ; Tue, 12 Feb 2002 18:26:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16am3H-0004rK-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 17:09:31 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16am3F-0004qq-00 for ipfix-arch@net.doit.wisc.edu; Tue, 12 Feb 2002 17:09:29 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1CN8wE02087 for ; Tue, 12 Feb 2002 15:08:58 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE22353; Tue, 12 Feb 2002 15:09:21 -0800 (PST) Message-ID: <3C69A2A0.9E76F024@cisco.com> Date: Tue, 12 Feb 2002 15:17:52 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] [Fwd: [ipfix] Re: Information Model] Content-Type: multipart/mixed; boundary="------------29784030D0973E02374C2594" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------29784030D0973E02374C2594 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit --------------29784030D0973E02374C2594 Content-Type: message/rfc822 Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <3C69A1C2.8B3C9DF6@cisco.com> Date: Tue, 12 Feb 2002 15:14:11 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Fullmer CC: Benoit Claise , ipifx-arch@net.doit.wisc.edu Subject: Re: [ipfix] Re: Information Model References: <200202061031.g16AVCg21451@bru-cse-222.cisco.com> <20020211202838.A96470@net.ohio-state.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Mark, Thanks for the comments. See inline. Ganesh Mark Fullmer wrote: > Comments start with ### > > > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > * Metering Process: Measurement process that is carried out at the > observation domain. > > * Flow Header: Every flow export packet includes a flow header > which carries some general information about the exporter, packet > identification etc. > > ### > Using the export "packet" term too soon, ie if this is a TCP control > connection the packet may be partial. I do not understand. This packet is generated at the level of exporter > > > 2. Flow Type and Flow Definition > > As defined in the requirement draft [1], > "A flow is a set of packets passing an observation point in the > network during a certain time interval. All packets belonging to a > particular flow have a set of common properties derived from the > data contained in the packet and from the packet treatment at the > observation point." > > In this draft we define the flow more specifically. A flow is > defined as a set of packets passing an observation point in the > network during a certain time interval. All packets belonging to a > particular flow have a set of common properties. Each property is > defined as the result of applying a function to the values of: > > a. one or more of packet header fields (eg. destination IP address) > b. one or more properties of the packet itself (eg. packet length) > c. one or more of fields derived from packet treatment (eg. AS > number) > > ### > This implies that if an IP address:AS mapping changes then there > would be a new flow if additional packets are are received from the > original IP. This needs clarification. Yes, if flow is AS based. > An implementation may choose to > do the AS and potentially other accounting fields lookup during the export > phase. > There is the problem you mentioned above in such a case. > > A packet is defined to belong to a flow if it matches all the defined > properties of the flow. Flows can be defined in multiple ways. Some > examples are: > Example 1: > To create flows, we define the different fields to distinguish flows. > The different combination of the field values creates unique flows. > If the keys are defined as {source IP address, destination IP > address, TOS}, then all of > > ### > This is misleading, flow state is created by traffic, not by defining them. The "create" should probably be changed to something else. Yes flows are created when a set of fields are designated the unique combination of which identifies the flow. > > It would be interesting to see multicast flow state created by the > multicast routing protocols instead of traffic, I'll get to this in a > different message. ?? > > > Example 3: > To create flows, we can filter some field values on all packets that > pass the observation point, in order to select only certain flows. > The filter is defined by choosing fixed values for specific fields > from the packet. > > All the packets that go from a customer network 192.1.40.0/24 to > another customer network 171.6.23.0/24 with TOS value of 4 define a > flow. All other combinations don't define a flow and are not taken > into account. The 3 flows from example 2 would now be reduced to 1 > flow, by filtering away the second and the third flow. > {192.1.40.0/24, 171.6.23.0/24, 4}. > > ### > I think we need some crude ascii art here. > > packets from observation point > || > || > \/ > sampling > || > || > \/ > filtering > || > || > \/ > translations > || > || > \/ > flow-engine > || > || > \/ > filtering of potential exports > || > || > \/ > export-queue > || > IPFX > || > \/ > collector > > Above the flow-engine can be considered the metering process and below > it the IPFX protocol. > > flow-engine could be expanded to include bidirectional and aggregation > explanations. There is the concept of observation domain to do the same. I drew up a figure as response to Jurgene's mail on the thread "Terminology. sggestion". > > > 2.2. Unidirectional and Bidirectional Flows > > A flow defined by the above terms is unidirectional. In case the > exporter has got the knowledge of the bi-directional flows and in > case the bi-directional information make sense, the exporter MAY > choose to export in the same Template/Flow Record, along with > bidirectional accounting information. This would save some bandwidth > as the exporter won't have to send two unidirectional flow records. > > ### > You're referencing Template and Flow Record before defining them. Flow Record is defined in the Terminology section. "Template" is not necessary here I guess. > > > 3. Metering Process Functions > > 3.1. Flow Classification > > The collector MUST be able to map the flow to the corresponding > property types defined by the flow type. This can be done only if the > collector has a mapping from flow type identifier (carried in each > flow record) to its actual structure. More details of how this can be > acheived is decribed in section 5. > > In addition the collecter, when it receives the flow records, MAY > need the following interpreting the flow records furthur: > > a. Observation Point. > b. Selection Criteria of Packets > > As mentioned in section 2.1, a flow record can be better analyzed if > the Observation Point from which it is measured is known. As such it > > Sadasivan & Claise [Page 7] > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > is recomended that the flow record carry the Observation Point > information along with the flow records when exported. In cases where > there is a single observation point or where the observation point > information is not relevant, the exporter MAY choose not to add this > to the flow records. > > ### > Record or Header. This may be too detailed verbage here since the export > process is not detailed until later. > > > > > 3.2.2. Sampling packets on a flow type (Si) > > Packets that satisfy the sampling criteria for this flow type. > Example: > Sample every 100th packet that was received at an observation point > and collect the flow information for a particular flow type. Choosing > all the packets is a special case where sampling rate is 1:1. > > ### > Need to use consistent wording when describing the maintenance of flow > state. 'collect' is used here. Ok. > > > 3.3. Selection Criteria of flows for export > > The measurement device MAY define additional rules so that only > certain flows records are picked up for export. This MAY be done by > either one of the two types of methods defined in 2.3.1 and 2.3.2 or > a combination of them. > > Example: > The flow records which meets the following selection criteria are > > ### > You're talking about exporting before defining what the export is. Need > to establish relationship between flow state expiration and export first. Does export need a more explicit definition than IPFIX? > > > 4. Flow Export Protocol > > The information that needs to be exported from the exporter can be > classified into the following categories: > * Control Information - This includes the flow type definition, > selection criteria for packets within the flow. This is also > called as control stream. > > ### > This is implying you're sending things like ACL's that define the > filters? Good luck getting the group to agree on a standard format > for ACL's :) Hoping to put in some basic elements (like sampling information etc) and rest of it I guess would be propritery. > > 4.1.2. Collector Redundancy > > In case there are multiple collectors, the exporter MAY multicast the > flow records to the set of collectors that joined the export > multicast group, instead of sending several unicast streams towards > the different collectors. Multicast would lower the bandwidth > requirements on the export link in case that the collectors are on > the same media, and could lower the internal bus utilization on the > exporter. Using multicast session with more than one collector > joining the flow export multicast group, redundancy of collectors can > be easily achieved. > > ### > Add some verbage about Multicast and security issues. Anyone can > join group, etc. Ok. > > > 4.2.3. Collector Failover > > This is an extension to section 4.2 to take care of collector crash. > The exporter opens control connections to multiple collectors. But > data gets sent only to one of the collectors which is chosen as the > primary. There could be one or more collectors configured as > secondary and a priority assigned to them. The primary collector > crash is detected at the exporter by the break in control connection > (depending on the transport protocol the connection timeout > mechanisms differ). On detecting loss of connectivity, the exporter > opens data stream with the secondary collector of the next highest > priority. This collector now becomes the primary. The maximum export > data loss would be the amount of data exported in the time between > when the loss of connectivity to the collector happened, and the time > at which this was detected by the exporter. > > ### > Why is the separate control channel optional. Why not just define it > and make it TCP? It simplifies a bunch of other things later on. I agree with you that it simplifies. These are 2 models we are suggesting which can be used for 2 different situations. > > > When using TCP a procedure must be defined if the collector can not > decode the packet (ie garbled TCP stream). For example reset the > connection. Ok. > > > The control connection should include a simple authenticator like a shared > secret so the collector can have some confidence it's a valid exporter. You mean to say something like MD5? > > > > > Sequence Number: > Exporter generated number which uniquely identifies a packet. The > sequence number increments for subsequent export packets. A separate > sequence number is manintained for control and export data packets if > control and data are send in separate packets. > > ### > In the current NetFlow export implementation the sequence number is > per flow so the collector can calculate lost flows. I thought it was per packet. Am I wrong? If so it is additional 4 byte info per record? I thought there was a # of flow records in the header which along with the sequence number in the header would give the count. > With per packet > sequence number this functionality is lost. Mixing in control information > complicates it even more (did you lose a control packet or flow packet). > > > Sadasivan & Claise [Page 13] > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > Source ID: > Unique identifier per observation domain. > > ### > There needs to be an exporter ID (IP address) so that replicated IPFX > packets retain the exporter. I'd like to see the Source ID restricted > to 16 bits so the collector doesn't need to maintain a hash table to > track the sequence numbers per exporter. What do you mean by "replicated IPFX packets"? > > > 5.2. Template and Template Flowsets > > Templates are used to completely identify the structure and semantics > of a particular information that needs to be communicated from the > exporter to the collector. Each template is uniquely identified by a > Template ID. The Template ID is a 16 bit identifier. A block of > templates from <0-255> are reserved for sending some of the control > information. The rest of the template IDs can be used by the > exporter to define the templates for the various flow types defined > within the exporter. A Template within an export packet is called as > a template record. A Template Flowset is a collection of one or more > template records which have been grouped together in an export > packet. The Flowset ID of a template flowset maps to a particular > template format. > > ### > Your template explanation took a while to digest. How about including > some common terminology like Type Length Value, ie the Template > is the Type and Length, the flow records are the Values. Ok. > > > 5.3. Categories of Template Flowset > > As explained in the terminology section, a flowset is a collection of > records with a similar template format in an export packet. Flowset > ID shares the same number space as a template ID. Template ID <0-255> > are reserved as mentioned above and these are used by Flowset IDs to > send Template Flowsets of different formats. All of the Templates are > sent over the control stream. The different template formats being > used are: > > 5.3.1. Case A, Template for Flow Record Definition > > The common examples of this case are templates for exported flow > records, and templates for flow related statistics or errors in the > exporter. Example of statistics information: total numbers of flows. > The format of the Template Flowset for this case is described below: > > ### > Need common terminology again. Statistics or Accounting? Statistics. > 5.6. Exporting Flow Records > > As mentioned above flow records can go through the same stream as a > control information or through a different stream as per the > description in section 4.1 and 4.2. If data stream is different, it > would be identified by a different sequence number. In anycase the > flags field of the flow export header MUST indicate that the packet > has only data flowsets (flag in the flow export header is set to > "data") or if it carries control and data flowsets (flag is set to > "both"). Data packets contain flow records corresponding to one or > more template IDs. Flow records that belong to the same template ID > can be grouped together to utilize the bandwidth better. A > collection of one or more flow records that have have the same > template ID is termed as a Data Flowset. The Flowset ID of a data > flowset is assigned the Template ID to which all the records in this > data flowset belong to. The collector uses this Flowset ID to > interpret the data contained within the flow records. A data flowset > cannot be split across multiple flow record packets. > > ### > When exporting the data via UDP there exporter MUST have a configuration > option to limit the maximum packet size so that tunneled exports do > not end up being fragmented. agreed. > > > The format of the Data Flowset is described below: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | FlowSet ID = Template ID | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 1 - Field Value 1 | Record 1 - Field Value 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 1 - Field Value 3 | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 2 - Field Value 1 | Record 2 - Field Value 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 2 - Field Value 3 | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Record 3 - Field Value 1 | ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ### > Verbage needs to be added about alignment. u_int32's on 32 bit > boundries, u_in16's on on 16 bit boundries, etc. This also implies > needing a 'NULL' field type for padding. Need to define byte order > of fields. > > Also the exporter SHOULD provide optimal encoding, ie > u_int32 > u_int16 > u_int16 > u_int8 > u_int8 > u_int8 > u_int8 > > not > u_int8 > pad > pad > pad > u_int32 > u_int8 > pad > pad > pad > u_int16 > u_int8 > pad > u_int16 > u_int8 > pad I guess over netwrok we have to send it as packed without any padding. The exporter and collector may be running different processors. > > > 5.6.1. Field Descriptions > > FlowSet ID = Template ID > Template ID corresponding to the flow records in the flowset. > > Length: > The length of the Data FlowSet including FlowSet ID and the Length . > > Record N - Field N > The remainder of the Data FlowSet is a collection of field values. > > Sadasivan & Claise [Page 22] > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > The Type and Length of the fields have been previously defined in the > Template Record referenced by the FlowSet ID/Template ID. > > The flow records contains the values for the fields defined by flow > type. > > 6. Specific Technology Considerations > > 6.1. Network Address and Port Translation > > In case the exporter is doing NAT [3] and in case the observation > domain has got the knowledge of both inside and outside parameters, > the exporter MAY choose to export both inside and outside parameters > in the same Template/Flow Record (The NAT parameters being the IP > address and/or the UDP/TCP ports). If not the exporter will only > export the parameters observed at the observation point. > > ### > s/got// Just one place - right? > > > This just implies that the information model MUST have inside and > outside parameters defined. > > A NAT device can be installed between the exporter and the collector. > This means that the flow records IP address could be meaningless for > the data analyzis without a NAT translator on the collector's side. > This case is out of the scope of this document as it concerns the > analysis of the data and not the export. > > 7. Information Model > > The information model for a flow measurement report is the list of > possible attributes of a flow, selection criteria (like parameters > for sampling) and observation point. The table below described all > the field type definition that an IPFIX compliant exporter will > support: > > Field Type Value Length Description > > IN_BYTES_32 1 4 32-bit counter for bytes > associated with an IP Flow > > IN_PKTS_32 2 4 32-bit counter for packets > associated with an IP Flow > > FLOWS 3 4 Number of main cache flows > that were aggregated > > PROT 4 1 IP protocol byte. > > Sadasivan & Claise [Page 23] > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > TOS 5 1 Type of service byte > > TCP_FLAGS 6 1 TCP Flags (cumulative OR > of TCP flags) > > TCP/UDP source port > L4_SRC_PORT 7 2 number (.e.g, FTP, Telnet, > etc...) > > IPV4_SRC_ADDR 8 4 Source IPv4 Address > > SRC_MASK 9 1 source route's mask bits > > ### > IPV4_SRC_MASK, be consistent > > INPUT_SNMP 10 2 Input interface index > > ### > just call it ifIndex > > TCP/UDP destination port > L4_DST_PORT 11 2 number (.e.g, FTP, Telnet, > etc...) > > IPV4_DST_ADDR 12 4 Destination IPv4 Address > > DST_MASK 13 1 destination route's mask > ### > ditto > Bits > > OUTPUT_SNMP 14 2 Output interface index > ### > ditto > > IPV4_NEXT_HOP 15 4 Next hop router's IPv4 > Address > > SRC_AS 16 4 Source BGP Autonomous > ### > Unicast source AS. Remember we have a multicast RIB too. Maybe for > multicast it's the multicast source AS (they should be the same) > > DST_AS 17 4 Destination BGP Autonomous > System Number > > BGP_NEXT_HOP 18 4 Next-hop router in the BGP > domain > > IPM_DPKTS 19 4 Packet count for IP > Multicast > > IPM_DOCTETS 20 4 Octet (byte) count for IP > Multicast > > SysUptime at which the > LAST_SWITCHED 21 4 last packet of this flow > was switched > > Sadasivan & Claise [Page 24] > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > SysUptime at which the > FIRST_SWITCHED 22 4 first packet of this flow > was switched > > IN_BYTES_64 23 8 64-bit counter for bytes > associated with an IP Flow > > IN_PKTS_64 24 8 64-bit counter for packets > associated with an IP Flow > > ### > what about IN_*_32? > > MAC_ADDR 25 6 Layer 2 Media Access > Control address associated > with a flow > > VLAN_ID 26 2 Virtual LAN identifier > associated with a flow > > IPV6_SRC_ADDR 27 16 IPv6 Source Address > > IPV6_DST_ADDR 28 16 IPv6 Destination Address > > IPV6_SRC_MASK 29 1 IPv6 Source Mask > > IPV6_DST_MASK 30 1 IPv6 Destination Mask > > FLOW_LABEL 31 2 IPV6 Flow Label > ### > IPV6_ > > ICMP Packet Type. This is > ICMP_TYPE 32 1 reported as (ICMP Type * > 256) + ICMP code > > IGMP_TYPE 33 1 IGMP Packet Type > > When using Sampling, > the rate at which > packets are sampled. For > SAMPLING_INTERVAL 34 1 example, a value of 100 > indicates that one of > every hundred packets is > sampled. > > ### > This looks too restrictive, need at least 2 bytes, ie what about 1/1000 Guess it should be 2 or 4 bytes > > > ### > Juniper also has a run length > > The type of algorithm used > for sampling data. > Currently, the only > sampling algorithm defined > SAMPLING_ALGO 35 1 is: > 0x02 packet-sampling > > Sadasivan & Claise [Page 25] > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > Timeout value for active > FLOW_ACTIVE_TIMEOUT 36 2 flow entries in the > cache. > > Timeout value for inactive > FLOW_INACTIVE_TIMEOUT 37 2 flow entries in the > cache. > ### > This looks like control channel information. Should indicate this. > > OUT_BYTES_32 38 4 32-bit counter for bytes > associated with an IP Flow > > OUT_PKTS_32 39 4 32-bit counter for packets > associated with an IP Flow > > OUT_BYTES_64 40 8 64-bit counter for bytes > associated with an IP Flow > > OUT_PKTS_64 41 8 64-bit counter for packets > associated with an IP Flow > inside TCP/UDP destination > > INSIDE_L4_SRC 42 2 port number (.e.g, FTP, > Telnet, etc...) > only applicable with NAT > > INSIDE_IPV4_SRC_ADDR 43 4 Source IPv4 Address > only applicable with NAT > > TCP/UDP destination port > INSIDE_L4_DST_PORT 44 2 number (.e.g, FTP, telnet > etc...) > only applicable with NAT > > INSIDE_IPV4_DST_ADDR 45 4 Destination IPv4 Address > only applicable with NAT > > INSIDE_IPV6_SRC_ADDR 46 16 IPv6 Source Address > only applicable with NAT > > INSIDE_IPV6_DST_ADDR 47 16 IPv6 Destination Address > only applicable with NAT > > TCP/UDP destination port > OUTSIDE_L4_SRC_PORT 48 2 number (.e.g, FTP, Telnet, > etc...) > only applicable with NAT > > OUTSIDE_IPV4_SRC_ADDR 49 4 Source IPv4 Address > > Sadasivan & Claise [Page 26] > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > only applicable with NAT > TCP/UDP destination port > OUTSIDE_L4_DST_PORT 50 2 number (.e.g, FTP, Telnet, > etc...) > only applicable with NAT > > OUTSIDE_IPV4_DST_ADDR 51 4 Destination IPv4 Address > only applicable with NAT > > OUTSIDE_IPV6_SRC_ADDR 52 16 IPv6 Source Address > only applicable with NAT > > OUTSIDE_IPV6_DST_ADDR 53 16 IPv6 Destination Address > only applicable with NAT > > Flow Direction 54 1 The direction of the flow > observed at the > observation point. If the > observation point is a set > of interface(s) the > direction is w.r.t the > wire. > > The "Value" column in the above table is a numeric identifier for the > field type. > > When extensibility is needed (when new technologies are defined or > when some new field types are needed), the newly added field types > MUST be added to the list. They MUST be defined by the exporter and > understood by the collector. > > 8. The Collector Side > > The collector SHOULD receive template definitions from the exporter, > before receiving flow records. The flow records can then be decoded > and stored locally on the collector. In case the template definitions > have not been received at the time a Flow Record is received, the > collector SHOULD keep the Flow Record for later decoding when the > template definitions will be received. The collector MUST decode and > store the entire flow records, even if the semantics of one or more > of the field types in the template associated with the flow record is > not understood. > > ### > The "MUST decode and store" the entire flow record should be dropped. The > collector may decide to only store some of the fields. It may also > decide to add fields of its own, for example exporter source. agreed. > > > The collector SHOULD maintain a table of active templates. The > template information SHOULD be kept for templates of flow records, > non-flow records, and dependency template. The table format is as > defined below. > > Sadasivan & Claise [Page 27] > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > +-----------+--------------+--------------+-----------------+ > | Exporter | Template ID | Template Def |Time Since Last | > | | | |Refresh (Tr) | > +-----------+--------------+--------------+-----------------+ > > Note that the Template IDs are unique per exporter. A template can > exist without being refreshed by an update for Tm period of time. Tr > gets incremented periodically. Each time an update is received for a > template, Tr is reset to 0. When Tr >= Tm, the entry is removed from > the table. > > Collector devices SHOULD use the combination of the source IP address > and the Source ID field to distinguish different export streams > originating from the same exporting device. For example: different > linecards on a router MAY generate different export streams to a > single collector. > > Acknowledgements > > We like to thank Will Eatherton, Michelle Ma, Peram Marimuthu, Martin > Djernaes and Vamsi Valluri for reviewing this document and providing > valuable comments. > > References > > [1] Requirements for IP Flow Export, > > > [2] B. Carpenter, "Middleboxes: taxonomy and issues", draft- > carpenter-midtax-01.txt, work in progress. > > [3] RFC 3022, Traditional IP Network Address Translator (Traditional > NAT) > > Authors' Addresses > > Ganesh Sadasivan > Cisco Systems, Inc. > 170 W. Tasman Dr. > San Jose, CA 95134 > USA > Phone: +1 (408) 527-0251 > Email: gsadasiv@cisco.com > > Sadasivan & Claise [Page 28] > > Internet Draft draft-gsadasiv-ipfix-proposal-00.txt February 2002 > > Benoit Claise > Cisco Systems > De Kleetlaan 6a b1 > 1831 Diegem > Belgium > Phone: +32 2 704 5622 > Email: bclaise@cisco.com > > Sadasivan & Claise [Page 29] --------------29784030D0973E02374C2594-- -- 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 Tue Feb 12 19:17:18 2002 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 TAA01343 for ; Tue, 12 Feb 2002 19:17:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ams4-0005qd-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 18:02:00 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ams2-0005q6-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 18:01:58 -0600 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA24555; Wed, 13 Feb 2002 01:01:14 +0100 (MET) Message-ID: <3C69ACD5.23049A18@cisco.com> Date: Wed, 13 Feb 2002 01:01:26 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter_Phaal@inmon.com CC: "'Sebastian Zander'" , quittek@ccrle.nec.de, ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Remote sampling and middle boxes References: <004901c1b402$0c6d2ba0$3200000a@xo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Peter > Sebastian Zander wrote: > > Quoting from the draft section 5.1: > > > > "The measuring device MUST be able to report the following attributes > > for each measured flow: > > [...] > > 18. unique identifier of the observation point > > 19. unique identifier of the measuring device > > " > > > > Is that not what you want? > > > > I didn't see this language in the posted drafts > . > > This might be sufficient if the design document supports multiple > definitions of an observation point: > 1. ifIndex|vlan ... (implies an observation point on measuring device). > 2. Agent. (implies remote observation point on Agent) > 3. Agent (all interfaces an remote Agent). > 4. list of observation points (data aggregated from multiple observation > points). I would like to encourage you to review http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt It might solve your problem because we export: 5.3.2 Case B, Template for Method Description This case describes the format for exported configuration information. Each of the configuration templates within this flowset describes : * List of methods that define the Selection Criteria and the parameters for each method. * Observation Point and its description ... Note that we assume in the draft that one observation point is interface or a set of interface. Now, the only thing which is missing in our draft is the unique identifier of the measuring device (i.e. the exporter IP address) in the information model. Because I was thinking that this unique ID would have been the source IP address of the export packet (OK, it could be a loopback to be independent of the router outgoing interface). But I understand your point, and it's not a problem to add the unique identifier of the measuring device (i.e. the exporter IP address) in the information model > > > An intermediate device collecting netflow, IPFIX, samples from multiple > sources requires a degree of flexibility in describing the source of the > data for each "virtual" or "proxy" observation point it re-exports using > IPFIX. > > Is this type of measurement device within the scope IPFIX? Supporting > multi-tiered IPFIX architectures would make for much greater scalability. My > reading of the current architecture is that it limits itself to two or three > tiers (depending on how one counts). It's not clear that an observation > point could be an IPFIX collector, or that a collector could export IPFIX > data. I don't see why we should limit the IPFIX effort, as long as this is a MAY feature. This is a good point to clarify. Regards, Benoit -- 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 Tue Feb 12 19:18:14 2002 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 TAA01369 for ; Tue, 12 Feb 2002 19:18:14 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16amta-0005t1-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 18:03:34 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16amtY-0005sF-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 18:03:32 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1D02gv26060; Tue, 12 Feb 2002 18:02:42 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXQ4J>; Tue, 12 Feb 2002 16:02:39 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A1421C@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Benoit Claise , Juergen Quittek Cc: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Tue, 12 Feb 2002 16:02:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B421.BE90B6C0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B421.BE90B6C0 Content-Type: text/plain; charset="iso-8859-1" Bernoit, >-----Original Message----- >From: Benoit Claise [mailto:bclaise@cisco.com] >Sent: Tuesday, February 12, 2002 8:19 AM >To: Juergen Quittek >Cc: ipfix-req@net.doit.wisc.edu >Subject: Re: [ipfix-req] Proposed changes to >draft-ietf-ipfix-reqs-00.txt > > >Will, KC, Juergen, Mike, Ganesh and I versus Reinaldo, Kevin > a version 2 of the IPFIX protocol could investigate the >needs of in-band >configuration >- no transport negotiation (which transport) >- no capability negotiation > These two phrases are not reflecting what people said. With two phrases you are taking out this possiblity altogether, which reading the answers was not what I understood. What would the right thing is to say that these things what out-of-the-scope. regards, Reinaldo ------_=_NextPart_001_01C1B421.BE90B6C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-req] Proposed changes to = draft-ietf-ipfix-reqs-00.txt

Bernoit,

>-----Original Message-----
>From: Benoit Claise [mailto:bclaise@cisco.com]
>Sent: Tuesday, February 12, 2002 8:19 AM
>To: Juergen Quittek
>Cc: ipfix-req@net.doit.wisc.edu
>Subject: Re: [ipfix-req] Proposed changes = to
>draft-ietf-ipfix-reqs-00.txt
>
>
>Will, KC, Juergen, Mike, Ganesh and I versus = Reinaldo, Kevin
>  a version 2 of the IPFIX protocol could = investigate the
>needs of in-band
>configuration
>- no transport negotiation (which = transport)
>- no capability negotiation
>

These two phrases are not reflecting what people = said. With two phrases you are taking out this possiblity altogether, = which reading the answers was not what I understood. What would the = right thing is to say that these things what = out-of-the-scope.

regards,

Reinaldo

------_=_NextPart_001_01C1B421.BE90B6C0-- -- 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 Tue Feb 12 19:29:13 2002 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 TAA01531 for ; Tue, 12 Feb 2002 19:29:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16an4V-00069Z-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 18:14:51 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16an4S-00068y-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 18:14:49 -0600 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA28775; Wed, 13 Feb 2002 01:14:10 +0100 (MET) Message-ID: <3C69AFDE.6848DBC5@cisco.com> Date: Wed, 13 Feb 2002 01:14:22 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter_Phaal@inmon.com CC: quittek@ccrle.nec.de, ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] Re: Remote sampling and middle boxes References: <003a01c1b3f3$3ab2b660$3200000a@xo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Peter, Peter Phaal wrote: > > > I think the last sentence is too restrictive. Why excluding packet > > > samplers sending samples from a remote observation point to a meter? > > > > 1. If you have in mind a port copy, then you copy the packets from one > > port to another port. So the observation point is an > > interface the packets are > > copied to. > > > > 2. If you have in mind (what we call on Cisco devices) the > > remote span, i.e. one > > device > > doing a port copy from own of its own port to a port to a > > remote device, then > > the observation point is an interface the packets are copied to. > > > > So what's in comon between 1. and 2., the interface. > > > > 3. Now, if you mean that you do packet sampling in one > > interface and send > > the results to another device (or observation domain), this > > is something which for > > me is not feasable, > > at least in my mind. Because the sampling function is part of > > metering process. > > So observation point is actually where you sample. > > Note: the sample mechanism part (or not) of the metering > > process is a principle we > > should agree before > > going much further. This concept must be part of the > > requirement document. > > Now, I'm trying to imagine one application where your > > scenario would be > > usefull.... > > A router composed of linecard 1 and linecard 2. We have 2 > > observation domains, 2 > > metering processes (one per line card). > > The packets observed on an interface of linecard1 would be > > sampled, but not > > exported to the collector. Instead they would be sent to the > > linecard 2 for latter > > processing with the flow locally seen. That's right that you > > could possibly do > > some more aggregations on line card 2... but do you have > > something specific in > > mind? Because I see one drawback here: the IPFIX flow records > > have to be processed > > twice within the router: once a "local export" to another > > observation domain, then > > the "real" export. And as you know, this costs in terms of CPU. > > There are a number of situations in which it would be nice to use IPFIX to > aggregate and export flow records based on remote sampling. Agreed with the 3 examples below. But In these 3 examples, you export to a remote collector. I thought that Juergen wanted to export to another meter of the same exporter. Hence my example with the export from line card 1 to line card 2, which doesn't make sense to me. More in the next email. Regards, Benoit > > 1. sFlow sends packet samples to a remote collector > for aggregation. IPFIX would be a good way of exporting data from the > aggregator. sFlow is supported across the Foundry Networks product line. > 2. The PSAMP http://www.research.att.com/~duffield/psamp/ group are > proposing to remotely export packet sampling. Again a remote aggregator of > PSAMP data might want to export aggregates using IPFIX. > 3. Juniper sampled mirroring can remotely forward samples. > > I assume that in each of these cases the IPFIX exporter is acting as a > "middle box." > > Another situation would be a middle box that bridges netflow, LFAP or any > other existing flow record into IPFIX flow records. > > Finally, a middle box aggregating IPFIX data from multiple IPFIX sources may > want to re-export aggregates (possibly removing duplicate flows). > > I was looking through the drafts and it wasn't apparent to me how a middle > box would export flows on behalf of other devices (indicating the true > source of the data, and the scope of aggregation). > > Presumably one would need to add an entry in 5.1 in the Data Model: > > 5.1.x MEASUREMENT ORIGIN > The IP address associated with the original measurement point. This may be > the same address as the exporter, or it may refer to a remote device that > provided the data. If flows are aggregated across multiple sources this > could be a list of origins. (FLOWS and FLOW_LABEL are scoped to each > MEASUREMENT ORIGIN. > > A corresponding adjustement to the Architecture document would also be > required, perhaps showing that collectors can also export IPFIX. > > Peter > ---------------------- > Peter Phaal > InMon Corp. > > Peter_Phaal@inmon.com -- 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 Tue Feb 12 19:36:34 2002 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 TAA01620 for ; Tue, 12 Feb 2002 19:36:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16anBF-0006JT-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 18:21:49 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16anBD-0006Id-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 18:21:47 -0600 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA00676; Wed, 13 Feb 2002 01:21:06 +0100 (MET) Message-ID: <3C69B17D.A66D549@cisco.com> Date: Wed, 13 Feb 2002 01:21:18 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <4F973E944951D311B6660008C7917CF008A1421C@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > > Bernoit, > > >-----Original Message----- > >From: Benoit Claise [mailto:bclaise@cisco.com] > >Sent: Tuesday, February 12, 2002 8:19 AM > >To: Juergen Quittek > >Cc: ipfix-req@net.doit.wisc.edu > >Subject: Re: [ipfix-req] Proposed changes to > >draft-ietf-ipfix-reqs-00.txt > > > > > >Will, KC, Juergen, Mike, Ganesh and I versus Reinaldo, Kevin > > a version 2 of the IPFIX protocol could investigate the > >needs of in-band > >configuration > >- no transport negotiation (which transport) > >- no capability negotiation > > > > These two phrases are not reflecting what people said. With two > phrases you are taking out this possiblity altogether, which reading > the answers was not what I understood. What would the right thing is > to say that these things what out-of-the-scope. I fully agree. "Out of the scope" is a better wording. My mistake. Regards, Benoit -- 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 Tue Feb 12 19:46:35 2002 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 TAA01803 for ; Tue, 12 Feb 2002 19:46:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16anLN-0006UW-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 18:32:17 -0600 Received: from [216.167.117.195] (helo=www.inmon.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16anLK-0006UQ-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 18:32:14 -0600 Received: from phaalpc (w086.z065104045.sjc-ca.dsl.cnc.net [65.104.45.86]) by www.inmon.com (8.9.3/(dn/norelay)) with SMTP id TAA19749; Tue, 12 Feb 2002 19:32:07 -0500 Reply-To: From: "Peter Phaal" To: "'Benoit Claise'" Cc: "'Sebastian Zander'" , , Subject: RE: [ipfix-req] Remote sampling and middle boxes Date: Tue, 12 Feb 2002 16:31:38 -0800 Message-ID: <005301c1b425$cd8ddaa0$3200000a@xo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C69ACD5.23049A18@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > I would like to encourage you to review > http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-propo > sal-00.txt > It might solve your problem because we export: > 5.3.2 Case B, Template for Method Description > This case describes the format for exported configuration > information. Each of the configuration templates within > this flowset > describes : > * List of methods that define the Selection Criteria and the > parameters for each method. > * Observation Point and its description > ... > > Note that we assume in the draft that one observation point > is interface or a > set of interface. > > Now, the only thing which is missing in our draft is the > unique identifier of > the measuring device (i.e. the exporter IP address) in the > information model. > Because I was thinking that this unique ID would have been > the source IP address > of the export packet (OK, it could be a loopback to be > independent of the router > outgoing interface). > But I understand your point, and it's not a problem to add > the unique identifier > of the measuring device (i.e. the exporter IP address) in the > information model Adding the unique identifier of the measuring device to the data model would be a good idea. NetFlow doesn't include the agent address as part of the NetFlow header, forcing intermediate services (such as NetFlow replication) to spoof IP source addresses to match that of the router. It's much cleaner if the flow records are self contained and don't depend on lower protocol layers for context. You might consider the SMON MIB (RFC 2613) SmonDataSource when defining the types of sources allowed. In addition to ifIndex, it identifies VLANs and objects from the entity MIB as possible observation points. Peter ---------------------- Peter Phaal InMon Corp. Peter_Phaal@inmon.com -- 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 Tue Feb 12 20:27:59 2002 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 UAA02642 for ; Tue, 12 Feb 2002 20:27:59 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16anye-0007LM-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 19:12:52 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16anyc-0007Kp-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 19:12:50 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1D1CJE16360; Tue, 12 Feb 2002 17:12:19 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE26926; Tue, 12 Feb 2002 17:12:42 -0800 (PST) Message-ID: <3C69BF89.CF1602B5@cisco.com> Date: Tue, 12 Feb 2002 17:21:14 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter_Phaal@inmon.com CC: ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] Remote sampling and middle boxes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Peter, See inline. > 1. sFlow sends packet samples to a remote collector > for aggregation. IPFIX would be a good way of exporting data from the > aggregator. sFlow is supported across the Foundry Networks product line. Agreed. But the current discussions focuses only on the export between primary exporter (which is tightly coupled with observation domain and its associated observation points) and the collector (or in your case the aggregator). From aggregator one may adopt same IPFIX protocol to send the records to secondary aggregator. But this is not currently in scope. The actions to get the packet samples also comes under metering. Another point is that packet samples are out-of-scope for this WG. I had raised this same issue a while ago and this is the reply I got. Don't know if this plan has changed. > 2. The PSAMP http://www.research.att.com/~duffield/psamp/ group are > proposing to remotely export packet sampling. Again a remote aggregator of > PSAMP data might want to export aggregates using IPFIX. > 3. Juniper sampled mirroring can remotely forward samples. > > I assume that in each of these cases the IPFIX exporter is acting as a > "middle box." I am not sure I agree with this. > > Another situation would be a middle box that bridges netflow, LFAP or any > other existing flow record into IPFIX flow records. I thought the plan was to come with a single export protocol that everyone conforms to. Thanks Ganesh > > Finally, a middle box aggregating IPFIX data from multiple IPFIX sources may > want to re-export aggregates (possibly removing duplicate flows). > > I was looking through the drafts and it wasn't apparent to me how a middle > box would export flows on behalf of other devices (indicating the true > source of the data, and the scope of aggregation). > > Presumably one would need to add an entry in 5.1 in the Data Model: > > 5.1.x MEASUREMENT ORIGIN > The IP address associated with the original measurement point. This may be > the same address as the exporter, or it may refer to a remote device that > provided the data. If flows are aggregated across multiple sources this > could be a list of origins. (FLOWS and FLOW_LABEL are scoped to each > MEASUREMENT ORIGIN. > > A corresponding adjustement to the Architecture document would also be > required, perhaps showing that collectors can also export IPFIX. > > Peter > ---------------------- > Peter Phaal > InMon Corp. -- 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 Tue Feb 12 20:32:21 2002 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 UAA02886 for ; Tue, 12 Feb 2002 20:32:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ao1O-0007PU-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 19:15:42 -0600 Received: from eng4.oar.net ([192.148.244.24]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16ao1M-0007PL-00 for ipfix-arch@net.doit.wisc.edu; Tue, 12 Feb 2002 19:15:40 -0600 Received: (qmail 4974 invoked by uid 4454); 13 Feb 2002 01:15:24 -0000 Date: Tue, 12 Feb 2002 20:15:24 -0500 From: Mark Fullmer To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Re: [ipfix] Re: Information Model] Message-ID: <20020212201524.A4966@net.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Precedence: bulk Sender: majordomo listserver On Tue, Feb 12, 2002 at 03:14:11PM -0800, Ganesh Sadasivan wrote: > > * Flow Header: Every flow export packet includes a flow header > > which carries some general information about the exporter, packet > > identification etc. > > > > ### > > Using the export "packet" term too soon, ie if this is a TCP control > > connection the packet may be partial. > > I do not understand. This packet is generated at the level of exporter I'm probably being picky, but the "packet" sent from the exporter may only have a partial IPFIX header if it's a stream protocol like TCP, ie the the "export" may be in two packets, or three...PDU is an option. > > Example: > > The flow records which meets the following selection criteria are > > > > ### > > You're talking about exporting before defining what the export is. Need > > to establish relationship between flow state expiration and export first. > > Does export need a more explicit definition than IPFIX? When the flow is ready for export needs definition, ie with NetFlow this is when it's expired from the cache. There may be an implementation that can be configured to periodically export active flows, or generate an export at flow state creation. > > ### > > Why is the separate control channel optional. Why not just define it > > and make it TCP? It simplifies a bunch of other things later on. > > I agree with you that it simplifies. These are 2 models we are suggesting > which can be used for 2 different situations. It would be nice if IPFIX required that the exporter shut down the data channel upon detection of the collector going away, ie when the control connection is broken. With the single control/data channel and no feedback from the collector this is not possible. > > The control connection should include a simple authenticator like a shared > > secret so the collector can have some confidence it's a valid exporter. > > You mean to say something like MD5? Or just a password type/value passed along when the templates are uploaded. I'm guessing the control connection here will also inform the collector where/how to listen for the data channel? > > Sequence Number: > > Exporter generated number which uniquely identifies a packet. The > > sequence number increments for subsequent export packets. A separate > > sequence number is manintained for control and export data packets if > > control and data are send in separate packets. > > > > ### > > In the current NetFlow export implementation the sequence number is > > per flow so the collector can calculate lost flows. > > I thought it was per packet. Am I wrong? If so it is additional 4 byte info > per record? I thought there was a # of flow records in the header which > along with the sequence number in the header would give the count. I wasn't clear. The sequence number is per packet / per linecard and incremented by the count of records. This allows the collector to calculate the number of lost flow records. If there are multiple record types in the packet as you describe the collector no longer has the ability to calculate lost flows. Not incrementing the sequence number for the other record types obviously negates the ability to detect lost control information. This is also why I would like to see the Source ID restricted to 16 bits. The collector needs to potentially maintain a sequence number for each source ID for each exporter. A 16 bit source ID as in the current NetFlow exports can be realized with just a u_int32[65536], anything larger and hashing is needed to find the sequence number. > > > With per packet > > sequence number this functionality is lost. Mixing in control information > > complicates it even more (did you lose a control packet or flow packet). > > > Source ID: > > Unique identifier per observation domain. > > > > ### > > There needs to be an exporter ID (IP address) so that replicated IPFX > > packets retain the exporter. I'd like to see the Source ID restricted > > to 16 bits so the collector doesn't need to maintain a hash table to > > track the sequence numbers per exporter. > > What do you mean by "replicated IPFX packets"? An exporter can maintain m data exports, where m is probably 1 or 2. If there are n active collectors where n > m then something needs to replicate the data channel. When the all the collector has to identify the exporter is the transport address (ie destination IP) then the collectors see the replicator as the data source. A common implementation is one collector performing security/IDS and another doing traffic analysis. > > Need common terminology again. Statistics or Accounting? > > Statistics. Your marketing people disagree :) > > ### > > Verbage needs to be added about alignment. u_int32's on 32 bit > > boundries, u_in16's on on 16 bit boundries, etc. This also implies > > needing a 'NULL' field type for padding. Need to define byte order > > of fields. > > > > Also the exporter SHOULD provide optimal encoding, ie [...] > I guess over netwrok we have to send it as packed without any padding. > The exporter and collector may be running different processors. If the data records are sent as words with word alignment and long words with long word alignment the decode/encode process is going to require less cycles. With alignment the data elements can be fetched with with just an indirect reference, without you'll need to bcopy() them out first. Worst case overhead is 3 bytes per flow record. > > ### > > s/got// > > Just one place - right? I think I found one more :) mark -- 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 Tue Feb 12 20:41:03 2002 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 UAA03047 for ; Tue, 12 Feb 2002 20:41:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aoB9-0007cY-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 19:25:47 -0600 Received: from [216.167.117.195] (helo=www.inmon.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aoB8-0007cT-00 for ipfix-req@net.doit.wisc.edu; Tue, 12 Feb 2002 19:25:46 -0600 Received: from phaalpc (w086.z065104045.sjc-ca.dsl.cnc.net [65.104.45.86]) by www.inmon.com (8.9.3/(dn/norelay)) with SMTP id UAA21833; Tue, 12 Feb 2002 20:25:31 -0500 Reply-To: From: "Peter Phaal" To: "'Ganesh Sadasivan'" Cc: Subject: RE: [ipfix-req] Remote sampling and middle boxes Date: Tue, 12 Feb 2002 17:25:03 -0800 Message-ID: <005501c1b42d$43a06e40$3200000a@xo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C69BF89.CF1602B5@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > > Another situation would be a middle box that bridges > netflow, LFAP or > any > > other existing flow record into IPFIX flow records. > > I thought the plan was to come with a single export protocol that > everyone > conforms to. Even if everyone adopted IPFIX, there would still be legacy equipment exporting flows in other formats. It would be nice to simply bridge them into IPFIX, rather than have every application support every flow export format. Peter ---------------------- Peter Phaal InMon Corp. Peter_Phaal@inmon.com -- 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 Feb 13 00:22:43 2002 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 AAA09231 for ; Wed, 13 Feb 2002 00:22:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16arUz-00042e-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 22:58:29 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16arUv-00041t-00; Tue, 12 Feb 2002 22:58:25 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1D4rrv19865; Tue, 12 Feb 2002 22:53:54 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXS4W>; Tue, 12 Feb 2002 20:53:50 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A14360@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, Juergen Quittek Cc: "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 20:53:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B44A.6D03CDF0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B44A.6D03CDF0 Content-Type: text/plain; charset="iso-8859-1" Hello Paul, the problem with the "virtual" word is that there is no way to find out what is "virtual" and what is not. So, the "virtual" can be actually the real one. This is the same thing as outside and inside. See draft-iab-unsaf-considerations-01.txt. In the case of twice NAT where Src, Dest and Port may change it's really a mess. regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Tuesday, February 12, 2002 9:04 AM >To: Juergen Quittek >Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; >ipfix@net.doit.wisc.edu; data >Subject: Re: [ipfix] Draft updates - Comments on the data model > > > >Comments in-line... > >Juergen Quittek wrote: >> >> --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: >> >> > >> > Comments: >> > >> > First ol all, would you guys mind if I rewrite this whole >> > section using the words "private side" and "public side" so >> > we align our nomenclature to RFC2663? >> >> Why risking further inconsistencies? Just refer to RFC 2663. >> All you want to introduce is well explained there. >> >> > >> > Also, the subsection titles refer to "virtual" this and that, >> > but the IEs refer to "outside" and "inside". So, we need some >> > unified terminology. I also think that using inside and outside >> > can cause confusion since the exporter/collector does not know >> > what's inside and outside. See >draft-iab-unsaf-considerations-01.html >> >> I still have problems with "virtual", "inside", and "outside". >> This applies to firewalls and IPv4 NATs, but not to several other >> boxes. Why not using more general terms, such as "received" and >> "transmitted" or "original" and "modified". These terms would >> apply to a wider range of boxes (what is "inside" for a NAT-PT?). >> >> This would make the draft more independent from certain NAT/firewall >> scenarios and would be understandable even for people who do not care >> about NAT issues at all. > > I thought I addressed this already buit let me try > again. BTW - I believe this my proposal is not > at all specific to NAT/firewall. Maybe an example is > the best way to explain it. Using your terminology it > looks like this > > Flow on the way out... > > C -> IP-R gets translated to C -> IP-A > > Gets reported as > > Src = C > Dest-Received = IP-O > Dest-Transmitted = IP-A > > On the way back > > IP-A -> C gets translated to IP-O -> C > > Gets Reported as > > Src-Received = IP-A > Src-Transmitted = IP-O > Dest = C > > > > Now suppose I want to find all the flows to and from > my virtual IP. First I need a list of virtual IP's so > I can find them. Then I need to search both the received > and transmitted fields for both Src and Dest. It can be > done but it can also be easier (maybe not easier for > the IPFIX protocol but that's not what we're here for). > > If reported as I proposed it looks like this... > > > > Src = C > Dest-virtual = IP-O > Dest-Actual = IP-A > > Src-virtual = IP-O > Src-Actal = IP-A > Dest = C > > Now if I want to see all the traffic for my > virtual IP's I just look for flows that have > the same src or dest virtual address. I don't > need a list and the query is simple. Also, the > data in the fields is clear. The actual field > is where the packet actually came from or > went to. The virtual is the requested source > or destination. > > > This work for ANY packet that gets re-directed for ANY > reason. Even if IP's are not actually modified. Such > as MAC based re-direction. > > >> >> Reinaldo, you talked about good writing. I think this includes >> avoiding irrelevant information (while still remaining clearly >> understandable). >> >> > other stuff. >> > >> [...] >> > >> > then in 5.11.18 and 5.11.9 >> > >> > "The Destination Virtual IE contains the destination address of >> > the flow/port as *received* by the Exporter" >> > >> > It should be *transmited* by the exporter, ie, you need an almost >> > complete 5-tuple set of IEs for the private side and for the >> > public side. >> >> You see, it already gets confusing. "received/original destination" >> would have been a much better choice of term compared to "virtual >> destination". >> >> Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > ------_=_NextPart_001_01C1B44A.6D03CDF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Draft updates - Comments on the data model

Hello Paul,

the problem with the "virtual" word is that = there is no way to find out what is "virtual" and what is = not. So, the "virtual" can be actually the real one.  = This is the same thing as outside and inside. See = draft-iab-unsaf-considerations-01.txt. In the case of twice NAT where = Src, Dest and Port may change it's really a mess.

regards,

Reinaldo


>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Tuesday, February 12, 2002 9:04 AM
>To: Juergen Quittek
>Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. = Norseth;
>ipfix@net.doit.wisc.edu; data
>Subject: Re: [ipfix] Draft updates - Comments on = the data model
>
>
>
>Comments in-line...
>
>Juergen Quittek wrote:
>>
>> --On 12 February 2002 00:18 -0800 Reinaldo = Penno wrote:
>>
>> >
>> > Comments:
>> >
>> > First ol all, would you guys mind if I = rewrite this whole
>> > section using the words "private = side" and "public side" so
>> > we align our nomenclature to = RFC2663?
>>
>> Why risking further inconsistencies? Just = refer to RFC 2663.
>> All you want to introduce is well explained = there.
>>
>> >
>> > Also, the subsection titles refer to = "virtual" this and that,
>> > but the IEs refer to = "outside" and "inside". So, we need some
>> > unified terminology. I also think that = using inside and outside
>> > can cause confusion since the = exporter/collector does not know
>> > what's inside and outside. See
>draft-iab-unsaf-considerations-01.html
>>
>> I still have problems with = "virtual", "inside", and = "outside".
>> This applies to firewalls and IPv4 NATs, = but not to several other
>> boxes. Why not using more general terms, = such as "received" and
>> "transmitted" or = "original" and "modified". These terms would
>> apply to a wider range of boxes (what is = "inside" for a NAT-PT?).
>>
>> This would make the draft more independent = from certain NAT/firewall
>> scenarios and would be understandable even = for people who do not care
>> about NAT issues at all.
>
>       I thought I = addressed this already buit let me try
>       again. BTW = - I believe this my proposal is not
>       at all = specific to NAT/firewall. Maybe an example is
>       the best = way to explain it. Using your terminology it
>       looks like = this
>
>       Flow on the = way out...
>
>       =         C -> IP-R gets translated = to C -> IP-A
>
>       Gets = reported as
>
>       =         = Src           &nb= sp;  =3D C
>       =         = Dest-Received    =3D IP-O
>       =         Dest-Transmitted =3D = IP-A
>
>       On the way = back
>
>       =         IP-A -> C  gets = translated to IP-O -> C
>
>       Gets = Reported as
>
>       =         = Src-Received    =3D IP-A
>       =         Src-Transmitted =3D = IP-O
>       =         = Dest            = =3D C
>
>
>
>       Now suppose = I want to find all the flows to and from
>       my virtual = IP. First I need a list of virtual IP's so
>       I can find = them. Then I need to search both the received
>       and = transmitted fields for both Src and Dest. It can be
>       done but it = can also be easier (maybe not easier for
>       the IPFIX = protocol but that's not what we're here for).
>
>       If reported = as I proposed it looks like this...
>
>
>
>       =         = Src            = =3D C
>       =         Dest-virtual   =3D = IP-O
>       =         = Dest-Actual    =3D IP-A
>
>       =         = Src-virtual    =3D IP-O
>       =         = Src-Actal      =3D IP-A
>       =         = Dest           =3D = C
>
>       Now if I = want to see all the traffic for my
>       virtual = IP's I just look for flows that have
>       the same = src or dest virtual address. I don't
>       need a list = and the query is simple. Also, the
>       data in the = fields is clear. The actual field
>       is where = the packet actually came from or
>       went to. = The virtual is the requested source
>       or = destination.
>
>
>       This work = for ANY packet that gets re-directed for ANY
>       reason. = Even if IP's are not actually modified. Such
>       as MAC = based re-direction.
>
>
>>
>> Reinaldo, you talked about good writing. I = think this includes
>> avoiding irrelevant information (while = still remaining clearly
>> understandable).
>>
>> > other stuff.
>> >
>> [...]
>> >
>> > then in 5.11.18 and 5.11.9
>> >
>> > "The Destination Virtual IE = contains the destination address of
>> > the flow/port as *received* by the = Exporter"
>> >
>> > It should be *transmited* by the = exporter, ie, you need an almost
>> > complete 5-tuple set of IEs for the = private side and for the
>> > public side.
>>
>> You see, it already gets confusing. = "received/original destination"
>> would have been a much better choice of = term compared to "virtual
>> destination".
>>
>>     Juergen
>> --
>> Juergen Quittek     = quittek@ccrle.nec.de     Tel: +49 6221 = 90511-15
>> NEC Europe Ltd.,    Network = Laboratories     Fax: +49 6221 90511-55
>> Adenauerplatz 6, 69115 Heidelberg, = Germany   http://www.ccrle.nec.de
>

------_=_NextPart_001_01C1B44A.6D03CDF0-- -- 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 Feb 13 00:47:21 2002 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 AAA10825 for ; Wed, 13 Feb 2002 00:47:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aruD-0004WM-00 for ipfix-list@mil.doit.wisc.edu; Tue, 12 Feb 2002 23:24:33 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16arUv-00041t-00; Tue, 12 Feb 2002 22:58:25 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1D4rrv19865; Tue, 12 Feb 2002 22:53:54 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFXS4W>; Tue, 12 Feb 2002 20:53:50 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A14360@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, Juergen Quittek Cc: "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Date: Tue, 12 Feb 2002 20:53:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B44A.6D03CDF0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B44A.6D03CDF0 Content-Type: text/plain; charset="iso-8859-1" Hello Paul, the problem with the "virtual" word is that there is no way to find out what is "virtual" and what is not. So, the "virtual" can be actually the real one. This is the same thing as outside and inside. See draft-iab-unsaf-considerations-01.txt. In the case of twice NAT where Src, Dest and Port may change it's really a mess. regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Tuesday, February 12, 2002 9:04 AM >To: Juergen Quittek >Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; >ipfix@net.doit.wisc.edu; data >Subject: Re: [ipfix] Draft updates - Comments on the data model > > > >Comments in-line... > >Juergen Quittek wrote: >> >> --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: >> >> > >> > Comments: >> > >> > First ol all, would you guys mind if I rewrite this whole >> > section using the words "private side" and "public side" so >> > we align our nomenclature to RFC2663? >> >> Why risking further inconsistencies? Just refer to RFC 2663. >> All you want to introduce is well explained there. >> >> > >> > Also, the subsection titles refer to "virtual" this and that, >> > but the IEs refer to "outside" and "inside". So, we need some >> > unified terminology. I also think that using inside and outside >> > can cause confusion since the exporter/collector does not know >> > what's inside and outside. See >draft-iab-unsaf-considerations-01.html >> >> I still have problems with "virtual", "inside", and "outside". >> This applies to firewalls and IPv4 NATs, but not to several other >> boxes. Why not using more general terms, such as "received" and >> "transmitted" or "original" and "modified". These terms would >> apply to a wider range of boxes (what is "inside" for a NAT-PT?). >> >> This would make the draft more independent from certain NAT/firewall >> scenarios and would be understandable even for people who do not care >> about NAT issues at all. > > I thought I addressed this already buit let me try > again. BTW - I believe this my proposal is not > at all specific to NAT/firewall. Maybe an example is > the best way to explain it. Using your terminology it > looks like this > > Flow on the way out... > > C -> IP-R gets translated to C -> IP-A > > Gets reported as > > Src = C > Dest-Received = IP-O > Dest-Transmitted = IP-A > > On the way back > > IP-A -> C gets translated to IP-O -> C > > Gets Reported as > > Src-Received = IP-A > Src-Transmitted = IP-O > Dest = C > > > > Now suppose I want to find all the flows to and from > my virtual IP. First I need a list of virtual IP's so > I can find them. Then I need to search both the received > and transmitted fields for both Src and Dest. It can be > done but it can also be easier (maybe not easier for > the IPFIX protocol but that's not what we're here for). > > If reported as I proposed it looks like this... > > > > Src = C > Dest-virtual = IP-O > Dest-Actual = IP-A > > Src-virtual = IP-O > Src-Actal = IP-A > Dest = C > > Now if I want to see all the traffic for my > virtual IP's I just look for flows that have > the same src or dest virtual address. I don't > need a list and the query is simple. Also, the > data in the fields is clear. The actual field > is where the packet actually came from or > went to. The virtual is the requested source > or destination. > > > This work for ANY packet that gets re-directed for ANY > reason. Even if IP's are not actually modified. Such > as MAC based re-direction. > > >> >> Reinaldo, you talked about good writing. I think this includes >> avoiding irrelevant information (while still remaining clearly >> understandable). >> >> > other stuff. >> > >> [...] >> > >> > then in 5.11.18 and 5.11.9 >> > >> > "The Destination Virtual IE contains the destination address of >> > the flow/port as *received* by the Exporter" >> > >> > It should be *transmited* by the exporter, ie, you need an almost >> > complete 5-tuple set of IEs for the private side and for the >> > public side. >> >> You see, it already gets confusing. "received/original destination" >> would have been a much better choice of term compared to "virtual >> destination". >> >> Juergen >> -- >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > ------_=_NextPart_001_01C1B44A.6D03CDF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Draft updates - Comments on the data model

Hello Paul,

the problem with the "virtual" word is that = there is no way to find out what is "virtual" and what is = not. So, the "virtual" can be actually the real one.  = This is the same thing as outside and inside. See = draft-iab-unsaf-considerations-01.txt. In the case of twice NAT where = Src, Dest and Port may change it's really a mess.

regards,

Reinaldo


>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Tuesday, February 12, 2002 9:04 AM
>To: Juergen Quittek
>Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. = Norseth;
>ipfix@net.doit.wisc.edu; data
>Subject: Re: [ipfix] Draft updates - Comments on = the data model
>
>
>
>Comments in-line...
>
>Juergen Quittek wrote:
>>
>> --On 12 February 2002 00:18 -0800 Reinaldo = Penno wrote:
>>
>> >
>> > Comments:
>> >
>> > First ol all, would you guys mind if I = rewrite this whole
>> > section using the words "private = side" and "public side" so
>> > we align our nomenclature to = RFC2663?
>>
>> Why risking further inconsistencies? Just = refer to RFC 2663.
>> All you want to introduce is well explained = there.
>>
>> >
>> > Also, the subsection titles refer to = "virtual" this and that,
>> > but the IEs refer to = "outside" and "inside". So, we need some
>> > unified terminology. I also think that = using inside and outside
>> > can cause confusion since the = exporter/collector does not know
>> > what's inside and outside. See
>draft-iab-unsaf-considerations-01.html
>>
>> I still have problems with = "virtual", "inside", and = "outside".
>> This applies to firewalls and IPv4 NATs, = but not to several other
>> boxes. Why not using more general terms, = such as "received" and
>> "transmitted" or = "original" and "modified". These terms would
>> apply to a wider range of boxes (what is = "inside" for a NAT-PT?).
>>
>> This would make the draft more independent = from certain NAT/firewall
>> scenarios and would be understandable even = for people who do not care
>> about NAT issues at all.
>
>       I thought I = addressed this already buit let me try
>       again. BTW = - I believe this my proposal is not
>       at all = specific to NAT/firewall. Maybe an example is
>       the best = way to explain it. Using your terminology it
>       looks like = this
>
>       Flow on the = way out...
>
>       =         C -> IP-R gets translated = to C -> IP-A
>
>       Gets = reported as
>
>       =         = Src           &nb= sp;  =3D C
>       =         = Dest-Received    =3D IP-O
>       =         Dest-Transmitted =3D = IP-A
>
>       On the way = back
>
>       =         IP-A -> C  gets = translated to IP-O -> C
>
>       Gets = Reported as
>
>       =         = Src-Received    =3D IP-A
>       =         Src-Transmitted =3D = IP-O
>       =         = Dest            = =3D C
>
>
>
>       Now suppose = I want to find all the flows to and from
>       my virtual = IP. First I need a list of virtual IP's so
>       I can find = them. Then I need to search both the received
>       and = transmitted fields for both Src and Dest. It can be
>       done but it = can also be easier (maybe not easier for
>       the IPFIX = protocol but that's not what we're here for).
>
>       If reported = as I proposed it looks like this...
>
>
>
>       =         = Src            = =3D C
>       =         Dest-virtual   =3D = IP-O
>       =         = Dest-Actual    =3D IP-A
>
>       =         = Src-virtual    =3D IP-O
>       =         = Src-Actal      =3D IP-A
>       =         = Dest           =3D = C
>
>       Now if I = want to see all the traffic for my
>       virtual = IP's I just look for flows that have
>       the same = src or dest virtual address. I don't
>       need a list = and the query is simple. Also, the
>       data in the = fields is clear. The actual field
>       is where = the packet actually came from or
>       went to. = The virtual is the requested source
>       or = destination.
>
>
>       This work = for ANY packet that gets re-directed for ANY
>       reason. = Even if IP's are not actually modified. Such
>       as MAC = based re-direction.
>
>
>>
>> Reinaldo, you talked about good writing. I = think this includes
>> avoiding irrelevant information (while = still remaining clearly
>> understandable).
>>
>> > other stuff.
>> >
>> [...]
>> >
>> > then in 5.11.18 and 5.11.9
>> >
>> > "The Destination Virtual IE = contains the destination address of
>> > the flow/port as *received* by the = Exporter"
>> >
>> > It should be *transmited* by the = exporter, ie, you need an almost
>> > complete 5-tuple set of IEs for the = private side and for the
>> > public side.
>>
>> You see, it already gets confusing. = "received/original destination"
>> would have been a much better choice of = term compared to "virtual
>> destination".
>>
>>     Juergen
>> --
>> Juergen Quittek     = quittek@ccrle.nec.de     Tel: +49 6221 = 90511-15
>> NEC Europe Ltd.,    Network = Laboratories     Fax: +49 6221 90511-55
>> Adenauerplatz 6, 69115 Heidelberg, = Germany   http://www.ccrle.nec.de
>

------_=_NextPart_001_01C1B44A.6D03CDF0-- -- 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 Feb 13 01:41:43 2002 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 BAA12518 for ; Wed, 13 Feb 2002 01:41:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16asnL-0005V4-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 00:21:31 -0600 Received: from c001-h000.c001.snv.cp.net ([209.228.32.114] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16asnH-0005UE-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 00:21:27 -0600 Received: (cpmta 6735 invoked from network); 12 Feb 2002 22:20:52 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.114) with SMTP; 12 Feb 2002 22:20:52 -0800 X-Sent: 13 Feb 2002 06:20:52 GMT Message-ID: <018c01c1b456$f32bb6c0$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: References: Subject: [ipfix] Configuration & MIBS Date: Tue, 12 Feb 2002 23:23:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0189_01C1B41C.461D64E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0189_01C1B41C.461D64E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture DraftAn email from = Mike Mcfadden and Dave Harrington brought up the issues of mibs and = management. As Dave explained itt, it is almost expected that a mib be = written as part of the WG for configuration of basic objects and = monitoring. This is not in the charter, but we need to think about = this. How much could the RTFM mibs be used? Would a config mib and a = monitoring mib be useful? What do people say? This does not have to be answered as part of our = work here, but it should be addressed at least in Minneapolis. ( I have = my absestos suit on now). K.C. ----- Original Message -----=20 From: Kevin Zhang=20 To: will@cisco.com ; Reinaldo Penno ; K.C. Norseth ; = ipfix@net.doit.wisc.edu=20 Sent: Tuesday, February 12, 2002 8:19 AM Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the Architecture Draft) Hi All, =20 My views on the points raised by Will - =20 The exporter configuration might be outside the scope of IPFIX; = however, a negotiation process that allows the exporter and collector to = sync on a protocol and information model is the best way to achieve = interoperability and satisfy application requirements in the meantime; = It is within the scope of the IPFIX WG. Furthermore, a probe can be an = exporter that has far more monitoring/metering flexibility. By = insisting on a rigid design, we are excluding an important segment of = IPFIX users.=20 =20 With regard to underlying transport, it was mentioned explicitly in = our charter that the transport protocol has to be congestion aware. I = do believe there are situations that UDP might be used when it does not = interfere other traffic (such as over LAN, see the architecture draft). = If transport layer can be negotiated (in-band or out-band), we can = accommodate both reliable and unreliable transport protocols.=20 =20 Thanks, =20 Kevin =20 =20 =20 =20 -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On = Behalf Of Will Eatherton Sent: Tuesday, February 12, 2002 12:37 AM To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the Architecture Draft) Lets be more clear cut then this. I dont want to have a major = architectural SHOULD on something we believe is fundamentally flawed and = will occupy signficant group time to spec if it is left in. We need a = clear decision to move forward. A spec that includes SHOULDS for all = proposed features is weak. =20 WIll -----Original Message----- From: majordomo listserver = [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno Sent: Monday, February 11, 2002 8:57 PM To: K.C. Norseth; will@cisco.com; ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the = recent comments on the Architecture Draft) Hello Norseth, =20 I think the right question to answer is not if it is = "necessary", since you can always pay somebody to be some sort of CLI = configuration master and do everything by hand. =20 I think the right question is if it should be on the = architecture document or not and with whihch level of compliance.=20 =20 I think it should be on the arch document and maybe putting it = with a SHOULD instead of a MUST will make (most) people happy. =20 cheers, =20 Reinaldo =20 =20 -----Original Message----- From: K.C. Norseth [mailto:kcn@norseth.com] Sent: Monday, February 11, 2002 8:25 PM To: will@cisco.com; ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the Architecture Draft) Will, I agree. Let's go for the wg concensus. What do people say? | - the exporter configuration is out of the scope of this = document (the exporter configuration out of band) =20 Configuration I think is out of scope, unless we hook it to an = existing mib or something. I so, we can refer to that mib or process. |- no transport negotiation (which transport) we need to define the action of each transport type. | - no capability negotiation Nice, but necessary? =20 =20 K.C. ----- Original Message -----=20 From: Will Eatherton=20 To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu ; = ipfix-arch-volunteers@net.doit.wisc.edu=20 Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; = plonka@doit.wisc.edu=20 Sent: Monday, February 11, 2002 8:24 AM Subject: Scope of IPFIX (was Answer to the recent comments = on the Architecture Draft) Group, =20 Cisco's interest in IPFIX was to help establish a = non-proprietary protocol similar to netflow but more flexible allowing = us to add value to our customers (and do so in a timely manner). If = IPFIX goes down a path along the lines as being advocated recent threads = by Reinaldo, it is unclear if the added burden of the protocol will be = make it worth the benefits of a non-proprietary protocol. Given it = seems I have seen roughly the same conversation occur 3 times in past = several day, It is unclear if further email discussion on this topic = will resolve the underlying question as to the scope of IPFIX. It seems = time for an official call on what is in/out of scope for IPFIX. As has = been mentioned here multiple times we would like to hear : =20 - the exporter configuration is out of the scope of this = document (the exporter configuration out of band) - no transport negotiation (which transport) - no capability negotiation Will :So lets have a protocol which is more flexible as NetFlow = version=20 :1-7,=20 I will not comment on that too much...Basically we are not = here to reverse-engineer Netflow, but to incorporate some good ideas = from it. :but not much more complicated, in order to be = successfully=20 :accepted by hardware vendors and application programmers. = ohh, please...Then Netflow is just right?=20 Reinaldo=20 ------=_NextPart_000_0189_01C1B41C.461D64E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Answer to the recent comments on the Architecture = Draft
An email from Mike Mcfadden and Dave = Harrington=20 brought up the issues of mibs and management.  As Dave explained = itt, it is=20 almost expected that a mib be written as part of the WG for = configuration of=20 basic objects and monitoring.  This  is not in the charter, = but we=20 need to think about this.  How much could the RTFM mibs be = used? =20 Would a config mib and a monitoring mib be useful?
 
What do people say?  This does not = have to be=20 answered as part of our work here, but it should be addressed at least = in=20 Minneapolis. ( I have my absestos suit on now).
 
 
K.C.
----- Original Message -----
From:=20 Kevin=20 Zhang
To: will@cisco.com ; Reinaldo Penno ; K.C. = Norseth ; ipfix@net.doit.wisc.edu
Sent: Tuesday, February 12, = 2002 8:19=20 AM
Subject: RE: [ipfix] Re: Scope = of IPFIX=20 (was Answer to the recent comments on the Architecture Draft)

Hi=20 All,
 
My=20 views on the points raised by Will -
 
The exporter configuration might be outside the scope of = IPFIX;=20 however, a negotiation process that allows the exporter and = collector to=20 sync on a protocol and information model is the best way to achieve=20 interoperability and satisfy application requirements in the = meantime; It is=20 within the scope of the IPFIX WG.  Furthermore, a probe can be = an=20 exporter that has far more monitoring/metering flexibility.  By = insisting on a rigid design, we are excluding an important segment = of IPFIX=20 users. 
 
With regard to underlying transport, it was mentioned = explicitly in=20 our charter that the transport protocol has to be congestion = aware.  I=20 do believe there are situations that UDP might be used when it = does not=20 interfere other traffic (such as over LAN, see the architecture=20 draft).  If transport layer can be negotiated (in-band or = out-band), we=20 can accommodate both reliable and unreliable transport=20 protocols. 
 
Thanks,
 
Kevin
 
 
 
 
 -----Original=20 Message-----
From: majordomo listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Will=20 Eatherton
Sent: Tuesday, February 12, 2002 12:37 = AM
To:=20 Reinaldo Penno; K.C. Norseth; = ipfix@net.doit.wisc.edu
Subject: RE:=20 [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the = Architecture Draft)

Lets be more clear cut then this. I dont want to = have a major=20 architectural SHOULD on something we believe is=20 fundamentally flawed and will occupy signficant group time to spec = if it=20 is left in.  We need a clear decision to move forward.  = A spec=20 that includes SHOULDS for all proposed features is=20 weak.
 
WIll
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo = Penno
Sent: Monday, February 11, 2002 8:57 = PM
To:=20 K.C. Norseth; will@cisco.com; = ipfix@net.doit.wisc.edu
Subject:=20 RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the=20 Architecture Draft)

Hello Norseth,
 
I think the right question to answer = is not if=20 it is "necessary", since you can always pay somebody to be some = sort of=20 CLI configuration master and do everything by hand.=20  
I think the right question is if it = should be=20 on the architecture document or not and with whihch level of = compliance.=20
 
I think it should be on the arch = document=20 and maybe putting it with a SHOULD instead of a MUST will = make=20 (most) people happy.
 
cheers,
 
Reinaldo
 
 
 -----Original=20 Message-----
From: K.C. Norseth=20 [mailto:kcn@norseth.com]
Sent: Monday, February 11, = 2002 8:25=20 PM
To: will@cisco.com;=20 ipfix@net.doit.wisc.edu
Subject: [ipfix] Re: Scope of = IPFIX=20 (was Answer to the recent comments on the Architecture=20 Draft)

Will,
 
I agree. Let's go for the wg concensus.  What do people=20 say?
 
| -=20 the exporter configuration is out of the scope of this = document   (the = exporter configuration out = of=20 band)
 
Configuration I think is out of scope, unless we hook = it to an=20 existing mib or something.  I so, we can refer to that = mib or=20 process.

|- no transport = negotiation=20 (which transport)

we need to define the action of = each=20 transport type.

| - no = capability=20 negotiation

Nice, but necessary?  

 
K.C.
----- Original Message ----- =
From:=20 Will=20 Eatherton
To: Reinaldo Penno = ; ipfix-arch@net.doit.wisc.edu=20 ; ipfix-arch-volunteers@net= .doit.wisc.edu=20
Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; = plonka@doit.wisc.edu
Sent: Monday, = February 11, 2002=20 8:24 AM
Subject: Scope of = IPFIX (was=20 Answer to the recent comments on the Architecture = Draft)

Group,
 
Cisco's interest in IPFIX  was to = help=20 establish a non-proprietary protocol similar to netflow = but=20 more flexible allowing us to add value to our customers = (and do=20 so in a timely manner).  If IPFIX goes down a=20 path along the lines as being advocated recent threads = by=20 Reinaldo,  it is unclear if the added burden of = the=20 protocol will be make it worth the benefits of a = non-proprietary=20 protocol.  Given it seems I have seen roughly the = same=20 conversation occur 3 times in past several day, It is = unclear if=20 further email discussion on this topic will resolve the = underlying=20 question as to the scope of IPFIX.  It seems=20 time for an official call on what is in/out = of scope=20 for IPFIX.  As has been mentioned here = multiple times=20 we would like to hear = :  

- the = exporter=20 configuration is out of the scope of this document   (the=20 exporter configuration out of band)

- no = transport negotiation=20 (which transport)

 - no = capability=20 negotiation

Will

:So lets have a protocol which is more = flexible as=20 NetFlow version
:1-7, =

I will not comment on that too = much...Basically we=20 are not here to reverse-engineer Netflow, but to = incorporate some=20 good ideas from it.

:but not much more complicated, in order = to be=20 successfully
:accepted by = hardware vendors=20 and application programmers.

ohh, please...Then Netflow is just = right?=20

Reinaldo=20 =






------=_NextPart_000_0189_01C1B41C.461D64E0-- -- 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 Feb 13 01:47:13 2002 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 BAA12642 for ; Wed, 13 Feb 2002 01:47:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16asvJ-0005f3-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 00:29:45 -0600 Received: from c001-h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16asvG-0005eQ-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 00:29:42 -0600 Received: (cpmta 22196 invoked from network); 12 Feb 2002 22:29:10 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.115) with SMTP; 12 Feb 2002 22:29:10 -0800 X-Sent: 13 Feb 2002 06:29:10 GMT Message-ID: <01dd01c1b458$1c5d8fe0$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: "Robert Lowe" Cc: References: <59358A738F45D51186A30008C74CE250DA06B3@slc-exc1.ctron.com> <3C696B88.4C1458B5@lawrence.edu> Subject: Re: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 Date: Tue, 12 Feb 2002 23:31:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Robert, ----- Original Message ----- From: Robert Lowe To: Norseth, KC Cc: Sent: Tuesday, February 12, 2002 12:22 PM Subject: Re: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 | > "Norseth, KC" wrote: | | Hi KC! | | > |A few more comments regarding templates, although ones which | > |probably fall within the realm of operational vs. protocol issues... | > | | > |Early on there was some discussion regarding the impact of | > |IPFIX on the network itself, and if/how the exporter or | > |collector should react to overload conditions. As I recall, | > |Peter Phaal indicated that from an analysis point of view, it | > |would not be good to change the sample rate. However, when | > |faced with an overload condition: | > | | > |1) On the exporter, should it: | > | a. continue as is, and drop packets when it has to, or | > | b. fall-back to a user pre-defined sampling rate, compromising | > | IPFIX data to avoid dropping packets ?? | > | | > |2) On the collector, should it: | > | a. continue, and lose flow data because it cannot | > |process it all, or | > | b. signal a fall-back to a different sampling rate via | > |a new template? | > | | > |If the solution uses the verb "buy", don't mention it! ;-) I | > |can accept a good argument that these are operational issues. | > | > This is very dangerous to have the exporter switch to sampling automatically. This | > could really confuse the information being gathered. You could get the message from the | > reports that volume has dropped down during a period of time, but in reality, it is | > dnagerously high. | | No, I was assuming that the new template would somehow be recorded, or available | during analysis, so that it would be recognized that the sampling rate changed | and could be properly reflected in a report. I agree that not having this change | record available during analysis makes the analysis pretty useless. | | But this is a kind of in-band config that would add more complexity than would | seem to outweigh its benefit. I think I need to re-read a few things to better | understand the use of templates in general too. This could be a SHOULD if people want it to be. I think it could be dangerous, but you are right, a template could inform the collector that this is sampled data. The collector would have to be smart enough to explain this to the readers of the reports when it changes though. It would also have to be smart to switch back and once again the collector would have to be smart enough to report this to the users. I don't think the collectors/applications out there now are smart enough for this. K.C. | Thanks! | | -Robert | | -- | 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/ | -- 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 Feb 13 02:55:36 2002 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 CAA22166 for ; Wed, 13 Feb 2002 02:55:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16atye-000771-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 01:37:16 -0600 Received: from c001-h000.c001.snv.cp.net ([209.228.32.114] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16atya-000760-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 01:37:12 -0600 Received: (cpmta 8440 invoked from network); 12 Feb 2002 23:36:38 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.114) with SMTP; 12 Feb 2002 23:36:38 -0800 X-Sent: 13 Feb 2002 07:36:38 GMT Message-ID: <028801c1b461$88c7afe0$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: , References: <3C695880.69C2A4FB@riverstonenet.com> <3C695D44.40D5A338@riverstonenet.com> Subject: [ipfix] Re: [ipfix-data] Data Doc Date: Wed, 13 Feb 2002 00:39:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, Where there is some elements that need to be fleshed out, it would be great to see them expanded/explained. Comments inline. ----- Original Message ----- From: To: Norseth, KC ; data Sent: Tuesday, February 12, 2002 11:21 AM Subject: [ipfix-data] Data Doc | KC, here are a bunch of edits. If you want, | send me the source and I'll take editor | responsibilties for it. | | Paul | | calato@riverstonenet.com wrote: | > | > 4. Information Model | > | | Delete Start | ============ | | > I think we need to begin with a couple of guidlines (which | > we should augment as we go). They are just guidelines. | > | > 1. Data element values should be defined in terms of other | > specifications. Since we are only reporting things in other protocols, | > there should be little reason for us to define anything from scatch. | > | > 2. Each element should be able to be interpreted on it own. In other | > words, don't make me look though the rest of the message to figure out | > what this value means. The drawback is this can lead to data element | > explosion. We'll have to balance the tradeoffs. | > | > 3. Others? | | Delete End | =========== | | Those were just my comments. I don't think they belong | in the document. Ok. There are other personal observations and comments still embedded in noth texts. | | > | > The IPFIX information model is listed in the IPFIX requirement | > document. The information model consists of the minimum set of | > attributes that an IPFIX exporting device should be able to export. In | > conjunction with IP flow definitions, they provide locally accurate | > information about a flow. | | I do not think it is the minimum set. It is the full | set to this point in time. We need to define the full | set in order to get interoperabiltity. Vendors defining | their own fields should be the exception rather than the | rule. Is taking out MINIMUM enough? | > | > 4.2. Attributes Related to Measurement | > | > The following attributes relates to measurements and measuring | > methodology: | > o Packet Counter | > o Dropped Packet Counter | > o Payload Byte Counter | | What is this?? Byte conter - It does sound funny. I will remove payload. This area is a cut and paste from Benoit/Ganesh. This area could be clarified and cleaned up. | | > o Timestamp of the First Packet Observed | > o Timestamp of the Last Packet Observed | > o Timeout Indication | > o Sampling Method | > o Sampling Parameters | > | > 4.3. Attributes Related to Flow Definition | > | > The following attributes relates to IP flow definitions. | > | > o Incoming Interface | > o Outgoing Interface | > o Packet Treatment | > o Unique ID of the Observation Point | > o Unique ID of the Measuring Device | > | > 4.4. Attributes related to Upper Layers | > | > The following attributes provides information of upper layer protocols. | > o Source Port Address | > o MPLS Label (if MPLS is supported) | | Just a nit but MPLS is actaually a lower layer. | | | Where are derived things like AS number? Ok. Clipped from Benoit/Ganesh. Can be cleaned up. Got some better wording? | > | > 4.5. IPFIX Template | > | > The IPFIX system MUST support efficient exporting of IP flow | > information. This can be achieved by negotiating a set of IPFIX | > Templates for an IPFIX session before actual IP flow information is | > exported. A template defines the structure of an IPFIX user message | > payload by describing the data type, meaning, and location of the fields | > in the payload. By agreeing on IPFIX templates, IPFIX end-points | > understand how to process IPFIX user messages. As a result, an exporting | > device only needs to export actual flow information without attaching | > any descriptors of the attributes; this reduces the amount of bytes sent | > over communication links. | > | > A template is an ordered list of keys. A key specifies an attribute that | > a meter entity MAY export. The specification MUST consist of the | > description and the data type of the attribute. (e.g. 'Number of Sent | > Bytes' can be a key that is an 32 bit unsigned integer) An exporting | > device typically defines keys. Based on the IPFIX information model, a | > set of IPFIX standard keys can be defined. | > | > 4.5.1. Template Negotiation | > | > During the initial setup of an IPFIX session, template negotiation | > procedures should be carried out. It would allow all the IPFIX | > end-points to synchronize on a set of templates that will be used during | > IP flow information export. | | | I assume a lot more discussion needs to happen here. Yes. This needs to be worked out more. | > | > 5. Information Elements | > 5.1. Packet Management | > | > This information contains the fields needed to manage the data packets | > transmitted | > | > 5.1.1. Version Number | > | > [Need to expand more] | | If this is IPFIX protocol version, it does not | belong here. I think we need to worry about a verions number. If not here, where? | | > | > 5.1.2. FLOWS | > V#3 S#4 | > Number of main cache flows | | What is this??? I saw this is as a flow counter in the header. This came from Beniot/Ganesh. It needs to be clarified. What I did was to go thgough Benoit & Ganeshs' document and add elements that we seemed to be missing in our doc.. Unfortunatly, some of these do not explein themselves well. I hope we can either flesh them out and give the same look and feel, or drop them if not needed. | > | > 5.1.3. FLOW_LABEL | > V#31 S#2 | > IPV6 Flow Label | > [Need to expand more] | > | | Delete, already covered below in more detail. Ok. | | | | Start delete | ============ | | > 5.12. NAT | > 5.12.1. INSIDE_L4_SRC | > V#42 S#2 | > | > NAT port number (.e.g, FTP, Telnet, etc...) only applicable with NAT | > | > 5.12.2. INSIDE_IPV4_SRC_ADDR | > V#43 S#4 | > Source IPv4 Address only applicable with NAT TCP/UDP destination port | > | > 5.12.3. INSIDE_L4_DST_PORT | > V#44 S#2 | > The number (.e.g, FTP, telnet etc...) only applicable with NAT | > | > 5.12.4. INSIDE_IPV4_DST_ADDR | > V#45 S#4 | > Destination IPv4 Address only applicable with NAT | > | > 5.12.5. INSIDE_IPV6_SRC_ADDR | > V#46 S#16 | > IPv6 Source Address only applicable with NAT | > | > 5.12.6. INSIDE_IPV6_DST_ADDR | > V#47 #16 | > IPv6 Destination Address only applicable with NAT | > | > 5.12.7. OUTSIDE_L4_SRC_PORT | > V#48 S#2 | > TCP/UDP destination port number (.e.g, FTP, Telnet, etc...) only | > applicable with NAT | > | > 5.12.8. OUTSIDE_IPV4_SRC_ADDR | > V#49 S#4 | > Source IPv4 Address only applicable with NAT TCP/UDP destination port | > | > 5.12.9. OUTSIDE_L4_DST_PORT | > V#50 S#2 | > number (.e.g, FTP, Telnet, etc...) only applicable with NAT | > | > 5.12.10. OUTSIDE_IPV4_DST_ADDR | > V#51 S#4 | > Destination IPv4 Address only applicable with NAT | > | > 5.12.11. OUTSIDE_IPV6_SRC_ADDR | > V#52 S#16 | > IPv6 Source Address only applicable with NAT | > | > 5.12.12. OUTSIDE_IPV6_DST_ADDR | > V#53 S#16 | > IPv6 Destination Address only applicable with NAT | > | | | Delete ENd | ========== | | Already covered above in more detail above. | Even if we disagree on the exact text, this | stuyff is duplicate. Ok, Gone. > 5.13. Vendor Specific IE | > | > 5.14.6. IPM_DPKTS | > V#19 S#4 | > Packet count for IP Multicast | > | > 5.14.7. IPM_DOCTETS | > V#20 S#4 | > Octet (byte) count for IP Multicast | | IPM_DPKTS and IPM_DOCTETS should be moved to where | the other counts are. Moved to counters. Still need to be fleshed out. | > | > 5.14.8. LAST_SWITCHED | > V#21 S#4 | > SysUptime at which the last packet of this flow was switched | > | > 5.14.9. FIRST_SWITCHED | > V#22 S#4 | > SysUptime at which the first packet of this flow was switched | > [Need to expand more] | > | | Move these with the other timestamp info, | I'll work on combining. Ok. | > 5.14.10. MAC_ADDR | > V#25 S#6 | > Layer 2 Media Access Control address associated with a flow | > | | Delete. Already covered under the address stuff. Ok. I keep thining only IP when I think of address. this is an address and both can be on a record. | | > 5.14.11. VLAN_ID | > V#26 S#2 | > Virtual LAN identifier associated with a flow | | Delete. already covered in more detail. Ok. | > | > 5.14.12. ICMP_TYPE | > V#32 S#1 | > ICMP Packet Type. This is reported as (ICMP Type * 256) + ICMP code | | | We need a spec reference. Yes. Copied from Benoit/Ganesh. | > | > 5.14.13. IGMP_TYPE | > V#33 S#1 | > IGMP Packet Type | | | we need a spec reference. Ditto. | > | > 5.15. Sampling | > | > 5.15.1. SAMPLING_INTERVAL | > V#34 S#1 | > When using Sampling, the rate at which packets are sampled. For | > example, a value of 100 indicates that one of every hundred packets is | > sampled. | > | > 5.15.2. SAMPLING_ALGO | > V#35 S#1 | > The type of algorithm used for sampling | > data. Currently, the only | > sampling algorithm defined is: | > 0x02 packet-sampling | > | > 5.15.3. FLOW_ACTIVE_TIMEOUT | > V#36 S#2 | > Timeout value for active flow entries in the cache. | > | > 5.15.4. FLOW_INACTIVE_TIMEOUT | > V#37 S#2 | > Timeout value for inactive flow entries in the cache. | > K.C. -- 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 Feb 13 04:49:07 2002 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 EAA24864 for ; Wed, 13 Feb 2002 04:49:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aviu-0001r8-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 03:29:08 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16avis-0001r0-00 for ipfix-req@net.doit.wisc.edu; Wed, 13 Feb 2002 03:29:06 -0600 Received: from fokus.fhg.de (dhcp187 [195.37.78.187]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1D9Sxp20161; Wed, 13 Feb 2002 10:28:59 +0100 (MET) Message-ID: <3C6A30D8.67239373@fokus.fhg.de> Date: Wed, 13 Feb 2002 10:24:40 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: Peter_Phaal@inmon.com CC: "'Benoit Claise'" , quittek@ccrle.nec.de, ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Remote sampling and middle boxes References: <004901c1b402$0c6d2ba0$3200000a@xo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Peter, Peter Phaal schrieb: > > Sebastian Zander wrote: > > Quoting from the draft section 5.1: > > > > "The measuring device MUST be able to report the following attributes > > for each measured flow: > > [...] > > 18. unique identifier of the observation point > > 19. unique identifier of the measuring device > > " > > > > Is that not what you want? > > > > I didn't see this language in the posted drafts > . Please look at http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-00.txt. This is the current requirements draft and I was thinking you were talking about it because your post did go to ipfix-req. > This might be sufficient if the design document supports multiple > definitions of an observation point: > 1. ifIndex|vlan ... (implies an observation point on measuring device). > 2. Agent. (implies remote observation point on Agent) > 3. Agent (all interfaces an remote Agent). > 4. list of observation points (data aggregated from multiple observation > points). > > An intermediate device collecting netflow, IPFIX, samples from multiple > sources requires a degree of flexibility in describing the source of the > data for each "virtual" or "proxy" observation point it re-exports using > IPFIX. > > Is this type of measurement device within the scope IPFIX? Supporting > multi-tiered IPFIX architectures would make for much greater scalability. My > reading of the current architecture is that it limits itself to two or three > tiers (depending on how one counts). It's not clear that an observation > point could be an IPFIX collector, or that a collector could export IPFIX > data. I like your proposal of building hierarchies of something like aggregators+ exporters for scalability. I think this should be considered in the architecture draft. Sebastian -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Feb 13 05:43:18 2002 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 FAA26325 for ; Wed, 13 Feb 2002 05:43:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16awav-0003LM-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 04:24:57 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16awat-0003LE-00 for ipfix-req@net.doit.wisc.edu; Wed, 13 Feb 2002 04:24:55 -0600 Received: from fokus.fhg.de (dhcp187 [195.37.78.187]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1DAOnp02284; Wed, 13 Feb 2002 11:24:49 +0100 (MET) Message-ID: <3C6A3DEE.F2D92370@fokus.fhg.de> Date: Wed, 13 Feb 2002 11:20:30 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <4108689799.1013426004@[192.168.102.164]> <3C694086.5D0B0891@cisco.com> <3C6961EE.8A7BED8@fokus.fhg.de> <3C699C3A.9203D67D@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, Benoit Claise schrieb: > > Hi Sebastian, > > [I skip the points on which we agree] > > > > > > > > 2. I think we should have statements in the requirement document about: > > > - configuration will be done out-bound > > > Note: this is at least the direction I see in the working group on that one: > > > Will, KC, Juergen, Mike, Ganesh and I versus Reinaldo, Kevin > > > a version 2 of the IPFIX protocol could investigate the needs of in-band > > > configuration > > > - no transport negotiation (which transport) > > > - no capability negotiation > > > > > > But the decisions about the last 2 bullets are still under discussion. These are > > > the 2 next big points the group has to agree on. > > > > I agree to your points. However I don't think that these are requirements for > > IP flow information export and thus they don't belong into the draft. > > Someone please correct me if I'm wrong but the requirement draft is, not only what > is required in the IPFIX protocol but also the scope of IPFIX protocol proposal. > This is the reason why I wanted to add the IPFIX the big principles, to limit the scope > of what will propose in IPFIX. In priciple if have no problems with your proposal if there is wg consensus on it. But if we extend the scope of the draft as you propose it must be made very clear e.g. by adding some words to section 1. I assume you envision an additional section for defining the scope of the protocol? > Any other thought? > > > > > > > > 6. I would remove the remotely from sectiont 6., this could be confusing. > > > The measuring device MUST provide a way of configuring the traffic > > > measurement and the traffic data export remotely. > > > > Why is that confusing? > > What does the remotely refer to? > - The way of configuring traffic measurement. Then I disagree > because the exporter configuration should be out of the scope of IPFIX > - The traffic data export. Then remotely is implicit It refers to configuration. If configuration will be declared out of scope then I agree to remove it. > Regards, Benoit Sebastian > > > > > > Cheers, > > > > Sebastian > > > > > > > > > > > > > > Cheers, > > > > > > > > Juergen > > > > -- > > > > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > > > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > > > > > 1. insert new section "2. Terminology" > > > > > > > > 2. Make section "1.1 IP Flows" new section "2.1. IP Traffic > > > > Flows or Flows" > > > > > > - Maybe the flow definition will have to be adapted. > > > See our terminology thread. > > > - The observation point definition should be removed from there. > > > > > > > > > > > > > > > 3. Add sections 2.2 to 2.8: > > > > > > Sure we will have to insert the definitions but there are still under discussion. > > > > > > > > > > > 2.2. Observation Point > > > > The observation point is a location in the network > > > > where IP packets can be observed. Examples are a line > > > > to which a probe is attached, a shared medium, such as > > > > an Ethernet-based LAN, a port of a router, or an > > > > entire router with several ports. > > > > > > > > 2.3. Trafic Flow Meter or Meter > > > > A meter observes packets at one or more obsrvation > > > > points. It analyzes the content of the packets and maps > > > > them to flows. For each observed flow the meter computes > > > > statistics and maintains a flow record where it stores > > > > relevant flow infromation. > > > > > > > > 2.4. Metering Process > > > > The metering process includes all actions performed by a > > > > meter with respect to observing packets, timestamping > > > > them, analyzing them, mapping them to flows, computing > > > > flow statistics, detecting flow expiration, and > > > > maintaining flow records. > > > > > > > > 2.5. Flow Record > > > > A flow record keeps information a flow including > > > > characteristic properties of the flow, for example the > > > > source IP address, and measured properties of the flow, > > > > for example the total number of bytes of all packets of > > > > the flow. > > > > > > > > 2.6. Flow Information Exporter or Exporter > > > > The exporter sends flow records created and maintained > > > > by one or more meters to one or more data collectors. > > > > > > > > 2.7. Flow Information Data Collector or Data Colletor > > > > The data collector receives flow records from one or > > > > more exporters. The data collector might process or > > > > store received flow record, but these actions are out > > > > of the scope of this document. > > > > > > > > 2.8. Flow Information Exort > > > > Flow information export denotes the process of > > > > transferring flow records from an exporter to a data > > > > collector. > > > > > > > > 4. Remove section 2.5 Network Surveillance > > > > > > > > 5. In section 2.6, 3rd paragraph: > > > > remove "'Heisenberg' effects," > > > > > > > > 6. In section 4.1, last sentence: > > > > replace "then it SHOULD be stored ... inaccurately." > > > > by "then the measuring device MUST be able to detect > > > > this failure and to report about it." > > > > > > > > 7. Replace section "4.2 Sampling" by section "4.2 Overload > > > > Behavior": > > > > > > I tend to disagree. > > > The metering can do sampling versus full > > > And in case of overload, the metering process might switch to sampling. > > > These are 2 different topics. > > > If you want to keep overload behavior, here is what I can propose: > > > > > > 4.2. Sampling > > > > > > The measuring device MAY support measuring traffic by packet > > > sampling. If sampling is supported the sampling method and its > > > parameters MUST be well defined. > > > > > > 4.2.1 Overload Behavior > > > > > > In case of an overload, e. g. lack of memory or > > > processing power, the measuring device MAY change the > > > metering process in order to cope with the lack of > > > resources. Possible reactions include: > > > > > > - Reduce the number of flow accounts. This can be > > > achieved by more coarse grained flow measurement or > > > by a restriction of the flow accounts to a subset of > > > the set of original ones. > > > - Sample packets before they are processed by the meter. > > > - Stop metering. > > > > > > Overload behavior is not restricted to the three options > > > listed above. But in any case, the overload behavior > > > MUST be clearly defined. For example in case of sampling, > > > the sampling method and all its parameters MUST be known > > > or indicated. > > > > > > > > > > > > > > > 8. Append to section "4.3 Timestamps" > > > > Also in case of a switch to overload behavior, a > > > > timestap MUST be generated for this event as well as for > > > > a switch back to regular behavior. > > > > > > I'm not too sure what you mean. > > > > > > That's it for now. > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > > > > > > > 9. Change section 5.3.1. "Congestion Awareness" to > > > > "Congestion-Friendlyness" > > > > Replace text of subsection by "For the flow information > > > > export a congestion-friendly protocol MUST be supported." > > > > > > > > 10. Insert new section 5.3.3 Robustness > > > > Data transfer SHOULD be robust against network and > > > > system fault conditions. Robustness may be supported for > > > > example by > > > > - flow control > > > > - by deploying redundant data receiving systems > > > > - fail-over/fail-back procedures. > > > > However, robustness should not be traded with > > > > congestion-friendlyness which has higher priority. > > > > > > > > 11. Update reference [MIDBOXTAX] which is now updated to > > > > version -03. > > > > > > > > 12. Remove all entries for network surveillance from table > > > > in Appendix > > > > > > > > 13. Update Table in appendix according to changes in text. > > > > > > > > -- > > > > 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/ > > > > > > -- > > > 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/ > > > > -- > > Sebastian Zander E-mail: zander@fokus.fhg.de > > FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > > D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > > -- > 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/ -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Feb 13 07:52:00 2002 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 HAA29950 for ; Wed, 13 Feb 2002 07:51:59 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ayYu-0007jy-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 06:31:00 -0600 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ayYr-0007iw-00; Wed, 13 Feb 2002 06:30:57 -0600 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g1DCVIj40985; Wed, 13 Feb 2002 13:31:18 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 36142C040; Wed, 13 Feb 2002 13:30:25 +0100 (CET) To: calato@riverstonenet.com Subject: [ipfix-data] Re: [ipfix] Draft updates - Comments on the data model Message-ID: <1013603425.3c6a5c6123715@citadel.mobility.ccrle.nec.de> Date: Wed, 13 Feb 2002 13:30:25 +0100 (CET) From: quittek@ccrle.nec.de Cc: Juergen Quittek , Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data References: <4204037903.1013521352@[192.168.102.164]> <3C694B02.F6BBD5F2@riverstonenet.com> In-Reply-To: <3C694B02.F6BBD5F2@riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Hi Paul, calato@riverstonenet.com wrote: > > Comments in-line... > > Juergen Quittek wrote: > > > > --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > > > > > > > > Comments: > > > > > > First ol all, would you guys mind if I rewrite this whole > > > section using the words "private side" and "public side" so > > > we align our nomenclature to RFC2663? > > > > Why risking further inconsistencies? Just refer to RFC 2663. > > All you want to introduce is well explained there. > > > > > > > > Also, the subsection titles refer to "virtual" this and that, > > > but the IEs refer to "outside" and "inside". So, we need some > > > unified terminology. I also think that using inside and outside > > > can cause confusion since the exporter/collector does not know > > > what's inside and outside. See > draft-iab-unsaf-considerations-01.html > > > > I still have problems with "virtual", "inside", and "outside". > > This applies to firewalls and IPv4 NATs, but not to several other > > boxes. Why not using more general terms, such as "received" and > > "transmitted" or "original" and "modified". These terms would > > apply to a wider range of boxes (what is "inside" for a NAT-PT?). > > > > This would make the draft more independent from certain NAT/firewall > > scenarios and would be understandable even for people who do not care > > about NAT issues at all. > > I thought I addressed this already buit let me try > again. BTW - I believe this my proposal is not > at all specific to NAT/firewall. Maybe an example is > the best way to explain it. Using your terminology it > looks like this > > Flow on the way out... > > C -> IP-R gets translated to C -> IP-A > > Gets reported as > > Src = C > Dest-Received = IP-O > Dest-Transmitted = IP-A > > On the way back > > IP-A -> C gets translated to IP-O -> C > > Gets Reported as > > Src-Received = IP-A > Src-Transmitted = IP-O > Dest = C For several NATs you will even get both addresses tranlated: C' <-> A' translated to C* <-> A* with primed addresses valid in one address realm and stared addresses in the other. Then you get Src-Received = C' Src-Transmitted = C* Dest-Received = A' Dest-Transmitted = A* for one direction and Src-Received = A* Src-Transmitted = A' Dest-Received = C* Dest-Transmitted = C' for the other one. How about identifying Src-Received with Src and Dest-Received with Dest? This would look like Src = C' Src-Transmitted = C* Dest = A' Dest-Transmitted = A* for one direction and Src = A* Src-Transmitted = A' Dest = C* Dest-Transmitted = C' for the other one. > > > > Now suppose I want to find all the flows to and from > my virtual IP. First I need a list of virtual IP's so > I can find them. Then I need to search both the received > and transmitted fields for both Src and Dest. It can be > done but it can also be easier (maybe not easier for > the IPFIX protocol but that's not what we're here for). > > If reported as I proposed it looks like this... > > > > Src = C > Dest-virtual = IP-O > Dest-Actual = IP-A > > Src-virtual = IP-O > Src-Actal = IP-A > Dest = C > > Now if I want to see all the traffic for my > virtual IP's I just look for flows that have > the same src or dest virtual address. I don't > need a list and the query is simple. Also, the > data in the fields is clear. The actual field > is where the packet actually came from or > went to. The virtual is the requested source > or destination. Are you suggesting to have Src, Src-received, Src-Transmitted, Src-Virtual, Src-Actual as five different IE identifiers? This seems to be overloaded. Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Feb 13 07:56:09 2002 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 HAA00040 for ; Wed, 13 Feb 2002 07:56:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ayja-0000Cw-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 06:42:02 -0600 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ayjW-0000Bv-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 06:41:59 -0600 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g1DCgKj41021; Wed, 13 Feb 2002 13:42:20 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 854B9C040; Wed, 13 Feb 2002 13:41:27 +0100 (CET) To: "K.C. Norseth" Subject: Re: [ipfix] Configuration & MIBS Message-ID: <1013604087.3c6a5ef7766ac@citadel.mobility.ccrle.nec.de> Date: Wed, 13 Feb 2002 13:41:27 +0100 (CET) From: quittek@ccrle.nec.de Cc: ipfix@net.doit.wisc.edu References: <018c01c1b456$f32bb6c0$850f880a@slc252750> In-Reply-To: <018c01c1b456$f32bb6c0$850f880a@slc252750> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Hi KC, Thanks for putting emphasis on the issue. My position is the following: A MIB for configuring the Meter/exporter would be a useful thing, although MIBs are probably more often used for monitoring than for configuration. Maybe this MIB could also be used to monitor configuration and operation of the meter/exporter. But I do not believe, that we need another MIB for reading metered data. The Meter MIB is defined and should serve this purpose sufficiently. However, all of these issues should be discussed when our working group is close to finishing its current tasks. When we have stable versions of all our planned documents, we can discuss with our AD about re-chartering ideas. Maybe our view of MIB or other configuration requirements have developed further until then. Best wishes, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de "K.C. Norseth" wrote: > Answer to the recent comments on the Architecture DraftAn email from > Mike Mcfadden and Dave Harrington brought up the issues of mibs and > management. As Dave explained itt, it is almost expected that a mib be > written as part of the WG for configuration of basic objects and > monitoring. This is not in the charter, but we need to think about > this. How much could the RTFM mibs be used? Would a config mib and a > monitoring mib be useful? > > What do people say? This does not have to be answered as part of our > work here, but it should be addressed at least in Minneapolis. ( I have > my absestos suit on now). > > > K.C. > ----- Original Message ----- > From: Kevin Zhang > To: will@cisco.com ; Reinaldo Penno ; K.C. Norseth ; > ipfix@net.doit.wisc.edu > Sent: Tuesday, February 12, 2002 8:19 AM > Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent > comments on the Architecture Draft) > > > Hi All, > > My views on the points raised by Will - > > The exporter configuration might be outside the scope of IPFIX; > however, a negotiation process that allows the exporter and collector to > sync on a protocol and information model is the best way to achieve > interoperability and satisfy application requirements in the meantime; > It is within the scope of the IPFIX WG. Furthermore, a probe can be an > exporter that has far more monitoring/metering flexibility. By > insisting on a rigid design, we are excluding an important segment of > IPFIX users. > > With regard to underlying transport, it was mentioned explicitly in > our charter that the transport protocol has to be congestion aware. I > do believe there are situations that UDP might be used when it does not > interfere other traffic (such as over LAN, see the architecture draft). > If transport layer can be negotiated (in-band or out-band), we can > accommodate both reliable and unreliable transport protocols. > > Thanks, > > Kevin > > > > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On > Behalf Of Will Eatherton > Sent: Tuesday, February 12, 2002 12:37 AM > To: Reinaldo Penno; K.C. Norseth; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent > comments on the Architecture Draft) > > > Lets be more clear cut then this. I dont want to have a major > architectural SHOULD on something we believe is fundamentally flawed and > will occupy signficant group time to spec if it is left in. We need a > clear decision to move forward. A spec that includes SHOULDS for all > proposed features is weak. > > WIll > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno > Sent: Monday, February 11, 2002 8:57 PM > To: K.C. Norseth; will@cisco.com; ipfix@net.doit.wisc.edu > Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the > recent comments on the Architecture Draft) > > > Hello Norseth, > > I think the right question to answer is not if it is > "necessary", since you can always pay somebody to be some sort of CLI > configuration master and do everything by hand. > I think the right question is if it should be on the > architecture document or not and with whihch level of compliance. > > I think it should be on the arch document and maybe putting it > with a SHOULD instead of a MUST will make (most) people happy. > > cheers, > > Reinaldo > > > -----Original Message----- > From: K.C. Norseth [mailto:kcn@norseth.com] > Sent: Monday, February 11, 2002 8:25 PM > To: will@cisco.com; ipfix@net.doit.wisc.edu > Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent > comments on the Architecture Draft) > > > Will, > > I agree. Let's go for the wg concensus. What do people say? > > | - the exporter configuration is out of the scope of this > document (the exporter configuration out of band) > > Configuration I think is out of scope, unless we hook it to an > existing mib or something. I so, we can refer to that mib or process. > |- no transport negotiation (which transport) > > we need to define the action of each transport type. > > | - no capability negotiation > > Nice, but necessary? > > > K.C. > ----- Original Message ----- > From: Will Eatherton > To: Reinaldo Penno ; ipfix-arch@net.doit.wisc.edu ; > ipfix-arch-volunteers@net.doit.wisc.edu > Cc: quittek@ccrle.nec.de ; knorseth@enterasys.com ; > plonka@doit.wisc.edu > Sent: Monday, February 11, 2002 8:24 AM > Subject: Scope of IPFIX (was Answer to the recent comments > on the Architecture Draft) > > > Group, > > Cisco's interest in IPFIX was to help establish a > non-proprietary protocol similar to netflow but more flexible allowing > us to add value to our customers (and do so in a timely manner). If > IPFIX goes down a path along the lines as being advocated recent threads > by Reinaldo, it is unclear if the added burden of the protocol will be > make it worth the benefits of a non-proprietary protocol. Given it > seems I have seen roughly the same conversation occur 3 times in past > several day, It is unclear if further email discussion on this topic > will resolve the underlying question as to the scope of IPFIX. It seems > time for an official call on what is in/out of scope for IPFIX. As has > been mentioned here multiple times we would like to hear : > - the exporter configuration is out of the scope of this > document (the exporter configuration out of band) > > - no transport negotiation (which transport) > > - no capability negotiation > > Will > > :So lets have a protocol which is more flexible as NetFlow > version > :1-7, > > I will not comment on that too much...Basically we are not > here to reverse-engineer Netflow, but to incorporate some good ideas > from it. > > :but not much more complicated, in order to be > successfully > :accepted by hardware vendors and application programmers. > > > ohh, please...Then Netflow is just right? > > Reinaldo > > > > > > > > -- 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 Feb 13 08:10:53 2002 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 IAA00371 for ; Wed, 13 Feb 2002 08:10:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16aytR-0000MC-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 06:52:13 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16aytP-0000Lf-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 06:52:11 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZB6W; Wed, 13 Feb 2002 04:50:58 -0800 Message-ID: <3C6A6130.F488BD5F@riverstonenet.com> Date: Wed, 13 Feb 2002 07:50:56 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "K.C. Norseth" CC: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: [ipfix-data] Data Doc References: <3C695880.69C2A4FB@riverstonenet.com> <3C695D44.40D5A338@riverstonenet.com> <028801c1b461$88c7afe0$850f880a@slc252750> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Comments inline. "K.C. Norseth" wrote: > > Paul, > > Where there is some elements that need to be fleshed out, it would be great > to see them expanded/explained. > > Comments inline. > > ----- Original Message ----- > From: > To: Norseth, KC ; data > > Sent: Tuesday, February 12, 2002 11:21 AM > Subject: [ipfix-data] Data Doc > > | KC, here are a bunch of edits. If you want, > | send me the source and I'll take editor > | responsibilties for it. > | > | Paul > | > | calato@riverstonenet.com wrote: > | > > > > | > 4. Information Model > | > > | > | Delete Start > | ============ > | > | > I think we need to begin with a couple of guidlines (which > | > we should augment as we go). They are just guidelines. > | > > | > 1. Data element values should be defined in terms of other > | > specifications. Since we are only reporting things in other protocols, > | > there should be little reason for us to define anything from scatch. > | > > | > 2. Each element should be able to be interpreted on it own. In other > | > words, don't make me look though the rest of the message to figure out > | > what this value means. The drawback is this can lead to data element > | > explosion. We'll have to balance the tradeoffs. > | > > | > 3. Others? > | > | Delete End > | =========== > | > | Those were just my comments. I don't think they belong > | in the document. > > Ok. There are other personal observations and comments still embedded in > noth texts. > > | > | > > | > The IPFIX information model is listed in the IPFIX requirement > | > document. The information model consists of the minimum set of > | > attributes that an IPFIX exporting device should be able to export. In > | > conjunction with IP flow definitions, they provide locally accurate > | > information about a flow. > | > | I do not think it is the minimum set. It is the full > | set to this point in time. We need to define the full > | set in order to get interoperabiltity. Vendors defining > | their own fields should be the exception rather than the > | rule. > > Is taking out MINIMUM enough? also replace "should" with "may"... "exporting device may be able to export" There may actaully be a minimum set which we can identify. We can mark such attributes in the doc at some point. That would help interoperability. > > > | > > | > 4.2. Attributes Related to Measurement > | > > | > The following attributes relates to measurements and measuring > | > methodology: > | > o Packet Counter > | > o Dropped Packet Counter > | > o Payload Byte Counter > | > | What is this?? > > Byte conter - It does sound funny. I will remove payload. This area is a > cut and paste from Benoit/Ganesh. This area could be clarified and cleaned > up. > | > | > o Timestamp of the First Packet Observed > | > o Timestamp of the Last Packet Observed > | > o Timeout Indication > | > o Sampling Method > | > o Sampling Parameters > | > > | > 4.3. Attributes Related to Flow Definition > | > > | > The following attributes relates to IP flow definitions. > | > > | > o Incoming Interface > | > o Outgoing Interface > | > o Packet Treatment > | > o Unique ID of the Observation Point > | > o Unique ID of the Measuring Device > | > > | > 4.4. Attributes related to Upper Layers > | > > | > The following attributes provides information of upper layer protocols. > | > o Source Port Address > | > o MPLS Label (if MPLS is supported) > | > | Just a nit but MPLS is actaually a lower layer. > | > | > | Where are derived things like AS number? > > Ok. Clipped from Benoit/Ganesh. Can be cleaned up. Got some better wording? Maybe "above and below the IP layer". I think stuff like interface, etc... can go here since the interface is kind of the lowest layer. > > | > > | > 4.5. IPFIX Template > | > > | > The IPFIX system MUST support efficient exporting of IP flow > | > information. This can be achieved by negotiating a set of IPFIX > | > Templates for an IPFIX session before actual IP flow information is > | > exported. A template defines the structure of an IPFIX user message > | > payload by describing the data type, meaning, and location of the fields > | > in the payload. By agreeing on IPFIX templates, IPFIX end-points > | > understand how to process IPFIX user messages. As a result, an exporting > | > device only needs to export actual flow information without attaching > | > any descriptors of the attributes; this reduces the amount of bytes sent > | > over communication links. > | > > | > A template is an ordered list of keys. A key specifies an attribute that > | > a meter entity MAY export. The specification MUST consist of the > | > description and the data type of the attribute. (e.g. 'Number of Sent > | > Bytes' can be a key that is an 32 bit unsigned integer) An exporting > | > device typically defines keys. Based on the IPFIX information model, a > | > set of IPFIX standard keys can be defined. > | > > | > 4.5.1. Template Negotiation > | > > | > During the initial setup of an IPFIX session, template negotiation > | > procedures should be carried out. It would allow all the IPFIX > | > end-points to synchronize on a set of templates that will be used during > | > IP flow information export. > | > | > | I assume a lot more discussion needs to happen here. > > Yes. This needs to be worked out more. > > | > > | > 5. Information Elements > | > 5.1. Packet Management > | > > | > This information contains the fields needed to manage the data packets > | > transmitted > | > > | > 5.1.1. Version Number > | > > | > [Need to expand more] > | > | If this is IPFIX protocol version, it does not > | belong here. > > I think we need to worry about a verions number. If not here, where? When we get to actually selecting a protocol we need to make sure it is there. Perhaps it goes in the requirements doc. > | > | > > | > 5.1.2. FLOWS > | > V#3 S#4 > | > Number of main cache flows > | > | What is this??? > > I saw this is as a flow counter in the header. This came from > Beniot/Ganesh. It needs to be clarified. > > What I did was to go thgough Benoit & Ganeshs' document and add elements > that we seemed to be missing in our doc.. Unfortunatly, some of these do > not explein themselves well. I hope we can either flesh them out and give > the same look and feel, or drop them if not needed. I would leave it out until someone gives a good reason for it to be in. > > | > > | > 5.1.3. FLOW_LABEL > | > V#31 S#2 > | > IPV6 Flow Label > | > [Need to expand more] > | > > | > | Delete, already covered below in more detail. > > Ok. > > | > > | > | > | Start delete > | ============ > | > | > 5.12. NAT > | > 5.12.1. INSIDE_L4_SRC > | > V#42 S#2 > | > > | > NAT port number (.e.g, FTP, Telnet, etc...) only applicable with NAT > | > > | > 5.12.2. INSIDE_IPV4_SRC_ADDR > | > V#43 S#4 > | > Source IPv4 Address only applicable with NAT TCP/UDP destination port > | > > | > 5.12.3. INSIDE_L4_DST_PORT > | > V#44 S#2 > | > The number (.e.g, FTP, telnet etc...) only applicable with NAT > | > > | > 5.12.4. INSIDE_IPV4_DST_ADDR > | > V#45 S#4 > | > Destination IPv4 Address only applicable with NAT > | > > | > 5.12.5. INSIDE_IPV6_SRC_ADDR > | > V#46 S#16 > | > IPv6 Source Address only applicable with NAT > | > > | > 5.12.6. INSIDE_IPV6_DST_ADDR > | > V#47 #16 > | > IPv6 Destination Address only applicable with NAT > | > > | > 5.12.7. OUTSIDE_L4_SRC_PORT > | > V#48 S#2 > | > TCP/UDP destination port number (.e.g, FTP, Telnet, etc...) only > | > applicable with NAT > | > > | > 5.12.8. OUTSIDE_IPV4_SRC_ADDR > | > V#49 S#4 > | > Source IPv4 Address only applicable with NAT TCP/UDP destination port > | > > | > 5.12.9. OUTSIDE_L4_DST_PORT > | > V#50 S#2 > | > number (.e.g, FTP, Telnet, etc...) only applicable with NAT > | > > | > 5.12.10. OUTSIDE_IPV4_DST_ADDR > | > V#51 S#4 > | > Destination IPv4 Address only applicable with NAT > | > > | > 5.12.11. OUTSIDE_IPV6_SRC_ADDR > | > V#52 S#16 > | > IPv6 Source Address only applicable with NAT > | > > | > 5.12.12. OUTSIDE_IPV6_DST_ADDR > | > V#53 S#16 > | > IPv6 Destination Address only applicable with NAT > | > > | > | > | Delete ENd > | ========== > | > | Already covered above in more detail above. > | Even if we disagree on the exact text, this > | stuyff is duplicate. > > Ok, Gone. > > > 5.13. Vendor Specific IE > > | > > | > 5.14.6. IPM_DPKTS > | > V#19 S#4 > | > Packet count for IP Multicast > | > > | > 5.14.7. IPM_DOCTETS > | > V#20 S#4 > | > Octet (byte) count for IP Multicast > | > | IPM_DPKTS and IPM_DOCTETS should be moved to where > | the other counts are. > > Moved to counters. Still need to be fleshed out. > > | > > | > 5.14.8. LAST_SWITCHED > | > V#21 S#4 > | > SysUptime at which the last packet of this flow was switched > | > > | > 5.14.9. FIRST_SWITCHED > | > V#22 S#4 > | > SysUptime at which the first packet of this flow was switched > | > [Need to expand more] > | > > | > | Move these with the other timestamp info, > | I'll work on combining. > > Ok. > > | > 5.14.10. MAC_ADDR > | > V#25 S#6 > | > Layer 2 Media Access Control address associated with a flow > | > > | > | Delete. Already covered under the address stuff. > > Ok. I keep thining only IP when I think of address. this is an address and > both can be on a record. Right. Depending on how we encode the address IE it can either be very flexible or rigid. If it is rigid, we'll need an IE for each address type. But we can get to those details later. > > | > | > 5.14.11. VLAN_ID > | > V#26 S#2 > | > Virtual LAN identifier associated with a flow > | > | Delete. already covered in more detail. > > Ok. > > | > > | > 5.14.12. ICMP_TYPE > | > V#32 S#1 > | > ICMP Packet Type. This is reported as (ICMP Type * 256) + ICMP code > | > | > | We need a spec reference. > > Yes. Copied from Benoit/Ganesh. > | > > | > 5.14.13. IGMP_TYPE > | > V#33 S#1 > | > IGMP Packet Type > | > | > | we need a spec reference. > > Ditto. > > | > > | > 5.15. Sampling > | > > | > 5.15.1. SAMPLING_INTERVAL > | > V#34 S#1 > | > When using Sampling, the rate at which packets are sampled. For > | > example, a value of 100 indicates that one of every hundred packets is > | > sampled. > | > > | > 5.15.2. SAMPLING_ALGO > | > V#35 S#1 > | > The type of algorithm used for sampling > | > data. Currently, the only > | > sampling algorithm defined is: > | > 0x02 packet-sampling > | > > | > 5.15.3. FLOW_ACTIVE_TIMEOUT > | > V#36 S#2 > | > Timeout value for active flow entries in the cache. > | > > | > 5.15.4. FLOW_INACTIVE_TIMEOUT > | > V#37 S#2 > | > Timeout value for inactive flow entries in the cache. > | > > > > K.C. -- 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 Feb 13 08:11:03 2002 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 IAA00390 for ; Wed, 13 Feb 2002 08:11:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ayxF-0000Qo-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 06:56:09 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ayxD-0000Q2-00; Wed, 13 Feb 2002 06:56:07 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZB7G; Wed, 13 Feb 2002 04:54:54 -0800 Message-ID: <3C6A621D.3263D19B@riverstonenet.com> Date: Wed, 13 Feb 2002 07:54:53 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: quittek@ccrle.nec.de CC: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: [ipfix-data] Re: [ipfix] Draft updates - Comments on the data model References: <4204037903.1013521352@[192.168.102.164]> <3C694B02.F6BBD5F2@riverstonenet.com> <1013603425.3c6a5c6123715@citadel.mobility.ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit quittek@ccrle.nec.de wrote: > > Hi Paul, > > calato@riverstonenet.com wrote: > > > > > Comments in-line... > > > > Juergen Quittek wrote: > > > > > > --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > > > > > > > > > > > Comments: > > > > > > > > First ol all, would you guys mind if I rewrite this whole > > > > section using the words "private side" and "public side" so > > > > we align our nomenclature to RFC2663? > > > > > > Why risking further inconsistencies? Just refer to RFC 2663. > > > All you want to introduce is well explained there. > > > > > > > > > > > Also, the subsection titles refer to "virtual" this and that, > > > > but the IEs refer to "outside" and "inside". So, we need some > > > > unified terminology. I also think that using inside and outside > > > > can cause confusion since the exporter/collector does not know > > > > what's inside and outside. See > > draft-iab-unsaf-considerations-01.html > > > > > > I still have problems with "virtual", "inside", and "outside". > > > This applies to firewalls and IPv4 NATs, but not to several other > > > boxes. Why not using more general terms, such as "received" and > > > "transmitted" or "original" and "modified". These terms would > > > apply to a wider range of boxes (what is "inside" for a NAT-PT?). > > > > > > This would make the draft more independent from certain NAT/firewall > > > scenarios and would be understandable even for people who do not care > > > about NAT issues at all. > > > > I thought I addressed this already buit let me try > > again. BTW - I believe this my proposal is not > > at all specific to NAT/firewall. Maybe an example is > > the best way to explain it. Using your terminology it > > looks like this > > > > Flow on the way out... > > > > C -> IP-R gets translated to C -> IP-A > > > > Gets reported as > > > > Src = C > > Dest-Received = IP-O > > Dest-Transmitted = IP-A > > > > On the way back > > > > IP-A -> C gets translated to IP-O -> C > > > > Gets Reported as > > > > Src-Received = IP-A > > Src-Transmitted = IP-O > > Dest = C > > For several NATs you will even get both addresses tranlated: > > C' <-> A' translated to C* <-> A* > > with primed addresses valid in one address realm and stared addresses > in the other. > > Then you get > > Src-Received = C' > Src-Transmitted = C* > Dest-Received = A' > Dest-Transmitted = A* > > for one direction and > > Src-Received = A* > Src-Transmitted = A' > Dest-Received = C* > Dest-Transmitted = C' > > for the other one. How about identifying Src-Received with Src > and Dest-Received with Dest? This would look like > > Src = C' > Src-Transmitted = C* > Dest = A' > Dest-Transmitted = A* > > for one direction and > > Src = A* > Src-Transmitted = A' > Dest = C* > Dest-Transmitted = C' > > for the other one. > > > > > > > > > Now suppose I want to find all the flows to and from > > my virtual IP. First I need a list of virtual IP's so > > I can find them. Then I need to search both the received > > and transmitted fields for both Src and Dest. It can be > > done but it can also be easier (maybe not easier for > > the IPFIX protocol but that's not what we're here for). > > > > If reported as I proposed it looks like this... > > > > > > > > Src = C > > Dest-virtual = IP-O > > Dest-Actual = IP-A > > > > Src-virtual = IP-O > > Src-Actal = IP-A > > Dest = C > > > > Now if I want to see all the traffic for my > > virtual IP's I just look for flows that have > > the same src or dest virtual address. I don't > > need a list and the query is simple. Also, the > > data in the fields is clear. The actual field > > is where the packet actually came from or > > went to. The virtual is the requested source > > or destination. > > Are you suggesting to have Src, Src-received, Src-Transmitted, > Src-Virtual, Src-Actual as five different IE identifiers? > This seems to be overloaded. No, we only need actual and virtual for both source and destination. Not sure if there is a better word for virtual but it is all I could come up with. It just indicates the address is not where the packet really went to or came from. I thought virtual worked, but I'm open to others. > > Cheers, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Feb 13 08:11:14 2002 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 IAA00402 for ; Wed, 13 Feb 2002 08:11:14 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ayur-0000O4-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 06:53:41 -0600 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ayYr-0007iw-00; Wed, 13 Feb 2002 06:30:57 -0600 Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id g1DCVIj40985; Wed, 13 Feb 2002 13:31:18 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 36142C040; Wed, 13 Feb 2002 13:30:25 +0100 (CET) To: calato@riverstonenet.com Subject: Re: [ipfix] Draft updates - Comments on the data model Message-ID: <1013603425.3c6a5c6123715@citadel.mobility.ccrle.nec.de> Date: Wed, 13 Feb 2002 13:30:25 +0100 (CET) From: quittek@ccrle.nec.de Cc: Juergen Quittek , Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data References: <4204037903.1013521352@[192.168.102.164]> <3C694B02.F6BBD5F2@riverstonenet.com> In-Reply-To: <3C694B02.F6BBD5F2@riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Hi Paul, calato@riverstonenet.com wrote: > > Comments in-line... > > Juergen Quittek wrote: > > > > --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > > > > > > > > Comments: > > > > > > First ol all, would you guys mind if I rewrite this whole > > > section using the words "private side" and "public side" so > > > we align our nomenclature to RFC2663? > > > > Why risking further inconsistencies? Just refer to RFC 2663. > > All you want to introduce is well explained there. > > > > > > > > Also, the subsection titles refer to "virtual" this and that, > > > but the IEs refer to "outside" and "inside". So, we need some > > > unified terminology. I also think that using inside and outside > > > can cause confusion since the exporter/collector does not know > > > what's inside and outside. See > draft-iab-unsaf-considerations-01.html > > > > I still have problems with "virtual", "inside", and "outside". > > This applies to firewalls and IPv4 NATs, but not to several other > > boxes. Why not using more general terms, such as "received" and > > "transmitted" or "original" and "modified". These terms would > > apply to a wider range of boxes (what is "inside" for a NAT-PT?). > > > > This would make the draft more independent from certain NAT/firewall > > scenarios and would be understandable even for people who do not care > > about NAT issues at all. > > I thought I addressed this already buit let me try > again. BTW - I believe this my proposal is not > at all specific to NAT/firewall. Maybe an example is > the best way to explain it. Using your terminology it > looks like this > > Flow on the way out... > > C -> IP-R gets translated to C -> IP-A > > Gets reported as > > Src = C > Dest-Received = IP-O > Dest-Transmitted = IP-A > > On the way back > > IP-A -> C gets translated to IP-O -> C > > Gets Reported as > > Src-Received = IP-A > Src-Transmitted = IP-O > Dest = C For several NATs you will even get both addresses tranlated: C' <-> A' translated to C* <-> A* with primed addresses valid in one address realm and stared addresses in the other. Then you get Src-Received = C' Src-Transmitted = C* Dest-Received = A' Dest-Transmitted = A* for one direction and Src-Received = A* Src-Transmitted = A' Dest-Received = C* Dest-Transmitted = C' for the other one. How about identifying Src-Received with Src and Dest-Received with Dest? This would look like Src = C' Src-Transmitted = C* Dest = A' Dest-Transmitted = A* for one direction and Src = A* Src-Transmitted = A' Dest = C* Dest-Transmitted = C' for the other one. > > > > Now suppose I want to find all the flows to and from > my virtual IP. First I need a list of virtual IP's so > I can find them. Then I need to search both the received > and transmitted fields for both Src and Dest. It can be > done but it can also be easier (maybe not easier for > the IPFIX protocol but that's not what we're here for). > > If reported as I proposed it looks like this... > > > > Src = C > Dest-virtual = IP-O > Dest-Actual = IP-A > > Src-virtual = IP-O > Src-Actal = IP-A > Dest = C > > Now if I want to see all the traffic for my > virtual IP's I just look for flows that have > the same src or dest virtual address. I don't > need a list and the query is simple. Also, the > data in the fields is clear. The actual field > is where the packet actually came from or > went to. The virtual is the requested source > or destination. Are you suggesting to have Src, Src-received, Src-Transmitted, Src-Virtual, Src-Actual as five different IE identifiers? This seems to be overloaded. Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Feb 13 08:27:10 2002 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 IAA00814 for ; Wed, 13 Feb 2002 08:27:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16azDD-0000rE-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 07:12:39 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ayxD-0000Q2-00; Wed, 13 Feb 2002 06:56:07 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZB7G; Wed, 13 Feb 2002 04:54:54 -0800 Message-ID: <3C6A621D.3263D19B@riverstonenet.com> Date: Wed, 13 Feb 2002 07:54:53 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: quittek@ccrle.nec.de CC: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: Re: [ipfix] Draft updates - Comments on the data model References: <4204037903.1013521352@[192.168.102.164]> <3C694B02.F6BBD5F2@riverstonenet.com> <1013603425.3c6a5c6123715@citadel.mobility.ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit quittek@ccrle.nec.de wrote: > > Hi Paul, > > calato@riverstonenet.com wrote: > > > > > Comments in-line... > > > > Juergen Quittek wrote: > > > > > > --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > > > > > > > > > > > Comments: > > > > > > > > First ol all, would you guys mind if I rewrite this whole > > > > section using the words "private side" and "public side" so > > > > we align our nomenclature to RFC2663? > > > > > > Why risking further inconsistencies? Just refer to RFC 2663. > > > All you want to introduce is well explained there. > > > > > > > > > > > Also, the subsection titles refer to "virtual" this and that, > > > > but the IEs refer to "outside" and "inside". So, we need some > > > > unified terminology. I also think that using inside and outside > > > > can cause confusion since the exporter/collector does not know > > > > what's inside and outside. See > > draft-iab-unsaf-considerations-01.html > > > > > > I still have problems with "virtual", "inside", and "outside". > > > This applies to firewalls and IPv4 NATs, but not to several other > > > boxes. Why not using more general terms, such as "received" and > > > "transmitted" or "original" and "modified". These terms would > > > apply to a wider range of boxes (what is "inside" for a NAT-PT?). > > > > > > This would make the draft more independent from certain NAT/firewall > > > scenarios and would be understandable even for people who do not care > > > about NAT issues at all. > > > > I thought I addressed this already buit let me try > > again. BTW - I believe this my proposal is not > > at all specific to NAT/firewall. Maybe an example is > > the best way to explain it. Using your terminology it > > looks like this > > > > Flow on the way out... > > > > C -> IP-R gets translated to C -> IP-A > > > > Gets reported as > > > > Src = C > > Dest-Received = IP-O > > Dest-Transmitted = IP-A > > > > On the way back > > > > IP-A -> C gets translated to IP-O -> C > > > > Gets Reported as > > > > Src-Received = IP-A > > Src-Transmitted = IP-O > > Dest = C > > For several NATs you will even get both addresses tranlated: > > C' <-> A' translated to C* <-> A* > > with primed addresses valid in one address realm and stared addresses > in the other. > > Then you get > > Src-Received = C' > Src-Transmitted = C* > Dest-Received = A' > Dest-Transmitted = A* > > for one direction and > > Src-Received = A* > Src-Transmitted = A' > Dest-Received = C* > Dest-Transmitted = C' > > for the other one. How about identifying Src-Received with Src > and Dest-Received with Dest? This would look like > > Src = C' > Src-Transmitted = C* > Dest = A' > Dest-Transmitted = A* > > for one direction and > > Src = A* > Src-Transmitted = A' > Dest = C* > Dest-Transmitted = C' > > for the other one. > > > > > > > > > Now suppose I want to find all the flows to and from > > my virtual IP. First I need a list of virtual IP's so > > I can find them. Then I need to search both the received > > and transmitted fields for both Src and Dest. It can be > > done but it can also be easier (maybe not easier for > > the IPFIX protocol but that's not what we're here for). > > > > If reported as I proposed it looks like this... > > > > > > > > Src = C > > Dest-virtual = IP-O > > Dest-Actual = IP-A > > > > Src-virtual = IP-O > > Src-Actal = IP-A > > Dest = C > > > > Now if I want to see all the traffic for my > > virtual IP's I just look for flows that have > > the same src or dest virtual address. I don't > > need a list and the query is simple. Also, the > > data in the fields is clear. The actual field > > is where the packet actually came from or > > went to. The virtual is the requested source > > or destination. > > Are you suggesting to have Src, Src-received, Src-Transmitted, > Src-Virtual, Src-Actual as five different IE identifiers? > This seems to be overloaded. No, we only need actual and virtual for both source and destination. Not sure if there is a better word for virtual but it is all I could come up with. It just indicates the address is not where the packet really went to or came from. I thought virtual worked, but I'm open to others. > > Cheers, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Feb 13 08:31:31 2002 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 IAA00997 for ; Wed, 13 Feb 2002 08:31:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16azH3-0000x0-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 07:16:37 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16azH1-0000wU-00 for ipfix-req@net.doit.wisc.edu; Wed, 13 Feb 2002 07:16:35 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZB93; Wed, 13 Feb 2002 05:15:22 -0800 Message-ID: <3C6A66E6.DD531EA5@riverstonenet.com> Date: Wed, 13 Feb 2002 08:15:18 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: Sebastian Zander , Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <4108689799.1013426004@[192.168.102.164]> <3C694086.5D0B0891@cisco.com> <3C6961EE.8A7BED8@fokus.fhg.de> <3C699C3A.9203D67D@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Hi Sebastian, > > [I skip the points on which we agree] > > > > > > > > 2. I think we should have statements in the requirement document about: > > > - configuration will be done out-bound > > > Note: this is at least the direction I see in the working group on that one: > > > Will, KC, Juergen, Mike, Ganesh and I versus Reinaldo, Kevin > > > a version 2 of the IPFIX protocol could investigate the needs of in-band > > > configuration > > > - no transport negotiation (which transport) > > > - no capability negotiation > > > > > > But the decisions about the last 2 bullets are still under discussion. These are > > > the 2 next big points the group has to agree on. > > > > I agree to your points. However I don't think that these are requirements for > > IP flow information export and thus they don't belong into the draft. > > Someone please correct me if I'm wrong but the requirement draft is, not only what > is required in the IPFIX protocol but also the scope of IPFIX protocol proposal. That's how I understand it. > This is the reason why I wanted to add the IPFIX the big principles, to limit the scope > > of what will propose in IPFIX. Not sure what you mean by "the big principals" but it is important to list both what you are covering and what you are intentionally not covering. Saying configuration is out-of-band and out of scope seems appropriate (assuming that is what we agree to). But even that cannot be used as the golden rule. For example, I still think configuring which fields to send should be done in band. > > Any other thought? > > > > > > > > 6. I would remove the remotely from sectiont 6., this could be confusing. > > > The measuring device MUST provide a way of configuring the traffic > > > measurement and the traffic data export remotely. > > > > Why is that confusing? > > What does the remotely refer to? > - The way of configuring traffic measurement. Then I disagree > because the exporter configuration should be out of the scope of IPFIX > - The traffic data export. Then remotely is implicit > > Regards, Benoit > > > > > > > Cheers, > > > > Sebastian > > > > > > > > > > > > > > Cheers, > > > > > > > > Juergen > > > > -- > > > > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > > > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > > > > > 1. insert new section "2. Terminology" > > > > > > > > 2. Make section "1.1 IP Flows" new section "2.1. IP Traffic > > > > Flows or Flows" > > > > > > - Maybe the flow definition will have to be adapted. > > > See our terminology thread. > > > - The observation point definition should be removed from there. > > > > > > > > > > > > > > > 3. Add sections 2.2 to 2.8: > > > > > > Sure we will have to insert the definitions but there are still under discussion. > > > > > > > > > > > 2.2. Observation Point > > > > The observation point is a location in the network > > > > where IP packets can be observed. Examples are a line > > > > to which a probe is attached, a shared medium, such as > > > > an Ethernet-based LAN, a port of a router, or an > > > > entire router with several ports. > > > > > > > > 2.3. Trafic Flow Meter or Meter > > > > A meter observes packets at one or more obsrvation > > > > points. It analyzes the content of the packets and maps > > > > them to flows. For each observed flow the meter computes > > > > statistics and maintains a flow record where it stores > > > > relevant flow infromation. > > > > > > > > 2.4. Metering Process > > > > The metering process includes all actions performed by a > > > > meter with respect to observing packets, timestamping > > > > them, analyzing them, mapping them to flows, computing > > > > flow statistics, detecting flow expiration, and > > > > maintaining flow records. > > > > > > > > 2.5. Flow Record > > > > A flow record keeps information a flow including > > > > characteristic properties of the flow, for example the > > > > source IP address, and measured properties of the flow, > > > > for example the total number of bytes of all packets of > > > > the flow. > > > > > > > > 2.6. Flow Information Exporter or Exporter > > > > The exporter sends flow records created and maintained > > > > by one or more meters to one or more data collectors. > > > > > > > > 2.7. Flow Information Data Collector or Data Colletor > > > > The data collector receives flow records from one or > > > > more exporters. The data collector might process or > > > > store received flow record, but these actions are out > > > > of the scope of this document. > > > > > > > > 2.8. Flow Information Exort > > > > Flow information export denotes the process of > > > > transferring flow records from an exporter to a data > > > > collector. > > > > > > > > 4. Remove section 2.5 Network Surveillance > > > > > > > > 5. In section 2.6, 3rd paragraph: > > > > remove "'Heisenberg' effects," > > > > > > > > 6. In section 4.1, last sentence: > > > > replace "then it SHOULD be stored ... inaccurately." > > > > by "then the measuring device MUST be able to detect > > > > this failure and to report about it." > > > > > > > > 7. Replace section "4.2 Sampling" by section "4.2 Overload > > > > Behavior": > > > > > > I tend to disagree. > > > The metering can do sampling versus full > > > And in case of overload, the metering process might switch to sampling. > > > These are 2 different topics. > > > If you want to keep overload behavior, here is what I can propose: > > > > > > 4.2. Sampling > > > > > > The measuring device MAY support measuring traffic by packet > > > sampling. If sampling is supported the sampling method and its > > > parameters MUST be well defined. > > > > > > 4.2.1 Overload Behavior > > > > > > In case of an overload, e. g. lack of memory or > > > processing power, the measuring device MAY change the > > > metering process in order to cope with the lack of > > > resources. Possible reactions include: > > > > > > - Reduce the number of flow accounts. This can be > > > achieved by more coarse grained flow measurement or > > > by a restriction of the flow accounts to a subset of > > > the set of original ones. > > > - Sample packets before they are processed by the meter. > > > - Stop metering. > > > > > > Overload behavior is not restricted to the three options > > > listed above. But in any case, the overload behavior > > > MUST be clearly defined. For example in case of sampling, > > > the sampling method and all its parameters MUST be known > > > or indicated. > > > > > > > > > > > > > > > 8. Append to section "4.3 Timestamps" > > > > Also in case of a switch to overload behavior, a > > > > timestap MUST be generated for this event as well as for > > > > a switch back to regular behavior. > > > > > > I'm not too sure what you mean. > > > > > > That's it for now. > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > > > > > > > 9. Change section 5.3.1. "Congestion Awareness" to > > > > "Congestion-Friendlyness" > > > > Replace text of subsection by "For the flow information > > > > export a congestion-friendly protocol MUST be supported." > > > > > > > > 10. Insert new section 5.3.3 Robustness > > > > Data transfer SHOULD be robust against network and > > > > system fault conditions. Robustness may be supported for > > > > example by > > > > - flow control > > > > - by deploying redundant data receiving systems > > > > - fail-over/fail-back procedures. > > > > However, robustness should not be traded with > > > > congestion-friendlyness which has higher priority. > > > > > > > > 11. Update reference [MIDBOXTAX] which is now updated to > > > > version -03. > > > > > > > > 12. Remove all entries for network surveillance from table > > > > in Appendix > > > > > > > > 13. Update Table in appendix according to changes in text. > > > > > > > > -- > > > > 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/ > > > > > > -- > > > 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/ > > > > -- > > Sebastian Zander E-mail: zander@fokus.fhg.de > > FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > > D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > > -- > 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/ -- 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 Feb 13 08:36:54 2002 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 IAA01167 for ; Wed, 13 Feb 2002 08:36:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16azMq-00013S-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 07:22:37 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16azMp-000138-00 for ipfix-arch@net.doit.wisc.edu; Wed, 13 Feb 2002 07:22:35 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZB0L; Wed, 13 Feb 2002 05:21:24 -0800 Message-ID: <3C6A6854.5FAD0F4F@riverstonenet.com> Date: Wed, 13 Feb 2002 08:21:24 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] [Fwd: [ipfix] Re: Information Model] References: <3C69A2A0.9E76F024@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit >> An implementation may choose to >> do the AS and potentially other accounting fields lookup during the export >> phase. >> > >There is the problem you mentioned above in such a case. Keep in mind that the flow key will give an indication of the affect of changes like this. FOr example, if the key is src-ip, dst-ip but the flow still reports src-AS and dst-AS the collector knows there is a possability the AS could change and no new flow would be reported. If on the other had the key was src-ip, dst-ip, src-AS, dst-AS then the collector knows that any change would create a new flow. I'm assuming here that we are not limited to only reporting atttributes in the flow key. -- 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 Feb 13 08:52:02 2002 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 IAA01446 for ; Wed, 13 Feb 2002 08:52:02 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16azZ7-0001HI-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 07:35:17 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16azZ4-0001GL-00; Wed, 13 Feb 2002 07:35:14 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZCAV; Wed, 13 Feb 2002 05:34:02 -0800 Message-ID: <3C6A6B49.2120FA9C@riverstonenet.com> Date: Wed, 13 Feb 2002 08:34:01 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, "K.C. Norseth" , ipfixx Subject: [ipfix] Re: MIDCOM first draft References: <4F973E944951D311B6660008C7917CF008A14248@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Tuesday, February 12, 2002 9:22 AM > >To: Penno, Reinaldo [SC9:T327:EXCH] > >Cc: ipfix-data-volunteers@net.doit.wisc.edu; > >ipfix-arch-volunteers@net.doit.wisc.edu; K.C. Norseth > >Subject: Re: MIDCOM first draft > > > > > >> Do you agree? > > > > Sorry for the delay. TOo many mails and not enough time :-) > > > > Depends on how the 5-tuple is reported. If done the way > > I suggested then it looks like this... (as I modified above) > > > > A <-> D > > B as virtual SRC/DST > > > > In that case the 5 touble would not change as a result of > > the translation assuming the actual address field is > > used in the 5-tuple. > > > > > > Hello Paul, > > I'll try to be more structured now. > > the way it is reported is one thing, but a NAT is by all purposes (by > definition) composed of two flows. You can export them in one record > or two records, but that doesn't change how it should be faced. > > would you agree with this? I would say no. Since a flow is defined by its key you cannot take that out of the picture. If the key is actual-src and actual-destination then there is only 1 flow and only 1 record. If the key is packet-src, packet-destination then it would be 2 flows as you suggest. > > regards, > > Reinaldo -- 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 Feb 13 09:16:04 2002 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 JAA02968 for ; Wed, 13 Feb 2002 09:16:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16azjg-0001ZJ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 07:46:12 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16azjd-0001Yq-00 for ipfix-req@net.doit.wisc.edu; Wed, 13 Feb 2002 07:46:10 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZCC1; Wed, 13 Feb 2002 05:44:58 -0800 Message-ID: <3C6A6DD9.8707F1E@riverstonenet.com> Date: Wed, 13 Feb 2002 08:44:57 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Peter_Phaal@inmon.com CC: "'Benoit Claise'" , "'Sebastian Zander'" , quittek@ccrle.nec.de, ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Remote sampling and middle boxes References: <005301c1b425$cd8ddaa0$3200000a@xo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Peter Phaal wrote: > > > I would like to encourage you to review > > http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-propo > > sal-00.txt > > It might solve your problem because we export: > > 5.3.2 Case B, Template for Method Description > > This case describes the format for exported configuration > > information. Each of the configuration templates within > > this flowset > > describes : > > * List of methods that define the Selection Criteria and the > > parameters for each method. > > * Observation Point and its description > > ... > > > > Note that we assume in the draft that one observation point > > is interface or a > > set of interface. > > > > Now, the only thing which is missing in our draft is the > > unique identifier of > > the measuring device (i.e. the exporter IP address) in the > > information model. > > Because I was thinking that this unique ID would have been > > the source IP address > > of the export packet (OK, it could be a loopback to be > > independent of the router > > outgoing interface). > > But I understand your point, and it's not a problem to add > > the unique identifier > > of the measuring device (i.e. the exporter IP address) in the > > information model > > Adding the unique identifier of the measuring device to the data model would > be a good idea. > > NetFlow doesn't include the agent address as part of the NetFlow header, > forcing intermediate services (such as NetFlow replication) to spoof IP > source addresses to match that of the router. It's much cleaner if the flow > records are self contained and don't depend on lower protocol layers for > context. Having an exporter ID seems straight forward enough. How about text like this (FYI - hacked from LFAP spec) Source Observation Address IE Source Observation address is the address of the device which observed the flow. This information is used by applications to later correlate the ingress/egress port with a specific Observation point. It is also used to maintain the observation information when there is an intermediate proxy. For example, given the picture below: SW1 -------- P1 ------ Collector ^ | SW2---------- | Flows coming from SW1 and SW2 through proxy P1 would look to the Collector like the same connection. With this IE in the message the original Observation point address is maintained. > > You might consider the SMON MIB (RFC 2613) SmonDataSource when defining the > types of sources allowed. In addition to ifIndex, it identifies VLANs and > objects from the entity MIB as possible observation points. > > Peter > ---------------------- > Peter Phaal > InMon Corp. > > Peter_Phaal@inmon.com > > -- > 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/ -- 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 Feb 13 09:22:04 2002 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 JAA03190 for ; Wed, 13 Feb 2002 09:22:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16azxK-0001s1-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 08:00:18 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16azxH-0001oj-00; Wed, 13 Feb 2002 08:00:15 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZC1H; Wed, 13 Feb 2002 05:59:03 -0800 Message-ID: <3C6A7126.8EC64F62@riverstonenet.com> Date: Wed, 13 Feb 2002 08:59:02 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: Juergen Quittek , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: [ipfix-data] Re: [ipfix] Draft updates - Comments on the data model References: <4F973E944951D311B6660008C7917CF008A14360@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit From that draft.... However, as a side effect of address translation, communicating endpoints on either side of the middlebox do not know how to refer to themselves using addresses that are applicable in the other realm -- the address translation is locked within the middlebox. I assumed it was the "middlebox" doing the reporting. In that case it has all the info needed. If not, then I agree trying to figure it out after the fact would be dificult. Paul Reinaldo Penno wrote: > > Hello Paul, > > the problem with the "virtual" word is that there is no way to find > out what is "virtual" and what is not. So, the "virtual" can be > actually the real one. This is the same thing as outside and inside. > See draft-iab-unsaf-considerations-01.txt. In the case of twice NAT > where Src, Dest and Port may change it's really a mess. > > regards, > > Reinaldo > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Tuesday, February 12, 2002 9:04 AM > >To: Juergen Quittek > >Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; > >ipfix@net.doit.wisc.edu; data > >Subject: Re: [ipfix] Draft updates - Comments on the data model > > > > > > > >Comments in-line... > > > >Juergen Quittek wrote: > >> > >> --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > >> > >> > > >> > Comments: > >> > > >> > First ol all, would you guys mind if I rewrite this whole > >> > section using the words "private side" and "public side" so > >> > we align our nomenclature to RFC2663? > >> > >> Why risking further inconsistencies? Just refer to RFC 2663. > >> All you want to introduce is well explained there. > >> > >> > > >> > Also, the subsection titles refer to "virtual" this and that, > >> > but the IEs refer to "outside" and "inside". So, we need some > >> > unified terminology. I also think that using inside and outside > >> > can cause confusion since the exporter/collector does not know > >> > what's inside and outside. See > >draft-iab-unsaf-considerations-01.html > >> > >> I still have problems with "virtual", "inside", and "outside". > >> This applies to firewalls and IPv4 NATs, but not to several other > >> boxes. Why not using more general terms, such as "received" and > >> "transmitted" or "original" and "modified". These terms would > >> apply to a wider range of boxes (what is "inside" for a NAT-PT?). > >> > >> This would make the draft more independent from certain > NAT/firewall > >> scenarios and would be understandable even for people who do not > care > >> about NAT issues at all. > > > > I thought I addressed this already buit let me try > > again. BTW - I believe this my proposal is not > > at all specific to NAT/firewall. Maybe an example is > > the best way to explain it. Using your terminology it > > looks like this > > > > Flow on the way out... > > > > C -> IP-R gets translated to C -> IP-A > > > > Gets reported as > > > > Src = C > > Dest-Received = IP-O > > Dest-Transmitted = IP-A > > > > On the way back > > > > IP-A -> C gets translated to IP-O -> C > > > > Gets Reported as > > > > Src-Received = IP-A > > Src-Transmitted = IP-O > > Dest = C > > > > > > > > Now suppose I want to find all the flows to and from > > my virtual IP. First I need a list of virtual IP's so > > I can find them. Then I need to search both the received > > and transmitted fields for both Src and Dest. It can be > > done but it can also be easier (maybe not easier for > > the IPFIX protocol but that's not what we're here for). > > > > If reported as I proposed it looks like this... > > > > > > > > Src = C > > Dest-virtual = IP-O > > Dest-Actual = IP-A > > > > Src-virtual = IP-O > > Src-Actal = IP-A > > Dest = C > > > > Now if I want to see all the traffic for my > > virtual IP's I just look for flows that have > > the same src or dest virtual address. I don't > > need a list and the query is simple. Also, the > > data in the fields is clear. The actual field > > is where the packet actually came from or > > went to. The virtual is the requested source > > or destination. > > > > > > This work for ANY packet that gets re-directed for ANY > > reason. Even if IP's are not actually modified. Such > > as MAC based re-direction. > > > > > >> > >> Reinaldo, you talked about good writing. I think this includes > >> avoiding irrelevant information (while still remaining clearly > >> understandable). > >> > >> > other stuff. > >> > > >> [...] > >> > > >> > then in 5.11.18 and 5.11.9 > >> > > >> > "The Destination Virtual IE contains the destination address of > >> > the flow/port as *received* by the Exporter" > >> > > >> > It should be *transmited* by the exporter, ie, you need an almost > > >> > complete 5-tuple set of IEs for the private side and for the > >> > public side. > >> > >> You see, it already gets confusing. "received/original destination" > > >> would have been a much better choice of term compared to "virtual > >> destination". > >> > >> Juergen > >> -- > >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > >> Adenauerplatz 6, 69115 Heidelberg, Germany > http://www.ccrle.nec.de > > -- 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 Feb 13 09:25:34 2002 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 JAA03364 for ; Wed, 13 Feb 2002 09:25:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b00e-0001xi-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 08:03:44 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b00c-0001x7-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 08:03:42 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZC1X; Wed, 13 Feb 2002 06:02:30 -0800 Message-ID: <3C6A71F5.D9DFA8DF@riverstonenet.com> Date: Wed, 13 Feb 2002 09:02:29 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "K.C. Norseth" CC: Robert Lowe , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 References: <59358A738F45D51186A30008C74CE250DA06B3@slc-exc1.ctron.com> <3C696B88.4C1458B5@lawrence.edu> <01dd01c1b458$1c5d8fe0$850f880a@slc252750> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit "K.C. Norseth" wrote: > > Hi Robert, > > ----- Original Message ----- > From: Robert Lowe > To: Norseth, KC > Cc: > Sent: Tuesday, February 12, 2002 12:22 PM > Subject: Re: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 > > | > "Norseth, KC" wrote: > | > | Hi KC! > | > | > |A few more comments regarding templates, although ones which > | > |probably fall within the realm of operational vs. protocol issues... > | > | > | > |Early on there was some discussion regarding the impact of > | > |IPFIX on the network itself, and if/how the exporter or > | > |collector should react to overload conditions. As I recall, > | > |Peter Phaal indicated that from an analysis point of view, it > | > |would not be good to change the sample rate. However, when > | > |faced with an overload condition: > | > | > | > |1) On the exporter, should it: > | > | a. continue as is, and drop packets when it has to, or > | > | b. fall-back to a user pre-defined sampling rate, compromising > | > | IPFIX data to avoid dropping packets ?? > | > | > | > |2) On the collector, should it: > | > | a. continue, and lose flow data because it cannot > | > |process it all, or > | > | b. signal a fall-back to a different sampling rate via > | > |a new template? > | > | > | > |If the solution uses the verb "buy", don't mention it! ;-) I > | > |can accept a good argument that these are operational issues. > | > > | > This is very dangerous to have the exporter switch to sampling > automatically. This > | > could really confuse the information being gathered. You could get the > message from the > | > reports that volume has dropped down during a period of time, but in > reality, it is > | > dnagerously high. > | > | No, I was assuming that the new template would somehow be recorded, or > available > | during analysis, so that it would be recognized that the sampling rate > changed > | and could be properly reflected in a report. I agree that not having this > change > | record available during analysis makes the analysis pretty useless. > | > | But this is a kind of in-band config that would add more complexity than > would > | seem to outweigh its benefit. I think I need to re-read a few things to > better > | understand the use of templates in general too. > > This could be a SHOULD if people want it to be. I think it could be > dangerous, but you are right, a template could inform the collector that > this is sampled data. The collector would have to be smart enough to > explain this to the readers of the reports when it changes though. It would > also have to be smart to switch back and once again the collector would have > to be smart enough to report this to the users. I don't think the > collectors/applications out there now are smart enough for this. What to do in overload situations has not been discussed much to date. A few ideas have been tossed around but that's it as for as I can tell. I don't think much more than a TBD can go in the doc at this point. > > K.C. > > | Thanks! > | > | -Robert > | > | -- > | 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/ > | > > -- > 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/ -- 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 Feb 13 09:43:00 2002 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 JAA04644 for ; Wed, 13 Feb 2002 09:42:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b0Jx-0002PP-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 08:23:41 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16azxH-0001oj-00; Wed, 13 Feb 2002 08:00:15 -0600 Received: from riverstonenet.com (134.141.180.72 [134.141.180.72]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZC1H; Wed, 13 Feb 2002 05:59:03 -0800 Message-ID: <3C6A7126.8EC64F62@riverstonenet.com> Date: Wed, 13 Feb 2002 08:59:02 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: Juergen Quittek , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: Re: [ipfix] Draft updates - Comments on the data model References: <4F973E944951D311B6660008C7917CF008A14360@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit From that draft.... However, as a side effect of address translation, communicating endpoints on either side of the middlebox do not know how to refer to themselves using addresses that are applicable in the other realm -- the address translation is locked within the middlebox. I assumed it was the "middlebox" doing the reporting. In that case it has all the info needed. If not, then I agree trying to figure it out after the fact would be dificult. Paul Reinaldo Penno wrote: > > Hello Paul, > > the problem with the "virtual" word is that there is no way to find > out what is "virtual" and what is not. So, the "virtual" can be > actually the real one. This is the same thing as outside and inside. > See draft-iab-unsaf-considerations-01.txt. In the case of twice NAT > where Src, Dest and Port may change it's really a mess. > > regards, > > Reinaldo > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Tuesday, February 12, 2002 9:04 AM > >To: Juergen Quittek > >Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; > >ipfix@net.doit.wisc.edu; data > >Subject: Re: [ipfix] Draft updates - Comments on the data model > > > > > > > >Comments in-line... > > > >Juergen Quittek wrote: > >> > >> --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: > >> > >> > > >> > Comments: > >> > > >> > First ol all, would you guys mind if I rewrite this whole > >> > section using the words "private side" and "public side" so > >> > we align our nomenclature to RFC2663? > >> > >> Why risking further inconsistencies? Just refer to RFC 2663. > >> All you want to introduce is well explained there. > >> > >> > > >> > Also, the subsection titles refer to "virtual" this and that, > >> > but the IEs refer to "outside" and "inside". So, we need some > >> > unified terminology. I also think that using inside and outside > >> > can cause confusion since the exporter/collector does not know > >> > what's inside and outside. See > >draft-iab-unsaf-considerations-01.html > >> > >> I still have problems with "virtual", "inside", and "outside". > >> This applies to firewalls and IPv4 NATs, but not to several other > >> boxes. Why not using more general terms, such as "received" and > >> "transmitted" or "original" and "modified". These terms would > >> apply to a wider range of boxes (what is "inside" for a NAT-PT?). > >> > >> This would make the draft more independent from certain > NAT/firewall > >> scenarios and would be understandable even for people who do not > care > >> about NAT issues at all. > > > > I thought I addressed this already buit let me try > > again. BTW - I believe this my proposal is not > > at all specific to NAT/firewall. Maybe an example is > > the best way to explain it. Using your terminology it > > looks like this > > > > Flow on the way out... > > > > C -> IP-R gets translated to C -> IP-A > > > > Gets reported as > > > > Src = C > > Dest-Received = IP-O > > Dest-Transmitted = IP-A > > > > On the way back > > > > IP-A -> C gets translated to IP-O -> C > > > > Gets Reported as > > > > Src-Received = IP-A > > Src-Transmitted = IP-O > > Dest = C > > > > > > > > Now suppose I want to find all the flows to and from > > my virtual IP. First I need a list of virtual IP's so > > I can find them. Then I need to search both the received > > and transmitted fields for both Src and Dest. It can be > > done but it can also be easier (maybe not easier for > > the IPFIX protocol but that's not what we're here for). > > > > If reported as I proposed it looks like this... > > > > > > > > Src = C > > Dest-virtual = IP-O > > Dest-Actual = IP-A > > > > Src-virtual = IP-O > > Src-Actal = IP-A > > Dest = C > > > > Now if I want to see all the traffic for my > > virtual IP's I just look for flows that have > > the same src or dest virtual address. I don't > > need a list and the query is simple. Also, the > > data in the fields is clear. The actual field > > is where the packet actually came from or > > went to. The virtual is the requested source > > or destination. > > > > > > This work for ANY packet that gets re-directed for ANY > > reason. Even if IP's are not actually modified. Such > > as MAC based re-direction. > > > > > >> > >> Reinaldo, you talked about good writing. I think this includes > >> avoiding irrelevant information (while still remaining clearly > >> understandable). > >> > >> > other stuff. > >> > > >> [...] > >> > > >> > then in 5.11.18 and 5.11.9 > >> > > >> > "The Destination Virtual IE contains the destination address of > >> > the flow/port as *received* by the Exporter" > >> > > >> > It should be *transmited* by the exporter, ie, you need an almost > > >> > complete 5-tuple set of IEs for the private side and for the > >> > public side. > >> > >> You see, it already gets confusing. "received/original destination" > > >> would have been a much better choice of term compared to "virtual > >> destination". > >> > >> Juergen > >> -- > >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > >> Adenauerplatz 6, 69115 Heidelberg, Germany > http://www.ccrle.nec.de > > -- 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 Feb 13 13:52:37 2002 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 NAA17164 for ; Wed, 13 Feb 2002 13:52:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b45Q-0005lt-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 12:24:56 -0600 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b45N-0005lS-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 12:24:53 -0600 Received: from agile.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id KAA26503; Wed, 13 Feb 2002 10:24:21 -0800 (PST) Received: from agile.yagosys.com (agile.yagosys.com [127.0.0.1]) by agile.yagosys.com (8.12.0/8.12.0) with ESMTP id g1DIOLS1007598 for ; Wed, 13 Feb 2002 10:24:21 -0800 Received: (from mrm@localhost) by agile.yagosys.com (8.12.0/8.12.0/Submit) id g1DIOLqV007597 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 10:24:21 -0800 Date: Wed, 13 Feb 2002 10:24:21 -0800 From: Michael MacFaden To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Configuration & MIBS Message-ID: <20020213102421.A1071@riverstonenet.com> References: <018c01c1b456$f32bb6c0$850f880a@slc252750> <1013604087.3c6a5ef7766ac@citadel.mobility.ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1013604087.3c6a5ef7766ac@citadel.mobility.ccrle.nec.de>; from quittek@ccrle.nec.de on Wed, Feb 13, 2002 at 01:41:27PM +0100 X-Operating-System: GNU/Linux 2.4.17 Precedence: bulk Sender: majordomo listserver On Wed, Feb 13, 2002 at 01:41:27PM +0100, quittek@ccrle.nec.de wrote: >A MIB for configuring the Meter/exporter would be a useful thing, >although MIBs are probably more often used for monitoring than for >configuration. Folks, A MIB module defines a technology's standard interface to the managment plane. It is not the same thing as the Simple Network Management Protocol v1/v2c/v3. RFC 2571 depicts the architecture of the IETF standard management framework. One versatile component of this framework is the Structure of Management Information (SMIv2) RFC 2578-80 which defines the contents of MIB modules. IETF standard MIB modules should expose the common configuration knobs found in the underlying technology and rarely should a MIB module define additional new knobs. (Kinda like architecture plans). A MIB module is a concise guide to implementors in their design of a configuration interface (CLI, XML, XYZ, whatever) to manage a given techology. Also note: there is only one MIB. >Maybe this MIB could also be used to monitor configuration >and operation of the meter/exporter. But I do not believe, that we >need another MIB for reading metered data. The Meter MIB is defined >and should serve this purpose sufficiently. In addition to general security requirements, there is always a general management requirement. In practice, we have found it useful to instrument LFAP via CLI/SNMP to keep track of collection systems. >However, all of these issues should be discussed when our working >group is close to finishing its current tasks. When we have stable >versions of all our planned documents, we can discuss with our AD >about re-chartering ideas. I agree. I suggest that the underlying technology clearly define recommended default settings as well as what common things one can change as well as monitor and if possible the impact of the change. For example: BGP finally being able to handle temporary disconnects when software upgrades are done to a device/support switching to redundant cpus. >Maybe our view of MIB or other configuration requirements have >developed further until then. Indeed. Regards, Mike MacFaden -- 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 Feb 13 14:23:36 2002 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 OAA18215 for ; Wed, 13 Feb 2002 14:23:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b4di-0006c5-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 13:00:22 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b4dg-0006YQ-00; Wed, 13 Feb 2002 13:00:20 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1DIxng02896; Wed, 13 Feb 2002 19:59:49 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA21711; Wed, 13 Feb 2002 19:59:46 +0100 Date: Wed, 13 Feb 2002 20:01:35 +0100 From: Juergen Quittek To: calato@riverstonenet.com cc: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: [ipfix-data] Re: [ipfix] Draft updates - Comments on the data model Message-ID: <18213776.1013630495@[192.168.102.31]> In-Reply-To: <3C6A621D.3263D19B@riverstonenet.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, --On 13 February 2002 07:54 -0500 calato@riverstonenet.com wrote: > quittek@ccrle.nec.de wrote: >> [...] >> > >> > Now if I want to see all the traffic for my >> > virtual IP's I just look for flows that have >> > the same src or dest virtual address. I don't >> > need a list and the query is simple. Also, the >> > data in the fields is clear. The actual field >> > is where the packet actually came from or >> > went to. The virtual is the requested source >> > or destination. >> >> Are you suggesting to have Src, Src-received, Src-Transmitted, >> Src-Virtual, Src-Actual as five different IE identifiers? >> This seems to be overloaded. > > No, we only need actual and virtual for both source > and destination. Not sure if there is a better word > for virtual but it is all I could come up with. It just > indicates the address is not where the packet really went to > or came from. I thought virtual worked, but I'm open > to others. I still have problems with the semantics of "virtual". At some NATs both sides may be virtual or both may have public network addresses. What is then virtual is an interpretation and there might be different ones. Therefore I prefer semantics being unambiguous, at least from the point of the meter, for example "received" and "transmitted" "original" and "modified" What is virtual can be interpreted by an application reciving input from the data collector. 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 Feb 13 14:42:18 2002 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 OAA18750 for ; Wed, 13 Feb 2002 14:42:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b51l-0007Cs-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 13:25:13 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b4dg-0006YQ-00; Wed, 13 Feb 2002 13:00:20 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1DIxng02896; Wed, 13 Feb 2002 19:59:49 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA21711; Wed, 13 Feb 2002 19:59:46 +0100 Date: Wed, 13 Feb 2002 20:01:35 +0100 From: Juergen Quittek To: calato@riverstonenet.com cc: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: Re: [ipfix] Draft updates - Comments on the data model Message-ID: <18213776.1013630495@[192.168.102.31]> In-Reply-To: <3C6A621D.3263D19B@riverstonenet.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Paul, --On 13 February 2002 07:54 -0500 calato@riverstonenet.com wrote: > quittek@ccrle.nec.de wrote: >> [...] >> > >> > Now if I want to see all the traffic for my >> > virtual IP's I just look for flows that have >> > the same src or dest virtual address. I don't >> > need a list and the query is simple. Also, the >> > data in the fields is clear. The actual field >> > is where the packet actually came from or >> > went to. The virtual is the requested source >> > or destination. >> >> Are you suggesting to have Src, Src-received, Src-Transmitted, >> Src-Virtual, Src-Actual as five different IE identifiers? >> This seems to be overloaded. > > No, we only need actual and virtual for both source > and destination. Not sure if there is a better word > for virtual but it is all I could come up with. It just > indicates the address is not where the packet really went to > or came from. I thought virtual worked, but I'm open > to others. I still have problems with the semantics of "virtual". At some NATs both sides may be virtual or both may have public network addresses. What is then virtual is an interpretation and there might be different ones. Therefore I prefer semantics being unambiguous, at least from the point of the meter, for example "received" and "transmitted" "original" and "modified" What is virtual can be interpreted by an application reciving input from the data collector. 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 Feb 13 15:03:27 2002 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 PAA19305 for ; Wed, 13 Feb 2002 15:03:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b5NB-0007fe-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 13:47:21 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b5N8-0007er-00 for ipfix-req@net.doit.wisc.edu; Wed, 13 Feb 2002 13:47:19 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1DJklg03268 for ; Wed, 13 Feb 2002 20:46:47 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA22031 for ; Wed, 13 Feb 2002 20:46:46 +0100 Date: Wed, 13 Feb 2002 20:48:34 +0100 From: Juergen Quittek To: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] Terminology again Message-ID: <21033130.1013633314@[192.168.102.31]> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi all, We had some terminology discussion and it has not converged yet. Therfore I like to raise one issue again: For the terinology section of the requirements draft (I belive now it will be a subset of the architecture's terminology) I would like to have two identifiers for the following: 1. the function block containing all metering functions This block gets as input observed (and potentially sampled) packets from the observation point. It classifies packets maps them to flows and creates/updates the according flow record. 2. the function block sending flow records to the collector I am fine with splitting blocks more or modifying them slightly, but I prefer to have this separation, because also the requirements are split in a very similar way. My initial naive suggestion was calling block 1. "meter" and calling block 2. "exporter". However this might (no it did already) cause confusion. Therefore, I am looking for better terms. Any suggestions? Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- 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 Feb 13 15:22:46 2002 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 PAA19740 for ; Wed, 13 Feb 2002 15:22:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b5gY-0000KM-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 14:07:22 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b5gT-0000JA-00; Wed, 13 Feb 2002 14:07:17 -0600 Received: from riverstonenet.com (134.141.180.79 [134.141.180.79]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZHST; Wed, 13 Feb 2002 12:06:04 -0800 Message-ID: <3C6AC729.4B87EA4A@riverstonenet.com> Date: Wed, 13 Feb 2002 15:06:01 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: [ipfix-data] Re: [ipfix] Draft updates - Comments on the data model References: <18213776.1013630495@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi Paul, > > --On 13 February 2002 07:54 -0500 calato@riverstonenet.com wrote: > > > quittek@ccrle.nec.de wrote: > >> > [...] > >> > > >> > Now if I want to see all the traffic for my > >> > virtual IP's I just look for flows that have > >> > the same src or dest virtual address. I don't > >> > need a list and the query is simple. Also, the > >> > data in the fields is clear. The actual field > >> > is where the packet actually came from or > >> > went to. The virtual is the requested source > >> > or destination. > >> > >> Are you suggesting to have Src, Src-received, Src-Transmitted, > >> Src-Virtual, Src-Actual as five different IE identifiers? > >> This seems to be overloaded. > > > > No, we only need actual and virtual for both source > > and destination. Not sure if there is a better word > > for virtual but it is all I could come up with. It just > > indicates the address is not where the packet really went to > > or came from. I thought virtual worked, but I'm open > > to others. > > I still have problems with the semantics of "virtual". At some > NATs both sides may be virtual or both may have public network > addresses. What is then virtual is an interpretation and there > might be different ones. Therefore I prefer semantics being > unambiguous, at least from the point of the meter, I think it is unambiguous at the NAT doing the reporting. Actual is where the NAT device knows (from its view) the packet came from or went to and virtual is where the packet was supposed to go or come from. I assume this is more than a wording issue but if you don't like actual and virtual, how about actual and original? > for example > "received" and "transmitted" > "original" and "modified" I agree these are easier to understand but I believe they are less useful as I pointed out in previous examples. This information is only available at the NAT device and will be lost if we report it as you suggest. Also, how do we represent MAC redirects. In your definition, received and transmitted IP are the same but reporting that is not interesting. I want to know what server actually handled the packet. It can be represented in my scheme. Maybe we need to sit down at the next meeting and hash it over then. > What is virtual can be interpreted by an application reciving > input from the data collector. > > 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 Feb 13 15:39:39 2002 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 PAA20119 for ; Wed, 13 Feb 2002 15:39:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b5wv-0000ge-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 14:24:17 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b5gT-0000JA-00; Wed, 13 Feb 2002 14:07:17 -0600 Received: from riverstonenet.com (134.141.180.79 [134.141.180.79]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZHST; Wed, 13 Feb 2002 12:06:04 -0800 Message-ID: <3C6AC729.4B87EA4A@riverstonenet.com> Date: Wed, 13 Feb 2002 15:06:01 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: Re: [ipfix] Draft updates - Comments on the data model References: <18213776.1013630495@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > > Hi Paul, > > --On 13 February 2002 07:54 -0500 calato@riverstonenet.com wrote: > > > quittek@ccrle.nec.de wrote: > >> > [...] > >> > > >> > Now if I want to see all the traffic for my > >> > virtual IP's I just look for flows that have > >> > the same src or dest virtual address. I don't > >> > need a list and the query is simple. Also, the > >> > data in the fields is clear. The actual field > >> > is where the packet actually came from or > >> > went to. The virtual is the requested source > >> > or destination. > >> > >> Are you suggesting to have Src, Src-received, Src-Transmitted, > >> Src-Virtual, Src-Actual as five different IE identifiers? > >> This seems to be overloaded. > > > > No, we only need actual and virtual for both source > > and destination. Not sure if there is a better word > > for virtual but it is all I could come up with. It just > > indicates the address is not where the packet really went to > > or came from. I thought virtual worked, but I'm open > > to others. > > I still have problems with the semantics of "virtual". At some > NATs both sides may be virtual or both may have public network > addresses. What is then virtual is an interpretation and there > might be different ones. Therefore I prefer semantics being > unambiguous, at least from the point of the meter, I think it is unambiguous at the NAT doing the reporting. Actual is where the NAT device knows (from its view) the packet came from or went to and virtual is where the packet was supposed to go or come from. I assume this is more than a wording issue but if you don't like actual and virtual, how about actual and original? > for example > "received" and "transmitted" > "original" and "modified" I agree these are easier to understand but I believe they are less useful as I pointed out in previous examples. This information is only available at the NAT device and will be lost if we report it as you suggest. Also, how do we represent MAC redirects. In your definition, received and transmitted IP are the same but reporting that is not interesting. I want to know what server actually handled the packet. It can be represented in my scheme. Maybe we need to sit down at the next meeting and hash it over then. > What is virtual can be interpreted by an application reciving > input from the data collector. > > 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 Feb 13 15:42:00 2002 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 PAA20182 for ; Wed, 13 Feb 2002 15:42:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b5zC-0000ib-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 14:26:38 -0600 Received: from mailhub.lawrence.edu ([143.44.65.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b5zB-0000iW-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 14:26:37 -0600 Received: from lawrence.edu ([143.44.97.41]) by lawrence.edu (PMDF V6.0-025 #44893) with ESMTP id <0GRH00OA5O0VIA@lawrence.edu> for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 14:38:55 -0600 (CST) Date: Wed, 13 Feb 2002 14:26:36 -0600 From: Robert Lowe Subject: Re: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 To: "K.C. Norseth" Cc: ipfix@net.doit.wisc.edu Message-id: <3C6ACBFC.BA5F03F3@lawrence.edu> Organization: Lawrence University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <59358A738F45D51186A30008C74CE250DA06B3@slc-exc1.ctron.com> <3C696B88.4C1458B5@lawrence.edu> <01dd01c1b458$1c5d8fe0$850f880a@slc252750> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit "K.C. Norseth" wrote: Hi K.C.! > ----- Original Message ----- > From: Robert Lowe > To: Norseth, KC > Cc: > Sent: Tuesday, February 12, 2002 12:22 PM > Subject: Re: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 > > | > "Norseth, KC" wrote: > | > | Hi KC! > | > | > |A few more comments regarding templates, although ones which > | > |probably fall within the realm of operational vs. protocol issues... > | > | > | > |Early on there was some discussion regarding the impact of > | > |IPFIX on the network itself, and if/how the exporter or > | > |collector should react to overload conditions. As I recall, > | > |Peter Phaal indicated that from an analysis point of view, it > | > |would not be good to change the sample rate. However, when > | > |faced with an overload condition: > | > | > | > |1) On the exporter, should it: > | > | a. continue as is, and drop packets when it has to, or > | > | b. fall-back to a user pre-defined sampling rate, compromising > | > | IPFIX data to avoid dropping packets ?? > | > | > | > |2) On the collector, should it: > | > | a. continue, and lose flow data because it cannot > | > |process it all, or > | > | b. signal a fall-back to a different sampling rate via > | > |a new template? > | > | > | > |If the solution uses the verb "buy", don't mention it! ;-) I > | > |can accept a good argument that these are operational issues. > | > > | > This is very dangerous to have the exporter switch to sampling > automatically. This > | > could really confuse the information being gathered. You could get the > message from the > | > reports that volume has dropped down during a period of time, but in > reality, it is > | > dnagerously high. > | > | No, I was assuming that the new template would somehow be recorded, or > available > | during analysis, so that it would be recognized that the sampling rate > changed > | and could be properly reflected in a report. I agree that not having this > change > | record available during analysis makes the analysis pretty useless. > | > | But this is a kind of in-band config that would add more complexity than > would > | seem to outweigh its benefit. I think I need to re-read a few things to > better > | understand the use of templates in general too. > > This could be a SHOULD if people want it to be. I think it could be > dangerous, but you are right, a template could inform the collector that > this is sampled data. The collector would have to be smart enough to > explain this to the readers of the reports when it changes though. It would > also have to be smart to switch back and once again the collector would have > to be smart enough to report this to the users. I don't think the > collectors/applications out there now are smart enough for this. Won't they have to become smarter? Besides a changing sample rate from one exporter, how will they aggregate flow data from multiple exporters, each potentially using a different sample rate? Or do all exporters within a "domain" have to use the sample rate? -Robert -- 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 Feb 13 15:58:49 2002 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 PAA20524 for ; Wed, 13 Feb 2002 15:58:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b6FQ-000126-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 14:43:24 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b6FO-000110-00; Wed, 13 Feb 2002 14:43:22 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DKd3Y18029; Wed, 13 Feb 2002 14:39:03 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFX9CR>; Wed, 13 Feb 2002 12:39:02 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A148CD@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, "K.C. Norseth" , ipfixx Subject: [ipfix] RE: MIDCOM first draft Date: Wed, 13 Feb 2002 12:38:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4CE.76D55680" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4CE.76D55680 Content-Type: text/plain; charset="iso-8859-1" Hello Paul, comments inline. >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Wednesday, February 13, 2002 5:34 AM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: ipfix-data-volunteers@net.doit.wisc.edu; >ipfix-arch-volunteers@net.doit.wisc.edu; K.C. Norseth; ipfixx >Subject: Re: MIDCOM first draft > > >> >> Hello Paul, >> >> I'll try to be more structured now. >> >> the way it is reported is one thing, but a NAT is by all purposes (by >> definition) composed of two flows. You can export them in one record >> or two records, but that doesn't change how it should be faced. >> >> would you agree with this? > > I would say no. Since a flow is defined by its key > you cannot take that out of the picture. If the > key is actual-src and actual-destination then > there is only 1 flow and only 1 record. There is no actual src and actual dest. The flow can be NATed twice in the same box. It's just how from an aimplementation standpoint you look at it (see below) > > If the key is packet-src, packet-destination then > it would be 2 flows as you suggest. Paul, the "key" is something that we invented. It's an implementation thing in the same sense that you might prefer to export NAT flows in one record. But it doesn't change the basic definition. A flow is defined by a 5-tuple. It's basic definition independent of IPfix. regards, Reinaldo ------_=_NextPart_001_01C1B4CE.76D55680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MIDCOM first draft

Hello Paul,

comments inline.

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Wednesday, February 13, 2002 5:34 = AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: = ipfix-data-volunteers@net.doit.wisc.edu;
>ipfix-arch-volunteers@net.doit.wisc.edu; K.C. = Norseth; ipfixx
>Subject: Re: MIDCOM first draft
>
>
>>
>> Hello Paul,
>>
>> I'll try to be more structured now.
>>
>> the way it is reported is one thing, but a = NAT is by all purposes (by
>> definition) composed of two flows. You can = export them in one record
>> or two records, but that doesn't change how = it should be faced.
>>
>> would you agree with this?
>
>       I would say = no. Since a flow is defined by its key
>       you cannot = take that out of the picture. If the
>       key is = actual-src and actual-destination then
>       there is = only 1 flow and only 1 record.

There is no actual src and actual dest. The flow can = be NATed twice in the same box. It's just how from an aimplementation = standpoint you look at it (see below)

>
>       If the key = is packet-src, packet-destination then
>       it would be = 2 flows as you suggest.

Paul, the "key" is something that we = invented. It's an implementation thing in the same sense that you might = prefer to export NAT flows in one record. But it doesn't change the = basic definition. A flow is defined by a 5-tuple. It's basic definition = independent of IPfix.

regards,

Reinaldo


------_=_NextPart_001_01C1B4CE.76D55680-- -- 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 Feb 13 15:58:50 2002 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 PAA20535 for ; Wed, 13 Feb 2002 15:58:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b6FL-00011v-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 14:43:19 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b6FI-00011o-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 14:43:16 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA22919; Wed, 13 Feb 2002 15:52:41 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma022897; Wed, 13 Feb 02 15:51:49 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYX3TNJ>; Wed, 13 Feb 2002 15:41:22 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06BF@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Robert Lowe'" , "K.C. Norseth" Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 Date: Wed, 13 Feb 2002 15:41:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4CE.D9877380" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4CE.D9877380 Content-Type: text/plain Depending on what you are trying to mine from the data. The load process may be different. If you start mixing 2 different types of data in a data mart, the wrong query could yield devastating results. A lot of applications leave it up to the user to generate their reports. They clone a report that was written and modify it. The data store to is going to be simple in rules, but rich in data. They would have to build an intuitiveness that they could pass on to the user. This could be missed as they build reports. Most users would miss this where the data is stored in the same area, but has different meaning. The issue of reporting data does get complex already when they are tracking a single flow across the whole network. The data collected is valid and same data, just a different viewpoint. Each router the data is reported on has valuable information, so it would be duplicated in the database. A rule specifying a next hop to be the same as the destination for example, would be a way of determining that this is the last edge of the lan. Rules like this need to be defined in the application. |-----Original Message----- |From: Robert Lowe [mailto:robert.h.lowe@lawrence.edu] |Sent: Wednesday, February 13, 2002 1:27 PM |To: K.C. Norseth |Cc: ipfix@net.doit.wisc.edu |Subject: Re: [ipfix] Questions regarding |draft-gsadasiv-ipfix-proposal-00 | | |"K.C. Norseth" wrote: | |Hi K.C.! | |> ----- Original Message ----- |> From: Robert Lowe |> To: Norseth, KC |> Cc: |> Sent: Tuesday, February 12, 2002 12:22 PM |> Subject: Re: [ipfix] Questions regarding |> draft-gsadasiv-ipfix-proposal-00 |> |> | > "Norseth, KC" wrote: |> | |> | Hi KC! |> | |> | > |A few more comments regarding templates, although ones which |> | > |probably fall within the realm of operational vs. protocol |> | > |issues... |> | > | |> | > |Early on there was some discussion regarding the impact |of IPFIX |> | > |on the network itself, and if/how the exporter or collector |> | > |should react to overload conditions. As I recall, Peter Phaal |> | > |indicated that from an analysis point of view, it would not be |> | > |good to change the sample rate. However, when faced with an |> | > |overload condition: |> | > | |> | > |1) On the exporter, should it: |> | > | a. continue as is, and drop packets when it has to, or |> | > | b. fall-back to a user pre-defined sampling |rate, compromising |> | > | IPFIX data to avoid dropping packets ?? |> | > | |> | > |2) On the collector, should it: |> | > | a. continue, and lose flow data because it |cannot process |> | > |it all, or |> | > | b. signal a fall-back to a different sampling |rate via a |> | > |new template? |> | > | |> | > |If the solution uses the verb "buy", don't mention it! ;-) I |> | > |can accept a good argument that these are operational issues. |> | > |> | > This is very dangerous to have the exporter switch to sampling |> automatically. This |> | > could really confuse the information being gathered. You could |> | > get the |> message from the |> | > reports that volume has dropped down during a period of |time, but |> | > in |> reality, it is |> | > dnagerously high. |> | |> | No, I was assuming that the new template would somehow be |recorded, |> | or |> available |> | during analysis, so that it would be recognized that the sampling |> | rate |> changed |> | and could be properly reflected in a report. I agree that not |> | having this |> change |> | record available during analysis makes the analysis pretty useless. |> | |> | But this is a kind of in-band config that would add more |complexity |> | than |> would |> | seem to outweigh its benefit. I think I need to re-read a few |> | things to |> better |> | understand the use of templates in general too. |> |> This could be a SHOULD if people want it to be. I think it could be |> dangerous, but you are right, a template could inform the collector |> that this is sampled data. The collector would have to be smart |> enough to explain this to the readers of the reports when it changes |> though. It would also have to be smart to switch back and |once again |> the collector would have to be smart enough to report this to the |> users. I don't think the collectors/applications out there now are |> smart enough for this. | |Won't they have to become smarter? Besides a changing sample |rate from one exporter, how will they aggregate flow data from |multiple exporters, |each potentially using a different sample rate? Or do all exporters |within a "domain" have to use the sample rate? | |-Robert | |-- |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/ | ------_=_NextPart_001_01C1B4CE.D9877380 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] Questions regarding = draft-gsadasiv-ipfix-proposal-00

Depending on what you are trying to mine from the = data.  The load process may be different.  If you start = mixing 2 different types of data in a data mart, the wrong query  = could yield devastating results.  A lot of applications leave it = up to the user to generate their reports. They clone a report that was = written and modify it.  The data store to is going to be simple in = rules, but rich in data.  They would have to build an = intuitiveness that they could pass on to the user.  This could be = missed as they build reports.  Most users would miss this where = the data is stored in the same area, but has different = meaning.

The issue of reporting data does get complex already = when they are tracking a single flow across the whole network.  = The data collected is valid and same data, just a different viewpoint. = Each router the data is reported on has valuable information, so it = would be duplicated in the database.  A rule specifying a next hop = to be the same as the destination for example, would be a way of = determining that this is the last edge of the lan.  Rules like = this need to be defined in the application.

|-----Original Message-----
|From: Robert Lowe [mailto:robert.h.lowe@lawrence= .edu]
|Sent: Wednesday, February 13, 2002 1:27 PM
|To: K.C. Norseth
|Cc: ipfix@net.doit.wisc.edu
|Subject: Re: [ipfix] Questions regarding
|draft-gsadasiv-ipfix-proposal-00
|
|
|"K.C. Norseth" wrote:
|
|Hi K.C.!
|
|> ----- Original Message -----
|> From: Robert Lowe = <robert.h.lowe@lawrence.edu>
|> To: Norseth, KC = <knorseth@enterasys.com>
|> Cc: <ipfix@net.doit.wisc.edu>
|> Sent: Tuesday, February 12, 2002 12:22 = PM
|> Subject: Re: [ipfix] Questions regarding =
|> draft-gsadasiv-ipfix-proposal-00
|>
|> | > "Norseth, KC" wrote:
|> |
|> | Hi KC!
|> |
|> | > |A few more comments regarding = templates, although ones which
|> | > |probably fall within the realm of = operational vs. protocol
|> | > |issues...
|> | > |
|> | > |Early on there was some discussion = regarding the impact
|of IPFIX
|> | > |on the network itself, and if/how the = exporter or collector
|> | > |should react to overload = conditions.  As I recall, Peter Phaal
|> | > |indicated that from an analysis point = of view, it would not be
|> | > |good to change the sample rate. = However, when faced with an
|> | > |overload condition:
|> | > |
|> | > |1) On the exporter, should it:
|> | > |       = a. continue as is, and drop packets when it has to, or
|> | > = |        b. fall-back to a user = pre-defined sampling
|rate, compromising
|> | > = |           IPFIX = data to avoid dropping packets ??
|> | > |
|> | > |2) On the collector, should it:
|> | > = |        a. continue, and lose flow = data because it
|cannot process
|> | > |it all, or
|> | > = |        b. signal a fall-back to a = different sampling
|rate via a
|> | > |new template?
|> | > |
|> | > |If the solution uses the verb = "buy", don't mention it!  ;-)  I
|> | > |can accept a good argument that these = are operational issues.
|> | >
|> | > This is very dangerous to have the = exporter switch to sampling
|> automatically.  This
|> | > could really confuse the information = being gathered.  You could
|> | > get the
|> message from the
|> | > reports that volume has dropped down = during a period of
|time, but
|> | > in
|> reality, it is
|> | > dnagerously high.
|> |
|> | No, I was assuming that the new template = would somehow be
|recorded,
|> | or
|> available
|> | during analysis, so that it would be = recognized that the sampling
|> | rate
|> changed
|> | and could be properly reflected in a = report.  I agree that not
|> | having this
|> change
|> | record available during analysis makes the = analysis pretty useless.
|> |
|> | But this is a kind of in-band config that = would add more
|complexity
|> | than
|> would
|> | seem to outweigh its benefit.  I think = I need to re-read a few
|> | things to
|> better
|> | understand the use of templates in general = too.
|>
|> This could be a SHOULD if people want it to = be. I think it could be
|> dangerous, but you are right, a template could = inform the collector
|> that this is sampled data.  The collector = would have to be smart
|> enough to explain this to the readers of the = reports when it changes
|> though.  It would also have to be smart = to switch back and
|once again
|> the collector would have to be smart enough to = report this to the
|> users.  I don't think the = collectors/applications out there now are
|> smart enough for this.
|
|Won't they have to become smarter?  Besides a = changing sample
|rate from one exporter, how will they aggregate = flow data from
|multiple exporters,
|each potentially using a different sample = rate?  Or do all exporters
|within a "domain" have to use the sample = rate?
|
|-Robert
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1B4CE.D9877380-- -- 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 Feb 13 16:23:35 2002 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 QAA21453 for ; Wed, 13 Feb 2002 16:23:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b6bC-0001UV-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 15:05:54 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b6bA-0001U6-00; Wed, 13 Feb 2002 15:05:52 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DL1PY03134; Wed, 13 Feb 2002 15:01:26 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFX9VX>; Wed, 13 Feb 2002 13:01:24 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A1492F@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: Juergen Quittek , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: RE: [ipfix] Draft updates - Comments on the data model Date: Wed, 13 Feb 2002 13:01:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4D1.96EEC700" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4D1.96EEC700 Content-Type: text/plain; charset="iso-8859-1" Hi Paul, complementing what Juergen said, in the same NAT box you can have several inside and outsides. You can have bi-directional NAT, twice bi-directional NAT, etc. What is iniside for one can be outside for another. Anyway, I think for the NAT stuff we should you expand the list from LFAP to indicate what type of NAT/Application redirection/etc was made in the packet. Beside just saying it was modified. there are several combinations, but we should put only the more commons. Vendors can expand it as they wish. regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Wednesday, February 13, 2002 5:59 AM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: Juergen Quittek; K.C. Norseth; ipfix@net.doit.wisc.edu; data >Subject: Re: [ipfix] Draft updates - Comments on the data model > > > >From that draft.... > > However, as a side effect of address > translation, communicating endpoints on either side of the middlebox > do not know how to refer to themselves using addresses that are > applicable in the other realm -- the address translation is locked > within the middlebox. > > >I assumed it was the "middlebox" doing the reporting. In that >case it has all the info needed. If not, then I agree >trying to figure it out after the fact would be dificult. > >Paul > >Reinaldo Penno wrote: >> >> Hello Paul, >> >> the problem with the "virtual" word is that there is no way to find >> out what is "virtual" and what is not. So, the "virtual" can be >> actually the real one. This is the same thing as outside and inside. >> See draft-iab-unsaf-considerations-01.txt. In the case of twice NAT >> where Src, Dest and Port may change it's really a mess. >> >> regards, >> >> Reinaldo >> >> >-----Original Message----- >> >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >> >Sent: Tuesday, February 12, 2002 9:04 AM >> >To: Juergen Quittek >> >Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; >> >ipfix@net.doit.wisc.edu; data >> >Subject: Re: [ipfix] Draft updates - Comments on the data model >> > >> > >> > >> >Comments in-line... >> > >> >Juergen Quittek wrote: >> >> >> >> --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: >> >> >> >> > >> >> > Comments: >> >> > >> >> > First ol all, would you guys mind if I rewrite this whole >> >> > section using the words "private side" and "public side" so >> >> > we align our nomenclature to RFC2663? >> >> >> >> Why risking further inconsistencies? Just refer to RFC 2663. >> >> All you want to introduce is well explained there. >> >> >> >> > >> >> > Also, the subsection titles refer to "virtual" this and that, >> >> > but the IEs refer to "outside" and "inside". So, we need some >> >> > unified terminology. I also think that using inside and outside >> >> > can cause confusion since the exporter/collector does not know >> >> > what's inside and outside. See >> >draft-iab-unsaf-considerations-01.html >> >> >> >> I still have problems with "virtual", "inside", and "outside". >> >> This applies to firewalls and IPv4 NATs, but not to several other >> >> boxes. Why not using more general terms, such as "received" and >> >> "transmitted" or "original" and "modified". These terms would >> >> apply to a wider range of boxes (what is "inside" for a NAT-PT?). >> >> >> >> This would make the draft more independent from certain >> NAT/firewall >> >> scenarios and would be understandable even for people who do not >> care >> >> about NAT issues at all. >> > >> > I thought I addressed this already buit let me try >> > again. BTW - I believe this my proposal is not >> > at all specific to NAT/firewall. Maybe an example is >> > the best way to explain it. Using your terminology it >> > looks like this >> > >> > Flow on the way out... >> > >> > C -> IP-R gets translated to C -> IP-A >> > >> > Gets reported as >> > >> > Src = C >> > Dest-Received = IP-O >> > Dest-Transmitted = IP-A >> > >> > On the way back >> > >> > IP-A -> C gets translated to IP-O -> C >> > >> > Gets Reported as >> > >> > Src-Received = IP-A >> > Src-Transmitted = IP-O >> > Dest = C >> > >> > >> > >> > Now suppose I want to find all the flows to and from >> > my virtual IP. First I need a list of virtual IP's so >> > I can find them. Then I need to search both the received >> > and transmitted fields for both Src and Dest. It can be >> > done but it can also be easier (maybe not easier for >> > the IPFIX protocol but that's not what we're here for). >> > >> > If reported as I proposed it looks like this... >> > >> > >> > >> > Src = C >> > Dest-virtual = IP-O >> > Dest-Actual = IP-A >> > >> > Src-virtual = IP-O >> > Src-Actal = IP-A >> > Dest = C >> > >> > Now if I want to see all the traffic for my >> > virtual IP's I just look for flows that have >> > the same src or dest virtual address. I don't >> > need a list and the query is simple. Also, the >> > data in the fields is clear. The actual field >> > is where the packet actually came from or >> > went to. The virtual is the requested source >> > or destination. >> > >> > >> > This work for ANY packet that gets re-directed for ANY >> > reason. Even if IP's are not actually modified. Such >> > as MAC based re-direction. >> > >> > >> >> >> >> Reinaldo, you talked about good writing. I think this includes >> >> avoiding irrelevant information (while still remaining clearly >> >> understandable). >> >> >> >> > other stuff. >> >> > >> >> [...] >> >> > >> >> > then in 5.11.18 and 5.11.9 >> >> > >> >> > "The Destination Virtual IE contains the destination address of >> >> > the flow/port as *received* by the Exporter" >> >> > >> >> > It should be *transmited* by the exporter, ie, you need >an almost >> >> >> > complete 5-tuple set of IEs for the private side and for the >> >> > public side. >> >> >> >> You see, it already gets confusing. "received/original >destination" >> >> >> would have been a much better choice of term compared to "virtual >> >> destination". >> >> >> >> Juergen >> >> -- >> >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 >6221 90511-15 >> >> >> NEC Europe Ltd., Network Laboratories Fax: +49 >6221 90511-55 >> >> >> Adenauerplatz 6, 69115 Heidelberg, Germany >> http://www.ccrle.nec.de >> > > ------_=_NextPart_001_01C1B4D1.96EEC700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Draft updates - Comments on the data model

Hi Paul,

complementing what Juergen said, in the same NAT box = you can have several inside and outsides. You can have bi-directional = NAT, twice bi-directional NAT, etc. What is iniside for one can be = outside for another.

Anyway, I think for the NAT stuff we should you = expand the list from LFAP to indicate what type of NAT/Application = redirection/etc was made in the packet. Beside just saying it was = modified. there are several combinations, but we should put only the = more commons. Vendors can expand it as they wish.

regards,

Reinaldo

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Wednesday, February 13, 2002 5:59 = AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: Juergen Quittek; K.C. Norseth; = ipfix@net.doit.wisc.edu; data
>Subject: Re: [ipfix] Draft updates - Comments on = the data model
>
>
>
>From that draft....
>
>   However, as a side effect of = address
>   translation, communicating = endpoints on either side of the middlebox
>   do not know how to refer to = themselves using addresses that are
>   applicable in the other realm -- = the address translation is locked
>   within the middlebox.
>
>
>I assumed it was the "middlebox" doing = the reporting. In that
>case it has all the info needed. If not, then I = agree
>trying to figure it out after the fact would be = dificult.
>
>Paul
>
>Reinaldo Penno wrote:
>>
>> Hello Paul,
>>
>> the problem with the "virtual" = word is that there is no way to find
>> out what is "virtual" and what is = not. So, the "virtual" can be
>> actually the real one.  This is the = same thing as outside and inside.
>> See draft-iab-unsaf-considerations-01.txt. = In the case of twice NAT
>> where Src, Dest and Port may change it's = really a mess.
>>
>> regards,
>>
>> Reinaldo
>>
>> >-----Original Message-----
>> >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>> >Sent: Tuesday, February 12, 2002 9:04 = AM
>> >To: Juergen Quittek
>> >Cc: Penno, Reinaldo [SC9:T327:EXCH]; = K.C. Norseth;
>> >ipfix@net.doit.wisc.edu; data
>> >Subject: Re: [ipfix] Draft updates - = Comments on the data model
>> >
>> >
>> >
>> >Comments in-line...
>> >
>> >Juergen Quittek wrote:
>> >>
>> >> --On 12 February 2002 00:18 -0800 = Reinaldo Penno wrote:
>> >>
>> >> >
>> >> > Comments:
>> >> >
>> >> > First ol all, would you guys = mind if I rewrite this whole
>> >> > section using the words = "private side" and "public side" so
>> >> > we align our nomenclature to = RFC2663?
>> >>
>> >> Why risking further = inconsistencies? Just refer to RFC 2663.
>> >> All you want to introduce is well = explained there.
>> >>
>> >> >
>> >> > Also, the subsection titles = refer to "virtual" this and that,
>> >> > but the IEs refer to = "outside" and "inside". So, we need some
>> >> > unified terminology. I also = think that using inside and outside
>> >> > can cause confusion since the = exporter/collector does not know
>> >> > what's inside and outside. = See
>> = >draft-iab-unsaf-considerations-01.html
>> >>
>> >> I still have problems with = "virtual", "inside", and = "outside".
>> >> This applies to firewalls and IPv4 = NATs, but not to several other
>> >> boxes. Why not using more general = terms, such as "received" and
>> >> "transmitted" or = "original" and "modified". These terms would
>> >> apply to a wider range of boxes = (what is "inside" for a NAT-PT?).
>> >>
>> >> This would make the draft more = independent from certain
>> NAT/firewall
>> >> scenarios and would be = understandable even for people who do not
>> care
>> >> about NAT issues at all.
>> >
>> >       I = thought I addressed this already buit let me try
>> >       = again. BTW - I believe this my proposal is not
>> >       at = all specific to NAT/firewall. Maybe an example is
>> >       = the best way to explain it. Using your terminology it
>> >       = looks like this
>> >
>> >       = Flow on the way out...
>> >
>> >      &nbs= p;        C -> IP-R gets = translated to C -> IP-A
>> >
>> >       = Gets reported as
>> >
>> = >           &n= bsp;   = Src           &nb= sp;  =3D C
>> = >           &n= bsp;   Dest-Received    =3D IP-O
>> = >           &n= bsp;   Dest-Transmitted =3D IP-A
>> >
>> >       On = the way back
>> >
>> = >           &n= bsp;   IP-A -> C  gets translated to IP-O -> = C
>> >
>> >       = Gets Reported as
>> >
>> = >           &n= bsp;   Src-Received    =3D IP-A
>> = >           &n= bsp;   Src-Transmitted =3D IP-O
>> = >           &n= bsp;   = Dest            = =3D C
>> >
>> >
>> >
>> >       = Now suppose I want to find all the flows to and from
>> >       my = virtual IP. First I need a list of virtual IP's so
>> >       I = can find them. Then I need to search both the received
>> >       = and transmitted fields for both Src and Dest. It can be
>> >       = done but it can also be easier (maybe not easier for
>> >       = the IPFIX protocol but that's not what we're here for).
>> >
>> >       If = reported as I proposed it looks like this...
>> >
>> >
>> >
>> = >           &n= bsp;   = Src            = =3D C
>> = >           &n= bsp;   Dest-virtual   =3D IP-O
>> = >           &n= bsp;   Dest-Actual    =3D IP-A
>> >
>> = >           &n= bsp;   Src-virtual    =3D IP-O
>> = >           &n= bsp;   Src-Actal      =3D = IP-A
>> = >           &n= bsp;   = Dest           =3D = C
>> >
>> >       = Now if I want to see all the traffic for my
>> >       = virtual IP's I just look for flows that have
>> >       = the same src or dest virtual address. I don't
>> >       = need a list and the query is simple. Also, the
>> >       = data in the fields is clear. The actual field
>> >       is = where the packet actually came from or
>> >       = went to. The virtual is the requested source
>> >       or = destination.
>> >
>> >
>> >       = This work for ANY packet that gets re-directed for ANY
>> >       = reason. Even if IP's are not actually modified. Such
>> >       as = MAC based re-direction.
>> >
>> >
>> >>
>> >> Reinaldo, you talked about good = writing. I think this includes
>> >> avoiding irrelevant information = (while still remaining clearly
>> >> understandable).
>> >>
>> >> > other stuff.
>> >> >
>> >> [...]
>> >> >
>> >> > then in 5.11.18 and = 5.11.9
>> >> >
>> >> > "The Destination Virtual = IE contains the destination address of
>> >> > the flow/port as *received* = by the Exporter"
>> >> >
>> >> > It should be *transmited* by = the exporter, ie, you need
>an almost
>>
>> >> > complete 5-tuple set of IEs = for the private side and for the
>> >> > public side.
>> >>
>> >> You see, it already gets = confusing. "received/original
>destination"
>>
>> >> would have been a much better = choice of term compared to "virtual
>> >> destination".
>> >>
>> >>     = Juergen
>> >> --
>> >> Juergen = Quittek     = quittek@ccrle.nec.de     Tel: +49
>6221 90511-15
>>
>> >> NEC Europe Ltd.,    = Network Laboratories     Fax: +49
>6221 90511-55
>>
>> >> Adenauerplatz 6, 69115 Heidelberg, = Germany
>> http://www.ccrle.nec.de
>> >
>

------_=_NextPart_001_01C1B4D1.96EEC700-- -- 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 Feb 13 16:24:41 2002 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 QAA21632 for ; Wed, 13 Feb 2002 16:24:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b6f7-0001YN-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 15:09:57 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b6f6-0001Y6-00 for ipfix-req@net.doit.wisc.edu; Wed, 13 Feb 2002 15:09:56 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DL59Y10658; Wed, 13 Feb 2002 15:05:09 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFX9XY>; Wed, 13 Feb 2002 13:05:07 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A1493D@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, Benoit Claise Cc: Sebastian Zander , Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Wed, 13 Feb 2002 13:05:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4D2.1A232FD0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4D2.1A232FD0 Content-Type: text/plain; charset="iso-8859-1" Well, we need to make a decision if we are going to have configuration in-band or not. And if yes, what can be configured. I'm not sure how Benoit et al feel about this. regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Wednesday, February 13, 2002 5:15 AM >To: Benoit Claise >Cc: Sebastian Zander; Juergen Quittek; ipfix-req@net.doit.wisc.edu >Subject: Re: [ipfix-req] Proposed changes to >draft-ietf-ipfix-reqs-00.txt > > > > Not sure what you mean by "the big principals" but > it is important to list both what you are covering > and what you are intentionally not covering. Saying > configuration is out-of-band and out of scope seems > appropriate (assuming that is what we agree to). > > But even that cannot be used as the golden rule. For > example, I still think configuring which fields to > send should be done in band. > >> ------_=_NextPart_001_01C1B4D2.1A232FD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-req] Proposed changes to = draft-ietf-ipfix-reqs-00.txt

Well, we need to make a decision if we are going to = have configuration in-band or not. And if yes, what can be configured. = I'm not sure how Benoit et al feel about this.

regards,

Reinaldo

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Wednesday, February 13, 2002 5:15 = AM
>To: Benoit Claise
>Cc: Sebastian Zander; Juergen Quittek; = ipfix-req@net.doit.wisc.edu
>Subject: Re: [ipfix-req] Proposed changes = to
>draft-ietf-ipfix-reqs-00.txt
>
>
>
>       Not sure = what you mean by "the big principals" but
>       it is = important to list both what you are covering
>       and what = you are intentionally not covering. Saying
>       = configuration is out-of-band and out of scope seems
>       appropriate = (assuming that is what we agree to).
>
>       But even = that cannot be used as the golden rule. For
>       example, I = still think configuring which fields to
>       send should = be done in band.
>
>>

------_=_NextPart_001_01C1B4D2.1A232FD0-- -- 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 Feb 13 16:26:28 2002 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 QAA21765 for ; Wed, 13 Feb 2002 16:26:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b6gu-0001aK-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 15:11:48 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b6gr-0001a1-00; Wed, 13 Feb 2002 15:11:45 -0600 Received: from riverstonenet.com (134.141.180.79 [134.141.180.79]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZ2QY; Wed, 13 Feb 2002 13:10:30 -0800 Message-ID: <3C6AD644.5CC9F18F@riverstonenet.com> Date: Wed, 13 Feb 2002 16:10:28 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, "K.C. Norseth" , ipfixx Subject: [ipfix] Re: MIDCOM first draft References: <4F973E944951D311B6660008C7917CF008A148CD@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > Hello Paul, > > comments inline. > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Wednesday, February 13, 2002 5:34 AM > >To: Penno, Reinaldo [SC9:T327:EXCH] > >Cc: ipfix-data-volunteers@net.doit.wisc.edu; > >ipfix-arch-volunteers@net.doit.wisc.edu; K.C. Norseth; ipfixx > >Subject: Re: MIDCOM first draft > > > > > >> > >> Hello Paul, > >> > >> I'll try to be more structured now. > >> > >> the way it is reported is one thing, but a NAT is by all purposes > (by > >> definition) composed of two flows. You can export them in one > record > >> or two records, but that doesn't change how it should be faced. > >> > >> would you agree with this? > > > > I would say no. Since a flow is defined by its key > > you cannot take that out of the picture. If the > > key is actual-src and actual-destination then > > there is only 1 flow and only 1 record. > > There is no actual src and actual dest. The flow can be NATed twice in > the same box. It's just how from an aimplementation standpoint you > look at it (see below) > Doesn't matter how many times it gets NATed. The end result is some IP gets stuffed in the paceket to go out and that is the actual address in the NAT case. The addresses in the middle are what I call the virtual addresses (for lack of a better term). There can be a list of virtual addresses if more than one translation takes place. > > > > If the key is packet-src, packet-destination then > > it would be 2 flows as you suggest. > > Paul, the "key" is something that we invented. It's an implementation > thing in the same sense that you might prefer to export NAT flows in > one record. But it doesn't change the basic definition. A flow is > defined by a 5-tuple. It's basic definition independent of IPfix. I don't think there is such a standard definition. Unless you mean a NAT flow and the NAT RFC defines such a thing (I'm not sure if it does or doesn't). ICMP for example does not have src and dest port but I'm sure it can be NATed just the same. > > regards, > > Reinaldo -- 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 Feb 13 16:42:29 2002 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 QAA22136 for ; Wed, 13 Feb 2002 16:42:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b6tx-00027P-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 15:25:17 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b6bA-0001U6-00; Wed, 13 Feb 2002 15:05:52 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DL1PY03134; Wed, 13 Feb 2002 15:01:26 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFX9VX>; Wed, 13 Feb 2002 13:01:24 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A1492F@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: Juergen Quittek , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: [ipfix-data] RE: [ipfix] Draft updates - Comments on the data model Date: Wed, 13 Feb 2002 13:01:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4D1.96EEC700" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4D1.96EEC700 Content-Type: text/plain; charset="iso-8859-1" Hi Paul, complementing what Juergen said, in the same NAT box you can have several inside and outsides. You can have bi-directional NAT, twice bi-directional NAT, etc. What is iniside for one can be outside for another. Anyway, I think for the NAT stuff we should you expand the list from LFAP to indicate what type of NAT/Application redirection/etc was made in the packet. Beside just saying it was modified. there are several combinations, but we should put only the more commons. Vendors can expand it as they wish. regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Wednesday, February 13, 2002 5:59 AM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: Juergen Quittek; K.C. Norseth; ipfix@net.doit.wisc.edu; data >Subject: Re: [ipfix] Draft updates - Comments on the data model > > > >From that draft.... > > However, as a side effect of address > translation, communicating endpoints on either side of the middlebox > do not know how to refer to themselves using addresses that are > applicable in the other realm -- the address translation is locked > within the middlebox. > > >I assumed it was the "middlebox" doing the reporting. In that >case it has all the info needed. If not, then I agree >trying to figure it out after the fact would be dificult. > >Paul > >Reinaldo Penno wrote: >> >> Hello Paul, >> >> the problem with the "virtual" word is that there is no way to find >> out what is "virtual" and what is not. So, the "virtual" can be >> actually the real one. This is the same thing as outside and inside. >> See draft-iab-unsaf-considerations-01.txt. In the case of twice NAT >> where Src, Dest and Port may change it's really a mess. >> >> regards, >> >> Reinaldo >> >> >-----Original Message----- >> >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >> >Sent: Tuesday, February 12, 2002 9:04 AM >> >To: Juergen Quittek >> >Cc: Penno, Reinaldo [SC9:T327:EXCH]; K.C. Norseth; >> >ipfix@net.doit.wisc.edu; data >> >Subject: Re: [ipfix] Draft updates - Comments on the data model >> > >> > >> > >> >Comments in-line... >> > >> >Juergen Quittek wrote: >> >> >> >> --On 12 February 2002 00:18 -0800 Reinaldo Penno wrote: >> >> >> >> > >> >> > Comments: >> >> > >> >> > First ol all, would you guys mind if I rewrite this whole >> >> > section using the words "private side" and "public side" so >> >> > we align our nomenclature to RFC2663? >> >> >> >> Why risking further inconsistencies? Just refer to RFC 2663. >> >> All you want to introduce is well explained there. >> >> >> >> > >> >> > Also, the subsection titles refer to "virtual" this and that, >> >> > but the IEs refer to "outside" and "inside". So, we need some >> >> > unified terminology. I also think that using inside and outside >> >> > can cause confusion since the exporter/collector does not know >> >> > what's inside and outside. See >> >draft-iab-unsaf-considerations-01.html >> >> >> >> I still have problems with "virtual", "inside", and "outside". >> >> This applies to firewalls and IPv4 NATs, but not to several other >> >> boxes. Why not using more general terms, such as "received" and >> >> "transmitted" or "original" and "modified". These terms would >> >> apply to a wider range of boxes (what is "inside" for a NAT-PT?). >> >> >> >> This would make the draft more independent from certain >> NAT/firewall >> >> scenarios and would be understandable even for people who do not >> care >> >> about NAT issues at all. >> > >> > I thought I addressed this already buit let me try >> > again. BTW - I believe this my proposal is not >> > at all specific to NAT/firewall. Maybe an example is >> > the best way to explain it. Using your terminology it >> > looks like this >> > >> > Flow on the way out... >> > >> > C -> IP-R gets translated to C -> IP-A >> > >> > Gets reported as >> > >> > Src = C >> > Dest-Received = IP-O >> > Dest-Transmitted = IP-A >> > >> > On the way back >> > >> > IP-A -> C gets translated to IP-O -> C >> > >> > Gets Reported as >> > >> > Src-Received = IP-A >> > Src-Transmitted = IP-O >> > Dest = C >> > >> > >> > >> > Now suppose I want to find all the flows to and from >> > my virtual IP. First I need a list of virtual IP's so >> > I can find them. Then I need to search both the received >> > and transmitted fields for both Src and Dest. It can be >> > done but it can also be easier (maybe not easier for >> > the IPFIX protocol but that's not what we're here for). >> > >> > If reported as I proposed it looks like this... >> > >> > >> > >> > Src = C >> > Dest-virtual = IP-O >> > Dest-Actual = IP-A >> > >> > Src-virtual = IP-O >> > Src-Actal = IP-A >> > Dest = C >> > >> > Now if I want to see all the traffic for my >> > virtual IP's I just look for flows that have >> > the same src or dest virtual address. I don't >> > need a list and the query is simple. Also, the >> > data in the fields is clear. The actual field >> > is where the packet actually came from or >> > went to. The virtual is the requested source >> > or destination. >> > >> > >> > This work for ANY packet that gets re-directed for ANY >> > reason. Even if IP's are not actually modified. Such >> > as MAC based re-direction. >> > >> > >> >> >> >> Reinaldo, you talked about good writing. I think this includes >> >> avoiding irrelevant information (while still remaining clearly >> >> understandable). >> >> >> >> > other stuff. >> >> > >> >> [...] >> >> > >> >> > then in 5.11.18 and 5.11.9 >> >> > >> >> > "The Destination Virtual IE contains the destination address of >> >> > the flow/port as *received* by the Exporter" >> >> > >> >> > It should be *transmited* by the exporter, ie, you need >an almost >> >> >> > complete 5-tuple set of IEs for the private side and for the >> >> > public side. >> >> >> >> You see, it already gets confusing. "received/original >destination" >> >> >> would have been a much better choice of term compared to "virtual >> >> destination". >> >> >> >> Juergen >> >> -- >> >> Juergen Quittek quittek@ccrle.nec.de Tel: +49 >6221 90511-15 >> >> >> NEC Europe Ltd., Network Laboratories Fax: +49 >6221 90511-55 >> >> >> Adenauerplatz 6, 69115 Heidelberg, Germany >> http://www.ccrle.nec.de >> > > ------_=_NextPart_001_01C1B4D1.96EEC700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Draft updates - Comments on the data model

Hi Paul,

complementing what Juergen said, in the same NAT box = you can have several inside and outsides. You can have bi-directional = NAT, twice bi-directional NAT, etc. What is iniside for one can be = outside for another.

Anyway, I think for the NAT stuff we should you = expand the list from LFAP to indicate what type of NAT/Application = redirection/etc was made in the packet. Beside just saying it was = modified. there are several combinations, but we should put only the = more commons. Vendors can expand it as they wish.

regards,

Reinaldo

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Wednesday, February 13, 2002 5:59 = AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: Juergen Quittek; K.C. Norseth; = ipfix@net.doit.wisc.edu; data
>Subject: Re: [ipfix] Draft updates - Comments on = the data model
>
>
>
>From that draft....
>
>   However, as a side effect of = address
>   translation, communicating = endpoints on either side of the middlebox
>   do not know how to refer to = themselves using addresses that are
>   applicable in the other realm -- = the address translation is locked
>   within the middlebox.
>
>
>I assumed it was the "middlebox" doing = the reporting. In that
>case it has all the info needed. If not, then I = agree
>trying to figure it out after the fact would be = dificult.
>
>Paul
>
>Reinaldo Penno wrote:
>>
>> Hello Paul,
>>
>> the problem with the "virtual" = word is that there is no way to find
>> out what is "virtual" and what is = not. So, the "virtual" can be
>> actually the real one.  This is the = same thing as outside and inside.
>> See draft-iab-unsaf-considerations-01.txt. = In the case of twice NAT
>> where Src, Dest and Port may change it's = really a mess.
>>
>> regards,
>>
>> Reinaldo
>>
>> >-----Original Message-----
>> >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>> >Sent: Tuesday, February 12, 2002 9:04 = AM
>> >To: Juergen Quittek
>> >Cc: Penno, Reinaldo [SC9:T327:EXCH]; = K.C. Norseth;
>> >ipfix@net.doit.wisc.edu; data
>> >Subject: Re: [ipfix] Draft updates - = Comments on the data model
>> >
>> >
>> >
>> >Comments in-line...
>> >
>> >Juergen Quittek wrote:
>> >>
>> >> --On 12 February 2002 00:18 -0800 = Reinaldo Penno wrote:
>> >>
>> >> >
>> >> > Comments:
>> >> >
>> >> > First ol all, would you guys = mind if I rewrite this whole
>> >> > section using the words = "private side" and "public side" so
>> >> > we align our nomenclature to = RFC2663?
>> >>
>> >> Why risking further = inconsistencies? Just refer to RFC 2663.
>> >> All you want to introduce is well = explained there.
>> >>
>> >> >
>> >> > Also, the subsection titles = refer to "virtual" this and that,
>> >> > but the IEs refer to = "outside" and "inside". So, we need some
>> >> > unified terminology. I also = think that using inside and outside
>> >> > can cause confusion since the = exporter/collector does not know
>> >> > what's inside and outside. = See
>> = >draft-iab-unsaf-considerations-01.html
>> >>
>> >> I still have problems with = "virtual", "inside", and = "outside".
>> >> This applies to firewalls and IPv4 = NATs, but not to several other
>> >> boxes. Why not using more general = terms, such as "received" and
>> >> "transmitted" or = "original" and "modified". These terms would
>> >> apply to a wider range of boxes = (what is "inside" for a NAT-PT?).
>> >>
>> >> This would make the draft more = independent from certain
>> NAT/firewall
>> >> scenarios and would be = understandable even for people who do not
>> care
>> >> about NAT issues at all.
>> >
>> >       I = thought I addressed this already buit let me try
>> >       = again. BTW - I believe this my proposal is not
>> >       at = all specific to NAT/firewall. Maybe an example is
>> >       = the best way to explain it. Using your terminology it
>> >       = looks like this
>> >
>> >       = Flow on the way out...
>> >
>> >      &nbs= p;        C -> IP-R gets = translated to C -> IP-A
>> >
>> >       = Gets reported as
>> >
>> = >           &n= bsp;   = Src           &nb= sp;  =3D C
>> = >           &n= bsp;   Dest-Received    =3D IP-O
>> = >           &n= bsp;   Dest-Transmitted =3D IP-A
>> >
>> >       On = the way back
>> >
>> = >           &n= bsp;   IP-A -> C  gets translated to IP-O -> = C
>> >
>> >       = Gets Reported as
>> >
>> = >           &n= bsp;   Src-Received    =3D IP-A
>> = >           &n= bsp;   Src-Transmitted =3D IP-O
>> = >           &n= bsp;   = Dest            = =3D C
>> >
>> >
>> >
>> >       = Now suppose I want to find all the flows to and from
>> >       my = virtual IP. First I need a list of virtual IP's so
>> >       I = can find them. Then I need to search both the received
>> >       = and transmitted fields for both Src and Dest. It can be
>> >       = done but it can also be easier (maybe not easier for
>> >       = the IPFIX protocol but that's not what we're here for).
>> >
>> >       If = reported as I proposed it looks like this...
>> >
>> >
>> >
>> = >           &n= bsp;   = Src            = =3D C
>> = >           &n= bsp;   Dest-virtual   =3D IP-O
>> = >           &n= bsp;   Dest-Actual    =3D IP-A
>> >
>> = >           &n= bsp;   Src-virtual    =3D IP-O
>> = >           &n= bsp;   Src-Actal      =3D = IP-A
>> = >           &n= bsp;   = Dest           =3D = C
>> >
>> >       = Now if I want to see all the traffic for my
>> >       = virtual IP's I just look for flows that have
>> >       = the same src or dest virtual address. I don't
>> >       = need a list and the query is simple. Also, the
>> >       = data in the fields is clear. The actual field
>> >       is = where the packet actually came from or
>> >       = went to. The virtual is the requested source
>> >       or = destination.
>> >
>> >
>> >       = This work for ANY packet that gets re-directed for ANY
>> >       = reason. Even if IP's are not actually modified. Such
>> >       as = MAC based re-direction.
>> >
>> >
>> >>
>> >> Reinaldo, you talked about good = writing. I think this includes
>> >> avoiding irrelevant information = (while still remaining clearly
>> >> understandable).
>> >>
>> >> > other stuff.
>> >> >
>> >> [...]
>> >> >
>> >> > then in 5.11.18 and = 5.11.9
>> >> >
>> >> > "The Destination Virtual = IE contains the destination address of
>> >> > the flow/port as *received* = by the Exporter"
>> >> >
>> >> > It should be *transmited* by = the exporter, ie, you need
>an almost
>>
>> >> > complete 5-tuple set of IEs = for the private side and for the
>> >> > public side.
>> >>
>> >> You see, it already gets = confusing. "received/original
>destination"
>>
>> >> would have been a much better = choice of term compared to "virtual
>> >> destination".
>> >>
>> >>     = Juergen
>> >> --
>> >> Juergen = Quittek     = quittek@ccrle.nec.de     Tel: +49
>6221 90511-15
>>
>> >> NEC Europe Ltd.,    = Network Laboratories     Fax: +49
>6221 90511-55
>>
>> >> Adenauerplatz 6, 69115 Heidelberg, = Germany
>> http://www.ccrle.nec.de
>> >
>

------_=_NextPart_001_01C1B4D1.96EEC700-- -- 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 Feb 13 17:13:54 2002 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 RAA22745 for ; Wed, 13 Feb 2002 17:13:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b7Pe-0002zu-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 15:58:02 -0600 Received: from [216.167.117.195] (helo=www.inmon.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b7Pc-0002ze-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 15:58:00 -0600 Received: from phaalpc (w086.z065104045.sjc-ca.dsl.cnc.net [65.104.45.86]) by www.inmon.com (8.9.3/(dn/norelay)) with SMTP id QAA04681; Wed, 13 Feb 2002 16:57:48 -0500 Reply-To: From: "Peter Phaal" To: "'Robert Lowe'" , "'K.C. Norseth'" Cc: Subject: RE: [ipfix] Questions regarding draft-gsadasiv-ipfix-proposal-00 Date: Wed, 13 Feb 2002 13:57:14 -0800 Message-ID: <002b01c1b4d9$662fdc00$3200000a@xo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C6ACBFC.BA5F03F3@lawrence.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit On Wed Feb 13 2002 - 14:26:36 CST, Robert Lowe wrote: > > Won't they have to become smarter? Besides a changing sample > rate from > one exporter, how will they aggregate flow data from multiple > exporters, > each potentially using a different sample rate? Or do all exporters > within a "domain" have to use the sample rate? > This raises an interesting point. The IPFIX charter doesn't address the algorithms used by the flow collector, but there are system-wide issues that should be explored. Design choices made in the IPFIX protocol specification can have a fundamental effect on the capabilities of traffic management systems collecting IPFIX data (scalability, latency, accuracy, multi-point correlation, etc.) Specifically here are some issues to consider with regard to agents dynamically altering sampling rates in response to network load: 1. It may introduce correlation into the measurements that biases results and makes the computation of variances impossible. 2. If the agent changes sampling rate, will it flush its flow cache? If it doesn't there will be some flows that have ill-defined sampling rates. Forcing a cache flush at the point where you are starting to sample because of a surge in traffic seems like a bad idea. 3. Network traffic is variable. The load in one interval is not very predictive of the load in the next interval. The agent is likely to always have the wrong sampling rate, reducing sampling interval before a burst and increasing the sampling interval before a lull. In general, it is important that a measurement agent should behave predictability. The IPFIX agents and the collectors need to be configured consistently on a network-wide basis. Selecting appropriate sampling rates for each observation point is a configuration issue and it should be up the the network manager to determine the appropriate sampling rate, taking into account the measurement load on exporters, load on the collector and the desired accuracy of measurements. Peter ---------------------- Peter Phaal InMon Corp. Peter_Phaal@inmon.com -- 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 Feb 13 17:19:22 2002 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 RAA22810 for ; Wed, 13 Feb 2002 17:19:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b7SZ-00036u-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 16:01:03 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b7SX-00035y-00; Wed, 13 Feb 2002 16:01:01 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DLucY24087; Wed, 13 Feb 2002 15:56:38 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFYA26>; Wed, 13 Feb 2002 13:56:37 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A149F9@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, "K.C. Norseth" , ipfixx Subject: [ipfix] RE: MIDCOM first draft Date: Wed, 13 Feb 2002 13:56:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4D9.49DCBAF0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4D9.49DCBAF0 Content-Type: text/plain; charset="iso-8859-1" >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Wednesday, February 13, 2002 1:10 PM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: ipfix-data-volunteers@net.doit.wisc.edu; >ipfix-arch-volunteers@net.doit.wisc.edu; K.C. Norseth; ipfixx >Subject: Re: MIDCOM first draft > > >Reinaldo Penno wrote: >> >> Hello Paul, >> >> comments inline. >> >> >-----Original Message----- >> >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >> >Sent: Wednesday, February 13, 2002 5:34 AM >> >To: Penno, Reinaldo [SC9:T327:EXCH] >> >Cc: ipfix-data-volunteers@net.doit.wisc.edu; >> >ipfix-arch-volunteers@net.doit.wisc.edu; K.C. Norseth; ipfixx >> >Subject: Re: MIDCOM first draft >> > >> > >> >> >> >> Hello Paul, >> >> >> >> I'll try to be more structured now. >> >> >> >> the way it is reported is one thing, but a NAT is by all purposes >> (by >> >> definition) composed of two flows. You can export them in one >> record >> >> or two records, but that doesn't change how it should be faced. >> >> >> >> would you agree with this? >> > >> > I would say no. Since a flow is defined by its key >> > you cannot take that out of the picture. If the >> > key is actual-src and actual-destination then >> > there is only 1 flow and only 1 record. >> >> There is no actual src and actual dest. The flow can be >NATed twice in >> the same box. It's just how from an aimplementation standpoint you >> look at it (see below) >> > > Doesn't matter how many times it gets NATed. The end result > is some IP gets stuffed in the paceket to go out and that is the > actual address in the NAT case. The addresses in the middle > are what I call the virtual addresses (for lack of a >better term). > There can be a list of virtual addresses if more than one > translation takes place. well, you do not really know when the translation ended. The packet might com in a interface and get translated, and then as it goes out another is translated again. If the intefaces are independent you would get two records saying that this is the "actual" destination. Remeber that the collector is the "middlebox controller" in this case. It can be 10 hops away for all we care. It doesn't know where is inside, outside, virtual or actual from the exporter(s) point of view. it will believe what is told and might receive several flow saying that for a given source, this is the "actual" destination, which IMHO is misleading. Saying what operation was performed on the packet (NAT, Twice NAT, etc) and what fields changed (without getting into outside, inside, virtual, actual, etc) is less confusing in my opinion. But if I couldn't convince you up to know that's okay (;-) > >> > >> > If the key is packet-src, packet-destination then >> > it would be 2 flows as you suggest. >> >> Paul, the "key" is something that we invented. It's an implementation >> thing in the same sense that you might prefer to export NAT flows in >> one record. But it doesn't change the basic definition. A flow is >> defined by a 5-tuple. It's basic definition independent of IPfix. > > I don't think there is such a standard definition. Unless > you mean a NAT flow and the NAT RFC defines such a thing > (I'm not sure if it does or doesn't). ICMP for example does > not have src and dest port but I'm sure it can be NATed just > the same. It's still a 5-tuple but in the case of ICMP some of the tuples are missing. RFC 2914 has some discussion on this subject "This raises the issue of the appropriate granularity of a "flow", where we define a `flow' as the level of granularity appropriate for the application of both fairness and congestion control. From RFC 2309: "There are a few `natural' answers: 1) a TCP or UDP connection (source address/port, destination address/port); 2) a source/destination host pair; 3) a given source host or a given destination host." IMO NAT is consisted of two flows. Actually after you NAT a packet it can be dropped by a firewall rule in the same box. A flow that otherwise wouldn't be dropped if the packet hasn't been modified. You can also take a step further asying that in the ingress direction stateful firewalls follow the conversation after the NAT, no before it. They do not consider the flow before the NAT the same thing, ie, you cannot send a unsolicited packet with the original addresses (before the NAT) in it and expect a firewall to accept them. Did I convince you? (;-) regards, Reinaldo >> >> regards, >> >> Reinaldo > ------_=_NextPart_001_01C1B4D9.49DCBAF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MIDCOM first draft

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Wednesday, February 13, 2002 1:10 = PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: = ipfix-data-volunteers@net.doit.wisc.edu;
>ipfix-arch-volunteers@net.doit.wisc.edu; K.C. = Norseth; ipfixx
>Subject: Re: MIDCOM first draft
>
>
>Reinaldo Penno wrote:
>>
>> Hello Paul,
>>
>> comments inline.
>>
>> >-----Original Message-----
>> >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>> >Sent: Wednesday, February 13, 2002 5:34 = AM
>> >To: Penno, Reinaldo = [SC9:T327:EXCH]
>> >Cc: = ipfix-data-volunteers@net.doit.wisc.edu;
>> = >ipfix-arch-volunteers@net.doit.wisc.edu; K.C. Norseth; = ipfixx
>> >Subject: Re: MIDCOM first draft
>> >
>> >
>> >>
>> >> Hello Paul,
>> >>
>> >> I'll try to be more structured = now.
>> >>
>> >> the way it is reported is one = thing, but a NAT is by all purposes
>> (by
>> >> definition) composed of two flows. = You can export them in one
>> record
>> >> or two records, but that doesn't = change how it should be faced.
>> >>
>> >> would you agree with this?
>> >
>> >       I = would say no. Since a flow is defined by its key
>> >       = you cannot take that out of the picture. If the
>> >       = key is actual-src and actual-destination then
>> >       = there is only 1 flow and only 1 record.
>>
>> There is no actual src and actual dest. The = flow can be
>NATed twice in
>> the same box. It's just how from an = aimplementation standpoint you
>> look at it (see below)
>>
>
>       Doesn't = matter how many times it gets NATed. The end result
>       is some IP = gets stuffed in the paceket to go out and that is the
>       actual = address in the NAT case. The addresses in the middle
>       are what I = call the virtual addresses (for lack of a
>better term).
>       There can = be a list of virtual addresses if more than one
>       translation = takes place.

well, you do not really know when the translation = ended. The packet might com in a interface and get translated, and then = as it goes out another is translated again. If the intefaces are = independent you would get two records saying that this is the = "actual" destination.

Remeber that the collector is the "middlebox = controller" in this case. It can be 10 hops away for all we care. = It doesn't know where is inside, outside, virtual or actual from the = exporter(s) point of view. it will believe what is told and might = receive several flow saying that for a given source, this is the = "actual" destination, which IMHO is misleading.

Saying what operation was performed on the packet = (NAT, Twice NAT, etc) and what fields changed (without getting into = outside, inside, virtual, actual, etc) is less confusing in my opinion. = But if I couldn't convince you up to

know that's okay (;-)


>
>> >
>> >       If = the key is packet-src, packet-destination then
>> >       it = would be 2 flows as you suggest.
>>
>> Paul, the "key" is something that = we invented. It's an implementation
>> thing in the same sense that you might = prefer to export NAT flows in
>> one record. But it doesn't change the basic = definition. A flow is
>> defined by a 5-tuple. It's basic definition = independent of IPfix.
>
>       I don't = think there is such a standard definition. Unless
>       you mean a = NAT flow and the NAT RFC defines such a thing
>       (I'm not = sure if it does or doesn't). ICMP for example does
>       not have = src and dest port but I'm sure it can be NATed just
>       the = same.

It's still a 5-tuple but in the case of ICMP some of = the tuples are missing. RFC 2914 has some discussion on this = subject

"This raises the issue of the appropriate = granularity of a "flow",
   where we define a `flow' as the level = of granularity appropriate for
   the application of both fairness and = congestion control.  From RFC
   2309:  "There are a few = `natural' answers: 1) a TCP or UDP connection
   (source address/port, destination = address/port); 2) a
   source/destination host pair; 3) a = given source host or a given
   destination host."

IMO NAT is consisted of two flows. Actually after you = NAT a packet it can be dropped by a firewall rule in the same box. A = flow that otherwise wouldn't be dropped if the packet hasn't been = modified. You can also take a step further asying that in the ingress = direction stateful firewalls follow the conversation after the NAT, no = before it. They do not consider the flow before the NAT the same thing, = ie, you cannot send a unsolicited packet with the original addresses = (before the NAT) in it and expect a firewall to accept them.

Did I convince you? (;-)

regards,

Reinaldo




>>
>> regards,
>>
>> Reinaldo
>

------_=_NextPart_001_01C1B4D9.49DCBAF0-- -- 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 Feb 13 17:51:39 2002 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 RAA23446 for ; Wed, 13 Feb 2002 17:51:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b7n2-0003XC-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 16:22:12 -0600 Received: from mailhost.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b7mz-0003Wq-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 16:22:09 -0600 Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id LAA02858; Thu, 14 Feb 2002 11:22:05 +1300 (NZDT) From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Cc: bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu, n.brownlee@auckland.ac.nz Subject: [ipfix] WG process: a proposal In-Reply-To: <011f01c1b454$8dfcebe0$850f880a@slc252750> Message-ID: Date: Thu, 14 Feb 2002 11:23:25 +1300 (New Zealand Daylight Time) X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Precedence: bulk Sender: majordomo listserver Hello all: Various people have been asking for some direction from the WG chairs as to where we're heading with the two current documents. After some discussion between Dave and myself, I'd like to suggest the following: A: Background 1) At the Salt Lake City IETF we called for volunteers to work on the two IPFIX documents, as set out in the WG charter. About 20 people volunteered. 2) After an initial flurry of discussion on the IPFIX list, things went quiet. We set up some extra sub-lists to help the design team members get some initial discussions going. 3) KC Norseth stepped forward and posted some skeleton documents. These were simply lists of section headings based on the 'IPFIX requirements' document. 4) KC also proposed a design teleconference. That idea was welcomed, and the conference was scheduled for 31 January. 5) At that point a group from Cisco, led by Benoit and Ganesh, came forward with a much more complete document, which they published as an individual Internet draft, so everyone could read it and comment. This was a very considerable contribution to the WG. 6) The teleconference was held, with many people participating. Minutes were posted on the list. Since then there has been a *lot* of discussion on the list and sublists. Many people (including those from Cisco) have contributed text, which KC has edited together to form a second document. This will shortly be published as a second individual draft. 7) We now have two documents, each with lots of worthwhile material in them. I suspect there is a feeling that these are, somehow, competing proposals - this is not the case. Both are serious contributions to the WG effort. B: What next? From the WG co-chairs point of view, any documents being produced as WG drafts need to be the result of open discussion in the WG, i.e. on its mailing list. The co-chairs' role is to facilitate discussion, and to guide it towards actually delivering documents as per the WG's charter goals. Decisions about the technical merit of text in various sections of the document needs to be decided by consensus on the list. Ideally, we'd like to get to the next IETF meeting (Minneapolis in March) with a single document to review / discuss / amend. So how can we achieve that? I propose that 1) We form a small 'editorial' team, with two people from those working on each of the two current documents (4 altogether). 2) We ask the editorial team to merge the documents together, and publish the resulting document(s) as IPFX WG drafts. 3) The members of the design team - i.e. all those who've contributed text to the drafts - will be listed in the 'Acknowledgements' section of all drafts produced. The editors of each document will appear as the document authors. 4) Watching the mailing list discussion, this is starting to happen as a natural development anyway. Agreeing to proceed in this way would simply introduce a little formality to it, and make the process clear to everyone. One other comment. This WG has certainly generated plenty of interesting discussion on its mailing list. It's clear that all those involved are putting a lot of effort into our goal of producing the best technical solutions. Thanks all round. I'd like comments / feedback on this notion from all concerned, please. In particular, if we can agree to proceed in this way, we need to decide who's on the editorial team ... Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P -- 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 Feb 13 17:58:48 2002 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 RAA23591 for ; Wed, 13 Feb 2002 17:58:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b824-0003tp-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 16:37:44 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b81z-0003tI-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 16:37:39 -0600 Received: from riverstonenet.com (134.141.180.79 [134.141.180.79]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZKKC; Wed, 13 Feb 2002 14:36:23 -0800 Message-ID: <3C6AEA65.B04974D3@riverstonenet.com> Date: Wed, 13 Feb 2002 17:36:21 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Nevil Brownlee CC: ipfix@net.doit.wisc.edu, bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu Subject: Re: [ipfix] WG process: a proposal References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Fine with me. I have strong interest in being on the data document's editorial team. Paul Nevil Brownlee wrote: > > Hello all: > > Various people have been asking for some direction from the WG chairs > as to where we're heading with the two current documents. After some > discussion between Dave and myself, I'd like to suggest the following: > > A: Background > > 1) At the Salt Lake City IETF we called for volunteers to work on > the two IPFIX documents, as set out in the WG charter. About > 20 people volunteered. > > 2) After an initial flurry of discussion on the IPFIX list, things > went quiet. We set up some extra sub-lists to help the design > team members get some initial discussions going. > > 3) KC Norseth stepped forward and posted some skeleton documents. > These were simply lists of section headings based on the > 'IPFIX requirements' document. > > 4) KC also proposed a design teleconference. That idea was > welcomed, and the conference was scheduled for 31 January. > > 5) At that point a group from Cisco, led by Benoit and Ganesh, > came forward with a much more complete document, which they > published as an individual Internet draft, so everyone could > read it and comment. This was a very considerable contribution > to the WG. > > 6) The teleconference was held, with many people participating. > Minutes were posted on the list. Since then there has been > a *lot* of discussion on the list and sublists. Many people > (including those from Cisco) have contributed text, which KC > has edited together to form a second document. This will > shortly be published as a second individual draft. > > 7) We now have two documents, each with lots of worthwhile material > in them. I suspect there is a feeling that these are, somehow, > competing proposals - this is not the case. Both are serious > contributions to the WG effort. > > B: What next? > > From the WG co-chairs point of view, any documents being produced as > WG drafts need to be the result of open discussion in the WG, i.e. on > its mailing list. The co-chairs' role is to facilitate discussion, > and to guide it towards actually delivering documents as per the WG's > charter goals. Decisions about the technical merit of text in various > sections of the document needs to be decided by consensus on the list. > > Ideally, we'd like to get to the next IETF meeting (Minneapolis in > March) with a single document to review / discuss / amend. So how > can we achieve that? > > I propose that > > 1) We form a small 'editorial' team, with two people from those > working on each of the two current documents (4 altogether). > > 2) We ask the editorial team to merge the documents together, > and publish the resulting document(s) as IPFX WG drafts. > > 3) The members of the design team - i.e. all those who've contributed > text to the drafts - will be listed in the 'Acknowledgements' > section of all drafts produced. The editors of each document > will appear as the document authors. > > 4) Watching the mailing list discussion, this is starting to > happen as a natural development anyway. Agreeing to proceed > in this way would simply introduce a little formality to it, > and make the process clear to everyone. > > One other comment. This WG has certainly generated plenty of interesting > discussion on its mailing list. It's clear that all those involved > are putting a lot of effort into our goal of producing the best > technical solutions. Thanks all round. > > I'd like comments / feedback on this notion from all concerned, please. > In particular, if we can agree to proceed in this way, we need to > decide who's on the editorial team ... > > Cheers, Nevil > > +---------------------------------------------------------------------+ > | Nevil Brownlee Director, Technology Development | > | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | > +---------------------------------------------------------------------P > > -- > 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/ -- 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 Feb 13 18:11:52 2002 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 SAA23860 for ; Wed, 13 Feb 2002 18:11:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b8Gm-0004Jw-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 16:52:56 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b8Gj-0004Jm-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 16:52:53 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id SAA00476; Wed, 13 Feb 2002 18:02:14 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma000469; Wed, 13 Feb 02 18:01:22 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYX3V3F>; Wed, 13 Feb 2002 17:50:54 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06C4@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Nevil Brownlee'" , ipfix@net.doit.wisc.edu Cc: bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu, "K.C. Norseth" , "Norseth, KC" Subject: RE: [ipfix] WG process: a proposal Date: Wed, 13 Feb 2002 17:51:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4E0.F13F8370" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4E0.F13F8370 Content-Type: text/plain Sounds great. I would like to be on the team. I have been working on a comparitive analysis on the docs, section by section. This could be of help in the merge process. I could get that out tonight if wanted. Each set of documents have strong features and weak features that together would form a solid document. K.C. |-----Original Message----- |From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] |Sent: Wednesday, February 13, 2002 3:23 PM |To: ipfix@net.doit.wisc.edu |Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; |plonka@doit.wisc.edu; n.brownlee@auckland.ac.nz |Subject: [ipfix] WG process: a proposal | | | |Hello all: | |Various people have been asking for some direction from the WG chairs |as to where we're heading with the two current documents. |After some discussion between Dave and myself, I'd like to |suggest the following: | |A: Background | |1) At the Salt Lake City IETF we called for volunteers to work on | the two IPFIX documents, as set out in the WG charter. About | 20 people volunteered. | |2) After an initial flurry of discussion on the IPFIX list, things | went quiet. We set up some extra sub-lists to help the design | team members get some initial discussions going. | |3) KC Norseth stepped forward and posted some skeleton documents. | These were simply lists of section headings based on the | 'IPFIX requirements' document. | |4) KC also proposed a design teleconference. That idea was | welcomed, and the conference was scheduled for 31 January. | |5) At that point a group from Cisco, led by Benoit and Ganesh, | came forward with a much more complete document, which they | published as an individual Internet draft, so everyone could | read it and comment. This was a very considerable contribution | to the WG. | |6) The teleconference was held, with many people participating. | Minutes were posted on the list. Since then there has been | a *lot* of discussion on the list and sublists. Many people | (including those from Cisco) have contributed text, which KC | has edited together to form a second document. This will | shortly be published as a second individual draft. | |7) We now have two documents, each with lots of worthwhile material | in them. I suspect there is a feeling that these are, somehow, | competing proposals - this is not the case. Both are serious | contributions to the WG effort. | |B: What next? | |From the WG co-chairs point of view, any documents being |produced as WG drafts need to be the result of open discussion |in the WG, i.e. on its mailing list. The co-chairs' role is |to facilitate discussion, |and to guide it towards actually delivering documents as per |the WG's charter goals. Decisions about the technical merit |of text in various sections of the document needs to be |decided by consensus on the list. | |Ideally, we'd like to get to the next IETF meeting (Minneapolis in |March) with a single document to review / discuss / amend. So |how can we achieve that? | |I propose that | |1) We form a small 'editorial' team, with two people from those | working on each of the two current documents (4 altogether). | |2) We ask the editorial team to merge the documents together, | and publish the resulting document(s) as IPFX WG drafts. | |3) The members of the design team - i.e. all those who've contributed | text to the drafts - will be listed in the 'Acknowledgements' | section of all drafts produced. The editors of each document | will appear as the document authors. | |4) Watching the mailing list discussion, this is starting to | happen as a natural development anyway. Agreeing to proceed | in this way would simply introduce a little formality to it, | and make the process clear to everyone. | |One other comment. This WG has certainly generated plenty of |interesting discussion on its mailing list. It's clear that |all those involved are putting a lot of effort into our goal |of producing the best |technical solutions. Thanks all round. | |I'd like comments / feedback on this notion from all |concerned, please. In particular, if we can agree to proceed |in this way, we need to decide who's on the editorial team ... | |Cheers, Nevil | |+---------------------------------------------------------------------+ || Nevil Brownlee Director, Technology Development | || Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | || FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | |+---------------------------------------------------------------------P | | |-- |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/ | ------_=_NextPart_001_01C1B4E0.F13F8370 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] WG process: a proposal

Sounds great.  I would like to be on the = team. 

I have been working on a comparitive analysis on the = docs, section by section.  This could be of help in the merge = process.  I could get that out tonight if wanted.  Each set = of documents have strong features and weak features that together would = form a solid document.

K.C.


|-----Original Message-----
|From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.= nz]
|Sent: Wednesday, February 13, 2002 3:23 PM
|To: ipfix@net.doit.wisc.edu
|Cc: bclaise@cisco.com; gsadasiv@cisco.com; = kcn@norseth.com;
|plonka@doit.wisc.edu; = n.brownlee@auckland.ac.nz
|Subject: [ipfix] WG process: a proposal
|
|
|
|Hello all:
|
|Various people have been asking for some direction = from the WG chairs
|as to where we're heading with the two current = documents. 
|After some discussion between Dave and myself, I'd = like to
|suggest the following:
|
|A: Background
|
|1) At the Salt Lake City IETF we called for = volunteers to work on
|   the two IPFIX documents, as set out in = the WG charter.  About
|   20 people volunteered.
|
|2) After an initial flurry of discussion on the = IPFIX list, things
|   went quiet.  We set up some extra = sub-lists to help the design
|   team members get some initial = discussions going.
|
|3) KC Norseth stepped forward and posted some = skeleton documents.
|   These were simply lists of section = headings based on the
|   'IPFIX requirements' document.
|
|4) KC also proposed a design teleconference.  = That idea was
|   welcomed, and the conference was = scheduled for 31 January.
|
|5) At that point a group from Cisco, led by Benoit = and Ganesh,
|   came forward with a much more complete = document, which they
|   published as an individual Internet = draft, so everyone could
|   read it and comment.  This was a = very considerable contribution
|   to the WG.
|
|6) The teleconference was held, with many people = participating.
|   Minutes were posted on the list.  = Since then there has been
|   a *lot* of discussion on the list and = sublists.  Many people
|   (including those from Cisco) have = contributed text, which KC
|   has edited together to form a second = document.  This will
|   shortly be published as a second = individual draft.
|
|7) We now have two documents, each with lots of = worthwhile material
|   in them.  I suspect there is a = feeling that these are, somehow,
|   competing proposals - this is not the = case.  Both are serious
|   contributions to the WG effort.
|
|B: What next?
|
|From the WG co-chairs point of view, any documents = being
|produced as WG drafts need to be the result of open = discussion
|in the WG, i.e. on its mailing list.  The = co-chairs' role is
|to facilitate discussion,
|and to guide it towards actually delivering = documents as per
|the WG's charter goals.  Decisions about the = technical merit
|of text in various sections of the document needs = to be
|decided by consensus on the list.
|
|Ideally, we'd like to get to the next IETF meeting = (Minneapolis in
|March) with a single document to review / discuss / = amend.  So
|how can we achieve that?
|
|I propose that
|
|1) We form a small 'editorial' team, with two = people from those
|   working on each of the two current = documents (4 altogether).
|
|2) We ask the editorial team to merge the documents = together,
|   and publish the resulting document(s) = as IPFX WG drafts.
|
|3) The members of the design team - i.e. all those = who've contributed
|   text to the drafts - will be listed in = the 'Acknowledgements'
|   section of all drafts produced. The = editors of each document
|   will appear as the document = authors.
|
|4) Watching the mailing list discussion, this is = starting to
|   happen as a natural development = anyway.  Agreeing to proceed
|   in this way would simply introduce a = little formality to it,
|   and make the process clear to = everyone.
|
|One other comment. This WG has certainly generated = plenty of
|interesting discussion on its mailing list.  = It's clear that
|all those involved are putting a lot of effort into = our goal
|of producing the best
|technical solutions.  Thanks all round.
|
|I'd like comments / feedback on this notion from = all
|concerned, please. In particular, if we can agree = to proceed
|in this way, we need to decide who's on the = editorial team ...
|
|Cheers, Nevil
|
|+-------------------------------------------------------------= --------+
|| Nevil = Brownlee          &nbs= p;          Director, = Technology Development |
|| Phone: +64 9 373 7599 = x8941        ITSS, The University of = Auckland |
||   FAX: +64 9 373 = 7021      Private Bag 92019, Auckland, New = Zealand |
|+-------------------------------------------------------------= --------P
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1B4E0.F13F8370-- -- 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 Feb 13 18:25:11 2002 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 SAA24093 for ; Wed, 13 Feb 2002 18:25:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b8S5-0004en-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 17:04:37 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b8S2-0004e6-00; Wed, 13 Feb 2002 17:04:35 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1DN44g04546; Thu, 14 Feb 2002 00:04:04 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA23509; Thu, 14 Feb 2002 00:04:01 +0100 Date: Thu, 14 Feb 2002 00:05:50 +0100 From: Juergen Quittek To: calato@riverstonenet.com cc: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: [ipfix-data] Re: [ipfix] Draft updates - Comments on the data model Message-ID: <32868311.1013645150@[192.168.102.31]> In-Reply-To: <3C6AC729.4B87EA4A@riverstonenet.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, --On 13 February 2002 15:06 -0500 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> Hi Paul, >> >> --On 13 February 2002 07:54 -0500 calato@riverstonenet.com wrote: >> >> > quittek@ccrle.nec.de wrote: >> >> >> [...] >> >> > >> >> > Now if I want to see all the traffic for my >> >> > virtual IP's I just look for flows that have >> >> > the same src or dest virtual address. I don't >> >> > need a list and the query is simple. Also, the >> >> > data in the fields is clear. The actual field >> >> > is where the packet actually came from or >> >> > went to. The virtual is the requested source >> >> > or destination. >> >> >> >> Are you suggesting to have Src, Src-received, Src-Transmitted, >> >> Src-Virtual, Src-Actual as five different IE identifiers? >> >> This seems to be overloaded. >> > >> > No, we only need actual and virtual for both source >> > and destination. Not sure if there is a better word >> > for virtual but it is all I could come up with. It just >> > indicates the address is not where the packet really went to >> > or came from. I thought virtual worked, but I'm open >> > to others. >> >> I still have problems with the semantics of "virtual". At some >> NATs both sides may be virtual or both may have public network >> addresses. What is then virtual is an interpretation and there >> might be different ones. Therefore I prefer semantics being >> unambiguous, at least from the point of the meter, > > I think it is unambiguous at the NAT doing the reporting. > Actual is where the NAT device knows (from its view) > the packet came from or went to and virtual is where > the packet was supposed to go or come from. > > I assume this is more than a wording issue but > if you don't like actual and virtual, how about actual > and original? > >> for example >> "received" and "transmitted" >> "original" and "modified" > > I agree these are easier to understand but I > believe they are less useful as I pointed out > in previous examples. This information > is only available at the NAT device and will > be lost if we report it as you suggest. > > Also, how do we represent MAC redirects. In your definition, > received and transmitted IP are the same but reporting > that is not interesting. I want to know what server > actually handled the packet. It can be represented > in my scheme. > > Maybe we need to sit down at the next meeting and > hash it over then. Yes, this is probably the best we can do. Anyway, this is not the final version of the draft, so for now I am fine with any of the choices we discussed. Juergen > >> What is virtual can be interpreted by an application reciving >> input from the data collector. >> >> 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 Feb 13 18:40:58 2002 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 SAA24295 for ; Wed, 13 Feb 2002 18:40:58 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b8nO-00052w-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 17:26:38 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b8S2-0004e6-00; Wed, 13 Feb 2002 17:04:35 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1DN44g04546; Thu, 14 Feb 2002 00:04:04 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA23509; Thu, 14 Feb 2002 00:04:01 +0100 Date: Thu, 14 Feb 2002 00:05:50 +0100 From: Juergen Quittek To: calato@riverstonenet.com cc: Reinaldo Penno , "K.C. Norseth" , ipfix@net.doit.wisc.edu, data Subject: Re: [ipfix] Draft updates - Comments on the data model Message-ID: <32868311.1013645150@[192.168.102.31]> In-Reply-To: <3C6AC729.4B87EA4A@riverstonenet.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, --On 13 February 2002 15:06 -0500 calato@riverstonenet.com wrote: > Juergen Quittek wrote: >> >> Hi Paul, >> >> --On 13 February 2002 07:54 -0500 calato@riverstonenet.com wrote: >> >> > quittek@ccrle.nec.de wrote: >> >> >> [...] >> >> > >> >> > Now if I want to see all the traffic for my >> >> > virtual IP's I just look for flows that have >> >> > the same src or dest virtual address. I don't >> >> > need a list and the query is simple. Also, the >> >> > data in the fields is clear. The actual field >> >> > is where the packet actually came from or >> >> > went to. The virtual is the requested source >> >> > or destination. >> >> >> >> Are you suggesting to have Src, Src-received, Src-Transmitted, >> >> Src-Virtual, Src-Actual as five different IE identifiers? >> >> This seems to be overloaded. >> > >> > No, we only need actual and virtual for both source >> > and destination. Not sure if there is a better word >> > for virtual but it is all I could come up with. It just >> > indicates the address is not where the packet really went to >> > or came from. I thought virtual worked, but I'm open >> > to others. >> >> I still have problems with the semantics of "virtual". At some >> NATs both sides may be virtual or both may have public network >> addresses. What is then virtual is an interpretation and there >> might be different ones. Therefore I prefer semantics being >> unambiguous, at least from the point of the meter, > > I think it is unambiguous at the NAT doing the reporting. > Actual is where the NAT device knows (from its view) > the packet came from or went to and virtual is where > the packet was supposed to go or come from. > > I assume this is more than a wording issue but > if you don't like actual and virtual, how about actual > and original? > >> for example >> "received" and "transmitted" >> "original" and "modified" > > I agree these are easier to understand but I > believe they are less useful as I pointed out > in previous examples. This information > is only available at the NAT device and will > be lost if we report it as you suggest. > > Also, how do we represent MAC redirects. In your definition, > received and transmitted IP are the same but reporting > that is not interesting. I want to know what server > actually handled the packet. It can be represented > in my scheme. > > Maybe we need to sit down at the next meeting and > hash it over then. Yes, this is probably the best we can do. Anyway, this is not the final version of the draft, so for now I am fine with any of the choices we discussed. Juergen > >> What is virtual can be interpreted by an application reciving >> input from the data collector. >> >> 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 Feb 13 18:50:31 2002 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 SAA24420 for ; Wed, 13 Feb 2002 18:50:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b8wB-0005FK-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 17:35:43 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b8w8-0005Eg-00 for ipfix-req@net.doit.wisc.edu; Wed, 13 Feb 2002 17:35:40 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1DNZ9g04659; Thu, 14 Feb 2002 00:35:09 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA23721; Thu, 14 Feb 2002 00:35:07 +0100 Date: Thu, 14 Feb 2002 00:36:55 +0100 From: Juergen Quittek To: Reinaldo Penno , calato@riverstonenet.com, Benoit Claise cc: Sebastian Zander , ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Message-ID: <34734104.1013647015@[192.168.102.31]> In-Reply-To: <4F973E944951D311B6660008C7917CF008A1493D@zsc4c008.us.nortel.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo, --On 13 February 2002 13:05 -0800 Reinaldo Penno wrote: > > Well, we need to make a decision if we are going to have > configuration in-band or not. And if yes, what can be > configured. I'm not sure how Benoit et al feel about this. Neither am I. But I can tell you my position: I would not do in-band configuration. Our charter tells us to "select a protocol by which IP flow information can be transferred" and I would prefer not to go beyond this. I am not saying that the charter clearly forbids in-band configuration, but in case of doubt it seems to be a good choice to follow the charter. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > regards, > > Reinaldo > >> -----Original Message----- >> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >> Sent: Wednesday, February 13, 2002 5:15 AM >> To: Benoit Claise >> Cc: Sebastian Zander; Juergen Quittek; ipfix-req@net.doit.wisc.edu >> Subject: Re: [ipfix-req] Proposed changes to >> draft-ietf-ipfix-reqs-00.txt >> >> >> >> Not sure what you mean by "the big principals" but >> it is important to list both what you are covering >> and what you are intentionally not covering. Saying >> configuration is out-of-band and out of scope seems >> appropriate (assuming that is what we agree to). >> >> But even that cannot be used as the golden rule. For >> example, I still think configuring which fields to >> send should be done in band. >> -- 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 Feb 13 19:19:43 2002 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 TAA24736 for ; Wed, 13 Feb 2002 19:19:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b9Jp-0005lM-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 18:00:09 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b9Jn-0005iA-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 18:00:07 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1DNtBY10226; Wed, 13 Feb 2002 17:55:11 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFYCKJ>; Wed, 13 Feb 2002 15:55:09 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A14BBB@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, Nevil Brownlee Cc: ipfix@net.doit.wisc.edu, bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu Subject: RE: [ipfix] WG process: a proposal Date: Wed, 13 Feb 2002 15:55:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B4E9.DDB8F3F0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B4E9.DDB8F3F0 Content-Type: text/plain; charset="iso-8859-1" I agree with this. I would prefer to be on the IPfix architecture editorial team. regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Wednesday, February 13, 2002 2:36 PM >To: Nevil Brownlee >Cc: ipfix@net.doit.wisc.edu; bclaise@cisco.com; gsadasiv@cisco.com; >kcn@norseth.com; plonka@doit.wisc.edu >Subject: Re: [ipfix] WG process: a proposal > > > >Fine with me. > >I have strong interest in being on the >data document's editorial team. > >Paul > >Nevil Brownlee wrote: >> >> Hello all: >> >> Various people have been asking for some direction from the WG chairs >> as to where we're heading with the two current documents. After some >> discussion between Dave and myself, I'd like to suggest the >following: >> >> A: Background >> >> 1) At the Salt Lake City IETF we called for volunteers to work on >> the two IPFIX documents, as set out in the WG charter. About >> 20 people volunteered. >> >> 2) After an initial flurry of discussion on the IPFIX list, things >> went quiet. We set up some extra sub-lists to help the design >> team members get some initial discussions going. >> >> 3) KC Norseth stepped forward and posted some skeleton documents. >> These were simply lists of section headings based on the >> 'IPFIX requirements' document. >> >> 4) KC also proposed a design teleconference. That idea was >> welcomed, and the conference was scheduled for 31 January. >> >> 5) At that point a group from Cisco, led by Benoit and Ganesh, >> came forward with a much more complete document, which they >> published as an individual Internet draft, so everyone could >> read it and comment. This was a very considerable contribution >> to the WG. >> >> 6) The teleconference was held, with many people participating. >> Minutes were posted on the list. Since then there has been >> a *lot* of discussion on the list and sublists. Many people >> (including those from Cisco) have contributed text, which KC >> has edited together to form a second document. This will >> shortly be published as a second individual draft. >> >> 7) We now have two documents, each with lots of worthwhile material >> in them. I suspect there is a feeling that these are, somehow, >> competing proposals - this is not the case. Both are serious >> contributions to the WG effort. >> >> B: What next? >> >> From the WG co-chairs point of view, any documents being produced as >> WG drafts need to be the result of open discussion in the WG, i.e. on >> its mailing list. The co-chairs' role is to facilitate discussion, >> and to guide it towards actually delivering documents as per the WG's >> charter goals. Decisions about the technical merit of text >in various >> sections of the document needs to be decided by consensus on >the list. >> >> Ideally, we'd like to get to the next IETF meeting (Minneapolis in >> March) with a single document to review / discuss / amend. So how >> can we achieve that? >> >> I propose that >> >> 1) We form a small 'editorial' team, with two people from those >> working on each of the two current documents (4 altogether). >> >> 2) We ask the editorial team to merge the documents together, >> and publish the resulting document(s) as IPFX WG drafts. >> >> 3) The members of the design team - i.e. all those who've contributed >> text to the drafts - will be listed in the 'Acknowledgements' >> section of all drafts produced. The editors of each document >> will appear as the document authors. >> >> 4) Watching the mailing list discussion, this is starting to >> happen as a natural development anyway. Agreeing to proceed >> in this way would simply introduce a little formality to it, >> and make the process clear to everyone. >> >> One other comment. This WG has certainly generated plenty of >interesting >> discussion on its mailing list. It's clear that all those involved >> are putting a lot of effort into our goal of producing the best >> technical solutions. Thanks all round. >> >> I'd like comments / feedback on this notion from all >concerned, please. >> In particular, if we can agree to proceed in this way, we need to >> decide who's on the editorial team ... >> >> Cheers, Nevil >> >> >+---------------------------------------------------------------------+ >> | Nevil Brownlee Director, Technology >Development | >> | Phone: +64 9 373 7599 x8941 ITSS, The University of >Auckland | >> | FAX: +64 9 373 7021 Private Bag 92019, Auckland, >New Zealand | >> >+---------------------------------------------------------------------P >> >> -- >> 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/ > >-- >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/ > ------_=_NextPart_001_01C1B4E9.DDB8F3F0 Content-Type: text/html; charset="iso-8859-1" RE: [ipfix] WG process: a proposal

I agree with this.

I would prefer to be on the IPfix architecture editorial team.

regards,

Reinaldo

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com]
>Sent: Wednesday, February 13, 2002 2:36 PM
>To: Nevil Brownlee
>Cc: ipfix@net.doit.wisc.edu; bclaise@cisco.com; gsadasiv@cisco.com;
>kcn@norseth.com; plonka@doit.wisc.edu
>Subject: Re: [ipfix] WG process: a proposal
>
>
>
>Fine with me.
>
>I have strong interest in being on the
>data document's editorial team.
>
>Paul
>
>Nevil Brownlee wrote:
>>
>> Hello all:
>>
>> Various people have been asking for some direction from the WG chairs
>> as to where we're heading with the two current documents.  After some
>> discussion between Dave and myself, I'd like to suggest the
>following:
>>
>> A: Background
>>
>> 1) At the Salt Lake City IETF we called for volunteers to work on
>>    the two IPFIX documents, as set out in the WG charter.  About
>>    20 people volunteered.
>>
>> 2) After an initial flurry of discussion on the IPFIX list, things
>>    went quiet.  We set up some extra sub-lists to help the design
>>    team members get some initial discussions going.
>>
>> 3) KC Norseth stepped forward and posted some skeleton documents.
>>    These were simply lists of section headings based on the
>>    'IPFIX requirements' document.
>>
>> 4) KC also proposed a design teleconference.  That idea was
>>    welcomed, and the conference was scheduled for 31 January.
>>
>> 5) At that point a group from Cisco, led by Benoit and Ganesh,
>>    came forward with a much more complete document, which they
>>    published as an individual Internet draft, so everyone could
>>    read it and comment.  This was a very considerable contribution
>>    to the WG.
>>
>> 6) The teleconference was held, with many people participating.
>>    Minutes were posted on the list.  Since then there has been
>>    a *lot* of discussion on the list and sublists.  Many people
>>    (including those from Cisco) have contributed text, which KC
>>    has edited together to form a second document.  This will
>>    shortly be published as a second individual draft.
>>
>> 7) We now have two documents, each with lots of worthwhile material
>>    in them.  I suspect there is a feeling that these are, somehow,
>>    competing proposals - this is not the case.  Both are serious
>>    contributions to the WG effort.
>>
>> B: What next?
>>
>> From the WG co-chairs point of view, any documents being produced as
>> WG drafts need to be the result of open discussion in the WG, i.e. on
>> its mailing list.  The co-chairs' role is to facilitate discussion,
>> and to guide it towards actually delivering documents as per the WG's
>> charter goals.  Decisions about the technical merit of text
>in various
>> sections of the document needs to be decided by consensus on
>the list.
>>
>> Ideally, we'd like to get to the next IETF meeting (Minneapolis in
>> March) with a single document to review / discuss / amend.  So how
>> can we achieve that?
>>
>> I propose that
>>
>> 1) We form a small 'editorial' team, with two people from those
>>    working on each of the two current documents (4 altogether).
>>
>> 2) We ask the editorial team to merge the documents together,
>>    and publish the resulting document(s) as IPFX WG drafts.
>>
>> 3) The members of the design team - i.e. all those who've contributed
>>    text to the drafts - will be listed in the 'Acknowledgements'
>>    section of all drafts produced. The editors of each document
>>    will appear as the document authors.
>>
>> 4) Watching the mailing list discussion, this is starting to
>>    happen as a natural development anyway.  Agreeing to proceed
>>    in this way would simply introduce a little formality to it,
>>    and make the process clear to everyone.
>>
>> One other comment. This WG has certainly generated plenty of
>interesting
>> discussion on its mailing list.  It's clear that all those involved
>> are putting a lot of effort into our goal of producing the best
>> technical solutions.  Thanks all round.
>>
>> I'd like comments / feedback on this notion from all
>concerned, please.
>> In particular, if we can agree to proceed in this way, we need to
>> decide who's on the editorial team ...
>>
>> Cheers, Nevil
>>
>>
>+---------------------------------------------------------------------+
>> | Nevil Brownlee                     Director, Technology
>Development |
>> | Phone: +64 9 373 7599 x8941        ITSS, The University of
>Auckland |
>> |   FAX: +64 9 373 7021      Private Bag 92019, Auckland,
>New Zealand |
>>
>+---------------------------------------------------------------------P
>>
>> --
>> 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/
>
>--
>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/
>

------_=_NextPart_001_01C1B4E9.DDB8F3F0-- -- 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 Feb 13 19:20:50 2002 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 TAA24755 for ; Wed, 13 Feb 2002 19:20:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b9M7-0005p8-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 18:02:31 -0600 Received: from c001-h007.c001.snv.cp.net ([209.228.32.121] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16b9M5-0005o9-00 for ipfix-data@net.doit.wisc.edu; Wed, 13 Feb 2002 18:02:29 -0600 Received: (cpmta 28793 invoked from network); 13 Feb 2002 16:01:57 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.121) with SMTP; 13 Feb 2002 16:01:57 -0800 X-Sent: 14 Feb 2002 00:01:57 GMT Message-ID: <003d01c1b4eb$31096ca0$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: , References: Subject: [ipfix-data] Re: [ipfix] WG process: a proposal Date: Wed, 13 Feb 2002 17:04:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Design team people. Reguardless of what happens, send me your contributions to update in the team drafts. They are important and will be incorporated. K.C. ----- Original Message ----- From: Nevil Brownlee To: Cc: ; ; ; ; Sent: Wednesday, February 13, 2002 3:23 PM Subject: [ipfix] WG process: a proposal | | Hello all: | | Various people have been asking for some direction from the WG chairs | as to where we're heading with the two current documents. After some | discussion between Dave and myself, I'd like to suggest the following: | | A: Background | | 1) At the Salt Lake City IETF we called for volunteers to work on | the two IPFIX documents, as set out in the WG charter. About | 20 people volunteered. | | 2) After an initial flurry of discussion on the IPFIX list, things | went quiet. We set up some extra sub-lists to help the design | team members get some initial discussions going. | | 3) KC Norseth stepped forward and posted some skeleton documents. | These were simply lists of section headings based on the | 'IPFIX requirements' document. | | 4) KC also proposed a design teleconference. That idea was | welcomed, and the conference was scheduled for 31 January. | | 5) At that point a group from Cisco, led by Benoit and Ganesh, | came forward with a much more complete document, which they | published as an individual Internet draft, so everyone could | read it and comment. This was a very considerable contribution | to the WG. | | 6) The teleconference was held, with many people participating. | Minutes were posted on the list. Since then there has been | a *lot* of discussion on the list and sublists. Many people | (including those from Cisco) have contributed text, which KC | has edited together to form a second document. This will | shortly be published as a second individual draft. | | 7) We now have two documents, each with lots of worthwhile material | in them. I suspect there is a feeling that these are, somehow, | competing proposals - this is not the case. Both are serious | contributions to the WG effort. | | B: What next? | | From the WG co-chairs point of view, any documents being produced as | WG drafts need to be the result of open discussion in the WG, i.e. on | its mailing list. The co-chairs' role is to facilitate discussion, | and to guide it towards actually delivering documents as per the WG's | charter goals. Decisions about the technical merit of text in various | sections of the document needs to be decided by consensus on the list. | | Ideally, we'd like to get to the next IETF meeting (Minneapolis in | March) with a single document to review / discuss / amend. So how | can we achieve that? | | I propose that | | 1) We form a small 'editorial' team, with two people from those | working on each of the two current documents (4 altogether). | | 2) We ask the editorial team to merge the documents together, | and publish the resulting document(s) as IPFX WG drafts. | | 3) The members of the design team - i.e. all those who've contributed | text to the drafts - will be listed in the 'Acknowledgements' | section of all drafts produced. The editors of each document | will appear as the document authors. | | 4) Watching the mailing list discussion, this is starting to | happen as a natural development anyway. Agreeing to proceed | in this way would simply introduce a little formality to it, | and make the process clear to everyone. | | One other comment. This WG has certainly generated plenty of interesting | discussion on its mailing list. It's clear that all those involved | are putting a lot of effort into our goal of producing the best | technical solutions. Thanks all round. | | I'd like comments / feedback on this notion from all concerned, please. | In particular, if we can agree to proceed in this way, we need to | decide who's on the editorial team ... | | Cheers, Nevil | | +---------------------------------------------------------------------+ | | Nevil Brownlee Director, Technology Development | | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | | +---------------------------------------------------------------------P | | | -- | 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/ | -- 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 Feb 13 19:20:57 2002 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 TAA24770 for ; Wed, 13 Feb 2002 19:20:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b9M8-0005pA-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 18:02:32 -0600 Received: from c001-h007.c001.snv.cp.net ([209.228.32.121] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16b9M5-0005oA-00 for ipfix-arch@net.doit.wisc.edu; Wed, 13 Feb 2002 18:02:29 -0600 Received: (cpmta 28793 invoked from network); 13 Feb 2002 16:01:57 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.121) with SMTP; 13 Feb 2002 16:01:57 -0800 X-Sent: 14 Feb 2002 00:01:57 GMT Message-ID: <003d01c1b4eb$31096ca0$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: , References: Subject: [ipfix-arch] Re: [ipfix] WG process: a proposal Date: Wed, 13 Feb 2002 17:04:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Design team people. Reguardless of what happens, send me your contributions to update in the team drafts. They are important and will be incorporated. K.C. ----- Original Message ----- From: Nevil Brownlee To: Cc: ; ; ; ; Sent: Wednesday, February 13, 2002 3:23 PM Subject: [ipfix] WG process: a proposal | | Hello all: | | Various people have been asking for some direction from the WG chairs | as to where we're heading with the two current documents. After some | discussion between Dave and myself, I'd like to suggest the following: | | A: Background | | 1) At the Salt Lake City IETF we called for volunteers to work on | the two IPFIX documents, as set out in the WG charter. About | 20 people volunteered. | | 2) After an initial flurry of discussion on the IPFIX list, things | went quiet. We set up some extra sub-lists to help the design | team members get some initial discussions going. | | 3) KC Norseth stepped forward and posted some skeleton documents. | These were simply lists of section headings based on the | 'IPFIX requirements' document. | | 4) KC also proposed a design teleconference. That idea was | welcomed, and the conference was scheduled for 31 January. | | 5) At that point a group from Cisco, led by Benoit and Ganesh, | came forward with a much more complete document, which they | published as an individual Internet draft, so everyone could | read it and comment. This was a very considerable contribution | to the WG. | | 6) The teleconference was held, with many people participating. | Minutes were posted on the list. Since then there has been | a *lot* of discussion on the list and sublists. Many people | (including those from Cisco) have contributed text, which KC | has edited together to form a second document. This will | shortly be published as a second individual draft. | | 7) We now have two documents, each with lots of worthwhile material | in them. I suspect there is a feeling that these are, somehow, | competing proposals - this is not the case. Both are serious | contributions to the WG effort. | | B: What next? | | From the WG co-chairs point of view, any documents being produced as | WG drafts need to be the result of open discussion in the WG, i.e. on | its mailing list. The co-chairs' role is to facilitate discussion, | and to guide it towards actually delivering documents as per the WG's | charter goals. Decisions about the technical merit of text in various | sections of the document needs to be decided by consensus on the list. | | Ideally, we'd like to get to the next IETF meeting (Minneapolis in | March) with a single document to review / discuss / amend. So how | can we achieve that? | | I propose that | | 1) We form a small 'editorial' team, with two people from those | working on each of the two current documents (4 altogether). | | 2) We ask the editorial team to merge the documents together, | and publish the resulting document(s) as IPFX WG drafts. | | 3) The members of the design team - i.e. all those who've contributed | text to the drafts - will be listed in the 'Acknowledgements' | section of all drafts produced. The editors of each document | will appear as the document authors. | | 4) Watching the mailing list discussion, this is starting to | happen as a natural development anyway. Agreeing to proceed | in this way would simply introduce a little formality to it, | and make the process clear to everyone. | | One other comment. This WG has certainly generated plenty of interesting | discussion on its mailing list. It's clear that all those involved | are putting a lot of effort into our goal of producing the best | technical solutions. Thanks all round. | | I'd like comments / feedback on this notion from all concerned, please. | In particular, if we can agree to proceed in this way, we need to | decide who's on the editorial team ... | | Cheers, Nevil | | +---------------------------------------------------------------------+ | | Nevil Brownlee Director, Technology Development | | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | | +---------------------------------------------------------------------P | | | -- | 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/ | -- 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 Feb 13 19:43:28 2002 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 TAA25002 for ; Wed, 13 Feb 2002 19:43:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16b9jr-0006JQ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 13 Feb 2002 18:27:03 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16b9jo-0006Ii-00 for ipfix@net.doit.wisc.edu; Wed, 13 Feb 2002 18:27:00 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1E0Q7g04796; Thu, 14 Feb 2002 01:26:08 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id BAA24034; Thu, 14 Feb 2002 01:26:04 +0100 Date: Thu, 14 Feb 2002 01:27:52 +0100 From: Juergen Quittek To: Nevil Brownlee , ipfix@net.doit.wisc.edu cc: bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu Subject: Re: [ipfix] WG process: a proposal Message-ID: <37790469.1013650072@[192.168.102.31]> In-Reply-To: X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil and Dave, Thank you for the guidance. This sounds very reasonable. But we have to hurry, because we have to submit the drafts until Friday 22nd. I volunteer for the editorial team. Some futher comments are inline. Juergen --On 14 February 2002 11:23 +1300 Nevil Brownlee wrote: > > Hello all: > > Various people have been asking for some direction from the WG chairs > as to where we're heading with the two current documents. After some > discussion between Dave and myself, I'd like to suggest the following: > > A: Background > > 1) At the Salt Lake City IETF we called for volunteers to work on > the two IPFIX documents, as set out in the WG charter. About > 20 people volunteered. > > 2) After an initial flurry of discussion on the IPFIX list, things > went quiet. We set up some extra sub-lists to help the design > team members get some initial discussions going. > > 3) KC Norseth stepped forward and posted some skeleton documents. > These were simply lists of section headings based on the > 'IPFIX requirements' document. > > 4) KC also proposed a design teleconference. That idea was > welcomed, and the conference was scheduled for 31 January. > > 5) At that point a group from Cisco, led by Benoit and Ganesh, > came forward with a much more complete document, which they > published as an individual Internet draft, so everyone could > read it and comment. This was a very considerable contribution > to the WG. > > 6) The teleconference was held, with many people participating. > Minutes were posted on the list. Since then there has been > a *lot* of discussion on the list and sublists. Many people > (including those from Cisco) have contributed text, which KC > has edited together to form a second document. This will > shortly be published as a second individual draft. > > 7) We now have two documents, each with lots of worthwhile material > in them. I suspect there is a feeling that these are, somehow, > competing proposals - this is not the case. Both are serious > contributions to the WG effort. > > B: What next? > > From the WG co-chairs point of view, any documents being produced as > WG drafts need to be the result of open discussion in the WG, i.e. on > its mailing list. The co-chairs' role is to facilitate discussion, > and to guide it towards actually delivering documents as per the WG's > charter goals. Decisions about the technical merit of text in various > sections of the document needs to be decided by consensus on the list. I'm afraid that we will not achieve this for the first version of the documents, because there are still several open issues and only eight days left. But we can work towards consensus on remaining open issues in Minneapolis and then update the documents accordingly. > Ideally, we'd like to get to the next IETF meeting (Minneapolis in > March) with a single document to review / discuss / amend. So how > can we achieve that? I guess you mean two documents? > I propose that > > 1) We form a small 'editorial' team, with two people from those > working on each of the two current documents (4 altogether). > > 2) We ask the editorial team to merge the documents together, > and publish the resulting document(s) as IPFX WG drafts. > > 3) The members of the design team - i.e. all those who've contributed > text to the drafts - will be listed in the 'Acknowledgements' > section of all drafts produced. The editors of each document > will appear as the document authors. > > 4) Watching the mailing list discussion, this is starting to > happen as a natural development anyway. Agreeing to proceed > in this way would simply introduce a little formality to it, > and make the process clear to everyone. > > One other comment. This WG has certainly generated plenty of interesting > discussion on its mailing list. It's clear that all those involved > are putting a lot of effort into our goal of producing the best > technical solutions. Thanks all round. > > I'd like comments / feedback on this notion from all concerned, please. > In particular, if we can agree to proceed in this way, we need to > decide who's on the editorial team ... > > Cheers, Nevil > > +---------------------------------------------------------------------+ > | Nevil Brownlee Director, Technology Development | > | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | > +---------------------------------------------------------------------P > > > -- > 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/ > -- 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 Feb 14 05:31:31 2002 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 FAA14746 for ; Thu, 14 Feb 2002 05:31:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bIrp-0002ad-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 04:11:53 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bIro-0002aF-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 04:11:52 -0600 Received: from fokus.fhg.de (dhcp187 [195.37.78.187]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1EABnp19148; Thu, 14 Feb 2002 11:11:49 +0100 (MET) Message-ID: <3C6B8C60.708AEE87@fokus.fhg.de> Date: Thu, 14 Feb 2002 11:07:28 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again References: <21033130.1013633314@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, Juergen Quittek schrieb: > > Hi all, > > We had some terminology discussion and it has not > converged yet. Therfore I like to raise one issue again: > > For the terinology section of the requirements draft > (I belive now it will be a subset of the architecture's > terminology) I would like to have two identifiers for > the following: > > 1. the function block containing all metering functions > This block gets as input observed (and potentially > sampled) packets from the observation point. It classifies > packets maps them to flows and creates/updates the > according flow record. > > 2. the function block sending flow records to the collector > > I am fine with splitting blocks more or modifying them > slightly, but I prefer to have this separation, because > also the requirements are split in a very similar way. I also would like to split those for at least 2 reasons. First we create a more general model because on a router linecard both are be combined but on a dedicated hardware/software based meter this will probably not the case. I don't think we should limit ipfix to routers only. Second the separation is nice to clarify the scope. The scope of the ipfix wg is to standardize the exporter (at least the interface to the outside). It's out of scope to standardize the meter (although we put some req. on it). I am not sure whether sampling is a function of the observation point or the meter. > My initial naive suggestion was calling block 1. "meter" > and calling block 2. "exporter". However this might (no it > did already) cause confusion. Therefore, I am looking for > better terms. Any suggestions? I have no better terms. I think what's maybe confusing is that we don't have a term for the overall process (meter+exporter+observation). What could be appropriate? flow monitor? Another possibility: Name the overall process metering and rename the inner function block 1 which does classification etc. Sebastian -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Feb 14 06:33:00 2002 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 GAA15292 for ; Thu, 14 Feb 2002 06:33:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bJqx-00056w-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 05:15:03 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bJqv-00056p-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 05:15:01 -0600 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EBGsQ25049 for ; Thu, 14 Feb 2002 05:16:54 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Feb 2002 05:15:00 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 05:15:00 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 14 Feb 2002 06:14:58 -0500 Message-ID: Thread-Topic: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Thread-Index: AcG06EeHdaGKtVQwRmCPjrTCWSbKrAAYDo1Q From: To: , , , Cc: , X-OriginalArrivalTime: 14 Feb 2002 11:15:00.0063 (UTC) FILETIME=[D77CAEF0:01C1B548] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA15292 Hello, See my inline comments. >Our charter tells us to "select a protocol by which >IP flow information can be transferred" and I would >prefer not to go beyond this. Transfer of flow information may not refer only to monitoring. I interpreted as one can monitor and then transfer ( exchange) flows between endpoints . To do this one has to configure first what we are interested in - that means configure, monitor and transfer flows. I am not sure and would like to get clarify my doubt, If we have in-band management what is the problem? It's is a good choice whether there is no flaw and it is good to control from one place to do both configure and manage the network elements. If we provide proper security mechanism and ensure that the devices gets the proper commands similar to CLI then what's the problem ? I can understand currently most of network elements configuration happens thro' CLI or other mechanisms.... Take for example SNMP is used only as monitoring tool and but people are working on to making configuration also thro' SNMP and seperate activity is going on in IETF community itself. Regards Ramg -- 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 Feb 14 06:52:30 2002 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 GAA15502 for ; Thu, 14 Feb 2002 06:52:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bK2m-0005Vs-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 05:27:16 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bK2j-0005Vl-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 05:27:14 -0600 Received: from fokus.fhg.de (dhcp206 [195.37.78.206]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1EBR8p07716; Thu, 14 Feb 2002 12:27:08 +0100 (MET) Message-ID: <3C6B9E6B.2040701@fokus.fhg.de> Date: Thu, 14 Feb 2002 12:24:27 +0100 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: quittek@ccrle.nec.de CC: Benoit Claise , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Re: [ipfix] Terminology suggestion References: <200202111529.g1BFTnb27134@bru-cse-222.cisco.com> <1013472201.3c685bc97479f@citadel.mobility.ccrle.nec.de> Content-Type: multipart/alternative; boundary="------------030003070700020203090502" Precedence: bulk Sender: majordomo listserver --------------030003070700020203090502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.gmd.de id g1EBR8p07716 Content-Transfer-Encoding: quoted-printable Hi J=FCrgen and others, In order to prevent mixing up the devices and the processes that run on=20 the devices I would suggest to define the components it in the following=20 way. - Keep the definition of the metering process as suggested in 2.4 by J=FC= rgen - Rename 2.6 (exporter) into exporting process - Define the exporter as the device on which one (or more) metering=20 processes and at least one exporting process run. There can be meters that do not run an exporting process but exporters=20 without metering process would not make sense. Therefore I prefer to use=20 the term exporter for the device on which both processes run (metering=20 and exporting) and distinguish it from a meter which can be defined as a=20 device that runs only metering processes. So you can see an exporter as=20 a meter device that additonally runs a flow exporting process. Furthermore I agree with Benoit that sampling should be seen as part of=20 the metering process. . Regards Tanja quittek@ccrle.nec.de wrote: >Hi Benoit, > >Benoit Claise wrote: > >>Hi Juergen, >> >>Here are my input on this terminology, as promised during the conf. >>call. >> >>Note that whether the definitions go into the requirements draft or in >>the architecture doesn't make any difference to me. This only thing of >>importance is that, if the requirement draft dissapears with the time, >>we don't want to loose the defintions. One solution is that the >>architecture document will have to repeat the definitions. >> >>>see draft-ietf-ipfix-reqs-00.txt, section 1.1 >>> >>I just copied the definition from draft-ietf-ipfix-reqs-00.txt for >>completeness. >> A flow is a set of packets passing an observation point in the >> network during a certain time interval. All packets belonging to = a >> particular flow have a set of common properties derived from the >> data contained in the packet and from the packet treatment at the >> observation point. >> >>I would go a little bit further in the definition, by describing what a >>property coul be: >> A flow is defined as a set of packets passing an observation point i= n the >> network during a certain time interval. All packets belonging to a >> particular flow have a set of common properties. Each property is >> defined as the result of applying a function to the values of: >> >> a. one or more of packet header fields (eg. destination IP address= ) >> b. one or more properties of the packet itself (eg. packet length) >> c. one or more of fields derived from packet treatment (eg. AS >> number) >> >> A packet is defined to belong to a flow if it matches all the define= d >> properties of the flow. >> > >Fine. But we should mention somewhere that also partial matches might be >sufficient. > >>>2.2. Observation Point >>>The observation point is a location in the network where IP packets >>>can be observed. Examples are a line to which a probe is attached, >>>a shared medium, such as an Ethernet-based LAN, a port of a router, >>>or an entire router with several ports. >>> >>I agree with the definition above, but I would be more specific: >>The observation point is a location in the network where IP packets >>can be observed. Examples are a line to which a probe is attached, >>a shared medium, such as an Ethernet-based LAN, a port of a router, >>or an entire router with several ports. The observation is characterize= d >>by one or a set of interfaces (physical or logical) of the exporter. >> > >I think the last sentence is too restrictive. Why excluding packet >samplers sending samples from a remote observation point to a meter? > >>Note: the exporter is defined below. >> >>>2.3. Trafic Flow Meter or Meter >>>A meter observes packets at one or more observation points. >>>It analyzes the content of the packets and maps them to flows. >>>For each observed flow the meter computes statistics and maintains >>>a flow record where it stores relevant flow infromation. >>> >>I think that the concept of exporter makes more sense. >>And I believe that you are mixing 2 definitions: >> > >No, it's just the opposite: I want to separate meter and exporter. >=20 > >>- the exporter (ex: a router or a probe) >>- the metering process which analyzes the traffic >>So I would just remove this definition and leave the exporter/metering >>process=20 >>as 2 definitions. >> >> * Exporter: The entity on which flows are measured and are >> exported. The exporter can be a router, a middlebox [2], or a >> traffic measurement probe. >> > >Here you are mixing metering and exporting. > >I see two function blocks in our architecture: The meter executing the >metering process and the exporter participating as sender in the flow >information export process. > >>>2.4. Metering Process >>>The metering process includes all actions performed by a meter >>>with respect to observing packets, timestamping them, analyzing them, >>>mapping them to flows, computing flow statistics, detecting flow >>>expiration, and maintaining flow records. >>> >>Measurement process that is carried out at the observation domain. >>The metering process includes all actions performed by a meter >>with respect to observing packets, timestamping them, analyzing them, >>mapping them to flows, computing flow statistics, detecting flow >>expiration, and maintaining flow records. >> >>Note: we had to introduce the concept of observation domain. >> >> * Observation Domain: The set of observation points which is the >> largest aggregatable set of flow information at the exporter is >> termed as an observation domain. The observation domain presents >> itself a unique ID to the collector for identifying the export >> packets generated by it. >> >> Example: The observation domian could be a router linecard, >> composed of several interfaces with each interface being an >> observation point. >> >>Why the concept of observation domain? >>Typically for a linecard on a router, which is an independant entity. >>So an exporter can be composed of several observation domains (read >>linecards). >>There is one metering process per observation domain (read linecard).=20 >>You can do flow aggregations for these linecard flows but not between >>flows from different linecards. >> > >Well you are approaching my hierarchy:=20 >exporter - meter - observation point > >The meter processes (and aggregates) packets from one or more >observation points and generates flow records. The sum of its >observation points outlines your observation domain. >The exporter exports flow records produced by one or more meters. > >First you say is "delete the term of meter" and then >"add the term of observation domain", because now we need it. > >If you just keep the meter, you do not need the observation >domain and you have an concept which is easier to understand >and which also matches the function blocks of the architecture. > >>Note: I agree that we are missing a high level picture of this in >>draft-gsadasiv-ipfix-proposal-00.txt >> >>>2.5. Flow Record >>>A flow record keeps information a flow including characteristic >>>properties of the flow, for example the source IP address, >>>and measured properties of the flow, for example the total number >>>of bytes of all packets of the flow. >>> >>All packets belonging to a particular flow have a set of common >>properties. >>But the flow record doesn't necessarily have the notion of its own >>properties. >>I would remove the properties part.=20 >>Here is the definition I would propose. >> >> * Flow Record: A flow record provides information about a specific >> flow that was measured at an observation point using a certain >> set of methods within an exporter. >> >>>2.6. Flow Information Exporter or Exporter >>>The exporter sends flow records created and maintained by one or >>>more meters to one or more data collectors. >>> >>See my previous remark about exporter versus meter >> > >dito > >>>2.7. Flow Information Data Collector or Data Collector >>>The data collector receives flow records from one or more exporters. >>>The data collector might process or store received flow record, >>>but these actions are out of the scope of this document. >>> >>OK. We called it just collector. But this is just a detail! >> > >Fine. What about the heading "Flow Information Collector or Collector" >and then renaming all data collectors into collectors? > >Best wishes, > > Juergen > >>Regards, Benoit. >> >> >>>2.8. Flow Information Export >>>Flow information export denotes the process of transferring flow >>>records from an exporter to a data collector. >>> >>> >>>-- >>>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/ >>> >> > >-- >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/ > --=20 Dipl.-Ing. Tanja Zseby =09 FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de=09 Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------= -------------=20 "Living on earth is expensive but it includes a free trip around the sun.= " (Anonymous) -------------------------------------------------------------------------= ------------- --------------030003070700020203090502 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jürgen and others,

In order to prevent mixing up the devices and the processes that run on the devices I would suggest to define the components it in the following way.
- Keep the definition of  the metering process as suggested in 2.4 by Jürgen
- Rename 2.6 (exporter) into exporting process
- Define the exporter as the device on which one (or more) metering processes and at least one exporting process run.
There can be meters that do not run an exporting process but exporters without metering process would not make sense. Therefore I prefer to use the term exporter for the device on which both processes run (metering and exporting) and distinguish it from a meter which can be defined as a device that runs only metering processes. So you can see an exporter as a meter device that additonally runs a flow exporting process.
Furthermore I agree with Benoit that sampling should be seen as part of the metering process. .

Regards
Tanja

quittek@ccrle.nec.de wrote:
Hi Benoit,

Benoit Claise <bclaise@cisco.com> wrote:

Hi Juergen,

Here are my input on this terminology, as promised during the conf.
call.

Note that whether the definitions go into the requirements draft or in
the architecture doesn't make any difference to me. This only thing of
importance is that, if the requirement draft dissapears with the time,
we don't want to loose the defintions. One solution is that the
architecture document will have to repeat the definitions.

see draft-ietf-ipfix-reqs-00.txt, section 1.1
I just copied the definition from draft-ietf-ipfix-reqs-00.txt for
completeness.
      A flow is a set of packets passing an observation point in the
      network during a certain time interval. All packets belonging to a
      particular flow have a set of common properties derived from the
      data contained in the packet and from the packet treatment at the
      observation point.

I would go a little bit further in the definition, by describing what a
property coul be:
   A flow is defined as a set of packets passing an observation point in the
   network during a certain time interval. All packets belonging to a
   particular flow have a set of common properties.  Each property is
   defined as the result of applying a function to the values of:

     a. one or more of packet header fields (eg. destination IP address)
     b. one or more properties of the packet itself (eg. packet length)
     c. 
one or more of fields derived from packet treatment (eg. AS
        number)

   A packet is defined to belong to a flow if it matches all the defined
   properties of the flow.

Fine. But we should mention somewhere that also partial matches might be
sufficient.

2.2.   Observation Point
The observation point is a location in the network where IP packets
can be observed.  Examples are a line to which a probe is attached,
a shared medium, such as an Ethernet-based LAN,  a port of a router,
or an entire router with several ports.
I agree with the definition above, but I would be more specific:
The observation point is a location in the network where IP packets
can be observed.  Examples are a line to which a probe is attached,
a shared medium, such as an Ethernet-based LAN, a port of a router,
or an entire router with several ports. The observation is characterized
by one or a set of interfaces (physical or logical) of the exporter.

I think the last sentence is too restrictive. Why excluding packet
samplers sending samples from a remote observation point to a meter?

Note: the exporter is defined below.
2.3.   Trafic Flow Meter or Meter
A  meter observes packets at one or more observation points.
It analyzes the content of the packets and maps them to flows.
For each observed flow the meter computes statistics and maintains
a flow record where it stores relevant flow infromation.
I think that the concept of exporter makes more sense.
And I believe that you are mixing 2 definitions:

No, it's just the opposite: I want to separate meter and exporter.
 
- the exporter (ex: a router or a probe)
- the metering process which analyzes the traffic
So I would just remove this definition and leave the exporter/metering
process 
as 2 definitions.

     * Exporter: The entity on which flows are measured and are
       exported. The exporter can be a router, a middlebox [2], or a
       traffic measurement probe.

Here you are mixing metering and exporting.

I see two function blocks in our architecture: The meter executing the
metering process and the exporter participating as sender in the flow
information export process.

2.4.   Metering Process
The metering process includes all actions performed by a meter
with respect to observing packets, timestamping them, analyzing them,
mapping them to flows, computing flow statistics, detecting flow
expiration, and maintaining flow records.
Measurement process that is carried out at the observation domain.
The metering process includes all actions performed by a meter
with respect to observing packets, timestamping them, analyzing them,
mapping them to flows, computing flow statistics, detecting flow
expiration, and maintaining flow records.

Note: we had to introduce the concept of observation domain.

     * Observation Domain: The set of observation points which is the
       largest aggregatable set of flow information at the exporter is
       termed as an observation domain. The observation domain presents
       itself a unique ID to the collector for identifying the export
       packets generated by it.

       Example: The observation domian could be a router linecard,
       composed of several interfaces with each interface being an
       observation point.

Why the concept of observation domain?
Typically for
 a linecard on a router, which is an independant entity.
So an exporter can be composed of several observation domains (read
linecards).
There is one metering process per observation domain (read linecard). 
You can do flow aggregations for these linecard flows but not between
flows from different linecards.

Well you are approaching my hierarchy: 
exporter - meter - observation point

The meter processes (and aggregates) packets from one or more
observation points and generates flow records. The sum of its
observation points outlines your observation domain.
The exporter exports flow records produced by one or more meters.

First you say is "delete the term of meter" and then
"add the term of observation domain", because now we need it.

If you just keep the meter, you do not need the observation
domain and you have an concept which is easier to understand
and which also matches the function blocks of the architecture.

Note: I agree that we are missing a high level picture of this in
draft-gsadasiv-ipfix-proposal-00.txt

2.5.   Flow Record
A flow record keeps information a flow including characteristic
properties of the flow, for example the source IP address,
and measured properties of the flow, for example the total number
of bytes of all packets of the flow.
All packets belonging to a particular flow have a set of common
properties.
But the flow record doesn't necessarily have the notion of its own
properties.
I would remove the properties part. 
Here is the definition I would propose.

     * Flow Record: A flow record provides information about a specific
       flow that was measured at an observation point using a certain
       set of methods within an exporter.
2.6.   Flow Information Exporter or Exporter
The exporter sends flow records created and maintained by one or
more meters to one or more data collectors.
See my previous remark about exporter versus meter

dito

2.7.  Flow Information Data Collector or Data Collector
The data collector receives flow records from one or more exporters.
The data collector might process or store received flow record,
but these actions are out of the scope of this document.
OK. We called it just collector. But this is just a detail!

Fine. What about the heading "Flow Information Collector or Collector"
and then renaming all data collectors into collectors?

Best wishes,

    Juergen

Regards, Benoit.


2.8.   Flow Information Export
Flow information export denotes the process of transferring flow
records from an exporter to a data collector.


--
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/



--
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/

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: zseby@fokus.fhg.de	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

--------------030003070700020203090502-- -- 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 Feb 14 07:06:42 2002 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 HAA15974 for ; Thu, 14 Feb 2002 07:06:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bKGR-00065l-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 05:41:23 -0600 Received: from mgw-x2.nokia.com ([131.228.20.22]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bKGO-00065b-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 05:41:21 -0600 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EBfQZ09820 for ; Thu, 14 Feb 2002 13:41:26 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Feb 2002 13:41:18 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Feb 2002 13:41:18 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 05:41:15 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipfix] WG process: a proposal X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 14 Feb 2002 06:41:14 -0500 Message-ID: Thread-Topic: [ipfix] WG process: a proposal Thread-Index: AcG03z1E6Xn4eBURTpiMg6FNUjZmKAAbkJ5A From: To: , Cc: , , , X-OriginalArrivalTime: 14 Feb 2002 11:41:15.0979 (UTC) FILETIME=[82CE61B0:01C1B54C] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA15974 I want to part of editorial team regards ramg >-----Original Message----- >From: ext Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] >Sent: Wednesday, February 13, 2002 5:23 PM >To: ipfix@net.doit.wisc.edu >Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; >plonka@doit.wisc.edu; n.brownlee@auckland.ac.nz >Subject: [ipfix] WG process: a proposal > > > >Hello all: > >Various people have been asking for some direction from the WG chairs >as to where we're heading with the two current documents. After some >discussion between Dave and myself, I'd like to suggest the following: > >A: Background > >1) At the Salt Lake City IETF we called for volunteers to work on > the two IPFIX documents, as set out in the WG charter. About > 20 people volunteered. > >2) After an initial flurry of discussion on the IPFIX list, things > went quiet. We set up some extra sub-lists to help the design > team members get some initial discussions going. > >3) KC Norseth stepped forward and posted some skeleton documents. > These were simply lists of section headings based on the > 'IPFIX requirements' document. > >4) KC also proposed a design teleconference. That idea was > welcomed, and the conference was scheduled for 31 January. > >5) At that point a group from Cisco, led by Benoit and Ganesh, > came forward with a much more complete document, which they > published as an individual Internet draft, so everyone could > read it and comment. This was a very considerable contribution > to the WG. > >6) The teleconference was held, with many people participating. > Minutes were posted on the list. Since then there has been > a *lot* of discussion on the list and sublists. Many people > (including those from Cisco) have contributed text, which KC > has edited together to form a second document. This will > shortly be published as a second individual draft. > >7) We now have two documents, each with lots of worthwhile material > in them. I suspect there is a feeling that these are, somehow, > competing proposals - this is not the case. Both are serious > contributions to the WG effort. > >B: What next? > >From the WG co-chairs point of view, any documents being produced as >WG drafts need to be the result of open discussion in the WG, i.e. on >its mailing list. The co-chairs' role is to facilitate discussion, >and to guide it towards actually delivering documents as per the WG's >charter goals. Decisions about the technical merit of text in various >sections of the document needs to be decided by consensus on the list. > >Ideally, we'd like to get to the next IETF meeting (Minneapolis in >March) with a single document to review / discuss / amend. So how >can we achieve that? > >I propose that > >1) We form a small 'editorial' team, with two people from those > working on each of the two current documents (4 altogether). > >2) We ask the editorial team to merge the documents together, > and publish the resulting document(s) as IPFX WG drafts. > >3) The members of the design team - i.e. all those who've contributed > text to the drafts - will be listed in the 'Acknowledgements' > section of all drafts produced. The editors of each document > will appear as the document authors. > >4) Watching the mailing list discussion, this is starting to > happen as a natural development anyway. Agreeing to proceed > in this way would simply introduce a little formality to it, > and make the process clear to everyone. > >One other comment. This WG has certainly generated plenty of >interesting >discussion on its mailing list. It's clear that all those involved >are putting a lot of effort into our goal of producing the best >technical solutions. Thanks all round. > >I'd like comments / feedback on this notion from all concerned, please. >In particular, if we can agree to proceed in this way, we need to >decide who's on the editorial team ... > >Cheers, Nevil > >+---------------------------------------------------------------------+ >| Nevil Brownlee Director, Technology Development | >| Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | >| FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | >+---------------------------------------------------------------------P > > >-- >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/ > -- 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 Feb 14 07:06:55 2002 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 HAA15987 for ; Thu, 14 Feb 2002 07:06:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bKHl-00068q-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 05:42:45 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bKHj-00068j-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 05:42:43 -0600 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EBiXQ26403 for ; Thu, 14 Feb 2002 05:44:33 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Feb 2002 05:42:40 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 05:42:39 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipfix] WG process: a proposal X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 14 Feb 2002 06:42:38 -0500 Message-ID: Thread-Topic: [ipfix] WG process: a proposal Thread-Index: AcG03z1E6Xn4eBURTpiMg6FNUjZmKAAbmmiw From: To: , Cc: , , , X-OriginalArrivalTime: 14 Feb 2002 11:42:39.0995 (UTC) FILETIME=[B4E234B0:01C1B54C] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA15987 I want to be part of editorial team for architecture document regards ramg >-----Original Message----- >From: ext Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] >Sent: Wednesday, February 13, 2002 5:23 PM >To: ipfix@net.doit.wisc.edu >Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; >plonka@doit.wisc.edu; n.brownlee@auckland.ac.nz >Subject: [ipfix] WG process: a proposal > > > >Hello all: > >Various people have been asking for some direction from the WG chairs >as to where we're heading with the two current documents. After some >discussion between Dave and myself, I'd like to suggest the following: > >A: Background > >1) At the Salt Lake City IETF we called for volunteers to work on > the two IPFIX documents, as set out in the WG charter. About > 20 people volunteered. > >2) After an initial flurry of discussion on the IPFIX list, things > went quiet. We set up some extra sub-lists to help the design > team members get some initial discussions going. > >3) KC Norseth stepped forward and posted some skeleton documents. > These were simply lists of section headings based on the > 'IPFIX requirements' document. > >4) KC also proposed a design teleconference. That idea was > welcomed, and the conference was scheduled for 31 January. > >5) At that point a group from Cisco, led by Benoit and Ganesh, > came forward with a much more complete document, which they > published as an individual Internet draft, so everyone could > read it and comment. This was a very considerable contribution > to the WG. > >6) The teleconference was held, with many people participating. > Minutes were posted on the list. Since then there has been > a *lot* of discussion on the list and sublists. Many people > (including those from Cisco) have contributed text, which KC > has edited together to form a second document. This will > shortly be published as a second individual draft. > >7) We now have two documents, each with lots of worthwhile material > in them. I suspect there is a feeling that these are, somehow, > competing proposals - this is not the case. Both are serious > contributions to the WG effort. > >B: What next? > >From the WG co-chairs point of view, any documents being produced as >WG drafts need to be the result of open discussion in the WG, i.e. on >its mailing list. The co-chairs' role is to facilitate discussion, >and to guide it towards actually delivering documents as per the WG's >charter goals. Decisions about the technical merit of text in various >sections of the document needs to be decided by consensus on the list. > >Ideally, we'd like to get to the next IETF meeting (Minneapolis in >March) with a single document to review / discuss / amend. So how >can we achieve that? > >I propose that > >1) We form a small 'editorial' team, with two people from those > working on each of the two current documents (4 altogether). > >2) We ask the editorial team to merge the documents together, > and publish the resulting document(s) as IPFX WG drafts. > >3) The members of the design team - i.e. all those who've contributed > text to the drafts - will be listed in the 'Acknowledgements' > section of all drafts produced. The editors of each document > will appear as the document authors. > >4) Watching the mailing list discussion, this is starting to > happen as a natural development anyway. Agreeing to proceed > in this way would simply introduce a little formality to it, > and make the process clear to everyone. > >One other comment. This WG has certainly generated plenty of >interesting >discussion on its mailing list. It's clear that all those involved >are putting a lot of effort into our goal of producing the best >technical solutions. Thanks all round. > >I'd like comments / feedback on this notion from all concerned, please. >In particular, if we can agree to proceed in this way, we need to >decide who's on the editorial team ... > >Cheers, Nevil > >+---------------------------------------------------------------------+ >| Nevil Brownlee Director, Technology Development | >| Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | >| FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | >+---------------------------------------------------------------------P > > >-- >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/ > -- 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 Feb 14 07:10:34 2002 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 HAA16099 for ; Thu, 14 Feb 2002 07:10:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bKQU-0006OD-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 05:51:46 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bKQT-0006O6-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 05:51:45 -0600 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EBrcQ26805 for ; Thu, 14 Feb 2002 05:53:38 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Feb 2002 05:51:44 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 05:51:10 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipfix] WG process: a proposal X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 14 Feb 2002 06:51:09 -0500 Message-ID: Thread-Topic: [ipfix] WG process: a proposal Thread-Index: AcG03z1E6Xn4eBURTpiMg6FNUjZmKAAbybPQ From: To: , Cc: , , , X-OriginalArrivalTime: 14 Feb 2002 11:51:10.0560 (UTC) FILETIME=[E5343E00:01C1B54D] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA16099 Sorry, email is slipped twice before i completed the email. I want to be part of editorial team for architecture and data model documents. See my inline comments >I propose that > >1) We form a small 'editorial' team, with two people from those > working on each of the two current documents (4 altogether). > >2) We ask the editorial team to merge the documents together, > and publish the resulting document(s) as IPFX WG drafts. > >3) The members of the design team - i.e. all those who've contributed > text to the drafts - will be listed in the 'Acknowledgements' > section of all drafts produced. The editors of each document > will appear as the document authors. > >4) Watching the mailing list discussion, this is starting to > happen as a natural development anyway. Agreeing to proceed > in this way would simply introduce a little formality to it, > and make the process clear to everyone. > >One other comment. This WG has certainly generated plenty of >interesting >discussion on its mailing list. It's clear that all those involved >are putting a lot of effort into our goal of producing the best >technical solutions. Thanks all round. > >I'd like comments / feedback on this notion from all concerned, please. >In particular, if we can agree to proceed in this way, we need to >decide who's on the editorial team ... > I agree with your suggestions since there may be more voluteers for this activity also how do we restrict the editorial team size. regards ramg -- 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 Feb 14 09:06:18 2002 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 JAA18406 for ; Thu, 14 Feb 2002 09:06:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bMHf-0001MV-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 07:50:47 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bMHb-0001Le-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 07:50:43 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g1EDnn012708; Thu, 14 Feb 2002 14:49:49 +0100 (CET) Date: Thu, 14 Feb 2002 14:49:49 +0100 (CET) From: Benoit Claise Message-Id: <200202141349.g1EDnn012708@bru-cse-222.cisco.com> To: quittek@ccrle.nec.de, ram.gopal@nokia.com Subject: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Cc: zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver Hi Ram and All, We've discussing the in-band configuration for a few times without conclusions. I propose to use this thread to arrive to a rough consensus and close the discussion one for all. Otherwise we're turning in circles and loosing everybody's time! And if we can't get a consensus, the chairmen and area directors will have to take a decision. Note: please let's try to concentrate on just one issue: in-band configuration and not capability negotiation and transport negotiation. One step at the time please. > > > >Our charter tells us to "select a protocol by which > >IP flow information can be transferred" and I would > >prefer not to go beyond this. > > Transfer of flow information may not refer only to monitoring. I interpreted as > one can monitor and then transfer ( exchange) flows between endpoints . To do this one has > to configure first what we are interested in - that means configure, monitor and transfer > flows. > > I am not sure and would like to get clarify my doubt, > > If we have in-band management what is the problem? It's is a good choice whether > there is no flaw and it is good to control from one place to do both configure and manage the network > elements. If we provide proper security mechanism and ensure that the devices gets > the proper commands similar to CLI then what's the problem ? What is the problem, you're asking? There are actually no problems. I agree it would be the perfect world to have in-band configuration. But here are some arguments against the idea. Actually I even think a little bit further: the exporter configuration is out of the scope of this charter. 1. Do you want the working group to spend the time (the money) to developp a comon provisioning protocol, IF this is even possible to have an agreement on that accross the different vendor (probes and routers), which I think is impossible. 2. What would happen with proprietary features, which most likely will not be part of the IPFIX provisioning protocol. So anyway we will have to use a different way of provisioning the device, like CLI for example, next to IPFIX. This will bypass the use of IPFIX provisioning protocol. 3. How many vendors would implement this in-band configuration? Because at the end this is the final question. What's the point to have a IETF protocol that no/not many vendors are going to implement. Do you think that vendors will spend time and money to developp again another configuration interface, next to CLI, SNMP, XML, etc...? And this just for an IPFIX protocol! 4. SNMP is widely used. Why? because the S stands for simple. And now, along the time, it has been evolving because there are new needs. I would like to start with something Simple, that everybody agrees on. And if there is a need for in-band configuration, then we can think of IPFIX2. Why trying to have an ISO standard from version 1? ;) You can give me a long list of nice idea about in-band configuration that I'm sure I would love to have in a perfect world but let's start with something Simple. Don't forget that simplicity is the key for interoperability. If not yet convinced: have you already compared Snmp and CMIP? 5. From the charter, "select a protocol by which IP flow information can be transferred" as Juergen said already. I would not beyond this point. OK, you (Ramg) have a different view. 6. IPFIX stands for Flow Information eXport. So we have to standardize the export, not the configuration. So the direction:exporter -> collector and not the direction collector -> exporter. At least for version 1. 7. Email from Nevil Brownlee, Subject: [ipfix] Comments on 'goals of IPFX WG' http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html 2. IPFIX is *not* trying to standardise a flow meter, i.e. a network entity which measures flows - we already have RFCs which do that, e.g. those for RTFM (2720 .. 2724). Existing widely-used implementations can remain different, but might perhaps be extended to report flow information in the IPFIX lingua franca. 3. Instead, we recognise that network equipment vendors already have flow measurement systems implemented as part of their equipment. Our goal is to make the IPFIX flow information export system so good technically that all vendors will be happy to implement it, for the benefit of all users of the data. A useful side-effect will be that IPFIX will make it easier to build and maintain interoperable flow data collecting systems. As we're not supposed to standardise a flow meter, why would we standardize its configuration? This email just expresses that the exporter configuration is out of the scope of the charter. 8. Juergen's argument: "Please consider that the meter will be built partially in hardware which is costly. Here we can save a lot by reducing some functions. The data collector implemented by software can be much more flexible with less cost." Regards, Benoit. > > I can understand currently most of network elements configuration happens thro' CLI or other mechanisms.... > > Take for example SNMP is used only as monitoring tool and but people are working on to making configuration > also thro' SNMP and seperate activity is going on in IETF community itself. > > > Regards > Ramg > > > > -- 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 Feb 14 09:33:26 2002 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 JAA19521 for ; Thu, 14 Feb 2002 09:33:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bMfn-0001s2-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 08:15:43 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bMfk-0001r4-00; Thu, 14 Feb 2002 08:15:40 -0600 Received: from riverstonenet.com (134.141.180.101 [134.141.180.101]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZ4DR; Thu, 14 Feb 2002 06:14:26 -0800 Message-ID: <3C6BC640.B9DB5023@riverstonenet.com> Date: Thu, 14 Feb 2002 09:14:25 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, "K.C. Norseth" , ipfixx Subject: [ipfix] Re: MIDCOM first draft References: <4F973E944951D311B6660008C7917CF008A149F9@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Wednesday, February 13, 2002 1:10 PM > >To: Penno, Reinaldo [SC9:T327:EXCH] > >Cc: ipfix-data-volunteers@net.doit.wisc.edu; > >ipfix-arch-volunteers@net.doit.wisc.edu; K.C. Norseth; ipfixx > >Subject: Re: MIDCOM first draft > > > > > >Reinaldo Penno wrote: > >> > >> Hello Paul, > >> > >> comments inline. > >> > >> >-----Original Message----- > >> >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >> >Sent: Wednesday, February 13, 2002 5:34 AM > >> >To: Penno, Reinaldo [SC9:T327:EXCH] > >> >Cc: ipfix-data-volunteers@net.doit.wisc.edu; > >> >ipfix-arch-volunteers@net.doit.wisc.edu; K.C. Norseth; ipfixx > >> >Subject: Re: MIDCOM first draft > >> > > >> > > >> >> > >> >> Hello Paul, > >> >> > >> >> I'll try to be more structured now. > >> >> > >> >> the way it is reported is one thing, but a NAT is by all > purposes > >> (by > >> >> definition) composed of two flows. You can export them in one > >> record > >> >> or two records, but that doesn't change how it should be faced. > >> >> > >> >> would you agree with this? > >> > > >> > I would say no. Since a flow is defined by its key > >> > you cannot take that out of the picture. If the > >> > key is actual-src and actual-destination then > >> > there is only 1 flow and only 1 record. > >> > >> There is no actual src and actual dest. The flow can be > >NATed twice in > >> the same box. It's just how from an aimplementation standpoint you > >> look at it (see below) > >> > > > > Doesn't matter how many times it gets NATed. The end result > > is some IP gets stuffed in the paceket to go out and that is > the > > actual address in the NAT case. The addresses in the middle > > are what I call the virtual addresses (for lack of a > >better term). > > There can be a list of virtual addresses if more than one > > translation takes place. > > well, you do not really know when the translation ended. The packet > might com in a interface and get translated, and then as it goes out > another is translated again. If the intefaces are independent you > would get two records saying that this is the "actual" destination. This is no different than having the packet go through 2 totally separate NAT boxes both of which are reporting on the packets seen. > > Remeber that the collector is the "middlebox controller" in this case. This might be part of the confusion. I speaking from and exporter point of view. We are not defining Collector behavior in IPFIX. > It can be 10 hops away for all we care. It doesn't know where is > inside, outside, virtual or actual from the exporter(s) point of view. Here you switch back to exporter. Not sure if you mean Collector. But in any case, if the exporter is also doing the NAT, it must know what IP it put in the packet (even if it is later translated again) and it must know what IP it took out of the packet. Hence actual and virtual or actual and original if you like that word better. > it will believe what is told and might receive several flow saying > that for a given source, this is the "actual" destination, which IMHO > is misleading. Since any report is from the perspective of the exporter it is correct. What happens later is not we are trying to report. Also, whomever is setting up these NAT sitiations understands their address space. By reporting it as I suggest, I believe more accurately represents the data and allows for more useful data mining later. > > Saying what operation was performed on the packet (NAT, Twice NAT, > etc) and what fields changed (without getting into outside, inside, > virtual, actual, etc) is less confusing in my opinion. But if I > couldn't convince you up to > > know that's okay (;-) I already agreed it iwas less confusuing but I also believe less useful. > > > > >> > > >> > If the key is packet-src, packet-destination then > >> > it would be 2 flows as you suggest. > >> > >> Paul, the "key" is something that we invented. It's an > implementation > >> thing in the same sense that you might prefer to export NAT flows > in > >> one record. But it doesn't change the basic definition. A flow is > >> defined by a 5-tuple. It's basic definition independent of IPfix. > > > > I don't think there is such a standard definition. Unless > > you mean a NAT flow and the NAT RFC defines such a thing > > (I'm not sure if it does or doesn't). ICMP for example does > > not have src and dest port but I'm sure it can be NATed just > > the same. > > It's still a 5-tuple but in the case of ICMP some of the tuples are > missing. RFC 2914 has some discussion on this subject > > "This raises the issue of the appropriate granularity of a "flow", > where we define a `flow' as the level of granularity appropriate > for > the application of both fairness and congestion control. From RFC > 2309: "There are a few `natural' answers: 1) a TCP or UDP > connection > (source address/port, destination address/port); 2) a > source/destination host pair; 3) a given source host or a given > destination host." I know there has been talk of a standard flow definition but I don't see how that can happen. IPFIX will be used to report flows with all types of keys that may or may not overlap with the 5-tuple field set. Even if we agree to the 5-tuple key set, what use will it be. > > IMO NAT is consisted of two flows. Actually after you NAT a packet it > can be dropped by a firewall rule in the same box. A flow that > otherwise wouldn't be dropped if the packet hasn't been modified. You > can also take a step further asying that in the ingress direction > stateful firewalls follow the conversation after the NAT, no before > it. They do not consider the flow before the NAT the same thing, ie, > you cannot send a unsolicited packet with the original addresses > (before the NAT) in it and expect a firewall to accept them. We seem to be arguing over the defintion of a flow. From the IPFIX docs so far, a more general definiton seems to be developing than the 5-tuple mentioned earlier... From reqs: ========== A flow is a set of packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties derived from the data contained in the packet and from the packet treatment at the observation point. From Arch (which matches Cisco doc): =================================== "A flow is a set of packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties derived from the data contained in the packet and from the packet treatment at the observation point." In this draft we define the flow more specifically. A flow is defined as a set of packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: a. one or more of packet header fields (eg. destination IP address) b. one or more properties of the packet itself (eg. packet length) c. one or more of fields derived from packet treatment (eg. AS number) A packet is defined to belong to a flow if it matches all the defined properties of the flow. Flows can be defined in multiple ways. Some examples are: > > Did I convince you? (;-) No yet. Are you going to the next meeting. Maybe Juergen , you amd I can sit down and hash this thing out over a couple beers! > > regards, > > Reinaldo > > >> > >> regards, > >> > >> Reinaldo > > -- 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 Feb 14 09:46:33 2002 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 JAA23086 for ; Thu, 14 Feb 2002 09:46:33 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bMkZ-0001zN-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 08:20:39 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bMkX-0001yW-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 08:20:37 -0600 Received: from Kevinz (1Cust109.tnt5.dca5.da.uu.net [63.61.19.109]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1EELFl31671 for ; Thu, 14 Feb 2002 06:21:15 -0800 Reply-To: From: "Kevin Zhang" To: Subject: RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Thu, 14 Feb 2002 09:22:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA23086 > > Hi All, > > I hope we are not mixing configuration with capability > negotiation. Capability negotiation maybe viewed as a way for > exporter and collector to exchange configuration information > without altering it, it should be included within the scope and > done in-band. As the processing power is distributed among > exporters and collectors, a simple exporter + sophisticated > collectors will still get the job done, and vice versa. > Capability negotiation can at least facilitate this. > > Whether in-band configuration needs to be supported or not, we > need to do a quick poll of IPFIX contributors to gauge the support. > > Thanks, > > Kevin > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Juergen Quittek > > Sent: Wednesday, February 13, 2002 6:37 PM > > To: Reinaldo Penno; calato@riverstonenet.com; Benoit Claise > > Cc: Sebastian Zander; ipfix-req@net.doit.wisc.edu > > Subject: RE: [ipfix-req] Proposed changes to > > draft-ietf-ipfix-reqs-00.txt > > > > > > Reinaldo, > > > > --On 13 February 2002 13:05 -0800 Reinaldo Penno > > wrote: > > > > > > > > Well, we need to make a decision if we are going to have > > > configuration in-band or not. And if yes, what can be > > > configured. I'm not sure how Benoit et al feel about this. > > > > Neither am I. But I can tell you my position: > > I would not do in-band configuration. > > Our charter tells us to "select a protocol by which > > IP flow information can be transferred" and I would > > prefer not to go beyond this. > > > > I am not saying that the charter clearly forbids > > in-band configuration, but in case of doubt it seems > > to be a good choice to follow the charter. > > > > Juergen > > -- > > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > > > > > regards, > > > > > > Reinaldo > > > > > >> -----Original Message----- > > >> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > > >> Sent: Wednesday, February 13, 2002 5:15 AM > > >> To: Benoit Claise > > >> Cc: Sebastian Zander; Juergen Quittek; ipfix-req@net.doit.wisc.edu > > >> Subject: Re: [ipfix-req] Proposed changes to > > >> draft-ietf-ipfix-reqs-00.txt > > >> > > >> > > >> > > >> Not sure what you mean by "the big principals" but > > >> it is important to list both what you are covering > > >> and what you are intentionally not covering. Saying > > >> configuration is out-of-band and out of scope seems > > >> appropriate (assuming that is what we agree to). > > >> > > >> But even that cannot be used as the golden rule. For > > >> example, I still think configuring which fields to > > >> send should be done in band. > > >> > > > > > > > > -- > > 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/ > > > > ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Thu Feb 14 09:46:39 2002 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 JAA23098 for ; Thu, 14 Feb 2002 09:46:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bMp9-00027b-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 08:25:23 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bMp7-00026Y-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 08:25:21 -0600 Received: from riverstonenet.com (134.141.180.101 [134.141.180.101]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZYZ4F3; Thu, 14 Feb 2002 06:24:08 -0800 Message-ID: <3C6BC886.E503DAA6@riverstonenet.com> Date: Thu, 14 Feb 2002 09:24:06 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: quittek@ccrle.nec.de, ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <200202141349.g1EDnn012708@bru-cse-222.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I vote no in-band configuration in IPFIX V1. Benoit Claise wrote: > > Hi Ram and All, > > We've discussing the in-band configuration for a few times without conclusions. > I propose to use this thread to arrive to a rough consensus and close the discussion one for all. Otherwise we're turning in circles and loosing everybody's time! > And if we can't get a consensus, the chairmen and area directors will have to take a decision. > > Note: please let's try to concentrate on just one issue: in-band configuration and not capability negotiation and transport negotiation. One step at the time please. > > > > > > > >Our charter tells us to "select a protocol by which > > >IP flow information can be transferred" and I would > > >prefer not to go beyond this. > > > > Transfer of flow information may not refer only to monitoring. I interpreted as > > one can monitor and then transfer ( exchange) flows between endpoints . To do this one has > > to configure first what we are interested in - that means configure, monitor and transfer > > flows. > > > > I am not sure and would like to get clarify my doubt, > > > > If we have in-band management what is the problem? It's is a good choice whether > > there is no flaw and it is good to control from one place to do both configure and manage the network > > elements. If we provide proper security mechanism and ensure that the devices gets > > the proper commands similar to CLI then what's the problem ? > > What is the problem, you're asking? > There are actually no problems. I agree it would be the perfect world to have in-band configuration. But here are some arguments against the idea. Actually I even think a little bit further: the exporter configuration is out of the scope of this charter. > > 1. Do you want the working group to spend the time (the money) to developp a comon provisioning protocol, IF this is even possible to have an agreement on that accross the different vendor (probes and routers), which I think is impossible. > > 2. What would happen with proprietary features, which most likely will not be part of the IPFIX provisioning protocol. So anyway we will have to use a different way of provisioning the device, like CLI for example, next to IPFIX. This will bypass the use of IPFIX provisioning protocol. > > 3. How many vendors would implement this in-band configuration? > Because at the end this is the final question. What's the point to have a IETF protocol that no/not many vendors are going to implement. > Do you think that vendors will spend time and money to developp again another configuration interface, next to CLI, SNMP, XML, etc...? And this just for an IPFIX protocol! > > 4. SNMP is widely used. Why? because the S stands for simple. > And now, along the time, it has been evolving because there are new needs. > I would like to start with something Simple, that everybody agrees on. > And if there is a need for in-band configuration, then we can think of IPFIX2. > Why trying to have an ISO standard from version 1? ;) > You can give me a long list of nice idea about in-band configuration that I'm sure I would love to have in a perfect world but let's start with something Simple. > Don't forget that simplicity is the key for interoperability. > If not yet convinced: have you already compared Snmp and CMIP? > > 5. From the charter, "select a protocol by which IP flow information can be transferred" as Juergen said already. I would not beyond this point. > OK, you (Ramg) have a different view. > > 6. IPFIX stands for Flow Information eXport. So we have to standardize the export, not the configuration. So the direction:exporter -> collector and not the direction collector -> exporter. At least for version 1. > > 7. Email from Nevil Brownlee, Subject: [ipfix] Comments on 'goals of IPFX WG' > http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html > 2. IPFIX is *not* trying to standardise a flow meter, i.e. a network > entity which measures flows - we already have RFCs which do that, > e.g. those for RTFM (2720 .. 2724). Existing widely-used > implementations can remain different, but might perhaps be extended > to report flow information in the IPFIX lingua franca. > > 3. Instead, we recognise that network equipment vendors already have > flow measurement systems implemented as part of their equipment. > Our goal is to make the IPFIX flow information export system > so good technically that all vendors will be happy to implement > it, for the benefit of all users of the data. A useful side-effect > will be that IPFIX will make it easier to build and maintain > interoperable flow data collecting systems. > > As we're not supposed to standardise a flow meter, why would we standardize its configuration? This email just expresses that the exporter configuration is out of the scope of the charter. > > 8. Juergen's argument: "Please consider that the meter will be built partially in hardware which is costly. Here we can save a lot by reducing some functions. > The data collector implemented by software can be much more flexible > with less cost." > > Regards, Benoit. > > > > > I can understand currently most of network elements configuration happens thro' CLI or other mechanisms.... > > > > Take for example SNMP is used only as monitoring tool and but people are working on to making configuration > > also thro' SNMP and seperate activity is going on in IETF community itself. > > > > > > Regards > > Ramg > > > > > > > > > > -- > 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/ -- 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 Feb 14 09:47:55 2002 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 JAA23124 for ; Thu, 14 Feb 2002 09:47:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bMvg-0002HA-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 08:32:08 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bMvc-0002GD-00; Thu, 14 Feb 2002 08:32:04 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EERjV14403; Thu, 14 Feb 2002 08:27:45 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFYGVM>; Thu, 14 Feb 2002 06:27:43 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A7334F@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: ipfix-data-volunteers@net.doit.wisc.edu, ipfix-arch-volunteers@net.doit.wisc.edu, "K.C. Norseth" , ipfixx Subject: [ipfix] RE: MIDCOM first draft Date: Thu, 14 Feb 2002 06:27:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B563.C33B2EB0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B563.C33B2EB0 Content-Type: text/plain; charset="iso-8859-1" okay, last round before the beers.. >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Thursday, February 14, 2002 6:14 AM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: ipfix-data-volunteers@net.doit.wisc.edu; >ipfix-arch-volunteers@net.doit.wisc.edu; K.C. Norseth; ipfixx >Subject: Re: MIDCOM first draft > > >From reqs: >========== > > A flow is a set of packets passing an observation point in the > network during a certain time interval. All packets >belonging to a > particular flow have a set of common properties derived from the > data contained in the packet and from the packet treatment at the > observation point. > >From Arch (which matches Cisco doc): >=================================== > >"A flow is a set of packets passing an observation point in >the network >during a certain time interval. All packets belonging to a particular >flow have a set of common properties derived from the data contained in >the packet and from the packet treatment at the observation point." > >In this draft we define the flow more specifically. A flow is defined >as a set of packets passing an observation point in the >network during a >certain time interval. All packets belonging to a particular >flow have a >set of common properties. Each property is defined as the result of >applying a function to the values of: > >a. one or more of packet header fields (eg. destination IP address) >b. one or more properties of the packet itself (eg. packet length) >c. one or more of fields derived from packet treatment (eg. AS number) > > >A packet is defined to belong to a flow if it matches all the defined >properties of the flow. Flows can be defined in multiple ways. Some >examples are: > > > In the case of twice NAT (and btw some OPES services or even some SLB stuff), the packets will have nothing in common (except *maybe* same AS). They do not have the same destination IP, source IP or port numbers. The packet length also change..So, they have nothing in common... And on top of that after the NAT the treatment the "flow" might get inside the same box a completely differ from before the NAT (different PHB, firewall, etc, etc) regards, Reinaldo ------_=_NextPart_001_01C1B563.C33B2EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MIDCOM first draft

okay, last round before the beers..

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Thursday, February 14, 2002 6:14 AM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: = ipfix-data-volunteers@net.doit.wisc.edu;
>ipfix-arch-volunteers@net.doit.wisc.edu; K.C. = Norseth; ipfixx
>Subject: Re: MIDCOM first draft
>
>
>From reqs:
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>      A flow is a set = of packets passing an observation point in the
>      network during a = certain time interval. All packets
>belonging to a
>      particular flow = have a set of common properties derived from the
>      data contained in = the packet and from the packet treatment at the
>      observation = point.
>
>From Arch (which matches Cisco doc):
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>"A flow is a set of packets passing an = observation point in
>the network
>during a certain time interval. All packets = belonging to a particular
>flow have a set of common properties derived = from the data contained in
>the packet and from the packet treatment at the = observation point."
>
>In this draft we define the flow more = specifically.  A flow is defined
>as a set of packets passing an observation point = in the
>network during a
>certain time interval. All packets belonging to = a particular
>flow have a
>set of common properties.  Each property is = defined as the result of
>applying a function to the values of:
>
>a. one or more of packet header fields (eg. = destination IP address)
>b. one or more properties of the packet itself = (eg. packet length)
>c. one or more of fields derived from packet = treatment (eg. AS number)
>
>
>A packet is defined to belong to a flow if it = matches all the defined
>properties of the flow. Flows can be defined in = multiple ways. Some
>examples are:
>
>
>

In the case of twice NAT (and btw some OPES services = or even some SLB stuff), the packets will have nothing in common = (except *maybe* same AS). They do not have the same destination IP, = source IP or port numbers.  The packet length also change..So, = they have nothing in common...

And on top of that after the NAT the treatment the = "flow" might get inside the same box a completely differ from = before the NAT (different PHB, firewall, etc, etc)

regards,

Reinaldo

------_=_NextPart_001_01C1B563.C33B2EB0-- -- 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 Feb 14 09:49:04 2002 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 JAA23149 for ; Thu, 14 Feb 2002 09:49:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bMkK-0001yv-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 08:20:24 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bMkH-0001xu-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 08:20:21 -0600 Received: from Kevinz (1Cust109.tnt5.dca5.da.uu.net [63.61.19.109]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1EEKql31662 for ; Thu, 14 Feb 2002 06:20:53 -0800 Reply-To: From: "Kevin Zhang" To: Subject: RE: [ipfix] WG process: a proposal Date: Thu, 14 Feb 2002 09:21:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C1B539.09174D90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C1B539.09174D90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [ipfix] WG process: a proposalMy original message got bounced back. See below. Kevin -----Original Message----- From: Kevin Zhang [mailto:kevin.zhang@xacct.com] Sent: Wednesday, February 13, 2002 6:09 PM To: Norseth, KC; 'Nevil Brownlee'; ipfix@net.doit.wisc.edu Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; plonka@doit.wisc.edu; K.C. Norseth Subject: RE: [ipfix] WG process: a proposal Hi all, I have strong interest to be on the architecture editorial team. Thanks, Kevin -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Norseth, KC Sent: Wednesday, February 13, 2002 5:51 PM To: 'Nevil Brownlee'; ipfix@net.doit.wisc.edu Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; plonka@doit.wisc.edu; K.C. Norseth; Norseth, KC Subject: RE: [ipfix] WG process: a proposal Sounds great. I would like to be on the team. I have been working on a comparitive analysis on the docs, section by section. This could be of help in the merge process. I could get that out tonight if wanted. Each set of documents have strong features and weak features that together would form a solid document. K.C. |-----Original Message----- |From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] |Sent: Wednesday, February 13, 2002 3:23 PM |To: ipfix@net.doit.wisc.edu |Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; |plonka@doit.wisc.edu; n.brownlee@auckland.ac.nz |Subject: [ipfix] WG process: a proposal | | | |Hello all: | |Various people have been asking for some direction from the WG chairs |as to where we're heading with the two current documents. |After some discussion between Dave and myself, I'd like to |suggest the following: | |A: Background | |1) At the Salt Lake City IETF we called for volunteers to work on | the two IPFIX documents, as set out in the WG charter. About | 20 people volunteered. | |2) After an initial flurry of discussion on the IPFIX list, things | went quiet. We set up some extra sub-lists to help the design | team members get some initial discussions going. | |3) KC Norseth stepped forward and posted some skeleton documents. | These were simply lists of section headings based on the | 'IPFIX requirements' document. | |4) KC also proposed a design teleconference. That idea was | welcomed, and the conference was scheduled for 31 January. | |5) At that point a group from Cisco, led by Benoit and Ganesh, | came forward with a much more complete document, which they | published as an individual Internet draft, so everyone could | read it and comment. This was a very considerable contribution | to the WG. | |6) The teleconference was held, with many people participating. | Minutes were posted on the list. Since then there has been | a *lot* of discussion on the list and sublists. Many people | (including those from Cisco) have contributed text, which KC | has edited together to form a second document. This will | shortly be published as a second individual draft. | |7) We now have two documents, each with lots of worthwhile material | in them. I suspect there is a feeling that these are, somehow, | competing proposals - this is not the case. Both are serious | contributions to the WG effort. | |B: What next? | |From the WG co-chairs point of view, any documents being |produced as WG drafts need to be the result of open discussion |in the WG, i.e. on its mailing list. The co-chairs' role is |to facilitate discussion, |and to guide it towards actually delivering documents as per |the WG's charter goals. Decisions about the technical merit |of text in various sections of the document needs to be |decided by consensus on the list. | |Ideally, we'd like to get to the next IETF meeting (Minneapolis in |March) with a single document to review / discuss / amend. So |how can we achieve that? | |I propose that | |1) We form a small 'editorial' team, with two people from those | working on each of the two current documents (4 altogether). | |2) We ask the editorial team to merge the documents together, | and publish the resulting document(s) as IPFX WG drafts. | |3) The members of the design team - i.e. all those who've contributed | text to the drafts - will be listed in the 'Acknowledgements' | section of all drafts produced. The editors of each document | will appear as the document authors. | |4) Watching the mailing list discussion, this is starting to | happen as a natural development anyway. Agreeing to proceed | in this way would simply introduce a little formality to it, | and make the process clear to everyone. | |One other comment. This WG has certainly generated plenty of |interesting discussion on its mailing list. It's clear that |all those involved are putting a lot of effort into our goal |of producing the best |technical solutions. Thanks all round. | |I'd like comments / feedback on this notion from all |concerned, please. In particular, if we can agree to proceed |in this way, we need to decide who's on the editorial team ... | |Cheers, Nevil | |+---------------------------------------------------------------------+ || Nevil Brownlee Director, Technology Development | || Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | || FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | |+---------------------------------------------------------------------P | | |-- |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/ | ------=_NextPart_000_0032_01C1B539.09174D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] WG process: a proposal
My=20 original message got bounced back.  See below.
 
Kevin
-----Original Message-----
From: Kevin Zhang=20 [mailto:kevin.zhang@xacct.com]
Sent: Wednesday, February 13, = 2002=20 6:09 PM
To: Norseth, KC; 'Nevil Brownlee';=20 ipfix@net.doit.wisc.edu
Cc: bclaise@cisco.com; = gsadasiv@cisco.com;=20 kcn@norseth.com; plonka@doit.wisc.edu; K.C. Norseth
Subject: = RE:=20 [ipfix] WG process: a proposal

Hi=20 all,
 
I=20 have strong interest to be on the architecture editorial=20 team.
 
Thanks,
 
Kevin
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Norseth,=20 KC
Sent: Wednesday, February 13, 2002 5:51 = PM
To: 'Nevil=20 Brownlee'; ipfix@net.doit.wisc.edu
Cc: bclaise@cisco.com;=20 gsadasiv@cisco.com; kcn@norseth.com; plonka@doit.wisc.edu; K.C. = Norseth;=20 Norseth, KC
Subject: RE: [ipfix] WG process: a=20 proposal

Sounds great.  I would like to be on the = team. =20

I have been working on a comparitive analysis on = the docs,=20 section by section.  This could be of help in the merge = process. =20 I could get that out tonight if wanted.  Each set of documents = have=20 strong features and weak features that together would form a solid=20 document.

K.C.


|-----Original Message-----
|From:=20 Nevil Brownlee [mailto:n.brownlee@auckland.ac.n= z]=20
|Sent: Wednesday, February 13, 2002 3:23 = PM=20
|To: ipfix@net.doit.wisc.edu
|Cc:=20 bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; =
|plonka@doit.wisc.edu; n.brownlee@auckland.ac.nz =
|Subject: [ipfix] WG process: a proposal
|
|
|=20
|Hello all:
| =
|Various people have been asking for some direction from = the WG=20 chairs
|as to where we're heading with the = two=20 current documents. 
|After some = discussion=20 between Dave and myself, I'd like to
|suggest the=20 following:
|
|A: = Background
|
|1) = At the Salt=20 Lake City IETF we called for volunteers to work on
|   the two IPFIX documents, as set out in the WG = charter.  About
|   20 = people=20 volunteered.
|
|2) After an=20 initial flurry of discussion on the IPFIX list, things =
|   went quiet.  We set up some extra = sub-lists to=20 help the design
|   team members = get some=20 initial discussions going.
| =
|3) KC Norseth stepped forward and posted some skeleton=20 documents.
|   These were simply = lists of=20 section headings based on the
|   'IPFIX=20 requirements' document.
|
|4) KC also proposed a design teleconference.  That = idea=20 was
|   welcomed, and the = conference was=20 scheduled for 31 January.
| =
|5) At that point a group from Cisco, led by Benoit and=20 Ganesh,
|   came forward with a = much more=20 complete document, which they
|  =20 published as an individual Internet draft, so everyone could=20
|   read it and comment.  This was = a very=20 considerable contribution
|   to = the=20 WG.
|
|6) The = teleconference=20 was held, with many people participating.
|   Minutes were posted on the list.  Since = then there=20 has been
|   a *lot* of = discussion on the=20 list and sublists.  Many people
|  =20 (including those from Cisco) have contributed text, which KC=20
|   has edited together to form a = second=20 document.  This will
|   = shortly be=20 published as a second individual draft.
|=20
|7) We now have two documents, each with lots of = worthwhile=20 material
|   in them.  I = suspect=20 there is a feeling that these are, somehow,
|   competing proposals - this is not the = case.  Both=20 are serious
|   contributions to = the WG=20 effort.
|
|B: = What=20 next?
|
|From = the WG=20 co-chairs point of view, any documents being
|produced as WG drafts need to be the result of open = discussion=20
|in the WG, i.e. on its mailing = list.  The=20 co-chairs' role is
|to facilitate = discussion,=20
|and to guide it towards actually = delivering=20 documents as per
|the WG's charter = goals. =20 Decisions about the technical merit
|of = text in=20 various sections of the document needs to be
|decided by consensus on the list.
|=20
|Ideally, we'd like to get to the next IETF = meeting=20 (Minneapolis in
|March) with a single = document to=20 review / discuss / amend.  So
|how = can we=20 achieve that?
|
|I propose=20 that
|
|1) We = form a small=20 'editorial' team, with two people from those
|   working on each of the two current documents = (4=20 altogether).
|
|2) We ask=20 the editorial team to merge the documents together,
|   and publish the resulting document(s) as IPFX = WG=20 drafts.
|
|3) = The members of=20 the design team - i.e. all those who've contributed
|   text to the drafts - will be listed in the=20 'Acknowledgements'
|   section = of all=20 drafts produced. The editors of each document
|   will appear as the document authors. =
|
|4) Watching the mailing list = discussion,=20 this is starting to
|   happen = as a=20 natural development anyway.  Agreeing to proceed =
|   in this way would simply introduce a little = formality=20 to it,
|   and make the process = clear to=20 everyone.
|
|One = other=20 comment. This WG has certainly generated plenty of
|interesting discussion on its mailing list.  It's = clear that=20
|all those involved are putting a lot of = effort into=20 our goal
|of producing the best =
|technical solutions.  Thanks all round. =
|
|I'd like comments / feedback = on this=20 notion from all
|concerned, please. In = particular,=20 if we can agree to proceed
|in this way, = we need to=20 decide who's on the editorial team ...
|=20
|Cheers, Nevil
| =
|+--------------------------------------------------------------= -------+=20
|| Nevil=20 = Brownlee           = ;         =20 Director, Technology Development |
|| = Phone: +64 9=20 373 7599 x8941        ITSS, The=20 University of Auckland |
||   = FAX: +64 9=20 373 7021      Private Bag 92019, Auckland, = New=20 Zealand |
|+--------------------------------------------------------------= -------P=20
|
|
|--
|Help        mailto:majordomo@net.doit.wis= c.edu=20 and say "help"
|in message body =
|Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
|"unsubscribe ipfix" in message = body=20
|Archive     http://ipfix.doit.wisc.edu/archive/ =
|

------=_NextPart_000_0032_01C1B539.09174D90-- -- 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 Feb 14 09:57:52 2002 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 JAA23474 for ; Thu, 14 Feb 2002 09:57:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bN61-0002Z4-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 08:42:49 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bN5z-0002Yy-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 08:42:47 -0600 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EEieQ11144 for ; Thu, 14 Feb 2002 08:44:40 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Feb 2002 08:42:46 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 08:42:38 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 14 Feb 2002 09:42:37 -0500 Message-ID: Thread-Topic: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Thread-Index: AcG1X8P124TSb+CqQuW1jd68LPZTTAABELFg From: To: , Cc: , X-OriginalArrivalTime: 14 Feb 2002 14:42:38.0097 (UTC) FILETIME=[D90DD010:01C1B565] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA23474 Hello Benoit, Thanks for pointing me the charters quote. See my inline comments. > >Note: please let's try to concentrate on just one issue: >in-band configuration and not capability negotiation and >transport negotiation. One step at the time please. I was discussing only configuration and not other aspects , see inline comments. >> If we have in-band management what is the problem? It's is a >good choice whether >> there is no flaw and it is good to control from one place to >do both configure and manage the network >> elements. If we provide proper security mechanism and ensure >that the devices gets >> the proper commands similar to CLI then what's the problem ? > >What is the problem, you're asking? >There are actually no problems. I agree it would be the >perfect world to have in-band configuration. But here are some >arguments against the idea. Actually I even think a little bit >further: the exporter configuration is out of the scope of >this charter. You yourself is convinced to have single point configuration and control thr' inband management. I can see some your good points and issues. We are not thinking here exporter or collector configuraation split or where to place the functionality etc. If there is a real potential problem then we should consider this as part of charter rather than just postponing IPFIX version1 ... version 2.... etc.... There is always a debate one can make whether to consider all the problems at forehand or do incremental activity. I do not want to get into that. > >1. Do you want the working group to spend the time (the money) >to developp a comon provisioning protocol, IF this is even >possible to have an agreement on that accross the different >vendor (probes and routers), which I think is impossible. > Flow information protocol is extensible and we cannot deal with each and every protocol. Flow information can be exchanged between two endpoints if they know how to interpret the fields. Like SNMP every protocol defines the MIB what to be managed. Typically, Management protocols are provides mechanisms they do not describes each attributes of protocol, IT is the responsibility of each protocol define their attributes which are to be managed and this more specific to details of the protocol. So in principle we have MIB and management protocol two are logically separate entities. Ok,its a matter of time and design team effort to put that. I do not think it is waste of money or time. >2. What would happen with proprietary features, which most >likely will not be part of the IPFIX provisioning protocol. So >anyway we will have to use a different way of provisioning the >device, like CLI for example, next to IPFIX. This will bypass >the use of IPFIX provisioning protocol. > See my previous comments. >4. SNMP is widely used. Why? because the S stands for simple. >And now, along the time, it has been evolving because there >are new needs. >I would like to start with something Simple, that everybody agrees on. >And if there is a need for in-band configuration, then we can >think of IPFIX2. >Why trying to have an ISO standard from version 1? ;) >You can give me a long list of nice idea about in-band >configuration that I'm sure I would love to have in a perfect >world but let's start with something Simple. >Don't forget that simplicity is the key for interoperability. >If not yet convinced: have you already compared Snmp and CMIP? > I agree that we start with simple, that does not mean that we should complete in hurry without addressing the other issues. I advice be patient and cool while you converse what i ask in the email and the statements in your email is not the correct way to communicate. What you replied is not the correct way to communicate, please read the emails before you communicate. >6. IPFIX stands for Flow Information eXport. So we have to >standardize the export, not the configuration. So the >direction:exporter -> collector and not the direction >collector -> exporter. At least for version 1. We are not talking version of IPFIX in our charter and it may be your assumption. Regards Ramg -- 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 Feb 14 10:12:10 2002 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 KAA23839 for ; Thu, 14 Feb 2002 10:12:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bNIl-0002sD-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 08:55:59 -0600 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bNIj-0002s5-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 08:55:57 -0600 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EEuAQ07328 for ; Thu, 14 Feb 2002 08:56:10 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Feb 2002 08:55:55 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 08:55:55 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 14 Feb 2002 09:55:54 -0500 Message-ID: Thread-Topic: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Thread-Index: AcG1X8P124TSb+CqQuW1jd68LPZTTAABELFgAADtvhA= From: To: , , Cc: , X-OriginalArrivalTime: 14 Feb 2002 14:55:55.0679 (UTC) FILETIME=[B4732AF0:01C1B567] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA23839 Hello Benoit, I am sorry once again, my system has some problem , emails slipped out my hands before completing it. I just fixed this now. Thanks for pointing me the charters quote. See my inline comments. > >Note: please let's try to concentrate on just one issue: >in-band configuration and not capability negotiation and >transport negotiation. One step at the time please. I was discussing only configuration and not other aspects , see inline comments. >> If we have in-band management what is the problem? It's is a >good choice whether >> there is no flaw and it is good to control from one place to >do both configure and manage the network >> elements. If we provide proper security mechanism and ensure >that the devices gets >> the proper commands similar to CLI then what's the problem ? > >What is the problem, you're asking? >There are actually no problems. I agree it would be the >perfect world to have in-band configuration. But here are some >arguments against the idea. Actually I even think a little bit >further: the exporter configuration is out of the scope of >this charter. You yourself is convinced to have single point configuration and control thr' inband management. I can see some of your good points and issues. We are not thinking here exporter or collector configuration split or where to place the functionality etc. If there is a real potential problem then we should consider this as part of charter rather than just postponing IPFIX version1 ... version 2.... etc.... There is always a debate one can make whether to consider all the problems at forehand or do incremental activity. I do not want to get into that. > >1. Do you want the working group to spend the time (the money) >to developp a comon provisioning protocol, IF this is even >possible to have an agreement on that accross the different >vendor (probes and routers), which I think is impossible. > Flow information protocol is extensible and we cannot deal in defining flows for each each and every protocols. Flow information can be exchanged between two endpoints if they know how to interpret the fields which may be vendor specific. With SNMP also every protocol defines the MIB and uses SNMP to exchange the information. Typically, Management protocols are provides mechanisms how to exchange and not what to exchange. The latter thing is more addressed by MIB which is a generic to represent attributes which are to be managed. So in principle we have MIB and management protocol two are logically separate functional entities. Ok,its a matter of time and design team effort to put that, we should not leave any items which are essential candidates. >2. What would happen with proprietary features, which most >likely will not be part of the IPFIX provisioning protocol. So >anyway we will have to use a different way of provisioning the >device, like CLI for example, next to IPFIX. This will bypass >the use of IPFIX provisioning protocol. > See my previous comments. >4. SNMP is widely used. Why? because the S stands for simple. >And now, along the time, it has been evolving because there >are new needs. >I would like to start with something Simple, that everybody agrees on. >And if there is a need for in-band configuration, then we can >think of IPFIX2. >Why trying to have an ISO standard from version 1? ;) >You can give me a long list of nice idea about in-band >configuration that I'm sure I would love to have in a perfect >world but let's start with something Simple. >Don't forget that simplicity is the key for interoperability. >If not yet convinced: have you already compared Snmp and CMIP? > I agree that we start with simple, that does not mean that we should complete in hurry without addressing the other issues. My advice is that be patient and cool when you reply. What i asked is more of clarification but your reply is not on those lines. >6. IPFIX stands for Flow Information eXport. So we have to >standardize the export, not the configuration. So the >direction:exporter -> collector and not the direction >collector -> exporter. At least for version 1. We are not talking version of IPFIX in our charter and it may be your assumption. Regards Ramg -- 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 Feb 14 10:29:16 2002 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 KAA24200 for ; Thu, 14 Feb 2002 10:29:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bNWQ-0003Gd-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 09:10:06 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bNWO-0003Fr-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 09:10:04 -0600 Received: from cisco.com (bclaise-isdn-home2.cisco.com [10.49.4.219]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA25180; Thu, 14 Feb 2002 16:09:17 +0100 (MET) Message-ID: <3C6BD31D.9426E870@cisco.com> Date: Thu, 14 Feb 2002 16:09:18 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ram.gopal@nokia.com CC: quittek@ccrle.nec.de, zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ramg, > > >> If we have in-band management what is the problem? It's is a > >good choice whether > >> there is no flaw and it is good to control from one place to > >do both configure and manage the network > >> elements. If we provide proper security mechanism and ensure > >that the devices gets > >> the proper commands similar to CLI then what's the problem ? > > > >What is the problem, you're asking? > >There are actually no problems. I agree it would be the > >perfect world to have in-band configuration. But here are some > >arguments against the idea. Actually I even think a little bit > >further: the exporter configuration is out of the scope of > >this charter. > > You yourself is convinced to have single point configuration and control thr' inband > management. I can see some of your good points and issues. We are not thinking > here exporter or collector configuration split or where to place the functionality etc. > If there is a real potential problem then we should consider this as part of charter > rather than just postponing IPFIX version1 ... version 2.... etc.... But the entire issue, I don't see which problem we are trying to solve by having in-band configuration, except that it could be a nice feature to have. > > > There is always a debate one can make whether to consider all the problems at forehand > or do incremental activity. I do not want to get into that. > > > > >1. Do you want the working group to spend the time (the money) > >to developp a comon provisioning protocol, IF this is even > >possible to have an agreement on that accross the different > >vendor (probes and routers), which I think is impossible. > > > > Flow information protocol is extensible and we cannot deal in defining > flows for each each and every protocols. Flow information can be exchanged between > two endpoints if they know how to interpret the fields which may be vendor specific. The information model must be extensible. Agreed, but this is a different issue than inband configuration. BTW, In Ganesh and I's draft, the collector will be able to decode a template, even if it doesn't know anything about some specific fields. > > > With SNMP also every protocol defines the MIB and uses SNMP to exchange the > information. > > > Typically, Management protocols are provides mechanisms how to exchange and not what to exchange. > The latter thing is more addressed by MIB which is a generic to represent attributes which are to > be managed. Agreed. I don't recall writing something which goes against that principle. > > > So in principle we have MIB and management protocol two are logically separate functional entities. Same remark > > > Ok,its a matter of time and design team effort to put that, we should not leave any items > which are essential candidates. > > > >2. What would happen with proprietary features, which most > >likely will not be part of the IPFIX provisioning protocol. So > >anyway we will have to use a different way of provisioning the > >device, like CLI for example, next to IPFIX. This will bypass > >the use of IPFIX provisioning protocol. > > > See my previous comments. > > >4. SNMP is widely used. Why? because the S stands for simple. > >And now, along the time, it has been evolving because there > >are new needs. > >I would like to start with something Simple, that everybody agrees on. > >And if there is a need for in-band configuration, then we can > >think of IPFIX2. > >Why trying to have an ISO standard from version 1? ;) > >You can give me a long list of nice idea about in-band > >configuration that I'm sure I would love to have in a perfect > >world but let's start with something Simple. > >Don't forget that simplicity is the key for interoperability. > >If not yet convinced: have you already compared Snmp and CMIP? > > > > I agree that we start with simple, that does not mean that we should complete > in hurry without addressing the other issues. > > My advice is that be patient and cool when you reply. What i asked is more of > clarification but your reply is not on those lines. > > > > >6. IPFIX stands for Flow Information eXport. So we have to > >standardize the export, not the configuration. So the > >direction:exporter -> collector and not the direction > >collector -> exporter. At least for version 1. > > We are not talking version of IPFIX in our charter and it may be > your assumption. No assumption here, I'm only trying to find a consensus. So instead of just saying NO, I'm proposing the following: if there is a really a need (a real potential problem, according to your own words), it's time to give your technical arguments. If not, let's investigate this nice-to-have feature later, maybe in version 2. Regards, Benoit -- 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 Feb 14 10:46:07 2002 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 KAA24974 for ; Thu, 14 Feb 2002 10:46:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bNoP-0003ax-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 09:28:41 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bNoN-0003aB-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 09:28:39 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EFNrV10873; Thu, 14 Feb 2002 09:23:53 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFYH8L>; Thu, 14 Feb 2002 07:23:51 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A73397@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, Benoit Claise Cc: quittek@ccrle.nec.de, ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to d raft-ietf-ipfix-reqs-00.txt Date: Thu, 14 Feb 2002 07:23:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B56B.9A617190" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B56B.9A617190 Content-Type: text/plain; charset="iso-8859-1" Hello, Last I counted we had most people saying that it's useful but we should tackle this later, except for Me, Kevin and Ram that would like to see it now. K.C said it was nice, Paul and Mike that it was for after "IPfixv1" and Benoit, Ganesh, Juergen and Will saying no. So in terms of number of vendors (I agree with Benoit that the important thing is the number of vendors adopting it) it seems there is an agreement to investigate this problem at some point. We need then to choose the words that reflect this position on the arch draft/req. Suggestions? Having said that I would like to clarify some points: One is that the idea was never to have a "common provisioning protocol". Provisioning seems a pretty heavy word. The in-band config would facilite things like template negotiation associate with flow metering capabilities and the like. So, in fact it would help configuring vendor specific features like extended flow information, etc Second, the fact that "the meter will be built partially in hardware which is costly. Here we can save a lot by reducing some functions. " is a implementation issue...Somebody else cold say that their meter would be build on software (a PC-appliance for instance) so they do not care. So trying to be fair with all possible IPfix users, I think we should drop this specific point altogether. Now, as I said, I think Benoit had a good point on the adoption of such a mechanism, ie, How many vendors would implement this in-band configuration. If we can base the vendors on the people that work for them, I would say up to this point 4-5 (not sure what percentage of companies that will really build an IPfix collector or exporter this represents). regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Thursday, February 14, 2002 6:24 AM >To: Benoit Claise >Cc: quittek@ccrle.nec.de; ram.gopal@nokia.com; zander@fokus.gmd.de; >ipfix-req@net.doit.wisc.edu >Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to >draft-ietf-ipfix-reqs-00.txt > > > >I vote no in-band configuration in IPFIX V1. > >Benoit Claise wrote: >> >> Hi Ram and All, >> >> We've discussing the in-band configuration for a few times >without conclusions. >> I propose to use this thread to arrive to a rough consensus >and close the discussion one for all. Otherwise we're turning >in circles and loosing everybody's time! >> And if we can't get a consensus, the chairmen and area >directors will have to take a decision. >> >> Note: please let's try to concentrate on just one issue: >in-band configuration and not capability negotiation and >transport negotiation. One step at the time please. >> >> > >> > >> > >Our charter tells us to "select a protocol by which >> > >IP flow information can be transferred" and I would >> > >prefer not to go beyond this. >> > >> > Transfer of flow information may not refer only to >monitoring. I interpreted as >> > one can monitor and then transfer ( exchange) flows >between endpoints . To do this one has >> > to configure first what we are interested in - that means >configure, monitor and transfer >> > flows. >> > >> > I am not sure and would like to get clarify my doubt, >> > >> > If we have in-band management what is the problem? It's is >a good choice whether >> > there is no flaw and it is good to control from one place >to do both configure and manage the network >> > elements. If we provide proper security mechanism and >ensure that the devices gets >> > the proper commands similar to CLI then what's the problem ? >> >> What is the problem, you're asking? >> There are actually no problems. I agree it would be the >perfect world to have in-band configuration. But here are some >arguments against the idea. Actually I even think a little bit >further: the exporter configuration is out of the scope of >this charter. >> >> 1. Do you want the working group to spend the time (the >money) to developp a comon provisioning protocol, IF this is >even possible to have an agreement on that accross the >different vendor (probes and routers), which I think is impossible. >> >> 2. What would happen with proprietary features, which most >likely will not be part of the IPFIX provisioning protocol. So >anyway we will have to use a different way of provisioning the >device, like CLI for example, next to IPFIX. This will bypass >the use of IPFIX provisioning protocol. >> >> 3. How many vendors would implement this in-band configuration? >> Because at the end this is the final question. What's the >point to have a IETF protocol that no/not many vendors are >going to implement. >> Do you think that vendors will spend time and money to >developp again another configuration interface, next to CLI, >SNMP, XML, etc...? And this just for an IPFIX protocol! >> >> 4. SNMP is widely used. Why? because the S stands for simple. >> And now, along the time, it has been evolving because there >are new needs. >> I would like to start with something Simple, that everybody >agrees on. >> And if there is a need for in-band configuration, then we >can think of IPFIX2. >> Why trying to have an ISO standard from version 1? ;) >> You can give me a long list of nice idea about in-band >configuration that I'm sure I would love to have in a perfect >world but let's start with something Simple. >> Don't forget that simplicity is the key for interoperability. >> If not yet convinced: have you already compared Snmp and CMIP? >> >> 5. From the charter, "select a protocol by which IP flow >information can be transferred" as Juergen said already. I >would not beyond this point. >> OK, you (Ramg) have a different view. >> >> 6. IPFIX stands for Flow Information eXport. So we have to >standardize the export, not the configuration. So the >direction:exporter -> collector and not the direction >collector -> exporter. At least for version 1. >> >> 7. Email from Nevil Brownlee, Subject: [ipfix] Comments on >'goals of IPFX WG' >> http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html >> 2. IPFIX is *not* trying to standardise a flow meter, >i.e. a network >> entity which measures flows - we already have RFCs >which do that, >> e.g. those for RTFM (2720 .. 2724). Existing widely-used >> implementations can remain different, but might >perhaps be extended >> to report flow information in the IPFIX lingua franca. >> >> 3. Instead, we recognise that network equipment >vendors already have >> flow measurement systems implemented as part of their >equipment. >> Our goal is to make the IPFIX flow information export system >> so good technically that all vendors will be happy to implement >> it, for the benefit of all users of the data. A >useful side-effect >> will be that IPFIX will make it easier to build and maintain >> interoperable flow data collecting systems. >> >> As we're not supposed to standardise a flow meter, why would >we standardize its configuration? This email just expresses >that the exporter configuration is out of the scope of the charter. >> >> 8. Juergen's argument: "Please consider that the meter will >be built partially in hardware which is costly. Here we can >save a lot by reducing some functions. >> The data collector implemented by software can be much more flexible >> with less cost." >> >> Regards, Benoit. >> >> > >> > I can understand currently most of network elements >configuration happens thro' CLI or other mechanisms.... >> > >> > Take for example SNMP is used only as monitoring tool and >but people are working on to making configuration >> > also thro' SNMP and seperate activity is going on in IETF >community itself. >> > >> > >> > Regards >> > Ramg >> > >> > >> > >> > >> >> -- >> 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/ > >-- >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/ > ------_=_NextPart_001_01C1B56B.9A617190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: in band configuration? RE: [ipfix-req] Proposed changes to = draft-ietf-ipfix-reqs-00.txt

Hello,

Last I counted we had most people saying that it's = useful but we should tackle this later, except for Me, Kevin and Ram = that would like to see it now. K.C said it was nice, Paul and Mike that = it was for after "IPfixv1" and Benoit, Ganesh, Juergen and = Will saying no.

So in terms of number of vendors (I agree with Benoit = that the important thing is the number of vendors adopting it) it seems = there is an agreement to investigate this problem at some point. We = need then to choose the words that reflect this position on the arch = draft/req. Suggestions?

Having said that I would like to clarify some = points:

One is that the idea was never to have a "common = provisioning protocol". Provisioning seems a pretty heavy word. = The in-band config would facilite things like template negotiation = associate with flow metering capabilities and the like. So, in fact it = would help configuring vendor specific features like extended flow = information, etc

Second, the fact that "the meter will be built = partially in hardware which is costly. Here we can
save a lot by reducing some functions. " is a = implementation issue...Somebody else cold say that their meter would be = build on software (a PC-appliance for instance) so they do not care. So = trying to be fair with all possible IPfix users, I think we should drop = this specific point altogether.

Now, as I said, I think Benoit had a good point on = the adoption of such a mechanism, ie, How many vendors would implement = this in-band configuration. If we can base the vendors on the people = that work for them, I would say up to this point 4-5 (not sure what = percentage of companies that will really build an IPfix collector or = exporter this represents).

regards,

Reinaldo



>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Thursday, February 14, 2002 6:24 AM
>To: Benoit Claise
>Cc: quittek@ccrle.nec.de; ram.gopal@nokia.com; = zander@fokus.gmd.de;
>ipfix-req@net.doit.wisc.edu
>Subject: Re: in band configuration? RE: = [ipfix-req] Proposed changes to
>draft-ietf-ipfix-reqs-00.txt
>
>
>
>I vote no in-band configuration in IPFIX = V1.
>
>Benoit Claise wrote:
>>
>> Hi Ram and All,
>>
>> We've discussing the in-band configuration = for a few times
>without conclusions.
>> I propose to use this thread to arrive to a = rough consensus
>and close the discussion one for all. Otherwise = we're turning
>in circles and loosing everybody's time!
>> And if we can't get a consensus, the = chairmen and area
>directors will have to take a decision.
>>
>> Note: please let's try to concentrate on = just one issue:
>in-band configuration and not capability = negotiation and
>transport negotiation. One step at the time = please.
>>
>> >
>> >
>> > >Our charter tells us to = "select a protocol by which
>> > >IP flow information can be = transferred" and I would
>> > >prefer not to go beyond = this.
>> >
>> > Transfer  of flow information may = not refer only to
>monitoring. I interpreted as
>> > one  can monitor and then = transfer ( exchange) flows
>between endpoints . To do this one has
>> > to  configure first what we are = interested in - that means
>configure, monitor and transfer
>> > flows.
>> >
>> > I am not sure and would like to get = clarify my doubt,
>> >
>> > If we have in-band management what is = the problem? It's is
>a good choice whether
>> > there is no flaw and it is good to = control from one place
>to do both configure and manage the = network
>> > elements. If we provide proper = security mechanism and
>ensure that the devices gets
>> > the proper commands  similar to = CLI then  what's the problem ?
>>
>> What is the problem, you're asking?
>> There are actually no problems. I agree it = would be the
>perfect world to have in-band configuration. But = here are some
>arguments against the idea. Actually I even = think a little bit
>further: the exporter configuration is out of = the scope of
>this charter.
>>
>> 1. Do you want the working group to spend = the time (the
>money) to developp a comon provisioning = protocol, IF this is
>even possible to have an agreement on that = accross the
>different vendor (probes and routers), which I = think is impossible.
>>
>> 2. What would happen with proprietary = features, which most
>likely will not be part of the IPFIX = provisioning protocol. So
>anyway we will have to use a different way of = provisioning the
>device, like CLI for example, next to IPFIX. = This will bypass
>the use of IPFIX provisioning protocol.
>>
>> 3. How many vendors would implement this = in-band configuration?
>> Because at the end this is the final = question. What's the
>point to have a IETF protocol that no/not many = vendors are
>going to implement.
>> Do you think that vendors will spend time = and money to
>developp again another configuration interface, = next to CLI,
>SNMP, XML, etc...?  And this just for an = IPFIX protocol!
>>
>> 4. SNMP is widely used. Why? because the S = stands for simple.
>> And now, along the time, it has been = evolving because there
>are new needs.
>> I would like to start with something = Simple, that everybody
>agrees on.
>> And if there is a need for in-band = configuration, then we
>can think of IPFIX2.
>> Why trying to have an ISO standard from = version 1? ;)
>> You can give me a long list of nice idea = about in-band
>configuration that I'm sure I would love to have = in a perfect
>world but let's start with something = Simple.
>> Don't forget that simplicity is the key for = interoperability.
>> If not yet convinced: have you already = compared Snmp and CMIP?
>>
>> 5. From the charter, "select a = protocol by which IP flow
>information can be transferred" as Juergen = said already. I
>would not beyond this point.
>> OK, you (Ramg) have a different = view.
>>
>> 6. IPFIX stands for Flow Information = eXport. So we have to
>standardize the export, not the configuration. = So the
>direction:exporter -> collector and not the = direction
>collector -> exporter. At least for version = 1.
>>
>> 7. Email from Nevil Brownlee, Subject: = [ipfix] Comments on
>'goals of IPFX WG'
>> http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html=
>>       2. = IPFIX is *not* trying to standardise a flow meter,
>i.e. a network
>>       entity = which measures flows - we already have RFCs
>which do that,
>>       e.g. = those for RTFM (2720 .. 2724).  Existing widely-used
>>       = implementations can remain different, but might
>perhaps be extended
>>       to = report flow information in the IPFIX lingua franca.
>>
>>       3. = Instead, we recognise that network equipment
>vendors already have
>>       flow = measurement systems implemented as part of their
>equipment.
>>       Our = goal is to make the IPFIX flow information export system
>>       so good = technically that all vendors will be happy to implement
>>       it, for = the benefit of all users of the data.  A
>useful side-effect
>>       will be = that IPFIX will make it easier to build and maintain
>>       = interoperable flow data collecting systems.
>>
>> As we're not supposed to standardise a flow = meter, why would
>we standardize its configuration? This email = just expresses
>that the exporter configuration is out of the = scope of the charter.
>>
>> 8. Juergen's argument: "Please = consider that the meter will
>be built partially in hardware which is costly. = Here we can
>save a lot by reducing some functions.
>> The data collector implemented by software = can be much more flexible
>> with less cost."
>>
>> Regards, Benoit.
>>
>> >
>> > I can understand  currently most = of network elements
>configuration happens thro'   CLI or = other mechanisms....
>> >
>> > Take for example SNMP is used only as = monitoring tool and
>but people are working on to making = configuration
>> > also thro' SNMP and seperate activity = is going on in IETF
>community itself.
>> >
>> >
>> > Regards
>> > Ramg
>> >
>> >
>> >
>> >
>>
>> --
>> = Help        mailto:majordomo@net.doit.wi= sc.edu and say
>"help" in message body
>> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>> "unsubscribe ipfix" in message = body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B56B.9A617190-- -- 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 Feb 14 10:56:37 2002 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 KAA25227 for ; Thu, 14 Feb 2002 10:56:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bNvj-0003nP-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 09:36:15 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bNvh-0003mb-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 09:36:13 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1EFZ7V13916; Thu, 14 Feb 2002 09:35:07 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFY2D7>; Thu, 14 Feb 2002 07:35:04 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A733B6@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Nevil Brownlee , ipfix@net.doit.wisc.edu Cc: bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu Subject: RE: [ipfix] WG process: a proposal - Add ons. Date: Thu, 14 Feb 2002 07:35:04 -0800 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B56D.2C37ED50" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B56D.2C37ED50 Content-Type: text/plain; charset="iso-8859-1" I said I would strongly like to be on the architecture team... But I would like to add something for people to think about before we move forward. K.C said that the two documents have strenghts and weakness. Well, there are cases where they have strenghts on the same area but their approaches are different. And there are cases where one proposes one thing that the other does not endorse (and vice-versa). So, is there a considerable risk that in order to please everybody we might end up pleasing no one? What I'm trying to say is that in order to cope with objections/requests from different people we end up with a proposal that is worst than both taken separately? Maybe then the traditional IETF process where proposals live or die by their own merits would have been better. just thiking out loud... thanks, Reinaldo >-----Original Message----- >From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz] >Sent: Wednesday, February 13, 2002 2:23 PM >To: ipfix@net.doit.wisc.edu >Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; >plonka@doit.wisc.edu; n.brownlee@auckland.ac.nz >Subject: [ipfix] WG process: a proposal > > > >Hello all: > >Various people have been asking for some direction from the WG chairs >as to where we're heading with the two current documents. After some >discussion between Dave and myself, I'd like to suggest the following: > >A: Background > >1) At the Salt Lake City IETF we called for volunteers to work on > the two IPFIX documents, as set out in the WG charter. About > 20 people volunteered. > >2) After an initial flurry of discussion on the IPFIX list, things > went quiet. We set up some extra sub-lists to help the design > team members get some initial discussions going. > >3) KC Norseth stepped forward and posted some skeleton documents. > These were simply lists of section headings based on the > 'IPFIX requirements' document. > >4) KC also proposed a design teleconference. That idea was > welcomed, and the conference was scheduled for 31 January. > >5) At that point a group from Cisco, led by Benoit and Ganesh, > came forward with a much more complete document, which they > published as an individual Internet draft, so everyone could > read it and comment. This was a very considerable contribution > to the WG. > >6) The teleconference was held, with many people participating. > Minutes were posted on the list. Since then there has been > a *lot* of discussion on the list and sublists. Many people > (including those from Cisco) have contributed text, which KC > has edited together to form a second document. This will > shortly be published as a second individual draft. > >7) We now have two documents, each with lots of worthwhile material > in them. I suspect there is a feeling that these are, somehow, > competing proposals - this is not the case. Both are serious > contributions to the WG effort. > >B: What next? > >From the WG co-chairs point of view, any documents being produced as >WG drafts need to be the result of open discussion in the WG, i.e. on >its mailing list. The co-chairs' role is to facilitate discussion, >and to guide it towards actually delivering documents as per the WG's >charter goals. Decisions about the technical merit of text in various >sections of the document needs to be decided by consensus on the list. > >Ideally, we'd like to get to the next IETF meeting (Minneapolis in >March) with a single document to review / discuss / amend. So how >can we achieve that? > >I propose that > >1) We form a small 'editorial' team, with two people from those > working on each of the two current documents (4 altogether). > >2) We ask the editorial team to merge the documents together, > and publish the resulting document(s) as IPFX WG drafts. > >3) The members of the design team - i.e. all those who've contributed > text to the drafts - will be listed in the 'Acknowledgements' > section of all drafts produced. The editors of each document > will appear as the document authors. > >4) Watching the mailing list discussion, this is starting to > happen as a natural development anyway. Agreeing to proceed > in this way would simply introduce a little formality to it, > and make the process clear to everyone. > >One other comment. This WG has certainly generated plenty of >interesting >discussion on its mailing list. It's clear that all those involved >are putting a lot of effort into our goal of producing the best >technical solutions. Thanks all round. > >I'd like comments / feedback on this notion from all concerned, please. >In particular, if we can agree to proceed in this way, we need to >decide who's on the editorial team ... > >Cheers, Nevil > >+---------------------------------------------------------------------+ >| Nevil Brownlee Director, Technology Development | >| Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | >| FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | >+---------------------------------------------------------------------P > > >-- >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/ > ------_=_NextPart_001_01C1B56D.2C37ED50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] WG process: a proposal - Add ons.

I said I would strongly like to be on the = architecture team...

But I would like to add something for people to think = about before we move forward.

K.C said that the two documents have strenghts and = weakness. Well, there are cases where they have strenghts on the same = area but their approaches are different. And there are cases where one = proposes one thing that the other does not endorse (and = vice-versa). 

So, is there a considerable risk that in order to = please everybody we might end up pleasing no one? What I'm trying to = say is that in order to cope with objections/requests from different = people we end up with a proposal that is worst than both taken = separately? Maybe then the traditional IETF process where proposals = live or die by their own merits would have been better.

just thiking out loud...

thanks,

Reinaldo




>-----Original Message-----
>From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.= nz]
>Sent: Wednesday, February 13, 2002 2:23 = PM
>To: ipfix@net.doit.wisc.edu
>Cc: bclaise@cisco.com; gsadasiv@cisco.com; = kcn@norseth.com;
>plonka@doit.wisc.edu; = n.brownlee@auckland.ac.nz
>Subject: [ipfix] WG process: a proposal
>
>
>
>Hello all:
>
>Various people have been asking for some = direction from the WG chairs
>as to where we're heading with the two current = documents.  After some
>discussion between Dave and myself, I'd like to = suggest the following:
>
>A: Background
>
>1) At the Salt Lake City IETF we called for = volunteers to work on
>   the two IPFIX documents, as set out = in the WG charter.  About
>   20 people volunteered.
>
>2) After an initial flurry of discussion on the = IPFIX list, things
>   went quiet.  We set up some = extra sub-lists to help the design
>   team members get some initial = discussions going.
>
>3) KC Norseth stepped forward and posted some = skeleton documents.
>   These were simply lists of section = headings based on the
>   'IPFIX requirements' = document.
>
>4) KC also proposed a design = teleconference.  That idea was
>   welcomed, and the conference was = scheduled for 31 January.
>
>5) At that point a group from Cisco, led by = Benoit and Ganesh,
>   came forward with a much more = complete document, which they
>   published as an individual Internet = draft, so everyone could
>   read it and comment.  This was = a very considerable contribution
>   to the WG.
>
>6) The teleconference was held, with many people = participating.
>   Minutes were posted on the = list.  Since then there has been
>   a *lot* of discussion on the list = and sublists.  Many people
>   (including those from Cisco) have = contributed text, which KC
>   has edited together to form a = second document.  This will
>   shortly be published as a second = individual draft.
>
>7) We now have two documents, each with lots of = worthwhile material
>   in them.  I suspect there is a = feeling that these are, somehow,
>   competing proposals - this is not = the case.  Both are serious
>   contributions to the WG = effort.
>
>B: What next?
>
>From the WG co-chairs point of view, any = documents being produced as
>WG drafts need to be the result of open = discussion in the WG, i.e. on
>its mailing list.  The co-chairs' role is = to facilitate discussion,
>and to guide it towards actually delivering = documents as per the WG's
>charter goals.  Decisions about the = technical merit of text in various
>sections of the document needs to be decided by = consensus on the list.
>
>Ideally, we'd like to get to the next IETF = meeting (Minneapolis in
>March) with a single document to review / = discuss / amend.  So how
>can we achieve that?
>
>I propose that
>
>1) We form a small 'editorial' team, with two = people from those
>   working on each of the two current = documents (4 altogether).
>
>2) We ask the editorial team to merge the = documents together,
>   and publish the resulting = document(s) as IPFX WG drafts.
>
>3) The members of the design team - i.e. all = those who've contributed
>   text to the drafts - will be listed = in the 'Acknowledgements'
>   section of all drafts produced. The = editors of each document
>   will appear as the document = authors.
>
>4) Watching the mailing list discussion, this is = starting to
>   happen as a natural development = anyway.  Agreeing to proceed
>   in this way would simply introduce = a little formality to it,
>   and make the process clear to = everyone.
>
>One other comment. This WG has certainly = generated plenty of
>interesting
>discussion on its mailing list.  It's clear = that all those involved
>are putting a lot of effort into our goal of = producing the best
>technical solutions.  Thanks all = round.
>
>I'd like comments / feedback on this notion from = all concerned, please.
>In particular, if we can agree to proceed in = this way, we need to
>decide who's on the editorial team ...
>
>Cheers, Nevil
>
>+----------------------------------------------------------= -----------+
>| Nevil = Brownlee          &nbs= p;          Director, = Technology Development |
>| Phone: +64 9 373 7599 = x8941        ITSS, The University of = Auckland |
>|   FAX: +64 9 373 = 7021      Private Bag 92019, Auckland, New = Zealand |
>+----------------------------------------------------------= -----------P
>
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B56D.2C37ED50-- -- 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 Feb 14 11:47:42 2002 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 LAA27116 for ; Thu, 14 Feb 2002 11:47:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bOgV-00059X-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 10:24:35 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bOgT-00059R-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 10:24:33 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id LAA08524 for ; Thu, 14 Feb 2002 11:33:59 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xmaa08465; Thu, 14 Feb 02 11:33:30 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXPA4F>; Thu, 14 Feb 2002 11:23:00 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06C7@slc-exc1.ctron.com> From: "Norseth, KC" To: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] WG process: a proposal - Add ons. Date: Thu, 14 Feb 2002 11:23:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B573.E7FA94B0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B573.E7FA94B0 Content-Type: text/plain Comments inline -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Thursday, February 14, 2002 8:35 AM To: Nevil Brownlee; ipfix@net.doit.wisc.edu Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; plonka@doit.wisc.edu Subject: RE: [ipfix] WG process: a proposal - Add ons. Importance: High I said I would strongly like to be on the architecture team... But I would like to add something for people to think about before we move forward. K.C said that the two documents have strenghts and weakness. Well, there are cases where they have strenghts on the same area but their approaches are different. And there are cases where one proposes one thing that the other does not endorse (and vice-versa). No matter who is on the review board, these comments would be useful. Please discuss these comments, ideas and opinions on the list. Everyone has the documents and has read them. It would be important for the reviewers to get the opinions of all. Lets not bash people or companies in the process though. So, is there a considerable risk that in order to please everybody we might end up pleasing no one? What I'm trying to say is that in order to cope with objections/requests from different people we end up with a proposal that is worst than both taken separately? Maybe then the traditional IETF process where proposals live or die by their own merits would have been better. Rough concensus is the statement. Although we want to please everyone, that does not mean we will. just thiking out loud... Thinking out loud is a great way for others to hear. Definitely some good points Reinaldo. In case you don't have the documents, they can be found at: http://norseth.org/ietf/ipfix/ (Directory includes MS word versions) http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt and http://search.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt If you cannot get any of these, send me an email and I can send them to you. K.C. thanks, Reinaldo >-----Original Message----- >From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz ] >Sent: Wednesday, February 13, 2002 2:23 PM >To: ipfix@net.doit.wisc.edu >Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; >plonka@doit.wisc.edu; n.brownlee@auckland.ac.nz >Subject: [ipfix] WG process: a proposal > > > >Hello all: > >Various people have been asking for some direction from the WG chairs >as to where we're heading with the two current documents. After some >discussion between Dave and myself, I'd like to suggest the following: > >A: Background > >1) At the Salt Lake City IETF we called for volunteers to work on > the two IPFIX documents, as set out in the WG charter. About > 20 people volunteered. > >2) After an initial flurry of discussion on the IPFIX list, things > went quiet. We set up some extra sub-lists to help the design > team members get some initial discussions going. > >3) KC Norseth stepped forward and posted some skeleton documents. > These were simply lists of section headings based on the > 'IPFIX requirements' document. > >4) KC also proposed a design teleconference. That idea was > welcomed, and the conference was scheduled for 31 January. > >5) At that point a group from Cisco, led by Benoit and Ganesh, > came forward with a much more complete document, which they > published as an individual Internet draft, so everyone could > read it and comment. This was a very considerable contribution > to the WG. > >6) The teleconference was held, with many people participating. > Minutes were posted on the list. Since then there has been > a *lot* of discussion on the list and sublists. Many people > (including those from Cisco) have contributed text, which KC > has edited together to form a second document. This will > shortly be published as a second individual draft. > >7) We now have two documents, each with lots of worthwhile material > in them. I suspect there is a feeling that these are, somehow, > competing proposals - this is not the case. Both are serious > contributions to the WG effort. > >B: What next? > >From the WG co-chairs point of view, any documents being produced as >WG drafts need to be the result of open discussion in the WG, i.e. on >its mailing list. The co-chairs' role is to facilitate discussion, >and to guide it towards actually delivering documents as per the WG's >charter goals. Decisions about the technical merit of text in various >sections of the document needs to be decided by consensus on the list. > >Ideally, we'd like to get to the next IETF meeting (Minneapolis in >March) with a single document to review / discuss / amend. So how >can we achieve that? > >I propose that > >1) We form a small 'editorial' team, with two people from those > working on each of the two current documents (4 altogether). > >2) We ask the editorial team to merge the documents together, > and publish the resulting document(s) as IPFX WG drafts. > >3) The members of the design team - i.e. all those who've contributed > text to the drafts - will be listed in the 'Acknowledgements' > section of all drafts produced. The editors of each document > will appear as the document authors. > >4) Watching the mailing list discussion, this is starting to > happen as a natural development anyway. Agreeing to proceed > in this way would simply introduce a little formality to it, > and make the process clear to everyone. > >One other comment. This WG has certainly generated plenty of >interesting >discussion on its mailing list. It's clear that all those involved >are putting a lot of effort into our goal of producing the best >technical solutions. Thanks all round. > >I'd like comments / feedback on this notion from all concerned, please. >In particular, if we can agree to proceed in this way, we need to >decide who's on the editorial team ... > >Cheers, Nevil > >+---------------------------------------------------------------------+ >| Nevil Brownlee Director, Technology Development | >| Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | >| FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | >+---------------------------------------------------------------------P > > >-- >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/ > ------_=_NextPart_001_01C1B573.E7FA94B0 Content-Type: text/html Message
Comments inline
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Thursday, February 14, 2002 8:35 AM
To: Nevil Brownlee; ipfix@net.doit.wisc.edu
Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; plonka@doit.wisc.edu
Subject: RE: [ipfix] WG process: a proposal - Add ons.
Importance: High

I said I would strongly like to be on the architecture team...

But I would like to add something for people to think about before we move forward.

K.C said that the two documents have strenghts and weakness. Well, there are cases where they have strenghts on the same area but their approaches are different. And there are cases where one proposes one thing that the other does not endorse (and vice-versa).   

No matter who is on the review board, these comments would be useful.  Please discuss these comments, ideas and opinions on  the list.  Everyone has the documents and has read them.  It would be important for the reviewers to get the opinions of all. 

Lets not bash people or companies in the process though.

So, is there a considerable risk that in order to please everybody we might end up pleasing no one? What I'm trying to say is that in order to cope with objections/requests from different people we end up with a proposal that is worst than both taken separately? Maybe then the traditional IETF process where proposals live or die by their own merits would have been better.  

Rough concensus is the statement.  Although we want to please everyone, that does not mean we will.

just thiking out loud...  

Thinking out loud is a great way for others to hear.  Definitely  some good points Reinaldo.

In case you don't have the documents, they can be found at:

http://norseth.org/ietf/ipfix/  (Directory includes MS word versions)
http://norseth.org/ietf/ipfix/draft-ietf-ipfix-architecture-00.txt
http://norseth.org/ietf/ipfix/draft-ietf-ipfix-data-00.txt

and

http://search.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt

If you cannot get any of these, send me an email and I can send them to you.

K.C.

thanks,

Reinaldo




>-----Original Message-----
>From: Nevil Brownlee [mailto:n.brownlee@auckland.ac.nz]
>Sent: Wednesday, February 13, 2002 2:23 PM
>To: ipfix@net.doit.wisc.edu
>Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com;
>plonka@doit.wisc.edu; n.brownlee@auckland.ac.nz
>Subject: [ipfix] WG process: a proposal
>
>
>
>Hello all:
>
>Various people have been asking for some direction from the WG chairs
>as to where we're heading with the two current documents.  After some
>discussion between Dave and myself, I'd like to suggest the following:
>
>A: Background
>
>1) At the Salt Lake City IETF we called for volunteers to work on
>   the two IPFIX documents, as set out in the WG charter.  About
>   20 people volunteered.
>
>2) After an initial flurry of discussion on the IPFIX list, things
>   went quiet.  We set up some extra sub-lists to help the design
>   team members get some initial discussions going.
>
>3) KC Norseth stepped forward and posted some skeleton documents.
>   These were simply lists of section headings based on the
>   'IPFIX requirements' document.
>
>4) KC also proposed a design teleconference.  That idea was
>   welcomed, and the conference was scheduled for 31 January.
>
>5) At that point a group from Cisco, led by Benoit and Ganesh,
>   came forward with a much more complete document, which they
>   published as an individual Internet draft, so everyone could
>   read it and comment.  This was a very considerable contribution
>   to the WG.
>
>6) The teleconference was held, with many people participating.
>   Minutes were posted on the list.  Since then there has been
>   a *lot* of discussion on the list and sublists.  Many people
>   (including those from Cisco) have contributed text, which KC
>   has edited together to form a second document.  This will
>   shortly be published as a second individual draft.
>
>7) We now have two documents, each with lots of worthwhile material
>   in them.  I suspect there is a feeling that these are, somehow,
>   competing proposals - this is not the case.  Both are serious
>   contributions to the WG effort.
>
>B: What next?
>
>From the WG co-chairs point of view, any documents being produced as
>WG drafts need to be the result of open discussion in the WG, i.e. on
>its mailing list.  The co-chairs' role is to facilitate discussion,
>and to guide it towards actually delivering documents as per the WG's
>charter goals.  Decisions about the technical merit of text in various
>sections of the document needs to be decided by consensus on the list.
>
>Ideally, we'd like to get to the next IETF meeting (Minneapolis in
>March) with a single document to review / discuss / amend.  So how
>can we achieve that?
>
>I propose that
>
>1) We form a small 'editorial' team, with two people from those
>   working on each of the two current documents (4 altogether).
>
>2) We ask the editorial team to merge the documents together,
>   and publish the resulting document(s) as IPFX WG drafts.
>
>3) The members of the design team - i.e. all those who've contributed
>   text to the drafts - will be listed in the 'Acknowledgements'
>   section of all drafts produced. The editors of each document
>   will appear as the document authors.
>
>4) Watching the mailing list discussion, this is starting to
>   happen as a natural development anyway.  Agreeing to proceed
>   in this way would simply introduce a little formality to it,
>   and make the process clear to everyone.
>
>One other comment. This WG has certainly generated plenty of
>interesting
>discussion on its mailing list.  It's clear that all those involved
>are putting a lot of effort into our goal of producing the best
>technical solutions.  Thanks all round.
>
>I'd like comments / feedback on this notion from all concerned, please.
>In particular, if we can agree to proceed in this way, we need to
>decide who's on the editorial team ...
>
>Cheers, Nevil
>
>+---------------------------------------------------------------------+
>| Nevil Brownlee                     Director, Technology Development |
>| Phone: +64 9 373 7599 x8941        ITSS, The University of Auckland |
>|   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand |
>+---------------------------------------------------------------------P
>
>
>--
>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/
>

------_=_NextPart_001_01C1B573.E7FA94B0-- -- 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 Feb 14 11:59:16 2002 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 LAA27624 for ; Thu, 14 Feb 2002 11:59:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bOxK-0005bo-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 10:41:58 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bOxG-0005b2-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 10:41:55 -0600 Received: from Kevinz (1Cust122.tnt4.dca5.da.uu.net [65.229.19.122]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1EGftl32218; Thu, 14 Feb 2002 08:41:55 -0800 Reply-To: From: "Kevin Zhang" To: "Benoit Claise" , Cc: , , Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Thu, 14 Feb 2002 11:42:54 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C6BD31D.9426E870@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA27624 My comments are inserted, thanks. Kevin > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Benoit Claise > Sent: Thursday, February 14, 2002 10:09 AM > To: ram.gopal@nokia.com > Cc: quittek@ccrle.nec.de; zander@fokus.gmd.de; > ipfix-req@net.doit.wisc.edu > Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to > draft-ietf-ipfix-reqs-00.txt > > > Ramg, > > > > > >> If we have in-band management what is the problem? It's is a > > >good choice whether > > >> there is no flaw and it is good to control from one place to > > >do both configure and manage the network > > >> elements. If we provide proper security mechanism and ensure > > >that the devices gets > > >> the proper commands similar to CLI then what's the problem ? > > > > > >What is the problem, you're asking? > > >There are actually no problems. I agree it would be the > > >perfect world to have in-band configuration. But here are some > > >arguments against the idea. Actually I even think a little bit > > >further: the exporter configuration is out of the scope of > > >this charter. > > > > You yourself is convinced to have single point configuration > and control thr' inband > > management. I can see some of your good points and issues. We > are not thinking > > here exporter or collector configuration split or where to > place the functionality etc. > > If there is a real potential problem then we should consider > this as part of charter > > rather than just postponing IPFIX version1 ... version 2.... etc.... > > But the entire issue, I don't see which problem we are trying to > solve by having in-band configuration, > except that it could be a nice feature to have. > I would underscore the fact that exporters might be probes and midboxes that need to support more data collection functionality. Without some form of configuration, preferably in-band, their applications will be significantly limited. > > > > > > There is always a debate one can make whether to consider all > the problems at forehand > > or do incremental activity. I do not want to get into that. > > > > > > > >1. Do you want the working group to spend the time (the money) > > >to developp a comon provisioning protocol, IF this is even > > >possible to have an agreement on that accross the different > > >vendor (probes and routers), which I think is impossible. > > > > > > > Flow information protocol is extensible and we cannot deal in defining > > flows for each each and every protocols. Flow information can > be exchanged between > > two endpoints if they know how to interpret the fields which > may be vendor specific. > > The information model must be extensible. Agreed, but this is a > different issue than inband > configuration. > BTW, In Ganesh and I's draft, the collector will be able to > decode a template, even if it doesn't know > anything about some specific fields. > Through template negotiation/acknowledgement, the correct context can be set at the IPFIX end-points. This will ensure correct interpretation of received data by the collector. The periodic template refreshing scheme is less robust as losses of the template information will put the collector on hold. For some applications that require real-time information collection, this means the flow information will be delayed at least another refreshing cycle. The CRANE protocol http://www.ietf.org/internet-drafts/draft-kzhang-crane-protocol-02.txt uses template negotiation to achieve flexibility and extensibility of flow information export. Very little contraints are imposed on what can be exported. The template negotiation typically happens once during set-up to allow the IPFIX end-points to sync. on a set of templates. The actual flow information is transfered in its native form accompanied by a template ID. I believe this is a nicer approach. > > > > > > With SNMP also every protocol defines the MIB and uses SNMP to > exchange the > > information. > > > > > > Typically, Management protocols are provides mechanisms how to > exchange and not what to exchange. > > The latter thing is more addressed by MIB which is a generic to > represent attributes which are to > > be managed. > > Agreed. I don't recall writing something which goes against that > principle. > > > > > > > So in principle we have MIB and management protocol two are > logically separate functional entities. > > Same remark > > > > > > > Ok,its a matter of time and design team effort to put that, > we should not leave any items > > which are essential candidates. > > > > > > >2. What would happen with proprietary features, which most > > >likely will not be part of the IPFIX provisioning protocol. So > > >anyway we will have to use a different way of provisioning the > > >device, like CLI for example, next to IPFIX. This will bypass > > >the use of IPFIX provisioning protocol. > > > > > See my previous comments. > > > > >4. SNMP is widely used. Why? because the S stands for simple. > > >And now, along the time, it has been evolving because there > > >are new needs. > > >I would like to start with something Simple, that everybody agrees on. > > >And if there is a need for in-band configuration, then we can > > >think of IPFIX2. > > >Why trying to have an ISO standard from version 1? ;) > > >You can give me a long list of nice idea about in-band > > >configuration that I'm sure I would love to have in a perfect > > >world but let's start with something Simple. > > >Don't forget that simplicity is the key for interoperability. > > >If not yet convinced: have you already compared Snmp and CMIP? > > > > > > > I agree that we start with simple, that does not mean that we > should complete > > in hurry without addressing the other issues. > > > > My advice is that be patient and cool when you reply. What i > asked is more of > > clarification but your reply is not on those lines. > > > > > > > > >6. IPFIX stands for Flow Information eXport. So we have to > > >standardize the export, not the configuration. So the > > >direction:exporter -> collector and not the direction > > >collector -> exporter. At least for version 1. > > > > We are not talking version of IPFIX in our charter and it may be > > your assumption. > > No assumption here, I'm only trying to find a consensus. > So instead of just saying NO, I'm proposing the following: > if there is a really a need (a real potential problem, according > to your own words), it's time to give > your technical arguments. > If not, let's investigate this nice-to-have feature later, maybe > in version 2. > > Regards, Benoit > > > > -- > 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/ > > ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Thu Feb 14 12:35:16 2002 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 MAA00684 for ; Thu, 14 Feb 2002 12:35:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bPND-0006Ej-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 11:08:43 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bPN9-0006DM-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 11:08:39 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1EH88g35062; Thu, 14 Feb 2002 18:08:08 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA00932; Thu, 14 Feb 2002 18:08:06 +0100 Date: Thu, 14 Feb 2002 18:09:56 +0100 From: Juergen Quittek To: Sebastian Zander cc: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again Message-ID: <97914445.1013710196@[192.168.102.31]> In-Reply-To: <3C6B8C60.708AEE87@fokus.fhg.de> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Sabastian, --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: > Hi Juergen, > > Juergen Quittek schrieb: >> >> Hi all, >> >> We had some terminology discussion and it has not >> converged yet. Therfore I like to raise one issue again: >> >> For the terinology section of the requirements draft >> (I belive now it will be a subset of the architecture's >> terminology) I would like to have two identifiers for >> the following: >> >> 1. the function block containing all metering functions >> This block gets as input observed (and potentially >> sampled) packets from the observation point. It classifies >> packets maps them to flows and creates/updates the >> according flow record. >> >> 2. the function block sending flow records to the collector >> >> I am fine with splitting blocks more or modifying them >> slightly, but I prefer to have this separation, because >> also the requirements are split in a very similar way. > > I also would like to split those for at least 2 reasons. > First we create a more general model because on a router linecard > both are be combined but on a dedicated hardware/software based > meter this will probably not the case. I don't think we should limit > ipfix to routers only. Second the separation is nice to clarify > the scope. The scope of the ipfix wg is to standardize the > exporter (at least the interface to the outside). It's out > of scope to standardize the meter (although we put some req. > on it). > > I am not sure whether sampling is a function of the observation > point or the meter. Neither am I, but we should agree on one or the other soon. What about the following (short version of more detailed suggestions already discussed for the architecture)? +-------+ +-----------+ +-------+ +--------+ +--------+ | obs. | | header | | | | flow | | ex- | | point |-->| capturing |-->| meter |-->| record |-->| porter | +-------+ +-----------+ +-------+ +--------+ +--------+ | | \____________________________ _____________________________/ \/ IPFIX traffic flow measurement module If can tell me a good reason I am fine with merging header capturing and meter, but in general I see them as different function blocks. Juergen >> My initial naive suggestion was calling block 1. "meter" >> and calling block 2. "exporter". However this might (no it >> did already) cause confusion. Therefore, I am looking for >> better terms. Any suggestions? > > I have no better terms. I think what's maybe confusing is that we don't > have a term for the overall process (meter+exporter+observation). > What could be appropriate? flow monitor? > > Another possibility: Name the overall process metering and rename > the inner function block 1 which does classification etc. > > Sebastian > > -- > Sebastian Zander E-mail: zander@fokus.fhg.de > FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > -- 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 Feb 14 12:58:05 2002 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 MAA02414 for ; Thu, 14 Feb 2002 12:58:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bPrG-0006rU-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 11:39:46 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bPrF-0006rD-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 11:39:45 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g1EHd6J24129; Thu, 14 Feb 2002 18:39:06 +0100 (CET) Date: Thu, 14 Feb 2002 18:39:06 +0100 (CET) From: Benoit Claise Message-Id: <200202141739.g1EHd6J24129@bru-cse-222.cisco.com> To: bclaise@cisco.com, ram.gopal@nokia.com, kevin.zhang@xacct.com Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Cc: quittek@ccrle.nec.de, ipfix-req@net.doit.wisc.edu X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver Hi Kevin, > > My comments are inserted, thanks. > > Kevin > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Benoit Claise > > Sent: Thursday, February 14, 2002 10:09 AM > > To: ram.gopal@nokia.com > > Cc: quittek@ccrle.nec.de; zander@fokus.gmd.de; > > ipfix-req@net.doit.wisc.edu > > Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to > > draft-ietf-ipfix-reqs-00.txt > > > > > > Ramg, > > > > > > > > >> If we have in-band management what is the problem? It's is a > > > >good choice whether > > > >> there is no flaw and it is good to control from one place to > > > >do both configure and manage the network > > > >> elements. If we provide proper security mechanism and ensure > > > >that the devices gets > > > >> the proper commands similar to CLI then what's the problem ? > > > > > > > >What is the problem, you're asking? > > > >There are actually no problems. I agree it would be the > > > >perfect world to have in-band configuration. But here are some > > > >arguments against the idea. Actually I even think a little bit > > > >further: the exporter configuration is out of the scope of > > > >this charter. > > > > > > You yourself is convinced to have single point configuration > > and control thr' inband > > > management. I can see some of your good points and issues. We > > are not thinking > > > here exporter or collector configuration split or where to > > place the functionality etc. > > > If there is a real potential problem then we should consider > > this as part of charter > > > rather than just postponing IPFIX version1 ... version 2.... etc.... > > > > But the entire issue, I don't see which problem we are trying to > > solve by having in-band configuration, > > except that it could be a nice feature to have. > > > > I would underscore the fact that exporters might be probes and midboxes that need to support more data collection functionality. Without some form of configuration, preferably in-band, their applications will be significantly limited. Obviously, we want to be able to configure an exporter. For example, just to configure what the template should be. The only conclusion that this thread draw is: in or out-of-band, I mean CLI configuration of the exporter or the exporter, via the IPFIX protocol, must be able to configure the exporter. > > > > > > > > > > > There is always a debate one can make whether to consider all > > the problems at forehand > > > or do incremental activity. I do not want to get into that. > > > > > > > > > > >1. Do you want the working group to spend the time (the money) > > > >to developp a comon provisioning protocol, IF this is even > > > >possible to have an agreement on that accross the different > > > >vendor (probes and routers), which I think is impossible. > > > > > > > > > > Flow information protocol is extensible and we cannot deal in defining > > > flows for each each and every protocols. Flow information can > > be exchanged between > > > two endpoints if they know how to interpret the fields which > > may be vendor specific. > > > > The information model must be extensible. Agreed, but this is a > > different issue than inband > > configuration. > > BTW, In Ganesh and I's draft, the collector will be able to > > decode a template, even if it doesn't know > > anything about some specific fields. > > > > Through template negotiation/acknowledgement, the correct context can be set at the IPFIX end-points. This will ensure correct interpretation of received data by the collector. The periodic template refreshing scheme is less robust as losses of the template information will put the collector on hold. For some applications that require real-time information collection, this means the flow information will be delayed at least another refreshing cycle. This is not correct but I would come back on that in other thread, later. Negotation is something else that the group will have to find a rough consensus on.. I propose to just concentrate on one issue at the time, if we want to be efficient: in or out-of-band configuration. No worries, the thread for negotation would follow! Regards, Benoit. > > The CRANE protocol http://www.ietf.org/internet-drafts/draft-kzhang-crane-protocol-02.txt uses template negotiation to achieve flexibility and extensibility of flow information export. Very little contraints are imposed on what can be exported. The template negotiation typically happens once during set-up to allow the IPFIX end-points to sync. on a set of templates. The actual flow information is transfered in its native form accompanied by a template ID. I believe this is a nicer approach. > > > > > > > > > > With SNMP also every protocol defines the MIB and uses SNMP to > > exchange the > > > information. > > > > > > > > > Typically, Management protocols are provides mechanisms how to > > exchange and not what to exchange. > > > The latter thing is more addressed by MIB which is a generic to > > represent attributes which are to > > > be managed. > > > > Agreed. I don't recall writing something which goes against that > > principle. > > > > > > > > > > > So in principle we have MIB and management protocol two are > > logically separate functional entities. > > > > Same remark > > > > > > > > > > > Ok,its a matter of time and design team effort to put that, > > we should not leave any items > > > which are essential candidates. > > > > > > > > > >2. What would happen with proprietary features, which most > > > >likely will not be part of the IPFIX provisioning protocol. So > > > >anyway we will have to use a different way of provisioning the > > > >device, like CLI for example, next to IPFIX. This will bypass > > > >the use of IPFIX provisioning protocol. > > > > > > > See my previous comments. > > > > > > >4. SNMP is widely used. Why? because the S stands for simple. > > > >And now, along the time, it has been evolving because there > > > >are new needs. > > > >I would like to start with something Simple, that everybody agrees on. > > > >And if there is a need for in-band configuration, then we can > > > >think of IPFIX2. > > > >Why trying to have an ISO standard from version 1? ;) > > > >You can give me a long list of nice idea about in-band > > > >configuration that I'm sure I would love to have in a perfect > > > >world but let's start with something Simple. > > > >Don't forget that simplicity is the key for interoperability. > > > >If not yet convinced: have you already compared Snmp and CMIP? > > > > > > > > > > I agree that we start with simple, that does not mean that we > > should complete > > > in hurry without addressing the other issues. > > > > > > My advice is that be patient and cool when you reply. What i > > asked is more of > > > clarification but your reply is not on those lines. > > > > > > > > > > > > >6. IPFIX stands for Flow Information eXport. So we have to > > > >standardize the export, not the configuration. So the > > > >direction:exporter -> collector and not the direction > > > >collector -> exporter. At least for version 1. > > > > > > We are not talking version of IPFIX in our charter and it may be > > > your assumption. > > > > No assumption here, I'm only trying to find a consensus. > > So instead of just saying NO, I'm proposing the following: > > if there is a really a need (a real potential problem, according > > to your own words), it's time to give > > your technical arguments. > > If not, let's investigate this nice-to-have feature later, maybe > > in version 2. > > > > Regards, Benoit > > > > > > > > -- > > 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/ > > > > > -- 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 Feb 14 12:59:42 2002 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 MAA02492 for ; Thu, 14 Feb 2002 12:59:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bPvR-0006uT-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 11:44:05 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bPvP-0006tx-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 11:44:03 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1EHhWg36966; Thu, 14 Feb 2002 18:43:32 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id SAA01292; Thu, 14 Feb 2002 18:43:28 +0100 Date: Thu, 14 Feb 2002 18:45:17 +0100 From: Juergen Quittek To: ram.gopal@nokia.com, reinaldo_penno@nortelnetworks.com, calato@riverstonenet.com, bclaise@cisco.com cc: zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Message-ID: <100036035.1013712317@[192.168.102.31]> In-Reply-To: X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ram, --On 14 February 2002 06:14 -0500 ram.gopal@nokia.com wrote: > Hello, > > See my inline comments. > > >> Our charter tells us to "select a protocol by which >> IP flow information can be transferred" and I would >> prefer not to go beyond this. > > Transfer of flow information may not refer only to > monitoring. I interpreted as one can monitor and then > transfer ( exchange) flows between endpoints . > To do this one has to configure first what we are > interested in - that means configure, monitor and transfer > flows. No one doubts that we have to configure the device. However, I do not understand how you imply from the term "transfer IP flow Information" that transferring configuration information in the opposite direction is included. Juergen > I am not sure and would like to get clarify my doubt, > > If we have in-band management what is the problem? > It's is a good choice whether there is no flaw and it is > good to control from one place to do both configure and > manage the network elements. If we provide proper security > mechanism and ensure that the devices gets the proper > commands similar to CLI then what's the problem ? I think Benoit already listed a several reasons. My major one is complexity. It is really hard to specify a protocol with all state transitions clearly and it is even harder to implement it without (or almost without) bugs. A general system design rule is that you cannot build complex things from scratch. More complex systems should be build upon the experience with less complex ones. So, let's first build a simpler IPFIX without in-band configuration and if this works fine and gets accepted, then let's think about sophisticated ways of configuration including in-band, out-of-band special protocol, COPS/SPPI SNMP/SMI, etc. > > I can understand currently most of network elements > configuration happens thro' CLI or other mechanisms.... > > Take for example SNMP is used only as monitoring tool > and but people are working on to making configuration > also thro' SNMP and seperate activity is going on in > IETF community itself. Yes, and I appreciate this and contribute to it now and then. But why is this an agrument for in-band configuration? If you suggest to have an IPFIX-MIB module, then we can argue about that. > > > Regards > Ramg > > > > -- 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 Feb 14 13:03:51 2002 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 NAA04170 for ; Thu, 14 Feb 2002 13:03:51 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bPqa-0006rA-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 11:39:04 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bPqY-0006qC-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 11:39:03 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g1EHcCU24080; Thu, 14 Feb 2002 18:38:12 +0100 (CET) Date: Thu, 14 Feb 2002 18:38:12 +0100 (CET) From: Benoit Claise Message-Id: <200202141738.g1EHcCU24080@bru-cse-222.cisco.com> To: calato@riverstonenet.com, bclaise@cisco.com, reinaldo_penno@nortelnetworks.com Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to d raft-ietf-ipfix-reqs-00.txt Cc: quittek@ccrle.nec.de, ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver Hello, > > Hello, > > Last I counted we had most people saying that it's useful but we should > tackle this later, except for Me, Kevin and Ram that would like to see it > now. K.C said it was nice, Paul and Mike that it was for after "IPfixv1" and > Benoit, Ganesh, Juergen and Will saying no. > > So in terms of number of vendors (I agree with Benoit that the important > thing is the number of vendors adopting it) it seems there is an agreement > to investigate this problem at some point. We need then to choose the words > that reflect this position on the arch draft/req. Suggestions? Are you proposing something like in the req. draft? The exporter configuration is out of the scope of the initial version of IPFIX, but could be investigated at a latter stage. Regards, Benoit. > > Having said that I would like to clarify some points: > > One is that the idea was never to have a "common provisioning protocol". > Provisioning seems a pretty heavy word. The in-band config would facilite > things like template negotiation associate with flow metering capabilities > and the like. So, in fact it would help configuring vendor specific features > like extended flow information, etc > > Second, the fact that "the meter will be built partially in hardware which > is costly. Here we can > save a lot by reducing some functions. " is a implementation > issue...Somebody else cold say that their meter would be build on software > (a PC-appliance for instance) so they do not care. So trying to be fair with > all possible IPfix users, I think we should drop this specific point > altogether. > > Now, as I said, I think Benoit had a good point on the adoption of such a > mechanism, ie, How many vendors would implement this in-band configuration. > If we can base the vendors on the people that work for them, I would say up > to this point 4-5 (not sure what percentage of companies that will really > build an IPfix collector or exporter this represents). > > regards, > > Reinaldo > > > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Thursday, February 14, 2002 6:24 AM > >To: Benoit Claise > >Cc: quittek@ccrle.nec.de; ram.gopal@nokia.com; zander@fokus.gmd.de; > >ipfix-req@net.doit.wisc.edu > >Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to > >draft-ietf-ipfix-reqs-00.txt > > > > > > > >I vote no in-band configuration in IPFIX V1. > > > >Benoit Claise wrote: > >> > >> Hi Ram and All, > >> > >> We've discussing the in-band configuration for a few times > >without conclusions. > >> I propose to use this thread to arrive to a rough consensus > >and close the discussion one for all. Otherwise we're turning > >in circles and loosing everybody's time! > >> And if we can't get a consensus, the chairmen and area > >directors will have to take a decision. > >> > >> Note: please let's try to concentrate on just one issue: > >in-band configuration and not capability negotiation and > >transport negotiation. One step at the time please. > >> > >> > > >> > > >> > >Our charter tells us to "select a protocol by which > >> > >IP flow information can be transferred" and I would > >> > >prefer not to go beyond this. > >> > > >> > Transfer of flow information may not refer only to > >monitoring. I interpreted as > >> > one can monitor and then transfer ( exchange) flows > >between endpoints . To do this one has > >> > to configure first what we are interested in - that means > >configure, monitor and transfer > >> > flows. > >> > > >> > I am not sure and would like to get clarify my doubt, > >> > > >> > If we have in-band management what is the problem? It's is > >a good choice whether > >> > there is no flaw and it is good to control from one place > >to do both configure and manage the network > >> > elements. If we provide proper security mechanism and > >ensure that the devices gets > >> > the proper commands similar to CLI then what's the problem ? > >> > >> What is the problem, you're asking? > >> There are actually no problems. I agree it would be the > >perfect world to have in-band configuration. But here are some > >arguments against the idea. Actually I even think a little bit > >further: the exporter configuration is out of the scope of > >this charter. > >> > >> 1. Do you want the working group to spend the time (the > >money) to developp a comon provisioning protocol, IF this is > >even possible to have an agreement on that accross the > >different vendor (probes and routers), which I think is impossible. > >> > >> 2. What would happen with proprietary features, which most > >likely will not be part of the IPFIX provisioning protocol. So > >anyway we will have to use a different way of provisioning the > >device, like CLI for example, next to IPFIX. This will bypass > >the use of IPFIX provisioning protocol. > >> > >> 3. How many vendors would implement this in-band configuration? > >> Because at the end this is the final question. What's the > >point to have a IETF protocol that no/not many vendors are > >going to implement. > >> Do you think that vendors will spend time and money to > >developp again another configuration interface, next to CLI, > >SNMP, XML, etc...? And this just for an IPFIX protocol! > >> > >> 4. SNMP is widely used. Why? because the S stands for simple. > >> And now, along the time, it has been evolving because there > >are new needs. > >> I would like to start with something Simple, that everybody > >agrees on. > >> And if there is a need for in-band configuration, then we > >can think of IPFIX2. > >> Why trying to have an ISO standard from version 1? ;) > >> You can give me a long list of nice idea about in-band > >configuration that I'm sure I would love to have in a perfect > >world but let's start with something Simple. > >> Don't forget that simplicity is the key for interoperability. > >> If not yet convinced: have you already compared Snmp and CMIP? > >> > >> 5. From the charter, "select a protocol by which IP flow > >information can be transferred" as Juergen said already. I > >would not beyond this point. > >> OK, you (Ramg) have a different view. > >> > >> 6. IPFIX stands for Flow Information eXport. So we have to > >standardize the export, not the configuration. So the > >direction:exporter -> collector and not the direction > >collector -> exporter. At least for version 1. > >> > >> 7. Email from Nevil Brownlee, Subject: [ipfix] Comments on > >'goals of IPFX WG' > >> http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html > >> 2. IPFIX is *not* trying to standardise a flow meter, > >i.e. a network > >> entity which measures flows - we already have RFCs > >which do that, > >> e.g. those for RTFM (2720 .. 2724). Existing widely-used > >> implementations can remain different, but might > >perhaps be extended > >> to report flow information in the IPFIX lingua franca. > >> > >> 3. Instead, we recognise that network equipment > >vendors already have > >> flow measurement systems implemented as part of their > >equipment. > >> Our goal is to make the IPFIX flow information export system > >> so good technically that all vendors will be happy to implement > >> it, for the benefit of all users of the data. A > >useful side-effect > >> will be that IPFIX will make it easier to build and maintain > >> interoperable flow data collecting systems. > >> > >> As we're not supposed to standardise a flow meter, why would > >we standardize its configuration? This email just expresses > >that the exporter configuration is out of the scope of the charter. > >> > >> 8. Juergen's argument: "Please consider that the meter will > >be built partially in hardware which is costly. Here we can > >save a lot by reducing some functions. > >> The data collector implemented by software can be much more flexible > >> with less cost." > >> > >> Regards, Benoit. > >> > >> > > >> > I can understand currently most of network elements > >configuration happens thro' CLI or other mechanisms.... > >> > > >> > Take for example SNMP is used only as monitoring tool and > >but people are working on to making configuration > >> > also thro' SNMP and seperate activity is going on in IETF > >community itself. > >> > > >> > > >> > Regards > >> > Ramg > >> > > >> > > >> > > >> > > >> > >> -- > >> 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/ > > > >-- > >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/ > > -- 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 Feb 14 13:07:14 2002 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 NAA04579 for ; Thu, 14 Feb 2002 13:07:14 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bQ2P-00074d-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 11:51:17 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bQ2M-000740-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 11:51:14 -0600 Received: from Kevinz (1Cust82.tnt4.dca5.da.uu.net [65.229.19.82]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1EHp8l32677; Thu, 14 Feb 2002 09:51:08 -0800 Reply-To: From: "Kevin Zhang" To: "Benoit Claise" , , Cc: , Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Thu, 14 Feb 2002 12:52:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200202141739.g1EHd6J24129@bru-cse-222.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id NAA04579 Hi Benoit, Please see my comments, Thanks, Kevin > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Thursday, February 14, 2002 12:39 PM > To: bclaise@cisco.com; ram.gopal@nokia.com; kevin.zhang@xacct.com > Cc: quittek@ccrle.nec.de; ipfix-req@net.doit.wisc.edu > Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to > draft-ietf-ipfix-reqs-00.txt > > > Hi Kevin, > > > > > My comments are inserted, thanks. > > > > Kevin > > > > > -----Original Message----- > > > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > > Of Benoit Claise > > > Sent: Thursday, February 14, 2002 10:09 AM > > > To: ram.gopal@nokia.com > > > Cc: quittek@ccrle.nec.de; zander@fokus.gmd.de; > > > ipfix-req@net.doit.wisc.edu > > > Subject: Re: in band configuration? RE: [ipfix-req] Proposed > changes to > > > draft-ietf-ipfix-reqs-00.txt > > > > > > > > > Ramg, > > > > > > > > > > > >> If we have in-band management what is the problem? It's is a > > > > >good choice whether > > > > >> there is no flaw and it is good to control from one place to > > > > >do both configure and manage the network > > > > >> elements. If we provide proper security mechanism and ensure > > > > >that the devices gets > > > > >> the proper commands similar to CLI then what's the problem ? > > > > > > > > > >What is the problem, you're asking? > > > > >There are actually no problems. I agree it would be the > > > > >perfect world to have in-band configuration. But here are some > > > > >arguments against the idea. Actually I even think a little bit > > > > >further: the exporter configuration is out of the scope of > > > > >this charter. > > > > > > > > You yourself is convinced to have single point configuration > > > and control thr' inband > > > > management. I can see some of your good points and issues. We > > > are not thinking > > > > here exporter or collector configuration split or where to > > > place the functionality etc. > > > > If there is a real potential problem then we should consider > > > this as part of charter > > > > rather than just postponing IPFIX version1 ... version 2.... etc.... > > > > > > But the entire issue, I don't see which problem we are trying to > > > solve by having in-band configuration, > > > except that it could be a nice feature to have. > > > > > > > I would underscore the fact that exporters might be probes and > midboxes that need to support more data collection functionality. > Without some form of configuration, preferably in-band, their > applications will be significantly limited. > > Obviously, we want to be able to configure an exporter. For > example, just to configure what the template should be. This I totally agree with you, template configuration/negotiation is the minimum the IPFIX should support. And it should be done in-band as this is an integral part of a flow export protocol. > The only conclusion that this thread draw is: in or out-of-band, > I mean CLI configuration of the exporter or the exporter, via the > IPFIX protocol, must be able to configure the exporter. I am not very clear about this point. Could you clarify? I assume in-band configuration refers to configuration through IPFIX control messages. > > > > > > > > > > > > > > > > There is always a debate one can make whether to consider all > > > the problems at forehand > > > > or do incremental activity. I do not want to get into that. > > > > > > > > > > > > > >1. Do you want the working group to spend the time (the money) > > > > >to developp a comon provisioning protocol, IF this is even > > > > >possible to have an agreement on that accross the different > > > > >vendor (probes and routers), which I think is impossible. > > > > > > > > > > > > > Flow information protocol is extensible and we cannot deal > in defining > > > > flows for each each and every protocols. Flow information can > > > be exchanged between > > > > two endpoints if they know how to interpret the fields which > > > may be vendor specific. > > > > > > The information model must be extensible. Agreed, but this is a > > > different issue than inband > > > configuration. > > > BTW, In Ganesh and I's draft, the collector will be able to > > > decode a template, even if it doesn't know > > > anything about some specific fields. > > > > > > > Through template negotiation/acknowledgement, the correct > context can be set at the IPFIX end-points. This will ensure > correct interpretation of received data by the collector. The > periodic template refreshing scheme is less robust as losses of > the template information will put the collector on hold. For > some applications that require real-time information collection, > this means the flow information will be delayed at least another > refreshing cycle. > > This is not correct but I would come back on that in other thread, later. > Negotation is something else that the group will have to find a > rough consensus on.. > I propose to just concentrate on one issue at the time, if we > want to be efficient: in or out-of-band configuration. No > worries, the thread for negotation would follow! > Agree > Regards, Benoit. > > > > > The CRANE protocol > http://www.ietf.org/internet-drafts/draft-kzhang-crane-protocol-02 > .txt uses template negotiation to achieve flexibility and > extensibility of flow information export. Very little contraints > are imposed on what can be exported. The template negotiation > typically happens once during set-up to allow the IPFIX > end-points to sync. on a set of templates. The actual flow > information is transfered in its native form accompanied by a > template ID. I believe this is a nicer approach. > > > > > > > > > > > > > > With SNMP also every protocol defines the MIB and uses SNMP to > > > exchange the > > > > information. > > > > > > > > > > > > Typically, Management protocols are provides mechanisms how to > > > exchange and not what to exchange. > > > > The latter thing is more addressed by MIB which is a generic to > > > represent attributes which are to > > > > be managed. > > > > > > Agreed. I don't recall writing something which goes against that > > > principle. > > > > > > > > > > > > > > > So in principle we have MIB and management protocol two are > > > logically separate functional entities. > > > > > > Same remark > > > > > > > > > > > > > > > Ok,its a matter of time and design team effort to put that, > > > we should not leave any items > > > > which are essential candidates. > > > > > > > > > > > > >2. What would happen with proprietary features, which most > > > > >likely will not be part of the IPFIX provisioning protocol. So > > > > >anyway we will have to use a different way of provisioning the > > > > >device, like CLI for example, next to IPFIX. This will bypass > > > > >the use of IPFIX provisioning protocol. > > > > > > > > > See my previous comments. > > > > > > > > >4. SNMP is widely used. Why? because the S stands for simple. > > > > >And now, along the time, it has been evolving because there > > > > >are new needs. > > > > >I would like to start with something Simple, that > everybody agrees on. > > > > >And if there is a need for in-band configuration, then we can > > > > >think of IPFIX2. > > > > >Why trying to have an ISO standard from version 1? ;) > > > > >You can give me a long list of nice idea about in-band > > > > >configuration that I'm sure I would love to have in a perfect > > > > >world but let's start with something Simple. > > > > >Don't forget that simplicity is the key for interoperability. > > > > >If not yet convinced: have you already compared Snmp and CMIP? > > > > > > > > > > > > > I agree that we start with simple, that does not mean that we > > > should complete > > > > in hurry without addressing the other issues. > > > > > > > > My advice is that be patient and cool when you reply. What i > > > asked is more of > > > > clarification but your reply is not on those lines. > > > > > > > > > > > > > > > > >6. IPFIX stands for Flow Information eXport. So we have to > > > > >standardize the export, not the configuration. So the > > > > >direction:exporter -> collector and not the direction > > > > >collector -> exporter. At least for version 1. > > > > > > > > We are not talking version of IPFIX in our charter and it may be > > > > your assumption. > > > > > > No assumption here, I'm only trying to find a consensus. > > > So instead of just saying NO, I'm proposing the following: > > > if there is a really a need (a real potential problem, according > > > to your own words), it's time to give > > > your technical arguments. > > > If not, let's investigate this nice-to-have feature later, maybe > > > in version 2. > > > > > > Regards, Benoit > > > > > > > > > > > > -- > > > 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/ > > > > > > > > > > ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Thu Feb 14 13:23:52 2002 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 NAA05323 for ; Thu, 14 Feb 2002 13:23:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bQI9-0007T7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 12:07:33 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bQI7-0007SP-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 12:07:31 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1EI70h23513; Thu, 14 Feb 2002 10:07:00 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE78315; Thu, 14 Feb 2002 10:07:23 -0800 (PST) Message-ID: <3C6BFCC5.EBA3CE5F@cisco.com> Date: Thu, 14 Feb 2002 10:07:01 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ram.gopal@nokia.com CC: quittek@ccrle.nec.de, reinaldo_penno@nortelnetworks.com, calato@riverstonenet.com, bclaise@cisco.com, zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ram, What does inband configuration mean? I'm taking just a few .. 1. Defining an observation point : Eg. The collector now has to say let the set of interfaces {a,b,..} belong to this observation point. So now the collector needs to know what kind of interfaces these are, their characteristics, whether they are groupable etc. All these rules have to be fed into the collector and these mostly would be vendor dependent.Boxes from different vendors exhibit different characteristics for these groupings. 2. Defining a metering process: Metering process can be defined at different levels at the time of observing the packets or after aggregating. There are a wide variety of metering mechanisms that are adopted today in terms of metering. In many cases the sequences in which metering is done is very important especially in the hardware switching platforms. Is the collector expected to know all these intricate details of a platform and send an in-band configuration message? Or are the existing products to be re-engineered to suit IPFIX protocol? Thanks Ganesh ram.gopal@nokia.com wrote: > Hello, > > See my inline comments. > > >Our charter tells us to "select a protocol by which > >IP flow information can be transferred" and I would > >prefer not to go beyond this. > > Transfer of flow information may not refer only to monitoring. I interpreted as > one can monitor and then transfer ( exchange) flows between endpoints . To do this one has > to configure first what we are interested in - that means configure, monitor and transfer > flows. > > I am not sure and would like to get clarify my doubt, > > If we have in-band management what is the problem? It's is a good choice whether > there is no flaw and it is good to control from one place to do both configure and manage the network > elements. If we provide proper security mechanism and ensure that the devices gets > the proper commands similar to CLI then what's the problem ? > > I can understand currently most of network elements configuration happens thro' CLI or other mechanisms.... > > Take for example SNMP is used only as monitoring tool and but people are working on to making configuration > also thro' SNMP and seperate activity is going on in IETF community itself. > > > Regards > Ramg > > > > -- > 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/ -- 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 Feb 14 13:26:57 2002 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 NAA05377 for ; Thu, 14 Feb 2002 13:26:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bQGt-0007RX-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 12:06:15 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bQGq-0007Qt-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 12:06:12 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1EI5gg37975; Thu, 14 Feb 2002 19:05:42 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01586; Thu, 14 Feb 2002 19:05:37 +0100 Date: Thu, 14 Feb 2002 19:07:23 +0100 From: Juergen Quittek To: Reinaldo Penno , calato@riverstonenet.com, Benoit Claise cc: ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to d raft-ietf-ipfix-reqs-00.txt Message-ID: <101361471.1013713643@[192.168.102.31]> In-Reply-To: <4F973E944951D311B6660008C7917CF008A73397@zsc4c008.us.nortel.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo, --On 14 February 2002 07:23 -0800 Reinaldo Penno wrote: > > Hello, > > Last I counted we had most people saying that it's useful but > we should tackle this later, except for Me, Kevin and Ram that > would like to see it now. K.C said it was nice, Paul and Mike > that it was for after "IPfixv1" and Benoit, Ganesh, Juergen and > Will saying no. I share Paul's and Mike's position. > So in terms of number of vendors (I agree with Benoit that the > important thing is the number of vendors adopting it) it seems > there is an agreement to investigate this problem at some point. > We need then to choose the words that reflect this position > on the arch draft/req. Suggestions? This is the requirements discussion, not the architecture discussion. So, there is the possibility of not having a in-band configuration requirement, which still would in no way excludes in-band configuration in the architecture. There have been several arguments that there are too many MUSTs in the requirements and I am currently looking for superfluous ones. Most of the MUSTs were derived from the applications. What application would necessarily require in-band configuration? If we do not find a good argument here, my proposal is not to mention in-band configuration in the requirements document. Juergen > Having said that I would like to clarify some points: > > One is that the idea was never to have a "common provisioning protocol". Provisioning seems a pretty heavy word. The in-band config would facilite things like template negotiation associate with flow metering capabilities and the like. So, in fact it > would help configuring vendor specific features like extended flow information, etc > > Second, the fact that "the meter will be built partially in hardware which is costly. Here we can > save a lot by reducing some functions. " is a implementation issue...Somebody else cold say that their meter would be build on software (a PC-appliance for instance) so they do not care. So trying to be fair with all possible IPfix users, I think we > should drop this specific point altogether. > > Now, as I said, I think Benoit had a good point on the adoption of such a mechanism, ie, How many vendors would implement this in-band configuration. If we can base the vendors on the people that work for them, I would say up to this point 4-5 (not > sure what percentage of companies that will really build an IPfix collector or exporter this represents). > > regards, > > Reinaldo > > >> -----Original Message----- >> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >> Sent: Thursday, February 14, 2002 6:24 AM >> To: Benoit Claise >> Cc: quittek@ccrle.nec.de; ram.gopal@nokia.com; zander@fokus.gmd.de; >> ipfix-req@net.doit.wisc.edu >> Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to >> draft-ietf-ipfix-reqs-00.txt >> >> >> >> I vote no in-band configuration in IPFIX V1. >> >> Benoit Claise wrote: >>> >>> Hi Ram and All, >>> >>> We've discussing the in-band configuration for a few times >> without conclusions. >>> I propose to use this thread to arrive to a rough consensus >> and close the discussion one for all. Otherwise we're turning >> in circles and loosing everybody's time! >>> And if we can't get a consensus, the chairmen and area >> directors will have to take a decision. >>> >>> Note: please let's try to concentrate on just one issue: >> in-band configuration and not capability negotiation and >> transport negotiation. One step at the time please. >>> >>> > >>> > >>> > > Our charter tells us to "select a protocol by which >>> > > IP flow information can be transferred" and I would >>> > > prefer not to go beyond this. >>> > >>> > Transfer of flow information may not refer only to >> monitoring. I interpreted as >>> > one can monitor and then transfer ( exchange) flows >> between endpoints . To do this one has >>> > to configure first what we are interested in - that means >> configure, monitor and transfer >>> > flows. >>> > >>> > I am not sure and would like to get clarify my doubt, >>> > >>> > If we have in-band management what is the problem? It's is >> a good choice whether >>> > there is no flaw and it is good to control from one place >> to do both configure and manage the network >>> > elements. If we provide proper security mechanism and >> ensure that the devices gets >>> > the proper commands similar to CLI then what's the problem ? >>> >>> What is the problem, you're asking? >>> There are actually no problems. I agree it would be the >> perfect world to have in-band configuration. But here are some >> arguments against the idea. Actually I even think a little bit >> further: the exporter configuration is out of the scope of >> this charter. >>> >>> 1. Do you want the working group to spend the time (the >> money) to developp a comon provisioning protocol, IF this is >> even possible to have an agreement on that accross the >> different vendor (probes and routers), which I think is impossible. >>> >>> 2. What would happen with proprietary features, which most >> likely will not be part of the IPFIX provisioning protocol. So >> anyway we will have to use a different way of provisioning the >> device, like CLI for example, next to IPFIX. This will bypass >> the use of IPFIX provisioning protocol. >>> >>> 3. How many vendors would implement this in-band configuration? >>> Because at the end this is the final question. What's the >> point to have a IETF protocol that no/not many vendors are >> going to implement. >>> Do you think that vendors will spend time and money to >> developp again another configuration interface, next to CLI, >> SNMP, XML, etc...? And this just for an IPFIX protocol! >>> >>> 4. SNMP is widely used. Why? because the S stands for simple. >>> And now, along the time, it has been evolving because there >> are new needs. >>> I would like to start with something Simple, that everybody >> agrees on. >>> And if there is a need for in-band configuration, then we >> can think of IPFIX2. >>> Why trying to have an ISO standard from version 1? ;) >>> You can give me a long list of nice idea about in-band >> configuration that I'm sure I would love to have in a perfect >> world but let's start with something Simple. >>> Don't forget that simplicity is the key for interoperability. >>> If not yet convinced: have you already compared Snmp and CMIP? >>> >>> 5. From the charter, "select a protocol by which IP flow >> information can be transferred" as Juergen said already. I >> would not beyond this point. >>> OK, you (Ramg) have a different view. >>> >>> 6. IPFIX stands for Flow Information eXport. So we have to >> standardize the export, not the configuration. So the >> direction:exporter -> collector and not the direction >> collector -> exporter. At least for version 1. >>> >>> 7. Email from Nevil Brownlee, Subject: [ipfix] Comments on >> 'goals of IPFX WG' >>> http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html >>> 2. IPFIX is *not* trying to standardise a flow meter, >> i.e. a network >>> entity which measures flows - we already have RFCs >> which do that, >>> e.g. those for RTFM (2720 .. 2724). Existing widely-used >>> implementations can remain different, but might >> perhaps be extended >>> to report flow information in the IPFIX lingua franca. >>> >>> 3. Instead, we recognise that network equipment >> vendors already have >>> flow measurement systems implemented as part of their >> equipment. >>> Our goal is to make the IPFIX flow information export system >>> so good technically that all vendors will be happy to implement >>> it, for the benefit of all users of the data. A >> useful side-effect >>> will be that IPFIX will make it easier to build and maintain >>> interoperable flow data collecting systems. >>> >>> As we're not supposed to standardise a flow meter, why would >> we standardize its configuration? This email just expresses >> that the exporter configuration is out of the scope of the charter. >>> >>> 8. Juergen's argument: "Please consider that the meter will >> be built partially in hardware which is costly. Here we can >> save a lot by reducing some functions. >>> The data collector implemented by software can be much more flexible >>> with less cost." >>> >>> Regards, Benoit. >>> >>> > >>> > I can understand currently most of network elements >> configuration happens thro' CLI or other mechanisms.... >>> > >>> > Take for example SNMP is used only as monitoring tool and >> but people are working on to making configuration >>> > also thro' SNMP and seperate activity is going on in IETF >> community itself. >>> > >>> > >>> > Regards >>> > Ramg >>> > >>> > >>> > >>> > >>> >>> -- >>> 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/ >> >> -- >> 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/ -- 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 Feb 14 14:03:11 2002 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 OAA06511 for ; Thu, 14 Feb 2002 14:03:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bQlh-0000JU-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 12:38:05 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bQld-0000Id-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 12:38:01 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1EIbBg39980; Thu, 14 Feb 2002 19:37:11 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA01866; Thu, 14 Feb 2002 19:37:09 +0100 Date: Thu, 14 Feb 2002 19:38:56 +0100 From: Juergen Quittek To: Nevil Brownlee , ipfix@net.doit.wisc.edu cc: bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu Subject: Re: [ipfix] WG process: a proposal Message-ID: <103254453.1013715536@[192.168.102.31]> In-Reply-To: X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil and Dave, You suggested a editor team of 4, but now we have 6 volunteers: Paul, KC, Reinaldo, Ram, Kevin and me. I am sure that all of us are well motivated and capable of doing a good job. Therefore, selecting just 4 might disappoint one or the other. Therefore I suggest taking all 6 instead of 4 and dividing us into two groups of 3, one for each document. However you decide, please decide soon, because we just have one week left and there is still a lot of work ahead. We need to arrange phone conferences, distribute the work and come up with the documents until next Friday. Cheers, Juergen --On 14 February 2002 11:23 +1300 Nevil Brownlee wrote: > > Hello all: > > Various people have been asking for some direction from the WG chairs > as to where we're heading with the two current documents. After some > discussion between Dave and myself, I'd like to suggest the following: > > A: Background > > 1) At the Salt Lake City IETF we called for volunteers to work on > the two IPFIX documents, as set out in the WG charter. About > 20 people volunteered. > > 2) After an initial flurry of discussion on the IPFIX list, things > went quiet. We set up some extra sub-lists to help the design > team members get some initial discussions going. > > 3) KC Norseth stepped forward and posted some skeleton documents. > These were simply lists of section headings based on the > 'IPFIX requirements' document. > > 4) KC also proposed a design teleconference. That idea was > welcomed, and the conference was scheduled for 31 January. > > 5) At that point a group from Cisco, led by Benoit and Ganesh, > came forward with a much more complete document, which they > published as an individual Internet draft, so everyone could > read it and comment. This was a very considerable contribution > to the WG. > > 6) The teleconference was held, with many people participating. > Minutes were posted on the list. Since then there has been > a *lot* of discussion on the list and sublists. Many people > (including those from Cisco) have contributed text, which KC > has edited together to form a second document. This will > shortly be published as a second individual draft. > > 7) We now have two documents, each with lots of worthwhile material > in them. I suspect there is a feeling that these are, somehow, > competing proposals - this is not the case. Both are serious > contributions to the WG effort. > > B: What next? > > From the WG co-chairs point of view, any documents being produced as > WG drafts need to be the result of open discussion in the WG, i.e. on > its mailing list. The co-chairs' role is to facilitate discussion, > and to guide it towards actually delivering documents as per the WG's > charter goals. Decisions about the technical merit of text in various > sections of the document needs to be decided by consensus on the list. > > Ideally, we'd like to get to the next IETF meeting (Minneapolis in > March) with a single document to review / discuss / amend. So how > can we achieve that? > > I propose that > > 1) We form a small 'editorial' team, with two people from those > working on each of the two current documents (4 altogether). > > 2) We ask the editorial team to merge the documents together, > and publish the resulting document(s) as IPFX WG drafts. > > 3) The members of the design team - i.e. all those who've contributed > text to the drafts - will be listed in the 'Acknowledgements' > section of all drafts produced. The editors of each document > will appear as the document authors. > > 4) Watching the mailing list discussion, this is starting to > happen as a natural development anyway. Agreeing to proceed > in this way would simply introduce a little formality to it, > and make the process clear to everyone. > > One other comment. This WG has certainly generated plenty of interesting > discussion on its mailing list. It's clear that all those involved > are putting a lot of effort into our goal of producing the best > technical solutions. Thanks all round. > > I'd like comments / feedback on this notion from all concerned, please. > In particular, if we can agree to proceed in this way, we need to > decide who's on the editorial team ... > > Cheers, Nevil > > +---------------------------------------------------------------------+ > | Nevil Brownlee Director, Technology Development | > | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | > +---------------------------------------------------------------------P > > > -- > 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/ > -- 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 Feb 14 14:06:32 2002 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 OAA06633 for ; Thu, 14 Feb 2002 14:06:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bQvQ-0000Te-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 12:48:08 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bQvN-0000Si-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 12:48:06 -0600 Received: from postal.cisco.com (postal.cisco.com [171.71.160.26]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1EIl2Z14443; Thu, 14 Feb 2002 10:47:11 -0800 (PST) Received: from WILLW2K (dhcp-171-71-126-47.cisco.com [171.71.126.47]) by postal.cisco.com (Mirapoint) with SMTP id AAK30703; Thu, 14 Feb 2002 10:47:24 -0800 (PST) Reply-To: From: "Will Eatherton" To: "Juergen Quittek" , "Nevil Brownlee" , Cc: , , , Subject: RE: [ipfix] WG process: a proposal Date: Thu, 14 Feb 2002 10:46:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <103254453.1013715536@[192.168.102.31]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, Proposal was 2 from each exisiting draft (from first draft I assume Ganesh/Benoit). So that is 6 volunteers for 2 slots. Since I have not volunteered I will feel comfortable pushing that I believe it should be kept to 4 total since otherwise I expect the group to have as much trouble reaching consensus as we have seen occur on the the list thus far. The rest of us will defintely continue to provide input in the form of reviews, but a cohesive document is going to require a small team with somewhat similar starting views on what the scope of this document is. Will > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Juergen Quittek > Sent: Thursday, February 14, 2002 10:39 AM > To: Nevil Brownlee; ipfix@net.doit.wisc.edu > Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; > plonka@doit.wisc.edu > Subject: Re: [ipfix] WG process: a proposal > > > Nevil and Dave, > > You suggested a editor team of 4, but now we have 6 > volunteers: Paul, KC, Reinaldo, Ram, Kevin and me. > > I am sure that all of us are well motivated and capable > of doing a good job. Therefore, selecting just 4 might > disappoint one or the other. > > Therefore I suggest taking all 6 instead of 4 > and dividing us into two groups of 3, > one for each document. > > However you decide, please decide soon, because we just > have one week left and there is still a lot of work ahead. > We need to arrange phone conferences, distribute the work > and come up with the documents until next Friday. > > Cheers, > > Juergen > > > --On 14 February 2002 11:23 +1300 Nevil Brownlee > wrote: > > > > > Hello all: > > > > Various people have been asking for some direction from the WG chairs > > as to where we're heading with the two current documents. After some > > discussion between Dave and myself, I'd like to suggest the following: > > > > A: Background > > > > 1) At the Salt Lake City IETF we called for volunteers to work on > > the two IPFIX documents, as set out in the WG charter. About > > 20 people volunteered. > > > > 2) After an initial flurry of discussion on the IPFIX list, things > > went quiet. We set up some extra sub-lists to help the design > > team members get some initial discussions going. > > > > 3) KC Norseth stepped forward and posted some skeleton documents. > > These were simply lists of section headings based on the > > 'IPFIX requirements' document. > > > > 4) KC also proposed a design teleconference. That idea was > > welcomed, and the conference was scheduled for 31 January. > > > > 5) At that point a group from Cisco, led by Benoit and Ganesh, > > came forward with a much more complete document, which they > > published as an individual Internet draft, so everyone could > > read it and comment. This was a very considerable contribution > > to the WG. > > > > 6) The teleconference was held, with many people participating. > > Minutes were posted on the list. Since then there has been > > a *lot* of discussion on the list and sublists. Many people > > (including those from Cisco) have contributed text, which KC > > has edited together to form a second document. This will > > shortly be published as a second individual draft. > > > > 7) We now have two documents, each with lots of worthwhile material > > in them. I suspect there is a feeling that these are, somehow, > > competing proposals - this is not the case. Both are serious > > contributions to the WG effort. > > > > B: What next? > > > > From the WG co-chairs point of view, any documents being produced as > > WG drafts need to be the result of open discussion in the WG, i.e. on > > its mailing list. The co-chairs' role is to facilitate discussion, > > and to guide it towards actually delivering documents as per the WG's > > charter goals. Decisions about the technical merit of text in various > > sections of the document needs to be decided by consensus on the list. > > > > Ideally, we'd like to get to the next IETF meeting (Minneapolis in > > March) with a single document to review / discuss / amend. So how > > can we achieve that? > > > > I propose that > > > > 1) We form a small 'editorial' team, with two people from those > > working on each of the two current documents (4 altogether). > > > > 2) We ask the editorial team to merge the documents together, > > and publish the resulting document(s) as IPFX WG drafts. > > > > 3) The members of the design team - i.e. all those who've contributed > > text to the drafts - will be listed in the 'Acknowledgements' > > section of all drafts produced. The editors of each document > > will appear as the document authors. > > > > 4) Watching the mailing list discussion, this is starting to > > happen as a natural development anyway. Agreeing to proceed > > in this way would simply introduce a little formality to it, > > and make the process clear to everyone. > > > > One other comment. This WG has certainly generated plenty of interesting > > discussion on its mailing list. It's clear that all those involved > > are putting a lot of effort into our goal of producing the best > > technical solutions. Thanks all round. > > > > I'd like comments / feedback on this notion from all concerned, please. > > In particular, if we can agree to proceed in this way, we need to > > decide who's on the editorial team ... > > > > Cheers, Nevil > > > > +---------------------------------------------------------------------+ > > | Nevil Brownlee Director, Technology Development | > > | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | > > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | > > +---------------------------------------------------------------------P > > > > > > -- > > 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/ > > > > > > -- > 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/ -- 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 Feb 14 14:19:34 2002 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 OAA06968 for ; Thu, 14 Feb 2002 14:19:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bRAL-0000qe-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 13:03:33 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bRAJ-0000po-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 13:03:31 -0600 Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1EJ2ph07547; Thu, 14 Feb 2002 11:02:51 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-59.cisco.com [171.71.137.59]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ABY53734; Thu, 14 Feb 2002 11:00:24 -0800 (PST) Message-ID: <3C6C09D9.9DB5AFCB@cisco.com> Date: Thu, 14 Feb 2002 11:02:49 -0800 From: Peram Marimuthu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Nevil Brownlee , ipfix@net.doit.wisc.edu, bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu Subject: Re: [ipfix] WG process: a proposal References: <103254453.1013715536@[192.168.102.31]> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, I dont believe this is what Nevil/Dave wanted. If I read the message correctly, Nevil was suggesting respresentation from draft-gsadasiv and the other draft that KC is putting together equally. My recommendation is to form a team only with people with significant inputs into the documents - Not just people that can say "I am interested" three times. I would recommend keeping the three editors - KC, Ganesh and Benoit as the editors of the current combined draft. As people start contributing significantly to the outcome of the combined draft, they join the editorial team. Peram Juergen Quittek wrote: > Nevil and Dave, > > You suggested a editor team of 4, but now we have 6 > volunteers: Paul, KC, Reinaldo, Ram, Kevin and me. > > I am sure that all of us are well motivated and capable > of doing a good job. Therefore, selecting just 4 might > disappoint one or the other. > > Therefore I suggest taking all 6 instead of 4 > and dividing us into two groups of 3, > one for each document. > > However you decide, please decide soon, because we just > have one week left and there is still a lot of work ahead. > We need to arrange phone conferences, distribute the work > and come up with the documents until next Friday. > > Cheers, > > Juergen > > --On 14 February 2002 11:23 +1300 Nevil Brownlee wrote: > > > > > Hello all: > > > > Various people have been asking for some direction from the WG chairs > > as to where we're heading with the two current documents. After some > > discussion between Dave and myself, I'd like to suggest the following: > > > > A: Background > > > > 1) At the Salt Lake City IETF we called for volunteers to work on > > the two IPFIX documents, as set out in the WG charter. About > > 20 people volunteered. > > > > 2) After an initial flurry of discussion on the IPFIX list, things > > went quiet. We set up some extra sub-lists to help the design > > team members get some initial discussions going. > > > > 3) KC Norseth stepped forward and posted some skeleton documents. > > These were simply lists of section headings based on the > > 'IPFIX requirements' document. > > > > 4) KC also proposed a design teleconference. That idea was > > welcomed, and the conference was scheduled for 31 January. > > > > 5) At that point a group from Cisco, led by Benoit and Ganesh, > > came forward with a much more complete document, which they > > published as an individual Internet draft, so everyone could > > read it and comment. This was a very considerable contribution > > to the WG. > > > > 6) The teleconference was held, with many people participating. > > Minutes were posted on the list. Since then there has been > > a *lot* of discussion on the list and sublists. Many people > > (including those from Cisco) have contributed text, which KC > > has edited together to form a second document. This will > > shortly be published as a second individual draft. > > > > 7) We now have two documents, each with lots of worthwhile material > > in them. I suspect there is a feeling that these are, somehow, > > competing proposals - this is not the case. Both are serious > > contributions to the WG effort. > > > > B: What next? > > > > From the WG co-chairs point of view, any documents being produced as > > WG drafts need to be the result of open discussion in the WG, i.e. on > > its mailing list. The co-chairs' role is to facilitate discussion, > > and to guide it towards actually delivering documents as per the WG's > > charter goals. Decisions about the technical merit of text in various > > sections of the document needs to be decided by consensus on the list. > > > > Ideally, we'd like to get to the next IETF meeting (Minneapolis in > > March) with a single document to review / discuss / amend. So how > > can we achieve that? > > > > I propose that > > > > 1) We form a small 'editorial' team, with two people from those > > working on each of the two current documents (4 altogether). > > > > 2) We ask the editorial team to merge the documents together, > > and publish the resulting document(s) as IPFX WG drafts. > > > > 3) The members of the design team - i.e. all those who've contributed > > text to the drafts - will be listed in the 'Acknowledgements' > > section of all drafts produced. The editors of each document > > will appear as the document authors. > > > > 4) Watching the mailing list discussion, this is starting to > > happen as a natural development anyway. Agreeing to proceed > > in this way would simply introduce a little formality to it, > > and make the process clear to everyone. > > > > One other comment. This WG has certainly generated plenty of interesting > > discussion on its mailing list. It's clear that all those involved > > are putting a lot of effort into our goal of producing the best > > technical solutions. Thanks all round. > > > > I'd like comments / feedback on this notion from all concerned, please. > > In particular, if we can agree to proceed in this way, we need to > > decide who's on the editorial team ... > > > > Cheers, Nevil > > > > +---------------------------------------------------------------------+ > > | Nevil Brownlee Director, Technology Development | > > | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | > > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | > > +---------------------------------------------------------------------P > > > > > > -- > > 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/ > > > > -- > 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/ -- 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 Feb 14 14:23:02 2002 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 OAA07068 for ; Thu, 14 Feb 2002 14:23:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bRE6-0000w4-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 13:07:26 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bRE3-0000up-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 13:07:24 -0600 Received: from Kevinz (1Cust185.tnt16.dca5.da.uu.net [63.10.64.185]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1EJ6jl00980; Thu, 14 Feb 2002 11:06:45 -0800 Reply-To: From: "Kevin Zhang" To: "Juergen Quittek" , "Nevil Brownlee" , Cc: , , , Subject: RE: [ipfix] WG process: a proposal Date: Thu, 14 Feb 2002 14:07:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <103254453.1013715536@[192.168.102.31]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA07068 Hi Nevil and Dave, I will second Juergen's proposal. Let's have the 6 volunteers do some heavy editing based on what we have currently without introducing new technical issues. Given the 22nd deadline, we need to get started right away. Thanks, Kevin > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Juergen Quittek > Sent: Thursday, February 14, 2002 1:39 PM > To: Nevil Brownlee; ipfix@net.doit.wisc.edu > Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; > plonka@doit.wisc.edu > Subject: Re: [ipfix] WG process: a proposal > > > Nevil and Dave, > > You suggested a editor team of 4, but now we have 6 > volunteers: Paul, KC, Reinaldo, Ram, Kevin and me. > > I am sure that all of us are well motivated and capable > of doing a good job. Therefore, selecting just 4 might > disappoint one or the other. > > Therefore I suggest taking all 6 instead of 4 > and dividing us into two groups of 3, > one for each document. > > However you decide, please decide soon, because we just > have one week left and there is still a lot of work ahead. > We need to arrange phone conferences, distribute the work > and come up with the documents until next Friday. > > Cheers, > > Juergen > > > --On 14 February 2002 11:23 +1300 Nevil Brownlee > wrote: > > > > > Hello all: > > > > Various people have been asking for some direction from the WG chairs > > as to where we're heading with the two current documents. After some > > discussion between Dave and myself, I'd like to suggest the following: > > > > A: Background > > > > 1) At the Salt Lake City IETF we called for volunteers to work on > > the two IPFIX documents, as set out in the WG charter. About > > 20 people volunteered. > > > > 2) After an initial flurry of discussion on the IPFIX list, things > > went quiet. We set up some extra sub-lists to help the design > > team members get some initial discussions going. > > > > 3) KC Norseth stepped forward and posted some skeleton documents. > > These were simply lists of section headings based on the > > 'IPFIX requirements' document. > > > > 4) KC also proposed a design teleconference. That idea was > > welcomed, and the conference was scheduled for 31 January. > > > > 5) At that point a group from Cisco, led by Benoit and Ganesh, > > came forward with a much more complete document, which they > > published as an individual Internet draft, so everyone could > > read it and comment. This was a very considerable contribution > > to the WG. > > > > 6) The teleconference was held, with many people participating. > > Minutes were posted on the list. Since then there has been > > a *lot* of discussion on the list and sublists. Many people > > (including those from Cisco) have contributed text, which KC > > has edited together to form a second document. This will > > shortly be published as a second individual draft. > > > > 7) We now have two documents, each with lots of worthwhile material > > in them. I suspect there is a feeling that these are, somehow, > > competing proposals - this is not the case. Both are serious > > contributions to the WG effort. > > > > B: What next? > > > > From the WG co-chairs point of view, any documents being produced as > > WG drafts need to be the result of open discussion in the WG, i.e. on > > its mailing list. The co-chairs' role is to facilitate discussion, > > and to guide it towards actually delivering documents as per the WG's > > charter goals. Decisions about the technical merit of text in various > > sections of the document needs to be decided by consensus on the list. > > > > Ideally, we'd like to get to the next IETF meeting (Minneapolis in > > March) with a single document to review / discuss / amend. So how > > can we achieve that? > > > > I propose that > > > > 1) We form a small 'editorial' team, with two people from those > > working on each of the two current documents (4 altogether). > > > > 2) We ask the editorial team to merge the documents together, > > and publish the resulting document(s) as IPFX WG drafts. > > > > 3) The members of the design team - i.e. all those who've contributed > > text to the drafts - will be listed in the 'Acknowledgements' > > section of all drafts produced. The editors of each document > > will appear as the document authors. > > > > 4) Watching the mailing list discussion, this is starting to > > happen as a natural development anyway. Agreeing to proceed > > in this way would simply introduce a little formality to it, > > and make the process clear to everyone. > > > > One other comment. This WG has certainly generated plenty of interesting > > discussion on its mailing list. It's clear that all those involved > > are putting a lot of effort into our goal of producing the best > > technical solutions. Thanks all round. > > > > I'd like comments / feedback on this notion from all concerned, please. > > In particular, if we can agree to proceed in this way, we need to > > decide who's on the editorial team ... > > > > Cheers, Nevil > > > > +---------------------------------------------------------------------+ > > | Nevil Brownlee Director, Technology Development | > > | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | > > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | > > +---------------------------------------------------------------------P > > > > > > -- > > 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/ > > > > > > -- > 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/ > > ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Thu Feb 14 14:23:54 2002 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 OAA07149 for ; Thu, 14 Feb 2002 14:23:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bREY-0000wD-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 13:07:54 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bREW-0000vy-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 13:07:52 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1EJ7Lt18396; Thu, 14 Feb 2002 11:07:21 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE81140; Thu, 14 Feb 2002 11:07:43 -0800 (PST) Message-ID: <3C6C0AE7.2D15B7BE@cisco.com> Date: Thu, 14 Feb 2002 11:07:19 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Sebastian Zander , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again References: <97914445.1013710196@[192.168.102.31]> Content-Type: multipart/alternative; boundary="------------ADC3CF9B39C9BEC6A057DC47" Precedence: bulk Sender: majordomo listserver --------------ADC3CF9B39C9BEC6A057DC47 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jurgene, I am of the opinion that "header capturing" is a metering function.I see restrictions with your model. Escpecially if some kind of metering is done on collected flows within the router. It was with this in mind that I send out in one of my previous mails the high level picture. Did not get any response. So I am resending with some more modification. I am slightly inclined to think that the metering process within the observation domain could be hierarchical but have not put it here. What are your inputs? +---------------------------------------------------------------+ | Observation Domain | | | | +-------+ +-------+ Packet level| | |Meter1 | .... |MeterM | ({Fi}, {Si})| | |Process| |Process| | | +-------+ +-------+ | | ^ ^ | | | | | | +-------+-------+ +-------+--------+ | | | | | | | | v v v v | |+------------+ +------------+ +------------+ +------------+| ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| |+------------+ +------------+ +------------+ +------------+| +---------------------------------------------------------------+ ^ ^ | | v v +----------+ +----------+ |Meter (O1)| .... |Meter (OP)| Flow Level +----------+ +----------+ ({Fi}, {Si}) | | +-------+--------+ | v (uniqued ID for an observation domain) +---------------+ | exporter | +---------------+ Thanks Ganesh Juergen Quittek wrote: > Hi Sabastian, > > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: > > > Hi Juergen, > > > > Juergen Quittek schrieb: > >> > >> Hi all, > >> > >> We had some terminology discussion and it has not > >> converged yet. Therfore I like to raise one issue again: > >> > >> For the terinology section of the requirements draft > >> (I belive now it will be a subset of the architecture's > >> terminology) I would like to have two identifiers for > >> the following: > >> > >> 1. the function block containing all metering functions > >> This block gets as input observed (and potentially > >> sampled) packets from the observation point. It classifies > >> packets maps them to flows and creates/updates the > >> according flow record. > >> > >> 2. the function block sending flow records to the collector > >> > >> I am fine with splitting blocks more or modifying them > >> slightly, but I prefer to have this separation, because > >> also the requirements are split in a very similar way. > > > > I also would like to split those for at least 2 reasons. > > First we create a more general model because on a router linecard > > both are be combined but on a dedicated hardware/software based > > meter this will probably not the case. I don't think we should limit > > ipfix to routers only. Second the separation is nice to clarify > > the scope. The scope of the ipfix wg is to standardize the > > exporter (at least the interface to the outside). It's out > > of scope to standardize the meter (although we put some req. > > on it). > > > > I am not sure whether sampling is a function of the observation > > point or the meter. > > Neither am I, but we should agree on one or the other soon. > What about the following (short version of more detailed > suggestions already discussed for the architecture)? > > +-------+ +-----------+ +-------+ +--------+ +--------+ > | obs. | | header | | | | flow | | ex- | > | point |-->| capturing |-->| meter |-->| record |-->| porter | > +-------+ +-----------+ +-------+ +--------+ +--------+ > > | | > \____________________________ _____________________________/ > \/ > IPFIX traffic flow measurement module > > If can tell me a good reason I am fine with merging header capturing > and meter, but in general I see them as different function blocks. > > Juergen > > >> My initial naive suggestion was calling block 1. "meter" > >> and calling block 2. "exporter". However this might (no it > >> did already) cause confusion. Therefore, I am looking for > >> better terms. Any suggestions? > > > > I have no better terms. I think what's maybe confusing is that we don't > > have a term for the overall process (meter+exporter+observation). > > What could be appropriate? flow monitor? > > > > Another possibility: Name the overall process metering and rename > > the inner function block 1 which does classification etc. > > > > Sebastian > > > > -- > > Sebastian Zander E-mail: zander@fokus.fhg.de > > FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > > D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > > > > -- > 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/ --------------ADC3CF9B39C9BEC6A057DC47 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jurgene,
   I am of the opinion that "header capturing" is a metering
   function.I see restrictions with your model. Escpecially
   if some kind of metering is done on collected flows within
   the router. It was with this in mind that I send out in one of
   my previous mails the high level picture. Did not get any
   response. So I am resending with some more modification. I am
   slightly inclined to think that the metering process within
   the observation domain could be hierarchical but have not put
   it here.
   What are your inputs?
 

+---------------------------------------------------------------+
|                   Observation Domain                          |
|                                                               |
|          +-------+                      +-------+ Packet level|
|          |Meter1 |         ....         |MeterM | ({Fi}, {Si})|
|          |Process|                      |Process|             |
|          +-------+                      +-------+             |
|              ^                              ^                 |
|              |                              |                 |
|      +-------+-------+              +-------+--------+        |
|      |               |              |                |        |
|      v               v              v                v        |
|+------------+  +------------+  +------------+   +------------+|
||Obsv Point11|..|Obsv Point1k|  |Obsv PointM1|.. |Obsv PointMn||
|+------------+  +------------+  +------------+   +------------+|
+---------------------------------------------------------------+
              ^                     ^
              |                     |
              v                     v
         +----------+          +----------+
         |Meter (O1)|   ....   |Meter (OP)| Flow Level
         +----------+          +----------+ ({Fi}, {Si})
                 |                |
                 +-------+--------+
                         |
                         v (uniqued ID for an observation domain)
                 +---------------+
                 |  exporter     |
                 +---------------+
 

Thanks
Ganesh

Juergen Quittek wrote:

Hi Sabastian,

--On 14 February 2002 11:07 +0100 Sebastian Zander <zander@fokus.gmd.de> wrote:

> Hi Juergen,
>
> Juergen Quittek schrieb:
>>
>> Hi all,
>>
>> We had some terminology discussion and it has not
>> converged yet. Therfore I like to raise one issue again:
>>
>> For the terinology section of the requirements draft
>> (I belive now it will be a subset of the architecture's
>> terminology) I would like to have two identifiers for
>> the following:
>>
>>  1. the function block containing all metering functions
>>     This block gets as input observed (and potentially
>>     sampled) packets from the observation point. It classifies
>>     packets maps them to flows and creates/updates the
>>     according flow record.
>>
>>  2. the function block sending flow records to the collector
>>
>> I am fine with splitting blocks more or modifying them
>> slightly, but I prefer to have this separation, because
>> also the requirements are split in a very similar way.
>
> I also would like to split those for at least 2 reasons.
> First we create a more general model because on a router linecard
> both are be combined but on a dedicated hardware/software based
> meter this will probably not the case. I don't think we should limit
> ipfix to routers only. Second the separation is nice to clarify
> the scope. The scope of the ipfix wg is to standardize the
> exporter (at least the interface to the outside). It's out
> of scope to standardize the meter (although we put some req.
> on it).
>
> I am not sure whether sampling is a function of the observation
> point or the meter.

Neither am I, but we should agree on one or the other soon.
What about the following (short version of more detailed
suggestions already discussed for the architecture)?

   +-------+   +-----------+   +-------+   +--------+   +--------+
   | obs.  |   | header    |   |       |   | flow   |   | ex-    |
   | point |-->| capturing |-->| meter |-->| record |-->| porter |
   +-------+   +-----------+   +-------+   +--------+   +--------+

   |                                                             |
    \____________________________  _____________________________/
                                 \/
                  IPFIX traffic flow measurement module

If can tell me a good reason I am fine with merging header capturing
and meter, but in general I see them as different function blocks.

    Juergen

>> My initial naive suggestion was calling block 1. "meter"
>> and calling block 2. "exporter". However this might (no it
>> did already) cause confusion. Therefore, I am looking for
>> better terms. Any suggestions?
>
> I have no better terms. I think what's maybe confusing is that we don't
> have a term for the overall process (meter+exporter+observation).
> What could be appropriate? flow monitor?
>
> Another possibility: Name the overall process metering and rename
> the inner function block 1 which does classification etc.
>
> Sebastian
>
> --
> Sebastian Zander                         E-mail: zander@fokus.fhg.de
> FhI FOKUS / Global Networking (GloNe)    Tel: +49-30-3463-7287
> Kaiserin-Augusta-Allee 31                Fax: +49-30-3463-8287
> D-10589 Berlin, Germany                  www.fokus.fhg.de/usr/sebastian.zander
>

--
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/

--------------ADC3CF9B39C9BEC6A057DC47-- -- 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 Feb 14 15:48:13 2002 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 PAA09286 for ; Thu, 14 Feb 2002 15:48:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bS4F-000244-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 14:01:19 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bS4D-00023w-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 14:01:17 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA26082; Thu, 14 Feb 2002 15:10:22 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xmaa26021; Thu, 14 Feb 02 15:09:24 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXPFA9>; Thu, 14 Feb 2002 14:58:54 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06CA@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Peram Marimuthu'" , Juergen Quittek Cc: Nevil Brownlee , ipfix@net.doit.wisc.edu, bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu Subject: RE: [ipfix] WG process: a proposal Date: Thu, 14 Feb 2002 14:59:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B592.11A3BA80" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B592.11A3BA80 Content-Type: text/plain I am not the only one with significant inputs. One of my responsibilities on the design team was to combine the work of the contributers into the team draft. Everyone who has volunteered to be on the review team has contributed major sections to the team drafts. Their input has been valueable and extensive. K.C. |-----Original Message----- |From: Peram Marimuthu [mailto:peram@cisco.com] |Sent: Thursday, February 14, 2002 12:03 PM |To: Juergen Quittek |Cc: Nevil Brownlee; ipfix@net.doit.wisc.edu; |bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; |plonka@doit.wisc.edu |Subject: Re: [ipfix] WG process: a proposal | | |Juergen, | |I dont believe this is what Nevil/Dave wanted. If I read the |message correctly, Nevil was suggesting respresentation from |draft-gsadasiv and the other draft that KC is putting together equally. | |My recommendation is to form a team only with people with |significant inputs into the documents - Not just people that |can say "I am interested" three times. I would recommend |keeping the three editors - KC, Ganesh and Benoit as the |editors of the current combined draft. As people start |contributing significantly to the outcome of the combined |draft, they join the editorial team. | |Peram | |Juergen Quittek wrote: | |> Nevil and Dave, |> |> You suggested a editor team of 4, but now we have 6 |> volunteers: Paul, KC, Reinaldo, Ram, Kevin and me. |> |> I am sure that all of us are well motivated and capable |> of doing a good job. Therefore, selecting just 4 might |disappoint one |> or the other. |> |> Therefore I suggest taking all 6 instead of 4 |> and dividing us into two groups of 3, |> one for each document. |> |> However you decide, please decide soon, because we just |> have one week left and there is still a lot of work ahead. |> We need to arrange phone conferences, distribute the work |> and come up with the documents until next Friday. |> |> Cheers, |> |> Juergen |> |> --On 14 February 2002 11:23 +1300 Nevil Brownlee |> wrote: |> |> > |> > Hello all: |> > |> > Various people have been asking for some direction from the WG |> > chairs as to where we're heading with the two current documents. |> > After some discussion between Dave and myself, I'd like to suggest |> > the following: |> > |> > A: Background |> > |> > 1) At the Salt Lake City IETF we called for volunteers to work on |> > the two IPFIX documents, as set out in the WG charter. About |> > 20 people volunteered. |> > |> > 2) After an initial flurry of discussion on the IPFIX list, things |> > went quiet. We set up some extra sub-lists to help the design |> > team members get some initial discussions going. |> > |> > 3) KC Norseth stepped forward and posted some skeleton documents. |> > These were simply lists of section headings based on the |> > 'IPFIX requirements' document. |> > |> > 4) KC also proposed a design teleconference. That idea was |> > welcomed, and the conference was scheduled for 31 January. |> > |> > 5) At that point a group from Cisco, led by Benoit and Ganesh, |> > came forward with a much more complete document, which they |> > published as an individual Internet draft, so everyone could |> > read it and comment. This was a very considerable contribution |> > to the WG. |> > |> > 6) The teleconference was held, with many people participating. |> > Minutes were posted on the list. Since then there has been |> > a *lot* of discussion on the list and sublists. Many people |> > (including those from Cisco) have contributed text, which KC |> > has edited together to form a second document. This will |> > shortly be published as a second individual draft. |> > |> > 7) We now have two documents, each with lots of worthwhile material |> > in them. I suspect there is a feeling that these are, somehow, |> > competing proposals - this is not the case. Both are serious |> > contributions to the WG effort. |> > |> > B: What next? |> > |> > From the WG co-chairs point of view, any documents being |produced as |> > WG drafts need to be the result of open discussion in the WG, i.e. |> > on its mailing list. The co-chairs' role is to facilitate |> > discussion, and to guide it towards actually delivering |documents as |> > per the WG's charter goals. Decisions about the technical |merit of |> > text in various sections of the document needs to be decided by |> > consensus on the list. |> > |> > Ideally, we'd like to get to the next IETF meeting (Minneapolis in |> > March) with a single document to review / discuss / amend. So how |> > can we achieve that? |> > |> > I propose that |> > |> > 1) We form a small 'editorial' team, with two people from those |> > working on each of the two current documents (4 altogether). |> > |> > 2) We ask the editorial team to merge the documents together, |> > and publish the resulting document(s) as IPFX WG drafts. |> > |> > 3) The members of the design team - i.e. all those who've |contributed |> > text to the drafts - will be listed in the 'Acknowledgements' |> > section of all drafts produced. The editors of each document |> > will appear as the document authors. |> > |> > 4) Watching the mailing list discussion, this is starting to |> > happen as a natural development anyway. Agreeing to proceed |> > in this way would simply introduce a little formality to it, |> > and make the process clear to everyone. |> > |> > One other comment. This WG has certainly generated plenty of |> > interesting discussion on its mailing list. It's clear that all |> > those involved are putting a lot of effort into our goal of |> > producing the best technical solutions. Thanks all round. |> > |> > I'd like comments / feedback on this notion from all concerned, |> > please. In particular, if we can agree to proceed in this way, we |> > need to decide who's on the editorial team ... |> > |> > Cheers, Nevil |> > |> > |+---------------------------------------------------------------------+ |> > | Nevil Brownlee Director, Technology |Development | |> > | Phone: +64 9 373 7599 x8941 ITSS, The University |of Auckland | |> > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, |New Zealand | |> > |+------------------------------------------------------------------- |> > +--P |> > |> > |> > -- |> > 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/ |> > |> |> -- |> 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/ | | |-- |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/ | ------_=_NextPart_001_01C1B592.11A3BA80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] WG process: a proposal

I am not the only one with significant inputs.  = One of my responsibilities on the design team was to combine the work = of the contributers into the team draft.  Everyone who has = volunteered to be on the review team has contributed major sections to = the team drafts.  Their input has been valueable and = extensive.

K.C.

|-----Original Message-----
|From: Peram Marimuthu [mailto:peram@cisco.com]
|Sent: Thursday, February 14, 2002 12:03 PM
|To: Juergen Quittek
|Cc: Nevil Brownlee; ipfix@net.doit.wisc.edu; =
|bclaise@cisco.com; gsadasiv@cisco.com; = kcn@norseth.com;
|plonka@doit.wisc.edu
|Subject: Re: [ipfix] WG process: a proposal
|
|
|Juergen,
|
|I dont believe this is what Nevil/Dave wanted. If I = read the
|message correctly, Nevil was suggesting = respresentation from
|draft-gsadasiv and the other draft that KC is = putting together equally.
|
|My recommendation is to form a team only with = people with
|significant inputs into the documents - Not just = people that
|can say "I am interested" three times. I = would recommend
|keeping the three editors - KC, Ganesh and Benoit = as the
|editors of the current combined draft. As people = start
|contributing significantly to the outcome of the = combined
|draft, they join the editorial team.
|
|Peram
|
|Juergen Quittek wrote:
|
|> Nevil and Dave,
|>
|> You suggested a editor team of 4, but now we = have 6
|> volunteers: Paul, KC, Reinaldo, Ram, Kevin and = me.
|>
|> I am sure that all of us are well motivated = and capable
|> of doing a good job. Therefore, selecting just = 4 might
|disappoint one
|> or the other.
|>
|> Therefore I suggest taking all 6 instead of = 4
|> and dividing us into two groups of 3,
|> one for each document.
|>
|> However you decide, please decide soon, = because we just
|> have one week left and there is still a lot of = work ahead.
|> We need to arrange phone conferences, = distribute the work
|> and come up with the documents until next = Friday.
|>
|> Cheers,
|>
|>     Juergen
|>
|> --On 14 February 2002 11:23 +1300 Nevil = Brownlee
|> <n.brownlee@auckland.ac.nz> wrote:=
|>
|> >
|> > Hello all:
|> >
|> > Various people have been asking for some = direction from the WG
|> > chairs as to where we're heading with the = two current documents. 
|> > After some discussion between Dave and = myself, I'd like to suggest
|> > the following:
|> >
|> > A: Background
|> >
|> > 1) At the Salt Lake City IETF we called = for volunteers to work on
|> >    the two IPFIX = documents, as set out in the WG charter.  About
|> >    20 people = volunteered.
|> >
|> > 2) After an initial flurry of discussion = on the IPFIX list, things
|> >    went quiet.  We = set up some extra sub-lists to help the design
|> >    team members get some = initial discussions going.
|> >
|> > 3) KC Norseth stepped forward and posted = some skeleton documents.
|> >    These were simply lists = of section headings based on the
|> >    'IPFIX requirements' = document.
|> >
|> > 4) KC also proposed a design = teleconference.  That idea was
|> >    welcomed, and the = conference was scheduled for 31 January.
|> >
|> > 5) At that point a group from Cisco, led = by Benoit and Ganesh,
|> >    came forward with a = much more complete document, which they
|> >    published as an = individual Internet draft, so everyone could
|> >    read it and = comment.  This was a very considerable contribution
|> >    to the WG.
|> >
|> > 6) The teleconference was held, with many = people participating.
|> >    Minutes were posted on = the list.  Since then there has been
|> >    a *lot* of discussion = on the list and sublists.  Many people
|> >    (including those from = Cisco) have contributed text, which KC
|> >    has edited together to = form a second document.  This will
|> >    shortly be published as = a second individual draft.
|> >
|> > 7) We now have two documents, each with = lots of worthwhile material
|> >    in them.  I = suspect there is a feeling that these are, somehow,
|> >    competing proposals - = this is not the case.  Both are serious
|> >    contributions to the WG = effort.
|> >
|> > B: What next?
|> >
|> > From the WG co-chairs point of view, any = documents being
|produced as
|> > WG drafts need to be the result of open = discussion in the WG, i.e.
|> > on its mailing list.  The co-chairs' = role is to facilitate
|> > discussion, and to guide it towards = actually delivering
|documents as
|> > per the WG's charter goals.  = Decisions about the technical
|merit of
|> > text in various sections of the document = needs to be decided by
|> > consensus on the list.
|> >
|> > Ideally, we'd like to get to the next = IETF meeting (Minneapolis in
|> > March) with a single document to review / = discuss / amend.  So how
|> > can we achieve that?
|> >
|> > I propose that
|> >
|> > 1) We form a small 'editorial' team, with = two people from those
|> >    working on each of the = two current documents (4 altogether).
|> >
|> > 2) We ask the editorial team to merge the = documents together,
|> >    and publish the = resulting document(s) as IPFX WG drafts.
|> >
|> > 3) The members of the design team - i.e. = all those who've
|contributed
|> >    text to the drafts - = will be listed in the 'Acknowledgements'
|> >    section of all drafts = produced. The editors of each document
|> >    will appear as the = document authors.
|> >
|> > 4) Watching the mailing list discussion, = this is starting to
|> >    happen as a natural = development anyway.  Agreeing to proceed
|> >    in this way would = simply introduce a little formality to it,
|> >    and make the process = clear to everyone.
|> >
|> > One other comment. This WG has certainly = generated plenty of
|> > interesting discussion on its mailing = list.  It's clear that all
|> > those involved are putting a lot of = effort into our goal of
|> > producing the best technical = solutions.  Thanks all round.
|> >
|> > I'd like comments / feedback on this = notion from all concerned,
|> > please. In particular, if we can agree to = proceed in this way, we
|> > need to decide who's on the editorial = team ...
|> >
|> > Cheers, Nevil
|> >
|> >
|+-------------------------------------------------------------= --------+
|> > | Nevil = Brownlee          &nbs= p;          Director, = Technology
|Development |
|> > | Phone: +64 9 373 7599 = x8941        ITSS, The University =
|of Auckland |
|> > |   FAX: +64 9 373 = 7021      Private Bag 92019, Auckland,
|New Zealand |
|> >
|+-------------------------------------------------------------= ------
|> > +--P
|> >
|> >
|> > --
|> > = Help        mailto:majordomo@net.doit.wi= sc.edu and say
|"help" in message body
|> > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe
|> > ipfix" in message body
|> > Archive     http://ipfix.doit.wisc.edu/archive/
|> >
|>
|> --
|> Help        = mailto:majordomo@net.doit.wi= sc.edu and say
|"help" in message body
|> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say "unsubscribe
|> ipfix" in message body
|> Archive     http://ipfix.doit.wisc.edu/archive/
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1B592.11A3BA80-- -- 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 Feb 14 15:50:09 2002 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 PAA09337 for ; Thu, 14 Feb 2002 15:50:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bS9X-0002Ef-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 14:06:47 -0600 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bS9U-0002EZ-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 14:06:44 -0600 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EK6tQ03313 for ; Thu, 14 Feb 2002 14:06:56 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Feb 2002 14:06:41 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 14:06:41 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipfix] WG process: a proposal X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 14 Feb 2002 15:06:40 -0500 Message-ID: Thread-Topic: [ipfix] WG process: a proposal Thread-Index: AcG1iZE5sRSuO7OaRGSm3GAXE0MeTgACeLDA From: To: , , , Cc: , , , X-OriginalArrivalTime: 14 Feb 2002 20:06:41.0251 (UTC) FILETIME=[1E13AB30:01C1B593] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA09337 Hello Will, Every one is subscribed to the email list, and mail has been sent out from the WG chair and it is not a good practice to force someone. I have not seen their response to the WG chairs request for editorial volunteers. Neither you mentioned that you are speaking with the consent of them. Moreover they are answering and listening to the other emails , it is not a good practice to refer someone with out their consent ( even if they have it is their responsibility to take interest in such activity) Coming back to your point, trying move other volunteers and making one document with the people you want to favor them is not good - we not playing we are doing a combined team effort. Regards Ramg >-----Original Message----- >From: ext Will Eatherton [mailto:will@cisco.com] >Sent: Thursday, February 14, 2002 1:47 PM >To: Juergen Quittek; Nevil Brownlee; ipfix@net.doit.wisc.edu >Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; >plonka@doit.wisc.edu >Subject: RE: [ipfix] WG process: a proposal > > >Juergen, > >Proposal was 2 from each exisiting draft (from first draft I assume >Ganesh/Benoit). So that is 6 volunteers for 2 slots. Since I have not >volunteered I will feel comfortable pushing that I believe it >should be kept >to 4 total since otherwise I expect the group to have as much trouble >reaching consensus as we have seen occur on the the list thus far. > >The rest of us will defintely continue to provide input in the form of >reviews, but a cohesive document is going to require a small team with >somewhat similar starting views on what the scope of this document is. > >Will > >> -----Original Message----- >> From: majordomo listserver >[mailto:majordomo@mil.doit.wisc.edu]On Behalf >> Of Juergen Quittek >> Sent: Thursday, February 14, 2002 10:39 AM >> To: Nevil Brownlee; ipfix@net.doit.wisc.edu >> Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; >> plonka@doit.wisc.edu >> Subject: Re: [ipfix] WG process: a proposal >> >> >> Nevil and Dave, >> >> You suggested a editor team of 4, but now we have 6 >> volunteers: Paul, KC, Reinaldo, Ram, Kevin and me. >> >> I am sure that all of us are well motivated and capable >> of doing a good job. Therefore, selecting just 4 might >> disappoint one or the other. >> >> Therefore I suggest taking all 6 instead of 4 >> and dividing us into two groups of 3, >> one for each document. >> >> However you decide, please decide soon, because we just >> have one week left and there is still a lot of work ahead. >> We need to arrange phone conferences, distribute the work >> and come up with the documents until next Friday. >> >> Cheers, >> >> Juergen >> >> >> --On 14 February 2002 11:23 +1300 Nevil Brownlee >> wrote: >> >> > >> > Hello all: >> > >> > Various people have been asking for some direction from >the WG chairs >> > as to where we're heading with the two current documents. >After some >> > discussion between Dave and myself, I'd like to suggest >the following: >> > >> > A: Background >> > >> > 1) At the Salt Lake City IETF we called for volunteers to work on >> > the two IPFIX documents, as set out in the WG charter. About >> > 20 people volunteered. >> > >> > 2) After an initial flurry of discussion on the IPFIX list, things >> > went quiet. We set up some extra sub-lists to help the design >> > team members get some initial discussions going. >> > >> > 3) KC Norseth stepped forward and posted some skeleton documents. >> > These were simply lists of section headings based on the >> > 'IPFIX requirements' document. >> > >> > 4) KC also proposed a design teleconference. That idea was >> > welcomed, and the conference was scheduled for 31 January. >> > >> > 5) At that point a group from Cisco, led by Benoit and Ganesh, >> > came forward with a much more complete document, which they >> > published as an individual Internet draft, so everyone could >> > read it and comment. This was a very considerable contribution >> > to the WG. >> > >> > 6) The teleconference was held, with many people participating. >> > Minutes were posted on the list. Since then there has been >> > a *lot* of discussion on the list and sublists. Many people >> > (including those from Cisco) have contributed text, which KC >> > has edited together to form a second document. This will >> > shortly be published as a second individual draft. >> > >> > 7) We now have two documents, each with lots of worthwhile material >> > in them. I suspect there is a feeling that these are, somehow, >> > competing proposals - this is not the case. Both are serious >> > contributions to the WG effort. >> > >> > B: What next? >> > >> > From the WG co-chairs point of view, any documents being >produced as >> > WG drafts need to be the result of open discussion in the >WG, i.e. on >> > its mailing list. The co-chairs' role is to facilitate discussion, >> > and to guide it towards actually delivering documents as >per the WG's >> > charter goals. Decisions about the technical merit of >text in various >> > sections of the document needs to be decided by consensus >on the list. >> > >> > Ideally, we'd like to get to the next IETF meeting (Minneapolis in >> > March) with a single document to review / discuss / amend. So how >> > can we achieve that? >> > >> > I propose that >> > >> > 1) We form a small 'editorial' team, with two people from those >> > working on each of the two current documents (4 altogether). >> > >> > 2) We ask the editorial team to merge the documents together, >> > and publish the resulting document(s) as IPFX WG drafts. >> > >> > 3) The members of the design team - i.e. all those who've >contributed >> > text to the drafts - will be listed in the 'Acknowledgements' >> > section of all drafts produced. The editors of each document >> > will appear as the document authors. >> > >> > 4) Watching the mailing list discussion, this is starting to >> > happen as a natural development anyway. Agreeing to proceed >> > in this way would simply introduce a little formality to it, >> > and make the process clear to everyone. >> > >> > One other comment. This WG has certainly generated plenty >of interesting >> > discussion on its mailing list. It's clear that all those involved >> > are putting a lot of effort into our goal of producing the best >> > technical solutions. Thanks all round. >> > >> > I'd like comments / feedback on this notion from all >concerned, please. >> > In particular, if we can agree to proceed in this way, we need to >> > decide who's on the editorial team ... >> > >> > Cheers, Nevil >> > >> > >+---------------------------------------------------------------------+ >> > | Nevil Brownlee Director, Technology >Development | >> > | Phone: +64 9 373 7599 x8941 ITSS, The University >of Auckland | >> > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, >New Zealand | >> > >+---------------------------------------------------------------------P >> > >> > >> > -- >> > 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/ >> > >> >> >> >> -- >> 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/ > > >-- >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/ > -- 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 Feb 14 16:06:43 2002 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 QAA09743 for ; Thu, 14 Feb 2002 16:06:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bSYG-0007DI-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 14:32:20 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bSYE-00070k-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 14:32:18 -0600 Received: from peter ([204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1EKX0l01869 for ; Thu, 14 Feb 2002 12:33:00 -0800 From: "Peter Ludemann" To: "Ipfix-Req@Net. Doit. Wisc. Edu" Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Thu, 14 Feb 2002 12:28:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C1B553.232E1460" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C1B553.232E1460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txtWhether or not we have in-band configuration, we do need a mechanism for advertising the data that a device can deliver (i.e., self-defining data). In terms of design and implementation, supporting a simple negotiation ("Don't send me x." "OK, here's a revised list of what I'm sending") isn't much more work. If you configure a device with a MIB or CLI, how do you tell the receivers about what data is being sent? How do you coordinate amongst thousands of sending devices and dozens of receivers ... doing this by hand would be a nightmare. (I'm not making up this scenario; but I can't give more details because of confidentiality issues.) There is a very pragmatic reason for having the receiver specify the fields it doesn't want. Some fields are expensive (for example, we have a probe which can look inside data streams and extract information such as URLs and response codes; it can also compute performance metrics such as response times ... when all of these are turned on, the performance can drop significantly). Having in-band configuration does not mean that a device needs to support anything beyond advertising the data that it will send. For example, with Kevin's CRANE proposal, the in-band configuration consists of: - the device ("meter") advertises the records it can send - the receiver requests restrictions on what is sent (which kinds of records, which fields in those records) - the device can ignore the restriction request So, this configuration simply offers the possibility of optimization but does not force the optimization. This kind of configuration does not specify frequency of data delivery, aggregation, filtering, etc. Currently, we do this out of band (with a CLI, MIB, or registry file) because it does not raise the coordination issues that data formats cause. We're thinking of a generic mechanism for doing configuration inside the transfer protocol, but that's a future issue that can easily be added to the existing protocol. - peter -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno Sent: Thursday, February 14, 2002 7:24 AM To: calato@riverstonenet.com; Benoit Claise Cc: quittek@ccrle.nec.de; ram.gopal@nokia.com; zander@fokus.gmd.de; ipfix-req@net.doit.wisc.edu Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Hello, Last I counted we had most people saying that it's useful but we should tackle this later, except for Me, Kevin and Ram that would like to see it now. K.C said it was nice, Paul and Mike that it was for after "IPfixv1" and Benoit, Ganesh, Juergen and Will saying no. So in terms of number of vendors (I agree with Benoit that the important thing is the number of vendors adopting it) it seems there is an agreement to investigate this problem at some point. We need then to choose the words that reflect this position on the arch draft/req. Suggestions? Having said that I would like to clarify some points: One is that the idea was never to have a "common provisioning protocol". Provisioning seems a pretty heavy word. The in-band config would facilite things like template negotiation associate with flow metering capabilities and the like. So, in fact it would help configuring vendor specific features like extended flow information, etc Second, the fact that "the meter will be built partially in hardware which is costly. Here we can save a lot by reducing some functions. " is a implementation issue...Somebody else cold say that their meter would be build on software (a PC-appliance for instance) so they do not care. So trying to be fair with all possible IPfix users, I think we should drop this specific point altogether. Now, as I said, I think Benoit had a good point on the adoption of such a mechanism, ie, How many vendors would implement this in-band configuration. If we can base the vendors on the people that work for them, I would say up to this point 4-5 (not sure what percentage of companies that will really build an IPfix collector or exporter this represents). regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Thursday, February 14, 2002 6:24 AM >To: Benoit Claise >Cc: quittek@ccrle.nec.de; ram.gopal@nokia.com; zander@fokus.gmd.de; >ipfix-req@net.doit.wisc.edu >Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to >draft-ietf-ipfix-reqs-00.txt > > > >I vote no in-band configuration in IPFIX V1. > >Benoit Claise wrote: >> >> Hi Ram and All, >> >> We've discussing the in-band configuration for a few times >without conclusions. >> I propose to use this thread to arrive to a rough consensus >and close the discussion one for all. Otherwise we're turning >in circles and loosing everybody's time! >> And if we can't get a consensus, the chairmen and area >directors will have to take a decision. >> >> Note: please let's try to concentrate on just one issue: >in-band configuration and not capability negotiation and >transport negotiation. One step at the time please. >> >> > >> > >> > >Our charter tells us to "select a protocol by which >> > >IP flow information can be transferred" and I would >> > >prefer not to go beyond this. >> > >> > Transfer of flow information may not refer only to >monitoring. I interpreted as >> > one can monitor and then transfer ( exchange) flows >between endpoints . To do this one has >> > to configure first what we are interested in - that means >configure, monitor and transfer >> > flows. >> > >> > I am not sure and would like to get clarify my doubt, >> > >> > If we have in-band management what is the problem? It's is >a good choice whether >> > there is no flaw and it is good to control from one place >to do both configure and manage the network >> > elements. If we provide proper security mechanism and >ensure that the devices gets >> > the proper commands similar to CLI then what's the problem ? >> >> What is the problem, you're asking? >> There are actually no problems. I agree it would be the >perfect world to have in-band configuration. But here are some >arguments against the idea. Actually I even think a little bit >further: the exporter configuration is out of the scope of >this charter. >> >> 1. Do you want the working group to spend the time (the >money) to developp a comon provisioning protocol, IF this is >even possible to have an agreement on that accross the >different vendor (probes and routers), which I think is impossible. >> >> 2. What would happen with proprietary features, which most >likely will not be part of the IPFIX provisioning protocol. So >anyway we will have to use a different way of provisioning the >device, like CLI for example, next to IPFIX. This will bypass >the use of IPFIX provisioning protocol. >> >> 3. How many vendors would implement this in-band configuration? >> Because at the end this is the final question. What's the >point to have a IETF protocol that no/not many vendors are >going to implement. >> Do you think that vendors will spend time and money to >developp again another configuration interface, next to CLI, >SNMP, XML, etc...? And this just for an IPFIX protocol! >> >> 4. SNMP is widely used. Why? because the S stands for simple. >> And now, along the time, it has been evolving because there >are new needs. >> I would like to start with something Simple, that everybody >agrees on. >> And if there is a need for in-band configuration, then we >can think of IPFIX2. >> Why trying to have an ISO standard from version 1? ;) >> You can give me a long list of nice idea about in-band >configuration that I'm sure I would love to have in a perfect >world but let's start with something Simple. >> Don't forget that simplicity is the key for interoperability. >> If not yet convinced: have you already compared Snmp and CMIP? >> >> 5. From the charter, "select a protocol by which IP flow >information can be transferred" as Juergen said already. I >would not beyond this point. >> OK, you (Ramg) have a different view. >> >> 6. IPFIX stands for Flow Information eXport. So we have to >standardize the export, not the configuration. So the >direction:exporter -> collector and not the direction >collector -> exporter. At least for version 1. >> >> 7. Email from Nevil Brownlee, Subject: [ipfix] Comments on >'goals of IPFX WG' >> http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html >> 2. IPFIX is *not* trying to standardise a flow meter, >i.e. a network >> entity which measures flows - we already have RFCs >which do that, >> e.g. those for RTFM (2720 .. 2724). Existing widely-used >> implementations can remain different, but might >perhaps be extended >> to report flow information in the IPFIX lingua franca. >> >> 3. Instead, we recognise that network equipment >vendors already have >> flow measurement systems implemented as part of their >equipment. >> Our goal is to make the IPFIX flow information export system >> so good technically that all vendors will be happy to implement >> it, for the benefit of all users of the data. A >useful side-effect >> will be that IPFIX will make it easier to build and maintain >> interoperable flow data collecting systems. >> >> As we're not supposed to standardise a flow meter, why would >we standardize its configuration? This email just expresses >that the exporter configuration is out of the scope of the charter. >> >> 8. Juergen's argument: "Please consider that the meter will >be built partially in hardware which is costly. Here we can >save a lot by reducing some functions. >> The data collector implemented by software can be much more flexible >> with less cost." >> >> Regards, Benoit. >> >> > >> > I can understand currently most of network elements >configuration happens thro' CLI or other mechanisms.... >> > >> > Take for example SNMP is used only as monitoring tool and >but people are working on to making configuration >> > also thro' SNMP and seperate activity is going on in IETF >community itself. >> > >> > >> > Regards >> > Ramg >> > >> > >> > >> > >> >> -- >> 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/ > >-- >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/ > ------=_NextPart_000_0002_01C1B553.232E1460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: in band configuration? RE: [ipfix-req] Proposed = changes to draft-ietf-ipfix-reqs-00.txt
Whether or not we have in-band configuration, we do need a = mechanism=20 for advertising the data that a device can deliver (i.e., self-defining=20 data). In terms of design and implementation, supporting a simple = negotiation=20 ("Don't send me x." "OK, here's a revised list of what I'm = sending")=20 isn't much more work.
 
If you configure a device with a MIB or CLI, = how do you=20 tell the receivers about what data is being sent? How do you coordinate = amongst=20 thousands of sending devices and dozens of receivers ... doing this by = hand=20 would be a nightmare. (I'm not making up this scenario; but I can't give = more=20 details because of confidentiality issues.)
 
There=20 is a very pragmatic reason for having the receiver specify the fields it = doesn't=20 want. Some fields are expensive (for example, we have a probe which = can=20 look inside data streams and extract information such as URLs and = response=20 codes; it can also compute performance metrics such as response = times ...=20 when all of these are turned on, the performance can drop=20 significantly).
 
Having in-band configuration does not mean that a = device needs=20 to support anything beyond advertising the data that it will send.=20 For example, with Kevin's CRANE proposal, the in-band = configuration=20 consists of:
- the=20 device ("meter") advertises the records it can send
- the=20 receiver requests restrictions on what is sent (which=20 kinds of records, which fields in those = records)
- the=20 device can ignore the restriction request
 
So,=20 this configuration simply offers the possibility of = optimization but=20 does not force the optimization.
 
This=20 kind of configuration does not specify frequency of=20 data delivery, aggregation, filtering, etc. Currently, we do=20 this out of band (with a CLI, MIB, or registry file) because it does not = raise=20 the coordination issues that data formats cause. We're thinking of a = generic=20 mechanism for doing configuration inside the transfer protocol, but = that's a=20 future issue that can easily be added to the existing=20 protocol.
 
-=20 peter
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo=20 Penno
Sent: Thursday, February 14, 2002 7:24 = AM
To:=20 calato@riverstonenet.com; Benoit Claise
Cc: = quittek@ccrle.nec.de;=20 ram.gopal@nokia.com; zander@fokus.gmd.de;=20 ipfix-req@net.doit.wisc.edu
Subject: RE: in band = configuration? RE:=20 [ipfix-req] Proposed changes to=20 draft-ietf-ipfix-reqs-00.txt

Hello,

Last I counted we had most people saying that it's = useful but=20 we should tackle this later, except for Me, Kevin and Ram that would = like to=20 see it now. K.C said it was nice, Paul and Mike that it was for after=20 "IPfixv1" and Benoit, Ganesh, Juergen and Will saying no.

So in terms of number of vendors (I agree with = Benoit that the=20 important thing is the number of vendors adopting it) it seems there = is an=20 agreement to investigate this problem at some point. We need then to = choose=20 the words that reflect this position on the arch draft/req. = Suggestions?=20

Having said that I would like to clarify some = points:=20

One is that the idea was never to have a "common = provisioning=20 protocol". Provisioning seems a pretty heavy word. The in-band config = would=20 facilite things like template negotiation associate with flow metering = capabilities and the like. So, in fact it would help configuring = vendor=20 specific features like extended flow information, etc

Second, the fact that "the meter will be built = partially in=20 hardware which is costly. Here we can
save a = lot by=20 reducing some functions. " is a implementation issue...Somebody else = cold say=20 that their meter would be build on software (a PC-appliance for = instance) so=20 they do not care. So trying to be fair with all possible IPfix users, = I think=20 we should drop this specific point altogether.

Now, as I said, I think Benoit had a good point on = the=20 adoption of such a mechanism, ie, How many vendors would implement = this=20 in-band configuration. If we can base the vendors on the people that = work for=20 them, I would say up to this point 4-5 (not sure what percentage of = companies=20 that will really build an IPfix collector or exporter this=20 represents).

regards,

Reinaldo



>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com<= /A>]=20
>Sent: Thursday, February 14, 2002 6:24 = AM=20
>To: Benoit Claise
>Cc:=20 quittek@ccrle.nec.de; ram.gopal@nokia.com; zander@fokus.gmd.de; =
>ipfix-req@net.doit.wisc.edu
>Subject: Re: in band configuration? RE: [ipfix-req] = Proposed=20 changes to
>draft-ietf-ipfix-reqs-00.txt=20
>
> =
>
>I vote no in-band = configuration in=20 IPFIX V1.
>
>Benoit=20 Claise wrote:
>>
>> Hi Ram and All,
>>=20
>> We've discussing the in-band = configuration=20 for a few times
>without = conclusions.=20
>> I propose to use this thread to arrive to = a rough=20 consensus
>and close the discussion one = for all.=20 Otherwise we're turning
>in circles and = loosing=20 everybody's time!
>> And if we can't = get a=20 consensus, the chairmen and area
>directors will=20 have to take a decision.
>> =
>> Note: please let's try to concentrate on just one = issue:=20
>in-band configuration and not capability = negotiation and
>transport negotiation. = One step at=20 the time please.
>>
>> >
>> > =
>> > >Our charter tells us to "select a protocol = by=20 which
>> > >IP flow information = can be=20 transferred" and I would
>> > = >prefer not=20 to go beyond this.
>> > =
>> > Transfer  of flow information may not = refer only to=20
>monitoring. I interpreted as =
>> > one  can monitor and then transfer ( = exchange) flows=20
>between endpoints . To do this one = has=20
>> > to  configure first what we are = interested=20 in - that means
>configure, monitor and=20 transfer
>> > flows. =
>> >
>> > I am = not sure and=20 would like to get clarify my doubt,
>> = >
>> > If we have in-band = management what=20 is the problem? It's is
>a good choice=20 whether
>> > there is no flaw and = it is good=20 to control from one place
>to do both = configure and=20 manage the network
>> > elements. = If we=20 provide proper security mechanism and
>ensure that=20 the devices gets
>> > the proper=20 commands  similar to CLI then  what's the problem ? =
>>
>> What is the = problem, you're=20 asking?
>> There are actually no = problems. I=20 agree it would be the
>perfect world to = have=20 in-band configuration. But here are some
>arguments=20 against the idea. Actually I even think a little bit
>further: the exporter configuration is out of the scope = of=20
>this charter.
>>=20
>> 1. Do you want the working group to = spend the=20 time (the
>money) to developp a comon = provisioning=20 protocol, IF this is
>even possible to = have an=20 agreement on that accross the
>different = vendor=20 (probes and routers), which I think is impossible.
>>
>> 2. What would = happen with=20 proprietary features, which most
>likely = will not=20 be part of the IPFIX provisioning protocol. So
>anyway we will have to use a different way of = provisioning the=20
>device, like CLI for example, next to = IPFIX. This=20 will bypass
>the use of IPFIX = provisioning=20 protocol.
>>
>> 3.=20 How many vendors would implement this in-band configuration? =
>> Because at the end this is the final question. = What's the=20
>point to have a IETF protocol that = no/not many=20 vendors are
>going to implement. =
>> Do you think that vendors will spend time and money = to=20
>developp again another configuration = interface,=20 next to CLI,
>SNMP, XML, etc...?  = And this=20 just for an IPFIX protocol!
>> =
>> 4. SNMP is widely used. Why? because the S stands = for=20 simple.
>> And now, along the time, it = has been=20 evolving because there
>are new = needs.=20
>> I would like to start with something = Simple, that=20 everybody
>agrees on.
>> And if there is a need for in-band configuration, = then we=20
>can think of IPFIX2.
>> Why trying to have an ISO standard from version 1? = ;)=20
>> You can give me a long list of nice idea = about=20 in-band
>configuration that I'm sure I = would love=20 to have in a perfect
>world but let's = start with=20 something Simple.
>> Don't forget that = simplicity is the key for interoperability.
>>=20 If not yet convinced: have you already compared Snmp and CMIP?=20
>>
>> 5. From = the=20 charter, "select a protocol by which IP flow
>information can be transferred" as Juergen said already. = I=20
>would not beyond this point. =
>> OK, you (Ramg) have a different view. =
>>
>> 6. IPFIX stands = for Flow=20 Information eXport. So we have to
>standardize the=20 export, not the configuration. So the
>direction:exporter -> collector and not the direction=20
>collector -> exporter. At least for = version=20 1.
>>
>> 7. Email=20 from Nevil Brownlee, Subject: [ipfix] Comments on
>'goals of IPFX WG'
>> http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html=20
>>       2. = IPFIX is=20 *not* trying to standardise a flow meter,
>i.e. a=20 network
>>      =20 entity which measures flows - we already have RFCs
>which do that,
>>       e.g. those for = RTFM (2720=20 .. 2724).  Existing widely-used
>>       implementations = can remain=20 different, but might
>perhaps be = extended=20
>>       to = report flow=20 information in the IPFIX lingua franca.
>>=20
>>       = 3.=20 Instead, we recognise that network equipment
>vendors already have
>>       flow measurement = systems=20 implemented as part of their
>equipment.=20
>>       Our = goal is to=20 make the IPFIX flow information export system
>>       so good = technically that=20 all vendors will be happy to implement
>>       it, for the = benefit of all=20 users of the data.  A
>useful=20 side-effect
>>       will be that = IPFIX will=20 make it easier to build and maintain
>>       interoperable = flow data=20 collecting systems.
>> =
>> As we're not supposed to standardise a flow meter, = why would=20
>we standardize its configuration? This = email just=20 expresses
>that the exporter = configuration is out=20 of the scope of the charter.
>> =
>> 8. Juergen's argument: "Please consider that the = meter will=20
>be built partially in hardware which is = costly.=20 Here we can
>save a lot by reducing some=20 functions.
>> The data collector = implemented by=20 software can be much more flexible
>> = with less=20 cost."
>>
>>=20 Regards, Benoit.
>>
>> >
>> > I can=20 understand  currently most of network elements
>configuration happens thro'   CLI or other=20 mechanisms....
>> > =
>> > Take for example SNMP is used only as = monitoring tool and=20
>but people are working on to making=20 configuration
>> > also thro' SNMP = and=20 seperate activity is going on in IETF
>community=20 itself.
>> >
>>=20 >
>> > Regards
>> > Ramg
>> = >=20
>> >
>> = >=20
>> >
>>=20
>> --
>>=20 Help        mailto:majordomo@net.doit.wis= c.edu=20 and say
>"help" in message body =
>> Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
>> "unsubscribe ipfix" in = message=20 body
>> = Archive     http://ipfix.doit.wisc.edu/archive/ =
>
>--
>Help        mailto:majordomo@net.doit.wis= c.edu=20 and say "help"
>in message body =
>Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
>"unsubscribe ipfix" in message = body=20
>Archive     http://ipfix.doit.wisc.edu/archive/ =
>

------=_NextPart_000_0002_01C1B553.232E1460-- -- 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 Feb 14 16:07:04 2002 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 QAA09763 for ; Thu, 14 Feb 2002 16:07:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bSWq-0006ce-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 14:30:52 -0600 Received: from mgw-dax1.ext.nokia.com ([63.78.179.216]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bSWn-0006bW-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 14:30:49 -0600 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1EKV2Q05316 for ; Thu, 14 Feb 2002 14:31:02 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Feb 2002 14:30:47 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 14 Feb 2002 14:30:42 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipfix] WG process: a proposal X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 14 Feb 2002 15:30:41 -0500 Message-ID: Thread-Topic: [ipfix] WG process: a proposal Thread-Index: AcG1i3rRDRl8m24+SS6oH7VR7LXGGgAC3GYg From: To: , Cc: , , , , , X-OriginalArrivalTime: 14 Feb 2002 20:30:42.0818 (UTC) FILETIME=[79515620:01C1B596] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA09763 Hello Peram, You do not force Cisco people only as editors and they have not raised their desire so far in the email.In IETF individual speaks for themselves and they are also subscribed to the list. See my inline comments. >I dont believe this is what Nevil/Dave wanted. If I read the >message correctly, Nevil was suggesting respresentation from >draft-gsadasiv and the other draft that KC is putting together equally. You read once more. " 1) We form a small 'editorial' team, with two people from those working on each of the two current documents (4 altogether). " Regards Ramg > >Juergen Quittek wrote: > >> Nevil and Dave, >> >> You suggested a editor team of 4, but now we have 6 >> volunteers: Paul, KC, Reinaldo, Ram, Kevin and me. >> >> I am sure that all of us are well motivated and capable >> of doing a good job. Therefore, selecting just 4 might >> disappoint one or the other. >> >> Therefore I suggest taking all 6 instead of 4 >> and dividing us into two groups of 3, >> one for each document. >> >> However you decide, please decide soon, because we just >> have one week left and there is still a lot of work ahead. >> We need to arrange phone conferences, distribute the work >> and come up with the documents until next Friday. >> >> Cheers, >> >> Juergen >> >> --On 14 February 2002 11:23 +1300 Nevil Brownlee > wrote: >> >> > >> > Hello all: >> > >> > Various people have been asking for some direction from >the WG chairs >> > as to where we're heading with the two current documents. >After some >> > discussion between Dave and myself, I'd like to suggest >the following: >> > >> > A: Background >> > >> > 1) At the Salt Lake City IETF we called for volunteers to work on >> > the two IPFIX documents, as set out in the WG charter. About >> > 20 people volunteered. >> > >> > 2) After an initial flurry of discussion on the IPFIX list, things >> > went quiet. We set up some extra sub-lists to help the design >> > team members get some initial discussions going. >> > >> > 3) KC Norseth stepped forward and posted some skeleton documents. >> > These were simply lists of section headings based on the >> > 'IPFIX requirements' document. >> > >> > 4) KC also proposed a design teleconference. That idea was >> > welcomed, and the conference was scheduled for 31 January. >> > >> > 5) At that point a group from Cisco, led by Benoit and Ganesh, >> > came forward with a much more complete document, which they >> > published as an individual Internet draft, so everyone could >> > read it and comment. This was a very considerable contribution >> > to the WG. >> > >> > 6) The teleconference was held, with many people participating. >> > Minutes were posted on the list. Since then there has been >> > a *lot* of discussion on the list and sublists. Many people >> > (including those from Cisco) have contributed text, which KC >> > has edited together to form a second document. This will >> > shortly be published as a second individual draft. >> > >> > 7) We now have two documents, each with lots of worthwhile material >> > in them. I suspect there is a feeling that these are, somehow, >> > competing proposals - this is not the case. Both are serious >> > contributions to the WG effort. >> > >> > B: What next? >> > >> > From the WG co-chairs point of view, any documents being >produced as >> > WG drafts need to be the result of open discussion in the >WG, i.e. on >> > its mailing list. The co-chairs' role is to facilitate discussion, >> > and to guide it towards actually delivering documents as >per the WG's >> > charter goals. Decisions about the technical merit of >text in various >> > sections of the document needs to be decided by consensus >on the list. >> > >> > Ideally, we'd like to get to the next IETF meeting (Minneapolis in >> > March) with a single document to review / discuss / amend. So how >> > can we achieve that? >> > >> > I propose that >> > >> > 1) We form a small 'editorial' team, with two people from those >> > working on each of the two current documents (4 altogether). >> > >> > 2) We ask the editorial team to merge the documents together, >> > and publish the resulting document(s) as IPFX WG drafts. >> > >> > 3) The members of the design team - i.e. all those who've >contributed >> > text to the drafts - will be listed in the 'Acknowledgements' >> > section of all drafts produced. The editors of each document >> > will appear as the document authors. >> > >> > 4) Watching the mailing list discussion, this is starting to >> > happen as a natural development anyway. Agreeing to proceed >> > in this way would simply introduce a little formality to it, >> > and make the process clear to everyone. >> > >> > One other comment. This WG has certainly generated plenty >of interesting >> > discussion on its mailing list. It's clear that all those involved >> > are putting a lot of effort into our goal of producing the best >> > technical solutions. Thanks all round. >> > >> > I'd like comments / feedback on this notion from all >concerned, please. >> > In particular, if we can agree to proceed in this way, we need to >> > decide who's on the editorial team ... >> > >> > Cheers, Nevil >> > >> > >+---------------------------------------------------------------------+ >> > | Nevil Brownlee Director, Technology >Development | >> > | Phone: +64 9 373 7599 x8941 ITSS, The University >of Auckland | >> > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, >New Zealand | >> > >+---------------------------------------------------------------------P >> > >> > >> > -- >> > 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/ >> > >> >> -- >> 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/ > > >-- >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/ > -- 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 Feb 14 17:41:29 2002 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 RAA11889 for ; Thu, 14 Feb 2002 17:41:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bUFO-00038w-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 16:20:58 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bUFK-000382-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 16:20:55 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1EMKOg41500; Thu, 14 Feb 2002 23:20:24 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA03238; Thu, 14 Feb 2002 23:20:22 +0100 Date: Thu, 14 Feb 2002 23:22:09 +0100 From: Juergen Quittek To: Ganesh Sadasivan cc: Sebastian Zander , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again Message-ID: <116647842.1013728929@[192.168.102.31]> In-Reply-To: <3C6C0AE7.2D15B7BE@cisco.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ganesh, --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: > Hi Jurgene, > I am of the opinion that "header capturing" is a metering > function.I see restrictions with your model. Escpecially > if some kind of metering is done on collected flows within > the router. It was with this in mind that I send out in one of > my previous mails the high level picture. Did not get any > response. So I am resending with some more modification. I am > slightly inclined to think that the metering process within > the observation domain could be hierarchical but have not put > it here. > What are your inputs? > Please excuse that I did not reply so far on your drawing. I did not understand it when I saw it the first time and sent it to the printer to study it later. Unfortunately, that's where it still is. I should better have sent you my questions on this: 1. What is the difference between a meter process and a meter? 2. How and from where do meters get input? from meter processes? 3. Is there only one exporter per observation domain? 4. What would be the difference between an observation domain ID and an exporter ID? Cheers, Juergen > > +---------------------------------------------------------------+ > | Observation Domain | > | | > | +-------+ +-------+ Packet level| > | |Meter1 | .... |MeterM | ({Fi}, {Si})| > | |Process| |Process| | > | +-------+ +-------+ | > | ^ ^ | > | | | | > | +-------+-------+ +-------+--------+ | > | | | | | | > | v v v v | > |+------------+ +------------+ +------------+ +------------+| > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| > |+------------+ +------------+ +------------+ +------------+| > +---------------------------------------------------------------+ > ^ ^ > | | > v v > +----------+ +----------+ > |Meter (O1)| .... |Meter (OP)| Flow Level > +----------+ +----------+ ({Fi}, {Si}) > | | > +-------+--------+ > | > v (uniqued ID for an observation domain) > +---------------+ > | exporter | > +---------------+ > > > Thanks > Ganesh > > Juergen Quittek wrote: > > Hi Sabastian, > > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: > >> Hi Juergen, >> >> Juergen Quittek schrieb: >>> >>> Hi all, >>> >>> We had some terminology discussion and it has not >>> converged yet. Therfore I like to raise one issue again: >>> >>> For the terinology section of the requirements draft >>> (I belive now it will be a subset of the architecture's >>> terminology) I would like to have two identifiers for >>> the following: >>> >>> 1. the function block containing all metering functions >>> This block gets as input observed (and potentially >>> sampled) packets from the observation point. It classifies >>> packets maps them to flows and creates/updates the >>> according flow record. >>> >>> 2. the function block sending flow records to the collector >>> >>> I am fine with splitting blocks more or modifying them >>> slightly, but I prefer to have this separation, because >>> also the requirements are split in a very similar way. >> >> I also would like to split those for at least 2 reasons. >> First we create a more general model because on a router linecard >> both are be combined but on a dedicated hardware/software based >> meter this will probably not the case. I don't think we should limit >> ipfix to routers only. Second the separation is nice to clarify >> the scope. The scope of the ipfix wg is to standardize the >> exporter (at least the interface to the outside). It's out >> of scope to standardize the meter (although we put some req. >> on it). >> >> I am not sure whether sampling is a function of the observation >> point or the meter. > > Neither am I, but we should agree on one or the other soon. > What about the following (short version of more detailed > suggestions already discussed for the architecture)? > > +-------+ +-----------+ +-------+ +--------+ +--------+ > | obs. | | header | | | | flow | | ex- | > | point |-->| capturing |-->| meter |-->| record |-->| porter | > +-------+ +-----------+ +-------+ +--------+ +--------+ > > | | > \____________________________ _____________________________/ > \/ > IPFIX traffic flow measurement module > > If can tell me a good reason I am fine with merging header capturing > and meter, but in general I see them as different function blocks. > > Juergen > >>> My initial naive suggestion was calling block 1. "meter" >>> and calling block 2. "exporter". However this might (no it >>> did already) cause confusion. Therefore, I am looking for >>> better terms. Any suggestions? >> >> I have no better terms. I think what's maybe confusing is that we don't >> have a term for the overall process (meter+exporter+observation). >> What could be appropriate? flow monitor? >> >> Another possibility: Name the overall process metering and rename >> the inner function block 1 which does classification etc. >> >> Sebastian >> >> -- >> Sebastian Zander E-mail: zander@fokus.fhg.de >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander >> > > -- > 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/ > -- 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 Feb 14 17:50:57 2002 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 RAA12098 for ; Thu, 14 Feb 2002 17:50:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bUN2-0003K8-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 16:28:52 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bUMz-0003JO-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 16:28:50 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1EMSDg41523; Thu, 14 Feb 2002 23:28:13 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id XAA03271; Thu, 14 Feb 2002 23:28:07 +0100 Date: Thu, 14 Feb 2002 23:29:53 +0100 From: Juergen Quittek To: Peter Ludemann , Reinaldo Penno , calato@riverstonenet.com, Benoit Claise cc: ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu, Kevin Zhang Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Message-ID: <117111158.1013729393@[192.168.102.31]> In-Reply-To: X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Peter, So what is your point? Do you want to have in-band configuration for the exported attributes/IEs in the requirements document? What would be the application requiring this? Or from which general requirement would you derive this one? Cheers, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 14 February 2002 11:32 -0800 Peter Ludemann wrote: > > Whether or not we have in-band configuration, we do need a mechanism for advertising the data that a device can deliver (i.e., self-defining data). In terms of design and implementation, supporting a simple negotiation ("Don't send me x." "OK, here's a > revised list of what I'm sending") isn't much more work. > If you configure a device with a MIB or CLI, how do you tell the receivers about what data is being sent? How do you coordinate amongst thousands of sending devices and dozens of receivers ... doing this by hand would be a nightmare. (I'm not making up > this scenario; but I can't give more details because of confidentiality issues.) > > There is a very pragmatic reason for having the receiver specify the fields it doesn't want. Some fields are expensive (for example, we have a probe which can look inside data streams and extract information such as URLs and response codes; it can also > compute performance metrics such as response times ... when all of these are turned on, the performance can drop significantly). > Having in-band configuration does not mean that a device needs to support anything beyond advertising the data that it will send. For example, with Kevin's CRANE proposal, the in-band configuration consists of: > - the device ("meter") advertises the records it can send > - the receiver requests restrictions on what is sent (which kinds of records, which fields in those records) > - the device can ignore the restriction request > > So, this configuration simply offers the possibility of optimization but does not force the optimization. > > This kind of configuration does not specify frequency of data delivery, aggregation, filtering, etc. Currently, we do this out of band (with a CLI, MIB, or registry file) because it does not raise the coordination issues that data formats cause. We're > thinking of a generic mechanism for doing configuration inside the transfer protocol, but that's a future issue that can easily be added to the existing protocol. > - peter > > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno > Sent: Thursday, February 14, 2002 7:24 AM > To: calato@riverstonenet.com; Benoit Claise > Cc: quittek@ccrle.nec.de; ram.gopal@nokia.com; zander@fokus.gmd.de; ipfix-req@net.doit.wisc.edu > Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt > > > > Hello, > > Last I counted we had most people saying that it's useful but we should tackle this later, except for Me, Kevin and Ram that would like to see it now. K.C said it was nice, Paul and Mike that it was for after "IPfixv1" and Benoit, Ganesh, Juergen and > Will saying no. > > So in terms of number of vendors (I agree with Benoit that the important thing is the number of vendors adopting it) it seems there is an agreement to investigate this problem at some point. We need then to choose the words that reflect this position > on the arch draft/req. Suggestions? > > Having said that I would like to clarify some points: > > One is that the idea was never to have a "common provisioning protocol". Provisioning seems a pretty heavy word. The in-band config would facilite things like template negotiation associate with flow metering capabilities and the like. So, in fact it > would help configuring vendor specific features like extended flow information, etc > > Second, the fact that "the meter will be built partially in hardware which is costly. Here we can > save a lot by reducing some functions. " is a implementation issue...Somebody else cold say that their meter would be build on software (a PC-appliance for instance) so they do not care. So trying to be fair with all possible IPfix users, I think we > should drop this specific point altogether. > > Now, as I said, I think Benoit had a good point on the adoption of such a mechanism, ie, How many vendors would implement this in-band configuration. If we can base the vendors on the people that work for them, I would say up to this point 4-5 (not > sure what percentage of companies that will really build an IPfix collector or exporter this represents). > > regards, > > Reinaldo > > >> -----Original Message----- >> From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >> Sent: Thursday, February 14, 2002 6:24 AM >> To: Benoit Claise >> Cc: quittek@ccrle.nec.de; ram.gopal@nokia.com; zander@fokus.gmd.de; >> ipfix-req@net.doit.wisc.edu >> Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to >> draft-ietf-ipfix-reqs-00.txt >> >> >> >> I vote no in-band configuration in IPFIX V1. >> >> Benoit Claise wrote: >>> >>> Hi Ram and All, >>> >>> We've discussing the in-band configuration for a few times >> without conclusions. >>> I propose to use this thread to arrive to a rough consensus >> and close the discussion one for all. Otherwise we're turning >> in circles and loosing everybody's time! >>> And if we can't get a consensus, the chairmen and area >> directors will have to take a decision. >>> >>> Note: please let's try to concentrate on just one issue: >> in-band configuration and not capability negotiation and >> transport negotiation. One step at the time please. >>> >>> > >>> > >>> > > Our charter tells us to "select a protocol by which >>> > > IP flow information can be transferred" and I would >>> > > prefer not to go beyond this. >>> > >>> > Transfer of flow information may not refer only to >> monitoring. I interpreted as >>> > one can monitor and then transfer ( exchange) flows >> between endpoints . To do this one has >>> > to configure first what we are interested in - that means >> configure, monitor and transfer >>> > flows. >>> > >>> > I am not sure and would like to get clarify my doubt, >>> > >>> > If we have in-band management what is the problem? It's is >> a good choice whether >>> > there is no flaw and it is good to control from one place >> to do both configure and manage the network >>> > elements. If we provide proper security mechanism and >> ensure that the devices gets >>> > the proper commands similar to CLI then what's the problem ? >>> >>> What is the problem, you're asking? >>> There are actually no problems. I agree it would be the >> perfect world to have in-band configuration. But here are some >> arguments against the idea. Actually I even think a little bit >> further: the exporter configuration is out of the scope of >> this charter. >>> >>> 1. Do you want the working group to spend the time (the >> money) to developp a comon provisioning protocol, IF this is >> even possible to have an agreement on that accross the >> different vendor (probes and routers), which I think is impossible. >>> >>> 2. What would happen with proprietary features, which most >> likely will not be part of the IPFIX provisioning protocol. So >> anyway we will have to use a different way of provisioning the >> device, like CLI for example, next to IPFIX. This will bypass >> the use of IPFIX provisioning protocol. >>> >>> 3. How many vendors would implement this in-band configuration? >>> Because at the end this is the final question. What's the >> point to have a IETF protocol that no/not many vendors are >> going to implement. >>> Do you think that vendors will spend time and money to >> developp again another configuration interface, next to CLI, >> SNMP, XML, etc...? And this just for an IPFIX protocol! >>> >>> 4. SNMP is widely used. Why? because the S stands for simple. >>> And now, along the time, it has been evolving because there >> are new needs. >>> I would like to start with something Simple, that everybody >> agrees on. >>> And if there is a need for in-band configuration, then we >> can think of IPFIX2. >>> Why trying to have an ISO standard from version 1? ;) >>> You can give me a long list of nice idea about in-band >> configuration that I'm sure I would love to have in a perfect >> world but let's start with something Simple. >>> Don't forget that simplicity is the key for interoperability. >>> If not yet convinced: have you already compared Snmp and CMIP? >>> >>> 5. From the charter, "select a protocol by which IP flow >> information can be transferred" as Juergen said already. I >> would not beyond this point. >>> OK, you (Ramg) have a different view. >>> >>> 6. IPFIX stands for Flow Information eXport. So we have to >> standardize the export, not the configuration. So the >> direction:exporter -> collector and not the direction >> collector -> exporter. At least for version 1. >>> >>> 7. Email from Nevil Brownlee, Subject: [ipfix] Comments on >> 'goals of IPFX WG' >>> http://ipfx.doit.wisc.edu/list/ipfix/archive/0388.html >>> 2. IPFIX is *not* trying to standardise a flow meter, >> i.e. a network >>> entity which measures flows - we already have RFCs >> which do that, >>> e.g. those for RTFM (2720 .. 2724). Existing widely-used >>> implementations can remain different, but might >> perhaps be extended >>> to report flow information in the IPFIX lingua franca. >>> >>> 3. Instead, we recognise that network equipment >> vendors already have >>> flow measurement systems implemented as part of their >> equipment. >>> Our goal is to make the IPFIX flow information export system >>> so good technically that all vendors will be happy to implement >>> it, for the benefit of all users of the data. A >> useful side-effect >>> will be that IPFIX will make it easier to build and maintain >>> interoperable flow data collecting systems. >>> >>> As we're not supposed to standardise a flow meter, why would >> we standardize its configuration? This email just expresses >> that the exporter configuration is out of the scope of the charter. >>> >>> 8. Juergen's argument: "Please consider that the meter will >> be built partially in hardware which is costly. Here we can >> save a lot by reducing some functions. >>> The data collector implemented by software can be much more flexible >>> with less cost." >>> >>> Regards, Benoit. >>> >>> > >>> > I can understand currently most of network elements >> configuration happens thro' CLI or other mechanisms.... >>> > >>> > Take for example SNMP is used only as monitoring tool and >> but people are working on to making configuration >>> > also thro' SNMP and seperate activity is going on in IETF >> community itself. >>> > >>> > >>> > Regards >>> > Ramg >>> > >>> > >>> > >>> > >>> >>> -- >>> 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/ >> >> -- >> 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/ >> > -- 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 Feb 14 18:10:09 2002 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 SAA12361 for ; Thu, 14 Feb 2002 18:10:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bUdV-0003fK-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 16:45:53 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bUdR-0003e2-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 16:45:49 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1EMjIh27006; Thu, 14 Feb 2002 14:45:18 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE90539; Thu, 14 Feb 2002 14:45:41 -0800 (PST) Message-ID: <3C6C3DFD.2BA38787@cisco.com> Date: Thu, 14 Feb 2002 14:45:17 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Sebastian Zander , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again References: <116647842.1013728929@[192.168.102.31]> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Jurgene, The picture does not appear garbled in the archives. Probably you can look at it there.See inline for my answers. Juergen Quittek wrote: > Hi Ganesh, > > --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: > > > Hi Jurgene, > > I am of the opinion that "header capturing" is a metering > > function.I see restrictions with your model. Escpecially > > if some kind of metering is done on collected flows within > > the router. It was with this in mind that I send out in one of > > my previous mails the high level picture. Did not get any > > response. So I am resending with some more modification. I am > > slightly inclined to think that the metering process within > > the observation domain could be hierarchical but have not put > > it here. > > What are your inputs? > > > Please excuse that I did not reply so far on your drawing. > I did not understand it when I saw it the first time and sent > it to the printer to study it later. Unfortunately, that's where > it still is. I should better have sent you my questions on this: > > 1. What is the difference between a meter process and a meter? Sorry that is a mistake, I meant "meter process" for both cases (within and outside the observation domain). > > 2. How and from where do meters get input? from meter processes? Since there is no separate meters and meter processes, you can think of it as meter process within the observation domain, feeding the the meter process outside the observation domain. > > 3. Is there only one exporter per observation domain? No. The exporter need not be tied to an observation domain. Example: Take the case of 2 linecards in a router., linecard 1 and linecard 2. Each of the LC forms an observation domain. The meters associated directly with observation points perform flow creation/updation based on the packets. There could be meters at a higher level (i.e per observation domain) that do furthur filtering or aggregation.However, the flows collected at the observation domain LC1& LC2 could be exported via LC2. Thus the exporter which is common to LC1 and LC2 resides in LC2. The flow export packet from each of the observation domain is identified by a unique ID. > > 4. What would be the difference between an observation domain > ID and an exporter ID? The export flow packet is identified by the observation domain ID . I am not sure we need the Exporter ID (or do we?) Thanks Ganesh > > > Cheers, > > Juergen > > > > > +---------------------------------------------------------------+ > > | Observation Domain | > > | | > > | +-------+ +-------+ Packet level| > > | |Meter1 | .... |MeterM | ({Fi}, {Si})| > > | |Process| |Process| | > > | +-------+ +-------+ | > > | ^ ^ | > > | | | | > > | +-------+-------+ +-------+--------+ | > > | | | | | | > > | v v v v | > > |+------------+ +------------+ +------------+ +------------+| > > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| > > |+------------+ +------------+ +------------+ +------------+| > > +---------------------------------------------------------------+ > > ^ ^ > > | | > > v v > > +----------+ +----------+ > > |Meter (O1)| .... |Meter (OP)| Flow Level > > +----------+ +----------+ ({Fi}, {Si}) > > | | > > +-------+--------+ > > | > > v (uniqued ID for an observation domain) > > +---------------+ > > | exporter | > > +---------------+ > > > > > > Thanks > > Ganesh > > > > Juergen Quittek wrote: > > > > Hi Sabastian, > > > > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: > > > >> Hi Juergen, > >> > >> Juergen Quittek schrieb: > >>> > >>> Hi all, > >>> > >>> We had some terminology discussion and it has not > >>> converged yet. Therfore I like to raise one issue again: > >>> > >>> For the terinology section of the requirements draft > >>> (I belive now it will be a subset of the architecture's > >>> terminology) I would like to have two identifiers for > >>> the following: > >>> > >>> 1. the function block containing all metering functions > >>> This block gets as input observed (and potentially > >>> sampled) packets from the observation point. It classifies > >>> packets maps them to flows and creates/updates the > >>> according flow record. > >>> > >>> 2. the function block sending flow records to the collector > >>> > >>> I am fine with splitting blocks more or modifying them > >>> slightly, but I prefer to have this separation, because > >>> also the requirements are split in a very similar way. > >> > >> I also would like to split those for at least 2 reasons. > >> First we create a more general model because on a router linecard > >> both are be combined but on a dedicated hardware/software based > >> meter this will probably not the case. I don't think we should limit > >> ipfix to routers only. Second the separation is nice to clarify > >> the scope. The scope of the ipfix wg is to standardize the > >> exporter (at least the interface to the outside). It's out > >> of scope to standardize the meter (although we put some req. > >> on it). > >> > >> I am not sure whether sampling is a function of the observation > >> point or the meter. > > > > Neither am I, but we should agree on one or the other soon. > > What about the following (short version of more detailed > > suggestions already discussed for the architecture)? > > > > +-------+ +-----------+ +-------+ +--------+ +--------+ > > | obs. | | header | | | | flow | | ex- | > > | point |-->| capturing |-->| meter |-->| record |-->| porter | > > +-------+ +-----------+ +-------+ +--------+ +--------+ > > > > | | > > \____________________________ _____________________________/ > > \/ > > IPFIX traffic flow measurement module > > > > If can tell me a good reason I am fine with merging header capturing > > and meter, but in general I see them as different function blocks. > > > > Juergen > > > >>> My initial naive suggestion was calling block 1. "meter" > >>> and calling block 2. "exporter". However this might (no it > >>> did already) cause confusion. Therefore, I am looking for > >>> better terms. Any suggestions? > >> > >> I have no better terms. I think what's maybe confusing is that we don't > >> have a term for the overall process (meter+exporter+observation). > >> What could be appropriate? flow monitor? > >> > >> Another possibility: Name the overall process metering and rename > >> the inner function block 1 which does classification etc. > >> > >> Sebastian > >> > >> -- > >> Sebastian Zander E-mail: zander@fokus.fhg.de > >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > >> > > > > -- > > 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/ > > -- 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 Feb 14 18:46:28 2002 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 SAA12862 for ; Thu, 14 Feb 2002 18:46:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bVJ2-0004Xn-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 17:28:48 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bVIz-0004XA-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 17:28:46 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1ENSFg41703; Fri, 15 Feb 2002 00:28:15 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id AAA03892; Fri, 15 Feb 2002 00:28:12 +0100 Date: Fri, 15 Feb 2002 00:29:57 +0100 From: Juergen Quittek To: Ganesh Sadasivan cc: Sebastian Zander , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again Message-ID: <120715491.1013732997@[192.168.102.31]> In-Reply-To: <3C6C3DFD.2BA38787@cisco.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ganesh, --On 14 February 2002 14:45 -0800 Ganesh Sadasivan wrote: > Hi Jurgene, > The picture does not appear garbled in the archives. Probably you > can look at it there.See inline for my answers. I could read the picture well (even in your reply). > > Juergen Quittek wrote: > >> Hi Ganesh, >> >> --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: >> >> > Hi Jurgene, >> > I am of the opinion that "header capturing" is a metering >> > function.I see restrictions with your model. Escpecially >> > if some kind of metering is done on collected flows within >> > the router. It was with this in mind that I send out in one of >> > my previous mails the high level picture. Did not get any >> > response. So I am resending with some more modification. I am >> > slightly inclined to think that the metering process within >> > the observation domain could be hierarchical but have not put >> > it here. >> > What are your inputs? >> > >> Please excuse that I did not reply so far on your drawing. >> I did not understand it when I saw it the first time and sent >> it to the printer to study it later. Unfortunately, that's where >> it still is. I should better have sent you my questions on this: >> >> 1. What is the difference between a meter process and a meter? > > Sorry that is a mistake, I meant "meter process" for both cases > (within and outside the observation domain). I think "meter" is a very well suited name for a box hosting a metering process! >> >> 2. How and from where do meters get input? from meter processes? > > Since there is no separate meters and meter processes, you can think of > it as meter process within the observation domain, feeding the the meter > process outside the observation domain. Meter processes can be cascaded? What is the input to a meter process? It must have the same structure than the output? Otherwise I do not see how you could cascade them. How is the total metering process shared by the packet meter processes and the flow meter processes? In other words: what are the differences between these (different?) kinds of meters inside and outside the observation domain? Juergen > >> >> 3. Is there only one exporter per observation domain? > > No. The exporter need not be tied to an observation domain. > Example: Take the case of 2 linecards in a router., linecard 1 and > linecard 2. Each of the LC forms an observation domain. The > meters associated directly with observation points perform flow > creation/updation based on the packets. There could be meters at > a higher level (i.e per observation domain) that do furthur filtering > or aggregation.However, the flows collected at the observation > domain LC1& LC2 could be > exported via LC2. Thus the exporter which is common to LC1 > and LC2 resides in LC2. The flow export packet from > each of the observation domain is identified by a unique ID. > > >> >> 4. What would be the difference between an observation domain >> ID and an exporter ID? > > The export flow packet is identified by the observation domain ID . > I am not sure we need the Exporter ID (or do we?) > > Thanks > Ganesh > >> >> >> Cheers, >> >> Juergen >> >> > >> > +---------------------------------------------------------------+ >> > | Observation Domain | >> > | | >> > | +-------+ +-------+ Packet level| >> > | |Meter1 | .... |MeterM | ({Fi}, {Si})| >> > | |Process| |Process| | >> > | +-------+ +-------+ | >> > | ^ ^ | >> > | | | | >> > | +-------+-------+ +-------+--------+ | >> > | | | | | | >> > | v v v v | >> > |+------------+ +------------+ +------------+ +------------+| >> > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| >> > |+------------+ +------------+ +------------+ +------------+| >> > +---------------------------------------------------------------+ >> > ^ ^ >> > | | >> > v v >> > +----------+ +----------+ >> > |Meter (O1)| .... |Meter (OP)| Flow Level >> > +----------+ +----------+ ({Fi}, {Si}) >> > | | >> > +-------+--------+ >> > | >> > v (uniqued ID for an observation domain) >> > +---------------+ >> > | exporter | >> > +---------------+ >> > >> > >> > Thanks >> > Ganesh >> > >> > Juergen Quittek wrote: >> > >> > Hi Sabastian, >> > >> > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: >> > >> >> Hi Juergen, >> >> >> >> Juergen Quittek schrieb: >> >>> >> >>> Hi all, >> >>> >> >>> We had some terminology discussion and it has not >> >>> converged yet. Therfore I like to raise one issue again: >> >>> >> >>> For the terinology section of the requirements draft >> >>> (I belive now it will be a subset of the architecture's >> >>> terminology) I would like to have two identifiers for >> >>> the following: >> >>> >> >>> 1. the function block containing all metering functions >> >>> This block gets as input observed (and potentially >> >>> sampled) packets from the observation point. It classifies >> >>> packets maps them to flows and creates/updates the >> >>> according flow record. >> >>> >> >>> 2. the function block sending flow records to the collector >> >>> >> >>> I am fine with splitting blocks more or modifying them >> >>> slightly, but I prefer to have this separation, because >> >>> also the requirements are split in a very similar way. >> >> >> >> I also would like to split those for at least 2 reasons. >> >> First we create a more general model because on a router linecard >> >> both are be combined but on a dedicated hardware/software based >> >> meter this will probably not the case. I don't think we should limit >> >> ipfix to routers only. Second the separation is nice to clarify >> >> the scope. The scope of the ipfix wg is to standardize the >> >> exporter (at least the interface to the outside). It's out >> >> of scope to standardize the meter (although we put some req. >> >> on it). >> >> >> >> I am not sure whether sampling is a function of the observation >> >> point or the meter. >> > >> > Neither am I, but we should agree on one or the other soon. >> > What about the following (short version of more detailed >> > suggestions already discussed for the architecture)? >> > >> > +-------+ +-----------+ +-------+ +--------+ +--------+ >> > | obs. | | header | | | | flow | | ex- | >> > | point |-->| capturing |-->| meter |-->| record |-->| porter | >> > +-------+ +-----------+ +-------+ +--------+ +--------+ >> > >> > | | >> > \____________________________ _____________________________/ >> > \/ >> > IPFIX traffic flow measurement module >> > >> > If can tell me a good reason I am fine with merging header capturing >> > and meter, but in general I see them as different function blocks. >> > >> > Juergen >> > >> >>> My initial naive suggestion was calling block 1. "meter" >> >>> and calling block 2. "exporter". However this might (no it >> >>> did already) cause confusion. Therefore, I am looking for >> >>> better terms. Any suggestions? >> >> >> >> I have no better terms. I think what's maybe confusing is that we don't >> >> have a term for the overall process (meter+exporter+observation). >> >> What could be appropriate? flow monitor? >> >> >> >> Another possibility: Name the overall process metering and rename >> >> the inner function block 1 which does classification etc. >> >> >> >> Sebastian >> >> >> >> -- >> >> Sebastian Zander E-mail: zander@fokus.fhg.de >> >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 >> >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >> >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander >> >> >> > >> > -- >> > 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/ >> > > -- 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 Feb 14 19:24:13 2002 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 TAA13420 for ; Thu, 14 Feb 2002 19:24:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bVu7-0005Kj-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 18:07:07 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bVu4-0005JZ-00 for ipfix-req@net.doit.wisc.edu; Thu, 14 Feb 2002 18:07:04 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1F06Xh01117; Thu, 14 Feb 2002 16:06:33 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE93746; Thu, 14 Feb 2002 16:06:56 -0800 (PST) Message-ID: <3C6C5108.B46B4308@cisco.com> Date: Thu, 14 Feb 2002 16:06:32 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Sebastian Zander , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again References: <120715491.1013732997@[192.168.102.31]> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > Hi Ganesh, > > --On 14 February 2002 14:45 -0800 Ganesh Sadasivan wrote: > > > Hi Jurgene, > > The picture does not appear garbled in the archives. Probably you > > can look at it there.See inline for my answers. > > I could read the picture well (even in your reply). > > > > > Juergen Quittek wrote: > > > >> Hi Ganesh, > >> > >> --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: > >> > >> > Hi Jurgene, > >> > I am of the opinion that "header capturing" is a metering > >> > function.I see restrictions with your model. Escpecially > >> > if some kind of metering is done on collected flows within > >> > the router. It was with this in mind that I send out in one of > >> > my previous mails the high level picture. Did not get any > >> > response. So I am resending with some more modification. I am > >> > slightly inclined to think that the metering process within > >> > the observation domain could be hierarchical but have not put > >> > it here. > >> > What are your inputs? > >> > > >> Please excuse that I did not reply so far on your drawing. > >> I did not understand it when I saw it the first time and sent > >> it to the printer to study it later. Unfortunately, that's where > >> it still is. I should better have sent you my questions on this: > >> > >> 1. What is the difference between a meter process and a meter? > > > > Sorry that is a mistake, I meant "meter process" for both cases > > (within and outside the observation domain). > > I think "meter" is a very well suited name for a box > hosting a metering process! Ok. > > > >> > >> 2. How and from where do meters get input? from meter processes? > > > > Since there is no separate meters and meter processes, you can think of > > it as meter process within the observation domain, feeding the the meter > > process outside the observation domain. > > Meter processes can be cascaded? yes. > > What is the input to a meter process? The input to the meter at the lowest level is packets. Flows are cretaed as a result of the lowest level meter process. At subsequent level,the input to meter would be flows. As I mentioned before the first level meter is a must but not the subsequent ones. > > It must have the same structure than the output? > Otherwise I do not see how you could cascade them. What does this mean? > > > How is the total metering process shared by the packet meter > processes and the flow meter processes? They are independent entities. > > In other words: what are the differences between these > (different?) kinds of meters inside and outside the observation > domain? The one outside observation domain operates on a bigger scope. For example: Say there are 2 lowest level meters: M11 extracts the 5 tuple IPV4 flows from interface1 at a sampling rate of 1 in 10. M12 extracts the 5 tuple IPV4 flows from interface2 at a sampling rate of 1 in 20. A meter at the level of observation domain sees the flows created by M11 and M12 and does one more level of sampling of all the flows created by both meters at a rate of 1 in 2 before exporting it. Ganesh > > > Juergen > > > > >> > >> 3. Is there only one exporter per observation domain? > > > > No. The exporter need not be tied to an observation domain. > > Example: Take the case of 2 linecards in a router., linecard 1 and > > linecard 2. Each of the LC forms an observation domain. The > > meters associated directly with observation points perform flow > > creation/updation based on the packets. There could be meters at > > a higher level (i.e per observation domain) that do furthur filtering > > or aggregation.However, the flows collected at the observation > > domain LC1& LC2 could be > > exported via LC2. Thus the exporter which is common to LC1 > > and LC2 resides in LC2. The flow export packet from > > each of the observation domain is identified by a unique ID. > > > > > >> > >> 4. What would be the difference between an observation domain > >> ID and an exporter ID? > > > > The export flow packet is identified by the observation domain ID . > > I am not sure we need the Exporter ID (or do we?) > > > > Thanks > > Ganesh > > > >> > >> > >> Cheers, > >> > >> Juergen > >> > >> > > >> > +---------------------------------------------------------------+ > >> > | Observation Domain | > >> > | | > >> > | +-------+ +-------+ Packet level| > >> > | |Meter1 | .... |MeterM | ({Fi}, {Si})| > >> > | |Process| |Process| | > >> > | +-------+ +-------+ | > >> > | ^ ^ | > >> > | | | | > >> > | +-------+-------+ +-------+--------+ | > >> > | | | | | | > >> > | v v v v | > >> > |+------------+ +------------+ +------------+ +------------+| > >> > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| > >> > |+------------+ +------------+ +------------+ +------------+| > >> > +---------------------------------------------------------------+ > >> > ^ ^ > >> > | | > >> > v v > >> > +----------+ +----------+ > >> > |Meter (O1)| .... |Meter (OP)| Flow Level > >> > +----------+ +----------+ ({Fi}, {Si}) > >> > | | > >> > +-------+--------+ > >> > | > >> > v (uniqued ID for an observation domain) > >> > +---------------+ > >> > | exporter | > >> > +---------------+ > >> > > >> > > >> > Thanks > >> > Ganesh > >> > > >> > Juergen Quittek wrote: > >> > > >> > Hi Sabastian, > >> > > >> > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: > >> > > >> >> Hi Juergen, > >> >> > >> >> Juergen Quittek schrieb: > >> >>> > >> >>> Hi all, > >> >>> > >> >>> We had some terminology discussion and it has not > >> >>> converged yet. Therfore I like to raise one issue again: > >> >>> > >> >>> For the terinology section of the requirements draft > >> >>> (I belive now it will be a subset of the architecture's > >> >>> terminology) I would like to have two identifiers for > >> >>> the following: > >> >>> > >> >>> 1. the function block containing all metering functions > >> >>> This block gets as input observed (and potentially > >> >>> sampled) packets from the observation point. It classifies > >> >>> packets maps them to flows and creates/updates the > >> >>> according flow record. > >> >>> > >> >>> 2. the function block sending flow records to the collector > >> >>> > >> >>> I am fine with splitting blocks more or modifying them > >> >>> slightly, but I prefer to have this separation, because > >> >>> also the requirements are split in a very similar way. > >> >> > >> >> I also would like to split those for at least 2 reasons. > >> >> First we create a more general model because on a router linecard > >> >> both are be combined but on a dedicated hardware/software based > >> >> meter this will probably not the case. I don't think we should limit > >> >> ipfix to routers only. Second the separation is nice to clarify > >> >> the scope. The scope of the ipfix wg is to standardize the > >> >> exporter (at least the interface to the outside). It's out > >> >> of scope to standardize the meter (although we put some req. > >> >> on it). > >> >> > >> >> I am not sure whether sampling is a function of the observation > >> >> point or the meter. > >> > > >> > Neither am I, but we should agree on one or the other soon. > >> > What about the following (short version of more detailed > >> > suggestions already discussed for the architecture)? > >> > > >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > >> > | obs. | | header | | | | flow | | ex- | > >> > | point |-->| capturing |-->| meter |-->| record |-->| porter | > >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > >> > > >> > | | > >> > \____________________________ _____________________________/ > >> > \/ > >> > IPFIX traffic flow measurement module > >> > > >> > If can tell me a good reason I am fine with merging header capturing > >> > and meter, but in general I see them as different function blocks. > >> > > >> > Juergen > >> > > >> >>> My initial naive suggestion was calling block 1. "meter" > >> >>> and calling block 2. "exporter". However this might (no it > >> >>> did already) cause confusion. Therefore, I am looking for > >> >>> better terms. Any suggestions? > >> >> > >> >> I have no better terms. I think what's maybe confusing is that we don't > >> >> have a term for the overall process (meter+exporter+observation). > >> >> What could be appropriate? flow monitor? > >> >> > >> >> Another possibility: Name the overall process metering and rename > >> >> the inner function block 1 which does classification etc. > >> >> > >> >> Sebastian > >> >> > >> >> -- > >> >> Sebastian Zander E-mail: zander@fokus.fhg.de > >> >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > >> >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > >> >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > >> >> > >> > > >> > -- > >> > 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/ > >> > > > -- 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 Feb 14 21:36:26 2002 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 VAA15982 for ; Thu, 14 Feb 2002 21:36:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bXqS-00000k-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 20:11:28 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bXqP-0007no-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 20:11:25 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1F29uV25662; Thu, 14 Feb 2002 20:09:57 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFYVJ0>; Thu, 14 Feb 2002 18:09:54 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A73B89@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: will@cisco.com, Juergen Quittek , Nevil Brownlee , ipfix@net.doit.wisc.edu Cc: bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu Subject: RE: [ipfix] WG process: a proposal Date: Thu, 14 Feb 2002 18:09:51 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B5C5.DA5087A0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B5C5.DA5087A0 Content-Type: text/plain; charset="iso-8859-1" Will, what you are proposing is not consensus. Nevil asked for comments on his *proposal*. This is a proposal, he didn't asked/mandated us to agree with him. This is the IETF, rough consensus... Reinaldo >-----Original Message----- >From: Will Eatherton [mailto:will@cisco.com] >Sent: Thursday, February 14, 2002 10:47 AM >To: Juergen Quittek; Nevil Brownlee; ipfix@net.doit.wisc.edu >Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; >plonka@doit.wisc.edu >Subject: RE: [ipfix] WG process: a proposal > > >Juergen, > >Proposal was 2 from each exisiting draft (from first draft I assume >Ganesh/Benoit). So that is 6 volunteers for 2 slots. Since I have not >volunteered I will feel comfortable pushing that I believe it >should be kept >to 4 total since otherwise I expect the group to have as much trouble >reaching consensus as we have seen occur on the the list thus far. > >The rest of us will defintely continue to provide input in the form of >reviews, but a cohesive document is going to require a small team with >somewhat similar starting views on what the scope of this document is. > >Will > >> -----Original Message----- >> From: majordomo listserver >[mailto:majordomo@mil.doit.wisc.edu]On Behalf >> Of Juergen Quittek >> Sent: Thursday, February 14, 2002 10:39 AM >> To: Nevil Brownlee; ipfix@net.doit.wisc.edu >> Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; >> plonka@doit.wisc.edu >> Subject: Re: [ipfix] WG process: a proposal >> >> >> Nevil and Dave, >> >> You suggested a editor team of 4, but now we have 6 >> volunteers: Paul, KC, Reinaldo, Ram, Kevin and me. >> >> I am sure that all of us are well motivated and capable >> of doing a good job. Therefore, selecting just 4 might >> disappoint one or the other. >> >> Therefore I suggest taking all 6 instead of 4 >> and dividing us into two groups of 3, >> one for each document. >> >> However you decide, please decide soon, because we just >> have one week left and there is still a lot of work ahead. >> We need to arrange phone conferences, distribute the work >> and come up with the documents until next Friday. >> >> Cheers, >> >> Juergen >> >> >> --On 14 February 2002 11:23 +1300 Nevil Brownlee >> wrote: >> >> > >> > Hello all: >> > >> > Various people have been asking for some direction from >the WG chairs >> > as to where we're heading with the two current documents. >After some >> > discussion between Dave and myself, I'd like to suggest >the following: >> > >> > A: Background >> > >> > 1) At the Salt Lake City IETF we called for volunteers to work on >> > the two IPFIX documents, as set out in the WG charter. About >> > 20 people volunteered. >> > >> > 2) After an initial flurry of discussion on the IPFIX list, things >> > went quiet. We set up some extra sub-lists to help the design >> > team members get some initial discussions going. >> > >> > 3) KC Norseth stepped forward and posted some skeleton documents. >> > These were simply lists of section headings based on the >> > 'IPFIX requirements' document. >> > >> > 4) KC also proposed a design teleconference. That idea was >> > welcomed, and the conference was scheduled for 31 January. >> > >> > 5) At that point a group from Cisco, led by Benoit and Ganesh, >> > came forward with a much more complete document, which they >> > published as an individual Internet draft, so everyone could >> > read it and comment. This was a very considerable contribution >> > to the WG. >> > >> > 6) The teleconference was held, with many people participating. >> > Minutes were posted on the list. Since then there has been >> > a *lot* of discussion on the list and sublists. Many people >> > (including those from Cisco) have contributed text, which KC >> > has edited together to form a second document. This will >> > shortly be published as a second individual draft. >> > >> > 7) We now have two documents, each with lots of worthwhile material >> > in them. I suspect there is a feeling that these are, somehow, >> > competing proposals - this is not the case. Both are serious >> > contributions to the WG effort. >> > >> > B: What next? >> > >> > From the WG co-chairs point of view, any documents being >produced as >> > WG drafts need to be the result of open discussion in the >WG, i.e. on >> > its mailing list. The co-chairs' role is to facilitate discussion, >> > and to guide it towards actually delivering documents as >per the WG's >> > charter goals. Decisions about the technical merit of >text in various >> > sections of the document needs to be decided by consensus >on the list. >> > >> > Ideally, we'd like to get to the next IETF meeting (Minneapolis in >> > March) with a single document to review / discuss / amend. So how >> > can we achieve that? >> > >> > I propose that >> > >> > 1) We form a small 'editorial' team, with two people from those >> > working on each of the two current documents (4 altogether). >> > >> > 2) We ask the editorial team to merge the documents together, >> > and publish the resulting document(s) as IPFX WG drafts. >> > >> > 3) The members of the design team - i.e. all those who've >contributed >> > text to the drafts - will be listed in the 'Acknowledgements' >> > section of all drafts produced. The editors of each document >> > will appear as the document authors. >> > >> > 4) Watching the mailing list discussion, this is starting to >> > happen as a natural development anyway. Agreeing to proceed >> > in this way would simply introduce a little formality to it, >> > and make the process clear to everyone. >> > >> > One other comment. This WG has certainly generated plenty >of interesting >> > discussion on its mailing list. It's clear that all those involved >> > are putting a lot of effort into our goal of producing the best >> > technical solutions. Thanks all round. >> > >> > I'd like comments / feedback on this notion from all >concerned, please. >> > In particular, if we can agree to proceed in this way, we need to >> > decide who's on the editorial team ... >> > >> > Cheers, Nevil >> > >> > >+---------------------------------------------------------------------+ >> > | Nevil Brownlee Director, Technology >Development | >> > | Phone: +64 9 373 7599 x8941 ITSS, The University >of Auckland | >> > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, >New Zealand | >> > >+---------------------------------------------------------------------P >> > >> > >> > -- >> > 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/ >> > >> >> >> >> -- >> 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/ > > >-- >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/ > ------_=_NextPart_001_01C1B5C5.DA5087A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] WG process: a proposal

Will,

what you are proposing is not consensus. Nevil asked = for comments on his *proposal*. This is a proposal, he didn't = asked/mandated us to agree with him. This is the IETF, rough = consensus...

Reinaldo

>-----Original Message-----
>From: Will Eatherton [mailto:will@cisco.com]
>Sent: Thursday, February 14, 2002 10:47 = AM
>To: Juergen Quittek; Nevil Brownlee; = ipfix@net.doit.wisc.edu
>Cc: bclaise@cisco.com; gsadasiv@cisco.com; = kcn@norseth.com;
>plonka@doit.wisc.edu
>Subject: RE: [ipfix] WG process: a = proposal
>
>
>Juergen,
>
>Proposal was 2 from each exisiting draft (from = first draft I assume
>Ganesh/Benoit).  So that is 6 volunteers = for 2 slots.  Since I have not
>volunteered I will feel comfortable pushing that = I believe it
>should be kept
>to 4 total since otherwise I expect the group to = have as much trouble
>reaching consensus as we have seen occur on the = the list thus far.
>
>The rest of us will defintely continue to = provide input in the form of
>reviews, but a cohesive document is going to = require a small team with
>somewhat similar starting views on what the = scope of this document is.
>
>Will
>
>> -----Original Message-----
>> From: majordomo listserver
>[mailto:majordomo@mil.doit.wi= sc.edu]On Behalf
>> Of Juergen Quittek
>> Sent: Thursday, February 14, 2002 10:39 = AM
>> To: Nevil Brownlee; = ipfix@net.doit.wisc.edu
>> Cc: bclaise@cisco.com; gsadasiv@cisco.com; = kcn@norseth.com;
>> plonka@doit.wisc.edu
>> Subject: Re: [ipfix] WG process: a = proposal
>>
>>
>> Nevil and Dave,
>>
>> You suggested a editor team of 4, but now = we have 6
>> volunteers: Paul, KC, Reinaldo, Ram, Kevin = and me.
>>
>> I am sure that all of us are well motivated = and capable
>> of doing a good job. Therefore, selecting = just 4 might
>> disappoint one or the other.
>>
>> Therefore I suggest taking all 6 instead of = 4
>> and dividing us into two groups of = 3,
>> one for each document.
>>
>> However you decide, please decide soon, = because we just
>> have one week left and there is still a lot = of work ahead.
>> We need to arrange phone conferences, = distribute the work
>> and come up with the documents until next = Friday.
>>
>> Cheers,
>>
>>     Juergen
>>
>>
>> --On 14 February 2002 11:23 +1300 Nevil = Brownlee
>> <n.brownlee@auckland.ac.nz> = wrote:
>>
>> >
>> > Hello all:
>> >
>> > Various people have been asking for = some direction from
>the WG chairs
>> > as to where we're heading with the two = current documents. 
>After some
>> > discussion between Dave and myself, = I'd like to suggest
>the following:
>> >
>> > A: Background
>> >
>> > 1) At the Salt Lake City IETF we = called for volunteers to work on
>> >    the two IPFIX = documents, as set out in the WG charter.  About
>> >    20 people = volunteered.
>> >
>> > 2) After an initial flurry of = discussion on the IPFIX list, things
>> >    went quiet.  We = set up some extra sub-lists to help the design
>> >    team members get = some initial discussions going.
>> >
>> > 3) KC Norseth stepped forward and = posted some skeleton documents.
>> >    These were simply = lists of section headings based on the
>> >    'IPFIX requirements' = document.
>> >
>> > 4) KC also proposed a design = teleconference.  That idea was
>> >    welcomed, and the = conference was scheduled for 31 January.
>> >
>> > 5) At that point a group from Cisco, = led by Benoit and Ganesh,
>> >    came forward with a = much more complete document, which they
>> >    published as an = individual Internet draft, so everyone could
>> >    read it and = comment.  This was a very considerable contribution
>> >    to the WG.
>> >
>> > 6) The teleconference was held, with = many people participating.
>> >    Minutes were posted = on the list.  Since then there has been
>> >    a *lot* of = discussion on the list and sublists.  Many people
>> >    (including those = from Cisco) have contributed text, which KC
>> >    has edited together = to form a second document.  This will
>> >    shortly be published = as a second individual draft.
>> >
>> > 7) We now have two documents, each = with lots of worthwhile material
>> >    in them.  I = suspect there is a feeling that these are, somehow,
>> >    competing proposals = - this is not the case.  Both are serious
>> >    contributions to the = WG effort.
>> >
>> > B: What next?
>> >
>> > From the WG co-chairs point of view, = any documents being
>produced as
>> > WG drafts need to be the result of = open discussion in the
>WG, i.e. on
>> > its mailing list.  The co-chairs' = role is to facilitate discussion,
>> > and to guide it towards actually = delivering documents as
>per the WG's
>> > charter goals.  Decisions about = the technical merit of
>text in various
>> > sections of the document needs to be = decided by consensus
>on the list.
>> >
>> > Ideally, we'd like to get to the next = IETF meeting (Minneapolis in
>> > March) with a single document to = review / discuss / amend.  So how
>> > can we achieve that?
>> >
>> > I propose that
>> >
>> > 1) We form a small 'editorial' team, = with two people from those
>> >    working on each of = the two current documents (4 altogether).
>> >
>> > 2) We ask the editorial team to merge = the documents together,
>> >    and publish the = resulting document(s) as IPFX WG drafts.
>> >
>> > 3) The members of the design team - = i.e. all those who've
>contributed
>> >    text to the drafts - = will be listed in the 'Acknowledgements'
>> >    section of all = drafts produced. The editors of each document
>> >    will appear as the = document authors.
>> >
>> > 4) Watching the mailing list = discussion, this is starting to
>> >    happen as a natural = development anyway.  Agreeing to proceed
>> >    in this way would = simply introduce a little formality to it,
>> >    and make the process = clear to everyone.
>> >
>> > One other comment. This WG has = certainly generated plenty
>of interesting
>> > discussion on its mailing list.  = It's clear that all those involved
>> > are putting a lot of effort into our = goal of producing the best
>> > technical solutions.  Thanks all = round.
>> >
>> > I'd like comments / feedback on this = notion from all
>concerned, please.
>> > In particular, if we can agree to = proceed in this way, we need to
>> > decide who's on the editorial team = ...
>> >
>> > Cheers, Nevil
>> >
>> >
>+----------------------------------------------------------= -----------+
>> > | Nevil = Brownlee          &nbs= p;          Director, = Technology
>Development |
>> > | Phone: +64 9 373 7599 = x8941        ITSS, The University =
>of Auckland |
>> > |   FAX: +64 9 373 = 7021      Private Bag 92019, Auckland,
>New Zealand |
>> >
>+----------------------------------------------------------= -----------P
>> >
>> >
>> > --
>> > = Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
>> in message body
>> > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>> > "unsubscribe ipfix" in = message body
>> > Archive     http://ipfix.doit.wisc.edu/archive/
>> >
>>
>>
>>
>> --
>> = Help        mailto:majordomo@net.doit.wi= sc.edu and say "help" in
>> message body
>> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>> "unsubscribe ipfix" in message = body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B5C5.DA5087A0-- -- 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 Feb 14 21:49:22 2002 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 VAA16142 for ; Thu, 14 Feb 2002 21:49:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bY7f-0000ML-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 20:29:15 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bY7d-0000Lw-00 for ipfix@net.doit.wisc.edu; Thu, 14 Feb 2002 20:29:13 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1F2S1V26242; Thu, 14 Feb 2002 20:28:02 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFYVNW>; Thu, 14 Feb 2002 18:27:59 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A73B9C@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Juergen Quittek , Nevil Brownlee , ipfix@net.doit.wisc.edu Cc: bclaise@cisco.com, gsadasiv@cisco.com, kcn@norseth.com, plonka@doit.wisc.edu Subject: RE: [ipfix] WG process: a proposal Date: Thu, 14 Feb 2002 18:27:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B5C8.61B6C860" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B5C8.61B6C860 Content-Type: text/plain; charset="iso-8859-1" I second this proposal. I also think there should be no esoteric number of editors we need to follow. So 6 people volunteered and btw they also contributed and put a lot of effort on both of these drafts. This would be fair because would balance people from several companies with different visions that gave considerable contributions. regards, Reinaldo >-----Original Message----- >From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >Sent: Thursday, February 14, 2002 10:39 AM >To: Nevil Brownlee; ipfix@net.doit.wisc.edu >Cc: bclaise@cisco.com; gsadasiv@cisco.com; kcn@norseth.com; >plonka@doit.wisc.edu >Subject: Re: [ipfix] WG process: a proposal > > >Nevil and Dave, > >You suggested a editor team of 4, but now we have 6 >volunteers: Paul, KC, Reinaldo, Ram, Kevin and me. > >I am sure that all of us are well motivated and capable >of doing a good job. Therefore, selecting just 4 might >disappoint one or the other. > >Therefore I suggest taking all 6 instead of 4 >and dividing us into two groups of 3, >one for each document. > >However you decide, please decide soon, because we just >have one week left and there is still a lot of work ahead. >We need to arrange phone conferences, distribute the work >and come up with the documents until next Friday. > >Cheers, > > Juergen > > >--On 14 February 2002 11:23 +1300 Nevil Brownlee > wrote: > >> >> Hello all: >> >> Various people have been asking for some direction from the WG chairs >> as to where we're heading with the two current documents. After some >> discussion between Dave and myself, I'd like to suggest the >following: >> >> A: Background >> >> 1) At the Salt Lake City IETF we called for volunteers to work on >> the two IPFIX documents, as set out in the WG charter. About >> 20 people volunteered. >> >> 2) After an initial flurry of discussion on the IPFIX list, things >> went quiet. We set up some extra sub-lists to help the design >> team members get some initial discussions going. >> >> 3) KC Norseth stepped forward and posted some skeleton documents. >> These were simply lists of section headings based on the >> 'IPFIX requirements' document. >> >> 4) KC also proposed a design teleconference. That idea was >> welcomed, and the conference was scheduled for 31 January. >> >> 5) At that point a group from Cisco, led by Benoit and Ganesh, >> came forward with a much more complete document, which they >> published as an individual Internet draft, so everyone could >> read it and comment. This was a very considerable contribution >> to the WG. >> >> 6) The teleconference was held, with many people participating. >> Minutes were posted on the list. Since then there has been >> a *lot* of discussion on the list and sublists. Many people >> (including those from Cisco) have contributed text, which KC >> has edited together to form a second document. This will >> shortly be published as a second individual draft. >> >> 7) We now have two documents, each with lots of worthwhile material >> in them. I suspect there is a feeling that these are, somehow, >> competing proposals - this is not the case. Both are serious >> contributions to the WG effort. >> >> B: What next? >> >> From the WG co-chairs point of view, any documents being produced as >> WG drafts need to be the result of open discussion in the WG, i.e. on >> its mailing list. The co-chairs' role is to facilitate discussion, >> and to guide it towards actually delivering documents as per the WG's >> charter goals. Decisions about the technical merit of text >in various >> sections of the document needs to be decided by consensus on >the list. >> >> Ideally, we'd like to get to the next IETF meeting (Minneapolis in >> March) with a single document to review / discuss / amend. So how >> can we achieve that? >> >> I propose that >> >> 1) We form a small 'editorial' team, with two people from those >> working on each of the two current documents (4 altogether). >> >> 2) We ask the editorial team to merge the documents together, >> and publish the resulting document(s) as IPFX WG drafts. >> >> 3) The members of the design team - i.e. all those who've contributed >> text to the drafts - will be listed in the 'Acknowledgements' >> section of all drafts produced. The editors of each document >> will appear as the document authors. >> >> 4) Watching the mailing list discussion, this is starting to >> happen as a natural development anyway. Agreeing to proceed >> in this way would simply introduce a little formality to it, >> and make the process clear to everyone. >> >> One other comment. This WG has certainly generated plenty of >interesting >> discussion on its mailing list. It's clear that all those involved >> are putting a lot of effort into our goal of producing the best >> technical solutions. Thanks all round. >> >> I'd like comments / feedback on this notion from all >concerned, please. >> In particular, if we can agree to proceed in this way, we need to >> decide who's on the editorial team ... >> >> Cheers, Nevil >> >> >+---------------------------------------------------------------------+ >> | Nevil Brownlee Director, Technology >Development | >> | Phone: +64 9 373 7599 x8941 ITSS, The University of >Auckland | >> | FAX: +64 9 373 7021 Private Bag 92019, Auckland, >New Zealand | >> >+---------------------------------------------------------------------P >> >> >> -- >> 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/ >> > > > >-- >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/ > ------_=_NextPart_001_01C1B5C8.61B6C860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] WG process: a proposal

I second this proposal. I also think there should be = no esoteric number of editors we need to follow. So 6 people = volunteered and btw they also contributed and put a lot of effort on = both of these drafts.

This would be fair because would balance people from = several companies with different visions that gave considerable = contributions.

regards,

Reinaldo


>-----Original Message-----
>From: Juergen Quittek [mailto:quittek@ccrle.nec.de]
>Sent: Thursday, February 14, 2002 10:39 = AM
>To: Nevil Brownlee; = ipfix@net.doit.wisc.edu
>Cc: bclaise@cisco.com; gsadasiv@cisco.com; = kcn@norseth.com;
>plonka@doit.wisc.edu
>Subject: Re: [ipfix] WG process: a = proposal
>
>
>Nevil and Dave,
>
>You suggested a editor team of 4, but now we = have 6
>volunteers: Paul, KC, Reinaldo, Ram, Kevin and = me.
>
>I am sure that all of us are well motivated and = capable
>of doing a good job. Therefore, selecting just 4 = might
>disappoint one or the other.
>
>Therefore I suggest taking all 6 instead of = 4
>and dividing us into two groups of 3,
>one for each document.
>
>However you decide, please decide soon, because = we just
>have one week left and there is still a lot of = work ahead.
>We need to arrange phone conferences, distribute = the work
>and come up with the documents until next = Friday.
>
>Cheers,
>
>    Juergen
>
>
>--On 14 February 2002 11:23 +1300 Nevil Brownlee =
><n.brownlee@auckland.ac.nz> wrote:
>
>>
>> Hello all:
>>
>> Various people have been asking for some = direction from the WG chairs
>> as to where we're heading with the two = current documents.  After some
>> discussion between Dave and myself, I'd = like to suggest the
>following:
>>
>> A: Background
>>
>> 1) At the Salt Lake City IETF we called for = volunteers to work on
>>    the two IPFIX documents, = as set out in the WG charter.  About
>>    20 people = volunteered.
>>
>> 2) After an initial flurry of discussion on = the IPFIX list, things
>>    went quiet.  We set = up some extra sub-lists to help the design
>>    team members get some = initial discussions going.
>>
>> 3) KC Norseth stepped forward and posted = some skeleton documents.
>>    These were simply lists = of section headings based on the
>>    'IPFIX requirements' = document.
>>
>> 4) KC also proposed a design = teleconference.  That idea was
>>    welcomed, and the = conference was scheduled for 31 January.
>>
>> 5) At that point a group from Cisco, led by = Benoit and Ganesh,
>>    came forward with a much = more complete document, which they
>>    published as an = individual Internet draft, so everyone could
>>    read it and = comment.  This was a very considerable contribution
>>    to the WG.
>>
>> 6) The teleconference was held, with many = people participating.
>>    Minutes were posted on = the list.  Since then there has been
>>    a *lot* of discussion on = the list and sublists.  Many people
>>    (including those from = Cisco) have contributed text, which KC
>>    has edited together to = form a second document.  This will
>>    shortly be published as a = second individual draft.
>>
>> 7) We now have two documents, each with = lots of worthwhile material
>>    in them.  I suspect = there is a feeling that these are, somehow,
>>    competing proposals - = this is not the case.  Both are serious
>>    contributions to the WG = effort.
>>
>> B: What next?
>>
>> From the WG co-chairs point of view, any = documents being produced as
>> WG drafts need to be the result of open = discussion in the WG, i.e. on
>> its mailing list.  The co-chairs' role = is to facilitate discussion,
>> and to guide it towards actually delivering = documents as per the WG's
>> charter goals.  Decisions about the = technical merit of text
>in various
>> sections of the document needs to be = decided by consensus on
>the list.
>>
>> Ideally, we'd like to get to the next IETF = meeting (Minneapolis in
>> March) with a single document to review / = discuss / amend.  So how
>> can we achieve that?
>>
>> I propose that
>>
>> 1) We form a small 'editorial' team, with = two people from those
>>    working on each of the = two current documents (4 altogether).
>>
>> 2) We ask the editorial team to merge the = documents together,
>>    and publish the resulting = document(s) as IPFX WG drafts.
>>
>> 3) The members of the design team - i.e. = all those who've contributed
>>    text to the drafts - will = be listed in the 'Acknowledgements'
>>    section of all drafts = produced. The editors of each document
>>    will appear as the = document authors.
>>
>> 4) Watching the mailing list discussion, = this is starting to
>>    happen as a natural = development anyway.  Agreeing to proceed
>>    in this way would simply = introduce a little formality to it,
>>    and make the process = clear to everyone.
>>
>> One other comment. This WG has certainly = generated plenty of
>interesting
>> discussion on its mailing list.  It's = clear that all those involved
>> are putting a lot of effort into our goal = of producing the best
>> technical solutions.  Thanks all = round.
>>
>> I'd like comments / feedback on this notion = from all
>concerned, please.
>> In particular, if we can agree to proceed = in this way, we need to
>> decide who's on the editorial team = ...
>>
>> Cheers, Nevil
>>
>>
>+----------------------------------------------------------= -----------+
>> | Nevil = Brownlee          &nbs= p;          Director, = Technology
>Development |
>> | Phone: +64 9 373 7599 = x8941        ITSS, The University of =
>Auckland |
>> |   FAX: +64 9 373 = 7021      Private Bag 92019, Auckland,
>New Zealand |
>>
>+----------------------------------------------------------= -----------P
>>
>>
>> --
>> = Help        mailto:majordomo@net.doit.wi= sc.edu and say
>"help" in message body
>> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>> "unsubscribe ipfix" in message = body
>> Archive     http://ipfix.doit.wisc.edu/archive/
>>
>
>
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B5C8.61B6C860-- -- 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 Feb 14 22:51:19 2002 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 WAA18003 for ; Thu, 14 Feb 2002 22:51:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bZ3X-0001SZ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 14 Feb 2002 21:29:03 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bZ3U-0001S1-00 for ipfix-data@net.doit.wisc.edu; Thu, 14 Feb 2002 21:29:00 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1F3STt23977 for ; Thu, 14 Feb 2002 19:28:29 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABE99359; Thu, 14 Feb 2002 19:28:52 -0800 (PST) Message-ID: <3C6C805C.5600E9F5@cisco.com> Date: Thu, 14 Feb 2002 19:28:28 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfix-data@net.doit.wisc.edu Subject: [ipfix-data] draft-ietf-ipfix-data-00.txt - comments Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, Here are my first pass comments, questions and suggestions on draft-ietf-ipfix-data-00.txt. Thanks Ganesh What is the idea behind putting Section 4.1-4.4? Is this a rough list or a complete list? Is this section supposed to cover all the fields in section 5? 5.1.1. Version Number Which version # is this refering to - IPV4/V6? 5.1.2. FLOWS This is # of flows which got aggergated at a second level meter. 5.2.1. Source Address IE 5.2.2. Destination Address IE 5.2.3. NEXT_HOP_IP IE Are we not distinguishing between V4 and V6 addresses by different IEs? To me separate IE is better than infering through version# . 5.3.3. Delta Time IE Just curious. How does this field get used? 5.3.4. LAST_SWITCHED SysUptime at which the last packet of this flow was processed by the meter before the flow record was exported or the flow ended. 5.3.5. FIRST_SWITCHED SysUptime at which the first packet of this flow was processed by the meter. 5.4.1. Class of Service IE There should be separate IEs to distinguish between Cos for V4, V6, MPLS & VLAN. A packet can have more than one Cos fields, each associated with { & & } 5.4.4 "This information is used by applications to later correlate the ingress/egress port with a specific Exporter. " What does this mean? This looks to me as a part of the flow header extension which is optional. 5.5. Flow State IE A better way to put this would be "export reason" which could be: 1. Inactive 2. End of flow detected 3. Forced export 4. Cache full 5.6. Statistical Elements Some of the IEs that I can think of: From the observation domain * Flows collected * Flows dropped From exporter * Export data packets sent * Export control packets sent * Export data packets dropped 5.6.1. Byte Count IE 5.6.2. Packet Count IE How does one distinguish between delta counter and running counter at the collector? 5.6.3. Dropped Byte Count IE I'm not sure how accurate one can get here. The packets may be dropped before the actual metering itself happened or well after the metering has happened (like another LC in a distributed system). But yes, in some cases this would work fine. 5.6.5. IPM_DPKTS Total number of packets after replication for this multicast flow. 5.6.6. IPM_DOCTETS Total number of octets after replication for this multicast flow. 5.8.3. Next Hop AS IE Don't we need a "Previous Hop AS IE"? 5.11. BGP & Vlan IE's May be better to split these 2 into 2 different sections (BGP related and VLAN related). 5.11.4. Source VLAN ID IE 5.11.5. Destination VLAN ID IE Is there not a one-to-one correspondence between VLAN-ID and interface Index? I am wondering where this would useful. Is there a plan to distinguish between .1p and .1q? 5.13.7. IGMP_TYPE Types of IGMP messages of concern to the host-router interaction. -- 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 Fri Feb 15 02:29:06 2002 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 CAA28924 for ; Fri, 15 Feb 2002 02:29:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bcXo-0005ho-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 01:12:32 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bcXn-0005h2-00 for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 01:12:31 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1F7C0g43485; Fri, 15 Feb 2002 08:12:00 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id IAA06650; Fri, 15 Feb 2002 08:11:55 +0100 Date: Fri, 15 Feb 2002 08:13:43 +0100 From: Juergen Quittek To: Ganesh Sadasivan cc: Sebastian Zander , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again Message-ID: <148541556.1013760823@[192.168.102.31]> In-Reply-To: <3C6C5108.B46B4308@cisco.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ganesh, Your ideas are getting clearer to me. Still I have some questions. Please find them inline. --On 14 February 2002 16:06 -0800 Ganesh Sadasivan wrote: > > > Juergen Quittek wrote: > >> Hi Ganesh, >> >> --On 14 February 2002 14:45 -0800 Ganesh Sadasivan wrote: >> >> > Hi Jurgene, >> > The picture does not appear garbled in the archives. Probably you >> > can look at it there.See inline for my answers. >> >> I could read the picture well (even in your reply). >> >> > >> > Juergen Quittek wrote: >> > >> >> Hi Ganesh, >> >> >> >> --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: >> >> >> >> > Hi Jurgene, >> >> > I am of the opinion that "header capturing" is a metering >> >> > function.I see restrictions with your model. Escpecially >> >> > if some kind of metering is done on collected flows within >> >> > the router. It was with this in mind that I send out in one of >> >> > my previous mails the high level picture. Did not get any >> >> > response. So I am resending with some more modification. I am >> >> > slightly inclined to think that the metering process within >> >> > the observation domain could be hierarchical but have not put >> >> > it here. >> >> > What are your inputs? >> >> > >> >> Please excuse that I did not reply so far on your drawing. >> >> I did not understand it when I saw it the first time and sent >> >> it to the printer to study it later. Unfortunately, that's where >> >> it still is. I should better have sent you my questions on this: >> >> >> >> 1. What is the difference between a meter process and a meter? >> > >> > Sorry that is a mistake, I meant "meter process" for both cases >> > (within and outside the observation domain). >> >> I think "meter" is a very well suited name for a box >> hosting a metering process! > > Ok. > >> >> >> >> >> >> 2. How and from where do meters get input? from meter processes? >> > >> > Since there is no separate meters and meter processes, you can think of >> > it as meter process within the observation domain, feeding the the meter >> > process outside the observation domain. >> >> Meter processes can be cascaded? > > yes. > >> >> What is the input to a meter process? > > The input to the meter at the lowest level is packets. > Flows are cretaed as a result of the lowest level > meter process. At subsequent level,the input to meter would > be flows. As I mentioned before the first level meter is a must > but not the subsequent ones. What are 'flows' here? Do you mean already flow records containing flow statistics? Or are these packet headers tagged with some flow ID? >> >> It must have the same structure than the output? >> Otherwise I do not see how you could cascade them. > > What does this mean? If you have two function blocks with identical names I assume their functions are identical. However the functions seem to be applied to different data for inside and outside meter processes. And I still do not understand whether they produce similar output. For sure the last stage must produce flow records. What is produces by the earlier stages I asked already above. >> >> >> How is the total metering process shared by the packet meter >> processes and the flow meter processes? > > They are independent entities. > >> >> In other words: what are the differences between these >> (different?) kinds of meters inside and outside the observation >> domain? > > The one outside observation domain operates on a bigger scope. > For example: Say there are 2 lowest level meters: > M11 extracts the 5 tuple IPV4 flows from interface1 at a > sampling rate of 1 in 10. > M12 extracts the 5 tuple IPV4 flows from interface2 at a > sampling rate of 1 in 20. > A meter at the level of observation domain sees the flows > created by M11 and M12 and does one more level of > sampling of all the flows created by both meters at a > rate of 1 in 2 before exporting it. I am not sure if you can do sampling at the second stage after you already did packet counting at the first level. What vwould the first level (inside) meter processes do other than sampling? Do they classify packets, determine the flow ID and forward some data on a per packet base to the second stage (outside) meter processes? Cheers, Juergen > > Ganesh > >> >> >> Juergen >> >> > >> >> >> >> 3. Is there only one exporter per observation domain? >> > >> > No. The exporter need not be tied to an observation domain. >> > Example: Take the case of 2 linecards in a router., linecard 1 and >> > linecard 2. Each of the LC forms an observation domain. The >> > meters associated directly with observation points perform flow >> > creation/updation based on the packets. There could be meters at >> > a higher level (i.e per observation domain) that do furthur filtering >> > or aggregation.However, the flows collected at the observation >> > domain LC1& LC2 could be >> > exported via LC2. Thus the exporter which is common to LC1 >> > and LC2 resides in LC2. The flow export packet from >> > each of the observation domain is identified by a unique ID. >> > >> > >> >> >> >> 4. What would be the difference between an observation domain >> >> ID and an exporter ID? >> > >> > The export flow packet is identified by the observation domain ID . >> > I am not sure we need the Exporter ID (or do we?) >> > >> > Thanks >> > Ganesh >> > >> >> >> >> >> >> Cheers, >> >> >> >> Juergen >> >> >> >> > >> >> > +---------------------------------------------------------------+ >> >> > | Observation Domain | >> >> > | | >> >> > | +-------+ +-------+ Packet level| >> >> > | |Meter1 | .... |MeterM | ({Fi}, {Si})| >> >> > | |Process| |Process| | >> >> > | +-------+ +-------+ | >> >> > | ^ ^ | >> >> > | | | | >> >> > | +-------+-------+ +-------+--------+ | >> >> > | | | | | | >> >> > | v v v v | >> >> > |+------------+ +------------+ +------------+ +------------+| >> >> > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| >> >> > |+------------+ +------------+ +------------+ +------------+| >> >> > +---------------------------------------------------------------+ >> >> > ^ ^ >> >> > | | >> >> > v v >> >> > +----------+ +----------+ >> >> > |Meter (O1)| .... |Meter (OP)| Flow Level >> >> > +----------+ +----------+ ({Fi}, {Si}) >> >> > | | >> >> > +-------+--------+ >> >> > | >> >> > v (uniqued ID for an observation domain) >> >> > +---------------+ >> >> > | exporter | >> >> > +---------------+ >> >> > >> >> > >> >> > Thanks >> >> > Ganesh >> >> > >> >> > Juergen Quittek wrote: >> >> > >> >> > Hi Sabastian, >> >> > >> >> > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: >> >> > >> >> >> Hi Juergen, >> >> >> >> >> >> Juergen Quittek schrieb: >> >> >>> >> >> >>> Hi all, >> >> >>> >> >> >>> We had some terminology discussion and it has not >> >> >>> converged yet. Therfore I like to raise one issue again: >> >> >>> >> >> >>> For the terinology section of the requirements draft >> >> >>> (I belive now it will be a subset of the architecture's >> >> >>> terminology) I would like to have two identifiers for >> >> >>> the following: >> >> >>> >> >> >>> 1. the function block containing all metering functions >> >> >>> This block gets as input observed (and potentially >> >> >>> sampled) packets from the observation point. It classifies >> >> >>> packets maps them to flows and creates/updates the >> >> >>> according flow record. >> >> >>> >> >> >>> 2. the function block sending flow records to the collector >> >> >>> >> >> >>> I am fine with splitting blocks more or modifying them >> >> >>> slightly, but I prefer to have this separation, because >> >> >>> also the requirements are split in a very similar way. >> >> >> >> >> >> I also would like to split those for at least 2 reasons. >> >> >> First we create a more general model because on a router linecard >> >> >> both are be combined but on a dedicated hardware/software based >> >> >> meter this will probably not the case. I don't think we should limit >> >> >> ipfix to routers only. Second the separation is nice to clarify >> >> >> the scope. The scope of the ipfix wg is to standardize the >> >> >> exporter (at least the interface to the outside). It's out >> >> >> of scope to standardize the meter (although we put some req. >> >> >> on it). >> >> >> >> >> >> I am not sure whether sampling is a function of the observation >> >> >> point or the meter. >> >> > >> >> > Neither am I, but we should agree on one or the other soon. >> >> > What about the following (short version of more detailed >> >> > suggestions already discussed for the architecture)? >> >> > >> >> > +-------+ +-----------+ +-------+ +--------+ +--------+ >> >> > | obs. | | header | | | | flow | | ex- | >> >> > | point |-->| capturing |-->| meter |-->| record |-->| porter | >> >> > +-------+ +-----------+ +-------+ +--------+ +--------+ >> >> > >> >> > | | >> >> > \____________________________ _____________________________/ >> >> > \/ >> >> > IPFIX traffic flow measurement module >> >> > >> >> > If can tell me a good reason I am fine with merging header capturing >> >> > and meter, but in general I see them as different function blocks. >> >> > >> >> > Juergen >> >> > >> >> >>> My initial naive suggestion was calling block 1. "meter" >> >> >>> and calling block 2. "exporter". However this might (no it >> >> >>> did already) cause confusion. Therefore, I am looking for >> >> >>> better terms. Any suggestions? >> >> >> >> >> >> I have no better terms. I think what's maybe confusing is that we don't >> >> >> have a term for the overall process (meter+exporter+observation). >> >> >> What could be appropriate? flow monitor? >> >> >> >> >> >> Another possibility: Name the overall process metering and rename >> >> >> the inner function block 1 which does classification etc. >> >> >> >> >> >> Sebastian >> >> >> >> >> >> -- >> >> >> Sebastian Zander E-mail: zander@fokus.fhg.de >> >> >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 >> >> >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >> >> >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander >> >> >> >> >> > >> >> > -- >> >> > 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/ >> >> > >> > > -- 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 Fri Feb 15 03:27:31 2002 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 DAA29680 for ; Fri, 15 Feb 2002 03:27:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bdLz-0006rS-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 02:04:23 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bdLw-0006rF-00 for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 02:04:20 -0600 Received: from fokus.fhg.de (dhcp252 [195.37.78.252]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1F84Fp14098; Fri, 15 Feb 2002 09:04:15 +0100 (MET) Message-ID: <3C6CBFF9.89BCA779@fokus.fhg.de> Date: Fri, 15 Feb 2002 08:59:53 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: Ganesh Sadasivan CC: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again References: <120715491.1013732997@[192.168.102.31]> <3C6C5108.B46B4308@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, Ganesh I try to answer to you both in one mail. Juergen: I think header capturing should be named packet capturing for generality because otherwise we have to define what header means (which layer) and impose limits here? I though header capturing is the functionality of the observation point!? Since you make it a separate block what's the functionality left for observation point? I agree to your blocks but do we need that high level of decomposition? Why not put packet capturing in observation point and flow record in meter? My intuitive 3 function blocks are: (1) Get packets from wire, (2) process packets & generate flow records and (3) export flow records. If we really do need further decomposition than it's fine with me but otherwise stay on the highest suitable level. I think on a high level sampling can be done as part of packet capturing or as part of metering. With further decomposition I think a sampling block would be between capturing & meter. But do we really need to define this? BTW I like your overall name but maybe the "traffic" could be omitted to make it shorter? Ganesh: I think cascading meters is a nice idea but that implies that the input interface of a meter is the same as the output interface as Juergen said. Why then limit the model to only 2 steps? I do not understand why in your picture the observation point is behind the meter. I think it's the other way around. If then the observation point definition is extended to cover an observation domain you have a fully recursive definition and can cascade meters as you want (or not if you don't). This would read e.g.: More than 1 meter could be grouped forming a (virtual) observation point for a following meter. In contrast to a real observation point which is a lincard or NIC. I think your example fits into this model. This approach would converge the 2 models. Additionally there was a comment from Peter Phaal who proposed to cascade exporters. I think this could be done with the model, if a collector can be seen as an observation point/domain as well. My guess is that that we need an exporter ID in addition to obs. point ID(s) to differentiate between different exporters at the collector level. Would be nice to have 2 ID types: (1) Where has the flow been observed, (2) who has told me about it. But im not 100% sure about this. Omitting an exporter ID would at least require some assumptions such that an observation point has only 1 exporter... Sebastian Ganesh Sadasivan schrieb: > > Juergen Quittek wrote: > > > Hi Ganesh, > > > > --On 14 February 2002 14:45 -0800 Ganesh Sadasivan wrote: > > > > > Hi Jurgene, > > > The picture does not appear garbled in the archives. Probably you > > > can look at it there.See inline for my answers. > > > > I could read the picture well (even in your reply). > > > > > > > > Juergen Quittek wrote: > > > > > >> Hi Ganesh, > > >> > > >> --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: > > >> > > >> > Hi Jurgene, > > >> > I am of the opinion that "header capturing" is a metering > > >> > function.I see restrictions with your model. Escpecially > > >> > if some kind of metering is done on collected flows within > > >> > the router. It was with this in mind that I send out in one of > > >> > my previous mails the high level picture. Did not get any > > >> > response. So I am resending with some more modification. I am > > >> > slightly inclined to think that the metering process within > > >> > the observation domain could be hierarchical but have not put > > >> > it here. > > >> > What are your inputs? > > >> > > > >> Please excuse that I did not reply so far on your drawing. > > >> I did not understand it when I saw it the first time and sent > > >> it to the printer to study it later. Unfortunately, that's where > > >> it still is. I should better have sent you my questions on this: > > >> > > >> 1. What is the difference between a meter process and a meter? > > > > > > Sorry that is a mistake, I meant "meter process" for both cases > > > (within and outside the observation domain). > > > > I think "meter" is a very well suited name for a box > > hosting a metering process! > > Ok. > > > > > > > >> > > >> 2. How and from where do meters get input? from meter processes? > > > > > > Since there is no separate meters and meter processes, you can think of > > > it as meter process within the observation domain, feeding the the meter > > > process outside the observation domain. > > > > Meter processes can be cascaded? > > yes. > > > > > What is the input to a meter process? > > The input to the meter at the lowest level is packets. > Flows are cretaed as a result of the lowest level > meter process. At subsequent level,the input to meter would > be flows. As I mentioned before the first level meter is a must > but not the subsequent ones. > > > > > It must have the same structure than the output? > > Otherwise I do not see how you could cascade them. > > What does this mean? > > > > > > > How is the total metering process shared by the packet meter > > processes and the flow meter processes? > > They are independent entities. > > > > > In other words: what are the differences between these > > (different?) kinds of meters inside and outside the observation > > domain? > > The one outside observation domain operates on a bigger scope. > For example: Say there are 2 lowest level meters: > M11 extracts the 5 tuple IPV4 flows from interface1 at a > sampling rate of 1 in 10. > M12 extracts the 5 tuple IPV4 flows from interface2 at a > sampling rate of 1 in 20. > A meter at the level of observation domain sees the flows > created by M11 and M12 and does one more level of > sampling of all the flows created by both meters at a > rate of 1 in 2 before exporting it. > > Ganesh > > > > > > > Juergen > > > > > > > >> > > >> 3. Is there only one exporter per observation domain? > > > > > > No. The exporter need not be tied to an observation domain. > > > Example: Take the case of 2 linecards in a router., linecard 1 and > > > linecard 2. Each of the LC forms an observation domain. The > > > meters associated directly with observation points perform flow > > > creation/updation based on the packets. There could be meters at > > > a higher level (i.e per observation domain) that do furthur filtering > > > or aggregation.However, the flows collected at the observation > > > domain LC1& LC2 could be > > > exported via LC2. Thus the exporter which is common to LC1 > > > and LC2 resides in LC2. The flow export packet from > > > each of the observation domain is identified by a unique ID. > > > > > > > > >> > > >> 4. What would be the difference between an observation domain > > >> ID and an exporter ID? > > > > > > The export flow packet is identified by the observation domain ID . > > > I am not sure we need the Exporter ID (or do we?) > > > > > > Thanks > > > Ganesh > > > > > >> > > >> > > >> Cheers, > > >> > > >> Juergen > > >> > > >> > > > >> > +---------------------------------------------------------------+ > > >> > | Observation Domain | > > >> > | | > > >> > | +-------+ +-------+ Packet level| > > >> > | |Meter1 | .... |MeterM | ({Fi}, {Si})| > > >> > | |Process| |Process| | > > >> > | +-------+ +-------+ | > > >> > | ^ ^ | > > >> > | | | | > > >> > | +-------+-------+ +-------+--------+ | > > >> > | | | | | | > > >> > | v v v v | > > >> > |+------------+ +------------+ +------------+ +------------+| > > >> > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| > > >> > |+------------+ +------------+ +------------+ +------------+| > > >> > +---------------------------------------------------------------+ > > >> > ^ ^ > > >> > | | > > >> > v v > > >> > +----------+ +----------+ > > >> > |Meter (O1)| .... |Meter (OP)| Flow Level > > >> > +----------+ +----------+ ({Fi}, {Si}) > > >> > | | > > >> > +-------+--------+ > > >> > | > > >> > v (uniqued ID for an observation domain) > > >> > +---------------+ > > >> > | exporter | > > >> > +---------------+ > > >> > > > >> > > > >> > Thanks > > >> > Ganesh > > >> > > > >> > Juergen Quittek wrote: > > >> > > > >> > Hi Sabastian, > > >> > > > >> > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: > > >> > > > >> >> Hi Juergen, > > >> >> > > >> >> Juergen Quittek schrieb: > > >> >>> > > >> >>> Hi all, > > >> >>> > > >> >>> We had some terminology discussion and it has not > > >> >>> converged yet. Therfore I like to raise one issue again: > > >> >>> > > >> >>> For the terinology section of the requirements draft > > >> >>> (I belive now it will be a subset of the architecture's > > >> >>> terminology) I would like to have two identifiers for > > >> >>> the following: > > >> >>> > > >> >>> 1. the function block containing all metering functions > > >> >>> This block gets as input observed (and potentially > > >> >>> sampled) packets from the observation point. It classifies > > >> >>> packets maps them to flows and creates/updates the > > >> >>> according flow record. > > >> >>> > > >> >>> 2. the function block sending flow records to the collector > > >> >>> > > >> >>> I am fine with splitting blocks more or modifying them > > >> >>> slightly, but I prefer to have this separation, because > > >> >>> also the requirements are split in a very similar way. > > >> >> > > >> >> I also would like to split those for at least 2 reasons. > > >> >> First we create a more general model because on a router linecard > > >> >> both are be combined but on a dedicated hardware/software based > > >> >> meter this will probably not the case. I don't think we should limit > > >> >> ipfix to routers only. Second the separation is nice to clarify > > >> >> the scope. The scope of the ipfix wg is to standardize the > > >> >> exporter (at least the interface to the outside). It's out > > >> >> of scope to standardize the meter (although we put some req. > > >> >> on it). > > >> >> > > >> >> I am not sure whether sampling is a function of the observation > > >> >> point or the meter. > > >> > > > >> > Neither am I, but we should agree on one or the other soon. > > >> > What about the following (short version of more detailed > > >> > suggestions already discussed for the architecture)? > > >> > > > >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > > >> > | obs. | | header | | | | flow | | ex- | > > >> > | point |-->| capturing |-->| meter |-->| record |-->| porter | > > >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > > >> > > > >> > | | > > >> > \____________________________ _____________________________/ > > >> > \/ > > >> > IPFIX traffic flow measurement module > > >> > > > >> > If can tell me a good reason I am fine with merging header capturing > > >> > and meter, but in general I see them as different function blocks. > > >> > > > >> > Juergen > > >> > > > >> >>> My initial naive suggestion was calling block 1. "meter" > > >> >>> and calling block 2. "exporter". However this might (no it > > >> >>> did already) cause confusion. Therefore, I am looking for > > >> >>> better terms. Any suggestions? > > >> >> > > >> >> I have no better terms. I think what's maybe confusing is that we don't > > >> >> have a term for the overall process (meter+exporter+observation). > > >> >> What could be appropriate? flow monitor? > > >> >> > > >> >> Another possibility: Name the overall process metering and rename > > >> >> the inner function block 1 which does classification etc. > > >> >> > > >> >> Sebastian > > >> >> > > >> >> -- > > >> >> Sebastian Zander E-mail: zander@fokus.fhg.de > > >> >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > > >> >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > > >> >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > > >> >> > > >> > > > >> > -- > > >> > 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/ > > >> > > > > -- Sebastian Zander E-mail: zander@fokus.fhg.de FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Fri Feb 15 05:27:22 2002 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 FAA01493 for ; Fri, 15 Feb 2002 05:27:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bfJX-0001xx-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 04:09:59 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bfJU-0001xr-00 for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 04:09:56 -0600 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1FABnQ29659 for ; Fri, 15 Feb 2002 04:11:49 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Feb 2002 04:09:55 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Feb 2002 04:09:54 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [ipfix-req] Terminology again Date: Fri, 15 Feb 2002 05:09:53 -0500 Message-ID: Thread-Topic: [ipfix-req] Terminology again Thread-Index: AcG1tgPRa3xa09nvTsS5RjqkDocZaAAU7kRA From: To: , Cc: , X-OriginalArrivalTime: 15 Feb 2002 10:09:54.0935 (UTC) FILETIME=[EA433070:01C1B608] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id FAA01493 Hello, >> >> What is the input to a meter process? > >The input to the meter at the lowest level is packets. >Flows are cretaed as a result of the lowest level >meter process. At subsequent level,the input to meter would >be flows. As I mentioned before the first level meter is a must >but not the subsequent ones. > The flow you refer to the Flow which is of interest to the collector or it is a RAW flow any data flowing thro' the observation point. Regards Ramg ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Fri Feb 15 11:58:26 2002 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 LAA11215 for ; Fri, 15 Feb 2002 11:58:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16blFR-0003sE-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 10:30:09 -0600 Received: from mailhub.lawrence.edu ([143.44.65.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16blFP-0003s7-00 for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 10:30:07 -0600 Received: from lawrence.edu ([143.44.97.41]) by lawrence.edu (PMDF V6.0-025 #44893) with ESMTP id <0GRL002G32ETTW@lawrence.edu> for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 10:42:30 -0600 (CST) Date: Fri, 15 Feb 2002 10:30:06 -0600 From: Robert Lowe Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes todraft-ietf-ipfix-reqs-00.txt To: Benoit Claise Cc: ram.gopal@nokia.com, kevin.zhang@xacct.com, quittek@ccrle.nec.de, ipfix-req@net.doit.wisc.edu Message-id: <3C6D378E.212509C7@lawrence.edu> Organization: Lawrence University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200202141739.g1EHd6J24129@bru-cse-222.cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: The lurker opinion poll (no vote)... ;-) In-band configuration -- not now. Negotiation -- limited (but that discussion is promised to follow). Benoit, I think this was a very perceptive comment. It seems we are at times confusing the two. -Robert > > I would underscore the fact that exporters might be probes and midboxes that need > > to support more data collection functionality. Without some form of configuration, > > preferably in-band, their applications will be significantly limited. > > Obviously, we want to be able to configure an exporter. For example, just to configure > what the template should be. > The only conclusion that this thread draw is: in or out-of-band, I mean CLI > configuration of the exporter or the exporter, via the IPFIX protocol, must be able > to configure the exporter. > > Through template negotiation/acknowledgement, the correct context can be set at > > the IPFIX end-points. This will ensure correct interpretation of received data > > by the collector. The periodic template refreshing scheme is less robust as > > losses of the template information will put the collector on hold. For some > > applications that require real-time information collection, this means the flow > > information will be delayed at least another refreshing cycle. > > This is not correct but I would come back on that in other thread, later. > Negotation is something else that the group will have to find a rough consensus on.. > I propose to just concentrate on one issue at the time, if we want to be efficient: > in or out-of-band configuration. No worries, the thread for negotation would follow! -- 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 Fri Feb 15 12:19:50 2002 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 MAA12249 for ; Fri, 15 Feb 2002 12:19:50 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16blg8-0004Ra-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 10:57:44 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16blg5-0004R6-00 for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 10:57:41 -0600 Received: from peter ([192.168.254.182]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1FGvZl06589; Fri, 15 Feb 2002 08:57:35 -0800 From: "Peter Ludemann" To: "Juergen Quittek" , "Reinaldo Penno" , , "Benoit Claise" Cc: , , , "Kevin Zhang" Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Fri, 15 Feb 2002 08:53:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <117111158.1013729393@[192.168.102.31]> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote Thursday, February 14, 2002 2:30 PM: > So what is your point? Do you want to have in-band configuration > for the exported attributes/IEs in the requirements document? Yes. The CRANE protocol solves real problems that we've encountered; and we have a number of partners who are using it (sorry, I can't announce these right now). > What would be the application requiring this? Or from which > general requirement would you derive this one? My answer is a little long. Our requirements go beyond just delivering the kind of data that IPFIX is discussing; but I think that they are very applicable to IPFIX. If all you care about is delivering one set of values which you'll never change, then there's no need for any in-band configuration. (This would be true only if you think that the data architecture folks will agree on a specification with no SHOULDs in the document ...) If you anticipate change, then at minimum you need to specify the version of the data that you're delivering. A more general solution is to use self-describing data. XML would be fine but it's much too verbose for delivering thousands of records per second from a small network device. So, the minimal requirement is to have some way for the device to advertise what it has. I don't see a need for all of XML's nesting capabilities; a simple 2-level scheme (type of record + fields) should suffice. The receiver could quietly take this advertisement and process it. But our experience in "IP data mediation" is that people usually only want specific fields; and they typically want to post-process them. Examples of such post-processing: associating values with IP addresses (e.g., reversing NAT, mapping IP to customer), aggregation, filtering, conditional splitting, etc. plus a host of database-oriented processing, such as looking for error patterns, for people who hog bandwidth, etc. If the sending device can be configured by a MIB or CLI, the receiver can adapt to what it advertises. But there are good reasons for such configuration to be done by response from the receiver: - the needed fields can be derived from the post-processing configuration, so they naturally reside on the receiver, not the sender - there can be tens or even thousands of sending devices, so centralized configuration is desirable (especially if they can't all have their versions changed simultaneously) - there needs to be a way of coordinating amongst multiple receivers, for fail-over deployments (these aren't hypothetical requirements: we have customers who are looking at deploying thousands of sending devices; and who require fail-over) Once you decide that the sender should advertises its data, it doesn't take much more work to allow the receiver to respond with a list of fields that it does or doesn't want. The sender can just mark the fields it won't send. The advantages of this are: - bandwidth saving (probably not very important) - computation saving on the sender (this can be significant in our experience) Our proposal makes it OPTIONAL for the sender to respond to the configuration request. The sender can ignore the configuration request and still send all the fields -- the receiver will just have to accept them (and throw away what it doesn't want). But if the sender can take advantage of the configuration request (e.g., turning off expensive computations), then it has a simple mechanism for doing so. ---- Peter Ludemann Chief Architect, XACCT +1.408.330.5732 -- 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 Fri Feb 15 12:25:09 2002 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 MAA12442 for ; Fri, 15 Feb 2002 12:25:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16blkk-0004ar-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 11:02:30 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16blki-0004Zh-00 for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 11:02:28 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1FH1kZ16002; Fri, 15 Feb 2002 09:01:47 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABF10613; Fri, 15 Feb 2002 09:02:17 -0800 (PST) Message-ID: <3C6D3F00.1CD73670@cisco.com> Date: Fri, 15 Feb 2002 09:01:52 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Quittek CC: Sebastian Zander , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again References: <148541556.1013760823@[192.168.102.31]> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Jurgene, See inline.. Juergen Quittek wrote: > Hi Ganesh, > > Your ideas are getting clearer to me. Still I have some > questions. Please find them inline. > > --On 14 February 2002 16:06 -0800 Ganesh Sadasivan wrote: > > > > > > > Juergen Quittek wrote: > > > >> Hi Ganesh, > >> > >> --On 14 February 2002 14:45 -0800 Ganesh Sadasivan wrote: > >> > >> > Hi Jurgene, > >> > The picture does not appear garbled in the archives. Probably you > >> > can look at it there.See inline for my answers. > >> > >> I could read the picture well (even in your reply). > >> > >> > > >> > Juergen Quittek wrote: > >> > > >> >> Hi Ganesh, > >> >> > >> >> --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: > >> >> > >> >> > Hi Jurgene, > >> >> > I am of the opinion that "header capturing" is a metering > >> >> > function.I see restrictions with your model. Escpecially > >> >> > if some kind of metering is done on collected flows within > >> >> > the router. It was with this in mind that I send out in one of > >> >> > my previous mails the high level picture. Did not get any > >> >> > response. So I am resending with some more modification. I am > >> >> > slightly inclined to think that the metering process within > >> >> > the observation domain could be hierarchical but have not put > >> >> > it here. > >> >> > What are your inputs? > >> >> > > >> >> Please excuse that I did not reply so far on your drawing. > >> >> I did not understand it when I saw it the first time and sent > >> >> it to the printer to study it later. Unfortunately, that's where > >> >> it still is. I should better have sent you my questions on this: > >> >> > >> >> 1. What is the difference between a meter process and a meter? > >> > > >> > Sorry that is a mistake, I meant "meter process" for both cases > >> > (within and outside the observation domain). > >> > >> I think "meter" is a very well suited name for a box > >> hosting a metering process! > > > > Ok. > > > >> > >> > >> >> > >> >> 2. How and from where do meters get input? from meter processes? > >> > > >> > Since there is no separate meters and meter processes, you can think of > >> > it as meter process within the observation domain, feeding the the meter > >> > process outside the observation domain. > >> > >> Meter processes can be cascaded? > > > > yes. > > > >> > >> What is the input to a meter process? > > > > The input to the meter at the lowest level is packets. > > Flows are cretaed as a result of the lowest level > > meter process. At subsequent level,the input to meter would > > be flows. As I mentioned before the first level meter is a must > > but not the subsequent ones. > > What are 'flows' here? Do you mean already flow records > containing flow statistics? > Or are these packet headers tagged with some flow ID? Yes flow records. Do we need packet headers tagged with flow ID at all ? Even if they appear in thet form of packet header, it would be better to call them flow records even though they may not the final structures to be exported. > > > >> > >> It must have the same structure than the output? > >> Otherwise I do not see how you could cascade them. > > > > What does this mean? > > If you have two function blocks with identical names > I assume their functions are identical. However the > functions seem to be applied to different data for inside > and outside meter processes. And I still do not understand > whether they produce similar output. For sure the last > stage must produce flow records. What is produces by the > earlier stages I asked already above. I agree with the fact that input to the first level meter is packets and to the rest of the levels it is flow records. The outputs produced by meters at any level should be flow records of some form which may not be what would be finally exported.We can distinguish between packet level and flow level meters. > > > >> > >> > >> How is the total metering process shared by the packet meter > >> processes and the flow meter processes? > > > > They are independent entities. > > > >> > >> In other words: what are the differences between these > >> (different?) kinds of meters inside and outside the observation > >> domain? > > > > The one outside observation domain operates on a bigger scope. > > For example: Say there are 2 lowest level meters: > > M11 extracts the 5 tuple IPV4 flows from interface1 at a > > sampling rate of 1 in 10. > > M12 extracts the 5 tuple IPV4 flows from interface2 at a > > sampling rate of 1 in 20. > > A meter at the level of observation domain sees the flows > > created by M11 and M12 and does one more level of > > sampling of all the flows created by both meters at a > > rate of 1 in 2 before exporting it. > > I am not sure if you can do sampling at the second stage > after you already did packet counting at the first level. > What vwould the first level (inside) meter processes do > other than sampling? Do they classify packets, determine > the flow ID and forward some data on a per packet base to > the second stage (outside) meter processes? Packet counting is not the targeted functionality in the example above.It is more of a traffic engineering application. The first level would sample packets and install the flow records into a flow cache (like how it is done in netflow today). The second level takes the flows from flow cache as input and does furthur sampling. The example is not a very clear one. It would have been better if the sampling at second level is replaced by say 2 filters filtering on some subsets of fields from the flow records. Thanks Ganesh > > > Cheers, > > Juergen > > > > Ganesh > > > >> > >> > >> Juergen > >> > >> > > >> >> > >> >> 3. Is there only one exporter per observation domain? > >> > > >> > No. The exporter need not be tied to an observation domain. > >> > Example: Take the case of 2 linecards in a router., linecard 1 and > >> > linecard 2. Each of the LC forms an observation domain. The > >> > meters associated directly with observation points perform flow > >> > creation/updation based on the packets. There could be meters at > >> > a higher level (i.e per observation domain) that do furthur filtering > >> > or aggregation.However, the flows collected at the observation > >> > domain LC1& LC2 could be > >> > exported via LC2. Thus the exporter which is common to LC1 > >> > and LC2 resides in LC2. The flow export packet from > >> > each of the observation domain is identified by a unique ID. > >> > > >> > > >> >> > >> >> 4. What would be the difference between an observation domain > >> >> ID and an exporter ID? > >> > > >> > The export flow packet is identified by the observation domain ID . > >> > I am not sure we need the Exporter ID (or do we?) > >> > > >> > Thanks > >> > Ganesh > >> > > >> >> > >> >> > >> >> Cheers, > >> >> > >> >> Juergen > >> >> > >> >> > > >> >> > +---------------------------------------------------------------+ > >> >> > | Observation Domain | > >> >> > | | > >> >> > | +-------+ +-------+ Packet level| > >> >> > | |Meter1 | .... |MeterM | ({Fi}, {Si})| > >> >> > | |Process| |Process| | > >> >> > | +-------+ +-------+ | > >> >> > | ^ ^ | > >> >> > | | | | > >> >> > | +-------+-------+ +-------+--------+ | > >> >> > | | | | | | > >> >> > | v v v v | > >> >> > |+------------+ +------------+ +------------+ +------------+| > >> >> > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| > >> >> > |+------------+ +------------+ +------------+ +------------+| > >> >> > +---------------------------------------------------------------+ > >> >> > ^ ^ > >> >> > | | > >> >> > v v > >> >> > +----------+ +----------+ > >> >> > |Meter (O1)| .... |Meter (OP)| Flow Level > >> >> > +----------+ +----------+ ({Fi}, {Si}) > >> >> > | | > >> >> > +-------+--------+ > >> >> > | > >> >> > v (uniqued ID for an observation domain) > >> >> > +---------------+ > >> >> > | exporter | > >> >> > +---------------+ > >> >> > > >> >> > > >> >> > Thanks > >> >> > Ganesh > >> >> > > >> >> > Juergen Quittek wrote: > >> >> > > >> >> > Hi Sabastian, > >> >> > > >> >> > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: > >> >> > > >> >> >> Hi Juergen, > >> >> >> > >> >> >> Juergen Quittek schrieb: > >> >> >>> > >> >> >>> Hi all, > >> >> >>> > >> >> >>> We had some terminology discussion and it has not > >> >> >>> converged yet. Therfore I like to raise one issue again: > >> >> >>> > >> >> >>> For the terinology section of the requirements draft > >> >> >>> (I belive now it will be a subset of the architecture's > >> >> >>> terminology) I would like to have two identifiers for > >> >> >>> the following: > >> >> >>> > >> >> >>> 1. the function block containing all metering functions > >> >> >>> This block gets as input observed (and potentially > >> >> >>> sampled) packets from the observation point. It classifies > >> >> >>> packets maps them to flows and creates/updates the > >> >> >>> according flow record. > >> >> >>> > >> >> >>> 2. the function block sending flow records to the collector > >> >> >>> > >> >> >>> I am fine with splitting blocks more or modifying them > >> >> >>> slightly, but I prefer to have this separation, because > >> >> >>> also the requirements are split in a very similar way. > >> >> >> > >> >> >> I also would like to split those for at least 2 reasons. > >> >> >> First we create a more general model because on a router linecard > >> >> >> both are be combined but on a dedicated hardware/software based > >> >> >> meter this will probably not the case. I don't think we should limit > >> >> >> ipfix to routers only. Second the separation is nice to clarify > >> >> >> the scope. The scope of the ipfix wg is to standardize the > >> >> >> exporter (at least the interface to the outside). It's out > >> >> >> of scope to standardize the meter (although we put some req. > >> >> >> on it). > >> >> >> > >> >> >> I am not sure whether sampling is a function of the observation > >> >> >> point or the meter. > >> >> > > >> >> > Neither am I, but we should agree on one or the other soon. > >> >> > What about the following (short version of more detailed > >> >> > suggestions already discussed for the architecture)? > >> >> > > >> >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > >> >> > | obs. | | header | | | | flow | | ex- | > >> >> > | point |-->| capturing |-->| meter |-->| record |-->| porter | > >> >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > >> >> > > >> >> > | | > >> >> > \____________________________ _____________________________/ > >> >> > \/ > >> >> > IPFIX traffic flow measurement module > >> >> > > >> >> > If can tell me a good reason I am fine with merging header capturing > >> >> > and meter, but in general I see them as different function blocks. > >> >> > > >> >> > Juergen > >> >> > > >> >> >>> My initial naive suggestion was calling block 1. "meter" > >> >> >>> and calling block 2. "exporter". However this might (no it > >> >> >>> did already) cause confusion. Therefore, I am looking for > >> >> >>> better terms. Any suggestions? > >> >> >> > >> >> >> I have no better terms. I think what's maybe confusing is that we don't > >> >> >> have a term for the overall process (meter+exporter+observation). > >> >> >> What could be appropriate? flow monitor? > >> >> >> > >> >> >> Another possibility: Name the overall process metering and rename > >> >> >> the inner function block 1 which does classification etc. > >> >> >> > >> >> >> Sebastian > >> >> >> > >> >> >> -- > >> >> >> Sebastian Zander E-mail: zander@fokus.fhg.de > >> >> >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > >> >> >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > >> >> >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > >> >> >> > >> >> > > >> >> > -- > >> >> > 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/ > >> >> > > >> > > > -- 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 Fri Feb 15 12:46:25 2002 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 MAA13644 for ; Fri, 15 Feb 2002 12:46:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bmA0-00054R-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 11:28:36 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bm9x-00053t-00 for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 11:28:34 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1FHRqZ00326; Fri, 15 Feb 2002 09:27:52 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABF11547; Fri, 15 Feb 2002 09:28:23 -0800 (PST) Message-ID: <3C6D451E.39B1F804@cisco.com> Date: Fri, 15 Feb 2002 09:27:59 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sebastian Zander CC: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again References: <120715491.1013732997@[192.168.102.31]> <3C6C5108.B46B4308@cisco.com> <3C6CBFF9.89BCA779@fokus.fhg.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Sebastian, The observation point is the place from where the packets from the wire are seen. The metering functionality acts on these packets to create flows. So even though the drawing shows meter behind the observation point, the metering is happening at the same place as the observation point in most of the cases. In the case of centralised proicessing where all the packets reach a shared memory, the metering is done after the packet is seen at the observation point. See more inline.. Sebastian Zander wrote: > Hi Juergen, Ganesh > > I try to answer to you both in one mail. > > Juergen: > > I think header capturing should be named packet capturing for generality because > otherwise we have to define what header means (which layer) and impose limits > here? > > I though header capturing is the functionality of the observation point!? Since > you make it a separate block what's the functionality left for observation point? Your case of capturing the packet header is a part of flow creation. This is a part of metering process itself. In some other case this functionality may not be necessary. Say if one is looking for packet length, capturing header is not a must. > > > I agree to your blocks but do we need that high level of decomposition? Why not > put packet capturing in observation point and flow record in meter? My intuitive 3 > function blocks are: (1) Get packets from wire, (2) process packets & generate flow > records and (3) export flow records. If we really do need further decomposition than > it's fine with me but otherwise stay on the highest suitable level. > > I think on a high level sampling can be done as part of packet capturing or as part > of metering. With further decomposition I think a sampling block would be between > capturing & meter. But do we really need to define this? > > BTW I like your overall name but maybe the "traffic" could be omitted to make it > shorter? > > Ganesh: > > I think cascading meters is a nice idea but that implies that the input interface > of a meter is the same as the output interface as Juergen said. Why then limit the > model to only 2 steps? Yes the first level meter which happens at the observation point, sees packets instead of flows. The rest of the levels should be seeing flow records of some form which need not be the final exported records. > > > I do not understand why in your picture the observation point is behind the meter. > I think it's the other way around. If then the observation point definition > is extended to cover an observation domain you have a fully recursive definition > and can cascade meters as you want (or not if you don't). This would read e.g.: > More than 1 meter could be grouped forming a (virtual) observation point for a > following meter. In contrast to a real observation point which is a lincard or > NIC. I think your example fits into this model. Yes one can cascade meters at multiple levels. But why we did not mention it is because from a practical standpoint, this would suffice. Today in most of the cases one level metering is what is done and recently only we heard about more requirements for a 2nd level meter . > > > This approach would converge the 2 models. > > Additionally there was a comment from Peter Phaal who proposed to cascade exporters. > I think this could be done with the model, if a collector can be seen as an observation > point/domain as well. > > My guess is that that we need an exporter ID in addition to obs. point ID(s) to > differentiate between different exporters at the collector level. Would be > nice to have 2 ID types: (1) Where has the flow been observed, > (2) who has told me about it. But im not 100% sure about this. Omitting an exporter > ID would at least require some assumptions such that an observation point has only > 1 exporter... Agreed on the last sentence. But why does the collector need to know "(2) who has told me about it"? To me the observation domain ID should identify the flow packets within and across exporters. Thanks Ganesh > > > Sebastian > > Ganesh Sadasivan schrieb: > > > > Juergen Quittek wrote: > > > > > Hi Ganesh, > > > > > > --On 14 February 2002 14:45 -0800 Ganesh Sadasivan wrote: > > > > > > > Hi Jurgene, > > > > The picture does not appear garbled in the archives. Probably you > > > > can look at it there.See inline for my answers. > > > > > > I could read the picture well (even in your reply). > > > > > > > > > > > Juergen Quittek wrote: > > > > > > > >> Hi Ganesh, > > > >> > > > >> --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: > > > >> > > > >> > Hi Jurgene, > > > >> > I am of the opinion that "header capturing" is a metering > > > >> > function.I see restrictions with your model. Escpecially > > > >> > if some kind of metering is done on collected flows within > > > >> > the router. It was with this in mind that I send out in one of > > > >> > my previous mails the high level picture. Did not get any > > > >> > response. So I am resending with some more modification. I am > > > >> > slightly inclined to think that the metering process within > > > >> > the observation domain could be hierarchical but have not put > > > >> > it here. > > > >> > What are your inputs? > > > >> > > > > >> Please excuse that I did not reply so far on your drawing. > > > >> I did not understand it when I saw it the first time and sent > > > >> it to the printer to study it later. Unfortunately, that's where > > > >> it still is. I should better have sent you my questions on this: > > > >> > > > >> 1. What is the difference between a meter process and a meter? > > > > > > > > Sorry that is a mistake, I meant "meter process" for both cases > > > > (within and outside the observation domain). > > > > > > I think "meter" is a very well suited name for a box > > > hosting a metering process! > > > > Ok. > > > > > > > > > > > >> > > > >> 2. How and from where do meters get input? from meter processes? > > > > > > > > Since there is no separate meters and meter processes, you can think of > > > > it as meter process within the observation domain, feeding the the meter > > > > process outside the observation domain. > > > > > > Meter processes can be cascaded? > > > > yes. > > > > > > > > What is the input to a meter process? > > > > The input to the meter at the lowest level is packets. > > Flows are cretaed as a result of the lowest level > > meter process. At subsequent level,the input to meter would > > be flows. As I mentioned before the first level meter is a must > > but not the subsequent ones. > > > > > > > > It must have the same structure than the output? > > > Otherwise I do not see how you could cascade them. > > > > What does this mean? > > > > > > > > > > > How is the total metering process shared by the packet meter > > > processes and the flow meter processes? > > > > They are independent entities. > > > > > > > > In other words: what are the differences between these > > > (different?) kinds of meters inside and outside the observation > > > domain? > > > > The one outside observation domain operates on a bigger scope. > > For example: Say there are 2 lowest level meters: > > M11 extracts the 5 tuple IPV4 flows from interface1 at a > > sampling rate of 1 in 10. > > M12 extracts the 5 tuple IPV4 flows from interface2 at a > > sampling rate of 1 in 20. > > A meter at the level of observation domain sees the flows > > created by M11 and M12 and does one more level of > > sampling of all the flows created by both meters at a > > rate of 1 in 2 before exporting it. > > > > Ganesh > > > > > > > > > > > Juergen > > > > > > > > > > >> > > > >> 3. Is there only one exporter per observation domain? > > > > > > > > No. The exporter need not be tied to an observation domain. > > > > Example: Take the case of 2 linecards in a router., linecard 1 and > > > > linecard 2. Each of the LC forms an observation domain. The > > > > meters associated directly with observation points perform flow > > > > creation/updation based on the packets. There could be meters at > > > > a higher level (i.e per observation domain) that do furthur filtering > > > > or aggregation.However, the flows collected at the observation > > > > domain LC1& LC2 could be > > > > exported via LC2. Thus the exporter which is common to LC1 > > > > and LC2 resides in LC2. The flow export packet from > > > > each of the observation domain is identified by a unique ID. > > > > > > > > > > > >> > > > >> 4. What would be the difference between an observation domain > > > >> ID and an exporter ID? > > > > > > > > The export flow packet is identified by the observation domain ID . > > > > I am not sure we need the Exporter ID (or do we?) > > > > > > > > Thanks > > > > Ganesh > > > > > > > >> > > > >> > > > >> Cheers, > > > >> > > > >> Juergen > > > >> > > > >> > > > > >> > +---------------------------------------------------------------+ > > > >> > | Observation Domain | > > > >> > | | > > > >> > | +-------+ +-------+ Packet level| > > > >> > | |Meter1 | .... |MeterM | ({Fi}, {Si})| > > > >> > | |Process| |Process| | > > > >> > | +-------+ +-------+ | > > > >> > | ^ ^ | > > > >> > | | | | > > > >> > | +-------+-------+ +-------+--------+ | > > > >> > | | | | | | > > > >> > | v v v v | > > > >> > |+------------+ +------------+ +------------+ +------------+| > > > >> > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| > > > >> > |+------------+ +------------+ +------------+ +------------+| > > > >> > +---------------------------------------------------------------+ > > > >> > ^ ^ > > > >> > | | > > > >> > v v > > > >> > +----------+ +----------+ > > > >> > |Meter (O1)| .... |Meter (OP)| Flow Level > > > >> > +----------+ +----------+ ({Fi}, {Si}) > > > >> > | | > > > >> > +-------+--------+ > > > >> > | > > > >> > v (uniqued ID for an observation domain) > > > >> > +---------------+ > > > >> > | exporter | > > > >> > +---------------+ > > > >> > > > > >> > > > > >> > Thanks > > > >> > Ganesh > > > >> > > > > >> > Juergen Quittek wrote: > > > >> > > > > >> > Hi Sabastian, > > > >> > > > > >> > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: > > > >> > > > > >> >> Hi Juergen, > > > >> >> > > > >> >> Juergen Quittek schrieb: > > > >> >>> > > > >> >>> Hi all, > > > >> >>> > > > >> >>> We had some terminology discussion and it has not > > > >> >>> converged yet. Therfore I like to raise one issue again: > > > >> >>> > > > >> >>> For the terinology section of the requirements draft > > > >> >>> (I belive now it will be a subset of the architecture's > > > >> >>> terminology) I would like to have two identifiers for > > > >> >>> the following: > > > >> >>> > > > >> >>> 1. the function block containing all metering functions > > > >> >>> This block gets as input observed (and potentially > > > >> >>> sampled) packets from the observation point. It classifies > > > >> >>> packets maps them to flows and creates/updates the > > > >> >>> according flow record. > > > >> >>> > > > >> >>> 2. the function block sending flow records to the collector > > > >> >>> > > > >> >>> I am fine with splitting blocks more or modifying them > > > >> >>> slightly, but I prefer to have this separation, because > > > >> >>> also the requirements are split in a very similar way. > > > >> >> > > > >> >> I also would like to split those for at least 2 reasons. > > > >> >> First we create a more general model because on a router linecard > > > >> >> both are be combined but on a dedicated hardware/software based > > > >> >> meter this will probably not the case. I don't think we should limit > > > >> >> ipfix to routers only. Second the separation is nice to clarify > > > >> >> the scope. The scope of the ipfix wg is to standardize the > > > >> >> exporter (at least the interface to the outside). It's out > > > >> >> of scope to standardize the meter (although we put some req. > > > >> >> on it). > > > >> >> > > > >> >> I am not sure whether sampling is a function of the observation > > > >> >> point or the meter. > > > >> > > > > >> > Neither am I, but we should agree on one or the other soon. > > > >> > What about the following (short version of more detailed > > > >> > suggestions already discussed for the architecture)? > > > >> > > > > >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > > > >> > | obs. | | header | | | | flow | | ex- | > > > >> > | point |-->| capturing |-->| meter |-->| record |-->| porter | > > > >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > > > >> > > > > >> > | | > > > >> > \____________________________ _____________________________/ > > > >> > \/ > > > >> > IPFIX traffic flow measurement module > > > >> > > > > >> > If can tell me a good reason I am fine with merging header capturing > > > >> > and meter, but in general I see them as different function blocks. > > > >> > > > > >> > Juergen > > > >> > > > > >> >>> My initial naive suggestion was calling block 1. "meter" > > > >> >>> and calling block 2. "exporter". However this might (no it > > > >> >>> did already) cause confusion. Therefore, I am looking for > > > >> >>> better terms. Any suggestions? > > > >> >> > > > >> >> I have no better terms. I think what's maybe confusing is that we don't > > > >> >> have a term for the overall process (meter+exporter+observation). > > > >> >> What could be appropriate? flow monitor? > > > >> >> > > > >> >> Another possibility: Name the overall process metering and rename > > > >> >> the inner function block 1 which does classification etc. > > > >> >> > > > >> >> Sebastian > > > >> >> > > > >> >> -- > > > >> >> Sebastian Zander E-mail: zander@fokus.fhg.de > > > >> >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > > > >> >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > > > >> >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > > > >> >> > > > >> > > > > >> > -- > > > >> > 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/ > > > >> > > > > > > > -- > Sebastian Zander E-mail: zander@fokus.fhg.de > FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Fri Feb 15 12:49:19 2002 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 MAA13814 for ; Fri, 15 Feb 2002 12:49:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bmCr-000593-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 11:31:33 -0600 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bmCp-00058S-00 for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 11:31:31 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1FHV0h11575; Fri, 15 Feb 2002 09:31:00 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABF11666; Fri, 15 Feb 2002 09:31:23 -0800 (PST) Message-ID: <3C6D45D3.20056FC7@cisco.com> Date: Fri, 15 Feb 2002 09:30:59 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ram.gopal@nokia.com CC: quittek@ccrle.nec.de, zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again References: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ram, ram.gopal@nokia.com wrote: > Hello, > > >> > >> What is the input to a meter process? > > > >The input to the meter at the lowest level is packets. > >Flows are cretaed as a result of the lowest level > >meter process. At subsequent level,the input to meter would > >be flows. As I mentioned before the first level meter is a must > >but not the subsequent ones. > > > > The flow you refer to the Flow which is of interest to the collector or it is a RAW flow any data flowing > thro' the observation point. It could be either. If there is no second level meter, the flow created by the lowest level meter would be what is exported. If there is a second level meter then the flow may or may not be the same structure as that which is exported. Thanks Ganesh > > > Regards > Ramg -- 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 Fri Feb 15 15:12:38 2002 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 PAA18180 for ; Fri, 15 Feb 2002 15:12:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16boNe-0000Fr-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 13:50:50 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16boNb-0000F2-00 for ipfix-req@net.doit.wisc.edu; Fri, 15 Feb 2002 13:50:47 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FJjgN25963; Fri, 15 Feb 2002 13:45:43 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFZABQ>; Fri, 15 Feb 2002 11:45:41 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A73FB7@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Robert Lowe , Benoit Claise Cc: ram.gopal@nokia.com, kevin.zhang@xacct.com, quittek@ccrle.nec.de, ipfix-req@net.doit.wisc.edu Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes todra ft-ietf-ipfix-reqs-00.txt Date: Fri, 15 Feb 2002 11:45:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B659.587287D0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B659.587287D0 Content-Type: text/plain; charset="iso-8859-1" Hello, I'm not sure who said that part about middleboxes, but it's a good point. There are devices out there related to middleboxes, probes, OPES, CDI with great flexibility and indirectly we are making a rigid architecture in regards to inband/CN thinking about the least functionality. That's why in order to make it fair for everybody I proposed to put in-band and/or CN as a SHOULD in the architecture document. I think this is further justified by the fact that we have several vendors already interested on this functionality. Since it's a SHOULD vendors not interested can just ignore it. We make it as Peter/Kevin proposed in a way that vendors that do not implement it can silent igonre that message. I'm not sure if the "not now" argument is okay, because I'm not sure there will be a later. We can finish with the charter deliverables and WG might be closed. So, once more I propose that we put this as a SHOULD, people interested work on it and we make sure that vendors that do not want to support it can just ignore the configuration/advertisement. thanks, Reinaldo >-----Original Message----- >From: Robert Lowe [mailto:robert.h.lowe@lawrence.edu] >Sent: Friday, February 15, 2002 8:30 AM >To: Benoit Claise >Cc: ram.gopal@nokia.com; kevin.zhang@xacct.com; quittek@ccrle.nec.de; >ipfix-req@net.doit.wisc.edu >Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes >todraft-ietf-ipfix-reqs-00.txt > > >Benoit Claise wrote: > >The lurker opinion poll (no vote)... ;-) > >In-band configuration -- not now. >Negotiation -- limited (but that discussion is promised to follow). > >Benoit, I think this was a very perceptive comment. It seems we are >at times confusing the two. > >-Robert > >> > I would underscore the fact that exporters might be probes >and midboxes that need >> > to support more data collection functionality. Without >some form of configuration, >> > preferably in-band, their applications will be >significantly limited. >> >> Obviously, we want to be able to configure an exporter. For >example, just to configure >> what the template should be. >> The only conclusion that this thread draw is: in or >out-of-band, I mean CLI >> configuration of the exporter or the exporter, via the IPFIX >protocol, must be able >> to configure the exporter. > >> > Through template negotiation/acknowledgement, the correct >context can be set at >> > the IPFIX end-points. This will ensure correct >interpretation of received data >> > by the collector. The periodic template refreshing scheme >is less robust as >> > losses of the template information will put the collector >on hold. For some >> > applications that require real-time information >collection, this means the flow >> > information will be delayed at least another refreshing cycle. >> >> This is not correct but I would come back on that in other >thread, later. >> Negotation is something else that the group will have to >find a rough consensus on.. >> I propose to just concentrate on one issue at the time, if >we want to be efficient: >> in or out-of-band configuration. No worries, the thread for >negotation would follow! > >-- >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/ > ------_=_NextPart_001_01C1B659.587287D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: in band configuration? RE: [ipfix-req] Proposed changes = todraft-ietf-ipfix-reqs-00.txt

Hello,

I'm not sure who said that part about middleboxes, = but it's a good point. There are devices out there related to = middleboxes, probes, OPES, CDI with great flexibility and indirectly we = are making a rigid architecture in regards to inband/CN thinking about = the least functionality. That's why in order to make it fair for = everybody I proposed to put in-band and/or CN as a SHOULD in the = architecture document. I think this is further justified by the fact = that we have several vendors already interested on this = functionality.

Since it's a SHOULD vendors not interested can just = ignore it. We make it as Peter/Kevin proposed in a way that vendors = that do not implement it can silent igonre that message.

I'm not sure if the "not now" argument is = okay, because I'm not sure there will be a later. We can finish with = the charter deliverables and WG might be closed.

So, once more I propose that we put this as a SHOULD, = people interested work on it and we make sure that vendors that do not = want to support it can just ignore the configuration/advertisement. =

thanks,

Reinaldo


>-----Original Message-----
>From: Robert Lowe [mailto:robert.h.lowe@lawrence= .edu]
>Sent: Friday, February 15, 2002 8:30 AM
>To: Benoit Claise
>Cc: ram.gopal@nokia.com; kevin.zhang@xacct.com; = quittek@ccrle.nec.de;
>ipfix-req@net.doit.wisc.edu
>Subject: Re: in band configuration? RE: = [ipfix-req] Proposed changes
>todraft-ietf-ipfix-reqs-00.txt
>
>
>Benoit Claise wrote:
>
>The lurker opinion poll (no vote)... ;-)
>
>In-band configuration -- not now.
>Negotiation -- limited (but that discussion is = promised to follow).
>
>Benoit, I think this was a very perceptive = comment.  It seems we are
>at times confusing the two.
>
>-Robert
>
>> > I would underscore the fact that = exporters might be probes
>and midboxes that need
>> > to support more data collection = functionality. Without
>some form of configuration,
>> > preferably in-band, their applications = will be
>significantly limited.
>>
>> Obviously, we want to be able to configure = an exporter. For
>example, just to configure
>> what the template should be.
>> The only conclusion that this thread draw = is: in or
>out-of-band, I mean CLI
>> configuration of the exporter or the = exporter, via the IPFIX
>protocol, must be able
>> to configure the exporter.
>
>> > Through template = negotiation/acknowledgement, the correct
>context can be set at
>> > the IPFIX end-points.  This will = ensure correct
>interpretation of received data
>> > by the collector.  The periodic = template refreshing scheme
>is less robust as
>> > losses of the template information = will put the collector
>on hold.  For some
>> > applications that require real-time = information
>collection, this means the flow
>> > information will be delayed at least = another refreshing cycle.
>>
>> This is not correct but I would come back = on that in other
>thread, later.
>> Negotation is something else that the group = will have to
>find a rough consensus on..
>> I propose to just concentrate on one issue = at the time, if
>we want to be efficient:
>> in or out-of-band configuration. No = worries, the thread for
>negotation would follow!
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B659.587287D0-- -- 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 Fri Feb 15 15:14:32 2002 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 PAA18252 for ; Fri, 15 Feb 2002 15:14:30 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16boPU-0000IX-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 13:52:44 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16boPR-0000IL-00 for ipfix@net.doit.wisc.edu; Fri, 15 Feb 2002 13:52:41 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA04583 for ; Fri, 15 Feb 2002 15:02:07 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma004548; Fri, 15 Feb 02 15:01:48 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXPX8Z>; Fri, 15 Feb 2002 14:51:17 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA06DC@slc-exc1.ctron.com> From: "Norseth, KC" To: "'ipfix@net.doit.wisc.edu'" Subject: [ipfix] IPFIX Design draft updates Date: Fri, 15 Feb 2002 14:51:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1B65A.2A969CB0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1B65A.2A969CB0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B65A.2A969CB0" ------_=_NextPart_001_01C1B65A.2A969CB0 Content-Type: text/plain IPFIX People. I have updated both the team architectural and data drafts. The .txt versions are enclosed. If someone wants them in Word format. Let me know. I am not worried at the moment of pagenation and Changes to the drafts: Architecture: * Reordering sections and better integration of the sections from Beniot and Ganesh's draft. * Further definition of some areas. * Spelling and grammer Data: * Integrating sections Beniot and Ganesh's draft. * Further definition of some areas. * Clarification of element types and how to define them. Now I need is the TC's to go along with each element. * Spelling and grammer If I have missed some updates to the draft, let me know. If you have any questions, just ask. Please give as many comments to the group as possible over the weekend, where the "editorial review" board is going to review everything on Monday. As recommended by Nevil, I will submit this as an individual draft, submitted by the design group. This way, reguardless of how the editoral board combines /removes text, this will be recorded for Minneapolis so it can be discussed as needed, just Benoit and Ganesh's is. It will also be given an IPFIX team name, not IETF-IPFIX. K.C. <> <> K.C. Norseth Firmware Engineering - Routing Enterasys Networks Phone: 801.887.9823 FAX: 801.972.5789 Email: knorseth@enterasys.com www: http://www.enterasys.com <> ------_=_NextPart_001_01C1B65A.2A969CB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable IPFIX Design draft updates

IPFIX People.

I have updated both the team = architectural and data drafts.  The .txt versions are = enclosed.  If someone wants them in Word format. Let me = know.  I am not worried at the moment of pagenation and =

Changes to the drafts:

Architecture:

  • Reordering sections and better = integration of the sections from Beniot and Ganesh's draft.  =
  • Further definition of some = areas.
  • Spelling and grammer

Data:

  • Integrating sections Beniot and = Ganesh's draft. 
  • Further definition of some = areas.
  • Clarification of element types and = how to define them.  Now I need is the TC's to go along with each = element.
  • Spelling and grammer

If I have missed some updates to the = draft, let me know.

If you have any questions, just = ask.  Please give as many comments to the group as possible over = the weekend, where the "editorial review" board is going to = review everything on Monday. 

As recommended by Nevil, I will submit = this as an individual draft, submitted by the design group.  This = way, reguardless of how the editoral board combines /removes text, this = will be recorded for Minneapolis so it can be discussed as needed, just = Benoit and Ganesh's  is.  It will also be given an IPFIX team = name, not IETF-IPFIX.

K.C.
= <<draft-ietf-ipfix-data-00.txt>> = <<draft-ietf-ipfix-architecture-00.txt>>
K.C. = Norseth
Firmware = Engineering -  Routing
Enterasys = Networks
   Phone: 801.887.9823
   = FAX:    801.972.5789
   = Email:   knorseth@enterasys.com
   = www:    http://www.enterasys.com=
<<Norseth, = KC.vcf>>

------_=_NextPart_001_01C1B65A.2A969CB0-- ------_=_NextPart_000_01C1B65A.2A969CB0 Content-Type: text/plain; name="draft-ietf-ipfix-data-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ipfix-data-00.txt" Content-Transfer-Encoding: quoted-printable IPFIX working group Internet Draft draft-ietf-ipfix-data-00.txt Expires: August 2002 =0DBenoit Claise Cisco Systems P. Calato Riverstone Networks Inc Ram Gopal Man Li Nokia =20 K.C. Norseth Enterasys Networks Reinaldo Penno NortelNetworks J. Quittek NEC Europe Ltd. Ganesh Sadasivan Cisco Systems, Inc.Kevin Zhang XACCT Technologies Tanja Zseby FhI FOKUS=0D=0D February 2002=0D IPFIX Data Model Architecture Model for IP Flow Information Export draft-ietf-ipfix-data-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all = provisions of Section 10 of RFC2026 [1].=20 Internet-Drafts are working documents of the Internet Engineering Task = Force (IETF), its areas, and its working groups. Note that other groups = may also distribute working documents as Internet-Drafts. = Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet- Drafts as reference material = or to cite them other than as "work in progress."=20 The list of current Internet-Drafts can be accessed at = http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at = http://www.ietf.org/shadow.html. Abstract This document defines architecture for scalable monitoring, measuring = and exporting IP flow information to collectors. =20 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are to be interpreted as described in RFC-2119 [1]. 1. Introduction 5 2. Scope 5 3. Terminology 5 4. Information Model 5 4.1. Attributes related to IP Packet Header 5 4.2. Attributes Related to Measurement 5 4.3. Attributes Related to Flow Definition 6 4.4. Attributes related to Upper Layers 6 4.5. IPFIX Template 6 4.5.1. Template Negotiation 6 5. Flow Export Structure 7 5.1. Flow Header 7 5.1.1. Fields 7 5.2. Template and Template Flowsets 8 5.3. Categories of Template Flowset 9 5.3.1. Case A, Template for Flow Record Definition 9 5.3.2. Case B, Template for Method Description 10 5.3.3. Case C, Template for Dependencies 13 5.4. Template Export Management 15 5.5. Exporting exporter statistics and errors 16 5.6. Exporting Flow Records 16 6. Information Elements 17 6.1. Packet Management 17 6.1.1. Version Number 17 6.1.2. FLOWS 17 6.2. IP Address 18 6.2.1. Source Address 18 6.2.2. Destination Address 18 6.2.3. NEXT_HOP_IP 18 6.3. Time Stamps 18 6.3.1. Time 18 6.3.2. UTC Time 18 6.3.3. Delta Time 18 6.3.4. LAST_SWITCHED 19 6.3.5. FIRST_SWITCHED 19 6.4. Service Types 19 6.4.1. Class of Service 19 6.4.2. TCP Control Bits 19 6.4.3. Protocol Identifier 19 6.4.4. Source Exporter [ is that the right term?? PAC] Address 20 6.5. Flow State 20 6.6. Statistical Elements 20 6.6.1. Byte Count 20 6.6.2. Packet Count 21 6.6.3. Dropped Byte Count 21 6.6.4. Dropped Packet Count 21 6.6.5. IPM_DPKTS 22 6.6.6. IPM_DOCTETS 22 6.7. Port Information 22 6.7.1. Source Port 22 6.7.2. Destination Port 22 6.8. Autonomous System (AS) 22 6.8.1. Source AS 22 6.8.2. Destination AS 22 6.8.3. Next Hop AS 23 6.9. IfIndexes and Interfaces 23 6.9.1. Ingress Port 23 6.9.2. Egress Port 23 6.9.3. Egress ATM Subinterface 23 6.9.4. EGRESS_FRAME_RELAY_SUBINTERFACE 23 6.10. NetMasks 24 6.10.1. Source Address Netmask 24 6.10.2. Destination Address Netmask 24 6.11. BGP & Vlan ?s 24 6.11.1. Destination BGP Community 24 6.11.2. Source BGP Community 24 6.11.3. BGP_NEXT_HOP 24 6.11.4. Source VLAN ID 24 6.11.5. Destination VLAN ID 24 6.12. Virtual Information 25 6.12.1. Source Virtual Address 25 6.12.2. Source Virtual Port 25 6.12.3. Destination Virtual Address 26 6.12.4. Destination Virtual Port 26 6.13. Vendor Specific 26 6.14. Misc. Information Elements 26 6.14.1. Flow Label 26 6.14.2. Flow Direction 27 6.14.3. Fragment ID 27 6.14.4. Internal queue priority 27 6.14.5. Global VPN Identifier 27 6.14.6. ICMP_TYPE 27 6.14.7. IGMP_TYPE 27 6.15. Sampling 27 6.15.1. SAMPLING_INTERVAL 27 6.15.2. SAMPLING_ALGO 28 6.15.3. FLOW_ACTIVE_TIMEOUT 28 6.15.4. FLOW_INACTIVE_TIMEOUT 28 7. References 28 8. Acknowledgements 30 9. Author's Addresses 32 10. Full Copyright Statement 33 11. Stuff to Add 33 12. End of stuff to add 34 1. Introduction Many applications e.g., Intrusion detection, traffic engineering, = require the monitoring, measuring of IP traffic flows. It is hence = important to have a standard way of exporting information related to IP = flows. This document defines architecture for IP traffic flow = monitoring, measuring and exporting. It provides a high-level = description of the key components and their functions.=20 2. Scope This document defines information data model for IPFIX[3]. = Specifically, this document=20 3. Terminology 4. Information Model The IPFIX information model is listed in the IPFIX requirement = document. The information model consists of the set of attributes that = an IPFIX exporting device should be able to export. In conjunction with = IP flow definitions, they provide locally accurate information about a = flow. To meet application?s requirement may require the collection device to = obtain additional information about the flow, e.g. address translation, = user identification, etc. Additional flow information may also be = required; in this case, equipment vendors may define extensions to the = IPFIX information model. Any extension to the IPFIX information model = should be conveyed between end points. This section presents a rigorous definition and sufficient statistics = for these attributes. 4.1. Attributes related to IP Packet Header=20 The following attributes are obtained directly from IP packet header = belonging to a flow: =20 o IP Version Number=20 o Source Address=20 o Destination Address=20 o Protocol Type=20 o TOS (for version 4)=20 o Flow Label (for version 6)=20 o DSCP (if DiffServ is supported)=20 4.2. Attributes Related to Measurement=20 The following attributes relates to measurements and measuring = methodology: o Packet Counter=20 o Dropped Packet Counter=20 o Byte Counter=20 o Timestamp of the First Packet Observed=20 o Timestamp of the Last Packet Observed=20 o Timeout Indication=20 o Sampling Method=20 o Sampling Parameters=20 4.3. Attributes Related to Flow Definition=20 The following attributes relates to IP flow definitions. o Incoming Interface=20 o Outgoing Interface=20 o Packet Treatment=20 o Unique ID of the Observation Point=20 o Unique ID of the Measuring Device=20 4.4. Attributes related to Upper Layers=20 The following attributes provides information of upper layer protocols. o Source Port Address=20 o MPLS Label (if MPLS is supported)=20 4.5. IPFIX Template=20 The IPFIX system MUST support efficient exporting of IP flow = information. This can be achieved by negotiating a set of IPFIX = Templates for an IPFIX session before actual IP flow information is = exported. A template defines the structure of an IPFIX user message = payload by describing the data type, meaning, and location of the = fields in the payload. By agreeing on IPFIX templates, IPFIX end-points = understand how to process IPFIX user messages. As a result, an = exporting device only needs to export actual flow information without = attaching any descriptors of the attributes; this reduces the amount of = bytes sent over communication links. A template is an ordered list of keys. A key specifies an attribute = that a meter entity MAY export. The specification MUST consist of the = description and the data type of the attribute. (e.g. 'Number of Sent = Bytes' can be a key that is a 32 bit unsigned integer) An exporting = device typically defines keys. Based on the IPFIX information model, a = set of IPFIX standard keys can be defined. 4.5.1. Template Negotiation=20 During the initial setup of an IPFIX session, template negotiation = procedures SHOULD be carried out. It would allow all the IPFIX = end-points to synchronize on a set of templates that will be used = during IP flow information export. At any time, the exporter MAY send out the template to the collectors. At any time, if a collector needs template information, it MAY send a = request to the exporter for template information. The exporter MUST be = able to accept the query and send the template to the collector. For = security reasons, the exporter MAY require previous knowledge of the = collector. 5. Flow Export Structure The general format of flow export packet is as follows: +-------+-------------------------------------------------------+ |Flow | +----------------+ +---------------+ +--------------+ | |Header | | Flow Set | | Flow Set | | Flow set | | | | +----------------+ +---------------+ +--------------+ | +-------+-------------------------------------------------------+ 5.1. Flow Header The flow header contains the export packet level information and some = information pertaining to the exporter itself. The flow header format = is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sysUpTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unix Secs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.1. Fields Version Number: The version number of the flow export protocol on the exporter side. = Both control and data records exported from the exporter are = self-describing. The collector can thus selectively choose to collect = the information from the export records regardless of the version. Note = that the packet header format has been kept similar the one developed = by the different versions of NetFlow defined by Cisco Systems, for = backward compatibility. The version field for this version of IPFIX is = 0x0009. Flags: Flags indicate the packet type and other attributes associated with the = packet. The format of flags is as follows: 15 1 0 +----------------------------------------------------+--------+ | |Control/| | Reserved |Data / | | |Both | +----------------------------------------------------+--------+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Flags |*|*| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ** Control/Data/Both Control/Data/Both: Flag to indicate whether the export packet is control/data/both. When = separate data stream is used, the exporter MUST set the flags to = indicate whether the stream type is control and data. SysUpTime: Time in milliseconds since this device was first booted. Unix Secs: Seconds since 0000 UTC 1970 Sequence Number: Exporter generated number which uniquely identifies a packet. The = sequence number increments for subsequent export packets. A separate = sequence number is maintained for control and export data packets if = control and data are send in separate packets. Source ID: Unique identifier per observation domain. 5.2. Template and Template Flowsets Templates are used to completely identify the structure and semantics = of particular information that needs to be communicated from the = exporter to the collector. Each template is uniquely identified by a = Template ID. The Template ID is a 16 bit identifier. A block of = templates from <0-255> are reserved for sending some of the control = information. The rest of the template IDs can be used by the exporter = to define the templates for the various flow types defined within the = exporter. A Template within an export packet is called as a template = record. A Template Flowset is a collection of one or more template = records which have been grouped together in an export packet. The = Flowset ID of a template flowset maps to a particular template format. 5.3. Categories of Template Flowset As explained in the terminology section, a flowset is a collection of = records with a similar template format in an export packet. Flowset ID = shares the same number space as a template ID. Template IDs <0-255> are = reserved as mentioned above and these are used by Flowset IDs to send = Template Flowsets of different formats. All of the Templates are sent = over the control stream. The different template formats being used are: 5.3.1. Case A, Template for Flow Record Definition The common examples of this case are templates for exported flow = records, and templates for flow related statistics or errors in the = exporter. Example of statistics information: total numbers of flows. = The format of the Template Flowset for this case is described below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowSet ID =3D 0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 1 | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1 | Field Length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2 | Field Length 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type N | Field Length N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID 2 | Field Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 1 | Field Length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type 2 | Field Length 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field Type M | Field Length M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FlowSet ID: Template flowset of this structure has a FlowSet ID of 0. Length: Total length of this FlowSet including the Flowset ID and the Length = field itself. Since an individual Template FlowSet MAY contain multiple = Template IDs (as illustrated above), the Length value will be used to = determine the position of the next FlowSet. Template ID: A unique ID per observation domain that defines the type of the record. = Template IDs 0-255 are reserved for special uses. Templates that = define Flow Record formats begin numbering at 256. Field Count: Number of fields in this Template Record. Since a Template Flowset MAY = contain multiple Template Records, this field allows the collector to = determine the end of the current Template Record and the start of the = next. Field Type: A numeric value that represents the type of the field. The possible = values of this field are described in the information model section. Field Length: The length of the above defined field, in bytes. See the information = model section for the field length. Note that the reason why we need the Field Length, even if this one is = fixed in the Information Model is because a collector MUST be able to = decode flow records, even if it doesn't know the semantics of certain = field types within the flow records. 5.3.2. Case B, Template for Method Description This case describes the format for exported configuration information. Each of the configuration templates within this flowset = describes : * List of methods that define the Selection Criteria and the parameters = for each method. * Observation Point and its description. One thing to note here is that instead of template ID, each = configuration template is associated with an Observation ID. The = observation ID uniquely identifies a {, Observation = Point}. At the same Observation point, multiple methods could be = adopted for packet measurement. As mentioned in section 3.1, for the = full interpretation of the flows from a metering process, the = associated {, Observation Point} associated with each flow = record is required. This can be achieved by sending Observation ID as = one of the fields in each of the flow records. In such a case the = template for flow records (see section 5.3.1) would define Observation = ID as one of the field types. Example: The exporter could be collecting the IPV4 packets that pass through an = observation point at a sampling rate of 1 in 100 while the IPV6 packets = that pass through the same observation point are collected at a = sampling rate of 1 in 200. The number space of Observation ID is = different from that of the Template ID. Each time a configuration = change happens w.r.t {, Observation Point}, a new = Observation ID is generated. The rate of configuration changes within = an exporter could range from very infrequent to very frequent. To take = care of the frequent cases, Observation ID is assigned a 32-bit = quantity. The following diagram shows the Template format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowSet ID =3D 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method Id 1 | Parameter Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type 1 | Parameter Length 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Value (Padded to nearest 4 bytes) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type K | Parameter Length K | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Value (Padded to nearest 4 bytes) | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method Id 2 | Parameter Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Point ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-element Count | Sub-element Type 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-element Length 1 | Sub-element Value 1 (Padded | | | to nearest 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-element Length M | Sub-element Value M (Padded | | | to nearest 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FlowSet ID: Template flowset of this structure has a FlowSet ID of 1. Length: Total = length of this FlowSet including the Flowset ID and Length field. Observation ID: 32 bit identifier per {, Observation Point} tuple. Method Count: Number of methods used for selecting the packet. Parameter Count: The number of parameters for this method. Parameter Type: Type of the Parameter used by this method. Parameter Length: Length of the Parameter used by Parameter Type. Parameter Value: Configured value of the parameter Parameter Type. Observation Point ID: 32 bit identifier that defines an observation point. Sub-element Count: Number of sub-elements that form the observation point. Sub-element Type: Type of one sub-element. Sub-element Length: Length of one sub-element represented by Sub-element Type. Sub-element Value Value of the sub-element of type Sub-element Type. 5.3.3. Case C, Template for Dependencies If multiple methods are used in conjunction on the observation point, = in order to analyze the flow records, the collector SHOULD know the = dependency between the multiple methods used. At the same observation = point, multiple different sets of measurement could be carried out = simultaneously or independently to the packets. Depending on how these = sets of measurements are done, the interpretation of flow records vary. Example : Say packets passing through an observation point are filtered, using 2 = different filters. case 1: Filters are completely non-overlapping. Say the filters are set on the = destination IP prefix. The first filter F1 masks and matches the = destination prefix {1.0.0.0/8} and the second filter masks and matches = the destination prefix {2.0.0.0/8}. The result of applying these 2 = filters generates 2 different sets of flows which are completely = non-overlapping. The collector could sum up the counters of flows that = result from F1 and F2 to provide more aggregation. case 2: Overlapping which are predictable. Say one filter is set on the source = IP prefix and destination IP prefix and the other on the destination IP = address. The first filter F1 masks and matches the {source prefix =3D = 1.0.0.0/8, destination prefix =3D 2.0.0.0/8} and the second filter F2 = masks and matches {destination prefix =3D 2.0.0.0/8}. Whenever a packet = matches F1 it will necessarily match F2 also. The result is 2 different = sets of flows where the flows created by applying F1 are a subset of = that created by F2. case 3: Overlapping which are un-predictable. Say the filters are set on the = source IP prefix and destination IP prefix. The first filter F1 masks = and matches the {source prefix =3D 1.0.0.0/8, destination prefix =3D = 2.2.0.0/16} and the second filter F2 masks and matches {source prefix = =3D 1.1.0.0/16, destination prefix =3D 2.0.0.0/8}. A packet with = {source IP address =3D 1.2.3.4, destination IP address =3D 2.2.2.2} = matches F1 but not F2. A packet with {source IP address =3D 1.1.3.4, = destination IP address =3D 2.3.1.1} matches F2 and not F1. The result = of applying these 2 filters generates 2 different sets of flows, the = dependency between the two being unpredictable. Discovering the dependencies amongst the different methods at the = observation point is non-trivial job for the exporter. The exporter = will deduce the dependencies to the best of its capability and inform = the collector. If unknown, the dependency relationship will be set to = unpredictable. The exporter MAY implement and export this dependency = template. The format of the dependency template is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowSet ID =3D 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number Of Dependency | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dependency 1 | Number Of Observation IDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dependency ID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Id 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Id 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dependency 2 | Number Of Observation IDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dependency ID 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Id 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Observation Id 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FlowSet ID: Template flowset of this structure has a FlowSet ID of 2. Length: Total length of this FlowSet including the Flowset ID and Length field. Observation Point ID: 32 bit identifier that defines an observation point. Number Of Dependency: Number of dependency for this observation point. Dependency: Tells whether the set of templates that follow are dependent, = independent or unpredictable. As mentioned in section 5.3.2, {, observation point} is identified by the Observation ID. Number Of Observation IDs: Number of Observation IDs in the dependency set. Dependency ID: Each dependency set is identified by a 32 bit ID. Observation ID: An element of a dependent or independent set. 5.4. Template Export Management The exporter takes the following steps for template export: * Periodically sends the entire template information and configuration = information to the collector. This corresponds to the set of all = Template IDs along with their descriptions and the set of all = Observation IDs along with their descriptions. The periodic export = frequency SHOULD be configurable in the exporter. * Changes in the control information happens due to change in = configuration or change in the templates of export flow records. These = changes can affect one or more of: 1. Template of flow records. See 4.3.1 2. Templates of configuration information. See 4.3.2 3. Dependency templates. See 4.3.3 When the control information changes, only the set of differences in = the information at the granularity of a template need to be exported to = the collector. This is valid for case 1. and case 2. For case 1., a new Template ID is generated and the changed template = along with its description is sent to the collector. For case 2., a new = Observation ID is generated and the changed Observation ID along with = its description is sent to the collector. Case 2 may result in case 3 = also. For case 3., the entire set of dependency list is regenerated at = the exporter and sent to the collector. The set of differences MAY be = sent a configurable number of consecutive times. This configurable = parameter is recommended to be more than one in the case of the simple = export model. 5.5. Exporting exporter statistics and errors The statistics and errors from the exporter MAY be periodically = exported to the collector. The information model specifics for = statistics and errors will be defined in future phase. 5.6. Exporting Flow Records As previously mentioned, flow records can go through the same stream as = control information or through a different stream as per the = description in section 4.1 and 4.2. If data stream is different, it = would be identified by a different sequence number. In any case the = flags field of the flow export header MUST indicate that the packet has = only data flowsets (flag in the flow export header is set to "data") or = if it carries control and data flowsets (flag is set to "both"). Data = packets contain flow records corresponding to one or more template IDs. = Flow records that belong to the same template ID can be grouped = together to utilize the bandwidth better. A collection of one or more = flow records that have the same template ID is termed as a Data = Flowset. The Flowset ID of a data flowset is assigned the Template ID = to which all the records in this data flowset belong to. The collector = uses this Flowset ID to interpret the data contained within the flow = records. A data flowset cannot be split across multiple flow record = packets. The format of the Data Flowset is described below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowSet ID =3D Template ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1 - Field Value 1 | Record 1 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2 - Field Value 1 | Record 2 - Field Value 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2 - Field Value 3 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 3 - Field Value 1 | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. Information Elements All element descriptions contain the following information to help put = it in the template FlowSet ID =3D Template ID Template ID corresponding to the flow records in the flowset. Field Type: This is the type of element the field is. All values are defined in = the TEXTUAL CONVENTIONS in the IETF rfcs. For example, a source = address is defined as field defined IpAddress from SNMPv2-SMI (RFC = 1443). [This needs to be filled in on all the fields] Size: The size of the Data FlowSet including FlowSet ID and the Length . Record N - Field N The remainder of the Data FlowSet is a collection of field values. The Type and Length of the fields have been previously defined in the = Template Record referenced by the FlowSet ID/Template ID. The flow records contain the values for the fields defined by flow = type. 6.1. Packet Management This information contains the fields needed to manage the data packets = transmitted 6.1.1. Version Number [Need to expand more] Template ID: ### Field Type: ### Size: ### 6.1.2. FLOWS V#3 S#4 =20 Number of main cache flows Template ID: ### Field Type: ### Size: ### 6.2. IP Address Template ID: ### Field Type: ### Size: ### 6.2.1. Source Address=20 Source address associated with a flow. Addresses can be of any type as = described in RFC 1700 [note - we need a new reference here, 1700 has = been obsoleted] Template ID: ### Field Type: ### Size: ### 6.2.2. Destination Address=20 Destination address associated with a flow. same as above. Template ID: ### Field Type: ### Size: ### 6.2.3. NEXT_HOP_IP=20 Address of the next hop. address is defined the same as for Source = Address . Template ID: ### Field Type: ### Size: ### 6.3. Time Stamps 6.3.1. Time=20 The time (as a SNMPv2 TimeStamp [1443]) associated with the = status/statistics observed or other events. Template ID: ### Field Type: ### Size: ### 6.3.2. UTC Time=20 The time in seconds since 00:00:00 UTC, January 1, 1970 associated with = the status/statistics observed or other events. If both Time and = UTC_TIME are present, UTC Time takes precedence.=20 Template ID: ### Field Type: ### Size: ### 6.3.3. Delta Time=20 The number in 100ths of seconds over which the statistics were = observed. TYPE is 71 and format is: Template ID: ### Field Type: ### Size: ### 6.3.4. LAST_SWITCHED V#21 S#4 SysUptime at which the last packet of this flow was switched Template ID: ### Field Type: ### Size: ### 6.3.5. FIRST_SWITCHED V#22 S#4 SysUptime at which the first packet of this flow was switched [Need to expand more] Template ID: ### Field Type: ### Size: ### 6.4. Service Types 6.4.1. Class of Service=20 The class of service associated with a flow.=20 Class of Service Received Class of Service Transmitted =20 1. IPv4, CoS value is defined by ToS in RFC 791 2. IPv6, CoS value is defined by Traffic Class in RFC 2460 3. MPLS, CoS value is defined by Exp in RFC 3032 4. VLAN, CoS value is defined by user_priority in IEEE802.1q[802.1q] = and IEEE 802.1p[802.1p] =20 [Can more than one Class of Service can be present??? PAC] =20 Template ID: ### Field Type: ### Size: ### 6.4.2. TCP Control Bits=20 The TCP control bits seen for this flow. Note a 0 value for each bit = only indicates that the flag was not detected (i.e. it may have = occurred but was not detected by the reporting CCE). TCP Control Bits = are defined by RFC 793.=20 Template ID: ### Field Type: ### Size: ### 6.4.3. Protocol Identifier=20 e.g. TCP/UDP [ need an RFC reference here. PAC]=20 Template ID: ### Field Type: ### Size: ### 6.4.4. Source Exporter [ is that the right term?? PAC] Address=20 Source Exporter address is the address of the Exporter reporting the = flow, Address is same as is as shown for Source Address. This = information is used by applications to later correlate the = ingress/egress port with a specific Exporter. It is also used to = maintain the source Exporter information when there is an intermediate = proxy. For example, given the picture below: =20 SW1 -------- P1 ------ FAS1 ^ | SW2---------- | =20 Flows coming from SW1 and SW2 through proxy P1 would look to the = Collector [ is this the right term??? PAC] like the same Exporter = connection. With the Source Exporter in the message the original = Exporter address is maintained. Template ID: ### Field Type: ### Size: ### 6.5. Flow State=20 Flow State is the intended End State for the Flow. Flow state has one of the following meanings: Flow is inactive Flow is active Template ID: ### Field Type: ### Size: ### 6.6. Statistical Elements To be expanded 6.6.1. Byte Count=20 Contains the count of octets sent and received associated with the = identified flow.=20 The byte count can be for bytes received (towards source) or bytes = sent (towards destination) or both (bi-directional flow). The byte count can be a running counter and is the count from the = beginning of the flow establishment. The byte count can be a delta counter and is the count since the last = report for this flow. Template ID: ### Field Type: ### Size: ### 6.6.2. Packet Count=20 Contains the count of packets sent and received associated with the = identified flow.=20 The packet count can be for packets received (towards source) or = packets sent (towards destination) or both (bi-directional flow). The packet count can be a running counter and is the count from the = beginning of the flow establishment. The packet count can be a delta counter and is the count since the last = report for this flow. Template ID: ### Field Type: ### Size: ### 6.6.3. Dropped Byte Count=20 Contains the count of octets dropped at the observation point = associated with the identified flow.=20 The dropped byte count can be a running counter and is the count from = the beginning of the flow establishment. The byte count can be a delta counter and is the count since the last = report for this flow. Template ID: ### Field Type: ### Size: ### 6.6.4. Dropped Packet Count=20 Contains the count of packets dropped at the observation point = associated with the identified flow.=20 The dropped packet count can be a running counter and is the count from = the beginning of the flow establishment. The dropped packet count can be a delta counter and is the count since = the last report for this flow. Template ID: ### Field Type: ### Size: ### 6.6.5. IPM_DPKTS V#19 S#4 Packet count for IP Multicast Template ID: ### Field Type: ### Size: ### 6.6.6. IPM_DOCTETS V#20 S#4 Octet (byte) count for IP Multicast Template ID: ### Field Type: ### Size: ### 6.7. Port Information To be added Template ID: ### Field Type: ### Size: ### 6.7.1. Source Port=20 This information element is used to report UDP source port [see RFC = 768] or TCP source port [see RFC 793]. Template ID: ### Field Type: ### Size: ### 6.7.2. Destination Port=20 This information element is used to report UDP destination port [see = RFC 768] or TCP destination port [see RFC 793]. Template ID: ### Field Type: ### Size: ### 6.8. Autonomous System (AS) To be added Template ID: ### Field Type: ### Size: ### 6.8.1. Source AS=20 The Autonomous System (AS) numbers for the source address associated = with a flow. Autonomous System (AS) number is defined by RFC 1930 and = RFC 1771 (BGP-4): Template ID: ### Field Type: ### Size: ### 6.8.2. Destination AS=20 The Autonomous System (AS) numbers for the destination address = associated wit a flow. Autonomous System (AS) number is defined by RFC = 1930 and RFC 1771 (BGP-4). Template ID: ### Field Type: ### Size: ### 6.8.3. Next Hop AS=20 The Autonomous System (AS) numbers for the next hop IP. Autonomous = System (AS) number is defined by RFC 1930 and RFC 1771 (BGP-4). Template ID: ### Field Type: ### Size: ### 6.9. IfIndexes and Interfaces To be added Template ID: ### Field Type: ### Size: ### 6.9.1. Ingress Port=20 The ingress ifIndex for the flow is provided in this information = element. ifIndex is defined by RFC 2233. Template ID: ### Field Type: ### Size: ### 6.9.2. Egress Port=20 The egress ifIndex for the flow is provided in this information = element. ifIndex is defined by RFC 2233. Template ID: ### Field Type: ### Size: ### 6.9.3. Egress ATM Subinterface The egress vpi/vci for the flow is provided in this Information = element. vpi/vci id defined by the ATM Forum UNI 3.1 specification: Template ID: ### Field Type: ### Size: ### 6.9.4. EGRESS_FRAME_RELAY_SUBINTERFACE=20 The egress DLCI for the flow is provided in this Information element. = ITU Q.922 defines the DLCI range. The frDlcmiState is defined in RFC = 2115 and defines the specific values of the DLCI. Template ID: ### Field Type: ### Size: ### 6.10. NetMasks 6.10.1. Source Address Netmask=20 The number of bits in the CIDR netmask, as defined in RFC 1519, for the = source address. Template ID: ### Field Type: ### Size: ### 6.10.2. Destination Address Netmask=20 The CIDR netmask, as defined in RFC 1519, for the destination address.=20 Template ID: ### Field Type: ### Size: ### 6.11. BGP & Vlan ?s 6.11.1. Destination BGP Community=20 The BGP community number for the destination address. BGP community = number is defined by RFC 1997: Template ID: ### Field Type: ### Size: ### 6.11.2. Source BGP Community=20 The BGP community number for the source address.=20 Template ID: ### Field Type: ### Size: ### 6.11.3. BGP_NEXT_HOP V#18 S#4 =20 Next-hop router in the BGP Template ID: ### Field Type: ### Size: ### domain 6.11.4. Source VLAN ID=20 The Source VLAN ID associated with the flow. VLAN ID is defined by IEEE = standard 802.1q - 1998[802.1q].=20 [ Is this ultimate source VLAN or the source vlan of the port where the = packet came in? Or do we need a way to represent both? PAC] Template ID: ### Field Type: ### Size: ### 6.11.5. Destination VLAN ID=20 The destination VLAN ID associated with the flow. VLAN ID is defined by = IEEE standard 802.1q - 1998[802.1q]. Template ID: ### Field Type: ### Size: ### =20 [ Is this ultimate destination VLAN or the destination vlan of the port = where the packet went out? Or do we need a way to represent both? PAC] 6.12. Virtual Information 6.12.1. Source Virtual Address=20 An Exporter may be involved in redirecting flows. This information = element captures information needed for proper accounting of redirected = flows. The Source Virtual information element contains the source = address of the flow as transmitted by the Exporter. It is generally = different than the source address information element, which contains = the address of the actual source of the message. A type field would contain the type of translation performed on the = source address. The following types are currently available: 1. - NAT 2. - LSNAT 3. - Web Cache The address is defined the same as for Source Address. Template ID: ### Field Type: ### Size: ### 6.12.2. Source Virtual Port=20 A CCE may be involved in redirecting flows. This information element = captures information needed for proper accounting of redirected flows. = The Source Virtual port information element contains the source port of = the flow as transmitted by the CCE. It may be different than the source = port information element, which contains the port of the actual source = of the flow. An IP Protocol field is present and is defined by the IP = protocol spec [RFC 791] (e.g. TCP/UDP). The fields indicate how to = interpret the port value field. A type field contains the type of translation performed on the source = port. The following types are currently available: 1. - NAT 2. - LSNAT 3. - Web Cache Template ID: ### Field Type: ### Size: ### 6.12.3. Destination Virtual Address=20 The Destination Virtual information element contains the destination = address of the flow as received by the Exporter. It is generally = different than the destination port number, which contains the actual = destination address of the flow. Template ID: ### Field Type: ### Size: ### 6.12.4. Destination Virtual Port=20 The Destination Virtual port information element contains the = destination port of the flow as received by the Exporter. It may be = different than the destination port recorded in the destination port, = which contains the actual destination port of the flow. Template ID: ### Field Type: ### Size: ### 6.13. Vendor Specific=20 Vendors may add their own information to the protocol. Information = contained in this information element is vendor specific. OID and OID = Value are defined by ITU X.680.X683 (1997) and are encoded as defined = by ITU X.690.691(1997). This information element MUST not contain any = information which cannot be safely ignored by the Exporter or = Collector. If multiple Vendor Specific information element's with the = same OID occur, then the vendor defines semantics of ordering. Template ID: ### Field Type: ### Size: ### 6.14. Misc. Information Elements To be added Template ID: ### Field Type: ### Size: ### 6.14.1. Flow Label=20 The Flow Label information element contains the IPV6 Flow Label = information as defined by RFC 2460.=20 Template ID: ### Field Type: ### Size: ### 6.14.2. Flow Direction V#54 S#1 The direction of the flow observed at the observation point. If the = observation point is a set of interface(s) the direction is w.r.t the = wire. Template ID: ### Field Type: ### Size: ### 6.14.3. Fragment ID=20 The fragment ID associated with the flow. RFC 791 and RFC 2460 define = fragment ID. Template ID: ### Field Type: ### Size: ### 6.14.4. Internal queue priority A switch may map several of its internal priority queues into a = Premium, High, Medium or Low category. [ this sections needs more work] Template ID: ### Field Type: ### Size: ### 6.14.5. Global VPN Identifier=20 The VPN identifier associated with the flow as defined in RFC 2685. Template ID: ### Field Type: ### Size: ### 6.14.6. ICMP_TYPE V#32 S#1 ICMP Packet Type. This is reported as (ICMP Type * 256) + ICMP code [We need a spec reference.] Template ID: ### Field Type: ### Size: ### 6.14.7. IGMP_TYPE V#33 S#1 IGMP Packet Type [We need a spec reference.] Template ID: ### Field Type: ### Size: ### 6.15. Sampling 6.15.1. SAMPLING_INTERVAL V#34 S#1 When using Sampling, the rate at which packets is sampled. For = example, a value of 100 indicates that one of every hundred packets is = sampled. Template ID: ### Field Type: ### Size: ### 6.15.2. SAMPLING_ALGO V#35 S#1 The type of algorithm used for sampling data. = Currently, the only sampling algorithm defined is: 0x02 packet-sampling Template ID: ### Field Type: ### Size: ### 6.15.3. FLOW_ACTIVE_TIMEOUT V#36 S#2 Timeout value for active flow entries in the cache. Template ID: ### Field Type: ### Size: ### 6.15.4. FLOW_INACTIVE_TIMEOUT V#37 S#2 Timeout value for inactive flow entries in the cache. Template ID: ### Field Type: ### Size: ### 7. References 3. J. Quittek ,et al.,? Requirements for IP Flow Information Export ?, = (work in progress) ,Internet Draft, Internet Engineering Task Force, = , November 2001 =20 4. M. Wood ,et al.,? Intrusion Detection Message Exchange = Requirements?,(work in progress), Internet Draft, Internet Engineering = Task Force, draft-ietf-idwg-requirements-06,February 2002. 5. Daniel O. Awduche, et. al.,? Overview and Principles of Internet = Traffic Engineering?, (work in progress), Internet Draft, Internet = Engineering Task Force, draft-ietf-tewg-principles-02.txt, May 2002=20 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions,=20 http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-adelaide/pp-di= st/ [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric = for IPPM,=20 , November 2001 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss = Metric for=20 IPPM, September 1999 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application = of Sampling Methodologies to Network Traffic Characterization, Proceedings of ACM = SIGCOMM'93,=20 San Francisco, CA, USA, September 13 - 17, 1993 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, = John G. CLEARY:=20 Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay = Variation on=20 the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for = Direct Traffic=20 Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, = August 28 -=20 September 1, 2000. [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric = for IPPM,=20 Request for Comments: 2679, September 1999 =20 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation of = Building Blocks=20 for Passive One-way-delay Measurements, Proceedings of Passive and = Active Measurement=20 Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 (PAM = 2001)=20 [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture and = framework," work in progress. October 2001. [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address = Translator (NAT) Terminology and Considerations", RFC 2663, August = 1999. [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network = Address Translator (Traditional NAT)", RFC 3022, January 2001. [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider = Provisioned Virtual Private Networks ", work in progress, = , January 2002.=20 [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft = , July 2001. [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and = W. Weiss, "An Architecture for Differentiated Services", RFC 2475, = December 1998. [1] Requirements for IP Flow Export, = [2] K.Zhang, et al., "Common Reliable Accounting for Network Element = (CRANE)", , February 2002 [3] G. Sadasivan, et al., "Flow Export Architecture", = , January 2002 =20 [4] Carlson, James, "PPP Design, Implementation and Debugging", Second = Edition . 8. Acknowledgements We like to thank all the people contributing to the requirements discussion on the mailing list, and the design teams for a lot of = valuable comments. George Carle Tanja Zseby Paul Calato Dave Plonka Kevin Zhang KC Norseth Phill Richards Will Eatherton Benoit Claise Ganesh Sadasivan Vamsi Valluri Ram Gopal Jc Martin Carter Bullard Juergen Quittek Reinaldo Penno Nevil Brownlee Simon Leinen 9. Author's Addresses Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Paul Calato Riverstone Networks, Inc. 5200 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 (603) 557-6913 Email: calato@riverstonenet.com Ganesh Sadasivan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1 (408) 527-0251 Email: gsadasiv@cisco.com Ram Gopal Nokia=20 5 Wayside Road,=20 Burlington, MA 01803 Phone:+1 781 993 3685 Email: ram.gopal@nokia.com Man Li=20 Nokia=20 5 Wayside Road,=20 Burlington, MA 01803=20 Phone: +1 781 993 3923=20 Email: man.m.li@nokia.com=20 K.C. Norseth Enterasys Networks 2691 S. Decker Lake Lane Salt Lake City, Utah 84119 Phone: +1 801 887 9823 Email: knorseth@enterasys.com Reinaldo Penno Nortel Networks, Inc.=20 2305 Mission College Boulevard Building SC9-B1240 =20 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com=20 Juergen Quittek NEC Europe Ltd. Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Kevin Zhang =20 XACCT Technologies, Inc.=20 2900 Lakeside Drive=20 Santa Clara, CA 95054=20 Phone +1 301 992 4697=20 Email: kevin.zhang@xacct.com Tanja Zseby GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 Email: zseby@fokus.gmd.de 10. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This = document and translations of it may be copied and furnished to others, = and derivative works that comment on or otherwise explain it or assist = in its implementation may be prepared, copied, published and = distributed, in whole or in part, without restriction of any kind, = provided that the above copyright notice and this paragraph are = included on all such copies and derivative works. However, this = document itself may not be modified in any way, such as by removing the = copyright notice or references to the Internet Society or other = Internet organizations, except as needed for the purpose of developing = Internet standards in which case the procedures for copyrights defined = in the Internet Standards process must be followed, or as required to = translate it into. 11. Stuff to Add We should have as example of how the works. A good example is what a = NetFlow v5 packet looks like. Need to add the health check query dialog between the collector and the = exporter. 12. End of stuff to add =20 IPFIX Information Data Model February, 2002 =20 IPFIX Design WG Expires August, 2002 [Page 3] IPFIX Design Team Expires July 2002 [Page 1] ------_=_NextPart_000_01C1B65A.2A969CB0 Content-Type: text/plain; name="draft-ietf-ipfix-architecture-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ipfix-architecture-00.txt" Content-Transfer-Encoding: quoted-printable IPFIX working group Internet Draft draft-design-team-ipfix-Architecture-00.txt Expires: August 2002 =0DBenoit Claise Cisco Systems P. Calato Riverstone Networks Inc Ram Gopal Man Li Nokia =20 K.C. Norseth Enterasys Networks Reinaldo Penno NortelNetworks J. Quittek NEC Europe Ltd. Ganesh Sadasivan Cisco Systems, Inc. Kevin Zhang XACCT Technologies Tanja Zseby FhI FOKUS=0D=0D February 2002=0D IPFIX Architecture Architecture Model for IP Flow Information Export draft-design-team-ipfix-architecture-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all = provisions of Section 10 of RFC2026 [1].=20 Internet-Drafts are working documents of the Internet Engineering Task = Force (IETF), its areas, and its working groups. Note that other groups = may also distribute working documents as Internet-Drafts. = Internet-Drafts are draft documents valid for a maximum of six months = and may be updated, replaced, or obsoleted by other documents at any = time. It is inappropriate to use Internet- Drafts as reference material = or to cite them other than as "work in progress."=20 The list of current Internet-Drafts can be accessed at = http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at = http://www.ietf.org/shadow.html. Abstract This document defines architecture for scalable monitoring, measuring = and exporting IP flow information to collectors. =20 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are to be interpreted as described in RFC-2119 [1]. 1. Introduction 3 2. Scope 3 3. Terminology 4 4. IPFIX reference Model 5 4.1. Exporter 6 4.2. IPFIX protocol 6 4.3. Collector 6 4.4. Relationship to RTFM 7 4.5. Applications 7 5. IPFIX Deployment Scenarios 7 5.1. Exporting Interface over LAN 7 5.2. Exporting Interface over WAN 8 6. Flow Type and Flow Definition 9 6.1. Observation Point 10 6.2. Unidirectional and Bidirectional Flows 11 7. Metering Process Functions 11 7.1. Flow Classification 11 7.2. Selection Criteria Of Packets 12 7.2.1. Function on properties that determines a flow type (Fi) 12 7.2.2. Sampling packets on a flow type (Si) 12 7.3. Selection Criteria of flows for export 12 7.4. Flow Expiration 13 8. Architectural Requirements (BLANK) 13 8.1. Recovery (BLANK) 13 8.2. Performance (BLANK) 13 8.3. Security 13 8.4. IPfix Considerations for Middleboxes 14 8.4.1. Firewall 14 8.4.2. Network Address Translation 15 8.4.3. Traffic Conditioners 16 8.4.4. Tunneling 17 8.4.5. VPNs 18 8.5. QoS Monitoring with IPFIX 20 8.5.1. Measurement of Round-trip-time (RTT) with IPFIX 20 8.5.2. Measurement of One-way-delay (OWD) with IPFIX 21 8.5.3. Measurement of Loss with IPFIX 21 8.5.4. Measurement of delay variation with IPFIX 21 8.5.5. Sampling for QoS Monitoring 21 9. IPFIX Protocol System 22 9.1. Capability Negotiation 22 9.1.1. Phase I Protocol and Protocol Management 23 9.1.2. Phase II 24 9.1.3. Renegotiation of Capabilities 26 9.1.4. Caching of Negotiated Parameters 26 10. Security Consideration 27 10.1. Data security. 27 10.1.1. No security 27 10.1.2. Authentication only 28 10.1.3. Encryption 28 10.2. IPFIX end point authentication 28 10.3. Denial of service (DoS) attack prevention 28 10.3.1. Network under attack 29 10.3.2. Generic DoS attack on the IPFIX system 29 10.3.3. IPFIX Specific DoS attack 29 11. Some Applications of IPFIX 29 11.1. IPFIX usage in Intrusion Detection 29 11.2. IPFIX and AAA 30 11.2.1. Connecting via an AAA client 31 11.2.2. Connecting via an Application Specific Module (ASM) 32 11.3. IPFIX usage in Traffic Engineering/Traffic Profiling 32 12. References 33 13. Acknowledgements 34 14. Author's Addresses 35 15. Full Copyright Statement 37 16. Stuff to Add 37 1. Introduction Many applications e.g., Intrusion detection, traffic engineering, = require the monitoring, measuring of IP traffic flows. It is hence = important to have a standard way of exporting information related to IP = flows. This document defines architecture for IP traffic flow = monitoring, measuring and exporting. It provides a high-level = description of the key components and their functions.=20 2. Scope This document defines architecture for IPFIX[3]. Specifically, this = document=20 o Describes the key architectural components of IPFIX. o Describes the external dependency and identifies those interfaces = explicitly.=20 o Defines architectural requirements, e.g., Recovery, Security, etc. o Describes the required mechanisms to interoperate with other = protocol/architecture this may includes AAA or Diameter or Intrusion = Detection system. o Identifies a minimal set of applications for IPFIX. 3. Terminology MOVED to the Requirements draft 4. IPFIX reference Model Figure 1 shows the reference model for IPFIX. The blocks shown are = logical entities. The functionalities of these components remain the = same regardless of their placements inside a network.=20 The main purpose of the IPFIX subsystems is to effectively communicate = the information model using IPFIX. The information model is composed of = set of attributes that are of interest to the applications. Each = application may require a subset of the parameters specified in the = information model. The information model is generalized and = communicated between IPFIX endpoints as Templates for operational = purpose. +------------+ +-------------+ |Application | | Application | | (1) |?. | (n) | +------------+ +-------------+ || || = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 || || || +---------------+---------+ || | | | || | Exporter(1) | IPFIX |<=3D+ || | | | || || +---------------+---------+ || || . || || . || || +---------------+---------+ || +-------+-----------+ | | | || | | | | Exporter(n) | IPFIX |<=3D=3D=3D=3D=3D>| IPFIX | = Collector | | | | || | | | +---------------+---------+ || +-------+-----------+ || ||=20 || || = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ = || +-------+-------------+ || || || | | | || || =3D=3D=3D=3D>| IPFIX | = Collector | +------------+ +-------------+ | |(Application)| |Observation | | Observation | +-------+-------------+ | Point(1) |?. | Point (n) | +------------+ +-------------+ Figure 1: IPFIX Reference Model 4.1. Exporter The exporter is a subsystem that interacts with one or more observation = points. The functions of an exporter may include: * Performing Flow ID management (capabilities negotiation)that includes = the creation of tags to refer a flow between Exporter and the Collector = for configuration and statistical purpose. * Assembling collected information into the right format to be carried = by the IPFIX protocol * Configuring observation points with flow monitoring rules * Measuring, aggregating and exporting IP Flow information to the = respective collectors. * May perform appropriate middle-box functions to translate the flow = information.=20 =20 The information collected can be either pushed periodically to the = collector or pulled by the collector on demand. 4.2. IPFIX protocol IPFIX protocol may run on top of either Transport or IP layer. If the = underlying network is not reliable, it is the responsibility of the = IPFIX protocol to perform transport level functions. It is recommended = to use reliable transport protocols like SCTP or TCP. The functions of IPFIX protocol include: * Reliably and securely transporting application level information = between an exporter and a collector ( security functions are leveraged = by using underlying security protocols) * Maintaining the communication links between IPFIX endpoints. = Supporting fail-over and fail-back procedures, and performing load = balancing if required. =20 4.3. Collector Collector is a subsystem that interacts with one or more Exporters. The = functions of the collector may include: * Performing Flow ID management (capabilities negotiation)that includes = the creation of tags to refer a flow between Exporter and the Collector = for configuration and statistical purpose. * Requesting an exporter sub-system to collect IP flows. * Communicating with different applications.=20 * Maintaining a repository of IP flow statistics=20 * Aggregating application level requests and form a template that will = suitable for exporter. =20 The application(s) and the collector may be tightly coupled in one = system. They may also be logically or physically a separate subsystem = from the application(s). In which case, the communication between them = is beyond the scope of IPFIX. 4.4. Relationship to RTFM To be filled out by Nevil Brownlee 4.5. Applications IPFIX applications may be Billing, Network Surveillance, and Intrusion = Detection sub-systems. etc.[3]. An application requests the Collector = to gather the relevant IP Flow information. =20 5. IPFIX Deployment Scenarios IPFIX exporting devices may vary greatly in their core functionality. = At one hand, a core router needs to support high-speed interfaces and = traffic throughput; it emphasizes on forwarding IP traffic quickly and = may not be able to perform extensive measurement on IP flow. It is also = likely to export high volume of IP flow information to external = systems. On the other hand, a measurement probe or an access device is = capable of providing more detailed information about IP flows and = performing complex on-device processing. Consequently, it may only = export low volume of IP flow information.=20 =20 Given the diversity of exporting devices, two deployment scenarios are = described. These scenarios only serve as examples for IPFIX system = design and deployment. =20 5.1. Exporting Interface over LAN=20 The following figure illustrates the scenarios where an exporting=20 device connects to the collecting devices over LAN.=20 +----------+ +----------+ +------------+ |Exporting | |Collection|<=3D=3D>| | |Device | |Device 1 | |Applications| +----------+ +----------+ |e.g. | ^ | ^ | |usage | | v | v |accounting, | --------------------------------------- |traffic | LAN |profiling, | --------------------------------------- |traffic | ^ | |engineering,| | v |QoS | +----------+ |Monitoring | = |Collection|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|etc= . | |Device 2 | | | +----------+ +------------+ This scenario is suitable for collecting information from core=20 routers. As the volume of exported data is typically high, LAN can=20 provide adequate bandwidth and introduce small latency to meet data = exporting requirement. =20 5.2. Exporting Interface over WAN=20 The following figure illustrates the scenario where an exporting=20 device connects to the collecting devices over WAN.=20 +----------+ |Collection| +------------+ |Device 1 |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| = | +----------+ |Applications| ^ |e.g. | | |usage | +----------+ +--|-------+ |accounting, | |Exporting |<--------|--- | |traffic | |Device |<--------|--------- | |profiling, | +----------+ | WAN | | |traffic | | | | |engineering,| | | | |QoS | +--------|-+ |Monitoring | | |etc. | v | | +----------+ | | |Collection|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| = | |Device 2 | +------------+ +----------+ =20 This scenario maybe used to collect information from probes or access = routers. It is critical that a congestion aware transport protocol = (e.g. TCP, SCTP) is used. 6. Flow Type and Flow Definition As defined in the requirement draft [1], "A flow is a set of packets passing an observation point in the network = during a certain time interval. All packets belonging to a particular = flow have a set of common properties derived from the data contained in = the packet and from the packet treatment at the observation point." In this draft we define the flow more specifically. A flow is defined = as a set of packets passing an observation point in the network during = a certain time interval. All packets belonging to a particular flow = have a set of common properties. Each property is defined as the = result of applying a function to the values of: a. one or more of packet header fields (e.g. destination IP address) b. one or more properties of the packet itself (e.g. packet length) c. one or more of fields derived from packet treatment (e.g. AS number) A packet is defined to belong to a flow if it matches all the defined = properties of the flow. Flows can be defined in multiple ways. Some = examples are: Example 1: To create flows, we define the different fields to distinguish flows. = The different combination of the field values creates unique flows. If = the keys are defined as {source IP address, destination IP address, = TOS}, then all of 1. {192.1.40.1, 171.6.23.5, 4} 2. {192.1.40.23, 171.6.23.67, 4} 3. {192.1.40.23, 171.6.23.67, 2} 4. {198.20.9.200, 171.6.23.67, 4} are different flows. Example 2: To create flows, we can apply a match function to all the packets that = pass through an observation point, in order to aggregate some values. = This could be done by defining the keys as {source IP address, = destination IP address, TOS} like in the example 1, and applying the = function which masks the least significant 8 bits of the source IP = address and destination IP address (i.e. the resultant is a /24 = address). The 4 flows from example 1 would now be aggregated into 3 = flows, by merging the flows 1. and 2. into a single flow. 1. {192.1.40.0/24, 171.6.23.0/24, 4} 2. {192.1.40.0/24, 171.6.23.0/24, 2} 3. {198.20.9.0/24, 171.6.23.0/24, 4} Example 3: To create flows, we can filter some field values on all packets that = pass the observation point, in order to select only certain flows. The = filter is defined by choosing fixed values for specific fields from the = packet. All the packets that go from a customer network 192.1.40.0/24 to = another customer network 171.6.23.0/24 with TOS value of 4 define a = flow. All other combinations don't define a flow and are not taken into = account. The 3 flows from example 2 would now be reduced to 1 flow, by = filtering away the second and the third flow. {192.1.40.0/24, = 171.6.23.0/24, 4}. The above example can be thought of as a function F takes as input = {source IP address, destination IP address, TOS}. The function selects = only the packets which satisfy all the 3 conditions which are: * mask the least significant 8 bits of source IP address, compare = against 192.1.40.0. * mask the least significant 8 bits of destination IP address, compare = against 171.6.23.0. * tos value equal to 4. Depending on the values of {source IP address, destination IP address, = TOS} of the different observed packets, the metering process function F = would choose/filter/aggregate different sets of packets, which would = create different flows. In other words, based on various combination = of values of {source IP address, destination IP address, TOS}, F(source = IP address, destination IP address, TOS) would results in the = definition of one or more flows. The function F is referred to as Flow = Type. 6.1. Observation Point For definition refer to section 1.2. A flow is uniquely defined by the = way it gets measured at an observation point. Example: The flow defined in the example 1 of section 2., can be used at 2 = different observation points 'a' and 'b' in 2 different ways. = Observation point 'a' measures the packets that match the flow = {192.1.40.0/8, 171.6.23.0/8, 4} at a sampling rate of 1 in 10 and 'b' = measures packets that match the same flow with a sampling rate of 1 in = 100. 6.2. Unidirectional and Bidirectional Flows A flow defined by the above terms is unidirectional. In case the = exporter has got the knowledge of the bi-directional flows and in case = the bi-directional information make sense, the exporter MAY choose to = export in the same Template/Flow Record, along with bidirectional = accounting information. This would save some bandwidth as the exporter = won't have to send two unidirectional flow records. [GANESH-2-11-02 ? Please expand more] =20 When the direction w.r.t wire is specified, then it can be further = categorized as uni/bi.. The direction however is optional and may not = be applicable in all the cases. 7. Metering Process Functions 7.1. Flow Classification The collector MUST be able to map the flow to the corresponding = property types defined by the flow type. This can be done only if the = collector has a mapping from flow type identifier (carried in each flow = record) to its actual structure. More details of how this can be = achieved are described in section 5.??? In addition the collector, when it receives the flow records, MAY need = the following interpreting the flow records further: a. Observation Point. b. Selection Criteria of Packets As mentioned in section 2.1, a flow record can be better analyzed if = the Observation Point from which it is measured is known. As such it is = recommended that the flow record carry the Observation Point = information along with the flow records when exported. In cases where = there is a single observation point or where the observation point = information is not relevant, the exporter MAY choose not to add this to = the flow records. 7.2. Selection Criteria Of Packets The measurement device MAY define rules so that only certain packets = within a flow can be chosen for measurement at an observation point. = This MAY be done by one of the two types of methods defined below or a = combination of them. A combination of each of these ways can be = adopted to select the packets .i.e. one can define a set of methods = {F1, S1, F2, S2, S3} executed in certain sequence at an observation = point to collect flows of a particular type. 7.2.1. Function on properties that determines a flow type (Fi) Packets that satisfy a function on the fields defined by the packet = header fields or fields obtained while doing the packet processing or = the properties of the packet itself. Example: Mask/Match of the fields that define a filter. The filter may be = defined as {Protocol =3D=3D TCP, Destination Port between 80 and 120}. = Multiple such filters could be used in any sequence to select packets. 7.2.2. Sampling packets on a flow type (Si) Packets that satisfy the sampling criteria for this flow type. Example: Sample every 100th packet that was received at an observation point and = collect the flow information for a particular flow type. choosing all = the packets is a special case where sampling rate is 1:1. 7.3. Selection Criteria of flows for export The measurement device MAY define additional rules so that only certain = flows records are picked up for export. This MAY be done by either one = of the two types of methods defined in 2.3.1 and 2.3.2 or a combination = of them. Example: The flow records which meet the following selection criteria are only = exported. 1. All flow records whose destination IP address matches {20.3.1.5}. 2. Every other (.i.e. sampling rate 1 in 2) flow record whose = destination IP address matches {160.0.1.30}. 7.4. Flow Expiration A flow is considered to be inactive if no packets of this flow has been = observed at the observation point for a given timeout interval. The = flow can be exported under the following conditions: 1. If the exporter can deduce the end of a flow, the exporter SHOULD = export the flow records when the end of the flow is detected. For = example: flow generated by TCP type of traffic where the FIN or RST = bits indicate the end of the flow 2. If the flow has been inactive for a certain period of time. This = inactivity timeout SHOULD be configurable. For example: flow generated = by UDP type of traffic. 3. For long aging flows, the exporter SHOULD export the flow records on = regular basis, in order to: a. report the flow records periodic accounting information to the = collector b. avoid counter wrapping This activity timeout SHOULD be configurable 4. If the exporter experiences resources constraints, a flow MAY be = prematurely expired (example: memory) 8. Architectural Requirements (BLANK) more to be written 8.1. Recovery (BLANK) more to be written 8.2. Performance (BLANK) more to be written 8.3. Security Refer Security Consideration section for details 8.4. IPFIX Considerations for Middleboxes A Middlebox is a network intermediate device that implements one or = more of the middlebox services. Policy based packet filtering (a.k.a. = firewall), Network address translation (NAT), Intrusion detection, Load = balancing, Policy based tunneling and IPsec security are all examples = of a middlebox function (or service). [MCFW]. For instance, a NAT = middlebox is a middlebox implementing NAT service and a firewall = middlebox is a middlebox implementing firewall service.=20 It is expected that the exporter in the IPFIX architecture will = probably implement some form of middlebox service given its ubiquity = today. Since some of these middlebox services might affect flow = exportation and how the collector interprets them, there is a need to = provide an analysis of these implications in relation to the IPFIX = architecture and a set of recommendations.=20 The following sections provide a non-exhaustive analysis of middlebox = services, its implications on the IPFIX architecture and a = corresponding set of recommendations. 8.4.1. Firewall Firewall is a policy based packet filtering middlebox function, = typically used for restricting access to/from specific devices and = applications. The policies are often termed Access Control Lists = (ACLs)[MCFW]. =20 The firewall middlebox service allows the exporter to explicitly drop = packets based on some administrative policy. In this case, the exporter = can take one of the following actions that will have a direct impact on = the information provided by the collector to the user. * Silently Discard In this case the packet is discarded and no flow information record is = sent to the collector. * Discard and export flow In this case the packet is discarded, and the flow information record = is sent to the collector. * Discard and export flow with discard notification In this case the packet is discarded, and the flow information record = is sent to the collector with an indication that the packet was = discarded. 8.4.2. Network Address Translation Network Address Translation is a method by which IP addresses are = mapped from one address realm to another, providing transparent routing = to end hosts. Transparent routing here refers to modifying end-node = addresses en-route and maintaining state for these updates so that when = a datagram leaves one realm and enters another, datagrams pertaining to = a session are forwarded to the right end-host in either realm = [NAT-TERM].=20 From an exporter (middlebox) perspective, a NAT is composed of two = flows, one from the client to the NAT middlebox and another from the = NAT middlebox to the destination. Based on this fact, the exporter has = several modes of operation, i.e., it can export the private realm flow, = the public realm, or both. This is further constrained by the flavor of = NAT implemented, meaning that in order for the exported information to = be useful for the collector, sometimes the associated flows on the two = realms need to be exported in the same flow record.=20 Although there are many flavors of address translation that lend = themselves to different applications, this section will only address = the IPFIX architecture implications of traditional NAT, bi-directional = NAT and twice NAT. 8.4.2.1. Traditional NAT Traditional NAT would allow hosts within a private network to = transparently access hosts in the external network, in most cases. In a = traditional NAT, sessions are unidirectional, outbound from the private = network. This is in contrast with bi-directional NAT, which permits = sessions in both inbound and outbound directions. A detailed = description of traditional NAT may be found in section [NAT-TERM]. If the exporter is providing traditional NAT service and only the = private realm flow is exported, only destination based information can = be inferred from the collector. The reason for this is twofold. First, = the collector will not be able to find the reverse flow (when = applicable) associated with a private realm flow record, and second is = that in the more general scenario the collector can be connected to = several exporters providing NAT service and there might be overlapping = private realm addresses between the networks connected to these = exporters. In a traditional NAT scenario the exporter SHOULD export private and = public realm information in the same flow record or provide the = collector with a unique key to associate the two if exported on = different flow records. 8.4.2.2. Bi-Directional NAT With a bi-directional NAT, sessions can be initiated from hosts in the = public network as well as the private network. Private network = addresses are bound to globally unique addresses, statically or = dynamically as connections are established in either direction. = Detailed description of Bi-Directional may be found in section = [NAT-TERM]. 8.4.2.3. Twice NAT Twice NAT is a variation of NAT in that both the source and destination = addresses are modified by NAT as a datagram crosses address realms. = This is in contrast to Traditional-NAT and Bi-Directional NAT, where = only one of the addresses (either source or destination) is translated. = Note, there is no such term as 'Once-NAT'. Detailed description of = Bi-Directional may be found in section [NAT-TERM]. In the case of twice NAT the exporter MUST export private and public = realm information in the same flow record or provide the collector with = a unique key to associate the two if exported on different flow = records. 8.4.3. Traffic Conditioners A traffic conditioner may contain the following elements: meter, = marker, shaper, and dropper. A traffic stream is selected by a = classifier, which steers the packets to a logical instance of a traffic = conditioner[DIFF-ARCH]. From an IPFIX architecture perspective we are going to address marking, = shaping and dropping services. 8.4.3.1. Marking=20 Diffserv packet markers set the DS field of a packet to a particular = codepoint, adding the marked packet to a particular DS behavior = aggregate. The marker may be configured to mark all packets which are = steered to it to a single codepoint, or may be configured to mark a = packet to one of a set of codepoints used to select a PHB in a PHB = group, according to the state of a meter. When the marker changes the = codepoint in a packet it is said to have "re-marked" the packet = [DIFF-ARCH]. From and IPFIX architecture perspective, the exporter can take one of = the following actions when it needs to remark a packet. * Unmarked flow The exporter can export the flow before it was remarked. This mode of = operation is strongly discouraged. * Remarked flow The exporter can export the flow after it was remarked.=20 * Unmarked and remarked flow. The exporter can export the flow before and after it was remarked or = export the flow before it was remarked and an indication of what was = the DSCP after it was remarked.=20 8.4.3.2. Shapers Shapers delay some or all of the packets in a traffic stream in Order = to bring the stream into compliance with a traffic profile. A shaper = usually has a finite-size buffer, and packets may be discarded if there = is not sufficient buffer space to hold the delayed packets. For an IPFIX perspective, since the discard of a packet by a shaper is = not voluntary, no indication should be sent to the collector.=20 8.4.3.3. Droppers Droppers discard some or all of the packets in a traffic stream in = order to bring the stream into compliance with a traffic profile. This = process is known as "policing" the stream. Note that a dropper can be = implemented as a special case of a shaper by setting the shaper buffer = size to zero (or a few) packets. In a manner analogous to the middlebox firewall service, middlebox = policing services also allow the exporter to explicitly drop packets = based on some administrative policy.=20 The three possible export behaviors described for the firewall service = when a packet needs to be dropped are also applicable to here, i.e., = silent discard, discard and export flow, discard and export flow with = discard notification. 8.4.4. Tunneling The exporter can export the flows before and/or after they get = tunneled. In the later case the encapsulated flow information might not = be available due to confidentiality precautions such as those used by = IPsec, or due to the fact the exporter lacks the necessary intelligence = to inspect the encapsulated packet. Moreover, depending on where in the = network the exporter is located, it might only be able to export flows = associated with the tunnel, without visibility into the encapsulated = packet. Apart from what was said above, it should also be factor in the fact = that flows exported before they get tunneled, will provide information = about the private network sites, but not necessarily about the = backbone, since the route taken by the packet it's now know at that = point in time (and vice-versa). Tunnel terminates on exporter Tunnel initiates on exporter Exporter implements tunnel switching 8.4.5. VPNs The term "Virtual Private Network" (VPN) refers to the communication = between a set of sites, making use of a shared network infrastructure. = Multiple sites of a private network may therefore communicate via the = public infrastructure, in order to facilitate the operation of the = private network. The logical structure of the VPN, such as addressing, = topology, connectivity, reachability, and access control, is equivalent = to part of or all of a conventional private network using private = facilities [RFC2764] [VPN-2547BIS]. There are multiple flavors of VPNs, the one with more relevance to the = IPFIX architecture is the PE-based-VPN. A PE-based VPN (or Provider = Edge-based Virtual Private Network) is one in which PE devices in the = SP network provide the VPN. This allows the existence of the VPN to be = hidden from the CE devices, which can operate as if part of a normal = customer network. A detailed discussion of VPNs can be found in = [PPVPN-FR]. 8.4.5.1. Layer 3 PE-based VPN A layer 3 PE-based VPN is one in which the SP takes part in IP level = forwarding based on the customer network's IP address space. In = general, the customer network is likely to make use of private and/or = non-unique IP addresses. This implies that at least some devices in = the provider network needs to understand the IP address space as used = in the customer network. Typically this knowledge is limited to the PE = device [PPVPN-FR] which is directly attached to the customer. In a layer 3 PE-based VPN the provider will need to participate in some = aspects of management and provisioning of the VPNs, such as ensuring = that the PE devices are configured to support the correct VPNs. This = implies that layer 3 PE-based VPNs are by definition provider = provisioned VPNs [PPVPN-FR]. In order to connect the different VPN sites belonging to the same VPN = the SP uses a tunneling technique such as MPLS, L2TP or IPsec. These = tunnels originate and terminate on PE devices.=20 One of the characteristics of a layer 3 PE-based VPNs is that they = offload some aspects of VPN management from the customer network. From = an IPFIX architecture perspective, this means that the SP is the one = that potentially will be providing the IPFIX service for the VPNs that = it provides connectivity. The exporter in Layer 3 PE-based VPN can be located on the customer's = network, on the SP's backbone (P Router) or on the edge (PE router). = The premise of this discussion is that the exporter is the one = providing middlebox services, so in the case of VPNs we assume that the = exporter is located in a PE device.=20 8.4.5.1.1. Tunneling [Reinaldo: Just reference 13.4? ? What is 13.4] 8.4.5.1.2. Overlapping Address Realms In the case the exporter plays the role of a PE router [VPN-2547BIS] in = a provider provisioned VPN scenario and has VPNs with overlapping = private address realms, it can only provide useful non-conflicting = information to the provider for intra-VPN traffic if it uses a = technique that allows the collector to uniquely identify to which VPN = the flow belongs. Several techniques could be used to accomplish this goal. One of these = techniques is to include the VPN Global unique identifier [VPN-ID] as = one of the keys in the flow record.=20 In the case the exporter supports VPNs with overlapping private address = realms, it MUST include the VPN-ID [VPN-ID] in the exported flow = record. 8.4.5.2. Layer 2 PE-based VPN [TBD] A layer 2 PE-based VPN is one in which the network is aware of the VPN, = but does only layer 2 forwarding and signaling. This implies that the = SP provisions and maintains layer 2 connectivity between CE devices = [VPN-L2]. Forwarding options include MAC addresses (such as LAN emulation), use = of point-to-point link layer connections (FR or ATM), = multipoint-to-point (using MPLS multipoint to point LSPs), and = point-to-multipoint (e.g., ATM VCCs). For a layer 2 PE-based VPN, the PE device may be a router, LSR, or IP = switch. From the CE's perspective, the PE will be operating as a = switch. 8.5. QoS Monitoring with IPFIX=20 The performance QoS monitoring is one target application for using the = IPFIX protocol. QoS monitoring is the passive observation of the = transmission quality for single flows or traffic aggregates in the = network. It is needed for instance for the validation of QoS guarantees = in service level agreements. Some QoS metrics require the correlation = of data from multiple measurement points. For this the clock of the = involved exporting devices need to be synchronized. Furthermore such = measurements would benefit from post-processing functions (e.g. packet = ID generation) at the exporter and/or collector. This section describes = how the monitoring of different metrics can be performed with IPFIX. = The following metrics are considered: round trip time, one-way-delay, = loss and delay variation. 8.5.1. Measurement of Round-trip-time (RTT) with IPFIX The passive measurement of round-trip-times (RTT) can be performed by = using packet pair matching techniques as described in [Brow00]. For the = measurements, request/response packet pairs from protocols like DNS, = ICMP,SNMP or TCP (syn/syn-ack, data/ack) are utilized to passively = observe the RTT. As always for passive measurements this only works if = the required traffic of interest is actually present in the network. In = order to use this measurement technique, the IPFIX meter needs to = measure both directions. A classification of the protocols mentioned = above has to be done. That means parts of the transport header are used = for the classification. Since a differentiation of flows in accordance = to the transport header is one of the requirements for IPFIX, such = classification can be performed without extensions. Nevertheless, the = meter needs to recognize request and response packets for the given = protocols and therefore needs to look further into the packet. This is = not required for IPFIX but can be achieved by optional extensions to = the classification process. The exporting device needs to assign a = timestamp for the arrival of the packets. The calculation of the RTT = can be done directly at the exporter or at the collector. In the first = case IPFIX would transfer the calculated RTT to the collector. In the = second case IPFIX needs to send the observed packet types and the = timestamps to the collector. 8.5.2. Measurement of One-way-delay (OWD) with IPFIX Passive one-way-delay measurements require the collection of data at = two measurement points. It is required to recognize packets at the = second measurement point in order to correlate packet arrival events = from both points. This can be done for instance by capturing packet = headers and parts of the packet and recognize packets based on this. In = order to reduce the amount of measurement data a unique packet ID can = be calculated from the header and part of the content e.g. by using a = CRC or hash function [GrDM98, DuGr00, ZsZC01].Since IPFIX is not = targeted at packet capturing these functionalities do not need to be = supported by a standard IPFIX meter. Nevertheless, in some scenarios it = might be sufficient to calculate a packet ID under consideration of = header fields including datagram ID and maybe sequence numbers (from = transport protocols) without looking at parts of the packet content. = Especially if packet IDs need to be unique only for a certain time = interval or a certain amount of packet ID collisions is tolerable this = can be a solution.=20 8.5.3. Measurement of Loss with IPFIX Passive loss measurements for single flows can be performed at one = measurement point for instance by using sequence numbers that are = present in higher layer protocols. This requires the capturing of the = sequence numbers of subsequent packets of the observed flow at the = IPFIX meter. An alternative to this is to perform a two-point = measurement as described above and just consider packets as lost that = do not arrive at the second measurement point in a given maximum time = frame.=20 8.5.4. Measurement of delay variation with IPFIX Delay variation is defined as the difference of one-way-delay values = for selected packets.[DeCi01]. Therefore this metric can be calculated = by performing passive measurement of one-way-delay for subsequent = packets (e.g. of a flow) and then calculate the differences.=20 8.5.5. Sampling for QoS Monitoring Since QoS monitoring can lead to an overwhelming amount of measurement = result data, it would highly benefit from the deployment of mechanisms = to reduce the measurement data, like aggregation of results and = sampling. Sampling methods can be grouped according to the sampling = strategy (systematic, random or stratified) and the trigger that starts = a sampling interval (count-based, time-based or packet-content-based) = [ClPB93]. Sampling can also be used as a method to dynamically reduce = resource consumption if the meter is overloaded. Then the IPFIX meter = can switch to a sampling method if too many packets have to be = observed. Since the expected estimation error depends heavily on the = used sampling strategy, the application that receives the data needs to = be aware of the sampling scheme and the used parameters. Therefore it = is important that the IPFIX exporter informs the collector precisely = about the used sampling strategy. This is even more required if the = IPFIX meter dynamically invokes sampling. 9. IPFIX Protocol System 9.1. Capability Negotiation The capability negotiation is composed of two phases. In the first = Phase, basic capabilities regarding the exporting interface support are = negotiated between IPFIX end-points. If this phase fails, the = negotiation process will terminate and status information will be = provided to upper layers.=20 In the second phase, more specific capabilities are negotiated, for = instance, extended information model support, redundancy support, = templates, and supported messages. One could use, for instance, a capability negotiation process similar = to LCP [RFC 1661]. For each capability proposed by one of the peers in = each of the phases, the answer can be a reject, ack or nak. More specifically, the system sending a Configure-Request is telling = the peer system that it is willing to receive data sent with the = enclosed options enabled. If the peer does not recognize (or = administratively prohibits) one or more options in the = Configure-Request message, it must return just these options in a = Configure-Reject message and the original sender must then remove the = options from a subsequent Configure-Request message. If some of these options were recognized but unacceptable with the = supplied parameters, the peer would then respond with a Configure-Nak = containing only the offending options and a suggested modified value = for the parameters (called a hint). The receiver of the Configure-Nak = then should decide if the hinted value is acceptable and, if so, send a = new Configure-Request reflecting the requested changes plus the = original values for the unchanged options. The sender of the = Configure-Request may not send back any message other than = Configure-Request in response to Configure-Nak, so the only recourses = available if the hint is unreasonable are to drop the option from = subsequent Configure-Request messages, use Protocol-Reject to disable = the protocol, or disconnect the link entirely. Finally, if all options are acceptable, the peer then responds with = Configure-Ack with exactly the same options list as given in the = Configure-Request to indicate that all of the enclosed options were = acceptable and that are now enabled. 9.1.1. Phase I - Capabilities and Capabilities Management In the first phase, basic capabilities regarding the exporting = interface support are negotiated between IPFIX end-points. If this = phase fails, the negotiation process will terminate and status = information will be provided to users.=20 The Phase I negotiation MAY be carried over UDP, as it is a widely = supported transport protocol.=20 9.1.1.1. Security support The security support capability is used to negotiate which methods = (e.g. IPSec, TLS, MD5, etc) can be used to provide confidentiality, = integrity and protection against spoofed attacks. 9.1.1.2. IPFIX protocol=20 It is possible that several protocols (e.g. LFAP, CRANE, NetFlow, and = Diameter) meet the IPFIX requirements. In this case, this capability = is used to negotiate which protocol the end points will use.=20 9.1.1.3. Version of Protocol=20 This capability is used to negotiate which version of the protocol = exporter and collector will use to communicate. Agreeing on a specific = version indicates that the end-points support all the semantics and = dynamic procedures specified by a version of the protocol.=20 The protocol syntax (information model, data model, coding schemes, = etc) should be negotiated in Phase II. =20 9.1.1.4. Transport layer support This capability is used to negotiate the transport layer protocol used = between the exporter and collector. As the reliability is a key requirement of an IPFIX system, the = transport protocol should be connection oriented, congestion aware, = reliable, and providing in-sequence data delivery (e.g. TCP, SCTP). Under some circumstances e.g., when the network path between exporter = and collectors ensures abundant bandwidth and 'no' packet loss due to = congestion, a lightweight transport protocol such as UDP may be = employed. In this case, the upper layer must provide capabilities to = ensure reliability, e.g. message integrity check, loss detection, = acknowledgment, etc. 9.1.2. Phase II ? Data Management and Data Transmission In this phase, the IPFIX protocol initiates its own connection setup = that involves further capability negotiation. 9.1.2.1. Data collection triggers and policies *Update interval [TBD] *Sampling [TBD] *Aggregation rules[TBD] * Caching The exporter caches a certain amount of data before sending it to the = collector. If the collector fails, the exporter will need to hold more = data than normal while it waits for the collector to come back or = switch to different one. In order to provide for these two modes of = operation, the exporter could be configured with two levels of caching. = One level when the system is operating normally and a second when a = failure occurs. If the exporter detects that a server is unavailable; = it should use the higher cache level that allows it to hold more data = than it does in normal operation. 9.1.2.2. Reliability This capability is used to negotiate parameters related to fail-over = support, load balancing, keepalives, etc. For instance, exporter and collector SHOULD set the keepalive (in the = case of TCP) or the HEARTBEAT interval in the case of SCTP to a = sufficiently low value so that it can quickly detect a collector crash. = On detecting a Keepalive timeout, the exporter SHOULD stop sending the = flow export data to the collector and bring down the transport = connection.=20 If the exporter detects that a collector is unavailable and fail-over = was negotiated, it should try to switch to the stand-by collector in = order to resume service. If the exporter does not keep a live = connection to the stand-by collector, it MAY go through the = capabilities negotiation process described in this section before it = could export data.=20 IN the case of UDP, an exporter MAY send a Collector Health request = query. The collector MUST reply to this request. The exporter MUST be = able to accept a response from the collector. If the exporter does not = see the health query response from the collector, it assumes the = collector is unavailable and MAY switch to another collector that is = available. In the case there are multiple collectors operating redundant mode, the = exporter MAY multicast the flow records to the set of collectors that = joined the export multicast group, instead of sending several unicast = streams towards the different collectors. Multicast would lower the = bandwidth requirements on the export link in case that the collectors = are on the same media, and could lower the internal bus utilization on = the exporter. In the case there are multiple collectors operating in load-balancing = mode, a weight number associated with each server MAY be used to infer = the amount of exported flows each server should receive.=20 It should be noted that servers operating in a redundant or = load-balancing mode could be running different version of the IPFIX = protocol and also use different capabilities. 9.1.2.3. Templates=20 This capability is used to negotiate a common set of templates = corresponding to an IPFIX session between the exporter and collector. A = locally unique template identifier (template ID) MUST be assigned to = each template, and carried along with IPFIX user messages to ensure = correct decoding of IP flow information. Exporter and collector MUST = use the same set of templates during a session. The templates can be = renegotiated but MUST always be agreed on by all IPFIX end-points = participated in the IPFIX session before they can be used. =20 The exporter and collector MUST agree on a common set of templates = before the collector can start sending data according to them.=20 The template negotiation follows the LCP method described earlier. The = collector may propose changes to the templates received from an = exporter (e.g. enabling some keys and disabling others), or it can = acknowledge the templates as is. In the case that a template or a key = is not recognized by the collector (e.g. they might be added to the = exporter after the collector configuration has completed), the = collector MAY choose to disable each unknown key or unknown templates = in order to avoid unnecessary traffic. A template is disabled when all = the keys are disabled.=20 9.1.2.4. Extended flow type support Beside standardized minimum set of possible flow properties, the = exporter should be able to classify and export flows based on extended = information such as (but not limited to) URL, RTP Media type and SIP = Method. This capability is used to negotiate what are those extended = properties. 9.1.2.5. Messages Supported A particular protocol or version might have optional messages that are = not mandatory. This capability is used to negotiate what are those = optional messages types supported.=20 9.1.2.6. Overlapping flows This capability is used to negotiate the support of overlapping flow = awareness, i.e., if exporter has the means of inferring if the same = will be exported more than once and letting the collector of this fact. = In the absence of explicit negotiation of this capability, the = collector MUST consider that all flows reported can overlap. In the = case the device reports overlapping between certain flows, the = collector SHOULD take this into consideration, but MUST NOT assume that = other flows will not overlap 9.1.2.7. MIDCOM related Capabilities [TBD] To Be Added 9.1.3. Renegotiation of Capabilities=20 Only renegotiation of capabilities agreed on phase II can be performed = without tearing down the connection.=20 The initial negotiation can deal with a wealth of settings and assign = ID's to various capability versions. The re-negotiation needs only to = refer these IDs and require simple acknowledgement. 9.1.4. Caching of Negotiated Parameters Negotiation of parameters can be transmitted at any time by the = exporter. It is also possible for the collector to request negotiation = parameters. The exporter MUST be able to receive a request from the = exporter. [Reinaldo] If you need to open a connection every time you need to = export a low (or at least frequently), is there any advantage to cache = the capabilities and associate a key so that you don't have to = renegotiate them?=20 [Kevin] This is a tough one. My understanding is that IPFIX tries to = deal with high volume data export, with rather static configuration, = and a session or connection last for a very long time. Caching the = capability requires the "state information" be managed by the exporter = and collector, and then we need to talk about how to aging, removing, = and updating them.=20 [Reinaldo] Here you can reuse the ID's mentioned on the renegotiation = of capabilities. In order to be able to renegotiate using the ID's you = need to keep state anyway. 10. Security Consideration IP flow information can be used for various purposes, such as usage = accounting, traffic profiling, traffic engineering, and intrusion = detection. For each application, the security requirement may differ = significantly from one to another. To be able to satisfy the security = needs of various IPFIX users, the architecture of IPFIX MUST provide = different levels of security protection. 10.1. Data security. IPFIX data contains the flow information extracted by the data probe = and reported to the data collector.=20 The IPFIX data may exist in both the exporter and the collector. In = addition, the data is also transferred on the wire from the exporter to = the collector when it is reported. To provide security, the data SHOULD = be protected from adversary. The protection of IPFIX data in the end system (exporter and collector) = is out of the scope. It is assumed that the end system operator will = provide adequate security for the IPFIX data.=20 The IPFIX architecture MUST allow different levels of protection to the = IPFIX data on the wire. Where ever security functions are required it = is recommended to leverage to lower layers using either IPsec or TLS, = if they can successfully satisfy the security requirement of IPFIX data = protection. To protect the data on the wire, three levels of granularity SHOULD be = supported: 10.1.1. No security No security is required when the transport between the exporter and the = collector is perceived as safe. This option allows the protocol to run = most efficiently without extra overhead and an IPFIX solution MUST = support it.=FF 10.1.2. Authentication only The authentication only protection provides the IPFIX users the = assurance of data integrity and authenticity. The data exchanged = between the exporter and the collector is protected by authentication = signature. Any modification of the IPFIX data will be detected by the = recipient, resulting in discarding of the received data. However, the = authentication only option doesn't offer data confidentiality. The = IPFIX user SHOULD avoid use this option when sensitive or confidential information is being exchanged. An IPFIX = solution SHOULD support this option. The authentication only option = SHOULD provide replay attack protection.=20 10.1.3. Encryption=20 Data encryption provides the best protection for IPFIX data. The IPFIX = data is encrypted at the sender and only the intended recipient can = decrypt and have access to the data. This option MUST be used when the = transport between the exporter and the collector are unsafe and the = IPFIX data needs to be protected. It is recommended to use the = underlying security layer functions for this purpose. The data encryption option adds overhead to the IPFIX data transfer. It = may limit the rate that an export can report its flow to the collector = due to the heavy resource requirement of running encryption. 10.2. IPFIX end point authentication It is important to make sure that the exporter is talking to the = "right" collector instead of a masqueraded collector. The same logic = also holds true from the collector point of view that it want to make = sure it is collecting the flow information from the "right" exporter. = The IPFIX architecture SHOULD allow the authentication capability so = that either one-way or mutual authentication can be performed between = the exporter and collector. The IPFIX architecture SHOULD use the existing transport protection = protocols such as TLS to fulfill the authentication requirement. 10.3. Denial of service (DoS) attack prevention Since one of the potential usages for IPFIX is for intrusion detection, = it is important for the IPFIX architecture to support some kind of DoS = resistance. 10.3.1. Network under attack The Network itself may be under attack, resulting in an overwhelming = number of IPFIX messages. The IPFIX SHOULD try to capture as much = information as possible. However, when large amount IPFIX messages are = generated in a short period of time, the IPFIX may become overloaded. = The IPFIX system MUST provide enough performance assurance so that the = system can still function under heavy load. Possible solutions include = flow control and message thresholding. 10.3.2. Generic DoS attack on the IPFIX system The IPFIX system may subject to generic DoS attacks, just as any system = on any open networks. These types of attacks are not IPFIX specific. = Preventing and responding to such types of attacks are out of the scope = of IPFIX WG. 10.3.3. IPFIX Specific DoS attack There is a specific attack on the IPFIX portion of the Exporter or Collector. (To be added and discussed on the general list). 11. Application Interoperability of IPFIX This section describes the required mechanism to interoperate with = IPFIX applications that are identified in the requirement document [3]. = These applications are not exhaustive. 11.1. IPFIX usage in Intrusion Detection Intrusion Detection System (IDS) monitors and controls the security = incidents [4]. Typical IDS system includes components like Data source, = Sensor, Analyzer and Management stations [4]. A Sensor monitors the = data source and raises the alarm to the Analyzer. The analyzer collects = various incident information and reports this to the management = station. With IPFIX, the event of interest can be exported either from collector = or from exporter. For smooth integration, it will be better for the IDS = system to integrate with the collector since the collector has all the = aggregated information from different observation points. The IDS can = request the collector to monitor the events or IP flow through an IPFIX = template. 11.2. IPFIX and AAA AAA defines a protocol and architecture for authentication, = authorization and accounting for service usage. The DIAMETER protocol = is used for AAA communication for network access services (Mobile IP, = NASREQ, and ROAMOPS). The AAA architecture [XXX-RFC2903] provides a = framework for extending the AAA support also for other services. = DIAMETER defines the exchange of messages between AAA entities, e.g. = between AAA clients at access devices and AAA servers and among AAA = servers. It is used also for the transfers of accounting records. For = usage-based accounting measurement data from the network is needed to = generate an accounting record. IPFIX provides a protocol to export = measurement data from the measurement point to the consumer of this = data (like network management and accounting systems). The provisioning = of accounting with IPFIX can be realized without an AAA infrastructure. = The collector can directly forward the measurement information to an = accounting application. Nevertheless, if an AAA infrastructure is in = place, IPFIX can provide the input for the generation of accounting = records and several features of the AAA architecture can be used. = Features include the mapping of a user ID to the flow information (by = using authentication information), the generation of DIAMETER = accounting records and the secure exchange of accounting records = between domains with DIAMETER. Three possibilities to connect IPFIX and = AAA can be distinguished:=20 11.2.1. Connecting via an AAA client One possibility to connect IPFIX and AAA is to run an AAA client on the = IPFIX collector. This client can generate DIAMETER accounting messages = and send them to an AAA server. The mapping of the flow information to = a user ID can be done in the AAA server by using data from the = authentication process. DIAMETER accounting messages can be sent to the = accounting application or to other AAA servers (e.g. in roaming = scenarios). +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | DIAMETER | | +--+--------+--+ | | AAA-C | | + +--------+ | | | | Collector | +--------------+ =20 ^ | IPFIX | +------------+ | Exporter | +------------+ =20 Figure 2: IPFIX collector connects to AAA server via AAA client=20 11.2.2. Connecting via an Application Specific Module (ASM) Another possibility is to directly connect the IPFIX collector with the = AAA server via an application specific module (ASM). Application = specific modules have been proposed by the IRTF AAA architecture = research group (AAARCH) in [RFC2903]. They act as an interface between = AAA server and service equipment. In this case the IPFIX collector is = part of the ASM. The ASM acts as an interface between the IPFIX = protocol and the input interface of the AAA server. The ASM translates = the received IPFIX data into an appropriate format for the AAA server. = The AAA server then can add information about the user ID and generate = a DIAMETER accounting record. This accounting record can be sent to an = accounting application or to other AAA serves.=20 +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | +------------------+ | ASM | | +------------+ | | | Collector | | +------------------+ ^ | IPFIX | +------------+ | Exporter | +------------+ Figure 3: IPFIX connects to AAA server via ASM 11.3. IPFIX usage in Traffic Engineering/Traffic Profiling To better utilize the network, traffic engineering [5] is performed by = the network administrator. IPFIX can monitor and report different = flows. Using this information as a baseline, network administrators can = perform optimized network planning and engineering. =20 [more to be written]=20 12. References 3. J. Quittek ,et al.,? Requirements for IP Flow Information Export ?, = (work in progress) ,Internet Draft, Internet Engineering Task Force, = , November 2001 =20 4. M. Wood ,et al.,? Intrusion Detection Message Exchange = Requirements?,(work in progress), Internet Draft, Internet Engineering = Task Force, draft-ietf-idwg-requirements-06,February 2002. 5. Daniel O. Awduche, et. al.,? Overview and Principles of Internet = Traffic Engineering?, (work in progress), Internet Draft, Internet = Engineering Task Force, draft-ietf-tewg-principles-02.txt, May 2002=20 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions,=20 http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47-adelaide/pp-di= st/ [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric = for IPPM,=20 , November 2001 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss = Metric for=20 IPPM, September 1999 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application = of Sampling Methodologies to Network Traffic Characterization, Proceedings of ACM = SIGCOMM'93,=20 San Francisco, CA, USA, September 13 - 17, 1993 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, = John G. CLEARY:=20 Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay = Variation on=20 the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for = Direct Traffic=20 Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, = August 28 -=20 September 1, 2000. [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric = for IPPM,=20 Request for Comments: 2679, September 1999 =20 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation of = Building Blocks=20 for Passive One-way-delay Measurements, Proceedings of Passive and = Active Measurement=20 Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 (PAM = 2001)=20 [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture and = framework," work in progress. October 2001. [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address = Translator (NAT) Terminology and Considerations", RFC 2663, August = 1999. [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network = Address Translator (Traditional NAT)", RFC 3022, January 2001. [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider = Provisioned Virtual Private Networks ", work in progress, = , January 2002.=20 [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft = , July 2001. [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and = W. Weiss, "An Architecture for Differentiated Services", RFC 2475, = December 1998. [1] Requirements for IP Flow Export, = [2] K.Zhang, et al., "Common Reliable Accounting for Network Element = (CRANE)", , February 2002 [3] G. Sadasivan, et al., "Flow Export Architecture", = , January 2002 =20 [4] Carlson, James, "PPP Design, Implementation and Debugging", Second = Edition . 13. Acknowledgements We like to thank all the people contributing to the requirements discussion on the mailing list, and the design teams for a lot of = valuable comments. George Carle Tanja Zseby Paul Calato Dave Plonka Kevin Zhang KC Norseth Phill Richards Will Eatherton Benoit Claise Ganesh Sadasivan Vamsi Valluri Ram Gopal Jc Martin Carter Bullard Juergen Quittek Reinaldo Penno Nevil Brownlee Simon Leinen 14. Author's Addresses Paul Calato Riverstone Networks, Inc. 5200 Great America Parkway Santa Clara, CA 95054 USA Phone: +1 (603) 557-6913 Email: calato@riverstonenet.com Benoit Claise Cisco Systems De Kleetlaan 6a b1 1831 Diegem Belgium Phone: +32 2 704 5622 Email: bclaise@cisco.com Ganesh Sadasivan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1 (408) 527-0251 Email: gsadasiv@cisco.com Ram Gopal Nokia=20 5 Wayside Road,=20 Burlington, MA 01803 Phone:+1 781 993 3685 Email: ram.gopal@nokia.com Man Li=20 Nokia=20 5 Wayside Road,=20 Burlington, MA 01803=20 Phone: +1 781 993 3923=20 Email: man.m.li@nokia.com=20 K.C. Norseth Enterasys Networks 2691 S. Decker Lake Lane Salt Lake City, Utah 84119 Phone: +1 801 887 9823 Email: knorseth@enterasys.com Reinaldo Penno Nortel Networks, Inc.=20 2305 Mission College Boulevard Building SC9-B1240 =20 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com=20 Juergen Quittek NEC Europe Ltd. Adenauerplatz 6 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@ccrle.nec.de Kevin Zhang =20 XACCT Technologies, Inc.=20 2900 Lakeside Drive=20 Santa Clara, CA 95054=20 Phone +1 301 992 4697=20 Email: kevin.zhang@xacct.com Tanja Zseby GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7153 Email: zseby@fokus.gmd.de 15. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This = document and translations of it may be copied and furnished to others, = and derivative works that comment on or otherwise explain it or assist = in its implementation may be prepared, copied, published and = distributed, in whole or in part, without restriction of any kind, = provided that the above copyright notice and this paragraph are = included on all such copies and derivative works. However, this = document itself may not be modified in any way, such as by removing the = copyright notice or references to the Internet Society or other = Internet organizations, except as needed for the purpose of developing = Internet standards in which case the procedures for copyrights defined = in the Internet Standards process must be followed, or as required to = translate it into. 16. Stuff to Add The following items need to be addressed: * Iana Port Number for IPFIX=20 An SNMP MIB module should be made available to monitor the various components and to define, if any, standard=20 configuration objects (Mike Mcfadden, Dave Harrington) IPFIX Architecture February, 2002 IPFIX Design Team Expires August, 2002 [Page 7] IPFIX Design Team Expires July 2002 [Page 1] ------_=_NextPart_000_01C1B65A.2A969CB0 Content-Type: application/octet-stream; name="Norseth, KC.vcf" Content-Disposition: attachment; filename="Norseth, KC.vcf" BEGIN:VCARD VERSION:2.1 N:Norseth;KC FN:Norseth, KC ORG:Cabletron Systems, Inc.;5167 TEL;WORK;VOICE:53823 ADR;WORK:;Salt Lake City;2835 South Decker Lake Drive;Salt Lake City;UT;84119;US LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Salt Lake City=0D=0A2835 South Decker Lake Drive=0D=0ASalt Lake City, UT 841= 19=0D=0AUS EMAIL;PREF;INTERNET:knorseth@cabletron.com REV:19991213T143559Z END:VCARD ------_=_NextPart_000_01C1B65A.2A969CB0-- -- 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 Fri Feb 15 15:15:25 2002 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 PAA18299 for ; Fri, 15 Feb 2002 15:15:25 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16boSJ-0000M4-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 13:55:39 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16boSH-0000LY-00 for ipfix-data@net.doit.wisc.edu; Fri, 15 Feb 2002 13:55:37 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FJpDN27221; Fri, 15 Feb 2002 13:51:13 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFZAGB>; Fri, 15 Feb 2002 11:51:12 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008A73FC6@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan , ipfix-data@net.doit.wisc.edu Subject: RE: [ipfix-data] draft-ietf-ipfix-data-00.txt - comments Date: Fri, 15 Feb 2002 11:51:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B65A.1D819CF0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B65A.1D819CF0 Content-Type: text/plain; charset="utf-8" Hello Ganesh, >-----Original Message----- >From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] >Sent: Thursday, February 14, 2002 7:28 PM >To: ipfix-data@net.doit.wisc.edu >Subject: [ipfix-data] draft-ietf-ipfix-data-00.txt - comments > > >5.3.4. LAST_SWITCHED >SysUptime at which the last packet of this flow was processed >by the meter before the flow record was exported or the >flow ended. > >5.3.5. FIRST_SWITCHED >SysUptime at which the first packet of this flow was processed >by the meter. > >5.4.1. Class of Service IE >There should be separate IEs to distinguish between >Cos for V4, V6, MPLS & VLAN. A packet can have more >than one Cos fields, each associated with >{ & & } yep. this needs to be expanded. > >5.11.4. Source VLAN ID IE >5.11.5. Destination VLAN ID IE >Is there not a one-to-one correspondence between VLAN-ID and >interface Index? I am wondering where this would useful. >Is there a plan to distinguish between .1p and .1q? yes, I'm rewriting this part. Spliting 801.q and p. And no, you can have the same VLAN-ID on different interfaces. > >5.13.7. IGMP_TYPE >Types of IGMP messages of concern to the host-router >interaction. > > >-- >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/ > ------_=_NextPart_001_01C1B65A.1D819CF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] draft-ietf-ipfix-data-00.txt - = comments

Hello Ganesh,

>-----Original Message-----
>From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]=
>Sent: Thursday, February 14, 2002 7:28 PM
>To: ipfix-data@net.doit.wisc.edu
>Subject: [ipfix-data] = draft-ietf-ipfix-data-00.txt - comments
>
>
>5.3.4.    LAST_SWITCHED
>SysUptime at which the last packet of this flow = was processed
>by the meter before the flow record was exported = or the
>flow ended.
>
>5.3.5.    FIRST_SWITCHED
>SysUptime at which the first packet of this flow = was processed
>by the meter.
>
>5.4.1.  Class of Service IE
>There should be separate IEs to distinguish = between
>Cos for V4, V6, MPLS & VLAN. A packet can = have more
>than one Cos fields, each associated with
>{<v4 | v6> & <mpls> & = <vlan>}

yep. this needs to be expanded.

>
>5.11.4.  Source VLAN ID IE
>5.11.5.  Destination VLAN ID IE
>Is there not a one-to-one correspondence between = VLAN-ID and
>interface Index? I am wondering where this would = useful.
>Is there a plan to distinguish between .1p and = .1q?

yes, I'm rewriting this part. Spliting 801.q and p. = And no, you can have the same VLAN-ID on different interfaces.

>
>5.13.7.    IGMP_TYPE
>Types of IGMP messages of concern to the = host-router
>interaction.
>
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B65A.1D819CF0-- -- 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 Fri Feb 15 18:35:20 2002 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 SAA23197 for ; Fri, 15 Feb 2002 18:35:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16brb6-00055g-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 17:16:56 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16brb4-000556-00 for ipfix@net.doit.wisc.edu; Fri, 15 Feb 2002 17:16:54 -0600 Received: from Kevinz (1Cust159.tnt15.dca5.da.uu.net [63.10.143.159]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1FNGwl10002; Fri, 15 Feb 2002 15:16:58 -0800 Reply-To: From: "Kevin Zhang" To: "Norseth, KC" , Subject: RE: [ipfix] IPFIX Design draft updates Date: Fri, 15 Feb 2002 18:17:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C1B64D.181215E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <59358A738F45D51186A30008C74CE250DA06DC@slc-exc1.ctron.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C1B64D.181215E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit IPFIX Design draft updatesHi KC, The architecture draft looks quite good to me, and I believe the addition from Beniot and Ganesh's text really strengthened the document. The entire section 5 of the data draft is very troublesome. If I remember correctly, at the conference call several weeks ago, we (including Cisco) agreed that the Cisco draft dived into protocol too soon, and we should complete the architecture and the data model documents before assessing/selecting a protocol. The message formats definitely belong to a protocol specification, not the data model draft. I suggest to remove entire section 5 from the data model draft. If the group decides that the data model draft will specify messages passing between IPFIX end-points, I suggest we include the formats from LFAF and CRANE as they were proposed as candidate protocols just like Netflow. Thanks, Kevin -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Norseth, KC Sent: Friday, February 15, 2002 2:52 PM To: 'ipfix@net.doit.wisc.edu' Subject: [ipfix] IPFIX Design draft updates IPFIX People. I have updated both the team architectural and data drafts. The .txt versions are enclosed. If someone wants them in Word format. Let me know. I am not worried at the moment of pagenation and Changes to the drafts: Architecture: a.. Reordering sections and better integration of the sections from Beniot and Ganesh's draft. b.. Further definition of some areas. c.. Spelling and grammer Data: a.. Integrating sections Beniot and Ganesh's draft. b.. Further definition of some areas. c.. Clarification of element types and how to define them. Now I need is the TC's to go along with each element. d.. Spelling and grammer If I have missed some updates to the draft, let me know. If you have any questions, just ask. Please give as many comments to the group as possible over the weekend, where the "editorial review" board is going to review everything on Monday. As recommended by Nevil, I will submit this as an individual draft, submitted by the design group. This way, reguardless of how the editoral board combines /removes text, this will be recorded for Minneapolis so it can be discussed as needed, just Benoit and Ganesh's is. It will also be given an IPFIX team name, not IETF-IPFIX. K.C. <> <> K.C. Norseth Firmware Engineering - Routing Enterasys Networks Phone: 801.887.9823 FAX: 801.972.5789 Email: knorseth@enterasys.com www: http://www.enterasys.com <> ------=_NextPart_000_0009_01C1B64D.181215E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPFIX Design draft updates
Hi=20 KC,
 
The=20 architecture draft looks quite good to me, and I believe the addition = from=20 Beniot and Ganesh's text really strengthened the document.=20
 
The=20 entire section 5 of the data draft is very troublesome.  If I = remember=20 correctly, at the conference call several weeks ago, we (including = Cisco) agreed=20 that the Cisco draft dived into protocol too soon, and we should = complete the=20 architecture and the data model documents before assessing/selecting a = protocol.=20 The message formats definitely belong to a protocol specification, not = the data=20 model draft.  I suggest to remove entire section 5 from the = data model=20 draft. 
 
If the=20 group decides that the data model draft will specify messages passing = between=20 IPFIX end-points, I suggest we include the formats from LFAF and CRANE = as they=20 were proposed as candidate protocols just like=20 Netflow.  
 
Thanks,
 
Kevin
 
 
 
 
 -----Original = Message-----
From:=20 majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of = Norseth, KC
Sent: Friday, February 15, 2002 2:52 = PM
To:=20 'ipfix@net.doit.wisc.edu'
Subject: [ipfix] IPFIX Design draft=20 updates

IPFIX People.

I have updated both the team = architectural and data=20 drafts.  The .txt versions are enclosed.  If someone wants = them in=20 Word format. Let me know.  I am not worried at the moment of = pagenation=20 and

Changes to the drafts:

Architecture:=20

  • Reordering sections and better = integration of=20 the sections from Beniot and Ganesh's draft. 
  • Further definition of some = areas.=20
  • Spelling and grammer =

Data:=20

  • Integrating sections Beniot and = Ganesh's=20 draft. 
  • Further definition of some = areas.=20
  • Clarification of element types and = how to define=20 them.  Now I need is the TC's to go along with each = element.=20
  • Spelling and grammer =

If I have missed some updates to the = draft, let me=20 know.

If you have any questions, just = ask.  Please=20 give as many comments to the group as possible over the weekend, where = the=20 "editorial review" board is going to review everything on = Monday. =20

As recommended by Nevil, I will submit = this as an=20 individual draft, submitted by the design group.  This way, = reguardless=20 of how the editoral board combines /removes text, this will be = recorded for=20 Minneapolis so it can be discussed as needed, just Benoit and = Ganesh's =20 is.  It will also be given an IPFIX team name, not = IETF-IPFIX.

K.C.
<<draft-ietf-ipfix-data-00.txt>> <<draft-ietf-ipfix-architecture-00.txt>>=20
K.C. = Norseth=20
Firmware = Engineering - =20 Routing
Enterasys=20 Networks
   = Phone:=20 801.887.9823 =
   FAX:    = 801.972.5789 =
   Email:   knorseth@enterasys.com
   www:    http://www.enterasys.com= =20
<<Norseth, = KC.vcf>>=20

------=_NextPart_000_0009_01C1B64D.181215E0-- -- 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 Fri Feb 15 18:59:28 2002 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 SAA23479 for ; Fri, 15 Feb 2002 18:59:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bs03-0005bo-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 17:42:43 -0600 Received: from c001-h007.c001.snv.cp.net ([209.228.32.121] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16bs01-0005az-00 for ipfix@net.doit.wisc.edu; Fri, 15 Feb 2002 17:42:41 -0600 Received: (cpmta 395 invoked from network); 15 Feb 2002 15:42:04 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.121) with SMTP; 15 Feb 2002 15:42:04 -0800 X-Sent: 15 Feb 2002 23:42:04 GMT Message-ID: <002e01c1b67a$c146ea00$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: , "Norseth, KC" , References: Subject: Re: [ipfix] IPFIX Design draft updates Date: Fri, 15 Feb 2002 16:44:44 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C1B640.126A40C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C1B640.126A40C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPFIX Design draft updatesI have no problem with that. The data draft = needed something in layout more than a line saying we can consider = LFAP,CRANE, or NetFlow, so I brought up the Cisco draft as a basis for = starting.. The individual elements defined are much better using the = other documents. That has always been a weakness of NetFlow, defining = the elements of the data where people didn't have to search for answers. I wonder if you could give me the CRANE alternative to section 5, and = Paul an LFAP alternative? What I could do is put in 3 different section = 5's in te data draft for people to see. The team draft we submit can = eaasily have 3 alternatives. K.C. ----- Original Message -----=20 From: Kevin Zhang=20 To: Norseth, KC ; ipfix@net.doit.wisc.edu=20 Sent: Friday, February 15, 2002 4:17 PM Subject: RE: [ipfix] IPFIX Design draft updates Hi KC, =20 The architecture draft looks quite good to me, and I believe the = addition from Beniot and Ganesh's text really strengthened the document. = =20 The entire section 5 of the data draft is very troublesome. If I = remember correctly, at the conference call several weeks ago, we = (including Cisco) agreed that the Cisco draft dived into protocol too = soon, and we should complete the architecture and the data model = documents before assessing/selecting a protocol. The message formats = definitely belong to a protocol specification, not the data model draft. = I suggest to remove entire section 5 from the data model draft. =20 =20 If the group decides that the data model draft will specify messages = passing between IPFIX end-points, I suggest we include the formats from = LFAF and CRANE as they were proposed as candidate protocols just like = Netflow. =20 =20 Thanks, =20 Kevin =20 =20 =20 =20 -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On = Behalf Of Norseth, KC Sent: Friday, February 15, 2002 2:52 PM To: 'ipfix@net.doit.wisc.edu' Subject: [ipfix] IPFIX Design draft updates IPFIX People.=20 I have updated both the team architectural and data drafts. The = .txt versions are enclosed. If someone wants them in Word format. Let = me know. I am not worried at the moment of pagenation and=20 Changes to the drafts:=20 Architecture:=20 a.. Reordering sections and better integration of the sections = from Beniot and Ganesh's draft. =20 b.. Further definition of some areas.=20 c.. Spelling and grammer=20 Data:=20 a.. Integrating sections Beniot and Ganesh's draft. =20 b.. Further definition of some areas.=20 c.. Clarification of element types and how to define them. Now I = need is the TC's to go along with each element.=20 d.. Spelling and grammer=20 If I have missed some updates to the draft, let me know.=20 If you have any questions, just ask. Please give as many comments = to the group as possible over the weekend, where the "editorial review" = board is going to review everything on Monday. =20 As recommended by Nevil, I will submit this as an individual draft, = submitted by the design group. This way, reguardless of how the = editoral board combines /removes text, this will be recorded for = Minneapolis so it can be discussed as needed, just Benoit and Ganesh's = is. It will also be given an IPFIX team name, not IETF-IPFIX. K.C.=20 <> = <>=20 K.C. Norseth=20 Firmware Engineering - Routing=20 Enterasys Networks=20 Phone: 801.887.9823=20 FAX: 801.972.5789=20 Email: knorseth@enterasys.com=20 www: http://www.enterasys.com=20 <>=20 ------=_NextPart_000_0029_01C1B640.126A40C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IPFIX Design draft updates
I have no problem with that.  The = data draft=20 needed something in layout more than a line saying we can consider = LFAP,CRANE,=20 or NetFlow, so I brought up the Cisco draft as a basis for = starting.. =20 The individual elements defined are much better using the other = documents. =20 That has always been a weakness of NetFlow, defining the elements of the = data=20 where people didn't have to search for answers.
 
I wonder if you could give me the CRANE = alternative=20 to section 5, and Paul an LFAP alternative?  What I could do is put = in 3=20 different section 5's in te data draft for people to see.  The team = draft=20 we submit can eaasily have 3 alternatives.
 
K.C.
----- Original Message -----
From:=20 Kevin=20 Zhang
To: Norseth,=20 KC ; ipfix@net.doit.wisc.edu
Sent: Friday, February 15, 2002 = 4:17=20 PM
Subject: RE: [ipfix] IPFIX = Design draft=20 updates

Hi=20 KC,
 
The=20 architecture draft looks quite good to me, and I believe the addition = from=20 Beniot and Ganesh's text really strengthened the document.=20
 
The=20 entire section 5 of the data draft is very troublesome.  = If I=20 remember correctly, at the conference call several weeks ago, we = (including=20 Cisco) agreed that the Cisco draft dived into protocol too soon, and = we should=20 complete the architecture and the data model documents before=20 assessing/selecting a protocol. The message formats definitely belong = to a=20 protocol specification, not the data model draft.  = I suggest to=20 remove entire section 5 from the data model draft.  =
 
If=20 the group decides that the data model draft will specify messages = passing=20 between IPFIX end-points, I suggest we include the formats from LFAF = and CRANE=20 as they were proposed as candidate protocols just like=20 Netflow.  
 
Thanks,
 
Kevin
 
 
 
 
 -----Original=20 Message-----
From: majordomo listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Norseth,=20 KC
Sent: Friday, February 15, 2002 2:52 PM
To:=20 'ipfix@net.doit.wisc.edu'
Subject: [ipfix] IPFIX Design = draft=20 updates

IPFIX People.

I have updated both the team = architectural and=20 data drafts.  The .txt versions are enclosed.  If someone = wants=20 them in Word format. Let me know.  I am not worried at the = moment of=20 pagenation and

Changes to the drafts:

Architecture:=20

  • Reordering sections and better = integration of=20 the sections from Beniot and Ganesh's draft. 
  • Further definition of some = areas.=20
  • Spelling and grammer =

Data:=20

  • Integrating sections Beniot and = Ganesh's=20 draft. 
  • Further definition of some = areas.=20
  • Clarification of element types and = how to=20 define them.  Now I need is the TC's to go along with each=20 element.=20
  • Spelling and grammer =

If I have missed some updates to the = draft, let=20 me know.

If you have any questions, just = ask.  Please=20 give as many comments to the group as possible over the weekend, = where the=20 "editorial review" board is going to review everything on = Monday. =20

As recommended by Nevil, I will = submit this as an=20 individual draft, submitted by the design group.  This way, = reguardless=20 of how the editoral board combines /removes text, this will be = recorded for=20 Minneapolis so it can be discussed as needed, just Benoit and = Ganesh's =20 is.  It will also be given an IPFIX team name, not=20 IETF-IPFIX.

K.C.
<<draft-ietf-ipfix-data-00.txt>> <<draft-ietf-ipfix-architecture-00.txt>>=20
K.C. = Norseth=20
Firmware = Engineering - =20 Routing
Enterasys=20 Networks
  =20 Phone: 801.887.9823
  =20 FAX:    801.972.5789
  =20 Email:   knorseth@enterasys.com
   www:    http://www.enterasys.com= =20
<<Norseth, = KC.vcf>>=20

------=_NextPart_000_0029_01C1B640.126A40C0-- -- 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 Fri Feb 15 23:42:23 2002 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 XAA29253 for ; Fri, 15 Feb 2002 23:42:23 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16bwOh-0003TM-00 for ipfix-list@mil.doit.wisc.edu; Fri, 15 Feb 2002 22:24:27 -0600 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16bwOe-0003TD-00 for ipfix@net.doit.wisc.edu; Fri, 15 Feb 2002 22:24:24 -0600 Received: from auckland.ac.nz (root@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id RAA16057 for ; Sat, 16 Feb 2002 17:24:16 +1300 (NZDT) Message-Id: <200202160424.RAA16057@mailhost.auckland.ac.nz> Date: Fri, 15 Feb 2002 22:19:26 -0800 (PST) From: n.brownlee@auckland.ac.nz Subject: [ipfix] WG process: next steps To: ipfix@net.doit.wisc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Hello everyone: Thanks to those who responded to my proposals a day or two back. We plan to continue producing the IPFIX Architecture and Data Model documents as follows: First, what we're trying to achieve by 22 February is the -00 versions of the IPFIX Architecture and Data Model drafts. -00 drafts don't need to be nicely-polished, complete documents. They need to be complete enough to show people what they're about, with sufficient detail to prompt their readers to send in email suggestions for improvements. Also, apart from the periods around each IETF meeting, the IETF Secretariat are happy to publish new versions of drafts as often as we need, indeed many WGs have documents getting to -09 and higher. We don't have to produce a highly-detailed, bulky document for version 00. In order to get the -00 drafts done before 22 Feb, an 'editorial' team of 5, i.e. Benoit, Ganesh, KC, Juergen and Paul will teleconference next Monday with the co-chairs, review the two individual drafts, and determine the -00 drafts' contents. The teleconference will also assign the sections of each draft to various editors. The initial team (above) should be able to get the -00 drafts submitted by Friday. After that, I believe that the WG is past the point where it needs a 'design team.' We should go back to having all discussion on the IPFIX list. One problem for the WG right now is 'how do we make sure that people who contribute to the WG effort are properly recognised for their efforts. Seems to me that around 4 is surely enough to do the actual editing (though I do realise that editing does take a lot of time), so we can't all be editors! We need to think about how we record contributions in the drafts 'Acknowledgements' sections, maybe listing the people who - wrote original text for sections - commented on the list, suggested improvements, etc - read the drafts and sent in corrections Would this be a good way past the 'everyone wants to be on the title page' problem? Remember, we're trying to produce the *Working Group's* best technical solutions for IPFIX! Also, we need to put together an agenda for the Minneapolis meeting. Items so far (in no particular order): 1. Review latest version of Requirements draft 2. Review Architecture and Data Model draft 3. Discuss how to recognise contributions to WG documents (e.g. as above) 4. Establish process for developing the Architecture and Data Model drafts. For example, maybe the co-chairs need to agree before any changes are made to section headings? So ... I trust that by the end of next week we'll have some good -00 drafts to work on. Do keep the mailing list discussions alive, its great to have a really active WG! Please post your comments on the above to the list, as always. Cheers, Nevil (firmly wearing WG co-chair hat) +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P -- 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 Sat Feb 16 10:39:39 2002 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 KAA13285 for ; Sat, 16 Feb 2002 10:39:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16c6de-0002cH-00 for ipfix-list@mil.doit.wisc.edu; Sat, 16 Feb 2002 09:20:34 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16c6db-0002bH-00 for ipfix-req@net.doit.wisc.edu; Sat, 16 Feb 2002 09:20:31 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1GFJvg82850; Sat, 16 Feb 2002 16:19:57 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA22946; Sat, 16 Feb 2002 16:19:53 +0100 Date: Sat, 16 Feb 2002 16:21:43 +0100 From: Juergen Quittek To: Peter Ludemann , Reinaldo Penno , calato@riverstonenet.com, Benoit Claise cc: ram.gopal@nokia.com, zander@fokus.gmd.de, ipfix-req@net.doit.wisc.edu, Kevin Zhang Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Message-ID: <264221648.1013876503@[192.168.102.31]> In-Reply-To: X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Peter, --On 15 February 2002 08:53 -0800 Peter Ludemann wrote: > Juergen Quittek wrote Thursday, February 14, 2002 2:30 PM: > >> So what is your point? Do you want to have in-band configuration >> for the exported attributes/IEs in the requirements document? > > Yes. The CRANE protocol solves real problems that we've encountered; and we > have a number of partners who are using it (sorry, I can't announce these > right now). > >> What would be the application requiring this? Or from which >> general requirement would you derive this one? > > My answer is a little long. Our requirements go beyond just delivering the > kind of data that IPFIX is discussing; but I think that they are very > applicable to IPFIX. > > If all you care about is delivering one set of values which you'll never > change, then there's no need for any in-band configuration. (This would be > true only if you think that the data architecture folks will agree on a > specification with no SHOULDs in the document ...) > > If you anticipate change, then at minimum you need to specify the version of > the data that you're delivering. A more general solution is to use > self-describing data. XML would be fine but it's much too verbose for > delivering thousands of records per second from a small network device. > > So, the minimal requirement is to have some way for the device to advertise > what it has. I don't see a need for all of XML's nesting capabilities; a > simple 2-level scheme (type of record + fields) should suffice. As far, as I followed the ongoing difscussion, (almost) everyone agrees to this. > The receiver could quietly take this advertisement and process it. But our > experience in "IP data mediation" is that people usually only want specific > fields; and they typically want to post-process them. Examples of such > post-processing: associating values with IP addresses (e.g., reversing NAT, > mapping IP to customer), aggregation, filtering, conditional splitting, etc. > plus a host of database-oriented processing, such as looking for error > patterns, for people who hog bandwidth, etc. > > If the sending device can be configured by a MIB or CLI, the receiver can > adapt to what it advertises. But there are good reasons for such > configuration to be done by response from the receiver: > - the needed fields can be derived from the post-processing configuration, > so they naturally reside on the receiver, not the sender > - there can be tens or even thousands of sending devices, so > centralized configuration is desirable (especially if they can't all > have their versions changed simultaneously) > - there needs to be a way of coordinating amongst multiple receivers, > for fail-over deployments > (these aren't hypothetical requirements: we have customers who are looking > at deploying thousands of sending devices; and who require fail-over) > > Once you decide that the sender should advertises its data, it doesn't take > much more work to allow the receiver to respond with a list of fields that > it does or doesn't want. The sender can just mark the fields it won't send. > The advantages of this are: > - bandwidth saving (probably not very important) > - computation saving on the sender (this can be significant > in our experience) I think we are discussing two different issues. Your suggestion covers - as far as I have understood so far - the negotiation between sender an receiver about individual attributes/fields/IEs to be sent. But as 'in-band configuration' i understand the more basic configuration of meter and exporter including which ports to observe, which filtering rules to apply, which flow keys to use, which sampling rate to choose, etc. But coming back to your point: If you say the exporter may ignore it, why then making it a requirement? Requirements should be essentially needed and not just nice to have, but opyionally ignored at any time. I think your point can be a valuable contribution to the architecture, but following your argument it does not belong into the requirement docvument. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Our proposal makes it OPTIONAL for the sender to respond to the > configuration request. The sender can ignore the configuration request and > still send all the fields -- the receiver will just have to accept them (and > throw away what it doesn't want). But if the sender can take advantage of > the configuration request (e.g., turning off expensive computations), then > it has a simple mechanism for doing so. > > > ---- > > Peter Ludemann > Chief Architect, XACCT > +1.408.330.5732 > -- 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 Sat Feb 16 10:58:22 2002 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 KAA13462 for ; Sat, 16 Feb 2002 10:58:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16c6xv-00034Y-00 for ipfix-list@mil.doit.wisc.edu; Sat, 16 Feb 2002 09:41:31 -0600 Received: from tokyo.ccrle.nec.de ([195.37.70.2]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16c6xt-00033f-00 for ipfix-req@net.doit.wisc.edu; Sat, 16 Feb 2002 09:41:29 -0600 Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1]) by tokyo.ccrle.nec.de (8.11.6/8.11.6) with ESMTP id g1GFexg83026; Sat, 16 Feb 2002 16:40:59 +0100 (CET) (envelope-from quittek@ccrle.nec.de) Received: from [192.168.102.31] ([192.168.102.31]) by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA23079; Sat, 16 Feb 2002 16:40:54 +0100 Date: Sat, 16 Feb 2002 16:42:42 +0100 From: Juergen Quittek To: Ganesh Sadasivan cc: Sebastian Zander , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again Message-ID: <265480839.1013877762@[192.168.102.31]> In-Reply-To: <3C6D3F00.1CD73670@cisco.com> X-Mailer: Mulberry/2.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ganesh, Thank you for your explanations. Now I got your points and agree, that this is a reasonable architecture for an IPFIX implementation on a router. Now, regarding terminology in the requirements document, do you think we need to to mention the observation domain in there? I do not think so, but would suggest to cover this only in the architecture. Not because it does not make sense, but because so far we do not have specific requirements for observation domains. If we have some I am fine with adding (and explaining) it. Until then I suggest the following list of terms omitting the term 'meter': - obs. point - metering process - flow record - exporter (or export process) - collector - export process Juergen --On 15 February 2002 09:01 -0800 Ganesh Sadasivan wrote: > > Hi Jurgene, > See inline.. > > Juergen Quittek wrote: > >> Hi Ganesh, >> >> Your ideas are getting clearer to me. Still I have some >> questions. Please find them inline. >> >> --On 14 February 2002 16:06 -0800 Ganesh Sadasivan wrote: >> >> > >> > >> > Juergen Quittek wrote: >> > >> >> Hi Ganesh, >> >> >> >> --On 14 February 2002 14:45 -0800 Ganesh Sadasivan wrote: >> >> >> >> > Hi Jurgene, >> >> > The picture does not appear garbled in the archives. Probably you >> >> > can look at it there.See inline for my answers. >> >> >> >> I could read the picture well (even in your reply). >> >> >> >> > >> >> > Juergen Quittek wrote: >> >> > >> >> >> Hi Ganesh, >> >> >> >> >> >> --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: >> >> >> >> >> >> > Hi Jurgene, >> >> >> > I am of the opinion that "header capturing" is a metering >> >> >> > function.I see restrictions with your model. Escpecially >> >> >> > if some kind of metering is done on collected flows within >> >> >> > the router. It was with this in mind that I send out in one of >> >> >> > my previous mails the high level picture. Did not get any >> >> >> > response. So I am resending with some more modification. I am >> >> >> > slightly inclined to think that the metering process within >> >> >> > the observation domain could be hierarchical but have not put >> >> >> > it here. >> >> >> > What are your inputs? >> >> >> > >> >> >> Please excuse that I did not reply so far on your drawing. >> >> >> I did not understand it when I saw it the first time and sent >> >> >> it to the printer to study it later. Unfortunately, that's where >> >> >> it still is. I should better have sent you my questions on this: >> >> >> >> >> >> 1. What is the difference between a meter process and a meter? >> >> > >> >> > Sorry that is a mistake, I meant "meter process" for both cases >> >> > (within and outside the observation domain). >> >> >> >> I think "meter" is a very well suited name for a box >> >> hosting a metering process! >> > >> > Ok. >> > >> >> >> >> >> >> >> >> >> >> 2. How and from where do meters get input? from meter processes? >> >> > >> >> > Since there is no separate meters and meter processes, you can think of >> >> > it as meter process within the observation domain, feeding the the meter >> >> > process outside the observation domain. >> >> >> >> Meter processes can be cascaded? >> > >> > yes. >> > >> >> >> >> What is the input to a meter process? >> > >> > The input to the meter at the lowest level is packets. >> > Flows are cretaed as a result of the lowest level >> > meter process. At subsequent level,the input to meter would >> > be flows. As I mentioned before the first level meter is a must >> > but not the subsequent ones. >> >> What are 'flows' here? Do you mean already flow records >> containing flow statistics? >> Or are these packet headers tagged with some flow ID? > > Yes flow records. > Do we need packet headers tagged > with flow ID at all ? Even if they appear in thet form of packet > header, it would be better to call them flow records even > though they may not the final structures to be exported. > >> >> >> >> >> >> It must have the same structure than the output? >> >> Otherwise I do not see how you could cascade them. >> > >> > What does this mean? >> >> If you have two function blocks with identical names >> I assume their functions are identical. However the >> functions seem to be applied to different data for inside >> and outside meter processes. And I still do not understand >> whether they produce similar output. For sure the last >> stage must produce flow records. What is produces by the >> earlier stages I asked already above. > > I agree with the fact that input to the first level meter > is packets and to the rest of the levels it is flow records. > The outputs produced by meters at any level should be > flow records of some form which may not be what would > be finally exported.We can distinguish between packet level > and flow level meters. > >> >> >> >> >> >> >> >> How is the total metering process shared by the packet meter >> >> processes and the flow meter processes? >> > >> > They are independent entities. >> > >> >> >> >> In other words: what are the differences between these >> >> (different?) kinds of meters inside and outside the observation >> >> domain? >> > >> > The one outside observation domain operates on a bigger scope. >> > For example: Say there are 2 lowest level meters: >> > M11 extracts the 5 tuple IPV4 flows from interface1 at a >> > sampling rate of 1 in 10. >> > M12 extracts the 5 tuple IPV4 flows from interface2 at a >> > sampling rate of 1 in 20. >> > A meter at the level of observation domain sees the flows >> > created by M11 and M12 and does one more level of >> > sampling of all the flows created by both meters at a >> > rate of 1 in 2 before exporting it. >> >> I am not sure if you can do sampling at the second stage >> after you already did packet counting at the first level. >> What vwould the first level (inside) meter processes do >> other than sampling? Do they classify packets, determine >> the flow ID and forward some data on a per packet base to >> the second stage (outside) meter processes? > > Packet counting is not the targeted functionality in the > example above.It is more of a traffic engineering application. > The first level would sample packets and install the flow records > into a flow cache (like how it is done in netflow today). The > second level takes the flows from flow cache as input and > does furthur sampling. The example is not a very clear one. It > would have been better if the sampling at second level is replaced > by say 2 filters filtering on some subsets of fields from the > flow records. > > Thanks > Ganesh > >> >> >> Cheers, >> >> Juergen >> > >> > Ganesh >> > >> >> >> >> >> >> Juergen >> >> >> >> > >> >> >> >> >> >> 3. Is there only one exporter per observation domain? >> >> > >> >> > No. The exporter need not be tied to an observation domain. >> >> > Example: Take the case of 2 linecards in a router., linecard 1 and >> >> > linecard 2. Each of the LC forms an observation domain. The >> >> > meters associated directly with observation points perform flow >> >> > creation/updation based on the packets. There could be meters at >> >> > a higher level (i.e per observation domain) that do furthur filtering >> >> > or aggregation.However, the flows collected at the observation >> >> > domain LC1& LC2 could be >> >> > exported via LC2. Thus the exporter which is common to LC1 >> >> > and LC2 resides in LC2. The flow export packet from >> >> > each of the observation domain is identified by a unique ID. >> >> > >> >> > >> >> >> >> >> >> 4. What would be the difference between an observation domain >> >> >> ID and an exporter ID? >> >> > >> >> > The export flow packet is identified by the observation domain ID . >> >> > I am not sure we need the Exporter ID (or do we?) >> >> > >> >> > Thanks >> >> > Ganesh >> >> > >> >> >> >> >> >> >> >> >> Cheers, >> >> >> >> >> >> Juergen >> >> >> >> >> >> > >> >> >> > +---------------------------------------------------------------+ >> >> >> > | Observation Domain | >> >> >> > | | >> >> >> > | +-------+ +-------+ Packet level| >> >> >> > | |Meter1 | .... |MeterM | ({Fi}, {Si})| >> >> >> > | |Process| |Process| | >> >> >> > | +-------+ +-------+ | >> >> >> > | ^ ^ | >> >> >> > | | | | >> >> >> > | +-------+-------+ +-------+--------+ | >> >> >> > | | | | | | >> >> >> > | v v v v | >> >> >> > |+------------+ +------------+ +------------+ +------------+| >> >> >> > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| >> >> >> > |+------------+ +------------+ +------------+ +------------+| >> >> >> > +---------------------------------------------------------------+ >> >> >> > ^ ^ >> >> >> > | | >> >> >> > v v >> >> >> > +----------+ +----------+ >> >> >> > |Meter (O1)| .... |Meter (OP)| Flow Level >> >> >> > +----------+ +----------+ ({Fi}, {Si}) >> >> >> > | | >> >> >> > +-------+--------+ >> >> >> > | >> >> >> > v (uniqued ID for an observation domain) >> >> >> > +---------------+ >> >> >> > | exporter | >> >> >> > +---------------+ >> >> >> > >> >> >> > >> >> >> > Thanks >> >> >> > Ganesh >> >> >> > >> >> >> > Juergen Quittek wrote: >> >> >> > >> >> >> > Hi Sabastian, >> >> >> > >> >> >> > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: >> >> >> > >> >> >> >> Hi Juergen, >> >> >> >> >> >> >> >> Juergen Quittek schrieb: >> >> >> >>> >> >> >> >>> Hi all, >> >> >> >>> >> >> >> >>> We had some terminology discussion and it has not >> >> >> >>> converged yet. Therfore I like to raise one issue again: >> >> >> >>> >> >> >> >>> For the terinology section of the requirements draft >> >> >> >>> (I belive now it will be a subset of the architecture's >> >> >> >>> terminology) I would like to have two identifiers for >> >> >> >>> the following: >> >> >> >>> >> >> >> >>> 1. the function block containing all metering functions >> >> >> >>> This block gets as input observed (and potentially >> >> >> >>> sampled) packets from the observation point. It classifies >> >> >> >>> packets maps them to flows and creates/updates the >> >> >> >>> according flow record. >> >> >> >>> >> >> >> >>> 2. the function block sending flow records to the collector >> >> >> >>> >> >> >> >>> I am fine with splitting blocks more or modifying them >> >> >> >>> slightly, but I prefer to have this separation, because >> >> >> >>> also the requirements are split in a very similar way. >> >> >> >> >> >> >> >> I also would like to split those for at least 2 reasons. >> >> >> >> First we create a more general model because on a router linecard >> >> >> >> both are be combined but on a dedicated hardware/software based >> >> >> >> meter this will probably not the case. I don't think we should limit >> >> >> >> ipfix to routers only. Second the separation is nice to clarify >> >> >> >> the scope. The scope of the ipfix wg is to standardize the >> >> >> >> exporter (at least the interface to the outside). It's out >> >> >> >> of scope to standardize the meter (although we put some req. >> >> >> >> on it). >> >> >> >> >> >> >> >> I am not sure whether sampling is a function of the observation >> >> >> >> point or the meter. >> >> >> > >> >> >> > Neither am I, but we should agree on one or the other soon. >> >> >> > What about the following (short version of more detailed >> >> >> > suggestions already discussed for the architecture)? >> >> >> > >> >> >> > +-------+ +-----------+ +-------+ +--------+ +--------+ >> >> >> > | obs. | | header | | | | flow | | ex- | >> >> >> > | point |-->| capturing |-->| meter |-->| record |-->| porter | >> >> >> > +-------+ +-----------+ +-------+ +--------+ +--------+ >> >> >> > >> >> >> > | | >> >> >> > \____________________________ _____________________________/ >> >> >> > \/ >> >> >> > IPFIX traffic flow measurement module >> >> >> > >> >> >> > If can tell me a good reason I am fine with merging header capturing >> >> >> > and meter, but in general I see them as different function blocks. >> >> >> > >> >> >> > Juergen >> >> >> > >> >> >> >>> My initial naive suggestion was calling block 1. "meter" >> >> >> >>> and calling block 2. "exporter". However this might (no it >> >> >> >>> did already) cause confusion. Therefore, I am looking for >> >> >> >>> better terms. Any suggestions? >> >> >> >> >> >> >> >> I have no better terms. I think what's maybe confusing is that we don't >> >> >> >> have a term for the overall process (meter+exporter+observation). >> >> >> >> What could be appropriate? flow monitor? >> >> >> >> >> >> >> >> Another possibility: Name the overall process metering and rename >> >> >> >> the inner function block 1 which does classification etc. >> >> >> >> >> >> >> >> Sebastian >> >> >> >> >> >> >> >> -- >> >> >> >> Sebastian Zander E-mail: zander@fokus.fhg.de >> >> >> >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 >> >> >> >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >> >> >> >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander >> >> >> >> >> >> >> > >> >> >> > -- >> >> >> > 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/ >> >> >> > >> >> > >> > > -- 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 Sat Feb 16 11:27:31 2002 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 LAA13687 for ; Sat, 16 Feb 2002 11:27:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16c7MH-0003cB-00 for ipfix-list@mil.doit.wisc.edu; Sat, 16 Feb 2002 10:06:41 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16c7MF-0003bp-00 for ipfix@net.doit.wisc.edu; Sat, 16 Feb 2002 10:06:39 -0600 Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1GG67t23542; Sat, 16 Feb 2002 08:06:07 -0800 (PST) Received: from cisco.com (sjc-vpn1-155.cisco.com [10.21.96.155]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ABY98413; Sat, 16 Feb 2002 08:03:38 -0800 (PST) Message-ID: <3C6E836B.640BA25B@cisco.com> Date: Sat, 16 Feb 2002 08:06:04 -0800 From: Peram Marimuthu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "K.C. Norseth" CC: kevin.zhang@xacct.com, "Norseth, KC" , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX Design draft updates References: <002e01c1b67a$c146ea00$850f880a@slc252750> Content-Type: multipart/alternative; boundary="------------BCDB6AA258DCF9EE5566EB80" Precedence: bulk Sender: majordomo listserver --------------BCDB6AA258DCF9EE5566EB80 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Having 3 alternatives loses the meaning of standardization. Peram "K.C. Norseth" wrote: > I have no problem with that. The data draft needed something in layout more than a line > saying we can consider LFAP,CRANE, or NetFlow, so I brought up the Cisco draft as a > basis for starting.. The individual elements defined are much better using the other > documents. That has always been a weakness of NetFlow, defining the elements of the > data where people didn't have to search for answers. I wonder if you could give me the > CRANE alternative to section 5, and Paul an LFAP alternative? What I could do is put in > 3 different section 5's in te data draft for people to see. The team draft we submit > can eaasily have 3 alternatives. K.C. > > ----- Original Message ----- > From: Kevin Zhang > To: Norseth, KC ; ipfix@net.doit.wisc.edu > Sent: Friday, February 15, 2002 4:17 PM > Subject: RE: [ipfix] IPFIX Design draft updates > Hi KC,The architecture draft looks quite good to me, and I believe the > addition from Beniot and Ganesh's text really strengthened the document. The > entire section 5 of the data draft is very troublesome. If I remember > correctly, at the conference call several weeks ago, we (including Cisco) > agreed that the Cisco draft dived into protocol too soon, and we should > complete the architecture and the data model documents before > assessing/selecting a protocol. The message formats definitely belong to a > protocol specification, not the data model draft. I suggest to remove entire > section 5 from the data model draft. If the group decides that the data model > draft will specify messages passing between IPFIX end-points, I suggest we > include the formats from LFAF and CRANE as they were proposed as candidate > protocols just like Netflow. Thanks,Kevin-----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of > Norseth, KC > Sent: Friday, February 15, 2002 2:52 PM > To: 'ipfix@net.doit.wisc.edu' > Subject: [ipfix] IPFIX Design draft updates > > > IPFIX People. > > I have updated both the team architectural and data drafts. The > .txt versions are enclosed. If someone wants them in Word format. > Let me know. I am not worried at the moment of pagenation and > > Changes to the drafts: > > Architecture: > > * Reordering sections and better integration of the sections from > Beniot and Ganesh's draft. > * Further definition of some areas. > * Spelling and grammer > > Data: > > * Integrating sections Beniot and Ganesh's draft. > * Further definition of some areas. > * Clarification of element types and how to define them. Now I > need is the TC's to go along with each element. > * Spelling and grammer > > If I have missed some updates to the draft, let me know. > > If you have any questions, just ask. Please give as many comments > to the group as possible over the weekend, where the "editorial > review" board is going to review everything on Monday. > > As recommended by Nevil, I will submit this as an individual draft, > submitted by the design group. This way, reguardless of how the > editoral board combines /removes text, this will be recorded for > Minneapolis so it can be discussed as needed, just Benoit and > Ganesh's is. It will also be given an IPFIX team name, not > IETF-IPFIX. > > K.C. > <> > <> > K.C. Norseth > Firmware Engineering - Routing > Enterasys Networks > Phone: 801.887.9823 > FAX: 801.972.5789 > Email: knorseth@enterasys.com > www: http://www.enterasys.com > <> > --------------BCDB6AA258DCF9EE5566EB80 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Having 3 alternatives loses the meaning of standardization.

Peram

"K.C. Norseth" wrote:

I have no problem with that.  The data draft needed something in layout more than a line saying we can consider LFAP,CRANE, or NetFlow, so I brought up the Cisco draft as a basis for starting..  The individual elements defined are much better using the other documents.  That has always been a weakness of NetFlow, defining the elements of the data where people didn't have to search for answers. I wonder if you could give me the CRANE alternative to section 5, and Paul an LFAP alternative?  What I could do is put in 3 different section 5's in te data draft for people to see.  The team draft we submit can eaasily have 3 alternatives. K.C.
----- Original Message -----
Sent: Friday, February 15, 2002 4:17 PM
Subject: RE: [ipfix] IPFIX Design draft updates
 Hi KC,The architecture draft looks quite good to me, and I believe the addition from Beniot and Ganesh's text really strengthened the document. The entire section 5 of the data draft is very troublesome.  If I remember correctly, at the conference call several weeks ago, we (including Cisco) agreed that the Cisco draft dived into protocol too soon, and we should complete the architecture and the data model documents before assessing/selecting a protocol. The message formats definitely belong to a protocol specification, not the data model draft. I suggest to remove entire section 5 from the data model draft. If the group decides that the data model draft will specify messages passing between IPFIX end-points, I suggest we include the formats from LFAF and CRANE as they were proposed as candidate protocols just like Netflow. Thanks,Kevin-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Norseth, KC
Sent: Friday, February 15, 2002 2:52 PM
To: 'ipfix@net.doit.wisc.edu'
Subject: [ipfix] IPFIX Design draft updates
 
IPFIX People.

I have updated both the team architectural and data drafts.  The .txt versions are enclosed.  If someone wants them in Word format. Let me know.  I am not worried at the moment of pagenation and

Changes to the drafts:

Architecture:

  • Reordering sections and better integration of the sections from Beniot and Ganesh's draft.
  • Further definition of some areas.
  • Spelling and grammer
Data:
  • Integrating sections Beniot and Ganesh's draft.
  • Further definition of some areas.
  • Clarification of element types and how to define them.  Now I need is the TC's to go along with each element.
  • Spelling and grammer
If I have missed some updates to the draft, let me know.

If you have any questions, just ask.  Please give as many comments to the group as possible over the weekend, where the "editorial review" board is going to review everything on Monday.

As recommended by Nevil, I will submit this as an individual draft, submitted by the design group.  This way, reguardless of how the editoral board combines /removes text, this will be recorded for Minneapolis so it can be discussed as needed, just Benoit and Ganesh's  is.  It will also be given an IPFIX team name, not IETF-IPFIX.

K.C.
<<draft-ietf-ipfix-data-00.txt>> <<draft-ietf-ipfix-architecture-00.txt>>
K.C. Norseth
Firmware Engineering -  Routing
Enterasys Networks
   Phone: 801.887.9823
   FAX:    801.972.5789
   Email:   knorseth@enterasys.com
   www:    http://www.enterasys.com
<<Norseth, KC.vcf>>

--------------BCDB6AA258DCF9EE5566EB80-- -- 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 Sat Feb 16 13:23:27 2002 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 NAA15096 for ; Sat, 16 Feb 2002 13:23:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16c9At-0005wk-00 for ipfix-list@mil.doit.wisc.edu; Sat, 16 Feb 2002 12:03:03 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16c9Ar-0005vg-00 for ipfix-req@net.doit.wisc.edu; Sat, 16 Feb 2002 12:03:01 -0600 Received: from peter ([192.168.254.182]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1GI31l12930; Sat, 16 Feb 2002 10:03:01 -0800 From: "Peter Ludemann" To: "Juergen Quittek" , "Reinaldo Penno" , , "Benoit Claise" Cc: , , , "Kevin Zhang" Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Sat, 16 Feb 2002 10:01:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <264221648.1013876503@[192.168.102.31]> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen: Thank-you for pointing out the apparent self-contradiction in my argument. I neglected to complete me argument. I'm glad that everyone agrees on the need for self-describing data. It wasn't clear from all the emails that were flying back and forth. :-) I'd like to address the two other issues that are not yet agreed to: - content negotiation (which extends content advertisement) - configuration of processing (sampling rates, ports, etc.) Some devices are very simple and have no need for any kind of content negotiation. Others (such as our PacketSight probe, which can have over 200 fields) are quite complex and can benefit greatly from content negotiation. The capability to respond to a content request is NOT optional. Every request MUST be answered; but the answer can be to reject the request, to honour it, or to partially honour it. For example: exporter advertises fields A,B,C,D receiver requests only fields A,D exporter responds with: fields A,B,C,D -- if it ignores the request fields A,D -- if it completely honours the request fields A,C,D -- if it partially honours the request One of our concerns with content negotiation was in minimising the development work for putting the transport protocol onto a network element (our target is 2 weeks or less). If the device already has the data available in a particular form, we want to be able to export it as-is. For example, the exporting device determines whether big-endian or little-endian numbers are used; the receiver translates as necessary. This has the advantages: - simpler implementation on the exporting device - minimal performance impact on the exporting device - minimal space requirements on the exporting device Of course, if the exporting device wants to switch the data from little-endian to big-endian (network byte order), we aren't going to prevent it. But we cater to the exporter's needs, not the receiver's. If the exporting device can take advantage of sending fewer fields, it can; but if simplicity of implementation or performance concerns would make it better to ignore content requests, that's also OK. Moving on to the second point: But as 'in-band configuration' i understand the more basic configuration of meter and exporter including which ports to observe, which filtering rules to apply, which flow keys to use, which sampling rate to choose, etc. I would like this kind of configuration also; but I think it is less necessary than content negotiation. Content information must be communicated amongst all the receivers (in a fail-over configuration), so simply using MIBs or a CLI won't work very well. However, the issues of determining sampling rate, observed ports, etc. do not need to be distributed in the same way (if needed, they can be exported as just another kind of record from the network device). I think that this kind of configuration will always remain "machine specific". But it can fit into a very simple structure, something like a list of attribute/value pairs being sent from the receiving device and a accepted/rejected message being sent back [the configuration must do multiple items together because there can be interactions amongst them]. This is similar to the way configuration is done using a MIB, except that it would get around some of the problems with MIB configuration (interactions amongst attributes, confirmation of result, multiple tools needed to do configuration, etc.). To sum up: we need a framework for all the configuration, without requiring agreement on the content (which we might never be able to, especially with backwards support for existing equipment). This is similar to the self-describing data delivery ... the requirement is that data be self-describing and that it contain type information, not that we all agree to a specific data model (there eventually will be standard data models, of course). Similarly, we should agree to a method of in-band content negotiation and processing configuration. - peter ---- Peter Ludemann peter.ludemann@xacct.com Chief Architect +1.408.330.5732 XACCT Technologies, Inc. 2900 Lakeside Drive Santa Clara, CA 95054 -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Juergen Quittek Sent: Saturday, February 16, 2002 7:22 AM To: Peter Ludemann; Reinaldo Penno; calato@riverstonenet.com; Benoit Claise Cc: ram.gopal@nokia.com; zander@fokus.gmd.de; ipfix-req@net.doit.wisc.edu; Kevin Zhang Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Hi Peter, --On 15 February 2002 08:53 -0800 Peter Ludemann wrote: > Juergen Quittek wrote Thursday, February 14, 2002 2:30 PM: > >> So what is your point? Do you want to have in-band configuration >> for the exported attributes/IEs in the requirements document? > > Yes. The CRANE protocol solves real problems that we've encountered; and we > have a number of partners who are using it (sorry, I can't announce these > right now). > >> What would be the application requiring this? Or from which >> general requirement would you derive this one? > > My answer is a little long. Our requirements go beyond just delivering the > kind of data that IPFIX is discussing; but I think that they are very > applicable to IPFIX. > > If all you care about is delivering one set of values which you'll never > change, then there's no need for any in-band configuration. (This would be > true only if you think that the data architecture folks will agree on a > specification with no SHOULDs in the document ...) > > If you anticipate change, then at minimum you need to specify the version of > the data that you're delivering. A more general solution is to use > self-describing data. XML would be fine but it's much too verbose for > delivering thousands of records per second from a small network device. > > So, the minimal requirement is to have some way for the device to advertise > what it has. I don't see a need for all of XML's nesting capabilities; a > simple 2-level scheme (type of record + fields) should suffice. As far, as I followed the ongoing difscussion, (almost) everyone agrees to this. > The receiver could quietly take this advertisement and process it. But our > experience in "IP data mediation" is that people usually only want specific > fields; and they typically want to post-process them. Examples of such > post-processing: associating values with IP addresses (e.g., reversing NAT, > mapping IP to customer), aggregation, filtering, conditional splitting, etc. > plus a host of database-oriented processing, such as looking for error > patterns, for people who hog bandwidth, etc. > > If the sending device can be configured by a MIB or CLI, the receiver can > adapt to what it advertises. But there are good reasons for such > configuration to be done by response from the receiver: > - the needed fields can be derived from the post-processing configuration, > so they naturally reside on the receiver, not the sender > - there can be tens or even thousands of sending devices, so > centralized configuration is desirable (especially if they can't all > have their versions changed simultaneously) > - there needs to be a way of coordinating amongst multiple receivers, > for fail-over deployments > (these aren't hypothetical requirements: we have customers who are looking > at deploying thousands of sending devices; and who require fail-over) > > Once you decide that the sender should advertises its data, it doesn't take > much more work to allow the receiver to respond with a list of fields that > it does or doesn't want. The sender can just mark the fields it won't send. > The advantages of this are: > - bandwidth saving (probably not very important) > - computation saving on the sender (this can be significant > in our experience) I think we are discussing two different issues. Your suggestion covers - as far as I have understood so far - the negotiation between sender an receiver about individual attributes/fields/IEs to be sent. But as 'in-band configuration' i understand the more basic configuration of meter and exporter including which ports to observe, which filtering rules to apply, which flow keys to use, which sampling rate to choose, etc. But coming back to your point: If you say the exporter may ignore it, why then making it a requirement? Requirements should be essentially needed and not just nice to have, but opyionally ignored at any time. I think your point can be a valuable contribution to the architecture, but following your argument it does not belong into the requirement docvument. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Our proposal makes it OPTIONAL for the sender to respond to the > configuration request. The sender can ignore the configuration request and > still send all the fields -- the receiver will just have to accept them (and > throw away what it doesn't want). But if the sender can take advantage of > the configuration request (e.g., turning off expensive computations), then > it has a simple mechanism for doing so. > > > ---- > > Peter Ludemann > Chief Architect, XACCT > +1.408.330.5732 > -- 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/ -- 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 Sat Feb 16 16:06:30 2002 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 QAA16605 for ; Sat, 16 Feb 2002 16:06:30 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cBdj-0001HA-00 for ipfix-list@mil.doit.wisc.edu; Sat, 16 Feb 2002 14:40:59 -0600 Received: from c001-h000.c001.snv.cp.net ([209.228.32.114] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16cBdg-0001FU-00 for ipfix@net.doit.wisc.edu; Sat, 16 Feb 2002 14:40:56 -0600 Received: (cpmta 27915 invoked from network); 16 Feb 2002 12:40:23 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.114) with SMTP; 16 Feb 2002 12:40:23 -0800 X-Sent: 16 Feb 2002 20:40:23 GMT Message-ID: <001501c1b72a$8af7f560$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: "Peram Marimuthu" Cc: , "Norseth, KC" , References: <002e01c1b67a$c146ea00$850f880a@slc252750> <3C6E836B.640BA25B@cisco.com> Subject: 3 definitions (was Re: [ipfix] IPFIX Design draft updates) Date: Sat, 16 Feb 2002 13:43:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C1B6EF.DD742560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C1B6EF.DD742560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peram, At the moment, we have no standard. We have flow accounting = implementations in place already, NetFlow, CRANE, and LFAP are three of = these. They all have merits. For us to say that NetFlow is the best = without the concensus of the group is wrong. What I am proposing is = that we provide 3 alternatives for people to see and comment on. These = 3 alternatives will be narrowly focused (Just a section 5 equivalent = definition) enough so that the overlapping information is removed, and = they can focus on what is there. From the concensus of the WG people, = we can create SYNERGY from the 3 proposals and build our standard. =20 In this first draft, there is no rule that says we have to have a = polished protocol. The Rough concensus of the IPFIX WG needs to be = asked for. I expect the first draft will be the most important to get = our thoughts across. After Minneapolis, we will have an emerging = standard from these presented. We do not not have to have 100% approval, althoug that would be our = dream. Remember, that for a standard to be accepted, we need rough = concensus and running code. Not one or the other, but both. K.C. ----- Original Message -----=20 From: Peram Marimuthu=20 To: K.C. Norseth=20 Cc: kevin.zhang@xacct.com ; Norseth, KC ; ipfix@net.doit.wisc.edu=20 Sent: Saturday, February 16, 2002 9:06 AM Subject: Re: [ipfix] IPFIX Design draft updates Having 3 alternatives loses the meaning of standardization.=20 Peram=20 "K.C. Norseth" wrote:=20 I have no problem with that. The data draft needed something in = layout more than a line saying we can consider LFAP,CRANE, or NetFlow, = so I brought up the Cisco draft as a basis for starting.. The = individual elements defined are much better using the other documents. = That has always been a weakness of NetFlow, defining the elements of the = data where people didn't have to search for answers. I wonder if you = could give me the CRANE alternative to section 5, and Paul an LFAP = alternative? What I could do is put in 3 different section 5's in te = data draft for people to see. The team draft we submit can eaasily have = 3 alternatives. K.C.=20 ----- Original Message ----- From: Kevin Zhang To: Norseth, KC ; ipfix@net.doit.wisc.edu Sent: Friday, February 15, 2002 4:17 PM Subject: RE: [ipfix] IPFIX Design draft updates Hi KC,The architecture draft looks quite good to me, and I = believe the addition from Beniot and Ganesh's text really strengthened = the document. The entire section 5 of the data draft is very = troublesome. If I remember correctly, at the conference call several = weeks ago, we (including Cisco) agreed that the Cisco draft dived into = protocol too soon, and we should complete the architecture and the data = model documents before assessing/selecting a protocol. The message = formats definitely belong to a protocol specification, not the data = model draft. I suggest to remove entire section 5 from the data model = draft. If the group decides that the data model draft will specify = messages passing between IPFIX end-points, I suggest we include the = formats from LFAF and CRANE as they were proposed as candidate protocols = just like Netflow. Thanks,Kevin-----Original Message-----=20 From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On = Behalf Of Norseth, KC=20 Sent: Friday, February 15, 2002 2:52 PM=20 To: 'ipfix@net.doit.wisc.edu'=20 Subject: [ipfix] IPFIX Design draft updates=20 =20 IPFIX People.=20 I have updated both the team architectural and data drafts. The = .txt versions are enclosed. If someone wants them in Word format. Let = me know. I am not worried at the moment of pagenation and=20 Changes to the drafts:=20 Architecture:=20 a.. Reordering sections and better integration of the sections = from Beniot and Ganesh's draft.=20 b.. Further definition of some areas.=20 c.. Spelling and grammer=20 Data:=20 a.. Integrating sections Beniot and Ganesh's draft.=20 b.. Further definition of some areas.=20 c.. Clarification of element types and how to define them. = Now I need is the TC's to go along with each element.=20 d.. Spelling and grammer=20 If I have missed some updates to the draft, let me know.=20 If you have any questions, just ask. Please give as many = comments to the group as possible over the weekend, where the "editorial = review" board is going to review everything on Monday.=20 As recommended by Nevil, I will submit this as an individual = draft, submitted by the design group. This way, reguardless of how the = editoral board combines /removes text, this will be recorded for = Minneapolis so it can be discussed as needed, just Benoit and Ganesh's = is. It will also be given an IPFIX team name, not IETF-IPFIX.=20 K.C.=20 <> = <>=20 K.C. Norseth=20 Firmware Engineering - Routing=20 Enterasys Networks=20 Phone: 801.887.9823=20 FAX: 801.972.5789=20 Email: knorseth@enterasys.com=20 www: http://www.enterasys.com=20 <> ------=_NextPart_000_0010_01C1B6EF.DD742560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Peram,
 
At the moment, we have no = standard.  We have=20 flow accounting implementations in place already, NetFlow, CRANE, and = LFAP are=20 three of these.  They all have merits.  For us to say = that=20 NetFlow is the best without the concensus of the group is wrong.  = What I am=20 proposing is that we provide 3 alternatives for people to see and = comment=20 on.  These 3 alternatives will be narrowly focused (Just a section = 5=20 equivalent definition) enough so that the overlapping information is = removed,=20 and they can focus on what is there.  From the concensus of the WG = people,=20 we can create SYNERGY from the 3 proposals and build our standard.  =
 
In this first draft, there is no rule = that says we=20 have to have a polished protocol.  The Rough concensus of the IPFIX = WG=20 needs to be asked for.  I expect the first draft will be the most = important=20 to get our thoughts across.  After Minneapolis, we will have an = emerging=20 standard from these presented.
 
We do not not have to have 100% = approval, althoug=20 that would be our dream.  Remember, that for a standard to be = accepted, we=20 need rough concensus and running code.  Not one or the other, but=20 both.
 
K.C.
 
----- Original Message -----
From:=20 Peram = Marimuthu=20
Cc: kevin.zhang@xacct.com ; Norseth,=20 KC ; ipfix@net.doit.wisc.edu
Sent: Saturday, February 16, = 2002 9:06=20 AM
Subject: Re: [ipfix] IPFIX = Design draft=20 updates

Having 3 alternatives loses the meaning of = standardization.=20

Peram=20

"K.C. Norseth" wrote:=20

I have no problem with = that.  The data=20 draft needed something in layout more than a line saying we can = consider=20 LFAP,CRANE, or NetFlow, so I brought up the Cisco draft as a basis = for=20 starting..  The individual elements defined are much better = using the=20 other documents.  That has always been a weakness of NetFlow, = defining=20 the elements of the data where people didn't have to search for=20 answers. I = wonder if you=20 could give me the CRANE alternative to section 5, and Paul an LFAP=20 alternative?  What I could do is put in 3 different section 5's = in te=20 data draft for people to see.  The team draft we submit can = eaasily=20 have 3 alternatives. K.C.=20
----- Original Message -----
From:=20 Kevin=20 Zhang
To: Norseth,=20 KC ; ipfix@net.doit.wisc.edu
Sent: Friday, February 15, = 2002 4:17=20 PM
Subject: RE: [ipfix] IPFIX = Design=20 draft updates
 Hi=20 KC,The = architecture draft looks=20 quite good to me, and I believe the addition from Beniot and = Ganesh's text=20 really strengthened the=20 document. The entire = section 5 of the=20 data draft is very troublesome.  If I remember correctly, at = the=20 conference call several weeks ago, we (including Cisco) agreed = that the=20 Cisco draft dived into protocol too soon, and we should complete = the=20 architecture and the data model documents before = assessing/selecting a=20 protocol. The message formats definitely belong to a protocol=20 specification, not the data model draft. I suggest to remove entire section 5 = from the=20 data model draft. If the group = decides that the=20 data model draft will specify messages passing between IPFIX = end-points, I=20 suggest we include the formats from LFAF and CRANE as they were = proposed=20 as candidate protocols just like=20 Netflow. Thanks,Kevin-----Original Message-----
From: majordomo listserver = [mailto:majordomo@mil.doit.wis= c.edu]On=20 Behalf Of Norseth, KC
Sent: Friday, February 15, 2002 2:52 = PM=20
To:=20 'ipfix@net.doit.wisc.edu'
Subject: [ipfix] IPFIX Design draft = updates=20
 =20
IPFIX People.=20

I have updated both the = team=20 architectural and data drafts.  The .txt versions are=20 enclosed.  If someone wants them in Word format. Let me = know. =20 I am not worried at the moment of pagenation and=20

Changes to the = drafts:=20

Architecture:=20

  • Reordering sections and = better=20 integration of the sections from Beniot and Ganesh's=20 draft.=20
  • Further definition of = some=20 areas.=20
  • Spelling and = grammer=20
Data:=20
  • Integrating sections = Beniot and=20 Ganesh's draft.=20
  • Further definition of = some=20 areas.=20
  • Clarification of = element types and=20 how to define them.  Now I need is the TC's to go along = with each=20 element.=20
  • Spelling and = grammer=20
If I have missed = some updates=20 to the draft, let me know.=20

If you have any questions, = just=20 ask.  Please give as many comments to the group as possible = over=20 the weekend, where the "editorial review" board is going to = review=20 everything on Monday.=20

As recommended by Nevil, I = will submit=20 this as an individual draft, submitted by the design = group.  This=20 way, reguardless of how the editoral board combines /removes = text, this=20 will be recorded for Minneapolis so it can be discussed as = needed, just=20 Benoit and Ganesh's  is.  It will also be given an = IPFIX team=20 name, not IETF-IPFIX.=20

K.C. =
<<draft-ietf-ipfix-data-00.txt>>=20 = <<draft-ietf-ipfix-architecture-00.txt>>= =20
K.C.=20 Norseth
Firmware Engineering - =20 Routing
Enterasys = Networks=20
   = Phone:=20 801.887.9823
   FAX:    = 801.972.5789
   Email:   knorseth@enterasys.com =
  =20 www:    http://www.enterasys.com=20
<<Norseth,=20 = KC.vcf>>

------=_NextPart_000_0010_01C1B6EF.DD742560-- -- 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 Sat Feb 16 19:37:21 2002 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 TAA18805 for ; Sat, 16 Feb 2002 19:37:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cEwb-0005R6-00 for ipfix-list@mil.doit.wisc.edu; Sat, 16 Feb 2002 18:12:41 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cEwZ-0005QD-00 for ipfix@net.doit.wisc.edu; Sat, 16 Feb 2002 18:12:39 -0600 Received: from mira-sjcd-2.cisco.com (mira-sjcd-2.cisco.com [171.69.43.46]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1GLqJE22886; Sat, 16 Feb 2002 13:52:19 -0800 (PST) Received: from cisco.com (sjc-vpn1-721.cisco.com [10.21.98.209]) by mira-sjcd-2.cisco.com (Mirapoint) with ESMTP id ABZ00528; Sat, 16 Feb 2002 13:49:48 -0800 (PST) Message-ID: <3C6ED48D.DA434090@cisco.com> Date: Sat, 16 Feb 2002 13:52:14 -0800 From: Peram Marimuthu X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "K.C. Norseth" CC: kevin.zhang@xacct.com, "Norseth, KC" , ipfix@net.doit.wisc.edu Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design draft updates) References: <002e01c1b67a$c146ea00$850f880a@slc252750> <3C6E836B.640BA25B@cisco.com> <001501c1b72a$8af7f560$850f880a@slc252750> Content-Type: multipart/alternative; boundary="------------C605FCB9242C1B906BCD52C6" Precedence: bulk Sender: majordomo listserver --------------C605FCB9242C1B906BCD52C6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit KC, There are separate documents for everyone to look at and evaluate the merits and short comings of each protocol. To say, IPfix offers a choice of 3 alternatives is as good as not standardization at all. We need to take a suitable path which proposes a middle ground with all the benefits. Since Nevil has suggested an editorial team of 5, I would suggest that you discuss Netflow, LFAP and Crane amongst yourselves and come out with a suitable proposal to the IPfix mailing list. We can all discuss your suggestions at that point. We need rough consensus, but we also need to make progress. Having 3 proposals on the table will definitely make it slower at Minneapolis. Peram "K.C. Norseth" wrote: > Hi Peram, At the moment, we have no standard. We have flow accounting implementations > in place already, NetFlow, CRANE, and LFAP are three of these. They all have merits. > For us to say that NetFlow is the best without the concensus of the group is wrong. > What I am proposing is that we provide 3 alternatives for people to see and comment on. > These 3 alternatives will be narrowly focused (Just a section 5 equivalent definition) > enough so that the overlapping information is removed, and they can focus on what is > there. From the concensus of the WG people, we can create SYNERGY from the 3 proposals > and build our standard. In this first draft, there is no rule that says we have to have > a polished protocol. The Rough concensus of the IPFIX WG needs to be asked for. I > expect the first draft will be the most important to get our thoughts across. After > Minneapolis, we will have an emerging standard from these presented. We do not not have > to have 100% approval, althoug that would be our dream. Remember, that for a standard > to be accepted, we need rough concensus and running code. Not one or the other, but > both. K.C. > > > ----- Original Message ----- > From: Peram Marimuthu > To: K.C. Norseth > Cc: kevin.zhang@xacct.com ; Norseth, KC ; ipfix@net.doit.wisc.edu > Sent: Saturday, February 16, 2002 9:06 AM > Subject: Re: [ipfix] IPFIX Design draft updates > Having 3 alternatives loses the meaning of standardization. > > Peram > > "K.C. Norseth" wrote: > > > I have no problem with that. The data draft needed something in layout more > > than a line saying we can consider LFAP,CRANE, or NetFlow, so I brought up > > the Cisco draft as a basis for starting.. The individual elements defined > > are much better using the other documents. That has always been a weakness > > of NetFlow, defining the elements of the data where people didn't have to > > search for answers. I wonder if you could give me the CRANE alternative to > > section 5, and Paul an LFAP alternative? What I could do is put in 3 > > different section 5's in te data draft for people to see. The team draft we > > submit can eaasily have 3 alternatives. K.C. > > > > ----- Original Message ----- > > From: Kevin Zhang > > To: Norseth, KC ; ipfix@net.doit.wisc.edu > > Sent: Friday, February 15, 2002 4:17 PM > > Subject: RE: [ipfix] IPFIX Design draft updates > > Hi KC,The architecture draft looks quite good to me, and I believe > > the addition from Beniot and Ganesh's text really strengthened the > > document. The entire section 5 of the data draft is very > > troublesome. If I remember correctly, at the conference call > > several weeks ago, we (including Cisco) agreed that the Cisco > > draft dived into protocol too soon, and we should complete the > > architecture and the data model documents before > > assessing/selecting a protocol. The message formats definitely > > belong to a protocol specification, not the data model draft. I > > suggest to remove entire section 5 from the data model draft. If > > the group decides that the data model draft will specify messages > > passing between IPFIX end-points, I suggest we include the formats > > from LFAF and CRANE as they were proposed as candidate protocols > > just like Netflow. Thanks,Kevin-----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On > > Behalf Of Norseth, KC > > Sent: Friday, February 15, 2002 2:52 PM > > To: 'ipfix@net.doit.wisc.edu' > > Subject: [ipfix] IPFIX Design draft updates > > > > > > IPFIX People. > > > > I have updated both the team architectural and data > > drafts. The .txt versions are enclosed. If someone > > wants them in Word format. Let me know. I am not > > worried at the moment of pagenation and > > > > Changes to the drafts: > > > > Architecture: > > > > * Reordering sections and better integration of the > > sections from Beniot and Ganesh's draft. > > * Further definition of some areas. > > * Spelling and grammer > > > > Data: > > > > * Integrating sections Beniot and Ganesh's draft. > > * Further definition of some areas. > > * Clarification of element types and how to define > > them. Now I need is the TC's to go along with each > > element. > > * Spelling and grammer > > > > If I have missed some updates to the draft, let me know. > > > > If you have any questions, just ask. Please give as > > many comments to the group as possible over the weekend, > > where the "editorial review" board is going to review > > everything on Monday. > > > > As recommended by Nevil, I will submit this as an > > individual draft, submitted by the design group. This > > way, reguardless of how the editoral board combines > > /removes text, this will be recorded for Minneapolis so > > it can be discussed as needed, just Benoit and Ganesh's > > is. It will also be given an IPFIX team name, not > > IETF-IPFIX. > > > > K.C. > > <> > > <> > > K.C. Norseth > > Firmware Engineering - Routing > > Enterasys Networks > > Phone: 801.887.9823 > > FAX: 801.972.5789 > > Email: knorseth@enterasys.com > > www: http://www.enterasys.com > > <> > > --------------C605FCB9242C1B906BCD52C6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit KC,

There are separate documents for everyone to look at and evaluate the merits
and short comings of each protocol. To say, IPfix offers a choice of 3 alternatives
is as good as not standardization at all. We need to take a suitable path which proposes
a middle ground with all the benefits.

Since Nevil has suggested an editorial team of 5, I would suggest that you discuss
Netflow, LFAP and Crane amongst yourselves and come out with a suitable proposal to
the IPfix mailing list. We can all discuss your suggestions at that point.

We need rough consensus, but we also need to make progress. Having 3 proposals on the
table will definitely make it slower at Minneapolis.

Peram

"K.C. Norseth" wrote:

 Hi Peram, At the moment, we have no standard.  We have flow accounting implementations in place already, NetFlow, CRANE, and LFAP are three of these.  They all have merits.  For us to say that NetFlow is the best without the concensus of the group is wrong.  What I am proposing is that we provide 3 alternatives for people to see and comment on.  These 3 alternatives will be narrowly focused (Just a section 5 equivalent definition) enough so that the overlapping information is removed, and they can focus on what is there.  From the concensus of the WG people, we can create SYNERGY from the 3 proposals and build our standard. In this first draft, there is no rule that says we have to have a polished protocol.  The Rough concensus of the IPFIX WG needs to be asked for.  I expect the first draft will be the most important to get our thoughts across.  After Minneapolis, we will have an emerging standard from these presented. We do not not have to have 100% approval, althoug that would be our dream.  Remember, that for a standard to be accepted, we need rough concensus and running code.  Not one or the other, but both. K.C.
 
----- Original Message -----
Sent: Saturday, February 16, 2002 9:06 AM
Subject: Re: [ipfix] IPFIX Design draft updates
 Having 3 alternatives loses the meaning of standardization.

Peram

"K.C. Norseth" wrote:

I have no problem with that.  The data draft needed something in layout more than a line saying we can consider LFAP,CRANE, or NetFlow, so I brought up the Cisco draft as a basis for starting..  The individual elements defined are much better using the other documents.  That has always been a weakness of NetFlow, defining the elements of the data where people didn't have to search for answers. I wonder if you could give me the CRANE alternative to section 5, and Paul an LFAP alternative?  What I could do is put in 3 different section 5's in te data draft for people to see.  The team draft we submit can eaasily have 3 alternatives. K.C.
----- Original Message -----
Sent: Friday, February 15, 2002 4:17 PM
Subject: RE: [ipfix] IPFIX Design draft updates
Hi KC,The architecture draft looks quite good to me, and I believe the addition from Beniot and Ganesh's text really strengthened the document. The entire section 5 of the data draft is very troublesome.  If I remember correctly, at the conference call several weeks ago, we (including Cisco) agreed that the Cisco draft dived into protocol too soon, and we should complete the architecture and the data model documents before assessing/selecting a protocol. The message formats definitely belong to a protocol specification, not the data model draft. I suggest to remove entire section 5 from the data model draft. If the group decides that the data model draft will specify messages passing between IPFIX end-points, I suggest we include the formats from LFAF and CRANE as they were proposed as candidate protocols just like Netflow. Thanks,Kevin-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Norseth, KC
Sent: Friday, February 15, 2002 2:52 PM
To: 'ipfix@net.doit.wisc.edu'
Subject: [ipfix] IPFIX Design draft updates
 
IPFIX People.

I have updated both the team architectural and data drafts.  The .txt versions are enclosed.  If someone wants them in Word format. Let me know.  I am not worried at the moment of pagenation and

Changes to the drafts:

Architecture:

  • Reordering sections and better integration of the sections from Beniot and Ganesh's draft.
  • Further definition of some areas.
  • Spelling and grammer
Data:
  • Integrating sections Beniot and Ganesh's draft.
  • Further definition of some areas.
  • Clarification of element types and how to define them.  Now I need is the TC's to go along with each element.
  • Spelling and grammer
If I have missed some updates to the draft, let me know.

If you have any questions, just ask.  Please give as many comments to the group as possible over the weekend, where the "editorial review" board is going to review everything on Monday.

As recommended by Nevil, I will submit this as an individual draft, submitted by the design group.  This way, reguardless of how the editoral board combines /removes text, this will be recorded for Minneapolis so it can be discussed as needed, just Benoit and Ganesh's  is.  It will also be given an IPFIX team name, not IETF-IPFIX.

K.C.
<<draft-ietf-ipfix-data-00.txt>> <<draft-ietf-ipfix-architecture-00.txt>>
K.C. Norseth
Firmware Engineering -  Routing
Enterasys Networks
   Phone: 801.887.9823
   FAX:    801.972.5789
   Email:   knorseth@enterasys.com
   www:    http://www.enterasys.com
<<Norseth, KC.vcf>>

--------------C605FCB9242C1B906BCD52C6-- -- 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 Sat Feb 16 19:56:00 2002 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 TAA18965 for ; Sat, 16 Feb 2002 19:56:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cFCt-0005hn-00 for ipfix-list@mil.doit.wisc.edu; Sat, 16 Feb 2002 18:29:31 -0600 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cFCr-0005he-00 for ipfix@net.doit.wisc.edu; Sat, 16 Feb 2002 18:29:29 -0600 Received: from auckland.ac.nz (root@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id MAA23924; Sun, 17 Feb 2002 12:36:27 +1300 (NZDT) Message-Id: <200202162336.MAA23924@mailhost.auckland.ac.nz> Date: Sat, 16 Feb 2002 17:31:38 -0800 (PST) From: n.brownlee@auckland.ac.nz Subject: Re: [ipfix] WG process: next steps To: kevin.zhang@xacct.com, ram.gopal@nokia.com cc: ipfix@net.doit.wisc.edu, plonka@doit.wisc.edu, n.brownlee@auckland.ac.nz In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Hello Kevin and Ram: Thanks for your emails, both asking how I'd come to choose the 5 people for Monday's teleconference. As I tried to point out in that note, I'm pushing the WG towards having a -00 (i.e a starting point) pair of IPFIX drafts. To get that done before Friday I'm sure we need to keep the group small, so I chose an arbitrary cutoff point. As I also said, the -00 drafts are a starting point. We can - indeed, will - discuss the question of how we acknowledge all the WG input at the Minneapolis meeting. In particular, the people doing the editing through next week are not neccessarily the ones who will be the document authors. As my next suggestion for that, how about picking one author from each of the groups that have published individual drafts within IPFIX? Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand -- 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 Sat Feb 16 19:56:13 2002 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 TAA18977 for ; Sat, 16 Feb 2002 19:56:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cFHc-0005q9-00 for ipfix-list@mil.doit.wisc.edu; Sat, 16 Feb 2002 18:34:24 -0600 Received: from rip.psg.com ([147.28.0.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cFHa-0005pO-00 for ipfix@net.doit.wisc.edu; Sat, 16 Feb 2002 18:34:22 -0600 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16cFGx-000635-00; Sat, 16 Feb 2002 16:33:43 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peram Marimuthu Cc: ipfix@net.doit.wisc.edu Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design draft updates) References: <002e01c1b67a$c146ea00$850f880a@slc252750> <3C6E836B.640BA25B@cisco.com> <001501c1b72a$8af7f560$850f880a@slc252750> <3C6ED48D.DA434090@cisco.com> Message-Id: Date: Sat, 16 Feb 2002 16:33:43 -0800 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit [ ad hat on ] > To say, IPfix offers a choice of 3 alternatives is as good as not > standardization at all. from the wg charter: "This group will select a protocol ..." note the use of the singular. and note "select," not "invent." and "Specific Goals o Define the notion of a "standard IP flow." The flow definition will be a practical one, similar to those currently in use by existing non-standard flow information export protocols which have attempted to achieve similar goals but have not documented their flow defintion." > We need to take a suitable path which proposes a middle ground with > all the benefits. if it has all the benefits, uses congestion-aware transport, is not encumbered, ... it need not be a middle ground, just an effective one. note also "Goals and Milestones: Feb 02 Submit IPFX-REQUIREMENTS to IESG for publication as an Informational RFC Feb 02 Submit Internet-Draft on IP Flow Export Architecture Feb 02 Submit Internet-Draft on IP Flow Export Data Model" randy -- 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 Sat Feb 16 19:59:27 2002 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 TAA19040 for ; Sat, 16 Feb 2002 19:59:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cFJq-0005tJ-00 for ipfix-list@mil.doit.wisc.edu; Sat, 16 Feb 2002 18:36:42 -0600 Received: from c001-h001.c001.snv.cp.net ([209.228.32.115] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16cFJo-0005si-00 for ipfix@net.doit.wisc.edu; Sat, 16 Feb 2002 18:36:40 -0600 Received: (cpmta 18596 invoked from network); 16 Feb 2002 14:49:26 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.115) with SMTP; 16 Feb 2002 14:49:26 -0800 X-Sent: 16 Feb 2002 22:49:26 GMT Message-ID: <003d01c1b73c$924b1740$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: "Peram Marimuthu" Cc: , "Norseth, KC" , References: <002e01c1b67a$c146ea00$850f880a@slc252750> <3C6E836B.640BA25B@cisco.com> <001501c1b72a$8af7f560$850f880a@slc252750> <3C6ED48D.DA434090@cisco.com> Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design draft updates) Date: Sat, 16 Feb 2002 15:52:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C1B701.E4270FA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C1B701.E4270FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peram, Comments inline. ----- Original Message -----=20 From: Peram Marimuthu=20 To: K.C. Norseth=20 Cc: kevin.zhang@xacct.com ; Norseth, KC ; ipfix@net.doit.wisc.edu=20 Sent: Saturday, February 16, 2002 2:52 PM Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design draft = updates) KC,=20 There are separate documents for everyone to look at and evaluate the = merits=20 and short comings of each protocol. To say, IPfix offers a choice of 3 = alternatives=20 is as good as not standardization at all. We need to take a suitable = path which proposes=20 a middle ground with all the benefits.=20 What I said is that there are three solutions out there right now. From = these three solutions, we have 2 choices: 1: Adopt one of these choices = or 2: Build a standard from theses choices. For the merits of both to = be evaluated, it would be nice to see the differences side by side. I = never said that IPFIX would have at the end 3 different choices, just = three for people to look at and decide from. What I propose on the = design team draft is to have one section that defines each as concise as = possible for people so it is easy to decide if we adopt one or another = or combine. The section of concern before my last change said that there were three = possibilities. They did not explain the pros and cons. This can help. Since Nevil has suggested an editorial team of 5, I would suggest that = you discuss=20 Netflow, LFAP and Crane amongst yourselves and come out with a = suitable proposal to=20 the IPfix mailing list. We can all discuss your suggestions at that = point.=20 I am sure it will be discussed. The editorial boards responsibility is = to put together the first draft of IPFIX. I dont think we will have = enough consensus of the whole group to dictate only one alternative on = the first draft. If we have three alternatives clearly defined on the = first draft, and helps the WG make a decision quickly, so what? =20 We need rough consensus, but we also need to make progress. Having 3 = proposals on the=20 table will definitely make it slower at Minneapolis.=20 Progress is when we look at all sides for a solution. It costs more = when only one solution is provided and it ends up not being the best = one. History is clear in that. K.C. Peram=20 "K.C. Norseth" wrote:=20 Hi Peram, At the moment, we have no standard. We have flow = accounting implementations in place already, NetFlow, CRANE, and LFAP = are three of these. They all have merits. For us to say that NetFlow = is the best without the concensus of the group is wrong. What I am = proposing is that we provide 3 alternatives for people to see and = comment on. These 3 alternatives will be narrowly focused (Just a = section 5 equivalent definition) enough so that the overlapping = information is removed, and they can focus on what is there. From the = concensus of the WG people, we can create SYNERGY from the 3 proposals = and build our standard. In this first draft, there is no rule that says = we have to have a polished protocol. The Rough concensus of the IPFIX = WG needs to be asked for. I expect the first draft will be the most = important to get our thoughts across. After Minneapolis, we will have = an emerging standard from these presented. We do not not have to have = 100% approval, althoug that would be our dream. Remember, that for a = standard to be accepted, we need rough concensus and running code. Not = one or the other, but both. K.C.=20 ----- Original Message ----- From: Peram Marimuthu To: K.C. Norseth Cc: kevin.zhang@xacct.com ; Norseth, KC ; ipfix@net.doit.wisc.edu Sent: Saturday, February 16, 2002 9:06 AM Subject: Re: [ipfix] IPFIX Design draft updates Having 3 alternatives loses the meaning of standardization.=20 Peram=20 "K.C. Norseth" wrote:=20 I have no problem with that. The data draft needed something in = layout more than a line saying we can consider LFAP,CRANE, or NetFlow, = so I brought up the Cisco draft as a basis for starting.. The = individual elements defined are much better using the other documents. = That has always been a weakness of NetFlow, defining the elements of the = data where people didn't have to search for answers. I wonder if you = could give me the CRANE alternative to section 5, and Paul an LFAP = alternative? What I could do is put in 3 different section 5's in te = data draft for people to see. The team draft we submit can eaasily have = 3 alternatives. K.C.=20 ----- Original Message ----- From: Kevin Zhang To: Norseth, KC ; ipfix@net.doit.wisc.edu Sent: Friday, February 15, 2002 4:17 PM Subject: RE: [ipfix] IPFIX Design draft updates Hi KC,The architecture draft looks quite good to me, and I = believe the addition from Beniot and Ganesh's text really strengthened = the document. The entire section 5 of the data draft is very = troublesome. If I remember correctly, at the conference call several = weeks ago, we (including Cisco) agreed that the Cisco draft dived into = protocol too soon, and we should complete the architecture and the data = model documents before assessing/selecting a protocol. The message = formats definitely belong to a protocol specification, not the data = model draft. I suggest to remove entire section 5 from the data model = draft. If the group decides that the data model draft will specify = messages passing between IPFIX end-points, I suggest we include the = formats from LFAF and CRANE as they were proposed as candidate protocols = just like Netflow. Thanks,Kevin-----Original Message-----=20 From: majordomo listserver = [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Norseth, KC=20 Sent: Friday, February 15, 2002 2:52 PM=20 To: 'ipfix@net.doit.wisc.edu'=20 Subject: [ipfix] IPFIX Design draft updates=20 =20 IPFIX People.=20 I have updated both the team architectural and data drafts. = The .txt versions are enclosed. If someone wants them in Word format. = Let me know. I am not worried at the moment of pagenation and=20 Changes to the drafts:=20 Architecture:=20 a.. Reordering sections and better integration of the = sections from Beniot and Ganesh's draft.=20 b.. Further definition of some areas.=20 c.. Spelling and grammer=20 Data:=20 a.. Integrating sections Beniot and Ganesh's draft.=20 b.. Further definition of some areas.=20 c.. Clarification of element types and how to define them. = Now I need is the TC's to go along with each element.=20 d.. Spelling and grammer=20 If I have missed some updates to the draft, let me know.=20 If you have any questions, just ask. Please give as many = comments to the group as possible over the weekend, where the "editorial = review" board is going to review everything on Monday.=20 As recommended by Nevil, I will submit this as an individual = draft, submitted by the design group. This way, reguardless of how the = editoral board combines /removes text, this will be recorded for = Minneapolis so it can be discussed as needed, just Benoit and Ganesh's = is. It will also be given an IPFIX team name, not IETF-IPFIX.=20 K.C.=20 <> = <>=20 K.C. Norseth=20 Firmware Engineering - Routing=20 Enterasys Networks=20 Phone: 801.887.9823=20 FAX: 801.972.5789=20 Email: knorseth@enterasys.com=20 www: http://www.enterasys.com=20 <> ------=_NextPart_000_003A_01C1B701.E4270FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Peram,
 
Comments inline.
----- Original Message -----
From:=20 Peram = Marimuthu=20
Cc: kevin.zhang@xacct.com ; Norseth,=20 KC ; ipfix@net.doit.wisc.edu
Sent: Saturday, February 16, = 2002 2:52=20 PM
Subject: Re: 3 definitions (was = Re:=20 [ipfix] IPFIX Design draft updates)

KC,=20

There are separate documents for everyone to look at and evaluate = the=20 merits
and short comings of each protocol. To say, IPfix offers a = choice=20 of 3 alternatives
is as good as not standardization at all. We = need to=20 take a suitable path which proposes
a middle ground with all the = benefits.=20

What I said is that there are three solutions out there right = now.  From=20 these three solutions, we have 2 choices:  1: Adopt one of these=20 choices or 2: Build a standard from theses choices.  For the = merits of=20 both to be evaluated, it would be nice to see the differences side by=20 side.   I never said that IPFIX would have at the end 3 = different=20 choices, just three for people to look at and decide from. = What I=20 propose on the design team draft is to have one section that defines = each as=20 concise as possible for people so it is easy to decide if we adopt one = or=20 another or combine.

The section of concern before my last change said that there were = three=20 possibilities.  They did not explain the pros and cons. This can = help.

Since Nevil has suggested an editorial team of 5, I would suggest = that you=20 discuss
Netflow, LFAP and Crane amongst yourselves and come out = with a=20 suitable proposal to
the IPfix mailing list. We can all discuss = your=20 suggestions at that point.

I am sure it will be discussed.  The editorial boards = responsibility is=20 to put together the first draft of IPFIX.  I dont think we will = have enough=20 consensus of the whole group to dictate only one alternative on the = first=20 draft.  If we have three alternatives clearly defined on the first = draft,=20 and helps the WG make a decision quickly, so what? 

We need rough consensus, but we also need to make progress. Having = 3=20 proposals on the
table will definitely make it slower at = Minneapolis.=20

Progress is when we look at all sides for a solution.  It costs = more=20 when only one solution is provided and it ends up not being = the best=20 one.  History is clear in that.

K.C.

Peram=20

"K.C. Norseth" wrote:=20

 Hi=20 Peram, At the = moment, we=20 have no standard.  We have flow accounting implementations in = place=20 already, NetFlow, CRANE, and LFAP are three of these.  They all = have=20 merits.  For us to say that NetFlow is the best without the = concensus=20 of the group is wrong.  What I am proposing is that we provide = 3=20 alternatives for people to see and comment on.  These 3 = alternatives=20 will be narrowly focused (Just a section 5 equivalent definition) = enough so=20 that the overlapping information is removed, and they can focus on = what is=20 there.  From the concensus of the WG people, we can create = SYNERGY from=20 the 3 proposals and build our standard. In this first draft, there is no rule = that says we=20 have to have a polished protocol.  The Rough concensus of the = IPFIX WG=20 needs to be asked for.  I expect the first draft will be the = most=20 important to get our thoughts across.  After Minneapolis, we = will have=20 an emerging standard from these presented. We do not not have to have 100% = approval, althoug=20 that would be our dream.  Remember, that for a standard to be = accepted,=20 we need rough concensus and running code.  Not one or the = other, but=20 both. K.C.=20
 
----- Original Message -----
From:=20 Peram=20 Marimuthu
Cc: kevin.zhang@xacct.com ; Norseth,=20 KC ; ipfix@net.doit.wisc.edu
Sent: Saturday, February = 16, 2002=20 9:06 AM
Subject: Re: [ipfix] IPFIX = Design=20 draft updates
 Having 3 alternatives loses the meaning = of=20 standardization.=20

Peram=20

"K.C. Norseth" wrote:=20

I have no problem with = that.  The=20 data draft needed something in layout more than a line saying we = can=20 consider LFAP,CRANE, or NetFlow, so I brought up the Cisco draft = as a=20 basis for starting..  The individual elements defined are = much=20 better using the other documents.  That has always been a = weakness=20 of NetFlow, defining the elements of the data where people = didn't have=20 to search for answers. I=20 wonder if you could give me the CRANE alternative to section 5, = and Paul=20 an LFAP alternative?  What I could do is put in 3 different = section=20 5's in te data draft for people to see.  The team draft we = submit=20 can eaasily have 3 alternatives. K.C.=20
----- Original Message = -----
From:=20 Kevin Zhang
To: Norseth, KC ; ipfix@net.doit.wisc.edu
Sent: Friday, February = 15, 2002=20 4:17 PM
Subject: RE: [ipfix] = IPFIX Design=20 draft updates
Hi KC,The architecture draft looks quite = good to=20 me, and I believe the addition from Beniot and Ganesh's text = really=20 strengthened the document. The=20 entire section 5 of the data draft is very troublesome.  = If I=20 remember correctly, at the conference call several weeks ago, = we=20 (including Cisco) agreed that the Cisco draft dived into = protocol too=20 soon, and we should complete the architecture and the data = model=20 documents before assessing/selecting a protocol. The message = formats=20 definitely belong to a protocol specification, not the data = model=20 draft. I suggest = to remove=20 entire section 5 from the data model draft. If the=20 group decides that the data model draft will specify messages = passing=20 between IPFIX end-points, I suggest we include the formats = from LFAF=20 and CRANE as they were proposed as candidate protocols just = like=20 Netflow. Thanks,Kevin-----Original Message----- =
From: majordomo = listserver [mailto:majordomo@mil.doit.wis= c.edu]On=20 Behalf Of Norseth, KC
Sent: Friday, February 15, 2002 2:52 = PM=20
To:=20 'ipfix@net.doit.wisc.edu'
Subject: [ipfix] IPFIX Design draft=20 updates
 =20
IPFIX People.=20

I have updated both = the team=20 architectural and data drafts.  The .txt versions are=20 enclosed.  If someone wants them in Word format. Let me = know.  I am not worried at the moment of pagenation=20 and=20

Changes to the=20 drafts:=20

Architecture:=20

  • Reordering sections = and better=20 integration of the sections from Beniot and Ganesh's=20 draft.=20
  • Further definition = of some=20 areas.=20
  • Spelling and=20 grammer
Data:=20
  • Integrating = sections Beniot and=20 Ganesh's draft.=20
  • Further definition = of some=20 areas.=20
  • Clarification of = element types=20 and how to define them.  Now I need is the TC's to go = along=20 with each element.=20
  • Spelling and=20 grammer
If I=20 have missed some updates to the draft, let me = know.=20

If you have any = questions, just=20 ask.  Please give as many comments to the group as = possible=20 over the weekend, where the "editorial review" board is = going to=20 review everything on Monday.=20

As recommended by = Nevil, I will=20 submit this as an individual draft, submitted by the design=20 group.  This way, reguardless of how the editoral board = combines /removes text, this will be recorded for = Minneapolis so it=20 can be discussed as needed, just Benoit and Ganesh's  = is. =20 It will also be given an IPFIX team name, not=20 IETF-IPFIX.=20

K.C. =
<<draft-ietf-ipfix-data-00.txt>>=20 = <<draft-ietf-ipfix-architecture-00.txt>>= =20
K.C.=20 Norseth
Firmware Engineering -  = Routing
Enterasys=20 Networks
   Phone: 801.887.9823=20
  =20 FAX:    801.972.5789=20
  =20 Email:   knorseth@enterasys.com =
  =20 www:    http://www.enterasys.com=20
<<Norseth,=20 = KC.vcf>>

------=_NextPart_000_003A_01C1B701.E4270FA0-- -- 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 Sun Feb 17 11:45:02 2002 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 LAA08250 for ; Sun, 17 Feb 2002 11:45:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cTwj-0002kY-00 for ipfix-list@mil.doit.wisc.edu; Sun, 17 Feb 2002 10:13:49 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cTwf-0002k4-00 for ipfix@net.doit.wisc.edu; Sun, 17 Feb 2002 10:13:45 -0600 Received: from Kevinz (d96ddb7b.fsp.oleane.fr [217.109.219.123]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1HGDNl19282; Sun, 17 Feb 2002 08:13:23 -0800 Reply-To: From: "Kevin Zhang" To: "KC' 'Norseth" Cc: "Ipfix@Net. Doit. Wisc. Edu" Subject: [ipfix] ipfix data model contribution Date: Sun, 17 Feb 2002 11:14:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001F_01C1B7A4.417B1730" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C1B7A4.417B1730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgS0MsDQoNCkF0dGFjaGVkIHBsZWFzZSBmaW5kIG15IGNvbnRyaWJ1dGlvbiB0byB0aGUgZGF0 YSBtb2RlbCBkb2N1bWVudCwgaXQgaXMgaW50ZW5kZWQgdG8gYmUgaW5jbHVkZWQgaW4gc2VjdGlv biA1IHRvIHNwZWNpZnkgbWVzc2FnZSBjb2Rpbmcgc2NoZW1lcy4NCg0KVGhhbmtzLA0KDQpLZXZp bg== ------=_NextPart_000_001F_01C1B7A4.417B1730 Content-Type: text/plain; name="draft-ietf-ipfix-data-section5-xacct.txt" Content-Disposition: attachment; filename="draft-ietf-ipfix-data-section5-xacct.txt" Content-Transfer-Encoding: quoted-printable =20 =0A= IPFIX WG Kevin Zhang, =20 Internet Draft XACCT Technologies=20 =20 =20 =20 =20 =20 =20 Contributions to Section 5 of the draft-ietf-ipfix-data-00.txt =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 1=20 =0C =20 =20 =20 =20 1 IPFIX Message Format=20 =20 IPFIX messages are exchanged between an exporter and collectors. They=20 consist of control messages and user messages. Control messages are=20 used to setup an IPFIX session, to facilitate capability and template=20 negotiation, and to query exporter=92s status. The user messages are=20 used for export IP flow information. An IPFIX message consists of an=20 8 octet message header; it is followed by a variable length message=20 payload that is aligned to 32 bit boundary. Some of the messages do=20 not have the Payload part. The fields are transmitted from left to=20 right. =20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version |Message ID(MID)| Session ID | Message Flags |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Message Payload ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Version: 8 bit unsigned integer=20 =20 The Version field indicates the supported IPFIX protocol=20 implementation. This field MUST be set to 1 to indicate the=20 IPFIX protocol Version 1.=20 =20 Message ID (MID): 8 bit unsigned integer=20 =20 The Message ID field identifies the type of the message. The=20 message IDs defined by IPFIX Version 1 are:=20 =20 Message Name Short Name Message ID=20 --------------------- --------------- ------------=20 Reserved 0x0000=20 =20 Flow Start START 0x0001=20 Flow Start Acknowledge START ACK 0x0002=20 Flow Stop STOP 0x0003=20 Flow Stop Acknowledge STOP ACK 0x0004=20 Connect CONNECT 0x0005=20 =20 Template Data TMPL DATA 0x0010=20 Template Data Acknowledge TMPL DATA ACK 0x0011=20 Final Template Data FINAL TMPL DATA 0x0012=20 Final Template Data Ack. FINAL TMPL DATA ACK 0x0013=20 Get Sessions GET SESS 0x0014=20 Get Sessions Response GET SESS RSP 0x0015=20 2=20 =0C =20 =20 =20 Get Template GET TMPL 0x0016=20 Get Template Response GET TMPL RSP 0x0017=20 Start Negotiation START NEGOTIATE 0x0018=20 Start Negotiation Ack. START NEGOTIATE ACK 0x0019=20 =20 Data DATA 0x0020=20 Data Acknowledge DATA ACK 0x0021=20 Data Not Acknowledge DATA NACK 0x0022=20 Error ERROR 0x0023=20 =20 Status Request STATUS REQ 0x0030=20 Status Response STATUS RSP 0x0031=20 =20 Session ID: 8 bit unsigned char=20 =20 The Session ID field identifies the IPFIX session with which=20 the message is associated. The session ID is ignored in the=20 case of GET SESS and GET SESS RSP messages. =20 =20 Message Flags: 8 bit unsigned char=20 =20 The Message Flags field can be used to identify options=20 associated with the message. Unless otherwise specified, the=20 flags are set to zero on transmit and are ignored on receipt.=20 =20 Message Length: 32 bit unsigned integer=20 =20 The Message Length field is the total length of the IPFIX=20 message in octet including the header.=20 =20 Message Payload: =20 =20 The Message payload field is of variable length, which is=20 aligned to 32 bit boundary. It is used to carry control and=20 use information between an exporter and a collector.=20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 3=20 =0C =20 =20 =20 =20 2 IPFIX Messages=20 =20 This section defines IPFIX messages. =20 =20 2.1 Flow Start (START)=20 =20 Description=20 =20 The Flow Start message is sent from a collector to an exporter=20 to indicate that the collector is ready to receive IPFIX=20 messages. =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0001 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 2.2 Flow Start Acknowledge (START ACK)=20 =20 Description=20 =20 The Flow Start Acknowledge message is sent by an exporter to=20 acknowledge the reception of a START message from a specific=20 collector. =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0002 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Exporter Boot Time |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= 4=20 =0C =20 =20 =20 Exporter Boot Time: 32 bit unsigned integer=20 =20 The Exporter Boot Time field is the timestamp of the last=20 exporter startup in seconds from 1970. This field can be=20 combined with the data sequence number (DSN) and the=20 exporter=92s IP address to serve as a system wide unique record = identifier.=20 =20 =20 2.3 Flow Stop (STOP)=20 =20 Description=20 =20 The Flow Stop message is sent from a collector to an exporter=20 to instruct it to stop sending IP flow information (to that=20 collector). =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0003 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 2.4 Flow Stop Acknowledge (STOP ACK)=20 =20 Description=20 =20 The Flow Stop Acknowledgement message acknowledges the STOP=20 message issued by a collector. = =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0004 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= 5=20 =0C =20 =20 =20 =20 2.5 Connect (CONNECT)=20 =20 Description=20 =20 The CONNECT message is sent from a collector to an exporter to=20 identify itself. The message MUST be the first message sent=20 over a transport layer between the collector and the exporter. = =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0005 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Collector Address |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Collector Port | Reserved | = =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Collector Address: 32 bit unsigned integer=20 =20 The Collector Address field is the collector=92s IP address=20 (IPV4).=20 =20 =20 Collector Port: 16 bit unsigned integer=20 =20 The Collector Port field is the collector=92s port number for = the=20 transport layer. =20 =20 2.6 Template Data (TMPL DATA)=20 =20 Description=20 =20 An exporter sends the Template Data message to a collector=20 after a START or a START NEGOTIATE message was received from=20 the collector. The message MUST contain all the templates that=20 are going to be used for the session. =20 The receiving collector MUST acknowledge the message by=20 sending either a TMPL DATA ACK (if template changes are=20 needed) or a FINAL TMPL DATA ACK message. =20 =20 =20 Message Format=20 =20 =0A= =0A= 6=20 =0C =20 =20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0010 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Config ID |E| Flags | Number of Templates |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Template Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ ... ... ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Template Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Configuration ID (Config. ID): 8 bit unsigned char=20 =20 The Configuration ID field identifies the version number=20 associated to a template set. Changes to any of the templates=20 would result in a new template version, and the version number=20 would be incremented by one. An implementation SHOULD handle=20 rollovers of the version number.=20 =20 Flags: 8 bit unsigned char=20 =20 The Flags field identifies any options associated to the=20 message. =20 =20 The flag defined by the IPFIX Version 1 is:=20 =20 The 'E' bit indicates the transmission order of the =93DATA=94=20 messages. If the field is set to 1, data is in big endian=20 format; otherwise, little endian format is used. =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 7=20 =0C =20 =20 =20 Number of Templates: 16 bit unsigned integer=20 =20 The Number of Templates field is the number of Templates (a=20 template is described by a Template Block) specified by the=20 message.=20 =20 Template Block=20 =20 The Template Block field is of variable length and aligned to=20 32 bit boundary. It is the specification of a template.=20 =20 =20 Template Block Format:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Template ID | Number of Keys |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |S| Template Flags | Description Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Template Block Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Description ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Key Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ ... ... ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Key Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Template ID: 16 bit unsigned integer=20 =20 The Template ID field identifies a specific template. =20 =20 Number of Keys: 16 bit unsigned integer=20 =20 The Number of Keys field is the number of keys included in the=20 template.=20 =20 =0A= =0A= =0A= =0A= 8=20 =0C =20 =20 =20 Template Flags: 16 bit unsigned integer=20 =20 The Template Flags field is composed of flags that indicate=20 different attributes of the template. In IPFIX Version 1, only=20 the =91S=92 bit is defined, other bits in the field SHOULD be = set=20 to zero by the sender and ignored by the receiver.=20 =20 The 'S' bit ('Status' bit) indicates that the template is a=20 status template that is used by the STATUS RSP message only. =20 =20 Description Length: 16 bit unsigned integer=20 =20 The Description Length field is the length of the Description=20 field. If no description is supplied, the length MUST be 0.=20 =20 Template Block Length: 32 bit unsigned integer=20 =20 The Template Block Length is the length of the template block=20 in octets. =20 =20 Description: Variable length unsigned char=20 =20 The Description field contains the text description of the=20 template (e.g. "Aggregated by interface and ToS bits"). It is=20 a variable length field of up to 64Kb long, and padded with 0=20 to the next 32 bit boundary. =20 =20 Key Block=20 =20 A key Block contains the specification of a key within a=20 template.=20 =20 Key Block Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Key ID |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Key Type ID | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |E| Key Attribute Vector |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Key ID: 32 bit unsigned integer=20 =20 The Key ID field identifies the key within a template. =20 =20 =0A= =0A= =0A= =0A= =0A= 9=20 =0C =20 =20 =20 Key Type ID: 16 bit unsigned integer=20 =20 The Key Type ID field specifies the data type of the key.=20 =20 The fixed length data types are defined as following:=20 =20 Data Type Data Type ID=20 --------------------- --------------=20 Boolean (1) 0x0001=20 Unsigned Integer8 0x0002=20 Signed Integer8 0x0003=20 Unsigned Integer16 0x0004=20 Signed Integer16 0x0005=20 Unsigned Integer32 0x0006=20 Signed Integer32 0x0007=20 Unsigned Integer64 0x0008=20 Signed Integer64 0x0009=20 =20 Float (2) 0x000a=20 Double (2) 0x000b=20 =20 The variable length data types are defined as following:=20 =20 String (3) 0x400c=20 Null Terminated String 0x400d=20 UTF-8 String 0x400e=20 UTF-16 String 0x400f=20 IP address (Ipv4) 0x0010=20 IP address (Ipv6) 0x0011=20 Time (sec) (4) 0x0012=20 Time (msec) (5) 0x0013=20 Time (usec) (6) 0x0014=20 Arbitrary Data (BLOB) (7) 0x0015=20 =20 (1) Boolean is represented as a single octet holding 0 for a=20 value of FALSE and 1 for a value of TRUE.=20 =20 (2) Float and Double are single and double precision floating=20 point numbers that comply with the IEEE-754 standard.=20 =20 (3) String is prefixed by a 32 bit length field that indicates=20 the length of the string, and followed by ASCII codes of the=20 string characters. This representation MUST only be used for=20 encoding data records in a =93DATA=94 message. =20 =20 (4) Time (sec) is a 32 bit value, most significant octet first = - seconds since 00:00:00 GMT, January 1, 1970.=20 =20 (5) Time (msec) is a 64 bit value, most significant octet=20 first - milliseconds since 00:00:00 GMT, January 1, 1970.=20 =20 (6) Time (usec) is a 64 bit value, most significant octet=20 first - microseconds since 00:00:00 GMT, January 1, 1970.=20 10=20 =0C =20 =20 =20 =20 (7) The arbitrary data is prefixed by a 32 bit length field=20 and followed by the data in binary format.=20 =20 Key Attribute Vector: 32 bit unsigned integer=20 =20 The Key Attribute Vector field indicates different attributes=20 of the key. In IPFIX Version 1, only the =91E=92 bit is = defined,=20 other bits in the field SHOULD be set to zero by the sender=20 and ignored by the receiver.=20 =20 The 'E' bit ('Disabled bit') is set to 1 when the key is=20 disabled in this template. By default the 'E' bit is set to 0.=20 =20 2.7 Template Data Acknowledge (TMPL DATA ACK)=20 =20 Description=20 =20 The Template Data Acknowledge message is sent from a collector=20 to an exporter after a TMPL DATA message has been received. It=20 proposes changes of the templates and/or key status changes=20 (enable/disable) for the templates. =20 =20 If a collector whishes to acknowledge reception of TMPL DATA=20 without changes, it MUST respond with the FINAL TMPL DATA ACK=20 message.=20 =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 11=20 =0C =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0011 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Config. ID | Reserved | Number of Template Changes |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Template Change Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ ... ... ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Template Change Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Configuration ID (Config. ID): 8 bit unsigned char=20 =20 See Section 2.6. The value MUST be identical to the Config. ID=20 field of the acknowledged TMPL DATA message.=20 =20 Number of Template Changes: 16 bit unsigned integer=20 =20 The Number of Template Changes field is the number of changed=20 Templates (a changed template is described by a Template=20 Change Block) specified by the message.=20 =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 12=20 =0C =20 =20 =20 Template Change Block=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Template ID | Number of Keys |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Key Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ ... ... ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Key Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Template ID: 16 bit unsigned integer=20 =20 See Section 2.6.=20 =20 Number of Keys: 16 bit unsigned integer=20 =20 See Section 2.6.=20 =20 Key Block=20 =20 See Section 2.6, only relevant keys are described. =20 =20 2.8 Final Template Data (FINAL TMPL DATA)=20 =20 Description=20 =20 The Final Template Data message is sent by an exporter to all=20 the collectors in a session, to convey the finalized=20 templates. It is similar to the TMPL DATA message, with the=20 only difference that a collector must accept the templates in=20 this message.=20 =20 Message Format=20 =20 Identical to the TMPL DATA (see section 2.6)=20 =20 Message ID (MID)=20 =20 0x0012 Final Template Data=20 =20 2.9 Final Template Data Acknowledge (FINAL TMPL DATA ACK)=20 =20 Description=20 13=20 =0C =20 =20 =20 =20 The collector acknowledges reception of the TMPL DATA or FINAL=20 TMPL DATA by sending a Final Template Data Acknowledge=20 message. It does not carry any changes to the templates.=20 Unlike TMPL DATA ACK messages, a FINAL TMPL DATA ACK message=20 indicates the acceptance of the templates for the session. A=20 collector MAY respond with this message to a TMPL DATA (if it=20 does not want any changes in the templates). A collector MUST=20 respond with this message to a FINAL TMPL DATA. =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0013 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Config. ID | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Configuration ID: 8 bit unsigned char=20 =20 See Section 2.6. This field MUST copy the configuration ID=20 from the acknowledged message.=20 =20 2.10 Get Sessions (GET SESS)=20 =20 Description=20 =20 The Get Sessions message is sent by a collector to an exporter=20 to query what are the current on-going IPFIX sessions. =20 =20 The Session ID field in the IPFIX message header MUST be =20 ignored by the receiver.=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 14=20 =0C =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0014 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request ID | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Request ID: 16 bit unsigned integer=20 =20 The Request ID field identifies the specific request issued by=20 the collector. The same Request ID MUST be placed in the=20 responding message in order to associate it with the request.=20 =20 2.11 Get Sessions Response (GET SESS RSP)=20 =20 Description=20 =20 The Get Sessions Response message is sent by an exporter to a=20 collector as a reply to a GET SESS request. The message MUST=20 contain all the information related to any session with which=20 the requesting collector is associated.=20 =20 The Session ID field in the common message header MUST be=20 ignored by the receiver.=20 =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 15=20 =0C =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0015 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request ID | Number of Sessions |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Vendor String Length | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| = =20 | |=20 ~ Vendor String ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Session Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ ... ... ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Session Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Request ID: 16 bit unsigned integer=20 =20 See Section 2.10.=20 =20 Number of Sessions: 16 bit unsigned integer=20 =20 The Number of Sessions field is the number of session blocks=20 in the message.=20 =20 Vendor String Length: 16 bit unsigned integer=20 =20 The Vendor String Length field is the length of Vendor String=20 field in octet. The field limits vendor strings to 64Kb long.=20 If no such string is supplied, the length MUST be set to 0. =20 =20 Vendor String: Variable length unsigned char=20 =20 The Vendor String field is a variable length field. It=20 identifies the vendor that created the session. It MUST be=20 padded with 0 to the next 32 bit boundary. The information=20 differentiates similar templates from different vendors. The=20 =0A= 16=20 =0C =20 =20 =20 actual format of the information is application specific and=20 outside the scope of this document. =20 =20 =20 Session Block=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Session ID | Reserved | Session Name Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Session Description Length | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Session Name ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Session Description ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Session ID: 8 bit unsigned char=20 =20 =20 Session Name Length: 16 bit unsigned integer=20 =20 The Session Name Length field is the length of the Session=20 Name field. The field limits the session name strings to 64 Kb=20 long. As a name is mandatory to differentiate between=20 sessions, this field MUST NOT be 0.=20 =20 Session Description Length: 16 bit unsigned integer=20 =20 The Session Description Length field is the length of a=20 session description. The field limits the session description=20 to 64Kb long. If no such Description is supplied, the length=20 MUST be set to 0. =20 =20 Session Name: Variable length unsigned char=20 =20 The Session Name field is the name for a session, which MAY be=20 displayed to end-users. It MUST be padded with 0 to the next=20 32 bit boundary. Session Name MUST be unique within an=20 exporter. This field is mandatory and MUST be a part of any=20 Session Block.=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= 17=20 =0C =20 =20 =20 Session Description: Variable length unsigned char=20 =20 The Session Description field is the text description of a=20 session; it could be displayed to end-users. It MUST be padded=20 with 0 to the next 32 bit boundary.=20 =20 2.12 Get Templates (GET TMPL)=20 =20 Description=20 =20 The Get Templates message is sent by a collector to an=20 exporter to query templates in a session. =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0016 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request ID | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Request ID: 16 bit unsigned integer=20 =20 See Section 2.10.=20 =20 2.13 Get Templates Response(GET TMPL RSP)=20 =20 Description=20 =20 The Get Templates Response message is sent by an exporter to a=20 collector as a response to a GET TMPL message. The message=20 SHOULD contain all templates available for the specific=20 session.=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 18=20 =0C =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0017 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Request ID | Number of Templates |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Template Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ ... ... ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Template Block ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Request ID: 16 bit unsigned integer=20 =20 See Section 2.10.=20 =20 Number of Templates: 16 bit unsigned integer=20 =20 See Section 2.6.=20 =20 Template Block=20 =20 Same as the template block defined in the TMPL DATA message=20 (see Section 2.6). However, Extended Key Blocks MUST be used=20 instead of Key Blocks. Extended key Block field provides=20 extensive informational data that MAY be displayed to end- users.=20 =20 Extended Key Block=20 =20 The Extended Key Block field provides comprehensive=20 information about a key. =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= 19=20 =0C =20 =20 =20 Extended Key Block Format:=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Key ID |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Key Type ID | Key Name Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Key Label Length | Key Help Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Key Name ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Key Label ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Key Help ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 |E| Key Attribute Vector |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Key ID: 32 bit unsigned integer=20 =20 Same as section 2.6.=20 =20 Key Type ID: 16 bit unsigned integer=20 =20 Same as section 2.6.=20 =20 Key Name Length: 16 bit unsigned integer=20 =20 The Key Name Length field is the length of the Key Name field.=20 The field limits Key Name strings to 64 Kb long. As a name is=20 mandatory to a key, this field MUST NOT be 0.=20 =20 =20 Key Label Length: 16 bit unsigned integer=20 =20 The Key Label Length field is the length of the Key Label=20 field. The field limits Key Label strings to 64 Kb long.=20 Length of 0 means that the Label field is to be skipped.=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= 20=20 =0C =20 =20 =20 Key Help Length: 16 bit unsigned integer=20 =20 The Key Help Length field is the length of the Key Help field.=20 The field limits Key Help strings to 64 Kb long. Length of 0=20 means that the Help field is to be skipped.=20 =20 Key Name: Variable length unsigned char=20 =20 The Key Name field is the name for the key, which could be=20 displayed to end users. It MUST be padded with 0 to the next=20 32 bit boundary. Key Name MUST be unique (within the template)=20 and case sensitive. This field is mandatory and MUST be a part=20 of any Extended Key Block. =20 =20 Key Label: Variable length unsigned char=20 =20 The Key Label field is a descriptive label, which could be=20 displayed to end users concerning this key. It MUST be padded=20 with 0 to the next 32 bit boundary. This field SHOULD be a=20 part of any Extended Key Block.=20 =20 Key Help: Variable length unsigned char=20 =20 The Key Help field is any Help string that could be displayed=20 to end users concerning this key. It MUST be padded with 0 to=20 the next 32 bit boundary. This field MAY be a part of any=20 Extended Key Block.=20 =20 Key Attribute Vector: 32 bit unsigned integer=20 =20 Same as section 2.6.=20 =20 2.14 Start Negotiation (START NEGOTIATE)=20 =20 Description=20 =20 The Start Negotiation message is sent by a collector. The=20 message should initiate template negotiation by the exporter=20 with all collectors in a session. =20 =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 21=20 =0C =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0018 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 2.15 Start Negotiation Acknowledge (START NEGOTIATE ACK)=20 =20 Description=20 =20 The Start Negotiation Acknowledge message MUST be sent by an=20 exporter to the collector to acknowledge the reception of the=20 START NEGOTIATE message. =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0019 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 2.16 Data (DATA)=20 =20 Description=20 =20 The DATA message carries actual IP flow data records from an=20 exporter to a collector. A data record is a structured=20 collection of fields that matches a specific template.=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 22=20 =0C =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0020 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Template ID | Config. ID |S|D| Flags |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Data Sequence Number (DSN) |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Record Data ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Template ID: 16 bit unsigned integer=20 =20 See Section 2.6.=20 =20 Configuration ID: 8 bit unsigned char=20 =20 See Section 2.6. The Config. ID field can prevent out-of-the- blue messages with outdated templates arriving and erroneously=20 processed. A collector MAY keep a short history of templates=20 in order to cope with this scenario.=20 =20 Flags: 8 bit unsigned char=20 =20 The Flags field is composed of flag bits that indicate=20 processing requirements of the data records. The IPFIX Version=20 1 defined two flags for these purposes. Unless otherwise=20 specified, the other flags are set to zero on transmit and are=20 ignored on receipt.=20 =20 The following flags are defined in IPFIX Version 1:=20 =20 The 'S' bit ('DSN Synchronize' bit): When set, it indicates=20 that the record is the first one received by the collector=20 after starting (or restarting) of data transmission to this=20 collector. The collector MUST set the initial DSN to the=20 DSN specified in the record. The flag is set to zero by=20 default.=20 =20 The 'D' bit ('Duplicate' bit): It is set for records that=20 are re-sent to an alternate collector after a collector=20 transition occurs. When the same records are sent to=20 different collectors, there is a possibility that=20 duplicated data exists. The Status of the =91D=92 bit will = help=20 =0A= 23=20 =0C =20 =20 =20 the billing/mediation system to perform de-duplication if=20 desired. =20 =20 Data Sequence Number: 32 bit unsigned integer=20 =20 The Data Sequence Number field is the record sequence number=20 used for preserving data orders and detecting data losses. The=20 DSN MUST be incremented by one for each new record=20 transmitted. The selection of the initial DSN number is=20 implementation specific. =20 =20 Record Data: Variable Length unsigned octets=20 =20 The Record Data field carries the actual accounting/billing=20 data that is structured according to the template identified=20 by the Template ID field. =20 =20 2.17 Data Acknowledge (DATA ACK)=20 =20 Description=20 =20 The Data Acknowledgement message is sent from a collector to=20 acknowledge receipt of records. It acknowledges the maximal=20 in-sequence DSN received.=20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0021 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Data Sequence Number |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Config. ID | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 Data Sequence Number: 32 bit unsigned integer=20 =20 See Section 2.16. It MUST be DSN of the last in-sequence=20 record that was received by the collector.=20 =20 Configuration ID: 8 bit unsigned char=20 =20 See Section 2.16.=20 =20 =20 2.18 Data Not Acknowledge (DATA NACK)=20 =20 Description=20 24=20 =0C =20 =20 =20 =20 The DATA NACK message is sent from a collector to trigger a=20 retransmission of records. The exporter MUST re-send the data=20 records starting from the one after the acknowledged record. =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0022 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Data Sequence Number |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Config. ID | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Data Sequence Number: 32 bit unsigned integer=20 =20 See Section 2.16. It MUST be DSN of the last in-sequence=20 record that was received by the collector.=20 =20 Configuration ID: 8 bit unsigned char=20 =20 See Section 2.16.=20 =20 2.19 Error (ERROR)=20 =20 Description=20 =20 The Error message MAY be issued by either a collector or=20 exporter. It indicates an error condition that was detected=20 by the sender. =20 =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 25=20 =0C =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0023 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Timestamp |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Error Code | Description Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Description ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Timestamp: 32 bit unsigned integer=20 =20 The Timestamp field is a timestamp in seconds since 00:00:00=20 GMT, January 1, 1970.=20 =20 Error Code: 16 bit unsigned integer=20 =20 The Error Code field is a code assigned to an error condition. = =20 The following error codes are defined in IPFIX Version 1:=20 =20 Error Condition Error Code=20 ----------- --------------=20 Unknown 0=20 =20 =20 Description Length: 16 bit unsigned integer=20 =20 The Description Length field is the length of the Description=20 field. The field limits Description strings to 64 Kb long. =20 Length of 0 means that the Description field is to be skipped. =20 =20 Description: Variable Length unsigned char=20 =20 The Description field is a text description that allows the=20 sender to provide more detailed information about the error=20 condition. It MUST be padded with 0 to the next 32 bit=20 boundary. =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= 26=20 =0C =20 =20 =20 =20 2.20 Status Request (STATUS REQ)=20 =20 Description=20 =20 Collectors MAY inquire general operation status of an exporter=20 by sending the Status Request message. The status information=20 SHOULD include a collection of states, counters, accumulators=20 of the data collection functions that reside with the=20 exporter. The status MAY include more information about the=20 Exporter itself. =20 =20 The status reporting mechanism relies on the status template=20 of a session. It is determined similarly as other templates.=20 Without a determined status template, no status information=20 can be delivered.=20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0030 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 =20 2.21 Status Response (STATUS RSP)=20 =20 Description=20 =20 The Status Response message contains a status report that MUST=20 be compatible with the status template of the session. It is=20 exporter=92s response to a STATUS REQ message from a collector. = =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 27=20 =0C =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Version | MID=3D0x0031 | Session ID | Message Flags = |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Message Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Template ID | Reserved |Config. ID |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Record Length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | |=20 ~ Record Data ~=20 | |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Template ID: 16 bit unsigned integer=20 =20 See Section 2.6. =20 =20 Configuration ID: 8 bit unsigned integer=20 =20 See Section 2.6. The version is needed here to prevent out-of- the-blue messages with outdated templates arriving and=20 erroneously processed. A collector MAY keep a short history of=20 templates in order to cope with this scenario.=20 =20 Record Length: 32 bit unsigned integer=20 =20 The Record Length field is the length of the Record Data field=20 in octets=20 =20 Record Data: Variable Length unsigned octets=20 =20 The Record Data field contains the status data that complies=20 with the status template. =20 =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 28=20 =0C =20 =20 =20 3 Protocol Version Negotiation=20 =20 Since the IPFIX protocol may evolve in the future and it may run over=20 different transport layers, a transport neutral version negotiation=20 mechanism running over UDP is defined. A collector MAY inquire an=20 exporter about the IPFIX protocol version and transport layer support=20 by sending a UDP packet on an agreed UDP port. The exporter MUST=20 respond to this request with a UDP packet carrying the protocol=20 version, the transport type and the port number used for the specific=20 transport. The Protocol Version Negotiation is optional for IPFIX=20 Version 1.=20 =20 The collector sends the following message to query the exporter=92s=20 protocol support.=20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Collector Address |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Collector Boot Time |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | I | P | F | X | = =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Collector Address:=20 =20 The Collector Address field is the IP address (Ipv4) of the=20 collector.=20 =20 Collector Boot Time=20 =20 The Collector Boot Time field is the timestamp of the last=20 collector startup in seconds from 1970. =20 =20 =91I=92, =91P=92, =91F=92, =91X=92: =20 =20 The =91I=92, =91P=92, =91F=92, =91X=92 fields are ASCII encoded = characters to=20 identify the IPFIX collector.=20 =20 =20 The exporter=92s reply to a version negotiation request MUST comply=20 with the following structure:=20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= 29=20 =0C =20 =20 =20 Message Format=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Default Protocol Info |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Additional Protocols Count |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Additional Protocols Info |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | ... Additional Protocols Info ... |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Additional Protocols Info |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Default Protocol Info:=20 =20 The Default Protocol Info field contains information of the=20 default protocol supported by the exporter. The field is=20 structured as a Protocol Info Block described below.=20 =20 Additional Protocols Count: 32 bit unsigned integer=20 =20 The Additional Protocols Count field specifies the number of=20 additional protocols supported by the exporter. In the case=20 that only the default protocol is supported, the field MUST be=20 set to 0.=20 =20 Additional Protocols Info:=20 =20 The Additional Protocol Info field is an array of Protocol Info=20 Blocks (described below) contain information about additional=20 protocols supported by the exporter.=20 =20 =20 Protocol Info Block=20 =20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Transport Type |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Protocol Version |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Port Number | Reserved |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Transport Type: 32 bit unsigned integer=20 =20 1 =96 TCP, 2 =96 SCTP, 3 - UDP=20 =20 Protocol Version: 32 bit unsigned integer=20 30=20 =0C =20 =20 =20 =20 Version number of the IPFIX protocol supported over the=20 specific transport layer, the current version is 1.=20 =20 Port Number: 16 bit unsigned integer=20 =20 Port number (either SCTP or TCP port) used for the protocol=20 =20 =20 =20 =20 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= 31=20 =0C ------=_NextPart_000_001F_01C1B7A4.417B1730-- -- 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 Sun Feb 17 20:55:48 2002 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 UAA14419 for ; Sun, 17 Feb 2002 20:55:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ccip-00068W-00 for ipfix-list@mil.doit.wisc.edu; Sun, 17 Feb 2002 19:36:03 -0600 Received: from c001-h008.c001.snv.cp.net ([209.228.32.122] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16ccii-00067j-00 for ipfix@net.doit.wisc.edu; Sun, 17 Feb 2002 19:35:56 -0600 Received: (cpmta 3384 invoked from network); 17 Feb 2002 17:35:24 -0800 Received: from 24.221.253.53 (HELO slc252750) by smtp.register-admin.com (209.228.32.122) with SMTP; 17 Feb 2002 17:35:24 -0800 X-Sent: 18 Feb 2002 01:35:24 GMT Message-ID: <003d01c1b81c$ec2aaf60$850f880a@slc252750> Reply-To: "K.C. Norseth" From: "K.C. Norseth" To: Subject: [ipfix] IPFIX Design team drafts Date: Sun, 17 Feb 2002 18:38:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Folks, I have updated the IPFIX design team documents. The archecture document has not changed other than calling it a design team draft vs a IETF IPFIX draft. The data draft has had the inclusion of CRANE in section 5 as a POSSIBLE protocol to consider. Currently, NetFlow v9 and CRANE are represented. Where we are trying to see if we can use an established protocol in IPFIX, CRANE, LFAP and NetFlow v9 are represented in Section 5. When LFAP gets me their piece, I will put it here also. Currently just the URL for LFAP is provided. I DO NOT PROPOSE WE IMPLEMENT ALL PROTOCOLS. I AM SHOWING THEM TOGETHER FOR COMPARITIVE ANALYSIS.. WE NEED TO HAVE ONLY ONE. We need the concensus of the WG to decide which protocol to use. Remember, we have until Friday to get this draft clean to get it submitted to the IETF. Comments are needed. The review board is meeting tomorrow. Any comments you give ASAP will be appreciated by all of us. Text Versions http://norseth.org/ietf/ipfix/draft-team-ipfix-architecture-00.txt http://norseth.org/ietf/ipfix/draft-team-ipfix-data-00.txt Microsoft word http://norseth.org/ietf/ipfix/draft-team-ipfix-architecture-00.doc http://norseth.org/ietf/ipfix/draft-team-ipfix-data-00.doc If anyone needs these emailed to you, let me know. K.C. -- 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 Feb 18 03:31:28 2002 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 DAA28527 for ; Mon, 18 Feb 2002 03:31:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cisE-0006Wv-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 02:10:10 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cisC-0006Wq-00 for ipfix-req@net.doit.wisc.edu; Mon, 18 Feb 2002 02:10:08 -0600 Received: from fokus.fhg.de (dhcp252 [195.37.78.252]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1I89wp23468; Mon, 18 Feb 2002 09:09:59 +0100 (MET) Message-ID: <3C70B5D0.EF64B0E7@fokus.fhg.de> Date: Mon, 18 Feb 2002 09:05:36 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: Ganesh Sadasivan CC: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Terminology again References: <120715491.1013732997@[192.168.102.31]> <3C6C5108.B46B4308@cisco.com> <3C6CBFF9.89BCA779@fokus.fhg.de> <3C6D451E.39B1F804@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ganesh, comments inline Ganesh Sadasivan schrieb: > > Hi Sebastian, > The observation point is the place from where the packets from the wire are seen. > The metering functionality acts on these packets to create flows. So even though > the drawing shows meter behind the observation point, the metering is happening > at the same place as the observation point in most of the cases. In the case of > centralised proicessing where all the packets reach a shared memory, the metering > is done after the packet is seen at the observation point. > See more inline.. I agree. What has confused me in your picture is that in the upper part the meter is above observation points and then there are meter and export below. I would suggest putting the 2nd level meter and export above (with the export as the top) to clearly show the way of the data: observation->1st meter->2nd meter->export > Sebastian Zander wrote: > > > Hi Juergen, Ganesh > > > > I try to answer to you both in one mail. > > > > Juergen: > > > > I think header capturing should be named packet capturing for generality because > > otherwise we have to define what header means (which layer) and impose limits > > here? > > > > I though header capturing is the functionality of the observation point!? Since > > you make it a separate block what's the functionality left for observation point? > > Your case of capturing the packet header is a part of flow creation. This is a part of > metering process itself. In some other case this functionality may not be necessary. > Say if one is looking for packet length, capturing header is not a must. That's true for a router. A passive probe must always do packet capturing to get packet information. Again I propose to avoid that kind of discussion by not getting into too much details in the model. Do we really need a separate block for packet capturing in the model? > > > > > > I agree to your blocks but do we need that high level of decomposition? Why not > > put packet capturing in observation point and flow record in meter? My intuitive 3 > > function blocks are: (1) Get packets from wire, (2) process packets & generate flow > > records and (3) export flow records. If we really do need further decomposition than > > it's fine with me but otherwise stay on the highest suitable level. > > > > I think on a high level sampling can be done as part of packet capturing or as part > > of metering. With further decomposition I think a sampling block would be between > > capturing & meter. But do we really need to define this? > > > > BTW I like your overall name but maybe the "traffic" could be omitted to make it > > shorter? > > > > Ganesh: > > > > I think cascading meters is a nice idea but that implies that the input interface > > of a meter is the same as the output interface as Juergen said. Why then limit the > > model to only 2 steps? > > Yes the first level meter which happens at the observation point, sees packets > instead of flows. The rest of the levels should be seeing flow records of > some form which need not be the final exported records. > > > > > > > I do not understand why in your picture the observation point is behind the meter. > > I think it's the other way around. If then the observation point definition > > is extended to cover an observation domain you have a fully recursive definition > > and can cascade meters as you want (or not if you don't). This would read e.g.: > > More than 1 meter could be grouped forming a (virtual) observation point for a > > following meter. In contrast to a real observation point which is a lincard or > > NIC. I think your example fits into this model. > > Yes one can cascade meters at multiple levels. But why we did not mention it is because > from a practical standpoint, this would suffice. Today in most of the cases > one level metering is what is done and recently only we heard about more requirements > for a 2nd level meter . > > > > > > > This approach would converge the 2 models. > > > > Additionally there was a comment from Peter Phaal who proposed to cascade exporters. > > I think this could be done with the model, if a collector can be seen as an observation > > point/domain as well. > > > > My guess is that that we need an exporter ID in addition to obs. point ID(s) to > > differentiate between different exporters at the collector level. Would be > > nice to have 2 ID types: (1) Where has the flow been observed, > > (2) who has told me about it. But im not 100% sure about this. Omitting an exporter > > ID would at least require some assumptions such that an observation point has only > > 1 exporter... > > Agreed on the last sentence. But why does the collector need to know > "(2) who has told me about it"? To me the observation domain ID should > identify the flow packets within and across exporters. I was thinking about the following: You get data from more than one IPFIX enabled box and you have a collector which performs aggregation on the data and re-exports it via IPFIX. Would be nice to be able to do this for acalability. But the aggregator could also be identified by an observation point id if the definition is flexible enough. The aggregator should also include the list of original observation points. This would be a similar approach as the SSRC, CSRC in Real-Time Transport Protocol (RTP). In case of in-band configuration you may probably need an exporter id for identification of an ipfix exporter. In case of having an authentication mechanism between exporter and collector you also need some kind of exporter id. But if you consider the last 2 things out of scope a flexible observation point id seems sufficient. Sebastian > Thanks > Ganesh > > > > > > > Sebastian > > > > Ganesh Sadasivan schrieb: > > > > > > Juergen Quittek wrote: > > > > > > > Hi Ganesh, > > > > > > > > --On 14 February 2002 14:45 -0800 Ganesh Sadasivan wrote: > > > > > > > > > Hi Jurgene, > > > > > The picture does not appear garbled in the archives. Probably you > > > > > can look at it there.See inline for my answers. > > > > > > > > I could read the picture well (even in your reply). > > > > > > > > > > > > > > Juergen Quittek wrote: > > > > > > > > > >> Hi Ganesh, > > > > >> > > > > >> --On 14 February 2002 11:07 -0800 Ganesh Sadasivan wrote: > > > > >> > > > > >> > Hi Jurgene, > > > > >> > I am of the opinion that "header capturing" is a metering > > > > >> > function.I see restrictions with your model. Escpecially > > > > >> > if some kind of metering is done on collected flows within > > > > >> > the router. It was with this in mind that I send out in one of > > > > >> > my previous mails the high level picture. Did not get any > > > > >> > response. So I am resending with some more modification. I am > > > > >> > slightly inclined to think that the metering process within > > > > >> > the observation domain could be hierarchical but have not put > > > > >> > it here. > > > > >> > What are your inputs? > > > > >> > > > > > >> Please excuse that I did not reply so far on your drawing. > > > > >> I did not understand it when I saw it the first time and sent > > > > >> it to the printer to study it later. Unfortunately, that's where > > > > >> it still is. I should better have sent you my questions on this: > > > > >> > > > > >> 1. What is the difference between a meter process and a meter? > > > > > > > > > > Sorry that is a mistake, I meant "meter process" for both cases > > > > > (within and outside the observation domain). > > > > > > > > I think "meter" is a very well suited name for a box > > > > hosting a metering process! > > > > > > Ok. > > > > > > > > > > > > > > > >> > > > > >> 2. How and from where do meters get input? from meter processes? > > > > > > > > > > Since there is no separate meters and meter processes, you can think of > > > > > it as meter process within the observation domain, feeding the the meter > > > > > process outside the observation domain. > > > > > > > > Meter processes can be cascaded? > > > > > > yes. > > > > > > > > > > > What is the input to a meter process? > > > > > > The input to the meter at the lowest level is packets. > > > Flows are cretaed as a result of the lowest level > > > meter process. At subsequent level,the input to meter would > > > be flows. As I mentioned before the first level meter is a must > > > but not the subsequent ones. > > > > > > > > > > > It must have the same structure than the output? > > > > Otherwise I do not see how you could cascade them. > > > > > > What does this mean? > > > > > > > > > > > > > > > How is the total metering process shared by the packet meter > > > > processes and the flow meter processes? > > > > > > They are independent entities. > > > > > > > > > > > In other words: what are the differences between these > > > > (different?) kinds of meters inside and outside the observation > > > > domain? > > > > > > The one outside observation domain operates on a bigger scope. > > > For example: Say there are 2 lowest level meters: > > > M11 extracts the 5 tuple IPV4 flows from interface1 at a > > > sampling rate of 1 in 10. > > > M12 extracts the 5 tuple IPV4 flows from interface2 at a > > > sampling rate of 1 in 20. > > > A meter at the level of observation domain sees the flows > > > created by M11 and M12 and does one more level of > > > sampling of all the flows created by both meters at a > > > rate of 1 in 2 before exporting it. > > > > > > Ganesh > > > > > > > > > > > > > > > Juergen > > > > > > > > > > > > > >> > > > > >> 3. Is there only one exporter per observation domain? > > > > > > > > > > No. The exporter need not be tied to an observation domain. > > > > > Example: Take the case of 2 linecards in a router., linecard 1 and > > > > > linecard 2. Each of the LC forms an observation domain. The > > > > > meters associated directly with observation points perform flow > > > > > creation/updation based on the packets. There could be meters at > > > > > a higher level (i.e per observation domain) that do furthur filtering > > > > > or aggregation.However, the flows collected at the observation > > > > > domain LC1& LC2 could be > > > > > exported via LC2. Thus the exporter which is common to LC1 > > > > > and LC2 resides in LC2. The flow export packet from > > > > > each of the observation domain is identified by a unique ID. > > > > > > > > > > > > > > >> > > > > >> 4. What would be the difference between an observation domain > > > > >> ID and an exporter ID? > > > > > > > > > > The export flow packet is identified by the observation domain ID . > > > > > I am not sure we need the Exporter ID (or do we?) > > > > > > > > > > Thanks > > > > > Ganesh > > > > > > > > > >> > > > > >> > > > > >> Cheers, > > > > >> > > > > >> Juergen > > > > >> > > > > >> > > > > > >> > +---------------------------------------------------------------+ > > > > >> > | Observation Domain | > > > > >> > | | > > > > >> > | +-------+ +-------+ Packet level| > > > > >> > | |Meter1 | .... |MeterM | ({Fi}, {Si})| > > > > >> > | |Process| |Process| | > > > > >> > | +-------+ +-------+ | > > > > >> > | ^ ^ | > > > > >> > | | | | > > > > >> > | +-------+-------+ +-------+--------+ | > > > > >> > | | | | | | > > > > >> > | v v v v | > > > > >> > |+------------+ +------------+ +------------+ +------------+| > > > > >> > ||Obsv Point11|..|Obsv Point1k| |Obsv PointM1|.. |Obsv PointMn|| > > > > >> > |+------------+ +------------+ +------------+ +------------+| > > > > >> > +---------------------------------------------------------------+ > > > > >> > ^ ^ > > > > >> > | | > > > > >> > v v > > > > >> > +----------+ +----------+ > > > > >> > |Meter (O1)| .... |Meter (OP)| Flow Level > > > > >> > +----------+ +----------+ ({Fi}, {Si}) > > > > >> > | | > > > > >> > +-------+--------+ > > > > >> > | > > > > >> > v (uniqued ID for an observation domain) > > > > >> > +---------------+ > > > > >> > | exporter | > > > > >> > +---------------+ > > > > >> > > > > > >> > > > > > >> > Thanks > > > > >> > Ganesh > > > > >> > > > > > >> > Juergen Quittek wrote: > > > > >> > > > > > >> > Hi Sabastian, > > > > >> > > > > > >> > --On 14 February 2002 11:07 +0100 Sebastian Zander wrote: > > > > >> > > > > > >> >> Hi Juergen, > > > > >> >> > > > > >> >> Juergen Quittek schrieb: > > > > >> >>> > > > > >> >>> Hi all, > > > > >> >>> > > > > >> >>> We had some terminology discussion and it has not > > > > >> >>> converged yet. Therfore I like to raise one issue again: > > > > >> >>> > > > > >> >>> For the terinology section of the requirements draft > > > > >> >>> (I belive now it will be a subset of the architecture's > > > > >> >>> terminology) I would like to have two identifiers for > > > > >> >>> the following: > > > > >> >>> > > > > >> >>> 1. the function block containing all metering functions > > > > >> >>> This block gets as input observed (and potentially > > > > >> >>> sampled) packets from the observation point. It classifies > > > > >> >>> packets maps them to flows and creates/updates the > > > > >> >>> according flow record. > > > > >> >>> > > > > >> >>> 2. the function block sending flow records to the collector > > > > >> >>> > > > > >> >>> I am fine with splitting blocks more or modifying them > > > > >> >>> slightly, but I prefer to have this separation, because > > > > >> >>> also the requirements are split in a very similar way. > > > > >> >> > > > > >> >> I also would like to split those for at least 2 reasons. > > > > >> >> First we create a more general model because on a router linecard > > > > >> >> both are be combined but on a dedicated hardware/software based > > > > >> >> meter this will probably not the case. I don't think we should limit > > > > >> >> ipfix to routers only. Second the separation is nice to clarify > > > > >> >> the scope. The scope of the ipfix wg is to standardize the > > > > >> >> exporter (at least the interface to the outside). It's out > > > > >> >> of scope to standardize the meter (although we put some req. > > > > >> >> on it). > > > > >> >> > > > > >> >> I am not sure whether sampling is a function of the observation > > > > >> >> point or the meter. > > > > >> > > > > > >> > Neither am I, but we should agree on one or the other soon. > > > > >> > What about the following (short version of more detailed > > > > >> > suggestions already discussed for the architecture)? > > > > >> > > > > > >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > > > > >> > | obs. | | header | | | | flow | | ex- | > > > > >> > | point |-->| capturing |-->| meter |-->| record |-->| porter | > > > > >> > +-------+ +-----------+ +-------+ +--------+ +--------+ > > > > >> > > > > > >> > | | > > > > >> > \____________________________ _____________________________/ > > > > >> > \/ > > > > >> > IPFIX traffic flow measurement module > > > > >> > > > > > >> > If can tell me a good reason I am fine with merging header capturing > > > > >> > and meter, but in general I see them as different function blocks. > > > > >> > > > > > >> > Juergen > > > > >> > > > > > >> >>> My initial naive suggestion was calling block 1. "meter" > > > > >> >>> and calling block 2. "exporter". However this might (no it > > > > >> >>> did already) cause confusion. Therefore, I am looking for > > > > >> >>> better terms. Any suggestions? > > > > >> >> > > > > >> >> I have no better terms. I think what's maybe confusing is that we don't > > > > >> >> have a term for the overall process (meter+exporter+observation). > > > > >> >> What could be appropriate? flow monitor? > > > > >> >> > > > > >> >> Another possibility: Name the overall process metering and rename > > > > >> >> the inner function block 1 which does classification etc. > > > > >> >> > > > > >> >> Sebastian > > > > >> >> > > > > >> >> -- > > > > >> >> Sebastian Zander E-mail: zander@fokus.fhg.de > > > > >> >> FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > > > > >> >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > > > > >> >> D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander > > > > >> >> > > > > >> > > > > > >> > -- > > > > >> > 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/ > > > > >> > > > > > > > > > > -- > > Sebastian Zander E-mail: zander@fokus.fhg.de > > FhI FOKUS / Global Networking (GloNe) Tel: +49-30-3463-7287 > > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > > D-10589 Berlin, Germany www.fokus.fhg.de/usr/sebastian.zander -- 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 Feb 18 05:52:48 2002 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 FAA29910 for ; Mon, 18 Feb 2002 05:52:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16clA5-0002Lz-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 04:36:45 -0600 Received: from odd-brew.cisco.com ([144.254.15.119] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16clA3-0002L1-00 for ipfix-req@net.doit.wisc.edu; Mon, 18 Feb 2002 04:36:43 -0600 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-76.cisco.com [144.254.7.76]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA08910; Mon, 18 Feb 2002 11:35:46 +0100 (MET) Message-ID: <3C70D90F.6AD7688B@cisco.com> Date: Mon, 18 Feb 2002 11:36:00 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: ram.gopal@nokia.com, quittek@ccrle.nec.de, ipfix-req@net.doit.wisc.edu Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Kevin, > > > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Thursday, February 14, 2002 12:39 PM > > To: bclaise@cisco.com; ram.gopal@nokia.com; kevin.zhang@xacct.com > > Cc: quittek@ccrle.nec.de; ipfix-req@net.doit.wisc.edu > > Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to > > draft-ietf-ipfix-reqs-00.txt > > > > > > Hi Kevin, > > > > > > > > My comments are inserted, thanks. > > > > > > Kevin > > > > > > > -----Original Message----- > > > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > > > Of Benoit Claise > > > > Sent: Thursday, February 14, 2002 10:09 AM > > > > To: ram.gopal@nokia.com > > > > Cc: quittek@ccrle.nec.de; zander@fokus.gmd.de; > > > > ipfix-req@net.doit.wisc.edu > > > > Subject: Re: in band configuration? RE: [ipfix-req] Proposed > > changes to > > > > draft-ietf-ipfix-reqs-00.txt > > > > > > > > > > > > Ramg, > > > > > > > > > > > > > > >> If we have in-band management what is the problem? It's is a > > > > > >good choice whether > > > > > >> there is no flaw and it is good to control from one place to > > > > > >do both configure and manage the network > > > > > >> elements. If we provide proper security mechanism and ensure > > > > > >that the devices gets > > > > > >> the proper commands similar to CLI then what's the problem ? > > > > > > > > > > > >What is the problem, you're asking? > > > > > >There are actually no problems. I agree it would be the > > > > > >perfect world to have in-band configuration. But here are some > > > > > >arguments against the idea. Actually I even think a little bit > > > > > >further: the exporter configuration is out of the scope of > > > > > >this charter. > > > > > > > > > > You yourself is convinced to have single point configuration > > > > and control thr' inband > > > > > management. I can see some of your good points and issues. We > > > > are not thinking > > > > > here exporter or collector configuration split or where to > > > > place the functionality etc. > > > > > If there is a real potential problem then we should consider > > > > this as part of charter > > > > > rather than just postponing IPFIX version1 ... version 2.... etc.... > > > > > > > > But the entire issue, I don't see which problem we are trying to > > > > solve by having in-band configuration, > > > > except that it could be a nice feature to have. > > > > > > > > > > I would underscore the fact that exporters might be probes and > > midboxes that need to support more data collection functionality. > > Without some form of configuration, preferably in-band, their > > applications will be significantly limited. > > > > Obviously, we want to be able to configure an exporter. For > > example, just to configure what the template should be. > This I totally agree with you, template configuration/negotiation is the minimum the IPFIX should support. And it should be done in-band as this is an integral part of a flow export protocol. Don't make me say what I haven't said. My view is: CLI (or any other means) configuration. No inband configuration within IPFIX. And no negotiation. But again, this should be another thread. > > > > The only conclusion that this thread draw is: in or out-of-band, > > I mean CLI configuration of the exporter or the exporter, via the > > IPFIX protocol, must be able to configure the exporter. > I am not very clear about this point. Could you clarify? I assume in-band configuration refers to configuration through IPFIX control messages. Not in my mind. see my point above Regards, Benoit > > > > > > > > > > > > > > > > > > > > > > > There is always a debate one can make whether to consider all > > > > the problems at forehand > > > > > or do incremental activity. I do not want to get into that. > > > > > > > > > > > > > > > > >1. Do you want the working group to spend the time (the money) > > > > > >to developp a comon provisioning protocol, IF this is even > > > > > >possible to have an agreement on that accross the different > > > > > >vendor (probes and routers), which I think is impossible. > > > > > > > > > > > > > > > > Flow information protocol is extensible and we cannot deal > > in defining > > > > > flows for each each and every protocols. Flow information can > > > > be exchanged between > > > > > two endpoints if they know how to interpret the fields which > > > > may be vendor specific. > > > > > > > > The information model must be extensible. Agreed, but this is a > > > > different issue than inband > > > > configuration. > > > > BTW, In Ganesh and I's draft, the collector will be able to > > > > decode a template, even if it doesn't know > > > > anything about some specific fields. > > > > > > > > > > Through template negotiation/acknowledgement, the correct > > context can be set at the IPFIX end-points. This will ensure > > correct interpretation of received data by the collector. The > > periodic template refreshing scheme is less robust as losses of > > the template information will put the collector on hold. For > > some applications that require real-time information collection, > > this means the flow information will be delayed at least another > > refreshing cycle. > > > > This is not correct but I would come back on that in other thread, later. > > Negotation is something else that the group will have to find a > > rough consensus on.. > > I propose to just concentrate on one issue at the time, if we > > want to be efficient: in or out-of-band configuration. No > > worries, the thread for negotation would follow! > > > Agree > > > Regards, Benoit. > > > > > > > > The CRANE protocol > > http://www.ietf.org/internet-drafts/draft-kzhang-crane-protocol-02 > > .txt uses template negotiation to achieve flexibility and > > extensibility of flow information export. Very little contraints > > are imposed on what can be exported. The template negotiation > > typically happens once during set-up to allow the IPFIX > > end-points to sync. on a set of templates. The actual flow > > information is transfered in its native form accompanied by a > > template ID. I believe this is a nicer approach. > > > > > > > > > > > > > > > > > > With SNMP also every protocol defines the MIB and uses SNMP to > > > > exchange the > > > > > information. > > > > > > > > > > > > > > > Typically, Management protocols are provides mechanisms how to > > > > exchange and not what to exchange. > > > > > The latter thing is more addressed by MIB which is a generic to > > > > represent attributes which are to > > > > > be managed. > > > > > > > > Agreed. I don't recall writing something which goes against that > > > > principle. > > > > > > > > > > > > > > > > > > > So in principle we have MIB and management protocol two are > > > > logically separate functional entities. > > > > > > > > Same remark > > > > > > > > > > > > > > > > > > > Ok,its a matter of time and design team effort to put that, > > > > we should not leave any items > > > > > which are essential candidates. > > > > > > > > > > > > > > > >2. What would happen with proprietary features, which most > > > > > >likely will not be part of the IPFIX provisioning protocol. So > > > > > >anyway we will have to use a different way of provisioning the > > > > > >device, like CLI for example, next to IPFIX. This will bypass > > > > > >the use of IPFIX provisioning protocol. > > > > > > > > > > > See my previous comments. > > > > > > > > > > >4. SNMP is widely used. Why? because the S stands for simple. > > > > > >And now, along the time, it has been evolving because there > > > > > >are new needs. > > > > > >I would like to start with something Simple, that > > everybody agrees on. > > > > > >And if there is a need for in-band configuration, then we can > > > > > >think of IPFIX2. > > > > > >Why trying to have an ISO standard from version 1? ;) > > > > > >You can give me a long list of nice idea about in-band > > > > > >configuration that I'm sure I would love to have in a perfect > > > > > >world but let's start with something Simple. > > > > > >Don't forget that simplicity is the key for interoperability. > > > > > >If not yet convinced: have you already compared Snmp and CMIP? > > > > > > > > > > > > > > > > I agree that we start with simple, that does not mean that we > > > > should complete > > > > > in hurry without addressing the other issues. > > > > > > > > > > My advice is that be patient and cool when you reply. What i > > > > asked is more of > > > > > clarification but your reply is not on those lines. > > > > > > > > > > > > > > > > > > > > >6. IPFIX stands for Flow Information eXport. So we have to > > > > > >standardize the export, not the configuration. So the > > > > > >direction:exporter -> collector and not the direction > > > > > >collector -> exporter. At least for version 1. > > > > > > > > > > We are not talking version of IPFIX in our charter and it may be > > > > > your assumption. > > > > > > > > No assumption here, I'm only trying to find a consensus. > > > > So instead of just saying NO, I'm proposing the following: > > > > if there is a really a need (a real potential problem, according > > > > to your own words), it's time to give > > > > your technical arguments. > > > > If not, let's investigate this nice-to-have feature later, maybe > > > > in version 2. > > > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > -- > > > > 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/ > > > > > > > > > > > > > > > -- 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 Feb 18 10:41:49 2002 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 KAA05215 for ; Mon, 18 Feb 2002 10:41:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cpd0-0002Vl-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 09:22:54 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cpcz-0002VS-00 for ipfix@net.doit.wisc.edu; Mon, 18 Feb 2002 09:22:53 -0600 Received: from riverstonenet.com (134.141.180.99 [134.141.180.99]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY6JB0; Mon, 18 Feb 2002 07:21:39 -0800 Message-ID: <3C711C04.CA6BC479@riverstonenet.com> Date: Mon, 18 Feb 2002 10:21:40 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: "KC' 'Norseth" , "Ipfix@Net. Doit. Wisc. Edu" Subject: Re: [ipfix] ipfix data model contribution References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit This looks like protocol definition to me. I thought we were supposed to select a protocol not build one. Kevin Zhang wrote: > > Hi KC, > > Attached please find my contribution to the data model document, it is intended to be included in section 5 to specify message coding schemes. > > Thanks, > > Kevin > > ------------------------------------------------------------------------ > Name: draft-ietf-ipfix-data-section5-xacct.txt > draft-ietf-ipfix-data-section5-xacct.txt Type: Plain Text (text/plain) > Encoding: quoted-printable -- 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 Feb 18 10:42:38 2002 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 KAA05257 for ; Mon, 18 Feb 2002 10:42:37 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cpel-0002Xa-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 09:24:43 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cpek-0002Wf-00 for ipfix@net.doit.wisc.edu; Mon, 18 Feb 2002 09:24:42 -0600 Received: from riverstonenet.com (134.141.180.99 [134.141.180.99]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY6JC2; Mon, 18 Feb 2002 07:23:29 -0800 Message-ID: <3C711C71.FD443FC0@riverstonenet.com> Date: Mon, 18 Feb 2002 10:23:29 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Peram Marimuthu CC: "K.C. Norseth" , kevin.zhang@xacct.com, "Norseth, KC" , ipfix@net.doit.wisc.edu Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design draft updates) References: <002e01c1b67a$c146ea00$850f880a@slc252750> <3C6E836B.640BA25B@cisco.com> <001501c1b72a$8af7f560$850f880a@slc252750> <3C6ED48D.DA434090@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Just FYI, I have no intentions on summitting an LFAP version of IPFIX for consideration. More on this in the next mail. Paul -- 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 Feb 18 10:51:10 2002 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 KAA05537 for ; Mon, 18 Feb 2002 10:51:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cppB-0002ko-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 09:35:29 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cpp8-0002jc-00 for ipfix-data@net.doit.wisc.edu; Mon, 18 Feb 2002 09:35:26 -0600 Received: from riverstonenet.com (134.141.180.99 [134.141.180.99]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY6JGB; Mon, 18 Feb 2002 07:34:13 -0800 Message-ID: <3C711EF6.FBD09465@riverstonenet.com> Date: Mon, 18 Feb 2002 10:34:14 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: data Subject: [ipfix-data] IPFIX Data Model Document Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit The last flurry of mail on this has confused me as to what we are trying to accomplish in the data model document. I thought we were trying to lay out the data sent and give it precise semantic meaning. Then follow that with general text on how that data should be sent not detailed wire encoding. As far as I can see there are still some gray areas in the semantics. For example, with destination VLAN ID, is it the ultimate destination or is it the VLAN ID of the outgoing interface? I'm sure there are others. If we don't have good defintions we wont have interoperabilty. Paul -- 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 Feb 18 13:56:57 2002 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 NAA13633 for ; Mon, 18 Feb 2002 13:56:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16csa0-0006EH-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 12:32:00 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16csZy-0006Ds-00 for ipfix@net.doit.wisc.edu; Mon, 18 Feb 2002 12:31:58 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id NAA18719 for ; Mon, 18 Feb 2002 13:41:24 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma018689; Mon, 18 Feb 02 13:41:13 -0500 Received: by cnc-exc2.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 13:30:50 -0500 Message-ID: <0BF8B32B723ED5119E0B0002A551748B01FA092A@corp-exc3.ctron.com> From: "Harrington, David" To: ipfix@net.doit.wisc.edu Subject: [ipfix] Selecting a protocol Date: Mon, 18 Feb 2002 13:30:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B8AA.5EC1E100" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B8AA.5EC1E100 Content-Type: text/plain Hi, I'm a little confused about the goals and the steps we're taking to get there. Randy points out that the goal is to *select a protocol*, and the selected protocol should have all the benefits, use congestion-aware transport, and not be encumbered. Of these three requirements, two are simple binary conditions. Does this mean we can eliminate some of the proposed protocols using these binary conditions? Which of the proposed protocols are congestion-aware and not encumbered? Of the proposals that are not congestion-aware, is there a way to define a manner of usage that would provide such congestion-awareness for the protocol, without modifying the protocol? Of the proposals that are currently encumbered, do we have statements from vendors to eliminate the legal and financial burdens from their proposals? Are there any encumbrances that have not yet been identified by vendors? Should the protocols that do not meet these conditions be eliminated from the drafts? If we do this, which proposals do we have left to consider? Randy, as AD can you tell us, are there also requirements for addressing security that would eliminate some proposals? Thanks, dbh > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Saturday, February 16, 2002 7:34 PM > To: Peram Marimuthu > Cc: ipfix@net.doit.wisc.edu > Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design > draft updates) > > > [ ad hat on ] > > > To say, IPfix offers a choice of 3 alternatives is as good as not > > standardization at all. > > from the wg charter: > > "This group will select a protocol ..." > > note the use of the singular. and note "select," not "invent." and > > "Specific Goals > > o Define the notion of a "standard IP flow." The flow definition > will be a practical one, similar to those currently in use by > existing non-standard flow information export protocols > which have > attempted to achieve similar goals but have not documented their > flow defintion." > > > We need to take a suitable path which proposes a middle ground with > > all the benefits. > > if it has all the benefits, uses congestion-aware transport, > is not encumbered, ... it need not be a middle ground, just > an effective one. > > note also > > "Goals and Milestones: > > Feb 02 Submit IPFX-REQUIREMENTS to IESG for publication as an > Informational RFC > Feb 02 Submit Internet-Draft on IP Flow Export Architecture > Feb 02 Submit Internet-Draft on IP Flow Export Data Model" > > randy > > -- > 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/ > ------_=_NextPart_001_01C1B8AA.5EC1E100 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Selecting a protocol

Hi,

I'm a little confused about the goals and the steps = we're taking to get there.
Randy points out that the goal is to *select a = protocol*, and the selected protocol should have all the benefits, use = congestion-aware transport, and not be encumbered.

Of these three requirements, two are simple binary = conditions. Does this mean we can eliminate some of the proposed = protocols using these binary conditions?

Which of the proposed protocols are congestion-aware = and not encumbered?

Of the proposals that are not congestion-aware, is = there a way to define a manner of usage that would provide such = congestion-awareness for the protocol, without modifying the = protocol?

Of the proposals that are currently encumbered, do we = have statements from vendors to eliminate the legal and financial = burdens from their proposals? Are there any encumbrances that have not = yet been identified by vendors?

Should the protocols that do not meet these = conditions be eliminated from the drafts?
If we do this, which proposals do we have left to = consider?

Randy, as AD can you tell us, are there also = requirements for addressing security that would eliminate some = proposals?

Thanks,
dbh

> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Saturday, February 16, 2002 7:34 = PM
> To: Peram Marimuthu
> Cc: ipfix@net.doit.wisc.edu
> Subject: Re: 3 definitions (was Re: [ipfix] = IPFIX Design
> draft updates)
>
>
> [ ad hat on ]
>
> > To say, IPfix offers a choice of 3 = alternatives is as good as not
> > standardization at all.
>
> from the wg charter:
>
>   "This group will select a = protocol ..."
>
> note the use of the singular.  and note = "select," not "invent."  and
>
>    "Specific Goals
>
>     o Define the notion of = a "standard IP flow." The flow definition
>       will be a = practical one, similar to those currently in use by
>       existing = non-standard flow information export protocols
> which have
>       attempted = to achieve similar goals but have not documented their
>       flow = defintion."
>
> > We need to take a suitable path which = proposes a middle ground with
> > all the benefits.
>
> if it has all the benefits, uses = congestion-aware transport,
> is not encumbered, ... it need not be a middle = ground, just
> an effective one.
>
> note also
>
>    "Goals and = Milestones:
>
>     Feb 02  Submit = IPFX-REQUIREMENTS to IESG for publication as an
>       =     Informational RFC
>     Feb 02  Submit = Internet-Draft on IP Flow Export Architecture
>     Feb 02  Submit = Internet-Draft on IP Flow Export Data Model"
>
> randy
>
> --
> Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
> in message body
> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
> "unsubscribe ipfix" in message = body
> Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B8AA.5EC1E100-- -- 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 Feb 18 14:11:01 2002 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 OAA14080 for ; Mon, 18 Feb 2002 14:11:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16csof-0006Uo-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 12:47:09 -0600 Received: from rip.psg.com ([147.28.0.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16csoe-0006UP-00 for ipfix@net.doit.wisc.edu; Mon, 18 Feb 2002 12:47:08 -0600 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16csnc-0009iq-00; Mon, 18 Feb 2002 10:46:04 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Harrington, David" Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Selecting a protocol References: <0BF8B32B723ED5119E0B0002A551748B01FA092A@corp-exc3.ctron.com> Message-Id: Date: Mon, 18 Feb 2002 10:46:04 -0800 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit realistically, i think you will have to modify any of the existing protocols to meet robust needs. and yes, i think security should be a consideration. [ note that snmpv3 control and tcp export over ipsec may meet some of the more difficult issues you raise ] randy -- 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 Feb 18 14:28:54 2002 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 OAA14791 for ; Mon, 18 Feb 2002 14:28:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ct9y-0006ze-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 13:09:10 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ct9w-0006yt-00 for ipfix-arch@net.doit.wisc.edu; Mon, 18 Feb 2002 13:09:08 -0600 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-76.cisco.com [144.254.7.76]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA07551 for ; Mon, 18 Feb 2002 20:08:35 +0100 (MET) Message-ID: <3C715141.3C4FE215@cisco.com> Date: Mon, 18 Feb 2002 20:08:49 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] applicability document? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit All, As already proposed by Nevil, I think this is a good idea to have an applicability document. What I would see in there is: - section 8.4 on "ipfix considerations for middleboxes" - section 8.5 on "QOS Monitoring with IPFIX" - section 11.1 on "Some applications of IPFIX" What do you think? Regards, Benoit -- 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 Feb 18 20:33:59 2002 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 UAA26116 for ; Mon, 18 Feb 2002 20:33:59 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cyrJ-0006UZ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 19:14:17 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cyrG-0006Tv-00 for ipfix@net.doit.wisc.edu; Mon, 18 Feb 2002 19:14:14 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1J1D4I04247; Mon, 18 Feb 2002 19:13:05 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFZYCV>; Mon, 18 Feb 2002 17:13:03 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008AE54FA@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: n.brownlee@auckland.ac.nz, kevin.zhang@xacct.com, ram.gopal@nokia.com Cc: ipfix@net.doit.wisc.edu, plonka@doit.wisc.edu Subject: RE: [ipfix] WG process: next steps Date: Mon, 18 Feb 2002 17:12:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B8E2.9210F8B0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B8E2.9210F8B0 Content-Type: text/plain; charset="iso-8859-1" Nevil, this "arbitrary cutoff" point took out the three active people on this list that were "pro" in-band configuration. Not to mention that this decision did not seem to be WG consensus. What function did you use to find out this arbitrary cutoff point? I want to use these odds in Las Vegas... -RP >-----Original Message----- >From: n.brownlee@auckland.ac.nz [mailto:n.brownlee@auckland.ac.nz] >Sent: Saturday, February 16, 2002 5:32 PM >To: kevin.zhang@xacct.com; ram.gopal@nokia.com >Cc: ipfix@net.doit.wisc.edu; plonka@doit.wisc.edu; >n.brownlee@auckland.ac.nz >Subject: Re: [ipfix] WG process: next steps > > > >Hello Kevin and Ram: > >Thanks for your emails, both asking how I'd come to choose the 5 people >for Monday's teleconference. > >As I tried to point out in that note, I'm pushing the WG towards having >a -00 (i.e a starting point) pair of IPFIX drafts. To get that done >before Friday I'm sure we need to keep the group small, so I chose an >arbitrary cutoff point. > >As I also said, the -00 drafts are a starting point. We can - indeed, >will - discuss the question of how we acknowledge all the WG input at >the Minneapolis meeting. In particular, the people doing the editing >through next week are not neccessarily the ones who will be >the document that's not what you said in you first email. >authors. As my next suggestion for that, how about picking one author >from each of the groups that have published individual drafts within >IPFIX? > >Cheers, Nevil > >----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > >-- >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/ > ------_=_NextPart_001_01C1B8E2.9210F8B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] WG process: next steps

Nevil,

this "arbitrary cutoff" point took out the = three active people on this list that were "pro" in-band = configuration. Not to mention that this decision did not seem to be WG = consensus.

What function did you use to find out this arbitrary = cutoff point? I want to use these odds in Las Vegas...

-RP

>-----Original Message-----
>From: n.brownlee@auckland.ac.nz [mailto:n.brownlee@auckland.ac.= nz]
>Sent: Saturday, February 16, 2002 5:32 PM
>To: kevin.zhang@xacct.com; = ram.gopal@nokia.com
>Cc: ipfix@net.doit.wisc.edu; = plonka@doit.wisc.edu;
>n.brownlee@auckland.ac.nz
>Subject: Re: [ipfix] WG process: next = steps
>
>
>
>Hello Kevin and Ram:
>
>Thanks for your emails, both asking how I'd come = to choose the 5 people
>for Monday's teleconference. 
>
>As I tried to point out in that note, I'm = pushing the WG towards having
>a -00 (i.e a starting point) pair of IPFIX = drafts.  To get that done
>before Friday I'm sure we need to keep the group = small, so I chose an
>arbitrary cutoff point. 
>
>As I also said, the -00 drafts are a starting = point.  We can - indeed,
>will - discuss the question of how we = acknowledge all the WG input at
>the Minneapolis meeting.  In particular, = the people doing the editing
>through next week are not neccessarily the ones = who will be
>the document

that's not what you said in you first email.

>authors.  As my next suggestion for that, = how about picking one author
>from each of the groups that have published = individual drafts within
>IPFIX?
>
>Cheers, Nevil
>
>-----------------------------------------------------------= ------------
>   Nevil = Brownlee          &nbs= p;        Director, Technology = Development
>   Phone: +64 9 373 7599 = x8941      ITSS, The University of = Auckland
>   FAX: +64 9 373 = 7021      Private Bag 92019, Auckland, New = Zealand
>
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B8E2.9210F8B0-- -- 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 Feb 18 20:41:57 2002 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 UAA26306 for ; Mon, 18 Feb 2002 20:41:57 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cz2o-0006h2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 19:26:10 -0600 Received: from rip.psg.com ([147.28.0.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16cz2m-0006gn-00 for ipfix@net.doit.wisc.edu; Mon, 18 Feb 2002 19:26:08 -0600 Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16cz2A-000LCd-00; Mon, 18 Feb 2002 17:25:30 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Reinaldo Penno" Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] WG process: next steps References: <4F973E944951D311B6660008C7917CF008AE54FA@zsc4c008.us.nortel.com> Message-Id: Date: Mon, 18 Feb 2002 17:25:30 -0800 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit > this "arbitrary cutoff" point was not arbitrary. look at the milestones in the wg charter and realize the cut-off dates for i-ds. randy -- 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 Feb 18 21:31:14 2002 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 VAA27076 for ; Mon, 18 Feb 2002 21:31:14 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16cznh-0007lY-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 20:14:37 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16czne-0007kv-00 for ipfix@net.doit.wisc.edu; Mon, 18 Feb 2002 20:14:34 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1J2DxI08632; Mon, 18 Feb 2002 20:14:00 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFZYQA>; Mon, 18 Feb 2002 18:13:58 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008AE5546@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Randy Bush Cc: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] WG process: next steps Date: Mon, 18 Feb 2002 18:13:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B8EB.136C8930" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B8EB.136C8930 Content-Type: text/plain; charset="iso-8859-1" Randy, The arbitrary in Nevil's email was in relation to the number and identities of the editors. Yes, we need to meet tha date but the relation of the function used to find out the number and the identities and the date remains a mystery. And probably will... -RP >-----Original Message----- >From: Randy Bush [mailto:randy@psg.com] >Sent: Monday, February 18, 2002 5:26 PM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: ipfix@net.doit.wisc.edu >Subject: RE: [ipfix] WG process: next steps > > >> this "arbitrary cutoff" point > >was not arbitrary. look at the milestones in the wg charter >and realize the >cut-off dates for i-ds. > >randy > ------_=_NextPart_001_01C1B8EB.136C8930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] WG process: next steps

Randy,

The arbitrary in Nevil's email was in relation to the = number and identities of the editors. Yes, we need to meet tha date but = the relation of the function used to find out the number and the = identities and the date remains a mystery. And probably = will...

-RP

>-----Original Message-----
>From: Randy Bush [mailto:randy@psg.com]
>Sent: Monday, February 18, 2002 5:26 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: ipfix@net.doit.wisc.edu
>Subject: RE: [ipfix] WG process: next = steps
>
>
>> this "arbitrary cutoff" = point
>
>was not arbitrary.  look at the milestones = in the wg charter
>and realize the
>cut-off dates for i-ds.
>
>randy
>

------_=_NextPart_001_01C1B8EB.136C8930-- -- 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 Feb 18 23:03:17 2002 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 XAA00447 for ; Mon, 18 Feb 2002 23:03:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16d1EK-0001rR-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 21:46:12 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16d1EH-0001qq-00 for ipfix-arch@net.doit.wisc.edu; Mon, 18 Feb 2002 21:46:09 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1J3jQI13041; Mon, 18 Feb 2002 21:45:27 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFZY60>; Mon, 18 Feb 2002 19:45:25 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008AE5571@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Benoit Claise , ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] applicability document? Date: Mon, 18 Feb 2002 19:45:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B8F7.DB5FDC10" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B8F7.DB5FDC10 Content-Type: text/plain; charset="iso-8859-1" I think it's a good idea Benoit. comments inline... >-----Original Message----- >From: Benoit Claise [mailto:bclaise@cisco.com] >Sent: Monday, February 18, 2002 11:09 AM >To: ipfix-arch@net.doit.wisc.edu >Subject: [ipfix-arch] applicability document? > > >All, > >As already proposed by Nevil, I think this is a good idea to have an >applicability document. >What I would see in there is: >- section 8.4 on "ipfix considerations for middleboxes" Some of it could be on the applicability. But some of it need to be on the arch document. Also, If you want to include CDI and OPES under the middlebox umbrella, then there is no need for a different section. Otherwise a section on OPES is deserved due to the uniqueness of the flow handling. >- section 8.5 on "QOS Monitoring with IPFIX" I like this section. >- section 11.1 on "Some applications of IPFIX" > >What do you think? > >Regards, Benoit > > >-- >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/ > ------_=_NextPart_001_01C1B8F7.DB5FDC10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] applicability document?

I think it's a good idea Benoit.

comments inline...

>-----Original Message-----
>From: Benoit Claise [mailto:bclaise@cisco.com]
>Sent: Monday, February 18, 2002 11:09 AM
>To: ipfix-arch@net.doit.wisc.edu
>Subject: [ipfix-arch] applicability = document?
>
>
>All,
>
>As already proposed by Nevil, I think this is a = good idea to have an
>applicability document.
>What I would see in there is:
>- section 8.4 on "ipfix considerations for = middleboxes"

Some of it could be on the applicability. But some of = it need to be on the arch document. Also, If you want to include CDI = and OPES under the middlebox umbrella, then there is no need for a = different section. Otherwise a section on OPES is deserved  due to = the uniqueness of the flow handling.

>- section 8.5 on "QOS Monitoring with = IPFIX"

I like this section.

>- section 11.1 on "Some applications of = IPFIX"
>
>What do you think?
>
>Regards, Benoit
>
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B8F7.DB5FDC10-- -- 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 Feb 18 23:12:35 2002 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 XAA00582 for ; Mon, 18 Feb 2002 23:12:35 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16d1Nh-000221-00 for ipfix-list@mil.doit.wisc.edu; Mon, 18 Feb 2002 21:55:53 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16d1Nf-000218-00 for ipfix-data@net.doit.wisc.edu; Mon, 18 Feb 2002 21:55:51 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1J3pXI13243; Mon, 18 Feb 2002 21:51:33 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFZY7Y>; Mon, 18 Feb 2002 19:51:31 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008AE5572@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, data Subject: RE: [ipfix-data] IPFIX Data Model Document Date: Mon, 18 Feb 2002 19:51:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B8F8.B2A89F40" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B8F8.B2A89F40 Content-Type: text/plain; charset="iso-8859-1" Hello Paul, >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Monday, February 18, 2002 7:34 AM >To: data >Subject: [ipfix-data] IPFIX Data Model Document > > > >The last flurry of mail on this has confused me as to >what we are trying to accomplish in the data model document. > >I thought we were trying to lay out the data sent and >give it precise semantic meaning. Then follow that >with general text on how that data should be sent not >detailed wire encoding. > >As far as I can see there are still some gray areas >in the semantics. For example, with destination VLAN ID, >is it the ultimate destination or is it the VLAN ID >of the outgoing interface? I'm sure there are others. well, this is the same thing as asking if the destination IP address is the address of the interface or the ultimate destination. Both can be used. I rewrote this VLAN ID stuff to include 802.1p. I'm still due to send the changes to KC today... > >If we don't have good defintions we wont have interoperabilty. yep... > > >Paul > >-- >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/ > ------_=_NextPart_001_01C1B8F8.B2A89F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] IPFIX Data Model Document

Hello Paul,

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Monday, February 18, 2002 7:34 AM
>To: data
>Subject: [ipfix-data] IPFIX Data Model = Document
>
>
>
>The last flurry of mail on this has confused me = as to
>what we are trying to accomplish in the data = model document.
>
>I thought we were trying to lay out the data = sent and
>give it precise semantic meaning. Then follow = that
>with general text on how that data should be = sent not
>detailed wire encoding.
>
>As far as I can see there are still some gray = areas
>in the semantics. For example, with destination = VLAN ID,
>is it the ultimate destination or is it the VLAN = ID
>of the outgoing interface? I'm sure there are = others.

well, this is the same thing as asking if the = destination IP address is the address of the interface or the ultimate = destination. Both can be used. I rewrote this VLAN ID stuff to include = 802.1p. I'm still due to send the changes to KC today...

>
>If we don't have good defintions we wont have = interoperabilty.

yep...

>
>
>Paul
>
>--
>Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
>in message body
>Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>"unsubscribe ipfix" in message = body
>Archive     http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1B8F8.B2A89F40-- -- 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 Tue Feb 19 04:00:09 2002 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 EAA12805 for ; Tue, 19 Feb 2002 04:00:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16d5eG-0007kI-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 02:29:16 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16d5eD-0007jf-00 for ipfix-req@net.doit.wisc.edu; Tue, 19 Feb 2002 02:29:13 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1J8SdO22660; Tue, 19 Feb 2002 02:28:40 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAFZZXB>; Tue, 19 Feb 2002 00:28:37 -0800 Message-ID: <7B802811BE77D51189910002A55CFD2C0123BB95@zsc3c032.us.nortel.com> From: "Christian Gilby" To: Peter Ludemann , ipfix-req@net.doit.wisc.edu Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to d raft-ietf-ipfix-reqs-00.txt Date: Tue, 19 Feb 2002 00:28:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B91F.6D95C0A0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B91F.6D95C0A0 Content-Type: text/plain; charset="iso-8859-1" Content Negotiation I agree that the negotiation of the set of attributes that a collector is interested in has a lot of value. Depending on the application, a collector may be interested in a small or large set of attributes. If the list of requested attributes can be advertised to the mesuring device (which can indicate which will be sent) then, IF the device does not ignore the request it can minimize the processing and export data volume required. I.e. no need to send extraneous attributes that the collector will ignore. In-band Configuration The ability to perform the configuration in-band (done in a lightweight manner) will have payoffs in large network deployments with mixed devices from various vendors. It will be a challenge to deal with configuration of existing implementations which can be difficult to add in-band config to (they may need to be configured manually on the box) but believe it is worthwile to have a framework for performing this config in-band for devices in a common way since we are trying to collect a common set of information across the devices. Regards, Chris -----Original Message----- From: Peter Ludemann [mailto:peter.ludemann@xacct.com] Sent: Saturday, February 16, 2002 10:02 AM Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Juergen: Thank-you for pointing out the apparent self-contradiction in my argument. I neglected to complete me argument. I'm glad that everyone agrees on the need for self-describing data. It wasn't clear from all the emails that were flying back and forth. :-) I'd like to address the two other issues that are not yet agreed to: - content negotiation (which extends content advertisement) - configuration of processing (sampling rates, ports, etc.) Some devices are very simple and have no need for any kind of content negotiation. Others (such as our PacketSight probe, which can have over 200 fields) are quite complex and can benefit greatly from content negotiation. The capability to respond to a content request is NOT optional. Every request MUST be answered; but the answer can be to reject the request, to honour it, or to partially honour it. For example: exporter advertises fields A,B,C,D receiver requests only fields A,D exporter responds with: fields A,B,C,D -- if it ignores the request fields A,D -- if it completely honours the request fields A,C,D -- if it partially honours the request One of our concerns with content negotiation was in minimising the development work for putting the transport protocol onto a network element (our target is 2 weeks or less). If the device already has the data available in a particular form, we want to be able to export it as-is. For example, the exporting device determines whether big-endian or little-endian numbers are used; the receiver translates as necessary. This has the advantages: - simpler implementation on the exporting device - minimal performance impact on the exporting device - minimal space requirements on the exporting device Of course, if the exporting device wants to switch the data from little-endian to big-endian (network byte order), we aren't going to prevent it. But we cater to the exporter's needs, not the receiver's. If the exporting device can take advantage of sending fewer fields, it can; but if simplicity of implementation or performance concerns would make it better to ignore content requests, that's also OK. Moving on to the second point: But as 'in-band configuration' i understand the more basic configuration of meter and exporter including which ports to observe, which filtering rules to apply, which flow keys to use, which sampling rate to choose, etc. I would like this kind of configuration also; but I think it is less necessary than content negotiation. Content information must be communicated amongst all the receivers (in a fail-over configuration), so simply using MIBs or a CLI won't work very well. However, the issues of determining sampling rate, observed ports, etc. do not need to be distributed in the same way (if needed, they can be exported as just another kind of record from the network device). I think that this kind of configuration will always remain "machine specific". But it can fit into a very simple structure, something like a list of attribute/value pairs being sent from the receiving device and a accepted/rejected message being sent back [the configuration must do multiple items together because there can be interactions amongst them]. This is similar to the way configuration is done using a MIB, except that it would get around some of the problems with MIB configuration (interactions amongst attributes, confirmation of result, multiple tools needed to do configuration, etc.). To sum up: we need a framework for all the configuration, without requiring agreement on the content (which we might never be able to, especially with backwards support for existing equipment). This is similar to the self-describing data delivery ... the requirement is that data be self-describing and that it contain type information, not that we all agree to a specific data model (there eventually will be standard data models, of course). Similarly, we should agree to a method of in-band content negotiation and processing configuration. - peter ---- Peter Ludemann peter.ludemann@xacct.com Chief Architect +1.408.330.5732 XACCT Technologies, Inc. 2900 Lakeside Drive Santa Clara, CA 95054 -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Juergen Quittek Sent: Saturday, February 16, 2002 7:22 AM To: Peter Ludemann; Reinaldo Penno; calato@riverstonenet.com; Benoit Claise Cc: ram.gopal@nokia.com; zander@fokus.gmd.de; ipfix-req@net.doit.wisc.edu; Kevin Zhang Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Hi Peter, --On 15 February 2002 08:53 -0800 Peter Ludemann wrote: > Juergen Quittek wrote Thursday, February 14, 2002 2:30 PM: > >> So what is your point? Do you want to have in-band configuration >> for the exported attributes/IEs in the requirements document? > > Yes. The CRANE protocol solves real problems that we've encountered; and we > have a number of partners who are using it (sorry, I can't announce these > right now). > >> What would be the application requiring this? Or from which >> general requirement would you derive this one? > > My answer is a little long. Our requirements go beyond just delivering the > kind of data that IPFIX is discussing; but I think that they are very > applicable to IPFIX. > > If all you care about is delivering one set of values which you'll never > change, then there's no need for any in-band configuration. (This would be > true only if you think that the data architecture folks will agree on a > specification with no SHOULDs in the document ...) > > If you anticipate change, then at minimum you need to specify the version of > the data that you're delivering. A more general solution is to use > self-describing data. XML would be fine but it's much too verbose for > delivering thousands of records per second from a small network device. > > So, the minimal requirement is to have some way for the device to advertise > what it has. I don't see a need for all of XML's nesting capabilities; a > simple 2-level scheme (type of record + fields) should suffice. As far, as I followed the ongoing difscussion, (almost) everyone agrees to this. > The receiver could quietly take this advertisement and process it. But our > experience in "IP data mediation" is that people usually only want specific > fields; and they typically want to post-process them. Examples of such > post-processing: associating values with IP addresses (e.g., reversing NAT, > mapping IP to customer), aggregation, filtering, conditional splitting, etc. > plus a host of database-oriented processing, such as looking for error > patterns, for people who hog bandwidth, etc. > > If the sending device can be configured by a MIB or CLI, the receiver can > adapt to what it advertises. But there are good reasons for such > configuration to be done by response from the receiver: > - the needed fields can be derived from the post-processing configuration, > so they naturally reside on the receiver, not the sender > - there can be tens or even thousands of sending devices, so > centralized configuration is desirable (especially if they can't all > have their versions changed simultaneously) > - there needs to be a way of coordinating amongst multiple receivers, > for fail-over deployments > (these aren't hypothetical requirements: we have customers who are looking > at deploying thousands of sending devices; and who require fail-over) > > Once you decide that the sender should advertises its data, it doesn't take > much more work to allow the receiver to respond with a list of fields that > it does or doesn't want. The sender can just mark the fields it won't send. > The advantages of this are: > - bandwidth saving (probably not very important) > - computation saving on the sender (this can be significant > in our experience) I think we are discussing two different issues. Your suggestion covers - as far as I have understood so far - the negotiation between sender an receiver about individual attributes/fields/IEs to be sent. But as 'in-band configuration' i understand the more basic configuration of meter and exporter including which ports to observe, which filtering rules to apply, which flow keys to use, which sampling rate to choose, etc. But coming back to your point: If you say the exporter may ignore it, why then making it a requirement? Requirements should be essentially needed and not just nice to have, but opyionally ignored at any time. I think your point can be a valuable contribution to the architecture, but following your argument it does not belong into the requirement docvument. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > Our proposal makes it OPTIONAL for the sender to respond to the > configuration request. The sender can ignore the configuration request and > still send all the fields -- the receiver will just have to accept them (and > throw away what it doesn't want). But if the sender can take advantage of > the configuration request (e.g., turning off expensive computations), then > it has a simple mechanism for doing so. > > > ---- > > Peter Ludemann > Chief Architect, XACCT > +1.408.330.5732 > ------_=_NextPart_001_01C1B91F.6D95C0A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: in band configuration? RE: [ipfix-req] Proposed changes to = draft-ietf-ipfix-reqs-00.txt

Content Negotiation
  I agree that the negotiation of the set of = attributes that a collector is interested in has a lot of value.  = Depending on the application, a collector may be interested in a small = or large set of attributes.  If the list of requested attributes = can be advertised to the mesuring device (which can indicate which will = be sent) then, IF the device does not ignore the request it can = minimize the processing and export data volume required.  I.e. no = need to send extraneous attributes that the collector will = ignore.

In-band Configuration
  The ability to perform the configuration = in-band (done in a lightweight manner) will have payoffs in large = network deployments with mixed devices from various vendors.  It = will be a challenge to deal with configuration of existing = implementations which can be difficult to add in-band config to (they = may need to be configured manually on the box) but believe it is = worthwile to have a framework for performing this config in-band for = devices in a common way since we are trying to collect a common set of = information across the devices.


Regards,
Chris
-----Original Message-----
From: Peter Ludemann [mailto:peter.ludemann@xacct.com= ]
Sent: Saturday, February 16, 2002 10:02 AM
Subject: RE: in band configuration? RE: [ipfix-req] = Proposed changes to
draft-ietf-ipfix-reqs-00.txt

Juergen:

Thank-you for pointing out the apparent = self-contradiction in my argument.
I neglected to complete me argument.

I'm glad that everyone agrees on the need for = self-describing data. It
wasn't clear from all the emails that were flying = back and forth. :-)

I'd like to address the two other issues that are not = yet agreed to:
 - content negotiation (which extends content = advertisement)
 - configuration of processing (sampling rates, = ports, etc.)

Some devices are very simple and have no need for any = kind of content
negotiation. Others (such as our PacketSight probe, = which can have over 200
fields) are quite complex and can benefit greatly = from content negotiation.

The capability to respond to a content request is NOT = optional. Every
request MUST be answered; but the answer can be to = reject the request, to
honour it, or to partially honour it. For = example:

    exporter advertises fields = A,B,C,D
    receiver requests only fields = A,D
    exporter responds with:
      fields A,B,C,D -- if = it ignores the request
      fields = A,D     -- if it completely honours the = request
      fields A,C,D &nbs= p; -- if it partially honours the request

One of our concerns with content negotiation was in = minimising the
development work for putting the transport protocol = onto a network element
(our target is 2 weeks or less). If the device = already has the data
available in a particular form, we want to be able = to export it as-is. For
example, the exporting device determines whether = big-endian or little-endian
numbers are used; the receiver translates as = necessary. This has the
advantages:
   - simpler implementation on the = exporting device
   - minimal performance impact on the = exporting device
   - minimal space requirements on the = exporting device
Of course, if the exporting device wants to switch = the data from
little-endian to big-endian (network byte order), we = aren't going to prevent
it. But we cater to the exporter's needs, not the = receiver's.

If the exporting device can take advantage of sending = fewer fields, it can;
but if simplicity of implementation or performance = concerns would make it
better to ignore content requests, that's also = OK.

Moving on to the second point:
   But as 'in-band configuration' i = understand the more
   basic configuration of meter and = exporter including which ports
   to observe, which filtering rules to = apply, which flow keys to use,
   which sampling rate to choose, = etc.

I would like this kind of configuration also; but I = think it is less
necessary than content negotiation. Content = information must be communicated
amongst all the receivers (in a fail-over = configuration), so simply using
MIBs or a CLI won't work very well. However, the = issues of determining
sampling rate, observed ports, etc. do not need to = be distributed in the
same way (if needed, they can be exported as just = another kind of record
from the network device).

I think that this kind of configuration will always = remain "machine
specific". But it can fit into a very simple = structure, something like a
list of attribute/value pairs being sent from the = receiving device and a
accepted/rejected message being sent back [the = configuration must do
multiple items together because there can be = interactions amongst them].
This is similar to the way configuration is done = using a MIB, except that it
would get around some of the problems with MIB = configuration (interactions
amongst attributes, confirmation of result, multiple = tools needed to do
configuration, etc.).

To sum up: we need a framework for all the = configuration, without requiring
agreement on the content (which we might never be = able to, especially with
backwards support for existing equipment). This is = similar to the
self-describing data delivery ... the requirement is = that data be
self-describing and that it contain type = information, not that we all agree
to a specific data model (there eventually will be = standard data models, of
course). Similarly, we should agree to a method of = in-band content
negotiation and processing configuration.


- peter

----
Peter = Ludemann           = peter.ludemann@xacct.com
Chief = Architect          = +1.408.330.5732
XACCT Technologies, Inc.
2900 Lakeside Drive      = Santa Clara, CA 95054

-----Original Message-----
From: majordomo listserver [mailto:majordomo@mil.doit.wi= sc.edu]On Behalf
Of Juergen Quittek
Sent: Saturday, February 16, 2002 7:22 AM
To: Peter Ludemann; Reinaldo Penno; = calato@riverstonenet.com; Benoit
Claise
Cc: ram.gopal@nokia.com; zander@fokus.gmd.de;
ipfix-req@net.doit.wisc.edu; Kevin Zhang
Subject: RE: in band configuration? RE: [ipfix-req] = Proposed changes to
draft-ietf-ipfix-reqs-00.txt


Hi Peter,

--On 15 February 2002 08:53 -0800 Peter Ludemann = <peter.ludemann@xacct.com>
wrote:

> Juergen Quittek wrote Thursday, February 14, = 2002 2:30 PM:
>
>> So what is your point? Do you want to have = in-band configuration
>> for the exported attributes/IEs in the = requirements document?
>
> Yes. The CRANE protocol solves real problems = that we've encountered; and
we
> have a number of partners who are using it = (sorry, I can't announce these
> right now).
>
>> What would be the application requiring = this? Or from which
>> general requirement would you derive this = one?
>
> My answer is a little long. Our requirements go = beyond just delivering the
> kind of data that IPFIX is discussing; but I = think that they are very
> applicable to IPFIX.
>
> If all you care about is delivering one set of = values which you'll never
> change, then there's no need for any in-band = configuration. (This would be
> true only if you think that the data = architecture folks will agree on a
> specification with no SHOULDs in the document = ...)
>
> If you anticipate change, then at minimum you = need to specify the version
of
> the data that you're delivering. A more general = solution is to use
> self-describing data.  XML would be fine = but it's much too verbose for
> delivering thousands of records per second from = a small network device.
>
> So, the minimal requirement is to have some way = for the device to
advertise
> what it has.  I don't see a need for all = of XML's nesting capabilities; a
> simple 2-level scheme (type of record + fields) = should suffice.

As far, as I followed the ongoing difscussion, = (almost) everyone agrees
to this.

> The receiver could quietly take this = advertisement and process it. But our
> experience in "IP data mediation" is = that people usually only want
specific
> fields; and they typically want to post-process = them. Examples of such
> post-processing: associating values with IP = addresses (e.g., reversing
NAT,
> mapping IP to customer), aggregation, = filtering, conditional splitting,
etc.
> plus a host of database-oriented processing, = such as looking for error
> patterns, for people who hog bandwidth, = etc.
>
> If the sending device can be configured by a = MIB or CLI, the receiver can
> adapt to what it advertises. But there are good = reasons for such
> configuration to be done by response from the = receiver:
>   - the needed fields can be derived = from the post-processing
configuration,
>     so they naturally = reside on the receiver, not the sender
>   - there can be tens or even = thousands of sending devices, so
>     centralized = configuration is desirable (especially if they can't all
>     have their versions = changed simultaneously)
>   - there needs to be a way of = coordinating amongst multiple receivers,
>     for fail-over = deployments
> (these aren't hypothetical requirements: we = have customers who are looking
> at deploying thousands of sending devices; and = who require fail-over)
>
> Once you decide that the sender should = advertises its data, it doesn't
take
> much more work to allow the receiver to respond = with a list of fields that
> it does or doesn't want.  The sender can = just mark the fields it won't
send.
> The advantages of this are:
>   - bandwidth saving (probably not = very important)
>   - computation saving on the sender = (this can be significant
>     in our = experience)

I think we are discussing two different issues. Your = suggestion
covers - as far as I have understood so far - the = negotiation
between sender an receiver about individual = attributes/fields/IEs
to be sent. But as 'in-band configuration' i = understand the more
basic configuration of meter and exporter including = which ports
to observe, which filtering rules to apply, which = flow keys to use,
which sampling rate to choose, etc.

But coming back to your point: If you say the = exporter may ignore it,
why then making it a requirement? Requirements = should be essentially
needed and not just nice to have, but opyionally = ignored at any time.

I think your point can be a valuable contribution to = the architecture,
but following your argument it does not belong into = the requirement
docvument.

    Juergen
--
Juergen Quittek     = quittek@ccrle.nec.de     Tel: +49 6221 = 90511-15
NEC Europe Ltd.,    Network = Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, = Germany   http://www.ccrle.nec.de

>
> Our proposal makes it OPTIONAL for the sender = to respond to the
> configuration request.  The sender can = ignore the configuration request
and
> still send all the fields -- the receiver will = just have to accept them
(and
> throw away what it doesn't want).  But if = the sender can take advantage of
> the configuration request (e.g., turning off = expensive computations), then
> it has a simple mechanism for doing so.
>
>
> ----
>
> Peter Ludemann
> Chief Architect, XACCT
> +1.408.330.5732
>

------_=_NextPart_001_01C1B91F.6D95C0A0-- -- 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 Tue Feb 19 06:03:49 2002 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 GAA14022 for ; Tue, 19 Feb 2002 06:03:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16d7nb-0003Vf-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 04:47:03 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16d7nY-0003UL-00 for ipfix-req@net.doit.wisc.edu; Tue, 19 Feb 2002 04:47:00 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g1JAkQG18629; Tue, 19 Feb 2002 11:46:26 +0100 (CET) Date: Tue, 19 Feb 2002 11:46:26 +0100 (CET) From: Benoit Claise Message-Id: <200202191046.g1JAkQG18629@bru-cse-222.cisco.com> To: peter.ludemann@xacct.com, ipfix-req@net.doit.wisc.edu, cgilby@nortelnetworks.com Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to d raft-ietf-ipfix-reqs-00.txt X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver Chris, > > Content Negotiation > I agree that the negotiation of the set of attributes that a collector is > interested in has a lot of value. Depending on the application, a collector > may be interested in a small or large set of attributes. If the list of > requested attributes can be advertised to the mesuring device (which can > indicate which will be sent) then, IF the device does not ignore the request > it can minimize the processing and export data volume required. I.e. no > need to send extraneous attributes that the collector will ignore. I don't call this above "content negotiation" but pure configuration. You tell the exporter which fields to export by defining a template. Regards, Benoit. > > In-band Configuration > The ability to perform the configuration in-band (done in a lightweight > manner) will have payoffs in large network deployments with mixed devices > from various vendors. It will be a challenge to deal with configuration of > existing implementations which can be difficult to add in-band config to > (they may need to be configured manually on the box) but believe it is > worthwile to have a framework for performing this config in-band for devices > in a common way since we are trying to collect a common set of information > across the devices. > > > Regards, > Chris > -----Original Message----- > From: Peter Ludemann [mailto:peter.ludemann@xacct.com] > Sent: Saturday, February 16, 2002 10:02 AM > Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to > draft-ietf-ipfix-reqs-00.txt > > Juergen: > > Thank-you for pointing out the apparent self-contradiction in my argument. > I neglected to complete me argument. > > I'm glad that everyone agrees on the need for self-describing data. It > wasn't clear from all the emails that were flying back and forth. :-) > > I'd like to address the two other issues that are not yet agreed to: > - content negotiation (which extends content advertisement) > - configuration of processing (sampling rates, ports, etc.) > > Some devices are very simple and have no need for any kind of content > negotiation. Others (such as our PacketSight probe, which can have over 200 > fields) are quite complex and can benefit greatly from content negotiation. > > The capability to respond to a content request is NOT optional. Every > request MUST be answered; but the answer can be to reject the request, to > honour it, or to partially honour it. For example: > > exporter advertises fields A,B,C,D > receiver requests only fields A,D > exporter responds with: > fields A,B,C,D -- if it ignores the request > fields A,D -- if it completely honours the request > fields A,C,D -- if it partially honours the request > > One of our concerns with content negotiation was in minimising the > development work for putting the transport protocol onto a network element > (our target is 2 weeks or less). If the device already has the data > available in a particular form, we want to be able to export it as-is. For > example, the exporting device determines whether big-endian or little-endian > numbers are used; the receiver translates as necessary. This has the > advantages: > - simpler implementation on the exporting device > - minimal performance impact on the exporting device > - minimal space requirements on the exporting device > Of course, if the exporting device wants to switch the data from > little-endian to big-endian (network byte order), we aren't going to prevent > it. But we cater to the exporter's needs, not the receiver's. > > If the exporting device can take advantage of sending fewer fields, it can; > but if simplicity of implementation or performance concerns would make it > better to ignore content requests, that's also OK. > > Moving on to the second point: > But as 'in-band configuration' i understand the more > basic configuration of meter and exporter including which ports > to observe, which filtering rules to apply, which flow keys to use, > which sampling rate to choose, etc. > > I would like this kind of configuration also; but I think it is less > necessary than content negotiation. Content information must be communicated > amongst all the receivers (in a fail-over configuration), so simply using > MIBs or a CLI won't work very well. However, the issues of determining > sampling rate, observed ports, etc. do not need to be distributed in the > same way (if needed, they can be exported as just another kind of record > from the network device). > > I think that this kind of configuration will always remain "machine > specific". But it can fit into a very simple structure, something like a > list of attribute/value pairs being sent from the receiving device and a > accepted/rejected message being sent back [the configuration must do > multiple items together because there can be interactions amongst them]. > This is similar to the way configuration is done using a MIB, except that it > would get around some of the problems with MIB configuration (interactions > amongst attributes, confirmation of result, multiple tools needed to do > configuration, etc.). > > To sum up: we need a framework for all the configuration, without requiring > agreement on the content (which we might never be able to, especially with > backwards support for existing equipment). This is similar to the > self-describing data delivery ... the requirement is that data be > self-describing and that it contain type information, not that we all agree > to a specific data model (there eventually will be standard data models, of > course). Similarly, we should agree to a method of in-band content > negotiation and processing configuration. > > > - peter > > ---- > Peter Ludemann peter.ludemann@xacct.com > Chief Architect +1.408.330.5732 > XACCT Technologies, Inc. > 2900 Lakeside Drive Santa Clara, CA 95054 > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Juergen Quittek > Sent: Saturday, February 16, 2002 7:22 AM > To: Peter Ludemann; Reinaldo Penno; calato@riverstonenet.com; Benoit > Claise > Cc: ram.gopal@nokia.com; zander@fokus.gmd.de; > ipfix-req@net.doit.wisc.edu; Kevin Zhang > Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to > draft-ietf-ipfix-reqs-00.txt > > > Hi Peter, > > --On 15 February 2002 08:53 -0800 Peter Ludemann > wrote: > > > Juergen Quittek wrote Thursday, February 14, 2002 2:30 PM: > > > >> So what is your point? Do you want to have in-band configuration > >> for the exported attributes/IEs in the requirements document? > > > > Yes. The CRANE protocol solves real problems that we've encountered; and > we > > have a number of partners who are using it (sorry, I can't announce these > > right now). > > > >> What would be the application requiring this? Or from which > >> general requirement would you derive this one? > > > > My answer is a little long. Our requirements go beyond just delivering the > > kind of data that IPFIX is discussing; but I think that they are very > > applicable to IPFIX. > > > > If all you care about is delivering one set of values which you'll never > > change, then there's no need for any in-band configuration. (This would be > > true only if you think that the data architecture folks will agree on a > > specification with no SHOULDs in the document ...) > > > > If you anticipate change, then at minimum you need to specify the version > of > > the data that you're delivering. A more general solution is to use > > self-describing data. XML would be fine but it's much too verbose for > > delivering thousands of records per second from a small network device. > > > > So, the minimal requirement is to have some way for the device to > advertise > > what it has. I don't see a need for all of XML's nesting capabilities; a > > simple 2-level scheme (type of record + fields) should suffice. > > As far, as I followed the ongoing difscussion, (almost) everyone agrees > to this. > > > The receiver could quietly take this advertisement and process it. But our > > experience in "IP data mediation" is that people usually only want > specific > > fields; and they typically want to post-process them. Examples of such > > post-processing: associating values with IP addresses (e.g., reversing > NAT, > > mapping IP to customer), aggregation, filtering, conditional splitting, > etc. > > plus a host of database-oriented processing, such as looking for error > > patterns, for people who hog bandwidth, etc. > > > > If the sending device can be configured by a MIB or CLI, the receiver can > > adapt to what it advertises. But there are good reasons for such > > configuration to be done by response from the receiver: > > - the needed fields can be derived from the post-processing > configuration, > > so they naturally reside on the receiver, not the sender > > - there can be tens or even thousands of sending devices, so > > centralized configuration is desirable (especially if they can't all > > have their versions changed simultaneously) > > - there needs to be a way of coordinating amongst multiple receivers, > > for fail-over deployments > > (these aren't hypothetical requirements: we have customers who are looking > > at deploying thousands of sending devices; and who require fail-over) > > > > Once you decide that the sender should advertises its data, it doesn't > take > > much more work to allow the receiver to respond with a list of fields that > > it does or doesn't want. The sender can just mark the fields it won't > send. > > The advantages of this are: > > - bandwidth saving (probably not very important) > > - computation saving on the sender (this can be significant > > in our experience) > > I think we are discussing two different issues. Your suggestion > covers - as far as I have understood so far - the negotiation > between sender an receiver about individual attributes/fields/IEs > to be sent. But as 'in-band configuration' i understand the more > basic configuration of meter and exporter including which ports > to observe, which filtering rules to apply, which flow keys to use, > which sampling rate to choose, etc. > > But coming back to your point: If you say the exporter may ignore it, > why then making it a requirement? Requirements should be essentially > needed and not just nice to have, but opyionally ignored at any time. > > I think your point can be a valuable contribution to the architecture, > but following your argument it does not belong into the requirement > docvument. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > > Our proposal makes it OPTIONAL for the sender to respond to the > > configuration request. The sender can ignore the configuration request > and > > still send all the fields -- the receiver will just have to accept them > (and > > throw away what it doesn't want). But if the sender can take advantage of > > the configuration request (e.g., turning off expensive computations), then > > it has a simple mechanism for doing so. > > > > > > ---- > > > > Peter Ludemann > > Chief Architect, XACCT > > +1.408.330.5732 > > -- 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 Tue Feb 19 07:10:19 2002 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 HAA15336 for ; Tue, 19 Feb 2002 07:10:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16d8nH-0006BR-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 05:50:47 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16d8nE-0006BH-00 for ipfix-arch@net.doit.wisc.edu; Tue, 19 Feb 2002 05:50:44 -0600 Received: from fokus.fhg.de (dhcp206 [195.37.78.206]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1JBobp26707; Tue, 19 Feb 2002 12:50:37 +0100 (MET) Message-ID: <3C723B66.1060608@fokus.fhg.de> Date: Tue, 19 Feb 2002 12:47:50 +0100 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Benoit Claise CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] applicability document? References: <3C715141.3C4FE215@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, I agree that it is a good idea to create an applicability document. I would propose to have one section for each of the applications in the requirements documents. Maybe there are also further applications that can use IPFIX ? Also the relations of IPFIX to other frameworks/protocols could be put into this document (or a separate one ?) I propose to have the following parts in the document: 1. Applications of IPFIX 1.1 Accounting with IPFIX 1.2 Traffic Profiling with IPFIX 1.3 Traffic Engineering with IPFIX 1.4 Intrusion detection with IPFIX 1.5 QoS Monitoring with IPFIX - other applications ? 2. Relation of IPFIX to other frameworks and protocols 2.1 IPFIX and AAA 2.2 IPFIX and RTFM 2.3 IPFIX considerations for middleboxes 2.4 IPFIX and RMON 2.5 IPFIX and IPPM (e.g. IPPM MIB) 2.6 IPFIX and PSAMP - further relations I could contribute some text at least to 1.1, 1.5 ,2.1, 2.2 and 2.5. If others agree, that we should work on this document, maybe Dave can open an additional "pseudo"- mailling-list [ipfix-appl] ? Regards Tanja Benoit Claise wrote: >All, > >As already proposed by Nevil, I think this is a good idea to have an >applicability document. >What I would see in there is: >- section 8.4 on "ipfix considerations for middleboxes" >- section 8.5 on "QOS Monitoring with IPFIX" >- section 11.1 on "Some applications of IPFIX" > >What do you think? > >Regards, Benoit > > >-- >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/ > -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- 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 Tue Feb 19 08:44:51 2002 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 IAA18066 for ; Tue, 19 Feb 2002 08:44:51 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dAGP-0000Ur-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 07:24:57 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dAGO-0000UW-00 for ipfix-req@net.doit.wisc.edu; Tue, 19 Feb 2002 07:24:56 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g1JDOPn23173 for ipfix-req@net.doit.wisc.edu; Tue, 19 Feb 2002 14:24:25 +0100 (CET) Date: Tue, 19 Feb 2002 14:24:25 +0100 (CET) From: Benoit Claise Message-Id: <200202191324.g1JDOPn23173@bru-cse-222.cisco.com> To: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] Some extra changes for the req. document X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver All, Some more proposed changes. 1. I would like to complete the following sections, with the non-indented text 3. Distinguishing Flows Packets are mapped to flows by evaluating their properties. Packets with common properties are considered to belong to the same flow. A packet showing at least one difference in the set of properties is considered to belong to a different flow. The following subsections list a set of properties which a measuring device MUST, SHOULD, or MAY be able to evaluate for mapping packets to flows. Please note that requiring the ability to evaluate a certain property does not imply that this property must be evaluated for each packet. In other words, compliant with IPFIX means that the box in general must be able, via its configuration, to somehow support to distinguish flows via all the MUST fields, even if in certain circumstance/for certain applications, only a subset of the MUST fields is needed and only a subset of the MUST fields is effectively used to distinguish flows. Which combination of properties is evaluated for a particular measurement and how these properties are evaluated depends on the configurati on of the measuring device. The configured choice of evaluated properties strongly depends on the environment and purpose of the measurement and on the information required by the data collector 5.1. Information Model The information model for a flow measurement report is the list of attributes of a flow to be contained in the report (including the semantics of the attributes). This section lists attributes a measuring device MUST or MAY be able to report. This does not imply that a report MUST contain all REQUIRED attributes, but that it MUST be possible to configure the device in a way that all of the REQUIRED attributes are contained in a report for each measured flow. In other words, compliant with IPFIX means that the box in general must be able, via its configuration, to somehow support to report all the MUST fields, even if in certain circumstance/for certain applications, only a subset of the MUST fields is needed and only a subset of the MUST fields is effectively reported. 2. Do we have to specify so many MUST as Information Model fields? I would vote to have only counters and timestamps as MUST and all the rest as MAY. So the MUST are 7,8,14,15: packet counter, observed byte counter, timestamps of the first packet observed, timestamp of the last packet observed. 3. The information model attributes 5 and 6 should specify TCP or UDP, not be confused by the interfaces. And we should add the following attributes: input and output interfaces Regards, Benoit -- 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 Tue Feb 19 08:46:38 2002 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 IAA18134 for ; Tue, 19 Feb 2002 08:46:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dAMX-0000bd-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 07:31:17 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dAMS-0000bS-00 for ipfix-req@net.doit.wisc.edu; Tue, 19 Feb 2002 07:31:12 -0600 Received: from fokus.fhg.de (dhcp206 [195.37.78.206]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1JDV9p26241; Tue, 19 Feb 2002 14:31:09 +0100 (MET) Message-ID: <3C7252F6.1080805@fokus.fhg.de> Date: Tue, 19 Feb 2002 14:28:22 +0100 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <4108689799.1013426004@[192.168.102.164]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.gmd.de id g1JDV9p26241 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA18134 Hi Jürgen, I have a further remark to your proposed changes in ipfix requirements (I forgot to mention it in my last mail). I would not rename the section 4.2 from "Sampling" into "Overload behavior" because I think we should allow sampling in general as an option and not only if the meter is overloaded. I would propose to leave the sampling section as it is and add "Overload behavior" as an additional section. Regards Tanja Juergen Quittek wrote: > Hi all, > > Here is my list of proposed changes to draft-ietf-ipfix-reqs-00.txt. > > I know that Benoit also is going to send some suggestions. > And of course anyone else should feel free to do so. > > Cheers, > > Juergen -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- 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 Tue Feb 19 08:59:34 2002 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 IAA18601 for ; Tue, 19 Feb 2002 08:59:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dAZy-0000wQ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 07:45:10 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dAZw-0000wI-00 for ipfix-req@net.doit.wisc.edu; Tue, 19 Feb 2002 07:45:08 -0600 Received: from fokus.fhg.de (dhcp206 [195.37.78.206]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1JDj4p29494; Tue, 19 Feb 2002 14:45:04 +0100 (MET) Message-ID: <3C725639.9060303@fokus.fhg.de> Date: Tue, 19 Feb 2002 14:42:17 +0100 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Benoit Claise CC: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Some extra changes for the req. document References: <200202191324.g1JDOPn23173@bru-cse-222.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, I agree with must of your changes, except issue 2. (see below) Benoit Claise wrote: >2. >Do we have to specify so many MUST as Information Model fields? >I would vote to have only counters and timestamps as MUST and all the rest as MAY. So the MUST are 7,8,14,15: packet counter, observed byte counter, timestamps of the first packet observed, timestamp of the last packet observed. > All the MUSTs in the information model are derived from applications that need them. If we would like to change anything here, we have to go again through the table with the applications and check wether really all applications can live without the attribute or we need to reduce the scope of the application in order to change the requirements for IPFIX. Regards Tanja -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- -- 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 Tue Feb 19 10:20:50 2002 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 KAA23373 for ; Tue, 19 Feb 2002 10:20:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dBpm-0002hD-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 09:05:34 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dBpk-0002h3-00 for ipfix-req@net.doit.wisc.edu; Tue, 19 Feb 2002 09:05:32 -0600 Received: from fokus.fhg.de (dhcp187 [195.37.78.187]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1JF5Ap22643; Tue, 19 Feb 2002 16:05:10 +0100 (MET) Message-ID: <3C726896.59499BF0@fokus.fhg.de> Date: Tue, 19 Feb 2002 16:00:38 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: Tanja Zseby CC: Benoit Claise , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Some extra changes for the req. document References: <200202191324.g1JDOPn23173@bru-cse-222.cisco.com> <3C725639.9060303@fokus.fhg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Tanja, Benoit, Tanja Zseby schrieb: > > Hi Benoit, > > I agree with must of your changes, except issue 2. (see below) > > Benoit Claise wrote: > > >2. > >Do we have to specify so many MUST as Information Model fields? > >I would vote to have only counters and timestamps as MUST and all the rest as MAY. So the MUST are 7,8,14,15: packet counter, observed byte counter, timestamps of the first packet observed, timestamp of the last packet observed. > > > All the MUSTs in the information model are derived from applications > that need them. If we would like to change anything here, we have to go > again through the table with the applications and check wether really > all applications can live without the attribute or we need to reduce the > scope of the application in order to change the requirements for IPFIX. Having only 7,8,14,15 as a MUST is not sufficient. 18 certainly is a MUST. And you yould need to export at least some ID to where you can map 7,8,14,15 I still think that most of the musts are required, but at least some are questionable e.g. 11,12,16,17,19 More issues in section 5.1: - Rename "transport type" to "transport protocol type" in (4.) (align to section 3.2) - Rename "observed byte counter" to "byte counter" and specify what exactly is counted (8.) - Rename "measuring device" to "exporter" in 19. It's not clear to me whether this is a MUST. If it's not a MUST the underlying assumptions must be added to the draft. -- Sebastian -- 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 Tue Feb 19 10:41:53 2002 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 KAA24366 for ; Tue, 19 Feb 2002 10:41:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dC6i-00033E-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 09:23:04 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dC6f-00032S-00 for ipfix-data@net.doit.wisc.edu; Tue, 19 Feb 2002 09:23:01 -0600 Received: from riverstonenet.com (134.141.180.74 [134.141.180.74]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY6ZN4; Tue, 19 Feb 2002 07:21:44 -0800 Message-ID: <3C726D88.F7B40897@riverstonenet.com> Date: Tue, 19 Feb 2002 10:21:44 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: data Subject: Re: [ipfix-data] IPFIX Data Model Document References: <4F973E944951D311B6660008C7917CF008AE5572@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > Hello Paul, > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Monday, February 18, 2002 7:34 AM > >To: data > >Subject: [ipfix-data] IPFIX Data Model Document > > > > > > > >The last flurry of mail on this has confused me as to > >what we are trying to accomplish in the data model document. > > > >I thought we were trying to lay out the data sent and > >give it precise semantic meaning. Then follow that > >with general text on how that data should be sent not > >detailed wire encoding. > > > >As far as I can see there are still some gray areas > >in the semantics. For example, with destination VLAN ID, > >is it the ultimate destination or is it the VLAN ID > >of the outgoing interface? I'm sure there are others. > > well, this is the same thing as asking if the destination IP address > is the address of the interface or the ultimate destination. Both can > be used. Never thought of that. When would the destination address be that of the interface? In any case, we'll need a tighter definition there too. > I rewrote this VLAN ID stuff to include 802.1p. I'm still due > to send the changes to KC today... If you can send me a copy too that would be good. 802.1p is already in the Class of Service IE but some suggestions were made to maybe separate it separate it out. > > > > >If we don't have good defintions we wont have interoperabilty. > > yep... > > > > > > >Paul > > > >-- > >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/ > > -- 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 Tue Feb 19 10:53:03 2002 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 KAA24876 for ; Tue, 19 Feb 2002 10:53:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dCGe-0003IG-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 09:33:20 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dCGc-0003HY-00 for ipfix-req@net.doit.wisc.edu; Tue, 19 Feb 2002 09:33:18 -0600 Received: from riverstonenet.com (134.141.180.74 [134.141.180.74]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY6ZPZ; Tue, 19 Feb 2002 07:32:03 -0800 Message-ID: <3C726FF3.4F218EB3@riverstonenet.com> Date: Tue, 19 Feb 2002 10:32:03 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christian Gilby CC: Peter Ludemann , ipfix-req@net.doit.wisc.edu Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <7B802811BE77D51189910002A55CFD2C0123BB95@zsc3c032.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Christian Gilby wrote: > > Content Negotiation > I agree that the negotiation of the set of attributes that a > collector is interested in has a lot of value. Depending on the > application, a collector may be interested in a small or large set of > attributes. If the list of requested attributes can be advertised to > the mesuring device (which can indicate which will be sent) then, IF > the device does not ignore the request it can minimize the processing > and export data volume required. I.e. no need to send extraneous > attributes that the collector will ignore. > > In-band Configuration > The ability to perform the configuration in-band (done in a > lightweight manner) will have payoffs in large network deployments > with mixed devices from various vendors. It will be a challenge to > deal with configuration of existing implementations which can be > difficult to add in-band config to (they may need to be configured > manually on the box) but believe it is worthwile to have a framework > for performing this config in-band for devices in a common way since > we are trying to collect a common set of information across the > devices. I don't think anyone indicated that it is not worthwhile. But rather the difficulty might make it better solved in a subsequent version. Paul > > Regards, > Chris > -----Original Message----- > From: Peter Ludemann [mailto:peter.ludemann@xacct.com] > Sent: Saturday, February 16, 2002 10:02 AM > Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes > to > draft-ietf-ipfix-reqs-00.txt > > Juergen: > > Thank-you for pointing out the apparent self-contradiction in my > argument. > I neglected to complete me argument. > > I'm glad that everyone agrees on the need for self-describing data. It > > wasn't clear from all the emails that were flying back and forth. :-) > > I'd like to address the two other issues that are not yet agreed to: > - content negotiation (which extends content advertisement) > - configuration of processing (sampling rates, ports, etc.) > > Some devices are very simple and have no need for any kind of content > negotiation. Others (such as our PacketSight probe, which can have > over 200 > fields) are quite complex and can benefit greatly from content > negotiation. > > The capability to respond to a content request is NOT optional. Every > request MUST be answered; but the answer can be to reject the request, > to > honour it, or to partially honour it. For example: > > exporter advertises fields A,B,C,D > receiver requests only fields A,D > exporter responds with: > fields A,B,C,D -- if it ignores the request > fields A,D -- if it completely honours the request > fields A,C,D -- if it partially honours the request > > One of our concerns with content negotiation was in minimising the > development work for putting the transport protocol onto a network > element > (our target is 2 weeks or less). If the device already has the data > available in a particular form, we want to be able to export it as-is. > For > example, the exporting device determines whether big-endian or > little-endian > numbers are used; the receiver translates as necessary. This has the > advantages: > - simpler implementation on the exporting device > - minimal performance impact on the exporting device > - minimal space requirements on the exporting device > Of course, if the exporting device wants to switch the data from > little-endian to big-endian (network byte order), we aren't going to > prevent > it. But we cater to the exporter's needs, not the receiver's. > > If the exporting device can take advantage of sending fewer fields, it > can; > but if simplicity of implementation or performance concerns would make > it > better to ignore content requests, that's also OK. > > Moving on to the second point: > But as 'in-band configuration' i understand the more > basic configuration of meter and exporter including which ports > to observe, which filtering rules to apply, which flow keys to use, > > which sampling rate to choose, etc. > > I would like this kind of configuration also; but I think it is less > necessary than content negotiation. Content information must be > communicated > amongst all the receivers (in a fail-over configuration), so simply > using > MIBs or a CLI won't work very well. However, the issues of determining > > sampling rate, observed ports, etc. do not need to be distributed in > the > same way (if needed, they can be exported as just another kind of > record > from the network device). > > I think that this kind of configuration will always remain "machine > specific". But it can fit into a very simple structure, something like > a > list of attribute/value pairs being sent from the receiving device and > a > accepted/rejected message being sent back [the configuration must do > multiple items together because there can be interactions amongst > them]. > This is similar to the way configuration is done using a MIB, except > that it > would get around some of the problems with MIB configuration > (interactions > amongst attributes, confirmation of result, multiple tools needed to > do > configuration, etc.). > > To sum up: we need a framework for all the configuration, without > requiring > agreement on the content (which we might never be able to, especially > with > backwards support for existing equipment). This is similar to the > self-describing data delivery ... the requirement is that data be > self-describing and that it contain type information, not that we all > agree > to a specific data model (there eventually will be standard data > models, of > course). Similarly, we should agree to a method of in-band content > negotiation and processing configuration. > > - peter > > ---- > Peter Ludemann peter.ludemann@xacct.com > Chief Architect +1.408.330.5732 > XACCT Technologies, Inc. > 2900 Lakeside Drive Santa Clara, CA 95054 > > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On > Behalf > Of Juergen Quittek > Sent: Saturday, February 16, 2002 7:22 AM > To: Peter Ludemann; Reinaldo Penno; calato@riverstonenet.com; Benoit > Claise > Cc: ram.gopal@nokia.com; zander@fokus.gmd.de; > ipfix-req@net.doit.wisc.edu; Kevin Zhang > Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes > to > draft-ietf-ipfix-reqs-00.txt > > Hi Peter, > > --On 15 February 2002 08:53 -0800 Peter Ludemann > > wrote: > > > Juergen Quittek wrote Thursday, February 14, 2002 2:30 PM: > > > >> So what is your point? Do you want to have in-band configuration > >> for the exported attributes/IEs in the requirements document? > > > > Yes. The CRANE protocol solves real problems that we've encountered; > and > we > > have a number of partners who are using it (sorry, I can't announce > these > > right now). > > > >> What would be the application requiring this? Or from which > >> general requirement would you derive this one? > > > > My answer is a little long. Our requirements go beyond just > delivering the > > kind of data that IPFIX is discussing; but I think that they are > very > > applicable to IPFIX. > > > > If all you care about is delivering one set of values which you'll > never > > change, then there's no need for any in-band configuration. (This > would be > > true only if you think that the data architecture folks will agree > on a > > specification with no SHOULDs in the document ...) > > > > If you anticipate change, then at minimum you need to specify the > version > of > > the data that you're delivering. A more general solution is to use > > self-describing data. XML would be fine but it's much too verbose > for > > delivering thousands of records per second from a small network > device. > > > > So, the minimal requirement is to have some way for the device to > advertise > > what it has. I don't see a need for all of XML's nesting > capabilities; a > > simple 2-level scheme (type of record + fields) should suffice. > > As far, as I followed the ongoing difscussion, (almost) everyone > agrees > to this. > > > The receiver could quietly take this advertisement and process it. > But our > > experience in "IP data mediation" is that people usually only want > specific > > fields; and they typically want to post-process them. Examples of > such > > post-processing: associating values with IP addresses (e.g., > reversing > NAT, > > mapping IP to customer), aggregation, filtering, conditional > splitting, > etc. > > plus a host of database-oriented processing, such as looking for > error > > patterns, for people who hog bandwidth, etc. > > > > If the sending device can be configured by a MIB or CLI, the > receiver can > > adapt to what it advertises. But there are good reasons for such > > configuration to be done by response from the receiver: > > - the needed fields can be derived from the post-processing > configuration, > > so they naturally reside on the receiver, not the sender > > - there can be tens or even thousands of sending devices, so > > centralized configuration is desirable (especially if they can't > all > > have their versions changed simultaneously) > > - there needs to be a way of coordinating amongst multiple > receivers, > > for fail-over deployments > > (these aren't hypothetical requirements: we have customers who are > looking > > at deploying thousands of sending devices; and who require > fail-over) > > > > Once you decide that the sender should advertises its data, it > doesn't > take > > much more work to allow the receiver to respond with a list of > fields that > > it does or doesn't want. The sender can just mark the fields it > won't > send. > > The advantages of this are: > > - bandwidth saving (probably not very important) > > - computation saving on the sender (this can be significant > > in our experience) > > I think we are discussing two different issues. Your suggestion > covers - as far as I have understood so far - the negotiation > between sender an receiver about individual attributes/fields/IEs > to be sent. But as 'in-band configuration' i understand the more > basic configuration of meter and exporter including which ports > to observe, which filtering rules to apply, which flow keys to use, > which sampling rate to choose, etc. > > But coming back to your point: If you say the exporter may ignore it, > why then making it a requirement? Requirements should be essentially > needed and not just nice to have, but opyionally ignored at any time. > > I think your point can be a valuable contribution to the architecture, > > but following your argument it does not belong into the requirement > docvument. > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Adenauerplatz 6, 69115 Heidelberg, Germany http://www.ccrle.nec.de > > > > > Our proposal makes it OPTIONAL for the sender to respond to the > > configuration request. The sender can ignore the configuration > request > and > > still send all the fields -- the receiver will just have to accept > them > (and > > throw away what it doesn't want). But if the sender can take > advantage of > > the configuration request (e.g., turning off expensive > computations), then > > it has a simple mechanism for doing so. > > > > > > ---- > > > > Peter Ludemann > > Chief Architect, XACCT > > +1.408.330.5732 > > -- 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 Tue Feb 19 11:00:24 2002 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 LAA25223 for ; Tue, 19 Feb 2002 11:00:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dCSa-0003Wx-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 09:45:40 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dCSY-0003WJ-00 for ipfix-req@net.doit.wisc.edu; Tue, 19 Feb 2002 09:45:38 -0600 Received: from riverstonenet.com (134.141.180.74 [134.141.180.74]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY6ZS7; Tue, 19 Feb 2002 07:44:24 -0800 Message-ID: <3C7272D8.C47E5674@riverstonenet.com> Date: Tue, 19 Feb 2002 10:44:24 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Tanja Zseby CC: Juergen Quittek , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: <4108689799.1013426004@[192.168.102.164]> <3C7252F6.1080805@fokus.fhg.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Tanja Zseby wrote: > > Hi Jürgen, > > I have a further remark to your proposed changes in ipfix requirements > (I forgot to mention it in my last mail). > I would not rename the section 4.2 from "Sampling" into "Overload > behavior" because I think we should allow sampling in general as an > option and not only if the meter is overloaded. I would propose to > leave the sampling section as it is and add "Overload behavior" as an > additional section. Also, sampling is not the only overload strategy. For example, aggregation might be another one. > > Regards > Tanja > > Juergen Quittek wrote: > > > Hi all, > > > > Here is my list of proposed changes to draft-ietf-ipfix-reqs-00.txt. > > > > I know that Benoit also is going to send some suggestions. > > And of course anyone else should feel free to do so. > > > > Cheers, > > > > Juergen > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > -------------------------------------------------------------------------------------- > "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) > -------------------------------------------------------------------------------------- > > -- > 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/ -- 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 Tue Feb 19 14:29:39 2002 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 OAA02362 for ; Tue, 19 Feb 2002 14:29:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dFet-0000uY-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 13:10:35 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dFer-0000sn-00 for ipfix-arch@net.doit.wisc.edu; Tue, 19 Feb 2002 13:10:33 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1JJ9xO11820 for ; Tue, 19 Feb 2002 13:10:00 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF5C56>; Tue, 19 Feb 2002 11:09:57 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008AE590F@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Clarification on Arch document, section 7.4 Date: Tue, 19 Feb 2002 11:09:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B979.02CF3580" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B979.02CF3580 Content-Type: text/plain; charset="iso-8859-1" a) "3. For long aging flows, the exporter SHOULD export the flow records on regular basis, in order to:" I think it should say "...the exporter SHOULD be able to export the flow..." b) then.. "a. report the flow records periodic accounting information to the collector b. avoid counter wrapping This activity timeout SHOULD be configurable" It should be "a. provide periodic accounting information to the collector b. avoid counter wrapping." This activity SHOULD be configurable. Btw, can someone elaborate on the counter wrapping stuff? c) then.. "4. If the exporter experiences resources constraints, a flow MAY be prematurely expired (example: memory)" Is there any other choice? This seems too implementation specific. regards, Reinaldo ------_=_NextPart_001_01C1B979.02CF3580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Clarification on Arch document, section 7.4

a) "3. For long aging flows, the exporter SHOULD = export the flow records on regular basis, in order to:"

I think it should say "...the exporter SHOULD be = able to export the flow..."

b) then..

   "a.  report the flow records = periodic accounting information to the collector
    b.  avoid counter wrapping = This activity timeout SHOULD be configurable"

It should be

"a. provide periodic accounting information to = the collector
b. avoid counter wrapping."

This activity SHOULD be configurable. Btw, can = someone elaborate on the counter wrapping stuff?

c) then..

"4. If the exporter experiences resources = constraints, a flow MAY be prematurely expired (example: = memory)"

Is there any other choice? This seems too = implementation specific.

regards,

Reinaldo

------_=_NextPart_001_01C1B979.02CF3580-- -- 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 Tue Feb 19 14:30:30 2002 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 OAA02428 for ; Tue, 19 Feb 2002 14:30:30 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dFf1-0000up-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 13:10:43 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dFez-0000tq-00 for ipfix-arch@net.doit.wisc.edu; Tue, 19 Feb 2002 13:10:41 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1JJA8O11864 for ; Tue, 19 Feb 2002 13:10:09 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF5C58>; Tue, 19 Feb 2002 11:10:06 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008AE5910@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Clarification on Arch document, section 7.2 Date: Tue, 19 Feb 2002 11:10:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B979.0808CB60" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B979.0808CB60 Content-Type: text/plain; charset="iso-8859-1" In the arch document it is said: "7.2. Selection Criteria Of Packets The measurement device MAY define rules so that only certain packets within a flow can be chosen for measurement at an observation point. This MAY be done by one of the two types of methods defined below or a combination of them. A combination of each of these ways can be adopted to select the packets .i.e. one can define a set of methods {F1, S1, F2, S2, S3} executed in certain sequence at an observation point to collect flows of a particular type. 7.2.1. Function on properties that determines a flow type (Fi) Packets that satisfy a function on the fields defined by the packet header fields or fields obtained while doing the packet processing or the properties of the packet itself. Example: Mask/Match of the fields that define a filter. The filter may be defined as {Protocol == TCP, Destination Port between 80 and 120}. Multiple such filters could be used in any sequence to select packets. 7.2.2. Sampling packets on a flow type (Si) Packets that satisfy the sampling criteria for this flow type. Example: Sample every 100th packet that was received at an observation point and collect the flow information for a particular flow type. choosing all the packets is a special case where sampling rate is 1:1." Now, 7.2.2 seems to be a valid example, but I'm not sure about 7.2.1. It seems to me that when you apply a function that further reduces the properies that determines a flow you are by definition indirectly (or directly) defining another flow. The flow based on the original definition plus Fi. Then this would be just another flow and not a "selection criteria of packets" within a flow. Maybe I should just rephrase mentioning that in the introduction of this section is is said "to collect flows of a particular type". So, a special type of a flow wouldn't be another flow? Yes, all the packets within a flow can be a subset of another flow, but then, all packets are a subset of the flow "src=any dest=any, proto=any, etc". regards, Reinaldo ------_=_NextPart_001_01C1B979.0808CB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Clarification on Arch document, section 7.2

In the arch document it is said:

"7.2.  Selection Criteria Of Packets

The measurement device MAY define rules so that only = certain packets within a flow can be chosen for measurement at an = observation point. This MAY be done by one of the two types of methods = defined below or a combination of them.  A combination of each of = these ways can be adopted to select the packets .i.e. one can define a = set of methods {F1, S1, F2, S2, S3} executed in certain sequence at an = observation point to collect flows of a particular type.


7.2.1.  Function on properties that determines a = flow type (Fi)

Packets that satisfy a function on the fields defined = by the packet header fields or fields obtained while doing the packet = processing or the properties of the packet itself.

Example:

Mask/Match of the fields that define a filter. The = filter may be defined as {Protocol =3D=3D TCP, Destination Port between = 80 and 120}. Multiple such filters could be used in any sequence to = select packets.

7.2.2.  Sampling packets on a flow type = (Si)

Packets that satisfy the sampling criteria for this = flow type.

Example:

Sample every 100th packet that was received at an = observation point and collect the flow information for a particular = flow type. choosing all the packets is a special case where sampling = rate is 1:1."

Now, 7.2.2 seems to be a valid example, but I'm not = sure about 7.2.1. It seems to me that when you apply a function that = further reduces the properies that determines a flow you are by = definition indirectly (or directly) defining another flow. The flow = based on the original definition plus Fi. Then this would be just = another flow and not a "selection criteria of packets" within = a flow.

Maybe I should just rephrase mentioning that in the = introduction of this section is is said "to collect flows of a = particular type". So, a special type of a flow wouldn't be another = flow? Yes, all the packets within a flow can be a subset of another = flow, but then, all packets are a subset of the flow "src=3Dany = dest=3Dany, proto=3Dany, etc".

regards,

Reinaldo

------_=_NextPart_001_01C1B979.0808CB60-- -- 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 Tue Feb 19 14:54:32 2002 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 OAA03321 for ; Tue, 19 Feb 2002 14:54:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dG5a-0001Rt-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 13:38:10 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dG5Y-0001RH-00 for ipfix-arch@net.doit.wisc.edu; Tue, 19 Feb 2002 13:38:08 -0600 Received: from riverstonenet.com (134.141.180.74 [134.141.180.74]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY68WV; Tue, 19 Feb 2002 11:36:50 -0800 Message-ID: <3C72A953.FD96AF8@riverstonenet.com> Date: Tue, 19 Feb 2002 14:36:51 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] Clarification on Arch document, section 7.2 References: <4F973E944951D311B6660008C7917CF008AE5910@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > In the arch document it is said: > > "7.2. Selection Criteria Of Packets > > The measurement device MAY define rules so that only certain packets > within a flow can be chosen for measurement at an observation point. > This MAY be done by one of the two types of methods defined below or a > combination of them. A combination of each of these ways can be > adopted to select the packets .i.e. one can define a set of methods > {F1, S1, F2, S2, S3} executed in certain sequence at an observation > point to collect flows of a particular type. > > 7.2.1. Function on properties that determines a flow type (Fi) > > Packets that satisfy a function on the fields defined by the packet > header fields or fields obtained while doing the packet processing or > the properties of the packet itself. > > Example: > > Mask/Match of the fields that define a filter. The filter may be > defined as {Protocol == TCP, Destination Port between 80 and 120}. > Multiple such filters could be used in any sequence to select packets. > > 7.2.2. Sampling packets on a flow type (Si) > > Packets that satisfy the sampling criteria for this flow type. > > Example: > > Sample every 100th packet that was received at an observation point > and collect the flow information for a particular flow type. choosing > all the packets is a special case where sampling rate is 1:1." > > Now, 7.2.2 seems to be a valid example, but I'm not sure about 7.2.1. > It seems to me that when you apply a function that further reduces the > properies that determines a flow you are by definition indirectly (or > directly) defining another flow. The flow based on the original > definition plus Fi. Then this would be just another flow and not a > "selection criteria of packets" within a flow. > > Maybe I should just rephrase mentioning that in the introduction of > this section is is said "to collect flows of a particular type". So, a > special type of a flow wouldn't be another flow? Yes, all the packets > within a flow can be a subset of another flow, but then, all packets > are a subset of the flow "src=any dest=any, proto=any, etc". > Here is my take on it... The selection process tells you which packets with be run through the Flow Definition rules to come up with unique flows to export. I think you are correct in saying the the selection criteria is self defines a flow, but it does not define and flow for Export. So out of the more general "Selection Flow Definition" there are sub-flows defined by the "Export Flow Definition". The other thing here that occurred to me is that you may need to know the selection criteria to make sense of the data. If I create a a graph by port number that info will help me understand why I only see ports in that range. My 2 cents. > regards, > > Reinaldo -- 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 Tue Feb 19 15:35:32 2002 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 PAA04623 for ; Tue, 19 Feb 2002 15:35:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dGeo-00029k-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 14:14:34 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dGem-00028t-00 for ipfix@net.doit.wisc.edu; Tue, 19 Feb 2002 14:14:32 -0600 Received: from riverstonenet.com (134.141.180.74 [134.141.180.74]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY69GH; Tue, 19 Feb 2002 12:13:16 -0800 Message-ID: <3C72B1DB.146DD0F7@riverstonenet.com> Date: Tue, 19 Feb 2002 15:13:15 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Peram Marimuthu , "K.C. Norseth" , kevin.zhang@xacct.com, "Norseth, KC" , ipfix@net.doit.wisc.edu Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design draft updates) References: <002e01c1b67a$c146ea00$850f880a@slc252750> <3C6E836B.640BA25B@cisco.com> <001501c1b72a$8af7f560$850f880a@slc252750> <3C6ED48D.DA434090@cisco.com> <3C711C71.FD443FC0@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote: > > Just FYI, I have no intentions on summitting an > LFAP version of IPFIX for consideration. More > on this in the next mail. > > Paul A few people contacted me on this mail so let me clarify. I'm not submitting LFAP at this point because I think it is too early in the process and the selection criteria has not been well defined. Once it is, if I believe LFAP is a good fit (with enhancements of course) I will submit a proposal at that time. Paul -- 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 Tue Feb 19 15:50:35 2002 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 PAA05066 for ; Tue, 19 Feb 2002 15:50:34 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dGwl-0002Tg-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 14:33:07 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dGwj-0002TZ-00 for ipfix@net.doit.wisc.edu; Tue, 19 Feb 2002 14:33:05 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id PAA08412; Tue, 19 Feb 2002 15:42:35 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma008390; Tue, 19 Feb 02 15:41:57 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXR3TQ>; Tue, 19 Feb 2002 15:31:18 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA0703@slc-exc1.ctron.com> From: "Norseth, KC" To: "Calato, Paul" , Peram Marimuthu , "K.C. Norseth" , kevin.zhang@xacct.com, ipfix@net.doit.wisc.edu Subject: RE: 3 definitions (was Re: [ipfix] IPFIX Design draft updates) Date: Tue, 19 Feb 2002 15:31:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B984.6EF3D620" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B984.6EF3D620 Content-Type: text/plain Paul, After our conversation today, I was going to update this in the arch document to reflect this statement. I will also make sure it is noted that any established protocol is still fair game. The more the reason to remove that section discussing the specifics of the protocols until the selection criteria is well defined. K.C. |-----Original Message----- |From: Calato, Paul |Sent: Tuesday, February 19, 2002 1:13 PM |To: Peram Marimuthu; K.C. Norseth; kevin.zhang@xacct.com; |Norseth, KC; ipfix@net.doit.wisc.edu |Subject: Re: 3 definitions (was Re: [ipfix] IPFIX Design draft updates) | | |calato@riverstonenet.com wrote: |> |> Just FYI, I have no intentions on summitting an |> LFAP version of IPFIX for consideration. More |> on this in the next mail. |> |> Paul | | | A few people contacted me on this mail so | let me clarify. I'm not submitting LFAP | at this point because I think it is too | early in the process and the selection | criteria has not been well defined. Once | it is, if I believe LFAP is a good fit | (with enhancements of course) I will | submit a proposal at that time. | | Paul | ------_=_NextPart_001_01C1B984.6EF3D620 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: 3 definitions (was Re: [ipfix] IPFIX Design draft = updates)

Paul,

After our conversation today, I was going to update = this in the arch document to reflect this statement.  I will also = make sure it is noted that any established protocol is still fair game. = The more the reason to remove that section discussing the specifics of = the protocols until the selection criteria is well defined.

K.C.


|-----Original Message-----
|From: Calato, Paul
|Sent: Tuesday, February 19, 2002 1:13 PM
|To: Peram Marimuthu; K.C. Norseth; = kevin.zhang@xacct.com;
|Norseth, KC; ipfix@net.doit.wisc.edu
|Subject: Re: 3 definitions (was Re: [ipfix] IPFIX = Design draft updates)
|
|
|calato@riverstonenet.com wrote:
|>
|> Just FYI, I have no intentions on summitting = an
|> LFAP version of IPFIX for consideration. = More
|> on this in the next mail.
|>
|> Paul
|
|
|       A few people = contacted me on this mail so
|       let me = clarify. I'm not submitting LFAP
|       at this point = because I think it is too
|       early in the = process and the selection
|       criteria has = not been well defined. Once
|       it is, if I = believe LFAP is a good fit
|       (with = enhancements of course) I will
|       submit a = proposal at that time.
|
|       Paul
|

------_=_NextPart_001_01C1B984.6EF3D620-- -- 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 Tue Feb 19 15:56:04 2002 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 PAA05252 for ; Tue, 19 Feb 2002 15:56:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dH1M-0002Z5-00 for ipfix-list@mil.doit.wisc.edu; Tue, 19 Feb 2002 14:37:52 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dH1L-0002Yr-00 for ipfix-data@net.doit.wisc.edu; Tue, 19 Feb 2002 14:37:51 -0600 Received: from riverstonenet.com (134.141.180.74 [134.141.180.74]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY693L; Tue, 19 Feb 2002 12:36:35 -0800 Message-ID: <3C72B754.D5D2AB1D@riverstonenet.com> Date: Tue, 19 Feb 2002 15:36:36 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ganesh Sadasivan CC: ipfix-data@net.doit.wisc.edu Subject: Re: [ipfix-data] draft-ietf-ipfix-data-00.txt - comments References: <3C6C805C.5600E9F5@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh Sadasivan wrote: > > Hi, > Here are my first pass comments, questions and > suggestions on draft-ietf-ipfix-data-00.txt. > Thanks > Ganesh > > What is the idea behind putting Section 4.1-4.4? Is this a > rough list or a complete list? Is this section supposed to > cover all the fields in section 5? > > 5.1.1. Version Number > Which version # is this refering to - IPV4/V6? > > 5.1.2. FLOWS > This is # of flows which got aggergated at a second > level meter. > > 5.2.1. Source Address IE > 5.2.2. Destination Address IE > 5.2.3. NEXT_HOP_IP IE > Are we not distinguishing between V4 and V6 addresses by different IEs? > To me separate IE is better than infering through version# . It is just an encoding thing. Either there is a field that is part of the address encoding that gives address family (ala RFC 1700 - which is now obsolete) or you have a separate IE for each. We can get to those details later. > > 5.3.3. Delta Time IE > Just curious. How does this field get used? ***IF*** there is any kind of Flow update then this field tells you how much time is covered by the update. Don't know if we are doing flow update messages yet, so it is here as a placeholder for now. > > 5.3.4. LAST_SWITCHED > SysUptime at which the last packet of this flow was processed > by the meter before the flow record was exported or the > flow ended. Do you actually know the time of the last switched packet?? > > 5.3.5. FIRST_SWITCHED > SysUptime at which the first packet of this flow was processed > by the meter. > > 5.4.1. Class of Service IE > There should be separate IEs to distinguish between > Cos for V4, V6, MPLS & VLAN. A packet can have more > than one Cos fields, each associated with > { & & } Why can't we just use the same element more than once? I'm just concerned about having hundreds of IE's to document and implement because of slight variations. > > 5.4.4 > "This information is used by applications to later correlate the > ingress/egress port with a specific Exporter. " > > What does this mean? > This looks to me as a part of the flow header extension which > is optional. I agree, we should move it out. > > 5.5. Flow State IE > A better way to put this would be "export reason" which could > be: > 1. Inactive > 2. End of flow detected > 3. Forced export > 4. Cache full > I like that. > 5.6. Statistical Elements > Some of the IEs that I can think of: > > From the observation domain > * Flows collected > * Flows dropped > > From exporter > * Export data packets sent > * Export control packets sent > * Export data packets dropped Are these stats that might be better available through a MIB? > > 5.6.1. Byte Count IE > 5.6.2. Packet Count IE > How does one distinguish between delta counter and running > counter at the collector? Just an encoding thing again, could be a bit or could be a separate IE. > > 5.6.3. Dropped Byte Count IE > I'm not sure how accurate one can get here. The packets may be dropped > before the actual metering itself happened or well after the metering > has > happened (like another LC in a distributed system). But yes, > in some cases this would work fine. Agreed. Same is true for sent count. Might get dropped later. > > 5.6.5. IPM_DPKTS > Total number of packets after replication for this multicast flow. > > 5.6.6. IPM_DOCTETS > Total number of octets after replication for this multicast flow. Let me see if I understand. If we are reporting a Multi-cast flow (e.g. A to B,C and D) then there might be 2 counts in the flow 1) the original byte count and 2) the replication byte count. > > 5.8.3. Next Hop AS IE > Don't we need a "Previous Hop AS IE"? Never thought of that. Why not. > > 5.11. BGP & Vlan IE's > May be better to split these 2 into 2 different sections (BGP related > and VLAN related). > > 5.11.4. Source VLAN ID IE > 5.11.5. Destination VLAN ID IE > Is there not a one-to-one correspondence between VLAN-ID and > interface Index? I am wondering where this would useful. There can be complicated rules for determining the VLAN (e.g. in on this port with this IP is VLAN 5 and the default is 10. This is the end result. > Is there a plan to distinguish between .1p and .1q? > Not sure what you mean. .1p is the priority info and .1q is the VLAN ID. Each can get reported. > 5.13.7. IGMP_TYPE > Types of IGMP messages of concern to the host-router > interaction. > > -- > 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/ -- 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 Feb 20 03:39:33 2002 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 DAA25019 for ; Wed, 20 Feb 2002 03:39:33 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dRu6-0000zb-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 02:15:06 -0600 Received: from mail-green.research.att.com ([135.207.30.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dRu3-0000zV-00 for ipfix@net.doit.wisc.edu; Wed, 20 Feb 2002 02:15:03 -0600 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 632EA1E02B for ; Wed, 20 Feb 2002 03:15:03 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id DAA16071 for ; Wed, 20 Feb 2002 03:15:02 -0500 (EST) Date: Wed, 20 Feb 2002 03:15:01 -0500 (EST) From: Fred True To: ipfix Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) In-Reply-To: <3C6AADFF.55C40F9B@research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: majordomo listserver Folks, A colleague of mine pointed me to the current discussion on expanding the Cisco netflow protocol to allow better management of export configuration, and I thought I'd add my $0.02. I've read over most of the threads I could find, but please let me know if I'm missing the gist of what has been proposed, or forgive me if I'm not aware of the full context of the discussion. First, on a related note, I presume people are aware of the forthcoming v9 netflow export format. This is the format they should have started with (as opposed to v1, v5, v7 etc.), as it is self-describing (e.g. it contains in-stream metadata telling client applications how to decode it) and can handle arbitrary export fields. They plan to use this for future versions of netflow, packet header sampling, etc. On the point of managing netflow data collection, I gather that the proposal is to modify the netflow export protocol to be bi-directional, so that a collector can send configuration messages to the routers rather than relying on the current CLI commands. I don't understand the point of this. Aside from requiring a whole lot of new development on the IOS side, I don't think any of us who manage routers really want a new paradigm for speaking to them, complete with requirements for reliability, low overhead, security, etc. What we've asked for in the past (and have not yet convinced them to implement) is to have a netflow configuration MIB. Everyone can deal with SNMP, it's reliable and allows authentication, it allows you to read or write configuration info, and it's easy to create lightweight SNMP clients on the collector (or management workstation) side to control the configuration, even in near-real-time (so, for example, you could tune your sampling rate based on observed data). It seems to me that leaving the plans for v9 netflow export alone and using SNMP for dynamic netflow configuration would be the most expedient and architecturally sound solution. -fred -- Fred True "My name is Ozymandias, King of Kings: Internet and Network Systems Research Look on my works, ye Mighty, AT&T Labs-Research, Florham Park, NJ and despair!" ft@research.att.com -P. B. Shelley -- 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 Feb 20 05:41:36 2002 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 FAA26526 for ; Wed, 20 Feb 2002 05:41:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dTuG-00047R-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 04:23:24 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dTuF-00046C-00 for ipfix@net.doit.wisc.edu; Wed, 20 Feb 2002 04:23:23 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1KAMiD11525; Wed, 20 Feb 2002 04:22:45 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF5M5A>; Wed, 20 Feb 2002 02:22:41 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008B6E327@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Fred True , ipfix Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Wed, 20 Feb 2002 02:22:42 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B9F8.87B971F0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B9F8.87B971F0 Content-Type: text/plain; charset="iso-8859-1" Hello Fred, comments inline.. >-----Original Message----- >From: Fred True [mailto:ft@research.att.com] >Sent: Wednesday, February 20, 2002 12:15 AM >To: ipfix >Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments >on the Architecture Draft) > > >Folks, > >A colleague of mine pointed me to the current discussion on >expanding the >Cisco netflow protocol to allow better management of export >configuration, >and I thought I'd add my $0.02. The discussion wasn't related to Netflow. It was related to IPfix. I've read over most of the threads I >could find, but please let me know if I'm missing the gist of what has >been proposed, or forgive me if I'm not aware of the full >context of the >discussion. > ... > >On the point of managing netflow data collection, I gather that the >proposal is to modify the netflow export protocol to be >bi-directional, so >that a collector can send configuration messages to the routers rather >than relying on the current CLI commands. Again, we were not talking about Netflow per se. I don't understand >the point of >this. Aside from requiring a whole lot of new development on the IOS >side, right, right, I imagine this is what it boils down to... I don't think any of us who manage routers really want a new >paradigm for speaking to them, complete with requirements for >reliability, >low overhead, security, etc. hum...I think I disagree. I know other people that work in big SPs that would disagree also. If CLI was so "easy" in a complex network such products weren't being made. http://www.cisco.com/warp/public/779/servpro/operate/csm/nemnsw/vpn/prodlit/ "Q. What are the key benefits of the Cisco VPN Solution Center for service providers? A. The Cisco VPN Solution Center can help service providers to improve time to market for new value-added VPN services, improve the quality of their networks, reduce operational costs, reduce total cost of ownership, and focus on business management and higher-level service-management activities." Of course if you are not interest in cost and/or spend your days in some lab I imagine that this is not a compelling reason. > >What we've asked for in the past (and have not yet convinced them to >implement) is to have a netflow configuration MIB. Everyone >can deal with >SNMP, it's reliable and allows authentication, it allows you to read or >write configuration info, and it's easy to create lightweight >SNMP clients >on the collector (or management workstation) side to control the >configuration, even in near-real-time (so, for example, you could tune >your sampling rate based on observed data). It seems to me >that leaving >the plans for v9 netflow export alone and using SNMP for >dynamic netflow >configuration would be the most expedient and architecturally sound >solution. We are talking about dozens of exporters possible talking to dozens of collectors with different levels of compliance. How do you intend to do that with SNMP? Having said that, I think a IPfix MIB is not a bad idea. regards, Reinaldo ------_=_NextPart_001_01C1B9F8.87B971F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the Architecture Draft)

Hello Fred,

comments inline..

>-----Original Message-----
>From: Fred True [mailto:ft@research.att.com]
>Sent: Wednesday, February 20, 2002 12:15 = AM
>To: ipfix
>Subject: [ipfix] Re: Scope of IPFIX (was Answer = to the recent comments
>on the Architecture Draft)
>
>
>Folks,
>
>A colleague of mine pointed me to the current = discussion on
>expanding the
>Cisco netflow protocol to allow better = management of export
>configuration,
>and I thought I'd add my $0.02. 

The discussion wasn't related to Netflow. It was = related to IPfix.

I've read over most of the threads I
>could find, but please let me know if I'm = missing the gist of what has
>been proposed, or forgive me if I'm not aware of = the full
>context of the
>discussion.
>
<snip>...<snip>

>
>On the point of managing netflow data = collection, I gather that the
>proposal is to modify the netflow export = protocol to be
>bi-directional, so
>that a collector can send configuration messages = to the routers rather
>than relying on the current CLI commands.  =

Again, we were not talking about Netflow per se. =

I don't understand
>the point of
>this.  Aside from requiring a whole lot of = new development on the IOS
>side,

right, right, I imagine this is what it boils down = to...

I don't think any of us who manage routers really = want a new
>paradigm for speaking to them, complete with = requirements for
>reliability,
>low overhead, security, etc.

hum...I think I disagree. I know other people that = work in big SPs that would disagree also. If CLI was so = "easy" in a complex network such products weren't being made. = http://www.cisco.com/warp/public/779/servpro/operate/c= sm/nemnsw/vpn/prodlit/

"Q. What are the key benefits of the Cisco VPN = Solution Center for service providers?

A. The Cisco VPN Solution Center can help service = providers to improve time to market for new value-added VPN services, = improve the quality of their networks, reduce operational costs, reduce = total cost of ownership, and focus on business management and = higher-level service-management activities."

Of course if you are not interest in cost and/or = spend your days in some lab I imagine that this is not a compelling = reason.

>
>What we've asked for in the past (and have not = yet convinced them to
>implement) is to have a netflow configuration = MIB.  Everyone
>can deal with
>SNMP, it's reliable and allows authentication, = it allows you to read or
>write configuration info, and it's easy to = create lightweight
>SNMP clients
>on the collector (or management workstation) = side to control the
>configuration, even in near-real-time (so, for = example, you could tune
>your sampling rate based on observed = data).  It seems to me
>that leaving
>the plans for v9 netflow export alone and using = SNMP for
>dynamic netflow
>configuration would be the most expedient and = architecturally sound
>solution.

We are talking about dozens of exporters possible = talking to dozens of collectors with different levels of compliance. = How do you intend to do that with SNMP?

Having said that, I think a IPfix MIB is not a bad = idea.

regards,

Reinaldo



------_=_NextPart_001_01C1B9F8.87B971F0-- -- 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 Feb 20 07:05:47 2002 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 HAA27468 for ; Wed, 20 Feb 2002 07:05:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dVED-0007P3-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 05:48:05 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dVEC-0007ON-00 for ipfix-arch@net.doit.wisc.edu; Wed, 20 Feb 2002 05:48:04 -0600 Received: from cisco.com (bclaise-isdn-home3.cisco.com [10.49.4.220]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA15231; Wed, 20 Feb 2002 12:47:26 +0100 (MET) Message-ID: <3C738CDB.510D2497@cisco.com> Date: Wed, 20 Feb 2002 12:47:40 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tanja Zseby CC: ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] applicability document? References: <3C715141.3C4FE215@cisco.com> <3C723B66.1060608@fokus.fhg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Tanja, Perfect. Regards, Benoit > Hi Benoit, > > I agree that it is a good idea to create an applicability document. I > would propose to have one section for each of the applications in the > requirements documents. Maybe there are also further applications that > can use IPFIX ? Also the relations of IPFIX to other > frameworks/protocols could be put into this document (or a separate one > ?) I propose to have the following parts in the document: > > 1. Applications of IPFIX > 1.1 Accounting with IPFIX > 1.2 Traffic Profiling with IPFIX > 1.3 Traffic Engineering with IPFIX > 1.4 Intrusion detection with IPFIX > 1.5 QoS Monitoring with IPFIX > - other applications ? > > 2. Relation of IPFIX to other frameworks and protocols > 2.1 IPFIX and AAA > 2.2 IPFIX and RTFM > 2.3 IPFIX considerations for middleboxes > 2.4 IPFIX and RMON > 2.5 IPFIX and IPPM (e.g. IPPM MIB) > 2.6 IPFIX and PSAMP > - further relations > > I could contribute some text at least to 1.1, 1.5 ,2.1, 2.2 and 2.5. > If others agree, that we should work on this document, maybe Dave can > open an additional "pseudo"- mailling-list [ipfix-appl] ? > > Regards > Tanja > > Benoit Claise wrote: > > >All, > > > >As already proposed by Nevil, I think this is a good idea to have an > >applicability document. > >What I would see in there is: > >- section 8.4 on "ipfix considerations for middleboxes" > >- section 8.5 on "QOS Monitoring with IPFIX" > >- section 11.1 on "Some applications of IPFIX" > > > >What do you think? > > > >Regards, Benoit > > > > > >-- > >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/ > > > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > -------------------------------------------------------------------------------------- > "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) > -------------------------------------------------------------------------------------- -- 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 Feb 20 09:04:31 2002 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 JAA00822 for ; Wed, 20 Feb 2002 09:04:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dX24-000276-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 07:43:40 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dX21-000270-00 for ipfix@net.doit.wisc.edu; Wed, 20 Feb 2002 07:43:37 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id IAA15620; Wed, 20 Feb 2002 08:53:06 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma015556; Wed, 20 Feb 02 08:52:36 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXR7Z3>; Wed, 20 Feb 2002 08:41:55 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA0706@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Fred True'" , ipfix Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Wed, 20 Feb 2002 08:42:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA14.6BEB0080" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA14.6BEB0080 Content-Type: text/plain |-----Original Message----- |From: Fred True [mailto:ft@research.att.com] |Sent: Wednesday, February 20, 2002 1:15 AM |To: ipfix |Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent |comments on the Architecture Draft) | | |Folks, | |A colleague of mine pointed me to the current discussion on |expanding the Cisco netflow protocol to allow better |management of export configuration, and I thought I'd add my |$0.02. I've read over most of the threads I could find, but |please let me know if I'm missing the gist of what has been |proposed, or forgive me if I'm not aware of the full context |of the discussion. | |First, on a related note, I presume people are aware of the |forthcoming v9 netflow export format. This is the format they |should have started with (as opposed to v1, v5, v7 etc.), as |it is self-describing (e.g. it contains in-stream metadata |telling client applications how to decode it) and can handle |arbitrary export fields. They plan to use this for future |versions of netflow, packet header sampling, etc. NetFlow v9 is only a possibilitry for IPFIX. It is far from being decided. |On the point of managing netflow data collection, I gather |that the proposal is to modify the netflow export protocol to |be bi-directional, so that a collector can send configuration |messages to the routers rather than relying on the current CLI |commands. I don't understand the point of this. Aside from |requiring a whole lot of new development on the IOS side, I |don't think any of us who manage routers really want a new |paradigm for speaking to them, complete with requirements for |reliability, low overhead, security, etc. Bi-directional is only a MAY. IPFIX is a lot more than that. IPFIX will hopefully contain the fixes to the procedure that NetFlow v5-v8 lack. |What we've asked for in the past (and have not yet convinced them to |implement) is to have a netflow configuration MIB. Everyone |can deal with SNMP, it's reliable and allows authentication, |it allows you to read or write configuration info, and it's |easy to create lightweight SNMP clients on the collector (or |management workstation) side to control the configuration, |even in near-real-time (so, for example, you could tune your |sampling rate based on observed data). It seems to me that |leaving the plans for v9 netflow export alone and using SNMP |for dynamic netflow configuration would be the most expedient |and architecturally sound solution. A MIB would be wonderful. Currently it is not in the scope of the charter, but it is not left out yet. Whether IPFIX adopts NetFlow, LFAP,DIAMETER, CRANE or whatever, I want it to be a more complete,robust solution than what is currently in use. PS. New documents coming out shortly. K.C. |-fred | |-- |Fred True "My name is Ozymandias, |King of Kings: |Internet and Network Systems Research Look on my works, ye Mighty, |AT&T Labs-Research, Florham Park, NJ and despair!" |ft@research.att.com -P. B. Shelley | | |-- |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/ | ------_=_NextPart_001_01C1BA14.6BEB0080 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the Architecture Draft)

|-----Original Message-----
|From: Fred True [mailto:ft@research.att.com] =
|Sent: Wednesday, February 20, 2002 1:15 AM
|To: ipfix
|Subject: [ipfix] Re: Scope of IPFIX (was Answer to = the recent
|comments on the Architecture Draft)
|
|
|Folks,
|
|A colleague of mine pointed me to the current = discussion on
|expanding the Cisco netflow protocol to allow = better
|management of export configuration, and I thought = I'd add my
|$0.02.  I've read over most of the threads I = could find, but
|please let me know if I'm missing the gist of what = has been
|proposed, or forgive me if I'm not aware of the = full context
|of the discussion.
|
|First, on a related note, I presume people are = aware of the
|forthcoming v9 netflow export format.  This is = the format they
|should have started with (as opposed to v1, v5, v7 = etc.), as
|it is self-describing (e.g. it contains in-stream = metadata
|telling client applications how to decode it) and = can handle
|arbitrary export fields.  They plan to use = this for future
|versions of netflow, packet header sampling, = etc.

NetFlow v9 is only a possibilitry for IPFIX.  It = is far from being decided.

|On the point of managing netflow data collection, I = gather
|that the proposal is to modify the netflow export = protocol to
|be bi-directional, so that a collector can send = configuration
|messages to the routers rather than relying on the = current CLI
|commands.  I don't understand the point of = this.  Aside from
|requiring a whole lot of new development on the IOS = side, I
|don't think any of us who manage routers really = want a new
|paradigm for speaking to them, complete with = requirements for
|reliability, low overhead, security, etc.

Bi-directional is only a MAY.  IPFIX is a lot = more than that.  IPFIX will hopefully contain the fixes to the = procedure that NetFlow v5-v8 lack.


|What we've asked for in the past (and have not yet = convinced them to
|implement) is to have a netflow configuration = MIB.  Everyone
|can deal with SNMP, it's reliable and allows = authentication,
|it allows you to read or write configuration info, = and it's
|easy to create lightweight SNMP clients on the = collector (or
|management workstation) side to control the = configuration,
|even in near-real-time (so, for example, you could = tune your
|sampling rate based on observed data).  It = seems to me that
|leaving the plans for v9 netflow export alone and = using SNMP
|for dynamic netflow configuration would be the most = expedient
|and architecturally sound solution.

A MIB would be wonderful.  Currently it is not = in the scope of the charter, but it is not left out yet.

Whether IPFIX adopts NetFlow, LFAP,DIAMETER, CRANE or = whatever, I want it to be a more complete,robust solution than what is = currently in use.


PS. New documents coming out shortly.

K.C.

|-fred
|
|--
|Fred True      =         =         =         "My name is Ozymandias, =
|King of Kings:
|Internet and Network Systems Research   = Look on my works, ye Mighty,
|AT&T Labs-Research, Florham Park, = NJ    and despair!"
|ft@research.att.com    =         =         =         =         -P. B. Shelley
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1BA14.6BEB0080-- -- 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 Feb 20 09:58:32 2002 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 JAA02550 for ; Wed, 20 Feb 2002 09:58:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dXwp-0003XL-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 08:42:19 -0600 Received: from pool-162-83-253-16.ny5030.east.verizon.net ([162.83.253.16] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dXwm-0003X2-00 for ipfix-arch@net.doit.wisc.edu; Wed, 20 Feb 2002 08:42:17 -0600 Received: from sphynx (sphynx.newyork.qosient.com [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g1KEg0i23209; Wed, 20 Feb 2002 09:42:00 -0500 Reply-To: From: "Carter Bullard" To: "'Benoit Claise'" , "'Tanja Zseby'" Cc: Subject: RE: [ipfix-arch] applicability document? Date: Wed, 20 Feb 2002 09:41:51 -0500 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED6601901E@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED660513CF@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Gentle people, I hate to make a negative point, because so much good stuff has been going on, but the applications that are listed below relate to the analysis flow data, not IPFIX. I can see applications like syslog event transport, packet capture transport, SNMP event transport, routing information export as extended applications of IPFIX, as these are transport applications. This is not to say that these things aren't important, but we shouldn't let IPFIX get toooo far off of the point. Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit Claise > Sent: Wednesday, February 20, 2002 6:48 AM > To: Tanja Zseby > Cc: ipfix-arch@net.doit.wisc.edu > Subject: Re: [ipfix-arch] applicability document? > > > Tanja, > > Perfect. > > Regards, Benoit > > > Hi Benoit, > > > > I agree that it is a good idea to create an applicability > document. I > > would propose to have one section for each of the > applications in the > > requirements documents. Maybe there are also further > applications that > > can use IPFIX ? Also the relations of IPFIX to other > > frameworks/protocols could be put into this document (or a separate > > one > > ?) I propose to have the following parts in the document: > > > > 1. Applications of IPFIX > > 1.1 Accounting with IPFIX > > 1.2 Traffic Profiling with IPFIX > > 1.3 Traffic Engineering with IPFIX > > 1.4 Intrusion detection with IPFIX > > 1.5 QoS Monitoring with IPFIX > > - other applications ? > > > > 2. Relation of IPFIX to other frameworks and protocols > > 2.1 IPFIX and AAA > > 2.2 IPFIX and RTFM > > 2.3 IPFIX considerations for middleboxes > > 2.4 IPFIX and RMON > > 2.5 IPFIX and IPPM (e.g. IPPM MIB) > > 2.6 IPFIX and PSAMP > > - further relations > > > > I could contribute some text at least to 1.1, 1.5 ,2.1, 2.2 > and 2.5. > > If others agree, that we should work on this document, > maybe Dave can > > open an additional "pseudo"- mailling-list [ipfix-appl] ? > > > > Regards > > Tanja > > > > Benoit Claise wrote: > > > > >All, > > > > > >As already proposed by Nevil, I think this is a good idea > to have an > > >applicability document. What I would see in there is: > > >- section 8.4 on "ipfix considerations for middleboxes" > > >- section 8.5 on "QOS Monitoring with IPFIX" > > >- section 11.1 on "Some applications of IPFIX" > > > > > >What do you think? > > > > > >Regards, Benoit > > > > > > > > >-- > > >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/ > > > > > > > -- > > Dipl.-Ing. Tanja Zseby > > FhI FOKUS/Global Networking Email: > zseby@fokus.fhg.de > > Kaiserin-Augusta-Allee 31 > Phone: +49-30-3463-7153 > > D-10589 Berlin, Germany Fax: > +49-30-3463-8153 > > > ---------------------------------------------------------------------- > > ---------------- > > "Living on earth is expensive but it includes a free trip > around the sun." (Anonymous) > > > -------------------------------------------------------------- > ------------------------ > > > -- > 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/ > > -- 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 Feb 20 10:07:40 2002 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 KAA02886 for ; Wed, 20 Feb 2002 10:07:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dY4g-0003i0-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 08:50:26 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dY4e-0003hu-00 for ipfix-arch@net.doit.wisc.edu; Wed, 20 Feb 2002 08:50:24 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id JAA23212; Wed, 20 Feb 2002 09:59:55 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma023160; Wed, 20 Feb 02 09:59:38 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXR9WJ>; Wed, 20 Feb 2002 09:48:58 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA0709@slc-exc1.ctron.com> From: "Norseth, KC" To: "'carter@qosient.com'" , "'Benoit Claise'" , "'Tanja Zseby'" Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] applicability document? Date: Wed, 20 Feb 2002 09:49:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA1D.C5DD30F0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA1D.C5DD30F0 Content-Type: text/plain That is one reason for a separate document. Currently, until decided, hopefully today, it remains in the arch document. K.C. |-----Original Message----- |From: Carter Bullard [mailto:carter@qosient.com] |Sent: Wednesday, February 20, 2002 7:42 AM |To: 'Benoit Claise'; 'Tanja Zseby' |Cc: ipfix-arch@net.doit.wisc.edu |Subject: RE: [ipfix-arch] applicability document? | | | |Gentle people, |I hate to make a negative point, because so much good |stuff has been going on, but the applications that are |listed below relate to the analysis flow data, not IPFIX. | |I can see applications like syslog event transport, |packet capture transport, SNMP event transport, routing |information export as extended applications of IPFIX, as these |are transport applications. | |This is not to say that these things aren't important, |but we shouldn't let IPFIX get toooo far off of the |point. | |Carter | |Carter Bullard |QoSient, LLC |300 E. 56th Street, Suite 18K |New York, New York 10022 | |carter@qosient.com |Phone +1 212 588-9133 |Fax +1 212 588-9134 |http://qosient.com | | | |> -----Original Message----- |> From: majordomo listserver |> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Benoit Claise |> Sent: Wednesday, February 20, 2002 6:48 AM |> To: Tanja Zseby |> Cc: ipfix-arch@net.doit.wisc.edu |> Subject: Re: [ipfix-arch] applicability document? |> |> |> Tanja, |> |> Perfect. |> |> Regards, Benoit |> |> > Hi Benoit, |> > |> > I agree that it is a good idea to create an applicability |> document. I |> > would propose to have one section for each of the |> applications in the |> > requirements documents. Maybe there are also further |> applications that |> > can use IPFIX ? Also the relations of IPFIX to other |> > frameworks/protocols could be put into this document (or a |separate |> > one |> > ?) I propose to have the following parts in the document: |> > |> > 1. Applications of IPFIX |> > 1.1 Accounting with IPFIX |> > 1.2 Traffic Profiling with IPFIX |> > 1.3 Traffic Engineering with IPFIX |> > 1.4 Intrusion detection with IPFIX |> > 1.5 QoS Monitoring with IPFIX |> > - other applications ? |> > |> > 2. Relation of IPFIX to other frameworks and protocols |> > 2.1 IPFIX and AAA |> > 2.2 IPFIX and RTFM |> > 2.3 IPFIX considerations for middleboxes |> > 2.4 IPFIX and RMON |> > 2.5 IPFIX and IPPM (e.g. IPPM MIB) |> > 2.6 IPFIX and PSAMP |> > - further relations |> > |> > I could contribute some text at least to 1.1, 1.5 ,2.1, 2.2 |> and 2.5. |> > If others agree, that we should work on this document, |> maybe Dave can |> > open an additional "pseudo"- mailling-list [ipfix-appl] ? |> > |> > Regards |> > Tanja |> > |> > Benoit Claise wrote: |> > |> > >All, |> > > |> > >As already proposed by Nevil, I think this is a good idea |> to have an |> > >applicability document. What I would see in there is: |> > >- section 8.4 on "ipfix considerations for middleboxes" |> > >- section 8.5 on "QOS Monitoring with IPFIX" |> > >- section 11.1 on "Some applications of IPFIX" |> > > |> > >What do you think? |> > > |> > >Regards, Benoit |> > > |> > > |> > >-- |> > >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/ |> > > |> > |> > -- |> > Dipl.-Ing. Tanja Zseby |> > FhI FOKUS/Global Networking Email: |> zseby@fokus.fhg.de |> > Kaiserin-Augusta-Allee 31 |> Phone: +49-30-3463-7153 |> > D-10589 Berlin, Germany Fax: |> +49-30-3463-8153 |> > |> |---------------------------------------------------------------------- |> > ---------------- |> > "Living on earth is expensive but it includes a free trip |> around the sun." (Anonymous) |> > |> -------------------------------------------------------------- |> ------------------------ |> |> |> -- |> 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/ |> |> | | | |-- |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/ | ------_=_NextPart_001_01C1BA1D.C5DD30F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] applicability document?

That is one reason for a separate document.  = Currently, until decided, hopefully today, it remains in the arch = document.

K.C.


|-----Original Message-----
|From: Carter Bullard [mailto:carter@qosient.com] =
|Sent: Wednesday, February 20, 2002 7:42 AM
|To: 'Benoit Claise'; 'Tanja Zseby'
|Cc: ipfix-arch@net.doit.wisc.edu
|Subject: RE: [ipfix-arch] applicability = document?
|
|
|
|Gentle people,
|I hate to make a negative point, because so much = good
|stuff has been going on, but the applications that = are
|listed below relate to the analysis flow data, not = IPFIX. 
|
|I can see applications like syslog event = transport,
|packet capture transport, SNMP event transport, = routing
|information export as extended applications of = IPFIX, as these
|are transport applications.
|
|This is not to say that these things aren't = important,
|but we shouldn't let IPFIX get toooo far off of = the
|point.
|
|Carter
|
|Carter Bullard
|QoSient, LLC
|300 E. 56th Street, Suite 18K
|New York, New York  10022
|
|carter@qosient.com
|Phone +1 212 588-9133
|Fax   +1 212 588-9134
|http://qosient.com
|
|
|
|> -----Original Message-----
|> From: majordomo listserver
|> [mailto:majordomo@mil.doit.wi= sc.edu] On Behalf Of Benoit Claise
|> Sent: Wednesday, February 20, 2002 6:48 = AM
|> To: Tanja Zseby
|> Cc: ipfix-arch@net.doit.wisc.edu
|> Subject: Re: [ipfix-arch] applicability = document?
|>
|>
|> Tanja,
|>
|> Perfect.
|>
|> Regards, Benoit
|>
|> > Hi Benoit,
|> >
|> > I  agree that it is a good idea to = create an applicability
|> document. I
|> > would propose to have one section for = each of the
|> applications in the
|> > requirements documents. Maybe there are = also further
|> applications that
|> > can use IPFIX ? Also the relations of = IPFIX to other
|> > frameworks/protocols could be put into = this document (or a
|separate
|> > one
|> > ?)  I propose to have the following = parts in the document:
|> >
|> > 1. Applications of IPFIX
|> >     1.1 Accounting = with IPFIX
|> >     1.2 Traffic = Profiling with IPFIX
|> >     1.3 Traffic = Engineering with IPFIX
|> >     1.4 Intrusion = detection with IPFIX
|> >     1.5 QoS = Monitoring with IPFIX
|> >     - other = applications ?
|> >
|> > 2. Relation of IPFIX to other frameworks = and protocols
|> >     2.1 IPFIX and = AAA
|> >     2.2 IPFIX and = RTFM
|> >     2.3 IPFIX = considerations for middleboxes
|> >     2.4 IPFIX and = RMON
|> >     2.5  IPFIX = and IPPM (e.g. IPPM MIB)
|> >     2.6 IPFIX and = PSAMP
|> >     -  further = relations
|> >
|> > I could contribute some text at least to = 1.1, 1.5 ,2.1, 2.2
|> and 2.5.
|> > If others agree, that we should work on = this document,
|> maybe Dave can
|> > open an additional "pseudo"- = mailling-list [ipfix-appl] ?
|> >
|> > Regards
|> > Tanja
|> >
|> > Benoit Claise wrote:
|> >
|> > >All,
|> > >
|> > >As already proposed by Nevil, I think = this is a good idea
|> to have an
|> > >applicability document. What I would = see in there is:
|> > >- section 8.4 on "ipfix = considerations for middleboxes"
|> > >- section 8.5 on "QOS Monitoring = with IPFIX"
|> > >- section 11.1 on "Some = applications of IPFIX"
|> > >
|> > >What do you think?
|> > >
|> > >Regards, Benoit
|> > >
|> > >
|> > >--
|> > = >Help        mailto:majordomo@net.doit.wi= sc.edu and say
|> "help" in message body
|> > >Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|> "unsubscribe
|> > >ipfix" in message body
|> > >Archive     http://ipfix.doit.wisc.edu/archive/
|> > >
|> >
|> > --
|> > Dipl.-Ing. Tanja Zseby
|> > FhI FOKUS/Global = Networking          &n= bsp;          Email: =
|> zseby@fokus.fhg.de
|> > Kaiserin-Augusta-Allee = 31           &nbs= p;           &nbs= p;      
|> Phone: +49-30-3463-7153
|> > D-10589 Berlin, = Germany           = ;            = ;  Fax:  
|> +49-30-3463-8153
|> >
|>
|--------------------------------------------------------------= --------
|> > ----------------
|> > "Living on earth is expensive but it = includes a free trip
|> around the sun." (Anonymous)
|> >
|> = --------------------------------------------------------------
|> ------------------------
|>
|>
|> --
|> Help        = mailto:majordomo@net.doit.wi= sc.edu and say "help"
|> in message body
|> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|> "unsubscribe ipfix" in message = body
|> Archive     http://ipfix.doit.wisc.edu/archive/
|>
|>
|
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1BA1D.C5DD30F0-- -- 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 Feb 20 11:03:58 2002 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 LAA04822 for ; Wed, 20 Feb 2002 11:03:58 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dYu1-0004j6-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 09:43:29 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dYu0-0004j0-00 for ipfix@net.doit.wisc.edu; Wed, 20 Feb 2002 09:43:28 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id KAA28874; Wed, 20 Feb 2002 10:52:58 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma028790; Wed, 20 Feb 02 10:52:23 -0500 Received: by cnc-exc2.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 10:41:57 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA070D@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Randy Bush'" Cc: "'Fred True'" , ipfix Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Date: Wed, 20 Feb 2002 10:42:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA25.2A168600" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA25.2A168600 Content-Type: text/plain |-----Original Message----- |From: Randy Bush [mailto:randy@research.att.com] |Sent: Wednesday, February 20, 2002 8:32 AM |To: Norseth, KC |Cc: 'Fred True'; ipfix |Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the |recent comments on the Architecture Draft) | | |> A MIB would be wonderful. Currently it is not in the scope of the |> charter, There is an unwritten rule that every group needs a mib. In the case of NetFlow (v5-v8), there has been a great cry for a mib by customers of some kind. We recognize this void. What will these mibs do? How do they relate to RTFM? Will they become part of the charter? That is still in the air. We just have not closed our minds to the idea. |but inventing a new configuration protocol is? We have not said we are inventing a new protocol. What we are doing is trying to select from existing protocols, the best protocol. To say that NetFlow v9 is it without doing a valid selection process would be wrong. K.C. |randy | ------_=_NextPart_001_01C1BA25.2A168600 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent = comments on the Architecture Draft)

|-----Original Message-----
|From: Randy Bush [mailto:randy@research.att.com= ]
|Sent: Wednesday, February 20, 2002 8:32 AM
|To: Norseth, KC
|Cc: 'Fred True'; ipfix
|Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer = to the
|recent comments on the Architecture Draft)
|
|
|> A MIB would be wonderful.  Currently it = is not in the scope of the
|> charter,

There is an unwritten rule that every group needs a = mib.  In the case of NetFlow (v5-v8), there has been a great cry = for a mib by customers of some kind. We recognize this void. What will = these mibs do?  How do they relate to RTFM? Will they become part = of the charter? That is still in the air.  We just have not closed = our minds to the idea.

|but inventing a new configuration protocol = is?

We have not said we are inventing a new protocol. = What we are doing is trying to select from existing protocols, the best = protocol.  To say that NetFlow v9 is it without doing a valid = selection process would be wrong.

K.C.

|randy
|

------_=_NextPart_001_01C1BA25.2A168600-- -- 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 Feb 20 12:25:39 2002 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 MAA08939 for ; Wed, 20 Feb 2002 12:25:39 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dZxh-0006Zf-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 10:51:21 -0600 Received: from mailhost.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dZxf-0006Za-00 for ipfix@net.doit.wisc.edu; Wed, 20 Feb 2002 10:51:19 -0600 Received: from auckland.ac.nz (root@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id FAA13738 for ; Thu, 21 Feb 2002 05:51:13 +1300 (NZDT) Message-Id: <200202201651.FAA13738@mailhost.auckland.ac.nz> Date: Wed, 20 Feb 2002 08:53:39 -0800 (PST) From: n.brownlee@auckland.ac.nz Subject: [ipfix] Re: WG process, 18 Feb teleconference minutes To: ipfix@net.doit.wisc.edu In-Reply-To: <20020219224308.A16324@doit.wisc.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Hello everyone: Responding to the "what's going on" postings on the list: As you all know from my last few 'WG cochair' postings, the co-chairs convened an 'editorial' teleconference to clarify what should be in each the Architecture and Data Model drafts, and make sure they get submitted on time. I realise that my selection of a small editorial team (only 5 people) was arbitrary, it was only intended to get the drafts safely submitted before the Minneapolis cutoff date, 22 February. Recommendations from the teleconference (full minutes follow below): - Need to focus energy on charter goals at this stage. Co-chairs will summarise / moderate the mailing list discussions, and produce lists of 'current issues' from time to time. - WG should consider making an 'Applicability' draft covering 'how to use IPFIX,' in more detail than will fit comfortably in the Architecture document. - WG should consider moving the 'middleboxes' material from the Architecture document (it's not mentioned in the WG charter) into a new draft. - Configuration. Not in charter, at this stage we need to document what current flow export systems do. (other 'not-in-charter' things include 'what's not done well in existing flow export systems') - 'Protocols' material in Architecture document. Our charter says we need to select a protocol. We propose to start by listing requirements, with reference to exisiting systems (as documented in their various Internet Drafts). When we have consensus on these requirements we will be able to evaluate the various protocols. - The 'Data Model' draft is really a combined information and data model, i.e. it defines a traffic flow (a set of packets which share common values from some attributes) and gives clear definitions for all the attributes supported in current flow export systems, together with brief encoding details for each attribute (e.g. using SNMP textual conventions). It does not say how a complete flow is to be encoded into a complete packet, that belongs in the Architecture document. Furthermeore, the data model details do not cover data elements of the "control" traffic (like message formats) only the flow information itself. - Architecture and Data Model drafts need IANA Considerations and Security Considerations sections. - Document editors. Teleconference believes each of the new documents should have two editors (on the title page), and a list of authors (i.e. all those who supplied text for the document) and their companies in a suitable section of the document. Suggested editors: Architecture - KC, Ganesh Data Model - KC, Paul Your co-chairs are working on agenda for the Minneapolis meeting. They encourage everyone to continue discussion on the list! ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand Thanks to Cisco for arranging and hosting the conference call. A list of those that participated follows the minutes below. ---------------------------------------------------------------------- The call began Mon Feb 18 ~1100 CST 2002. The conference call followed a rough list of agenda items introduced by KC Norseth and the chairs. The following topics were discussed: *) We began with a reminder that our charter should be the guide to what issues need to be addressed in the "Architecture" and "Data Model" documents. We reviewed the following list of items from our charter, naming which document (REQuirements, DATA model, ARCHitecture) should address each: flow definition: req data encodings: data packet sampling: req/data ... security: all transport: arch reliability: all To limit the work for our document milestones, we mentioned that we should be careful not to "design the future" at this point, i.e. we are not chartered to design an entire IPFIX system. *) Regarding the "design team" arch and data documents, it was noted that "middleboxes" is not mentioned in the charter. It should perhaps be moved/deferred to a yet-to-be-proposed document. *) It was noted that our focus for the discussion today is to prepare "-00" versions of teh drafts of arch and data by the end of the week. We are not choosing which is "technically best" amongst the implementation proposals at this point. *) There was some discussion on the items currently in the early draft of the "Data Model" document. It was generally agreed that this doucment should define data members in an implementation-independent way. This led to some terminology discussions in which is was noted that our "Data Model" is also, or is instead, an Information Model document. *) We discussed our charter item regarding selecting a protocol (whether an existing transport or full flow-export implementation) and the chairs suggested that this be deferred for the time being. This will be proposed in the mailing list. *) We asked Benoit and Ganesh they were OK with the integration of portions of their B/G "IPFIX proposal" document at this point. No issues were raised, and they agreed that its use as a source of input for the other documents was satisfactory. *) Renaming data model to informational model was proposed. In general, throughout the discussion, this seemed generally accepted amongst the participants. While this document has this new, hopefully clearer purpose, we will continue to refer to the document as the _data_ model. It was noted that some things that are in the current "Data Model" document don't belong there, if it is really an information model, with some minor encoding details (such as integer sizes and such). Specifically things such as version number fields, message formats and structures do'tn't belong in this document. *) It was asked which documents are responsible for specifying the "flow definition" (as mentioned in the charter). It was proposed, and generally accepted, that the requirements document addresses the flow defintion as it should, and that additionally the data model doc should further qualify the flow defintion using the terminology and info/data model elements that it introduces. *) We discussed, at some length, which sections of the existing documents could be be moved to applicability document(s). Further discussion on this issue should continue in the mailing list. *) It was proposed that it is the Architecture document that may ultimately have the message encodings on the wire and such, so that material will be removed from the data document. *) It was proposed that the architecture document talk about how you export or act upon the flow info that is assembled in terms of things defined in informational model. *) Where does information abelong bout how the thing is configured? This is out-of-scope... w/regard to current practice there is no communication of this information. (negotiation of what the exporter is doing is out-of-scope but not necessarily what the collector is capable of) It was agreed that this is still a hot issue in the list... *) The chairs were asked to participate more in the mailing list to raise a warning when long discussions about topics that are not in the charter are drawing the pariticipants efforts away from our focus. *) It was noted that after another Requirements document revision, and discussion in Minneapolis, the requirements doc will probably be about two months behind the scedule originally proposed. We'll aim for last call in April. *) Packet sampling was discussed - because it is in our charter. It was suggeste that sampling belongs, at least, in the data model document. Possibly also in the architecture, but as yet it is unknown to what degree. To constrain this portion of the effort from leading to undue complications, it was suggested that we address it to the point that packet sampling is used in existing practice. Dave Plonka volunteered to proposed (in the public mailing) list how this should be addressed in the existing docs. *) It was proposed that the current architecture doc should add a section that defines what the selection criteria will be for an IPFIX transport protocol. *) Terminology - Requirements draft will contain a subset of all requirements, Architecture and data will have their own terminology *) Limit arch and info/data model to what the charter requires (section 8 of arch pretty much goes out) *) We discussed who should be listed as "Authors" or "Editors" of the existing "design team" draft documents. It was noted that the IESG suggest that it only be a short list, and our current list is not suitably short. It was proposed that only the document editors be specified at the top of the documents, and that all the other authoring participants be acknowledged in an "Authors" section of each document. The chairs asked that we attempt to choose select just two people to be the editor for each document. Also, it was noted that the editors must be able to cooperate with each other. For the Requirements document, Juergen said the authors would discuss this soon, such as on Feb 19. For the Architecture document, KC and Ganesh have been proposed. For the Data Model, KC and Paul Calato have been proposed. *) Participating authors will suitably credited in an "Authors" section, perhaps in addition to others in the usual Acknowledgements section. We signed off from the call Mon Feb 18 ~1300 CST 2002 The following participated in the conference call: KC Norseth Ganesh Sadasivan Benoit Claise Dave Plonka Paul Calato Juergen Quittek Nevil Brownlee ---------------------------------------------------------------------- -- 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 Feb 20 12:28:37 2002 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 MAA09562 for ; Wed, 20 Feb 2002 12:28:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16daJq-0007MN-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 11:14:14 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16daJo-0007MG-00 for ipfix@net.doit.wisc.edu; Wed, 20 Feb 2002 11:14:12 -0600 Date: Wed, 20 Feb 2002 11:14:12 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Message-ID: <20020220111412.C18793@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-F-PARENT_DEL, illegal attempt to delete parent logical name table X-Shakespearean-Insult: Thou surly dizzy-eyed coxcomb Precedence: bulk Sender: majordomo listserver Please note the following reminder from our AD (which I'm forwarding because it bounced to the list admin)... ----- Forwarded message from owner-ipfix@net.doit.wisc.edu ----- From: Randy Bush References: <59358A738F45D51186A30008C74CE250DA0706@slc-exc1.ctron.com> Message-Id: Sender: Randy Bush Date: Wed, 20 Feb 2002 07:31:54 -0800 > A MIB would be wonderful. Currently it is not in the scope of the > charter, but inventing a new configuration protocol is? randy ----- End forwarded message ----- Randy - this got bounced to me because of our subscriber-only list policy... let me know if you'd prefer to be subscribed by this email address (or both). -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Feb 20 16:59:36 2002 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 QAA21627 for ; Wed, 20 Feb 2002 16:59:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16deKH-0005SC-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 15:30:57 -0600 Received: from mail-green.research.att.com ([135.207.30.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16deKF-0005Rx-00 for ipfix@net.doit.wisc.edu; Wed, 20 Feb 2002 15:30:55 -0600 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 402741E053; Wed, 20 Feb 2002 16:30:49 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA03256; Wed, 20 Feb 2002 16:30:47 -0500 (EST) Date: Wed, 20 Feb 2002 16:30:48 -0500 (EST) From: Fred True To: Reinaldo Penno Cc: ipfix Subject: RE: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) In-Reply-To: <4F973E944951D311B6660008C7917CF008B6E327@zsc4c008.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sender: majordomo listserver Reinaldo, > I don't think any of us who manage routers really want a new > >paradigm for speaking to them, complete with requirements for > >reliability, > >low overhead, security, etc. > > hum...I think I disagree. I know other people that work in big SPs that > would disagree also. If CLI was so "easy" in a complex network such products > weren't being made. Well let me be more clear: I was not advocating CLI - in fact quite the reverse. What I'm saying is that there are other extant protocols or methods that can be used to accomplish collector-to-router communication and configuration management. SNMP seems like a decent choice to me, for the reasons I stated, but I am sure there are other options. What I don't think we need, though (as someone who works with a very large ISP, especially in the area of measurement and instrumentation) is a brand new paradigm specific to Netflow or IPFIX. I don't specifically know what IPFIX is proposing that is different than Netflow or packet header sampling (can someone point me to the proposal?); but if we are dealing with some type of router based traffic measurement, the configuration parameters, even in extreme cases, are fairly straightforward. You set interfaces you want to monitor, filters (using whatever syntax is appropriate for the router), aggregation schemes, sampling rates or methods, collection destinations, etc. From our point of view, we are already managing thousands of devices with SNMP. There are an abundance of tools for dealing with SNMP: everything from commerical products with correlation across many layers of devices to Perl modules for developers or prototypers. > We are talking about dozens of exporters possible talking to dozens of > collectors with different levels of compliance. How do you intend to do that > with SNMP? What's so difficult about that? We plan to deal with hundreds, not dozens (in fact we currently deal with more than dozens). If there is a published MIB, even if there are several versions across different devices, I don't see the scaling problem. Just make sure the tools you run on your collectors are portable, and know how to speak to the available versions via simple inquiries. The point I *can* see is that if this is to be supported across many vendors, it would be nice to have a standard syntax for things like filters, sampling parameters, etc. Is that what IPFIX intends? -fred -- Fred True "My name is Ozymandias, King of Kings: Internet and Network Systems Research Look on my works, ye Mighty, AT&T Labs-Research, Florham Park, NJ and despair!" ft@research.att.com -P. B. Shelley -- 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 Feb 20 19:41:14 2002 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 TAA24945 for ; Wed, 20 Feb 2002 19:41:14 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dh1T-00018x-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 18:23:43 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dh1Q-00018R-00 for ipfix-data@net.doit.wisc.edu; Wed, 20 Feb 2002 18:23:40 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1L0N7D14528; Wed, 20 Feb 2002 18:23:08 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF57D6>; Wed, 20 Feb 2002 16:23:06 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008B6EAAE@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: ipfix-data@net.doit.wisc.edu, calato@riverstonenet.com Cc: "Norseth, KC" Subject: [ipfix-data] Data doc Date: Wed, 20 Feb 2002 16:23:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA6D.EDF0FE00" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA6D.EDF0FE00 Content-Type: text/plain; charset="iso-8859-1" Hello Paul, I'm finishing rewriting sections 6.9.3, 6.9.4, 6.10.1, 6.10.2, 6.12 - 6.12.4 of the data doc. I changed the virtual information section (6.12) it to a more general section on services that change packet content. These include, but are not limited to, Request Routing, middleboxes, OPES and others. instead of virtual this and that I'm planning on putting original and modified. Are you okay witht his? BTW, what is LSNAT? regards, Reinaldo ------_=_NextPart_001_01C1BA6D.EDF0FE00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Data doc

Hello Paul,

I'm finishing rewriting sections 6.9.3, 6.9.4, = 6.10.1, 6.10.2, 6.12 - 6.12.4 of the data doc.

I changed the virtual information section = (6.12)  it to a more general section on services that change = packet content. These include, but are not limited to, Request Routing, = middleboxes, OPES and others.

instead of virtual this and that I'm planning on = putting original and modified. Are you okay witht his?

BTW, what is LSNAT?

regards,

Reinaldo



------_=_NextPart_001_01C1BA6D.EDF0FE00-- -- 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 Feb 20 20:45:48 2002 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 UAA25789 for ; Wed, 20 Feb 2002 20:45:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dhwe-0002K9-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 19:22:48 -0600 Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dhwa-0002JZ-00 for ipfix-data@net.doit.wisc.edu; Wed, 20 Feb 2002 19:22:44 -0600 Received: from agile.yagosys.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id RAA18174; Wed, 20 Feb 2002 17:22:13 -0800 (PST) Received: from agile.yagosys.com (agile.yagosys.com [127.0.0.1]) by agile.yagosys.com (8.12.0/8.12.0) with ESMTP id g1L1MDkY020955 for ; Wed, 20 Feb 2002 17:22:13 -0800 Received: (from mrm@localhost) by agile.yagosys.com (8.12.0/8.12.0/Submit) id g1L1MDp0020954 for ipfix-data@net.doit.wisc.edu; Wed, 20 Feb 2002 17:22:13 -0800 Date: Wed, 20 Feb 2002 17:22:13 -0800 From: Michael MacFaden To: ipfix-data@net.doit.wisc.edu Subject: Re: [ipfix-data] Data doc Message-ID: <20020220172213.M1067@riverstonenet.com> References: <4F973E944951D311B6660008C7917CF008B6EAAE@zsc4c008.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4F973E944951D311B6660008C7917CF008B6EAAE@zsc4c008.us.nortel.com>; from reinaldo_penno@nortelnetworks.com on Wed, Feb 20, 2002 at 04:23:04PM -0800 X-Operating-System: GNU/Linux 2.4.17 Precedence: bulk Sender: majordomo listserver On Wed, Feb 20, 2002 at 04:23:04PM -0800, Reinaldo Penno wrote: >BTW, what is LSNAT? See RFC 2391 Mike MacFaden -- 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 Feb 20 21:49:51 2002 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 VAA27439 for ; Wed, 20 Feb 2002 21:49:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dj3W-0003ks-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 20:33:59 -0600 Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dj3U-0003kK-00 for ipfix-data@net.doit.wisc.edu; Wed, 20 Feb 2002 20:33:56 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g1L2XPt02033; Wed, 20 Feb 2002 18:33:25 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABG25183; Wed, 20 Feb 2002 18:33:47 -0800 (PST) Message-ID: <3C745C74.DE60AEE9@cisco.com> Date: Wed, 20 Feb 2002 18:33:24 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: reinaldo_penno@nortelnetworks.com CC: ipfix-data@net.doit.wisc.edu Subject: [ipfix-data] data doc section 5 [was "Re: [ipfix-arch] Clarification on Arch document, section 7.2"] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Reinaldo, For some reason I missed this e-mail... The intention is to do some kind of pre-filtering so that a narrower set of flows are generated. The flow itself could be different from what is used for filtering. Just to expand this a little more: Create flows for only those packets which are destined to an IP address 90.1.2.3 with destination L4 port=80. The flows itself are defined by keys say {src address, tos, input interface, src port}. Thanks Ganesh -------------------------------------------------------------------------- In the arch document it is said: "7.2. Selection Criteria Of Packets The measurement device MAY define rules so that only certain packets within a flow can be chosen for measurement at an observation point. This MAY be done by one of the two types of methods defined below or a combination of them. A combination of each of these ways can be adopted to select the packets .i.e. one can define a set of methods {F1, S1, F2, S2, S3} executed in certain sequence at an observation point to collect flows of a particular type. 7.2.1. Function on properties that determines a flow type (Fi) Packets that satisfy a function on the fields defined by the packet header fields or fields obtained while doing the packet processing or the properties of the packet itself. Example: Mask/Match of the fields that define a filter. The filter may be defined as {Protocol == TCP, Destination Port between 80 and 120}. Multiple such filters could be used in any sequence to select packets. 7.2.2. Sampling packets on a flow type (Si) Packets that satisfy the sampling criteria for this flow type. Example: Sample every 100th packet that was received at an observation point and collect the flow information for a particular flow type. choosing all the packets is a special case where sampling rate is 1:1." Now, 7.2.2 seems to be a valid example, but I'm not sure about 7.2.1. It seems to me that when you apply a function that further reduces the properies that determines a flow you are by definition indirectly (or directly) defining another flow. The flow based on the original definition plus Fi. Then this would be just another flow and not a "selection criteria of packets" within a flow. Maybe I should just rephrase mentioning that in the introduction of this section is is said "to collect flows of a particular type". So, a special type of a flow wouldn't be another flow? Yes, all the packets within a flow can be a subset of another flow, but then, all packets are a subset of the flow "src=any dest=any, proto=any, etc". regards, Reinaldo -- 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 Feb 20 22:28:28 2002 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 WAA27875 for ; Wed, 20 Feb 2002 22:28:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16djcX-0004SN-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 21:10:09 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16djcW-0004Ri-00 for ipfix-data@net.doit.wisc.edu; Wed, 20 Feb 2002 21:10:08 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1L39GD00588; Wed, 20 Feb 2002 21:09:17 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF58PK>; Wed, 20 Feb 2002 19:09:15 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008B6EB83@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan Cc: ipfix-data@net.doit.wisc.edu Subject: [ipfix-data] RE: data doc section 5 [was "Re: [ipfix-arch] Clarification on Ar ch document, section 7.2"] Date: Wed, 20 Feb 2002 19:09:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA85.23C05AF0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA85.23C05AF0 Content-Type: text/plain; charset="iso-8859-1" Hello Ganesh, comments inline.. >-----Original Message----- >From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] >Sent: Wednesday, February 20, 2002 6:33 PM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: ipfix-data@net.doit.wisc.edu >Subject: data doc section 5 [was "Re: [ipfix-arch] >Clarification on Arch >document, section 7.2"] > > >Hi Reinaldo, > For some reason I missed this e-mail... > The intention is to do some kind of pre-filtering > so that a narrower set of flows are generated. > The flow itself could be different from what is > used for filtering. right, but it must be a subset of the filtered one, right? I think see what you mean...you have a pre-filtering rule, say PF that gives you a set of flows S. You then apply independent methods (say M1 and M2) to find results R1 and R2, which then you might possible export independetly. Is this okay? So, my question is: what's the difference from applying say, PF+M1 directly on the original unfiltered flow and also PF+M2 on the original unfiltered flow and get results R1 and R2? thanks, Reinaldo > Just to expand this a little more: Create flows for > only those packets which are destined to an IP address > 90.1.2.3 with destination L4 port=80. The flows > itself are defined by keys say > {src address, tos, input interface, src port}. > >Thanks >Ganesh > >--------------------------------------------------------------- >----------- > >In the arch document it is said: > >"7.2. Selection Criteria Of Packets > >The measurement device MAY define rules so that only certain packets >within >a flow can be chosen for measurement at an observation point. This MAY >be >done by one of the two types of methods defined below or a combination >of >them. A combination of each of these ways can be adopted to select the >packets .i.e. one can define a set of methods {F1, S1, F2, S2, S3} >executed >in certain sequence at an observation point to collect flows of a >particular >type. > > >7.2.1. Function on properties that determines a flow type (Fi) > >Packets that satisfy a function on the fields defined by the packet >header >fields or fields obtained while doing the packet processing or the >properties of the packet itself. > >Example: > >Mask/Match of the fields that define a filter. The filter may >be defined >as >{Protocol == TCP, Destination Port between 80 and 120}. Multiple such >filters could be used in any sequence to select packets. > >7.2.2. Sampling packets on a flow type (Si) > >Packets that satisfy the sampling criteria for this flow type. > >Example: > >Sample every 100th packet that was received at an observation point and >collect the flow information for a particular flow type. choosing all >the >packets is a special case where sampling rate is 1:1." > >Now, 7.2.2 seems to be a valid example, but I'm not sure about >7.2.1. It > >seems to me that when you apply a function that further reduces the >properies that determines a flow you are by definition indirectly (or >directly) defining another flow. The flow based on the original >definition >plus Fi. Then this would be just another flow and not a "selection >criteria >of packets" within a flow. > >Maybe I should just rephrase mentioning that in the >introduction of this > >section is is said "to collect flows of a particular type". So, a >special >type of a flow wouldn't be another flow? Yes, all the packets within a >flow >can be a subset of another flow, but then, all packets are a subset of >the >flow "src=any dest=any, proto=any, etc". > >regards, > >Reinaldo > > ------_=_NextPart_001_01C1BA85.23C05AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: data doc section 5 [was "Re: [ipfix-arch] Clarification = on Arch document, section 7.2"]

Hello Ganesh,

comments inline..

>-----Original Message-----
>From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]=
>Sent: Wednesday, February 20, 2002 6:33 = PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: ipfix-data@net.doit.wisc.edu
>Subject: data doc section 5 [was "Re: = [ipfix-arch]
>Clarification on Arch
>document, section 7.2"]
>
>
>Hi Reinaldo,
>  For some reason I missed this = e-mail...
>  The intention is to do some kind of = pre-filtering
>  so that a narrower set of flows are = generated.
>  The flow itself  could be different = from what is
>  used for filtering.

right, but it must be a subset of the filtered one, = right?

I think see what you mean...you have a pre-filtering = rule, say PF that gives you a set of flows S. You then apply = independent methods (say M1 and M2) to find results R1 and R2, which = then you might possible export independetly. Is this okay?

So, my question is: what's the difference from = applying say, PF+M1 directly on the original unfiltered flow and also = PF+M2 on the original unfiltered flow and get results R1 and R2? =

thanks,

Reinaldo



>  Just to expand this a little more: Create = flows for
>  only those packets which are destined to = an IP address
>  90.1.2.3 with destination L4 port=3D80. = The flows
>  itself are defined by keys  = say
> {src address, tos, input interface, src = port}.
>
>Thanks
>Ganesh
>
>-----------------------------------------------------------= ----
>-----------
>
>In the arch document it is said:
>
>"7.2.  Selection Criteria Of = Packets
>
>The measurement device MAY define rules so that = only certain packets
>within
>a flow can be chosen for measurement at an = observation point. This MAY
>be
>done by one of the two types of methods defined = below or a combination
>of
>them.  A combination of each of these ways = can be adopted to select the
>packets .i.e. one can define a set of methods = {F1, S1, F2, S2, S3}
>executed
>in certain sequence at an observation point to = collect flows of a
>particular
>type.
>
>
>7.2.1.  Function on properties that = determines a flow type (Fi)
>
>Packets that satisfy a function on the fields = defined by the packet
>header
>fields or fields obtained while doing the packet = processing or the
>properties of the packet itself.
>
>Example:
>
>Mask/Match of the fields that define a filter. = The filter may
>be defined
>as
>{Protocol =3D=3D TCP, Destination Port between = 80 and 120}. Multiple such
>filters could be used in any sequence to select = packets.
>
>7.2.2.  Sampling packets on a flow type = (Si)
>
>Packets that satisfy the sampling criteria for = this flow type.
>
>Example:
>
>Sample every 100th packet that was received at = an observation point and
>collect the flow information for a particular = flow type. choosing all
>the
>packets is a special case where sampling rate is = 1:1."
>
>Now, 7.2.2 seems to be a valid example, but I'm = not sure about
>7.2.1. It
>
>seems to me that when you apply a function that = further reduces the
>properies that determines a flow you are by = definition indirectly (or
>directly) defining another flow. The flow based = on the original
>definition
>plus Fi. Then this would be just another flow = and not a "selection
>criteria
>of packets" within a flow.
>
>Maybe I should just rephrase mentioning that in = the
>introduction of this
>
>section is is said "to collect flows of a = particular type". So, a
>special
>type of a flow wouldn't be another flow? Yes, = all the packets within a
>flow
>can be a subset of another flow, but then, all = packets are a subset of
>the
>flow "src=3Dany dest=3Dany, proto=3Dany, = etc".
>
>regards,
>
>Reinaldo
>
>

------_=_NextPart_001_01C1BA85.23C05AF0-- -- 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 Feb 20 23:30:55 2002 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 XAA00023 for ; Wed, 20 Feb 2002 23:30:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dkb0-0005fI-00 for ipfix-list@mil.doit.wisc.edu; Wed, 20 Feb 2002 22:12:38 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dkay-0005eu-00 for ipfix-data@net.doit.wisc.edu; Wed, 20 Feb 2002 22:12:36 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1L4BsZ20168; Wed, 20 Feb 2002 20:11:54 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABG27196; Wed, 20 Feb 2002 20:12:27 -0800 (PST) Message-ID: <3C747393.F6237544@cisco.com> Date: Wed, 20 Feb 2002 20:12:04 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-data@net.doit.wisc.edu Subject: [ipfix-data] Re: data doc section 5 [was "Re: [ipfix-arch] Clarification on Arch document, section 7.2"] References: <4F973E944951D311B6660008C7917CF008B6EB83@zsc4c008.us.nortel.com> Content-Type: multipart/alternative; boundary="------------420E534ADB0B6D53B90C1067" Precedence: bulk Sender: majordomo listserver --------------420E534ADB0B6D53B90C1067 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Renaldo, Reinaldo Penno wrote: > > > Hello Ganesh, > > comments inline.. > > >-----Original Message----- > >From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] > >Sent: Wednesday, February 20, 2002 6:33 PM > >To: Penno, Reinaldo [SC9:T327:EXCH] > >Cc: ipfix-data@net.doit.wisc.edu > >Subject: data doc section 5 [was "Re: [ipfix-arch] > >Clarification on Arch > >document, section 7.2"] > > > > > >Hi Reinaldo, > > For some reason I missed this e-mail... > > The intention is to do some kind of pre-filtering > > so that a narrower set of flows are generated. > > The flow itself could be different from what is > > used for filtering. > > right, but it must be a subset of the filtered one, right? > > I think see what you mean...you have a pre-filtering rule, say PF that > gives you a set of flows S. You then apply independent methods (say M1 > and M2) to find results R1 and R2, which then you might possible > export independetly. Is this okay? > > So, my question is: what's the difference from applying say, PF+M1 > directly on the original unfiltered flow and also PF+M2 on the > original unfiltered flow and get results R1 and R2? Probably you did not understand my explanation. But leave it. As you said we can generate the same set of flows by other means (eg. collect all flows and do postfiltering on flows).But the idea here is to say that these are the options available. One can use any combinaiton of section 5.2 & 5.3 to achieve the desired results. Thanks Ganesh > > > thanks, > > Reinaldo > > > > Just to expand this a little more: Create flows for > > only those packets which are destined to an IP address > > 90.1.2.3 with destination L4 port=80. The flows > > itself are defined by keys say > > {src address, tos, input interface, src port}. > > > >Thanks > >Ganesh > > > >--------------------------------------------------------------- > >----------- > > > >In the arch document it is said: > > > >"7.2. Selection Criteria Of Packets > > > >The measurement device MAY define rules so that only certain packets > >within > >a flow can be chosen for measurement at an observation point. This > MAY > >be > >done by one of the two types of methods defined below or a > combination > >of > >them. A combination of each of these ways can be adopted to select > the > >packets .i.e. one can define a set of methods {F1, S1, F2, S2, S3} > >executed > >in certain sequence at an observation point to collect flows of a > >particular > >type. > > > > > >7.2.1. Function on properties that determines a flow type (Fi) > > > >Packets that satisfy a function on the fields defined by the packet > >header > >fields or fields obtained while doing the packet processing or the > >properties of the packet itself. > > > >Example: > > > >Mask/Match of the fields that define a filter. The filter may > >be defined > >as > >{Protocol == TCP, Destination Port between 80 and 120}. Multiple such > > >filters could be used in any sequence to select packets. > > > >7.2.2. Sampling packets on a flow type (Si) > > > >Packets that satisfy the sampling criteria for this flow type. > > > >Example: > > > >Sample every 100th packet that was received at an observation point > and > >collect the flow information for a particular flow type. choosing all > > >the > >packets is a special case where sampling rate is 1:1." > > > >Now, 7.2.2 seems to be a valid example, but I'm not sure about > >7.2.1. It > > > >seems to me that when you apply a function that further reduces the > >properies that determines a flow you are by definition indirectly (or > > >directly) defining another flow. The flow based on the original > >definition > >plus Fi. Then this would be just another flow and not a "selection > >criteria > >of packets" within a flow. > > > >Maybe I should just rephrase mentioning that in the > >introduction of this > > > >section is is said "to collect flows of a particular type". So, a > >special > >type of a flow wouldn't be another flow? Yes, all the packets within > a > >flow > >can be a subset of another flow, but then, all packets are a subset > of > >the > >flow "src=any dest=any, proto=any, etc". > > > >regards, > > > >Reinaldo > > > > --------------420E534ADB0B6D53B90C1067 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Renaldo,

Reinaldo Penno wrote:

 

Hello Ganesh,

comments inline..

>-----Original Message-----
>From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]
>Sent: Wednesday, February 20, 2002 6:33 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: ipfix-data@net.doit.wisc.edu
>Subject: data doc section 5 [was "Re: [ipfix-arch]
>Clarification on Arch
>document, section 7.2"]
>
>
>Hi Reinaldo,
>  For some reason I missed this e-mail...
>  The intention is to do some kind of pre-filtering
>  so that a narrower set of flows are generated.
>  The flow itself  could be different from what is
>  used for filtering.

right, but it must be a subset of the filtered one, right?

I think see what you mean...you have a pre-filtering rule, say PF that gives you a set of flows S. You then apply independent methods (say M1 and M2) to find results R1 and R2, which then you might possible export independetly. Is this okay?

So, my question is: what's the difference from applying say, PF+M1 directly on the original unfiltered flow and also PF+M2 on the original unfiltered flow and get results R1 and R2?

Probably you did not understand my explanation. But leave it.
As you said we can generate the same set of flows by other
means (eg. collect all flows and do postfiltering on flows).But
the idea here is to say that these are the options available.
One can use any combinaiton of section 5.2 & 5.3 to achieve
the desired results.

Thanks
Ganesh

 

thanks,

Reinaldo
 

>  Just to expand this a little more: Create flows for
>  only those packets which are destined to an IP address
>  90.1.2.3 with destination L4 port=80. The flows
>  itself are defined by keys  say
> {src address, tos, input interface, src port}.
>
>Thanks
>Ganesh
>
>---------------------------------------------------------------
>-----------
>
>In the arch document it is said:
>
>"7.2.  Selection Criteria Of Packets
>
>The measurement device MAY define rules so that only certain packets
>within
>a flow can be chosen for measurement at an observation point. This MAY
>be
>done by one of the two types of methods defined below or a combination
>of
>them.  A combination of each of these ways can be adopted to select the
>packets .i.e. one can define a set of methods {F1, S1, F2, S2, S3}
>executed
>in certain sequence at an observation point to collect flows of a
>particular
>type.
>
>
>7.2.1.  Function on properties that determines a flow type (Fi)
>
>Packets that satisfy a function on the fields defined by the packet
>header
>fields or fields obtained while doing the packet processing or the
>properties of the packet itself.
>
>Example:
>
>Mask/Match of the fields that define a filter. The filter may
>be defined
>as
>{Protocol == TCP, Destination Port between 80 and 120}. Multiple such
>filters could be used in any sequence to select packets.
>
>7.2.2.  Sampling packets on a flow type (Si)
>
>Packets that satisfy the sampling criteria for this flow type.
>
>Example:
>
>Sample every 100th packet that was received at an observation point and
>collect the flow information for a particular flow type. choosing all
>the
>packets is a special case where sampling rate is 1:1."
>
>Now, 7.2.2 seems to be a valid example, but I'm not sure about
>7.2.1. It
>
>seems to me that when you apply a function that further reduces the
>properies that determines a flow you are by definition indirectly (or
>directly) defining another flow. The flow based on the original
>definition
>plus Fi. Then this would be just another flow and not a "selection
>criteria
>of packets" within a flow.
>
>Maybe I should just rephrase mentioning that in the
>introduction of this
>
>section is is said "to collect flows of a particular type". So, a
>special
>type of a flow wouldn't be another flow? Yes, all the packets within a
>flow
>can be a subset of another flow, but then, all packets are a subset of
>the
>flow "src=any dest=any, proto=any, etc".
>
>regards,
>
>Reinaldo
>
>

--------------420E534ADB0B6D53B90C1067-- -- 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 Feb 21 07:42:11 2002 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 HAA15149 for ; Thu, 21 Feb 2002 07:42:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16ds3I-00021r-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 06:10:20 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16ds3F-00020k-00 for ipfix@net.doit.wisc.edu; Thu, 21 Feb 2002 06:10:17 -0600 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-76.cisco.com [144.254.7.76]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA21825 for ; Thu, 21 Feb 2002 13:09:45 +0100 (MET) Message-ID: <3C74E397.CB2F34B5@cisco.com> Date: Thu, 21 Feb 2002 13:09:59 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft) Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Fred,
 
Subject: [ipfix] Re: Scope of IPFIX (was Answer to the recent comments on the Architecture Draft)
From: Fred True (ft@research.att.com)
Date: Wed Feb 20 2002 - 02:15:01 CST

Folks,

A colleague of mine pointed me to the current discussion on expanding the
Cisco netflow protocol to allow better management of export configuration,
and I thought I'd add my $0.02.  I've read over most of the threads I
could find, but please let me know if I'm missing the gist of what has
been proposed, or forgive me if I'm not aware of the full context of the
discussion.

First, on a related note, I presume people are aware of the forthcoming v9
netflow export format.  This is the format they should have started with
(as opposed to v1, v5, v7 etc.), as it is self-describing (e.g. it
contains in-stream metadata telling client applications how to decode it)
and can handle arbitrary export fields.  They plan to use this for future
versions of netflow, packet header sampling, etc.

On the point of managing netflow data collection, I gather that the
proposal is to modify the netflow export protocol to be bi-directional, so
that a collector can send configuration messages to the routers rather
than relying on the current CLI commands.

No we don't want to have a bidirectional protocol.
From http://ipfx.doit.wisc.edu/list/ipfix/archive/0705.html:
-  Configuration.  Not in charter, at this stage we need to
   document what current flow export systems do. (other 'not-in-charter'
   things include 'what's not done well in existing flow export systems')

Regards, Benoit

I don't understand the point of
this.  Aside from requiring a whole lot of new development on the IOS
side, I don't think any of us who manage routers really want a new
paradigm for speaking to them, complete with requirements for reliability,
low overhead, security, etc.

What we've asked for in the past (and have not yet convinced them to
implement) is to have a netflow configuration MIB.  Everyone can deal with
SNMP, it's reliable and allows authentication, it allows you to read or
write configuration info, and it's easy to create lightweight SNMP clients
on the collector (or management workstation) side to control the
configuration, even in near-real-time (so, for example, you could tune
your sampling rate based on observed data).  It seems to me that leaving
the plans for v9 netflow export alone and using SNMP for dynamic netflow
configuration would be the most expedient and architecturally sound
solution.

-fred

--
Fred True                               "My name is Ozymandias, King of Kings:
Internet and Network Systems Research    Look on my works, ye Mighty,
AT&T Labs-Research, Florham Park, NJ     and despair!"
ft@research.att.com                                     -P. B. Shelley

-- 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 Feb 21 10:06:41 2002 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 KAA19561 for ; Thu, 21 Feb 2002 10:06:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16duQb-0005Ft-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 08:42:33 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16duQZ-0005Fl-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 08:42:31 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id JAA08084; Thu, 21 Feb 2002 09:52:02 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma008032; Thu, 21 Feb 02 09:51:14 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXSXCG>; Thu, 21 Feb 2002 09:40:32 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA0718@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Reinaldo Penno'" , ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] Clarification on Arch document, section 7.4 Date: Thu, 21 Feb 2002 09:41:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BAE5.C8A5A2E0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BAE5.C8A5A2E0 Content-Type: text/plain -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 19, 2002 12:10 PM To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Clarification on Arch document, section 7.4 a) "3. For long aging flows, the exporter SHOULD export the flow records on regular basis, in order to:" I think it should say "...the exporter SHOULD be able to export the flow..." b) then.. "a. report the flow records periodic accounting information to the collector b. avoid counter wrapping This activity timeout SHOULD be configurable" It should be "a. provide periodic accounting information to the collector b. avoid counter wrapping." This activity SHOULD be configurable. Btw, can someone elaborate on the counter wrapping stuff? It is very simple to send so much data though the line on a flow that the byte counter rolls over. This is very typical in 1 gig and 10g ports. counter 32 is not large enough field size for this. c) then.. "4. If the exporter experiences resources constraints, a flow MAY be prematurely expired (example: memory)" Is there any other choice? This seems too implementation specific. regards, Reinaldo ------_=_NextPart_001_01C1BAE5.C8A5A2E0 Content-Type: text/html Message
 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, February 19, 2002 12:10 PM
To: ipfix-arch@net.doit.wisc.edu
Subject: [ipfix-arch] Clarification on Arch document, section 7.4

a) "3. For long aging flows, the exporter SHOULD export the flow records on regular basis, in order to:"

I think it should say "...the exporter SHOULD be able to export the flow..."

b) then..

   "a.  report the flow records periodic accounting information to the collector
    b.  avoid counter wrapping This activity timeout SHOULD be configurable"

It should be

"a. provide periodic accounting information to the collector
b. avoid counter wrapping."

This activity SHOULD be configurable. Btw, can someone elaborate on the counter wrapping stuff?  

It is very simple to send so much data though the line on a flow that the byte counter rolls over.  This is very typical in 1 gig and 10g  ports.  counter 32 is not large enough field size for this.

c) then..

"4. If the exporter experiences resources constraints, a flow MAY be prematurely expired (example: memory)"

Is there any other choice? This seems too implementation specific.

regards,

Reinaldo

------_=_NextPart_001_01C1BAE5.C8A5A2E0-- -- 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 Feb 21 10:11:16 2002 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 KAA19709 for ; Thu, 21 Feb 2002 10:11:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16duYg-0005Oh-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 08:50:54 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16duYe-0005OI-00 for ipfix-data@net.doit.wisc.edu; Thu, 21 Feb 2002 08:50:52 -0600 Received: from riverstonenet.com (134.141.180.106 [134.141.180.106]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY77JJ; Thu, 21 Feb 2002 06:49:37 -0800 Message-ID: <3C750900.CCF2CDE@riverstonenet.com> Date: Thu, 21 Feb 2002 09:49:36 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-data@net.doit.wisc.edu, "Norseth, KC" Subject: Re: [ipfix-data] Data doc References: <4F973E944951D311B6660008C7917CF008B6EAAE@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > Hello Paul, > > I'm finishing rewriting sections 6.9.3, 6.9.4, 6.10.1, 6.10.2, 6.12 - > 6.12.4 of the data doc. > Can you send a copy to me as well > I changed the virtual information section (6.12) it to a more general > section on services that change packet content. These include, but are > not limited to, Request Routing, middleboxes, OPES and others. > > instead of virtual this and that I'm planning on putting original and > modified. Are you okay witht his? > The wording doesn't matter to me as long as the concept is the same. I'll have to take a look at the text. > BTW, what is LSNAT? I think Mike already answered this one. > > regards, > > Reinaldo -- 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 Feb 21 11:56:21 2002 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 LAA24233 for ; Thu, 21 Feb 2002 11:56:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dw5I-0007W0-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 10:28:40 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dw5F-0007UV-00 for ipfix@net.doit.wisc.edu; Thu, 21 Feb 2002 10:28:37 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g1LGS4h06895 for ipfix@net.doit.wisc.edu; Thu, 21 Feb 2002 17:28:04 +0100 (CET) Date: Thu, 21 Feb 2002 17:28:04 +0100 (CET) From: Benoit Claise Message-Id: <200202211628.g1LGS4h06895@bru-cse-222.cisco.com> To: ipfix@net.doit.wisc.edu Subject: [ipfix] missing ipfix emails?? X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver All, I see emails in the archive that I haven't been forwarded to me: http://ipfix.doit.wisc.edu/list/ipfix/archive/0694.html http://ipfix.doit.wisc.edu/list/ipfix/archive/0693.html http://ipfix.doit.wisc.edu/list/ipfix/archive/0692.html http://ipfix.doit.wisc.edu/list/ipfix/archive/0698.html And I'm sure that I haven't received them because I run procmail with procmail.log on my UNIX system. Some of these emails are from Tuesday. So just delay is not possible! Is it only me or did others face the same problem? Regards, Benoit. -- 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 Feb 21 14:03:06 2002 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 OAA29673 for ; Thu, 21 Feb 2002 14:03:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dyAR-0002OA-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 12:42:07 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dyAO-0002Nz-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 12:42:04 -0600 Received: from fokus.fhg.de (dhcp206 [195.37.78.206]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1LIfqP05090; Thu, 21 Feb 2002 19:41:52 +0100 (MET) Message-ID: <3C753EC1.4010603@fokus.fhg.de> Date: Thu, 21 Feb 2002 19:38:57 +0100 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "K.C. Norseth" , reinaldo_penno@nortelnetworks.com CC: IPFIX Architecture , Tanja Zseby Subject: [ipfix-arch] applicability document Content-Type: multipart/mixed; boundary="------------040009000703000204020804" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------040009000703000204020804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi K.C. and Reinaldo, attached you can find the first version of the applicability document as text file. It includes the sections 8 and 10 from Reinaldo and me from the architecture draft. I also included the intrusion detection part (section 8.1) Who contributed this to the architecture ? Regards Tanja -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- --------------040009000703000204020804 Content-Type: text/plain; name="ipfix-applicability-v1.txt" Content-Disposition: inline; filename="ipfix-applicability-v1.txt" Content-Transfer-Encoding: 7bit Internet Draft T.Zseby draft-zseby-ipfix-applicability-00.txt FhI FOKUS Expires: August 2002 R. Penno VERSION DATE February 21, 2002 Nortel Networks February 2002 IPFIX Applicability Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes how various applications can use the IP Flow Information Export (IPFIX) protocol. It furthermore shows how the IPFIX framework relates to other architectures and frameworks. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ ]. 1. INTRODUCTION 2 2. TERMINOLOGY 3 3. APPLICATIONS OF IPFIX 3 3.1. ACCOUNTING WITH IPFIX 3 3.2. TRAFFIC PROFILING WITH IPFIX 3 3.3. TRAFFIC ENGINEERING WITH IPFIX 3 3.4. INTRUSION DETECTION WITH IPFIX 3 3.5. QOS MONITORING WITH IPFIX 3 3.5.1. Measurement of Round-trip-time (RTT) with IPFIX 4 3.5.2. Measurement of One-way-delay (OWD) with IPFIX 4 3.5.3. Measurement of Loss with IPFIX 5 3.5.4. Measurement of delay variation with IPFIX 5 3.5.5. Sampling for QoS Monitoring 5 3.6. DEPLOYMENT OF SAMPLING METHODS IN IPFIX 5 4. RELATION OF IPFIX TO OTHER FRAMEWORKS AND PROTOCOLS 5 4.1. IPFIX AND AAA 6 4.1.1. Connecting via an AAA client 7 4.1.2. Connecting via an Application Specific Module (ASM) 7 4.2. IPFIX AND RTFM 8 4.3. IPFIX CONSIDERATIONS FOR MIDDLEBOXES 8 4.3.1. Firewall 8 4.3.2. Network Address Translation 9 4.3.3. Traffic Conditioners 11 4.3.4. Tunneling 12 4.3.5. VPNs 12 4.4. IPFIX AND RMON 14 4.5. IPFIX AND IPPM 14 4.6. IPFIX AND PSAMP 14 5. SECURITY CONSIDERATION 15 6. REFERENCES 15 7. ACKNOWLEDGEMENTS 16 8. AUTHOR'S ADDRESSES 16 9. FULL COPYRIGHT STATEMENT 17 1. Introduction The IPFIX protocol defines how IP Flow information can be exported. It is intended to provide input for various applications. This document describes how applications can use the IPFIX protocol. Furthermore the relations of IPFIX to other frameworks and architectures are described. 2. Terminology [maybe needed ] 3. Applications of IPFIX 3.1. Accounting with IPFIX [TODO for Tanja] 3.2. Traffic Profiling with IPFIX [TODO] 3.3. Traffic Engineering with IPFIX [TODO] 3.4. Intrusion detection with IPFIX [TODO for Reinaldo ?] Intrusion Detection System (IDS) monitors and controls the security incidents [4]. Typical IDS system includes components like Data source, Sensor, Analyzer and Management stations [4]. A Sensor monitors the data source and raises the alarm to the Analyzer. The analyzer collects various incident information and reports this to the management station. With IPFIX, the event of interest can be exported either from collector or from exporter. For smooth integration, it will be better for the IDS system to integrate with the collector since the collector has all the aggregated information from different observation points. The IDS can request the collector to monitor the events or IP flow through an IPFIX template. [Who contributed this text to the architecture doc ?] 3.5. QoS Monitoring with IPFIX The performance of QoS monitoring is one target application for using the IPFIX protocol. QoS monitoring is the passive observation of the transmission quality for single flows or traffic aggregates in the network. It is needed for instance for the validation of QoS guarantees in service level agreements. Some QoS metrics require the correlation of data from multiple measurement points. For this the clock of the involved exporting devices need to be synchronized. Furthermore such measurements would benefit from post-processing functions (e.g. packet ID generation) at the exporter and/or collector. This section describes how the monitoring of different metrics can be performed with IPFIX. The following metrics are considered: round trip time, one-way-delay, loss and delay variation. 3.5.1.Measurement of Round-trip-time (RTT) with IPFIX The passive measurement of round-trip-times (RTT) can be performed by using packet pair matching techniques as described in [Brow00]. For the measurements, request/response packet pairs from protocols like DNS, ICMP,SNMP or TCP (syn/syn-ack, data/ack) are utilized to passively observe the RTT. As always for passive measurements this only works if the required traffic of interest is actually present in the network. In order to use this measurement technique, the IPFIX meter needs to measure both directions. A classification of the protocols mentioned above has to be done. That means parts of the transport header are used for the classification. Since a differentiation of flows in accordance to the transport header is one of the requirements for IPFIX, such classification can be performed without extensions. Nevertheless, the meter needs to recognize request and response packets for the given protocols and therefore needs to look further into the packet. This is not required for IPFIX but can be achieved by optional extensions to the classification process. The exporting device needs to assign a timestamp for the arrival of the packets. The calculation of the RTT can be done directly at the exporter or at the collector. In the first case IPFIX would transfer the calculated RTT to the collector. In the second case IPFIX needs to send the observed packet types and the timestamps to the collector. 3.5.2.Measurement of One-way-delay (OWD) with IPFIX Passive one-way-delay measurements require the collection of data at two measurement points. It is required to recognize packets at the second measurement point in order to correlate packet arrival events from both points. This can be done for instance by capturing packet headers and parts of the packet and recognize packets based on this. In order to reduce the amount of measurement data a unique packet ID can be calculated from the header and part of the content e.g. by using a CRC or hash function [GrDM98, DuGr00, ZsZC01].Since IPFIX is not targeted at packet capturing these functionalities do not need to be supported by a standard IPFIX meter. Nevertheless, in some scenarios it might be sufficient to calculate a packet ID under consideration of header fields including datagram ID and maybe sequence numbers (from transport protocols) without looking at parts of the packet content. Especially if packet IDs need to be unique only for a certain time interval or a certain amount of packet ID collisions is tolerable this can be a solution. 3.5.3.Measurement of Loss with IPFIX Passive loss measurements for single flows can be performed at one measurement point for instance by using sequence numbers that are present in higher layer protocols. This requires the capturing of the sequence numbers of subsequent packets of the observed flow at the IPFIX meter. An alternative to this is to perform a two-point measurement as described above and just consider packets as lost that do not arrive at the second measurement point in a given maximum time frame. 3.5.4.Measurement of delay variation with IPFIX Delay variation is defined as the difference of one-way-delay values for selected packets.[DeCi01]. Therefore this metric can be calculated by performing passive measurement of one-way-delay for subsequent packets (e.g. of a flow) and then calculate the differences. 3.5.5.Sampling for QoS Monitoring Since QoS monitoring can lead to an overwhelming amount of measurement result data, it would highly benefit from the deployment of mechanisms to reduce the measurement data, like aggregation of results and sampling. Sampling methods can be grouped according to the sampling strategy (systematic, random or stratified) and the trigger that starts a sampling interval (count-based, time-based or packet-content-based) [ClPB93]. Sampling can also be used as a method to dynamically reduce resource consumption if the meter is overloaded. Then the IPFIX meter can switch to a sampling method if too many packets have to be observed. Since the expected estimation error depends heavily on the used sampling strategy, the application that receives the data needs to be aware of the sampling scheme and the used parameters. Therefore it is important that the IPFIX exporter informs the collector precisely about the used sampling strategy. This is even more required if the IPFIX meter dynamically invokes sampling. 3.6. Deployment of Sampling Methods in IPFIX [TODO for Tanja] [other applications ?] 4. Relation of IPFIX to other frameworks and protocols 4.1. IPFIX and AAA AAA defines a protocol and architecture for authentication, authorization and accounting for service usage. The DIAMETER protocol is used for AAA communication for network access services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture [XXX-RFC2903] provides a framework for extending the AAA support also for other services. DIAMETER defines the exchange of messages between AAA entities, e.g. between AAA clients at access devices and AAA servers and among AAA servers. It is used also for the transfers of accounting records. For usage-based accounting measurement data from the network is needed to generate an accounting record. IPFIX provides a protocol to export measurement data from the measurement point to the consumer of this data (like network management and accounting systems). The provisioning of accounting with IPFIX can be realized without an AAA infrastructure. The collector can directly forward the measurement information to an accounting application. Nevertheless, if an AAA infrastructure is in place, IPFIX can provide the input for the generation of accounting records and several features of the AAA architecture can be used. Features include the mapping of a user ID to the flow information (by using authentication information), the generation of DIAMETER accounting records and the secure exchange of accounting records between domains with DIAMETER. Three possibilities to connect IPFIX and AAA can be distinguished: 4.1.1.Connecting via an AAA client One possibility to connect IPFIX and AAA is to run an AAA client on the IPFIX collector. This client can generate DIAMETER accounting messages and send them to an AAA server. The mapping of the flow information to a user ID can be done in the AAA server by using data from the authentication process. DIAMETER accounting messages can be sent to the accounting application or to other AAA servers (e.g. in roaming scenarios). +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | DIAMETER | | +--+--------+--+ | | AAA-C | | + +--------+ | | | | Collector | +--------------+ ^ | IPFIX | +------------+ | Exporter | +------------+ Figure 2: IPFIX collector connects to AAA server via AAA client 4.1.2. Connecting via an Application Specific Module (ASM) Another possibility is to directly connect the IPFIX collector with the AAA server via an application specific module (ASM). Application specific modules have been proposed by the IRTF AAA architecture research group (AAARCH) in [RFC2903]. They act as an interface between AAA server and service equipment. In this case the IPFIX collector is part of the ASM. The ASM acts as an interface between the IPFIX protocol and the input interface of the AAA server. The ASM translates the received IPFIX data into an appropriate format for the AAA server. The AAA server then can add information about the user ID and generate a DIAMETER accounting record. This accounting record can be sent to an accounting application or to other AAA serves. +---------+ DIAMETER +---------+ | AAA-S |------------->| AAA-S | +---------+ +---------+ ^ | +------------------+ | ASM | | +------------+ | | | Collector | | +------------------+ ^ | IPFIX | +------------+ | Exporter | +------------+ Figure 3: IPFIX connects to AAA server via ASM 4.2. IPFIX and RTFM [TODO for Tanja] 4.3. IPFIX Considerations for Middleboxes A Middlebox is a network intermediate device that implements one or more of the middlebox services. Policy based packet filtering (a.k.a. firewall), Network address translation (NAT), Intrusion detection, Load balancing, Policy based tunneling and IPsec security are all examples of a middlebox function (or service). [MCFW]. For instance, a NAT middlebox is a middlebox implementing NAT service and a firewall middlebox is a middlebox implementing firewall service. It is expected that the exporter in the IPFIX architecture will probably implement some form of middlebox service given its ubiquity today. Since some of these middlebox services might affect flow exportation and how the collector interprets them, there is a need to provide an analysis of these implications in relation to the IPFIX architecture and a set of recommendations. The following sections provide a non-exhaustive analysis of middlebox services, its implications on the IPFIX architecture and a corresponding set of recommendations. 4.3.1. Firewall Firewall is a policy based packet filtering middlebox function, typically used for restricting access to/from specific devices and applications. The policies are often termed Access Control Lists (ACLs)[MCFW]. The firewall middlebox service allows the exporter to explicitly drop packets based on some administrative policy. In this case, the exporter can take one of the following actions that will have a direct impact on the information provided by the collector to the user. * Silently Discard In this case the packet is discarded and no flow information record is sent to the collector. * Discard and export flow In this case the packet is discarded, and the flow information record is sent to the collector. * Discard and export flow with discard notification In this case the packet is discarded, and the flow information record is sent to the collector with an indication that the packet was discarded. 4.3.2. Network Address Translation Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end hosts. Transparent routing here refers to modifying end-node addresses en-route and maintaining state for these updates so that when a datagram leaves one realm and enters another, datagrams pertaining to a session are forwarded to the right end-host in either realm [NAT-TERM]. From an exporter (middlebox) perspective, a NAT is composed of two flows, one from the client to the NAT middlebox and another from the NAT middlebox to the destination. Based on this fact, the exporter has several modes of operation, i.e., it can export the private realm flow, the public realm, or both. This is further constrained by the flavor of NAT implemented, meaning that in order for the exported information to be useful for the collector, sometimes the associated flows on the two realms need to be exported in the same flow record. Although there are many flavors of address translation that lend themselves to different applications, this section will only address the IPFIX architecture implications of traditional NAT, bi- directional NAT and twice NAT. 4.3.2.1. Traditional NAT Traditional NAT would allow hosts within a private network to transparently access hosts in the external network, in most cases. In a traditional NAT, sessions are unidirectional, outbound from the private network. This is in contrast with bi-directional NAT, which permits sessions in both inbound and outbound directions. A detailed description of traditional NAT may be found in section [NAT-TERM]. If the exporter is providing traditional NAT service and only the private realm flow is exported, only destination based information can be inferred from the collector. The reason for this is twofold. First, the collector will not be able to find the reverse flow (when applicable) associated with a private realm flow record, and second is that in the more general scenario the collector can be connected to several exporters providing NAT service and there might be overlapping private realm addresses between the networks connected to these exporters. In a traditional NAT scenario the exporter SHOULD export private and public realm information in the same flow record or provide the collector with a unique key to associate the two if exported on different flow records. 4.3.2.2. Bi-Directional NAT With a bi-directional NAT, sessions can be initiated from hosts in the public network as well as the private network. Private network addresses are bound to globally unique addresses, statically or dynamically as connections are established in either direction. Detailed description of Bi-Directional may be found in section [NAT- TERM]. 4.3.2.3. Twice NAT Twice NAT is a variation of NAT in that both the source and destination addresses are modified by NAT as a datagram crosses address realms. This is in contrast to Traditional-NAT and Bi- Directional NAT, where only one of the addresses (either source or destination) is translated. Note, there is no such term as 'Once- NAT'. Detailed description of Bi-Directional may be found in section [NAT-TERM]. In the case of twice NAT the exporter MUST export private and public realm information in the same flow record or provide the collector with a unique key to associate the two if exported on different flow records. 4.3.3. Traffic Conditioners A traffic conditioner may contain the following elements: meter, marker, shaper, and dropper. A traffic stream is selected by a classifier, which steers the packets to a logical instance of a traffic conditioner[DIFF-ARCH]. From an IPFIX architecture perspective we are going to address marking, shaping and dropping services. 4.3.3.1. Marking Diffserv packet markers set the DS field of a packet to a particular codepoint, adding the marked packet to a particular DS behavior aggregate. The marker may be configured to mark all packets which are steered to it to a single codepoint, or may be configured to mark a packet to one of a set of codepoints used to select a PHB in a PHB group, according to the state of a meter. When the marker changes the codepoint in a packet it is said to have "re-marked" the packet [DIFF-ARCH]. From and IPFIX architecture perspective, the exporter can take one of the following actions when it needs to remark a packet. * Unmarked flow The exporter can export the flow before it was remarked. This mode of operation is strongly discouraged. * Remarked flow The exporter can export the flow after it was remarked. * Unmarked and remarked flow. The exporter can export the flow before and after it was remarked or export the flow before it was remarked and an indication of what was the DSCP after it was remarked. 4.3.3.2. Shapers Shapers delay some or all of the packets in a traffic stream in Order to bring the stream into compliance with a traffic profile. A shaper usually has a finite-size buffer, and packets may be discarded if there is not sufficient buffer space to hold the delayed packets. For an IPFIX perspective, since the discard of a packet by a shaper is not voluntary, no indication should be sent to the collector. 4.3.3.3. Droppers Droppers discard some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile. This process is known as "policing" the stream. Note that a dropper can be implemented as a special case of a shaper by setting the shaper buffer size to zero (or a few) packets. In a manner analogous to the middlebox firewall service, middlebox policing services also allow the exporter to explicitly drop packets based on some administrative policy. The three possible export behaviors described for the firewall service when a packet needs to be dropped are also applicable to here, i.e., silent discard, discard and export flow, discard and export flow with discard notification. 4.3.4. Tunneling The exporter can export the flows before and/or after they get tunneled. In the later case the encapsulated flow information might not be available due to confidentiality precautions such as those used by IPsec, or due to the fact the exporter lacks the necessary intelligence to inspect the encapsulated packet. Moreover, depending on where in the network the exporter is located, it might only be able to export flows associated with the tunnel, without visibility into the encapsulated packet. Apart from what was said above, it should also be factor in the fact that flows exported before they get tunneled, will provide information about the private network sites, but not necessarily about the backbone, since the route taken by the packet it's now know at that point in time (and vice-versa). Tunnel terminates on exporter Tunnel initiates on exporter Exporter implements tunnel switching 4.3.5. VPNs The term "Virtual Private Network" (VPN) refers to the communication between a set of sites, making use of a shared network infrastructure. Multiple sites of a private network may therefore communicate via the public infrastructure, in order to facilitate the operation of the private network. The logical structure of the VPN, such as addressing, topology, connectivity, reachability, and access control, is equivalent to part of or all of a conventional private network using private facilities [RFC2764] [VPN-2547BIS]. There are multiple flavors of VPNs, the one with more relevance to the IPFIX architecture is the PE-based-VPN. A PE-based VPN (or Provider Edge-based Virtual Private Network) is one in which PE devices in the SP network provide the VPN. This allows the existence of the VPN to be hidden from the CE devices, which can operate as if part of a normal customer network. A detailed discussion of VPNs can be found in [PPVPN-FR]. 4.3.5.1. Layer 3 PE-based VPN A layer 3 PE-based VPN is one in which the SP takes part in IP level forwarding based on the customer network's IP address space. In general, the customer network is likely to make use of private and/or non-unique IP addresses. This implies that at least some devices in the provider network needs to understand the IP address space as used in the customer network. Typically this knowledge is limited to the PE device [PPVPN-FR] which is directly attached to the customer. In a layer 3 PE-based VPN the provider will need to participate in some aspects of management and provisioning of the VPNs, such as ensuring that the PE devices are configured to support the correct VPNs. This implies that layer 3 PE-based VPNs are by definition provider provisioned VPNs [PPVPN-FR]. In order to connect the different VPN sites belonging to the same VPN the SP uses a tunneling technique such as MPLS, L2TP or IPsec. These tunnels originate and terminate on PE devices. One of the characteristics of a layer 3 PE-based VPNs is that they offload some aspects of VPN management from the customer network. From an IPFIX architecture perspective, this means that the SP is the one that potentially will be providing the IPFIX service for the VPNs that it provides connectivity. The exporter in Layer 3 PE-based VPN can be located on the customer's network, on the SP's backbone (P Router) or on the edge (PE router). The premise of this discussion is that the exporter is the one providing middlebox services, so in the case of VPNs we assume that the exporter is located in a PE device. 4.3.5.1.1. Tunneling [TODO for Reinaldo ?] 4.3.5.1.2. Overlapping Address Realms In the case the exporter plays the role of a PE router [VPN-2547BIS] in a provider provisioned VPN scenario and has VPNs with overlapping private address realms, it can only provide useful non-conflicting information to the provider for intra-VPN traffic if it uses a technique that allows the collector to uniquely identify to which VPN the flow belongs. Several techniques could be used to accomplish this goal. One of these techniques is to include the VPN Global unique identifier [VPN- ID] as one of the keys in the flow record. In the case the exporter supports VPNs with overlapping private address realms, it MUST include the VPN-ID [VPN-ID] in the exported flow record. 4.3.5.2. Layer 2 PE-based VPN [TBD] A layer 2 PE-based VPN is one in which the network is aware of the VPN, but does only layer 2 forwarding and signaling. This implies that the SP provisions and maintains layer 2 connectivity between CE devices [VPN-L2]. Forwarding options include MAC addresses (such as LAN emulation), use of point-to-point link layer connections (FR or ATM), multipoint-to- point (using MPLS multipoint to point LSPs), and point-to-multipoint (e.g., ATM VCCs). For a layer 2 PE-based VPN, the PE device may be a router, LSR, or IP switch. From the CE's perspective, the PE will be operating as a switch. 4.4. IPFIX and RMON [TODO] 4.5. IPFIX and IPPM [TODO for Tanja] 4.6. IPFIX and PSAMP [TODO for Tanja ?] [further relations ?] 5. Security Consideration [TODO] 6. References [QuZC02] J. Quittek ,et. Al "Requirements for IP Flow Information Export ", (work in progress) ,Internet Draft, Internet Engineering Task Force, , February 2002 [Wood02]M. Wood ,et al.," Intrusion Detection Message Exchange Requirements",(work in progress), Internet Draft, Internet Engineering Task Force, draft-ietf-idwg-requirements-06,February 2002. [Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of Internet Traffic Engineering", (work in progress), Internet Draft, Internet Engineering Task Force, draft-ietf-tewg-principles-02.txt, May 2002 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions, http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47- adelaide/pp-dist/ [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric for IPPM, , November 2001 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss Metric for IPPM, September 1999 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: Application of Sampling Methodologies to Network Traffic Characterization, Proceedings of ACM SIGCOMM'93, San Francisco, CA, USA, September 13 - 17, 1993 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed MARTENS, John G. CLEARY: Nonintrusive and Accurate Measurement of Unidirectional Delay and Delay Variation on the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000. [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay Metric for IPPM, Request for Comments: 2679, September 1999 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation of Building Blocks for Passive One-way-delay Measurements, Proceedings of Passive and Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture and framework," work in progress. October 2001. [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider Provisioned Virtual Private Networks ", work in progress, , January 2002. [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft , July 2001. [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. 7. Acknowledgements 8. Author's Addresses Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9-B1240 Santa Clara, CA 95134 Email: rpenno@nortelnetworks.com Tanja Zseby Fraunhofer Institute for Open Communication Systems(FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49 30 3463 7153 Email: zseby@fokus.fhg.de 9. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. --------------040009000703000204020804-- -- 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 Feb 21 14:17:36 2002 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 OAA00300 for ; Thu, 21 Feb 2002 14:17:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dyQJ-0002go-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 12:58:32 -0600 Received: from pool-162-83-253-16.ny5030.east.verizon.net ([162.83.253.16] helo=newyork.qosient.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dyQH-0002gh-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 12:58:29 -0600 Received: from sphynx (sphynx.newyork.qosient.com [192.168.0.64]) by newyork.qosient.com (8.11.6/8.11.0) with ESMTP id g1LIwOi07722; Thu, 21 Feb 2002 13:58:24 -0500 Reply-To: From: "Carter Bullard" To: "'Tanja Zseby'" , "'K.C. Norseth'" , Cc: "'IPFIX Architecture'" Subject: RE: [ipfix-arch] applicability document Date: Thu, 21 Feb 2002 13:58:12 -0500 Organization: QoSient, LLC Message-ID: <5C8959A16A71B449AE793CF52FBBED66019022@ptah.newyork.qosient.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <5C8959A16A71B449AE793CF52FBBED66051410@ptah.newyork.qosient.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Tanja, Not a criticism but a question for clarification. You refer to an IPFIX meter in your applicability document. What is an IPFIX meter? Carter Carter Bullard QoSient, LLC 300 E. 56th Street, Suite 18K New York, New York 10022 carter@qosient.com Phone +1 212 588-9133 Fax +1 212 588-9134 http://qosient.com > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby > Sent: Thursday, February 21, 2002 1:39 PM > To: K.C. Norseth; reinaldo_penno@nortelnetworks.com > Cc: IPFIX Architecture; Tanja Zseby > Subject: [ipfix-arch] applicability document > > > Hi K.C. and Reinaldo, > > attached you can find the first version of the applicability > document as > text file. > > It includes the sections 8 and 10 from Reinaldo and me from the > architecture draft. I also included the intrusion detection part > (section 8.1) Who contributed this to the architecture ? > > Regards > Tanja > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: > zseby@fokus.fhg.de > Kaiserin-Augusta-Allee 31 Phone: > +49-30-3463-7153 > D-10589 Berlin, Germany Fax: > +49-30-3463-8153 > -------------------------------------------------------------- > ------------------------ > "Living on earth is expensive but it includes a free trip > around the sun." (Anonymous) > -------------------------------------------------------------- > ------------------------ > > -- 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 Feb 21 14:30:23 2002 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 OAA00891 for ; Thu, 21 Feb 2002 14:30:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16dyey-000334-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 13:13:40 -0600 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16dyew-00032x-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 13:13:38 -0600 Received: from fokus.fhg.de (dhcp206 [195.37.78.206]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1LJDSP08823; Thu, 21 Feb 2002 20:13:28 +0100 (MET) Message-ID: <3C75462C.4070505@fokus.fhg.de> Date: Thu, 21 Feb 2002 20:10:36 +0100 From: Tanja Zseby Organization: FhI FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: carter@qosient.com CC: "'Tanja Zseby'" , "'K.C. Norseth'" , reinaldo_penno@nortelnetworks.com, "'IPFIX Architecture'" Subject: Re: [ipfix-arch] applicability document References: <5C8959A16A71B449AE793CF52FBBED66019022@ptah.newyork.qosient.com> Content-Type: multipart/alternative; boundary="------------040703060604050004090000" Precedence: bulk Sender: majordomo listserver --------------040703060604050004090000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Carter, I just meant the metering process that runs on an IPFIX device. I could also be simply renamed to "metering process". We had (and still have) long discussions on terminology for the requirements document. When the terminology is fixed, then we should go again through the applicability document and adjust it to the terms. Regards, Tanja Carter Bullard wrote: >Tanja, > Not a criticism but a question for clarification. >You refer to an IPFIX meter in your applicability document. >What is an IPFIX meter? > >Carter > >Carter Bullard >QoSient, LLC >300 E. 56th Street, Suite 18K >New York, New York 10022 > >carter@qosient.com >Phone +1 212 588-9133 >Fax +1 212 588-9134 >http://qosient.com > >>-----Original Message----- >>From: majordomo listserver >>[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby >>Sent: Thursday, February 21, 2002 1:39 PM >>To: K.C. Norseth; reinaldo_penno@nortelnetworks.com >>Cc: IPFIX Architecture; Tanja Zseby >>Subject: [ipfix-arch] applicability document >> >> >>Hi K.C. and Reinaldo, >> >>attached you can find the first version of the applicability >>document as >>text file. >> >>It includes the sections 8 and 10 from Reinaldo and me from the >>architecture draft. I also included the intrusion detection part >>(section 8.1) Who contributed this to the architecture ? >> >>Regards >>Tanja >> >>-- >>Dipl.-Ing. Tanja Zseby >>FhI FOKUS/Global Networking Email: >>zseby@fokus.fhg.de >>Kaiserin-Augusta-Allee 31 Phone: >>+49-30-3463-7153 >>D-10589 Berlin, Germany Fax: >>+49-30-3463-8153 >>-------------------------------------------------------------- >>------------------------ >>"Living on earth is expensive but it includes a free trip >>around the sun." (Anonymous) >>-------------------------------------------------------------- >>------------------------ >> >> > > > >-- >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/ > -- Dipl.-Ing. Tanja Zseby FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 D-10589 Berlin, Germany Fax: +49-30-3463-8153 -------------------------------------------------------------------------------------- "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) -------------------------------------------------------------------------------------- --------------040703060604050004090000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Carter,

I just meant the metering process that runs on an IPFIX device. I could also be simply renamed to "metering process". We had (and still have) long discussions on terminology for the requirements document. When the terminology is fixed, then we should go again through the applicability document and adjust it to the terms.

Regards,
Tanja



Carter Bullard wrote:
Tanja,
   Not a criticism but a question for clarification.
You refer to an IPFIX meter in your applicability document.
What is an IPFIX meter?

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter@qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

-----Original Message-----
From: majordomo listserver 
[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby
Sent: Thursday, February 21, 2002 1:39 PM
To: K.C. Norseth; reinaldo_penno@nortelnetworks.com
Cc: IPFIX Architecture; Tanja Zseby
Subject: [ipfix-arch] applicability document


Hi K.C. and Reinaldo,

attached you can find the first version of the applicability 
document as 
text file.

It includes the sections 8 and 10 from Reinaldo and me from the 
architecture draft. I also included the intrusion detection part 
(section 8.1) Who contributed this to the architecture ?

Regards
Tanja

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: 
zseby@fokus.fhg.de	
Kaiserin-Augusta-Allee 31				Phone: 
+49-30-3463-7153
D-10589 Berlin, Germany				Fax:   
+49-30-3463-8153
--------------------------------------------------------------
------------------------ 
"Living on earth is expensive but it includes a free trip 
around the sun." (Anonymous)
--------------------------------------------------------------
------------------------





--
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/

-- 
Dipl.-Ing. Tanja Zseby			    	      	
FhI FOKUS/Global Networking			Email: zseby@fokus.fhg.de	
Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
-------------------------------------------------------------------------------------- 
"Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
--------------------------------------------------------------------------------------

--------------040703060604050004090000-- -- 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 Feb 21 16:23:41 2002 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 QAA04745 for ; Thu, 21 Feb 2002 16:23:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e0Kg-0005Gc-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 15:00:51 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e0Kd-0005FT-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 15:00:47 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1LKxdj19163; Thu, 21 Feb 2002 14:59:39 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF6JN0>; Thu, 21 Feb 2002 12:59:36 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008B6F0C7@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "Norseth, KC" , ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] Clarification on Arch document, section 7.4 Date: Thu, 21 Feb 2002 12:59:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB1A.AA544DC0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BB1A.AA544DC0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Norseth, KC [mailto:knorseth@enterasys.com] Sent: Thursday, February 21, 2002 6:41 AM To: Penno, Reinaldo [SC9:T327:EXCH]; ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] Clarification on Arch document, section 7.4 -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 19, 2002 12:10 PM To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Clarification on Arch document, section 7.4 a) "3. For long aging flows, the exporter SHOULD export the flow records on regular basis, in order to:" I think it should say "...the exporter SHOULD be able to export the flow..." b) then.. "a. report the flow records periodic accounting information to the collector b. avoid counter wrapping This activity timeout SHOULD be configurable" It should be "a. provide periodic accounting information to the collector b. avoid counter wrapping." This activity SHOULD be configurable. Btw, can someone elaborate on the counter wrapping stuff? It is very simple to send so much data though the line on a flow that the byte counter rolls over. This is very typical in 1 gig and 10g ports. counter 32 is not large enough field size for this. yes, that's what I tought. So the solution is just to augment th efield to a 64 counter. It seems that the peirodic reporting is completely orthogonal to this specific issue. c) then.. "4. If the exporter experiences resources constraints, a flow MAY be prematurely expired (example: memory)" Is there any other choice? This seems too implementation specific. regards, Reinaldo ------_=_NextPart_001_01C1BB1A.AA544DC0 Content-Type: text/html; charset="iso-8859-1" Message
 
-----Original Message-----
From: Norseth, KC [mailto:knorseth@enterasys.com]
Sent: Thursday, February 21, 2002 6:41 AM
To: Penno, Reinaldo [SC9:T327:EXCH]; ipfix-arch@net.doit.wisc.edu
Subject: RE: [ipfix-arch] Clarification on Arch document, section 7.4

 
-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, February 19, 2002 12:10 PM
To: ipfix-arch@net.doit.wisc.edu
Subject: [ipfix-arch] Clarification on Arch document, section 7.4

a) "3. For long aging flows, the exporter SHOULD export the flow records on regular basis, in order to:"

I think it should say "...the exporter SHOULD be able to export the flow..."

b) then..

   "a.  report the flow records periodic accounting information to the collector
    b.  avoid counter wrapping This activity timeout SHOULD be configurable"

It should be

"a. provide periodic accounting information to the collector
b. avoid counter wrapping."

This activity SHOULD be configurable. Btw, can someone elaborate on the counter wrapping stuff?  

It is very simple to send so much data though the line on a flow that the byte counter rolls over.  This is very typical in 1 gig and 10g  ports.  counter 32 is not large enough field size for this. 

yes, that's what I tought. So the solution is just to augment th efield to a 64 counter. It seems that the peirodic reporting is completely orthogonal to this specific issue.

 

c) then..

"4. If the exporter experiences resources constraints, a flow MAY be prematurely expired (example: memory)"

Is there any other choice? This seems too implementation specific.

regards,

Reinaldo

------_=_NextPart_001_01C1BB1A.AA544DC0-- -- 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 Feb 21 16:58:48 2002 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 QAA05675 for ; Thu, 21 Feb 2002 16:58:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e0yT-0006Rm-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 15:41:57 -0600 Received: from [130.216.191.4] (helo=mailhost.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e0yR-0006Rh-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 15:41:56 -0600 Received: from auckland.ac.nz (root@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id KAA07738; Fri, 22 Feb 2002 10:41:39 +1300 (NZDT) Message-Id: <200202212141.KAA07738@mailhost.auckland.ac.nz> Date: Thu, 21 Feb 2002 13:44:02 -0800 (PST) From: n.brownlee@auckland.ac.nz Subject: [ipfix-arch] counter wrapping To: reinaldo_penno@nortelnetworks.com cc: ipfix-arch@net.doit.wisc.edu In-Reply-To: <4F973E944951D311B6660008C7917CF008B6F0C7@zsc4c008.us.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Hi Reinaldo: > b. avoid counter wrapping." > > This activity SHOULD be configurable. Btw, can someone elaborate on the > counter wrapping stuff? > > It is very simple to send so much data though the line on a flow that the > byte counter rolls over. This is very typical in 1 gig and 10g ports. > counter 32 is not large enough field size for this. > > yes, that's what I tought. So the solution is just to augment th efield to a > 64 counter. It seems that the peirodic reporting is completely orthogonal to > this specific issue. You've covered the 'counter wrapping' problem - a flow information meter (whatever that turns out to be) needs counters wide enough not to wrap too often, and that becomes more of a problem at high link speeds. In RTFM, all counts are kept in 64-bit unsigned counters so that they don't wrap too often. Of more interest, I don't remember seeing any IPFIX discussion concerning just how information about long-running flows is to be exported. In particular, I believe that counters should never be reset. That would mean that successive exports of the same flow would have increasing counter values, a collector would need to remember the previous value and subtract it. Furthermore, provided unsigned arithmetic is used, the difference is correct even if the counter has wrapped. Provided, of course that the counter has only wrapped once! Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand -- 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 Feb 21 17:27:47 2002 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 RAA06126 for ; Thu, 21 Feb 2002 17:27:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e1Gi-00075e-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 16:00:48 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e1Gg-00074Z-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 16:00:46 -0600 Received: from riverstonenet.com (134.141.180.106 [134.141.180.106]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY8D2C; Thu, 21 Feb 2002 13:59:31 -0800 Message-ID: <3C756DC2.5B77F391@riverstonenet.com> Date: Thu, 21 Feb 2002 16:59:30 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: n.brownlee@auckland.ac.nz CC: reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <200202212141.KAA07738@mailhost.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit n.brownlee@auckland.ac.nz wrote: > > Hi Reinaldo: > > > b. avoid counter wrapping." > > > > This activity SHOULD be configurable. Btw, can someone elaborate on the > > counter wrapping stuff? > > > > It is very simple to send so much data though the line on a flow that the > > byte counter rolls over. This is very typical in 1 gig and 10g ports. > > counter 32 is not large enough field size for this. > > > > yes, that's what I tought. So the solution is just to augment th efield to a > > 64 counter. It seems that the peirodic reporting is completely orthogonal to > > this specific issue. We need to be careful here. Some of us need to get counters directly from the hardware so just changing the size is not an option. Doing it in software can be an issue too because that means extra memory is needed for each flow. > > You've covered the 'counter wrapping' problem - a flow information meter > (whatever that turns out to be) needs counters wide enough not to wrap > too often, and that becomes more of a problem at high link speeds. Not only the link speed but the aggregation level too. The higher level aggregations tend to get more bytes/packets per second. > In RTFM, all counts are kept in 64-bit unsigned counters so that they > don't wrap too often. > > Of more interest, I don't remember seeing any IPFIX discussion > concerning just how information about long-running flows is to be > exported. In particular, I believe that counters should never be reset. One more thing to keep in mind here is that most hardware does not provide a way to do an atomic get and set operation. So if you do reset it, you'll likely loose some information. > That would mean that successive exports of the same flow would have > increasing counter values, The other way is the box keeps track of the last reported in counter in software and still provide deltas. The problem with cumulative counts is on failover the collector will not have the last count. I'd like to keep collector to collector requirements to a minimum or none if possible. > a collector would need to remember the > previous value and subtract it. Furthermore, provided unsigned > arithmetic is used, the difference is correct even if the counter has > wrapped. Provided, of course that the counter has only wrapped once! > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > -- > 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/ -- 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 Feb 21 17:34:03 2002 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 RAA06295 for ; Thu, 21 Feb 2002 17:34:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e1UZ-0007Mn-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 16:15:07 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e1UV-0007Mg-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 16:15:03 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id RAA13904; Thu, 21 Feb 2002 17:24:34 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma013876; Thu, 21 Feb 02 17:23:56 -0500 Received: by smtp.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 17:13:28 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA0720@slc-exc1.ctron.com> From: "Norseth, KC" To: "Calato, Paul" , n.brownlee@auckland.ac.nz Cc: ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] counter wrapping Date: Thu, 21 Feb 2002 17:13:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB25.07267730" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BB25.07267730 Content-Type: text/plain Although a DELTA counter helps, if the interval between checking the flow causes a wrap (or 2 wraps), it can cause grief. This is an issue when the hardware cannot handle the larger number. The ability to send a flow record at any interval due to a counter rollover needs to be a selection criteria. K.C. |-----Original Message----- |From: Calato, Paul |Sent: Thursday, February 21, 2002 3:00 PM |To: n.brownlee@auckland.ac.nz |Cc: reinaldo_penno@nortelnetworks.com; ipfix-arch@net.doit.wisc.edu |Subject: Re: [ipfix-arch] counter wrapping | | |n.brownlee@auckland.ac.nz wrote: |> |> Hi Reinaldo: |> |> > b. avoid counter wrapping." |> > |> > This activity SHOULD be configurable. Btw, can someone |elaborate on |> > the counter wrapping stuff? |> > |> > It is very simple to send so much data though the line on a flow |> > that the byte counter rolls over. This is very typical in |1 gig and |> > 10g ports. counter 32 is not large enough field size for this. |> > |> > yes, that's what I tought. So the solution is just to augment th |> > efield to a 64 counter. It seems that the peirodic reporting is |> > completely orthogonal to this specific issue. | | We need to be careful here. Some of us need to get counters | directly from the hardware so just changing the size is | not an option. Doing it in software can be an issue too | because that means extra memory is needed for each flow. | |> |> You've covered the 'counter wrapping' problem - a flow information |> meter (whatever that turns out to be) needs counters wide enough not |> to wrap too often, and that becomes more of a problem at high link |> speeds. | | Not only the link speed but the aggregation level too. | The higher level aggregations tend to get more bytes/packets | per second. | |> In RTFM, all counts are kept in 64-bit unsigned counters so |that they |> don't wrap too often. |> |> Of more interest, I don't remember seeing any IPFIX discussion |> concerning just how information about long-running flows is to be |> exported. In particular, I believe that counters should never be |> reset. | | One more thing to keep in mind here is that most hardware | does not provide a way to do an atomic get and set operation. | So if you do reset it, you'll likely loose some information. | |> That would mean that successive exports of the same flow would have |> increasing counter values, | | The other way is the box keeps track of the last reported | in counter in software and still provide deltas. The |problem with | cumulative counts is on failover the collector will not | have the last count. I'd like to keep collector to collector | requirements to a minimum or none if possible. | |> a collector would need to remember the |> previous value and subtract it. Furthermore, provided unsigned |> arithmetic is used, the difference is correct even if the |counter has |> wrapped. Provided, of course that the counter has only wrapped once! |> |> Cheers, Nevil |> |> |----------------------------------------------------------------------- |> Nevil Brownlee Director, Technology Development |> Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland |> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand |> |> -- |> 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/ | |-- |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/ | ------_=_NextPart_001_01C1BB25.07267730 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] counter wrapping

Although a DELTA counter helps, if the interval = between checking the flow causes a wrap (or 2 wraps), it can cause = grief.  This is an issue when the hardware cannot handle the = larger number.  The ability to send a flow record at any interval = due to a counter rollover needs to be a selection criteria.

K.C.

|-----Original Message-----
|From: Calato, Paul
|Sent: Thursday, February 21, 2002 3:00 PM
|To: n.brownlee@auckland.ac.nz
|Cc: reinaldo_penno@nortelnetworks.com; = ipfix-arch@net.doit.wisc.edu
|Subject: Re: [ipfix-arch] counter wrapping
|
|
|n.brownlee@auckland.ac.nz wrote:
|>
|> Hi Reinaldo:
|>
|> > b. avoid counter wrapping."
|> >
|> > This activity SHOULD be configurable. = Btw, can someone
|elaborate on
|> > the counter wrapping stuff?
|> >
|> > It is very simple to send so much data = though the line on a flow
|> > that the byte counter rolls over.  = This is very typical in
|1 gig and
|> > 10g  ports. counter 32 is not large = enough field size for this.
|> >
|> > yes, that's what I tought. So the = solution is just to augment th
|> > efield to a 64 counter. It seems that the = peirodic reporting is
|> > completely orthogonal to this specific = issue.
|
|       We need to be = careful here. Some of us need to get counters
|       directly from = the hardware so just changing the size is
|       not an option. = Doing it in software can be an issue too
|       because that = means extra memory is needed for each flow.
|
|>
|> You've covered the 'counter wrapping' problem = - a flow information
|> meter (whatever that turns out to be) needs = counters wide enough not
|> to wrap too often, and that becomes more of a = problem at high link
|> speeds.
|
|       Not only the = link speed but the aggregation level too.
|       The higher = level aggregations tend to get more bytes/packets
|       per second. =
|
|> In RTFM, all counts are kept in 64-bit = unsigned counters so
|that they
|> don't wrap too often.
|>
|> Of more interest, I don't remember seeing any = IPFIX discussion
|> concerning just how information about = long-running flows is to be
|> exported.  In particular, I believe that = counters should never be
|> reset.
|
|       One more thing = to keep in mind here is that most hardware
|       does not = provide a way to do an atomic get and set operation.
|       So if you do = reset it, you'll likely loose some information.
|
|> That would mean that successive exports of the = same flow would have
|> increasing counter values,
|
|       The other way = is the box keeps track of the last reported
|       in counter in = software and still provide deltas. The
|problem with
|       cumulative = counts is on failover the collector will not
|       have the last = count. I'd like to keep collector to collector
|       requirements = to a minimum or none if possible.
|
|> a collector would need to remember the
|> previous value and subtract it.  = Furthermore, provided unsigned
|> arithmetic is used, the difference is correct = even if the
|counter has
|> wrapped.  Provided, of course that the = counter has only wrapped once!
|>
|> Cheers, Nevil
|>
|>
|--------------------------------------------------------------= ---------
|>    Nevil = Brownlee          &nbs= p;        Director, Technology = Development
|>    Phone: +64 9 373 7599 = x8941      ITSS, The University of = Auckland
|>    FAX: +64 9 373 = 7021      Private Bag 92019, Auckland, New = Zealand
|>
|> --
|> Help        = mailto:majordomo@net.doit.wi= sc.edu and say
|"help" in message body
|> Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say "unsubscribe
|> ipfix" in message body
|> Archive     http://ipfix.doit.wisc.edu/archive/
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1BB25.07267730-- -- 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 Feb 21 17:38:36 2002 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 RAA06367 for ; Thu, 21 Feb 2002 17:38:36 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e1Y7-0007VO-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 16:18:47 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e1Y6-0007VB-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 16:18:46 -0600 Received: from peter ([204.253.100.102]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1LMIsl13004; Thu, 21 Feb 2002 14:18:54 -0800 From: "Peter Ludemann" To: , Cc: Subject: RE: [ipfix-arch] counter wrapping Date: Thu, 21 Feb 2002 14:17:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200202212141.KAA07738@mailhost.auckland.ac.nz> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit n.brownlee@auckland.ac.nz wrote Thursday, February 21, 2002 1:44 PM: To: reinaldo_penno@nortelnetworks.com > Of more interest, I don't remember seeing any IPFIX discussion > concerning just how information about long-running flows is to be > exported. In particular, I believe that counters should never be reset. > That would mean that successive exports of the same flow would have > increasing counter values, a collector would need to remember the > previous value and subtract it. Furthermore, provided unsigned > arithmetic is used, the difference is correct even if the counter has > wrapped. Provided, of course that the counter has only wrapped once! In our experience, it's better to output deltas. Absolute values are needed only if you have an unreliable data exporter. (In fact, we have some modules which turn absolute values (e.g., from SNMP) into deltas [taking into account wrapped counters of course].) The reason for delta values is that they make a much cleaner data model [each delta value has start/end timestamps, of course]. If I want to produce reports that show values with various intervals (5-minutes, hourly, daily, weekly), it's easy to write queries that sum things up this way. With absolute values, things are somewhat uglier. (SQL doesn't have unsigned arithmetic) But, as I said, deltas only work if you have a reliable flow exporter. Otherwise, you have no choice but to use absolute values and deal with the overflow issues, which can happen even with 64-bit counters. - peter ---- Peter Ludemann peter.ludemann@xacct.com Chief Architect +1.408.330.5732 XACCT Technologies, Inc. 2900 Lakeside Drive Santa Clara, CA 95054 USA -- 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 Feb 21 17:46:53 2002 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 RAA06467 for ; Thu, 21 Feb 2002 17:46:52 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e1iV-0007ls-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 16:29:31 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e1iT-0007l9-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 16:29:29 -0600 Received: from riverstonenet.com (134.141.180.106 [134.141.180.106]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY8DQ6; Thu, 21 Feb 2002 14:28:12 -0800 Message-ID: <3C75747A.B7177F1A@riverstonenet.com> Date: Thu, 21 Feb 2002 17:28:10 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Norseth, KC" CC: n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <59358A738F45D51186A30008C74CE250DA0720@slc-exc1.ctron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit "Norseth, KC" wrote: > > Although a DELTA counter helps, if the interval between checking the > flow causes a wrap (or 2 wraps), it can cause grief. This is an issue > when the hardware cannot handle the larger number. The ability to > send a flow record at any interval due to a counter rollover needs to > be a selection criteria. I don't have a problem with intermediate updates but I think your last statement is key "...due to a counter rollover". If we can select only those flows that are in danger of rollover we can help keep from overwhelming the exporter with the number of updates to be sent out. The flows moving at a slower pace can send updates in a more leisurely manner. > > K.C. > > |-----Original Message----- > |From: Calato, Paul > |Sent: Thursday, February 21, 2002 3:00 PM > |To: n.brownlee@auckland.ac.nz > |Cc: reinaldo_penno@nortelnetworks.com; ipfix-arch@net.doit.wisc.edu > |Subject: Re: [ipfix-arch] counter wrapping > | > | > |n.brownlee@auckland.ac.nz wrote: > |> > |> Hi Reinaldo: > |> > |> > b. avoid counter wrapping." > |> > > |> > This activity SHOULD be configurable. Btw, can someone > |elaborate on > |> > the counter wrapping stuff? > |> > > |> > It is very simple to send so much data though the line on a flow > |> > that the byte counter rolls over. This is very typical in > |1 gig and > |> > 10g ports. counter 32 is not large enough field size for this. > |> > > |> > yes, that's what I tought. So the solution is just to augment th > |> > efield to a 64 counter. It seems that the peirodic reporting is > |> > completely orthogonal to this specific issue. > | > | We need to be careful here. Some of us need to get counters > | directly from the hardware so just changing the size is > | not an option. Doing it in software can be an issue too > | because that means extra memory is needed for each flow. > | > |> > |> You've covered the 'counter wrapping' problem - a flow information > |> meter (whatever that turns out to be) needs counters wide enough > not > |> to wrap too often, and that becomes more of a problem at high link > |> speeds. > | > | Not only the link speed but the aggregation level too. > | The higher level aggregations tend to get more bytes/packets > | per second. > | > |> In RTFM, all counts are kept in 64-bit unsigned counters so > |that they > |> don't wrap too often. > |> > |> Of more interest, I don't remember seeing any IPFIX discussion > |> concerning just how information about long-running flows is to be > |> exported. In particular, I believe that counters should never be > |> reset. > | > | One more thing to keep in mind here is that most hardware > | does not provide a way to do an atomic get and set operation. > | So if you do reset it, you'll likely loose some information. > | > |> That would mean that successive exports of the same flow would have > > |> increasing counter values, > | > | The other way is the box keeps track of the last reported > | in counter in software and still provide deltas. The > |problem with > | cumulative counts is on failover the collector will not > | have the last count. I'd like to keep collector to collector > | requirements to a minimum or none if possible. > | > |> a collector would need to remember the > |> previous value and subtract it. Furthermore, provided unsigned > |> arithmetic is used, the difference is correct even if the > |counter has > |> wrapped. Provided, of course that the counter has only wrapped > once! > |> > |> Cheers, Nevil > |> > |> > |----------------------------------------------------------------------- > > |> Nevil Brownlee Director, Technology > Development > |> Phone: +64 9 373 7599 x8941 ITSS, The University of > Auckland > |> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New > Zealand > |> > |> -- > |> 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/ > | > |-- > |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/ > | -- 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 Feb 21 18:04:03 2002 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 SAA06959 for ; Thu, 21 Feb 2002 18:04:02 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e1zt-0000Lr-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 16:47:29 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e1zr-0000Lk-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 16:47:27 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id RAA15353; Thu, 21 Feb 2002 17:56:55 -0500 (EST) Received: from unknown(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma015347; Thu, 21 Feb 02 17:56:12 -0500 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id <1VYXTC3R>; Thu, 21 Feb 2002 17:45:30 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA0722@slc-exc1.ctron.com> From: "Norseth, KC" To: "Calato, Paul" Cc: "'ipfix-arch@net.doit.wisc.edu'" , "'n.brownlee@auckland.ac.nz'" Subject: RE: [ipfix-arch] counter wrapping Date: Thu, 21 Feb 2002 17:46:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB29.89410EC0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BB29.89410EC0 Content-Type: text/plain |-----Original Message----- |From: Calato, Paul |Sent: Thursday, February 21, 2002 3:28 PM |To: Norseth, KC |Cc: n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu |Subject: Re: [ipfix-arch] counter wrapping | | |"Norseth, KC" wrote: |> |> Although a DELTA counter helps, if the interval between checking the |> flow causes a wrap (or 2 wraps), it can cause grief. This |is an issue |> when the hardware cannot handle the larger number. The ability to |> send a flow record at any interval due to a counter rollover |needs to |> be a selection criteria. | | I don't have a problem with intermediate updates but | I think your last statement is key "...due to a counter |rollover". | If we can select only those flows that are in danger of | rollover we can help keep from overwhelming the exporter | with the number of updates to be sent out. The flows moving at | a slower pace can send updates in a more leisurely manner. Yes. K.C. |> |> K.C. |> |> |-----Original Message----- |> |From: Calato, Paul |> |Sent: Thursday, February 21, 2002 3:00 PM |> |To: n.brownlee@auckland.ac.nz |> |Cc: reinaldo_penno@nortelnetworks.com; ipfix-arch@net.doit.wisc.edu |> |Subject: Re: [ipfix-arch] counter wrapping |> | |> | |> |n.brownlee@auckland.ac.nz wrote: |> |> |> |> Hi Reinaldo: |> |> |> |> > b. avoid counter wrapping." |> |> > |> |> > This activity SHOULD be configurable. Btw, can someone |> |elaborate on |> |> > the counter wrapping stuff? |> |> > |> |> > It is very simple to send so much data though the line |on a flow |> |> > that the byte counter rolls over. This is very typical in |> |1 gig and |> |> > 10g ports. counter 32 is not large enough field size for this. |> |> > |> |> > yes, that's what I tought. So the solution is just to |augment th |> |> > efield to a 64 counter. It seems that the peirodic reporting is |> |> > completely orthogonal to this specific issue. |> | |> | We need to be careful here. Some of us need to get counters |> | directly from the hardware so just changing the size is |> | not an option. Doing it in software can be an issue too |> | because that means extra memory is needed for each flow. |> | |> |> |> |> You've covered the 'counter wrapping' problem - a flow |information |> |> meter (whatever that turns out to be) needs counters wide enough |> not |> |> to wrap too often, and that becomes more of a problem at |high link |> |> speeds. |> | |> | Not only the link speed but the aggregation level too. |> | The higher level aggregations tend to get more bytes/packets |> | per second. |> | |> |> In RTFM, all counts are kept in 64-bit unsigned counters so |> |that they |> |> don't wrap too often. |> |> |> |> Of more interest, I don't remember seeing any IPFIX discussion |> |> concerning just how information about long-running flows is to be |> |> exported. In particular, I believe that counters should never be |> |> reset. |> | |> | One more thing to keep in mind here is that most hardware |> | does not provide a way to do an atomic get and set operation. |> | So if you do reset it, you'll likely loose some information. |> | |> |> That would mean that successive exports of the same flow |would have |> |> |> increasing counter values, |> | |> | The other way is the box keeps track of the last reported |> | in counter in software and still provide deltas. The problem |> |with |> | cumulative counts is on failover the collector will not |> | have the last count. I'd like to keep collector to collector |> | requirements to a minimum or none if possible. |> | |> |> a collector would need to remember the |> |> previous value and subtract it. Furthermore, provided unsigned |> |> arithmetic is used, the difference is correct even if the |> |counter has |> |> wrapped. Provided, of course that the counter has only wrapped |> once! |> |> |> |> Cheers, Nevil |> |> |> |> |> ||--------------------------------------------------------------------- |> |-- |> |> |> Nevil Brownlee Director, Technology |> Development |> |> Phone: +64 9 373 7599 x8941 ITSS, The University of |> Auckland |> |> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New |> Zealand |> |> |> |> -- |> |> 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/ |> | |> |-- |> |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/ |> | | ------_=_NextPart_001_01C1BB29.89410EC0 Content-Type: text/html RE: [ipfix-arch] counter wrapping

|-----Original Message-----
|From: Calato, Paul
|Sent: Thursday, February 21, 2002 3:28 PM
|To: Norseth, KC
|Cc: n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu
|Subject: Re: [ipfix-arch] counter wrapping
|
|
|"Norseth, KC" wrote:
|>
|> Although a DELTA counter helps, if the interval between checking the
|> flow causes a wrap (or 2 wraps), it can cause grief.  This
|is an issue
|> when the hardware cannot handle the larger number.  The ability to
|> send a flow record at any interval due to a counter rollover
|needs to
|> be a selection criteria.
|
|       I don't have a problem with intermediate updates but
|       I think your last statement is key "...due to a counter
|rollover".
|       If we can select only those flows that are in danger of
|       rollover we can help keep from overwhelming the exporter
|       with the number of updates to be sent out. The flows moving at
|       a slower pace can send updates in a more leisurely manner.

Yes.

K.C.

|>
|> K.C.
|>
|> |-----Original Message-----
|> |From: Calato, Paul
|> |Sent: Thursday, February 21, 2002 3:00 PM
|> |To: n.brownlee@auckland.ac.nz
|> |Cc: reinaldo_penno@nortelnetworks.com; ipfix-arch@net.doit.wisc.edu
|> |Subject: Re: [ipfix-arch] counter wrapping
|> |
|> |
|> |n.brownlee@auckland.ac.nz wrote:
|> |>
|> |> Hi Reinaldo:
|> |>
|> |> > b. avoid counter wrapping."
|> |> >
|> |> > This activity SHOULD be configurable. Btw, can someone
|> |elaborate on
|> |> > the counter wrapping stuff?
|> |> >
|> |> > It is very simple to send so much data though the line
|on a flow
|> |> > that the byte counter rolls over.  This is very typical in
|> |1 gig and
|> |> > 10g  ports. counter 32 is not large enough field size for this.
|> |> >
|> |> > yes, that's what I tought. So the solution is just to
|augment th
|> |> > efield to a 64 counter. It seems that the peirodic reporting is
|> |> > completely orthogonal to this specific issue.
|> |
|> |       We need to be careful here. Some of us need to get counters
|> |       directly from the hardware so just changing the size is
|> |       not an option. Doing it in software can be an issue too
|> |       because that means extra memory is needed for each flow.
|> |
|> |>
|> |> You've covered the 'counter wrapping' problem - a flow
|information
|> |> meter (whatever that turns out to be) needs counters wide enough
|> not
|> |> to wrap too often, and that becomes more of a problem at
|high link
|> |> speeds.
|> |
|> |       Not only the link speed but the aggregation level too.
|> |       The higher level aggregations tend to get more bytes/packets
|> |       per second.
|> |
|> |> In RTFM, all counts are kept in 64-bit unsigned counters so
|> |that they
|> |> don't wrap too often.
|> |>
|> |> Of more interest, I don't remember seeing any IPFIX discussion
|> |> concerning just how information about long-running flows is to be
|> |> exported.  In particular, I believe that counters should never be
|> |> reset.
|> |
|> |       One more thing to keep in mind here is that most hardware
|> |       does not provide a way to do an atomic get and set operation.
|> |       So if you do reset it, you'll likely loose some information.
|> |
|> |> That would mean that successive exports of the same flow
|would have
|>
|> |> increasing counter values,
|> |
|> |       The other way is the box keeps track of the last reported
|> |       in counter in software and still provide deltas. The problem
|> |with
|> |       cumulative counts is on failover the collector will not
|> |       have the last count. I'd like to keep collector to collector
|> |       requirements to a minimum or none if possible.
|> |
|> |> a collector would need to remember the
|> |> previous value and subtract it.  Furthermore, provided unsigned
|> |> arithmetic is used, the difference is correct even if the
|> |counter has
|> |> wrapped.  Provided, of course that the counter has only wrapped
|> once!
|> |>
|> |> Cheers, Nevil
|> |>
|> |>
|>
||---------------------------------------------------------------------
|> |--
|>
|> |>    Nevil Brownlee                   Director, Technology
|> Development
|> |>    Phone: +64 9 373 7599 x8941      ITSS, The University of
|> Auckland
|> |>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New
|> Zealand
|> |>
|> |> --
|> |> 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/
|> |
|> |--
|> |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/
|> |
|

------_=_NextPart_001_01C1BB29.89410EC0-- -- 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 Feb 21 18:33:07 2002 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 SAA07307 for ; Thu, 21 Feb 2002 18:33:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e2QX-0000ze-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 17:15:01 -0600 Received: from mailhub.lawrence.edu ([143.44.65.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e2QU-0000zC-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 17:14:59 -0600 Received: from lawrence.edu ([143.44.97.41]) by lawrence.edu (PMDF V6.0-025 #44893) with ESMTP id <0GRW003G3P5YLD@lawrence.edu> for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 17:27:35 -0600 (CST) Date: Thu, 21 Feb 2002 17:14:57 -0600 From: Robert Lowe Subject: Re: [ipfix-arch] applicability document To: Tanja Zseby Cc: "K.C. Norseth" , reinaldo_penno@nortelnetworks.com, IPFIX Architecture Message-id: <3C757F71.8E3FFE17@lawrence.edu> Organization: Lawrence University MIME-version: 1.0 X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3C753EC1.4010603@fokus.fhg.de> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Tanja Zseby wrote: Hi Tanja! See inline comments... Mostly English stuff -- somewhere where I can rise slightly above useless in this whole process. :-) -Robert P.S. I ran out of time to go through everything now... I'll try to add more comments later, beginning with section 4.1.1 > Hi K.C. and Reinaldo, > > attached you can find the first version of the applicability document as > text file. > > It includes the sections 8 and 10 from Reinaldo and me from the > architecture draft. I also included the intrusion detection part > (section 8.1) Who contributed this to the architecture ? > > Regards > Tanja > > -- > Dipl.-Ing. Tanja Zseby > FhI FOKUS/Global Networking Email: zseby@fokus.fhg.de > Kaiserin-Augusta-Allee 31 Phone: +49-30-3463-7153 > D-10589 Berlin, Germany Fax: +49-30-3463-8153 > -------------------------------------------------------------------------------------- > "Living on earth is expensive but it includes a free trip around the sun." (Anonymous) > -------------------------------------------------------------------------------------- > > ------------------------------------------------------------------------------------------ > Internet Draft T.Zseby > draft-zseby-ipfix-applicability-00.txt FhI FOKUS > Expires: August 2002 R. Penno > VERSION DATE February 21, 2002 Nortel Networks > February 2002 > > IPFIX Applicability > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026 [1]. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. Internet-Drafts are draft documents valid for a maximum of > six months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet- Drafts > as reference material or to cite them other than as "work in > progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > Abstract > > This document describes how various applications can use the IP > Flow Information Export (IPFIX) protocol. It furthermore shows how > the IPFIX framework relates to other architectures and frameworks. > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC-2119 [ ]. > > 1. INTRODUCTION 2 > 2. TERMINOLOGY 3 > 3. APPLICATIONS OF IPFIX 3 > 3.1. ACCOUNTING WITH IPFIX 3 > 3.2. TRAFFIC PROFILING WITH IPFIX 3 > 3.3. TRAFFIC ENGINEERING WITH IPFIX 3 > 3.4. INTRUSION DETECTION WITH IPFIX 3 > 3.5. QOS MONITORING WITH IPFIX 3 > 3.5.1. Measurement of Round-trip-time (RTT) with IPFIX 4 > 3.5.2. Measurement of One-way-delay (OWD) with IPFIX 4 > 3.5.3. Measurement of Loss with IPFIX 5 > 3.5.4. Measurement of delay variation with IPFIX 5 > 3.5.5. Sampling for QoS Monitoring 5 > 3.6. DEPLOYMENT OF SAMPLING METHODS IN IPFIX 5 > 4. RELATION OF IPFIX TO OTHER FRAMEWORKS AND PROTOCOLS 5 > 4.1. IPFIX AND AAA 6 > 4.1.1. Connecting via an AAA client 7 > 4.1.2. Connecting via an Application Specific Module (ASM) 7 > 4.2. IPFIX AND RTFM 8 > 4.3. IPFIX CONSIDERATIONS FOR MIDDLEBOXES 8 > 4.3.1. Firewall 8 > 4.3.2. Network Address Translation 9 > 4.3.3. Traffic Conditioners 11 > 4.3.4. Tunneling 12 > 4.3.5. VPNs 12 > 4.4. IPFIX AND RMON 14 > 4.5. IPFIX AND IPPM 14 > 4.6. IPFIX AND PSAMP 14 > 5. SECURITY CONSIDERATION 15 > 6. REFERENCES 15 > 7. ACKNOWLEDGEMENTS 16 > 8. AUTHOR'S ADDRESSES 16 > 9. FULL COPYRIGHT STATEMENT 17 > > 1. Introduction > > The IPFIX protocol defines how IP Flow information can be exported. > It is intended to provide input for various applications. This > document describes how applications can use the IPFIX protocol. > Furthermore the relations of IPFIX to other frameworks and , ^^^^^^^^^ relationship > architectures are described. > > 2. Terminology > [maybe needed ] > > 3. Applications of IPFIX > > 3.1. Accounting with IPFIX > [TODO for Tanja] > > 3.2. Traffic Profiling with IPFIX > > [TODO] > > 3.3. Traffic Engineering with IPFIX > > [TODO] > > 3.4. Intrusion detection with IPFIX > [TODO for Reinaldo ?] > > Intrusion Detection System (IDS) monitors and controls the security ^^ ^^^ insert 'An' or modify the subject/verbs drop 'the' > incidents [4]. Typical IDS system includes components like Data ^^^^^^^ A typical... > source, Sensor, Analyzer and Management stations [4]. A Sensor I don't know what common practice is in these documents, but unless it is accompanied by an acronym, I would change these nouns to lowercase (and any others throughout). > monitors the data source and raises the alarm to the Analyzer. The ^^^ an > analyzer collects various incident information and reports this to > the management station. > > With IPFIX, the event of interest can be exported either from > collector or from exporter. For smooth integration, it will be better I'd change this to... "from either the collector or the exporter." > for the IDS system to integrate with the collector since the , One of the editors can improve the "flow" by not using integration and integrate in the same sentence. ;-) > collector has all the aggregated information from different > observation points. The IDS can request the collector to monitor the > events or IP flow through an IPFIX template. > > [Who contributed this text to the architecture doc ?] > > 3.5. QoS Monitoring with IPFIX > > The performance of QoS monitoring is one target application for using > the IPFIX protocol. This whole section is about "target applications", so I would drop this sentence altogether. > QoS monitoring is the passive observation of the ^^^ (unnecessary) > transmission quality for single flows or traffic aggregates in the > network. It is needed for instance for the validation of QoS One example of its usefulness is for the validation... > guarantees in service level agreements. Some QoS metrics require the > correlation of data from multiple measurement points. For this the this=accurate correlation? > clock of the involved exporting devices need to be synchronized. (the clock) needs > Furthermore such measurements would benefit from post-processing , > functions (e.g. packet ID generation) at the exporter and/or > collector. This section describes how the monitoring of different > metrics can be performed with IPFIX. The following metrics are > considered: round trip time, one-way-delay, loss and delay variation. > > 3.5.1.Measurement of Round-trip-time (RTT) with IPFIX > > The passive measurement of round-trip-times (RTT) can be performed by > using packet pair matching techniques as described in [Brow00]. For > the measurements, request/response packet pairs from protocols like > DNS, ICMP,SNMP or TCP (syn/syn-ack, data/ack) are utilized to ^ (insert space) > passively observe the RTT. As always for passive measurements this , > only works if the required traffic of interest is actually present in > the network. In order to use this measurement technique, the IPFIX > meter needs to measure both directions. A classification of the (I second Carter -- meter should be clarified) > protocols mentioned above has to be done. That means parts of the Parts of... > transport header are used for the classification. Since a > differentiation of flows in accordance to the transport header is one ^^ (with?) > of the requirements for IPFIX, such classification can be performed > without extensions. Nevertheless, the meter needs to recognize > request and response packets for the given protocols and therefore > needs to look further into the packet. IMHO, "therefore needs to" is unnecessary. The final "packet" needs to be plural, correct? Otherwise, specifically mention one of the packets (request or response). > This is not required for IPFIX "This" is ambiguous. Do you mean measurement of the RTT is not a required component of any given IPFIX implementation? > but can be achieved by optional extensions to the classification > process. The exporting device needs to assign a timestamp for the > arrival of the packets. The calculation of the RTT can be done > directly at the exporter or at the collector. In the first case IPFIX , > would transfer the calculated RTT to the collector. In the second > case IPFIX needs to send the observed packet types and the timestamps > to the collector. > > 3.5.2.Measurement of One-way-delay (OWD) with IPFIX > > Passive one-way-delay measurements require the collection of data at > two measurement points. It is required to recognize packets at the ^^^^^^^^ necessary > second measurement point in order to correlate packet arrival events ^^^^^^^^^^^ to > from both points. This can be done for instance by capturing packet ^^^^^^^^^^^^ unnecessary -- implied by "can be". > headers and parts of the packet and recognize packets based on this. 1 2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1. Should agree with packet headers -- both singular, or both plural. E.g., This can be done by capturing the packet header and parts of the packet... 2. ...that can be used to recognize the same packet at the subsequent measurement point. > In order to reduce the amount of measurement data a unique packet ID ^^^^^^^^ (unnecessary) , > can be calculated from the header and part of the content e.g. by > using a CRC or hash function [GrDM98, DuGr00, ZsZC01].Since IPFIX is ^ (insert space) > not targeted at packet capturing these functionalities do not need to > be supported by a standard IPFIX meter. Nevertheless, in some > scenarios it might be sufficient to calculate a packet ID under > consideration of header fields including datagram ID and maybe > sequence numbers (from transport protocols) without looking at parts > of the packet content. Especially if packet IDs need to be unique ^^^^^^^^^^ (delete) > only for a certain time interval or a certain amount of packet ID > collisions is tolerable this can be a solution. , > > 3.5.3.Measurement of Loss with IPFIX > > Passive loss measurements for single flows can be performed at one > measurement point for instance by using sequence numbers that are ^^^^^^^^^^^^ (delete) > present in higher layer protocols. This requires the capturing of the > sequence numbers of subsequent packets of the observed flow at the ^^ (in?) > IPFIX meter. An alternative to this is to perform a two-point > measurement as described above and just consider packets as lost that > do not arrive at the second measurement point in a given maximum time > frame. > > 3.5.4.Measurement of delay variation with IPFIX > > Delay variation is defined as the difference of one-way-delay values > for selected packets.[DeCi01]. Therefore this metric can be > calculated by performing passive measurement of one-way-delay for > subsequent packets (e.g. of a flow) and then calculate the ^^^^^^^^^^^^^^ calculating > differences. > > 3.5.5.Sampling for QoS Monitoring > > Since QoS monitoring can lead to an overwhelming amount of ^^^^^^^ produce > measurement result data, it would highly benefit from the deployment ^^1^^^ ^^^^^^^^^2^^^^^^... 1. delete this word 2. ...methods such as aggregation of results, and sampling would greatly increase the efficiency of the collection and analysis process. > of mechanisms to reduce the measurement data, like aggregation of > results and sampling. Sampling methods can be grouped according to > the sampling strategy (systematic, random or stratified) and the > trigger that starts a sampling interval (count-based, time-based or > packet-content-based) [ClPB93]. Sampling can also be used as a method > to dynamically reduce resource consumption if the meter is > overloaded. > Then the IPFIX meter can switch to a sampling method if > too many packets have to be observed. Given the bursty nature of IP traffic, is this an appropriate strategy??? We had a similar discussion relating to fall-back strategies when an exporter is under heavy load and came to the conclusion that this was not worth pursuing. > Since the expected estimation > error depends heavily on the used sampling strategy, the application ^^^^ ^ (delete) in use OR... deployed sampling strategy > that receives the data needs to be aware of the sampling scheme and > the used parameters. Therefore it is important that the IPFIX ^^^^ (delete) ^in use > exporter informs the collector precisely about the used sampling > strategy. Eliminate this sentence... implied from the previous? At the very least, re-word it! > This is even more required if the IPFIX meter dynamically ^^^^^^^^^^^^^^^^^^ No "Versteigerung" possible. Required is like "dead" -- if you are, you can't become more dead. :) > invokes sampling. ^^^^^^^ or adjusts? > 3.6. Deployment of Sampling Methods in IPFIX > > [TODO for Tanja] > > [other applications ?] > > 4. Relation of IPFIX to other frameworks and protocols > > 4.1. IPFIX and AAA > > AAA defines a protocol and architecture for authentication, > authorization and accounting for service usage. The DIAMETER protocol > is used for AAA communication for network access services (Mobile IP, > NASREQ, and ROAMOPS). The AAA architecture [XXX-RFC2903] provides a > framework for extending the AAA support also for other services. ^^^^^^^^ to > DIAMETER defines the exchange of messages between AAA entities, e.g. > between AAA clients at access devices and AAA servers and among AAA > servers. It is used also for the transfers of accounting records. For ^ (singular) > usage-based accounting measurement data from the network is needed to > generate an accounting record. Don't understand this sentence... for (something to happen), (something else) is needed. > IPFIX provides a protocol to export > measurement data from the measurement point to the consumer of this > data (like network management and accounting systems). The > provisioning of accounting with IPFIX can be realized without an AAA > infrastructure. The collector can directly forward the measurement > information to an accounting application. Nevertheless, if an AAA > infrastructure is in place, IPFIX can provide the input for the > generation of accounting records and several features of the AAA , > architecture can be used. Features include the mapping of a user ID > to the flow information (by using authentication information), the > generation of DIAMETER accounting records and the secure exchange of > accounting records between domains with DIAMETER. Three possibilities > to connect IPFIX and AAA can be distinguished: > > 4.1.1.Connecting via an AAA client > > One possibility to connect IPFIX and AAA is to run an AAA client on > the IPFIX collector. This client can generate DIAMETER accounting > messages and send them to an AAA server. The mapping of the flow > information to a user ID can be done in the AAA server by using > data from the authentication process. DIAMETER accounting messages > can be sent to the accounting application or to other AAA servers > (e.g. in roaming scenarios). > > +---------+ DIAMETER +---------+ > | AAA-S |------------->| AAA-S | > +---------+ +---------+ > ^ > | DIAMETER > | > | > +--+--------+--+ > | | AAA-C | | > + +--------+ | > | | > | Collector | > +--------------+ > ^ > | IPFIX > | > +------------+ > | Exporter | > +------------+ > > Figure 2: IPFIX collector connects to AAA server via AAA client > > 4.1.2. Connecting via an Application Specific Module (ASM) > > Another possibility is to directly connect the IPFIX collector with > the AAA server via an application specific module (ASM). > Application specific modules have been proposed by the IRTF AAA > architecture research group (AAARCH) in [RFC2903]. They act as an > interface between AAA server and service equipment. In this case > the IPFIX collector is part of the ASM. The ASM acts as an > interface between the IPFIX protocol and the input interface of the > AAA server. The ASM translates the received IPFIX data into an > appropriate format for the AAA server. The AAA server then can add > information about the user ID and generate a DIAMETER accounting > record. This accounting record can be sent to an accounting > application or to other AAA serves. > > +---------+ DIAMETER +---------+ > | AAA-S |------------->| AAA-S | > +---------+ +---------+ > ^ > | > +------------------+ > | ASM | > | +------------+ | > | | Collector | | > +------------------+ > ^ > | IPFIX > | > +------------+ > | Exporter | > +------------+ > > Figure 3: IPFIX connects to AAA server via ASM > > 4.2. IPFIX and RTFM > [TODO for Tanja] > > 4.3. IPFIX Considerations for Middleboxes > > A Middlebox is a network intermediate device that implements one or > more of the middlebox services. Policy based packet filtering (a.k.a. > firewall), Network address translation (NAT), Intrusion detection, > Load balancing, Policy based tunneling and IPsec security are all > examples of a middlebox function (or service). [MCFW]. For instance, > a NAT middlebox is a middlebox implementing NAT service and a > firewall middlebox is a middlebox implementing firewall service. > > It is expected that the exporter in the IPFIX architecture will > probably implement some form of middlebox service given its ubiquity > today. Since some of these middlebox services might affect flow > exportation and how the collector interprets them, there is a need to > provide an analysis of these implications in relation to the IPFIX > architecture and a set of recommendations. > > The following sections provide a non-exhaustive analysis of middlebox > services, its implications on the IPFIX architecture and a > corresponding set of recommendations. > > 4.3.1. Firewall > > Firewall is a policy based packet filtering middlebox function, > typically used for restricting access to/from specific devices and > applications. The policies are often termed Access Control Lists > (ACLs)[MCFW]. > > The firewall middlebox service allows the exporter to explicitly drop > packets based on some administrative policy. In this case, the > exporter can take one of the following actions that will have a > direct impact on the information provided by the collector to the > user. > > * Silently Discard > > In this case the packet is discarded and no flow information record > is sent to the collector. > > * Discard and export flow > > In this case the packet is discarded, and the flow information record > is sent to the collector. > > * Discard and export flow with discard notification > > In this case the packet is discarded, and the flow information record > is sent to the collector with an indication that the packet was > discarded. > > 4.3.2. Network Address Translation > > Network Address Translation is a method by which IP addresses are > mapped from one address realm to another, providing transparent > routing to end hosts. Transparent routing here refers to modifying > end-node addresses en-route and maintaining state for these updates > so that when a datagram leaves one realm and enters another, > datagrams pertaining to a session are forwarded to the right end-host > in either realm [NAT-TERM]. > > From an exporter (middlebox) perspective, a NAT is composed of two > flows, one from the client to the NAT middlebox and another from the > NAT middlebox to the destination. Based on this fact, the exporter > has several modes of operation, i.e., it can export the private realm > flow, the public realm, or both. This is further constrained by the > flavor of NAT implemented, meaning that in order for the exported > information to be useful for the collector, sometimes the associated > flows on the two realms need to be exported in the same flow record. > > Although there are many flavors of address translation that lend > themselves to different applications, this section will only address > the IPFIX architecture implications of traditional NAT, bi- > directional NAT and twice NAT. > > 4.3.2.1. Traditional NAT > > Traditional NAT would allow hosts within a private network to > transparently access hosts in the external network, in most cases. In > a traditional NAT, sessions are unidirectional, outbound from the > private network. This is in contrast with bi-directional NAT, which > permits sessions in both inbound and outbound directions. A detailed > description of traditional NAT may be found in section [NAT-TERM]. > > If the exporter is providing traditional NAT service and only the > private realm flow is exported, only destination based information > can be inferred from the collector. The reason for this is twofold. > First, the collector will not be able to find the reverse flow (when > applicable) associated with a private realm flow record, and second > is that in the more general scenario the collector can be connected > to several exporters providing NAT service and there might be > overlapping private realm addresses between the networks connected to > these exporters. > > In a traditional NAT scenario the exporter SHOULD export private and > public realm information in the same flow record or provide the > collector with a unique key to associate the two if exported on > different flow records. > > 4.3.2.2. Bi-Directional NAT > > With a bi-directional NAT, sessions can be initiated from hosts in > the public network as well as the private network. Private network > addresses are bound to globally unique addresses, statically or > dynamically as connections are established in either direction. > Detailed description of Bi-Directional may be found in section [NAT- > TERM]. > > 4.3.2.3. Twice NAT > > Twice NAT is a variation of NAT in that both the source and > destination addresses are modified by NAT as a datagram crosses > address realms. This is in contrast to Traditional-NAT and Bi- > Directional NAT, where only one of the addresses (either source or > destination) is translated. Note, there is no such term as 'Once- > NAT'. Detailed description of Bi-Directional may be found in section > [NAT-TERM]. > > In the case of twice NAT the exporter MUST export private and public > realm information in the same flow record or provide the collector > with a unique key to associate the two if exported on different flow > records. > > 4.3.3. Traffic Conditioners > A traffic conditioner may contain the following elements: meter, > marker, shaper, and dropper. A traffic stream is selected by a > classifier, which steers the packets to a logical instance of a > traffic conditioner[DIFF-ARCH]. > > From an IPFIX architecture perspective we are going to address > marking, shaping and dropping services. > > 4.3.3.1. Marking > Diffserv packet markers set the DS field of a packet to a particular > codepoint, adding the marked packet to a particular DS behavior > aggregate. The marker may be configured to mark all packets which > are steered to it to a single codepoint, or may be configured to mark > a packet to one of a set of codepoints used to select a PHB in a PHB > group, according to the state of a meter. When the marker changes > the codepoint in a packet it is said to have "re-marked" the packet > [DIFF-ARCH]. > > From and IPFIX architecture perspective, the exporter can take one of > the following actions when it needs to remark a packet. > > * Unmarked flow > > The exporter can export the flow before it was remarked. This mode of > operation is strongly discouraged. > > * Remarked flow > > The exporter can export the flow after it was remarked. > > * Unmarked and remarked flow. > > The exporter can export the flow before and after it was remarked or > export the flow before it was remarked and an indication of what was > the DSCP after it was remarked. > > 4.3.3.2. Shapers > > Shapers delay some or all of the packets in a traffic stream in Order > to bring the stream into compliance with a traffic profile. A shaper > usually has a finite-size buffer, and packets may be discarded if > there is not sufficient buffer space to hold the delayed packets. > > For an IPFIX perspective, since the discard of a packet by a shaper > is not voluntary, no indication should be sent to the collector. > > 4.3.3.3. Droppers > > Droppers discard some or all of the packets in a traffic stream in > order to bring the stream into compliance with a traffic profile. > This process is known as "policing" the stream. Note that a dropper > can be implemented as a special case of a shaper by setting the > shaper buffer size to zero (or a few) packets. > > In a manner analogous to the middlebox firewall service, middlebox > policing services also allow the exporter to explicitly drop packets > based on some administrative policy. > > The three possible export behaviors described for the firewall > service when a packet needs to be dropped are also applicable to > here, i.e., silent discard, discard and export flow, discard and > export flow with discard notification. > > 4.3.4. Tunneling > > The exporter can export the flows before and/or after they get > tunneled. In the later case the encapsulated flow information might > not be available due to confidentiality precautions such as those > used by IPsec, or due to the fact the exporter lacks the necessary > intelligence to inspect the encapsulated packet. Moreover, depending > on where in the network the exporter is located, it might only be > able to export flows associated with the tunnel, without visibility > into the encapsulated packet. > > Apart from what was said above, it should also be factor in the fact > that flows exported before they get tunneled, will provide > information about the private network sites, but not necessarily > about the backbone, since the route taken by the packet it's now know > at that point in time (and vice-versa). > > Tunnel terminates on exporter > > Tunnel initiates on exporter > > Exporter implements tunnel switching > > 4.3.5. VPNs > > The term "Virtual Private Network" (VPN) refers to the communication > between a set of sites, making use of a shared network > infrastructure. Multiple sites of a private network may therefore > communicate via the public infrastructure, in order to facilitate the > operation of the private network. The logical structure of the VPN, > such as addressing, topology, connectivity, reachability, and access > control, is equivalent to part of or all of a conventional private > network using private facilities [RFC2764] [VPN-2547BIS]. > > There are multiple flavors of VPNs, the one with more relevance to > the IPFIX architecture is the PE-based-VPN. A PE-based VPN (or > Provider Edge-based Virtual Private Network) is one in which PE > devices in the SP network provide the VPN. This allows the existence > of the VPN to be hidden from the CE devices, which can operate as if > part of a normal customer network. A detailed discussion of VPNs can > be found in [PPVPN-FR]. > > 4.3.5.1. Layer 3 PE-based VPN > > A layer 3 PE-based VPN is one in which the SP takes part in IP level > forwarding based on the customer network's IP address space. In > general, the customer network is likely to make use of private and/or > non-unique IP addresses. This implies that at least some devices in > the provider network needs to understand the IP address space as used > in the customer network. Typically this knowledge is limited to the > PE device [PPVPN-FR] which is directly attached to the customer. > > In a layer 3 PE-based VPN the provider will need to participate in > some aspects of management and provisioning of the VPNs, such as > ensuring that the PE devices are configured to support the correct > VPNs. This implies that layer 3 PE-based VPNs are by definition > provider provisioned VPNs [PPVPN-FR]. > > In order to connect the different VPN sites belonging to the same VPN > the SP uses a tunneling technique such as MPLS, L2TP or IPsec. These > tunnels originate and terminate on PE devices. > > One of the characteristics of a layer 3 PE-based VPNs is that they > offload some aspects of VPN management from the customer network. > From an IPFIX architecture perspective, this means that the SP is the > one that potentially will be providing the IPFIX service for the VPNs > that it provides connectivity. > > The exporter in Layer 3 PE-based VPN can be located on the customer's > network, on the SP's backbone (P Router) or on the edge (PE router). > The premise of this discussion is that the exporter is the one > providing middlebox services, so in the case of VPNs we assume that > the exporter is located in a PE device. > > 4.3.5.1.1. Tunneling > > [TODO for Reinaldo ?] > > 4.3.5.1.2. Overlapping Address Realms > > In the case the exporter plays the role of a PE router [VPN-2547BIS] > in a provider provisioned VPN scenario and has VPNs with overlapping > private address realms, it can only provide useful non-conflicting > information to the provider for intra-VPN traffic if it uses a > technique that allows the collector to uniquely identify to which VPN > the flow belongs. > > Several techniques could be used to accomplish this goal. One of > these techniques is to include the VPN Global unique identifier [VPN- > ID] as one of the keys in the flow record. > > In the case the exporter supports VPNs with overlapping private > address realms, it MUST include the VPN-ID [VPN-ID] in the exported > flow record. > > 4.3.5.2. Layer 2 PE-based VPN [TBD] > > A layer 2 PE-based VPN is one in which the network is aware of the > VPN, but does only layer 2 forwarding and signaling. This implies > that the SP provisions and maintains layer 2 connectivity between CE > devices [VPN-L2]. > > Forwarding options include MAC addresses (such as LAN emulation), use > of point-to-point link layer connections (FR or ATM), multipoint-to- > point (using MPLS multipoint to point LSPs), and point-to-multipoint > (e.g., ATM VCCs). > > For a layer 2 PE-based VPN, the PE device may be a router, LSR, or IP > switch. From the CE's perspective, the PE will be operating as a > switch. > > 4.4. IPFIX and RMON > [TODO] > > 4.5. IPFIX and IPPM > > [TODO for Tanja] > > 4.6. IPFIX and PSAMP > > [TODO for Tanja ?] > > > [further relations ?] > > 5. Security Consideration > > [TODO] > > 6. References > > [QuZC02] J. Quittek ,et. Al "Requirements for IP Flow Information > Export ", (work in progress) ,Internet Draft, Internet Engineering > Task Force, , February 2002 > > [Wood02]M. Wood ,et al.," Intrusion Detection Message Exchange > Requirements",(work in progress), Internet Draft, Internet > Engineering Task Force, draft-ietf-idwg-requirements-06,February > 2002. > > [Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of > Internet Traffic Engineering", (work in progress), Internet Draft, > Internet Engineering Task Force, draft-ietf-tewg-principles-02.txt, > May 2002 > > [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions, > http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47- > adelaide/pp-dist/ > > [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric > for IPPM, , November 2001 > > [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss > Metric for IPPM, September 1999 > > [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: > Application of Sampling Methodologies to Network Traffic > Characterization, Proceedings of ACM SIGCOMM'93, > San Francisco, CA, USA, September 13 - 17, 1993 > > [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed > MARTENS, John G. CLEARY: > Nonintrusive and Accurate Measurement of Unidirectional Delay and > Delay Variation on the Internet, INET'98, Geneva, Switzerland, > 21-24 July, 1998 > > [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling > for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, > Stockholm, Sweden, August 28 - September 1, 2000. > > [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay > Metric for IPPM, Request for Comments: 2679, September 1999 > > [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation > of Building Blocks > for Passive One-way-delay Measurements, Proceedings of Passive and > Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, > April 23-24, 2001 > > [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture > and framework," work in progress. October 2001. > > [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address > Translator (NAT) Terminology and Considerations", RFC 2663, August > 1999. > > [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network > Address Translator (Traditional NAT)", RFC 3022, January 2001. > > [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider > Provisioned Virtual Private Networks ", work in progress, ietf-ppvpn-framework-03.txt>, January 2002. > > [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft > , July 2001. > > [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and > W. Weiss, "An Architecture for Differentiated Services", RFC 2475, > December 1998. > > 7. Acknowledgements > > 8. Author's Addresses > > Reinaldo Penno > Nortel Networks, Inc. > 2305 Mission College Boulevard > Building SC9-B1240 > Santa Clara, CA 95134 > Email: rpenno@nortelnetworks.com > > Tanja Zseby > Fraunhofer Institute for Open Communication Systems(FOKUS) > Kaiserin-Augusta-Allee 31 > 10589 Berlin > Germany > Phone: +49 30 3463 7153 > Email: zseby@fokus.fhg.de > > 9. Full Copyright Statement > > "Copyright (C) The Internet Society (date). All Rights Reserved. > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain > it or assist in its implementation may be prepared, copied, > published and distributed, in whole or in part, without restriction > of any kind, provided that the above copyright notice and this > paragraph are included on all such copies and derivative works. > However, this document itself may not be modified in any way, such > as by removing the copyright notice or references to the Internet > Society or other Internet organizations, except as needed for the > purpose of developing Internet standards in which case the > procedures for copyrights defined in the Internet Standards process > must be followed, or as required to translate it into. -- 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 Feb 21 21:57:00 2002 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 VAA10646 for ; Thu, 21 Feb 2002 21:57:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e5Zi-0004yD-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 20:36:42 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e5Zg-0004y5-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 20:36:40 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1M2a7E01032 for ; Thu, 21 Feb 2002 18:36:08 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABG58398; Thu, 21 Feb 2002 18:36:30 -0800 (PST) Message-ID: <3C75AE96.92F6098A@cisco.com> Date: Thu, 21 Feb 2002 18:36:07 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Qs on DoS sections Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, Some questions DoS sections: 7.3.1. Network under attack The Network itself may be under attack, resulting in an overwhelming number of IPFIX messages. The IPFIX SHOULD try to capture as much information as possible. However, when large amount IPFIX messages are generated in a short period of time, the IPFIX may become overloaded. The IPFIX system MUST provide enough performance assurance so that the system can still function under heavy load. Possible solutions include flow control and message thresholding. Q: What has "enough performance assurance" got to do with "flow control and message thresholding"? I guess it should be that "IPFIX system should be able to detect and react quickly to an overload condition". For something which cannot be clearly quantified, "MUST" seems to be too harsh. 7.3.2. Generic DoS attack on the IPFIX system The IPFIX system may subject to generic DoS attacks, just as any system on any open networks. These types of attacks are not IPFIX specific. Preventing and responding to such types of attacks are out of the scope of IPFIX WG. Q: Is this not a special case of 7.3.1? Thanks Ganesh -- 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 Feb 21 21:57:43 2002 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 VAA10658 for ; Thu, 21 Feb 2002 21:57:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16e5e3-00053s-00 for ipfix-list@mil.doit.wisc.edu; Thu, 21 Feb 2002 20:41:11 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16e5e1-00051x-00 for ipfix-arch@net.doit.wisc.edu; Thu, 21 Feb 2002 20:41:09 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1M2eYE03308; Thu, 21 Feb 2002 18:40:36 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABG58505; Thu, 21 Feb 2002 18:40:56 -0800 (PST) Message-ID: <3C75AFA0.AE153DE3@cisco.com> Date: Thu, 21 Feb 2002 18:40:33 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: n.brownlee@auckland.ac.nz, reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <200202212141.KAA07738@mailhost.auckland.ac.nz> <3C756DC2.5B77F391@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit As a policy: Export flow records when counters go past a threshold. Keep IEs for * Absolute counts * Delta counts whichever would suit the appropriate implementation. my $.02 Ganesh calato@riverstonenet.com wrote: > n.brownlee@auckland.ac.nz wrote: > > > > Hi Reinaldo: > > > > > b. avoid counter wrapping." > > > > > > This activity SHOULD be configurable. Btw, can someone elaborate on the > > > counter wrapping stuff? > > > > > > It is very simple to send so much data though the line on a flow that the > > > byte counter rolls over. This is very typical in 1 gig and 10g ports. > > > counter 32 is not large enough field size for this. > > > > > > yes, that's what I tought. So the solution is just to augment th efield to a > > > 64 counter. It seems that the peirodic reporting is completely orthogonal to > > > this specific issue. > > We need to be careful here. Some of us need to get counters > directly from the hardware so just changing the size is > not an option. Doing it in software can be an issue too > because that means extra memory is needed for each flow. > > > > > You've covered the 'counter wrapping' problem - a flow information meter > > (whatever that turns out to be) needs counters wide enough not to wrap > > too often, and that becomes more of a problem at high link speeds. > > Not only the link speed but the aggregation level too. > The higher level aggregations tend to get more bytes/packets > per second. > > > In RTFM, all counts are kept in 64-bit unsigned counters so that they > > don't wrap too often. > > > > Of more interest, I don't remember seeing any IPFIX discussion > > concerning just how information about long-running flows is to be > > exported. In particular, I believe that counters should never be reset. > > One more thing to keep in mind here is that most hardware > does not provide a way to do an atomic get and set operation. > So if you do reset it, you'll likely loose some information. > > > That would mean that successive exports of the same flow would have > > increasing counter values, > > The other way is the box keeps track of the last reported > in counter in software and still provide deltas. The problem with > cumulative counts is on failover the collector will not > have the last count. I'd like to keep collector to collector > requirements to a minimum or none if possible. > > > a collector would need to remember the > > previous value and subtract it. Furthermore, provided unsigned > > arithmetic is used, the difference is correct even if the counter has > > wrapped. Provided, of course that the counter has only wrapped once! > > > > Cheers, Nevil > > > > ----------------------------------------------------------------------- > > Nevil Brownlee Director, Technology Development > > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > -- > > 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/ > > -- > 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/ -- 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 Fri Feb 22 05:46:29 2002 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 FAA26417 for ; Fri, 22 Feb 2002 05:46:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eCqQ-0006tB-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 04:22:26 -0600 Received: from mgw-dax2.ext.nokia.com ([63.78.179.217]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eCqO-0006t2-00 for ipfix-arch@net.doit.wisc.edu; Fri, 22 Feb 2002 04:22:24 -0600 Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1MAOMQ17217 for ; Fri, 22 Feb 2002 04:24:22 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Feb 2002 04:22:23 -0600 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Feb 2002 04:21:00 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [ipfix-arch] Qs on DoS sections Date: Fri, 22 Feb 2002 05:20:59 -0500 Message-ID: Thread-Topic: [ipfix-arch] Qs on DoS sections Thread-Index: AcG7S5SYzVuMybtWQ/++qGheWDg8twAP5U9w From: To: , X-OriginalArrivalTime: 22 Feb 2002 10:21:00.0104 (UTC) FILETIME=[9FA02C80:01C1BB8A] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA26417 Hello Ganesh, See my inline comments. > >7.3.2. Generic DoS attack on the IPFIX system > >The IPFIX system may subject to generic DoS attacks, just as any >system on any open networks. These types of attacks are not IPFIX >specific. Preventing and responding to such types of attacks are out >of the scope of IPFIX WG. > >Q: Is this not a special case of 7.3.1? Currently mechanism like Ingress filtering, Traceback etc... are the mechanism to detect or prevent Dos attacks but they are not widely adopted in the Internet. This is the reason the Dos attacks is not in the scope of IPFIX. May be we have to reword this sentence, simply as Dos attacks are not part of the scope rather than a lengthy statement. I am not sure of 7.3.1, may be cliff or paul can comment on that. regards ramg -- 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 Fri Feb 22 06:32:18 2002 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 GAA27711 for ; Fri, 22 Feb 2002 06:32:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eDgd-0001B5-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 05:16:23 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eDgb-0001AM-00 for ipfix-arch@net.doit.wisc.edu; Fri, 22 Feb 2002 05:16:21 -0600 Received: from cisco.com (bclaise-isdn-home3.cisco.com [10.49.4.220]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA23188; Fri, 22 Feb 2002 12:15:05 +0100 (MET) Message-ID: <3C762847.44C36762@cisco.com> Date: Fri, 22 Feb 2002 12:15:19 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: carter@qosient.com CC: "'Tanja Zseby'" , "'K.C. Norseth'" , reinaldo_penno@nortelnetworks.com, "'IPFIX Architecture'" Subject: Re: [ipfix-arch] applicability document References: <5C8959A16A71B449AE793CF52FBBED66019022@ptah.newyork.qosient.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, The correct terminology should be metering process, according to the req-01 draft that has been posted a few days ago. 2.3. Metering Process The metering process gets as input all packets observed at the observation point. On these packets it performs the actions of timestamping, sampling, filtering, mapping them to flows. Furthermore, the metering process includes maintaining flow records, computing flow statistics, and detecting flow expiration. Regards, Benoit Carter Bullard wrote: > Tanja, > Not a criticism but a question for clarification. > You refer to an IPFIX meter in your applicability document. > What is an IPFIX meter? > > Carter > > Carter Bullard > QoSient, LLC > 300 E. 56th Street, Suite 18K > New York, New York 10022 > > carter@qosient.com > Phone +1 212 588-9133 > Fax +1 212 588-9134 > http://qosient.com > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby > > Sent: Thursday, February 21, 2002 1:39 PM > > To: K.C. Norseth; reinaldo_penno@nortelnetworks.com > > Cc: IPFIX Architecture; Tanja Zseby > > Subject: [ipfix-arch] applicability document > > > > > > Hi K.C. and Reinaldo, > > > > attached you can find the first version of the applicability > > document as > > text file. > > > > It includes the sections 8 and 10 from Reinaldo and me from the > > architecture draft. I also included the intrusion detection part > > (section 8.1) Who contributed this to the architecture ? > > > > Regards > > Tanja > > > > -- > > Dipl.-Ing. Tanja Zseby > > FhI FOKUS/Global Networking Email: > > zseby@fokus.fhg.de > > Kaiserin-Augusta-Allee 31 Phone: > > +49-30-3463-7153 > > D-10589 Berlin, Germany Fax: > > +49-30-3463-8153 > > -------------------------------------------------------------- > > ------------------------ > > "Living on earth is expensive but it includes a free trip > > around the sun." (Anonymous) > > -------------------------------------------------------------- > > ------------------------ > > > > > > -- > 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/ -- 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 Fri Feb 22 06:44:08 2002 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 GAA28037 for ; Fri, 22 Feb 2002 06:44:08 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eDrk-0001ak-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 05:27:52 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eDri-0001Zq-00 for ipfix-arch@net.doit.wisc.edu; Fri, 22 Feb 2002 05:27:50 -0600 Received: from cisco.com (bclaise-isdn-home3.cisco.com [10.49.4.220]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA29974; Fri, 22 Feb 2002 12:26:38 +0100 (MET) Message-ID: <3C762AFC.83794426@cisco.com> Date: Fri, 22 Feb 2002 12:26:53 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: n.brownlee@auckland.ac.nz CC: reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <200202212141.KAA07738@mailhost.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil, n.brownlee@auckland.ac.nz wrote: > Hi Reinaldo: > > > b. avoid counter wrapping." > > > > This activity SHOULD be configurable. Btw, can someone elaborate on the > > counter wrapping stuff? > > > > It is very simple to send so much data though the line on a flow that the > > byte counter rolls over. This is very typical in 1 gig and 10g ports. > > counter 32 is not large enough field size for this. > > > > yes, that's what I tought. So the solution is just to augment th efield to a > > 64 counter. It seems that the peirodic reporting is completely orthogonal to > > this specific issue. > > You've covered the 'counter wrapping' problem - a flow information meter > (whatever that turns out to be) needs counters wide enough not to wrap > too often, and that becomes more of a problem at high link speeds. > In RTFM, all counts are kept in 64-bit unsigned counters so that they > don't wrap too often. > > Of more interest, I don't remember seeing any IPFIX discussion > concerning just how information about long-running flows is to be > exported. In particular, I believe that counters should never be reset. Why? For long run flows, you can just export the flow records with the acconting information seen during that interval. If you must export the flow records because: - you faced the long aging time timeout (for example: 30 minutes) - the counters is about to wrap. then you consider the flow to be ended (expired) and export the accounting data for that period. Now a new flow with the same characterics will be directly created. Not a problem. And you start the accounting from 0 for that "new" flow. The collector won't be confused at all and don't need to remember any values. Regards, Benoit > > That would mean that successive exports of the same flow would have > increasing counter values, a collector would need to remember the > previous value and subtract it. Furthermore, provided unsigned > arithmetic is used, the difference is correct even if the counter has > wrapped. Provided, of course that the counter has only wrapped once! > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > -- > 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/ -- 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 Fri Feb 22 10:03:20 2002 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 KAA04827 for ; Fri, 22 Feb 2002 10:03:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eGu6-00066j-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 08:42:30 -0600 Received: from d2cspimg001.smartpipes.com ([63.89.185.24]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eGu4-00064P-00 for ipfix-arch@net.doit.wisc.edu; Fri, 22 Feb 2002 08:42:28 -0600 Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 14:41:56 -0000 Message-ID: <4652644B98DFF34696801F8F3070D3FE01188702@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Ganesh Sadasivan'" , ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] Qs on DoS sections Date: Fri, 22 Feb 2002 14:41:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Precedence: bulk Sender: majordomo listserver Comments inline. -----Original Message----- From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] Sent: Thursday, February 21, 2002 9:36 PM To: ipfix-arch@net.doit.wisc.edu Subject: [ipfix-arch] Qs on DoS sections Hi, Some questions DoS sections: 7.3.1. Network under attack The Network itself may be under attack, resulting in an overwhelming number of IPFIX messages. The IPFIX SHOULD try to capture as much information as possible. However, when large amount IPFIX messages are generated in a short period of time, the IPFIX may become overloaded. The IPFIX system MUST provide enough performance assurance so that the system can still function under heavy load. Possible solutions include flow control and message thresholding. Q: What has "enough performance assurance" got to do with "flow control and message thresholding"? I guess it should be that "IPFIX system should be able to detect and react quickly to an overload condition". For something which cannot be clearly quantified, "MUST" seems to be too harsh. [cliff] one of the potential usage of IPFIX is for intrusion detection. When the network is under attack, it may heavily load the IPFIX system. To be able to report the network status, IPFIX system needs to have some mechanism (yet to be defined) to guarantee that enough flow information is captured so that ID can detect the attack and then respond accordingly. Whether it is a "SHOULD" or "MUST" is open for discussion. But in my opinion, to be able to support IDS, it seems to be a "MUST". 7.3.2. Generic DoS attack on the IPFIX system The IPFIX system may subject to generic DoS attacks, just as any system on any open networks. These types of attacks are not IPFIX specific. Preventing and responding to such types of attacks are out of the scope of IPFIX WG. Q: Is this not a special case of 7.3.1? [cliff] 7.3.1 refers to the network under attack, where the IPFIX system itself it not the direct target of the attack. 7.3.2 refers to the case that either the probe or the collector is under direct attack. We probably should update the text to be more clear. -- 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 Fri Feb 22 10:10:03 2002 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 KAA05066 for ; Fri, 22 Feb 2002 10:10:03 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eGyd-0006Hv-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 08:47:11 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eGya-0006HZ-00 for ipfix-req@net.doit.wisc.edu; Fri, 22 Feb 2002 08:47:08 -0600 Date: Fri, 22 Feb 2002 08:47:08 -0600 From: Dave Plonka To: ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] I-D ACTION:draft-ietf-ipfix-reqs-01.txt Message-ID: <20020222084708.A21005@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-F-CURTIDCHANGE, already a change to the process default transaction in progress X-Shakespearean-Insult: Thou saucy milk-livered lewdster Precedence: bulk Sender: majordomo listserver Below please find the announcement regarding the availability of the updated requirements draft. I've also updated the link on our IPFIX web site ("http://ipfix.doit.wisc.edu"). Dave ----- Forwarded message from owner-ipfix@net.doit.wisc.edu ----- To: IETF-Announce: ; Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipfix-reqs-01.txt Date: Fri, 22 Feb 2002 06:19:37 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Requirements for IP Flow Information Export Author(s) : J. Quittek et al. Filename : draft-ietf-ipfix-reqs-01.txt Pages : 24 Date : 21-Feb-02 This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes and middleboxes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-reqs-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-reqs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-reqs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020221154436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-reqs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-reqs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020221154436.I-D@ietf.org> --OtherAccess-- --NextPart-- ----- End forwarded message ----- -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Fri Feb 22 10:21:24 2002 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 KAA05482 for ; Fri, 22 Feb 2002 10:21:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eHGH-0006mJ-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 09:05:25 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eHGF-0006mB-00 for ipfix-app@net.doit.wisc.edu; Fri, 22 Feb 2002 09:05:23 -0600 Date: Fri, 22 Feb 2002 09:05:23 -0600 From: Dave Plonka To: ipfix-app@net.doit.wisc.edu Subject: [ipfix-app] new "ipfix-app" alias for IPFIX mailing list Message-ID: <20020222090522.B21005@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-F-CURTIDCHANGE, already a change to the process default transaction in progress X-Shakespearean-Insult: Thou saucy milk-livered lewdster Precedence: bulk Sender: majordomo listserver IPFIX participants, As Tanja recently requested, in this thread: http://ipfix.doit.wisc.edu/archive/0684.html we now have an "ipfix-app" alias, meaning "applications" or "applicability", for our IPFIX mailing list. Please send content which has to do with the applicability statements or documents to "ipfix-app@net.doit.wisc.edu", and the message will be sent to our public IPFIX mailing list with the message subject tagged with "[ipfix-app]". This is just like the "ipfix-req", "ipfix-arch" and "ipfix-data" that we've been using. More information about these aliases is here: http://ipfix.doit.wisc.edu/#Mailing_List_Aliases_Convention Dave P.S. I've also set up up an "ipfix-app-volunteers@net.doit.wisc.edu" alias which currently just forwards to Tanja and Reinaldo, as the current authors of the document that Tanja posted here: http://ipfix.doit.wisc.edu/archive/0717.html -- ":) You will make many changes before settling satisfactorily. :)" - the actual message (complete with smiley faces) that I received in a fortune cookie at dinner after the IPFIX WG meeting during IETF 52 in Salt Lake City -- 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 Fri Feb 22 12:52:02 2002 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 MAA13606 for ; Fri, 22 Feb 2002 12:52:02 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eJXF-00016r-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 11:31:05 -0600 Received: from mailhost.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eJXC-00016f-00 for ipfix@net.doit.wisc.edu; Fri, 22 Feb 2002 11:31:03 -0600 Received: from auckland.ac.nz (root@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id GAA04538 for ; Sat, 23 Feb 2002 06:30:56 +1300 (NZDT) Message-Id: <200202221730.GAA04538@mailhost.auckland.ac.nz> Date: Fri, 22 Feb 2002 09:33:19 -0800 (PST) From: n.brownlee@auckland.ac.nz Subject: [ipfix] IPFIX: Current issues / list digest, 22 Feb 02 To: ipfix@net.doit.wisc.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Hello everyone: I've more or less caught up with the list dsicussions, here's my attempt to summarise them and make a list of current issues, along with WG cochairs comments and guidance. I'll try to send an updated version of this around Friday each week from now on. Hope this helps, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand IPFIX Co-chairs list of IPFIX issues Nevil Brownlee, Fri 22 Feb 02 ++ marks each issue ** WG co-chairs comment - Mailing list discussion items Contributors names are listed in full following the list of issues ++ Counter wrapping, long-running flows ** Support for both absolute counts (counters) and deltas, no clear consensus. - Benoit, 22 Feb: Close flow and export it when it nears counter wrap, restart as a new flow. - Ganesh, 21 Feb: Export flow records when counters go past a threshold, Keep IEs for absolute counts or delta counts, whichever is needed. - Peter, 21 Feb: In our experience, it's better to output deltas. Absolute values are needed only if you have an unreliable data exporter. - KC, 21 Feb: Ability to send a flow record at any interval due to a counter rollover needs to be a selection criteria. - Reinaldo, 19 Feb: Could someone elaborate on this? ++ Configuration: protocol ** Out of scope, i.e. WG should not consider this until we have the Arch and Data drafts well under way. - KC, 20 Feb: not doing that, trying to select best of existing protocols - Randy, 20 Feb: reminder, out of scope - Reinaldo, 20 Feb, IPFIX config protocol needed, MIB OK as well - Fred, 20 Feb: NetFlow v9: good summary posting 'bi-directional config' = collector can ask exporter for reqd flows Fred doesn't think it would be useful, lots of IOS development, implications for reliability, security, etc. Config via an 'IPFIX Configuration MIB' would be better. - Juergen/Reinaldo/Paul/Benoit/Ram, 14 Feb: 'Not trying to standardise meter, therefore don't specify how to configure one.' - Mike, 13 Feb: Configuration and MIBs: "A MIB module is a concise guide to implementors in their design of a configuration interface (CLI, XML, XYZ, whatever) to manage a given techology" - Mark, 12 Feb: Comments on exporter-collector session management, session IDs. - Will, 11 Feb: Doesn't want 'SHOULD support in-band configuration.' ++ Configuration: Content Negotiation - Christian/Peter/Juergen, ~19 Feb: Collector should be able to request a subset of all available flow attributes, exporter should indicate which attributes it can send. - Benoit, 19 Feb: This is pure configuration. You tell the exporter w hich fields to export by defining a template. ++ Configuration: In-band Configuration - Christian/Peter/Juergen: This is the ability for a collector to ask an exporter for a particular set of flows ++ Applicability document *** Material currently in Arch draft. Discuss at Minneapolis meeting. Charter mentions it to support Architecture draft, so its OK to start work on this, but don't let it distract from other WG drafts! Use ipfix-app list alias for discussion. - Carter, 20 Feb: OK, but don't go too far off topic - KC, 20 Feb: Renaldo, Kevin & Tanja contributed most of this material in Arch, they'd be good editors - Tanja, Feb 19: 'Applicability' contents proposal - Proposed by KC, support from Benoit ++ Middleboxes document *** Not in scope, material currently in Arch draft. Do we need a separate document? Or put it in pplicability draft? ++ Selecting a Flow Info Export protocol ** Our charter says we'll select a protocol, however we'll probably need to look (small) improvements to an existing protocol - 19 Feb: KC had intended to list 'overview' descriptions of existing protocols in Arch draft. Paul thinks this is premature, we should list 'selection criteria' there instead. KC agrees, meantime (so as not to loose the contributed text from B/G and Kevin) we'll shift it into appendices. - Randy, 18 Feb: realistically, i think you will have to modify any of the existing protocols to meet robust needs. and yes, i think security should be a consideration. [ note that snmpv3 control and tcp export over ipsec may meet some of the more difficult issues you raise ] - David, 18 Feb: Selection criteria are needed for this! ++ Defining a flow - Paul, 19 Feb: Selection process chooses packets to consider, flow definition rules determine which unique flows to export, i.e. flow definition rules may define sub-flows. Collector may wish to know the selection cfriteria. - Reinaldo, 19 Feb: Is a subset of a flow (i.e. one formed by adding another filter function) not 'just another' flow? ++ Overload conditions - KC/Robert, 13 Feb: Should exporter or collector be allowed to hanle overload by changing sampling rate? Or is it better to loose packets instead? ++ Security Considerations - Cliff, 12 Feb: text for Arch draft B/G = Benoit & Ganesh Benoit Calise, Cisco Carter Bullard, QOSient Christian Gilby, Nortel Cliff Wang, SmartPipes David Harrington, Enterasys Fred True, AT&T Research Ganesh Sadavisan, Cisco Jean-christophe Martin, Sun Juergen Quittek, NEC KC Norseth, Enterasys Kevin Zhang, Xacct Man M Li, Nokia Mark Fullmer, OARnet Paul Calato, Riverstone Peter Ludemann, Xacct Ram Gopal, Nokia Randy Bush (AD), AT&T Reinaldo Penno, Nortel Sebastian Zander, Fraunhofer Institute FOKUS Simon Leinen, Switch Tanja Zseby, Fraunhofer Institute FOKUS Venkatraman G, Infosys Technologies Will Eatherton, Cisco ++Other comments Robert Lowe , 15 Feb: The lurker opinion poll (no vote)... ;-) In-band configuration -- not now. Negotiation -- limited (but that discussion is promised to follow). Benoit, I think this was a very perceptive comment. It seems we are at times confusing the two. Peter Phaal , 13 Feb: The IPFIX charter doesn't address the algorithms used by the flow collector, but there are system-wide issues that should be explored. Design choices made in the IPFIX protocol specification can have a fundamental effect on the capabilities of traffic management systems collecting IPFIX data (scalability, latency, accuracy, multi-point correlation, etc.) -- 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 Fri Feb 22 15:38:34 2002 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 PAA22529 for ; Fri, 22 Feb 2002 15:38:33 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eM7w-0004Vh-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 14:17:08 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eM7t-0004Ur-00 for ipfix-data@net.doit.wisc.edu; Fri, 22 Feb 2002 14:17:05 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1MKCkF06215; Fri, 22 Feb 2002 14:12:46 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF6Z5D>; Fri, 22 Feb 2002 12:12:44 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008BD2E01@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: ipfix-data@net.doit.wisc.edu, "Norseth, KC" Subject: [ipfix-data] Data doc - New sections 6.9.3, 6.9.4, 6.10.1, 6.10. 2 Date: Fri, 22 Feb 2002 12:12:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBDD.4995DFD0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBDD.4995DFD0 Content-Type: text/plain; charset="iso-8859-1" 6.9.3. Egress ATM Circuit The egress vpi/vci for the flow is provided in this Information element. vpi/vci id is defined by the ATM Forum UNI 3.1 specification: Template ID: ### Field Type: ### Size: ### 6.9.4. Egress Frame Relay DLCI The egress DLCI for the flow is provided in this Information element. ITU Q.922 defines the DLCI range. The frDlcmiState and the specific values of the DLCIis are defined in RFC 2115. Template ID: ### Field Type: ### Size: ### 6.10.1. Source Address Netmask The number of bits in the CIDR netmask, as defined in RFC 1519, for the source address. Template ID: ### Field Type: ### Size: ### 6.10.2. Destination Address Netmask The number of bits in the CIDR netmask, as defined in RFC 1519, for the destination address. ------_=_NextPart_001_01C1BBDD.4995DFD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [ipfix-data] Data doc - New sections 6.9.3, 6.9.4, 6.10.1, = 6.10.2

6.9.3.  Egress ATM Circuit

The egress vpi/vci for the flow is provided in this = Information element. vpi/vci id is defined by the ATM Forum UNI 3.1 = specification:

Template ID: ###   Field Type: = ###   Size: ###

6.9.4.  Egress Frame Relay DLCI

The egress DLCI for the flow is provided in this = Information element. ITU Q.922 defines the DLCI range. The frDlcmiState = and the specific values of the DLCIis are defined in RFC = 2115.

Template ID: ###   Field Type: = ###   Size: ###

6.10.1.  Source Address Netmask

The number of bits in the CIDR netmask, as defined in = RFC 1519, for the source address.

Template ID: ###   Field Type: = ###   Size: ###

6.10.2.  Destination Address Netmask

The number of bits in the CIDR netmask, as defined in = RFC 1519, for the destination address.

------_=_NextPart_001_01C1BBDD.4995DFD0-- -- 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 Fri Feb 22 15:44:45 2002 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 PAA22933 for ; Fri, 22 Feb 2002 15:44:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eMB4-0004aB-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 14:20:22 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eMB2-0004Z6-00 for ipfix-arch@net.doit.wisc.edu; Fri, 22 Feb 2002 14:20:20 -0600 Received: from riverstonenet.com (134.141.180.78 [134.141.180.78]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY8SKY; Fri, 22 Feb 2002 12:18:59 -0800 Message-ID: <3C76A7B1.184461FD@riverstonenet.com> Date: Fri, 22 Feb 2002 15:18:57 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: n.brownlee@auckland.ac.nz, reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <200202212141.KAA07738@mailhost.auckland.ac.nz> <3C762AFC.83794426@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Nevil, > > n.brownlee@auckland.ac.nz wrote: > > > Hi Reinaldo: > > > > > b. avoid counter wrapping." > > > > > > This activity SHOULD be configurable. Btw, can someone elaborate on the > > > counter wrapping stuff? > > > > > > It is very simple to send so much data though the line on a flow that the > > > byte counter rolls over. This is very typical in 1 gig and 10g ports. > > > counter 32 is not large enough field size for this. > > > > > > yes, that's what I tought. So the solution is just to augment th efield to a > > > 64 counter. It seems that the peirodic reporting is completely orthogonal to > > > this specific issue. > > > > You've covered the 'counter wrapping' problem - a flow information meter > > (whatever that turns out to be) needs counters wide enough not to wrap > > too often, and that becomes more of a problem at high link speeds. > > In RTFM, all counts are kept in 64-bit unsigned counters so that they > > don't wrap too often. > > > > Of more interest, I don't remember seeing any IPFIX discussion > > concerning just how information about long-running flows is to be > > exported. In particular, I believe that counters should never be reset. > > Why? > For long run flows, you can just export the flow records with the acconting > information seen during that interval. > If you must export the flow records because: > - you faced the long aging time timeout (for example: 30 minutes) > - the counters is about to wrap. > then you consider the flow to be ended (expired) and export the accounting data > for that period. > Now a new flow with the same characterics will be directly created. Not a problem. > And you start the accounting from 0 for that "new" flow. Most hardware can't do a get and set in one operation. So in between reading the count and setting it to zero you may loose some of the count. > The collector won't be confused at all and don't need to remember any values. > > Regards, Benoit > > > > > That would mean that successive exports of the same flow would have > > increasing counter values, a collector would need to remember the > > previous value and subtract it. Furthermore, provided unsigned > > arithmetic is used, the difference is correct even if the counter has > > wrapped. Provided, of course that the counter has only wrapped once! > > > > Cheers, Nevil > > > > ----------------------------------------------------------------------- > > Nevil Brownlee Director, Technology Development > > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > -- > > 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/ > > -- > 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/ -- 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 Fri Feb 22 15:47:43 2002 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 PAA23062 for ; Fri, 22 Feb 2002 15:47:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eMIE-0004lx-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 14:27:46 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eMIC-0004lQ-00 for ipfix-data@net.doit.wisc.edu; Fri, 22 Feb 2002 14:27:44 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1MKNQF08854; Fri, 22 Feb 2002 14:23:26 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF651Z>; Fri, 22 Feb 2002 12:23:24 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008BD2E20@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: ipfix-data@net.doit.wisc.edu, "Norseth, KC" Subject: [ipfix-data] Data doc - New section 6.12 - 6.12.4 Date: Fri, 22 Feb 2002 12:23:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBDE.C6ECB520" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBDE.C6ECB520 Content-Type: text/plain; charset="iso-8859-1" Hello Paul/K.C. this is part of the proposed changes in section 6.12. If we get some rough consensus I will post the whole section later. 6.12. Virtual Information An exporter may be involved in providing services that require application level intelligence and/or transform or filter content such as middlebox and OPES respectively. Each type field of the following IEs contain the type of operation performed on the packet. The currently available types are: 1. - NAT 2. - LSNAT 3. - Twice NAT 4. - Request Routing 5. - Outgoing L3 Tunnel 6. - Incoming L3 Tunnel 7. - Outgoing L2 Tunnel 8. - Incoming L2 Tunnel 9. - OPES (several sub-services here) 10. - others... TBD: How to convey when Several operations are applied to a packet, for instance, NAT and L2TP. Export several virtual sets... TBD: The type field is repeated on each IE, altough I do not expect that for the same set of virtual IEs we are going to have NAT in one and RR in other. It would cause confusion (see below) TBD: The order is important when applying and consequentely reporting a chain of operations in flow records. regards, Reinaldo ------_=_NextPart_001_01C1BBDE.C6ECB520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [ipfix-data] Data doc - New section 6.12 - 6.12.4

Hello Paul/K.C.

this is part of the proposed changes in section 6.12. = If we get some rough consensus I will post the whole section = later.


6.12. Virtual Information <or some other = name>

An exporter may be involved in providing services = that require application level intelligence and/or transform or filter = content such as middlebox and OPES respectively.

Each type field of the following IEs contain the type = of operation performed on the packet. The currently available types = are:

1. - NAT
2. - LSNAT
3. - Twice NAT
4. - Request Routing
5. - Outgoing L3 Tunnel
6. - Incoming L3 Tunnel
7. - Outgoing L2 Tunnel
8. - Incoming L2 Tunnel
9. - OPES (several sub-services here)
10. - others...

TBD: How to convey when Several operations are = applied to a packet, for instance, NAT and L2TP. Export several virtual = sets...

TBD: The type field is repeated on each IE, altough I = do not expect that for the same set of virtual IEs we are going to have = NAT in one and RR in other. It would cause confusion (see = below)

TBD: The order is important when applying and = consequentely reporting a chain of operations in flow records.

regards,

Reinaldo

------_=_NextPart_001_01C1BBDE.C6ECB520-- -- 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 Fri Feb 22 15:47:43 2002 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 PAA23073 for ; Fri, 22 Feb 2002 15:47:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eMKR-0004px-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 14:30:03 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eMKP-0004oB-00 for ipfix-data@net.doit.wisc.edu; Fri, 22 Feb 2002 14:30:01 -0600 Received: from riverstonenet.com (134.141.180.78 [134.141.180.78]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY8SQK; Fri, 22 Feb 2002 12:28:41 -0800 Message-ID: <3C76A9F8.F78FE8A@riverstonenet.com> Date: Fri, 22 Feb 2002 15:28:40 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-data@net.doit.wisc.edu, "Norseth, KC" Subject: Re: [ipfix-data] Data doc - New sections 6.9.3, 6.9.4, 6.10.1, 6.10.2 References: <4F973E944951D311B6660008C7917CF008BD2E01@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit These seem to be pretty much the same as what's there now. Paul Reinaldo Penno wrote: > > 6.9.3. Egress ATM Circuit > > The egress vpi/vci for the flow is provided in this Information > element. vpi/vci id is defined by the ATM Forum UNI 3.1 specification: > > Template ID: ### Field Type: ### Size: ### > > 6.9.4. Egress Frame Relay DLCI > > The egress DLCI for the flow is provided in this Information element. > ITU Q.922 defines the DLCI range. The frDlcmiState and the specific > values of the DLCIis are defined in RFC 2115. > > Template ID: ### Field Type: ### Size: ### > > 6.10.1. Source Address Netmask > > The number of bits in the CIDR netmask, as defined in RFC 1519, for > the source address. > > Template ID: ### Field Type: ### Size: ### > > 6.10.2. Destination Address Netmask > > The number of bits in the CIDR netmask, as defined in RFC 1519, for > the destination address. -- 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 Fri Feb 22 15:50:29 2002 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 PAA23245 for ; Fri, 22 Feb 2002 15:50:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eMNc-0004um-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 14:33:20 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eMNa-0004te-00 for ipfix-data@net.doit.wisc.edu; Fri, 22 Feb 2002 14:33:19 -0600 Received: from riverstonenet.com (134.141.180.78 [134.141.180.78]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY8SRN; Fri, 22 Feb 2002 12:31:57 -0800 Message-ID: <3C76AABC.A5D67BC1@riverstonenet.com> Date: Fri, 22 Feb 2002 15:31:56 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-data@net.doit.wisc.edu, "Norseth, KC" Subject: Re: [ipfix-data] Data doc - New section 6.12 - 6.12.4 References: <4F973E944951D311B6660008C7917CF008BD2E20@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > Hello Paul/K.C. > > this is part of the proposed changes in section 6.12. If we get some > rough consensus I will post the whole section later. > > 6.12. Virtual Information > > An exporter may be involved in providing services that require > application level intelligence and/or transform or filter content such > as middlebox and OPES respectively. > > Each type field of the following IEs contain the type of operation > performed on the packet. The currently available types are: > > 1. - NAT > 2. - LSNAT > 3. - Twice NAT > 4. - Request Routing > 5. - Outgoing L3 Tunnel > 6. - Incoming L3 Tunnel > 7. - Outgoing L2 Tunnel > 8. - Incoming L2 Tunnel > 9. - OPES (several sub-services here) > 10. - others... > > TBD: How to convey when Several operations are applied to a packet, > for instance, NAT and L2TP. Export several virtual sets... Can't you just have a LIST of IE's? > > TBD: The type field is repeated on each IE, altough I do not expect > that for the same set of virtual IEs we are going to have NAT in one > and RR in other. It would cause confusion (see below) > > TBD: The order is important when applying and consequentely reporting > a chain of operations in flow records. If order means the order of translation then I think that takes care of having multiple IE's with the same type. > > regards, > > Reinaldo -- 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 Fri Feb 22 16:18:00 2002 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 QAA25719 for ; Fri, 22 Feb 2002 16:18:00 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eMpO-0005Y9-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 15:02:02 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eMpM-0005Wu-00 for ipfix-data@net.doit.wisc.edu; Fri, 22 Feb 2002 15:02:00 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1MKvgF16090; Fri, 22 Feb 2002 14:57:42 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF6574>; Fri, 22 Feb 2002 12:57:41 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008BD2E82@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: ipfix-data@net.doit.wisc.edu, "Norseth, KC" Subject: RE: [ipfix-data] Data doc - New sections 6.9.3, 6.9.4, 6.10.1, 6. 10.2 Date: Fri, 22 Feb 2002 12:57:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBE3.8FE71160" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBE3.8FE71160 Content-Type: text/plain; charset="iso-8859-1" yep...I just made some editorial changes like subinterface->ATM cirtuit, Frame Relay subinterfcace-> DLCI, and others.. regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Friday, February 22, 2002 12:29 PM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: ipfix-data@net.doit.wisc.edu; Norseth, KC >Subject: Re: [ipfix-data] Data doc - New sections 6.9.3, 6.9.4, 6.10.1, >6.10.2 > > > >These seem to be pretty much the same as >what's there now. > >Paul > >Reinaldo Penno wrote: >> >> 6.9.3. Egress ATM Circuit >> >> The egress vpi/vci for the flow is provided in this Information >> element. vpi/vci id is defined by the ATM Forum UNI 3.1 >specification: >> >> Template ID: ### Field Type: ### Size: ### >> >> 6.9.4. Egress Frame Relay DLCI >> >> The egress DLCI for the flow is provided in this Information element. >> ITU Q.922 defines the DLCI range. The frDlcmiState and the specific >> values of the DLCIis are defined in RFC 2115. >> >> Template ID: ### Field Type: ### Size: ### >> >> 6.10.1. Source Address Netmask >> >> The number of bits in the CIDR netmask, as defined in RFC 1519, for >> the source address. >> >> Template ID: ### Field Type: ### Size: ### >> >> 6.10.2. Destination Address Netmask >> >> The number of bits in the CIDR netmask, as defined in RFC 1519, for >> the destination address. > ------_=_NextPart_001_01C1BBE3.8FE71160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] Data doc - New sections 6.9.3, 6.9.4, 6.10.1, = 6.10.2

yep...I just made some editorial changes like = subinterface->ATM cirtuit, Frame Relay subinterfcace-> DLCI, and = others..

regards,

Reinaldo

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Friday, February 22, 2002 12:29 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: ipfix-data@net.doit.wisc.edu; Norseth, = KC
>Subject: Re: [ipfix-data] Data doc - New = sections 6.9.3, 6.9.4, 6.10.1,
>6.10.2
>
>
>
>These seem to be pretty much the same as
>what's there now.
>
>Paul
>
>Reinaldo Penno wrote:
>>
>> 6.9.3.  Egress ATM Circuit
>>
>> The egress vpi/vci for the flow is provided = in this Information
>> element. vpi/vci id is defined by the ATM = Forum UNI 3.1
>specification:
>>
>> Template ID: ###   Field Type: = ###   Size: ###
>>
>> 6.9.4.  Egress Frame Relay DLCI
>>
>> The egress DLCI for the flow is provided in = this Information element.
>> ITU Q.922 defines the DLCI range. The = frDlcmiState and the specific
>> values of the DLCIis are defined in RFC = 2115.
>>
>> Template ID: ###   Field Type: = ###   Size: ###
>>
>> 6.10.1.  Source Address Netmask
>>
>> The number of bits in the CIDR netmask, as = defined in RFC 1519, for
>> the source address.
>>
>> Template ID: ###   Field Type: = ###   Size: ###
>>
>> 6.10.2.  Destination Address = Netmask
>>
>> The number of bits in the CIDR netmask, as = defined in RFC 1519, for
>> the destination address.
>

------_=_NextPart_001_01C1BBE3.8FE71160-- -- 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 Fri Feb 22 16:31:09 2002 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 QAA26273 for ; Fri, 22 Feb 2002 16:31:09 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eN2p-0005s4-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 15:15:55 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eN2m-0005rI-00 for ipfix-data@net.doit.wisc.edu; Fri, 22 Feb 2002 15:15:53 -0600 Received: from riverstonenet.com (134.141.180.78 [134.141.180.78]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY8S8P; Fri, 22 Feb 2002 13:14:35 -0800 Message-ID: <3C76B4BA.D1AD13BD@riverstonenet.com> Date: Fri, 22 Feb 2002 16:14:34 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: ipfix-data@net.doit.wisc.edu, "Norseth, KC" Subject: Re: [ipfix-data] Data doc - New section 6.12 - 6.12.4 References: <4F973E944951D311B6660008C7917CF008BD2E9F@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Friday, February 22, 2002 12:32 PM > >To: Penno, Reinaldo [SC9:T327:EXCH] > >Cc: ipfix-data@net.doit.wisc.edu; Norseth, KC > >Subject: Re: [ipfix-data] Data doc - New section 6.12 - 6.12.4 > > > > > >Reinaldo Penno wrote: > >> > >> Hello Paul/K.C. > >> > >> this is part of the proposed changes in section 6.12. If we get > some > >> rough consensus I will post the whole section later. > >> > >> 6.12. Virtual Information > >> > >> An exporter may be involved in providing services that require > >> application level intelligence and/or transform or filter > >content such > >> as middlebox and OPES respectively. > >> > >> Each type field of the following IEs contain the type of operation > >> performed on the packet. The currently available types are: > >> > >> 1. - NAT > >> 2. - LSNAT > >> 3. - Twice NAT > >> 4. - Request Routing > >> 5. - Outgoing L3 Tunnel > >> 6. - Incoming L3 Tunnel > >> 7. - Outgoing L2 Tunnel > >> 8. - Incoming L2 Tunnel > >> 9. - OPES (several sub-services here) > >> 10. - others... > >> > >> TBD: How to convey when Several operations are applied to a packet, > > >> for instance, NAT and L2TP. Export several virtual sets... > > > > Can't you just have a LIST of IE's? > > yes, that what I meant by "several virtual sets". I was wondering if > maybe you could maybe consolidate the information. > > > > >> > >> TBD: The type field is repeated on each IE, altough I do not expect > > >> that for the same set of virtual IEs we are going to have NAT in > one > >> and RR in other. It would cause confusion (see below) > >> > >> TBD: The order is important when applying and consequentely > reporting > >> a chain of operations in flow records. > > > > If order means the order of translation then I think that > > takes care of having multiple IE's with the same type. > > Not only having multiple IEs with the same type but in order, not any > order. I just want to make sure that we understand that the order is > important. We should probably say that when the exporter is involved > on these types of services the order of the IEs MUST reflect the order > of the operations performed. agreed. > > regards, > > Reinaldo > > > > > > > > > > > > >> > >> regards, > >> > >> Reinaldo > > -- 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 Fri Feb 22 16:38:14 2002 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 QAA26520 for ; Fri, 22 Feb 2002 16:38:14 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eMzf-0005nV-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 15:12:39 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eMzZ-0005me-00 for ipfix-data@net.doit.wisc.edu; Fri, 22 Feb 2002 15:12:33 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1ML8BF00710; Fri, 22 Feb 2002 15:08:11 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1MAF66GC>; Fri, 22 Feb 2002 13:08:09 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008BD2E9F@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com Cc: ipfix-data@net.doit.wisc.edu, "Norseth, KC" Subject: RE: [ipfix-data] Data doc - New section 6.12 - 6.12.4 Date: Fri, 22 Feb 2002 13:08:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBE5.05D40350" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBE5.05D40350 Content-Type: text/plain; charset="iso-8859-1" >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Friday, February 22, 2002 12:32 PM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: ipfix-data@net.doit.wisc.edu; Norseth, KC >Subject: Re: [ipfix-data] Data doc - New section 6.12 - 6.12.4 > > >Reinaldo Penno wrote: >> >> Hello Paul/K.C. >> >> this is part of the proposed changes in section 6.12. If we get some >> rough consensus I will post the whole section later. >> >> 6.12. Virtual Information >> >> An exporter may be involved in providing services that require >> application level intelligence and/or transform or filter >content such >> as middlebox and OPES respectively. >> >> Each type field of the following IEs contain the type of operation >> performed on the packet. The currently available types are: >> >> 1. - NAT >> 2. - LSNAT >> 3. - Twice NAT >> 4. - Request Routing >> 5. - Outgoing L3 Tunnel >> 6. - Incoming L3 Tunnel >> 7. - Outgoing L2 Tunnel >> 8. - Incoming L2 Tunnel >> 9. - OPES (several sub-services here) >> 10. - others... >> >> TBD: How to convey when Several operations are applied to a packet, >> for instance, NAT and L2TP. Export several virtual sets... > > Can't you just have a LIST of IE's? yes, that what I meant by "several virtual sets". I was wondering if maybe you could maybe consolidate the information. > >> >> TBD: The type field is repeated on each IE, altough I do not expect >> that for the same set of virtual IEs we are going to have NAT in one >> and RR in other. It would cause confusion (see below) >> >> TBD: The order is important when applying and consequentely reporting >> a chain of operations in flow records. > > If order means the order of translation then I think that > takes care of having multiple IE's with the same type. Not only having multiple IEs with the same type but in order, not any order. I just want to make sure that we understand that the order is important. We should probably say that when the exporter is involved on these types of services the order of the IEs MUST reflect the order of the operations performed. regards, Reinaldo > > > > > >> >> regards, >> >> Reinaldo > ------_=_NextPart_001_01C1BBE5.05D40350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-data] Data doc - New section 6.12 - 6.12.4

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Friday, February 22, 2002 12:32 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: ipfix-data@net.doit.wisc.edu; Norseth, = KC
>Subject: Re: [ipfix-data] Data doc - New section = 6.12 - 6.12.4
>
>
>Reinaldo Penno wrote:
>>
>> Hello Paul/K.C.
>>
>> this is part of the proposed changes in = section 6.12. If we get some
>> rough consensus I will post the whole = section later.
>>
>> 6.12. Virtual Information <or some other = name>
>>
>> An exporter may be involved in providing = services that require
>> application level intelligence and/or = transform or filter
>content such
>> as middlebox and OPES respectively.
>>
>> Each type field of the following IEs = contain the type of operation
>> performed on the packet. The currently = available types are:
>>
>> 1. - NAT
>> 2. - LSNAT
>> 3. - Twice NAT
>> 4. - Request Routing
>> 5. - Outgoing L3 Tunnel
>> 6. - Incoming L3 Tunnel
>> 7. - Outgoing L2 Tunnel
>> 8. - Incoming L2 Tunnel
>> 9. - OPES (several sub-services = here)
>> 10. - others...
>>
>> TBD: How to convey when Several operations = are applied to a packet,
>> for instance, NAT and L2TP. Export several = virtual sets...
>
>       Can't you = just have a LIST of IE's?

yes, that what I meant by "several virtual = sets". I was wondering if maybe you could maybe consolidate the = information.

>
>>
>> TBD: The type field is repeated on each IE, = altough I do not expect
>> that for the same set of virtual IEs we are = going to have NAT in one
>> and RR in other. It would cause confusion = (see below)
>>
>> TBD: The order is important when applying = and consequentely reporting
>> a chain of operations in flow = records.
>
>       If order = means the order of translation then I think that
>       takes care = of having multiple IE's with the same type.

Not only having multiple IEs with the same type but = in order, not any order. I just want to make sure that we understand = that the order is important. We should probably say that when the = exporter is involved on these types of services the order of the IEs = MUST reflect the order of the operations performed.

regards,

Reinaldo



>
>
>
>      
>
>>
>> regards,
>>
>> Reinaldo
>

------_=_NextPart_001_01C1BBE5.05D40350-- -- 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 Fri Feb 22 18:40:31 2002 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 SAA01208 for ; Fri, 22 Feb 2002 18:40:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eP3R-0000nD-00 for ipfix-list@mil.doit.wisc.edu; Fri, 22 Feb 2002 17:24:41 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eP3O-0000mY-00 for ipfix-arch@net.doit.wisc.edu; Fri, 22 Feb 2002 17:24:38 -0600 Received: from cisco.com (bclaise-isdn-home3.cisco.com [10.49.4.220]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id AAA07808; Sat, 23 Feb 2002 00:23:25 +0100 (MET) Message-ID: <3C76D2FC.BC9D58ED@cisco.com> Date: Sat, 23 Feb 2002 00:23:40 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: n.brownlee@auckland.ac.nz, reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <200202212141.KAA07738@mailhost.auckland.ac.nz> <3C762AFC.83794426@cisco.com> <3C76A7B1.184461FD@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, calato@riverstonenet.com wrote: > Benoit Claise wrote: > > > > Nevil, > > > > n.brownlee@auckland.ac.nz wrote: > > > > > Hi Reinaldo: > > > > > > > b. avoid counter wrapping." > > > > > > > > This activity SHOULD be configurable. Btw, can someone elaborate on the > > > > counter wrapping stuff? > > > > > > > > It is very simple to send so much data though the line on a flow that the > > > > byte counter rolls over. This is very typical in 1 gig and 10g ports. > > > > counter 32 is not large enough field size for this. > > > > > > > > yes, that's what I tought. So the solution is just to augment th efield to a > > > > 64 counter. It seems that the peirodic reporting is completely orthogonal to > > > > this specific issue. > > > > > > You've covered the 'counter wrapping' problem - a flow information meter > > > (whatever that turns out to be) needs counters wide enough not to wrap > > > too often, and that becomes more of a problem at high link speeds. > > > In RTFM, all counts are kept in 64-bit unsigned counters so that they > > > don't wrap too often. > > > > > > Of more interest, I don't remember seeing any IPFIX discussion > > > concerning just how information about long-running flows is to be > > > exported. In particular, I believe that counters should never be reset. > > > > Why? > > For long run flows, you can just export the flow records with the acconting > > information seen during that interval. > > If you must export the flow records because: > > - you faced the long aging time timeout (for example: 30 minutes) > > - the counters is about to wrap. > > then you consider the flow to be ended (expired) and export the accounting data > > for that period. > > Now a new flow with the same characterics will be directly created. Not a problem. > > And you start the accounting from 0 for that "new" flow. > > Most hardware can't do a get and set in one > operation. So in between reading the count > and setting it to zero you may loose some > of the count. I'm not too sure about the details of most hardware, but this is the way it works with netflow. Regards, Benoit > > > > The collector won't be confused at all and don't need to remember any values. > > > > Regards, Benoit > > > > > > > > That would mean that successive exports of the same flow would have > > > increasing counter values, a collector would need to remember the > > > previous value and subtract it. Furthermore, provided unsigned > > > arithmetic is used, the difference is correct even if the counter has > > > wrapped. Provided, of course that the counter has only wrapped once! > > > > > > Cheers, Nevil > > > > > > ----------------------------------------------------------------------- > > > Nevil Brownlee Director, Technology Development > > > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > > > -- > > > 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/ > > > > -- > > 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/ -- 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 Sat Feb 23 15:13:28 2002 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 PAA23813 for ; Sat, 23 Feb 2002 15:13:23 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eiDd-0003M0-00 for ipfix-list@mil.doit.wisc.edu; Sat, 23 Feb 2002 13:52:29 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eiDa-0003LB-00 for ipfix-req@net.doit.wisc.edu; Sat, 23 Feb 2002 13:52:26 -0600 Received: from peter ([192.168.254.182]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1NJrGl24930 for ; Sat, 23 Feb 2002 11:53:16 -0800 From: "Peter Ludemann" To: Subject: [ipfix-req] Collector Failover as a requirement Date: Sat, 23 Feb 2002 11:51:56 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit This note is about requirements for reliability and underlying transport protocols and is NOT a critique of http://www.ietf.org/internet-drafts/draft-gsadasiv-ipfix-proposal-00.txt. Section 4.2.3 of that document, which describes Collector Failover in generic terms, leads me to believe that some people in the WG might have made invalid assumptions about the transport protocol (which is "beyond the scope of [the] document" (Section 1.1)) ... and these invalid assumptions lead to omitting important requirements. TCP's keepalive is not sufficient for detecting loss of connectivity, as sections 4.2.0 and 4.2.1 suggest (there is no guarantee that a collector crash will send any kind of signal to the sender, which is why TCP has such a complex start-up and shut-down; keepalive is not guaranteed to be implemented and even if implemented its response is measured in hours ... for more on this, see (at the risk of copyright violation of Stevens' "TCP/IP Illustrated", Chapter 23) http://www.comp.nus.edu.sg/~shenru/tcpip/tcp_keep.htm). So, unless we mandate SCTP for transport, the flow export needs to define its own equivalent of keepalive and behaviour on failover. I don't think that we can mandate SCTP because it's not yet widely available. Therefore, to satisfy the Reliability requirement, the data export protocol must be able to provide failure detection so that failover can be done quickly. The data export protocol must also specify the underlying transports that it is designed to work on. - peter ---- Peter Ludemann peter.ludemann@xacct.com Chief Architect +1.408.330.5732 XACCT Technologies, Inc. 2900 Lakeside Drive Santa Clara, CA 95054 -- 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 Sat Feb 23 15:17:53 2002 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 PAA23844 for ; Sat, 23 Feb 2002 15:17:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eiMq-0003b1-00 for ipfix-list@mil.doit.wisc.edu; Sat, 23 Feb 2002 14:02:00 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eiMn-0003aU-00 for ipfix-req@net.doit.wisc.edu; Sat, 23 Feb 2002 14:01:57 -0600 Received: from peter ([192.168.254.182]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1NK2Wl24960; Sat, 23 Feb 2002 12:02:32 -0800 From: "Peter Ludemann" To: "Benoit Claise" , , Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Sat, 23 Feb 2002 12:01:12 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200202191046.g1JAkQG18629@bru-cse-222.cisco.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise [mailto:bclaise@cisco.com] wrote Tuesday, February 19, 2002 2:46 AM: > I don't call this above "content negotiation" but pure configuration. > You tell the exporter which fields to export by defining a template. So, shall we have an argument about terminology? That's avoiding the point. It's more important that we discuss the actual requirements. So far, I've seen arguments in favour of both content negotiation and in-band configuration but the only arguments I've seen against these seem to be "I don't like it" or "it's not in the charter". If I missed more substantive arguments, please send me a reference ... it would be nice to have something a bit more persuasive. Benoit's statement begs the question: how is the template defined? If it's done out-of-band, that requires a separate element management system (unless you like entering CLI commands or SNMP values by hand). It makes a tightly-coupled sender-receiver difficult to handle (I'll give an example later). Both content negotiation and in-band configuration should be required but in the trivial sense that the device must respond to the request for content change or configuration but the response can be "I refuse to change the content" or "your configuration request is rejected". This is easy to implement; and it allows other devices to do the content negotiation or in-band configuration that they want. [Similarly, I would like a MIB to be required, at minimum to get configuration, performance, and other "out of band" data; and it could also (optionally) be used to set configuration values.] If we don't put these features into the standard, some people will add them anyway and we won't have a standard any more. Sometimes configuration at the device (or via an element management system) is the best way to do things. But sometimes the receiver must be involved; or the sender and receiver need to be configured together. In-band content negotiation and configuration simplify this. Here is one scenario. Consider collecting layer 3/4 data (e.g., collecting details of individual FTP or HTTP connections) exporting the sessions in "slices" (e.g., giving the progress every 30 minutes). From this, a nice histogram of protocol usage by time of day can be generated. But now we want more details around the busy times (e.g., 5 minutes slices) but less details at other times [to save space in the database]. This can easily be done via in-band configuration -- after all, the collector is connected directly to the data receiving and processing system; but would be much more complex using an element management system, which isn't designed for changing things so dynamically. Going further with this example, we want do dynamically drill-down to find busy URLs and FTP sites but not to do this all the time because of performance issues and because of data space considerations. This could be done without in-band configuration, but it would be much nastier. (This example is taken from experience with a data collection system that was inserting over 100 million records a day into a database ... clearly, being able to limit the amount of data is very important and can have significant impact on the cost of the deployment.) In this scenario, we sometimes want to do in-band configuration and sometimes want to do other configuration (so, there is something to Benoit's remark). As I've mentioned elsewhere, I think that data negotiation is the more important of the two, because of the need to coordinate template information amongst multiple (failover) receivers; but in-band configuration is also useful and allows a simpler deployment. (Again, based on our experience, ease-of-deployment is a very important consideration, unless you enjoy long meetings in large airless rooms with representatives from a dozen different departments.) In general, I believe that "perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away" (Antoine de Saint-Exupery). But in-band content negotiation and configuration are not very complex (we've implemented them, anyway), are sufficiently useful to be included, and would lead to "standard extension" if we don't include them. - peter ---- Peter Ludemann peter.ludemann@xacct.com Chief Architect +1.408.330.5732 XACCT Technologies, Inc. 2900 Lakeside Drive Santa Clara, CA 95054 -- 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 Sat Feb 23 15:32:16 2002 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 PAA23953 for ; Sat, 23 Feb 2002 15:32:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eicq-0003vV-00 for ipfix-list@mil.doit.wisc.edu; Sat, 23 Feb 2002 14:18:32 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16eico-0003ug-00 for ipfix@net.doit.wisc.edu; Sat, 23 Feb 2002 14:18:30 -0600 Received: from peter ([192.168.254.182]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1NKIll24988; Sat, 23 Feb 2002 12:18:47 -0800 From: "Peter Ludemann" To: , Cc: "KC' 'Norseth" , "Ipfix@Net. Doit. Wisc. Edu" Subject: RE: [ipfix] ipfix data model contribution Date: Sat, 23 Feb 2002 12:17:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C711C04.CA6BC479@riverstonenet.com> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit calato@riverstonenet.com wrote Monday, February 18, 2002 7:22 AM: > This looks like protocol definition to me. I thought > we were supposed to select a protocol not build one. This is an existing protocol (at least, it's been specified and implemented; and it has survived some fairly nasty testing at my hands and at the hands of other sadists). Most of what Kevin contributed is related to data format ... there's a little bit that relates to protocol matters (e.g., start/stop) and some that might be arguable as to which document it belongs in (data templates and negotiation). - peter ---- Peter Ludemann peter.ludemann@xacct.com Chief Architect +1.408.330.5732 XACCT Technologies, Inc. 2900 Lakeside Drive Santa Clara, CA 95054 -- 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 Sun Feb 24 00:22:31 2002 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 AAA29766 for ; Sun, 24 Feb 2002 00:22:30 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16eqga-0006Sc-00 for ipfix-list@mil.doit.wisc.edu; Sat, 23 Feb 2002 22:54:56 -0600 Received: from eng4.oar.net ([192.148.244.24]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16eqgZ-0006SX-00 for ipfix-req@net.doit.wisc.edu; Sat, 23 Feb 2002 22:54:55 -0600 Received: (qmail 84170 invoked by uid 4454); 24 Feb 2002 04:54:37 -0000 Date: Sat, 23 Feb 2002 23:54:37 -0500 From: Mark Fullmer To: Peter Ludemann Cc: ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Collector Failover as a requirement Message-ID: <20020223235437.A84125@net.ohio-state.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from peter.ludemann@xacct.com on Sat, Feb 23, 2002 at 11:51:56AM -0800 Precedence: bulk Sender: majordomo listserver On Sat, Feb 23, 2002 at 11:51:56AM -0800, Peter Ludemann wrote: > TCP's keepalive is not sufficient for detecting loss of connectivity, as > sections 4.2.0 and 4.2.1 suggest (there is no guarantee that a collector > crash will send any kind of signal to the sender, which is why TCP has such > a complex start-up and shut-down; keepalive is not guaranteed to be A few suggestions to help aim at a middle ground between the lightweight/best effort NetFlow (like) protocol vs. the more resource intensive "reliable" drafts/implementations. o make the control connection in draft-gsadasiv-ipfix-proposal-00.txt required and TCP. This removes the need for retransmits or periodic updates of templates to the collector. When the collector boots up it won't have to wait for templates. This also can stop the router from generating flows to a non existant collector. o Implement a keepalive mechanism where the collector will ACK the highest sequence number flow record it has processed per (any?) "observation domain" The keepalive can be optional -- ie the exporter can send a keepalive of N to inform the collector it expects a keepalive every N seconds or 0 to disable it. Default disabled. o The exporter will send the collector a message on the control connection indicating where to listen for flow records (ie what protocol UDP/TCP/SCTP) and addressing information (port, IP address). Must UDP May TCP/SCTP. o Change the sequence number in draft-gsadasiv-ipfix-proposal-00.txt to number of flows instead of number of packets so that the collector can count lost flow records as in NetFlow v5,6,7,8. o Ignore the configuration of the exporter issue for now, but implement the control connection message format such that it can be tackled later, or implemented by a vendor and then submitted for IPFIX v2. Ie, require the exporter to NAK any messages sent by the collector it can not decode. mark -- 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 Feb 25 03:45:05 2002 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 DAA02788 for ; Mon, 25 Feb 2002 03:45:05 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fGOl-0002Rv-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 02:22:15 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fGOj-0002Qx-00 for ipfix-req@net.doit.wisc.edu; Mon, 25 Feb 2002 02:22:13 -0600 Received: from peter ([192.168.254.182]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1P8Mpl32388; Mon, 25 Feb 2002 00:22:51 -0800 From: "Peter Ludemann" To: "Mark Fullmer" Cc: Subject: RE: [ipfix-req] Collector Failover as a requirement Date: Mon, 25 Feb 2002 00:21:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20020223235437.A84125@net.ohio-state.edu> Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit My comments interspersed. > From: Mark Fullmer [mailto:maf@eng.oar.net] > Sent: Saturday, February 23, 2002 8:55 PM > To: Peter Ludemann > Cc: ipfix-req@net.doit.wisc.edu > Subject: Re: [ipfix-req] Collector Failover as a requirement > > > On Sat, Feb 23, 2002 at 11:51:56AM -0800, Peter Ludemann wrote: > > TCP's keepalive is not sufficient for detecting loss of connectivity, as > > sections 4.2.0 and 4.2.1 suggest (there is no guarantee that a collector > > crash will send any kind of signal to the sender, which is why > TCP has such > > a complex start-up and shut-down; keepalive is not guaranteed to be > > A few suggestions to help aim at a middle ground between the > lightweight/best effort NetFlow (like) protocol vs. the > more resource intensive "reliable" drafts/implementations. In a normal deployment, with the collector close to the sender, "reliable" isn't more resource-intensive. And TCP is a reasonable choice; the latest NFS is done over TCP because it's as efficient as using UDP and avoids re-inventing wheels for things like congestion control. When a connection is broken, TCP uses longer and longer intervals when retransmitting, so the execution overhead remains small. Having said that, it is impossible to make a 100% reliable system. If connections go down, eventually there will be no more room inside the sender to store data, so some data must be discarded. The protocol must be able to detect this and inform the receiver (when things are reconnected). One more thing about unreliable protocols ... they're attractive in theory but in practice we find ourselves building workarounds to make them seem reliable (this applies to both NetFlow and SNMP). Any data delivery method that avoids reliability simply pushes things on to another part of the system. > o make the control connection in draft-gsadasiv-ipfix-proposal-00.txt > required and TCP. This removes the need for retransmits or > periodic updates of templates to the collector. When the collector > boots up it won't have to wait for templates. This also can > stop the router from generating flows to a non existant collector. I don't think that only TCP should be required. I would also allow SCTP ... it's better than TCP for fail-over, but not widely available yet. > o Implement a keepalive mechanism where the collector will ACK the > highest sequence number flow record it has processed per (any?) > "observation domain" The keepalive can be optional -- ie the > exporter can send a keepalive of N to inform the collector it > expects a keepalive every N seconds or 0 to disable it. Default > disabled. This is essentially the way that CRANE works. However, I don't think that a keepalive gives any advantage ... the sender should just time out and failover if it doesn't receive a data ACK in time (there's no need for keepalives when no data are being sent). [Downstream deduplication will always be needed for handling failures because ACKs can get lost.] [I'm currently doing some experiments on the best way to do ACKs to get the fastest failover; so I reserve the right to change my mind about heartbeet keepalives.] > o The exporter will send the collector a message on the control > connection indicating where to listen for flow records > (ie what protocol UDP/TCP/SCTP) and addressing information > (port, IP address). Must UDP May TCP/SCTP. The initial message can also advertise the protocol version. I would be opposed to UDP for data delivery. I don't see any performance advantages and it causes a lot of downstream processing pain. > o Change the sequence number in draft-gsadasiv-ipfix-proposal-00.txt > to number of flows instead of number of packets so that the collector > can count lost flow records as in NetFlow v5,6,7,8. Access to the packet count is not possible with most TCP implementations anyway. > o Ignore the configuration of the exporter issue for now, but implement > the control connection message format such that it can be > tackled later, or implemented by a vendor and then submitted for > IPFIX v2. Ie, require the exporter to NAK any messages sent by > the collector it can not decode. I believe that content negotiation is important for reasons of performance and synchronizing amongst receivers in a fail-over setup. Other in-band configuration is less important (it can be done via MIBS but is also easier to define in a generic way (essentially a set of keyword/value pairs that must be all handled as a single transaction ... like SNMP SET but with database-style transaction control). I would like to see in v1: - a standard data protocol (with generic configuration) using TCP for transport - a core set of values and types (the "data model") and in v2: - other transport protocols (such as SCTP) - additional standard values and types - additional standard kinds of configuration The v1 protocol must allow this future extensibility. > > mark - peter ---------- Peter Ludemann +1.408.330.5732 Chief Architect +1.650.248.3973 (mobile) XACCT Technologies peter.ludemann@xacct.com 2900 Lakeside Drive http://www.xacct.com Santa Clara CA 95054 -- 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 Feb 25 05:44:10 2002 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 FAA04102 for ; Mon, 25 Feb 2002 05:44:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fIAr-00052q-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 04:16:01 -0600 Received: from bru-cse-222.cisco.com ([144.254.8.48]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fIAo-00051x-00 for ipfix-req@net.doit.wisc.edu; Mon, 25 Feb 2002 04:15:59 -0600 Received: (from bclaise@localhost) by bru-cse-222.cisco.com (8.10.2+Sun/CA/950118) id g1PAFQS12394; Mon, 25 Feb 2002 11:15:26 +0100 (CET) Date: Mon, 25 Feb 2002 11:15:26 +0100 (CET) From: Benoit Claise Message-Id: <200202251015.g1PAFQS12394@bru-cse-222.cisco.com> To: bclaise@cisco.com, ipfix-req@net.doit.wisc.edu, peter.ludemann@xacct.com Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt X-Sun-Charset: US-ASCII Precedence: bulk Sender: majordomo listserver Hi Peter, > > > I don't call this above "content negotiation" but pure configuration. > > You tell the exporter which fields to export by defining a template. > > So, shall we have an argument about terminology? That's avoiding the point. > > It's more important that we discuss the actual requirements. So far, I've > seen arguments in favour of both content negotiation and in-band > configuration but the only arguments I've seen against these seem to be "I > don't like it" or "it's not in the charter". If I missed more substantive > arguments, please send me a reference ... it would be nice to have something > a bit more persuasive. > > Benoit's statement begs the question: how is the template defined? If it's > done out-of-band, that requires a separate element management system (unless > you like entering CLI commands or SNMP values by hand). It makes a > tightly-coupled sender-receiver difficult to handle (I'll give an example > later). As a reminder from Nevil http://ipfix.doit.wisc.edu/list/ipfix/archive/0736.html ++ Configuration: protocol - Randy, 20 Feb: reminder, out of scope [I skipped the other people's comments] As the configuration is out of scope, data negotation (as you call it in the rest of your email below) or configuration negotation (as I call it) must follow the same path -> out of scope. Regards, Benoit. > > Both content negotiation and in-band configuration should be required but in > the trivial sense that the device must respond to the request for content > change or configuration but the response can be "I refuse to change the > content" or "your configuration request is rejected". This is easy to > implement; and it allows other devices to do the content negotiation or > in-band configuration that they want. [Similarly, I would like a MIB to be > required, at minimum to get configuration, performance, and other "out of > band" data; and it could also (optionally) be used to set configuration > values.] > > If we don't put these features into the standard, some people will add them > anyway and we won't have a standard any more. > > Sometimes configuration at the device (or via an element management system) > is the best way to do things. But sometimes the receiver must be involved; > or the sender and receiver need to be configured together. In-band content > negotiation and configuration simplify this. > > Here is one scenario. Consider collecting layer 3/4 data (e.g., collecting > details of individual FTP or HTTP connections) exporting the sessions in > "slices" (e.g., giving the progress every 30 minutes). From this, a nice > histogram of protocol usage by time of day can be generated. > > But now we want more details around the busy times (e.g., 5 minutes slices) > but less details at other times [to save space in the database]. This can > easily be done via in-band configuration -- after all, the collector is > connected directly to the data receiving and processing system; but would be > much more complex using an element management system, which isn't designed > for changing things so dynamically. Going further with this example, we > want do dynamically drill-down to find busy URLs and FTP sites but not to do > this all the time because of performance issues and because of data space > considerations. This could be done without in-band configuration, but it > would be much nastier. (This example is taken from experience with a data > collection system that was inserting over 100 million records a day into a > database ... clearly, being able to limit the amount of data is very > important and can have significant impact on the cost of the deployment.) > > In this scenario, we sometimes want to do in-band configuration and > sometimes want to do other configuration (so, there is something to Benoit's > remark). As I've mentioned elsewhere, I think that data negotiation is the > more important of the two, because of the need to coordinate template > information amongst multiple (failover) receivers; but in-band configuration > is also useful and allows a simpler deployment. > > (Again, based on our experience, ease-of-deployment is a very important > consideration, unless you enjoy long meetings in large airless rooms with > representatives from a dozen different departments.) > > In general, I believe that "perfection is reached, not when there is no > longer anything to add, but when there is no longer anything to take away" > (Antoine de Saint-Exupery). But in-band content negotiation and > configuration are not very complex (we've implemented them, anyway), are > sufficiently useful to be included, and would lead to "standard extension" > if we don't include them. > > - peter > > ---- > Peter Ludemann peter.ludemann@xacct.com > Chief Architect +1.408.330.5732 > XACCT Technologies, Inc. > 2900 Lakeside Drive Santa Clara, CA 95054 > -- 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 Feb 25 10:28:44 2002 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 KAA13733 for ; Mon, 25 Feb 2002 10:28:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fMkC-0005MS-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 09:08:48 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fMkA-0005Lz-00 for ipfix-arch@net.doit.wisc.edu; Mon, 25 Feb 2002 09:08:46 -0600 Received: from riverstonenet.com (134.141.180.105 [134.141.180.105]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY9R3Z; Mon, 25 Feb 2002 07:07:29 -0800 Message-ID: <3C7A532F.D7CA10BD@riverstonenet.com> Date: Mon, 25 Feb 2002 10:07:27 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: n.brownlee@auckland.ac.nz, reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <200202212141.KAA07738@mailhost.auckland.ac.nz> <3C762AFC.83794426@cisco.com> <3C76A7B1.184461FD@riverstonenet.com> <3C76D2FC.BC9D58ED@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Thought I would reply direct. I would check on that. Since the hardware is the one that increments the counter as packets are going through, the only way to read the count and then set it to zero as one operation would be to stop the hardware from updating the counter while the read-set-to-zero operation is happening. So either the netflow hardware really supports that operation or a tradeoff was made to leave the issue as is. It would be good to know as it affects how to best accomplish intermediate updates should we go that way. Paul Benoit Claise wrote: > > Paul, > > calato@riverstonenet.com wrote: > > > Benoit Claise wrote: > > > > > > Nevil, > > > > > > n.brownlee@auckland.ac.nz wrote: > > > > > > > Hi Reinaldo: > > > > > > > > > b. avoid counter wrapping." > > > > > > > > > > This activity SHOULD be configurable. Btw, can someone elaborate on the > > > > > counter wrapping stuff? > > > > > > > > > > It is very simple to send so much data though the line on a flow that the > > > > > byte counter rolls over. This is very typical in 1 gig and 10g ports. > > > > > counter 32 is not large enough field size for this. > > > > > > > > > > yes, that's what I tought. So the solution is just to augment th efield to a > > > > > 64 counter. It seems that the peirodic reporting is completely orthogonal to > > > > > this specific issue. > > > > > > > > You've covered the 'counter wrapping' problem - a flow information meter > > > > (whatever that turns out to be) needs counters wide enough not to wrap > > > > too often, and that becomes more of a problem at high link speeds. > > > > In RTFM, all counts are kept in 64-bit unsigned counters so that they > > > > don't wrap too often. > > > > > > > > Of more interest, I don't remember seeing any IPFIX discussion > > > > concerning just how information about long-running flows is to be > > > > exported. In particular, I believe that counters should never be reset. > > > > > > Why? > > > For long run flows, you can just export the flow records with the acconting > > > information seen during that interval. > > > If you must export the flow records because: > > > - you faced the long aging time timeout (for example: 30 minutes) > > > - the counters is about to wrap. > > > then you consider the flow to be ended (expired) and export the accounting data > > > for that period. > > > Now a new flow with the same characterics will be directly created. Not a problem. > > > And you start the accounting from 0 for that "new" flow. > > > > Most hardware can't do a get and set in one > > operation. So in between reading the count > > and setting it to zero you may loose some > > of the count. > > I'm not too sure about the details of most hardware, but this is the way it works with > netflow. > > Regards, Benoit > > > > > > > > The collector won't be confused at all and don't need to remember any values. > > > > > > Regards, Benoit > > > > > > > > > > > That would mean that successive exports of the same flow would have > > > > increasing counter values, a collector would need to remember the > > > > previous value and subtract it. Furthermore, provided unsigned > > > > arithmetic is used, the difference is correct even if the counter has > > > > wrapped. Provided, of course that the counter has only wrapped once! > > > > > > > > Cheers, Nevil > > > > > > > > ----------------------------------------------------------------------- > > > > Nevil Brownlee Director, Technology Development > > > > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > > > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > > > > > -- > > > > 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/ > > > > > > -- > > > 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/ -- 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 Feb 25 13:35:55 2002 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 NAA23808 for ; Mon, 25 Feb 2002 13:35:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fPd5-0001L2-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 12:13:39 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fPd2-0001KL-00 for ipfix-req@net.doit.wisc.edu; Mon, 25 Feb 2002 12:13:37 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1PID0E07598; Mon, 25 Feb 2002 10:13:00 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABH16191; Mon, 25 Feb 2002 10:13:23 -0800 (PST) Message-ID: <3C7A7EAB.3D220E78@cisco.com> Date: Mon, 25 Feb 2002 10:12:59 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ludemann CC: Benoit Claise , ipfix-req@net.doit.wisc.edu, cgilby@nortelnetworks.com Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Peter, Peter Ludemann wrote: > Benoit Claise [mailto:bclaise@cisco.com] wrote Tuesday, February 19, 2002 > 2:46 AM: > > > I don't call this above "content negotiation" but pure configuration. > > You tell the exporter which fields to export by defining a template. > > So, shall we have an argument about terminology? That's avoiding the point. > > It's more important that we discuss the actual requirements. So far, I've > seen arguments in favour of both content negotiation and in-band > configuration but the only arguments I've seen against these seem to be "I > don't like it" or "it's not in the charter". If I missed more substantive > arguments, please send me a reference ... it would be nice to have something > a bit more persuasive. May be you missed my response to one of the e-mails in this thread. The main reason I see is complexity. Just taking a few cases.. 1. Defining an observation point : Eg. The collector now has to say let the set of interfaces {a,b,..} belong to this observation point. So now the collector needs to know what kind of interfaces these are, their characteristics, whether they are groupable etc. All these rules have to be fed into the collector and these mostly would be vendor dependent.Boxes from different vendors exhibit different characteristics for these groupings. 2. Defining a metering process: Metering process can be defined at different levels at the time of observing the packets or after aggregating. There are a wide variety of metering mechanisms that are adopted today in terms of metering. In many cases the sequences in which metering is done is very important especially in the hardware switching platforms. Is the collector expected to know all these intricate details of a platform and send an in-band configuration message? Or are the existing products to be re-engineered to suit IPFIX protocol? 3. If there are 'n' exporters trying to export to a collector, choosing the least common fields among all the exporters to define a common template of export from the collector is not an easy task. Say the collector decides on a template, common to all exporters and now a new exporter joins which cannot support this set what is the collector's policy now? The choice of policies varies greatly with applications that finally use this data. This has to be coupled with the understanding of how metering is done at the exporter. 4. In the routers, whose main job is to route the packets with performance and forwarding features as the top priority, making decisions as to which stack to setup (TCP/SCTP) for export, what security protocol should be used, dynamically decide what templates/fields to accept/reject, dynamically modify the export timers, export rate, start peeking deeper into a packet which may affect the performance, though ideally achievable is too much an overhead. I tend to beleive that each service provider would be interested in defining these decisions for the routers in their own way and generalising any such behavior may not add much value, other than adding more complexity. It is fairly trivial still to use expect scripts and cron jobs to achieve the same;) Thanks Ganesh > > > Benoit's statement begs the question: how is the template defined? If it's > done out-of-band, that requires a separate element management system (unless > you like entering CLI commands or SNMP values by hand). It makes a > tightly-coupled sender-receiver difficult to handle (I'll give an example > later). > > > Both content negotiation and in-band configuration should be required but in > the trivial sense that the device must respond to the request for content > change or configuration but the response can be "I refuse to change the > content" or "your configuration request is rejected". This is easy to > implement; and it allows other devices to do the content negotiation or > in-band configuration that they want. [Similarly, I would like a MIB to be > required, at minimum to get configuration, performance, and other "out of > band" data; and it could also (optionally) be used to set configuration > values.] > > > If we don't put these features into the standard, some people will add them > anyway and we won't have a standard any more. > > Sometimes configuration at the device (or via an element management system) > is the best way to do things. But sometimes the receiver must be involved; > or the sender and receiver need to be configured together. In-band content > negotiation and configuration simplify this. > > Here is one scenario. Consider collecting layer 3/4 data (e.g., collecting > details of individual FTP or HTTP connections) exporting the sessions in > "slices" (e.g., giving the progress every 30 minutes). From this, a nice > histogram of protocol usage by time of day can be generated. > > But now we want more details around the busy times (e.g., 5 minutes slices) > but less details at other times [to save space in the database]. This can > easily be done via in-band configuration -- after all, the collector is > connected directly to the data receiving and processing system; but would be > much more complex using an element management system, which isn't designed > for changing things so dynamically. Going further with this example, we > want do dynamically drill-down to find busy URLs and FTP sites but not to do > this all the time because of performance issues and because of data space > considerations. This could be done without in-band configuration, but it > would be much nastier. (This example is taken from experience with a data > collection system that was inserting over 100 million records a day into a > database ... clearly, being able to limit the amount of data is very > important and can have significant impact on the cost of the deployment.) > > In this scenario, we sometimes want to do in-band configuration and > sometimes want to do other configuration (so, there is something to Benoit's > remark). As I've mentioned elsewhere, I think that data negotiation is the > more important of the two, because of the need to coordinate template > information amongst multiple (failover) receivers; but in-band configuration > is also useful and allows a simpler deployment. > > (Again, based on our experience, ease-of-deployment is a very important > consideration, unless you enjoy long meetings in large airless rooms with > representatives from a dozen different departments.) > > In general, I believe that "perfection is reached, not when there is no > longer anything to add, but when there is no longer anything to take away" > (Antoine de Saint-Exupery). But in-band content negotiation and > configuration are not very complex (we've implemented them, anyway), are > sufficiently useful to be included, and would lead to "standard extension" > if we don't include them. > > - peter > > ---- > Peter Ludemann peter.ludemann@xacct.com > Chief Architect +1.408.330.5732 > XACCT Technologies, Inc. > 2900 Lakeside Drive Santa Clara, CA 95054 > > -- > 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/ -- 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 Feb 25 13:48:12 2002 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 NAA24332 for ; Mon, 25 Feb 2002 13:48:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fPtf-0001i4-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 12:30:47 -0600 Received: from sj-msg-core-3.cisco.com ([171.70.157.152]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fPtY-0001hI-00 for ipfix-req@net.doit.wisc.edu; Mon, 25 Feb 2002 12:30:40 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1PIU8w02776; Mon, 25 Feb 2002 10:30:08 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABH16970; Mon, 25 Feb 2002 10:30:27 -0800 (PST) Message-ID: <3C7A82AA.BD814C45@cisco.com> Date: Mon, 25 Feb 2002 10:30:03 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ludemann CC: Mark Fullmer , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Collector Failover as a requirement References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Peter, Peter Ludemann wrote: > My comments interspersed. > > > From: Mark Fullmer [mailto:maf@eng.oar.net] > > Sent: Saturday, February 23, 2002 8:55 PM > > To: Peter Ludemann > > Cc: ipfix-req@net.doit.wisc.edu > > Subject: Re: [ipfix-req] Collector Failover as a requirement > > > > > > On Sat, Feb 23, 2002 at 11:51:56AM -0800, Peter Ludemann wrote: > > > TCP's keepalive is not sufficient for detecting loss of connectivity, as > > > sections 4.2.0 and 4.2.1 suggest (there is no guarantee that a collector > > > crash will send any kind of signal to the sender, which is why > > TCP has such > > > a complex start-up and shut-down; keepalive is not guaranteed to be > > > > A few suggestions to help aim at a middle ground between the > > lightweight/best effort NetFlow (like) protocol vs. the > > more resource intensive "reliable" drafts/implementations. > > In a normal deployment, with the collector close to the sender, "reliable" > isn't more resource-intensive. And TCP is a reasonable choice; the > latest NFS is done over TCP because it's as efficient as using > UDP and avoids re-inventing wheels for things like congestion control. > When a connection is broken, TCP uses longer and longer intervals when > retransmitting, so the execution overhead remains small. What is a "normal deployment"? TCP is not as efficient as UDP in terms of processing requirements (this should be fairly obvious). Well if the network is reliable enough, I think UDP would work out better. > > > Having said that, it is impossible to make a 100% reliable system. > If connections go down, eventually there will be no more room inside > the sender to store data, so some data must be discarded. The protocol > must be able to detect this and inform the receiver (when things are > reconnected). > > One more thing about unreliable protocols ... they're attractive in theory > but in practice we find ourselves building workarounds to make them > seem reliable (this applies to both NetFlow and SNMP). Any data delivery > method that avoids reliability simply pushes things on to another > part of the system. I am curious to know the workarounds done on top of Netflow to make it relaible? > > > > o make the control connection in draft-gsadasiv-ipfix-proposal-00.txt > > required and TCP. This removes the need for retransmits or > > periodic updates of templates to the collector. When the collector > > boots up it won't have to wait for templates. This also can > > stop the router from generating flows to a non existant collector. > > I don't think that only TCP should be required. I would also allow SCTP > ... it's better than TCP for fail-over, but not widely available yet. > > > o Implement a keepalive mechanism where the collector will ACK the > > highest sequence number flow record it has processed per (any?) > > "observation domain" The keepalive can be optional -- ie the > > exporter can send a keepalive of N to inform the collector it > > expects a keepalive every N seconds or 0 to disable it. Default > > disabled. > > This is essentially the way that CRANE works. However, I don't think > that a keepalive gives any advantage ... the sender should just time > out and failover if it doesn't receive a data ACK in time (there's no > need for keepalives when no data are being sent). [Downstream > deduplication will always be needed for handling failures because > ACKs can get lost.] > > [I'm currently doing some experiments on the best way to do ACKs to > get the fastest failover; so I reserve the right to change my mind > about heartbeet keepalives.] > > > o The exporter will send the collector a message on the control > > connection indicating where to listen for flow records > > (ie what protocol UDP/TCP/SCTP) and addressing information > > (port, IP address). Must UDP May TCP/SCTP. > > The initial message can also advertise the protocol version. > > I would be opposed to UDP for data delivery. I don't see any > performance advantages and it causes a lot of downstream > processing pain. Can you explain a little more here? > > > > o Change the sequence number in draft-gsadasiv-ipfix-proposal-00.txt > > to number of flows instead of number of packets so that the collector > > can count lost flow records as in NetFlow v5,6,7,8. There are other means to achive the same in the new protocol. Basically the flowsets tell the length and using the size of each record in the flowset, one can calculate the # of records. > > > Access to the packet count is not possible with most TCP implementations > anyway. > > > o Ignore the configuration of the exporter issue for now, but implement > > the control connection message format such that it can be > > tackled later, or implemented by a vendor and then submitted for > > IPFIX v2. Ie, require the exporter to NAK any messages sent by > > the collector it can not decode. > > I believe that content negotiation is important for reasons of performance > and synchronizing amongst receivers in a fail-over setup. Other in-band > configuration is less important (it can be done via MIBS but is also > easier to define in a generic way (essentially a set of keyword/value > pairs that must be all handled as a single transaction ... like SNMP > SET but with database-style transaction control). > > I would like to see in v1: > - a standard data protocol (with generic configuration) using TCP > for transport > - a core set of values and types (the "data model") > and in v2: > - other transport protocols (such as SCTP) > - additional standard values and types > - additional standard kinds of configuration > > The v1 protocol must allow this future extensibility. inband config and content negotiation I already replied to your previous mail. I am not convinced it is worth adding it in this framework. Thanks Ganesh > > > > > > mark > > - peter > > ---------- > Peter Ludemann +1.408.330.5732 > Chief Architect +1.650.248.3973 (mobile) > XACCT Technologies peter.ludemann@xacct.com > 2900 Lakeside Drive http://www.xacct.com > Santa Clara CA 95054 > > -- > 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/ -- 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 Feb 25 13:59:44 2002 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 NAA25018 for ; Mon, 25 Feb 2002 13:59:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fQ8V-0001zz-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 12:46:07 -0600 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fQ8T-0001zl-00 for ipfix@net.doit.wisc.edu; Mon, 25 Feb 2002 12:46:05 -0600 Received: from auckland.ac.nz (root@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id HAA15845 for ; Tue, 26 Feb 2002 07:45:56 +1300 (NZDT) Message-Id: <200202251845.HAA15845@mailhost.auckland.ac.nz> Date: Mon, 25 Feb 2002 10:48:15 -0800 (PST) From: n.brownlee@auckland.ac.nz Subject: [ipfix] Current WG activities To: ipfix@net.doit.wisc.edu In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Hello all: The IPFIX Architecture and Data Model version 00 drafts were submitted on time, early afternoon (PST). We're waiting for internet-drafts@ietf to get them published. Now that we're past the draft submission deadline, we'll certainly keep working on the drafts. The latest versions of them will be available on the IPFIX web site. Over the next few weeks I believe we should continue to work on - expanding/refining the descriptions of the flow attributes in the Data Model draft - improving the list of protocol selection criteria in the Architecture draft On 23 Feb, Peter Ludemann sent a few emails, pointing out the need to make our arguments very clear on topics like 'how do we want to see IPFIX exporters and collectors configured?' I agree that 'not in the charter' isn't a very strong argument, but the WG is trying hard *not* to invent a complete new protocol. So incremental improvements to an existing protocol can certainly be talked about ... Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand -- 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 Feb 25 17:22:44 2002 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 RAA02045 for ; Mon, 25 Feb 2002 17:22:44 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fTAQ-00063r-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 16:00:18 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fTAO-00060c-00 for ipfix-arch@net.doit.wisc.edu; Mon, 25 Feb 2002 16:00:16 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1PLtDb11465; Mon, 25 Feb 2002 15:55:13 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 13:55:12 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008C54725@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: calato@riverstonenet.com, Benoit Claise Cc: n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] counter wrapping Date: Mon, 25 Feb 2002 13:55:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BE47.189D1DF0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BE47.189D1DF0 Content-Type: text/plain; charset="ISO-8859-1" Hello Paul, Could we just have the two counters as proposed by Ganesh (absolute and delta)? An implementation would use one or the other as it sees fit. regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Monday, February 25, 2002 7:07 AM >To: Benoit Claise >Cc: n.brownlee@auckland.ac.nz; Penno, Reinaldo [SC9:T327:EXCH]; >ipfix-arch@net.doit.wisc.edu >Subject: Re: [ipfix-arch] counter wrapping > > > >Thought I would reply direct. > >I would check on that. Since the hardware >is the one that increments the counter as >packets are going through, the only way to >read the count and then set it to zero as >one operation would be to stop the hardware >from updating the counter while the read-set-to-zero >operation is happening. > >So either the netflow hardware really supports that >operation or a tradeoff was made to leave the issue >as is. > >It would be good to know as it affects how to best >accomplish intermediate updates should we go that way. > >Paul > >Benoit Claise wrote: >> >> Paul, >> >> calato@riverstonenet.com wrote: >> >> > Benoit Claise wrote: >> > > >> > > Nevil, >> > > >> > > n.brownlee@auckland.ac.nz wrote: >> > > >> > > > Hi Reinaldo: >> > > > >> > > > > b. avoid counter wrapping." >> > > > > >> > > > > This activity SHOULD be configurable. Btw, can >someone elaborate on the >> > > > > counter wrapping stuff? >> > > > > >> > > > > It is very simple to send so much data though the >line on a flow that the >> > > > > byte counter rolls over. This is very typical in 1 >gig and 10g ports. >> > > > > counter 32 is not large enough field size for this. >> > > > > >> > > > > yes, that's what I tought. So the solution is just >to augment th efield to a >> > > > > 64 counter. It seems that the peirodic reporting is >completely orthogonal to >> > > > > this specific issue. >> > > > >> > > > You've covered the 'counter wrapping' problem - a flow >information meter >> > > > (whatever that turns out to be) needs counters wide >enough not to wrap >> > > > too often, and that becomes more of a problem at high >link speeds. >> > > > In RTFM, all counts are kept in 64-bit unsigned >counters so that they >> > > > don't wrap too often. >> > > > >> > > > Of more interest, I don't remember seeing any IPFIX discussion >> > > > concerning just how information about long-running >flows is to be >> > > > exported. In particular, I believe that counters >should never be reset. >> > > >> > > Why? >> > > For long run flows, you can just export the flow records >with the acconting >> > > information seen during that interval. >> > > If you must export the flow records because: >> > > - you faced the long aging time timeout (for example: >30 minutes) >> > > - the counters is about to wrap. >> > > then you consider the flow to be ended (expired) and >export the accounting data >> > > for that period. >> > > Now a new flow with the same characterics will be >directly created. Not a problem. >> > > And you start the accounting from 0 for that "new" flow. >> > >> > Most hardware can't do a get and set in one >> > operation. So in between reading the count >> > and setting it to zero you may loose some >> > of the count. >> >> I'm not too sure about the details of most hardware, but >this is the way it works with >> netflow. >> >> Regards, Benoit >> >> > >> > >> > > The collector won't be confused at all and don't need to >remember any values. >> > > >> > > Regards, Benoit >> > > >> > > > >> > > > That would mean that successive exports of the same >flow would have >> > > > increasing counter values, a collector would need to >remember the >> > > > previous value and subtract it. Furthermore, provided unsigned >> > > > arithmetic is used, the difference is correct even if >the counter has >> > > > wrapped. Provided, of course that the counter has >only wrapped once! >> > > > >> > > > Cheers, Nevil >> > > > >> > > > >----------------------------------------------------------------------- >> > > > Nevil Brownlee Director, >Technology Development >> > > > Phone: +64 9 373 7599 x8941 ITSS, The >University of Auckland >> > > > FAX: +64 9 373 7021 Private Bag 92019, >Auckland, New Zealand >> > > > >> > > > -- >> > > > 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/ >> > > >> > > -- >> > > 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/ > ------_=_NextPart_001_01C1BE47.189D1DF0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] counter wrapping

Hello Paul,

Could we just have the two counters as proposed by = Ganesh (absolute and delta)? An implementation would use one or the = other as it sees fit.

regards,

Reinaldo

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com= ]
>Sent: Monday, February 25, 2002 7:07 AM
>To: Benoit Claise
>Cc: n.brownlee@auckland.ac.nz; Penno, Reinaldo = [SC9:T327:EXCH];
>ipfix-arch@net.doit.wisc.edu
>Subject: Re: [ipfix-arch] counter = wrapping
>
>
>
>Thought I would reply direct.
>
>I would check on that. Since the hardware
>is the one that increments the counter as
>packets are going through, the only way to =
>read the count and then set it to zero as
>one operation would be to stop the = hardware
>from updating the counter while the = read-set-to-zero
>operation is happening.
>
>So either the netflow hardware really supports = that
>operation or a tradeoff was made to leave the = issue
>as is.
>
>It would be good to know as it affects how to = best
>accomplish intermediate updates should we go = that way.
>
>Paul
>
>Benoit Claise wrote:
>>
>> Paul,
>>
>> calato@riverstonenet.com wrote:
>>
>> > Benoit Claise wrote:
>> > >
>> > > Nevil,
>> > >
>> > > n.brownlee@auckland.ac.nz = wrote:
>> > >
>> > > > Hi Reinaldo:
>> > > >
>> > > > > b. avoid counter = wrapping."
>> > > > >
>> > > > > This activity SHOULD be = configurable. Btw, can
>someone elaborate on the
>> > > > > counter wrapping = stuff?
>> > > > >
>> > > > > It is very simple to = send so much data though the
>line on a flow that the
>> > > > > byte counter rolls = over.  This is very typical in 1
>gig and 10g  ports.
>> > > > > counter 32 is not large = enough field size for this.
>> > > > >
>> > > > > yes, that's what I = tought. So the solution is just
>to augment th efield to a
>> > > > > 64 counter. It seems = that the peirodic reporting is
>completely orthogonal to
>> > > > > this specific = issue.
>> > > >
>> > > > You've covered the 'counter = wrapping' problem - a flow
>information meter
>> > > > (whatever that turns out to = be) needs counters wide
>enough not to wrap
>> > > > too often, and that becomes = more of a problem at high
>link speeds.
>> > > > In RTFM, all counts are kept = in 64-bit unsigned
>counters so that they
>> > > > don't wrap too often.
>> > > >
>> > > > Of more interest, I don't = remember seeing any IPFIX discussion
>> > > > concerning just how = information about long-running
>flows is to be
>> > > > exported.  In = particular, I believe that counters
>should never be reset.
>> > >
>> > > Why?
>> > > For long run flows, you can just = export the flow records
>with the acconting
>> > > information seen during that = interval.
>> > > If you must export the flow = records because:
>> > >  - you faced the long aging = time timeout (for example:
>30 minutes)
>> > >  - the counters is about to = wrap.
>> > > then you consider the flow to be = ended (expired) and
>export the accounting data
>> > > for that period.
>> > > Now a new flow with the same = characterics will be
>directly created. Not a problem.
>> > > And you start the accounting from = 0 for that "new" flow.
>> >
>> = >         Most hardware = can't do a get and set in one
>> = >         operation. So in = between reading the count
>> = >         and setting it to = zero you may loose some
>> = >         of the = count.
>>
>> I'm not too sure about the details of most = hardware, but
>this is the way it works with
>> netflow.
>>
>> Regards, Benoit
>>
>> >
>> >
>> > > The collector won't be confused = at all and don't need to
>remember any values.
>> > >
>> > > Regards, Benoit
>> > >
>> > > >
>> > > > That would mean that = successive exports of the same
>flow would have
>> > > > increasing counter values, a = collector would need to
>remember the
>> > > > previous value and subtract = it.  Furthermore, provided unsigned
>> > > > arithmetic is used, the = difference is correct even if
>the counter has
>> > > > wrapped.  Provided, of = course that the counter has
>only wrapped once!
>> > > >
>> > > > Cheers, Nevil
>> > > >
>> > > >
>-----------------------------------------------------------= ------------
>> > > >    Nevil = Brownlee          &nbs= p;        Director,
>Technology Development
>> > > >    Phone: +64 = 9 373 7599 x8941      ITSS, The
>University of Auckland
>> > > >    FAX: +64 9 = 373 7021      Private Bag 92019,
>Auckland, New Zealand
>> > > >
>> > > > --
>> > > > = Help        mailto:majordomo@net.doit.wi= sc.edu and say
>"help" in message body
>> > > > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>> > > > "unsubscribe = ipfix" in message body
>> > > > = Archive     http://ipfix.doit.wisc.edu/archive/
>> > >
>> > > --
>> > > = Help        mailto:majordomo@net.doit.wi= sc.edu and say
>"help" in message body
>> > > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
>> > > "unsubscribe ipfix" in = message body
>> > > Archive     = http://ipfix.doit.wisc.edu/archive/
>

------_=_NextPart_001_01C1BE47.189D1DF0-- -- 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 Feb 25 17:24:21 2002 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 RAA02065 for ; Mon, 25 Feb 2002 17:24:21 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fT4A-0005sL-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 15:53:50 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fT48-0005rk-00 for ipfix-req@net.doit.wisc.edu; Mon, 25 Feb 2002 15:53:48 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1PLr2b10844; Mon, 25 Feb 2002 15:53:02 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 13:53:01 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008C5471E@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: Ganesh Sadasivan , Peter Ludemann Cc: Benoit Claise , ipfix-req@net.doit.wisc.edu, "Christian Gilby" Subject: RE: in band configuration? RE: [ipfix-req] Proposed changes to draft-ietf-ipfix-reqs-00.txt Date: Mon, 25 Feb 2002 13:53:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BE46.CACAC8C0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BE46.CACAC8C0 Content-Type: text/plain; charset="ISO-8859-1" Hello Ganesh/Peter, comments inline.. >-----Original Message----- >From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com] >Sent: Monday, February 25, 2002 10:13 AM >To: Peter Ludemann >Cc: Benoit Claise; ipfix-req@net.doit.wisc.edu; Gilby, Christian >[SC9:0000:EXCH] >Subject: Re: in band configuration? RE: [ipfix-req] Proposed changes to >draft-ietf-ipfix-reqs-00.txt > > >Hi Peter, > >Peter Ludemann wrote: > >> Benoit Claise [mailto:bclaise@cisco.com] wrote Tuesday, >February 19, 2002 >> 2:46 AM: >> >> > I don't call this above "content negotiation" but pure >configuration. >> > You tell the exporter which fields to export by defining a >template. >> >> So, shall we have an argument about terminology? That's >avoiding the point. >> >> It's more important that we discuss the actual requirements. >So far, I've >> seen arguments in favour of both content negotiation and in-band >> configuration but the only arguments I've seen against these >seem to be "I >> don't like it" or "it's not in the charter". If I missed >more substantive >> arguments, please send me a reference ... it would be nice >to have something >> a bit more persuasive. > > to be re-engineered to suit IPFIX protocol? > 3. If there are 'n' exporters trying to export to a >collector, choosing the >least common > fields among all the exporters to define a common >template of export from This would be one option. The other option would be the exporter use a different template for each collector, in order to make the most of their implementation. >the > collector is not an easy task. Say the collector decides >on a template, >common to all > exporters and now a new exporter joins which cannot >support this set what >is the > collector's policy now? The choice of policies varies >greatly with >applications > that finally use this data. This has to be coupled with >the understanding >of how > metering is done at the exporter. > 4. In the routers, whose main job is to route the packets >with performance and > forwarding features as the top priority, making >decisions as to which stack > > to setup (TCP/SCTP) for export, what security protocol >should be used, > dynamically decide what templates/fields to >accept/reject, dynamically >modify > the export timers, export rate, start peeking deeper into >a packet which may > > affect the performance, though ideally achievable is too >much an overhead. > I tend to beleive that each service provider would be >interested in defining > > these decisions for the routers in their own way and >generalising any such > behavior may not add much value, other than adding more >complexity. It is > fairly trivial still to use expect scripts and cron jobs >to achieve the >same;) This argument is okay for traditional routers (for a lack of a better word). The possible users for the IPfix protocol are PC-probes, more intelligent edge routers, routers that offer middlebox services, IPservices switches, etc Deciding on a protocol that has the least functions just to accomodate a single type of equipment is not the way to go. As we said before, we can this part of the protocol optional. We are impacting the possible users of IPfix by asking them to downgrade how feature rich their equipment can be. We are also asking for people to make their own extensions and go away from the standard. I think the IETF should think a little bit outside of the box here. regards, Reinaldo > >Thanks >Ganesh > >> >> ------_=_NextPart_001_01C1BE46.CACAC8C0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: in band configuration? RE: [ipfix-req] Proposed changes to = draft-ietf-ipfix-reqs-00.txt

Hello Ganesh/Peter,

comments inline..

>-----Original Message-----
>From: Ganesh Sadasivan [mailto:gsadasiv@cisco.com]=
>Sent: Monday, February 25, 2002 10:13 AM
>To: Peter Ludemann
>Cc: Benoit Claise; ipfix-req@net.doit.wisc.edu; = Gilby, Christian
>[SC9:0000:EXCH]
>Subject: Re: in band configuration? RE: = [ipfix-req] Proposed changes to
>draft-ietf-ipfix-reqs-00.txt
>
>
>Hi Peter,
>
>Peter Ludemann wrote:
>
>> Benoit Claise [mailto:bclaise@cisco.com] wrote = Tuesday,
>February 19, 2002
>> 2:46 AM:
>>
>> > I don't call this above "content = negotiation" but pure
>configuration.
>> > You tell the exporter which fields to = export by defining a
>template.
>>
>> So, shall we have an argument about = terminology? That's
>avoiding the point.
>>
>> It's more important that we discuss the = actual requirements.
>So far, I've
>> seen arguments in favour of both content = negotiation and in-band
>> configuration but the only arguments I've = seen against these
>seem to be "I
>> don't like it" or "it's not in = the charter". If I missed
>more substantive
>> arguments, please send me a reference ... = it would be nice
>to have something
>> a bit more persuasive.
>
>       to be = re-engineered to suit IPFIX protocol?
>   3. If there are 'n' exporters = trying to export to a
>collector, choosing the
>least common
>      fields among all = the exporters to define a common
>template of export from

This would be one option. The other option would be = the exporter use a different template for each collector, in order to = make the most of their implementation.

>the
>      collector is not = an easy task. Say the collector decides
>on a template,
>common to all
>      exporters and now = a new exporter joins which cannot
>support this set what
>is the
>      collector's = policy now? The choice of policies  varies
>greatly with
>applications
>      that finally use = this data. This has to be coupled with
>the understanding
>of how
>      metering is done = at the exporter.
> 4. In the routers, whose main job is to route = the packets
>with performance and
>     forwarding features as = the top priority,  making
>decisions as to which stack
>
>     to setup (TCP/SCTP) for = export, what security protocol
>should be used,
>     dynamically decide = what  templates/fields to
>accept/reject, dynamically
>modify
>     the export timers, = export rate, start peeking deeper into
>a packet which may
>
>     affect the performance, = though ideally achievable is too
>much an overhead.
>     I tend to beleive that = each service provider would be
>interested in defining
>
>     these decisions for the = routers in their own way and
>generalising any such
>     behavior may not add = much value, other than adding more
>complexity. It is
>    fairly trivial still to use = expect scripts and cron jobs
>to achieve the
>same;)


This argument is okay for traditional routers (for a = lack of a better word). The possible users for the IPfix protocol are = PC-probes, more intelligent edge routers, routers that offer middlebox = services, IPservices switches, etc

Deciding on a protocol that has the least functions = just to accomodate a single type of equipment is not the way to go. As = we said before, we can this part of the protocol optional.

We are impacting the possible users of IPfix by = asking them to downgrade how feature rich their equipment can be. We = are also asking for people to make their own extensions and go away = from the standard. I think the IETF should think a little bit outside = of the box here.

regards,

Reinaldo

>
>Thanks
>Ganesh
>
>>
>>

------_=_NextPart_001_01C1BE46.CACAC8C0-- -- 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 Feb 25 22:48:32 2002 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 WAA09176 for ; Mon, 25 Feb 2002 22:48:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fYGX-0004lN-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 21:26:57 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fYGV-0004jq-00 for ipfix-req@net.doit.wisc.edu; Mon, 25 Feb 2002 21:26:55 -0600 Received: from Kevinz (sdn-ar-006flmiamP326.dialsprint.net [63.180.76.232]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1Q3Rel06803; Mon, 25 Feb 2002 19:27:41 -0800 Reply-To: From: "Kevin Zhang" To: "Mark Fullmer" , "Peter Ludemann" Cc: Subject: RE: [ipfix-req] Collector Failover as a requirement Date: Mon, 25 Feb 2002 22:28:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020223235437.A84125@net.ohio-state.edu> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA09176 Hi Mark, Thanks for some very good ideas you offered, please see my comments inserted. Kevin > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Mark Fullmer > Sent: Saturday, February 23, 2002 11:55 PM > To: Peter Ludemann > Cc: ipfix-req@net.doit.wisc.edu > Subject: Re: [ipfix-req] Collector Failover as a requirement > > > On Sat, Feb 23, 2002 at 11:51:56AM -0800, Peter Ludemann wrote: > > TCP's keepalive is not sufficient for detecting loss of connectivity, as > > sections 4.2.0 and 4.2.1 suggest (there is no guarantee that a collector > > crash will send any kind of signal to the sender, which is why > TCP has such > > a complex start-up and shut-down; keepalive is not guaranteed to be > > A few suggestions to help aim at a middle ground between the > lightweight/best effort NetFlow (like) protocol vs. the > more resource intensive "reliable" drafts/implementations. > > o make the control connection in draft-gsadasiv-ipfix-proposal-00.txt > required and TCP. This removes the need for retransmits or > periodic updates of templates to the collector. When the collector > boots up it won't have to wait for templates. This also can > stop the router from generating flows to a non existant collector. > > o Implement a keepalive mechanism where the collector will ACK the > highest sequence number flow record it has processed per (any?) > "observation domain" The keepalive can be optional -- ie the > exporter can send a keepalive of N to inform the collector it > expects a keepalive every N seconds or 0 to disable it. Default > disabled. This is a very good idea. keepalive can be piggybacked through ACKs from collectors. This will not only serve as indication of collector fault conditions as well as congestion, it can also improve transport reliability. This should be done on the IPFIX protocol layer whether TCP or UDP is used as the transport protocol. > > o The exporter will send the collector a message on the control > connection indicating where to listen for flow records > (ie what protocol UDP/TCP/SCTP) and addressing information > (port, IP address). Must UDP May TCP/SCTP. The current IPFIX architecture draft from the design team proposed to use UDP to convey some low level information such as IPFIX version, transport protocol support, and port number. I think this could achieve this requirment. > > o Change the sequence number in draft-gsadasiv-ipfix-proposal-00.txt > to number of flows instead of number of packets so that the collector > can count lost flow records as in NetFlow v5,6,7,8. > Simply counting the lost flow records may not be enough as values associated with each record are different (e.g. start of a flow, end of a flow, interim records). We should really base our design over a reliable transport layer that offers congestion control. UDP can optionally be used for limited configurations. > o Ignore the configuration of the exporter issue for now, but implement > the control connection message format such that it can be > tackled later, or implemented by a vendor and then submitted for > IPFIX v2. Ie, require the exporter to NAK any messages sent by > the collector it can not decode. > I believe required control messages must be included in this version as options. For those exporting devices that can not support them, a simple reply from exporter to collector will signal the limitation of the exporter; then both devices will fall back to a setting that is less demanding on the exporter. > > mark > > -- > 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/ > > ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Mon Feb 25 22:48:53 2002 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 WAA09189 for ; Mon, 25 Feb 2002 22:48:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fYI8-0004oI-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 21:28:36 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fYI6-0004n8-00 for ipfix-arch@net.doit.wisc.edu; Mon, 25 Feb 2002 21:28:34 -0600 Received: from Kevinz (sdn-ar-006flmiamP326.dialsprint.net [63.180.76.232]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1Q3Rsl06812; Mon, 25 Feb 2002 19:27:54 -0800 Reply-To: From: "Kevin Zhang" To: "Reinaldo Penno" , , "Benoit Claise" Cc: , Subject: RE: [ipfix-arch] counter wrapping Date: Mon, 25 Feb 2002 22:28:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011B_01C1BE4B.CF482140" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4F973E944951D311B6660008C7917CF008C54725@zsc4c008.us.nortel.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_011B_01C1BE4B.CF482140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [ipfix-arch] counter wrappingHi Paul and Reinaldo, The data model draft should focus on the definition of various attributes or IEs, so that information collected is correctly exported and processed by downstream systems. How the informaiton is collected is out side our scope, as long as it conforms to the definition. I felt nother prevent us to introduce both counters (absolute and delta) in or document. Thanks, Kevin -----Original Message----- From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo Penno Sent: Monday, February 25, 2002 4:55 PM To: calato@riverstonenet.com; Benoit Claise Cc: n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] counter wrapping Hello Paul, Could we just have the two counters as proposed by Ganesh (absolute and delta)? An implementation would use one or the other as it sees fit. regards, Reinaldo >-----Original Message----- >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] >Sent: Monday, February 25, 2002 7:07 AM >To: Benoit Claise >Cc: n.brownlee@auckland.ac.nz; Penno, Reinaldo [SC9:T327:EXCH]; >ipfix-arch@net.doit.wisc.edu >Subject: Re: [ipfix-arch] counter wrapping > > > >Thought I would reply direct. > >I would check on that. Since the hardware >is the one that increments the counter as >packets are going through, the only way to >read the count and then set it to zero as >one operation would be to stop the hardware >from updating the counter while the read-set-to-zero >operation is happening. > >So either the netflow hardware really supports that >operation or a tradeoff was made to leave the issue >as is. > >It would be good to know as it affects how to best >accomplish intermediate updates should we go that way. > >Paul > >Benoit Claise wrote: >> >> Paul, >> >> calato@riverstonenet.com wrote: >> >> > Benoit Claise wrote: >> > > >> > > Nevil, >> > > >> > > n.brownlee@auckland.ac.nz wrote: >> > > >> > > > Hi Reinaldo: >> > > > >> > > > > b. avoid counter wrapping." >> > > > > >> > > > > This activity SHOULD be configurable. Btw, can >someone elaborate on the >> > > > > counter wrapping stuff? >> > > > > >> > > > > It is very simple to send so much data though the >line on a flow that the >> > > > > byte counter rolls over. This is very typical in 1 >gig and 10g ports. >> > > > > counter 32 is not large enough field size for this. >> > > > > >> > > > > yes, that's what I tought. So the solution is just >to augment th efield to a >> > > > > 64 counter. It seems that the peirodic reporting is >completely orthogonal to >> > > > > this specific issue. >> > > > >> > > > You've covered the 'counter wrapping' problem - a flow >information meter >> > > > (whatever that turns out to be) needs counters wide >enough not to wrap >> > > > too often, and that becomes more of a problem at high >link speeds. >> > > > In RTFM, all counts are kept in 64-bit unsigned >counters so that they >> > > > don't wrap too often. >> > > > >> > > > Of more interest, I don't remember seeing any IPFIX discussion >> > > > concerning just how information about long-running >flows is to be >> > > > exported. In particular, I believe that counters >should never be reset. >> > > >> > > Why? >> > > For long run flows, you can just export the flow records >with the acconting >> > > information seen during that interval. >> > > If you must export the flow records because: >> > > - you faced the long aging time timeout (for example: >30 minutes) >> > > - the counters is about to wrap. >> > > then you consider the flow to be ended (expired) and >export the accounting data >> > > for that period. >> > > Now a new flow with the same characterics will be >directly created. Not a problem. >> > > And you start the accounting from 0 for that "new" flow. >> > >> > Most hardware can't do a get and set in one >> > operation. So in between reading the count >> > and setting it to zero you may loose some >> > of the count. >> >> I'm not too sure about the details of most hardware, but >this is the way it works with >> netflow. >> >> Regards, Benoit >> >> > >> > >> > > The collector won't be confused at all and don't need to >remember any values. >> > > >> > > Regards, Benoit >> > > >> > > > >> > > > That would mean that successive exports of the same >flow would have >> > > > increasing counter values, a collector would need to >remember the >> > > > previous value and subtract it. Furthermore, provided unsigned >> > > > arithmetic is used, the difference is correct even if >the counter has >> > > > wrapped. Provided, of course that the counter has >only wrapped once! >> > > > >> > > > Cheers, Nevil >> > > > >> > > > >----------------------------------------------------------------------- >> > > > Nevil Brownlee Director, >Technology Development >> > > > Phone: +64 9 373 7599 x8941 ITSS, The >University of Auckland >> > > > FAX: +64 9 373 7021 Private Bag 92019, >Auckland, New Zealand >> > > > >> > > > -- >> > > > 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/ >> > > >> > > -- >> > > 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/ > ------=_NextPart_000_011B_01C1BE4B.CF482140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] counter wrapping
Hi=20 Paul and Reinaldo,
 
The=20 data model draft should focus on the definition of various attributes or = IEs, so=20 that information collected is correctly exported and processed by=20 downstream systems.  How the informaiton is collected is out side = our=20 scope, as long as it conforms to the definition.  I felt nother = prevent us=20 to introduce both counters (absolute and delta) in or=20 document.
 
Thanks,
 
Kevin
-----Original Message-----
From: majordomo = listserver=20 [mailto:majordomo@mil.doit.wisc.edu]On Behalf Of Reinaldo=20 Penno
Sent: Monday, February 25, 2002 4:55 PM
To:=20 calato@riverstonenet.com; Benoit Claise
Cc:=20 n.brownlee@auckland.ac.nz; = ipfix-arch@net.doit.wisc.edu
Subject: RE:=20 [ipfix-arch] counter wrapping

Hello Paul,

Could we just have the two counters as proposed by = Ganesh=20 (absolute and delta)? An implementation would use one or the other as = it sees=20 fit.

regards,

Reinaldo

>-----Original Message-----
>From: calato@riverstonenet.com [mailto:calato@riverstonenet.com<= /A>]=20
>Sent: Monday, February 25, 2002 7:07 AM =
>To: Benoit Claise
>Cc:=20 n.brownlee@auckland.ac.nz; Penno, Reinaldo [SC9:T327:EXCH]; =
>ipfix-arch@net.doit.wisc.edu
>Subject:=20 Re: [ipfix-arch] counter wrapping
>=20
>
> =
>Thought I would reply direct.
>=20
>I would check on that. Since the = hardware=20
>is the one that increments the counter = as=20
>packets are going through, the only way to=20
>read the count and then set it to zero = as=20
>one operation would be to stop the = hardware=20
>from updating the counter while the=20 read-set-to-zero
>operation is happening. =
>
>So either = the netflow=20 hardware really supports that
>operation = or a=20 tradeoff was made to leave the issue
>as = is.=20
>
>It would be good = to know as=20 it affects how to best
>accomplish = intermediate=20 updates should we go that way.
> =
>Paul
>
>Benoit Claise wrote:
>>=20
>> Paul,
>>=20
>> calato@riverstonenet.com = wrote:=20
>>
>> > = Benoit Claise=20 wrote:
>> > >
>> > > Nevil,
>> = >=20 >
>> > > = n.brownlee@auckland.ac.nz=20 wrote:
>> > >
>> > > > Hi Reinaldo:
>>=20 > > >
>> > > > > = b. avoid=20 counter wrapping."
>> > > > = >=20
>> > > > > This activity SHOULD = be=20 configurable. Btw, can
>someone elaborate = on=20 the
>> > > > > counter = wrapping=20 stuff?
>> > > > > =
>> > > > > It is very simple to send so = much data=20 though the
>line on a flow that = the=20
>> > > > > byte counter rolls = over. =20 This is very typical in 1
>gig and = 10g =20 ports.
>> > > > > counter = 32 is not=20 large enough field size for this.
>> = > >=20 > >
>> > > > > yes, = that's=20 what I tought. So the solution is just
>to augment=20 th efield to a
>> > > > > = 64=20 counter. It seems that the peirodic reporting is
>completely orthogonal to
>> > >=20 > > this specific issue.
>> > = >=20 >
>> > > > You've covered = the=20 'counter wrapping' problem - a flow
>information=20 meter
>> > > > (whatever that = turns out=20 to be) needs counters wide
>enough not to = wrap
>> > > > too often, and = that=20 becomes more of a problem at high
>link=20 speeds.
>> > > > In RTFM, all = counts=20 are kept in 64-bit unsigned
>counters so = that=20 they
>> > > > don't wrap too=20 often.
>> > > > =
>> > > > Of more interest, I don't remember = seeing any=20 IPFIX discussion
>> > > > = concerning=20 just how information about long-running
>flows is=20 to be
>> > > > = exported.  In=20 particular, I believe that counters
>should never=20 be reset.
>> > > =
>> > > Why?
>> = > > For=20 long run flows, you can just export the flow records
>with the acconting
>> = > >=20 information seen during that interval.
>> >=20 > If you must export the flow records because:
>> > >  - you faced the long aging time = timeout (for=20 example:
>30 minutes)
>> > >  - the counters is about to = wrap.=20
>> > > then you consider the flow to be = ended=20 (expired) and
>export the accounting = data=20
>> > > for that period. =
>> > > Now a new flow with the same characterics = will be=20
>directly created. Not a problem. =
>> > > And you start the accounting from 0 for = that "new"=20 flow.
>> >
>>=20 >         Most hardware = can't do a=20 get and set in one
>>=20 >         operation. So in = between=20 reading the count
>>=20 >         and setting it to = zero=20 you may loose some
>>=20 >         of the = count.=20
>>
>> I'm not = too sure=20 about the details of most hardware, but
>this is=20 the way it works with
>> = netflow.=20
>>
>> = Regards,=20 Benoit
>>
>>=20 >
>> >
>>=20 > > The collector won't be confused at all and don't need to=20
>remember any values.
>> > >
>> > = > Regards,=20 Benoit
>> > >
>> > > >
>> = > > >=20 That would mean that successive exports of the same
>flow would have
>> > = > >=20 increasing counter values, a collector would need to
>remember the
>> > > = >=20 previous value and subtract it.  Furthermore, provided = unsigned=20
>> > > > arithmetic is used, the = difference is=20 correct even if
>the counter has =
>> > > > wrapped.  Provided, of course = that the=20 counter has
>only wrapped once! =
>> > > >
>> = > > >=20 Cheers, Nevil
>> > > > =
>> > > >
>------------------------------------------------------------= -----------=20
>> > > >    Nevil=20 = Brownlee           = ;       =20 Director,
>Technology Development =
>> > > >    Phone: +64 9 373 = 7599=20 x8941      ITSS, The
>University of Auckland
>> = > >=20 >    FAX: +64 9 373 = 7021     =20 Private Bag 92019,
>Auckland, New = Zealand=20
>> > > >
>> >=20 > > --
>> > > >=20 Help        mailto:majordomo@net.doit.wis= c.edu=20 and say
>"help" in message body =
>> > > > Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
>> > > > "unsubscribe = ipfix" in=20 message body
>> > > >=20 Archive     http://ipfix.doit.wisc.edu/archive/ =
>> > >
>> > = > --=20
>> > >=20 Help        mailto:majordomo@net.doit.wis= c.edu=20 and say
>"help" in message body =
>> > > Unsubscribe mailto:majordomo@net.doit.wis= c.edu=20 and say
>> > > "unsubscribe = ipfix" in=20 message body
>> > >=20 Archive     http://ipfix.doit.wisc.edu/archive/ =
>

------=_NextPart_000_011B_01C1BE4B.CF482140-- -- 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 Feb 25 22:51:07 2002 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 WAA09237 for ; Mon, 25 Feb 2002 22:51:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fYH3-0004mI-00 for ipfix-list@mil.doit.wisc.edu; Mon, 25 Feb 2002 21:27:29 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fYH2-0004lO-00 for ipfix-req@net.doit.wisc.edu; Mon, 25 Feb 2002 21:27:28 -0600 Received: from Kevinz (sdn-ar-006flmiamP326.dialsprint.net [63.180.76.232]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1Q3Rkl06806; Mon, 25 Feb 2002 19:27:46 -0800 Reply-To: From: "Kevin Zhang" To: "Ganesh Sadasivan" , "Peter Ludemann" Cc: "Mark Fullmer" , Subject: RE: [ipfix-req] Collector Failover as a requirement Date: Mon, 25 Feb 2002 22:28:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C7A82AA.BD814C45@cisco.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA09237 Please see my comments inserted. Thanks, Kevin > -----Original Message----- > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > Of Ganesh Sadasivan > Sent: Monday, February 25, 2002 1:30 PM > To: Peter Ludemann > Cc: Mark Fullmer; ipfix-req@net.doit.wisc.edu > Subject: Re: [ipfix-req] Collector Failover as a requirement > > > Hi Peter, > > Peter Ludemann wrote: > > > My comments interspersed. > > > > > From: Mark Fullmer [mailto:maf@eng.oar.net] > > > Sent: Saturday, February 23, 2002 8:55 PM > > > To: Peter Ludemann > > > Cc: ipfix-req@net.doit.wisc.edu > > > Subject: Re: [ipfix-req] Collector Failover as a requirement > > > > > > > > > On Sat, Feb 23, 2002 at 11:51:56AM -0800, Peter Ludemann wrote: > > > > TCP's keepalive is not sufficient for detecting loss of > connectivity, as > > > > sections 4.2.0 and 4.2.1 suggest (there is no guarantee > that a collector > > > > crash will send any kind of signal to the sender, which is why > > > TCP has such > > > > a complex start-up and shut-down; keepalive is not guaranteed to be > > > > > > A few suggestions to help aim at a middle ground between the > > > lightweight/best effort NetFlow (like) protocol vs. the > > > more resource intensive "reliable" drafts/implementations. > > > > In a normal deployment, with the collector close to the sender, > "reliable" > > isn't more resource-intensive. And TCP is a reasonable choice; the > > latest NFS is done over TCP because it's as efficient as using > > UDP and avoids re-inventing wheels for things like congestion control. > > When a connection is broken, TCP uses longer and longer intervals when > > retransmitting, so the execution overhead remains small. > > What is a "normal deployment"? TCP is not as efficient as UDP in terms > of processing requirements (this should be fairly obvious). Well if the > network is reliable enough, I think UDP would work out better. > I really doubt we can assume the network is reliable. The potential deployment of IPFIX systems will involve WAN, and including exporting devices such as probes, mid-boxes etc. Let's not limit ourselves too much at this time. Another issue with UDP is that it is not congestion aware, it can interfere with network traffics from other sources. This is clearly required in our charter. > > > > > > Having said that, it is impossible to make a 100% reliable system. > > If connections go down, eventually there will be no more room inside > > the sender to store data, so some data must be discarded. The protocol > > must be able to detect this and inform the receiver (when things are > > reconnected). > > > > One more thing about unreliable protocols ... they're > attractive in theory > > but in practice we find ourselves building workarounds to make them > > seem reliable (this applies to both NetFlow and SNMP). Any data delivery > > method that avoids reliability simply pushes things on to another > > part of the system. > > I am curious to know the workarounds done on top of Netflow to make it > relaible? > With TCP and SCTP widely availabe, what's the point to replicate many of their features over UDP. > > > > > > > o make the control connection in > draft-gsadasiv-ipfix-proposal-00.txt > > > required and TCP. This removes the need for retransmits or > > > periodic updates of templates to the collector. When the > collector > > > boots up it won't have to wait for templates. This also can > > > stop the router from generating flows to a non existant collector. > > > > I don't think that only TCP should be required. I would also allow SCTP > > ... it's better than TCP for fail-over, but not widely available yet. > > > > > o Implement a keepalive mechanism where the collector will ACK the > > > highest sequence number flow record it has processed per (any?) > > > "observation domain" The keepalive can be optional -- ie the > > > exporter can send a keepalive of N to inform the collector it > > > expects a keepalive every N seconds or 0 to disable it. Default > > > disabled. > > > > This is essentially the way that CRANE works. However, I don't think > > that a keepalive gives any advantage ... the sender should just time > > out and failover if it doesn't receive a data ACK in time (there's no > > need for keepalives when no data are being sent). [Downstream > > deduplication will always be needed for handling failures because > > ACKs can get lost.] > > > > [I'm currently doing some experiments on the best way to do ACKs to > > get the fastest failover; so I reserve the right to change my mind > > about heartbeet keepalives.] > > > > > o The exporter will send the collector a message on the control > > > connection indicating where to listen for flow records > > > (ie what protocol UDP/TCP/SCTP) and addressing information > > > (port, IP address). Must UDP May TCP/SCTP. > > > > The initial message can also advertise the protocol version. > > > > > I would be opposed to UDP for data delivery. I don't see any > > performance advantages and it causes a lot of downstream > > processing pain. > > Can you explain a little more here? > Without adding features over UDP, IPFIX over UDP would be unreliable, congestion UN-aware, incapable of supporting redundancy configurations, and more. > > > > > > > > o Change the sequence number in draft-gsadasiv-ipfix-proposal-00.txt > > > to number of flows instead of number of packets so that > the collector > > > can count lost flow records as in NetFlow v5,6,7,8. > > There are other means to achive the same in the new protocol. > Basically the > flowsets tell the length and using the size of each record in the > flowset, one > can calculate the # of records. > > > > > > > Access to the packet count is not possible with most TCP implementations > > anyway. > > > > > o Ignore the configuration of the exporter issue for now, > but implement > > > the control connection message format such that it can be > > > tackled later, or implemented by a vendor and then submitted for > > > IPFIX v2. Ie, require the exporter to NAK any messages sent by > > > the collector it can not decode. > > > > I believe that content negotiation is important for reasons of > performance > > and synchronizing amongst receivers in a fail-over setup. Other in-band > > configuration is less important (it can be done via MIBS but is also > > easier to define in a generic way (essentially a set of keyword/value > > pairs that must be all handled as a single transaction ... like SNMP > > SET but with database-style transaction control). > > > > I would like to see in v1: > > - a standard data protocol (with generic configuration) using TCP > > for transport > > - a core set of values and types (the "data model") > > and in v2: > > - other transport protocols (such as SCTP) > > - additional standard values and types > > - additional standard kinds of configuration > > > > The v1 protocol must allow this future extensibility. > > inband config and content negotiation I already replied to your > previous mail. I am not convinced it is worth adding it in this > framework. > Thanks > Ganesh > > > > > > > > > > > > > mark > > > > - peter > > > > ---------- > > Peter Ludemann +1.408.330.5732 > > Chief Architect +1.650.248.3973 (mobile) > > XACCT Technologies peter.ludemann@xacct.com > > 2900 Lakeside Drive http://www.xacct.com > > Santa Clara CA 95054 > > > > -- > > 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/ > > > -- > 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/ > > > ÿñÞ–™šŠ[hþf£¢·hšçzßÝ¢+ÿÂ+ýçnjwlk/ázZÿŠyž²Æ yºÉIì¹»®&Þ™¨¥¶æj:+v‰¨þw­ýÚ"·ü"±ÏÞvæ§vƲþéì¹»®&ÞŠ—âÇø§™ë,j›¡Ü€­Èb½èm¶Ÿÿþ*_‹Ý¢+ÿÂ+ýçnýªÜ†+Þ From majordomo@mil.doit.wisc.edu Tue Feb 26 08:22:45 2002 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 IAA27940 for ; Tue, 26 Feb 2002 08:22:44 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fhBj-0002vB-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 06:58:35 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fhBg-0002uY-00; Tue, 26 Feb 2002 06:58:32 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QCrWB10318; Tue, 26 Feb 2002 06:53:32 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 04:53:30 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008C54A47@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: kevin.zhang@xacct.com, calato@riverstonenet.com, Benoit Claise Cc: n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu Subject: [ipfix-arch] IPfix candidates and Intellectual Property Rights Date: Tue, 26 Feb 2002 04:53:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEC4.97085E20" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BEC4.97085E20 Content-Type: text/plain; charset="ISO-8859-1" Hello, some down to earth question. Which of the candidate protocols (CRANE, LFAP, Netflow, others) have Intellectual Property Rights attached to it and what is the guidance of this WG on this subject? If two or more proposals are technically equivalent and one has no IPR we choose the one without IPR? thanks, Reinaldo ------_=_NextPart_001_01C1BEC4.97085E20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable IPfix candidates and Intellectual Property Rights

Hello,

some down to earth question. Which of the candidate = protocols (CRANE, LFAP, Netflow, others) have Intellectual Property = Rights attached to it and what is the guidance of this WG on this = subject? If two or more proposals are technically equivalent and one = has no IPR we choose the one without IPR?

thanks,

Reinaldo

------_=_NextPart_001_01C1BEC4.97085E20-- -- 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 Tue Feb 26 08:47:07 2002 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 IAA29095 for ; Tue, 26 Feb 2002 08:47:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fhaz-0003W2-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 07:24:41 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fhBg-0002uY-00; Tue, 26 Feb 2002 06:58:32 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QCrWB10318; Tue, 26 Feb 2002 06:53:32 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 04:53:30 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008C54A47@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: kevin.zhang@xacct.com, calato@riverstonenet.com, Benoit Claise Cc: n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu Subject: [ipfix-req] IPfix candidates and Intellectual Property Rights Date: Tue, 26 Feb 2002 04:53:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEC4.97085E20" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BEC4.97085E20 Content-Type: text/plain; charset="ISO-8859-1" Hello, some down to earth question. Which of the candidate protocols (CRANE, LFAP, Netflow, others) have Intellectual Property Rights attached to it and what is the guidance of this WG on this subject? If two or more proposals are technically equivalent and one has no IPR we choose the one without IPR? thanks, Reinaldo ------_=_NextPart_001_01C1BEC4.97085E20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable IPfix candidates and Intellectual Property Rights

Hello,

some down to earth question. Which of the candidate = protocols (CRANE, LFAP, Netflow, others) have Intellectual Property = Rights attached to it and what is the guidance of this WG on this = subject? If two or more proposals are technically equivalent and one = has no IPR we choose the one without IPR?

thanks,

Reinaldo

------_=_NextPart_001_01C1BEC4.97085E20-- -- 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 Tue Feb 26 17:55:11 2002 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 RAA24124 for ; Tue, 26 Feb 2002 17:55:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fqEj-0005mr-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 16:38:17 -0600 Received: from c001-h023.c001.snv.cp.net ([209.228.32.138] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16fqEf-0005m4-00 for ipfix-arch@net.doit.wisc.edu; Tue, 26 Feb 2002 16:38:13 -0600 Received: (cpmta 20865 invoked from network); 26 Feb 2002 14:37:42 -0800 Date: 26 Feb 2002 14:37:42 -0800 Message-ID: <20020226223742.20864.cpmta@c001.snv.cp.net> X-Sent: 26 Feb 2002 22:37:42 GMT Received: from [12.25.1.117] by mail.norseth.com with HTTP; 26 Feb 2002 14:37:42 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: reinaldo_penno@nortelnetworks.com From: kcn@norseth.com Cc: kevin.zhang@xacct.com, calato@riverstonenet.com, bclaise@cisco.com, n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu X-Mailer: Web Mail 3.9.3.5 Subject: [ipfix-arch] Re: [ipfix-req] IPfix candidates and Intellectual Property Rights X-Sent-From: kcn@norseth.com Precedence: bulk Sender: majordomo listserver Reinaldo, Enclosed is the IETF policy. http://www.ietf.org/ipr.html The IPFIX protocol has to be open so it can be accepted by all. On Tue, 26 February 2002, "Reinaldo Penno" wrote: > Subject: [ipfix-req] IPfix candidates and Intellectual Property Rights > Sender: majordomo listserver > To: kevin.zhang@xacct.com, calato@riverstonenet.com, > Benoit Claise > > Delivered-To: norseth.com%kcn@norseth.com > From: "Reinaldo Penno" > Cc: n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, > ipfix-req@net.doit.wisc.edu > Received: (cpmta 8313 invoked from network); 26 Feb 2002 05:39:31 -0800 > Received: from 128.104.31.31 (HELO mil.doit.wisc.edu) > by smtp.c001.snv.cp.net (209.228.32.108) with SMTP; 26 Feb 2002 05:39:31 -0800 > Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) > id 16fhaz-0003W2-00 > for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 07:24:41 -0600 > Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) > by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) > id 16fhBg-0002uY-00; Tue, 26 Feb 2002 06:58:32 -0600 > Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) > by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QCrWB10318; > Tue, 26 Feb 2002 06:53:32 -0600 (CST) > Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) > id ; Tue, 26 Feb 2002 04:53:30 -0800 > Return-Path: > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C1BEC4.97085E20" > Mime-Version: 1.0 > X-Received: 26 Feb 2002 13:39:31 GMT > Date: Tue, 26 Feb 2002 04:53:29 -0800 > Precedence: bulk > Message-Id: <4F973E944951D311B6660008C7917CF008C54A47@zsc4c008.us.nortel.com> > X-Mailer: Internet Mail Service (5.5.2653.19) > > > > > > > IPfix candidates and Intellectual Property Rights > > > >

Hello, >

> >

some down to earth question. Which of the candidate protocols (CRANE, LFAP, Netflow, others) have Intellectual Property Rights attached to it and what is the guidance of this WG on this subject? If two or more proposals are technically equivalent and one has no IPR we choose the one without IPR?

> >

thanks, >

> >

Reinaldo >

> > > -- 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 Tue Feb 26 17:55:24 2002 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 RAA24138 for ; Tue, 26 Feb 2002 17:55:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fqEi-0005mq-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 16:38:16 -0600 Received: from c001-h023.c001.snv.cp.net ([209.228.32.138] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16fqEf-0005m3-00 for ipfix-req@net.doit.wisc.edu; Tue, 26 Feb 2002 16:38:13 -0600 Received: (cpmta 20865 invoked from network); 26 Feb 2002 14:37:42 -0800 Date: 26 Feb 2002 14:37:42 -0800 Message-ID: <20020226223742.20864.cpmta@c001.snv.cp.net> X-Sent: 26 Feb 2002 22:37:42 GMT Received: from [12.25.1.117] by mail.norseth.com with HTTP; 26 Feb 2002 14:37:42 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: reinaldo_penno@nortelnetworks.com From: kcn@norseth.com Cc: kevin.zhang@xacct.com, calato@riverstonenet.com, bclaise@cisco.com, n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu X-Mailer: Web Mail 3.9.3.5 Subject: Re: [ipfix-req] IPfix candidates and Intellectual Property Rights X-Sent-From: kcn@norseth.com Precedence: bulk Sender: majordomo listserver Reinaldo, Enclosed is the IETF policy. http://www.ietf.org/ipr.html The IPFIX protocol has to be open so it can be accepted by all. On Tue, 26 February 2002, "Reinaldo Penno" wrote: > Subject: [ipfix-req] IPfix candidates and Intellectual Property Rights > Sender: majordomo listserver > To: kevin.zhang@xacct.com, calato@riverstonenet.com, > Benoit Claise > > Delivered-To: norseth.com%kcn@norseth.com > From: "Reinaldo Penno" > Cc: n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, > ipfix-req@net.doit.wisc.edu > Received: (cpmta 8313 invoked from network); 26 Feb 2002 05:39:31 -0800 > Received: from 128.104.31.31 (HELO mil.doit.wisc.edu) > by smtp.c001.snv.cp.net (209.228.32.108) with SMTP; 26 Feb 2002 05:39:31 -0800 > Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) > id 16fhaz-0003W2-00 > for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 07:24:41 -0600 > Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) > by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) > id 16fhBg-0002uY-00; Tue, 26 Feb 2002 06:58:32 -0600 > Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) > by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QCrWB10318; > Tue, 26 Feb 2002 06:53:32 -0600 (CST) > Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) > id ; Tue, 26 Feb 2002 04:53:30 -0800 > Return-Path: > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C1BEC4.97085E20" > Mime-Version: 1.0 > X-Received: 26 Feb 2002 13:39:31 GMT > Date: Tue, 26 Feb 2002 04:53:29 -0800 > Precedence: bulk > Message-Id: <4F973E944951D311B6660008C7917CF008C54A47@zsc4c008.us.nortel.com> > X-Mailer: Internet Mail Service (5.5.2653.19) > > > > > > > IPfix candidates and Intellectual Property Rights > > > >

Hello, >

> >

some down to earth question. Which of the candidate protocols (CRANE, LFAP, Netflow, others) have Intellectual Property Rights attached to it and what is the guidance of this WG on this subject? If two or more proposals are technically equivalent and one has no IPR we choose the one without IPR?

> >

thanks, >

> >

Reinaldo >

> > > -- 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 Tue Feb 26 18:02:42 2002 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 SAA24316 for ; Tue, 26 Feb 2002 18:02:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fqOT-0005zx-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 16:48:21 -0600 Received: from c001-h023.c001.snv.cp.net ([209.228.32.138] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16fqOR-0005yt-00 for ipfix-arch@net.doit.wisc.edu; Tue, 26 Feb 2002 16:48:19 -0600 Received: (cpmta 21259 invoked from network); 26 Feb 2002 14:47:48 -0800 Date: 26 Feb 2002 14:47:48 -0800 Message-ID: <20020226224748.21258.cpmta@c001.snv.cp.net> X-Sent: 26 Feb 2002 22:47:48 GMT Received: from [12.25.1.117] by mail.norseth.com with HTTP; 26 Feb 2002 14:47:48 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: reinaldo_penno@nortelnetworks.com From: kcn@norseth.com Cc: kevin.zhang@xacct.com, calato@riverstonenet.com, bclaise@cisco.com, n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu X-Mailer: Web Mail 3.9.3.5 Subject: [ipfix-arch] RE: [ipfix-req] IPfix candidates and Intellectual Property Rights X-Sent-From: kcn@norseth.com Precedence: bulk Sender: majordomo listserver I see what you mean. IPR is assumed, where the whatever protocol is going to assume the name IPFIX. If they cannot release the IPR, then that cannot become the IPFIX protocol. IPFIX belongs to the IETF. K.C. On Tue, 26 February 2002, "Reinaldo Penno" wrote: > Subject: RE: [ipfix-req] IPfix candidates and Intellectual Property Rights > Return-Path: > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C1BF17.3D526E90" > Mime-Version: 1.0 > To: kcn@norseth.com > X-Received: 26 Feb 2002 22:45:15 GMT > Delivered-To: norseth.com%kcn@norseth.com > From: "Reinaldo Penno" > Date: Tue, 26 Feb 2002 14:45:07 -0800 > Cc: kevin.zhang@xacct.com, calato@riverstonenet.com, bclaise@cisco.com, > n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, > ipfix-req@net.doit.wisc.edu > Message-Id: <4F973E944951D311B6660008C7917CF008C5510A@zsc4c008.us.nortel.com> > X-Mailer: Internet Mail Service (5.5.2653.19) > Received: (cpmta 20332 invoked from network); 26 Feb 2002 14:45:15 -0800 > Received: from 47.103.122.112 (HELO zrc2s0jx.nortelnetworks.com) > by smtp.c001.snv.cp.net (209.228.32.110) with SMTP; 26 Feb 2002 14:45:15 -0800 > Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) > by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QMjBa00717; > Tue, 26 Feb 2002 16:45:11 -0600 (CST) > Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) > id ; Tue, 26 Feb 2002 14:45:08 -0800 > > > > > > > RE: [ipfix-req] IPfix candidates and Intellectual Property Rights > > > >

Hello K.C. >

> >

I do not want to be picky, but what's the definition on "open"? Does it mean it's *free* of charge or that it can be licensed to anyone? You know, these two things make a lot of difference.(;-)

> >

I cheked the three drafts and it seems none of them have IPR statements. I think that if you have a IPR you need to put a statement on your draft...

> >

thanks, >

> >

Reinaldo >

>
>
> >

>-----Original Message----- >
>From: kcn@norseth.com [mailto:kcn@norseth.com] >
>Sent: Tuesday, February 26, 2002 2:38 PM >
>To: Penno, Reinaldo [SC9:T327:EXCH] >
>Cc: kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com; >
>n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu; >
>ipfix-req@net.doit.wisc.edu >
>Subject: Re: [ipfix-req] IPfix candidates and Intellectual Property >
>Rights >
> >
> >
>Reinaldo, >
> >
>Enclosed is the IETF policy. >
>   http://www.ietf.org/ipr.html >
> >
>The IPFIX protocol has to be open so it can be accepted by all. >
> >
>On Tue, 26 February 2002, "Reinaldo Penno" wrote: >
> >

> > > -- 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 Tue Feb 26 18:03:21 2002 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 SAA24335 for ; Tue, 26 Feb 2002 18:03:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fqOT-0005zw-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 16:48:22 -0600 Received: from c001-h023.c001.snv.cp.net ([209.228.32.138] helo=c001.snv.cp.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 16fqOR-0005yu-00 for ipfix-req@net.doit.wisc.edu; Tue, 26 Feb 2002 16:48:19 -0600 Received: (cpmta 21259 invoked from network); 26 Feb 2002 14:47:48 -0800 Date: 26 Feb 2002 14:47:48 -0800 Message-ID: <20020226224748.21258.cpmta@c001.snv.cp.net> X-Sent: 26 Feb 2002 22:47:48 GMT Received: from [12.25.1.117] by mail.norseth.com with HTTP; 26 Feb 2002 14:47:48 PST Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 To: reinaldo_penno@nortelnetworks.com From: kcn@norseth.com Cc: kevin.zhang@xacct.com, calato@riverstonenet.com, bclaise@cisco.com, n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu X-Mailer: Web Mail 3.9.3.5 Subject: RE: [ipfix-req] IPfix candidates and Intellectual Property Rights X-Sent-From: kcn@norseth.com Precedence: bulk Sender: majordomo listserver I see what you mean. IPR is assumed, where the whatever protocol is going to assume the name IPFIX. If they cannot release the IPR, then that cannot become the IPFIX protocol. IPFIX belongs to the IETF. K.C. On Tue, 26 February 2002, "Reinaldo Penno" wrote: > Subject: RE: [ipfix-req] IPfix candidates and Intellectual Property Rights > Return-Path: > Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C1BF17.3D526E90" > Mime-Version: 1.0 > To: kcn@norseth.com > X-Received: 26 Feb 2002 22:45:15 GMT > Delivered-To: norseth.com%kcn@norseth.com > From: "Reinaldo Penno" > Date: Tue, 26 Feb 2002 14:45:07 -0800 > Cc: kevin.zhang@xacct.com, calato@riverstonenet.com, bclaise@cisco.com, > n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, > ipfix-req@net.doit.wisc.edu > Message-Id: <4F973E944951D311B6660008C7917CF008C5510A@zsc4c008.us.nortel.com> > X-Mailer: Internet Mail Service (5.5.2653.19) > Received: (cpmta 20332 invoked from network); 26 Feb 2002 14:45:15 -0800 > Received: from 47.103.122.112 (HELO zrc2s0jx.nortelnetworks.com) > by smtp.c001.snv.cp.net (209.228.32.110) with SMTP; 26 Feb 2002 14:45:15 -0800 > Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) > by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QMjBa00717; > Tue, 26 Feb 2002 16:45:11 -0600 (CST) > Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) > id ; Tue, 26 Feb 2002 14:45:08 -0800 > > > > > > > RE: [ipfix-req] IPfix candidates and Intellectual Property Rights > > > >

Hello K.C. >

> >

I do not want to be picky, but what's the definition on "open"? Does it mean it's *free* of charge or that it can be licensed to anyone? You know, these two things make a lot of difference.(;-)

> >

I cheked the three drafts and it seems none of them have IPR statements. I think that if you have a IPR you need to put a statement on your draft...

> >

thanks, >

> >

Reinaldo >

>
>
> >

>-----Original Message----- >
>From: kcn@norseth.com [mailto:kcn@norseth.com] >
>Sent: Tuesday, February 26, 2002 2:38 PM >
>To: Penno, Reinaldo [SC9:T327:EXCH] >
>Cc: kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com; >
>n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu; >
>ipfix-req@net.doit.wisc.edu >
>Subject: Re: [ipfix-req] IPfix candidates and Intellectual Property >
>Rights >
> >
> >
>Reinaldo, >
> >
>Enclosed is the IETF policy. >
>   http://www.ietf.org/ipr.html >
> >
>The IPFIX protocol has to be open so it can be accepted by all. >
> >
>On Tue, 26 February 2002, "Reinaldo Penno" wrote: >
> >

> > > -- 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 Tue Feb 26 18:04:18 2002 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 SAA24350 for ; Tue, 26 Feb 2002 18:04:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fqPG-00060n-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 16:49:10 -0600 Received: from rip.psg.com ([147.28.0.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fqPE-00060E-00; Tue, 26 Feb 2002 16:49:08 -0600 Received: from randy by rip.psg.com with local (Exim 4.00) id 16fqOi-000EC6-00; Tue, 26 Feb 2002 14:48:36 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kcn@norseth.com Cc: ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-arch] Re: [ipfix-req] IPfix candidates and Intellectual Property Rights References: <20020226223742.20864.cpmta@c001.snv.cp.net> Message-Id: Date: Tue, 26 Feb 2002 14:48:36 -0800 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- 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 Tue Feb 26 18:05:08 2002 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 SAA24367 for ; Tue, 26 Feb 2002 18:05:07 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fqQZ-000630-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 16:50:31 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fqQX-00061Y-00; Tue, 26 Feb 2002 16:50:29 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QMjBa00717; Tue, 26 Feb 2002 16:45:11 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 14:45:08 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008C5510A@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: kcn@norseth.com Cc: kevin.zhang@xacct.com, calato@riverstonenet.com, bclaise@cisco.com, n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu Subject: [ipfix-arch] RE: [ipfix-req] IPfix candidates and Intellectual Property Rights Date: Tue, 26 Feb 2002 14:45:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BF17.3D526E90" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BF17.3D526E90 Content-Type: text/plain; charset="ISO-8859-1" Hello K.C. I do not want to be picky, but what's the definition on "open"? Does it mean it's *free* of charge or that it can be licensed to anyone? You know, these two things make a lot of difference.(;-) I cheked the three drafts and it seems none of them have IPR statements. I think that if you have a IPR you need to put a statement on your draft... thanks, Reinaldo >-----Original Message----- >From: kcn@norseth.com [mailto:kcn@norseth.com] >Sent: Tuesday, February 26, 2002 2:38 PM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com; >n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu; >ipfix-req@net.doit.wisc.edu >Subject: Re: [ipfix-req] IPfix candidates and Intellectual Property >Rights > > >Reinaldo, > >Enclosed is the IETF policy. > http://www.ietf.org/ipr.html > >The IPFIX protocol has to be open so it can be accepted by all. > >On Tue, 26 February 2002, "Reinaldo Penno" wrote: > ------_=_NextPart_001_01C1BF17.3D526E90 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-req] IPfix candidates and Intellectual Property = Rights

Hello K.C.

I do not want to be picky, but what's the definition = on "open"? Does it mean it's *free* of charge or that it can = be licensed to anyone? You know, these two things make a lot of = difference.(;-)

I cheked the three drafts and it seems none of them = have IPR statements. I think that if you have a IPR you need to put a = statement on your draft...

thanks,

Reinaldo



>-----Original Message-----
>From: kcn@norseth.com [mailto:kcn@norseth.com]
>Sent: Tuesday, February 26, 2002 2:38 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: kevin.zhang@xacct.com; = calato@riverstonenet.com; bclaise@cisco.com;
>n.brownlee@auckland.ac.nz; = ipfix-arch@net.doit.wisc.edu;
>ipfix-req@net.doit.wisc.edu
>Subject: Re: [ipfix-req] IPfix candidates and = Intellectual Property
>Rights
>
>
>Reinaldo,
>
>Enclosed is the IETF policy.
>   http://www.ietf.org/ipr.html
>
>The IPFIX protocol has to be open so it can be = accepted by all.
>
>On Tue, 26 February 2002, "Reinaldo = Penno" wrote:
>

------_=_NextPart_001_01C1BF17.3D526E90-- -- 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 Tue Feb 26 18:30:17 2002 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 SAA24925 for ; Tue, 26 Feb 2002 18:30:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fqgU-0006TR-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 17:06:58 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fqQX-00061Y-00; Tue, 26 Feb 2002 16:50:29 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QMjBa00717; Tue, 26 Feb 2002 16:45:11 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 14:45:08 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008C5510A@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: kcn@norseth.com Cc: kevin.zhang@xacct.com, calato@riverstonenet.com, bclaise@cisco.com, n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] IPfix candidates and Intellectual Property Rights Date: Tue, 26 Feb 2002 14:45:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BF17.3D526E90" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BF17.3D526E90 Content-Type: text/plain; charset="ISO-8859-1" Hello K.C. I do not want to be picky, but what's the definition on "open"? Does it mean it's *free* of charge or that it can be licensed to anyone? You know, these two things make a lot of difference.(;-) I cheked the three drafts and it seems none of them have IPR statements. I think that if you have a IPR you need to put a statement on your draft... thanks, Reinaldo >-----Original Message----- >From: kcn@norseth.com [mailto:kcn@norseth.com] >Sent: Tuesday, February 26, 2002 2:38 PM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com; >n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu; >ipfix-req@net.doit.wisc.edu >Subject: Re: [ipfix-req] IPfix candidates and Intellectual Property >Rights > > >Reinaldo, > >Enclosed is the IETF policy. > http://www.ietf.org/ipr.html > >The IPFIX protocol has to be open so it can be accepted by all. > >On Tue, 26 February 2002, "Reinaldo Penno" wrote: > ------_=_NextPart_001_01C1BF17.3D526E90 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-req] IPfix candidates and Intellectual Property = Rights

Hello K.C.

I do not want to be picky, but what's the definition = on "open"? Does it mean it's *free* of charge or that it can = be licensed to anyone? You know, these two things make a lot of = difference.(;-)

I cheked the three drafts and it seems none of them = have IPR statements. I think that if you have a IPR you need to put a = statement on your draft...

thanks,

Reinaldo



>-----Original Message-----
>From: kcn@norseth.com [mailto:kcn@norseth.com]
>Sent: Tuesday, February 26, 2002 2:38 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc: kevin.zhang@xacct.com; = calato@riverstonenet.com; bclaise@cisco.com;
>n.brownlee@auckland.ac.nz; = ipfix-arch@net.doit.wisc.edu;
>ipfix-req@net.doit.wisc.edu
>Subject: Re: [ipfix-req] IPfix candidates and = Intellectual Property
>Rights
>
>
>Reinaldo,
>
>Enclosed is the IETF policy.
>   http://www.ietf.org/ipr.html
>
>The IPFIX protocol has to be open so it can be = accepted by all.
>
>On Tue, 26 February 2002, "Reinaldo = Penno" wrote:
>

------_=_NextPart_001_01C1BF17.3D526E90-- -- 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 Tue Feb 26 18:37:04 2002 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 SAA25057 for ; Tue, 26 Feb 2002 18:37:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fqfc-0006S8-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 17:06:04 -0600 Received: from rip.psg.com ([147.28.0.39]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fqPE-00060E-00; Tue, 26 Feb 2002 16:49:08 -0600 Received: from randy by rip.psg.com with local (Exim 4.00) id 16fqOi-000EC6-00; Tue, 26 Feb 2002 14:48:36 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: kcn@norseth.com Cc: ipfix-arch@net.doit.wisc.edu, ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-arch] Re: [ipfix-req] IPfix candidates and Intellectual Property Rights References: <20020226223742.20864.cpmta@c001.snv.cp.net> Message-Id: Date: Tue, 26 Feb 2002 14:48:36 -0800 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit NOTE WELL: All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -- 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 Tue Feb 26 23:09:24 2002 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 XAA01559 for ; Tue, 26 Feb 2002 23:09:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fv7u-0004lN-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 21:51:34 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fv7r-0004kC-00; Tue, 26 Feb 2002 21:51:31 -0600 Received: from Kevinz (sdn-ar-006flmiamP030.dialsprint.net [63.180.117.142]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1R3pIl15326; Tue, 26 Feb 2002 19:51:19 -0800 Reply-To: From: "Kevin Zhang" To: "Reinaldo Penno" , Cc: , , , , , Subject: [ipfix-arch] RE: [ipfix-req] IPfix candidates and Intellectual Property Rights Date: Tue, 26 Feb 2002 22:49:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010C_01C1BF17.D2888580" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4F973E944951D311B6660008C7917CF008C5510A@zsc4c008.us.nortel.com> Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_010C_01C1BF17.D2888580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [ipfix-req] IPfix candidates and Intellectual Property RightsHi Reinaldo, As CRANE specification exists as an I-D, we are complying to all the IETF rules w.r.t. IPR. I will include the IPR statement in a future version of the CRANE draft. Thanks, Kevin -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 26, 2002 5:45 PM To: kcn@norseth.com Cc: kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com; n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu; ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] IPfix candidates and Intellectual Property Rights Hello K.C. I do not want to be picky, but what's the definition on "open"? Does it mean it's *free* of charge or that it can be licensed to anyone? You know, these two things make a lot of difference.(;-) I cheked the three drafts and it seems none of them have IPR statements. I think that if you have a IPR you need to put a statement on your draft... thanks, Reinaldo >-----Original Message----- >From: kcn@norseth.com [mailto:kcn@norseth.com] >Sent: Tuesday, February 26, 2002 2:38 PM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com; >n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu; >ipfix-req@net.doit.wisc.edu >Subject: Re: [ipfix-req] IPfix candidates and Intellectual Property >Rights > > >Reinaldo, > >Enclosed is the IETF policy. > http://www.ietf.org/ipr.html > >The IPFIX protocol has to be open so it can be accepted by all. > >On Tue, 26 February 2002, "Reinaldo Penno" wrote: > ------=_NextPart_000_010C_01C1BF17.D2888580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-req] IPfix candidates and Intellectual = Property Rights
Hi=20 Reinaldo,
 
As=20 CRANE specification exists as an I-D, we are complying to all the IETF = rules=20 w.r.t. IPR.  I will include the IPR statement in a future version = of the=20 CRANE draft.
 
Thanks,
 
Kevin
-----Original Message-----
From: Reinaldo Penno=20 [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, = February=20 26, 2002 5:45 PM
To: kcn@norseth.com
Cc:=20 kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com;=20 n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu;=20 ipfix-req@net.doit.wisc.edu
Subject: RE: [ipfix-req] IPfix=20 candidates and Intellectual Property Rights

Hello K.C.

I do not want to be picky, but what's the definition = on=20 "open"? Does it mean it's *free* of charge or that it can be licensed = to=20 anyone? You know, these two things make a lot of = difference.(;-)

I cheked the three drafts and it seems none of them = have IPR=20 statements. I think that if you have a IPR you need to put a statement = on your=20 draft...

thanks,

Reinaldo



>-----Original Message-----
>From: kcn@norseth.com [mailto:kcn@norseth.com] =
>Sent: Tuesday, February 26, 2002 2:38 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc:=20 kevin.zhang@xacct.com; calato@riverstonenet.com; = bclaise@cisco.com;=20
>n.brownlee@auckland.ac.nz;=20 ipfix-arch@net.doit.wisc.edu;
>ipfix-req@net.doit.wisc.edu
>Subject:=20 Re: [ipfix-req] IPfix candidates and Intellectual Property =
>Rights
>
>
>Reinaldo,
>
>Enclosed is the IETF = policy.=20
>   http://www.ietf.org/ipr.html
>
>The IPFIX protocol has to = be open so=20 it can be accepted by all.
> =
>On Tue, 26 February 2002, "Reinaldo Penno" wrote: =
>

------=_NextPart_000_010C_01C1BF17.D2888580-- -- 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 Tue Feb 26 23:26:06 2002 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 XAA01920 for ; Tue, 26 Feb 2002 23:26:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16fvRB-0005DQ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 26 Feb 2002 22:11:29 -0600 Received: from usmail.xacct.com ([204.253.100.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16fv7r-0004kC-00; Tue, 26 Feb 2002 21:51:31 -0600 Received: from Kevinz (sdn-ar-006flmiamP030.dialsprint.net [63.180.117.142]) by usmail.xacct.com (8.11.2/8.11.2) with SMTP id g1R3pIl15326; Tue, 26 Feb 2002 19:51:19 -0800 Reply-To: From: "Kevin Zhang" To: "Reinaldo Penno" , Cc: , , , , , Subject: RE: [ipfix-req] IPfix candidates and Intellectual Property Rights Date: Tue, 26 Feb 2002 22:49:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010C_01C1BF17.D2888580" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <4F973E944951D311B6660008C7917CF008C5510A@zsc4c008.us.nortel.com> Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_010C_01C1BF17.D2888580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [ipfix-req] IPfix candidates and Intellectual Property RightsHi Reinaldo, As CRANE specification exists as an I-D, we are complying to all the IETF rules w.r.t. IPR. I will include the IPR statement in a future version of the CRANE draft. Thanks, Kevin -----Original Message----- From: Reinaldo Penno [mailto:reinaldo_penno@nortelnetworks.com] Sent: Tuesday, February 26, 2002 5:45 PM To: kcn@norseth.com Cc: kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com; n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu; ipfix-req@net.doit.wisc.edu Subject: RE: [ipfix-req] IPfix candidates and Intellectual Property Rights Hello K.C. I do not want to be picky, but what's the definition on "open"? Does it mean it's *free* of charge or that it can be licensed to anyone? You know, these two things make a lot of difference.(;-) I cheked the three drafts and it seems none of them have IPR statements. I think that if you have a IPR you need to put a statement on your draft... thanks, Reinaldo >-----Original Message----- >From: kcn@norseth.com [mailto:kcn@norseth.com] >Sent: Tuesday, February 26, 2002 2:38 PM >To: Penno, Reinaldo [SC9:T327:EXCH] >Cc: kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com; >n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu; >ipfix-req@net.doit.wisc.edu >Subject: Re: [ipfix-req] IPfix candidates and Intellectual Property >Rights > > >Reinaldo, > >Enclosed is the IETF policy. > http://www.ietf.org/ipr.html > >The IPFIX protocol has to be open so it can be accepted by all. > >On Tue, 26 February 2002, "Reinaldo Penno" wrote: > ------=_NextPart_000_010C_01C1BF17.D2888580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ipfix-req] IPfix candidates and Intellectual = Property Rights
Hi=20 Reinaldo,
 
As=20 CRANE specification exists as an I-D, we are complying to all the IETF = rules=20 w.r.t. IPR.  I will include the IPR statement in a future version = of the=20 CRANE draft.
 
Thanks,
 
Kevin
-----Original Message-----
From: Reinaldo Penno=20 [mailto:reinaldo_penno@nortelnetworks.com]
Sent: Tuesday, = February=20 26, 2002 5:45 PM
To: kcn@norseth.com
Cc:=20 kevin.zhang@xacct.com; calato@riverstonenet.com; bclaise@cisco.com;=20 n.brownlee@auckland.ac.nz; ipfix-arch@net.doit.wisc.edu;=20 ipfix-req@net.doit.wisc.edu
Subject: RE: [ipfix-req] IPfix=20 candidates and Intellectual Property Rights

Hello K.C.

I do not want to be picky, but what's the definition = on=20 "open"? Does it mean it's *free* of charge or that it can be licensed = to=20 anyone? You know, these two things make a lot of = difference.(;-)

I cheked the three drafts and it seems none of them = have IPR=20 statements. I think that if you have a IPR you need to put a statement = on your=20 draft...

thanks,

Reinaldo



>-----Original Message-----
>From: kcn@norseth.com [mailto:kcn@norseth.com] =
>Sent: Tuesday, February 26, 2002 2:38 PM
>To: Penno, Reinaldo [SC9:T327:EXCH]
>Cc:=20 kevin.zhang@xacct.com; calato@riverstonenet.com; = bclaise@cisco.com;=20
>n.brownlee@auckland.ac.nz;=20 ipfix-arch@net.doit.wisc.edu;
>ipfix-req@net.doit.wisc.edu
>Subject:=20 Re: [ipfix-req] IPfix candidates and Intellectual Property =
>Rights
>
>
>Reinaldo,
>
>Enclosed is the IETF = policy.=20
>   http://www.ietf.org/ipr.html
>
>The IPFIX protocol has to = be open so=20 it can be accepted by all.
> =
>On Tue, 26 February 2002, "Reinaldo Penno" wrote: =
>

------=_NextPart_000_010C_01C1BF17.D2888580-- -- 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 Feb 27 04:34:20 2002 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 EAA14772 for ; Wed, 27 Feb 2002 04:34:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g0B7-00047q-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 03:15:13 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16g0B5-00046J-00 for ipfix@net.doit.wisc.edu; Wed, 27 Feb 2002 03:15:11 -0600 Received: from cisco.com (bclaise-isdn-home4.cisco.com [10.49.4.221]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA25829; Wed, 27 Feb 2002 10:14:02 +0100 (MET) Message-ID: <3C7CA36A.5494F20B@cisco.com> Date: Wed, 27 Feb 2002 10:14:18 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: n.brownlee@auckland.ac.nz CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] Current WG activities References: <200202251845.HAA15845@mailhost.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Nevil, I'm confused by your email below. > > On 23 Feb, Peter Ludemann sent a few emails, pointing out the need to > make our arguments very clear on topics like 'how do we want to see > IPFIX exporters and collectors configured?' I agree that 'not in the > charter' isn't a very strong argument, but the WG is trying hard *not* > to invent a complete new protocol. So incremental improvements to an > existing protocol can certainly be talked about ... And a previous email you sent, which expresses: + Configuration: protocol ** Out of scope, i.e. WG should not consider this until we have the Arch and Data drafts well under way. - Randy, 20 Feb: reminder, out of scope On one side, you wrote: configuration is out of scope On the other side, you wrote: let's talk about improvements... Can you please shed some light, I'm confused. Regards, > > > Cheers, Nevil > > ----------------------------------------------------------------------- > Nevil Brownlee Director, Technology Development > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > -- > 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/ -- 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 Feb 27 05:06:20 2002 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 FAA15422 for ; Wed, 27 Feb 2002 05:06:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g0k1-0004xN-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 03:51:17 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16g0jz-0004wm-00 for ipfix-req@net.doit.wisc.edu; Wed, 27 Feb 2002 03:51:16 -0600 Received: from cisco.com (bclaise-isdn-home4.cisco.com [10.49.4.221]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA17002; Wed, 27 Feb 2002 10:50:41 +0100 (MET) Message-ID: <3C7CAC00.E40882D7@cisco.com> Date: Wed, 27 Feb 2002 10:50:57 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Fullmer CC: Peter Ludemann , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Collector Failover as a requirement References: <20020223235437.A84125@net.ohio-state.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Mark, Mark Fullmer wrote: > On Sat, Feb 23, 2002 at 11:51:56AM -0800, Peter Ludemann wrote: > > TCP's keepalive is not sufficient for detecting loss of connectivity, as > > sections 4.2.0 and 4.2.1 suggest (there is no guarantee that a collector > > crash will send any kind of signal to the sender, which is why TCP has such > > a complex start-up and shut-down; keepalive is not guaranteed to be > > A few suggestions to help aim at a middle ground between the > lightweight/best effort NetFlow (like) protocol vs. the > more resource intensive "reliable" drafts/implementations. > > o make the control connection in draft-gsadasiv-ipfix-proposal-00.txt > required and TCP. This removes the need for retransmits or > periodic updates of templates to the collector. When the collector > boots up it won't have to wait for templates. This also can > stop the router from generating flows to a non existant collector. This sounds actually like a good trade-off. Note that this idea is now part of http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architecture-00.txt 5.3. Collector Crash Detection and Recovery 5.3.1. Simple Export Model data stream and control stream: unreliable transport 5.3.2. Export Model with Reliable Control Connection data stream: unreliable or reliable transport control stream: reliable transport And also 5.4.Collector Crash Detection and Recovery 5.4.1. Simple Export Model 5.4.2. Export Model with Reliable Control Connection Regards, Benoit > > > o Implement a keepalive mechanism where the collector will ACK the > highest sequence number flow record it has processed per (any?) > "observation domain" The keepalive can be optional -- ie the > exporter can send a keepalive of N to inform the collector it > expects a keepalive every N seconds or 0 to disable it. Default > disabled. > > o The exporter will send the collector a message on the control > connection indicating where to listen for flow records > (ie what protocol UDP/TCP/SCTP) and addressing information > (port, IP address). Must UDP May TCP/SCTP. > > o Change the sequence number in draft-gsadasiv-ipfix-proposal-00.txt > to number of flows instead of number of packets so that the collector > can count lost flow records as in NetFlow v5,6,7,8. > > o Ignore the configuration of the exporter issue for now, but implement > the control connection message format such that it can be > tackled later, or implemented by a vendor and then submitted for > IPFIX v2. Ie, require the exporter to NAK any messages sent by > the collector it can not decode. > > > mark > > -- > 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/ -- 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 Feb 27 05:51:39 2002 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 FAA15986 for ; Wed, 27 Feb 2002 05:51:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g1OS-00062i-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 04:33:04 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16g1OQ-00061o-00 for ipfix-arch@net.doit.wisc.edu; Wed, 27 Feb 2002 04:33:02 -0600 Received: from cisco.com (bclaise-isdn-home4.cisco.com [10.49.4.221]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA15519; Wed, 27 Feb 2002 11:31:49 +0100 (MET) Message-ID: <3C7CB5A4.8748B219@cisco.com> Date: Wed, 27 Feb 2002 11:32:05 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: calato@riverstonenet.com CC: n.brownlee@auckland.ac.nz, reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <200202212141.KAA07738@mailhost.auckland.ac.nz> <3C762AFC.83794426@cisco.com> <3C76A7B1.184461FD@riverstonenet.com> <3C76D2FC.BC9D58ED@cisco.com> <3C7A532F.D7CA10BD@riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Paul, > Thought I would reply direct. > > I would check on that. Since the hardware > is the one that increments the counter as > packets are going through, the only way to > read the count and then set it to zero as > one operation would be to stop the hardware > from updating the counter while the read-set-to-zero > operation is happening. > > So either the netflow hardware really supports that > operation or a tradeoff was made to leave the issue as is. I called our specialist. Without going into the implementation details, his answer is: Our h/w does not loose any data when it happens. I'd think it's a bug if some h/w does it. Here is my view on the absolute/delta counters, as I wrote in a previous email. But I would like to expand on absolute/delta counters. If you think of keeping an absolute counter value, this is a counter you must maintain for all active flows. What should be the size? You have no idea initially ... a 32 or 64 bit counter? So you must have a 64 bit counter for every single flow. This implies a lot of memory (if not done in hardware) and it implies an extra 32 bits sent to the collector for every flow records! If you think of sending delta values, it's delta compared to what? To the flow aging time, right? Side question: Does it mean that you must have an absolute counter as well? So why don't we forget about absolute or delta counters but speak about the counters of the flow live time. For long run flows, you can just export the flow records with the accounting information seen during the flow live time. Knowing a long run flow is actually a serie of shorter flows with the same characteristics. You must export the flow records because: - you faced the long aging time timeout (for example: 30 minutes), then the live time of the flow is 30 minutes. We export the counters for that specific period of 30 minutes. - the 32 bits counter is about to wrap. Then you consider the flow to be ended (expired) sooner and export the accounting data for that period, whatever the period is. Now, because packets with the same characterics continue to arrive, a new flow with the same characterics will be directly created. Obviously with a counter starting at 0. That way, the collector won't be confused at all and you have an easier implementation. The explanation above was this idea when Ganesh and I wrote: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-data-00.txt 5.4. Flow Expiration ... 3. For long aging flows, the exporter SHOULD export the flow records on regular basis, in order to: a. report the flow records periodic accounting information to the collector b. avoid counter wrapping THERE IS A SMALL FORMATTING PROBLEM. THERE SHOULD BE A NEW LINE This activity timeout SHOULD be configurable 4. If the exporter experiences resources constraints, a flow MAY be prematurely expired (example: memory) Regards, Benoit > > > It would be good to know as it affects how to best > accomplish intermediate updates should we go that way. > > Paul > > Benoit Claise wrote: > > > > Paul, > > > > calato@riverstonenet.com wrote: > > > > > Benoit Claise wrote: > > > > > > > > Nevil, > > > > > > > > n.brownlee@auckland.ac.nz wrote: > > > > > > > > > Hi Reinaldo: > > > > > > > > > > > b. avoid counter wrapping." > > > > > > > > > > > > This activity SHOULD be configurable. Btw, can someone elaborate on the > > > > > > counter wrapping stuff? > > > > > > > > > > > > It is very simple to send so much data though the line on a flow that the > > > > > > byte counter rolls over. This is very typical in 1 gig and 10g ports. > > > > > > counter 32 is not large enough field size for this. > > > > > > > > > > > > yes, that's what I tought. So the solution is just to augment th efield to a > > > > > > 64 counter. It seems that the peirodic reporting is completely orthogonal to > > > > > > this specific issue. > > > > > > > > > > You've covered the 'counter wrapping' problem - a flow information meter > > > > > (whatever that turns out to be) needs counters wide enough not to wrap > > > > > too often, and that becomes more of a problem at high link speeds. > > > > > In RTFM, all counts are kept in 64-bit unsigned counters so that they > > > > > don't wrap too often. > > > > > > > > > > Of more interest, I don't remember seeing any IPFIX discussion > > > > > concerning just how information about long-running flows is to be > > > > > exported. In particular, I believe that counters should never be reset. > > > > > > > > Why? > > > > For long run flows, you can just export the flow records with the acconting > > > > information seen during that interval. > > > > If you must export the flow records because: > > > > - you faced the long aging time timeout (for example: 30 minutes) > > > > - the counters is about to wrap. > > > > then you consider the flow to be ended (expired) and export the accounting data > > > > for that period. > > > > Now a new flow with the same characterics will be directly created. Not a problem. > > > > And you start the accounting from 0 for that "new" flow. > > > > > > Most hardware can't do a get and set in one > > > operation. So in between reading the count > > > and setting it to zero you may loose some > > > of the count. > > > > I'm not too sure about the details of most hardware, but this is the way it works with > > netflow. > > > > Regards, Benoit > > > > > > > > > > > > The collector won't be confused at all and don't need to remember any values. > > > > > > > > Regards, Benoit > > > > > > > > > > > > > > That would mean that successive exports of the same flow would have > > > > > increasing counter values, a collector would need to remember the > > > > > previous value and subtract it. Furthermore, provided unsigned > > > > > arithmetic is used, the difference is correct even if the counter has > > > > > wrapped. Provided, of course that the counter has only wrapped once! > > > > > > > > > > Cheers, Nevil > > > > > > > > > > ----------------------------------------------------------------------- > > > > > Nevil Brownlee Director, Technology Development > > > > > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > > > > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > > > > > > > -- > > > > > 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/ > > > > > > > > -- > > > > 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/ -- 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 Feb 27 09:13:34 2002 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 JAA23333 for ; Wed, 27 Feb 2002 09:13:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g4Vv-0003MU-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 07:52:59 -0600 Received: from ctron-dnm.enterasys.com ([12.25.1.120] helo=ctron-dnm.ctron.com ident=firewall-user) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16g4Vu-0003MP-00 for ipfix-arch@net.doit.wisc.edu; Wed, 27 Feb 2002 07:52:58 -0600 Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id JAA19380; Wed, 27 Feb 2002 09:02:31 -0500 (EST) Received: from cnc-exc2(134.141.77.103) by ctron-dnm.ctron.com via smap (4.1) id xma019346; Wed, 27 Feb 02 09:02:01 -0500 Received: by smtp.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 08:51:27 -0500 Message-ID: <59358A738F45D51186A30008C74CE250DA073F@slc-exc1.ctron.com> From: "Norseth, KC" To: "'Benoit Claise'" , "Calato, Paul" Cc: n.brownlee@auckland.ac.nz, reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: RE: [ipfix-arch] counter wrapping Date: Wed, 27 Feb 2002 08:51:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BF95.E4CD80F0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BF95.E4CD80F0 Content-Type: text/plain |-----Original Message----- |From: Benoit Claise [mailto:bclaise@cisco.com] |Sent: Wednesday, February 27, 2002 3:32 AM |To: Calato, Paul |Cc: n.brownlee@auckland.ac.nz; |reinaldo_penno@nortelnetworks.com; ipfix-arch@net.doit.wisc.edu |Subject: Re: [ipfix-arch] counter wrapping | | |Paul, | | |> Thought I would reply direct. |> |> I would check on that. Since the hardware |> is the one that increments the counter as |> packets are going through, the only way to |> read the count and then set it to zero as |> one operation would be to stop the hardware |> from updating the counter while the read-set-to-zero operation is |> happening. |> |> So either the netflow hardware really supports that |> operation or a tradeoff was made to leave the issue as is. | |I called our specialist. Without going into the implementation |details, his answer is: Our h/w does not loose any data when |it happens. I'd think it's a bug if some h/w does it. | |Here is my view on the absolute/delta counters, as I wrote in |a previous email. But I would like to expand on absolute/delta |counters. | |If you think of keeping an absolute counter value, this is a |counter you must maintain for all active flows. What should be |the size? You have no idea initially ... a 32 or 64 bit |counter? So you must have a 64 bit counter for every single |flow. This implies a lot of memory (if not done in hardware) |and it implies an extra 32 bits sent to the collector for |every flow records! | |If you think of sending delta values, it's delta compared to |what? To the flow aging time, right? Side question: Does it |mean that you must have an absolute counter as well? | |So why don't we forget about absolute or delta counters but |speak about the counters of the flow live time. You cannot just forget absolute or delta counters. It is obviously an issue. It is also not clear in current documentation of flow accounting protocols, and implementation is difficult when you have to guess what is meant. We need to be clear in what we mean. you were to assume 30 minute intervals, that is asking for trouble. In the case of things like intrusion detection, you have to shorten the interval time down to 1 to 5 minutes. If a flow is exporting about 5m of packets every 5 minutes and the flow lasts 20 minutes, and we had an interval set of 5 minutes, we would see the byte count during export as 5m, 10m, 15m, 20m,... For this to be meainngful data to a an network analyst, he would want to see that there are 5m bytes going on during this time. Someone needs to give valid representation of this information, either the collector or the exporter. It is a lot easier for the exporter to provide this information. Having the exporter do it also makes sense in the case of collector failover nbeacuse the new collector does not know the history of the flow and would assume tnat when it sees 15m, it really means 15m, not 5 since the last time the exporter sent the flow. |For long run flows, you can just export the flow records with |the accounting information seen during the flow live time. |Knowing a long run flow is actually a serie of shorter flows |with the same characteristics. | |You must export the flow records because: | - you faced the long aging time timeout (for example: 30 |minutes), then the live time of the flow is 30 minutes. We |export the counters for that specific period of 30 minutes. | - the 32 bits counter is about to wrap. Then you consider the |flow to be ended (expired) sooner and export the accounting |data for that period, whatever the period is. | |Now, because packets with the same characterics continue to |arrive, a new flow with the same characterics will be directly |created. Obviously with a counter starting at 0. That way, the |collector won't be confused at all and you have an easier |implementation. | | |The explanation above was this idea when Ganesh and I wrote: |http://www.ietf.org/internet-drafts/draft-ietf-ipfix-data-00.txt | |5.4. Flow Expiration | | ... | | 3. For long aging flows, the exporter SHOULD export the flow | records on regular basis, in order to: | | a. report the flow records periodic accounting information | to the collector | b. avoid counter wrapping | | THERE IS A SMALL FORMATTING PROBLEM. THERE SHOULD BE |A NEW LINE | This activity timeout SHOULD be configurable | | 4. If the exporter experiences resources constraints, a flow | MAY be prematurely expired (example: memory) | |Regards, Benoit | |> |> |> It would be good to know as it affects how to best |> accomplish intermediate updates should we go that way. |> |> Paul |> |> Benoit Claise wrote: |> > |> > Paul, |> > |> > calato@riverstonenet.com wrote: |> > |> > > Benoit Claise wrote: |> > > > |> > > > Nevil, |> > > > |> > > > n.brownlee@auckland.ac.nz wrote: |> > > > |> > > > > Hi Reinaldo: |> > > > > |> > > > > > b. avoid counter wrapping." |> > > > > > |> > > > > > This activity SHOULD be configurable. Btw, can someone |> > > > > > elaborate on the counter wrapping stuff? |> > > > > > |> > > > > > It is very simple to send so much data though the |line on a |> > > > > > flow that the byte counter rolls over. This is |very typical |> > > > > > in 1 gig and 10g ports. counter 32 is not large enough |> > > > > > field size for this. |> > > > > > |> > > > > > yes, that's what I tought. So the solution is just to |> > > > > > augment th efield to a 64 counter. It seems that the |> > > > > > peirodic reporting is completely orthogonal to |this specific |> > > > > > issue. |> > > > > |> > > > > You've covered the 'counter wrapping' problem - a flow |> > > > > information meter (whatever that turns out to be) needs |> > > > > counters wide enough not to wrap too often, and that becomes |> > > > > more of a problem at high link speeds. In RTFM, all |counts are |> > > > > kept in 64-bit unsigned counters so that they don't wrap too |> > > > > often. |> > > > > |> > > > > Of more interest, I don't remember seeing any IPFIX |discussion |> > > > > concerning just how information about long-running |flows is to |> > > > > be exported. In particular, I believe that counters should |> > > > > never be reset. |> > > > |> > > > Why? |> > > > For long run flows, you can just export the flow records with |> > > > the acconting information seen during that interval. |If you must |> > > > export the flow records because: |> > > > - you faced the long aging time timeout (for example: 30 |> > > > minutes) |> > > > - the counters is about to wrap. |> > > > then you consider the flow to be ended (expired) and |export the accounting data |> > > > for that period. |> > > > Now a new flow with the same characterics will be |directly created. Not a problem. |> > > > And you start the accounting from 0 for that "new" flow. |> > > |> > > Most hardware can't do a get and set in one |> > > operation. So in between reading the count |> > > and setting it to zero you may loose some |> > > of the count. |> > |> > I'm not too sure about the details of most hardware, but |this is the |> > way it works with netflow. |> > |> > Regards, Benoit |> > |> > > |> > > |> > > > The collector won't be confused at all and don't need to |> > > > remember any values. |> > > > |> > > > Regards, Benoit |> > > > |> > > > > |> > > > > That would mean that successive exports of the same |flow would |> > > > > have increasing counter values, a collector would need to |> > > > > remember the previous value and subtract it. Furthermore, |> > > > > provided unsigned arithmetic is used, the difference is |> > > > > correct even if the counter has wrapped. Provided, |of course |> > > > > that the counter has only wrapped once! |> > > > > |> > > > > Cheers, Nevil |> > > > > |> > > > > |----------------------------------------------------------------------- |> > > > > Nevil Brownlee Director, |Technology Development |> > > > > Phone: +64 9 373 7599 x8941 ITSS, The |University of Auckland |> > > > > FAX: +64 9 373 7021 Private Bag 92019, |Auckland, New Zealand |> > > > > |> > > > > -- |> > > > > 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/ |> > > > |> > > > -- |> > > > 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/ | | |-- |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/ | ------_=_NextPart_001_01C1BF95.E4CD80F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipfix-arch] counter wrapping

|-----Original Message-----
|From: Benoit Claise [mailto:bclaise@cisco.com]
|Sent: Wednesday, February 27, 2002 3:32 AM
|To: Calato, Paul
|Cc: n.brownlee@auckland.ac.nz;
|reinaldo_penno@nortelnetworks.com; = ipfix-arch@net.doit.wisc.edu
|Subject: Re: [ipfix-arch] counter wrapping
|
|
|Paul,
|
|
|> Thought I would reply direct.
|>
|> I would check on that. Since the = hardware
|> is the one that increments the counter = as
|> packets are going through, the only way = to
|> read the count and then set it to zero = as
|> one operation would be to stop the = hardware
|> from updating the counter while the = read-set-to-zero operation is
|> happening.
|>
|> So either the netflow hardware really supports = that
|> operation or a tradeoff was made to leave the = issue as is.
|
|I called our specialist. Without going into the = implementation
|details, his answer is: Our h/w does not loose any = data when
|it happens. I'd think it's a bug if some h/w does = it.
|
|Here is my view on the absolute/delta counters, as = I wrote in
|a previous email. But I would like to expand on = absolute/delta
|counters.
|
|If you think of keeping an absolute counter value, = this is a
|counter you must maintain for all active flows. = What should be
|the size? You have no idea initially ... a 32 or 64 = bit
|counter? So you must have a 64 bit counter for = every single
|flow. This implies a lot of memory (if not done in = hardware)
|and it implies an extra 32 bits sent to the = collector for
|every flow records!
|
|If you think of sending delta values, it's delta = compared to
|what? To the flow aging time, right? Side question: = Does it
|mean that you must have an absolute counter as = well?
|
|So why don't we forget about absolute or delta = counters but
|speak about the counters of the flow  live = time.

You cannot just forget absolute or delta = counters.  It is obviously an issue.  It is also not clear in = current documentation of flow accounting protocols, and implementation = is difficult when you have to guess what is meant. We need to be clear = in what we mean.

 you were to assume 30 minute intervals, that is = asking for trouble.  In the case of things like intrusion = detection, you have to shorten the interval time down to 1 to 5 = minutes.

If a flow is exporting about 5m of packets every 5 = minutes and the flow lasts 20 minutes, and we had an interval set of 5 = minutes, we would see the byte count during export as 5m, 10m, 15m, = 20m,...  For this to be meainngful data to a an network analyst, = he would want to see that there are 5m bytes going on during this = time.  Someone needs to give valid representation of this = information, either the collector or the exporter.  It is a lot = easier for the exporter to provide this information.  Having the = exporter do it also makes sense in the case of collector failover = nbeacuse the new collector does not know the history of the flow and = would assume tnat when it sees 15m, it really means 15m, not 5 since = the last time the exporter sent the flow.

|For long run flows, you can just export the flow = records with
|the accounting information seen during the flow = live time.
|Knowing a long run flow is actually a serie of = shorter flows
|with the same characteristics.
|
|You must export the flow records because:
| - you faced the long aging time timeout (for = example: 30
|minutes), then the live time of the flow is 30 = minutes. We
|export the counters for that specific period of 30 = minutes.
| - the 32 bits counter is about to wrap. Then you = consider the
|flow to be ended (expired) sooner and export the = accounting
|data for that period, whatever the period = is.
|
|Now, because packets with the same characterics = continue to
|arrive, a new flow with the same characterics will = be directly
|created. Obviously with a counter starting at 0. = That way, the
|collector won't be confused at all and you have an = easier
|implementation.
|
|
|The explanation above was this idea when Ganesh and = I wrote:
|http://www.ietf.org/internet-drafts/draft-ietf-ipfix-d= ata-00.txt
|
|5.4. Flow Expiration
|
|      ...
|
|       3. For long = aging flows, the exporter SHOULD export the flow
|         = records on regular basis, in order to:
|
|         = a.  report the flow records periodic accounting information
|          &n= bsp;  to the collector
|         = b.  avoid counter wrapping
|
|          THERE = IS A SMALL FORMATTING PROBLEM. THERE SHOULD BE
|A NEW LINE
|          This = activity timeout SHOULD be configurable
|
|      4. If the exporter = experiences resources constraints, a flow
|         = MAY be prematurely expired (example: memory)
|
|Regards, Benoit
|
|>
|>
|> It would be good to know as it affects how to = best
|> accomplish intermediate updates should we go = that way.
|>
|> Paul
|>
|> Benoit Claise wrote:
|> >
|> > Paul,
|> >
|> > calato@riverstonenet.com wrote:
|> >
|> > > Benoit Claise wrote:
|> > > >
|> > > > Nevil,
|> > > >
|> > > > n.brownlee@auckland.ac.nz = wrote:
|> > > >
|> > > > > Hi Reinaldo:
|> > > > >
|> > > > > > b. avoid counter = wrapping."
|> > > > > >
|> > > > > > This activity SHOULD = be configurable. Btw, can someone
|> > > > > > elaborate on the = counter wrapping stuff?
|> > > > > >
|> > > > > > It is very simple to = send so much data though the
|line on a
|> > > > > > flow that the byte = counter rolls over.  This is
|very typical
|> > > > > > in 1 gig and = 10g  ports. counter 32 is not large enough
|> > > > > > field size for = this.
|> > > > > >
|> > > > > > yes, that's what I = tought. So the solution is just to
|> > > > > > augment th efield to = a 64 counter. It seems that the
|> > > > > > peirodic reporting is = completely orthogonal to
|this specific
|> > > > > > issue.
|> > > > >
|> > > > > You've covered the = 'counter wrapping' problem - a flow
|> > > > > information meter = (whatever that turns out to be) needs
|> > > > > counters wide enough not = to wrap too often, and that becomes
|> > > > > more of a problem at high = link speeds. In RTFM, all
|counts are
|> > > > > kept in 64-bit unsigned = counters so that they don't wrap too
|> > > > > often.
|> > > > >
|> > > > > Of more interest, I don't = remember seeing any IPFIX
|discussion
|> > > > > concerning just how = information about long-running
|flows is to
|> > > > > be exported.  In = particular, I believe that counters should
|> > > > > never be reset.
|> > > >
|> > > > Why?
|> > > > For long run flows, you can = just export the flow records with
|> > > > the acconting information seen = during that interval.
|If you must
|> > > > export the flow records = because:
|> > > >  - you faced the long = aging time timeout (for example: 30
|> > > > minutes)
|> > > >  - the counters is about = to wrap.
|> > > > then you consider the flow to = be ended (expired) and
|export the accounting data
|> > > > for that period.
|> > > > Now a new flow with the same = characterics will be
|directly created. Not a problem.
|> > > > And you start the accounting = from 0 for that "new" flow.
|> > >
|> > = >         Most hardware = can't do a get and set in one
|> > = >         operation. So in = between reading the count
|> > = >         and setting it to = zero you may loose some
|> > = >         of the = count.
|> >
|> > I'm not too sure about the details of = most hardware, but
|this is the
|> > way it works with netflow.
|> >
|> > Regards, Benoit
|> >
|> > >
|> > >
|> > > > The collector won't be confused = at all and don't need to
|> > > > remember any values.
|> > > >
|> > > > Regards, Benoit
|> > > >
|> > > > >
|> > > > > That would mean that = successive exports of the same
|flow would
|> > > > > have increasing counter = values, a collector would need to
|> > > > > remember the previous = value and subtract it.  Furthermore,
|> > > > > provided unsigned = arithmetic is used, the difference is
|> > > > > correct even if the = counter has wrapped.  Provided,
|of course
|> > > > > that the counter has only = wrapped once!
|> > > > >
|> > > > > Cheers, Nevil
|> > > > >
|> > > > >
|--------------------------------------------------------------= ---------
|> > > > >    Nevil = Brownlee          &nbs= p;        Director,
|Technology Development
|> > > > >    Phone: = +64 9 373 7599 x8941      ITSS, The
|University of Auckland
|> > > > >    FAX: +64 = 9 373 7021      Private Bag 92019,
|Auckland, New Zealand
|> > > > >
|> > > > > --
|> > > > > = Help        mailto:majordomo@net.doit.wi= sc.edu and
|say "help" in message body
|> > > > > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|> > > > > "unsubscribe = ipfix" in message body
|> > > > > = Archive     http://ipfix.doit.wisc.edu/archive/
|> > > >
|> > > > --
|> > > > = Help        mailto:majordomo@net.doit.wi= sc.edu and say
|"help" in message body
|> > > > Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|> > > > "unsubscribe ipfix" = in message body
|> > > > Archive     = http://ipfix.doit.wisc.edu/archive/
|
|
|--
|Help        mailto:majordomo@net.doit.wi= sc.edu and say "help"
|in message body
|Unsubscribe mailto:majordomo@net.doit.wi= sc.edu and say
|"unsubscribe ipfix" in message = body
|Archive     http://ipfix.doit.wisc.edu/archive/
|

------_=_NextPart_001_01C1BF95.E4CD80F0-- -- 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 Feb 27 09:42:23 2002 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 JAA24839 for ; Wed, 27 Feb 2002 09:42:23 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g514-000481-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 08:25:10 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16g512-00046o-00 for ipfix-arch@net.doit.wisc.edu; Wed, 27 Feb 2002 08:25:08 -0600 Received: from cisco.com (bclaise-isdn-home4.cisco.com [10.49.4.221]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id PAA14909; Wed, 27 Feb 2002 15:22:41 +0100 (MET) Message-ID: <3C7CEBC0.8B37EB59@cisco.com> Date: Wed, 27 Feb 2002 15:22:56 +0100 From: Benoit Claise X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Norseth, KC" CC: "Calato, Paul" , n.brownlee@auckland.ac.nz, reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <59358A738F45D51186A30008C74CE250DA073F@slc-exc1.ctron.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit KC,
 
|-----Original Message-----
|From: Benoit Claise [mailto:bclaise@cisco.com]
|Sent: Wednesday, February 27, 2002 3:32 AM
|To: Calato, Paul
|Cc: n.brownlee@auckland.ac.nz;
|reinaldo_penno@nortelnetworks.com; ipfix-arch@net.doit.wisc.edu
|Subject: Re: [ipfix-arch] counter wrapping
|
|
|Paul,
|
|
|> Thought I would reply direct.
|>
|> I would check on that. Since the hardware
|> is the one that increments the counter as
|> packets are going through, the only way to
|> read the count and then set it to zero as
|> one operation would be to stop the hardware
|> from updating the counter while the read-set-to-zero operation is
|> happening.
|>
|> So either the netflow hardware really supports that
|> operation or a tradeoff was made to leave the issue as is.
|
|I called our specialist. Without going into the implementation
|details, his answer is: Our h/w does not loose any data when
|it happens. I'd think it's a bug if some h/w does it.
|
|Here is my view on the absolute/delta counters, as I wrote in
|a previous email. But I would like to expand on absolute/delta
|counters.
|
|If you think of keeping an absolute counter value, this is a
|counter you must maintain for all active flows. What should be
|the size? You have no idea initially ... a 32 or 64 bit
|counter? So you must have a 64 bit counter for every single
|flow. This implies a lot of memory (if not done in hardware)
|and it implies an extra 32 bits sent to the collector for
|every flow records!
|
|If you think of sending delta values, it's delta compared to
|what? To the flow aging time, right? Side question: Does it
|mean that you must have an absolute counter as well?
|
|So why don't we forget about absolute or delta counters but
|speak about the counters of the flow  live time.

You cannot just forget absolute or delta counters.  It is obviously an issue.  It is also not clear in current documentation of flow accounting protocols, and implementation is difficult when you have to guess what is meant. We need to be clear in what we mean.

 you were to assume 30 minute intervals, that is asking for trouble.  In the case of things like intrusion detection, you have to shorten the interval time down to 1 to 5 minutes.

5.4
    section 3
          This activity timeout SHOULD be configurable
 

If a flow is exporting about 5m of packets every 5 minutes and the flow lasts 20 minutes, and we had an interval set of 5 minutes, we would see the byte count during export as 5m, 10m, 15m, 20m,...

Call it delta if you want to, but makes sense to export is:
              timestamps flow start     timestamps flow stop         counter
------------------------------------------------------------------------------------------
              t1 (minute 0)                 t2 (5th minute)                   5m
              t3 (5th minute)              t4 (10th minute)                 5m
              t5 (10th minute)            t6 (15th minute)                 5m
              t7 (20th minute)            t7 (20th minute)                 5m

Then the collector doesn't have to do diff to find out meaningfull values, to find out what happened in the previous 5 minutes
 

For this to be meainngful data to a an network analyst, he would want to see that there are 5m bytes going on during this time.  Someone needs to give valid representation of this information, either the collector or the exporter.
It is a lot easier for the exporter to provide this information.  Having the exporter do it also makes sense in the case of collector failover nbeacuse the new collector does not know the history of the flow and would assume tnat when it sees 15m, it really means 15m, not 5 since the last time the exporter sent the flow.
Some more arguments not to report 5m, 10m, 15m, 20m,.., or do I miss something?

Regards, Benoit

 

|For long run flows, you can just export the flow records with
|the accounting information seen during the flow live time.
|Knowing a long run flow is actually a serie of shorter flows
|with the same characteristics.
|
|You must export the flow records because:
| - you faced the long aging time timeout (for example: 30
|minutes), then the live time of the flow is 30 minutes. We
|export the counters for that specific period of 30 minutes.
| - the 32 bits counter is about to wrap. Then you consider the
|flow to be ended (expired) sooner and export the accounting
|data for that period, whatever the period is.
|
|Now, because packets with the same characterics continue to
|arrive, a new flow with the same characterics will be directly
|created. Obviously with a counter starting at 0. That way, the
|collector won't be confused at all and you have an easier
|implementation.
|
|
|The explanation above was this idea when Ganesh and I wrote:
|http://www.ietf.org/internet-drafts/draft-ietf-ipfix-data-00.txt
|
|5.4. Flow Expiration
|
|      ...
|
|       3. For long aging flows, the exporter SHOULD export the flow
|         records on regular basis, in order to:
|
|         a.  report the flow records periodic accounting information
|             to the collector
|         b.  avoid counter wrapping
|
|          THERE IS A SMALL FORMATTING PROBLEM. THERE SHOULD BE
|A NEW LINE
|          This activity timeout SHOULD be configurable
|
|      4. If the exporter experiences resources constraints, a flow
|         MAY be prematurely expired (example: memory)
|
|Regards, Benoit
|
|>
|>
|> It would be good to know as it affects how to best
|> accomplish intermediate updates should we go that way.
|>
|> Paul
|>
|> Benoit Claise wrote:
|> >
|> > Paul,
|> >
|> > calato@riverstonenet.com wrote:
|> >
|> > > Benoit Claise wrote:
|> > > >
|> > > > Nevil,
|> > > >
|> > > > n.brownlee@auckland.ac.nz wrote:
|> > > >
|> > > > > Hi Reinaldo:
|> > > > >
|> > > > > > b. avoid counter wrapping."
|> > > > > >
|> > > > > > This activity SHOULD be configurable. Btw, can someone
|> > > > > > elaborate on the counter wrapping stuff?
|> > > > > >
|> > > > > > It is very simple to send so much data though the
|line on a
|> > > > > > flow that the byte counter rolls over.  This is
|very typical
|> > > > > > in 1 gig and 10g  ports. counter 32 is not large enough
|> > > > > > field size for this.
|> > > > > >
|> > > > > > yes, that's what I tought. So the solution is just to
|> > > > > > augment th efield to a 64 counter. It seems that the
|> > > > > > peirodic reporting is completely orthogonal to
|this specific
|> > > > > > issue.
|> > > > >
|> > > > > You've covered the 'counter wrapping' problem - a flow
|> > > > > information meter (whatever that turns out to be) needs
|> > > > > counters wide enough not to wrap too often, and that becomes
|> > > > > more of a problem at high link speeds. In RTFM, all
|counts are
|> > > > > kept in 64-bit unsigned counters so that they don't wrap too
|> > > > > often.
|> > > > >
|> > > > > Of more interest, I don't remember seeing any IPFIX
|discussion
|> > > > > concerning just how information about long-running
|flows is to
|> > > > > be exported.  In particular, I believe that counters should
|> > > > > never be reset.
|> > > >
|> > > > Why?
|> > > > For long run flows, you can just export the flow records with
|> > > > the acconting information seen during that interval.
|If you must
|> > > > export the flow records because:
|> > > >  - you faced the long aging time timeout (for example: 30
|> > > > minutes)
|> > > >  - the counters is about to wrap.
|> > > > then you consider the flow to be ended (expired) and
|export the accounting data
|> > > > for that period.
|> > > > Now a new flow with the same characterics will be
|directly created. Not a problem.
|> > > > And you start the accounting from 0 for that "new" flow.
|> > >
|> > >         Most hardware can't do a get and set in one
|> > >         operation. So in between reading the count
|> > >         and setting it to zero you may loose some
|> > >         of the count.
|> >
|> > I'm not too sure about the details of most hardware, but
|this is the
|> > way it works with netflow.
|> >
|> > Regards, Benoit
|> >
|> > >
|> > >
|> > > > The collector won't be confused at all and don't need to
|> > > > remember any values.
|> > > >
|> > > > Regards, Benoit
|> > > >
|> > > > >
|> > > > > That would mean that successive exports of the same
|flow would
|> > > > > have increasing counter values, a collector would need to
|> > > > > remember the previous value and subtract it.  Furthermore,
|> > > > > provided unsigned arithmetic is used, the difference is
|> > > > > correct even if the counter has wrapped.  Provided,
|of course
|> > > > > that the counter has only wrapped once!
|> > > > >
|> > > > > Cheers, Nevil
|> > > > >
|> > > > >
|-----------------------------------------------------------------------
|> > > > >    Nevil Brownlee                   Director,
|Technology Development
|> > > > >    Phone: +64 9 373 7599 x8941      ITSS, The
|University of Auckland
|> > > > >    FAX: +64 9 373 7021      Private Bag 92019,
|Auckland, New Zealand
|> > > > >
|> > > > > --
|> > > > > 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/
|> > > >
|> > > > --
|> > > > 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/
|
|
|--
|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/
|

-- 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 Feb 27 11:45:59 2002 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 LAA01549 for ; Wed, 27 Feb 2002 11:45:59 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g6ip-0007DO-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 10:14:27 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g6in-0007DF-00 for ipfix@net.doit.wisc.edu; Wed, 27 Feb 2002 10:14:25 -0600 Date: Wed, 27 Feb 2002 10:14:25 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-architecture-00.txt Message-ID: <20020227101425.B20231@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-W-HWM_STALL, internal I/O stalled by highwater mark activity X-Shakespearean-Insult: Thou infectious dizzy-eyed mumble-news Precedence: bulk Sender: majordomo listserver Below please find the announcement regarding the availability of the updated architecture draft. I've also updated the link on our IPFIX web site ("http://ipfix.doit.wisc.edu"). Dave ----- Forwarded message from owner-ipfix@net.doit.wisc.edu ----- To: IETF-Announce: ; Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipfix-architecture-00.txt Date: Wed, 27 Feb 2002 07:22:26 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Architecture Architecture for IP Flow Information Export Author(s) : K.C. Norseth, G. Sadasivan Filename : draft-ietf-ipfix-architecture-00.txt Pages : 24 Date : 26-Feb-02 This document defines architecture for scalable monitoring, measuring and exporting IP flow information to collectors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architecture-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-architecture-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-architecture-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-architecture-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-architecture-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130205.I-D@ietf.org> --OtherAccess-- --NextPart-- ----- End forwarded message ----- -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Feb 27 11:47:01 2002 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 LAA01647 for ; Wed, 27 Feb 2002 11:47:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g6kR-0007H2-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 10:16:07 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g6kP-0007Gv-00 for ipfix@net.doit.wisc.edu; Wed, 27 Feb 2002 10:16:05 -0600 Date: Wed, 27 Feb 2002 10:16:05 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-data-00.txt Message-ID: <20020227101605.C20231@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-W-HWM_STALL, internal I/O stalled by highwater mark activity X-Shakespearean-Insult: Thou infectious dizzy-eyed mumble-news Precedence: bulk Sender: majordomo listserver Below please find the announcement regarding the availability of the updated info/data model draft. I've also updated the link on our IPFIX web site ("http://ipfix.doit.wisc.edu"). Dave ----- Forwarded message from owner-ipfix@net.doit.wisc.edu ----- To: IETF-Announce: ; Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipfix-data-00.txt Date: Wed, 27 Feb 2002 07:22:31 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Data Model Data Model for IP Flow Information Export Author(s) : K. Norseth, P. Calato Filename : draft-ietf-ipfix-data-00.txt Pages : 25 Date : 26-Feb-02 This document defines an information and daqta model for scalable monitoring, measuring and exporting IP flow information to collectors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-data-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-data-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-data-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020226130217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-data-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-data-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020226130217.I-D@ietf.org> --OtherAccess-- --NextPart-- ----- End forwarded message ----- -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Feb 27 11:52:19 2002 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 LAA02237 for ; Wed, 27 Feb 2002 11:52:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g6yQ-0007c1-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 10:30:34 -0600 Received: from sj-msg-core-2.cisco.com ([171.69.24.11]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16g6yP-0007Zl-00 for ipfix@net.doit.wisc.edu; Wed, 27 Feb 2002 10:30:33 -0600 Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g1RGTsE25966; Wed, 27 Feb 2002 08:29:59 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-54.cisco.com [171.71.137.54]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id ABH80264; Wed, 27 Feb 2002 08:30:16 -0800 (PST) Message-ID: <3C7D0980.1107A202@cisco.com> Date: Wed, 27 Feb 2002 08:29:52 -0800 From: Ganesh Sadasivan X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: plonka@doit.wisc.edu CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] I-D ACTION:draft-ietf-ipfix-architecture-00.txt References: <20020227101425.B20231@doit.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit sections 3.0 and 4.0 of the architecture has undergone some non-trivial changes along with minor changes in section 5.0 & 8.0 . We hope to update the doc. with the changed sections in a day or two. Thanks Ganesh Dave Plonka wrote: > Below please find the announcement regarding the availability of the > updated architecture draft. I've also updated the link on our IPFIX > web site ("http://ipfix.doit.wisc.edu"). > > Dave > > ----- Forwarded message from owner-ipfix@net.doit.wisc.edu ----- > > To: IETF-Announce: ; > Cc: ipfix@net.doit.wisc.edu > From: Internet-Drafts@ietf.org > Reply-to: Internet-Drafts@ietf.org > Subject: I-D ACTION:draft-ietf-ipfix-architecture-00.txt > Date: Wed, 27 Feb 2002 07:22:26 -0500 > Sender: nsyracus@cnri.reston.va.us > > --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Flow Information Export Working Group of the IETF. > > Title : IPFIX Architecture Architecture for IP Flow > Information Export > Author(s) : K.C. Norseth, G. Sadasivan > Filename : draft-ietf-ipfix-architecture-00.txt > Pages : 24 > Date : 26-Feb-02 > > This document defines architecture for scalable monitoring, > measuring and exporting IP flow information to collectors. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architecture-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ipfix-architecture-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipfix-architecture-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > --NextPart > Content-Type: Multipart/Alternative; Boundary="OtherAccess" > > --OtherAccess > Content-Type: Message/External-body; > access-type="mail-server"; > server="mailserv@ietf.org" > > Content-Type: text/plain > Content-ID: <20020226130205.I-D@ietf.org> > > ENCODING mime > FILE /internet-drafts/draft-ietf-ipfix-architecture-00.txt > > --OtherAccess > Content-Type: Message/External-body; > name="draft-ietf-ipfix-architecture-00.txt"; > site="ftp.ietf.org"; > access-type="anon-ftp"; > directory="internet-drafts" > > Content-Type: text/plain > Content-ID: <20020226130205.I-D@ietf.org> > > --OtherAccess-- > > --NextPart-- > > ----- End forwarded message ----- > > -- > plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI > > -- > 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/ -- 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 Feb 27 12:28:32 2002 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 MAA04692 for ; Wed, 27 Feb 2002 12:28:32 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g7SP-0000Xy-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 11:01:34 -0600 Received: from mailhost.auckland.ac.nz ([130.216.1.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16g7SN-0000Xp-00 for ipfix@net.doit.wisc.edu; Wed, 27 Feb 2002 11:01:31 -0600 Received: from auckland.ac.nz (root@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id GAA09103; Thu, 28 Feb 2002 06:00:54 +1300 (NZDT) Message-Id: <200202271700.GAA09103@mailhost.auckland.ac.nz> Date: Wed, 27 Feb 2002 09:03:10 -0800 (PST) From: n.brownlee@auckland.ac.nz Subject: Re: [ipfix] Current WG activities To: bclaise@cisco.com cc: ipfix@net.doit.wisc.edu In-Reply-To: <3C7CA36A.5494F20B@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Precedence: bulk Sender: majordomo listserver Hi Benoit: >> On 23 Feb, Peter Ludemann sent a few emails, pointing out the need to >> make our arguments very clear on topics like 'how do we want to see >> IPFIX exporters and collectors configured?' I agree that 'not in the >> charter' isn't a very strong argument, but the WG is trying hard *not* >> to invent a complete new protocol. So incremental improvements to an >> existing protocol can certainly be talked about ... > > And a previous email you sent, which expresses: > + Configuration: protocol > ** Out of scope, i.e. WG should not consider this until we have > the Arch and Data drafts well under way. > - Randy, 20 Feb: reminder, out of scope > > On one side, you wrote: configuration is out of scope > On the other side, you wrote: let's talk about improvements... > > Can you please shed some light, I'm confused. 1) The Arch and Data version 00 drafts are now published (another WG Goal met). 2) The charter says we'll "select a protocol," which means we need to work on - i.e. discuss further on the list - the selection criteria for that protocol. 3) It seems to me that discussing aspects like exporter and collector configuration methods is helpful; it would be good to see some consensus on this emerge. 4) In selecting a protocol, we'll pick the one which comes closest to meeting all the selection criteria. *If* the chosen one could be *slightly* modified or extended to meet all the criteria, we may have to consider including those modifications in the final IPFIX Arcitecture document. The main point of my 'current WG activities' posting was really "the -00 drafts are out," now we can/should try to reach consensus on the issues which got a lot of airing on the mailing list earlier. Does that help? Cheers, Nevil PS: On the question of IPR. Randy has reiterated the IETF (RFC 2026) position on this. I had assumed that all those with 'candidate protocols' (and published drafts documenting them) had read and understood RFC 2026. ----------------------------------------------------------------------- Nevil Brownlee Director, Technology Development Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand -- 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 Feb 27 14:17:56 2002 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 OAA11546 for ; Wed, 27 Feb 2002 14:17:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g9Kv-0002XD-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 13:01:57 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16g9Ku-0002Lc-00 for ipfix-req@net.doit.wisc.edu; Wed, 27 Feb 2002 13:01:56 -0600 Received: from riverstonenet.com (134.141.180.84 [134.141.180.84]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY0YLH; Wed, 27 Feb 2002 11:00:39 -0800 Message-ID: <3C7D2CD5.DB506BA2@riverstonenet.com> Date: Wed, 27 Feb 2002 14:00:37 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: Mark Fullmer , Peter Ludemann , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Collector Failover as a requirement References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Kevin Zhang wrote: > > Hi Mark, > > Thanks for some very good ideas you offered, please see my comments inserted. > > Kevin > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Mark Fullmer > > Sent: Saturday, February 23, 2002 11:55 PM > > To: Peter Ludemann > > Cc: ipfix-req@net.doit.wisc.edu > > Subject: Re: [ipfix-req] Collector Failover as a requirement > > > > > > On Sat, Feb 23, 2002 at 11:51:56AM -0800, Peter Ludemann wrote: > > > TCP's keepalive is not sufficient for detecting loss of connectivity, as > > > sections 4.2.0 and 4.2.1 suggest (there is no guarantee that a collector > > > crash will send any kind of signal to the sender, which is why > > TCP has such > > > a complex start-up and shut-down; keepalive is not guaranteed to be > > > > A few suggestions to help aim at a middle ground between the > > lightweight/best effort NetFlow (like) protocol vs. the > > more resource intensive "reliable" drafts/implementations. > > > > o make the control connection in draft-gsadasiv-ipfix-proposal-00.txt > > required and TCP. This removes the need for retransmits or > > periodic updates of templates to the collector. When the collector > > boots up it won't have to wait for templates. This also can > > stop the router from generating flows to a non existant collector. > > > > o Implement a keepalive mechanism where the collector will ACK the > > highest sequence number flow record it has processed per (any?) > > "observation domain" The keepalive can be optional -- ie the > > exporter can send a keepalive of N to inform the collector it > > expects a keepalive every N seconds or 0 to disable it. Default > > disabled. > This is a very good idea. keepalive can be piggybacked through ACKs from collectors. This will not only serve as indication of collector fault conditions as well as congestion, it can also improve transport reliability. This should be done on the IPFIX protocol layer whether TCP or UDP is used as the transport protocol. > > > > > o The exporter will send the collector a message on the control > > connection indicating where to listen for flow records > > (ie what protocol UDP/TCP/SCTP) and addressing information > > (port, IP address). Must UDP May TCP/SCTP. > The current IPFIX architecture draft from the design team proposed to use UDP to convey some low level information such as IPFIX version, transport protocol support, and port number. I think this could achieve this requirment. > > > > > o Change the sequence number in draft-gsadasiv-ipfix-proposal-00.txt > > to number of flows instead of number of packets so that the collector > > can count lost flow records as in NetFlow v5,6,7,8. > > > Simply counting the lost flow records may not be enough as values associated with each record are different (e.g. start of a flow, end of a flow, interim records). We should really base our design over a reliable transport layer that offers congestion control. UDP can optionally be used for limited configurations. One note here. Once the exporter runs out of room information will be lost. We need to handle/define the "lost data" situation in **ANY** solution we define. > > > o Ignore the configuration of the exporter issue for now, but implement > > the control connection message format such that it can be > > tackled later, or implemented by a vendor and then submitted for > > IPFIX v2. Ie, require the exporter to NAK any messages sent by > > the collector it can not decode. > > > I believe required control messages must be included in this version as options. For those exporting devices that can not support them, a simple reply from exporter to collector will signal the limitation of the exporter; then both devices will fall back to a setting that is less demanding on the exporter. > > > > > mark > > > > -- > > 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/ > > > > éi?¨¥¶?s?SÝ¢j'z×hSÜ"±Ç?¹©Ý±¬¡zZb?g¬±¨n?rR{.nÇ+?·¦j)m¢f£¢·hs?ÞµÚ"·¬qçnjwlk+§²æìr¸>z*_<§?ë,j>¡Ü?­Èb½èm¶YÿS-âÅÚ"·¬qçnýªÜ?+Þ -- 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 Feb 27 14:18:26 2002 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 OAA11587 for ; Wed, 27 Feb 2002 14:18:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16g9HC-0001U9-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 12:58:06 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16g9HA-0001JD-00 for ipfix-arch@net.doit.wisc.edu; Wed, 27 Feb 2002 12:58:04 -0600 Received: from riverstonenet.com (134.141.180.84 [134.141.180.84]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY0YJG; Wed, 27 Feb 2002 10:56:42 -0800 Message-ID: <3C7D2BE8.CCB47BC1@riverstonenet.com> Date: Wed, 27 Feb 2002 13:56:40 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Reinaldo Penno CC: Benoit Claise , n.brownlee@auckland.ac.nz, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <4F973E944951D311B6660008C7917CF008C54725@zsc4c008.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > > Hello Paul, > > Could we just have the two counters as proposed by Ganesh (absolute > and delta)? An implementation would use one or the other as it sees > fit. > Yes. I just wanted to point out the issue with deltas. It should be there as an option though. Paul > regards, > > Reinaldo > > >-----Original Message----- > >From: calato@riverstonenet.com [mailto:calato@riverstonenet.com] > >Sent: Monday, February 25, 2002 7:07 AM > >To: Benoit Claise > >Cc: n.brownlee@auckland.ac.nz; Penno, Reinaldo [SC9:T327:EXCH]; > >ipfix-arch@net.doit.wisc.edu > >Subject: Re: [ipfix-arch] counter wrapping > > > > > > > >Thought I would reply direct. > > > >I would check on that. Since the hardware > >is the one that increments the counter as > >packets are going through, the only way to > >read the count and then set it to zero as > >one operation would be to stop the hardware > >from updating the counter while the read-set-to-zero > >operation is happening. > > > >So either the netflow hardware really supports that > >operation or a tradeoff was made to leave the issue > >as is. > > > >It would be good to know as it affects how to best > >accomplish intermediate updates should we go that way. > > > >Paul > > > >Benoit Claise wrote: > >> > >> Paul, > >> > >> calato@riverstonenet.com wrote: > >> > >> > Benoit Claise wrote: > >> > > > >> > > Nevil, > >> > > > >> > > n.brownlee@auckland.ac.nz wrote: > >> > > > >> > > > Hi Reinaldo: > >> > > > > >> > > > > b. avoid counter wrapping." > >> > > > > > >> > > > > This activity SHOULD be configurable. Btw, can > >someone elaborate on the > >> > > > > counter wrapping stuff? > >> > > > > > >> > > > > It is very simple to send so much data though the > >line on a flow that the > >> > > > > byte counter rolls over. This is very typical in 1 > >gig and 10g ports. > >> > > > > counter 32 is not large enough field size for this. > >> > > > > > >> > > > > yes, that's what I tought. So the solution is just > >to augment th efield to a > >> > > > > 64 counter. It seems that the peirodic reporting is > >completely orthogonal to > >> > > > > this specific issue. > >> > > > > >> > > > You've covered the 'counter wrapping' problem - a flow > >information meter > >> > > > (whatever that turns out to be) needs counters wide > >enough not to wrap > >> > > > too often, and that becomes more of a problem at high > >link speeds. > >> > > > In RTFM, all counts are kept in 64-bit unsigned > >counters so that they > >> > > > don't wrap too often. > >> > > > > >> > > > Of more interest, I don't remember seeing any IPFIX > discussion > >> > > > concerning just how information about long-running > >flows is to be > >> > > > exported. In particular, I believe that counters > >should never be reset. > >> > > > >> > > Why? > >> > > For long run flows, you can just export the flow records > >with the acconting > >> > > information seen during that interval. > >> > > If you must export the flow records because: > >> > > - you faced the long aging time timeout (for example: > >30 minutes) > >> > > - the counters is about to wrap. > >> > > then you consider the flow to be ended (expired) and > >export the accounting data > >> > > for that period. > >> > > Now a new flow with the same characterics will be > >directly created. Not a problem. > >> > > And you start the accounting from 0 for that "new" flow. > >> > > >> > Most hardware can't do a get and set in one > >> > operation. So in between reading the count > >> > and setting it to zero you may loose some > >> > of the count. > >> > >> I'm not too sure about the details of most hardware, but > >this is the way it works with > >> netflow. > >> > >> Regards, Benoit > >> > >> > > >> > > >> > > The collector won't be confused at all and don't need to > >remember any values. > >> > > > >> > > Regards, Benoit > >> > > > >> > > > > >> > > > That would mean that successive exports of the same > >flow would have > >> > > > increasing counter values, a collector would need to > >remember the > >> > > > previous value and subtract it. Furthermore, provided > unsigned > >> > > > arithmetic is used, the difference is correct even if > >the counter has > >> > > > wrapped. Provided, of course that the counter has > >only wrapped once! > >> > > > > >> > > > Cheers, Nevil > >> > > > > >> > > > > >----------------------------------------------------------------------- > > >> > > > Nevil Brownlee Director, > >Technology Development > >> > > > Phone: +64 9 373 7599 x8941 ITSS, The > >University of Auckland > >> > > > FAX: +64 9 373 7021 Private Bag 92019, > >Auckland, New Zealand > >> > > > > >> > > > -- > >> > > > 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/ > >> > > > >> > > -- > >> > > 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/ > > -- 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 Feb 27 15:45:02 2002 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 PAA16855 for ; Wed, 27 Feb 2002 15:45:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16gAYB-0004eY-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 14:19:43 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16gAY8-0004dn-00 for ipfix-req@net.doit.wisc.edu; Wed, 27 Feb 2002 14:19:40 -0600 Received: from riverstonenet.com (134.141.180.84 [134.141.180.84]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY0ZLV; Wed, 27 Feb 2002 12:18:18 -0800 Message-ID: <3C7D3F08.6A6F8ABD@riverstonenet.com> Date: Wed, 27 Feb 2002 15:18:16 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: kevin.zhang@xacct.com CC: Ganesh Sadasivan , Peter Ludemann , Mark Fullmer , ipfix-req@net.doit.wisc.edu Subject: Re: [ipfix-req] Collector Failover as a requirement References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 8bit Kevin Zhang wrote: > > Please see my comments inserted. > > Thanks, > > Kevin > > > -----Original Message----- > > From: majordomo listserver [mailto:majordomo@mil.doit.wisc.edu]On Behalf > > Of Ganesh Sadasivan > > Sent: Monday, February 25, 2002 1:30 PM > > To: Peter Ludemann > > Cc: Mark Fullmer; ipfix-req@net.doit.wisc.edu > > Subject: Re: [ipfix-req] Collector Failover as a requirement > > > > > > Hi Peter, > > > > Peter Ludemann wrote: > > > > > My comments interspersed. > > > > > > > From: Mark Fullmer [mailto:maf@eng.oar.net] > > > > Sent: Saturday, February 23, 2002 8:55 PM > > > > To: Peter Ludemann > > > > Cc: ipfix-req@net.doit.wisc.edu > > > > Subject: Re: [ipfix-req] Collector Failover as a requirement > > > > > > > > > > > > On Sat, Feb 23, 2002 at 11:51:56AM -0800, Peter Ludemann wrote: > > > > > TCP's keepalive is not sufficient for detecting loss of > > connectivity, as > > > > > sections 4.2.0 and 4.2.1 suggest (there is no guarantee > > that a collector > > > > > crash will send any kind of signal to the sender, which is why > > > > TCP has such > > > > > a complex start-up and shut-down; keepalive is not guaranteed to be > > > > > > > > A few suggestions to help aim at a middle ground between the > > > > lightweight/best effort NetFlow (like) protocol vs. the > > > > more resource intensive "reliable" drafts/implementations. > > > > > > In a normal deployment, with the collector close to the sender, > > "reliable" > > > isn't more resource-intensive. And TCP is a reasonable choice; the > > > latest NFS is done over TCP because it's as efficient as using > > > UDP and avoids re-inventing wheels for things like congestion control. > > > When a connection is broken, TCP uses longer and longer intervals when > > > retransmitting, so the execution overhead remains small. > > > > What is a "normal deployment"? TCP is not as efficient as UDP in terms > > of processing requirements (this should be fairly obvious). Well if the > > network is reliable enough, I think UDP would work out better. > > > I really doubt we can assume the network is reliable. The potential deployment of IPFIX systems will involve WAN, and including exporting devices such as probes, mid-boxes etc. Let's not limit ourselves too much at this time. Another issue with UDP is that it is not congestion aware, it can interfere with network traffics from other sources. This is clearly required in our charter. > > > > > > > > > > Having said that, it is impossible to make a 100% reliable system. > > > If connections go down, eventually there will be no more room inside > > > the sender to store data, so some data must be discarded. The protocol > > > must be able to detect this and inform the receiver (when things are > > > reconnected). > > > > > > One more thing about unreliable protocols ... they're > > attractive in theory > > > but in practice we find ourselves building workarounds to make them > > > seem reliable (this applies to both NetFlow and SNMP). Any data delivery > > > method that avoids reliability simply pushes things on to another > > > part of the system. > > > > I am curious to know the workarounds done on top of Netflow to make it > > relaible? > > > With TCP and SCTP widely availabe, what's the point to replicate many of their features over UDP. > > > > > > > > > > > o make the control connection in > > draft-gsadasiv-ipfix-proposal-00.txt > > > > required and TCP. This removes the need for retransmits or > > > > periodic updates of templates to the collector. When the > > collector > > > > boots up it won't have to wait for templates. This also can > > > > stop the router from generating flows to a non existant collector. > > > > > > I don't think that only TCP should be required. I would also allow SCTP > > > ... it's better than TCP for fail-over, but not widely available yet. > > > > > > > o Implement a keepalive mechanism where the collector will ACK the > > > > highest sequence number flow record it has processed per (any?) > > > > "observation domain" The keepalive can be optional -- ie the > > > > exporter can send a keepalive of N to inform the collector it > > > > expects a keepalive every N seconds or 0 to disable it. Default > > > > disabled. > > > > > > This is essentially the way that CRANE works. However, I don't think > > > that a keepalive gives any advantage ... the sender should just time > > > out and failover if it doesn't receive a data ACK in time (there's no > > > need for keepalives when no data are being sent). [Downstream > > > deduplication will always be needed for handling failures because > > > ACKs can get lost.] > > > > > > [I'm currently doing some experiments on the best way to do ACKs to > > > get the fastest failover; so I reserve the right to change my mind > > > about heartbeet keepalives.] > > > > > > > o The exporter will send the collector a message on the control > > > > connection indicating where to listen for flow records > > > > (ie what protocol UDP/TCP/SCTP) and addressing information > > > > (port, IP address). Must UDP May TCP/SCTP. > > > > > > The initial message can also advertise the protocol version. > > > > > > > > I would be opposed to UDP for data delivery. I don't see any > > > performance advantages and it causes a lot of downstream > > > processing pain. > > > > Can you explain a little more here? > > > Without adding features over UDP, IPFIX over UDP would be unreliable, congestion UN-aware, incapable of supporting redundancy configurations, and more. Simply using TCP does not make it reliable. You still need application level reliability. Once you do that, UDP becomes more reliable becasue re-transmit happens at a the application level. However it is still congestion unaware. You can also still do redundancy with a keepalive as has already been discussed. I don't think UDP can be ruled out so easily. > > > > > > > > > > > > > o Change the sequence number in draft-gsadasiv-ipfix-proposal-00.txt > > > > to number of flows instead of number of packets so that > > the collector > > > > can count lost flow records as in NetFlow v5,6,7,8. > > > > There are other means to achive the same in the new protocol. > > Basically the > > flowsets tell the length and using the size of each record in the > > flowset, one > > can calculate the # of records. > > > > > > > > > > > Access to the packet count is not possible with most TCP implementations > > > anyway. > > > > > > > o Ignore the configuration of the exporter issue for now, > > but implement > > > > the control connection message format such that it can be > > > > tackled later, or implemented by a vendor and then submitted for > > > > IPFIX v2. Ie, require the exporter to NAK any messages sent by > > > > the collector it can not decode. > > > > > > I believe that content negotiation is important for reasons of > > performance > > > and synchronizing amongst receivers in a fail-over setup. Other in-band > > > configuration is less important (it can be done via MIBS but is also > > > easier to define in a generic way (essentially a set of keyword/value > > > pairs that must be all handled as a single transaction ... like SNMP > > > SET but with database-style transaction control). > > > > > > I would like to see in v1: > > > - a standard data protocol (with generic configuration) using TCP > > > for transport > > > - a core set of values and types (the "data model") > > > and in v2: > > > - other transport protocols (such as SCTP) > > > - additional standard values and types > > > - additional standard kinds of configuration > > > > > > The v1 protocol must allow this future extensibility. > > > > inband config and content negotiation I already replied to your > > previous mail. I am not convinced it is worth adding it in this > > framework. > > Thanks > > Ganesh > > > > > > > > > > > > > > > > > > > > mark > > > > > > - peter > > > > > > ---------- > > > Peter Ludemann +1.408.330.5732 > > > Chief Architect +1.650.248.3973 (mobile) > > > XACCT Technologies peter.ludemann@xacct.com > > > 2900 Lakeside Drive http://www.xacct.com > > > Santa Clara CA 95054 > > > > > > -- > > > 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/ > > > > > > -- > > 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/ > > > > > > éi?¨¥¶?s?SÝ¢j'z×hSÜ"±Ç?¹©Ý±¬¡zZb?g¬±¨n?rR{.nÇ+?·¦j)m¢f£¢·hs?ÞµÚ"·¬qçnjwlk+§²æìr¸>z*_<§?ë,j>¡Ü?­Èb½èm¶YÿS-âÅÚ"·¬qçnýªÜ?+Þ -- 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 Feb 27 16:05:12 2002 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 QAA18029 for ; Wed, 27 Feb 2002 16:05:11 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16gAzZ-0005IE-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 14:48:01 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16gAzW-0005HA-00 for ipfix-arch@net.doit.wisc.edu; Wed, 27 Feb 2002 14:47:58 -0600 Received: from riverstonenet.com (134.141.180.84 [134.141.180.84]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY0Z9C; Wed, 27 Feb 2002 12:46:37 -0800 Message-ID: <3C7D45AB.9274E9C2@riverstonenet.com> Date: Wed, 27 Feb 2002 15:46:35 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: n.brownlee@auckland.ac.nz, reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <200202212141.KAA07738@mailhost.auckland.ac.nz> <3C762AFC.83794426@cisco.com> <3C76A7B1.184461FD@riverstonenet.com> <3C76D2FC.BC9D58ED@cisco.com> <3C7A532F.D7CA10BD@riverstonenet.com> <3C7CB5A4.8748B219@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > Paul, > > > Thought I would reply direct. > > > > I would check on that. Since the hardware > > is the one that increments the counter as > > packets are going through, the only way to > > read the count and then set it to zero as > > one operation would be to stop the hardware > > from updating the counter while the read-set-to-zero > > operation is happening. > > > > So either the netflow hardware really supports that > > operation or a tradeoff was made to leave the issue as is. > > I called our specialist. Without going into the implementation details, his answer is: > Our h/w does not loose any data when it happens. I'd think it's a bug if some h/w does it. > > Here is my view on the absolute/delta counters, as I wrote in a previous email. But I would > like to expand on absolute/delta counters. > > If you think of keeping an absolute counter value, this is a counter you must maintain for > all active flows. What should be the size? You have no idea initially ... a 32 or 64 bit > counter? So you must have a 64 bit counter for every single flow. This implies a lot of > memory (if not done in hardware) and it implies an extra 32 bits sent to the collector for > every flow records! > > If you think of sending delta values, it's delta compared to what? To the flow aging time, > right? > Side question: Does it mean that you must have an absolute counter as well? > > So why don't we forget about absolute or delta counters but speak about the counters of the > flow live time. I think we need to offer both in order to support existing devices. Some hardware only have cumulative counters with no atomic get/set operation. > > For long run flows, you can just export the flow records with the accounting information > seen during the flow live time. Knowing a long run flow is actually a serie of shorter flows > with the same characteristics. This depends on how flow updates get reported. Since most of the flow information is static attributes then they can be reported once with updates only reporting counts and a "flowID" (aka LFAP style). This can save a lot of bits on the wire. But there are drawbacks to this approach as well. I assume we'll get into those nasty details at some point. > > You must export the flow records because: > - you faced the long aging time timeout (for example: 30 minutes), then the live time of > the flow is 30 minutes. We export the counters for that specific period of 30 minutes. > - the 32 bits counter is about to wrap. Then you consider the flow to be ended (expired) > sooner and export the accounting data for that period, whatever the period is. > > Now, because packets with the same characterics continue to arrive, a new flow with the same > characterics will be directly created. Obviously with a counter starting at 0. > That way, the collector won't be confused at all and you have an easier implementation. > > The explanation above was this idea when Ganesh and I wrote: > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-data-00.txt > > 5.4. Flow Expiration > > ... > > 3. For long aging flows, the exporter SHOULD export the flow > records on regular basis, in order to: > > a. report the flow records periodic accounting information > to the collector > b. avoid counter wrapping > > THERE IS A SMALL FORMATTING PROBLEM. THERE SHOULD BE A NEW LINE > This activity timeout SHOULD be configurable > > 4. If the exporter experiences resources constraints, a flow > MAY be prematurely expired (example: memory) > > Regards, Benoit > > > > > > > It would be good to know as it affects how to best > > accomplish intermediate updates should we go that way. > > > > Paul > > > > Benoit Claise wrote: > > > > > > Paul, > > > > > > calato@riverstonenet.com wrote: > > > > > > > Benoit Claise wrote: > > > > > > > > > > Nevil, > > > > > > > > > > n.brownlee@auckland.ac.nz wrote: > > > > > > > > > > > Hi Reinaldo: > > > > > > > > > > > > > b. avoid counter wrapping." > > > > > > > > > > > > > > This activity SHOULD be configurable. Btw, can someone elaborate on the > > > > > > > counter wrapping stuff? > > > > > > > > > > > > > > It is very simple to send so much data though the line on a flow that the > > > > > > > byte counter rolls over. This is very typical in 1 gig and 10g ports. > > > > > > > counter 32 is not large enough field size for this. > > > > > > > > > > > > > > yes, that's what I tought. So the solution is just to augment th efield to a > > > > > > > 64 counter. It seems that the peirodic reporting is completely orthogonal to > > > > > > > this specific issue. > > > > > > > > > > > > You've covered the 'counter wrapping' problem - a flow information meter > > > > > > (whatever that turns out to be) needs counters wide enough not to wrap > > > > > > too often, and that becomes more of a problem at high link speeds. > > > > > > In RTFM, all counts are kept in 64-bit unsigned counters so that they > > > > > > don't wrap too often. > > > > > > > > > > > > Of more interest, I don't remember seeing any IPFIX discussion > > > > > > concerning just how information about long-running flows is to be > > > > > > exported. In particular, I believe that counters should never be reset. > > > > > > > > > > Why? > > > > > For long run flows, you can just export the flow records with the acconting > > > > > information seen during that interval. > > > > > If you must export the flow records because: > > > > > - you faced the long aging time timeout (for example: 30 minutes) > > > > > - the counters is about to wrap. > > > > > then you consider the flow to be ended (expired) and export the accounting data > > > > > for that period. > > > > > Now a new flow with the same characterics will be directly created. Not a problem. > > > > > And you start the accounting from 0 for that "new" flow. > > > > > > > > Most hardware can't do a get and set in one > > > > operation. So in between reading the count > > > > and setting it to zero you may loose some > > > > of the count. > > > > > > I'm not too sure about the details of most hardware, but this is the way it works with > > > netflow. > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > The collector won't be confused at all and don't need to remember any values. > > > > > > > > > > Regards, Benoit > > > > > > > > > > > > > > > > > That would mean that successive exports of the same flow would have > > > > > > increasing counter values, a collector would need to remember the > > > > > > previous value and subtract it. Furthermore, provided unsigned > > > > > > arithmetic is used, the difference is correct even if the counter has > > > > > > wrapped. Provided, of course that the counter has only wrapped once! > > > > > > > > > > > > Cheers, Nevil > > > > > > > > > > > > ----------------------------------------------------------------------- > > > > > > Nevil Brownlee Director, Technology Development > > > > > > Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland > > > > > > FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand > > > > > > > > > > > > -- > > > > > > 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/ > > > > > > > > > > -- > > > > > 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/ -- 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 Feb 27 16:28:25 2002 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 QAA19548 for ; Wed, 27 Feb 2002 16:28:24 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16gBIW-0005mB-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 15:07:36 -0600 Received: from host3.riverstonenet.com ([63.113.148.3] helo=exc-sc1.yagosys.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16gBIU-0005m0-00 for ipfix-arch@net.doit.wisc.edu; Wed, 27 Feb 2002 15:07:35 -0600 Received: from riverstonenet.com (134.141.180.100 [134.141.180.100]) by exc-sc1.yagosys.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1PZY05HW; Wed, 27 Feb 2002 13:06:15 -0800 Message-ID: <3C7D4A44.2AE92ECD@riverstonenet.com> Date: Wed, 27 Feb 2002 16:06:12 -0500 From: calato@riverstonenet.com X-Mailer: Mozilla 4.75C-CCK-MCD NSCPCD475 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Benoit Claise CC: "Norseth, KC" , n.brownlee@auckland.ac.nz, reinaldo_penno@nortelnetworks.com, ipfix-arch@net.doit.wisc.edu Subject: Re: [ipfix-arch] counter wrapping References: <59358A738F45D51186A30008C74CE250DA073F@slc-exc1.ctron.com> <3C7CEBC0.8B37EB59@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > KC, > > > > > |-----Original Message----- > > |From: Benoit Claise [mailto:bclaise@cisco.com] > > |Sent: Wednesday, February 27, 2002 3:32 AM > > |To: Calato, Paul > > |Cc: n.brownlee@auckland.ac.nz; > > |reinaldo_penno@nortelnetworks.com; ipfix-arch@net.doit.wisc.edu > > |Subject: Re: [ipfix-arch] counter wrapping > > | > > | > > |Paul, > > | > > | > > |> Thought I would reply direct. > > |> > > |> I would check on that. Since the hardware > > |> is the one that increments the counter as > > |> packets are going through, the only way to > > |> read the count and then set it to zero as > > |> one operation would be to stop the hardware > > |> from updating the counter while the read-set-to-zero operation is > > > > |> happening. > > |> > > |> So either the netflow hardware really supports that > > |> operation or a tradeoff was made to leave the issue as is. > > | > > |I called our specialist. Without going into the implementation > > |details, his answer is: Our h/w does not loose any data when > > |it happens. I'd think it's a bug if some h/w does it. > > | > > |Here is my view on the absolute/delta counters, as I wrote in > > |a previous email. But I would like to expand on absolute/delta > > |counters. > > | > > |If you think of keeping an absolute counter value, this is a > > |counter you must maintain for all active flows. What should be > > |the size? You have no idea initially ... a 32 or 64 bit > > |counter? So you must have a 64 bit counter for every single > > |flow. This implies a lot of memory (if not done in hardware) > > |and it implies an extra 32 bits sent to the collector for > > |every flow records! > > | > > |If you think of sending delta values, it's delta compared to > > |what? To the flow aging time, right? Side question: Does it > > |mean that you must have an absolute counter as well? > > | > > |So why don't we forget about absolute or delta counters but > > |speak about the counters of the flow live time. > > > > You cannot just forget absolute or delta counters. It is obviously > > an issue. It is also not clear in current documentation of flow > > accounting protocols, and implementation is difficult when you have > > to guess what is meant. We need to be clear in what we mean. > > > > you were to assume 30 minute intervals, that is asking for > > trouble. In the case of things like intrusion detection, you have > > to shorten the interval time down to 1 to 5 minutes. > > 5.4 > section 3 > This activity timeout SHOULD be configurable > > > > > > > If a flow is exporting about 5m of packets every 5 minutes and the > > flow lasts 20 minutes, and we had an interval set of 5 minutes, we > > would see the byte count during export as 5m, 10m, 15m, 20m,... > > Call it delta if you want to, but makes sense to export is: > timestamps flow start timestamps flow stop > counter > ------------------------------------------------------------------------------------------ > > t1 (minute 0) t2 (5th > minute) 5m > t3 (5th minute) t4 (10th > minute) 5m > t5 (10th minute) t6 (15th > minute) 5m > t7 (20th minute) t7 (20th > minute) 5m > > Then the collector doesn't have to do diff to find out meaningfull > values, to find out what happened in the previous 5 minutes > > Agreed. But if the device cannot do the deltas in hardware then it is forced to get extra memory for EACH flow so it can do the deltas. For situations where the flow key is granular I would rather have the Collector keep the extra memory per flow since. But you do have an issue on failover. However, this may be mitigated by the fact that low granularity flows be definition will have less data lost. perhaps an acceptable tradeoff is this high volume case. The Collectors can of course also solve the problem, but that is out of scope. When the Key is coarse, then I would want to use delta counts which help ensure no data loss on failover. The volume is also likely to be less so if the hardware doesn't support it, a shadow software count may be acceptable. By having both, the implementor can make the choice. BTW - I'm all for limiting the number of options where possible. But **if** strong, real world arguments can be made for both cumulative and deltas then we should not force one or the other. > > For this to be meainngful data to a an network analyst, he would > > want to see that there are 5m bytes going on during this time. > > Someone needs to give valid representation of this information, > > either the collector or the exporter. > > > It is a lot easier for the exporter to provide this information. > > Having the exporter do it also makes sense in the case of collector > > failover nbeacuse the new collector does not know the history of the > > flow and would assume tnat when it sees 15m, it really means 15m, > > not 5 since the last time the exporter sent the flow. > > Some more arguments not to report 5m, 10m, 15m, 20m,.., or do I miss > something? > > Regards, Benoit > > > > > > > |For long run flows, you can just export the flow records with > > |the accounting information seen during the flow live time. > > |Knowing a long run flow is actually a serie of shorter flows > > |with the same characteristics. > > | > > |You must export the flow records because: > > | - you faced the long aging time timeout (for example: 30 > > |minutes), then the live time of the flow is 30 minutes. We > > |export the counters for that specific period of 30 minutes. > > | - the 32 bits counter is about to wrap. Then you consider the > > |flow to be ended (expired) sooner and export the accounting > > |data for that period, whatever the period is. > > | > > |Now, because packets with the same characterics continue to > > |arrive, a new flow with the same characterics will be directly > > |created. Obviously with a counter starting at 0. That way, the > > |collector won't be confused at all and you have an easier > > |implementation. > > | > > | > > |The explanation above was this idea when Ganesh and I wrote: > > |http://www.ietf.org/internet-drafts/draft-ietf-ipfix-data-00.txt > > | > > |5.4. Flow Expiration > > | > > | ... > > | > > | 3. For long aging flows, the exporter SHOULD export the flow > > > > | records on regular basis, in order to: > > | > > | a. report the flow records periodic accounting > > information > > | to the collector > > | b. avoid counter wrapping > > | > > | THERE IS A SMALL FORMATTING PROBLEM. THERE SHOULD BE > > |A NEW LINE > > | This activity timeout SHOULD be configurable > > | > > | 4. If the exporter experiences resources constraints, a flow > > | MAY be prematurely expired (example: memory) > > | > > |Regards, Benoit > > | > > |> > > |> > > |> It would be good to know as it affects how to best > > |> accomplish intermediate updates should we go that way. > > |> > > |> Paul > > |> > > |> Benoit Claise wrote: > > |> > > > |> > Paul, > > |> > > > |> > calato@riverstonenet.com wrote: > > |> > > > |> > > Benoit Claise wrote: > > |> > > > > > |> > > > Nevil, > > |> > > > > > |> > > > n.brownlee@auckland.ac.nz wrote: > > |> > > > > > |> > > > > Hi Reinaldo: > > |> > > > > > > |> > > > > > b. avoid counter wrapping." > > |> > > > > > > > |> > > > > > This activity SHOULD be configurable. Btw, can someone > > |> > > > > > elaborate on the counter wrapping stuff? > > |> > > > > > > > |> > > > > > It is very simple to send so much data though the > > |line on a > > |> > > > > > flow that the byte counter rolls over. This is > > |very typical > > |> > > > > > in 1 gig and 10g ports. counter 32 is not large enough > > > > |> > > > > > field size for this. > > |> > > > > > > > |> > > > > > yes, that's what I tought. So the solution is just to > > |> > > > > > augment th efield to a 64 counter. It seems that the > > |> > > > > > peirodic reporting is completely orthogonal to > > |this specific > > |> > > > > > issue. > > |> > > > > > > |> > > > > You've covered the 'counter wrapping' problem - a flow > > |> > > > > information meter (whatever that turns out to be) needs > > |> > > > > counters wide enough not to wrap too often, and that > > becomes > > |> > > > > more of a problem at high link speeds. In RTFM, all > > |counts are > > |> > > > > kept in 64-bit unsigned counters so that they don't wrap > > too > > |> > > > > often. > > |> > > > > > > |> > > > > Of more interest, I don't remember seeing any IPFIX > > |discussion > > |> > > > > concerning just how information about long-running > > |flows is to > > |> > > > > be exported. In particular, I believe that counters > > should > > |> > > > > never be reset. > > |> > > > > > |> > > > Why? > > |> > > > For long run flows, you can just export the flow records > > with > > |> > > > the acconting information seen during that interval. > > |If you must > > |> > > > export the flow records because: > > |> > > > - you faced the long aging time timeout (for example: 30 > > |> > > > minutes) > > |> > > > - the counters is about to wrap. > > |> > > > then you consider the flow to be ended (expired) and > > |export the accounting data > > |> > > > for that period. > > |> > > > Now a new flow with the same characterics will be > > |directly created. Not a problem. > > |> > > > And you start the accounting from 0 for that "new" flow. > > |> > > > > |> > > Most hardware can't do a get and set in one > > |> > > operation. So in between reading the count > > |> > > and setting it to zero you may loose some > > |> > > of the count. > > |> > > > |> > I'm not too sure about the details of most hardware, but > > |this is the > > |> > way it works with netflow. > > |> > > > |> > Regards, Benoit > > |> > > > |> > > > > |> > > > > |> > > > The collector won't be confused at all and don't need to > > |> > > > remember any values. > > |> > > > > > |> > > > Regards, Benoit > > |> > > > > > |> > > > > > > |> > > > > That would mean that successive exports of the same > > |flow would > > |> > > > > have increasing counter values, a collector would need to > > > > |> > > > > remember the previous value and subtract it. > > Furthermore, > > |> > > > > provided unsigned arithmetic is used, the difference is > > |> > > > > correct even if the counter has wrapped. Provided, > > |of course > > |> > > > > that the counter has only wrapped once! > > |> > > > > > > |> > > > > Cheers, Nevil > > |> > > > > > > |> > > > > > > > > ----------------------------------------------------------------------- > > > > |> > > > > Nevil Brownlee Director, > > |Technology Development > > |> > > > > Phone: +64 9 373 7599 x8941 ITSS, The > > |University of Auckland > > |> > > > > FAX: +64 9 373 7021 Private Bag 92019, > > |Auckland, New Zealand > > |> > > > > > > |> > > > > -- > > |> > > > > 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/ > > |> > > > > > |> > > > -- > > |> > > > 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/ > > | > > | > > |-- > > |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/ > > | -- 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 Feb 27 17:33:10 2002 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 RAA22619 for ; Wed, 27 Feb 2002 17:33:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16gCHr-0007LS-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 16:10:59 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16gCHo-0007LM-00 for ipfix@net.doit.wisc.edu; Wed, 27 Feb 2002 16:10:56 -0600 Date: Wed, 27 Feb 2002 16:10:56 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] URL for updated arch draft Message-ID: <20020227161056.A27808@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Organization: UW-Madison, DoIT, Network Services X-VMS-Error: %SYSTEM-W-SUBRNG5, subscript 5 range error, PC=00000000, PS=00000596 X-Shakespearean-Insult: Thou clouted rude-growing varlet Precedence: bulk Sender: majordomo listserver IPFIX folks, KC and Ganesh have updated the architecture draft. We've put it on the IPFIX site here: http://ipfix.doit.wisc.edu/arch/ I'll be happy to put other updates in that directory and/or do similarly for the other req/data/app documents if the editors would find that useful. Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- 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 Feb 27 18:51:05 2002 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 SAA24784 for ; Wed, 27 Feb 2002 18:51:05 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 16gDLh-00018G-00 for ipfix-list@mil.doit.wisc.edu; Wed, 27 Feb 2002 17:19:01 -0600 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 16gDLa-00017f-00 for ipfix-data@net.doit.wisc.edu; Wed, 27 Feb 2002 17:18:54 -0600 Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1RNDK825021; Wed, 27 Feb 2002 17:13:21 -0600 (CST) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 15:13:18 -0800 Message-ID: <4F973E944951D311B6660008C7917CF008CBBDEB@zsc4c008.us.nortel.com> From: "Reinaldo Penno" To: "Norseth, KC" , calato@riverstonenet.com Cc: ipfix-data@net.doit.wisc.edu Subject: [ipfix-data] Data doc Date: Wed, 27 Feb 2002 15:13:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BFE4.568107F0" Precedence: bulk Sender: majordomo listserver This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BFE4.568107F0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BFE4.568107F0" ------_=_NextPart_001_01C1BFE4.568107F0 Content-Type: text/plain; charset="ISO-8859-1" Hello KC, Paul here it goes the sections I promised in one single doc. regards, Reinaldo ------_=_NextPart_001_01C1BFE4.568107F0 Content-Type: text/html; charset="ISO-8859-1" [ipfix-data] Data doc

Hello KC, Paul

here it goes the sections I promised in one single doc.

regards,

Reinaldo

  ------_=_NextPart_001_01C1BFE4.568107F0-- ------_=_NextPart_000_01C1BFE4.568107F0 Content-Type: text/plain; name="draft-ietf-ipfix-data-reinaldo-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ipfix-data-reinaldo-00.txt" Content-Transfer-Encoding: quoted-printable 6.9.3. Egress ATM Circuit =0A= =0A= The egress vpi/vci for the flow is provided in this Information = element. =0A= vpi/vci id is defined by the ATM Forum UNI 3.1 specification:=0A= =0A= Template ID: ### Field Type: ### Size: ### =0A= =0A= 6.9.4. Egress Frame Relay DLCI =0A= =0A= The egress DLCI for the flow is provided in this Information element. = =0A= ITU Q.922 defines the DLCI range. The frDlcmiState and the specific =0A= values of the DLCIis are defined in RFC 2115.=0A= =0A= Template ID: ### Field Type: ### Size: ### =0A= =0A= 6.10.1. Source Address Netmask =0A= =0A= The number of bits in the CIDR netmask, as defined in RFC 1519, for =0A= the source address. =0A= =0A= Template ID: ### Field Type: ### Size: ### =0A= =0A= 6.10.2. Destination Address Netmask =0A= =0A= The number of bits in the CIDR netmask, as defined in RFC 1519, for =0A= the destination address. =0A= =0A= 6.11.4. Source VLAN ID =0A= =0A= The Source VLAN ID associated with the flow. VLAN ID is defined by =0A= IEEE standard 802.1q - 1998[802.1q]. =0A= =0A= A VLAN Ethernet interface should only accept packets in which the =0A= VLAN-ID matches the VLAN-ID associated to its interface=0A= =0A= Template ID: ### Field Type: ### Size: ###=0A= =0A= 6.11.5. Destination VLAN ID =0A= =0A= The destination VLAN ID associated with the flow. VLAN ID is defined=0A= by IEEE standard 802.1q - 1998[802.1q].=0A= =0A= It=92s possible that the destination VLAN-ID in the packet is different = =0A= than the interface VLAN-ID.=0A= =0A= Template ID: ### Field Type: ### Size: ###=0A= =0A= 6.12. Middlebox and other Services=0A= =0A= An exporter may be involved in providing services that require =0A= application level intelligence and/or transform or filter content such = =0A= as middlebox and OPES respectively.=0A= =0A= When the exporter is involved on these types of services the order of = =0A= the IEs that contain information associated with these service MUST =0A= reflect the order of the operations performed.=0A= =0A= Each type field of the following IEs contain the type of operation =0A= performed on the packet. The currently available types are:=0A= =0A= 1. - NAT =0A= 2. - LSNAT =0A= 3. - Twice NAT =0A= 4. - Request Routing [KRR]=0A= 5. - Outgoing L3 Tunnel =0A= 6. - Incoming L3 Tunnel =0A= 7. - Outgoing L2 Tunnel =0A= 8. - Incoming L2 Tunnel =0A= 9. - OPES (several sub-services here) =0A= 10. - others... =0A= =0A= 6.12.1. Modified Source Address =0A= =0A= This information element contains the source address of the flow as =0A= transmitted by the Exporter after a middlebox, OPES or similar service = =0A= was applied to the packet. It may be different than the source address = =0A= information element, which contains the original source address of the = packet.=0A= =0A= The address is defined the same as for Source Address.=0A= =0A= Template ID: ### Field Type: ### Size: ###=0A= =0A= 6.12.2. Modified Source Port =0A= =0A= This information element contains the source port of the flow as =0A= transmitted by the exporter after a middlebox, OPES or similar service = =0A= was applied to the packet. It may be different than the source port =0A= information element, which contains the original source port of the = packet. =0A= =0A= Template ID: ### Field Type: ### Size: ###=0A= =0A= =0A= 6.12.3. Modified Destination Address =0A= =0A= This information element contains the destination address of the flow = =0A= as transmitted by the exporter after a middlebox, OPES or similar =0A= service was applied to the packet. It might be different than the =0A= destination address information element, which contains the original = =0A= destination address of the packet.=0A= =0A= Template ID: ### Field Type: ### Size: ###=0A= =0A= =0A= 6.12.4. Destination Virtual Port =0A= =0A= This information element contains the destination port of the flow as = =0A= transmitted by the exporter after a middlebox, OPES or similar service = =0A= was applied to the packet. It may be different than the destination =0A= port information element, which contains the original destination port = =0A= of the packet. =0A= =0A= Template ID: ### Field Type: ### Size: ###=0A= =0A= 6.13. Vendor Specific =0A= =0A= Vendors may add their own information to the protocol. Information =0A= contained in this information element is vendor specific. OID and OID = =0A= Value are defined by ITU X.680.X683 (1997) and are encoded as defined = =0A= by ITU X.690.691(1997). This information element MUST not contain any = =0A= information which cannot be safely ignored by the Exporter or Collector.= =0A= If multiple Vendor Specific information element's with the same OID = occur, =0A= then the vendor defines semantics of ordering.=0A= =0A= Template ID: ### Field Type: ### Size: ###=0A= =0A= Remove section below - 6.14.4 =96 Implementation Specific.=0A= =0A= 6.14.4. Internal queue priority=0A= =0A= A switch may map several of its internal priority queues into a = Premium, =0A= High, Medium or Low category.=0A= =0A= =0A= Template ID: ### Field Type: ### Size: ###=0A= =0A= =0A= 7. References=0A= =0A= [KRR] A. Barbir et al., "Known CN Request-Routing Mechanisms", =0A= draft-ietf-cdi-known-request-routing-00.txt, February 2002=0A= =0A= =0A= =0A= =0A= ------_=_NextPart_000_01C1BFE4.568107F0-- -- 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/